Part I

1
Part I Viewpoint Modeling

• Antonio Vallecillo
• Universidad de Málaga
• Dpto. Lenguajes y Ciencias de la Computación
• av_at_lcc.uma.es
• http//www.lcc.uma.es/av/

2
Agenda

• Viewpoint Modeling
• ODS, Enterprise Architecture, Viewpoints, Models
• Modeling approaches and standards
• Model Driven Development and UML
• Use of UML for ODP system specifications
• ODP in MDA system specifications
• Conclusions

3
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 QoS
  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

4
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_at_home, folding_at_home
• P2P systems
• (Napster), Emule, KaZaA
• Avionics and space systems
• Large and heterogeneous systems, many
  participants, many kinds of devices, embedded
  computers, critical operations

5
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

6
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

7
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.)

8
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, PIM, PSM)
• Main proposals for Enterprise Architecture
• Kruchtens 41 views
• Zachmans framework
• DoDs TOGAF
• ISO/IEC and ITU-Ts RM-ODP

9
IEEE Std. 1471 (2000)

• IEEE Recommended Practice for Architectural
  Description of Software-Intensive System
• Scope
• 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
• Expression of the persistent characteristics and
  supporting principles of a system to guide
  acceptable change
• Verification of a system implementations
  compliance with an architectural description
• 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.

10
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.

11
IEEE 1471 conceptual model of architectural
description
12
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

13
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

14
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)

15
Krutchens 41 view model
16
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 how elements in one view
  relate to elements in other views

17
Considerations about the 41 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 (v1)
• It is also notation-independent
• UML supports well its views (apart from the
  development view)

18
Zachmans framework
19
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

20
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

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

22
ODP Viewpointsdifferent concerns
23
An ODP system specification
- and correspondences between specifications
24
ODP Correspondences
25
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

26
Example A Bank Information System

• A bank is composed of branches, spread all over
  the country
• The banks 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 branchs employee will have a computer
  and a printer
• The Bank information system (BIS) will manage all
  IS-related issues

27
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.

28
BIS Enterprise specification (ctd)

• Environment contracts e.g., transactions
  performed using other banks ATMs should have
  effect within at most 24 hours information about
  a branchs customers cannot be disclosed to other
  branches
• Accountability e.g., the branch manager is
  responsible for authorizing an overdrawn, but can
  delegate to the branchs controller officer
• The banks central office will be specified by
  another community
• Its goal is to manage and coordinate the
  branches activities
• Its objects are
• Its roles are
• Its assignment policies are
• Its policies are
• Environment contracts
• Accountability.
• Branches may interact with each other and with
  the bank central office

29
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

30
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.

31
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)

32
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.
• BankTeller 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 NotToday (today Dollars, daily_limit
  Dollars)
• returns Error (reason Text)

33
BIS Computational specification

• Interfaces allow subtyping
• Environment contracts capture non functional
  requirements
• Security,
• performance,
• availability,
• etc.

34
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
• Highly dependent on the CV
• BEOs correspond to comp. objects
• Channels correspond to Bindingobjects

35
Grouping concepts
36
Channel structure
37
Multi-endpoint channel
38
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

39
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

40
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

41
Part II Models, UML and DSLs

• Antonio Vallecillo
• Universidad de Málaga
• Dpto. Lenguajes y Ciencias de la Computación
• av_at_lcc.uma.es
• http//www.lcc.uma.es/av/

42
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 first-class 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 OMGs proposal for MDD, using OMG
  standards
• MOF, UML, OCL, XMI, QVT
• MOF y UML allow the definition of new families of
  languages

43
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.)

44
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.

45
Four-layers metamodel hierarchy
46
Four-layers metamodel hierarchy (example)
47
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

48
MOF Metamodel (simplified)
49
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)

50
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

51
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

52
OCL expressions
context c Company inv enoughEmployees
c.numberOfEmployees gt 50
53
OCL expressions (I)

• context Company inv OnlyOneOver50
• self.employee-gtselect(p Person p.age gt
  50)-gtsize()1
• context Personincome Integer
• init parents.income-gtsum() 1 -- pocket
  allowance
• derive if underAge
• then parents.income-gtsum() 1 -- pocket
  allowance
• else job.salary -- income from regular job
• endif
• context PersongetCurrentSpouse() Person
• pre self.isMarried true
• body self.mariages-gtselect(m not
  m.ended).spouse
• context Job
• inv self.employer.numberOfEmployees gt 1
• inv self.employee.age gt 21

54
OCL expressions (II)

• context Person inv
• let income Integer self.job.salary-gtsum() in
• if isUnemployed then income lt 100 else income gt
  100 endif
• context Person
• def income Integer self.job.salary-gtsum()
• def nickname String Little Red Rooster
• def hasTitle(t String) Boolean
  self.job-gtexists(title t)
• context Personincome (d Date) Integer
• post result age 1000
• context PersonbirthdayHappens()
• post age age_at_pre 1
• context CompanyhireEmployee(p Person)
• post employees employees_at_pre-gtincluding(p)
  and
• stockprice() stockprice_at_pre() 10

55
New (improved) alignments in 2.0
56
Language definition mechanisms
57
UML 2.0 Profiles

• 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

58
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 (ltlttracegtgt,
  ltltdevicegtgt,)
• 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)

59
You may want to use a UML Profile to

1. 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)
2. Give a syntax for constructs that do not have a
   notation (such as in the case of actions)
3. Give a different notation for already existing
   symbols (e.g., use a picture of a computer
   instead of the ordinary node symbol)
4. Add semantics that is left unspecified in the
   metamodel (e.g., assign priorities to signals in
   a statemachine)

60
You may want to use a UML Profile to

1. Add semantics that does not exist in the
   metamodel (such as defining a timer, clock, or
   continuous time)
2. 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)
3. 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)

61
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.baseClass.connection-gt
forAll(c (c.extensionColored-gtnotEmpty())
implies
c.extenstionColored.colorself.color)
62
Another example

• We want to model the connections of a system
  that follows a star-shaped topology
• context MyTopologyMainNode
• inv self.localnodes -gtforAll (n Node
  n.location self.location)
• inv self.target -gtforAll(n MainNode
  n.location ltgt self.location)

63
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)

64
Profile for the Star Topology
65
Profile constraints definitions
context Node -- Connected to exactly one local
edge and to no edges inv self.baseClass.conn
ection-gtselect(extensionLocalEdge-gtnotEmpty())-gtsi
ze()1 and self.baseClass.connection-gtselect(exte
nsionEdge-gtnotEmpty())-gtisEmpty() context
LocalEgde -- all nodes it connects should have
the same location inv self.baseAssociation.co
nnection-gt select(participant.extensionNode-gtnotE
mpty())-gt collect(participant.extensionNode.locat
ion)-gt union(select(participant.extensionMainNode
-gtnotEmpty())-gt collect(participant.extensionMain
Node.location))-gt forAll(l1, l2 l1 l2)
inv -- a local edge connects exactly one main
node self.baseAssociation.connection-gt
select(participant.extensionMainNode-gtnotEmpty()
and multiplicity.min1 and
multiplicity.max1)-gtsize()1 context Egde -- an
edge only connects main nodes inv
self.baseAssociation.connection-gt select(partic
ipant.extensionNode-gtnotEmpty())-gtisEmpty() and
select(participant.extensionMainNode-gtnotEmpty()
)-gt collect(participant.extensionMainNode.locatio
n)-gtforAll(l1, l2 l1 ltgt l2)
66
Use of a UML Profile
67
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

68
UML 2.0 Profile Example EJB Platform
69
Part IIIUML for ODP system specification

• Antonio Vallecillo
• Universidad de Málaga
• Dpto. Lenguajes y Ciencias de la Computación
• av_at_lcc.uma.es
• http//www.rm-odp.net/

70
UML4ODP

• 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

71
UML4ODP

• 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.

72
UML4ODP

• 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

73
UML4ODP 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

74
UML4ODP 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

75
UML4ODP Clause 6.4 (UoD, ODP specifications and
UML models)
76
UML4ODP 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_SystemSpec,
  that contains a set of models, one for each
  viewpoint specification, each stereotyped as
  ltXgt_Spec, where ltXgt 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

77
ODP System specification structure
78
Enterprise metamodel (excerpt 1)
79
Enterprise metamodel (excerpt 2)
80
Enterprise Profile Classifiers (excerpt)
81
Information Language metamodel
82
Information Profile
83
UML4ODP 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

84
UML4ODP Clauses 7-11

• X ltViewpointgt Specification
• X.1 Modelling concepts
• A brief description of the ltviewpointgt language
• Summary of the ltviewpointgt 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 ltViewpointgt specification structure (in UML
  terms)
• UML packages and grouping rules
• X.4 Viewpoint correspondences for the
  ltViewpointgt language
• Description of the correspondences to other
  viewpoints
• Not in UML (clause 12)

85
UML4ODP 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

86
Correspondence metamodel
87
Correspondence Profile
88
Conformance Profile
89
UML4ODP 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

90
Annex C Relation with MDA
91
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

92
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

93
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

94
ODP Specifications and the MDA
95
ODP and MDA together offer
An IT based approach to system development that
provides a framework for

• separating and integrating different system
  concerns
• combining skills and experience
• assigning responsibilities
• automating development

96
Progress and Targets

• Start of Project May 2003
• SC7 WD May 2004 SC7 meeting
• 1st CD Dec 2004
• 2nd CD May-Oct 2005 SC7 meeting
• FCD May 2006 WG19 meeting
• FDIS? Dec 2006 WG19 meeting

Current WD is available as ISO-stds/04-06-01