Transcript System Analysis & Design Methods: 3 more UML diagrams

Systems Analysis &
Design Methods
Three more UML diagrams
Contents

More UML diagrams
Use case diagrams
(the diagram is less important than the use cases
themselves )
 Activity diagrams
 Deployment diagrams

System Analysis & Design Methods: 3
more UML diagrams
2
Use Cases: The idea

Martin:


Describes user audible or visible events, as a result of
a user’s stimulus.
Fowler:
=function that can be heard or seen by a user.
 There is a precise goal for the user

System Analysis & Design Methods: 3
more UML diagrams
3
Use Cases – In general







Beginning of requirements analysis. If used, use at
beginning.
=Description of behaviour (in small ovals).
Simple technique. Little rigor. Client can participate.
Supposed to help finding classes and relations.
Use cases (text) are more important than use case diagrams.
Use cases are one possible way to split up functionality and split
up the project.
Detailed diagrams exist but are not very useful.
System Analysis & Design Methods: 3
more UML diagrams
4
Use Cases: An example
primary course
Context: The products of a store visitor pass the cassier.
A ‘normal‘ procedure =‘primary course’=‘normal use
case’ might be:
 Register product (= 1 use case)




1. Cassier moves product over the barcode scanner (the one
stimulus !!)
2. System beeps to show barcode is understood. (audible !!)
3. Price and subtotal appear on screen (visible !!)
4. Product description and price are printed. (visible !!)
System Analysis & Design Methods: 3
more UML diagrams
5
Use Cases: Example
alternate course
Context: The products of a store visitor pass the
cassier. An ‘alternate course’ gives the use case
in case of ‘trouble’:
 Barcode not known
i.p.v. 2:
System beeps low signal prompting to scan again. If
not successful after three trials, do manual
procedure.
System Analysis & Design Methods: 3
more UML diagrams
6
Use Case Diagram/SystemBoundary
Diagram
<<uses>>
Register product
<<uses>>
<<extends>>
Barcode not known
System Analysis & Design Methods: 3
more UML diagrams
boundary
7
Use case diagram: Remarks

The cartoon figure (stick figure) is called an ‘actor’ .








Actor gives external stimulus.
Actors can be machines too, like clocks.
Actors can start up several use cases.
De <<extends>>-arrow starts from the alternate course and
means that a use case is ‘extended’.
De <<uses>>-arrow points to a common part of a use case.
The difference between <<extends >> and <<uses>> is not
really clearcut.
De rectangle shows the system boundaries. E.g. the actor is not
part of the system.
Strictly speaking the diagram shown is a mix of a use case
diagram and a system boundary diagram.
System Analysis & Design Methods: 3
more UML diagrams
8
Activity diagrams



Look like ‘Petri-nets’ used in electronics.
Can be seen as ‘flow charts with parallellism’
Unexpected part of UML. Not specifically
related to object orientation. Not part of the
UML author’s previous works.
System Analysis & Design Methods: 3
more UML diagrams
9
Activity diagrams
Activity = task or method
 Arrows show sequence
 When parallel processing is possible, we see 2 kinds
of synchronization bars:

Concurrent fork: arrows starting from the concurrent
fork show 2 ‘swimlanes’ that may be executed in parallel
 Concurrent join: means: execution can go on from here
only after both swimlanes have finished executing.


A ‘sequential branch’ or ‘decision activity’ (diamond)
is inherited from flow chart drawing
System Analysis & Design Methods: 3
more UML diagrams
10
Activity Diagram
Initial state
Action State or Activity
Select Site
Concurrent fork
Commission architect
Sequential branch or
Decision activity
Develop plan
Concurrent join
Bid plan
[not accepted]
‘Do site’ work and
‘Do trade work’ may be
performed in parallel.
They are called
‘swimlanes’
End state
Do site work
Do trade work
Guard
Finish construction
System Analysis & Design Methods: 3
more UML diagrams
11
Component Diagram


Component Diagram
 A graph of components connected by dependency
relationships.
 Shows the dependencies among software components. In
Java, components are often java packages so a component
diagram often plays the same role as a package diagram.
Dependencies are shown as dashed arrows from the client
component to the supplier component.
If the dependency is really on an interface, you can show this
with a lollypop simbol.
 The dependency can be caused by a datafield, local variable or
parameter on the dependend side.
System Analysis & Design Methods: 3
more UML diagrams
12
Component Diagram Example
Scheduler
component
interface
Planner
updatable
GUI
System Analysis & Design Methods: 3
more UML diagrams
13
Deployment Diagram
Component diagrams are often shown inside
deployment diagrams.
 Deployment diagrams show physical relationship
between hardware and software parts in system.
 A deployment diagram is a graph of nodes
connected by communication associations.
 Nodes
are shown as 3-D boxes.
 Nodes may contain components.
 Components may contain objects (indicating that the
object is part of the component)
System Analysis & Design Methods: 3
more UML diagrams
14
Deployment Diagram Example
:HostMachine
<<database>>
meetingsDB
:Scheduler
node
:PC
:Planner
System Analysis & Design Methods: 3
more UML diagrams
15