Upload
vanlien
View
232
Download
0
Embed Size (px)
Citation preview
INF5120 Model based System Development 02.02.2009
1
Telecom and Informatics 1
INF5120
UML2 and SysML,
Objecteering SOA support
”Modelbased System development”
Lecture 3: 02.02.2009Arne-Jørgen Berre
Telecom and Informatics 2
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
INF5120 Model based System Development 02.02.2009
2
Telecom and Informatics 3
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
OOram – Role modeling
� Methodology from UIO/SINTEF from 1996
� Book: Working with Objects,
� Prof. Trygve Reenskaug & al
4
INF5120 Model based System Development 02.02.2009
3
Telecom and Informatics
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 Authorizer
Book-
keeper
Pay-
master
A role abstraction:
- A general role played by
many objects
- Part of the responsibility
for an object
Telecom and Informatics
State diagram view
Traveler Authorizer
SD
Book-
keeper
Pay-
master
au
bo
pm
tr
TransitionName of message
Possible
States
1
23
travelRequest
Internal 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.
INF5120 Model based System Development 02.02.2009
4
Telecom and Informatics
Interface view
Traveler Authorizer
SD
Book-
keeper
Pay-
master
bo
trau
pm
A rounded rectangle denotes an interface.
A dashed line associates the symbol with a port.
<Interface name> is the name of an interface or a port.
<Message list> is either a list of messages or a list of interface names.
<Interface name>
<Message list>
Authorizer<Traveler
travelPermissionRequest
expenceReport
External view
Defines a set of messages
that may be sent from one
role to another.
Telecom and Informatics
Objects play several roles
ProjectManager
ProjectParticipant
Ruth
INF5120 Model based System Development 02.02.2009
5
Telecom and Informatics
AuthorizerTraveler Secretary PaymasterBookkeeper TravelAgent
Synthesis of ExpenseReport and
AirlineBooking
Traveler
Traveler
Authorizer PaymasterBookkeeper
Secretary PaymasterBookkeeper TravelAgent
ExpenseReport
AirlineBooking
CompositModel
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
INF5120 Model based System Development 02.02.2009
6
Telecom and Informatics 11
UML 2.0
With contributions from Øystein Haugen, SINTEF &
Birger Møller-Pedersen, UiO
Telecom and Informatics 12
UML 2.0
INF5120 Model based System Development 02.02.2009
7
Telecom and Informatics 13
UML standardization within OMG –
for Ericsson (Haugen, Møller-Pedersen)
Ericsson
UML standardization
team
developers
world-wide
Requirements from
improved
contributing
in cooperation
with
tool vendors
issuing
requirements
in cooperation
with alllies
better tools
Telecom and Informatics 14
U2 Partners
� 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
2P2P
INF5120 Model based System Development 02.02.2009
8
Telecom and Informatics 15
Why UML2.0?
� for Ericsson, Motorola, Alcatel, Nokia (telecom, realtime)
� SDL/MSC only one vendor
� UML/ROOM (as by RoseRT) 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 16
Very Short History
� December 1999 RFI (Request For Information)
� 29 Responses to the RFI
� Ericsson made a joint response with Motorola and Alcatel (and Nokia)
� September 2000 RFP (Request For Proposal)
� October 2001 Initial submission
� August 2002 Revised submission
� June 2003 Recommended for adoption
� then Finalization Task Force
� July 2005 Available technology
� then Revision Task Force
� February 2006 UML 2.1 for approval
� http://www.omg.org/cgi-bin/doc?ptc/06-01-02.htm
INF5120 Model based System Development 02.02.2009
9
Telecom and Informatics 17
SDL
UML
ROOM??
!
Snapshot
from one of
the meetings
Telecom and Informatics 18
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
INF5120 Model based System Development 02.02.2009
10
Telecom and Informatics 19
ATM: Domain Model I
Card
Account
User ATM Bank
1
*
1
*
* 1* *
myAccount
11
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 20
Domain Model II
Keyboard CashDispenserCardReader Screen
ATM
INF5120 Model based System Development 02.02.2009
11
Telecom and Informatics 21
Use Case Model
ATM
«include»
«include»
UserBank
Withdrawal
CashRepository
Currency
Authentication
Telecom and Informatics 22
Context model with UML1.x class
diagrams � with plain composition and no encapsulation
� with only provided interfaces on classes
User Bank
Keyboard CashDispenserCardReader Screen
ATM
User-ATM ATM-Bank
INF5120 Model based System Development 02.02.2009
12
Telecom and Informatics
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.
23
Telecom and Informatics
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.
24
INF5120 Model based System Development 02.02.2009
13
Telecom and Informatics 25
Composite class (incomplete)
� with parts, ports and connectors
ATM
:CardReader
:CashDispenser:Keyboard
User-Reader
User-Keyboard
ATM-bank
User-Cash
:ScreenUser-Screen
part
port
connector
Telecom and Informatics 26
Context Model in UML2.0 - I
� composite structure as part of a Collaboration
BankContext
:User :ATM :Bank
User-Reader
User-Keyboard
ATM-bank
User-Cash
User-Screen
INF5120 Model based System Development 02.02.2009
14
Telecom and Informatics 27
Context Model in UML2.0 - II
� Including multiplicities on parts
BankContext
:User
[1..10000]
:ATM
[1..100]:Bank
User-Reader
User-Keyboard
ATM-bank
User-Cash
User-Screen
multiplicity
Telecom and Informatics 28
BankContext
@ as part of Packages?
:User
[1..10000]
:ATM
[1..100]:Bank
User-Reader
User-Keyboard
ATM-bank
User-Cash
User-Screen
�o
INF5120 Model based System Development 02.02.2009
15
Telecom and Informatics 29
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 30
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.
INF5120 Model based System Development 02.02.2009
16
Telecom and Informatics 31
(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
sd EnterPIN
:Bank:User :ATM
msg(”Give PIN”)
Digit
Digit
Digit
Digit
Code(cid, pin)
PIN OK
OK
The frame
(UML 2)
The name of the interaction
Send Event
Receive Event
Message name
Continuation
Telecom and Informatics 32
Combined fragment example
combined fragment
frame
operator
operand
separator
sd EnterPIN
:Bank:User :ATM
msg(”Give PIN”)
Digit
Digit
Digit
Digit
Code(cid, pin)
alt
PIN NOK
PIN OK
NOK
OK
INF5120 Model based System Development 02.02.2009
17
Telecom and Informatics 33
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 34
:Bank:User
sd Authenticate
EnterPINref
loop(0,3)
EnterPINref
Idle
Cardid(cid)
msg("Try again!")
:ATM
PIN NOK
References (Interaction Use /
Occurrence)
reference
Continuation
INF5120 Model based System Development 02.02.2009
18
Telecom and Informatics 35
Nested combined fragments
:Bank:User
sd Withdrawal
Authenticateref
alt
PIN NOK
PIN OK
Withdrawal
msg("Give amount!")
ok
:ATM
amount(v) checkaccount(v)
alt money(v)
receipt(v)
nokmsg(”Amount too large”)
msg(”Illegal entry”)
card
card taken
Continuation
reference
combined fragment
nested fragment
Telecom and Informatics 36
sd Withdrawal
Authenticateref
PIN NOKPIN OK
okmoney(v)
receipt(v)
:Bank:User :ATM
sd
nok
msg(”Amount too large”)
:Bank:User :ATM
sd
msg(”Illegal entry”)
:User :ATM
sd
card
card taken
:User :ATM
sd
Withdrawal
msg("Give amount!")
amount(v) checkaccount(v)
:Bank:User :ATM
sd
Interaction Overview Diagram
Continuation
reference
combined fragment
nested fragment
Inline diagram
INF5120 Model based System Development 02.02.2009
19
Telecom and Informatics 37
sm EnterPIN
enterDigit
send(msg(”Give PIN”)); n=1; PIN=0
waitOK
digit [n=4] / PIN=PIN+digit
send(Code(cid,PIN))
ok
digit [n<4]/
n++;
PIN= PIN+digit*10(3-n)
noknok
ok
EnterPIN state machine
n:integerPIN: integer
<<statemachine>>
EnterPIN
definition of exit point
trigger
guard
effect
Telecom and Informatics 38
Statemachine for the ATM
sm ATM
:Withdrawal
entry: send(card)
CardOut
:EnterPIN
/authN=0
Idle
CardId(cid)
[authN<3]/
authN++;
send(msg(”Try again”))
/authN=0
[authN==3]/
authN=0
send(msg(
”illegal entry”));
nok
ok
cancelledok
:Status
:Service
statusWithdrawal
cardTaken
use of exit point
submachine state
INF5120 Model based System Development 02.02.2009
20
Telecom and Informatics 39
Attributes of the ATM
� Statemachine is a Classifier
(that is class-like):
� Attributes
� Operations (local actions)
� Behaviors (e.g. state machines)
� authN number of tries
� cid card id
� sa selected amount
sendMoney(a:Amount)
authN: integer
cid: integer
sa: Amount
<<statemachine>>
ATM
Telecom and Informatics 40
State machine Withdrawal
sm Withdrawal
:GetAmountcancelled
VerifyTransaction
send(CheckAccount(sa)) nok/
send(msg(”Amount too large”))
ok
ok/
sendMoney(sa);
send(Receit(sa));
again
cancelled
use of entry point
INF5120 Model based System Development 02.02.2009
21
Telecom and Informatics 41
Simple GetAmount
sm GetAmount
:SelectAmount
Send(msg(”select amount”))
amount(sa);
cancel
cancelled
again
Send(msg(”select another amount”))
definition of entry point
Telecom and Informatics 42
A service similar to Withdrawal:
Currency
:Bank:User
sd Currency
Authenticateref
alt
PIN NOK
PIN OK
Currency
msg("Give currency!")
ok
:ATM
amount(e) checkaccount(v(e))
altEUR(e)
receipt(v)
nokmsg(”Amount too large”)
msg(”Illegal entry”)
card
EUR
msg("Give amount!")
[enough on account]
[inadequate funds]
card taken
:Bank:User
sd Withdrawal
Authenticateref
alt
PIN NOK
PIN OK
Withdrawal
msg("Give amount!")
ok
:ATM
amount(v) checkaccount(v)
alt money(v)
receipt(v)
nokmsg(”Amount too large”)
msg(”Illegal entry”)
card
card taken
INF5120 Model based System Development 02.02.2009
22
Telecom and Informatics 43
Interactions are generalizable and
redefinable
:Bank:User
sd GenWithdrawal
Authenticationref
alt
PIN NOK
PIN OK
ok
:ATM
checkaccount(v(e))
alt
receipt(v)
nokmsg(”Amount too large”)
msg(”Illegal entry”)
card
[enough on account]
[inadequate funds]
getAmount
ref
giveMoneyref
card taken
Currency
msg("Give currency!")
amount(e)
EUR
msg("Give amount!")
sd getAmount
:User :ATM
EUR(e)
sd giveMoney
:User :ATM
ok
sd getAmountsd giveMoney
GenWithdrawal
redefined getAmount
redefined giveMoney
Withdrawal
redefined getAmount
redefined giveMoney
Currency
form
al
gate
actual
gate
Telecom and Informatics 44
ATM revisited - generalised
sm ATM
entry: send(card)
CardOut
:EnterPIN
/authN=0
Idle
CardId(cid)
[authN<3]/
authN++;
send(msg(”Try again”))
/authN=0
[authN==3]/
authN=0
send(msg(
”illegal entry”));
nok
ok
:Status
:Service
status
cardTaken
INF5120 Model based System Development 02.02.2009
23
Telecom and Informatics 45
Extended state machines
sm WithdrawalATM
:Withdrawal
CardOut
cancelledok
:Service
{extended}
Withdrawal
sm CurrencyATM
:Currency
CardOut
cancelledok
:Service
{extended}
Currency
Telecom and Informatics 46
:Bank:User
sd Authenticate
EnterPINref
loop(0,3)
EnterPINref
Idle
Cardid(cid)
msg("Try again!")
:ATM
ref ATM_Authenticate
PIN NOK
Decomposing a Lifeline wrt an
Interaction
we want to look into
this lifeline
this is the name of
the diagram where
we find the
decomposition
INF5120 Model based System Development 02.02.2009
24
Telecom and Informatics 47
Decomposition
:Keyboard :Controller:CardReader
sd ATM_Authenticate
ATM_EnterPINref
loop(0,3)
ATM_EnterPINref
ATM_Idle
Cardid(cid)
msg("Try again!")
:CashDispenser
ATM_PIN NOK
msg("Try again!")
Cardid(cid)
:Screen
Code(cid, pin)
NOK
Code(cid, pin)
OK, NOK
:Bank:User
sd Authenticate
EnterPINref
loop(0,3)
EnterPINref
Idle
Cardid(cid)
msg("Try again!")
:ATM
ref ATM_Authenticate
PIN NOK
notice the
correspondance!
notice the
correspondance!
Telecom and Informatics 48
Nested sequence diagrams
INF5120 Model based System Development 02.02.2009
25
Telecom and Informatics 49
Composite (design) class
ATM
:CardReader
:CashDispenser:Keyboard
:Controller
User-Reader
User-Keyboard
ATM-bank
User-Cash
:ScreenUser-Screen
Telecom and Informatics 50
Structured Classes are like other
Classes
� Structured Classes may have� attributes & operations, interfaces, \
� Internal structure is inherited, inherited parts may be redefined by extension
ATM
:CardReader
:CashDispenser:Keyboard
:Controller
User-Reader
User-Keyboard
ATM-bank
User-Cash
:ScreenUser-Screen
INF5120 Model based System Development 02.02.2009
26
Telecom and Informatics 51
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 52
What is special for Components
� Realization by a number of classes
INF5120 Model based System Development 02.02.2009
27
Telecom and Informatics 53
... 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 54
Deployment of components
� Artifacts,
� Nodes,
� Network of
Nodes,
� ...
INF5120 Model based System Development 02.02.2009
28
Telecom and Informatics 55
Must be profiled for actual
component models
Telecom and Informatics 56
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
INF5120 Model based System Development 02.02.2009
29
Telecom and Informatics
Objecteering SOA solution and tool
support
57
Telecom and Informatics
Objecteering for SOA
58
INF5120 Model based System Development 02.02.2009
30
Telecom and Informatics
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
59
Telecom and Informatics
OBLIG 1 – “Smart House Design” –
increments with group presentations� CIM models (BPMN)
� CIM models (Scope, Goal, Requirements)
� Requirements models
� SoaML models
60
OBLIG 2 – “Smart House mappings
and transformations”
� MOFScript transformations to Java and potentially to
different technologies/platforms
� Discussion on Model Driven Interoperability