1© Wolfgang Emmerich, 1999
Communications Software EngineeringAnalysis Model
Wolfgang Emmerich
2© Wolfgang Emmerich, 1999
Lecture Overview
■ Aims of Analysis Model■ Building on outputs of Requirements Model■ Basic UML notations■ Introduction of new types of analysis objects■ Reuse of use cases■ Inputs for Design Model
3© Wolfgang Emmerich, 1999
UserReqs
SystemReqs
DetailedDesign
Coding
Archit.Design
SystemIntegr.
Pre-Prod.Test
Stages of Development Process
Project and Risk ManagementSystem Management
Version and Configuration ManagementQuality Management
4© Wolfgang Emmerich, 1999
System Reqs Document
Owner: Chief Business Analyst1 UML Use Case Model (Rose) +2 UML Interaction Diagrams (Rose) +
• UML Sequence Diagrams• UML Collaboration Diagrams
3 UML Analysis Class Diagram (Rose) +4 User Interface Prototypes (GUI Tools, Office) *5 Specification of Report Format (Office)6 User Manual (Office)
• User Reference Manual• User’s Guide
AnalysisModel
5© Wolfgang Emmerich, 1999
Aims of the Analysis
■ To provide a ‘logical model’ of the system, interms of :• classes,• relationships
■ “How to get the thing right, now and in thefuture “
6© Wolfgang Emmerich, 1999
Producing an Analysis Model
■ Inputs■ Actions
10 Draft initial class diagram11 Re-examine use case and object behaviour12 Refine class diagram13 Execute check14 Revise class diagram15 Group classes into packages
■ Outputs■ Notations
7© Wolfgang Emmerich, 1999
Analysis Input and Outputs
■ Inputs:• uses cases and use case model• problem domain object list
■ Outputs:• class roles and responsibilities [text]• use case description in terms of classes and
operations [text x use case]• completed analysis model [class and package
diagrams]
8© Wolfgang Emmerich, 1999
Notations
■ Class (rectangle containing name, attributes,operations)
■ Object (rectangle plus obx:Cx)■ Association (by value/aggregation,
cardinality/multiplicity)■ Generalisation (UML term replacing OOSE
‘inheritance’)■ Package■ Depends association
9© Wolfgang Emmerich, 1999
Polygoncentre: Pointvertices: List of PointborderColour: Colour fillColour: Colour
display (on: Surface) rotate (angle: Integer) erase () destroy () select (p: point): Boolean
Polygon
classNameattribute name: type
Op name (parameter: type): result type
className
CLASSES IN UML
10© Wolfgang Emmerich, 1999
objectName: className
attribute name: type = value
(same operationsfor all instances
of a class)
objectName: className
triangle1: Polygoncentre = (0,0)vertices = (0,0), (4,0), (4,3)borderColour: black fillColour: white
display (on: Surface) rotate (angle: Integer) erase () destroy () select (p: point): Boolean
Objects in UML
triangle1: Polygon
11© Wolfgang Emmerich, 1999
ResearcherLecturerLibrarian
Staff Member
SUBCLASS SUBCLASS SUBCLASS
SUPERCLASS
MouseHandlerKeyboardHandler
Handler
UML Generalization
JoystickHandler
12© Wolfgang Emmerich, 1999
bidirectional / binary
unidirectional
“composition”
“aggregation”
role namemultiplicity
role namemultiplicity
supplementary characteristics
association name[+ single directional arrow]
Associations in UML
13© Wolfgang Emmerich, 1999
Composition vs Aggregation
■ Compositionclass Address { char *street; char * plz;}class Person { char * name; Address adr;}
Person p = new Person()
■ Aggregationclass Address { char *street; char * plz;}class Person { char * name; Address *adr; Person(){
adr=new Address();}Person p=new Person;
14© Wolfgang Emmerich, 1999
User Workstationauthorised on >
home directory
1..* 1..*
1..*1
Authorisationprioritiesprivileges
start session()
OperationAttribute
AttributesOfClass
OperationOfClass1
1
1..* 1..*
Association Examples in UML
ClassDecl
Directory
15© Wolfgang Emmerich, 1999
Class Diagrams in UML
■ Class diagrams :• show logical, static structure of system• provide core of ‘unified model’
■ Generation of initial class diagram fromproblem domain object list• classes of objects• associations / attributes• generalization relationships
16© Wolfgang Emmerich, 1999
ReceiptTotal cansTotal bottlesTotal crates
Customer panel
Operator panel
CanWidthHeight
BottleNeckLengthBottom
CrateWidthHeightLength
Deposit ItemNameDeposit value$Daily total
A ‘Recycling Machine’ Class Diagram
17© Wolfgang Emmerich, 1999
Exploiting Use Cases
■ Employ classes and use cases, one by one,• to describe roles and responsibilities of each
class• to distribute behaviour specified in use cases• to ensure that there is a class for every behaviour
18© Wolfgang Emmerich, 1999
■ Interface classes - for everything concernedwith system interfaces
■ Entity classes - for persistent information andbehaviour coupled to it
■ Control classes - for functionality notnormally tied to other classes
■ Integrated into UML as stereotypes:
<< interface >>
interface name
<< entity >>
entity name
<< control >>
control name
Roles of Classes in OOSE
19© Wolfgang Emmerich, 1999
Receipt Receiver
CustomerOperator
Receipt Printer
Operator Panel
Alarm Device
Customer Panel
Interface Classes
■ Contain functionality directly dependant onsystem environment
■ Definitions focus on interaction betweenactors and use cases
20© Wolfgang Emmerich, 1999
Receipt Printer
Operator Panel
Alarm Device
CustomerPanel
<< interface >>
Customer Panel
<< interface >>
Crate slot
<< interface >>
Bottle slot
<< interface >>
Can slot
<< interface >>
Receipt button
Associations between Interface Classes
■ Definition of both dynamic■ and static associations
21© Wolfgang Emmerich, 1999
<< entity >>Deposit Item
Name: StringDeposit value: ECU$Daily total: Integer
<< entity >>Crate
<< entity >>Can
<< entity >>Bottle
Attributes of Entity Classes
■ Purposes of entityclasses :• To store information
persisting aftercompletion of a use case
• To define behaviour formanipulating thisinformation
22© Wolfgang Emmerich, 1999
Receipt Basis Deposit Item
Entity Communication
■ A primary task to identify associationsinvolving communication• modelling of communication between objects• shows the sending and receiving of messages as
stimuli• starts from object initiating communication• directed to object where reply generated or
operation executed
23© Wolfgang Emmerich, 1999
<< entity >>Deposit Item
Name: StringDeposit value: ECUDaily total: Integer
Create ()setValue (integer)Increment ()
Entity Operations
■ Defining entity operations for:• storing and fetching information• creating and removing object• behaviour that must change if
entity object is changed
24© Wolfgang Emmerich, 1999
extends
deposit item receiver
alarm device
information administrator
report generator
Control Classes
■ Control classes needed toprovide for:• behaviour not natural in
interface and entity classes• 'glue' between other classes
in use case• typical control behaviours• improved maintainability
25© Wolfgang Emmerich, 1999
1 0 .. n
Receipt printer
Customer Panel
Receipt Basis
Deposit Item Receiver
Deposit Item
Can Bottle Crate
Use Case View
■ Model each use case■ Describe use case in terms of classes
26© Wolfgang Emmerich, 1999
An elaborated Use Case
When the customer returns a deposit item the CustomerPanel’s sensors measure its dimensions. Thesemeasurements are sent to the control object Deposit ItemReceiver which checks via Deposit Item whether it isacceptable. If so, Receipt Basis increments the customertotal and the daily total is also incremented. If it is notaccepted, Deposit Item Receiver signals this back toCustomer Panel which signals NOT VALID.When the Customer presses the receipt button, CustomerPanel detects this and sends this message to Deposit ItemReceiver. Deposit Item Receiver first prints the date viaReceipt Printer and then asks Receipt Basis to go throughthe customer’s returned items and sum them. Thisinformation is sent back to Deposit Item Receiver whichasks Receipt Printer to print it out.
27© Wolfgang Emmerich, 1999
Packages
■ Packages are a way to decompose classdiagrams into manageable units
■ Packages are necessary:• because of large numbers of classes• to provide optional functionality• to minimise effect of change
28© Wolfgang Emmerich, 1999
Packages (Cont’d)
■ Packages should have a:• tight functional coupling inside• weak coupling outside indicated by 'dependency
associations’ between packages
■ Packages may:• ‘contain’ nested packages with ‘service packages’
as atomic parts• have individual classes outside• be result of organisational or managerial
pressures
29© Wolfgang Emmerich, 1999
Main
Recycling Machine Packages
Alarm
Deposit
Receipt printer
Administration
30© Wolfgang Emmerich, 1999
<< interface >>
Customer Panel
<< interface >>
Crate slot
<< interface >>
Bottle slot
<< interface >>
Can slot
<< interface >>
Receipt button
<< entity >>Receipt basis
<< control >>Deposit Item
Receiver
<< entity >>Crate
<< entity >>Can
<< entity >>Bottle
<< entity >>Deposit Item
Name: StringDeposit value: ECUDaily total: Integer
Create ()setValue (integer)Increment ()
Deposit
<< interface>>Receipt printer::Printer
<< control >>Alarm::Alarmist
‘Deposit’ Package in UML
31© Wolfgang Emmerich, 1999
Analysis Model
■ Outputs:• class roles [text]• use case description in terms of classes and
operations [text x use case]• completed analysis model classes [diagram]• sub-system diagrams [package diagram]
■ Notations introduced:• class, object, associations• (binary, unidirectional, aggregation,
generalisation)• stereotypes (classes, associations)• package (+ dependency association)
32© Wolfgang Emmerich, 1999
Analysis in OOSE - Summary
■ USER PERSECTIVE• Actors and Use Cases• Strong emphasis on requirements modelling• Resistence to effects of change
■ ADVANTAGES OVER OTHER METHODS• Ways to identify and define classes and objects• Effective and useful identification of roles of
classes• Recognition of user role (and interface)• Refined with practical use
33© Wolfgang Emmerich, 1999
Modelling Processes
34© Wolfgang Emmerich, 1999
Processes and Threads
■ Execution of a program is a process■ Concurrent programs consist of multiple
processes■ Threads are lightweight processes■ Both threads and processes can be modelled
in the same way■ We use finite state machines for that
35© Wolfgang Emmerich, 1999
Labelled Transition Systems
■ Special form of finite state machines■ Used to model states of concurrent programs
and transitions between them■ LTS:=(S,T,A,δ δ ,c) where
• S (a finite set of states)• T ⊆ S×S (a finite set of transitions)• A (an alphabet of atomic actions)• δ: T→ A (a transition labelling)• c∈S (the current state)
36© Wolfgang Emmerich, 1999
1 2 3 4 5
n States
0
0 Current State
Transitions
Graphic LTS Notation
think talk scratch
talk think
scratch
scratch
abc Labels
37© Wolfgang Emmerich, 1999
LTS Semantics
■ All actions that are annotations of transitionsstarting from the current state are enabled
■ If process engages in enabled action target oftransition becomes current state
■ In this way LTS determines all possible tracesof process
Demo
38© Wolfgang Emmerich, 1999
Finite State Processes (FSP)
■ LTS become unmanageable for large numberof states and transitions
■ Process algebras determine LTSs in a moreconcise way
■ Finite State Processes (FSP): machinereadable notation for a process algebra
■ For each FSP model an equivalent LTS can beconstructed automatically
39© Wolfgang Emmerich, 1999
FSP Intro: Action Prefix
■ Let x be an action and P a process. The actionprefix (x->P) is process that initially engagesin action x and then behaves in the same wayas process P
■ Used to model atomic actions■ Actions have lower case identifiers, states
have upper case identifiers■ Example: ONESHOT=(once->STOP).
■ Equivalent LTS:
0 1
once
40© Wolfgang Emmerich, 1999
FSP Intro: Recursion
■ Let P be a process. Then P may be used inaction prefixes in a recursive way.
■ Used to model repetitive behaviour■ Example: SWITCH=OFF.
OFF =(on->ON).ON =(off->OFF).
■ Equivalent LTS:
■ Note: Processes are equivalent to states
0 1
on
off
41© Wolfgang Emmerich, 1999
FSP Intro: Local Processes
■ It is not necessary for all states/processes tobe globally visible.
■ Restricting states/processes by use of ‘ , ’■ Example:
SWITCH=OFF,OFF=(on->ON),ON=(off->OFF).
■ OFF and ON are not visible outside SWITCH
■ Equivalent to:SWITCH=(on->off->SWITCH).
42© Wolfgang Emmerich, 1999
■ (x->P|y->Q) describes a choice thatengages either in x or y . After x it contin-ueswith P, after y it continues with Q
■ Example: DRINKS=(
red->tea->DRINKS | blue->coffee->DRINKS
).■ Equivalent LTS:
FSP Intro: Choice
0 1red
blue
2tea
coffee
43© Wolfgang Emmerich, 1999
FSP Intro: Indexes
■ A range type is a finite and scalar type:■ Example: range T=0..3
■ If T is a range type then x[i:T] is thedeclaration of an action index and P[i:T] isdeclares an indexed process .
■ A process index variable is valid within theprocess, an indexed action is valid within thescope of the choice.
44© Wolfgang Emmerich, 1999
range T=0..5
X=X[0],X[i:T]=(inc->X[i+1]).
45© Wolfgang Emmerich, 1999
FSP Intro: Index Example
const N =1range T =0..Nrange R =0..2*NSUM =(in[a:T][b:T]->OUT[a+b],OUT[s:R]=(out[s]->SUM).
■ Equivalent LTS:
0 1in.0.0
in.0.1
2out.0
out.1
3
in.1.0
in.1.1
out.2
46© Wolfgang Emmerich, 1999
FSP Intro: Guarded Actions
■ The guarded action when B x->P means thatwhen the guard B is true action x is enabledand the process proceeds as P.
■ Example:COUNT(N=3) =COUNT[0],COUNT[i:0..N]=(when(i<N) inc->COUNT[i+1] |when(i>0) dec->COUNT[i-1] ).
■ Equivalent LTS:
0 1inc
dec2
inc
dec3
inc
dec
47© Wolfgang Emmerich, 1999
Summary
■ Formal Definition of LTS■ Algebraic notation in FSP■ Equivalence between LTS and FSP■ FSP and LTS concepts introduced so far are
sufficient for sequential programs■ Next session: FSP constructs for modelling
concurrent programs
48© Wolfgang Emmerich, 1999
Modelling Concurrency in FSP
49© Wolfgang Emmerich, 1999
What do we have to model?
■ Relative or absolute speed?• Neither!
■ Concurrency or parallelism?• Interleaved model of concurrency!
■ Relative order of actions?• Arbitrary interleaving!
■ We use an asynchronous model of execution!
50© Wolfgang Emmerich, 1999
FSP: Parallel Composition
■ If P and Q are processes then (P||Q) denotesthe parallel execution of P and Q
■ || is used to model parallel composition ofprocesses
■ Names of concurrent processes arepreceeded by ||
■ Example:CONVERSE =(think->talk->STOP).
ITCH =(scratch->STOP).
||CONVERSE_ITCH =(ITCH || CONVERSE).
51© Wolfgang Emmerich, 1999
Equivalent LTSs
1,0 2,0 2,1 1,1 0,10,0
think talk scratch
talk think
scratch scratch
1 20
think talk
10scratch
ITCH=(scratch->STOP).
CONVERSE =(think->talk->STOP).
||CONVERSE_ITCH =(ITCH || CONVERSE).
52© Wolfgang Emmerich, 1999
Properties of Parallel Composition
■ Parallel composition operator has twoimportant algebraic properties
■ Commutativeness• (P||Q)=(Q||P)
• ordering is not important!
■ Associativeness• ((P||Q)||R)=(P||(Q||R))=(P||Q||R)
• brackets can be omitted!
53© Wolfgang Emmerich, 1999
FSP: Process Interactions
■ Concurrent processes that share actionsinteract with each other
■ Used to model synchronisation■ Example:
MAKER = (make->ready->MAKER).
USER = (ready->use->USER).
||MAKER_USER = (MAKER || USER).
■ Product has to be ready before it can be used.
54© Wolfgang Emmerich, 1999
Equivalent LTS
1 20
make ready make
use
3
MAKER = (make->ready->MAKER).USER = (ready->use->USER).||MAKER_USER = (MAKER || USER).
useDemo
55© Wolfgang Emmerich, 1999
Handshake
■ An action that is acknowledged by anotheraction is referred to as handshake
■ Widely used to structure process interactions■ Example:
MAKERv2=(make->ready->used->MAKERv2).USERv2 =(ready->use->used ->USERv2).||MAKER_USERv2 = (MAKERv2 || USERv2).
■ LTS:
1 20 make ready use3
used
56© Wolfgang Emmerich, 1999
FSP: Process Labelling
■ The process label a:P prefixes each label inthe alphabet of P with a
■ Avoids name clashes in different instanti-ations of processes and enables reuse.
■ Example:SWITCH = (on->off->SWITCH).||TWOSWITCH=(a:SWITCH||b:SWITCH).
■ Alphabet of ||TWOSWITCH:{a.on, a.off, b.on, b.off}
57© Wolfgang Emmerich, 1999
FSP: Process Labelling (cont’d).
■ The process label {a1,..,ax}::P replacesevery label n in the alphabet of P with labela1.n,…,ax.n .
■ Example:RESOURCE=(acquire->release->RESOURCE).USER = (acquire->use->release->USER).||RESOURCE_SHARE = (a:USER || b:USER || {a,b}::RESOURCE).
58© Wolfgang Emmerich, 1999
Equivalent LTSs
1 20a.acquire a.use
a.release
a:USER
10b.acquire
a.acquire
a.releaseb.release
{a,b}::RESOURCE
1 20a.acquire a.use
a.release
3 4
b.acquire
b.use
b.release
a:USER || b:USER || {a,b}::RESOURCE
59© Wolfgang Emmerich, 1999
FSP: Relabelling
■ Relabelling functions change names of actionlabels. The relabelling function is:/{new1/old1,… newn/oldn}.
■ Used to synchronise actions with differentnames in composite processes.
■ Example:CLIENT=(call->wait->continue->CLIENT).SERVER=(request->serve->reply->SERVER).||CLIENT_SERVER = (CLIENT || SERVER)
/{call/request, reply/wait } .
60© Wolfgang Emmerich, 1999
Equivalent LTSs
1 20call wait
continue
CLIENT=(call->wait->continue->CLIENT). 1 20
request serve
reply
SERVER=(request->serve->reply->SERVER).
1 20 call serve reply3
continue
||CLIENT_SERVER = (CLIENT || SERVER)/{call/request, reply/wait}.
61© Wolfgang Emmerich, 1999
FSP: Hiding
■ The hiding operator \{a1..ax} removesaction labels a1..ax from alphabet of P andhides them
■ Hidden actions are labelled tau
■ Hidden actions in different processes are notshared
■ Example:USER=(acquire->use->release->
USER)\{use}.
62© Wolfgang Emmerich, 1999
FSP: Interfaces
■ The interface operator @{a1..ax} hides allactions in the alphabet of P that do not occurin the set a1..ax .
■ Complementary to hiding■ Like hiding used to reduce complexity of
resulting LTS.■ Example:
USER = (acquire->use->release-> USER)@{acquire,release}.
63© Wolfgang Emmerich, 1999
FSP: Structure Diagrams
P cx
aProcess P withalphabet {a,c,x}
P
m
cx
Q bdx
cx
aParallel Composition
(P||Q)/{m/a,m/b,c/d}
T a U yx
SComposite Process
||S = (T||U)@{x,y}
64© Wolfgang Emmerich, 1999
Summary
■ Parallel Composition■ Process Interactions■ Process Labelling■ Process Relabelling■ Hiding / Interfaces■ Structure Diagrams■ Solve Exercises of tutorial sheet