UML

advertisement
The Unified Modelling
Language
Introduction
1
Overview
• Session One
• Session Two
• Lecture
• Lecture
– An introduction to the
UML
– Bank account case study
• Tutorial
– Practical Exercise
• Post Session
– Reading
– UML for real-time systems
– Traffic Light Case Study
– Other bits of UML
• Tutorial
– Practical Exercise (assessed)
• Post Session
– Reading on further examples
(2PC and transaction
processing).
2
Session One
3
Aims of Session One
• Aims:
– Provide an overview of the main components of
UML
• Use Cases, Class Diagrams, Interaction
Diagrams, Activity Diagrams and State Charts
• CRC cards will also be mentioned as a useful
technique
– Cover basics of object-oriented concepts and
terminology
• Encapsulation, Inheritance and Polymorphism
4
Managing Complexity
• System development is hampered by the
complexity
• Software and hardware engineering has
developed techniques to manage this
complexity
• These depend on hiding detail not essential
to the task in hand
• Such an approach is known as abstraction
5
About the UML
• The Unified Modelling Language (UML) is an industry
standard for object oriented design notation,
supported by the Object Management Group (OMG).
• It is becoming widely adopted in many areas of the
software and computer systems development
community.
Some references included
in slides at end of notes
6
Key Diagrams in UML
Requirements
Capture
Use Case Diagram
System
Structure
Class Diagram
System
Behaviour
Interaction Diagrams
Activity Diagrams
State Charts
(+ CRC cards)
7
Activity
Take a couple of minutes to read through the introductory Bank
Account case study on the following two slides.
The aim is to try and pull out the key things which
we might want to represent in a model of the Bank as
described.
– Focus on requirements
– Could also look for candidate classes and methods
– Think how you would most naturally express these requirements
(written list, diagram etc.)
8
Introductory Case Study
The Bank Account
You are asked to design a system to handle current and
savings accounts for a bank. Accounts are assigned to
one or more customers, who may make deposits or
withdraw money. Each type of account earns interest on
the current balance held in it. Current accounts may
have negative balances (overdrafts) and then interest is
deducted. Rates of interest are different for each type of
account. On a savings account, there is a maximum
amount that can be withdrawn in one transaction.
9
Introductory Case Study
The Bank Account
Bank employees may check any account that is held at
their branch. They are responsible for invoking the
addition of interest and for issuing statements at the
correct times.
A money transfer is a short lived record of an amount
which has been debited from one account and has to
be credited to another. A customer may create such a
transfer from their account to any other. Transfers
within a branch happen immediately, while those
between branches take three days.
10
The Bank Case Study
Use Case Diagram
Examine and capture requirements
Class Diagram
Start to examine system structure
Activity Diagram
Illustrate dependencies in system
Interaction Diagrams
Express system dynamics
11
Use Case Modelling
12
Use Case model of the bank
deposit
withdraw
aCustomer
transfer
statement
This is one
possibility
teller
add
interest
13
Actors
• An actor indicates an external person or system
which is involved in a use case
• The same person or system may play the role of
more than one actor, depending on the context
• An actor may be a set of roles, which are related
• An actor may be involved in more than one use case
• One actor is normally the initiator of each use case
14
Use Cases
• The use case symbol indicates an activity
which will supply value to an actor
• Within each use case there must be a
description of what this activity does for the
actor
• Use cases can be described by
–
–
–
–
English descriptions - active voice, present tense
State charts
Activity diagrams
Any other means as preferred
15
Activity
Take a minute to read through the following use case
description.
The example concerns making a Deposit.
16
Use Case Description - Deposit
The customer passes over to the bank an amount of
money, in some combination of cash and cheques. The
customer specifies which account is to be updated. The
teller checks the money and authorises the updating of
the relevant account.
If the money is incorrect or the account does not exist
the teller informs the customer, returns the money and
the account is not updated.
17
Notes On The Description
• The customer is the actor that initiates the deposit.
• The inputs to the use case are identified.
• The outcomes are identified.
• Two exceptions are identified and the alternative
outcomes are given.
• The use case is adequate for the users to agree
that it is accurate, without becoming a design.
18
Class Modelling
19
Classes and Objects
• An object is a means of partitioning the
solution to a design problem.
• Objects are similar to modules in some ways.
Object = Identity +State +Behaviour
• Objects provide encapsulation of data.
• An object is described by a class. A class
may define a number of objects with identical
properties.
20
What’s In An Object
• An object has a public interface defining the
operations it will support.
Often termed
methods
• An object has private data, attributes, which
only its own operations can access.
• An object can have private operations, for its
own use.
• An object may know about other objects via
associations.
So, how do we identify objects?
21
Identifying Objects
• A simple recipe
– Step 1: We can identify objects in our problem
statement by looking for nouns and noun
phrases.
– Step 2: Each of these can be underlined and
becomes a candidate for an object in our solution.
– Step 3: We can eliminate some objects by some
simple rules.
• We must make sure that our objects fit in
with our use cases.
22
Activity
Take a couple of minutes to read through the case study
description of the Bank Account introduced in the previous
lecture.
The aim is to have a go at identifying what you think may
be candidate classes and objects based on the approach
identified on the previous slide - i.e. identification of nouns
and noun phrases.
23
Nouns in the bank account example
You are asked to design a system to handle current and savings accounts for a
bank. Accounts are assigned to one or more customers, who may make deposits or
withdraw money. Each type of account earns interest on the current balance held in
it. Current accounts may have negative balances (overdrafts) and then interest is
deducted. Rates of interest are different for each type of account. On a savings
account, there is a maximum amount that can be withdrawn in one transaction.
Bank employees may check any account that is held at their branch. They are
responsible for invoking the addition of interest and for issuing statements at the
correct times.
A money transfer is a short lived record of an amount which has been debited from
one account and has to be credited to another. A customer may create such a
transfer from their account to any other. Transfers within a branch happen
immediately, while those between branches take three days.
24
Nouns in the bank account example
You are asked to design a system to handle current and savings accounts for a
bank. Accounts are assigned to one or more customers, who may make deposits or
withdraw money. Each type of account earns interest on the current balance held in
it. Current accounts may have negative balances (overdrafts) and then interest is
deducted. Rates of interest are different for each type of account. On a savings
account, there is a maximum amount that can be withdrawn in one transaction.
Bank employees may check any account that is held at their branch. They are
responsible for invoking the addition of interest and for issuing statements at the
correct times.
A money transfer is a short lived record of an amount which has been debited from
one account and has to be credited to another. A customer may create such a
transfer from their account to any other. Transfers within a branch happen
immediately, while those between branches take three days.
25
Rules for rejecting nouns
1. Redundant - overdraft, account
2. Vague - amount, money
3. An event or an operation - transaction, deposit
4. Outside scope of system - bank, days
5. Meta-language - transaction, correct times, record
6. An attribute - interest, rate of interest, maximum
amount, current balance, overdraft
26
Nouns Left
• current account
• savings account
• customer
• branch
Now we need to consider
some graphical way of
expressing our class model
• statement
• transfer
27
Class Diagram
1
Customer
Associations
between
classes
1
withdraws and deposits money with
withdraws and deposits money with
1
1
Branch
holds
holds
0..*
0..*
0..*
Current
account
0..*
moves money to
1
1
Savings
account
moves money to
Transfer
1
1
1
1
summarises
summarises
Statement
1
1
28
Class Diagram
withdraws and deposits money with
1
Customer
1
Showing class
details
withdraws and deposits money with
0..*
Current
Account
1
0..*
1
Branch
holds
holds
0..*
0..*
-balance : real
moves money to
+withdraw(a:Real)
+deposit(a:Real)
+curBal():Real
1
moves money to
Transfer
1
1
1
Savings
Account
1
1
Statement
summarises 1
summarises
1
29
Navigability
• Open arrow heads on the associations show
navigability
• This indicates which object needs to know about
which other object to make an association work
• We try to keep navigability one way to reduce
coupling
• Where no navigability is shown this can mean two
way or not yet defined - be consistent
30
Inheritance
• One obvious cause of additional costs and difficulties
of maintenance is duplication of functionality
• Large, unstructured systems often contain large
amounts of code performing the same tasks
• In structured methods modules and libraries of
standard functions are used to reduce this
• Classes allow us to define a type of object once and
duplicate it as needed in our programs
31
Generalisation and Specialisation
• We can go further than classes which define identical
objects in one place
• We often find that objects are very similar without
being identical
• The parts of different classes which are the same can
be factored out as a generalisation of all of them
• The differences can be added to this to form a family
of specialisations
generalisation
employee
specialisations
developer
analyst
manager
32
Specialisations
generalisation
*or* parent class
*or* super-class
employee
specialisation
*or* child class
*or* sub-class
developer
analyst
manager
• Specialisations may have additional
attributes and/or operations
• Specialisations may have different
implementations for operations
– In this case we show everything in the super-class
and repeat the different operations in the subclasses
33
Polymorphism
• A specialisation may also redefine operations
which were implemented in its parent.
employee
printDetails()
developer
analyst
manager
printDetails()
printDetails()
printDetails()
printDetails(int x)
Also referred to
as overloading
of methods where
can have same method
name but different
signatures
34
Class Diagram using Specialisation
1
Customer
0..*
Account
0..*
1
1
holds
1
Branch
moves money to
Transfer
Current
Account
1
Savings
Account
summarises
Statement
1
35
An Example
Account
{abstract}
-balance : Real
-rate : Real
+withdraw(a:Real)
+deposit(a:Real)
+curBal():Real
CurrentAccount
SavingsAccount
-chequeNo : Integer
+withdraw(a:Real)
+withdraw(a:Real)
+newBook()
36
Interfaces
• Since we are only allowed to see the
operations of a class, two classes with the
same operations should be interchangeable.
• This gives us the most abstract view of an
object - its interface.
• If someone else is developing the class from
which some of our objects are derived, all
they have is the interface.
• We can still build our part of the system.
37
Interfaces In UML
Exchange
Exchange
<<interface>>
Transfer
move cash
Account
<<uses>>
move cash
Transfer
<<interface>>
Transfer
Account
38
CRC Cards
39
Linking Classes and Use Cases
• Each use case will be carried out in terms of
actors and objects.
• Objects are based on classes.
• Actors and objects send and receive
messages.
• Messages invoke operations.
• An operation may send messages to invoke
further operations.
40
Interactions and Scenarios
• A sequence of messages, possibly including
alternatives, is called an interaction
• Each separate alternative for an interaction is
called a scenario
• A use case will be implemented by a set of
scenarios, making up all the outcomes of an
initial message from the initiating actor
• The objects in the system must support all
the operations required by all the use cases
41
CRC Cards to Explore Use Cases
• Class, Collaboration, Responsibility cards
are a method of exploring how well a class
model supports use cases (Wirfs-Brock).
• There is a card for each class.
• Each card has the name, the responsibilities
and the collaborators of that class.
• They are used to role play the design and
check if it is complete.
42
CRC Card for Current Account
Current Account
Maintains an account’s balance.
Class name
Transfer
Allows transfers.
Statement
Accumulates interest.
Responsibilities
Collaborators
43
Playing the CRC cards
• Draw up a card for each class.
• Allocate cards to people in the design team.
• Each person acts out their role, starting with
the invocation of the use case.
• A card takes responsibility for its job in the
interaction or passes responsibility to a
collaborator.
44
Modelling Interactions
using
Interaction Diagrams
Activity Diagrams
State Charts
45
Showing Interactions
• Importance of exploring interactions
• We particularly want to develop scenarios and check
them.
• Key phrase to focus on
– “Scenarios of usage”
• Showing how static structure support dynamic
behaviour
46
Sequence Diagrams
show sequences of messages with the
emphasis on the order in which they are
sent
47
Sequence for a successful deposit
:aCustomer
:Teller
c:Customer
ac1:Account
b:Branch
deposit(v,a,name)
c:= getRec(name)
ac1 := getAcc(a,c)
addToBalance(v)
48
Messages
• May be numbered and nested
• Parameters may be passed
• Values may be returned using
assignment :=
Synchronous (procedure)
Flat (thread)
Asynchronous (concurrent)
Return from synchronous
[v<30]
• Messages may be conditional use of guards (expression in
square brackets)
Guard
*[x>10] Iteration
*
• Sub-sequences may be
enclosed in a box - helpful?
v=getval()
• Messages or sub-sequences
may be repeated *
[v>0]
Repeated
sequence
[v>10]setval(v)
49
Synchronous Messages
o1:C1
o2:C2
m(p1,p2)
o1:C1
o2:C2
m(p1,p2)
50
Asynchronous Messages
o1:C1
o2:C2
m1(p1,p2)
o3:C3
• The sender is not
blocked
• Messages may be sent
in either direction
m2(p3,p4)
• Behaviour is genuinely
concurrent
• Return values cannot
be implied
51
Flat Messages
• The sender stops and
waits to receive a
message
• This does not imply that
the next message is a
direct reply to the one
sent
o1:C1
o2:C2
o3:C3
m1(p1,p2)
m2(p3,p4)
m3(p5)
• Java’s threads are
typical examples
52
Collaboration Diagrams
show how systems are built from objects
and how messages get sent.
53
Collaboration for a successful
deposit
b:Branch
1.1:c:= getRec(name)
1.2:ac1 := getAcc(a,c)
1:deposit(v,a,name)
c1:Customer
:Teller
:ACustomer
1.3:addToBalance(v)
ac1:Account
54
Activity Diagrams
55
Activity Diagram for single Use Case
• The example on the following slide is taken
from the OMG UML notation guide and shows
a single action sequence
• Possible single use case
Get Beverage
56
Find
Beverage
[found coffee]
Put Coffee
in Filter
[no coke]
[no coffee]
Add Water
to machine
[found coke]
Get
Cups
Put Filter
in machine
Get Can
of Coke
Turn on
machine
/coffeePot.turnOn
Brew
Coffee
light goes out
Pour
Coffee
Drink
57
Dependencies between Use Cases
• Consider the bank account case study …
• Initial requirements were fuzzy ...
– What about opening a new account?
• Consider the situation where a Manager
needs to authorise the opening of a new
account …
• What else does the Manager do?
58
Dependencies between Use Cases
Open
Account
Teller
Manager
Paper work
Customer
A possible revision
to previous use case
diagram?
59
Dependencies between Use Cases
• Since the use case diagram shows only actors, not
instances of actors, it is difficult to express the
dependency in them
• We could show the Manager as a specialisation of
the Teller … helpful?
Teller
Manager
• How to show the dependency between two use
cases?
– complicated interaction diagram?
– More convenient to use an activity diagram with
swimlanes
60
Open New Account
[no accounts to do]
Enter
Done
Free
[accounts to do]
Ready
Doing
Accounts
Request
Authorisation
Complete
Wait
Customer
Teller
Manager
61
State Charts
internal behaviour of an object
62
An Example Statechart
move(r,c) / ^umpire.validate(‘X’,r,c)
XtoMove
XtoMove
XhasMoved
invalid() / ^xPlayer.makeAMove()
valid() / ^ yPlayer.makeAMove()
valid() / ^ xPlayer.makeAMove()
move( r,c) / ^ umpire.validate(‘Y’,r,c)
YhasMoved
YtoMove
invalid() / ^ yPlayer.makeAMove()
63
Actions on Transitions
• Once triggered, a transition is said to fire
• A transition may cause actions as part of its firing
– Some actions are changes to local or global
variables
• count++
– Some are output actions, sending messages to
other objects
• ^umpire.validate(‘X’,r,c)
• Actions follow the / symbol
64
Kinds of trigger
[tries<6] ask(m)
WantAnAnswer
tries :=0
FindingAnswer
after(10secs) / tries++
^reply(r)
when(tries=6) / ^reply(“failed”)
65
Nested States and Super States
when(checked)
Check answer
Get question
question(m)
requesting
requesting
[tries<6]ask(m)
WantAnAnswer
tries :=0
FindingAnswer
after(10secs)/tries++
^ reply(r)
when(tries=6)/^reply(“failed”)
66
Entry, exit and do actions
updating
entry/checkBalance()
do/addBalance()
• As well as labelling
transitions with actions, it is
possible to define actions
within a state
•
•
exit/tellBalance()
•
entry
– defines an action to be
performed on entering a state
exit
– defines an action to be
performed when leaving a state
do
– defines an action to be
performed while in a state
67
Concurrency, Synchronisation and
Conditions
Concurrency
Conditional states
Concurrency
Notation is common with
Activity Diagrams
68
Showing Fuller Behaviour
Waiting
Thinking
yPlayer:Player
move( r,c)/^umpire.validate(‘X’,r,c)
XtoMove
XhasMoved
invalid()/^ xPlayer.makeAMove()
valid()/^ yPlayer.makeAMove()
valid()/^ xPlayer.makeAMove()
Waiting
move( r,c)/^umpire.validate(‘Y’,r,c)
YhasMoved
b:Board
YtoMove
umpire:Checker
invalid()/^yPlayer.makeAMove()
•
Waiting
Thinking
xPlayer:Player
Checking
•
The collaboration and statechart diagrams can
be combined to get a complete model of
behaviour
Can you complete the picture for the players and
umpire? What about start and end states? What
about game logic?
69
Tutorial and Post Session Work
Tutorial Work:
– After a welcome coffee break, work in small
groups (3-4):
• Review the lecture notes and consider any
questions at this point
• Examine the tutorial exercise on the following
slides
70
Tutorial and Post Session Work
Post Session:
– Read back through session one notes and look at
some of the questions posed in note text below
slides.
– Read the provided hand out: The UML for Systems
Engineers, Bruce Powel Douglass, I-Logix
– What other UML notation elements do you know
about or can you find out about? What sources
would you use?
71
Tutorial Session
Exercise 1 - Use Case Diagram
– A simple word processor is required to create new and edit existing
documents. The word processor is required to support standard operations
such as cut, paste and spell check. The ability to print is also required.
– Question : Prepare a use case diagram that captures the requirements of
the word processor
Exercise 2 - Use Case Diagram
– A CD shop requires a system to help manage sales and stock. The shop
maintains a list of stock to track customer sales, returns of goods and
deliveries of new stock. The stock list is also used to allow queries of items
that are in stock in the event that they cannot be located on the shelves.
– Question: Prepare a use case diagram that captures the requirements of
the CD shop.
72
Tutorial Session
Exercise 3 - Class Diagram
– A new company wishes to enter the computer board games market. They intend to
produce a range of on-screen versions of well known two-player games, starting
with noughts and crosses (also known as tic-tac-toe) and chess. The users share a
screen and make moves in turn. The program makes sure that only legal moves are
allowed and declares a winner at the appropriate point. To make the implementation
of new games easy, and to ease the work of maintaining many different games, the
company want to design a game framework, which can be reused as frequently as
possible. The noughts and crosses game is played on a 3 by 3 square board
between two players. The player who starts (PlayerX) chooses a square of the
board and puts a cross in it. The other player (PlayerO) chooses an empty square
and puts a nought in it. Thereafter players continue to alternate, placing their own
token in empty squares. The winner is the first player to complete a straight line
(horizontal, vertical or diagonal) of three of their own tokens. If the board is filled
without either player achieving this then the game is a draw.
– Question: Find the classes and draw the class diagram for the above noughts and
crosses game. If you are doing this as a group activity then make sure that all
members do know how the game works before proceeding. Once you have this
initial class diagram think how you might develop this into a more general game
framework as outlined above.
73
Session Two
74
Overview
• Aims:
– Review of UML notation
relating to real-time and
embedded systems
– Learn about some other
useful bits of UML!
• Session Two
• Lecture
– UML for real-time systems
– Traffic Light Case Study
– Other bits of UML
• Tutorial
– Practical Exercise (assessed)
• Post Session
– Reading on further examples
(2PC and transaction
processing).
75
Particulars of RT Domain
Two questions:
1. What are we interested in modelling?
Timing Information:
Interactions:
Important for dependencies
and synchronisations
Need to model message
passing / communication
2. What UML notations/diagrams can we use?
Existing Standard Diagrams:
Activity diagrams, interaction diagrams, state charts
-plus all the other diagrams have their place
Stereotypes and guards:
Help to convey timing information
76
Activity
Take a couple of minutes to read through the case study
description of a traffic light junction on the following two
slides.
Convince yourself that you understand it and see if you
agree that it describes a traffic light fully and accurately. If
not, what other assumptions would you want to make?
77
Traffic Light Case Study
You are asked to design a system to control the traffic lights at a road
junction. Lights are set to one or more colours, which determine what cars
may do. Each combination of colours permits different actions for cars
approaching it. Red means “stop”. Green means “carry on” or “start
moving”. Amber means “slow down ready to stop”. Red and amber
together mean “get ready to move off”.
The lights change according to the following rules:
• the lights have not changed for 90 seconds they move through the
sequence from green to red, via red and amber, or from red to green
via amber
• if there are cars waiting at a red light and no cars approaching the
green light, the change sequence occurs
• if a pedestrian pushes the crossing button on a light, the change
sequence occurs if that light was on green
78
Traffic Light Case Study
79
Activity
Consider your thoughts developing on the traffic light case
study.
What requirements can you identify?
Develop a use case diagram that captures the
requirements. Perhaps start by identifying actors and then
think in terms of what the resulting system must satisfy.
80
Use Case Diagram
Driver
Cross
Pedestrian
81
Activity
Consider your thoughts developing on the traffic light case
study. Moving on from the requirements we are now going
to examine a structure for the system.
What classes can you identify? What associations can you form
between them?
Don’t go for too much detail at the moment - develop a basic
class diagram that would support the requirements of the
system.
Think about the approach to identifying classes from the
last lecture.
82
Simple Class Diagram
Button
requests
crossing
Timer
TrafficLight
synchronises
83
Activity
Considering the basic class diagram presented on the
previous slide spend a few minutes to look at adding
additional detail in terms of:
– navigation and
– multiplicities
84
Extra details
Button
*
requests
crossing
TrafficLight
1
Timer
1
synchronises
*
85
Activity
Considering the basic class diagram presented on the
previous slide, look at adding additional detail inside the
classes in terms of:
– attributes and
– operations
Focus on the Timer and TrafficLight classes
86
Extra details
Button
*
Stereotype
1
requests crossing
TrafficLight
«RTtimer»
Timer
{isPeriodic = True,
interval = 90}
Constraints /
Properties
-setting:{red,green,amber}
+change():void
isPeriodic : Boolean
interval:TimeInterval
reset
1
synchronises
*
Attributes and operation specified in profile
87
UML TM Profile for Schedulability,
Performance, and Time Specification
The RFP called for “proposals for a UML profile that
defines standard paradigms of use for modeling of time, schedulability-, and performance-related aspects of
real-time systems” that would:
– Enable the construction of models that could be used to
make quantitative predictions regarding these characteristics
– Facilitate communication of design intent between
developers in a standard way
– Enable interoperability between various analysis and design
tools
88
Why is this required?
Do we need such profiles?
Think what the alternatives are …
Good points
Consistency
Standards
Automation
Weak Points
Complexity!
Overkill
89
General Resource Modeling Framework
<<profile>>
RTresourceModeling
Basic concepts to support
modelling of resources and
timing mechanisms/quantifiers
<<import>>
<<import>>
<<profile>>
RTconcurrencyModeling
<<profile>>
RTtimeModeling
Technology specific
subprofile
<<import>>
Infrastructure Models
<<import>>
<<import>>
<<modelLibrary>>
RealTimeCORBAModel
Analysis Models
<<profile>>
SAprofile
<<import>>
<<profile>>
RSAprofile
<<profile>>
PAprofile
Profile compliance points profiles define tagged values
and stereotypes for
schedulability(SA) and
performance(PA)
90
Sequence for Pedestrian Crossing
:Pedestrian
b1:Button
push( )
reset( )
:Timer
t1:TrafficLight
t2:TrafficLight
t3:TrafficLight
t4:TrafficLight
{0 ms}
timeout( ){5 ms} timeout( ) {5 ms}
{45 ms}
{45 ms}
timeout( ) {5 ms}
{45 ms}
timeout( ) {5 ms}
{45 ms}
Issues:
• How do we ensure that all four lights change
simultaneously?
• System partitioning– interfacing synchronous and
asynchronous systems. Where is the boundary in the above
system?
91
Sequence for Pedestrian Crossing
:Pedestrian
:Junction
change()
92
Activity
Look at the Sequence Diagram introduced for the traffic
light case study and redraw it as a collaboration
diagram. Focus on the structure of the diagram and
representation of interactions.
93
Collaboration for Pedestrian Crossing
1:push( )
t1:TrafficLight
1.1.1a:change( )
b1:Button
:Pedestrian
t2:TrafficLight
1.1:reset( )
1.1.1b:change( )
:Timer
t3:TrafficLight
1.1.1c:change( )
1.1.1d:change( )
t4:TrafficLight
94
Collaboration for Pedestrian Crossing
l:Junction
b1:Button
:Pedestrian
95
Activity
Think about a state chart for the traffic light.
Begin by considering what states are to be supported
and what transitions between states are valid.
What are valid start states – and it is sensible to show
an end state?
96
State Chart for Traffic Light
Red
XtoMove
timeout()
Red and Amber
[sequenceNo=1 or
sequenceNo=3]
after(5secs)
Amber
after(5secs)
[sequenceNo=2 or
sequenceNo=4]
Green
timeout()
97
State Chart for Timer
after(interval)/^[ i:=1..4]ti.timeout();RTcurrentVal:=0
interval := 90 secs
Counting
reset()/^[i:=1..4]ti.timeout();RtcurrentVal := 0
98
Other Bits of UML
Packages
Implementation Diagrams
99
Packages
• No elements showing tabbed rectangle with a label
in the larger rectangle.
Bank use cases
Bank classes
Account
Current
Account
• A package contents shown
inside the larger rectangle
has its label on the tab
Customer
Transfer
Savings
Account
Branch
Bank interactions
• Subpackages can be shown
attached to the owning
package by a  headed line
Bank sequences
Bank collaborations
100
Implementation Diagrams
• UML has implementation diagrams to show the
overall construction of a system
• Representing Nodes - nodes represent physical
parts of the system, such as processors
• Component Diagrams - components represent
pieces of the software in the system
• Deployment Diagrams - Combine node and
component information to show how software is
deployed
101
Representing Nodes
myPC:Pentium2
wireb
«ethernet»
yourPC:Pentium3
102
Component Diagram
Compilation Components Example
source
«compile»
object
library
«link»
My App
<<executable>>
«link»
103
Component Diagram
Runtime Components Example
Umpire
Board
Player
104
Deployment Diagram
myPC:Pentium2
p1:Player
u:Umpire
b:Board
«ethernet»
wireb
p2:Player
yourPC:Pentium3
105
Further Examples in the
Real-time Domain
Two Phase Commit
Transaction processing
106
Two phase commit (2PC)
• 2PC is a means of minimising the risk of an
inconsistent outcome where co-operating processes
have to update global information.
• In a distributed database, a transaction may involve a
number of tasks spread over a number of servers.
• The master process:
– divides the work of the transaction into sub-tasks and
transmits requests to the corresponding servers
– sends a ready request to each of these tasks, to report as
soon as they succeed or fail; this may be piggy backed on
the initial request
107
Two phase commit (2PC)
• each task then proceeds as follows:
– it requests locks for data that it will read or write; read locks
can be shared, but write locks must be exclusive;
– if any lock is refused, the task sends back a failure
response and does nothing until it receives an abort;
– if it is successful in acquiring the locks, it performs the
computation; no locks are released here; once the
computation is complete, the task sends a ready response
and waits for an abort or commit;
– if the task receives a commit it updates the data affected by
its computation, releases all its locks and ends;
– if it receives an abort it releases all its locks and ends
without updating the global copy of its data
108
Two phase commit (2PC)
• the master process waits until it either receives any
failure response, when it sends an abort to all its
tasks and enters the aborted state, or it receives a
ready response from all its tasks, when it sends a
commit to all its tasks;
• in the aborted state, the master process will continue
to send aborts to any tasks that send messages,
since these will be stragglers or result from recovery
by a task which failed.
109
2PC Class Diagram
1
Computation
1..*
carries out
runs on
1
1
Transaction
1
spawns
1..*
Task
1
executes on
Server
1
1
1
are needed for
is made to
1..*
Lock request
1..*
110
2PC Collaboration Diagram
t1:Task
s1:Server
t:Transaction
:User
t2:Task
s2:Server
111
Transaction Processing
• Starts by spawning all the tasks needed to perform it.
These are passed a set of locks needed and a
duration for their computations.
• The Transaction then enters the running state until it
has either received ready messages from all its
tasks, when it sends them all a commit message and
terminates, or it receives one or more failed
messages, when it sends abort messages to all its
tasks and terminates.
• We assume that it does not need to wait after the
aborts are sent to check for recovering stragglers
112
Transaction Processing
when(tasks<0)/^newTask(locks,d);locks++
needed := n;tasks := 0
spawning
when(tasks>0)/^task[tasks].abort;tasks-Transaction
failed
when(tasks=needed)
when(tasks=0)
when(suc+ref=tasks and ref>0)
when(tasks=0)
Transaction
succeeded
running
ready(n)/suc++
when(suc=tasks)
when(tasks>0)/^task[tasks].commit;tasks--
failed(n)/ref++
113
A Task
• Is initially in the locking state. From here it makes
repeated transitions to the asking state, until the last
lock has been granted. Each time it makes this
transition it sends a message to its Server, s, asking
for a lock.
• In the asking state, the lock is either granted,
triggering a transition back to locking and
incrementing locks, or refused, triggering a transition
to failed and causing a fail message to be sent to the
Transition, tr.
• If all locks granted, Task sends compute request to
its Server and enters the computing state.
114
A Task
• It waits there until it receives a done message, when
it sends a ready message to its Transition, tr, and
enters the ready state.
• If the Task reaches the ready state and receives a
commit message from its Transition, it commits,
shown here as simply moving to the releasing state,
but in a real system involving updating the current
copies of its data.
• In either the failed or the ready states an abort
message causes the Task to move to the releasing
state. In the releasing state, all locks granted to this
task are released.
115
Statechart for a Task
116
Server
• The Server receives messages for locks or
computational tasks.
• When it does so it increments the count of locks or
tasks (used for state dependent probabilities and
rates in the performance model) and creates a
Request or Active as appropriate.
• When it receives a give or a finished message, this
indicates success for one of these subsidiaries, as
shown in their simple state diagrams.
• It may also receive a release from a committing or
aborting Task.
117
Server statechart
118
119
Tutorial Session
• After a welcome coffee break you will work in small
groups (3-4 students)
– Review the lecture notes and consider any questions at this
point
– Examine the tutorial exercise on the following slides. This
aims to give you some practise looking at interactions
between objects and experience with UML class and
interaction diagrams.
– This will be collected in at the end of the tutorial and marked
as a piece of coursework contributing to your final module
mark.
– An assessment/feedback sheet will be handed out during
the tutorial session. You should clearly enter the names of
all students in your group and submit the sheet with your
coursework.
120
Tutorial Session (Coursework)
The card game switch works as follows.
Step 1: The cards are dealt out to the players. The initial direction of play is clockwise.
Step 2: The player on the dealers left is the first to play a card.
Step 3: Players always keep their cards face downwards and play the top card from their
pile.
Step 4: After a player plays their top card, the next event depends on the values of that card.
– if an eight is played, the player two from the one who played the card, in the current direction
of play, plays their next card, i.e. the normal next player is missed out;
– if a jack is played, the direction of play is reversed and the player next in the new direction of
play plays their top card;
– if any other card is played, the next player in the direction of play plays their top card.
Step 5: Step 4 is repeated until one player has played all of their cards. That player is the
winner.
Assume three players, Player1, Player2 and Player3, seated in that sequence clockwise.
They take turns by sending messages such as play(jack) to the gameTable object. The
gameTable object controls who plays next, in accordance with the rules described in step
4 above, by sending the message turn() to the appropriate player after it receives each
play() message.
121
Tutorial Session (Coursework)
1. Identify classes that support the objects described above and draw the resulting UML
class diagram. The class diagram should show detail boxes for the class name, attributes
and operations. You need only complete sections for the class name and operations.
Clearly state any assumptions you make. Clearly show direction and nature of
associations and show appropriate multiplicity information. State any assumptions that
you need to make.
2. Draw a UML sequence diagram to show how the following game would proceed, clearly
showing which of the three players wins. Clearly state any assumptions that you make.
Assume that Player3 has just dealt and the three players each have the following cards
in their pile:
•Player1, from top to bottom of card pile:
five, eight, three, ace.
•Player2, from top to bottom of card pile:
four, two, jack, seven.
•Player3, from top to bottom of card pile:
nine, queen, six, ten
122
Some General UML References
•
Stevens, P and Pooley, R. (2000). Using UML Software Engineering with Object and Components,
Updated Edition. Pearson Education Limited.
•
Pooley, R and Wilcox P (2004). Applying UML: Advanced Application. Butterworth-Heinmann
•
Douglass, Bruce P., Doing Hard Time: Developing Real- Time Systems with UML, Objects,
Frameworks, and Patterns, Addison- Wesley, 1999
•
Douglass, Bruce P., Real- Time Design Patterns: Robust Scalable Architectures for Real- Time
Systems Addison- Wesley, 2002
•
Fowler and Scott, UML Distilled, Addison- Wesley 1997
•
Some good free references from the Internet for general UML material:
–
OMG UML web pages via http://www.uml.org/
–
Rational white papers via http://www.rational.com/products/whitepapers/
–
Scott Amblers’ white papers via http://www.ambysoft.com/onlineWritings.html
123
Some More Related References
•
Response to the OMG RFP for Schedulability, Performance, and Time, Revised
Submission, Monday, June 18 2001, OMG document number: ad/2001-06-14 (224
pages).
http://ftp.cse.sc.edu/jdavis/UML%20Research%20Stuff/UML_sched_perf_time.pdf
•
The Real- Time UML Standard: Definition and Application by Alan Moore, Bran Selic
and Ben Watson (94 pages). http://neptune.irit.fr/Biblio/01-07-03.pdf
•
UMLTM Profile for Schedulability,Performance, and Time Specification,
http://cgi.omg.org/docs/ptc/02-03-02.pdf
•
I-Logix white papers (register via http://www.ilogix.com/ )
–
Real-Time Object Orientation, by Dr. Bruce Powel Douglass
–
Real-Time Design Patterns, by Dr. Bruce Powel Douglass
–
Capturing Requirements for Real-Time and Embedded Systems, by Dr. Bruce Powel Douglass
–
Custom Embedded Communications Protocols, by Dr. Bruce Powel Douglass
–
The UML for Systems Engineering, by Dr. Bruce Powel Douglass (your reading from session one)
124
And finally …
•
A wide range of tools are available to support working with UML (some are
freely available via the Internet). Many have support targeting modelling of
real-time systems - a small example follows:
–
–
–
–
–
•
Rational Rose: http://www.rational.com/products/rose/index.jsp
Artisan: http://www.artisansw.com/vip/goo_uml.asp
ArgoUML: http://argouml.tigris.org/
Poseidon (commercial version of argoUML): http://www.gentleware.com/
Ilogix: http://www.ilogix.com/
These lecture notes (including diagrams introduced during the lecture) and
other material relating to this part of the Systems Partitioning module can be
found at the following URL:
http://www.macs.hw.ac.uk/~paw/teaching/ISLI/index.html
125
Download
Related flashcards

Theory of computation

16 cards

Computer science

25 cards

Web development

38 cards

Computer science

29 cards

Software

43 cards

Create Flashcards