Object Oriented Design: UML Diagrams

Before UML 2.0 Diagram Overview (14)

Structural

Class diagram

Object diagram

Composite diagram

Behavioural

Use case diagram

Sequence diagram

State machine diagram

Activity diagram

Communication diagram / Collaboration diagram

Interaction overview

Timing diagram

Implementation

Component diagram

Deployment diagram

Model Management

Package diagram

Profile Diagram

Structural

Class diagram

Class Name : name of class, ( stereotyped : abstract class, enumeration data type)
Attributes -> type, visibility
Operations -> visibility, parameters, return type

public	+	Any class can use the feature
protected	#	Any descendent of the class can see the feature
private	-	Only the class itself can see the feature
package	~

Relationships (additional_1, additional_2)

Association
aggregation
composition
Generalization/ Inheritance
Dependency
Realization

Composition vs aggregation

Both are same, (ex: Garden has Mango Plant, Garden has Banana Plant)

but in composition the contained classes (Mango Plant, Banana Plant) are strongly dependent on the life cycle of the container (Garden). If container class is destroyed,the contained classes are also vanished. In aggregation, not dependent, Plant objects will remain even when the Garden is destroyed.

Multiplicity

Multiplicity	Option	Cardinality
0..0	0	Collection must be empty
0..1		No instances or 1 instance
1..1	1	Exactly 1 instance
0..*	*	0 or more instances
1..*		At least 1 instance
5..5	5	Exactly 5 instances
m..n		At least m but no more than n instances (m , n are integers)

In addition to common pre-defined compartments (name,attributes,operations) , user-defined compartments (exceptions thrown, responsibilities) can be added to a class.

Detailed class notation

Example 01 : 2015 OOD assignment 1

Example 2 : 2015 OOD assignment 2

Example 3 : OOD Exam 2014 Question 2 part (b); OOD Exam 2016 Question 2 part (c)

Object Diagram

Composite Structure Diagram

Bank ATM UML composite structure diagram example

Purpose: The purpose of this diagram is to show internal structure of a bank ATM and relationships between different parts of the ATM.
Summary: Bank ATM is typically made up of several devices such as central processor unit (CPU), cryptoprocessor, memory, customer display, function key buttons (usually located near the display), magnetic and/or smartchip card reader, encrypting PIN Pad, customer receipt printer, vault, modem.

( Apache Tomcat 7 Server Composite Structure Diagram Example )

Behavioural

Use case diagram

Define interactions between an actor and a system to achieve a goal.
Model the context of the system : present an outside view of how elements of the system will be used.
Model the functional requirements of the system.
Don’t specify how use cases are implemented
A set of sequences : interactions of actors with the system (outside)
Have variants : common re-usable behaviour is factored out as a set of use cases.
Can apply to whole system or a sub system
Format of a UML use case

Title
Main success scenario (numbered list of steps)
extention

Example : Buy Item

Use case title : Buy Item
Actors : Customer (initiator), Cashier
Success scenario :

The customer arrives at the checkout with items to purchase.
The cashier records purchase and collects a payment.
On completion, customer leaves with the items.

Extension : payment fails, customer leaves without items.

Actor

External entity
Interacts with the system (ex: human, software, physical)
Role rather than an individual (ex: one human can be a user actor and manager actor)

Use Case

Set of interactions between the system
One or more actors to achieve some specific goal.
Focus on user’s goals
Can be organized by generalization, include and extend relationship.

Use case diagram

System boundary

Relationships

Association / communication : actors associated with use cases

Generalization : inheritance relationship between actors, between use cases

Actor generalization

Use case generalization

Include

A use case includes another use case (sub use case)

Can have a common behaviour of a system as a sub use case

Make use cases more compact, rational and simple

extend

A use case is extended to describe more behaviour in some cases

Models optional parts

Rare, complex variations

Error or exception handling

Use a label to describe the extension

Example 1 : OOD assignment 2015 : Multi screen cinema

Example 2 : Automated Teller Machine (ATM)

Example 3 : Finance Example

Limitations

Lack of standard format
Not good to capture non-functional requirements
Some relationships will confuse extend/include
Emphasize ordering (numbered steps) and functional decomposition that are not object oriented.
Gives picture of existing processes of the system

Interaction Diagrams

System Sequence diagram

Visualizes a particular use case

Part of the process of analysing and documenting the use cases
Models events generated by external actors
The sequence of events that cross the boundary between actors and system(s)

Elements participate : Actors and System(s)
Elements pass messages : can be any type of messages depending on the system

Part of elaboration phase of design

Identify system events and system operations
Document sequence of interactions in use cases

Notation : use UML Sequence Diagram notations
System : the Software (+ hardware)

Identify just one system, although large systems may have loosely coupled sub systems that might be identified as separate.

System Event : initializes system operations
System Operations : determined by System Events

enterItem(UPC, quantity)
endSale()
makePayment()

Example : Use case : Buy Items

Represent the operations associated with these events as operations of a class in UML

How to draw a System Sequence Diagram : Steps

Identify and name System Operations from System Sequence Diagram
State the purpose or responsibilities of the Operation
State the Pre-Conditions : the state of the system prior to the operation
State the Post-Conditions : state changes as they affect objects in the conceptual model

Pre and Post Conditions are predicates : statements that can be true or false
We require that the pre-conditions be true before the operation, and assert that the post-conditions will be true afterwards.
Pre and Post Conditions and Output may be written in text/natural language and added as comments to UML

Sequence diagram

Visualizes a method of a class
Focus on time ordering of messages and interactions
Consists of :

Objects (roles) participate in interaction

Across top of diagram

initiating object on left, subsequent interacting objects on right

Role (Object)	Notation
Object of an anonymous class	or
Named object of a specified class
Anonymous object of a specified class
Actor	or

Object lifeline

Vertical dashed line

Represent the existence of object over time

Messages/actions

Arrows between lifelines

As time is increasing, messages are shown from top to bottom

Asynchronous : Send (sending signal)

Synchronous : Call (invocation of operations of receiving objects)

Format : altr = msgName(arg1:class) : returnType

Message	Notation
Call (invoke an operation) : asynchronous	solid arrowhead
Send (send a signal) : asynchronous	stick arrowhead
Return (return to caller object)
Create / Destroy an object	and

Activation

Double line on lifeline

Shows execution of a procedure

Message Semantics

Second call to object

Showing returns

Message to itself

Conditional message

Conditional message alternative syntax using opt operator

Mutually exclusive condition

Iteration for a sequence of messages

Iteration over a multi object

Message that takes time (downward arrow)

Found message

Combined Fragments : example from Microsoft Developer Network

Nested Fragments

Message Sequencing : Decimal numbering of messages : 1 1.1 1.2 2 2.1 3 …….

Notation Summary

Example1 : Video Rental System

Example2 : Elevator System : asynchronous messages : stick arrowhead : sending signal

Example 3 : OOD Exam Paper 2015 Question 2 part (c ) ; I guess the same question will be in your exam paper too.

Communication diagram (Collaboration diagram)

Focus on structural organization of objects/instances/roles that send and receive messages

similar to sequence diagrams
Focus on control, not explicit

Graph of instances with links between them to indicate communication between them.

Messages : labelled arrows : attached to connectors/links
Include a sequence number (and a guard : optional)
Message parameters, return values
UML syntax

return := message(parameter: paraType) : retType

Example 1 : communication diagram vs Sequence Diagram

Example 2 : makePayment example

The message makePayment is sent to an instance of s POST. It corresponds to the makePayment system operation message.
The POST object sends the makePayment message to a Sale instance
The Sale object creates an instance of a Payment

Sequence Diagram

Communication Diagram

Return type and value name

State Machine diagram

(video guide) (behavioural vs protocol)

Two types (UML 2.0)

Behavioural state machine diagrams

Specify the discrete behaviour of a part of designed system.

(life cycle of various model elements - classes, instances, components,

subsystems)

Behavior is modeled as a traversal of a graph of state nodes connected with

Transitions.

Transitions are triggered by the dispatching of series of events.
During the traversal, the state machine may also execute some activities.
The behaviored classifier owning a state machine defines;

which signal and call triggers are defined for the state machine, and
which attributes and operations are available in activities of the state machine.

Protocol state machine diagrams

Specialization of behavioural state machine
Express usage protocols of a part of a system

(lifetime of a classifier, legal transitions triggered by classifiers, interfaces or ports)

It specifies which operations of the classifier can be called in which state and under which conditions, thus specifying the allowed call sequences on the classifier’s operations
A protocol state machine is always defined in the context of a classifier and a classifier may have several protocol state machines.
The states of a protocol state machine (protocol states) present an external view of the class that is exposed to its clients.

SMD is an enhanced and extended Finite State Machine (FSM) automation

Based on Statechart Notation (Harel, 1987)

Finite State Machine (FSM)

Abstract machine
In one of a finite number of states
Mealy machine

support actions that depend on both the state of the system and the

triggering event

Moore machine

as well as entry and exit actions, which are associated with states rather

than transitions

(Mealy vs Moore video guide)

Older state modelling methods include Ward and Mellor (1985), Hartley and Pirbhai (1987)

Model real-time, embedded systems

Event

Significant or noteworthy occurrence

State

Condition of an object at the moment
can have optional entry and exit actions
Notation : rounded rectangles

Transition

Relationship between two states that indicates when an event occurs
Notation : arrows between states
Transition labels have three parts :-

Event [Guard] / Behaviour

– Event (or Trigger) is something that happens that affects the system (can have Event Parameters)

– Guard is a Boolean condition that must be true for transition to take

place

– Behaviour (or Actions) can be associated with transitions (executed if

and when the transition fires)

Actions occur quickly and aren’t interruptible whereas activities, can take longer and are interruptible

Internal transition: a response to an event that cause the execution

of an effect but does not cause a change of state or the execution of

exit actions

Completion transition: transitions that lacks an explicit trigger is

triggered by the completion of activity in the state that it leaves

– may have a guard condition which is evaluated at the time that activity

in state completes

Same event can be a trigger for more that one transition leaving a

single state

– each must have a separate guard condition

– only one transition may fire (within one thread of control) in response to

one event occurrence

State	Notation
Simple State Doesn’t have Sub States
States can have entry and exit actions (initialization and cleanup) and activity
Initial pseudostate (can be at most one initial vertex in a region)
Composite state is defined as state that has substates (nested states) ─ Hierarchical State Machine (HSM) – every state machine has a optional top state

Hierarchical State Machine (HSM)

HSMs facilitate abstraction and reuse of behaviour

Sub-states (nested states) only define differences from superstates

(containing states)

sub-state inherits common behaviour from superstate(s) by

Ignoring events automatically handled by higher-level states

Reduce complexity

in Example 4, Cancel transition to Idle represented once instead of having a transition from each of four Active states

STM in a Frame

State Machine could be in a frame labeled as state machine or stm

in abbreviated form.

Example 1 : Modelling Telephone Example

Example 2 : simplified version of a Process Sale Use Case

Can use a SM to describe the legal sequence of external system events that are recognized and handled by system in context of particular use case.

Example 3 : Stock Dispatch Example

Item Received is an event, /get first item is an action, [Not all items checked] is a guard, do/check item is an activity

Example 4 : Composite State Example

Example 5 : Toaster Oven Example : Composite State Example

Activity diagram

Interaction overview diagram

Timing diagram

Implementation

Component diagram

Shows;

Components
Provided and required interfaces
Ports
Relationships between them

Component-based development based on assumptions, If needed;

Previously constructed components could be reused and
That components could be replaced by some other equivalent and conformant components

Components in UML could represent;

Logical components
Physical components

Component;

Reusable piece of software
Provide meaningful aggregate of functionality
A cluster of classes coherent each other but loosely coupled relative to other clusters

Programming ideally proceeds by assembling existing functionalities.

Some programmers build basic components, self-contained and functionally exhaustive, while other programmers assemble and configure them.

This allows for a separation of expertise where for instance, experts on operating systems develop OS code, while other programmers focus on particular application domains.

Some contexts are well-suited for components:

(ex: the operating system API provides a clear component that separates hardware from application programs, but other domains are harder to break into clearly defined components)

self -contained

Can move it around and

Reuse it without complex installation of other software

Components may not make sense without other components which are

Required.

Coarse-grained
Functionally exhaustive
Customisable
With an interface (programming)

Component in UML

Black box (external view of the component)

White box (internal view of the component)

Interactions between components may also be designated by straight lines without plug and socket notation;

Components use each other
Provide interfaces to each other

Specifying Component Interfaces : Types also can be specified.

Component and Classes

What classes actually implement a component
To specify this, number of notations, representing inclusion or realization

(video guide : more)

Deployment Diagram

Overview of how a system is deployed on the necessary hardware
Three elements :

Artifacts
Nodes
Connections

Deployment diagram is to show the allocation of artifacts to nodes in the physical design of a system.
Artifacts

Physical item, Implements a portion of the software design
Typically a software code (could be a source file, document, item related to s/w code)
Have relationships with other artifacts (dependency, composition)

Nodes

Computational resource
Contain memory and processing
Artifacts are deployed on nodes for execution
May contain other nodes to represent complex execution capability
Two types

Devices
Execution environments

Two Nodes talking

Nodes vs Artifacts

Example 1

Example 2

Model Management

Package diagram

Allows examination of a software system at a very coarse scale.
Very good for analysing whole system or a large part of it.
Package in UML

a unit containing certain number of UML elements (typically classes)
Can be defined recursively, with packages including other packages.
notation

No exact programming language entity, that a package corresponds.

In java : Java Packages
In C++ : C++ Namespaces

No two elements within a package has the same name. (Package provides namespaces)
Can set visibility of an element of a package, in front of th element name.

public	+	Visible to elements within its containing package, including nested packages and to external elements.
private	-	Visible only to elements within its containing package and to nested packages.

Dependency relationship

To represent the access of an element which has the appropriate visibility to afford access.
Dashed arrows from Client --------> Supplier
Client can be modified without modifying the Supplier (opposite is not valid)
Dependency arrows can be labelled, specifying the type of relationship.(but often unnecessary, can avoid if it gives complication)

Packages and other diagrams

Packages represent inclusion and dependencies between nested packages.
Can use package diagrams to partition other sets of diagrams, in order to have convenience in large systems. (in class diagrams, use case diagrams, etc)