F

O RA
M
S

E S ES
O
F
DI
AG

C
P
TY

IE L FE
R ENT

P M
I F
D
ING
Y
IF

U
N T
I DE
 UML FRAMEWORK

In itia tio n F e a s ib ilty S tu d y

S c o p e o f D e v e lo p m e n t
U M L F ra m e w o rk
R e q u ir e m e n ts - d o m a in d e s c r ip tio n
- b o u n d a r ie s
C a p tu re
U se C ases
U s e C a s e D ia g ra m

R e q u ir e m e n ts D o m a in M o d e l
A n a ly s is
D o m a in M o d e l
U se C ases
U s e C a s e D ia g r a m
C la s s D ia g r a m
D a t a D ic tio n a r y
CRCs
I n t e r a c tio n S e q u e n c e D ia g r a m
C o lla b o r a t io n D ia g r a m
O p e r a t io n S p e c if ic a tio n s
S ta te c h a rts
S y s te m
D e s ig n M o d e l Im p le m e n ta tio n
D e s ig n
S o ftw a r e A r c h ite c tu re
* s u b -s y s te m s
* la y e r s & p a r titio n in g
O b je c t D e s ig n
U se C ases
U s e C a s e D ia g r a m
s t a t ic v ie w C la s s D ia g r a m r e d r a w n / e x t e n d e d c la s s
d ia g r a m t o r e f le c t d e s ig n
D a t a D ic tio n a r y
d y n a m ic CRCs d e c is io n s : a d d it io n o f in t e r f a c e
a n d c o n tr o l o b je c ts ; a d d itio n
v ie w I n t e r a c t io n S e q u e n c e D ia g r a m
o f c o n s t r a in ts , e tc .
C o lla b o r a t io n D ia g r a m
O p e r a t io n S p e c if ic a tio n s
S ta te c h a r ts
In te rfa c e D e s ig n
* P r e s e n t a t io n L a y e r
D a ta M a n a g e m e n t
* S to r a g e m e c h a n is m s
 TWO MAIN PIECES OF UML
Structural diagrams (physical structure: object/entity and their r/ships)
Two categories:
Class: Class diagram, Object diagram
Implementation: Component diagram, Deployment diagram
Non OO option: data model i.e ERD.
Behavioral diagrams (physical functions)
To show how process flows between components, classes, users and the
system.
E.g. Use case diagram, Activity diagram, Sequence diagram, Collaboration (or composite)
diagram, State (or Statechart) diagram.
Non OO option: Flowchart, DFD
Likely to be accompanied with (informal) tables, decision table etc in an
SRS.
GROUP WORK (10%)
OBJECTIVE/ SKILL: Practicing the search for new knowledge
Form a group of 5 students.
Each group will be given a topic of different models.
Using the internet, find the answers for the following questions:
WHAT exactly is it about?
WHEN it can be used? (State its purposes)
HOW can it be used? (Describe the notations, pick two good
working example)
The task must be completed in 1 hr.
A presenter and an illustrator will be picked randomly from
each group to present the findings. Time allocated: 15 20 min
for each group.
CLASS DIAGRAM
UML was designed with OO programming as a core
concept.
The class is used as the core modeling element.
Encapsulate system behavior and relevant data into
a single operational unit; what classes form the
system, what they offer and how they relate. Not
about how they communicate.
Useful for:
Illustrating system class details and dependencies.
Showing interfaces and required system interactions
OBJECT DIAGRAM
Used to show structural relationships between
instantiated class instances (objects).
Similar to class diagrams but are more concrete;
Every object represents a true in-memory
software element.
Every class represents a definition of those
elements.
Useful for:
Showing object dependencies
Illustrating constraints on object interactions.
COMPONENT DIAGRAM
Components represents the physical realization of
the system elements, typically constructed from
one or more classes that provide a set of defined
behavior.
Used to show dependencies between components
and other external systems via defined interfaces
or other dependencies.
Useful for:
Showing system physical structure.
Detailing system architecture and module.
Illustrating dependencies between internal and
external system elements.
DEPLOYMENT DIAGRAM
All software systems must be deployed to a
physical computer system to be functional:
typically under the control of OS and networked to
other computer elements.
Deployment diagrams take the system
components, show how they are packaged for
delivery to target computers, and show the key
networking elements that exist between devices.
Useful for:
Detailing software packaging.
Illustrating system deployment onto various
component devices.
SEQUENCE DIAGRAM
Focus on the series of message passed between
different system components and objects.
Typically have a single flow, but possible to
have sequence fragments that show looping,
branching, or other kind of procedural
processing events.
Useful for:
Describing r/ships between model elements
(system components).
Describing sequence-based dependencies.
ACTIVITY DIAGRAM
Similar to flowcharts but contain more details.
Useful for:
Illustrating use case flow.
Process view of dynamic system activities.
User interface modeling.
Algorithm details for processing
Illustrating other business activities (worker,
process activities)
COLLABORATION DIAGRAM
Bring class diagram to the next step: a cross between class and
sequence diagram!
Combines elements of other structural diagrams to illustrate
collaborations between system components.
Collaborations occur when a group of classes interact to provide
a defined system functional behavior.
Useful for:
Showing collaborations between system elements.
Abstracting the system structure into a series of collaborating
components.
Drawing attention to core system functional behavior.
Diagram component internal structure and interfaces.
 STATE DIAGRAM
Capture key system states, events, guards and actions.
Summarizes system behavior as a series of state transitions as a
result of one or more events
Can be subdivided to show internal sub state transitions.
Useful for:
Describing system state.
Dynamic aspects of system behavior.
Entry and exit actions for a state change.
System trigger conditions.
Internal state behavior.
Application of historical state information.
 USE CASE DIAGRAM
A high level abstraction about a system help visualization
Excellent way to communicate to management, customers or non-developer:
Illustrate what a system will do when it is completed.
But does not go into details how a system will do something.
Central to the requirement definition process.
Useful for:
indicating system boundaries.
Detailing communication paths between system element and external
Actors.
Summarizing system functionality as a set of use cases.
Illustrating dependencies and interactions between system functional areas.
 USE CASE DIAGRAM

Used to indicate system functional boundaries,

external interactions with system Actors and core
system functionality as a set of flow-based
requirements.
Notation:
System something that perform some functions e.g.
a piece of software
Actors person/system that uses the system.
Use Cases what actions that a user takes on a
system.
PRACTICE
The Grading System
A teacher can record grades, view grades, and
distribute report cards.
A student can view grades (perhaps through an
online program)
A printing admin can create report cards and
view grades online to see if the report cards
are correct.
RELATING HIGHLY-RELATED USE CASES

Include or extend?
A teacher will record grades and update grades.
Whenever a teacher records or updates grades,
the grades will always be saved.
In some cases, such as If a failing grade is
saved, then the guardians are notified.
How about check report card for accuracy.
Note the use of extension points.
EXERCISE 1
In groups of 3-4 spend 5 minutes attempting to
draw a use case diagram for the space invader
game below:
POSSIBLE ANSWER

Move Left

Move Right

Fire Laser
Player
View High Scores

Play Game
 EXERCISE 2
Consider Sonic the
hedgehog.
1. What can sonic do?
2. What are the use
cases?
3. Are there any
relationships
4. Draw the use case
diagram

1. Move left
2. Move right
3. Jump
4. Jump left
5. Jump right
6. Spin Dash
7. Pause
POSSIBLE ANSWERS

Sonic the hedgehog

Move Left

Move Right
<<extend>>
Player Jump Left
Jump <<extend>>

What about: Spin Dash Jump Right

New game
Choose character
Pause Game
etc
NOTE
There are other types of structural and
behavior diagrams available such as Package
diagram, Timing diagram, Communication
diagram, Interaction Overview diagram.