1. Part I – Viewpoint Modeling
Antonio Vallecillo
Universidad de Málaga
Dpto. Lenguajes y Ciencias de la Computación
Título: MDA: mito o realidad?
Resumen:
La Arquitectura Dirigida por Modelos (Model Driven Architecture, MDA®), es una iniciativa de OMG que propone el uso de modelos como piezas básicas para el diseño y la construcción de aplicaciones software. Los principales objetivos que persigue MDA son la separación de la lógica del negocio de las plataformas de implementación, la modularidad, la generación automatizada de implementaciones, y la descomposición arquitectónica del sistema en modelos independientes que representen distintas vistas o aspectos particulares del mismo. MDA cuenta ahora mismo con grandes promotores, y comienza a ser utilizada en varios sectores de la industria del software. Sin embargo, también cuenta con bastantes detractores que cuestionan su utilidad. En esta charla discutiremos los conceptos y mecanismos que introduce MDA, sus puntos fuertes y débiles, así como los pros y los contras que puede acarrear actualmente su adopción en entornos empresariales.
Objetivos:
- conocer la filosofía y mecanismos básicos de MDA
- discutir los puntos fuertes y débiles de la propuesta, de acuerdo a su estado actual
- presentar algunos casos de uso y experiencias reales
- tratar de fijar los contextos propios para su aplicación
- discutir las líneas abiertas y los campos en donde actualmente se trabaja

2. Agenda Viewpoint Modeling Model Driven Development and UML
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
Nov 2006

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

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

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

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

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

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
Kruchten’s “4+1 views”
Zachman’s framework
DoD’s TOGAF
ISO/IEC and ITU-T’s RM-ODP
Nov 2006

9. IEEE Std (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 implementation’s 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.”
Nov 2006

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

11. IEEE 1471 conceptual model of architectural description
Nov 2006

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

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

14. Viewpoint examples UML views Web Engineering viewpoints MDA
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

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

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

17. 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 (v1)
It is also notation-independent
UML supports well its views (apart from the development view)
Nov 2006

18. Zachman’s framework
Nov 2006

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

20. ODP Framework
The Reference Model of ODP (ITU-T Rec X | 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

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

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

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

24. ODP Correspondences
Nov 2006

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

26. 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 IS-related issues
Nov 2006

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

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

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

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

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

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 NotToday (today: Dollars, daily_limit: Dollars) }
Nov 2006

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

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 Binding objects
Nov 2006

35. Grouping concepts
Nov 2006

36. Channel structure
Nov 2006

37. Multi-endpoint channel
Nov 2006

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

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

40. ODP Correspondences, Common Functions and Transparencies
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

41. Part II – Models, UML and DSLs
Antonio Vallecillo
Universidad de Málaga
Dpto. Lenguajes y Ciencias de la Computación

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

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

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

45. Four-layers metamodel hierarchy
Nov 2006

46. Four-layers metamodel hierarchy (example)
Nov 2006

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

48. MOF Metamodel (simplified)
Elemento principal para posibilitar la tecnología MDA.
Proporciona conceptos y herramientas para razonar sobre lenguajes de modelado y transformaciones.
Repositorio MOF
Define un formato de intercambio para modelos de M1 llamado XMI (XML Metadata Interchange), basado en XML.
Nov 2006

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

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

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

52. OCL expressions context c : Company
inv enoughEmployees: c.numberOfEmployees > 50
Nov 2006

53. OCL expressions (I) context Company inv OnlyOneOver50:
self.employee->select(p : Person | p.age > 50)->size()=1
context Person::income : Integer
init: parents.income->sum() * 1% -- pocket allowance
derive: if underAge
then parents.income->sum() * 1% -- pocket allowance
else job.salary -- income from regular job
endif
context Person::getCurrentSpouse() : Person
pre: self.isMarried = true
body: self.mariages->select(m | not m.ended).spouse
context Job
inv: self.employer.numberOfEmployees >= 1
inv: self.employee.age > 21
Nov 2006

54. OCL expressions (II) context Person inv:
let income : Integer = self.job.salary->sum() in
if isUnemployed then income < 100 else income >= 100 endif
context Person
def: income : Integer = self.job.salary->sum()
def: nickname : String = ’Little Red Rooster’
def: hasTitle(t : String) : Boolean = self.job->exists(title = t)
context Person::income (d: Date) : Integer
post: result = age * 1000
context Person::birthdayHappens()
post: age = + 1
context Company::hireEmployee(p : Person)
post: employees = and
stockprice() = + 10
Nov 2006

55. New (improved) alignments in 2.0
Nov 2006

56. Language definition mechanisms
Nov 2006

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

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 (<<trace>>, <<device>>,…)
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

59. You may want to use a UML Profile to
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)
Nov 2006

60. You may want to use a UML Profile to
Add semantics that does not exist in the metamodel (such as defining a timer, clock, or continuous time)
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)
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)
Nov 2006

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->
forAll(c | (c.extensionColored->notEmpty()) implies
c.extenstionColored.color=self.color)
Nov 2006

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

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

64. Profile for the Star Topology
Nov 2006

65. Profile constraints definitions
context Node -- Connected to exactly one local edge and to no edges
inv: self.baseClass.connection->select(extensionLocalEdge->notEmpty())->size()=1 and
self.baseClass.connection->select(extensionEdge->notEmpty())->isEmpty()
context LocalEgde -- all nodes it connects should have the same location
inv: self.baseAssociation.connection->
select(participant.extensionNode->notEmpty())->
collect(participant.extensionNode.location)->
union(select(participant.extensionMainNode->notEmpty())->
collect(participant.extensionMainNode.location))-> forAll(l1, l2 | l1 = l2)
inv : -- a local edge connects exactly one main node
self.baseAssociation.connection->
select(participant.extensionMainNode->notEmpty() and multiplicity.min=1 and multiplicity.max=1)->size()=1
context Egde: -- an edge only connects main nodes
inv : self.baseAssociation.connection->
select(participant.extensionNode->notEmpty())->isEmpty() and
select(participant.extensionMainNode->notEmpty())->
collect(participant.extensionMainNode.location)->forAll(l1, l2 | l1 <> l2)
Nov 2006

66. Use of a UML Profile
Nov 2006

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

68. UML 2.0 Profile Example: EJB Platform
Nov 2006

69. Part III UML for ODP system specification
Antonio Vallecillo
Universidad de Málaga
Dpto. Lenguajes y Ciencias de la Computación

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

71. UML4ODP Why? Target audiences
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

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

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®
Annex D Architectural Styles
Nov 2006

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

75. UML4ODP Clause 6.4 (UoD, ODP specifications and UML models)
Nov 2006

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 «<X>_Spec», where <X> 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

77. ODP System specification structure
Nov 2006

78. Enterprise metamodel (excerpt 1)
Nov 2006

79. Enterprise metamodel (excerpt 2)
Nov 2006

80. Enterprise Profile: Classifiers (excerpt)
Nov 2006

81. Information Language metamodel
Nov 2006

82. Information Profile
Nov 2006

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

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

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

86. Correspondence metamodel
Nov 2006

87. Correspondence Profile
Nov 2006

88. Conformance Profile
Nov 2006

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

90. Annex C: Relation with MDA
Nov 2006

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

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

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

94. ODP Specifications and the MDA
Nov 2006

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

96. Progress and Targets Current WD is available as ISO-stds/04-06-01
Start of Project May 2003
SC7 WD May 2004 SC7 meeting
1st CD Dec 2004
2nd CD May-Oct SC7 meeting
FCD May 2006 WG19 meeting
FDIS? Dec WG19 meeting
Current WD is available as ISO-stds/
Nov 2006