Part I Viewpoint Modeling Antonio Vallecillo Universidad

Part I – Viewpoint Modeling Antonio Vallecillo Universidad de Málaga Dpto. Lenguajes y Ciencias de la Computación av@lcc. uma. es http: //www. lcc. uma. es/~av/ Nov 2006

Agenda 1. Viewpoint Modeling • ODS, Enterprise Architecture, Viewpoints, Models • Modeling approaches and standards 2. 3. Use of UML for ODP system specifications 4. ODP in MDA system specifications 5. Nov 2006 Model Driven Development and UML Conclusions 2

Large distributed systems A system is distributed when it executes spread over a set of computers Properties of distributed systems: Concurrency (efficiency, total execution time) Scalability and ordered growth Allow for mobility, replication, … Problems of distributed systems: No global view of the system Complex design, management, maintenance and evolution Communication delays and errors, possible Qo. S degradation No global clock (difficult synchronization among processes) Compatibility and interoperability problems (heterogeneity) Event races, asynchrony, … Distributed systems are more difficult to verify and test Nov 2006 3

Examples of large distributed systems Client-server systems Web applications (3 -4 tiers) Yahoo!, Google, Airlines portals, Banks portals, etc. Most commercial systems for retail shops Include several POS in a shop, shop servers, business server, warehouse computers, connection to financial services (banks, credit cards), suppliers, etc. Process farms SETI@home, folding@home P 2 P systems (Napster), Emule, Ka. Za. A Avionics and space systems Large and heterogeneous systems, many participants, many kinds of devices, embedded computers, critical operations Nov 2006 4

Open systems A system is open if its specifications are available This include making available information about: The standards it conforms to (international or de-facto) The software architecture of the system The interfaces required to interoperate with the system, exchange information with it, and extend it Open systems are independently extensible Open systems are different from open source systems None of these implies the other Open systems are not necessarily distributed systems But here we will deal with Open and Distributed Systems Nov 2006 5

Goals of ODS Portability of services and applications Interoperability between systems and services from different providers and parties Reusability Transparencies Access (invocation mechanisms and languages) Failure Location, Migration, Relocation Replication Transactions Extensibility and evolution Modularity and decoupling Nov 2006 6

Viewpoint modeling Different stakeholders see the system from different perspectives Managers, developers, maintainers, users, owner There are too many different concerns that need to be addressed in the design of an ODS Functionality, security, distribution, heterogeneity, … Viewpoint modeling is commonly used in other (more mature) engineering disciplines Different maps for a building (floor plants, electricity, water conductions, heating system, etc. ) Different maps for a city (physical, metro, buses, etc. ) Nov 2006 7

Viewpoint modeling initiatives Based on IEEE Std. 1471 This standards defines the main concepts and sets the global picture Commonly used in most modeling approaches UML (structural view, behavioural view) Web Engineering (Navigation, Presentation, Data, Process, etc. ) MDA (CIM, PSM) … Main proposals for Enterprise Architecture Kruchten’s “ 4+1 views” Zachman’s framework Do. D’s TOGAF ISO/IEC and ITU-T’s RM-ODP Nov 2006 8

IEEE Std. 1471 (2000) “IEEE Recommended Practice for Architectural Description of Software-Intensive System” Scope 1. 2. 3. 4. Expression of the system and its evolution Communication among the system stakeholders Evaluation and comparison of architectures in a consistent manner Planning, managing, and executing the activities of system development 5. Expression of the persistent characteristics and supporting principles of a system to guide acceptable change 6. Verification of a system implementation’s compliance with an architectural description 7. Recording contributions to the body of knowledge of software-intensive systems architecture Purpose “To facilitate the expression and communication of architectures and thereby lay a foundation for quality and cost gains through standardization of elements and practices for architectural description. ” Nov 2006 9

IEEE 1471 Main concepts Architect: The person, team, or organization responsible for systems architecture. Architectural description: A collection of products to document an architecture. Architecture: The fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution. System: A collection of components organized to accomplish a specific function or set of functions. View: A representation of a whole system from the perspective of a related set of concerns. Viewpoint: A specification of the conventions for constructing and using a view. A pattern or template from which to develop individual views by establishing the purposes and audience for a view and the techniques for its creation and analysis. Nov 2006 10

IEEE 1471 conceptual model of architectural description Nov 2006 11

IEEE 1471 viewpoints An AD shall identify the viewpoints selected for use, and include a rationale for the selection of each viewpoint Each viewpoint shall be specified by a) A viewpoint name, b) The stakeholders to be addressed by the viewpoint, c) The concerns to be addressed by the viewpoint, d) The language, modeling techniques, or analytical methods to be used in constructing a view based upon the viewpoint, e) The source, for a library viewpoint (the source could include author, date, or reference to other documents). A viewpoint specification may include additional information: Formal or informal consistency and completeness tests to be applied to the models making up an associated view Evaluation or analysis techniques to be applied to the models Heuristics, patterns, or other guidelines to assist in synthesis of an associated view Nov 2006 12

Viewpoint completeness and consistency An architectural description is consistent if none of its views imposes contradictory requirements on the rest of the viewpoints An architectural description is complete if it contains all the information required by the different kinds of stakeholders Nov 2006 13

Viewpoint examples UML views Requirements, Structure, Behaviour, Deployment Web Engineering viewpoints Navegation (hypertext) Presentation (and adaptation) Business Logic (processes) MDA Computation Independent Viewpoint (CIMs) Platform Independent Viewpoint (PIMs) Platform Specific Viewpoint (PSMs) Nov 2006 14

Krutchen’s “ 4+1 view model” Nov 2006 15

Krutchen views The logical view is the object model of the design (when an object-oriented design method is used), The process view captures the concurrency and synchronization aspects of the design, The physical view describes the mapping(s) of the software onto the hardware and reflects its distributed aspect, The development view describes the static organization of the software in its development environment The scenarios illustrate the system requirements and its basic functionality by means of use cases Scenarios are used at the beginning to capture the system requirements, to identify the mayor elements of the system, and at the end to illustrate and validate the system design Correspondences show elements in one view relate to elements in other views Nov 2006 16

Considerations about the “ 4+1 view model” It prescribes the viewpoints that should compose the architectural description of a system Not all views are required in all cases E. g. , for small systems It is methodology-independent Although IBM used it as the basis for RUP (v 1) It is also notation-independent UML supports well its views (apart from the development view) Nov 2006 17

Zachman’s framework Nov 2006 18

Considerations about the Zachman Framework It prescribes the viewpoints that should compose the architectural description of a system It is very detailed Probably too much! It means at least 36 high-level models for an application Zachman thinks all views are required in all cases Even for small systems It is methodology-independent The Popkin process tries to fill this gap It is also notation-independent Sowa tried to formalize some of the views Nov 2006 19

ODP Framework 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, data, functionality, distribution, technology It comprises A structure for system specifications in terms of viewpoints A set of object-oriented foundation modeling concepts common to all viewpoint languages A language (concepts and rules) for expressing each viewpoint specification A set of correspondences between the viewpoints A set of common functions A set of transparencies A set of conformance points A framework for ODP standards Nov 2006 20

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 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) Nov 2006 21

ODP Viewpoints—different concerns Information Enterprise System Computational Technology Engineering Nov 2006 22

An ODP system specification - business aspects - What for? Why? Who? When? - information - changes to information - constraints Enterprise Information - Object configuration - Interactions between objects at interfaces Computational - Mechanisms and services for distribution transparencies and Qo. S constraints. - Hardware and software components implementing the system Engineering Technology - and correspondences between specifications Nov 2006 23

ODP Correspondences Nov 2006 24

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: Communities (of enterprise objects) Objectives Enterprise objects Behaviour • Roles (fulfilled by enterprise objects in a community) • Processes (leading to Objectives) Policies Accountability The system is just another object Nov 2006 25

Example: A Bank Information System A bank is composed of branches, spread all over the country The bank’s central office manages and coordinates the branches’ activities Each branch has a manager and is responsible to provide banking services to its customers Branches may interact with each other and with the bank central office Each branch will have an ATM and a main server, and each branch’s employee will have a computer and a printer The Bank information system (BIS) will manage all ISrelated issues Nov 2006 26

BIS – Enterprise specification Each branch, and will be specified by a community Its goal is to “provide banking services to its customers” Its objects model the branch entities: people (“Joe Smith”, “Lucy Brown”), computers (PC #123 -45, printer #xyz), concrete bank accounts, etc. Its roles are: branch manager, controller, customer (active), …, or bank account, money, etc. (passive) Assignment policies (e. g. , the requirements of a person to become a customer) Policies: • Permissions: what can be done, e. g. money can be deposited into an open account • Prohibition: what must not be done, e. g. customers must not withdraw more than 600 Euros per day • Obligations: what must be done, e. g. the bank manager must advise customers when the interest rate changes, customers must present some ID for withdrawing money. • Authorizations: accounts of some VIP customers are allowed to have overdrawn. Nov 2006 27

BIS – Enterprise specification (ct’d) Environment contracts: e. g. , transactions performed using other banks’ ATMs should have effect within at most 24 hours; information about a branch’s customers cannot be disclosed to other branches Accountability: e. g. , the branch manager is responsible for authorizing an overdrawn, but can delegate to the branch’s controller officer The bank’s central office will be specified by another community It’s goal is to “manage and coordinate the branches’ activities” It’s objects are… It’s roles are … It’s assignment policies are… It’s policies are… Environment contracts… Accountability…. Branches may interact with each other and with the bank central office Nov 2006 28

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 Nov 2006 29

BIS – Information specification Describes a model with the information types, their relationships, and constraints on these types and relationships e. g. , a bank account consists a balance and the “amount-withdrawn-today”. Static schema captures the state and structure of a object at some particular instance e. g. , at midnight, the amount-withdrawn-today is 0. An invariant schema restricts the state and structure of an object at all times e. g. , the amountwithdrawn-today is less than or equal to 600. A dynamic schema defines a permitted change in the state and structure of an object e. g. a withdrawal of $X from an account decreases the balance by $X and increases the amount-withdrawn-today by $X. Static and dynamic schema are always constrained by invariant schemata $400 could be withdrawn in the morning but an additional $200 could not be withdrawn in the afternoon as the amount-withdrawn-today cannot exceed $500. Schemas can also be used to describe relationships or associations between objects e. g. , the static schema “owns account” could associate each account with a customer. Nov 2006 30

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. , Qo. S constraints) Nov 2006 31

BIS – Computational specification Objects in a computational specification can be application objects (e. g. a bank branch) or ODP infrastructure objects (e. g. a type repository or a trader) Objects interact at well defined interfaces, using signals, operations or flows. Bank. Teller = Interface Type { operation Deposit (c: Customer, a: Account, d: Dollars) returns OK (new_balance: Dollars) returns Error (reason: Text); operation Withdraw (c: Customer, a: Account, d: Dollars) returns OK (new_balance: Dollars) returns Not. Today (today: Dollars, daily_limit: Dollars) returns Error (reason: Text); } Nov 2006 32

BIS – Computational specification Interfaces allow subtyping Environment contracts capture non functional requirements Security, performance, availability, etc. Nov 2006 33

The engineering specification Specifies the mechanisms and services that provide the distribution transparencies and Qo. S 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 Highly dependent on the CV BEOs correspond to comp. objects Channels correspond to Binding objects Nov 2006 34

Grouping concepts Nov 2006 35

Channel structure Nov 2006 36

Multi-endpoint channel Nov 2006 37

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 Nov 2006 38

BIS – Technology specification Technology object types Types of PCs, servers, ATMs, printers Types of Operating Systems and Applications (text editors, etc) Types of connections (LANs, WANs, Intranets, etc. ) Technology selection process Providers’ selection and contracts Conformance points Compliance tests Implementation, deployment, maintenance, evolution Deployment plans Configuration guides Evolution plans Nov 2006 39

ODP Correspondences, Common Functions and Transparencies Correspondences An ODP specification of a system is composed of five views and a set of correspondences between them Correspondences do not belong to any view ODP distinguishes two kinds of correspondences • Required correspondences • Correspondence statements Common functions An ODP specification can make use of some of the common functions defined by the RM-ODP. They are “standard” Transparencies An ODP specification can implement some of the transparencies defined by the RM-ODP The specification should state which ones are used, and how they are implemented Nov 2006 40

Part II – Models, UML and DSLs Antonio Vallecillo Universidad de Málaga Dpto. Lenguajes y Ciencias de la Computación av@lcc. uma. es http: //www. lcc. uma. es/~av/ Nov 2006

Model Driven Development (MDD) An approach to software development in which the focus and primary artifacts of development are models (as opposed to programs) and model transformations (compare with current language-driven approaches, whose firstclass entities are “programs” and “compilers”) MDD implies the (semi) automated generation of implementation(s) from models Modeling languages are key to MDD Model transformation languages are also modeling languages Models conform to meta-models MDA is the OMG’s proposal for MDD, using OMG standards: MOF, UML, OCL, XMI, QVT MOF y UML allow the definition of new families of languages Nov 2006 42

What is a Model? A description of (part of) a system written in a well-defined language. (Equivalent to specification. ) [Kleppe, 2003] A representation of a part of the function, structure and/or behavior of a system [MDA, 2001] A description or specification of the system and its environment for some certain purpose. A model is often presented as a combination of drawings and text. [MDA Guide, 2003] A set of statements about the system. [Seidewitz, 2003] (Statement: expression about the system that can be considered true or false. ) Nov 2006 43

What is a Metamodel? A model of a well-defined language [Kleppe, 2003] A model of models [MDA, 2001] A model that defines the language for expressing a model [MOF, 2000] A meta-metamodel is a model that defines the language for expressing a metamodel. The relationship between a meta-metamodel and a metamodel is analogous to the relationship between a metamodel and a model. A model of a modelling language [Seidewitz, 2003] That is, a metamodel makes statements about what can be expressed in the valid models of a certain modelling language. Nov 2006 44

Four-layers metamodel hierarchy Nov 2006 45

Four-layers metamodel hierarchy (example) Nov 2006 46

OMG standards for modeling MDA is MDD using OMG standards MOF • Meta Object facility UML • Unified Modeling Language OCL • Object Constraint Language XMI Metadata Interchange MOF QVT • Query/View/Transformation Nov 2006 47

MOF Metamodel (simplified) Nov 2006 48

UML (2. 0) The Unified Modeling Language (UML) is a general-purpose visual language for specifying, constructing and documenting the artifacts of systems. UML (2. 0) defines Thirteen types of diagrams, for representing: • The static application structure ¤ class, object, component, deployment, composite structure • Different aspects of dynamic behavior ¤ use case, statechart, activity, interaction (collaboration, sequence, communication, interaction overview, timing) Three ways for organizing and managing the application modules • models, packages, subsystems Plus a set of extension mechanisms (UML Profiles) Nov 2006 49

UML 2. 0: Four parts Infrastructure – UML internals More precise conceptual base Superstructure – User level features New capabilities for large-scale systems Consolidation of existing features Alignment with mature modeling languages (e. g. SDL, HMSC) Better extension capabilities (profiles) OCL 2. 0 – Constraint Language Full conceptual alignment with UML A general purpose query language Diagram interchange For exchanging graphical information (model diagrams) Size and relative position of diagrams elements Nov 2006 50

OCL (Object Constraint Language) A formal language used to describe expressions on UML models. Expressions typically specify invariant conditions that must hold for the system being modeled, queries over objects described in a model, pre and post-conditions on actions and operations constraints on model elements. When the OCL expressions are evaluated, they do not have side effects; i. e. their evaluation cannot alter the state of the corresponding executing system. OCL expressions can however be used to specify operations / actions that, when executed, do alter the state of the system. OCL expressions are all typed Nov 2006 51

OCL expressions context c : Company inv enough. Employees: c. number. Of. Employees > 50 Nov 2006 52

OCL expressions (I) context Company inv Only. One. Over 50: self. employee->select(p : Person | p. age > 50)->size()=1 context Person: : income : Integer init: parents. income->sum() * 1% -- pocket allowance derive: if under. Age then parents. income->sum() * 1% -- pocket allowance else job. salary -- income from regular job endif context Person: : get. Current. Spouse() : Person pre: self. is. Married = true body: self. mariages->select(m | not m. ended). spouse context Job inv: self. employer. number. Of. Employees >= 1 inv: self. employee. age > 21 Nov 2006 53

OCL expressions (II) context Person inv: let income : Integer = self. job. salary->sum() in if is. Unemployed then income < 100 else income >= 100 endif context Person def: income : Integer = self. job. salary->sum() def: nickname : String = ’Little Red Rooster’ def: has. Title(t : String) : Boolean = self. job->exists(title = t) context Person: : income (d: Date) : Integer post: result = age * 1000 context Person: : birthday. Happens() post: age = age@pre + 1 context Company: : hire. Employee(p : Person) post: employees = employees@pre->including(p) and stockprice() = stockprice@pre() + 10 Nov 2006 54

New (improved) alignments in 2. 0 Nov 2006 55

Language definition mechanisms Nov 2006 56

UML 2. 0 Profiles specialize UML for specific domains When there is no need to change UML 2. 0 metamodel and semantics, just to extend or customize them A Profile is a metamodel concept Defined on metamodel Used on model Excellent mechanism for defining MDA “Platforms” Examples: OMG standards: • • EAI: Enterprise Application Integration EDOC: Enterprise Distributed Object Computing CORBA, CCM Schedulability, Performance and Time Proprietary: • UML-RT: UML for Real Time Nov 2006 57

UML 2. 0 Extension mechanisms Stereotypes A stereotype defines how an existing metaclass may be extended It enables the use of platform or domain specific terminology or notation in place of, or in addition to, the ones used for the extended metaclass. UML already defines some of them (<>, <>, …) Tag definitions and tagged values Just like a class, a stereotype may have properties (tag definitions) When a stereotype is applied to a model element, the values of the properties are referred to as tagged values They are pairs label/value {label = value} Constraints A profile may define a set of (OCL) constraints on the stereotyped elements (well-formedness rules of the models defined by the extension) Nov 2006 58

You may want to use a UML Profile to 1. 2. 3. 4. Nov 2006 Give a terminology that is adapted to a particular platform or domain (e. g. capturing some of the EJB terminology: home interfaces, enterprise java beans, archives) Give a syntax for constructs that do not have a notation (such as in the case of actions) Give a different notation for already existing symbols (e. g. , use a picture of a computer instead of the ordinary node symbol) Add semantics that is left unspecified in the metamodel (e. g. , assign priorities to signals in a statemachine) 59

You may want to use a UML Profile to 5. 6. Add constraints that restrict the way you may use the metamodel and its constructs (such as disallowing actions from being able to execute in parallel within a single transition) 7. Nov 2006 Add semantics that does not exist in the metamodel (such as defining a timer, clock, or continuous time) Add information that can be used when transforming a model to another model or code (such as defining mapping rules between a model and Java code) 60

Example of a UML 2. 0 Profile A profile that allows to assign colors and weights to some elements of a model -- Constraint: -- connected elements should -- be colored in the same color context Colored inv: self. base. Class. connection-> for. All(c | (c. extension. Colored->not. Empty()) implies c. extenstion. Colored. color=self. color) Nov 2006 61

Another example We want to model the connections of a system that follows a star-shaped topology context My. Topology: : Main. Node inv: self. localnodes ->for. All (n : Node | n. location = self. location) inv: self. target ->for. All(n : Main. Node | n. location <> self. location) Nov 2006 62

Steps to define a Profile Define the conceptual model of the platform or domain for which we want to define the profile For each element (concept, association) in the conceptual model: Choose one (or more) UML elements that can be used to represent the element Define a stereotype Define the tag definitions of the sterotypes, using the attributes of the elements of the conceptual model Define the Profile constraints, based on the conceptual model constraints and invariants (association multiplicities, OCL constraints) Nov 2006 63

Profile for the Star Topology Nov 2006 64

Profile constraints definitions context Node -- Connected to exactly one local edge and to no edges inv: self. base. Class. connection->select(extension. Local. Edge->not. Empty())->size()=1 and self. base. Class. connection->select(extension. Edge->not. Empty())->is. Empty() context Local. Egde -- all nodes it connects should have the same location inv: self. base. Association. connection-> select(participant. extension. Node->not. Empty())-> collect(participant. extension. Node. location)-> union(select(participant. extension. Main. Node->not. Empty())-> collect(participant. extension. Main. Node. location))-> for. All(l 1, l 2 | l 1 = l 2) inv : -- a local edge connects exactly one main node self. base. Association. connection-> select(participant. extension. Main. Node->not. Empty() and multiplicity. min=1 and multiplicity. max=1)->size()=1 context Egde: -- an edge only connects main nodes inv : self. base. Association. connection-> select(participant. extension. Node->not. Empty())->is. Empty() and select(participant. extension. Main. Node->not. Empty())-> collect(participant. extension. Main. Node. location)->for. All(l 1, l 2 | l 1 <> l 2) Nov 2006 65

Use of a UML Profile Nov 2006 66

MOF extensions vs. Profiles Choose a MOF extension if: The domain is well defined, with widely accepted concepts You do not need to combine applications from different domains Yo need to “break” the semantics of UML to represent the domain concepts Choose a Profile if: The domain is not standard or not stable Applications from the domain can be combined with applications from other domains You can just “extend” the semantics of UML to represent the domain concepts Nov 2006 67

UML 2. 0 Profile Example: EJB Platform Nov 2006 68

Part III UML for ODP system specification Antonio Vallecillo Universidad de Málaga Dpto. Lenguajes y Ciencias de la Computación av@lcc. uma. es http: //www. rm-odp. net/ Nov 2006

“UML 4 ODP” ITU-T X. 906 | ISO/IEC 19793: Use of UML for ODP system specifications 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” Nov 2006 70

UML 4 ODP Why? RM-ODP is notation- and methodology- independent Which is an advantage (a-priori). . . but hampers its widespread adoption and use Target audiences UML Modelers • who need to structure (somehow) their LARGE system specifications ODP Modelers • who need some (graphical) notation for expressing their ODP specifications and tool support Modeling tool suppliers • who wish to develop UML-based tools that are capable of expressing RM-ODP viewpoint specifications. Nov 2006 71

UML 4 ODP This Recommendation | International Standard defines: a UML based notation for the expression of ODP specifications an approach for structuring of them using the notation, thus providing the basis for model development methods It provides: The expression of a system specification in terms of RM-ODP viewpoint specifications using defined UML concepts and extensions • A set of UML 2. 0 profiles (one for each viewpoint) • A way of using these profiles (structuring rules) relationships between the resultant RM-ODP viewpoint specifications; • A way of modelling ODP correspondences • A profile for correspondences A way for modelling conformance of implementations to specifications; • A profile for conformance (reference points, conformance staments, etc. ) relationships between RM-ODP viewpoint specifications and model driven architectures such as the OMG MDA Nov 2006 72

UML 4 ODP – Document structure Foreword 0 Introduction 1 Scope 2 Normative references 3 Definitions 4 Abbreviations 5 Conventions 6 Overview of modelling and system specification approach 7 Enterprise Specification 8 Information Specification 9 Computational Specification 10 Engineering Specification 11 Technology Specification 12 Correspondences specification 13 Modelling conformance in ODP system specifications 14 Conformance and compliance to this document Annex A UML profiles for ODP languages using ITU-T guidelines for UML profile design Annex B An example of ODP specifications using UML Annex C Relationship with MDA® Annex D Architectural Styles Nov 2006 73

UML 4 ODP Clause 6 6 Overview of modelling and system specification approach 6. 1 Introduction 6. 2 Overview of ODP concepts (extracted from RM-ODP-1) 6. 3 Overview of UML concepts 6. 4 Universes of discourse, ODP specs and UML models 6. 5 General principles for expressing and structuring ODP system specifications using UML 6. 6 Correspondences between viewpoint specifications Nov 2006 74

UML 4 ODP Clause 6. 4 (Uo. D, ODP specifications and UML models) Nov 2006 75

UML 4 ODP Clause 6. 5 (Principles for expressing and structuring ODP specs using UML) The DSLs used to represent the viewpoint languages are defined using the UML lightweight extension mechanism (UML Profiles) The ODP system specification will consist of a single UML model stereotyped as «ODP_System. Spec» , that contains a set of models, one for each viewpoint specification, each stereotyped as «_Spec» , where is the viewpoint concerned Stereotypes are used to represent domain specific specializations of UML metaclasses in order to express the semantics of the RM-ODP viewpoint language concerned Each viewpoint specification uses the appropriate UML profile for that language, as described in Clauses 7 to 11 Nov 2006 76

ODP System specification structure Nov 2006 77

Enterprise metamodel (excerpt 1) Nov 2006 78

Enterprise metamodel (excerpt 2) Nov 2006 79

Enterprise Profile: Classifiers (excerpt) Nov 2006 80

Information Language metamodel Nov 2006 81

Information Profile Nov 2006 82

UML 4 ODP Clause 6. 6 (Correspondences) Correspondences are key to viewpoint modeling They form part of the ODP specification of a system Correspondences are not part of any viewpoint specification Correspondences are expressed in UML too Nov 2006 83

UML 4 ODP Clauses 7 -11 X Specification X. 1 Modelling concepts • A brief description of the language • Summary of the MOF-metamodel X. 2 UML Profile • Description on how the language concepts are mapped to UML, by extending the appropriate metaclasses • UML specification of the profile X. 3 specification structure (in UML terms) • UML packages and grouping rules X. 4 Viewpoint correspondences for the language • Description of the correspondences to other viewpoints • Not in UML (clause 12) Nov 2006 84

UML 4 ODP Clauses 12 -14 12 Correspondences specification 12. 1 Modelling concepts 12. 2 UML Profile 13 Modelling conformance in ODP system specifications 13. 1 Modelling concepts 13. 2 UML profile 14 Conformance and compliance to this document 14. 1 Conformance 14. 2 Compliance Nov 2006 85

Correspondence metamodel Nov 2006 86

Correspondence Profile Nov 2006 87

Conformance Profile Nov 2006 88

UML 4 ODP Annexes Annex A: UML profiles for ODP languages using ITU-T guidelines for UML profile design Annex B An example of ODP specifications using UML Annex C Relationship with MDA Annex D Architectural Styles Nov 2006 89

Annex C: Relation with MDA Nov 2006 90

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 Nov 2006 91

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 types of transformations between models Nov 2006 92

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 Nov 2006 93

ODP Specifications and the MDA Nov 2006 94

ODP and MDA together offer An IT based approach to system development that provides a framework for: § § combining skills and experience § assigning responsibilities § Nov 2006 separating and integrating different system concerns automating development 95

Progress and Targets Start of Project SC 7 WD 1 st CD 2 nd CD FDIS? May 2003 May 2004 SC 7 meeting Dec 2004 May-Oct 2005 SC 7 meeting May 2006 WG 19 meeting Dec 2006 WG 19 meeting Current WD is available as ISO-stds/04 -06 -01 Nov 2006 96