Fundamentals of UML, diagrams and usage based on UML 2.0 delivered to post-graduate students of Object Oriented Software Engineering.

1. OBJECT-ORIENTED
SOFTWAREENGINEERING
UNIT 03 : Unified Modeling Language
© 2019, PRAMOD PARAJULI

2. Disclaimer
These slides are part of teaching materials for Object Oriented
Software Engineering (OOSE). These slides do not cover all
aspect of learning OOSE, nor are these be taken as primary
source of information. As the core textbooks and reference
books for learning the subject has already been specified and
provided to the students, students are encouraged to learn
from the original sources.
Contents in these slides are copyrighted to the instructor and
authors of original texts where applicable.

3. UNIFIEDMODELINGLANGUAGE
 Is a standard to model systems
 Is not a process! Optimally should be used in a process that is
use case driven, architecture-centric, iterative, and incremental.
 Helps to
– visualise a system throughout different phases of development.
– specify requirements
– design software components
– document (requirements, architecture, design, source code, project
plans, tests, prototypes, release)

4. BUILDINGBLOCKSOFUML
UML has 3 types of building blocks
 Things – abstraction of ‘first class citizens’
 Relationships – among things
 Diagrams – group interesting collections of things

5. THINGS
Things in UML
 Structural things
 Behavioral things
 Grouping things
 Annotational things

6. THINGS
Structural things
 Structural components, the noun part of models
 Class – set of objects e.g. Sensor
 Interface – externally visible behavior of an element
that specify a service of a class or component
 Collaboration
 Use case
 Active classes, components, and nodes

7. THINGS
Structural things
 Class – set of objects e.g. Sensor
Sensor
-name
-value
-time_stamp
+powerUp()
+calibrate()
+readSensor()
+setInterval()

8. THINGS
Structural things
 Interface – externally visible behavior of an
element that specify a service of a class or
component
 Interface defines only the specifications not the
implementations!
IReadSensorDat
a

9. THINGS
Structural things
 Collaboration – specify structure and behavior of
collaboration between entities
 We visualise such collaborations in use-case
diagrams and activity diagrams.
Init
Sensor

10. THINGS
Structural things
 Use case – specify description of set of sequence of
actions
 Used to structure the behavioral things
 Realised by a collaboration
Request
data

11. THINGS
Structural things
 Active class – a class that its objects represent
elements whose behavior is concurrent with other
elements.
EventManager
+start()
+stop()
+flush()

12. THINGS
Structural things
 Component – physical and replaceable part that
represents the packaging of logical elements such
as classes, interfaces and collaborations.
 COM+, Java Beans etc.
sensordata.java

13. THINGS
Structural things
 Node – exists at runtime and represents a
computational resource
 Contains a set of components
WebServer

14. THINGS
Structural things
 Structural components, the noun part of models
 Class – set of objects e.g. Sensor
 Interface – externally visible behavior of an element
that specify a service of a class or component
 Collaboration
 Use case
 Active classes, components, and nodes

15. THINGS
Behavioral things
 Represent dynamic components in UML models, the
verb part of UML models
 Two types;
– Interaction
– State machine

16. THINGS
Behavioral things
 Interaction – messages passed between/among
components
display

17. THINGS
Behavioral things
 State machine – specifies the sequence of states an
object or an interaction goes through during its
lifetime in response to events
Waiting

18. THINGS
Grouping things
 Packages – organise elements into groups
Conversion rules

19. THINGS
Annotational things
 Notes – explanatory parts of UML model
regex for
formatting

20. RELATIONSHIPS
Relationships in UML
 Dependency
 Association
 Generalisation
 Realisation

21. RELATIONSHIPS
Relationships in UML
 Dependency – shows semantic relationship
between two things in which a change to one
thing (independent) may affect the semantics of
the other (dependent)

22. RELATIONSHIPS
Relationships in UML
 Association – shows links among objects along with
labels and multiplicity
weather station sensor
0..1 *

23. RELATIONSHIPS
Relationships in UML
 Generalisation – shows
generalisation/specialisation relationships in
which objects of specialised element (the child)
are substitutable for objects of generalised
element (the parent)

24. RELATIONSHIPS
Relationships in UML
 Realisation – semantic relationship between
classifiers.
 Used between interfaces and classes or
components that realise them, and between use
cases and the collaborations that realise them.

25. UMLNOTATIONS(DIAGRAMS)
UNIT 03: Object Orientation Fundamentals and UML
References:
• Booch et al., The Unified Modeling Language User Guide, Pearson. and
• Booch et al., Object-Oriented Analysis and Design with Applications, 3rd
ed., Addison-Wesley., Chapter 5.

26. DIAGRAMS
Diagrams in UML
 Graphical representation
of a set of elements
 Different combination of
elements serve different
purpose
 Package diagram
 Component diagrams
 Deployment diagrams
 Use case diagrams
 Activity diagrams
 Class diagrams
 Sequence diagrams
 Interaction overview diagrams
 Composite structure diagrams
 State machine diagrams
 Timing diagrams
 Object diagrams
 Communication diagrams

28. Process segments
Requirements Analysis Design Development Deployment
UML
diagrams
Use case diagram
Sponsor
objectives
Conceptual
model
Class diagram
Conceptual
level classes
Specification
level classes
Implementation
level classes
Object diagram Identify objects Identify objects
State diagram
Object
behavior
Sequence diagram
Object
interaction
Collaboration diagram
Object
interaction
Activity diagram
User
operation(s)
System
operations
Component diagram
Visualise
components
Package diagram
System
requirements
Deployment diagrams
System
elements
System
integration
System
integration

29. STRUCTUREDIAGRAMS
 Package diagram
 Class diagram
 Component diagram
 Deployment diagram
 Object diagram
 Composite structure diagram

30. BEHAVIORDIAGRAMS
 Use-case diagrams
 Activity diagram
 State machine diagram
 Interaction diagrams
– Sequence diagram
– Communication diagram
– Interaction overview diagram
– Timing diagram

31. Example on the book for diagrams:
Hydroponics Gardening System

32. PACKAGEDIAGRAMS
It is essential to organise
OOAD artifacts;
 Provide clarity and
understanding of complex
system development
 Supports concurrent model
used by multiple users
 Supports version control
 Provides abstraction at
multiple levels – from
systems to classes in a
component
 Provides encapsulation and
containment; supports
modularity.
 (fig. 5-2, 5-3)

33. PACKAGEDIAGRAMS

34. PACKAGEDIAGRAMS

35. PACKAGEDIAGRAMS
Visibility of elements
 Public ( + ) – can be thought
as package interface
 Private ( - )
 (fig. 5-4)
Dependency relationship
 Elements of package depends
on elements of the same or
other packages
 Tail of the arrow – dependent
(client)
 Arrowhead – supporter (supplier)
 Type of dependency – defined
within guillemets ( « » )
e.g. «import»
 (fig. 5-5)

36. PACKAGEDIAGRAMS

37. PACKAGEDIAGRAMS

38. PACKAGEDIAGRAMS
 Multiple dependencies
between packages are
aggregated to the level of
containing package.
(fig. 5-6)
 Package diagrams can also be
used to show different model
elements such as classes, (fig. 5-
7)
 Can also be used on UML diagrams
that are not structure diagrams
e.g. use cases
 Usage
package_name::element_
name

39. PACKAGEDIAGRAMS

40. PACKAGEDIAGRAMS

41. PACKAGEDIAGRAMS
Advanced concepts
 Import – import public package
 Access – within the package
 (fig. 5-8)

43. COMPONENTDIAGRAMS
 Components
– reusable piece of software,
– provides meaningful aggregation of
functionality
– collaborate with other through well-defined
interfaces

44. COMPONENTDIAGRAMS
 Components
– ports – have public visibility unless otherwise
noted, kept on the boundary
– components may have hidden ports (kept
totally inside the boundary), used for testing
– Named as
port_name:Port_Type
– Use of ball and socket, (fig. 5-9)

46. COMPONENTDIAGRAMS
 Components – interfaces
– Interfaces can be grouped, (fig. 5-10)
– An example of component diagram, (fig. 5-11)
– Interface specification, (fig. 5-12)
– Alternate notation for the interface, (fig. 5-13)
– Realization of dependencies, (fig. 5-14)
– Containment of realization, (fig. 5-15)

52. COMPONENTDIAGRAMS
 Components – internal structure
– A component may contain subsystems
– These subsystems have their own interfaces
– (fig. 5-16)

54. DEPLOYMENTDIAGRAMS
 Shows allocation of artifacts to nodes in the physical
design of a system
 3 essential elements
– Artifacts
– Nodes
– Their connections

55. DEPLOYMENTDIAGRAMS
 The artifact notation – using <<manifest>>, (fig. 5-17)
 The node notation – represents computational resource
 Two types of nodes;
– Devices
– Execution environment
 Nodes can have multiplicity, (fig. 5-18)
 Example of a deployment diagram, (fig. 5-19)

59. USE-CASEDIAGRAMS
 Specify business needs
 Includes roles as actors (fig. 5-20)
 Shows who needs what
 Use cases – a function
 Use case diagram (exists in environment, may
have system boundary) (fig. 5-22)

61. USE-CASEDIAGRAMS
 Use cases are detailed using use case specification,
example on p.179
 Use case diagram may include «include» and
«extend» relationships among the use cases,
(fig. 5-25)
 When to use «include» and «extend»? (table 5-1,
p. 184)
 Advanced concept: generalization (fig. 5-26)

65. ACTIVITYDIAGRAMS
 Representing flow of process graphically, has very high
semantics
 Elements: action nodes, control nodes, and object
nodes.
 Control notes – 3 types:
– initial and final (activity final and flow final), (fig. 5-28)
– decision and merge (fig. 5-29, fig. 5-30), and
– fork and join (fig. 5-31)
 Activity diagram with objects (fig. 5-32)

70. CLASSDIAGRAMS
 Class notations (fig. 5-33)
 Set of attributes, methods
 Detailed attribute and operation specification
 Abstract class – has no instances (italicize the
name) (fig. 5-34) – FoodItem
 Subclass (Tomato) inherits the abstract class
 Content (has-a relationship)
 Class relationship may contain multiplicity

72. CLASSDIAGRAMS
 Class relationships (fig. 5-35)
– Association
– Generalisation
– Aggregation
– Composition
 Classes can be used to represent physical containment
(fig. 5-36)

75. CLASSDIAGRAMS
Advanced concepts
 Template classes (fig. 5-37)
 Visibility of elements (fig. 3-38)
– Public ( + )
– Protected ( # )
– Private ( - )
– Package ( ~ )
 Association end names and qualifiers (roles
played by classes), (fig. 5-39)

78. CLASSDIAGRAMS
Advanced concepts
 Constraints – can be specifies for classes
and their relationships, (fig. 5-40)
 Association classes and notes, (fig. 5-41)

81. SEQUENCEDIAGRAMS
 Used to trace the execution of a scenario in the same
context as a communication diagram (included together).
 Objects and interactions – lifelines and messages
(events/invocation of operations), (fig. 5-42)
 Different notations can be used for types of messages (fig.
5-43)
 Destruction events

84. INTERACTIONOVERVIEWDIAGRAMS
 Combination of activity diagram and interaction
diagram.
 Provide overview of the flow control between
interaction diagram elements.
 Any interaction diagram can be used. But in most cases,
sequence diagram is used.
 Flow of control elements (fig. 5-49), for parallel paths,
a fork node is used.

86. COMPOSITESTRUCTUREDIAGRAMS
 Explains structured classifier with the definition of its internal
structure.
 The internal structure contains parts and their relationships.
 They can be nested.
 Useful for decomposition of models.
 Essential elements - parts, ports, interfaces, connectors
 Example: (fig. 5-50)

88. STATEMACHINEDIAGRAMS
 Useful to model time-critical systems
 Shows behavior progression through a series of states,
triggered by events.
 Typically used to describe the behavior of individual
objects.
 Applicable to only those classes that exhibit event-ordered
behavior.
 Useful to analyse and design dynamic behavior.

89. STATEMACHINEDIAGRAMS
 Initial, final, and simple states, (fig. 5-52)
 Transition and events – movement between states, (fig. 5-
53)
 A transition without any annotation is called complete
transition.
 States can have additional states, (fig. 5-54)

92. STATEMACHINEDIAGRAMS
Advanced concepts
 State activities – entry, do and exit, (fig. 5-55)
 Controlling transitions use;
– If-then conditions
– Effects of states (fig. 5-56)
 Composite and nested states, (fig. 5-57, 5-58)
 Concurrency and control, (fig. 5-59 – 67)
 Sub-machine state, (fig. 5-68)

98. TIMINGDIAGRAMS
 Model timing requirements of given system
 Reuse elements that appear in other UML diagrams.
 (fig. 5-69, 5-70)
 Events and constrains can be defined, (fig. 5-71, 5-72)

101. TIMINGDIAGRAMS
Advanced concepts
 Alternate representations, (fig. 5-73)
 Events vs. messages, (fig. 5-74)

103. OBJECTDIAGRAMS
 Model objects and their relationships in logical design of a
system
 Represents a snapshot in time of events over a certain
configuration of objects.
 During analysis, used to indicate semantics of primary and
secondary scenarios
 During design, used to illustrate the semantics of
mechanisms in the logical design of a system

104. OBJECTDIAGRAMS
Two elements
 Objects, (fig. 5-75)
 Relationships, (fig. 5-76)
 May use end names and qualifiers

106. COMMUNICATIONDIAGRAMS
 A type of interaction diagram that shows how objects are
linked and what messages they pass
 Contain;
– Objects
– Links
– Messages
 Sequence is expressed (fig. 5-77)

108. COMMUNICATIONDIAGRAMS
 Synchronisation is supported, (fig. 5-79)
 Iterations and conditions, (fig. 5-80)

111. End of Unit 03 : UML