41
UML 2 Models for ODP Engineering/Technology Viewpoints – An Experiment Daisuke Hashimo to [email protected] Hiroshi Miyazaki [email protected] .com Akira Tanaka [email protected] m

UML 2 Models for ODP Engineering/Technology Viewpoints – An Experiment - Daisuke Hashimoto [email protected] [email protected] Hiroshi

Embed Size (px)

Citation preview

Page 1: UML 2 Models for ODP Engineering/Technology Viewpoints – An Experiment - Daisuke Hashimoto hashimoto@tech-arts.co.jp hashimoto@tech-arts.co.jp Hiroshi

UML 2 Models for ODP Engineering/Technology

Viewpoints

– An Experiment -

Daisuke [email protected]

Hiroshi [email protected]

Akira [email protected]

Page 2: UML 2 Models for ODP Engineering/Technology Viewpoints – An Experiment - Daisuke Hashimoto hashimoto@tech-arts.co.jp hashimoto@tech-arts.co.jp Hiroshi

2

Agenda

Introduction UML 2.0 profile and models for Engineering

Viewpoint UML 2.0 profile and models for Technology

Viewpoint Considerations Conclusions

Page 3: UML 2 Models for ODP Engineering/Technology Viewpoints – An Experiment - Daisuke Hashimoto hashimoto@tech-arts.co.jp hashimoto@tech-arts.co.jp Hiroshi

Introduction

Page 4: UML 2 Models for ODP Engineering/Technology Viewpoints – An Experiment - Daisuke Hashimoto hashimoto@tech-arts.co.jp hashimoto@tech-arts.co.jp Hiroshi

4

Background and objective

The ISO/IEC and ITU-T joint project, “Use of UML for ODP system specifications,” made a decision to shift from UML 1.4 to UML 2.0 based profile.

Therefore it is necessary to examine that UML 2.0 model elements can appropriately represent necessary ODP concepts.

The above project is an international collaboration, and we are interested in Engineering and Technology viewpoints for promising connection with OMG’s MDA initiative.

Here I am to present this paper.

Page 5: UML 2 Models for ODP Engineering/Technology Viewpoints – An Experiment - Daisuke Hashimoto hashimoto@tech-arts.co.jp hashimoto@tech-arts.co.jp Hiroshi

5

This paper is Based on... Authors are members of INTAP (Japan) ODP

committee. Developed “A Guide for using RM-ODP and UML

Profile for EDOC” (2003) This paper is based on:

RM-ODP Part 2, Part 3, and Enterprise Language standards

CD document of ISO/IEC and ITU-T’s joint project “Use of UML for ODP system specifications”

INTAP ODP committee has liaison with Japanese committee for SC7/WG19 on RM-ODP activity.

INTAP Technical Report “Applying EDOC and MDA to the RM-ODP Engineering and Technology Viewpoints” (2003)

Profile developed with the same objective, but based on UML 1.4 UML 2.0 superstructure specification from OMG

Page 6: UML 2 Models for ODP Engineering/Technology Viewpoints – An Experiment - Daisuke Hashimoto hashimoto@tech-arts.co.jp hashimoto@tech-arts.co.jp Hiroshi

UML 2.0 profile and modelsfor Engineering Viewpoint

Page 7: UML 2 Models for ODP Engineering/Technology Viewpoints – An Experiment - Daisuke Hashimoto hashimoto@tech-arts.co.jp hashimoto@tech-arts.co.jp Hiroshi

7

Target Architectural Diagrams

Five architectural diagrams are quoted here from RM-ODP Part 3 Engineering Language.

Those diagrams are grouped into two: Diagram 1 to 3 for Node structure modeling

discussion Diagram 4 to 5 for Channel modeling discussion

Page 8: UML 2 Models for ODP Engineering/Technology Viewpoints – An Experiment - Daisuke Hashimoto hashimoto@tech-arts.co.jp hashimoto@tech-arts.co.jp Hiroshi

8

Target Architectural Diagrams -1

Example structure supporting a basic engineering object (from RM-ODP Part 3, Clause 8 Figure 4)

Page 9: UML 2 Models for ODP Engineering/Technology Viewpoints – An Experiment - Daisuke Hashimoto hashimoto@tech-arts.co.jp hashimoto@tech-arts.co.jp Hiroshi

9

Target Architectural Diagrams -2

Example structure of a capsule (from RM-ODP Part 3, Clause 8 Figure 5)

Page 10: UML 2 Models for ODP Engineering/Technology Viewpoints – An Experiment - Daisuke Hashimoto hashimoto@tech-arts.co.jp hashimoto@tech-arts.co.jp Hiroshi

10

Target Architectural Diagrams -3

Example structure of a node (RM-ODP Part 3, Clause 8 Figure 6)

Page 11: UML 2 Models for ODP Engineering/Technology Viewpoints – An Experiment - Daisuke Hashimoto hashimoto@tech-arts.co.jp hashimoto@tech-arts.co.jp Hiroshi

11

Major elements from those diagrams

Need to cover at least the following major elements in UML 2.0 diagrams:

Basic Engineering Object (BEO) Capsule Capsule Manager (CPM) Cluster Cluster Manager (CLM) Node Nucleus

Page 12: UML 2 Models for ODP Engineering/Technology Viewpoints – An Experiment - Daisuke Hashimoto hashimoto@tech-arts.co.jp hashimoto@tech-arts.co.jp Hiroshi

12

Candidate UML diagrams

Deployment diagram Deployment diagram has some constraints.

Node: UML 2 only allows certain types of modeling elements

(e.g. Node, Artifact) to be placed within a Node. Artifact is poor to represent internal structure of capsule.

Communication path: This diagram’s communication path is association between

Nodes(not communication path between capsules).

Class diagram and Component diagram Component and Class (structured classifier) can have parts. Those diagram is powerful to represent internal structure of Node.

Which one? Will be discussed in the following slides.

Page 13: UML 2 Models for ODP Engineering/Technology Viewpoints – An Experiment - Daisuke Hashimoto hashimoto@tech-arts.co.jp hashimoto@tech-arts.co.jp Hiroshi

13

Issue: modeling engineering objects

Candidates for modeling engineering objects. Class: may be more abstract than component? Component: may give an impression of software component?

Concept of ODP’s Object is close to Object concept in UML. But, Object is used to represent snapshot in UML world.

(UML modeling is class based) Object is defined by element of Instance specification in UML2.0.

Instance specification is not classified (Class? Component?)

Our choice in this paper is… Using Component for profile definition. Using Component instance for diagramming.

InstanceSpecification

class component

specification

instance

class component

componentinstanceobject

Page 14: UML 2 Models for ODP Engineering/Technology Viewpoints – An Experiment - Daisuke Hashimoto hashimoto@tech-arts.co.jp hashimoto@tech-arts.co.jp Hiroshi

14

Profile definition (1/3)

stereotypeNV_CapsuleManager

stereotypeNV_ClusterManager

stereotypeNV_Cluster

stereotypeNV_Capsule

stereotypeNV_Node

stereotypeNV_Nucleus

stereotypeNV_BEO

metaclassComponent

NV_Profile_Capsule

Page 15: UML 2 Models for ODP Engineering/Technology Viewpoints – An Experiment - Daisuke Hashimoto hashimoto@tech-arts.co.jp hashimoto@tech-arts.co.jp Hiroshi

15

Example UML 2.0 Model: Nodes

NV_NodeAssistantPC :

NV_NodeIneractionServer :

NV_NodeEnterpriseServer :

NV_NodeEIS_Server1 :

NV_NodeEIS_Server2 :

EIS TierThis node is for user and loan information management.

EIS TierThis node is for fine information management.

ClientTier InteractionTier EnterpriseTier

Node Configuration

Page 16: UML 2 Models for ODP Engineering/Technology Viewpoints – An Experiment - Daisuke Hashimoto hashimoto@tech-arts.co.jp hashimoto@tech-arts.co.jp Hiroshi

16

Example UML 2.0 model: Node(internal)

NV_Capsule: Capsule_2

NV_Nucleus: Nucleus_1

NucleusService

NV_ClusterManager: ClusterManager_1A

NV_BEO: BEO_1AB

NV_BEO: BEO_1AA

NV_Cluster: Cluster_1A

NV_CapsuleManager: CapsuleManager_1

NV_BEO: BEO_1BB

NV_BEO: BEO_1BA

NV_Cluster: Cluster_1B

NV_ClusterManager: ClusterManager_1B

NV_Stub: Stub_1A

NV_Stub: Stub_1B

NV_Binder: Binder_1A

NV_Binder: Binder_1B

NV_ProtocolObject: ProtocolObject_1A

NV_ProtocolObject: ProtocolObject_1B

NV_Capsule: Capsule_1

delegatedelegate

NV_Node: Node_1

NV_Node: Node_2

NV_Interceptor: Interceptor_A

Capsule

Page 17: UML 2 Models for ODP Engineering/Technology Viewpoints – An Experiment - Daisuke Hashimoto hashimoto@tech-arts.co.jp hashimoto@tech-arts.co.jp Hiroshi

17

Target Architectural Diagrams -4

An example of a basic client/server channel (RM-ODP Part 3, Clause 8 Figure 2)

Page 18: UML 2 Models for ODP Engineering/Technology Viewpoints – An Experiment - Daisuke Hashimoto hashimoto@tech-arts.co.jp hashimoto@tech-arts.co.jp Hiroshi

18

Target Architectural Diagrams -5

An example of a multi-endpoint channel (RM-ODP Part 3, Clause 8 Figure 3)

Page 19: UML 2 Models for ODP Engineering/Technology Viewpoints – An Experiment - Daisuke Hashimoto hashimoto@tech-arts.co.jp hashimoto@tech-arts.co.jp Hiroshi

19

Major elements from those diagrams

Channel Stub Binder Protocol Object Interceptor

Candidate diagrams Composite structure diagram

Represent configuration of channel in this aspect. Class or component has capability to represent it.

Package diagram Not able to represent the structural aspects.

Page 20: UML 2 Models for ODP Engineering/Technology Viewpoints – An Experiment - Daisuke Hashimoto hashimoto@tech-arts.co.jp hashimoto@tech-arts.co.jp Hiroshi

20

Issue: modeling channel Node and Channel shares the same Engineering objects

(Stub, binder, Protocol Object), i.e. ideally overlapping diagram are needed to represent this situation.

UML 2.0 does not provide “overlapping diagram” capability. Possible approaches:

two separate diagrams (double occurrence of the same engineering object)

one structural diagram and one package Our choice in this paper – Structural diagram for Node and

use of package for Channel

Node A Node B

Channel

Engineering object

Page 21: UML 2 Models for ODP Engineering/Technology Viewpoints – An Experiment - Daisuke Hashimoto hashimoto@tech-arts.co.jp hashimoto@tech-arts.co.jp Hiroshi

21

Profile definition (2/3)

stereotypeNV_Channel

stereotypeNV_Stub

stereotypeNV_Interceptor

stereotypeNV_ProtocolObject

stereotypeNV_Binder

metaclassComponent

metaclassPackage

NV_Profile_Channel

Page 22: UML 2 Models for ODP Engineering/Technology Viewpoints – An Experiment - Daisuke Hashimoto hashimoto@tech-arts.co.jp hashimoto@tech-arts.co.jp Hiroshi

22

Example UML 2.0 model: Channel

Note: Interface connection may be omitted.

NV_Binder: Binder_1

NV_Stub: Stub_1

NV_ProtocolObject: ProtocolObject_1

NV_Interceptor: Interceptor_A

NV_ProtocolObject: ProtocolObject_2

NV_Binder: Binder_2

NV_Stub: Stub_2

NV_ChannelChannel_123package

Page 23: UML 2 Models for ODP Engineering/Technology Viewpoints – An Experiment - Daisuke Hashimoto hashimoto@tech-arts.co.jp hashimoto@tech-arts.co.jp Hiroshi

23

Objects and domains

A domain is a set of objects: which UML element can represent ODP domain concept properly?

<X> Domain: A set of objects, each of which is related by a characterizing relationship <X> to a controlling object.

Three candidates for modeling domain Class: members are parts (classes) <structured

classifier> Component : members are parts (components)

<structured classifier> Package: members are any model element.

Page 24: UML 2 Models for ODP Engineering/Technology Viewpoints – An Experiment - Daisuke Hashimoto hashimoto@tech-arts.co.jp hashimoto@tech-arts.co.jp Hiroshi

24

Issue: modeling domain A member may belong to multiple domains, i.e. domains may share the

same objects Class: parts can be shared [use of dotted line box] Component: can parts (component) be shared? Package: «import»/«access» may be used to share

Our choice in this paper - Package

Page 25: UML 2 Models for ODP Engineering/Technology Viewpoints – An Experiment - Daisuke Hashimoto hashimoto@tech-arts.co.jp hashimoto@tech-arts.co.jp Hiroshi

25

Profile definition (3/3)

stereotypeNV_Domain

metaclassPackage

metaclassComponent

stereotypeNV_Object

NV_Profile_Domain

Page 26: UML 2 Models for ODP Engineering/Technology Viewpoints – An Experiment - Daisuke Hashimoto hashimoto@tech-arts.co.jp hashimoto@tech-arts.co.jp Hiroshi

26

Example UML 2.0 model: Domain and objects

NV_ProtocolObjectProtocolObject :

AssistantPC node model

NV_ProtocolObjecta ComponentNV_ProtocolObject

ProtocolObject :

InteractionServer node model

NV_ObjectCommnicationControlingObject :

NV_CommunicationDomainCommunicationDomain A

access

access

NV_ProtocolObjecta Component

NV_ProtocolObjectProtocolObject :

EnterpriseServer node model

NV_ProtocolObjectProtocolObject :

EIS_Server1 node model

accessaccess

NV_ProtocolObjectProtocolObject :

EIS_Server2 node model

access

CommunicationDomainModel

Page 27: UML 2 Models for ODP Engineering/Technology Viewpoints – An Experiment - Daisuke Hashimoto hashimoto@tech-arts.co.jp hashimoto@tech-arts.co.jp Hiroshi

27

Issue: Correspondence

Engineering Viewpoint to Computational Viewpoint Assumption: Each BEO has one to one relationship to

corresponding Computational Object (from Engineering to Computational, not vice versa).

Correspondence could be expressed asdependency from BEO sub-Package in Engineering Viewpoint Package to Computational Objects in Computational Viewpoint Package in UML

The issue How to best express this correspondence in UML

CV

NV

Page 28: UML 2 Models for ODP Engineering/Technology Viewpoints – An Experiment - Daisuke Hashimoto hashimoto@tech-arts.co.jp hashimoto@tech-arts.co.jp Hiroshi

UML 2.0 profile and modelsfor Technology Viewpoint

Page 29: UML 2 Models for ODP Engineering/Technology Viewpoints – An Experiment - Daisuke Hashimoto hashimoto@tech-arts.co.jp hashimoto@tech-arts.co.jp Hiroshi

29

Major Elements in this viewpoint

Technology Object Implementable Standard Implementation IXIT

Candidate diagram Deployment diagram

Page 30: UML 2 Models for ODP Engineering/Technology Viewpoints – An Experiment - Daisuke Hashimoto hashimoto@tech-arts.co.jp hashimoto@tech-arts.co.jp Hiroshi

30

Issue: rich set of concepts in UML

The issue: extent for defining UML Profile for Technology Viewpoint

Since UML 2 provides a similar set of modeling elements e.g. artifact, artifacts, device, document, executable, executionEnvironment, file, li

brary, node, script, source, etc. What is the added value of «TV_Object» other than ODP context, if «T

V_Object» is applied to both Node and Artifact? Double stereotype like «TV_Object, artifact» maybe used.

Implementable Standard? Maybe as a target of «manifestation »

Implementation? Maybe related to software engineering process like the one in OMG’s SPEM

IXIT? Useful for providing additional information for testing

Page 31: UML 2 Models for ODP Engineering/Technology Viewpoints – An Experiment - Daisuke Hashimoto hashimoto@tech-arts.co.jp hashimoto@tech-arts.co.jp Hiroshi

31

Profile definition

stereotypeTV_Implementation

stereotypeTV_ImplementationStandard

stereotypeTV_IXIT

stereotypeTV_Object

metaclassClass

metaclassArtifact

metaclassNode

metaclassComment

metaclassActivity

TV_Profile

Page 32: UML 2 Models for ODP Engineering/Technology Viewpoints – An Experiment - Daisuke Hashimoto hashimoto@tech-arts.co.jp hashimoto@tech-arts.co.jp Hiroshi

32

Example UML 2.0 model: Nodes and networks

TV_Object: AssistantPC

TV_Object: Library LAN

TV_Object: InteractionServer

TV_Object: EnterpriseServer

TV_Object: EIS_Server1

TV_Object: EIS_Server2

TV_Object: Internet

Node Configuration

Page 33: UML 2 Models for ODP Engineering/Technology Viewpoints – An Experiment - Daisuke Hashimoto hashimoto@tech-arts.co.jp hashimoto@tech-arts.co.jp Hiroshi

33

Example UML 2.0 model: Node structure

TV_Object: CPU

TV_Object: Memory

TV_Object: Storage

ExecutionEnvironment: Operating System

ExecutionEnvironment: Apache Middleware

TV_ObjectBorrowingSystem

TV_ObjectUserManager

TV_ObjectItemManager

TV_ObjectFineSystem

TV_Object: EnterpriseServer node

TV_ImplementationStandardJCP J2EE

realization

TV_ImplementationStandardIEEE POSIX

realization

TV_Object: Library LAN

TV_Object: Internet

NV_BEOLibraryManager :

manifest

NV_BEOUserManagerComponent :

NV_BEOItemManagerComponent :

NV_BEOFileSystemComponent :

manifest

manifest

manifest

TV_Object: Library Firewall

EnterpriseServer Node Structure

Page 34: UML 2 Models for ODP Engineering/Technology Viewpoints – An Experiment - Daisuke Hashimoto hashimoto@tech-arts.co.jp hashimoto@tech-arts.co.jp Hiroshi

34

Example UML 2.0 model: IXIT

TV_ObjectBorrowingSystem

ExecutionEnvironment: Apache middleware

TV_IXITRuns on J2EE version 1 or laterEncoding is UNICODERequires daily backup

TV_IXITMax number of concurrent access: 100WS-I Basic Profile 1.0

IXIT

Page 35: UML 2 Models for ODP Engineering/Technology Viewpoints – An Experiment - Daisuke Hashimoto hashimoto@tech-arts.co.jp hashimoto@tech-arts.co.jp Hiroshi

35

Issue: Correspondence

Technology Viewpoint to Engineering Viewpoint Each Technology Object has one to one relationship to

corresponding Engineering Object. Could be expressed as dependency from Technology

Objects in Technology Viewpoint Package to Engineering Objects in Engineering Viewpoint Package.

The issue How to best express this correspondence in UML

NV

TV

Page 36: UML 2 Models for ODP Engineering/Technology Viewpoints – An Experiment - Daisuke Hashimoto hashimoto@tech-arts.co.jp hashimoto@tech-arts.co.jp Hiroshi

Some comments

Page 37: UML 2 Models for ODP Engineering/Technology Viewpoints – An Experiment - Daisuke Hashimoto hashimoto@tech-arts.co.jp hashimoto@tech-arts.co.jp Hiroshi

37

Consideration needed on

Consistent modeling Recursive application of viewpoints Choice of consistent base classes Relationship/correspondence (specification)

Page 38: UML 2 Models for ODP Engineering/Technology Viewpoints – An Experiment - Daisuke Hashimoto hashimoto@tech-arts.co.jp hashimoto@tech-arts.co.jp Hiroshi

38

Issue: UML tools

UML 2.0 capabilities differ from tool to tool. Different Profile definition mechanisms Different UML 2.0 Implementation levels

Different diagramming capabilities Different base class support Different constraint implementation Different OCL support …

(Almost) No interoperability for profile definition data Development of profile data for major UML 2.0

tools and making them available, through international collaboration, is expected.

Page 39: UML 2 Models for ODP Engineering/Technology Viewpoints – An Experiment - Daisuke Hashimoto hashimoto@tech-arts.co.jp hashimoto@tech-arts.co.jp Hiroshi

Conclusions

Page 40: UML 2 Models for ODP Engineering/Technology Viewpoints – An Experiment - Daisuke Hashimoto hashimoto@tech-arts.co.jp hashimoto@tech-arts.co.jp Hiroshi

40

One possible use of UML 2.0 or profile demonstrated – We can use UML 2.0 tools to describe ODP specifications, and hope MDA tools to help implement the ODP systems.

Consistent and practical modeling approach is important for UML4ODP.

Openly available profile definitions are also important.

Page 41: UML 2 Models for ODP Engineering/Technology Viewpoints – An Experiment - Daisuke Hashimoto hashimoto@tech-arts.co.jp hashimoto@tech-arts.co.jp Hiroshi

41

Thank you very muchfor your attention!