STATIC UML DIAGRAMS IN OOAD,UNIT 2 OOAD PPT

1. STATIC UML DIAGRAMS
9/29/2020
K.LEELARANI AP/CSE,
KAMARAJ COLLEGE OF
ENGINEERING AND TECHNOLOGY

2. Class Diagram
 A class diagram in the Unified Modelling Language
(UML) is a type of static structure diagram that
describes the structure of a system by showing the
system's classes, their attributes, operations (or
methods), and the relationships among objects.
2

3. UML Representation of Class
Class Name
Attributes of Class
Operations/methods
of Class
3

4. EXAMPLE:
4

5. visibility
 Relates to the level of information hiding to be
enforced
Types of visibility:
1.Public(+)
2.Protected(#)
3.Private(-)
4.Package(~)
5

6. Class Relationships
 A class may be involved in one or more relationships with
other classes.
1.Inheritance (or Generalization)
2.Association
3.Aggregation
4.Composition
5. Dependency
6

7. Inheritance (or Generalization)
 Represents an "is-a"
relationship.
 An abstract class name or
superclass
 SubClass1 and SubClass2 are
specializations of Super Class.
 A solid line with a hollow
arrowhead that point from the
child to the parent class
7

8. Inheritance-example
8

9. Simple Association
 A structural link between
two peer classes.
 There is an association
between Class1 and Class2
 A solid line connecting two
classes
9

10. Association-Example
10

11. Aggregation
Class2 is part of Class1.
Many instances (denoted by the
*) of Class2 can be associated
with Class1.
Objects of Class1 and Class2
have separate lifetimes.
A solid line with a unfilled
diamond at the association end
connected to the class of
aggregation
11

12. Aggregation-Example
12

13. Composition
 A special type of aggregation where
parts are destroyed when the whole is
destroyed.
 Objects of Class2 live and die with
Class1.
 Class2 cannot stand by itself.
 A solid line with a filled diamond at
the association connected to the class
of composite
13

14. Composition-Example
14

15. Dependency
 Exists between two classes if changes to the definition
of one may cause changes to the other (but not the
other way around).
 Class1 depends on Class2
 A dashed line with an open arrow
15

16. Dependency-Example
16

17. Relationship Names
 Names of relationships are written in the middle of the
association line.
17

18. Multiplicity
 How many objects of each class take part in the
relationships and multiplicity can be expressed as:
 Exactly one - 1
 Zero or one - 0..1
 Many - 0..* or *
 One or more - 1..*
 Exact Number - e.g. 3..4 or 6
 Or a complex relationship - e.g. 0..1, 3..4, 6.* would
mean any number of objects other than 2 or 5
18

19. Multiplicity Example
19

20. Example of a Class Diagram
Video Rental System
methods
class name
Video
+rentMovie()
Customer
-CID: int
-name: String
+authenticateCustomer ()
relationship
rents
1..*1..*
multiplicityvisibility
attributes
-cassetteID : int
-cassetteVolumeNo: int
20

21. Aggregation Example- Computer
and parts
21

22. Inheritance Example- Cell
Taxonomy
22

23. Class Diagram
23

24. Example of UML Class Diagram
 ATMs system is very simple as customers need
to press some buttons to receive cash.
However, there are multiple security layers
that any ATM system needs to pass. This helps
to prevent fraud and provide cash or need
details to banking customers.
24

25. 25

26. Elaboration
 The primary purpose of this phase is to complete the
most essential parts of the project that are high risk
and plan the construction phase.
26

27. Steps to take during this phase:
 1.Complete project plan with construction iterations
planned with requirements for each iteration.
 2. 80% of use cases are completed.
 3. The project domain model is defined.
 4. Rank use cases by priority and risk.
• 5. Begin design and development of the riskiest and
highest priority use cases.
• 6. Plan the iterations for the construction phase.
27

28. Requirements to be completed for
this phase include
 Description of the software architecture.
 A prototype that overcomes the greatest project
technical risk and has minimal high priority
functionality.
 Complete project plan.
 Development plan
28

29. Domain model is called as a
"Visual Dictionary"
29

31. 31
Domain Models
 It illustrates noteworthy concepts in a domain.
 The model influence operation contracts, glossary
and the design in the domain layer of the design
model.
 Applying the UML class diagram notation for a
domain model yields a conceptual perspective.

32. 32
 "A domain model is a representation of real-world conceptual
classes, not of software components.“
 Domain modeling is a technique used to understand the project
problem description and to translate the requirements of that
project into software components of a solution.
 The software components are commonly implemented in an
object oriented programming language.
 A domain model contains conceptual classes, associations
between conceptual classes, and attributes of a conceptual class.
 "Informally, a conceptual class is an idea, thing, or object".

33. Grade Report model is shown as a class
diagram.
33

34. Partial Domain Model for a visual dictionary using UML
Class Diagram
34

35. What is a Domain Model
 A domain model is a visual representation of
conceptual classes or real situation objects in a
domain.
 Domain models are also called as conceptual
models, domain object models and analysis
object models.
35

36.  Applying UML notation, a domain model is illustrated
with a set of class diagrams in which no
operations(method signatures) are defined.
 It provides a conceptual perspective.
 Domain objects or conceptual classes
 Associations between conceptual classes
 Attributes of conceptual classes
36

37. Domain model is a visual
Dictionary
 Domain model visualizes and relates words or
concepts in the domain.
 It shows an abstraction of the conceptual classes and
communicate with other classes.
 The information is expressed in plain text (glossary).
37

38.  It is easy to understand the terms and especially their
relationships in a visual language.
 Therefore, the domain model is a visual dictionary of
the noteworthy abstractions, domain vocabulary and
information content of the domain.
38

39. Domain model is a picture of
software business objects
 It is a visualization of things in a real situation domain
of interest.
 It is not of software objects such as Java or C# classes or
software objects with responsibilities.
39

40. Two traditional meanings of
Domain Model
 Domain model is a conceptual perspective of objects
in a real situation of the world.
 It is a domain layer of software objects.
 The layer of software objects below the presentation or
UI layer that is composed of domain objects.
40

41.  Software objects that represent things in the problem
domain space with related business logic or domain
logic methods.
 Domain layer is to indicate the second software
oriented meaning of domain model.
41

42. Conceptual classes
 The domain model illustrates conceptual classes or
vocabulary in the domain.
 It is an idea, thing or object.
 It is considered in terms of its symbol, intension and
extension.
42

43.  Symbol- words or images representing a conceptual
class.
 Intension- The definition of a conceptual class.
 Extension- The set to which the conceptual class
applies.
43

44. Example for event of a purchase
transaction
 Symbol-sale
 Intension- The event of a purchase transaction and has
a date and time.
 Extension- The set of all sale instances.
44

45. 45

46. 46
A Domain Model is not a
Software Artifact
Sale
Date
Time
Sales Database
Sale
Date
Time
Print()
A Conceptual class: Software Artifacts:
vs.

47. Domain models are the initial artifacts created in Object-Oriented-
Analysis.
An object has:
 identity,
 state, and
 behaviour.
An object can be
 related to other objects and
 complex (with sub-objects).
A class is a description of a set of objects that share the same attributes,
operations/responsibilities, relationships and semantics.
Identifying objects in the problem domain is used to identify conceptual classes
in the problem domain. Conceptual classes model entities in the problem
domain, not in the software domain.

47

48.  Making a domain model
 Identify conceptual classes
 Draw the class diagram
 Add any associations between classes
 Add attributes (properties) to the classes
Larman suggest that domain modeling should be similar to
map making.
 use existing names (do not invent your own)
 exclude irrelevant features (that is the basis of modeling)
 do not add things that are not there.
48

49. Domain Modeling Practice
 Use Case Name: create marking scheme
 Actor: Instructor
 Precondition: None
 Flow of events: Basic Path
 The instructor has selected create marking scheme.
 The system prompts the instructor to enter the course name and the semester that
the course will be offered.
 The instructor enters the information.
 The system then prompts the instructor to add a work item name, its maximum
score, and its weight.
 The instructor provides the information.
 The system prompts the instructor to continue adding work items.
 If the instructor agrees, step 4 is started again.
 The instructor is then prompted for the late submission policy.
 The instructor enters the policy.
 The system saves the marking scheme and the use case ends.
49

50. Post condition: A marking scheme has been created for a course
in the specified semester
 A list of possible nouns or none phrases are:
scheme, marking scheme, course, name, instructor, semester,
work item, value, weight, policy, submission policy, system
 Which nouns are conceptual classes, which are attributes to the classes?
We can try using a conceptual class category list.
 Some of the category list items are: physical objects, transactions, things in
a container, rules and policies, and records.
50

51. Domain model for create marking scheme
51

52. Domain model and data model
 A domain model is not a data model.
 The conceptual class has no attributes.
 It is valid to have attributeless conceptual classes .
52

53. How to create a Domain Model
 Find the conceptual classes.
 Draw them as classes in a UML class diagram.
 Add associations and attributes.
53

55. 55
Association
It is used to satisfy the information requirements.
An association is a relationship between classes that
indicate some meaningful and interesting connection.
In the UML, associations are defined as “ the semantic
relationship between two or more classifiers that
involve connections among their instances.

56. 56
Associations
association
Register Sale
Records-current
1 1
Fig 1.Associations

57. 57
When to show an Association?
 Associations for which knowledge of the relationship
needs to be preserved for some duration such as
milliseconds or years.
 Associations derived from the Common Associations
List.
 Need some memory of a relationship?

58. 58
Applying UML: Association
Notation
 An association is represented as a line between
classes with a capitalized association name.
 The ends of an association may contain
multiplicity that indicates the numerical
relationship between instances of the classes.
 Associations are inherently bidirectional.
 Optional reading direction arrow indicates the
direction to read the association name.

59. 59
UML Notation for Association
- “reading direction arrow”
- it has no meaning except to
indicate direction of reading the
association label
- often excluded
Register Sale
Records-current
1 1
multiplicityassociation name

60. 60
Guidelines: How to name an
Association in UML
Name an association based on a class name-verb phrase-
class name format.
 Legal formats are:
 Paid-by
 PaidBy
 Verb phrase creates a sequence that is readable and
meaningful.
Association name should start with a capital letter.
Classifier helps to link instances.

61. 61
Applying UML: Roles
 Each end of an association is called a role.
 Roles may have
 multiplicity expression
 name
 navigability

62. 62
Multiplicity
 Multiplicity defines how many instances of a class A
can be associated with one instance of class B.
 Eg:A single instance of a store can be associated with
many (zero or more) indicated by * item instances.

63. 63
Multiplicity
multiplicity of the
role
Store Item
Stocks
1 *
Fig 3 Multiplicity on an association.

64. 64
Multiplicity
Fig 4. Multiplicity values.
T
*
zero or more;
“many”
T
1..*
one or more;
T
1..40
one to 40
T
5
exactly 5
T
3,5,8
exactly 3,5 or 8

65. 65
Applying UML: Multiple Associations between two
classes
 Two classes may have multiple associations between
them.

66. 66
Multiple Associations
1
1
*
*
Flies-from
Flight Airport
Flies-to
Fig 6. Multiple associations.

67. 67
How to Find Associations with
a Common Associations List
The common categories that are worth considering are:

68. 68

69. 69

70. 70
NextGen POS partial
domain model
Initiated-by
Paid-by
Captured-on
Records-sales-on
Logs-
completed
1
1
1
11
1 1
1
1
*
1
Describes
1..*
1
Records-sale-of
Described-by
*
1
1..* 1
11
1
Stocks
*1
Contains
1..*1
Product
Catalog
Product
Specfication
Store ItemSales
LineItem
Register ManagerSale
Cashier
CustomerPayment
Used-by
*
Started-by
Houses
1..*
Contained-in
0..1 *
Initiated-by

71. Monopoly partial Domain model
71

73. Generalization and Specialization
 Conceptual class hierarchies are the basis for software
class hierarchies that exploit inheritance
 Association classes capture information about the
association
 Time intervals capture the idea that some objects are
valid for a limited time
73

74. Generalization
 CashPayment, CreditPayment, and CheckPayment are
similar
 Identify commonality among concepts and define a
superclass
 Separate and shared arrow notations in UML
74

75. When to make generalization hierarchies?
Cash
Payment
Credit
Payment
Check
Payment
Payment
superclass - more general
concept
subclass - more
specialized concept
these are conceptual
classes, not software
classes

76. Conceptual Super classes and
Subclasses
Conceptual super class is more general than subclass
 All members of subclass must be members of the
super class
 100% of super class definition shall apply to the
subclass
Subclass “is-a” super class
 Woman “is-a” human
 Man “is-a” human
 Anything else that is a human?
 All humans have a heart and a brain
76

77. When to Define a Subclass?
 The subclass has additional attributes
 The subclass has additional associations
 The subclass is operated on differently from the
superclass or other subclasses
 The subclass represents an animated thing that
behaves differently from the superclass
77

78. What about this hierarchy?
Male
Customer
Female
Customer
Customer Correct subclasses.
But useful?
Fig. 31.6
Guidelines for creating conceptual subclasses:
• Subclass has additional attributes or associations of interest
• Subclass behaves or is operated on, or handled or
manipulated differently than superclass or other subclasses

79. When to Define a Superclass?
 Possible subclasses represent variations of a similar
concept
 Subclasses will conform to the 100% and is-a rules
 All subclasses have the same attribute that can be
factored out and put in the superclass
 All subclasses have the same association that can be
related to the superclass
79

80. Abstract Conceptual Classes
 If every member of a class C must also be a member of
a subclass, then C is called an abstract class
 That is, if C is never used by itself, but only derived
classes are used, C is abstract
 UML uses italics for abstract classes
80
Cash
Payment
Credit
Payment
Check
Payment
Payment
amount : Money
abstract class
indicated by italics

81. Association, Aggregation and
Composition
 Association is a simple structural connection or
channel between classes and is a relationship where all
objects have their own lifecycle and there is no owner.
81

82. Association
82

83. Aggregation
 Aggregation is a specialize form of Association where all
object have their own lifecycle but there is a ownership like
parent and child.
 Child object can not belong to another parent object at the
same time. ( "has-a" relationship).
Implementation details:
1. Typically we use pointer variables that point to an object
that lives outside the scope of the aggregate class
2. Can use reference values that point to an object that
lives outside the scope of the aggregate class
3. Not responsible for creating/destroying subclasses
83

84. Aggregation
84

85. Composition
 Composition is again specialize form of Aggregation. It
is a strong type of Aggregation. Here the Parent and
Child objects have coincident lifetimes.
 Child object does not have it's own lifecycle and if
parent object gets deleted, then all of it's child objects
will also be deleted.
Implementation details:
1. Typically we use normal member variables
2. Can use pointer values if the composition class
automatically handles allocation/de-allocation
3. Responsible for creation/destruction of subclasses
85

86. Composition
86

87. Packages
 When the domain model gets too large, factor it into
packages of strongly related concepts
 A UML package is shown as a tabbed folder, with
subordinate packages in it. For example, a domain
may have a Sales and Core elements package.
87
Store RegisterHas
1..*
package: Core Elements
1

88. Packages: Dependency
 If a model’s elements are dependent upon another,
show the dependency with an arrowed line. For
example, Sales is dependent upon Core Elements.
88

89. Import package
 <<import>> - one package imports the functionality
of other package
89

90. Access Package
90
 <<access>> - one package requires help from
functions of other package.

91. Packages can be represented by
the notations
91

92. 92
Some major elements of the package diagram are shown on the drawing below.
Web Shopping, Mobile Shopping, Phone Shopping, and Mail
Shopping packages merge Shopping Cart package. The same 4
packages use Payment package. Both Payment and Shopping Cart
packages import other packages.

93. Sequence Diagram
 Sequence Diagrams are interaction diagrams that
detail how operations are carried out.
 They illustrate how the different parts of a system
interact with each other to carry out a function, and
the order in which the interactions occur when a
particular use case is executed.
93

94. Sequence Diagram Notations
94

95. Lifeline Notation
 A sequence diagram is made up of several of
these lifeline notations
 No two lifeline notations should overlap each
other
 They represent the different objects that
interact with each other in the system
 A lifeline notation with an actor element
symbol is used when the sequence diagram is
owned by a use case
95

96. Activation Bars
 Activation bar is the box placed
on the lifeline
 It indicates that an object is
active (or instantiated) during
an interaction between two
objects
 The length of the rectangle
indicates the duration of the
interaction
96

97. Message Arrows
 An arrow from the Message Caller to the Message
Receiver specifies a message
 The message can flow in any direction; from left to
right, right to left and back to the caller itself
 The description of the message should go on the arrow
 Arrow heads may change according to different
message types
97

98. Different message types
 Synchronous message
 Asynchronous message
 Return message
 Reflexive message
 Participant creation message
 Participant destruction message
98

99.  A synchronous message is used
when the sender waits for the
receiver to process the message
and return before carrying on
with another message
 An asynchronous message is
used when the message caller
does not wait for the receiver to
process the message and return
before sending other messages to
other objects within the system
99
Synchronous and Asynchronous message

100. Synchronous and Asynchronous
message
100

101. Return and Reflexive message
 A return message is used to indicate that the message
receiver is done processing the message and is
returning control over to the message caller.
 When an object sends a message to itself, it is called a
reflexive message. It is indicated with a message
arrow that starts and ends at the same lifeline
101

102. Return and Reflexive message
102

103. Creation and destruction message
 Participant creation message; objects can be created
in the middle of a sequence. The dropped participant
box notation is used when you need to show that the
particular participant did not exist until the create call
was sent.
 Participant destruction message; participants,
when no longer needed, can also be deleted from a
sequence diagram. This is done by adding an ‘X’ at the
end of the lifeline of the said participant.
103

104. Creation and destruction message
104

105. Comments
 UML generally permits the annotation of comments in
all UML diagram types.
 The comment object is a rectangle with a folded-over
corner as shown below. The comment can be linked to
the related object with a dashed line.
105

106. How to Draw a Sequence Diagram
 A sequence diagram represents the scenario or flow of
events in one single use case. The message flow of the
sequence diagram is based on the narrative of the
particular use case.
 Before you start drawing the sequence diagram or
decide what interactions should be included in it, you
need to ready a comprehensive description of the
particular use case.
106

107. Use case example - Create
new online library account
107

108.  From the use case diagram example of ‘Create New
Online Library Account’, we will focus on the use case
named ‘Create New User Account’ to draw our
sequence diagram.
Step 1:
Identify the objects or participants in the use case
‘Create New User Account’
 Librarian
 Online Library Management system
 User credentials data base
 Email system
108

109. Step 2:
List down the steps involved in the execution of the
use case
 The librarian requires the system to create a new online
library account
 The librarian selects the library user account type
 The librarian enters the user’s details
 The user’s details are checked using the user
Credentials Database
 The new library user account is created
 A summary of the new account’s details is emailed to
the user
109

110. Step 3:
Identify which messages should be passed between
the objects we identified earlier as the system
executes these steps. Then draw the sequence
diagram.
110

111. 111

112. Ex: ATM SYSTEM
112