UML2 and SysML, Objecteering SOA support ”Modelbased ... · INF5120 Model based System...

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


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


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

OOram – Role modeling

� Methodology from UIO/SINTEF from 1996

� Book: Working with Objects,

� Prof. Trygve Reenskaug & al

4


3


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


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.


4


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.


Objects play several roles

ProjectManager

ProjectParticipant

Ruth


5


AuthorizerTraveler Secretary PaymasterBookkeeper TravelAgent

Synthesis of ExpenseReport and

AirlineBooking

Traveler

Traveler

Authorizer PaymasterBookkeeper

Secretary PaymasterBookkeeper TravelAgent

ExpenseReport

AirlineBooking

CompositModel


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


6


UML 2.0

With contributions from Øystein Haugen, SINTEF &

Birger Møller-Pedersen, UiO


UML 2.0


7


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


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


8


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


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


9


SDL

UML

ROOM??

!

Snapshot

from one of

the meetings


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


10


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.


Domain Model II

Keyboard CashDispenserCardReader Screen

ATM


11


Use Case Model

ATM

«include»

«include»

UserBank

Withdrawal

CashRepository

Currency

Authentication


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


12


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


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


13


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


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


14


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


BankContext

@ as part of Packages?

:User

[1..10000]

:ATM

[1..100]:Bank

User-Reader

User-Keyboard

ATM-bank

User-Cash

User-Screen

�o


15


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


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.


16


(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


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


17


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


:Bank:User

sd Authenticate

EnterPINref

loop(0,3)

EnterPINref

Idle

Cardid(cid)

msg("Try again!")

:ATM

PIN NOK

References (Interaction Use /

Occurrence)

reference

Continuation


18


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


sd Withdrawal

Authenticateref

PIN NOKPIN OK

okmoney(v)

receipt(v)

:Bank:User :ATM

sd

nok

msg(”Amount too large”)

:Bank:User :ATM

sd


:User :ATM

sd

card

card taken

:User :ATM

sd

Withdrawal

msg("Give amount!")


:Bank:User :ATM

sd

Interaction Overview Diagram

Continuation

reference

combined fragment

nested fragment

Inline diagram


19


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


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


20


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


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


21


Simple GetAmount

sm GetAmount

:SelectAmount

Send(msg(”select amount”))

amount(sa);

cancel

cancelled

again

Send(msg(”select another amount”))

definition of entry point


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)



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


alt money(v)

receipt(v)



card

card taken


22


Interactions are generalizable and

redefinable

:Bank:User

sd GenWithdrawal

Authenticationref

alt

PIN NOK

PIN OK

ok

:ATM

checkaccount(v(e))

alt

receipt(v)



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


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


23


Extended state machines

sm WithdrawalATM

:Withdrawal

CardOut

cancelledok

:Service

{extended}

Withdrawal

sm CurrencyATM

:Currency

CardOut

cancelledok

:Service

{extended}

Currency


: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


24


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!


Nested sequence diagrams


25


Composite (design) class

ATM

:CardReader


:Controller

User-Reader

User-Keyboard

ATM-bank

User-Cash

:ScreenUser-Screen


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


:Controller

User-Reader

User-Keyboard

ATM-bank

User-Cash

:ScreenUser-Screen


26


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


What is special for Components

� Realization by a number of classes


27


... 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


Deployment of components

� Artifacts,

� Nodes,

� Network of

Nodes,

� ...


28


Must be profiled for actual

component models


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


29


Objecteering SOA solution and tool

support

57


Objecteering for SOA

58


30


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


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

UML2 and SysML, Objecteering SOA support ”Modelbased ... · INF5120 Model based System...

Documents

Transcript of UML2 and SysML, Objecteering SOA support ”Modelbased ... · INF5120 Model based System...