PRED4

Specifikacija templejta
korisnicke funkcije: PRIMER

IME Isplata kesa
PRED- Sistem je besposlen

USLOVI
POST- Racun je zaduzen

USLOVI
POBUDNI Kartica ubacena ATM masinu

DOGADJAJ (novcani automat)
© Telelogic AB 2002
Specifikacija templejta korisnicke funkcije:
PRIMER
OSNOVNI PRAVAC 1. Korisnik ubacuje karticu

AKCIJE 2. Sistem trazi odgovarajuci PIN
3. Korisnik ubacuje PIN
4. Sistem salje upit za vrstu transakcije
5. Korisnik trazi isplatu kesa
6. Sistem pita za tip racuna
7. …
……
14. Sistem izbacuje karticu
Specifikacija templejta korisnicke funkcije:
PRIMER
ALTERNATIVAN NEPONOVLJIV
PRAVAC -ubacen neadekvatan PIN
AKCIJE
1. Korisnik ubacuje karticu
2. Sistem trazi PIN
3. Korisnik ubacuje PIN
4. Sistem prikazuje da je PIN
pogresan I izbacuje karticu
5. Sistem prijavljuje pokusaj tzv.
„ATM System Log“
Relacije: Asocija
• Crta se izmedju izvodzaca i korisnicke funkcije
• Predstavlja neusmerenu komunikaciju izmedju
izvodzaca i sistema
Relacija: Generalizacija
• Crta se izmedju dve korisnicke
funkcije ili izmedju dva izvodzaca
• Oznacava vezu specijalizovane korisne
funkcije/izvodzaca do uopstenije
Administrator User
korisnicke funkcije/izvodzaca
register user • Dete korisnicka funkcija/izvodzac
nasledjuje sve osobine i asocijacije
roditelja a moze imati nove osobine i
asocijacije u odnosu na roditelja, t.j.
register administrator
insertovanjem dodatnih sekvenca
akcije u roditeljsku sekvencu
Oznacava
‚specijalnu vrstu‘-
relacije
Association vs. Generalization
A A
B B
Oba izvodzaca, A i B Oba izvodzaca, A ILI

obavezno realizuju B obavezno realizuju
korisnicku funkciju korisnicku funkciju
Relationships: Dependency
• Crta se izmedju dve korisnicke
funkcije
• Oznacava semanticku relaciju
izmedju dve korisnicke
funkcije
• Funkcionisanje jednog ili vise
elemenata zahteva prisustvo
jednog ili vise drugih
elemenenata.
• Semantika se moze specificirati
koriscenjem stereotipova
Stereotipi (kategorije) (1)
• UML omogucava programeru da definise nov
simbol baziran na postojecem (t.j. “legalna”
ekstenzija UML-a)
• Oznacava se elementima, na primer, «extend»
• Ukljucuju osobine osnovnih simbola
• Uopsteno govoreci imaju razlicitu upotrebu od
osnovnih simbola, I cesto dodatna ogranicenja
• UML ukljucuje (oko 40) predefinisanih stereotipa
• Programeri koji kreiraju nove stereotipe moraju da
definisu njihovo znacenje i primenu
Stereotipi (2)
• Zavisnost je osnovni simbol
• Koristi se kako za korisnicke
funkcije tako i za ostale elemente
modelovanja
Samo za korisnicke funkcije imamo...
«extend» • «extend» stereotip se koristi da

modeluje opcionalno ponasanje
«include»
• «include» stereotip se koristi da
modeluje uobicajeno ponasanje
Relacije zavisnosti izmedju
korisnickih funkcija
«extend» prikazuje
opcionalno ATM System
ponasanje, koje se Withdraw

Foreign «extend» WithdrawCash
nekada izvrsava Currency
«include»
PrintReceipt
ATM System Log Customer
«include»
«include» opisuje
uobicajeno ponasanje, CheckBalance
koje se uvek izvrsava
Proces analize korisnickih funkcija
Iteracija
Izvodzaci Korisnicke funkcije Opis korisnickih funkcija
• Izvodzaci: Ime i opis

• Za svakog izvodzaca: Traziti korisnicku funkciju
pitajuci izvodzaca “Za sta bi hteo da koristis sistem?”
• Imenuj i opisi svaku korisnicku funkciju
Napomene modelovanje korisnickih
funkcija
 Budite sigurni da svaki slucaj opisuje znacajan deo koriscenja
sistema i da je razumljiv eksperima domena i programerima
 Kada se definisu korisnicke funkcije u tekstu, koristite imenice i
glagole na pravilan i konzistentan nacin da bi se pomoglo u
razvoju objekata i poruka za dijagram interakcija
 Factor out common usages that are required by multiple use cases
 If the usage is required use «include»
 If the base use case is complete and the usage may be optional,
consider use «extend»
 A use case diagram should
 contain only use cases at the same level of abstraction
 include only actors who are required
 Large numbers of use cases can be organized by hierarchies
Use Case Properties
Miscellaneous (Misc)
- Classification: - Primary
- Secondary
Actions (Act)
- Basic course of action
- Alternative courses of action
Conditions (Cond)
- Pre-conditions
- Post-conditions
Documentation (Doc)
- Description
- Triggering event
Actor Properties
Miscellaneous (Misc)
- Initiator
- Actor type
User
System
Documentation (Doc)
- Description
Use Case Dependency Property
Form
Miscellaneous
(Misc)
- Specify
association
stereotype
«extend»
«include»
Report on Use Cases
• To generate a report on use
cases
– From the browser, select
Reports, objects, Use
Cases…
– From the UCD editor, select
Reports, Use Cases...
Report Formatting Options
• Names may be entered
in two ways
– By typing the use case
name(s) in this field
– By selecting the use
cases on a UCD prior to
choosing the Report
option from the menu
Report Monitoring Window Option
Suggestions
• Options, Font
– Use a monospaced font, like
Courier
• Options, Output Width
– Set to 132
• Options, Clear Screen
– Set to off
• Options, Reuse
– Set to on
Checking a Use Case Diagram
• Invoked from the use case diagram editor or from the the UML Suite
browser
• Check Contents checks the semantics of the selected diagram
– Checking rules:
• A UCD actor must participate in at least one use case.
• An initiating actor must send an event.
• Check Use Case Model checks one or more selected use case
diagrams
– Checking rules:
• Each use case must have only one initiating actor
• Each use case must have a decomposition or a qualifying
sequence diagram
Exercise 1 & 2
• Goal: Create a project hierarchy
• Goal: Create a requirements model
– Create a use case diagram
Review Questions
• What is a use case?

• What is an actor?
• What is an association on a use case diagram?
• When is the «extend» relationship used?
• When is the «include» relationship used?
• When is generalization used?
Use Case Analysis Process
Iterate
Seek
Actors Seek Use Cases Describe the Use Cases
How d
oe s UML
help m
e he r
e?
Analysis Phase
Analyzing the Use Cases
Using Activity Diagrams
• Analyzing and organizing use case
scenarios
• Modeling business workflow (e.g., the picture
of the analysis process used in this course)
• Documenting procedural steps of a single
operation
Activity Diagrams
• Introduction
• UML activity diagram: concepts and
notation
• Drawing activity diagram with the UML
Suite
• Diagram navigation
• Reporting and checking
Base Elements
• Start State s ta te
St art
– Begins the sequence of activities
– At most one
Take order
• Action State st a te
Act ion
– Represent an activity
• Final State
– End the sequence of activities s ta te
Final
– Can appear many times
Activity Diagram: A Development Process
These activities are

carried out in parallel,
however, they don‘t know
each other, so explicit
synchronization has to be
forced!
Action/Activity State
• Each state in an activity diagrams is either
– an action state
Action
• atomic, no substructure
• executes “instantaneously”
• can not be interrupted
• runs to completion and transitions out
– or an activity state Activity
• not atomic, has a substructure
• executes a nested activity graph
• is a “hierarchical action”
Transistions in Activity Diagrams
 Just like their state machine counterparts (simple

state and submachine state) except that ...
 ... transitions coming out of them are taken when the

step is finished, rather than being triggered by an
external event, ...
Activity – Run to Completion Semantics
buy parts return to work
This activity has a

This activity is atomic: substructure
it runs to completion
and transitions out!
return to work
buy parts visit return to

pub office
Decision
• A single event trigger leads to more than
one possible outcome
– each has its own guard condition
[product in stock]
[else]
se rved
i s a re
”
“else word
Object Flow and Object-in-State
fl o w-
ct
Obje ty state
i t
activ to objec
Take order
ut puts
o
n- st ate Order
je ct -i [entered]
Ob
fl o w-
b j e ct ides
O o v Order
j e c t pr ivity Allocate stock
ob to ac t [planned]
input
Convenience Features
 Partitions are a grouping mechanism.
 “Swimlanes” are the notation for partitions.
 They do not provide domain-specific semantics.
 Used to show allocation of responsibility for the
activities to business units, use cases, classes
Management
Evaluate Revise
Impact Plan
[ priority = 1]
Support
Register Release
Bug Fix
Engineering
Fix Test
Bug Fix
Convenience Features
 Signal send icon

Wake Up
Signal
… translates to a transition with a Turn on Coffee Pot

send action.
 Signal receipt icon Get Cups Coffee

Pot
Signal
Coffee Done
… translates to a wait state (a state
with no action and a signal trigger
event).
Drink Coffee
Diagram Navigation from a Use
Case
d na me
u al if ie
q
Double-click the Use Case to navigate
Creating an Activity Diagram
• Create from
– Use case
– Class
– Statechart event
or activity
• Or File, New,
Activity Diagram
Adding Swimlanes
1. Click on the partition symbol
2. Click on the diagram to place the partition
3. Resize the partition as desired
4. Click on the swimlane symbol or
5. Click within the partition to place the swimlane
Diagram Navigation Double-
Clicking on...
An operation (shown as signal receipt) “Print” of class CreateReport
 Creates an AD called
Create Report:Print.
Creates an STD
called Create
Report:Print.
Object-in-state “Order”
 Create an AD, CD or
SD called Order.
Create an STD called
Order:top.
Reports
• Report on Activities
shows:
– Action/activity state
names
– Transitions
(optional)
– Object flows
(optional)
– Connected notes
(optional)
Checking Activity diagrams
• Transitions:
– Each decision must have at least one incoming transition
– Each decision must have at least two outgoing transitions with a
distinct guard condition
– Action state must have at least one outgoing transition and one
incoming transition
– Transitions originating from an action state or decision must not
have an event
– Each signal receipt may not have more than one incoming object
flow
– Each signal send may not have more than one outgoing object
flow
• Names
– All action states must have an entry action
– All signal sends and receipts must have an event label
Why do Activity Diagrams help
me analyze Use Cases?
• The “run-to-completion” semantics helps to
– describe a Use Case as a sequence of exclusive
activities
– define pre- and post-conditions for every Use
Case
– identify common behavior of Use Cases
– restructure the Use Case diagram to realize an
“orthogonal decomposition” of the functional
requirements
Exercise 3
• Goal: Analyze a use case
– Describe different scenarios
– Create an activity diagram for a use case
Review Questions
• Name two uses of an activity diagram
• What is the difference between an action
state and an activity state?
• How are transitions triggered?
Functional Analysis: Summary
Build a Use Case diagram containing ...
– use cases, together with their textual specification (and
maybe analysed with activity diagrams) and
– actors, together with their textual descriptions.
-----------------
-----------------
-----------------
----------------
Insert New
Element In List
List is Full Error Handling
Else
End of List Return List
Else
Next Element Else

In List
New Element > List[i]
Swap Element
Requirements Analysis Process
Functional Builds Use Case

Analysis Model
Iterate Explains
Problem Domain
Object-Oriented Builds
Model
Analysis
(Concept Classes)
Analysis Phase
Finding Concept Classes
When to use Problem Domain
Modeling?
• Starting a project from scratch
• The requirements specification exists only in a very
vague form
• No predefined logical architecture available
• Facilitate the slide-over from a functional analysis to
the object-oriented analysis
The problem domain model
The problem domain model is used to explain
the concepts defined in the Use Case model.
How to do that?
• Find and define entities that have a direct counterpart
in the application environment and the system must
know about. These entities are used for realizing the
Use Cases.
So, what are these entities?
Entities
are the basis of the
object-oriented paradigm!
Now on sale!
Object-oriented
toasters!
„Object-orientation“ is certainly one of

the most foozled words today.
But that doesn‘t change the fact that it is

still the most promising technique in the
realm of modern software development.
Object-Oriented Concepts and
Textbook definition: Terms
A language is called object-oriented if …
it provides support for encapsulation

it provides the mechanism of inheritance and
aggregation
it supports polymorphism
Object-Oriented Concepts and
Terms
To model a system in an object-oriented way means to
model it as a set of
real-world “entities”
(small bundles of data and functions) responding to
and exchanging messages
The entities are called objects

The data are called attributes
The functions are called operations
Classes and objects
A class is an abstract descriptor for a set of objects that
share the same definitions of attributes, operations, and
relationships.
An object has no other properties than those defined in

the class.
Four objects of
the class tree!
Class & Object symbols
Here are
some objects
of the class
Pump
Pump1: Pump Pump2: Pump Pump3: Pump

State=Stopped State=Reversed State=Forward
Objects are instances of a class
Pump Pump Name

Unfolded and State
Attributes (Data)
folded class
symbol. Start(Direction)
Stop Operations
Object-Oriented Concepts and Terms
The change of paradigm (compared to structural

programming) shows up when looking at the following
question:
OO asks: ‚Would you (object) be so kind to do something for

me?‘
So, the key technique is ...

to distribute responsibility upon objects and
to organize their communication!
To do so one needs to describe

structure and relationsships
between objects
Static Structural Diagrams
 Show a graph of classifier elements connected by
static relationships.
 UML provides different kinds

 class diagram: classifier view
 object diagram: instance view
Class Diagrams vs. Object Diagrams
Both are static structural diagrams, i.e. graphs of

classifier elements connected by static relationships.
 A class diagram shows all possible relations that

may exit between its instances at run-time!
 An object diagram shows the structure of a specific

scenario (a snap shot!)
Carbon Chemistry: Classifier
View
Element
C
1
«covalent» 2..4
Carbon Hydrogen
0..2 C H
1 C
«covalent»
Carbon Chemistry: Instance
View
:H y d ro g e n :H y d ro g e n
:H y d ro g e n :C a rb o n :C a rb o n :H y d ro g e n
:H y d ro g e n :H y d ro g e n
Class Diagram:• Association
*
Associations are drawn
1
Car owns Person between classes, not objects
Owner
1 • It means that objects of these
classes are related with each
1
other in some interesting way
insures Insurance that we want to model.
• Name the association and
Multiplicity: show with an arrow how it
•1: Exactly one. should be read:
•1..3: One to three – ”a person owns zero to many
cars”
•1,5: One or five
• Alternatively you can name
•*: Zero to many roles at the association ends:
•[nothing]: – ”Owner”
unspecified
Notes
1 0..1 CarePlan
Patient
: t h is
Note ote
No care plan exists when a
is a n
patient is initially admitted for
emergency care.
• Notes may be used to annotate elements

Class Diagram: Aggregation
Car Whole • This is a stronger relation than
association
• It shall be possible to read the
4 1 2..5 relation:
Wheel Engine Door – “Whole consists of parts” or
Parts
– ”Whole contains parts”,
– ”Whole is a collection of
parts”
Reflects a
‚is a part of‘-
relationship
Class Diagram: Composition
 A whole is responsible for the creation and destruction of its parts
 A part can belong to only one whole at a time
 When a whole is destroyed, its parts must cease to exist as well
 It’s a strong form of aggregation
Window
* 1 1
Scrollbar Header Panel

Class Diagram: Generalization
Figure
 Implies that a (specialised) class
inherits the properties of an other
Position (general) class.
Draw
 Is a relation between classes, not
Move objects.
 It shall be possible to say:
”A Rectangle is a special kind
of figure”
Rectangle Circle
 Everything is inherited including
associations
Height Radius
Width
 You can only add operations,
Draw attributes and relations
Draw  Operations can be redefined
 Multiple inheritance is allowed but
rare in the problem domain model.
The Problem Domain Model
The problem domain model provides a classifier

view consisting of classes of objects outside the
system and on the system border. It describes
these classes and the static relations between
them.
How to build a Problem Domain
Model?
•Extract classes from Use Cases Iterate over finding,
– Actors specifying and relating
classes until it feels stable.
– Interface classes (keyboard, sensors, Wait with writing the
actuators …) specifications for the
– Information passing the system border classes until the class
diagram is stable.
•Specify the classes Remember: In the problem
– Name domain model, you are
– Important attributes modelling concepts in the
real world, not software
– Simple description of what it
classes. Not all domain
represents classes represent visible
– Possibly some important operations objects
•Relate the classes
– Avoid redundant relations
– Use inheritance to model common
attributes and relations
Example: Access Control System
Employee Access Control System
OpenDoor RegisterUserCard
Door Administrator
RegisterAdminCard
UnRegisterUserCard
Database
Is this a sound
problem
domain model?
1
Card
has
1 Door
-CardId
* *
«actor» may pass through
Employee
+Open
1 +Close
1
1
Code has 1 1 1
1 KeyPad CardReader Display Text
1 1
shows
4
+keyStroke(Key) +EnterCard(aCard) +Display(Text) +Show
Key +RemoveCard()
1
-Value
0..20
Character
-ASCII_Code
+Show
Surely getting down to level of Character and Key is wildly overenthusiastic!
One should rule them out as anything but attributes because
(a) they are fully contained, with existence dependence and
(b) have value but do not represent objects that have identity!
1
Card
has
1 Door
-CardId
* *
Employee
+Open
1 +Close

1
1
Code has 1 1 1

1 KeyPad CardReader Display Text
1 1
shows
4

+keyStroke(Key) +EnterCard(aCard) +Display(Text) +Show
Key +RemoveCard()
1
-Value
0..20

Character
-ASCII_Code
+Show
1
Card
has
1 Door
-CardId
-Code * *
Employee
+Open
+Close
1 1 1
Keypad CardReader Display
-Key -Text
+keyStroke(Key) +EnterCard(aCard) +Display(Text)

+RemoveCard()
If Employee is shown as actor,

why isn’t Door?
Where are the other actors?
1
Card
has
1 «actor»
-CardId
-Code * * Door
Employee
+Open
+Close
What’s with this «actor»(s) who 1
participates in relationships?
1 1 1
Keypad CardReader Display

Come on, either it’s an actor and -Key -Text
is a black box,
box or it’s not! +keyStroke(Key) +EnterCard(aCard) +Display(Text)
+RemoveCard()
Also, those classes are surely not part of

Door: They are part of AccessControlUnit
or some such. Doors generally do not have
keypads: An AccessControlUnit might.
«actor» «actor»
Administrator Employee
* *
*
*
Give *
This looks
* Read Press
Press
Give Read
like a
* * * * * *
CardReader KeyPad Display

*
Key Text
sound
1
EnterCard(aCard) KeyStroke(Key) Display(Text) concept
Card RemoveCard()
1 1
cardId 1
code
ShowsMessages
1 1 1
«actor» AccessControlUnit «actor»

Database 1 1 1 1 Door
QueryAndUpdate Opens
Card(CardData)
KeyStroke(Key) Open
Close
The control system made in SDL

UML Suite <class
Tool Tip:
name>
Tabbing
<attribute>
<operation>
Use TAB to move around the three

compartments
<multiplicity> <association name> <multiplicity>

<role name> <role name>
Use TAB to move around the five adornment positions

Setting Default Multiplicity
1
These buttons on When a new …the default

the palette association is multiplicity
specify the drawn... appears
default
multiplicity
Exercise 4
• Goal: The problem domain model
– Find/identify classes participating
Requirements Analysis Process
Start Project
{n=0}
{n=0}
Use Case Analysis
How can UML

help me here?
Use Case Model
[n. iteration]
Problem Domain Analysis
Repeat Use Case Model Problem Domain Model

Use Case Analysis Refine
[n. iteration] [n. iteration] Problem Domain Model
[Inconsistency in Requirements Explain Use Case Model

detected]/
{n=n+1}
[Missing Use Case scenarios

detected]/
{n=n+1}
[Requirements model stable]

Requirements Analysis with
• Sequence Diagrams
Perform the translation of requirements to
system/object responsibilities
• Organize necessary communication between
objects via messages, which is the only way
objects can interact
• Describe a selected use case with one or more
Sequence Diagrams
Example Diagram (1)
WithdrawCash:BasicCourse
am is
:Controller :AccountList d i ag r
en c e
S equ e d as
Customer
na m o u r se>
a s e> : <c
c
<use
card
prompt for PIN
PIN
validate PIN
PIN valid
select transaction
type
Example Diagram (2):
Withdraw Cash:InvalidPIN
:Controller :AccountList
Customer ATM System log
Card
Prompt for PIN
PIN
Validate PIN
PIN invalid
Log invalid PIN

PIN invalid
Card
Initiator (Actor)
c to r)
tor (A
Initia
Security
Officer
reportSituation
ss ag e
Me
situationReport
f el i ne
to r li
A c
Objects
m o us c t o f
no n y Ob je cl ass
b j ect A
t n o wn
O c un k
obje
Smith:Patient :Patient Smith
fel i ne
e ect l i
Activ O b j
t
objec
Name syntax: <objectname>:<classname>

t -b o x
ec
Object Creation a r ro w t o o b
a
j
t i o n
ss ag e ct c re
Me tes obje
a
indic
registerCarePlan
:CarePlan
updateCarePlan f e l i n e
to li
a rr o w s ts
ag e t ex i
Me s s bj e c v e s
tes o a r r i
d i ca ss a g e
in me
ef o re
b
Object Destruction
a ft er
:Controller
n u i n g tes
on ti i ca
li n e c e s i nd
Life ge arriv
a ts
mess still exis
t
objec
:Controller
ct i o n
d es tru t m ay n
l i c i t d o u c ti o
Exp i n a n de stru
a g es p l i ci t
s
Mes pany ex
acc o m
:Controller
Messages
:Controller
ro n ou s
h
sync
f ine d
unde e turn
r
:Controller
no us
c hr o
asyn
Example: Different Arrows
Nested Flow Flat Flow Asynchronous Flow

:teller :Order :Article :caller :exchge :callee :appl :errhdl :alarm
lift receiver
getValue dial tone unknown
price alarm
dial digit
dial digit
getName ringing tone ringing signal
lift receiver
Message Syntax
d s age ts
guar ion me s me n
it argu
co n d name
:Hospital
[registered] Admit (patientID, room)

In-Scope Region (Focus of
Control)
The period of time when
:Controller
the object is executing and/or
waiting for a return message
e g ion
o p e r on )
c g i
In-s ation re
v
(acti
Branching
:Controller :Controller
reportEvent [door open] reportEvent
reportPerson [code entered] reportPerson
io n a l
o p t u s ive
n s are y e x cl
n d i tio u tu all e n c y)
r d c o b e m c u r r
gua n o t c o n
n e e d s h o w
an d m a y
t h e y
( e. g.
Timing Marks and Constraints
m ark
g
timin :Caller :Exchange :Callee
a lift receiver
{b - a < 1 sec}
b dial tone
{c - b < 10 sec}
This call is c dial number
str a int routed through

co n
d route
the network d'
{d' - d < 5 sec} ringing phone phone rings
script e answer phone
{f - e < 1 sec}
At this point stop tone stop ringing f
the parties
can talk
Adding Timing Marks and
•Timing marks
Constraints
 Timing constraints
– Select message to be marked  Click timing constraint symbol
– Tab to desired position  Click desired position in diagram
– Enter timing mark  Enter “{“, constraint expression, “}”
v ig a te
y to na arks
a b ke i ng m
T m
Use d the ti ame
n n
arou essage
m
and
Modeling Loops with Sequence
• There are no quidelines given in the UML standard document,
diagrams?
however one could use this:
Loop modelling in sequence diagrams:
MyObject1 calls MyObject2.findout() with i as input
and will do so within the MyObject1.findresult() scope
until it gets the results it desires
MyObject1:class MyObject2:class
findout(i)
findresults(until results match input)
results
Analyzing Use Cases with Sequence
Diagrams: Extend-relation
B «extend» A
Include specialized and optional behavior at a specific location

Diagrams: Include-relation
B «include» A
include A
Include necessary behavior at a specific position

Diagrams: Generalization
B A
Overwrite/use or extend behavior of the super Use Case

Connection between Class
Diagram and Sequence Diagram Motor Controller
Classes 2 1
start() getStatus()
Objects LeftMotor:Motor RightMotor:Motor MainController:Controller
start()
start()
getStatus()
getStatus()
Object Stereotypes
• Entity object
– Generally passive; often
persistent
• Control object
– Manages interactions
between objects; usually
controls sequencing for one
use case
• Boundary object
– Insulates the rest of the
system from actors; usually
at least one boundary object
per actor-use case pair
Assigning a stereotype to
an object is optional
Diagram Navigation from a
Sequence Diagram
Double-click an Object to navigate

Navigation is from the object’s class,
not from the object itself.
Reports on Sequence Diagrams
 Invoke from sequence
diagram or the UML
Suite browser
Check Sequence Diagram
• Check Contents checks selected diagram contents
only without checking its consistency with other
diagrams
– Sample rules
• An SD message must have a valid name
• There must be only one initiator
• Check Local Model performs consistency check on
classes and events referenced in the selected
diagram(s)
• Check Global Model performs consistency check on
all classes and events on all diagrams
Model interactions with sequence
diagrams
Step 1: Select a use case
Step 2: Select course of action to be modeled
(basic or an alternative)
Step 3: Invent/identify objects participating
Step 4: Connect objects with messages that
fulfill/represent the responsibilities of the
use case

PRED4

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

PRED4

Uploaded by

Copyright:

Available Formats

Specifikacija templejta

korisnicke funkcije: PRIMER

PRED- Sistem je besposlen

POST- Racun je zaduzen

POBUDNI Kartica ubacena ATM masinu

OSNOVNI PRAVAC 1. Korisnik ubacuje karticu

Oba izvodzaca, A i B Oba izvodzaca, A ILI

«extend» • «extend» stereotip se koristi da

ponasanje, koje se Withdraw

ATM System Log Customer

koje se uvek izvrsava

Izvodzaci Korisnicke funkcije Opis korisnickih funkcija

• Izvodzaci: Ime i opis

Reports, Use Cases...

• What is a use case?

These activities are

 Just like their state machine counterparts (simple

 ... transitions coming out of them are taken when the

buy parts return to work

This activity has a

buy parts visit return to

 Signal send icon

… translates to a transition with a Turn on Coffee Pot

 Signal receipt icon Get Cups Coffee

Double-click the Use Case to navigate

2. Click on the diagram to place the partition

3. Resize the partition as desired

4. Click on the swimlane symbol or

5. Click within the partition to place the swimlane

List is Full Error Handling

End of List Return List

Next Element Else

New Element > List[i]

Functional Builds Use Case

„Object-orientation“ is certainly one of

But that doesn‘t change the fact that it is

it provides support for encapsulation

The entities are called objects

An object has no other properties than those defined in

Pump1: Pump Pump2: Pump Pump3: Pump

Objects are instances of a class

Pump Pump Name

The change of paradigm (compared to structural

OO asks: ‚Would you (object) be so kind to do something for

So, the key technique is ...

To do so one needs to describe

 UML provides different kinds

Both are static structural diagrams, i.e. graphs of

 A class diagram shows all possible relations that

 An object diagram shows the structure of a specific

• Notes may be used to annotate elements

Scrollbar Header Panel

The problem domain model provides a classifier

Employee Access Control System

Keypad CardReader Display

+keyStroke(Key) +EnterCard(aCard) +Display(Text)

If Employee is shown as actor,

What’s with this «actor»(s) who 1

Keypad CardReader Display

Also, those classes are surely not part of

CardReader KeyPad Display

«actor» AccessControlUnit «actor»

The control system made in SDL

Use TAB to move around the three