telecom and informatics 1 inf5120 uml2 and sysml, objecteering soa support ”modelbased system...

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


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


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

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

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.


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

travelPermissionRequestexpenceReport

External view

Defines a set of messages that may be sent from one

role to another.


Objects play several roles

ProjectManager

ProjectParticipant

Ruth


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

1. Sep. of concern and composition on one abstraction level

2. Sep. of concern and composition between abstraction levels

3. Specialization - generalization


UML 2.0

With contributions from Øystein Haugen, SINTEF &

Birger Møller-Pedersen, UiO


UML 2.0


UML standardization within OMG – for Ericsson (Haugen, Møller-Pedersen)

EricssonUML standardization

team

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


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


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


ATM: Domain Model I

CardAccount

User ATM Bank

1

*

1

*

* 1* *

myAccount

11

FromHaugen, Ø., 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


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


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


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


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

No


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.


(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


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


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


sm EnterPIN

enterDigit

send(msg(”Give PIN”)); n=1; PIN=0

waitOK

digit [n=4] / PIN=PIN+digitsend(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 ATMsm 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


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: integercid: integersa: 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


Simple GetAmount

sm GetAmount

:SelectAmount

Send(msg(”select amount”))

amount(sa);

cancelcancelled

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


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 getAmountredefined giveMoney

Withdrawal

redefined getAmountredefined giveMoney

Currency

formal

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


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!")

:ATMref 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


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!")

:ATMref ATM_Authenticate

PIN NOK

notice the correspondance!

notice the correspondance!


Nested sequence diagrams


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


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


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


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


Objecteering SOA solution and tool support

57


Objecteering for SOA

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

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

telecom and informatics 1 inf5120 uml2 and sysml, objecteering soa support ”modelbased system...

Documents