1 the unified modelling language introduction. 2 overview session one lecture –an introduction to...
TRANSCRIPT
1
The Unified Modelling Language
Introduction
2
Overview
• Session One
• Lecture – An introduction to the
UML– Bank account case study
• Tutorial– Practical Exercise
• Post Session– Reading
• 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).
3
Session One
4
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
5
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
6
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
7
Key Diagrams in UML
Requirements
Capture
System
Structure
System Behaviour
Use Case Diagram
Interaction Diagrams
Activity Diagrams
State Charts(+ CRC cards)
Class Diagram
8
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 whichwe 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.)
9
Introductory Case StudyThe 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.
10
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.
Introductory Case StudyThe Bank Account
11
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
12
Use Case Modelling
13
Use Case model of the bank
withdraw
transfer
statement
addinterest
teller
aCustomer
deposit
This is onepossibility
14
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
15
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
16
Activity
Take a minute to read through the following use case description.
The example concerns making a Deposit.
17
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.
18
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.
19
Class Modelling
20
Classes and Objects
• An object is a means of partitioning the solution to a design problem.
• Objects are similar to modules in some ways.
• Objects provide encapsulation of data.
• An object is described by a class. A class may define a number of objects with identical properties.
Object = Identity +State +Behaviour
21
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?
22
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.
23
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.
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
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.
Nouns in the bank account example
26
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
27
Nouns Left
• current account
• savings account
• customer
• branch
• statement
• transfer
Now we need to considersome graphical way of
expressing our class model
28
Class Diagram
Currentaccount
Savingsaccount
Statement
Branch
Customer
Transfer
withdraws and deposits money with withdraws and deposits money with
holds holds
moves money tomoves money to
summarisessummarises
11
1 1
11 1 1
1
1
1
1
0..* 0..*0..* 0..*
Associations betweenclasses
29
Class Diagram
-balance : real
1
TransferSavingsAccount
Statement
Branch
Customerwithdraws and deposits money with
withdraws and deposits money with
holds holds
summarisessummarises
1
1 1
moves money to
11
moves money to
1 1
1
1
1
1
0..*
0..*
0..*
0..*
CurrentAccount
+withdraw(a:Real)+deposit(a:Real)+curBal():Real
Showing classdetails
30
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
31
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
32
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
employee
manageranalystdeveloper
specialisations
generalisation
• 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
33
Specialisations
• 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 sub-classes
employee
manageranalystdeveloper
generalisation*or* parent class*or* super-class
specialisation*or* child class *or* sub-class
34
• A specialisation may also redefine operations which were implemented in its parent.
Polymorphism
developer
printDetails()
employee
printDetails()
analyst
printDetails()
manager
Also referred to as overloading
of methods where can have same method
name but different signatures
printDetails()
printDetails(int x)
35
Class Diagram using Specialisation
Account
Statement
Branch
Customer
Transfer
holds
moves money to
summarises
1
1
1
1
1
1
0..*
0..*
CurrentAccount
SavingsAccount
36
An Example
+withdraw(a:Real)
+withdraw(a:Real)
+withdraw(a:Real)
Account
CurrentAccount SavingsAccount
-balance : Real-rate : Real
-chequeNo : Integer
{abstract}
+deposit(a:Real)+curBal():Real
+newBook()
37
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.
38
Interfaces In UML
Exchange
Account
<<interface>>Transfer
Transfer
Exchange
Account
<<interface>>Transfer
<<uses>>
move cashmove cash
39
CRC Cards
40
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.
41
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
42
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.
43
CRC Card for Current Account
Current Account
Maintains an account’s balance.
Allows transfers.
Accumulates interest.
Transfer
Statement
Responsibilities Collaborators
Class name
44
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.
45
Modelling Interactionsusing
Interaction DiagramsActivity Diagrams
State Charts
46
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
47
Sequence Diagrams
show sequences of messages with the emphasis on the order in which they are
sent
48
Sequence for a successful deposit
ac1:Accountc:Customer b:Branch:aCustomer :Tellerdeposit(v,a,name)
c:= getRec(name)
ac1 := getAcc(a,c)
addToBalance(v)
49
Messages
• May be numbered and nested• Parameters may be passed
• Values may be returned using assignment :=
• Messages may be conditional - use of guards (expression in square brackets)
• Sub-sequences may be enclosed in a box - helpful?
• Messages or sub-sequences may be repeated *
Synchronous (procedure)
Flat (thread)
Asynchronous (concurrent)
Return from synchronous
[v<30] Guard
*[x>10] Iteration
v=getval()
[v>10]setval(v)
*
[v>0]
Repeatedsequence
50
Synchronous Messages
m(p1,p2)
o1:C1 o2:C2
m(p1,p2)
o1:C1 o2:C2
51
Asynchronous Messages
• The sender is not blocked
• Messages may be sent in either direction
• Behaviour is genuinely concurrent
• Return values cannot be implied
m1(p1,p2)
o1:C1 o2:C2
m2(p3,p4)
o3:C3
52
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
• Java’s threads are typical examples
m2(p3,p4)
o1:C1 o2:C2
m3(p5)
o3:C3
m1(p1,p2)
53
Collaboration Diagrams
show how systems are built from objects and how messages get sent.
54
:ACustomer:Teller
ac1:Account
b:Branch
c1:Customer
1.1:c:= getRec(name)
1:deposit(v,a,name)1.2:ac1 := getAcc(a,c)
1.3:addToBalance(v)
Collaboration for a successful deposit
55
Activity Diagrams
56
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
57
Find Beverage
Get Cups
Add Water to machine
Turn onmachine
Put Coffeein Filter
BrewCoffee
Get Canof Coke
Put Filterin machine
Pour Coffee
Drink
[no coffee] [no coke]
[found coke][found coffee]
/coffeePot.turnOn
light goes out
58
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?
59
Dependencies between Use Cases
OpenAccount
Paper work
Teller
Customer
Manager
A possible revisionto previous use casediagram?
60
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?
• How to show the dependency between two use cases?
– complicated interaction diagram?
– More convenient to use an activity diagram with swimlanes
Teller Manager
61
Open New Account
[no accounts to do]
[accounts to do]
Customer Teller Manager
Enter Free
RequestAuthorisation
Ready
DoingAccounts
Done
WaitComplete
62
State Charts
internal behaviour of an object
63
XtoMoveXtoMoveXtoMove
YtoMove
XhasMoved
YhasMoved
move(r,c) / umpire.validate(‘X’,r,c)
move( r,c) / ^umpire.validate(‘Y’,r,c)
valid() / ^ xPlayer.makeAMove()
invalid() / xPlayer.makeAMove()
valid() / ^ yPlayer.makeAMove()
invalid() / ^ yPlayer.makeAMove()
An Example Statechart
64
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
65
WantAnAnswer FindingAnswer
[tries<6] ask(m)
after(10secs) / tries++
^reply(r)
when(tries=6) / ^reply(“failed”)
tries :=0
Kinds of trigger
66
Get questionCheck answer
requesting
WantAnAnswer FindingAnswer
[tries<6]ask(m)
after(10secs)/tries++
^ reply(r)when(tries=6)/^reply(“failed”)
tries :=0
requesting
when(checked)
question(m)
Nested States and Super States
67
Entry, exit and do actions
• As well as labelling transitions with actions, it is possible to define actions within a state
• 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
updating
entry/checkBalance()
do/addBalance()
exit/tellBalance()
68
Concurrency, Synchronisation and Conditions
Concurrency
Notation is common withActivity Diagrams
Conditional states
Concurrency
69
XtoMoveXtoMoveXtoMove
YtoMove
XhasMoved
YhasMoved
move( r,c)/^umpire.validate(‘X’,r,c)
move( r,c)/^umpire.validate(‘Y’,r,c)
valid()/^ xPlayer.makeAMove()invalid()/^ xPlayer.makeAMove()
valid()/^yPlayer.makeAMove()
invalid()/ yPlayer.makeAMove()
Waiting
Thinking
Waiting
Checking
Waiting
Thinking
b:Board
yPlayer:Player
xPlayer:Player
umpire:Checker
• 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?
Showing Fuller Behaviour
70
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
71
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?
72
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.
73
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.
74
Session Two
75
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).
76
Particulars of RT DomainTwo questions:
1. What are we interested in modelling?
2. What UML notations/diagrams can we use?
Timing Information:Important for dependencies and synchronisations
Interactions:Need to model message passing / communication
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
77
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?
78
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
79
Traffic Light Case Study
80
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.
81
Use Case Diagram
Cross
Pedestrian
Driver
82
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.
83
Simple Class Diagram
Button
requests crossing
TrafficLight
Timer synchronises
84
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
Activity
85
Extra details
Button
requests crossing
TrafficLight
Timer synchronises1
*
*
1
86
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
Activity
87
Button
requests crossing
*
1
TrafficLight
-setting:{red,green,amber}
+change():void
«RTtimer»Timer
{isPeriodic = True,interval = 90}
*
1
synchronises
isPeriodic : Booleaninterval:TimeInterval
reset
Extra details
Constraints /Properties
Stereotype
Attributes and operation specified in profile
88
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
UML TM Profile for Schedulability,Performance, and Time Specification
89
Do we need such profiles?
Think what the alternatives are …
Why is this required?
Good pointsConsistencyStandardsAutomation
Weak PointsComplexity!Overkill
90
<<profile>>RTresourceModeling
<<profile>>RTconcurrencyModeling
<<profile>>RTtimeModeling
<<profile>>SAprofile
<<profile>>PAprofile
<<profile>>RSAprofile
<<modelLibrary>>RealTimeCORBAModelAnalysis Models
General Resource Modeling Framework
Infrastructure Models<<import>>
<<import>>
<<import>>
<<import>>
<<import>>
<<import>>
Basic concepts to support modelling of resources and
timing mechanisms/quantifiers
Technology specific subprofile
Profile compliance points - profiles define tagged values
and stereotypes for schedulability(SA) and
performance(PA)
91
Sequence for Pedestrian Crossing
push( )reset( )
timeout( ) timeout( )timeout( ) timeout( )
{0 ms}
{5 ms} {5 ms} {5 ms}{5 ms}
{45 ms} {45 ms} {45 ms} {45 ms}
b1:Button:Pedestrian t1:TrafficLight:Timer t2:TrafficLight t3:TrafficLight t4:TrafficLight
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?
92
:Junction:Pedestrian
change()
Sequence for Pedestrian Crossing
93
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.
Activity
94
t1:TrafficLight
:Pedestrian
t4:TrafficLight
t3:TrafficLight
t2:TrafficLight
1:push( )
( )
1.1.1a:change( )
1.1.1b:change
1.1.1c:change( )
1.1.1d:change( )
b1:Button
:Timer
1.1:reset( )
Collaboration for Pedestrian Crossing
95
l:Junction
:Pedestrian
b1:Button
Collaboration for Pedestrian Crossing
96
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?
Activity
97
XtoMoveXtoMoveRed
Green
Red and Amber
Amber
timeout()
after(5secs)
timeout()
after(5secs)
[sequenceNo=1 orsequenceNo=3]
[sequenceNo=2 orsequenceNo=4]
State Chart for Traffic Light
98
after(interval)/^[ i:=1..4]ti.timeout();RTcurrentVal:=0
reset()/^[i:=1..4]ti.timeout();RtcurrentVal := 0
interval := 90 secsCounting
State Chart for Timer
99
Other Bits of UML
PackagesImplementation Diagrams
100
Packages
• No elements showing - tabbed rectangle with a label in the larger rectangle.
• A package contents shown inside the larger rectangle has its label on the tab
• Subpackages can be shown attached to the owning package by a headed line
Bank classes
Account Transfer
Customer Branch
CurrentAccount
SavingsAccount
Bank interactions
Bank sequences Bank collaborations
Bank use cases
101
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
102
Representing Nodes
myPC:Pentium2
yourPC:Pentium3
«ethernet»wireb
103
Component Diagram Compilation Components Example
My App<<executable>>
object
source
«compile»
«link»
«link»
library
104
Component Diagram Runtime Components Example
Player
Umpire
Board
105
Deployment Diagram
myPC:Pentium2
yourPC:Pentium3
«ethernet»
wireb
p2:Player
u:Umpire
b:Board
p1:Player
106
Further Examples in theReal-time Domain
Two Phase CommitTransaction processing
107
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
108
• 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
Two phase commit (2PC)
109
• 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.
Two phase commit (2PC)
110
Transaction
Lock request
ServerTask
Computation1
1..*
1
1
1
1
1
1 1
1..*
1..* 1..*
spawns
carries out runs on
executes on
is made toare needed for
2PC Class Diagram
111
s2:Servert2:Task
t1:Task s1:Server
t:Transaction:User
2PC Collaboration Diagram
112
• 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
Transaction Processing
113
spawning
Transactionsucceeded
Transactionfailed
running
needed := n;tasks := 0
when(tasks=0)
when(tasks=0)
when(tasks=needed)
when(tasks<0)/^newTask(locks,d);locks++
when(tasks>0)/^task[tasks].abort;tasks--
when(tasks>0)/^task[tasks].commit;tasks--
when(suc=tasks)
ready(n)/suc++
failed(n)/ref++
when(suc+ref=tasks and ref>0)
Transaction Processing
114
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.
115
• 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.
A Task
116
Statechart for a Task
117
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.
118
Server statechart
119
120
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.
121
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.
122
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
123
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
124
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)
125
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