Transcript SOFTWARE ENGINEERING OBJECT-ORIENTED MODELING WITH UML OO MODELING WITH UML

SOFTWARE ENGINEERING
OBJECT-ORIENTED MODELING WITH
UML
OO MODELING WITH UML
1
OBJECTIVES LEARNING
1. Understand what is the UML and how it can be used to model
software systems.
2. Understand the most essential features of UML class diagrams:
classes, generalizations and associations.
3. Know some more advanced features of the UML: aggregation
and constraints.
4. Appreciate that the UML is a modeling language and not a
software development methodology.
OO MODELING WITH UML
2
2
OBJECT-ORIENTED MODELING WITH UML OUTLINE

Overview of UML

Modeling and Abstraction
– OO modeling
– aggregation, classification and generalization

Objects and Classes
– state & behaviour
– attributes & operations

Generalization
– inheritance
– coverage

Links and Associations
– multiplicity
– aggregation & composition
OO MODELING WITH UML
3
2.2
WHAT IS UML?

a general purpose visual modeling language for systems

incorporates current best practice in modeling techniques and
software engineering

software development methodology neutral

industry standard OO modeling language (but can also be used
for non-OO systems)

basic premise: software systems can be modeled as
collections of collaborating objects
OO MODELING WITH UML
4
UML STRUCTURE
UML
Building
blocks

Common
mechanisms
Building blocks
– things
– relationships
– diagrams

Common mechanisms
–
–
–
–
specifications
adornments
common divisions
extensibility mechanisms

Architecture
Architecture
– use-case view
– logical view
– process view
– implementation view
– deployment view
OO MODELING WITH UML
5
2.3
OBJECT-ORIENTED MODELING

Why models?
– Models succinctly describe reality (i.e., they abstract reality).
 show essential details; filter out non-essential details
– This allows us to focus on the “big picture” of software
development,
 i.e., programming-in-the-large,
– and, thus, to better deal with the complexity of software
development,
 with human limitations in understanding complex things
– resulting in better understanding of requirements, cleaner designs,
and more maintainable systems.
OO MODELING WITH UML
8
2.3
OBJECT-ORIENTED MODELING

Why objects?
– Objects more accurately reflect the real world in a model thereby
reducing the “semantic gap” between reality and a model.
– Objects localize changes to the model!
We model reality as a number of interacting objects.
OO MODELING WITH UML
9
OOMODELING & LEVELS OF ABSTRACTION
Conceptual Level- We construct a problem domain model.
– We do not consider any aspects of implementation of objects
 Focus on identifying concept(“objects”)
in the problem domain
Design Level - We construct a solution domain model.
– We consider interfaces of objects (but no internal aspects)
 Focus on how objects interact in the solution domain
Implementation Level - We implement the solution domain model.
– We consider all details of objects (external and internal)
 Focus on how to code objects
 Modeling proceeds from the conceptual to implementation
Same OO concepts can be used at all levels to build models
OO MODELING WITH UML
10
2.3.2
ABSTRACTION
mental process of selecting some object characteristics and
properties to model and excluding others that are not relevant
Q
- wings, flies, landing gear, ...

abstraction is always for some purpose

many different abstractions of the same thing are possible

all abstractions are incomplete descriptions of reality
 We do not need completeness, just modeling adequacy!
OO MODELING WITH UML
11
2.3.2
TYPES OF ABSTRACTIONS

classification — group similar instances of objects
DBMS
software
Microsoft
software
IS_MEMBER_OF
relationship
Word
PowerPoint
IS_MEMBER_OF
relationship
. . .
Access
Oracle
. . .
Sybase
 pick out common properties and ignore unique properties
OO MODELING WITH UML
12
TYPES OF ABSTRACTIONS (cont’d)

aggregation — group dissimilar sets of objects
airplane
IS_PART_OF
relationship
wing
landing gear
. . .
fuselage
 ignore differences among the parts and concentrate
on the fact that they form the whole
OO MODELING WITH UML
13
TYPES OF ABSTRACTIONS (cont’d)

generalization — group similar sets of objects
superclass/supertype
student
IS_A
relationship
secondary
undergrad
. . .
postgrad
subclass/subtype
 note difference between classification and generalization
– classification – applied to individual instances of objects
– generalization – applied to sets of objects (classes)
OO MODELING WITH UML
14
TYPES OF ABSTRACTIONS (cont’d)
Note: we can combine different types of abstraction when modeling
student
generalization
undergrad
classification
Sam
Tina
. . .
John
aggregation
name
student id
. . .
OO MODELING WITH UML
15
2.3.4; 2.4.2
OBJECT
a concept, abstraction or thing with crisp
boundaries and meaning which plays a role
with respect to a request for an operation
Fred’s Savings
Account
(a real-life object)
balance
deposit
withdraw
 The interface describes the operations
which an object can perform
OO MODELING WITH UML
16
OBJECT — PROPERTIES
Fred’s Savings
Account
identity
accountNumber (integer value)
state
amount (money value)
Balance Method (code)
balance
Balance
Deposit Method (code)
deposit
Deposit
behaviour
Withdraw Method (code)
withdraw
Withdraw
Pay-interest Method (code)
payInterest
OO MODELING WITH UML
17
OBJECT PROVIDE INFORMATION HIDING
a kind of abstraction that enforces a (clean)
separation between the external interface
and the internal implementation of an object
user
request
response


object 1
object 2
interface
interface
request
response
An object’s interface encapsulates and abstracts an object thereby
providing information hiding.
An object has a visible ( public) interface and a hidden ( private)
implementation.
Objects help promote modular development.
OO MODELING WITH UML
19
2.3.4; 2.4.2
(OBJECT) CLASS
a description of a group of objects that have common:
– state
– behaviour

– relationships
– semantics
A class provides a template to create objects (a “factory” for
objects)
 a class is a classifier; an object is an instance

A good class should capture only one abstraction
 It should one major theme

A class should be named using the vocabulary of the problem
domain
So that it is meaningful and traceable
OO MODELING WITH UML
20
2.3.4; 2.4.2
WHY CLASSES?

conveniently describes a collection of objects  abstraction
 reduces complexity – makes systems easier to understand
 write-once – common definition defined and stored once

specifies what values are acceptable in a given context
 allows compilers (and people) to understand the programmer’s
intention and to do certain types of error checking
 Choosing appropriate classes is an
important design decision
How are classes and modules related?
– classes can be thought of as
loosely coupled, highly cohesive modules
OO MODELING WITH UML
21
2.3.4
CLASS — ATTRIBUTE
a description of data values held by objects in a class

each attribute has a:
– name (unique within a class, but not across classes)
– type (specifies the domain of values – string, integer, money, etc. –
from which an attribute can take its values)
 continuous (e.g., salary)
 discrete (e.g., sex)
– visibility: public (+), private (-), protected (#), package (~)
– initial value (optional)
– multiplicity (optional; number of simultaneous values,
e.g., telephone number; default is exactly 1)
– changeability: frozen, addOnly, no constraint (default)

base attribute versus derived attribute
– e.g., birthdate versus age
OO MODELING WITH UML
22
ATTRIBUTES — UML NOTATION
«stereotype» visibility name [multiplicity]: typeExpression = initialValue
{propertyString}
propertyString –> a comma separated list of properties or constraints
 only “name” is mandatory
Examples
+ size: area = (100,000) {frozen}
name: string
telephone[0..2]: string
telephone[1, 3..4]: string
- salary: money {>0, <1,000,000}
 You are not required to know this syntax!
OO MODELING WITH UML
23
2.3.4; 2.4.2
CLASS — OPERATION
a function or transformation that may
be applied to or by objects in a class
Company  hire, fire, pay-dividends, …
Course  register, waive-prerequisite, …

An operation invoked by a message sent to an object
– operation signature: name of operation (called selector), number
and types of the arguments, and type of the result value
– visibility: public (+), private (-), protected (#), package (~)
– side effects:if the execution of an operation changes the state
an object (query operation  no side effects)
of
OO MODELING WITH UML
24
2.4.2
CLASS — METHOD
The implementation of an operation for a class

An operation is visible; the method is hidden.
– An operation is a classifier ; a method is an instance .


polymorphic operation – an operation that can have several
different methods
class
Account
operation
payInterest
Savings
Checking
calculate interest on savings accounts
calculate interest on checking accounts
dynamic binding – choosing the method to execute for an
operation based on the object’s class
OO MODELING WITH UML
25
OPERATION — UML NOTATION
«stereotype» visibility name (parameterList): returnType {propertyString}
parameterList –> kind name: typeExpression = defaultValue
kind--> in - pass by value
out - pass by reference (no input value; output value only)
inout - pass by reference (input and output value)
propertyString –> a comma separated list of properties or constraints
isQuery = true or false
isPolymorphic = true or false
concurrency = sequential
guarded
- callers must coordinate to ensure only one call to
an object may execute at one time
- multiple calls to an object may occur
simultaneously, but only one is allowed to execute
at a time; other calls are blocked
concurrent - multiple calls may occur simultaneously to an
object and all execute concurrently
operation signature = {name (parameterList): returnType}
 You are not required to know this syntax!
OO MODELING WITH UML
26
CLASS — UML GRAPHICAL NOTATION
Class name
attribute
compartment
operation
compartment
extra
compartment
Visibility
+ public
- private
# protected
~ package
Account
-accoutNumber : int
+amount : money
-count : int = 0
+create(aNumber : int)
-incrementCount( )
+getCount( ) : int
+getNumber( ) : int
+balance( ) : money
+deposit(amount)
+withdraw(amount)
-payInterest( )
OO MODELING WITH UML
27
SCOPE

Attributes and operations normally have instance scope
(i.e., they apply to/operate on a single object instance)

Sometimes, it is useful to have attributes and operations that
have class scope (i.e., they apply to/operate on an entire class
of objects)
 attributes whose values are class determined – a counter
 object constructors – create new object instances

In UML notation, such attributes/operations are underlined
OO MODELING WITH UML
28
WHY CLASSES FOR MODELING SYSTEMS ?

By abstracting a collection of objects and representing them as
a class, the complexity of developing a system is reduced since
it becomes easier to:
– understand the system  We need to understand only the
classes, not the individual objects.
– specify the system  Classes provide a place to define and
store common definitions only once.
Choosing appropriate classes is an
IMPORTANT DESIGN DECISION
that helps promote modular development.
OO MODELING WITH UML
29
2.4.2
GENERALIZATION
a relationship between a class of kind.
discriminator: an attribute of enumeration type that indicates which property of a
class is being abstracted by a generalization
OO MODELING WITH UML
30
2.4.2
GENERALIZATION
a relationship between a class of kind.
discriminator: an attribute of enumeration type that indicates which property of a
class is being abstracted by a generalization
OO MODELING WITH UML
31
2.4.2
GENERALIZATION / SPECIALZATION
Can also be applied bottom-up
OO MODELING WITH UML
32
2.4.2
GENERALIZATION / SPECIALZATION
OO MODELING WITH UML
33
2.4.2
GENERALIZATION
a relationship between a class and one or more refined versions
generalization
Vehicle
superclass
subclass
vehicle-type
Van
Car
superclass
Truck
car-size
Compact
Midsize
subclass
discriminator
Fullsize
specialization
discriminator: an attribute of enumeration type that indicates which property of a
class is being abstracted by a generalization
OO MODELING WITH UML
34
GENERALIZATION — INHERITANCE
the assumption of properties by a
subclass from its superclasses

We extract similarities (common attributes and operations), put
them in a superclass and inherit them to subclass(es)
 􀀂 Properties and behaviour are only defined in one place:
√ reduces redundancy of descriptions
√ promotes reusability of descriptions
√ simplifies modification of descriptions.
 An object of a superclass can be substituted
with an object of the subclass.
OO MODELING WITH UML
35
GENERALIZATION — INHERITANCE (cont’d)
A subclass may
– add new properties
(attributes, operations)
– override methods
Account
accountNumber
amount
balance
deposit
withdraw
conflict resolution by:
– user-defined order
– predefined order
– redefine names
(attributes only)
Single inheritance
Savings
Checking
serviceCharge
withdraw
Multiple inheritance
interestRate
payInterest
Checking
Savings
Which withdraw method should
CheckingSavings inherit?
OO MODELING WITH UML
36
MULTIPLE INHERITANCE EXAMPLE
University
Member
id
id
id
Employee
Student
id
id
Undergrad
id
id
Postgrad
Staff
? id
id ?
Faculty
TA
OO MODELING WITH UML
37
MULTIPLE INHERITANCE EXAMPLE
Student
Employee
id
id
id
id
Undergrad
id
id
Postgrad
Staff
? id
id ?
Faculty
TA
OO MODELING WITH UML
38
MULTIPLE INHERITANCE EXAMPLE
Vehicle
LandVehicle
weight
displacement
size
Car
WaterVehicle
size
Amphibious
Vehicle
Boat
name conflict
OO MODELING WITH UML
39
GENERALIZATION — ABSTRACT CLASS
a class that has no direct instances

An abstract class used for modeling purposes as a container for
definitions, but no instances of the class are of interest
Account
Checking
Savings
Note: Operations may also be abstract  no method specified
Shown in UML by using italics
OO MODELING WITH UML
40
GENERALIZATION — COVERAGE
overlapping - a superclass object can be a member of more than one
Player subclass
Player
Tennis
Soccer
{overlapping}
Tennis
Soccer
disjoint - a superclass object is a member of at most one subclass
Female
Male
Person
Person
{disjoint}
Male
Female
OO MODELING WITH UML
41
GENERALIZATION — COVERAGE (cont’d)
Postgrad
Undergrad
complete - all superclass objects are also members of some subclass
University
University
Student
Student
{complete}
Undergrad
Postgrad
incomplete - some superclass object is not a member of any subclass
Tree
Elm
Oak
{incomplete}
Tree
Birch
Oak
Elm
Birch
OO MODELING WITH UML
42
GENERALIZATION — COVERAGE (cont’d)
Soccer
Tennis
overlapping, incomplete
Player
Player
{overlapping, incomplete}
Tennis
Soccer
overlapping, complete
Course
Course
PG
UG
{overlapping, complete}
UG
PG
OO MODELING WITH UML
43
GENERALIZATION — COVERAGE (cont’d)
Postgrad
Undergrad
disjoint, complete
University
Student
University
Student
{disjoint, complete}
Undergrad
Postgrad
disjoint, incomplete
Tree
Elm
Oak
{disjoint, incomplete}
Tree
Birch
Oak
Elm
Birch
OO MODELING WITH UML
44
QUESTION?
Payment
Cash
Credit-card
Debit-card
The coverage of the generalization shown above is:
– overlapping, complete
– disjoint, complete
– overlapping, incomplete
– disjoint, incomplete
What is the policy of the organization?
OO MODELING WITH UML
45
QUESTION?
Customer
Individual
Company
The coverage of the generalization shown above is:
– overlapping, complete
– disjoint, complete
– overlapping, incomplete
– disjoint, incomplete
What is the policy of the organization?
OO MODELING WITH UML
46
2.4.2
LINK
a physical or conceptual relationship between object instances
Person
Gan Kok Wee
Dik Lee
Works-for
Teaches
Beat Wüthrich
Fred Lochovsky
Organization
Pam Drew
HKUST
Boeing
 links allow one object to send
Course
COMP 111
COMP 337
COMP 211
COMP 332
messages to another object
OO MODELING WITH UML
47
2.4.2
ASSOCIATION
a description of a group of links with common semantics
Person
Works-for
Works-for
class
diagram Person
Organization
 Teaches
Teaches
Course
 Can show navigability of
associations
Works-for
(implies thatOrganization
the source object has a
reference to the target object)
 Can show readability of
associations
 An association is a classifier; a link is an instance
 Conceptually, associations are inherently bi-directional
OO MODELING WITH UML
48
ASSOCIATION (cont’d)

there can be several associations between the same two
classes
Person
Attended
University
Works-for
Fred

•
Attended
Works-for
• U Toronto
or even with the same class
Married-to
Person
Manages
OO MODELING WITH UML
49
ASSOCIATION — DEGREE

unary (reflexive)
relates a class to itself
Person
Manages

binary
relates two
classes

ternary
relates three
classes
Person
 Teaches
Project
Course
Language
Person

n-ary - relates any number of classes
 In practice, the vast majority of associations are binary
OO MODELING WITH UML
50
ASSOCIATION — DEGREE (cont’d)
Bank
Customer
Account
 can this be expressed as two binary associations?
suppose we know:
Bank
Customer
Customer
John has account 532 with HSBC
John has account 121 with BoC
Mary has account 993 with BoC
Is-with
Is-with
Has
Customer
Bank
Account
Has
Has
Is-with
Account
X
?
Account
X
?
Bank
√
?
OO MODELING WITH UML
51
ASSOCIATION — DEGREE (cont’d)
Person
Project
Language
 can this be expressed as two binary associations?
suppose we know:
Person
Project
Project
Mary works on the Accounting project using Cobol
Mary works on the CAD project using C
John works on the Accounting project using C
Works-on
Works-on
With
Project
Person
Language
With
Uses
Uses
Language
X
?
Language
X
?
Person
X
?
OO MODELING WITH UML
55
2.4.2; 5.3.2
ASSOCIATION — MULTIPLICITY

specifies restrictions on the number of objects in each class that
may be related to objects in another class
Instructor
1..*
Teaches
0..*
Course
For a given course, how many instructors can teach it?
 each course must be taught by one instructor but may have many
For a given instructor, how many courses can he teach?
 an instructor does not have to teach any course but may teach
more than one course in a given semester
 a real-world constraint!
OO MODELING WITH UML
60
ASSOCIATION — MULTIPLICITY (cont’d)
C1
a..b
A
c..d
min-card(C2,A)
max-card(C2,A)
C2
max-card(C1,A)
min-card(C1,A)
minimal cardinality (min-card)
min-card(C1,A): minimum number of links in which each object of
C1 can participate in A
min-card(C1,A) = 0  optional participation
min-card(C1,A) > 0  mandatory participation
maximal cardinality (max-card)
max-card(C1,A): maximum number of links in which each object of
C1 can participate in A
OO MODELING WITH UML
61
ASSOCIATION — MULTIPLICITY (cont’d)
special cardinalities:
max-card = *  an unlimited upper bound ()
min-card = 1 and max-card = 1  can use 1 by itself
min-card = 0 and max-card = *  can use * by itself
max-card(C1,A) = 1 and max-card(C2,A) = 1
 one-to-one association (1:1)
max-card(C1,A) = 1 and max-card(C2,A) = *
 one-to-many association (1:N)
max-card(C1,A) = * and max-card(C2,A) = *
 many to many association (N:M)
OO MODELING WITH UML
62
ASSOCIATION — MULTIPLICITY (cont’d)
one-to-one association (1:1)
Country
Country
China
Canada
USA
0..1
Capital-of
Capital-of
1..1
1
City
City
Beijing
Ottawa
New York
Washington
OO MODELING WITH UML
63
ASSOCIATION — MULTIPLICITY (cont’d)
one-to-many association (1:N)
Employee
Employee
John
James
Alan
Bill
*0..*
Assigned-to
Assigned-to
1..11
Department
Department
Sales
Production
Marketing
Larry
OO MODELING WITH UML
64
ASSOCIATION — MULTIPLICITY (cont’d)
many to many association (N:M)
Supplier
Supplier
E-com
Vtech
Mach
SGH
*
Supplies
Supplies
*
Part
Part
85213
28175
33472
Hi-tech
90231
Lansing
OO MODELING WITH UML
65
QUESTION?
Student
?
10..45
Enrolled-in
?
1..5

A student must enroll in at least one course and
can enroll in at most five courses

A course must have at least ten students enrolled
in it and cannot have more than forty-five students
enrolled in it.
Course
OO MODELING WITH UML
66
N-ARY ASSOCIATION — MULTIPLICITY
defined with respect to the other n-1 ends
 given a ternary association among classes (A, B, C), the multiplicity of
the C end states how many C objects may appear in association with
a particular pair of (A, B) objects
Registration
Course
*
0..1
Professor
*
Student




 0 or
1 professor
for
each (course,
student)
a student
will not take
the same course
from
more than one
professor,
but a student
may take more
thancourses
one course from
for each (student,
professor)
 many
one professor and a professor may teach more than one course
for each (course, professor)
 many students
OO MODELING WITH UML
67
QUESTION?
Meets
Course
*
0..3
Day
0..1
Classroom

for each (course, classroom)
 0, 1, 2 or 3 days

for each (course, day)
 0 or 1 classrooms

for each (classroom, day)
 many courses
OO MODELING WITH UML
68
QUESTION?
What is the most likely multiplicity of the following associations?
ServiceOrder
ServiceAgent
ServiceOrder
Product
Has
Takes
WaitsFor
ComposedOf
ServiceCall
ServiceOrder
Part
Part
OO MODELING WITH UML
69
EXAMPLE: CAR LOANS
The classes shown have some attributes that are internal object
identifiers(OIDs) that should not appear at the conceptual modeling level
and should either be deleted or be replaced with relationships. All such
attributes conveniently have names ending in ID.
Some further information about the application follows. A person may
work for any number of companies. Persons, companies, or banks may
own cars. The car owner ID represents either the person, company, or
bank who owns the car. A car may have only one owner (person, company,
or bank). A car loan given by a bank is for the purchase of a car. A car may
have multiple car loans.
Prepare a class diagram in which the pointers are replaced with
relationships. Use associations and generalizations as necessary. Show
the most likely multiplicities for all associations and the final attributes for
each class.
Note: Your final class diagram should contain no IDs.
OO MODELING WITH UML
70
EXAMPLE
Person
Car
name
age
employer 1 ID
employer 2 ID
employer 3 ID
person ID
address
Car loan
owner ID
vehicle ID
owner type
model
year
Company
name
company ID
vehicle ID
customer type
customer ID
account number
bank ID
interest rate
current balance
Bank
name
bank ID
OO MODELING WITH UML
71
OO MODELING WITH UML
72
2.4.2
AGGREGATION/COMPOSITION ASSOCIATION

a special type of association in which there is a “part-of”
relationship between one class and another class
Computer
Has
Disk
 a component may exist independent of the aggregate object of
which it is a part  aggregation
Course
Has
Course-offering
 a component may not exist independent of the aggregate
object of which it is a part  composition
OO MODELING WITH UML
73
AGGREGATION/COMPOSITION (cont’d)

sometimes it is not clear whether the parts should be related
with
or
Chassis
Transmission
Car
Doors
Engine
Frame
 Which aggregation association to use is a matter of how
one interprets reality and/or the requirements of the
application
OO MODELING WITH UML
74
WHEN TO USE AGGREGATION/COMPOSITION?

Would you use the phrase “part of” to describe the association
or name it “Has”? (But be CAREFUL! Not all “Has” associations
are aggregations.)

Are operations on the whole automatically applied to the part(s)
 composition?

Are some attribute values propagated from the whole to all or
some of the parts?

Is there an intrinsic asymmetry to the association where one
object class is subordinate to the other(s)?
 It is not wrong to use association rather than aggregation!
(When in doubt, use association!)
OO MODELING WITH UML
75
2.4.2
ASSOCIATION — ROLE NAMES
role: one end of an association
Person
 Works-for
employee
employer
Company
 for binary associations there are two roles
OO MODELING WITH UML
76
ASSOCIATION — ROLE NAMES (cont’d)
role: one end of an association
Person
Boss
Manages
Worker
John
Sarah
Boss
Worker
Frank
Bill
Boss
 It is necessary to use role names when an association
relates objects from the same class
OO MODELING WITH UML
77
2.4.2
ASSOCIATION — ASSOCIATION CLASS
Student
 Enrolled-in
Course
What about an attribute like grade?
Course
Student
A+
Marco
C
A
Connie
B+
A-
COMP 332
COMP 201
COMP 303
Jason
B
Joe
OO MODELING WITH UML
78
ASSOCIATION — ASSOCIATION CLASS (cont’d)
Possibility 1: use many attributes for grade
(a) in Student
Student
 Enrolled-in
Course
student#
name .
..
grade1
grade2.
..
?
(b) in Course
Student
 Enrolled-in
Course
course-code
name .
..
grade1
grade2.
..
?
OO MODELING WITH UML
79
ASSOCIATION — ASSOCIATION CLASS (cont’d)
Possibility 2: use a multi-valued attribute for grade
(a) in Student
Student
 Enrolled-in
Course
student#
name .
..
grade .[1..*]
..
(b) in Course
Student
 Enrolled-in
Course
course-code
name .
..
grade .[1..*]
..
OO MODELING WITH UML
80
ASSOCIATION — ASSOCIATION CLASS (cont’d)
Possibility 3: use an association class
Student
Course
Enrolled-in
grade
Course
Student
COMP 332
A+
B+
Marco
A-
C
Connie
COMP 201
COMP 303
A
Jason
B
Joe
OO MODELING WITH UML
81
ASSOCIATION — ASSOCIATION CLASS (cont’d)
When to associate an attribute with an association?
salary
Person
name
hkid
address
?
Works-for
Company
name
address
 Usually needed only for many to many relationships!
OO MODELING WITH UML
82
ASSOCIATION — CONSTRAINTS
ordering
Country
1
Has
*
Member-of
{ordered} *
President
subset
Person
1
{subset}
*
*
Committee
Chair-of
general
C1
a..b
A
{Boolean expression}
c..d
C2
OO MODELING WITH UML
83
UML RELATIONSHIPS
association
describes links among object instances
(only relationship that relates object instances)
generalization relates a more general class (superclass) to a
more specific kind of the general class (subclass)
dependency
relates classes whose behaviour or implementation
affect other classes
flow
relates two versions of an object at successive times
usage
shows that one class requires another class for its
correct functioning
realization
relates a specification to its implementation
(e.g., an interface to the classes that implement it)
OO MODELING WITH UML
84
STEREOTYPE
a new class of modeling element, which is a
subclass of an existing modeling element
 allows the object model to be dynamically extended
Example: we can define different kinds of classes that are useful
for modeling
«control»
«boundary»
«entity»
PenTracker
OrderForm
BankAccount
PenTracker
OrderForm
BankAccount
 special icons can be used for each stereotype
OO MODELING WITH UML
85
CLASS DIAGRAM EXAMPLE
1..*
Order
Item
description
picture
cost
date
delivery address
1..*
Payable
1
Invoice
amount
date
due date
*
Has buy invoice
1
buyer
*
Has sell invoice
Account
balance
seller owner
1
{incomplete}
VIP
expiry date
OO MODELING WITH UML
86
CLASS DIAGRAM EXAMPLE
Successor
Client
EventHandler
- currentEventId: integer
- source: string
handleRequest(): void
GUIEventHandler
OO MODELING WITH UML
87
EXAMPLE
Construct a class diagram for the classes listed below. Use
association, aggregation and generalization relationships as
necessary. Show multiplicity for all relationships and role names
where necessary.
file system
drive
file
directory
sector
ASCII file
disk
executable file
track
OO MODELING WITH UML
88
SUMMARY — OBJECT-ORIENTED MODELING

UML — Object Model
Class name
attribute
compartment
operation
compartment
classifier
instance
class
attribute
operation
association
object
value
method
link
Student
{complete, disjoint}
Undergrad
Student
Course
10..45
Grad
Enrolled-in
1..5
Course
Course-offering
OO MODELING WITH UML
89