Outline AIMS Embedded Systems Programming MT...
Transcript of Outline AIMS Embedded Systems Programming MT...
AIMS Embedded Systems ProgrammingMT 2015
Design with the Unified Modeling Language (UML)
Daniel Kroening
University of Oxford, Computer Science Department
Version 1.0, 2014
Outline
D. Kroening: AIMS Embedded Systems Programming MT 2015 2
Model-Driven Architecture (MDA)
Model-Driven Architecture
Key idea:1. Build high-level model for the software
system2. Gradually refine into actual program
while maintaining a layered architecture
MDA is forward engineering: the specification comes before theimplementation
D. Kroening: AIMS Embedded Systems Programming MT 2015 3
Technology Independence
Requirement: Preserve investment in an application
I as platforms proliferateI while the existing platforms change
Solution: Isolate information and processing logic fromtechnology specifics
I Build platform-independent modelsI Refine these models to specific platformsI Maintain this separation
D. Kroening: AIMS Embedded Systems Programming MT 2015 4
Raising the Level of Abstraction
I Not new. Has been done before.I Programming Languages
(hardwired circuitry, punch cards, assembler, PASCAL/C,OO, ...)
I Operating systems, data bases, ...
I Interesting: well-established for two sides of the problemI WYSIWYG GUI buildersI Data modeling
→ hand coding no longer predominates
I Goal: higher productivity
D. Kroening: AIMS Embedded Systems Programming MT 2015 5
MDA Models
Business Model(computation-independent)
PPPqAnalysis Model
(platform-independent)PPPq
Design Model(platform-dependent)
PPPq
Code
RE
FIN
EM
EN
T
BUSINESSANALYST
ARCHITECT/DESIGNER
DEVELOPER/TESTER
D. Kroening: AIMS Embedded Systems Programming MT 2015 6
What is UML?
I The Unified Modeling Language (UML) is a standardizedlanguage for describing software
I graphical notation for all constructs
I Focus on object-oriented systems
I Dominating language for modelling application software(2nd only to English)
D. Kroening: AIMS Embedded Systems Programming MT 2015 7
History
I Grady Booch, Ivar Jacobson, and James Rumbaugh, atthe time employed at Rational Software:
1990s: UML 1.x
I November 1997: UML became a standard,defined by the Object Management Group (OMG)
I September 2004: UML 2.0
D. Kroening: AIMS Embedded Systems Programming MT 2015 8
Why?
1. You are very likely to see this on the job!
2. It’s the standard for OO design
3. (Some) formalization possible,enables tool-support
D. Kroening: AIMS Embedded Systems Programming MT 2015 9
UML Diagram Types
THIS COURSE
Structure
Behavior
Diagram
DeploymentPackage
InteractionUse Case
ActivityState Machine
ClassComposite StructureObjectComponent
Timing
Overview
CommunicationInteraction
Sequence
D. Kroening: AIMS Embedded Systems Programming MT 2015 10
Disadvantages of UML
I Semantics is vague: meaning of diagrams is not alwayswell-defined
I Some historical, inherited complexity
I Huge (main standard document has 732 pages),and not very accessible
I Tools assign different meanings to the same diagram
D. Kroening: AIMS Embedded Systems Programming MT 2015 11
Class Diagrams
A Class Diagram...
describes the types of theobjects, and relationshipsamong objects
Studentname: Stringcollege: Collegefriends: Person[0..*]courses: Course[0..*]supervisor: Academicenroll(Course c): voiddrop_out(Course c): void
I Classes have a name and twomore compartments
I 1st compartment: fieldsI 2nd compartment: methodsI Classes belong to a package.
D. Kroening: AIMS Embedded Systems Programming MT 2015 12
Packages
XYZ
XYZ.SUB
Studentname: Stringcollege: Collegefriends: Person[0..*]courses: Course[0..*]supervisor: Academicenroll(Course c): voiddrop_out(Course c): void
PersondateOfBirth : Datename : StringchangeName(...) : boolean
Studentname: Stringcollege: Collegefriends: Person[0..*]courses: Course[0..*]supervisor: Academicenroll(Course c): voiddrop_out(Course c): void
PersondateOfBirth : Datename : StringchangeName(...) : boolean I These form a
namespace.
I The arrowdenotes“contained in”
D. Kroening: AIMS Embedded Systems Programming MT 2015 13
Class Fields
Studentname: Stringcollege: Collegefriends: Person[0..*]courses: Course[0..*]supervisor: Academicenroll(Course c): voiddrop_out(Course c): void
I These are variables, and hold thestate of the object
I Fields have aI name, and aI type.
I The type may beI a class,I or something “predefined”.I Arrays are also possible using
multiplicities – we will discussthe syntax later.
I Static fields are underlined.
D. Kroening: AIMS Embedded Systems Programming MT 2015 14
Initial Values
ConstantsPI: Real = 3.14159265 {readOnly}e: Real = 2.71828183 {readOnly}speed_of_light: Real = 299792458Plancks_constant: Real = 6.62606896E-34
I Fields may have an initial valueI Syntax:
field name : field type = value
I These are assigned upon creation ofthe object→ constructor
D. Kroening: AIMS Embedded Systems Programming MT 2015 15
Methods
String_size: Integersize(): Integerconcat(s: String): Stringsubstring(lower: Integer, upper: Integer): StringtoInteger(): IntegertoReal(): Real
I Operations that have read/write access to thefields
I Defined byI name,I parameter list,I return type.
I It is possible to define operators as well.
D. Kroening: AIMS Embedded Systems Programming MT 2015 16
Modifiers: Example
Patient*-dateOfBirth : Date*+treatment : String*#illness : String*+name : String*~GP : Number*+updateCondition( condition : ConditionCode, Notes : String ) : void*#changeName( newName : String ) : boolean*#printPrescription() : boolean*+notifyGP() : void
+ public − private# protected ∼ package
D. Kroening: AIMS Embedded Systems Programming MT 2015 17
Relationships between Classes
I Generalization
I Association
I Aggregation
I Composition
D. Kroening: AIMS Embedded Systems Programming MT 2015 18
Generalization
Patienttreatment : Stringillness : StringGP : NumberupdateCondition(...) : void
PersondateOfBirth : Datename : StringchangeName(...) : boolean
I Taxonomic relationshipbetween a more generaldescription and a morespecific one that extends it
I OO: this is inheritance
I denoted by an arrow line withan empty arrowhead fromsubclass to superclass
I Often: read as “is a”
D. Kroening: AIMS Embedded Systems Programming MT 2015 19
Generalization: Example I
Patienttreatment : Stringillness : StringGP : NumberupdateCondition(...) : void
PersondateOfBirth : Datename : StringchangeName(...) : boolean
Doctorspecialities: Speciality[0..*]
D. Kroening: AIMS Embedded Systems Programming MT 2015 20
Generalization: Example II
StoryGenre: String
BookISBN : Stringpublisher : Stringpages : Integer
Novel
This is multiple inheritance!1
1Read Bertrand Meyer, “Harnessing multiple inheritance”, for more on this.D. Kroening: AIMS Embedded Systems Programming MT 2015 21
Association
I “Connection” between classes (may involve more than two)
I Class X uses/references class Y
I This connection may have several properties:I NameI NavigabilityI MultiplicityI Role names, visibility
I Denoted with a solid line
D. Kroening: AIMS Embedded Systems Programming MT 2015 22
Properties of Associations
I NameI Typically a verbI Describes nature of connection
I NavigabilityI Establishes the direction of the relationI Denoted with an arrow headI May be bidirectional or unspecified
I MultiplicityI Establishes how many objects participate in the relationI Typical: 0, 1, 0..1, 1..∗, 0..∗ (same as ∗)I Default: 1
I Role names, visibility→ think of these as extra members
D. Kroening: AIMS Embedded Systems Programming MT 2015 23
Association: Example I
Customer Magazinesubscribes0..* 0..*+subscriber +subscribed magazine
D. Kroening: AIMS Embedded Systems Programming MT 2015 24
Association: Example II
Professor Studentsupervises1..2 0..*+supervisor +student
D. Kroening: AIMS Embedded Systems Programming MT 2015 25
Association: Example III (Navigability)
Studentname: Stringcollege: College
Mark
D. Kroening: AIMS Embedded Systems Programming MT 2015 26
n-Ary Relations
Some cases associations involve more than two classes
Student Course
Grade
0..*1..*
0..*
I A student takes zero or morecourses,and possibly has grades
I A course has at least onestudent,and possibly has grades (for thestudents)
I A grade may have been obtainedby at least one student, and maybe assigned to some courses
D. Kroening: AIMS Embedded Systems Programming MT 2015 27
n-Ary Relations: Another Example
Teamname: String
Score
Matchstadium: String
1..*2
1
D. Kroening: AIMS Embedded Systems Programming MT 2015 28
Aggregation
I Special case of association
I Read as “has a”
I Must not involve more than two classes
I Not a container relationship – no implications on lifetime
I Drawn with empty diamond
D. Kroening: AIMS Embedded Systems Programming MT 2015 29
Aggregation: Example
Professor Courseteaches 0..*+teacher +course
D. Kroening: AIMS Embedded Systems Programming MT 2015 30
Composition
I Special case of aggregation
I This is a container relationship:once the “owner” is destroyed, so is the object containedtherein
I “Owner” must have multiplicity 0..1 or 1
I Drawn with a filled diamond
D. Kroening: AIMS Embedded Systems Programming MT 2015 31
Composition: Example
Triangle Point3
D. Kroening: AIMS Embedded Systems Programming MT 2015 32
Templates
VectorTsize:int
I Classes may have templateparameters
I Corresponds to C++ templatesor Java generics
I Build an instance with Vector〈int,3〉
D. Kroening: AIMS Embedded Systems Programming MT 2015 33
Object Diagrams
S1: Studentname=’’John Smith”
I These are instances of classes
I Look like class diagrams,but the name is underlined
I The second compartmentcontains initializations
D. Kroening: AIMS Embedded Systems Programming MT 2015 34
Behavior Diagrams
I So far, we only saw Structure Diagrams
I No behavior on those defined so far – even the methodsare somewhat mysterious
I We will now look at Behavior Diagrams:I Use Case DiagramsI Activity DiagramsI State Machine DiagramsI Sequence Diagrams
D. Kroening: AIMS Embedded Systems Programming MT 2015 35
Use Case Diagrams
A Use Case Diagram...
is a description of system behavior withrespect to external entities such as humanusers or other systems.
D. Kroening: AIMS Embedded Systems Programming MT 2015 36
Use Case Diagrams
Student Professor
Teaching
There areI use cases (ovals): these correspond to behavior.
I actors (stick figures)
These diagrams are really informal.
D. Kroening: AIMS Embedded Systems Programming MT 2015 37
Use Case Diagrams: Use Case Extension
Student Professor
Teaching
Tutorial Class Lecture
I Use cases can be specialized/extended
I This is like inheritance – same notation
D. Kroening: AIMS Embedded Systems Programming MT 2015 38
Use Case Diagrams: Actor Extension
Student Professor
Teaching
BSc Student MSc Student
I Actors can be specialized/extended
I This is also like inheritance
D. Kroening: AIMS Embedded Systems Programming MT 2015 39
Activity Diagrams
study
eat watch TV
still interested
had enough
I There is a notion of an activecontrol location (the nodes)
I Change in semantics fromUML 1.x to 2.x!
I UML 2.0: Rounded boxes areactivities,semantics similar to Petri Nets
D. Kroening: AIMS Embedded Systems Programming MT 2015 40
Activity Diagrams: Building Blocks
Initial node
Activity final node
Flow final node
Conditional branch (somewhat redun-dant)
Merge (also redundant)
Fork: concurrency!
Join: process synchronization
D. Kroening: AIMS Embedded Systems Programming MT 2015 41
Semantics of Activity Diagrams
study
eat watch TV
still interested
had enough
vfvf
vfvf
vf vfvf vf
vf
I Idea: pass tokens around
I Forks replicate tokens,join nodes generate tokens ifthere are enough incomingtokens.
I Formalization: class assignment
D. Kroening: AIMS Embedded Systems Programming MT 2015 42
Activity Diagrams: Branches and Guards
I Guards should not overlap – theordering of evaluation is not defined
I The guards should be complete
I One of the edges may have a guard else
D. Kroening: AIMS Embedded Systems Programming MT 2015 43
State Machine Diagrams
A State Machine Diagram...
is a graphical representation of a finite statemachine.
On
Off
I These are a variant of Harel’sstatecharts (1987)
I Very popular in control engineering(automotive, aerospace, ...)
I Also see Martha’s Executable Biologycourse
D. Kroening: AIMS Embedded Systems Programming MT 2015 44
State Machine Diagrams: Building Blocks
Initial / Junction
Terminate
Entry Point / Exit Point / History (hier-archy)
Choice (somewhat redundant)
Fork
Join
trigger [guard] / action Transition with trigger, guard, and ac-tion
D. Kroening: AIMS Embedded Systems Programming MT 2015 45
State Machine Diagrams: Warmup Example
Twiddle thumbs
i=0
[i<10]/i++
[i>=10]
D. Kroening: AIMS Embedded Systems Programming MT 2015 46
Transitions in State Machine Diagrams
Trigger, ... [ Guard ] / Action
I Each part is optional
I A Trigger is typically an event identifier with arguments:Event ( Recv-Arguments . . . )
If there is more than one trigger: OR-semantics
I The Guard is a Boolean expression
I An Action can beI some assignment, function call,I a send-event command. Typical syntax:
Event ( Send-Arguments )
D. Kroening: AIMS Embedded Systems Programming MT 2015 47
Branches and Guards in State Machine Diagrams
I Guards should not overlap – the ordering of evaluationis not defined by the standard
I The guards need not be complete: you just stay in thecurrent state until a transition becomes enabled
D. Kroening: AIMS Embedded Systems Programming MT 2015 48
Events in State Machine Diagrams
I Idea: there is a finite set of events;events may be parameterized, e.g., button(1)
I Events may be external or internal
I There is a queue of events that have occurredI The ordering of dequeuing is not defined
I The processing of an event must be finishedbefore any other event is processed (run-to-completion)
D. Kroening: AIMS Embedded Systems Programming MT 2015 49
Events in State Machine Diagrams: Example
Start Dialtone Dialing Busy
Wrong Number
Busy
Ringing Connected
Pick up Dial(d) RecBusy
RecPickup
Hang up
Hang up Hang up Hang up
Hang up
Hang up
Timeout
WrongNr
GoodNr
I Those plentiful “Hang up” edges are annoying
I What about dialing more than one digit?
D. Kroening: AIMS Embedded Systems Programming MT 2015 50
Internal Transitions in State Machine Diagrams
DialtoneDial(d) / nr+=d
DialingDial(d)/ nr+=d
I Internal transitions are triggered only if the state containingthem is active
I May have triggers, guard, action
I They fire without leaving/re-entering the state
D. Kroening: AIMS Embedded Systems Programming MT 2015 51
Internal Actions
States may have special internal transitions defined using thefollowing prefixes:
I entry: executed when a state is entered
I exit: executed when a state is left
I do: ongoing activity while in the state
D. Kroening: AIMS Embedded Systems Programming MT 2015 52
Hierarchy in State Machine Diagrams
Outer State
Inner State 1
Inner State 2
I State machines may be nested,which yields hierarchy
I Transitions may cross hierarchyboundaries
I Advantage: May avoid manytransitions
I Hierarchy may be used to modelconcurrency
D. Kroening: AIMS Embedded Systems Programming MT 2015 53
Hierarchy in State Machine Diagrams: Example
Phone off the hook
Dialtone Dialing
Ringing
Busy
Wrong Number
Connected
Pick up
Dial(d) RecBusy
RecPickup
Timeout
WrongNr
GoodNr
Hang up
D. Kroening: AIMS Embedded Systems Programming MT 2015 54
Hierarchy in State Machine Diagrams: Example
Phone off the hook
Dialtone Dialing
Ringing
Busy
Wrong Number
Connected
Pick up
Dial(d) RecBusy
RecPickup
Timeout
WrongNr
GoodNr
Hang up
D. Kroening: AIMS Embedded Systems Programming MT 2015 55
State Machine Diagrams: History
Student Life
SleepEat
StudyPlay
Wait outside of building
Fire Alarm All Clear
I We have seen thathierarchy is useful tomodel exceptions
I But how about recovery?
Sometimes it is helpful toresume what youinterrupted.
I This is modelled by meansof a history node.
D. Kroening: AIMS Embedded Systems Programming MT 2015 56
State Machine Diagrams: History
I A transition to a history state restores the state that thechart was in when it was left.
I This is meant to be used as means to resume an activityafter an exception or the like.
I There may be one transition outgoing from a history state –this goes to the default state.
I There is also a deep history state:I Denoted by H∗
I Also restores the state of any sub-charts,e.g., within “Sleep” or “Eat”.
D. Kroening: AIMS Embedded Systems Programming MT 2015 57
Precedence Rules for Transitions
I What if multiple transitions are enabled?Which one is taken?
I There is only one rule:
UML Transition Precedence Rule
A transition out of a composite state s has a lowerprecedence than any transition out of anysub-state of s.
I This applies to UML State Machine Diagrams – Statechartdialects have all sort of additional rules.
D. Kroening: AIMS Embedded Systems Programming MT 2015 58
Concurrency in State Machine Diagrams
I You can use to obtain concurrent threads ofexecution
I There is an alternative, which is easier to manage
I There are both and-states and or-states in state charts
I or-states are what you are used to:you either “Eat” OR “Sleep” OR “Play”. . .
I and-states allow you to “Eat” AND “Play”
D. Kroening: AIMS Embedded Systems Programming MT 2015 59
Concurrency Example
Taking a Course
Practical 1 Practical 2 Practical 3 Practical 4
Class 1 Class 2 Class 3 Class 4
Exam
PassFail
fail
pass
I Concurrent threads denoted by means of “swimlanes”I Composite activity ends once all composed activities end
D. Kroening: AIMS Embedded Systems Programming MT 2015 60
Sequence Diagrams
A Sequence Diagram...
defines the behavior of objectsby describing the messagesthey pass.
Mike John
How are you doing?
Good, and you?
I Horizontal axis: the objects oractors
I Vertical axis: time
D. Kroening: AIMS Embedded Systems Programming MT 2015 61
Sequence Diagrams: Building Blocks
Mike: PersonObject with type and lifeline
i++ Synchronous message
i++ Asynchronous message
return Return from method
Control
D. Kroening: AIMS Embedded Systems Programming MT 2015 62
Notation for Messages
1: hello Messages can be numbered
2: buy(”tuna sandwich”) Messages can have parameters
Messages can be self-referential
D. Kroening: AIMS Embedded Systems Programming MT 2015 63
Synchronous vs. Asynchronous Messages
Synchronous: The caller waits for the completion of the ex-ecution of the operation
Asynchronous: The caller does not wait for the completionof the execution of the operation, but insteadcontinues immediately
D. Kroening: AIMS Embedded Systems Programming MT 2015 64
Lifetime vs. Control
A
B
foo(1,2,3)
A
B
foo(1,2,3)
D. Kroening: AIMS Embedded Systems Programming MT 2015 65
Sequence Diagrams: Webshop Example
Client Webshop Mastercard
‘‘BUY(card, product)”
‘‘AUTHORIZE(card, amount)”
‘‘RESULT(status)”
‘‘BUILD_PAGE(status)”
D. Kroening: AIMS Embedded Systems Programming MT 2015 66
Semantics of Sequence Diagrams
I A sequence diagram defines a partial ordering on the timean event (send/receive) occurs.
I Rules (causal order):
1. Send before matching receive2. Receive or send before send of same process3. Two receives on the same process sent from the same
process
WARNING:
No other guarantees provided,even if suggested by diagram!
D. Kroening: AIMS Embedded Systems Programming MT 2015 67
Races in Sequence Diagrams
AB
I Let ≺v be the visual ordering,and ≺c the causal ordering
I A diagram has a race iff there existsa trace M1, . . . ,Mn with
M1 ≺c M2 . . . ≺c Mn
but not
M1 ≺v M2 . . . ≺v Mn
D. Kroening: AIMS Embedded Systems Programming MT 2015 68
Sequence Diagrams: Webshop Example Again
Client Webshop Mastercard
‘‘BUY(card, product)”
‘‘PLEASE_WAIT’’‘‘AUTHORIZE(card, amount)”
‘‘RESULT(status)”‘‘BUILD_PAGE(status)”
D. Kroening: AIMS Embedded Systems Programming MT 2015 69
Combining Sequence Diagrams
Meeting
Mike John
How are you doing?
Good, and you?
Sequence diagrams can becombined or integrated intoother diagrams by adding aframe
D. Kroening: AIMS Embedded Systems Programming MT 2015 70
Combining Sequence Diagrams
C1
P1 P2
A
B
C2
P1 P2
C
C3
P2 P3
D
These are calledHigh-levelMessageSequence Charts(HMSCs)
Does this onehave a race?
D. Kroening: AIMS Embedded Systems Programming MT 2015 71