INF5120
UML2 and SysML,
Objecteering SOA support
”Modelbased System development”
Lecture 3: 02.02.2009
Arne-Jørgen Berre
Telecom and Informatics
1
Lecture plan - 2009

1: 19/1: Introduction to MBSU, MDA, OO and Service/SOA modeling, Overall EA (AJB)






2: 26/1: MS I: Business Process Modeling (CIM) - with BPMN and BMM (AJB), Objecteering UML Modeler
3: 2/2: MS II: UML2 and SysML, Objecteering SOA and Scope, – Collaboration /Component models
4: 9/2: MS III: SoaML I (PIM) and Requirements modeling , CIM->PIM
5: 16/2:MDE I: Metamodeling , DSL and UML profiles, MDA technologies (XMI, Eclipse, EMF/GMF) (ARS)
6: 23/2: MS IV: Method Engineering and SPEM / EPF (BRE)
7: 2/3: MS V: SoaML II and Service Design (AJB)




8: 9/3: MDE II: Model transformations with MOScript, (ATL and QVT) – and JEE (GO)
9 :16/3:: MDE II: Code generation with MOFScript and other technologies (GO)
10: 23/3: MDE IV: PIM and Web Services teknologi (PSM) for SOA with WSDL/XML/BPEL (PSM) (BRE)
11: 30/3: MDI I: Model Driven Interoperability I (AJB)

EASTER



12: 20/4: MDE V: Open ArchitectureWare/Kermeta, Microsoft OSLO etc. (Neil, Franck, Anthe)
13: 27/4: MDI II: Model Driven Interoperability - II - Ontologies, Semantic web and Semantic Modeling (AJB)
14: 4/5: Course summary





Exam: May 29th, 2009 (Friday)
AJB – Arne J. Berre
BRE – Brian Elvesæter
GO – Gøran Olsen
ARS – Arnor Solberg
Telecom and Informatics
2
Next Lecture – February 9th, 2009
 MS III: (Modeling Services III)
 SoaML I - Service oriented architecture Modeling
Language – from a modeler’s perspective (PIM)
 Requirements modeling
 CIM->PIM mappings and transformations
Telecom and Informatics
3
OOram – Role modeling
 Methodology from UIO/SINTEF from 1996
 Book: Working with Objects,

Prof. Trygve Reenskaug & al
Telecom and Informatics
4
Role model
The role model is the basic abstraction in OOram. It is an object
oriented model of an object structure and represents a bounded part of
an interesting phenomen
Traveler
A role abstraction:
- A general role played by
many objects
- Part of the responsibility
for an object
Authorizer
Bookkeeper
Paymaster
Telecom and Informatics
State diagram view
Describes the possible states of the role, the signals that are acceptable in each
state, the action taken as a result of each signal, and the next state attained after
the action is completed.
Possible
States
Name of message
Transition
Inte rnal vie w
Telecom and Informatics
Interface view
Defines a set of messages
that may be sent from one
role to another.
E xte rnal vie w
Telecom and Informatics
Objects play several roles
ProjectManager
ProjectParticipant
Ruth
Telecom and Informatics
Synthesis of ExpenseReport and
AirlineBooking
ExpenseReport
Traveler
Authorizer
Bookkeeper
Paymaster
Secretary
Bookkeeper
Paymaster
TravelAgent
Secretary
Bookkeeper
Paymaster
TravelAgent
AirlineBooking
Traveler
CompositModel
Traveler
Authorizer
Telecom and Informatics
Use of synthesis
1. Sep. of concern and
composition on one
abstraction level
2. Sep. of concern and
composition between
abstraction levels
3. Specialization generalization
Telecom and Informatics
UML 2.0
With contributions from Øystein
Haugen, SINTEF &
Birger Møller-Pedersen, UiO
Telecom and Informatics
11
UML 2.0
Telecom and Informatics
12
UML standardization within OMG –
for Ericsson (Haugen, Møller-Pedersen)
better tools
improved
Requirements from
developers
world-wide
Ericsson
UML standardization
team
issuing
requirements
in cooperation
with alllies
contributing
in cooperation
with
tool vendors
Telecom and Informatics
13
U2 Partners
2P
 Submitters
 Alcatel, CA, Ericsson, Fujitsu, HP, IBM, I-Logix, IONA, Kabira,
Motorola, Oracle, Rational, SOFTEAM, Telelogic, Unisys
 Supporters
 Advanced Concepts Center LLC, Ceira Technologies,
Commissariat à L'Energie Atomique, Compuware,
DaimlerChrysler, Embarcadero Technologies, Enea Data, France
Telecom, Fraunhofer FOKUS, Gentleware, Intellicorp, Jaczone,
Kennedy Carter, Klasse Objecten, KLOCwork, Lockheed Martin,
Mercury Computer, MSC.Software, Northeastern University,
Popkin Software, Proforma, Sims Associates, Syntropy Ltd., Sun
Microsystems, University of Kaiserslautern, University of Kent,
VERIMAG, WebGain, and 88solutions
Telecom and Informatics
14
Why UML2.0?
 for Ericsson, Motorola, Alcatel, Nokia (telecom, realtime)
 SDL/MSC
 UML/ROOM (as by RoseRT)
only one vendor
only one vendor
 UML2.0 combining features from these
 for others
 Scalability, modeling of large, complex systems
 Improvement of existing concepts: activities, components,
 Completeness: action semantics, formal/precise definition
 in general
 Experiences with UML1.x required an improvement
 Model Based Development requires a good modeling language
Telecom and Informatics
15
!
??
ROOM
UML
SDL
Snapshot
from one of
the meetings
Telecom and Informatics
17
Example - ATM
 Domain statement
 An Automatic Teller Machine (ATM) is a system with mechanical as




well as electronic parts. Its purpose is to provide a bank user with
cash provided that the user can authenticate herself and she has
adequate funds in her bank account.
She authenticates herself by presenting a card to the ATM
cardreader, and a personal identification number (PIN) through the
ATM keyboard.
The ATM is connected electronically and possibly through some
kind of network to the bank such that the account status may be
checked online.
The ATM is refilled with cash notes regularly or when the number of
specific notes is below some limit.
The ATM may also provide foreign currency to the customer
Telecom and Informatics
18
ATM: Domain Model I
User
*
*
ATM
1
*
Bank
1
1
*
*
Card
1
1
Account
myAccount
From
Haugen, Ø., B. Møller-Pedersen, and T. Weigert,
Modeling Embedded Systems in UML 2.0, in
The Embedded Systems Handbook,
Richard Zurawski, Editor. 2005, CRC Press.
Telecom and Informatics
19
Domain Model II
ATM
CardReader
Keyboard
Screen
CashDispenser
Telecom and Informatics
20
Use Case Model
ATM
CashRepository
Withdrawal
User
«include»
Authentication
«include»
Bank
Currency
Telecom and Informatics
21
Context model with UML1.x class
diagrams
 with plain composition and no encapsulation
 with only provided interfaces on classes
ATM-Bank
User-ATM
ATM
User
CardReader
Keyboard
Bank
Screen
CashDispenser
Telecom and Informatics
22
UML Composite Diagrams
 Composite Diagrams
A composite structure diagram is a diagram that shows
the internal structure of a classifier, including its interaction
points to other parts of the system. It shows the
configuration and relationship of parts, that together,
perform the behavior of the containing classifier.
classes can be displayed as composite elements exposing
interfaces and containing ports and parts.
Telecom and Informatics
23
Part
 A part is an element that represents a set of one or more
instances which are owned by a containing classifier
instance. So for example, if a diagram instance owned a
set of graphical elements, then the graphical elements
could be represented as parts; if it were useful to do so, to
model some kind of relationship between them. Note that
a part can be removed from its parent before the parent is
deleted, so that the part isn't deleted at the same time.
A part is shown as an unadorned rectangle contained
within the body of a class or component element.
Telecom and Informatics
24
Composite class (incomplete)
part
 with parts, ports and connectors
ATM
User-Reader
User-Screen
port
:CardReader
ATM-bank
:Screen
User-Keyboard
:Keyboard
:CashDispenser
connector
User-Cash
Telecom and Informatics
25
Context Model in UML2.0 - I
 composite structure as part of a Collaboration
BankContext
User-Reader
ATM-bank
:User
User-Screen
:Bank
:ATM
User-Keyboard
User-Cash
Telecom and Informatics
26
Context Model in UML2.0 - II
 Including multiplicities on parts
multiplicity
BankContext
User-Reader
:User
[1..10000]
User-Screen
:ATM
[1..100]
ATM-bank
:Bank
User-Keyboard
User-Cash
Telecom and Informatics
27
… as part of Packages?
No
BankContext
User-Reader
:User
[1..10000]
User-Screen
:ATM
[1..100]
ATM-bank
:Bank
User-Keyboard
User-Cash
Telecom and Informatics
28
Sequence Diagrams (Interactions)
 Sequence Diagrams are
 simple
 powerful
 readable
 used to describe interaction sequences
 History
 Has been used for a number of years informally
 Standardized 1992 in Z.120 (Message Sequence Charts - MSC)
 Last major revision of MSC is from 1999 (called MSC-2000)
 Formal semantics of MSC-96 is given in Z.120 Annex B
 Included in UML from 1999, but in a rather simple variant
Telecom and Informatics
29
Purpose
 Emphasizes the interaction between objects indicating that
the interplay is the most important aspect
 Often only a small portion of the total variety of behavior is
described improve the individual understanding of an interaction
problem
 Sequence Diagrams are used to ...
 document protocol situations,
 illustrate behavior situations,
 verify interaction properties relative to a specification,
 describe test cases,
 document simulation traces.
Telecom and Informatics
30
(Simple) Sequence Diagram
 Messages have one send event, and one receive event.
 The send event must occur before the receive event.
 The send event is the result of an Action
 Events are strictly ordered along a lifeline from top to bottom
The frame
(UML 2)
sd EnterPIN
:User
The name of the interaction
:ATM
:Bank
msg(”Give PIN”)
Digit
Receive Event
Digit
Continuation
Digit
Digit
Code(cid, pin)
Send Event
OK
Message name
PIN OK
Telecom and Informatics
31
Combined fragment example
sd EnterPIN
:User
:ATM
:Bank
msg(”Give PIN”)
combined fragment
frame
Digit
Digit
Digit
operator
Digit
Code(cid, pin)
operand
separator
alt
NOK
PIN NOK
OK
PIN OK
Telecom and Informatics
32
Combined fragments of Interaction
 We want to express
 choices: alternative, option, break
 parallel merge
 loops
 We may also want to add other operators
 negation
 critical region
 assertion
 Other suggested operators that will not come in UML 2.0
 interrupt
 disrupt
Telecom and Informatics
33
References (Interaction Use /
Occurrence)
sd Authenticate
reference
:User
:ATM
:Bank
Idle
Cardid(cid)
Continuation
ref
EnterPIN
loop(0,3)
PIN NOK
msg("Try again!")
ref
EnterPIN
Telecom and Informatics
34
Nested combined fragments
reference
sd Withdrawal
:User
combined fragment
ref
:ATM
:Bank
Authenticate
alt
Continuation
PIN OK
nested fragment
Withdrawal
msg("Give amount!")
amount(v)
alt
checkaccount(v)
money(v)
ok
receipt(v)
nok
msg(”Amount too large”)
PIN NOK
msg(”Illegal entry”)
card
card taken
Telecom and Informatics
35
Interaction Overview Diagram
sd Withdrawal
reference
ref
combined fragment
Authenticate
PIN NOK
PIN OK
sd
:User
:ATM
sd
:Bank
Withdrawal
:User
msg("Give amount!")
nested fragment
amount(v)
:ATM
Continuation
msg(”Illegal entry”)
checkaccount(v)
sd
sd
:User
money(v)
:ATM
:Bank
ok
:User
:ATM
:Bank
nok
msg(”Amount too large”)
receipt(v)
Inline diagram
sd
:User
:ATM
card
card taken
Telecom and Informatics
36
EnterPIN state machine
trigger
guard
<<statemachine>>
EnterPIN
sm EnterPIN
send(msg(”Give PIN”)); n=1; PIN=0
n:integer
PIN: integer
effect
enterDigit
digit [n<4]/
n++;
PIN= PIN+digit*10(3-n)
digit [n=4] / PIN=PIN+digit
send(Code(cid,PIN))
nok
nok
waitOK
ok
ok
definition of exit point
Telecom and Informatics
37
Statemachine for the ATM
use of exit point
sm ATM
Idle
/authN=0
CardId(cid)
submachine state
/authN=0
:EnterPIN
:Service
ok
status
Withdrawal
nok
[authN<3]/
authN++;
send(msg(”Try again”))
:Withdrawal
[authN==3]/
authN=0
send(msg(
”illegal entry”));
ok
:Status
cancelled
CardOut
entry: send(card)
cardTaken
Telecom and Informatics
38
Attributes of the ATM
 Statemachine is a Classifier
(that is class-like):
 Attributes
 Operations (local actions)
 Behaviors (e.g. state machines)
<<statemachine>>
ATM
authN: integer
cid: integer
sa: Amount
 authN
 cid
 sa
number of tries
card id
selected amount
sendMoney(a:Amount)
Telecom and Informatics
39
State machine Withdrawal
sm Withdrawal
cancelled
cancelled
:GetAmount
again
send(CheckAccount(sa))
nok/
send(msg(”Amount too large”))
use of
entry point
VerifyTransaction
ok/
sendMoney(sa);
send(Receit(sa));
ok
Telecom and Informatics
40
Simple GetAmount
sm GetAmount
Send(msg(”select amount”))
cancel
cancelled
:SelectAmount
Send(msg(”select another amount”))
amount(sa);
again
definition of
entry point
Telecom and Informatics
41
A service similar to Withdrawal:
Currency
sd Withdrawal
sd Currency
:User
:ATM
ref
ref
Authenticate
alt
:User
:Bank
:ATM
:Bank
Authenticate
alt
PIN OK
PIN OK
Currency
Withdrawal
msg("Give currency!")
msg("Give amount!")
EUR
amount(v)
msg("Give amount!")
checkaccount(v)
checkaccount(v(e))
amount(e)
alt
[enough on account]
EUR(e)
ok
alt
money(v)
ok
receipt(v)
receipt(v)
msg(”Amount too large”)
[inadequate funds]
nok
nok
msg(”Amount too large”)
PIN NOK
PIN NOK
msg(”Illegal entry”)
msg(”Illegal entry”)
card
card
card taken
card taken
Telecom and Informatics
42
Interactions are generalizable and
redefinable
GenWithdrawal
sd GenWithdrawal
:User
ref
:ATM
:Bank
actual
gate
sd getAmount
sd giveMoney
Authentication
alt
Withdrawal
PIN OK
redefined getAmount
redefined giveMoney
sd getAmount
ref
Currency
redefined getAmount
redefined giveMoney
getAmount
:User
:ATM
checkaccount(v(e))
Currency
alt
ref
[enough on account]
msg("Give currency!")
ok
giveMoney
EUR
receipt(v)
msg(”Amount too large”)
nok
[inadequate funds]
form
al
gate
msg("Give amount!")
amount(e)
PIN NOK
msg(”Illegal entry”)
sd giveMoney
:User
:ATM
card
card taken
EUR(e)
Telecom and Informatics
ok
43
ATM revisited - generalised
sm ATM
Idle
/authN=0
CardId(cid)
/authN=0
:EnterPIN
:Service
ok
status
nok
[authN<3]/
authN++;
send(msg(”Try again”))
:Status
[authN==3]/
authN=0
send(msg(
”illegal entry”));
CardOut
entry: send(card)
cardTaken
Telecom and Informatics
44
Extended state machines
sm WithdrawalATM
sm CurrencyATM
:Service
{extended}
:Service
{extended}
Withdrawal
Currency
:Withdrawal
ok
CardOut
:Currency
cancelled
ok
cancelled
CardOut
Telecom and Informatics
45
Decomposing a Lifeline wrt an
Interaction
sd Authenticate
:User
:ATM
ref ATM_Authenticate
:Bank
Idle
Cardid(cid)
ref
EnterPIN
loop(0,3)
PIN NOK
msg("Try again!")
ref
this is the name of
the diagram where
we find the
decomposition
EnterPIN
we want to look into
this lifeline
Telecom and Informatics
46
Decomposition
sd Authenticate
:User
sd ATM_Authenticate
:ATM
ref ATM_Authenticate
:Bank
:CardReader
:CashDispenser
Idle
Cardid(cid)
ref
EnterPIN
:Screen
:Keyboard
:Controller
ATM_Idle
Cardid(cid)
Cardid(cid)
Code(cid, pin)
ref
ATM_EnterPIN
OK, NOK
loop(0,3)
loop(0,3)
PIN NOK
ATM_PIN NOK
msg("Try again!")
msg("Try again!")
ref
EnterPIN
ref
msg("Try again!")
Code(cid, pin)
ATM_EnterPIN
NOK
notice the
correspondance!
notice the
correspondance!
Telecom and Informatics
47
Nested sequence diagrams
Telecom and Informatics
48
Composite (design) class
ATM
User-Reader
User-Screen
:CardReader
:Controller
ATM-bank
:Screen
User-Keyboard
:Keyboard
:CashDispenser
User-Cash
Telecom and Informatics
49
Structured Classes are like other
Classes
ATM
User-Reader
:CardReader
:Controller
User-Screen
ATM-bank
:Screen
User-Keyboard
:Keyboard
:CashDispenser
User-Cash
 Structured Classes may have
 attributes & operations, interfaces, …
 Internal structure is inherited, inherited parts may be redefined by
extension
Telecom and Informatics
50
What about Components?
 Components have all the
properties of structured classes
Note that these are just
derived, that is they are
also defined for classes
Telecom and Informatics
51
What is special for Components
 Realization by a number of classes
Telecom and Informatics
52
... and
 may be kind of ‘package’, i.e. it may have model
elements that you would not have for classes
A component may have
e.g. use cases, sequence
diagrams, packages,
dependencies, components
Telecom and Informatics
53
Deployment of components
 Artifacts,
 Nodes,
 Network of
Nodes,
 ...
Telecom and Informatics
54
Must be profiled for actual
component models
Telecom and Informatics
55
Finally
 Tools







Objecteering
IBM Rational Software Modeler (eller Architect)
Telelogic
real-time, telecom, but moving towards general
I-Logix
real-time, telecom, control systems
Softteam
general, with emphasis on profiling
MagicDraw
Enterprise Architect
 Books
 UML 2.0 in a nutshell, Dan Pilone and Neil Pitman
Telecom and Informatics
56
Objecteering SOA solution and tool
support
Telecom and Informatics
57
Objecteering for SOA
Telecom and Informatics
58
OBLIG 1 and 2: – “Smart House”









Design a platform independent Smart house system:
6 groups of 4 people:
1. Alarm-system
2. Temperature control
3. Video surveillance
4. Lightning and equipment control (X10)
5. Media control – Music/picture/video server
6. Integration group
- or combine from above
 Design for use of commercially available sensors and
equipment, initially map to Java simulation, secondly map
to technology platforms/device control
Telecom and Informatics
59
OBLIG 1 – “Smart House Design” –
increments with group presentations




CIM models (BPMN)
CIM models (Scope, Goal, Requirements)
Requirements models
SoaML models
OBLIG 2 – “Smart House mappings
and transformations”
 MOFScript transformations to Java and potentially to
different technologies/platforms
 Discussion on Model Driven Interoperability
Telecom and Informatics
60