OBJECT-ORIENTED

SOFTWARE ENGINEERING
UNIT 03 : Unified Modeling Language

© 2019, PRAMOD PARAJULI

 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.
 UNIFIED MODELING LANGUAGE
 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)
 BUILDING BLOCKS OF UML
UML has 3 types of building blocks

 Things – abstraction of ‘first class citizens’

 Relationships – among things
 Diagrams – group interesting collections of things
 THINGS
Things in UML

 Structural things
 Behavioral things
 Grouping things
 Annotational things
 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
 THINGS
Structural things
 Class – set of objects e.g. Sensor
Sensor
-name
-value
-time_stamp
+powerUp()
+calibrate()
+readSensor()
+setInterval()
 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!

IReadSensorData
 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
 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
 THINGS
Structural things
 Active class – a class that its objects represent elements
whose behavior is concurrent with other elements.
EventManager

+start()
+stop()
+flush()
 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
 THINGS
Structural things
 Node – exists at runtime and represents a computational
resource
 Contains a set of components

WebServer
 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
 THINGS
Behavioral things
 Represent dynamic components in UML models, the
verb part of UML models
 Two types;
– Interaction
– State machine
 THINGS
Behavioral things
 Interaction – messages passed between/among components

display
 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
 THINGS
Grouping things
 Packages – organise elements into groups

Conversion rules
 THINGS
Annotational things
 Notes – explanatory parts of UML model

regex for
formatting
 RELATIONSHIPS
Relationships in UML

 Dependency
 Association
 Generalisation
 Realisation
 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)
 RELATIONSHIPS
Relationships in UML
 Association – shows links among objects along with labels
and multiplicity

0..1 *
weather station sensor
 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)
 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.
 UNIT 03: Object Orientation Fundamentals and UML

UML NOTATIONS (DIAGRAMS)

References:
• Booch et al., The Unified Modeling Language User Guide, Pearson. and
• Booch et al., Object-Oriented Analysis and Design with Applications, 3 rd ed., Addison-Wesley., Chapter 5.
 DIAGRAMS
 Package diagram
Diagrams in UML  Component diagrams

 Graphical representation 

Deployment diagrams
Use case diagrams
of a set of elements  Activity diagrams
 Class diagrams
 Different combination of  Sequence diagrams
 Interaction overview diagrams
elements serve different  Composite structure diagrams
purpose 

State machine diagrams
Timing diagrams
 Object diagrams
 Communication diagrams
 Process segments

Requirements Analysis Design Development Deployment

Use case diagram Sponsor objectives Conceptual model

Conceptual level Specification level Implementation level
Class diagram
classes classes classes
Object diagram Identify objects Identify objects

State diagram Object behavior

UML diagrams

Sequence diagram Object interaction

Collaboration diagram Object interaction

Activity diagram User operation(s) System operations

Visualise
Component diagram
components
System
Package diagram
requirements
Deployment diagrams System elements System integration System integration
 STRUCTURE DIAGRAMS
 Package diagram
 Class diagram
 Component diagram
 Deployment diagram
 Object diagram
 Composite structure diagram
 BEHAVIOR DIAGRAMS
 Use-case diagrams
 Activity diagram
 State machine diagram
 Interaction diagrams
– Sequence diagram
– Communication diagram
– Interaction overview diagram
– Timing diagram
 Example on the book for diagrams:
Hydroponics Gardening System
 PACKAGE DIAGRAMS
It is essential to organise
OOAD artifacts;  Provides abstraction at multiple
 Provide clarity and understanding
levels – from systems to classes in
of complex system development a component
 Supports concurrent model used  Provides encapsulation and
by multiple users containment; supports modularity.
 Supports version control  (fig. 5-2, 5-3)
PACKAGE DIAGRAMS
PACKAGE DIAGRAMS
 PACKAGE DIAGRAMS
Visibility of elements Dependency relationship
 Public ( + ) – can be thought as  Elements of package depends on
package interface elements of the same or other
 Private ( - ) packages
 (fig. 5-4)  Tail of the arrow – dependent (client)
 Arrowhead – supporter (supplier)
 Type of dependency – defined within
guillemets ( « » )
e.g. «import»
 (fig. 5-5)
PACKAGE DIAGRAMS
PACKAGE DIAGRAMS
 PACKAGE DIAGRAMS
 Multiple dependencies  Package diagrams can also be
between packages are used to show different model
aggregated to the level of elements such as classes, (fig. 5-7)
 Can also be used on UML diagrams
containing package.
that are not structure diagrams
(fig. 5-6) e.g. use cases
 Usage
package_name::element_na
me
PACKAGE DIAGRAMS
PACKAGE DIAGRAMS
 PACKAGE DIAGRAMS
Advanced concepts
 Import – import public package
 Access – within the package
 (fig. 5-8)
 COMPONENT DIAGRAMS
 Components
– reusable piece of software,
– provides meaningful aggregation of functionality
– collaborate with other through well-defined interfaces
 COMPONENT DIAGRAMS
 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)
 COMPONENT DIAGRAMS
 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)
 COMPONENT DIAGRAMS
 Components – internal structure
– A component may contain subsystems
– These subsystems have their own interfaces
– (fig. 5-16)
 DEPLOYMENT DIAGRAMS
 Shows allocation of artifacts to nodes in the physical
design of a system
 3 essential elements
– Artifacts
– Nodes
– Their connections
 DEPLOYMENT DIAGRAMS
 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)
 USE-CASE DIAGRAMS
 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)
 USE-CASE DIAGRAMS
 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)
 ACTIVITY DIAGRAMS
 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)
 CLASS DIAGRAMS
 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
 CLASS DIAGRAMS
 Class relationships (fig. 5-35)
– Association
– Generalisation
– Aggregation
– Composition
 Classes can be used to represent physical containment
(fig. 5-36)
 CLASS DIAGRAMS
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)
 CLASS DIAGRAMS
Advanced concepts
 Constraints – can be specifies for classes and their
relationships, (fig. 5-40)
 Association classes and notes, (fig. 5-41)
 SEQUENCE DIAGRAMS
 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
INTERACTION OVERVIEW DIAGRAMS
 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.
 COMPOSITE STRUCTURE DIAGRAMS
 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)
 STATE MACHINE DIAGRAMS
 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.
 STATE MACHINE DIAGRAMS
 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)
 STATE MACHINE DIAGRAMS
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)
 TIMING DIAGRAMS
 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)
 TIMING DIAGRAMS
Advanced concepts
 Alternate representations, (fig. 5-73)
 Events vs. messages, (fig. 5-74)
 OBJECT DIAGRAMS
 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
 OBJECT DIAGRAMS
Two elements
 Objects, (fig. 5-75)
 Relationships, (fig. 5-76)
 May use end names and qualifiers
 COMMUNICATION DIAGRAMS
 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)
 COMMUNICATION DIAGRAMS
 Synchronisation is supported, (fig. 5-79)
 Iterations and conditions, (fig. 5-80)
End of Unit 03 : UML