Modeling the ODP Computational Viewpoint with UML 2.0

Modeling the ODP Computational Viewpoint

with UML 2.0

José Raúl Romero, José Raúl Romero, Antonio VallecilloAntonio Vallecillo

Universidad de Málaga, SpainUniversidad de Málaga, Spain

Dept. Lenguajes y Ciencias de la ComputaciónDept. Lenguajes y Ciencias de la Computación

{jrromero,av}@lcc.uma.es {jrromero,av}@lcc.uma.es

Geneva, October 11, 2005 ITU-T SG17 Meeting2

LOGOAgenda

1. The Reference Model for Open Distributed

Processing

2. A (graphical) notation for the ODP CV

3. Modeling the ODP CV with UML 2.0

4. Issues for discussion

5. Conclusions


LOGOImportant

Acknowledgements This work has been developed within WG19 of

ISO/JTC1/SC7, in the context of the development of ISO/IEC 19793 | ITU-T Rec. X.906: “Use of UML for ODP system specification”

Although the views in this presentation are the authors’ solely responsibility, they could not have been formulated without the previous work and the many hours of detailed discussions with ISO experts on ODP, who have been involved in investigating and addressing the problems of the UML specification of ODP systems. Special mention deserve Akira Tanaka, Peter Linington and Bryan Wood.

Disclaimer This presentation describes work in progress, that may

(and will) change as the ISO/IEC Standard 19793 | ITU-T Rec. X.906 is developed.


LOGOThe Reference Model for Open Distributed Processing (I)

RM-ODP is a framework for ODP standardization and system specification covering all aspects of distributed systems: enterprise business, system, technology, distribution,… comprehensive and coherent object-oriented modeling concepts based on separation of concerns: viewpoint specifications Transparencies Common functions Viewpoints Different abstractions of the same system Reflect different concerns Expressed in terms of specific viewpoint languages Powerful mechanism for dealing with the complexity of

distributed systems


LOGOViewpoint languages and notations

ODP Viewpoint languages are abstract, i.e., ODP does not prescribe any notation for expressing viewpoint specifications

Without a concrete syntax… it is difficult to write ODP specifications there is no tool support no analysis of the specifications (formal or informal) the industrial acceptance and application of ODP might be hindered

Formal methods are convenient for precise/unambiguous interpretation of ODP concepts and specifications (eg. Z, Object-Z, LOTOS, maude, …)

… … but traditionally uselessbut traditionally useless

The Reference Model for Open Distributed Processing (II)

We need a general-purpose modeling We need a general-purpose modeling notation, familiar to developers, easy notation, familiar to developers, easy to learn and to use, with commercial to learn and to use, with commercial

tool support …tool support …


LOGOISO/IEC 19793 | ITU-T Rec X.906: Use of UML for ODP system specification

A standard defining: a set of UML Profiles for expressing a system

specification in terms of viewpoint specifications possible relationships between the resultant ODP

viewpoint specifications and how they are represented the structure of a system specification expressed as a

set of UML models using ODP viewpoint profiles

Target audiences of ISO/IEC 19793 | ITU-T Rec. X.906 UML Modelers, that need to structure (somehow) their

LARGE system specifications ODP Modelers, that need some (graphical) notation for

expressing their ODP specifications and tool support Tool vendors


LOGO

ODPODPSystemSystem

EnterpriseEnterprise

ComputationComputation

InformationInformation

TechnologyTechnology

EngineeringEngineering

The RM-ODP viewpoints

Hard- and software componentsThat implement the system

Mechanisms and services for distribution

transparencies

Information, changes,

constraints

Business aspects

who? why?

Configuration of objects

interacting at interfaces

The Reference Model for Open Distributed Processing (III)


LOGO

The Computational Viewpoint describes the functionality of the ODP system and its environment through the decomposition of the system into objects, which interact at interfaces, in a distribution transparent manner.

Computational specificationsThe Reference Model for Open Distributed Processing (and IV)

A Computational Specification describes the functional decomposition of an ODP system as: A configuration of computational objects; The internal actions of those; The interactions among those objects; Environment contracts for those objects and their

interfaces.


LOGO

ODP-CV ODP-CV ConceptsConcepts

Graphical notation for the ODP-CV (I)

UML 1.4+ was already proposed for ODP computational VP modeling: UML Profile for EDOC (Component Collaboration Architecture – CCA) Distributed System design within the DSE4DS Project (Akehurst et al.) +

CQML (for environment contracts)

Mapping to UML elementsMapping to UML elements UML 1.x UML 1.x ApproachesApproaches

Previous approaches

Very complete and precise approaches, but …

There is a big gap between the ODP and UML 1.x concepts Which made UML 1.X proposals too large and complex for a

wide industrial acceptance

José Raúl Romero

As a result, too large and complex approaches


LOGO

ODP-CV ODP-CV MetamodelMetamodel

Graphical notation for the ODP-CV (and II)

UML 2.0 provides several improvements to UML 1.x that make it more suitable for modeling the software architecture of large distributed systems The addition of new diagrams (e.g., interaction overview

diagrams, timing diagrams, etc.) and enhancements to the existing ones (e.g., the component diagram)

The influence of the mature SDL language and the MSCs The fully alignment of OCL with UML 2.0 The enhancement of the language extension mechanisms

Mapping to UML Mapping to UML elementselements

UML 2.0 Profile for the UML 2.0 Profile for the ODP Computational ODP Computational

ViewpointViewpoint

Unified Modeling Language v2.0


LOGORelationships between UOD, ODP specifications, and UML models

Universe

of Discourse

(UOD)

ODP

specification UML

model

Notation suitable for representing a

UML model

models (see RM-ODP)

maps to

(UML4ODP)

expresses (see UML spec)


LOGOModeling the ODP-CV in UML 2.0 (I)The UML 2.0 Profile for the ODP Computational Viewpoint

The UML Profile defines the stereotypes, tags and

constraints that allow us to use the

specific domain terminologyThe profile presented here serves as input to

the WG19 forthcoming standard on ISO/IEC 19793 | ITU-T Rec. X.906:

UML for ODP system specifications(2nd CD due next month)


LOGOThe Profile is based on a Metamodel for the ODP Computational Viewpoint


LOGOModeling the ODP-CV in UML 2.0 (II)

ODP conceptODP concept UML elementUML element

Computational object templateComponent

<<CV_CompObjectTemplate>>

Computational objectInstanceSpecification (from

Component)<<CV_Object>>

Computational interface templatePort

<<CV_CompInterfaceTemplate>>Tags {objectRole, type}

Computational interface

Interaction point (Port at instance level)

<<CV_SignalInterface>>

<<CV_OperationInterface>>

<<CV_StreamInterface>>

Computational interface signature

Interface<<CV_SignalInterfaceSignature>>

<<CV_OperationInterfaceSignature>>

<<CV_StreamInterfaceSignature>>

Computational objects and interfaces

José Raúl Romero

Nuestra contribución es modelar los elementos de ODP ...













































































José Raúl Romero

Nuestra contribución es modelar los elementos de ODP ...


LOGOModeling the ODP-CV in UML 2.0 (III)


Signals and operations

Message<<CV_Signal>>

<<CV_Invocation>>

<<CV_Termination>>

<<CV_Announcement>>

Flows (in terms of signals) Message/Interaction

<<CV_Flow>>

Interaction signatures (individual signals)

Reception<<CV_SignalSignature>>

<<CV_InvocationSignature>>

<<CV_TerminationSignature>>

<<CV_AnnouncementSignature>>

<<CV_FlowSignature>>

Interaction signatures (operations)

Operation<<CV_InterrogationSignature>>

Interactions






<<CV_Invocation>>

<<CV_Termination>>

<<CV_Announcement>>


<<CV_Flow>>









Interactions






<<CV_Invocation>>

<<CV_Termination>>

<<CV_Announcement>>


<<CV_Flow>>









Interactions






<<CV_Invocation>>

<<CV_Termination>>

<<CV_Announcement>>


<<CV_Flow>>









Interactions


LOGOUML Profile (I)


LOGOUML Profile (II)


LOGOUML Profile (III)


LOGOUML Profile (IV)


LOGOModeling the ODP-CV in UML 2.0 (IV)Specifying ODP systems

Behaviour is described in terms of:− Interaction models (message passing)

− Activity models (sequence, i/o, …)

− Statecharts (changes caused by events, …)

validate item

get item

detail

validate user

get user

userfines

check finesfines

Update loanvalidItem

validUser

User ManagerItem Manager Fine Control System Borrowing System

: Itemdetail

[Accepted]

[Rejected]

[Accepted]

[Rejected]

validate item

get item

detail

validate user

get user

userfines

check finesfines


validUser


: Itemdetail

[Accepted]

[Rejected]

[Accepted]

[Rejected]

[ ]

{interactionOperand = , interactionOperator = alt}

alt

: IUserMgnt : IItemMgnt: Assistant : IBorrow : ILoan : IFine

«CV_Announcement»

«CV_Announcement»

«CV_Announcement»

«CV_Announcement»

«CV_Announcement»

{ due date is over }

«CV_Termination»

«CV_Invocation»

returnItem( userId=, itemId= )1:

getLoan 2:

fine( userId=, amount= )4:

removeLoan( id= )6:

freeItem( id= )7:

getLoanResponse 3:

suspendUser 5: [ ]


alt


«CV_Announcement»

«CV_Announcement»

«CV_Announcement»

«CV_Announcement»

«CV_Announcement»


«CV_Termination»

«CV_Invocation»


getLoan 2:


removeLoan( id= )6:

freeItem( id= )7:

getLoanResponse 3:

suspendUser 5:

<<CV_ObjectTemplate>>BorrowingSystem

borrow : IBorrow

toFineSystem : IFine

toUserMgr : IUserMgnt

toItemMgr : IItemMgnt

loan : ILoan

«CV_InterfaceTemplate»




<<CV_ObjectTemplate>>ItemMgr

itemMgnt : IItemMgnt«CV_InterfaceTemplate»

<<CV_ObjectTemplate>>FineSystem

fine : IFine

toUserMgr : IUserMgnt«CV_InterfaceTemplate»


<<CV_ObjectTemplate>>UserMgr

userMgnt : IUserMgnt«CV_InterfaceTemplate»

IUserMgnt_Response

IItemMgnt_Response

IUserMgnt_Signature

IItemMgnt_Signature

IBorrow_Signature

ILoan_Response

ILoan_Signature

IFine_Signature

«CV_InterfaceTemplate»type = operationobjectRole = server


«CV_InterfaceTemplate»type = operationobjectRole = client






«CV_InterfaceTemplate»<<CV_ObjectTemplate>>

BorrowingSystem

borrow : IBorrow

toFineSystem : IFine

toUserMgr : IUserMgnt

toItemMgr : IItemMgnt

loan : ILoan





<<CV_ObjectTemplate>>ItemMgr

itemMgnt : IItemMgnt«CV_InterfaceTemplate»


fine : IFine





IUserMgnt_Response

IItemMgnt_Response

IUserMgnt_Signature

IItemMgnt_Signature

IBorrow_Signature

ILoan_Response

ILoan_Signature

IFine_Signature










<<CV_BindingObject>> : Sync

toPlayer

toListener

«CV_StreamInterface»

<<CV_Object>>: Player

toListener

toSync«CV_StreamInterface»

<<CV_Object>>: Listener

toPlayer toSync«CV_StreamInterface»

«CV_StreamInterface»«CV_SignalInterface»

«CV_SignalInterface»

<<CV_BindingObject>> : Sync

toPlayer

toListener

«CV_StreamInterface»

<<CV_Object>>: Player

toListener

toSync«CV_StreamInterface»

<<CV_Object>>: Listener

toPlayer toSync«CV_StreamInterface»

«CV_StreamInterface»«CV_SignalInterface»

«CV_SignalInterface»

Component diagrams are used to describe the ODP system Structure

Environment contracts are modeled:− using UML restriction mechanisms (OCL, timing diagrams, …)

− applying other UML profiles (e.g., UML Profile for Modeling QoS Characteristics)

<<profile>>

UML Profile for Modeling QoS and Fault Tolerance

Characteristics and Mechanisms

<<profile>>

ODP CV Profile

My ODP System

<<apply>><<apply>>


LOGOModeling the ODP-CV in UML 2.0 (V)Example 1: Structure specification


LOGOModeling the ODP-CV in UML 2.0 (VI)Example 1: Structure specification

<<CV_OperationInterfaceSignature>>IUserMgnt__Signature

addUser( detail : User ) : boolean


getUser( id : Integer ) : User

<<CV_InterrogationSignature>>suspendUser( id : Integer )enableUser( id : Integer )





IUserMgnt__Signature

«CV_InterfaceTemplate»type = operation

«CV_InterfaceTemplate»type = operation


LOGOModeling the ODP-CV in UML 2.0 (VII)Example 1: Behaviour specification


LOGOModeling the ODP-CV in UML 2.0 (VIII)Example 1: Behaviour specification


LOGOModeling the ODP-CV in UML 2.0 (IX)Example 2: Structure specification

Computational Templates

Snapshot

• A multimedia system

composed by listeners

who want to receive

audio frames from an

audio streamer (i.e.

Internet radio station)

• A binding object

manages the multicast of

audio frames from a

audio streamer to its

registered listeners.

• A service manager object

manages the listeners’

selections


LOGOModeling the ODP-CV in UML 2.0 (and X)Example 2: Behaviour specification

Computational Object Template

validate item

get item

detail

validate user

get user

userfines

check finesfines


validUser


: Itemdetail

[Accepted]

[Rejected]

[Accepted]

[Rejected]

validate item

get item

detail

validate user

get user

userfines

check finesfines


validUser


: Itemdetail

[Accepted]

[Rejected]

[Accepted]

[Rejected]

[ ]


alt


«CV_Announcement»

«CV_Announcement»

«CV_Announcement»

«CV_Announcement»

«CV_Announcement»


«CV_Termination»

«CV_Invocation»


getLoan 2:


removeLoan( id= )6:

freeItem( id= )7:

getLoanResponse 3:

suspendUser 5: [ ]


alt


«CV_Announcement»

«CV_Announcement»

«CV_Announcement»

«CV_Announcement»

«CV_Announcement»


«CV_Termination»

«CV_Invocation»


getLoan 2:


removeLoan( id= )6:

freeItem( id= )7:

getLoanResponse 3:

suspendUser 5:


LOGOIssues for discussion

Differences between the ODP and UML object models The UML object model assumes that classes are first-class citizens. Objects

are instances of these classes. The ODP model considers objects as first-class citizens. Types are predicates

on objects, and classes are collections of objects. In UML, invariants and operations are owned by individual objects. ODP

uses “collective state” for invariants, and “collective behavior” for operation and interaction specifications

UML 2.0 allow semantic variations

Terminology conflicts ODP object vs. UML object ODP type vs. UML type ODP interface vs. UML interface; ODP class vs. UML class

Structuring rules In ODP, signals with different causalities can coexist in an interface. UML

requires different UML interfaces for signals with different causalities. ODP computational objects can instantiate interface templates. UML

ports cannot be individually instantiated.


LOGOConclusions

UML 2.0 enables the representation of ODP Computational concepts in a more natural manner than UML 1.5

There is not a "perfect" match of concepts, but this does not invalidate the profile

The UML 2.0 Profile for the ODP Computational Viewpoint will be discussed during the forthcoming ISO/JTC1/SC7 WG19 meeting in Bari (Italy), 24-28 October, 2005.


LOGOEnd of Presentation

Antonio Vallecillo

[email protected]

http://www.lcc.uma.es/~av

Date post:	14-Jan-2016
Category:	Documents
Upload:	jereni
View:	25 times
Download:	0 times

Modeling the ODP Computational Viewpoint with UML 2.0

Documents