The Unified Modelling

Language 2

BY
S.MUTHUMARIAPPAN
AP/CSE,
UML
 1. Sequence Diagram
 2. Collaboration Diagram
 3. Statechart Diagram
 4. Activity Diagram
 5. Component Diagram
 6. Deployment Diagram
 7. Modelling Architecture
 8. Summary and Test
3.1 Sequence Diagram
 Sequence diagrams show potential interactions between objects in
the system being defined. Normally these are specified as part of a
use case or use case flow and show how the use case will be
implemented in the system. They include:

 Objects - oblong boxes or actors at the top - either named or just shown as
belonging to a class, from, or to which messages are sent to other objects.

 Messages - solid lines for calls and dotted lines for data returns, showing the
messages that are sent between objects including the order of the messages
which is from the top to the bottom of the diagram.

 Object lifelines - dotted vertical lines showing the lifetime of the objects.

 Activation - the vertical oblong boxes on the object lifelines showing the
thread of control in a synchronous system.
SEQUENCE DIAGRAM
3.2 Collaboration Diagram
 Collaboration Diagrams show similar information to sequence diagrams,
except that the vertical sequence is missing. In its place are:
 Object Links - solid lines between the objects. These represent the references
between objects that are needed for them to interact and so show the static
structure at object level. On the links are:
 Messages - arrows with one or more message name that show the direction
and names of the messages sent between objects
3.3 Statechart Diagram
 UML came about when James Rumbaugh joined Grady Booch at
Rational Software. They both had object-oriented syntaxes and
needed to combine them. Semantically, they were very similar; it was
mainly the symbols that needed to be unified. The result was UML
1.0.
 States - oblong boxes which indicate the stable states of the object between events.
 Transitions - the solid arrows which show possible changes of state.
 Events - the text on the transitions before the '/' showing the incoming call to the object
interface which causes the change of state.
 Conditions - a boolean statement in square brackets which qualifies the event.
 Actions - the text after the '/' which defines the objects response to the transition
between states.

Extra syntax which defines state centric functionality
3.4 Activity Diagram
 A UML Activity Diagram is a general purpose flowchart with a few
extras. It can be used to detail a business process, or to help define
complex iteration and selection in a use case description. It includes:
 Active states - oblongs with rounded corners which describe what is
done.
 Transitions - which show the order in which the active states occur
and represent a thread of activity.
 Conditions - (in square brackets) which qualify the transitions.
 Decisions - (nodes in the transitions) which cause the thread to select
one of multiple paths.
 Swimlanes - (vertical lines the length of the diagram) which allow
activities to be assigned to objects.
 Synch States - horizontal or vertical solid lines which split or merge
threads (transitions)
2.5 UML Diagram Types - 2
3.5 Component Diagram
Component Diagrams show the types of software components in the system, their

interfaces and dependencies.

3.6 Deployment Diagram
 Deployment diagrams show the computing nodes in the system, their
communication links, the components that run on them and their

dependencies.
3.7 Modelling Architecture
Class diagrams can be used to model hi-level architecture
with packages, interfaces and dependencies. Packages are
used to group together a set of model elements for various
purposes. The results may show:
 Subsystems - the design view of a software
component or re-useable part of a component.
 Libraries of re-useable elements, usually classes.
 The hierarchic structure and layering of the system
 Client-server relationships between components
and other model elements
 Logical dependencies of sub-systems and libraries
on one another
MODELING ARCHITECTURE
2.9 Summary and Test

 Sequence diagrams show potential interactions between

objects in the system in the order in which they normally occur
 Collaboration diagrams also show interaction between objects,
but emphasise the structure required to support them
 Statecharts are a class-centric view of system functionality
 An activity diagram is a general purpose flowchart
 Component diagrams show the types of software components
in the system, their interfaces and dependencies
 Deployment diagrams show the computing nodes in the
system, their communication links, the components that run on
them and their dependencies
 Class diagrams can be used to model hi-level architecture with
packages, interfaces and dependencies
TEST
 1. The vertical dotted lines on a sequence diagram show
A The thread of control in a synchronous system
B The messages sent between objects
C The lifetime of the object
D A and C
E A and B
F B and C
G All of the above

 2. On a collaboration diagram, messages:

A Are shown as solid lines between objects
B Are shown as arrows on the links between objects
C Are shown as arrows between objects
D May be numbered
E Have message names
F C, D and E
G C and E
H B, D and E
I All of the above
 3. A condition on a statechart
A Qualifies an action
B Appears in curly brackets
C Resolves to true or false
D Qualifies a transition
E Appears in square brackets
F A, B & C
G C, D & E
TEST
 4. On an activity diagram, which of the following is true
A An activity diagram is the same as state chart, only with different symbols
B A decision steers the thread
C A swimlane can represent an activity
D A sync state splits or combines the thread
EB&C
FB&D
GC&D

 5. A component diagram
A Shows the decomposition of the system into subsystems
B Shows the decomposition of the systems into software elements
C Shows relationships between computing nodes
D Shows dependencies between software elements
EB&D
FC&D
GB&C
H None of the above
 6. A deployment diagram
A Shows the decomposition of the system into subsystems
B Shows the decomposition of the systems into software elements
C Shows relationships between computing nodes
D Shows dependencies between software elements Shows dependencies between software elements
EB&D
FC&D
GB&C
H None of the above
 7. A sub-system can represent
A Libraries of classes
B The design of a component
C The design of part of a component
D A layer in the architecture
EB&C
FB&D
G B, C & D