OBJECTORIENTED MODELING WITH UML

1
SOFTWARE ENGINEERING

• OBJECT-ORIENTED MODELING WITH UML

2
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.

3
OBJECT-ORIENTED MODELING WITH UML OUTLINE
2

• 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

4
WHAT IS UML?
2.2

• 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

5
UML STRUCTURE

• Building blocks
• things
• relationships
• diagrams
• Common mechanisms
• specifications
• adornments
• common divisions
• extensibility mechanisms

• Architecture
• use-case view
• logical view
• process view
• implementation view
• deployment view

6
UML STRUCTURE (contd)

• Building blocks - basic UML modeling elements
• things the modeling elements classes,
  interfaces, use case, interactions, packages,
  notes (can be structural, behavioural, grouping
  or annotational)
• relationships specify how two or more things are
  semantically related
• diagrams views into UML models show collections
  of things that visualize what the system will do
  or how it will do it
• Common mechanisms - common ways of achieving
  specific goals
• specifications textual descriptions of the
  semantics of a modeling element
• adornments additional, visual details about
  modeling elements
• common divisions particular ways of thinking
  about the world (e.g., classifier-instance
  interface-implementation)
• extensibility mechanisms ways to customize the
  modeling elements for specific needs

7
UML STRUCTURE (contd)

• Architecture - the strategic aspects of the
  high-level structure of the system that is
  captured in UML by
• use-case view captures the basic requirements
  for the system and provides the basis for the
  construction of the other views
• logical view captures the vocabulary of the
  problem domain as a set of classes and objects
• process view models the executable threads and
  processes in the system
• implementation view models the files and
  components that make up the physical code base of
  the system
• deployment view models the physical deployment
  of components onto computational nodes such as
  computers and peripherals

8
OBJECT-ORIENTED MODELING
2.3

• 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.

9
OBJECT-ORIENTED MODELING
2.3

• 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.
10
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
11
ABSTRACTION
2.3.2

• mental process of selecting some object
  characteristics and properties to model and
  excluding others that are not relevant

Q
- wings,
landing gear, ...
flies,

• 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!

12
TYPES OF ABSTRACTIONS
2.3.2

• classification group similar instances of
  objects

DBMS software
Microsoft software
IS_MEMBER_OF relationship
IS_MEMBER_OF relationship
Sybase
. . .
Access
Oracle
Word
PowerPoint
. . .

• pick out common properties and ignore unique
  properties

13
TYPES OF ABSTRACTIONS (contd)

• aggregation group dissimilar sets of objects

airplane
IS_PART_OF relationship
fuselage
. . .
wing
landing gear

• ignore differences among the parts and
  concentrateon the fact that they form the whole

14
TYPES OF ABSTRACTIONS (contd)

• generalization group similar sets of objects

superclass/supertype
student
IS_A relationship
postgrad
. . .
secondary
undergrad
subclass/subtype

• note difference between classification and
  generalization
• classification applied to individual instances
  of objects
• generalization applied to sets of objects
  (classes)

15
TYPES OF ABSTRACTIONS (contd)

• Note we can combine different types of
  abstraction when modeling

student
generalization
undergrad
classification
John
. . .
Sam
Tina
aggregation
. . .
name
student id
16
OBJECT
2.3.4 2.4.2
a concept, abstraction or thing with crisp
boundaries and meaning which plays a role with
respect to a request for an operation

• The interface describes the operationswhich an
  object can perform

17
OBJECT PROPERTIES
Freds Savings Account
identity
18
OBJECT PROPERTIES

• identity Objects have unique existence in time
  and space
• often referenced by a unique identifier, but this
  is not the same as the object
• represented by an object id (OID) for
  implementation purposes
• state The static properties of objects that are
  persistent (attributes)
• fixed number of attributes
• either mutable (can be changed) or immutable
  (cannot be changed)
• behaviour The dynamic properties of objects that
  describe how objects communicate with each
  other (operations)
• fixed number of operations
• operations invoked by messages received from
  other objects
• message handling may be state dependent
• operations may change an objects state
  (attribute values)
• in many models
• only state or behaviour is emphasized, or
• they are treated separately
• in object-oriented models they are considered
  together since objects contain both aspects

19
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
request
response
response

• An objects 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.
20
(OBJECT) CLASS
2.3.4 2.4.2

• a description of a group of objects that have
  common
• state relationships
• behaviour 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

21
WHY CLASSES?
2.3.4 2.4.2

• 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
  programmers intention and to do certain types of
  error checking
• Choosing appropriate classes is animportant
  design decision
• How are classes and modules related?
• classes can be thought of asloosely coupled,
  highly cohesive modules

22
CLASS ATTRIBUTE
2.3.4
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

23
ATTRIBUTES UML NOTATION

• stereotype visibility name multiplicity
  typeExpression initialValue propertyString
• propertyString gt a comma separated list of
  properties or constraints
• only name is mandatory
• Examples
• size area (100,000) frozen
• name string
• telephone0..2 string
• telephone1, 3..4 string
• - salary money gt0, lt1,000,000
• You are not required to know this syntax!

24
CLASS OPERATION
2.3.4 2.4.2
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 effectsif the execution of an operation
  changes the state of an object (query operation
  no side effects)

25
CLASS METHOD
2.4.2
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 operation
• Account payInterest
• Savings calculate interest on savings accounts
• Checking calculate interest on checking accounts

• dynamic binding choosing the method to execute
  for an operation based on the objects class

26
OPERATION UML NOTATION

• stereotype visibility name (parameterList)
  returnType propertyString
• parameterList gt kind name typeExpression
  defaultValue
• kind--gt in - pass by value
• out - pass by reference (no input value output
  value only)
• inout - pass by reference (input and output
  value)
• propertyString gt a comma separated list of
  properties or constraints
• isQuery true or false
• isPolymorphic true or false
• concurrency sequential - callers must
  coordinate to ensure only one call to an
  object may execute at one time
• guarded - 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!

27
CLASS UML GRAPHICAL NOTATION
Visibility public - private protected
package
28
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

29
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.
30
GENERALIZATION
2.4.2

• 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
31
GENERALIZATION
2.4.2

• 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
32
GENERALIZATION / SPECIALZATION
2.4.2
Can also be applied bottom-up
33
GENERALIZATION / SPECIALZATION
2.4.2
34
GENERALIZATION
2.4.2

• a relationship between a class and one or more
  refined versions

generalization
Vehicle
vehicle-type
Van
Car
Truck
discriminator
car-size
Compact
Midsize
Fullsize
specialization
discriminator an attribute of enumeration type
that indicates which property of a class is
being abstracted by a generalization
35
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.

36
GENERALIZATION INHERITANCE (contd)

• conflict resolution by
• user-defined order
• predefined order
• redefine names(attributes only)

• A subclass may
• add new properties (attributes, operations)

• override methods

Single inheritance
Multiple inheritance
Which withdraw method should CheckingSavings
inherit?
37
MULTIPLE INHERITANCE EXAMPLE
id
id
id
id
id
id
? id
id ?
38
MULTIPLE INHERITANCE EXAMPLE
id
id
id
id
? id
id ?
39
MULTIPLE INHERITANCE EXAMPLE
weight
displacement
name conflict
40
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

Note Operations may also be abstract ? no
method specified Shown in UML by using italics
41
GENERALIZATION COVERAGE
overlapping - a superclass object can be a member
of more than one subclass
disjoint - a superclass object is a member of at
most one subclass
42
GENERALIZATION COVERAGE (contd)
complete - all superclass objects are also
members of some subclass
incomplete - some superclass object is not a
member of any subclass
43
GENERALIZATION COVERAGE (contd)
overlapping, incomplete
overlapping, complete
44
GENERALIZATION COVERAGE (contd)
disjoint, complete
disjoint, incomplete
45
QUESTION?
What is the policy of the organization?
46
QUESTION?
What is the policy of the organization?
47
LINK
2.4.2
a physical or conceptual relationship between
object instances
Teaches
Works-for

• links allow one object to send messages to
  another object

48
ASSOCIATION
2.4.2

• a description of a group of links with common
  semantics

Teaches
u Teaches
Person
Course

• Can show navigability ofassociations(implies
  that the source object has a reference to the
  target object)

class diagram
Works-for

• Works-for

• Can show readability ofassociations

• An association is a classifier a link is an
  instance

• Conceptually, associations are inherently
  bi-directional

49
ASSOCIATION (contd)

• there can be several associations between the
  same two classes

Attended
Person
University
Works-for
Attended
Works-for

• or even with the same class

Person
Manages
Married-to
50
ASSOCIATION DEGREE

• unary (reflexive)
• relates a class to itself

• n-ary - relates any number of classes

• In practice, the vast majority of associations
  are binary

51
ASSOCIATION DEGREE (contd)

• can this be expressed as two binary
  associations?
• suppose we know John has account 532 with HSBC
• John has account 121 with BoC
• Mary has account 993 with BoC

X
?
X
?
v
?
52
ASSOCIATION DEGREE (contd)
532
121
993

• Cannot tell which of Johns accounts is with
  which bank

53
ASSOCIATION DEGREE (contd)
John
121
532
Mary
993

• Cannot tell which BoC account belongs to which
  customer

54
ASSOCIATION DEGREE (contd)
532
121
993
John
Mary

• O.K. Why?

55
ASSOCIATION DEGREE (contd)

• can this be expressed as two binary
  associations?
• suppose we know Mary works on the Accounting
  project using Cobol
• Mary works on the CAD project using C
• John works on the Accounting project using C

X
?
X
?
X
?
56
ASSOCIATION DEGREE (contd)

• Cannot tell that John uses only C on Accounting

57
ASSOCIATION DEGREE (contd)

• Cannot tell which language Mary uses on which
  project

58
ASSOCIATION DEGREE (contd)

• Cannot tell that John works only on Accounting

59
ASSOCIATION DEGREE (contd)
60
ASSOCIATION MULTIPLICITY
2.4.2 5.3.2

• specifies restrictions on the number of objects
  in each class that may be related to objects in
  another class

0..
1..
Instructor
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!

61
ASSOCIATION MULTIPLICITY (contd)
A
c..d
a..b
C1
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-ca
rd(C1,A) gt 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

62
ASSOCIATION MULTIPLICITY (contd)

• 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 (11)
• max-card(C1,A) 1 and max-card(C2,A)
• one-to-many association (1N)
• max-card(C1,A) and max-card(C2,A)
• many to many association (NM)

63
ASSOCIATION MULTIPLICITY (contd)

• one-to-one association (11)

0..1
1..1
1
Capital-of
64
ASSOCIATION MULTIPLICITY (contd)
one-to-many association (1N)
1

1..1
0..
Assigned-to
65
ASSOCIATION MULTIPLICITY (contd)
many to many association (NM)


Supplies
66
QUESTION?
?
?
10..45
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.

67
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

0..1

? 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
  than one course from one professor and a
  professor may teach more than one course

• for each (student, professor)

? many courses

• for each (course, professor)

? many students
68
QUESTION?

0..3
0..1
? 0, 1, 2 or 3 days
? 0 or 1 classrooms
? many courses
69
QUESTION?
What is the most likely multiplicity of the
following associations?
70
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.

71
EXAMPLE
72
(No Transcript)
73
AGGREGATION/COMPOSITION ASSOCIATION
2.4.2

• a special type of association in which there is a
  part-of relationship between one class and
  another class

Has
Disk
Computer

• a component may exist independent of the
  aggregate object of which it is a part ?
  aggregation

Has
Course-offering
Course

• a component may not exist independent of the
  aggregate object of which it is a part ?
  composition

74
AGGREGATION/COMPOSITION (contd)

• sometimes it is not clear whether the parts
  should be related with           or

Car

• Which aggregation association to use is a matter
  of how one interprets reality and/or the
  requirements of the application

75
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!)

76
ASSOCIATION ROLE NAMES
2.4.2

• role one end of an association

employee
employer

• for binary associations there are two roles

77
ASSOCIATION ROLE NAMES (contd)
role one end of an association
Boss
Person
Manages
Worker
Boss
Worker
Boss

• It is necessary to use role names when an
  associationrelates objects from the same class

78
ASSOCIATION ASSOCIATION CLASS
2.4.2
What about an attribute like grade?
A
B
A-
C
A
B
79
ASSOCIATION ASSOCIATION CLASS (contd)

• Possibility 1 use many attributes for grade

(a) in Student
(b) in Course
80
ASSOCIATION ASSOCIATION CLASS (contd)

• Possibility 2 use a multi-valued attribute for
  grade

(a) in Student
(b) in Course
81
ASSOCIATION ASSOCIATION CLASS (contd)

• Possibility 3 use an association class

82
ASSOCIATION ASSOCIATION CLASS (contd)

• When to associate an attribute with an
  association?

?
salary

• Usually needed only for many to many
  relationships!

83
ASSOCIATION CONSTRAINTS

• ordering

subset
general
84
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)

85
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

boundary OrderForm
entity BankAccount
control PenTracker

• special icons can be used for each stereotype

86
CLASS DIAGRAM EXAMPLE
87
CLASS DIAGRAM EXAMPLE
88
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

89
SUMMARY OBJECT-ORIENTED MODELING

• UML Object Model

classifier instance class object attribute
value operation method association link