Presentation is loading. Please wait.

Presentation is loading. Please wait.

Modeling the ODP Computational Viewpoint with UML 2.0

Similar presentations


Presentation on theme: "Modeling the ODP Computational Viewpoint with UML 2.0"— Presentation transcript:

1 Modeling the ODP Computational Viewpoint with UML 2.0
José Raúl Romero, Antonio Vallecillo Universidad de Málaga, Spain Dept. Lenguajes y Ciencias de la Computación

2 Agenda The Reference Model for Open Distributed Processing
A (graphical) notation for the ODP CV Modeling the ODP CV with UML 2.0 Issues for discussion Conclusions Geneva, October 11, 2005 ITU-T SG17 Meeting

3 Important Acknowledgements Disclaimer
This work has been developed within WG19 of ISO/JTC1/SC7, in the context of the development of ISO/IEC | 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 | ITU-T Rec. X.906 is developed. Geneva, October 11, 2005 ITU-T SG17 Meeting

4 The 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 Well, RM-ODP was developed by ISO/IEC and ITU-T as a framework for the design of component-based distributed platforms. It provides the modeller a compressive and coherent OO modelling structure, transparencies and common functions. However, one of the most interesting aspect of RM-ODP is that it is based on the “separation of concerns” principle. That means that it divides the system design activity into different perspectives. These areas of concern are named “viewpoints” in RM-ODP and they have demonstrated to be a powerful mechanism for dealing with the complexity of large distributed systems. So, each viewpoint reflects different concerns, which are expressed in terms of specific viewpoint languages. Geneva, October 11, 2005 ITU-T SG17 Meeting

5 Without a concrete syntax…
The Reference Model for Open Distributed Processing (II) Viewpoint 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 useless However, ODP does not prescribe any specific language for its viewpoint specifications, what means that ODP viewpoint languages are abstract. However, system modellers need to have concrete syntaxes in order to specify their ODP systems. Besides, the lack of common concrete syntaxes may hinder the industrial acceptance and application of the ODP standard, for instance, because of the lack of tool support. Usually, formal methods have been proposed as a concrete syntax for writing these viewpoint specifications in a precise and unambiguous manner. However, these languages are complex and difficult to learn and to use for common software designers. Besides, there is no attractive commercial support for them. Thus, we need some kind of general and extended modelling notation, which results familiar to developers, easy to learn and to use and with a commercial tool support. In our opinion, graphical notations seem to be the best candidate. We need a general-purpose modeling notation, familiar to developers, easy to learn and to use, with commercial tool support … Geneva, October 11, 2005 ITU-T SG17 Meeting

6 Target audiences of ISO/IEC 19793 | ITU-T Rec. X.906
ISO/IEC | 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 | 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 This is part of the work on and that what is being presented on the Computational View is an example of the general approach to the development of the viewpoint profiles in 19793, for example the UML 1.x vs UML 2.0 issues are common; a metamodel is defined for each viewpoint language as the basis for the corresponding profile etc. Geneva, October 11, 2005 ITU-T SG17 Meeting

7 ODP System Information Enterprise Technology Computation Engineering
The Reference Model for Open Distributed Processing (III) The RM-ODP viewpoints Information Enterprise ODP System Business aspects who? why? Information, changes, constraints Computation Engineering Technology More specifically, the Reference Model for ODP describes five different viewpoints. The Enterprise viewpoint refers to the business aspects. The Information viewpoint specifies which information is managed by the system, how does this information change and which constraints are applied on data. The Computational viewpoint refers to the functional description of the system. The engineering viewpoint to the mechanisms and services needed for the distribution. And the Technology viewpoint refers to how the system is implemented. Hard- and software components That implement the system Configuration of objects interacting at interfaces Mechanisms and services for distribution transparencies Geneva, October 11, 2005 ITU-T SG17 Meeting

8 A configuration of computational objects;
The Reference Model for Open Distributed Processing (and IV) Computational specifications 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. 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. More specifically, our proposal refers to the Computational viewpoint, which describes the functionality of the system in terms of computational objects that interact at interfaces. So, a Computational Specification describes the functional decomposition of an ODP system as a configuration of objects, their internal actions, the interactions among them and in terms of environment contracts for those objects and their interfaces. Geneva, October 11, 2005 ITU-T SG17 Meeting

9 Mapping to UML elements
Graphical notation for the ODP-CV (I) Previous approaches 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) 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 Concerning to the use of graphical notations, UML 1.4 and later versions have been already proposed for the modeling of the ODP computational viewpoint. For example, the UML Profile for EDOC and, more specifically, its Component Collaboration Architecture, provides a very extensive approach. In fact, many of these proposals were complete and precise approaches. However, they seem to be too large and complex for a wide industrial acceptance. Perhaps, because of the big gap existing between the ODP and the UML concepts. ODP-CV Concepts UML 1.x Approaches Mapping to UML elements Geneva, October 11, 2005 ITU-T SG17 Meeting

10 Graphical notation for the ODP-CV (and II)
Unified Modeling Language v2.0 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 UML 2.0 provides several improvements to previous versions, that make UML more suitable for modeling large distributed systems. For example, UML 2.0 adds new diagrams and provides enhancements to the existing one. In particular, the component diagram has been pretty improved. Moreover, the influence of SDL, the alignment of OCL with UML 2.0 and the enhancement of the extension mechanisms bring the modeling language closer to the ODP concepts. Our contribution in this paper consists in providing a comfortable way of modeling ODP concepts using an UML 2.0 Profile for the ODP Computational Viewpoint. ODP-CV Metamodel UML 2.0 Profile for the ODP Computational Viewpoint Mapping to UML elements Geneva, October 11, 2005 ITU-T SG17 Meeting

11 Relationships between UOD, ODP specifications, and UML models
Geneva, October 11, 2005 ITU-T SG17 Meeting

12 specific domain terminology
Modeling 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 terminology The profile presented here serves as input to the WG19 forthcoming standard on ISO/IEC | ITU-T Rec. X.906: UML for ODP system specifications (2nd CD due next month) Geneva, October 11, 2005 ITU-T SG17 Meeting

13 The Profile is based on a Metamodel for the ODP Computational Viewpoint
Just mention that there is a metamodel underneath, but without describing it in detail Geneva, October 11, 2005 ITU-T SG17 Meeting

14 Modeling the ODP-CV in UML 2.0 (II)
Computational objects and interfaces ODP concept UML element Computational object template Component <<CV_CompObjectTemplate>> Computational object InstanceSpecification (from Component) <<CV_Object>> Computational interface template Port <<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>> Geneva, October 11, 2005 ITU-T SG17 Meeting

15 Modeling the ODP-CV in UML 2.0 (II)
Computational objects and interfaces ODP concept UML element Computational object template Component <<CV_CompObjectTemplate>> Computational object InstanceSpecification (from Component) <<CV_Object>> Computational interface template Port <<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>> Geneva, October 11, 2005 ITU-T SG17 Meeting

16 Modeling the ODP-CV in UML 2.0 (II)
Computational objects and interfaces ODP concept UML element Computational object template Component <<CV_CompObjectTemplate>> Computational object InstanceSpecification (from Component) <<CV_Object>> Computational interface template Port <<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>> Geneva, October 11, 2005 ITU-T SG17 Meeting

17 Modeling the ODP-CV in UML 2.0 (II)
Computational objects and interfaces ODP concept UML element Computational object template Component <<CV_CompObjectTemplate>> Computational object InstanceSpecification (from Component) <<CV_Object>> Computational interface template Port <<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>> Geneva, October 11, 2005 ITU-T SG17 Meeting

18 Modeling the ODP-CV in UML 2.0 (II)
Computational objects and interfaces ODP concept UML element Computational object template Component <<CV_CompObjectTemplate>> Computational object InstanceSpecification (from Component) <<CV_Object>> Computational interface template Port <<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>> Geneva, October 11, 2005 ITU-T SG17 Meeting

19 Modeling the ODP-CV in UML 2.0 (III)
Interactions ODP concept UML element 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>> Geneva, October 11, 2005 ITU-T SG17 Meeting

20 Modeling the ODP-CV in UML 2.0 (III)
Interactions ODP concept UML element 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>> Geneva, October 11, 2005 ITU-T SG17 Meeting

21 Modeling the ODP-CV in UML 2.0 (III)
Interactions ODP concept UML element 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>> Geneva, October 11, 2005 ITU-T SG17 Meeting

22 Modeling the ODP-CV in UML 2.0 (III)
Interactions ODP concept UML element 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>> Geneva, October 11, 2005 ITU-T SG17 Meeting

23 UML Profile (I) Geneva, October 11, 2005 ITU-T SG17 Meeting

24 UML Profile (II) Geneva, October 11, 2005 ITU-T SG17 Meeting

25 UML Profile (III) Geneva, October 11, 2005 ITU-T SG17 Meeting

26 UML Profile (IV) Geneva, October 11, 2005 ITU-T SG17 Meeting

27 Modeling the ODP-CV in UML 2.0 (IV)
Specifying ODP systems Component diagrams are used to describe the ODP system Structure Behaviour is described in terms of: Interaction models (message passing) Activity models (sequence, i/o, …) Statecharts (changes caused by events, …) Environment contracts are modeled: using UML restriction mechanisms (OCL, timing diagrams, …) applying other UML profiles (e.g., UML Profile for Modeling QoS Characteristics) Geneva, October 11, 2005 ITU-T SG17 Meeting

28 Modeling the ODP-CV in UML 2.0 (V)
Example 1: Structure specification Geneva, October 11, 2005 ITU-T SG17 Meeting

29 Modeling the ODP-CV in UML 2.0 (VI)
Example 1: Structure specification Geneva, October 11, 2005 ITU-T SG17 Meeting

30 Modeling the ODP-CV in UML 2.0 (VII)
Example 1: Behaviour specification Geneva, October 11, 2005 ITU-T SG17 Meeting

31 Modeling the ODP-CV in UML 2.0 (VIII)
Example 1: Behaviour specification Geneva, October 11, 2005 ITU-T SG17 Meeting

32 Computational Templates
Modeling the ODP-CV in UML 2.0 (IX) Example 2: Structure specification 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 Snapshot Computational Templates Geneva, October 11, 2005 ITU-T SG17 Meeting

33 Computational Object Template
Modeling the ODP-CV in UML 2.0 (and X) Example 2: Behaviour specification Computational Object Template Geneva, October 11, 2005 ITU-T SG17 Meeting

34 Issues 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. Geneva, October 11, 2005 ITU-T SG17 Meeting

35 Conclusions 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), October, 2005. Geneva, October 11, 2005 ITU-T SG17 Meeting

36 Thank You ! End of Presentation Antonio Vallecillo
Geneva, October 11, 2005 ITU-T SG17 Meeting


Download ppt "Modeling the ODP Computational Viewpoint with UML 2.0"

Similar presentations


Ads by Google