1. UML for ODP system specifications ITU-T X.906 | ISO/IEC 19793 (A work-in-progress presentation) Antonio Vallecillo Universidad de Málaga Dept. Lenguajes y Ciencias de la Computación av@lcc.uma.es http://www.lcc.uma.es/~av/

2. June 20052 Agenda 1. ODP system specifications 2. Use of UML for ODP system specifications 3. ODP in MDA system specifications 4. Sources and progress so far 5. Conclusions

3. June 20053 Important 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. Acknowledgements –The work presented here has been developed by the ISO/IEC JTC1-SC7-WG19 Working group. We’d like to acknowledge the work by many ODP experts who have been involved in investigating and addressing the problems of the UML specification of ODP systems. Specially mention deserve Sandy Tyndale- Biscoe, Akira Tanaka and Bryan Wood.

4. June 20054 ODP System Specifications The Reference Model of ODP (ITU-T Rec X.901- 904 | ISO/IEC 10746) defines a framework for system specification, covering all aspects of open distributed systems: –“enterprise” context, functionality, distribution, infrastructure, technology It comprises –a structure for system specifications in terms of viewpoints –a language (concepts and rules) for expressing each viewpoint specification –a set of object-oriented foundation modeling concepts common to all viewpoint languages

5. June 20055 ODP Viewpoints Different abstractions of the same system –each abstraction focuses on different concerns –each abstraction achieved using a set of viewpoint concepts and rules A mechanism for dealing with the complexity of distributed systems

6. June 20056 ODP Viewpoints An ODP specification includes a set of viewpoint specifications (or views) A viewpoint specification –Is a specification of a system from a specific viewpoint –is expressed in terms of the viewpoint concepts and rules (the viewpoint language) to describe the concerns and decisions covered by the viewpoint specification –Is related to, and consistent with, other viewpoint specifications (correspondences)

7. June 20057 ODP Viewpoints—different concernsSystem Enterprise Computational Information Technology Engineering

8. June 20058 The enterprise specification Specifies the roles played by the system in its organizational environment An object model of, for example, part of some social/commercial organization in terms of: –Enterprise objects –Communities (of enterprise objects) –Objectives –Behaviour Roles (fulfilled by enterprise objects in a community) Processes (leading to Objectives) –Policies –Accountability –…

9. June 20059 The information specification Specifies system behavior to fulfill its enterprise roles, abstracted from implementation An object model of the system describing the semantics of information and of information processing in the system, in terms of: –Information objects –Invariant schema: predicates on information objects that must always be true –Static schema: state of information objects at some location in time –Dynamic schema: allowable state changes of information objects

10. June 200510 The computational specification Specifies computational structure of the system in terms of units of functionality (distribution and technology independent) An object model of the system describing the structure of processing in terms of: –Computational objects –Interfaces (of computational objects): functions supported –Invocations (by computational objects): functions invoked –Computational bindings –Environment contracts (e.g., QoS constraints)

11. June 200511 The engineering specification Specifies the mechanisms and services that provide the distribution transparencies and QoS constraints required by the system, independent of platform and technology An object model of the system describing the infrastructure supporting the computational structure –Basic engineering objects –(Infrastructure) Engineering objects –Clusters, capsules, nodes –Channels –Functions

12. June 200512 The technology specification Specifies the H/W and S/W pieces from which the system is built An object model of the system –defining the configuration of technology objects that comprise the ODP system, and the interfaces between them –identifying conformance points

13. June 200513 An ODP system specification - Object configuration - Interactions between objects at interfaces Computational Enterprise - business aspects - What for? Why? Who? When? - information - changes to information - constraints Information - Hardware and software components implementing the system Technology Engineering - Mechanisms and services for distribution trans- parencies and QoS constraints. - and correspondences between specifications

14. June 200514 Correspondences between ODP VPs Enterprise Technology Engineering Computational Information

15. June 200515 Use of UML* for ODP system specs ITU-T X.906 | ISO/IEC 19793 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 A standard that enables the use of MDA tools in developing and maintaining ODP system specifications *currently moving to 2.0

16. June 200516 Use of UML* for ODP system specs ITU-T X.906 | ISO/IEC 19793 Why? –RM-ODP is notation- and methodology- independent –Which is an advantage (a-priori)... –...but hampers its widespread adoption and use Target audiences of ISO/IEC 19793 –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

17. June 200517 UML Profiles for ODP Viewpoint Languages

18. June 200518 Enterprise metamodel (excerpt)

19. June 200519 UML Profile – Enterprise lang. (excerpt) ConceptStereotypeUML Metaclass ODP System«EV_ODPSystem» Class Field of Application«EV_FieldOfApplication» Comment attached to Package Community«EV_Community» Subsystem Enterprise Object«EV_EnterpriseObject» Class Enterprise Object fulfilling Role«EV_FulfilsRole» Association Community Object«EV_CommunityObject» Class Objective«EV_Objective» Class Role«EV_Role» Class, StateMachine (in role model), Partition (in process model) Action«EV_Action» State Interaction«EV_Interaction» Class, StateMachine, ActivityGraph Process«EV_Process» Class, A ctivityGraph Step«EV_Step» ActionState Artefact«EV_Artefact» ObjectFlowState (in process model), Signal (in role model)

20. June 200520 UML Profile – Enterprise lang. (icons) «EV_EnterpriseObject» «EV_ODPSystem» «EV_Role» «EV_Interaction» «EV_Artefact» «EV_CommunityObject» «EV_Community» «EV_Objective» «EV_Process» «EV_Step»

21. June 200521 Information Language metamodel

22. June 200522 UML Profile – Information Language

23. June 200523 UML Profile – Information lang. (icons) «Information_Spec» «IV_InformationObject» «IV_InformationObjectType» «IV_ActionType» «IV_InvariantSchema» « IV_StaticSchema» « IV_DynamicSchema»

24. June 200524 Computational Language metamodel

25. June 200525 UML Profile – Computational Language

26. June 200526 ODP System specification structure >

27. June 200527 Engineering Language metamodel (1)

28. June 200528 Engineering Language metamodel (2)

29. June 200529 UML Profile – Engineering language

30. June 200530 Technology Language metamodel

31. June 200531 UML Profile – Technology language

32. June 200532 UML mappings – Technology language Technology Language ConceptsCorresponding UML elements Technology objectDeployment diagram including instances of components Implementable standarda)Stereotyped Notes attached to deployment diagram and/or instance of components or b)UML tagged values or named property list ImplementationA process of building a testable UML system according to a UML model or models IXITStereotyped Notes

33. June 200533 Proof of concept: the Templeman Library The standard will include, as an example, a partial specification of a computerized system that supports the operations of a University Library, in particular those related to the borrowing process of Library items. The system should keep track of the items of the University Library, its borrowers, and their outstanding loans. The library system will be used by the library staff (librarian and assistants) to help them record loans, returns, etc.

34. June 200534 UML specification of the ODP system

35. June 200535 Enterprise Specifications

36. June 200536 Enterprise specification – Global

37. June 200537 Enterprise spec – Library Community

38. June 200538 Enterprise spec – enterprise objects

39. June 200539 Enterprise spec – Role fulfilment

40. June 200540 Enterprise spec – Processes

41. June 200541 Enterprise spec – Activity graph

42. June 200542 Enterprise spec – Interactions

43. June 200543 Enterprise spec – Request Item and Delegations

44. June 200544 Enterprise spec – state diagram for Borrower role

45. June 200545 Enterprise spec – Artefact roles of Loan

46. June 200546 Enterprise spec – Policies

47. June 200547 Enterprise spec – Interactions between comunities context Templeman Library System (E Spec)::Library::Behaviour::Roles::Librarian inv: self.roleFiller <> Templeman Library System (E Spec)::Personnel::Behaviour::Roles::Dean.roleFiller

48. June 200548 Information Specifications

49. June 200549 Information specification

50. June 200550 Information spec – Object types

51. June 200551 Information spec – Action types

52. June 200552 Information spec – invariant schemata context Library inv undergradLimits: (undergradMaxLoans = 8) and (undergradBookLoanPeriod = 28) and (undergradPeriodicalLoanPeriod = 0) context Library inv uniqueIdentifiers: self.items->forAll( itm1,itm2 | itm1.id <> itm2.id) and self.users->forAll( usr1,usr2 | usr1.id <> usr2.id) context Library inv oneLibrarianAndOneClockWhileOpen: self.isOpen implies (self.Librarian->size() = 1) and (self.Calendar->size() = 1) context Library inv consistentNumberOfLoans: self.users.borrowedItems->sum() = self.loans->size() context Loan inv wellFormedLoans: issueDate <= dueDate

53. June 200553 Information spec – Static schema

54. June 200554 Information spec – Dynamic schema

55. June 200555 Computational Specifications

56. June 200556 Computational specification

57. June 200557 Computational specification

58. June 200558 Engineering Specifications

59. June 200559 Engineering specification

60. June 200560 Technology Specifications

61. June 200561 Technology specification - example

62. June 200562 ODP in MDA System Specifications

63. June 200563 What is MDA? An approach to system development using models as a basis for understanding, design, construction, deployment, operation, maintenance and modification Three essential elements: –specifying a system independently of the platform that supports it, –specifying platforms, –transforming the system specification into one for a particular choice of platform. Goals: portability, interoperability and reusability Prescribes the kinds of model to be used in specifying a system, how those models are prepared and the relationships between them

64. June 200564 What MDA does Identifies different viewpoints on a system –different abstractions - reflecting different concerns –providing a way of dealing with system complexity Specifies 3 kinds of viewpoint model for a system: –a computation independent model (CIM): a view of a system that specifies its function without specifying details of its structure –a platform independent model (PIM): a view of a system that specifies its computational structure independent of any specific platform - usable with different platforms of similar type. –a platform specific model (PSM): a view of a system that combines the specifications in the PIM with a specification of the use of a particular type of platform. Specifies transformations between models

65. June 200565 What MDA does not do MDA does not offer: a definition of the concerns and design decisions to be covered by each MDA model language constructs to express the concerns and decisions covered by each MDA model …but ODP can offer: a definition of the concerns and design decisions to be covered by each MDA model language constructs to express the concerns and decisions covered by each MDA model

66. June 200566 ODP Specifications and the MDA

67. June 200567 ODP and MDA together offer  separating and integrating different system concerns  combining skills and experience  assigning responsibilities  automating development An IT based approach to system development that provides a framework for:

68. June 200568 UML 4 ODP – (Some) Sources Japanese Association of Healthcare Information System Industry (JAHSI) - Hospital Information Reference Enterprise Model project European research projects: –e.g. COMBINE - investigating the organisation and process for component-based system development Industrial Practice OMG –UML profile for Enterprise Distributed Object Computing (EDOC) A worked example for the standard

69. June 200569 Progress and Targets Start of ProjectMay 2003 SC7 WDMay 2004SC7 meeting 1st CDDec 2004 FCDMay-Oct 2005 SC7 meeting FDISDec 2005 ISMay 2006 SC7 meeting Current WD is available as ISO-stds/04-06-01