ITEC 4010: Systems Analysis and Design II

Lecture 16
Mapping UML object models

Professor Peter Khaiter

Topics
Mapping concept

Types of transformations

Mapping to code

Mapping to persistent storage schema

Introduction 2
Mapping concept: transformation types
 Forward engineering is maintaining a strong
correspondence between the design model and
the code
e.g., each UML class is mapped to a Java class
 Reverse engineering is maintaining a strong
correspondence between the source code
elements and the elements of the design model
inverse transformation of forward engineering
e.g. create UML class for each Java class declaration
statement
 Many CASE tools support reverse engineering

Introduction 3
Mapping associations in code
 In UML, associations denote collections of
bidirectional links between two or more
objects
 OOPL: do not support associations, but
provide references:
one object stores a handle to another object
 During mapping, association is realized in
terms of references
 Multiplicity of associations and their direction
are taken into account

Introduction 4
Mapping associations: unidirectional 1:1
 Client has a unidirectional 1:1 association
with Account object; Client calls the
operations of the Account, but Account
never invokes operations of the Client
 Mapping: using a reference from Client to
Account, i.e., adding an attribute account of
type Account public class Client {
private Account account;
public Client() {
account = new
Client 1 1 Account
Account();
}
public Account getAccount()
{
return account;
}
Introduction
} 5
 Mapping associations: bidirectional 1:1
 Introduces mutual dependences among classes
that need to work together closely
 Assume that Account needs to display the
Client who is the owner and therefore needs to
access its Client object – by adding owner
attribute of Client type to Account in Java code
public class Client { public class Account {
private Account account; private Client owner;
public Client() { public Account(Client owner) {
account = new Account(this); this.owner = owner();
} }
public Account getAccount() { public Client getOwner() {
return account; return owner;
} }
} }

Introduction 6
 Mapping associations: 1:M
 cannot be realized using a single reference or
a pair of references
 requires a collection of references
 assume that Client can have several
Accounts - use a set of references called
accounts
public class Client {
private Set accounts;
public Client() {
accounts = new Set();
Client 1 * Account
}
…….
}

Introduction 7
 Mapping associations: M:M
 assume the Tournament class has an
ordered many-to-many association with the
Player class – realized by using a List
attribute in each class
Tournament * {ordered} * Player

public class Tournament { public class Player {

private List players; private List tournaments;
public Tournament() { public Player() {
players = new ArrayList(); tournament = new ArrayList();
} }
……. …..
} }

Introduction 8
Mapping qualified associations
 used to reduce multiplicity of one “many” side in
1:M or M:M association – by introducing an
attribute of the class on the “many” side
 Consider a M:M association between League
and Player. Assume that Players can choose a
nickname that is unique within the League

League * * Player

League nickName * 0..1 Player

Introduction 9
Mapping qualified associations
 Realization: a Map object is used to
represent the qualified end; qualifier is
passed as a parameter in the operations to
access the other end of the association
 A private player attribute is created in
League and a league attributed – in
Player
 The player attribute is a Map indexed by the
nickname of the Player within the League
(because the nickname is stored in the Map, a
specific Player can have different
nicknames across Leagues
Introduction 10
 Mapping qualified associations

public class League { public class Player {

private Map players; private Map leagues;
public void addPlayer public void addLeague
(String nickName, Player p) { (String nickName, League l) {
….. …..
} }
……. …..
} }

Introduction 11
Mapping association classes
 In IML, association class holds the
attributes and operations of the association
 Realization: transform the association class
into a separate object with corresponding
binary associations (reified class!)
 then apply techniques (from previous
slides) to convert each binary association to
a set of reference attributes

Lecture 16 12
 Mapping association classes
Statistics

+getAverageStats(name)
+getTotalStats(name)
+updateStats(name)

Tournament * * Player

Statistics
* 1 1 *
Tournament +getAverageStats(name) Player
+getTotalStats(name)
+updateStats(name)

Introduction 13
Mapping Object Models to
Persistent Storage Schema

Lecture 16 14
Levels of data models
 Data model (database schema) is an abstraction
that presents the database structures in more
understandable terms than as raw bits and bytes
External (conceptual) data model
as required by a single application
entity-relationship (ER) diagrams
Logical data model (global conceptual schema)
reflects logical storage structures (tables, etc.) of the
database model to be used for the system implementation
a global integrated model to support any current and
expected applications that need accessing information
stored in the database
Physical data model
specific to a particular DBMS (such as Oracle10g).
defines how data is actually stored on persistent storage
devices, typically disks (defines indexes, clustering of data,
etc.)

Introduction 15
Integrating application and data modeling
Mapping of application model to the database model
Applic atio n

<<s ubs ys tem>>

pre s e ntatio n

object-relational
mapping
<<s ubs ys tem>>
c o ntro l
Databas e

databas e s c he ma databas e pro g rams

<<s ubs ys tem>>
me diato r

<<s ubs ys tem>>

e ntity

<<s ubs ys tem>>

fo undatio n
resource

Introduction 16
Relational database model
 Relational table
fixed set of columns
any number or rows (records)
no duplicate rows in a table  primary key
foreign keys to link to other tables  referential integrity
NULL values allowed
atomic and non-repeating types only
Employee
emp_id CHAR(7) <pk> not null
dept_id SMALLINT <fk> null Alternate (candidate) key
family_name VARCHAR(30) <ak> not null
first_name VARCHAR(20) not null
date_of_birth DATE <ak> not null
gender Gender not null
phone_num1 VARCHAR(12) null
phone_num2 VARCHAR(12) null
salary DEC(8,2) null
Introduction 17
SQL for table definition
--==============================================================
-- Domain: "Gender"
--==============================================================
create distinct type "Gender" as CHAR(1) with comparisons;

--==============================================================
-- Table: "Employee"
--==============================================================
create table "Employee" (
"emp_id" CHAR(7) not null,
"dept_id" SMALLINT,
"family_name" VARCHAR(30) not null,
"first_name" VARCHAR(20) not null,
"date_of_birth" DATE not null,
"gender" "Gender" not null
constraint "C_gender" check ("gender" in ('F','M','f','m')),
"phone_num1" VARCHAR(12),
"phone_num2" VARCHAR(12),
"salary" DEC(8,2),
primary key ("emp_id"),
unique ("date_of_birth", "family_name")
);

Introduction 18
 Referential integrity
 Referential integrity constraints to maintain relationships
between tables
primary-to-foreign key correspondence
 Foreign key – a set of columns in one table whose values are
either NULL or are required to match the values of the primary
key in the same or another table

Department
Employee
dept_id SMALLINT <pk> not null
dept_name VARCHAR(50) not null emp_id CHAR(7) <pk> not null
address VARCHAR(120) null dept_id SMALLINT <fk> null
family_name VARCHAR(30) <ak> not null
first_name VARCHAR(20) not null
date_of_birth DATE <ak> not null
gender Gender not null
dept_id = dept_id 0..n
phone_num1 VARCHAR(12) null
Upd(R); Del(N) phone_num2 VARCHAR(12) null
salary DEC(8,2) null

Introduction 19
Declarative referential integrity constraints
 Associated with delete and update operations
 What to do with Employee rows if a Department row is
deleted or updated (i.e. when dept_id gets updated)?
Upd(R); Del(R) – restrict the update or delete operation (i.e.
do not allow the operation to go ahead if there are still Employee
rows linked to that Department).
Upd(C); Del(C) – cascade the operation (i.e. delete all linked
Employee rows).
Upd(N); Del(N) – set null (i.e. update or delete the
Department row and set dept_id of the linked Employee rows to
NULL).
Upd(D); Del(D) – set default (i.e. update or delete the
Department row and set dept_id of the linked Employee rows to
the default value).
 change parent allowed (cpa) constraint could also be
defined for a referential integrity
cpa states that records in a child (foreign) table can be re-
assigned to a different record in a parent table (e.g., employee
relocated to another department)

Introduction 20
SQL for referential integrity
alter table "Employee"
drop foreign key "RefToDepartment";

alter table "Employee"

add foreign key "RefToDepartment" ("dept_id")
references "Department" ("dept_id")
on delete set null;

 referential integrity is specified for the

delete operations only
 in Oracle, restrict is the only declarative
constraint allowed for the update
operations, so restrict is implicitly assumed
Introduction 21
 Referential integrity: many-to-many
relationship

Student CourseOffering
stud_id CHAR(8) <pk> not null crs_name VARCHAR(50) <pk> not null
name VARCHAR(50) not null semester CHAR(1) <pk> not null

crs_name = crs_name
stud_id = stud_id
semester = semester
Upd(R); Del(C)
Upd(R); Del(R)

0..n StdToCrsOff 0..n

stud_id CHAR(8) <fk1> not null
crs_name VARCHAR(50) <fk2> not null
semester CHAR(1) <fk2> not null

Introduction 22
Triggers
 DB programs, written in an extended SQL, executed automatically
(triggered) as a result of a modification operation (insert, update
or delete) on a table on which the trigger has been defined
 To procedurally enforce business rules (more complex referential
integrity constraints)
create trigger keepdpt
on Department for delete
as
if @@rowcount = 0
return /* avoid firing trigger if no rows affected */
if exists
(select * from Employee, deleted
where Employee.dept_id = deleted.dept_id)
begin
print ‘Test for RESTRICT DELETE failed. No deletion’
rollback transaction
return
end
return
go

Introduction 23
 Stored procedures
 DB programs, written
SQL query Stored procedure call in an extended SQL
that can be called
(from the client application) (from the client application) from a client program
as required
 A stored procedure
Parse is given a name, can
Locate procedure take input and output
(perhaps in procedure cache)
parameters, it is
Validate syntax compiled and stored in
and object references the database
Check authorization Triggers are a
Check authorization Server special kind of
stored procedures
Database
Optimize
Substitute parameters
Compile formal for the actual
Execute

Introduction 24
 Views
EmpNoSalary  stored and
emp_id named SQL
dept_id query
family_name
first_name
 because a result
date_of_birth of any SQL query
gender is a transient
phone_num1
phone_num2
table, a view can
Employee
be used in place
of a table in other
-- SQL operations
========================================================= 
===== can be derived
-- View: "EmpNoSalary" from one or more
-- tables and/or one
========================================================= or more other
=====
create view "EmpNoSalary" as
views
select Employee.emp_id, Employee.dept_id,
Employee.family_name, Employee.first_name,
Employee.date_of_birth, Employee.gender,
Employee.phone_num1,Employee.phone_num2
from Employee;

Introduction 25
Object-relational mapping – entity classes
 UML entity classes are transformed to
relational tables

 Attributes are defined on atomic data types

or built-in the RDBMS structured data
types (Date, Currency)

Lecture 16 26
Object-relational mapping – entity classes
Employee
EEmployee
employee_id CHAR(8)
employeeId : String
family_name VARCHAR(30)
familyName : String
first_name VARCHAR(20)
firstName : String middle_initial CHAR(1)
middleName : String

Contact
EContact contact_id SMALLINT
organization_id INTEGER
contactId : String contact_name VARCHAR(50)
contactName : String fax VARCHAR(15)
phone : Set(String) email VARCHAR(15)
fax : String
email : String contact_id = contact_id

ContactPhone
phone VARCHAR(15)
contact_id SMALLINT

Introduction 27
Object-relational mapping – associations
 Uses referential integrity constraints
 Any 1:1 or 1:M association can be directly
expressed by introducing a foreign key in one
table to match the primary key in other table
 In 1:1 association, the foreign key can be
added to either table; it may be desired to
combine both entity classes in one table
 M:M association requires association class

Lecture 16 28
Object-relational mapping – associations

ETask
description : String -theTask
createdDateTime : Date
value : float 0..n* EmpTask

1..n -theEmp
Created 1
0..n
*
EEvent
1 EEmployee
description : String
Due employeeId : String
createdDateTime : Date
familyName : String
dueDateTime : Date 0..n* 1 firstName : String
completedDateTime : Date
Com pleted middleName : String
priority : char
0..1
0..n*

Introduction 29
 Object-relational mapping – associations
Task
task_id SMALLINT <pk> not null
employee_id CHAR(8) <fk> not null
description VARCHAR(255) not null
created_dt DATE not null
task_id = task_id
value FLOAT null

Event
event_id INTEGER <pk> not null
task_id SMALLINT <fk1> not null employee_id = employee_id
created_emp_id CHAR(8) <fk2> not null
due_emp_id CHAR(8) <fk3> not null
completed_emp_id CHAR(8) <fk4> null employee_id = created_emp_id
description VARCHAR(255) not null
created_dt DATE not null
due_dt DATE null Employee
completed_dt DATE null
priority SMALLINT null employee_id CHAR(8) <pk> not null
family_name VARCHAR(30) not null
first_name VARCHAR(20) not null
employee_id = due_emp_id middle_initial CHAR(1) null
employee_id = completed_emp_id

Introduction 30
Object-relational mapping – aggregation
 UML aggregation is not supported by RDBM
 Principles for association mapping are applied
 Strong aggregation (composition) – attempt
to combine the subset and superset entity
classes in a single table:
Possible for 1:1 aggregation
For 1:M aggregation (both strong and weak forms)
– the subset class must be modelled as a separate
table (with a foreign key to the owning table)

Lecture 16 31
Object-relational mapping – aggregations
ECourse
EStudent courseCode : String
courseName : String
studentId : String creditPoints : short
studentName : String
currentFees : float
-hasStud
Takes
0..n* -takesCrsoff 0..n*
ECourseOffering
0..n* 0..n* year : short
semester : short
EAcademicRecord enrolmentQuota : int
courseCode : String
year : short 0..n*
semester : short
grade : String 0..1
EAcademicInCharge

next slide
Introduction 32
Object-relational mapping – aggregations
AcademicRecord
student_id = student_id student_id NCHAR(8) <pk,fk1> not null course_code = course_code
course_code CHAR(7) <pk,fk2> not null
year DATE <pk> not null
semester NCHAR <pk> not null
grade VARCHAR(2) not null

Student Course

student_id NCHAR(8) <pk> not null course_code CHAR(7) <pk> not null
student_name VARCHAR(50) not null course_name VARCHAR(30) not null
current_fees MONEY null credit_points SMALLINT null

student_id = student_id course_code = course_code

StdToCrsOff CourseOffering
student_id NCHAR(8) <pk,fk1> not null crsoff_id SERIAL <pk> not null
crsoff_id SERIAL <pk,fk2> not null course_code CHAR(7) <ak,fk> not null
year DATE <ak> not null
semester NCHAR <ak> not null
enrolment_quota SMALLINT null
crsoff_id = crsoff_id
academic_in_charge VARCHAR(60) null

Lecture 16 33
Object-relational mapping – generalizations
 UML generalization is not supported by RDBM
 Four strategies for mapping generalization:
map each class to a table
map the entire class hierarchy to a single
“superclass” table
map each concrete class to a table
map each disjoint concrete class to a table
 Problem: support of inheritance,
polymorphism, code reuse and other concepts

Lecture 16 34
Object-relational mapping – generalizations
Person

Employee Student

StudentEmployee

next slides
Introduction 35
Object-relational mapping – generalizations
 Mapping each class to a table (“vertical mapping”). Subclass
tables include a column for each attribute in the superclass

Person
person_id = person_id person_id <pk>
person_id = person_id

Employee Student
employee_id <pk> student_id <pk>
person_id <fk> person_id <fk>

StudentEmployee
employee_id = employee_id employee_id <pk,fk1> student_id = student_id
student_id <pk,fk2>

Introduction 36
Object-relational mapping – generalizations
 Mapping the class hierarchy to a table
 Table Person contains combined set of attributes from all classes in generalization hierarchy
 Two columns (is_employee and is_student) meant to record whether a person is an employee, a student or both

Person
person_id uniqueidentifier <pk> not null
is_employee char(1) null
is_student char(1) null

Introduction 37
Object-relational mapping – generalizations
 Mapping each concrete class to a table (“horizontal” mapping)
 Any attribute of the abstract superclass Person is “inherited” by the tables corresponding to the
concrete classes; the superclass table is not needed

Employee Student
employee_id <pk> student_id <pk>

StudentEmployee
employee_id = employee_id employee_id <pk,fk1> student_id = student_id
student_id <pk,fk2>

Introduction 38
Object-relational mapping – generalizations
 Mapping each disjoint concrete class to a table
 Assumed that it is always known whether an employee is also a student and vice versa

Employee Student
employee_id NCHAR(8) <pk> not null student_id NCHAR(10) <pk> not null
is_student BOOLEAN not null is_employee BOOLEAN not null

Introduction 39