d'après les textes des groupes de travail de l'OMG

Jean BézivinUniversité de Nantes

Faculté des Sciences et Techniques2, rue de la Houssinière

BP 9220844322 Nantes Cedex 3

Tel. 02 51 12 58 13Cell. 06 14 32 22 36

E.mail. Jean.Bezivin@sciences.univ-nantes.fr

[Le court, le moyen et le long terme]

Quelques considérations sur l'évolution du formalisme

UML

Résumé

On connaît la façon dont le consensus a été établi sur une notation unifiée pour la description des artefacts logiciels dans la technologie des objets. Depuis la version 1.0, le langage UML connaît un succès croissant, qui dépasse parfois le cadre strict de la description de systèmes logiciels. À l'OMG, tout en finalisant la version 1.4, le groupe de révision du langage (RTF) a mis en chantier une proposition pour la version 2.0. En dehors de ce cadre officiel, de nombreuses autres propositions d'extension sont régulièrement faites, souvent pertinentes et intéressantes, mais qui posent la question de la définition précise du périmètre d'application de la notation UML. Pour répondre à cette question, il est possible de considérer UML comme une famille de langages ou encore de s'appuyer sur l'architecture standard de méta-modélisation de l'OMG (MOF). Différents scénarios sur l'évolution de la norme UML seront évoqués dans l'exposé.

Plan

HistoriqueRappel : le processus OMGQuelques rencontres importantesLe court terme : UML 1.4Le moyen terme : UML 2.0Le long terme : MOF, QoS, etc.Conclusions

Questions centrales

En l'an 2000, un responsable de service informatique a fait développer une application, avec une modélisation préalable en UML 1.3.

Les modèles correspondants ont été stockés en format Rose .mdl. En 2010, une refonte substantielle de cette application est nécessaire

Hormis le responsable de service, le personnel ayant participé à la réalisation n'est plus en place.

Questions : Le modèle UML a-t'il évolué en même temps que la maintenance de

l'application ? Existe-t'il des outils permettant de retravailler ce modèle en version 1.3? En supposant que l'on soit en 2010 en version 7.34 d'UML, peut on convertir

le modèle initial ? Est on captif de la série initiale d'outils (Rose) ou peut-on migrer vers

d'autres outils ?

Questions centrales

Comment concilier souci de standardisation, pérennité des formalismes et des outils avec ouverture et extensibilité ?

Getting serious with UML

"In short: the time for experimentation is past;

the time for stability and use is now."

Grady BoochChief Scientist

Rational Software Corporation

Historique : Évolution de UML

0.8 ->0.90.9->0.91->1.01.0->1.1->1.2-

>1.3

1.3

UML d'après les «amigos»

OMT ObjectoryBooch

UML

J imRumbaugh Grady Booch I var J acobson

1.4

2.0

x.y

La vision OMG de l'unification

Fragmentation

Unification

Standardisation

Industrialisation

Autres méthodes Booch 91 OOSEOMT-1

Booch 93 OMT-2

OOPSLA’95 Unified Method O.8

UML 0.9 & 0.91UML

expertise despartenaires

UML 1.0

Soumission de UML 1.0 à l'OMG Pour recommendation (janvier 1997).

(juin 96 - oct. 96)

Ret

ours

pu

blic

s

1.0 ->1.1->1.2->1.3 -> 1.4 ->…-> 2.0

Rappel: Processus d'adoption des technologies proposée par

l'OMG

Task Force

RFI RFP AB Review (Architecture Board)

Evaluation

Final AB Review

Board Approval

DTC or PTC Recommendation

DTC = Domain Technical committee.PTC = Platform Technical committee.

Groupes de travail

ANALYSIS & DESIGN TASK FORCE Plenary Meeting Agenda

Burlingame, CA, USA 13 September 2000

Relevant Deadline(s)

•RFP-5 Action Semantics RFP Initial submission deadline: 08/15/00 Voting list deadline: 08/30/00 RFP Status: In progress

•RFP-9 UML Profile for Scheduling, Performance, and Time ("Realtime") RFP Initial submission deadline: 08/15/00 Voting list deadline: 07/31/00 RFP Status: In progress

•RFP-11 XMI Production of XML Schema RFP Revised submission deadline: 08/28/00 RFP Status: In progress

•RFP-12 Profile for Event-based Architectures in EAI RFP Initial submission deadline: 08/21/00 Voting list deadline: 08/15/00 RFP Status: In progress

Dès qu'une recommendation est adoptée, une RTF est créée, qui prend en responsabilité l'évolution de cette recommendation.

What's New September 15, 2000

(Burlingame, CA): OMG issues three UML 2.0 RFPs. The OMG Platform Technology Committee voted by acclamation to issue a set of  three  UML 2.0 Request for Proposals.

September 15, 2000 (Burlingame, CA): OMG votes to extend UML 1.4 revision deadline. The OMG Platform Technology Committee voted by acclamation to extend the deadline for the recommended changes for the UML 1.4 minor revision from November 1 to December 22, 2000. The extension will allow for a more complete QA review cycle before the revision is finalized.

Le travail de la RTF

The following artifacts are related to UML 2.0 RFPs that have already been issued by the OMG Platform Technology Committee: UML 2.0 RFPs (OMG document ad/2000-09-05) -- A presentation by the co-chairs of the UML 2.0 Working Group that summarizes the process and the content for the OMG 2.0 Infrastructure, Superstructure and OCL RFPs. UML 2.0 Infrastructure RFP (OMG document ad/2000-09-01) -- A UML 2.0 RFP issued September 15, 2000 that is primarily concerned with architectural alignment, restructuring and extension mechanisms. UML 2.0 Superstructure RFP (OMG document ad/2000-09-02) -- A UML 2.0 RFP issued September 15, 2000 that is primarily concerned with the refinement and extension of UML 1.x semantics and notation. UML 2.0 OCL RFP (OMG document ad/2000-09-03)  -- A UML 2.0 RFP that is primarily concerned with defining an OCL metamodel.

Quelques rendez-vous importants

Analyse des contributions de quelques réunions techniquesNiceMontréalMesa

Réunion de la Task Force OA&D,à Nice le 7 novembre 1996

1. Minutes of the OMG ADTF Meeting in Nice, France2. The following are the minutes of the OMG Analysis and Design Task Force

meeting held in Nice France on November 7, 1996. Mike Bradley of BellSouth chaired the meeting. Mike Meier of IBM took minutes. …

3. Nice consacre le choix d'abandonner la recherche impossible de la méthode unifiée.

4. Nice voit le choix stratégique difficile entre la précision et la modularité.

Devant et derrière,Avant et après ...

UMLOMT

Merise

SA/RT

ERDERD

SADTSADT

DFDDFDDFDDFD

etc.

procédés industriels de production.

JSDJSD

Proposition IBM/Objectime

is a refinement of

Core Meta-Model

67 Formally defined Meta-Types

Modeling Schemes

(for specific languages)Extension Mechanism

Object Constraint Language (OCL)

OA&D Standard

Réunion de la Task Force OA&D,à Montréal le 26 juin 1997

Mary Loomis a animé une discussion sur les propositions d’activités futures (par exemple de futurs appels à proposition RFP). On trouvera ci-dessous le résultat de cette discussion préliminaire.

Le procédé (software process), le génie des procédés (process engineering). Compléter le formalisme. Rendre OCL accessible au niveau M1 Vérification de conformité des outils AGL L’ingénierie de projection aller-retour (round-trip engineering) La connexion CDIF (subject area OA&D) ; Echange par fichiers Interopérabilité entre outils OA&D et autres outils tel que simulateurs Définition des correspondances entre SDL et UML Mécanismes d’extensibilité “ à la scheme ” et modèles de standardisation de ces schémas. Dresser une correspondance de STEP/EXPRESS, IDEF, ER, Définir un métamodèle universel Une notation humain-lisible (textuel, non-graphique) permettant aussi l’échange Les composants,( les composants-métiers) - appliquer UML pour construire des modèles de composants Alignement avec le BOF, le groupe Workflow, le CF règles événement-condition-action, le RFP Composant, le sous-comité

Modèle de Référence Objet (ORMSC) Définitions de l’analyse par apport à la conception

Ceci a été suivi par quelques discussions de priorités. Il ressort de cet échange que le point “ streamed/file” constitue la plus haute priorité.

Réunion de la Task Force OA&D,à Mesa le 12 janvier 2000

Analyser les résultats du RFI UML 2.0 (26 réponses)

Délimiter le périmètre; Eviter l'implosion

Le premier bilan significatif après une période significative d'utilisation de UML

Evolution d'UML

<<docum ent>>UM L 1.1

<<docum ent>>UM L 1.2

<<docum ent>>UM L 1.3

<<refine>>

<<docum ent>>UM L 1.4

<<docum ent>>UM L 2.0

<<refine>>

<<refine>>

<<refine>>

Q3 1997(OM G AdoptedTechnology)

Q2 1998

Q3 1999

Q3 2000(planned m inor revision)

2001(planned m ajor revision)

Editorial revis ionwith no significanttechnical changes.

ISO PubliclyAvailable

Specifications(PAS)

Other relevantstandards TBA

<<inform alLiaison>>

<<form alLiaison>>

Unification of m ajorm odeling languages,including Booch, O MTand Objectory

Court terme

Moyen terme

Court terme : UML 1.4

Les profilsCorrections de détail (incohérences,

bruits, sur-spécifications, etc.)Modélisation par rôles (amélioration)Types primitifs, énumérations,

gestion des sous-systèmes, etc.Amélioration couplage XMI

Les profils UML

A UML profile is a grouping construct for UML model elements that have been customized for a specific domain or purpose using extension mechanisms such as stereotypes, tagged values and constraints. For example, the UML Profile for CORBA RFP customizes UML for specifying CORBA IDL.

The UML specification for profiles will be significantly improved in the next minor revision of UML, UML 1.4, which is planned for Q4 2000.

Le moyen terme : UML 2.0

OMG UML 1.x has emerged as the dominant software modeling language Successfully applied to a wide range of domains, ranging from

health and finance to aerospace and e-commerce. Extensive use has raised numerous usage and

implementation issues by modelers and vendors Further evolution requires major changes outside the scope of a

Revision Task Force Need for a major UML revision substantiated by vendor

and user feedback AD PTF UML Architectural Roadmap UML 2.0 Request for Information (RFI)

There is widespread support for a major revision that will address substantive usage and implementation issues

La préparation du RFP UML 2.0

AD PTF UML Architectural Roadmap Requirements established by the UML RTF and updated with the results of the UML 2.0 RFI.

UML 2.0 RFI 26 submissions from vendors, users, academics, consultants and other standards

organizations

UML 2.0 RFP Physical meetings during last 4 TC meetings Biweekly telecons since Oslo TC meeting 10 to 40 participants at each meeting and telecon

2/21 3/28 5/2 6/6 7/11 8/15 9/19 10/24 11/28 1/2 2/6 3/12 4/16 5/21 6/25 7/30 9/3 10/8

Apr ’99 Jul ’99 Oct ’99 Jan ’00 Apr ’00 Jul ’00 Oct ’00

Architectural Roadmap

UML 2.0 RFI

UML 2.0 RFP Draft

La réorganisation architecturale d'UML

UML architecture MOF alignment using strict meta-modeling Modular separation into language kernel and profiles Remove vague/gratuitous/unused constructs

Extensibility First-class extensibility mechanism Support language customization

Component-based modeling Relationships Behavioral modeling

Structuring of interactions Reduce restrictions on activity diagrams

Model management Support for modeling of architectures

Diagram interchange

Analyse du RFI UML 2.0

Most prominent enhancement requests Precise and unambiguous language kernel Additional concepts layered on top of kernel MOF compliance First-class extensibility mechanism Support for component-based development Internal structure of classifiers Limit associations to context Statemachine generalization Scalability and encapsulation of statemachines Structuring of interactions and sequence diagrams Modeling of architectures Abstract data flow modeling Specify mapping from notation to abstract syntax

Respondents suggested a major revision is urgent Initial submission requested by end of 2000

La rédaction du RFP UML 2.0

UML RTF Architectural Roadmap ad/00-06-01 RFI Response Submitters Meeting Mesa, Jan 2000

Collected and evaluated RFI responses Identified problems and requirements UML 2.0 Summarized in ad/00-01-07

RFP Drafting Meeting Denver, March 2000 Assessed problems and requirements Aligned requirements with architectural roadmap Produced UML 2.0 RFP draft ad/00-06-06

RFP Drafting Meeting Oslo, June 2000 Reviewed mandatory and optional requirements Discussed desirability of multiple RFPs

RFP Drafting & Review Telecons, July/August 2000 Refined requirements in biweekly telecons Recognized strong support for multiple RFPs Produced final drafts of multiple RFPs

La structure du RFP UML 2.0

Divided UML 2.0 Effort into multiple RFPsInfrastructureSuperstructureOCLDiagram interchange

Requirements modularly separated into cohesive units to preserve architectural integrity, to facilitate distributed collaborations, and to facilitate final integration

Les relations avec les autres spécifs de l'OMG

The UML 2.0 is a major revision to the UML 1.x version series, which includes OMG UML 1.1 and all of its subsequent minor revisions. In general, proposals should be consistent with, and use the terminology of the most current UML 1.x specification at the time of submission. If there is reason to deviate from UML 1.x terminology in order to make a major revision that reason should be clearly explained. Submitters are strongly encouraged to consider backward-compatibility issues when recommending major revisions; gratuitous changes to the current UML specification are strongly discouraged.

The UML 2.0 must be compliant with the most current Meta-Object Facility Specification (currently 1.3, OMG document formal/2000-04-01) at the time of the submission. Proposals for UML 2.0 may suggest revisions to the Meta Object Facility, but they should try to minimize the impact on existing MOF usage.

The UML 2.0 shall reconcile with the action semantics proposal under development (see the RFP, OMG document ad/98-11-01).

The UML 2.0 shall take into account existing profiles for components, if any. The UML 2.0 must be complementary to UML-related adopted technologies

such as XMI (currently 1.1, OMG document formal/2000-06-01). Therefore the vocabulary and underlying models of these adopted technologies must be used whenever possible. Restrictions and extensions to these technologies must be called out explicitly.

Caractéristiques générales du RFP UML 2.0

Infrastructure (ad/00-08-08) Improve the architectural alignment with MOF and XMI Restructure UML to be easier to understand, implement and extend Provide first class extension mechanisms and profiles that are consistent

with the metamodel architecture

Superstructure (ad/00-08-09) Enable the modeling of structural patterns, such as component-based

development and the specification of run-time architectures Support encapsulation and scalability in behavioral modeling, in particular,

for state machines and interactions Remove restrictions on activity graph modeling due to the mapping to state

machines Clarify semantics of generalization, dependency, and association

OCL (ad/00-08-10) Define an OCL metamodel consistent with the UML metamodel Increase the expressive power of OCL

Diagram interchange (ad/00-08-11)

Critères généraux d'évaluation

Requirements on all RFPs Enforce separation of concerns between semantics and notation;

provide precise bi-directional mapping Minimize impact on UML 1.x, XMI 1.x and MOF 1.x Identify vague/gratuitous/too specific/unused language elements

to be retired from the language Specify an XMI DTD for the metamodel

Proposals are preferred that Unify mechanisms and concepts (rather than introduce or maintain

several, but similar mechanisms) Describing mechanisms at an abstract level (rather than provide

concrete or implementation-oriented mechanisms) Address requirements using concepts and notations already

deployed (rather than introduce new concepts or notations) Provide simple mappings between Notation Guide and Semantics Are backwards compatible or provide mappings

Le RFP Infrastructure

Architectural alignment Strict alignment with MOF and 4-layer metamodel architecture Share model elements between MOF and UML kernel Identify clearly delineated kernel Identify semantic variation points in the kernel

Extensibility First-class extension mechanism consistent w/

profiles/architecture Restructure so that profiles can specialize the kernel semantics Improve and specify dependencies between metamodel

packages Define new diagrams in profiles

– Mandatory requirements – Optional requirements

Le RFP Superstructure

Structural modeling System development based on plug-substitutable components and

reusable interaction patterns between components Run-time architecture of classifiers in terms of hierarchical decom-

position of its internal structure, including dynamic behavior Data flow modeling at high-level of abstraction

Behavioral modeling Improve scalability through encapsulation and decomposition Clarify semantics of state machines (generalization, protocol) Improve control/data flow and event handling in activity graphs

Relationships Clarify semantics of generalization and dependencies Specify scope covered by associations

Improve consistency, provide notation for patterns Align with other specification languages

– Mandatory requirements – Optional requirements

Les RFP OCL et Echange de Diagrammes

OCLOCL metamodel Improve expressive power preserving

declarative natureProvide formal semantics for OCL

Diagram interchangeDefine MOF-compliant metamodel to specify

graphical elements and their layout together with relation to semantic metaclasses

– Mandatory requirements – Optional requirements

Technologieprocédurale

Technologiedes composants

Technologiedes objets

Objets,Classes,

Smalltalk,C++,

...

Procédures,Pascal,

C,...

Packages,Frameworks,

Patterns,…

1980 1995 2000

Raffinementprocédural

Technologiedes modèles

Modèles,Méta-Modèles,

UML,MOF,XML,XMI,

XSLT,…

Compositiond'objets

Transformationde modèles

De multiples modèles

modèle dedéploiement

modèle d'analysemodèle

de conceptionobjets métier

cb

a

d fe g

processus métier

règles métier

usecases

modèle de test

etc.modèle de

coût

modèle deressources

Les deux bus

Cobol

CORBA, IDL, IIOP,... CORBA, IDL, IIOP,...

Java

Workflow

MOF, UML, XML,... MOF, UML, XML,...

UML

Software Process

CWM

C#

Évolution vers le MOF

UMLUML MOFMOF

UMLUMLunModèleunModèle

unModèleunModèle

MOFMOF

UMLUML

UML_FBOUML_FBO

unModèleunModèle

PWGPWG WorkflowWorkflow etc.etc.

Common Warehouse Metadata (CWM)

Common Warehouse Metadata (CWM)

(a) (b) (c)

Hiérarchie de l'organisation

Le MOF

Le méta-modèle UML et les autres MMs

Des modèles UML et d'autres modèles

Diverses utilisations des modèles

M0

M1

M2

M3

Organisation comparée

MOF

Le méta-modèleUML

Un modèleUML M

Un phénomème correspondantau modèle M

EBNF

La grammairede Pascal

Un programmePascal P

Une exécution du Programme P

Avantages :GénéralitéStructuration/ArchitectureOCL

Exemple:Passage d’une approche langagecomme QMLvers une approche m-modèle.

Espaces M1, M2 et M3

M3

M2

M1

M2

M1

M2

M1 M1M1

Modèles de produits et de procédés

MOFMOF

UMLUMLUPMUPM

RUPRUP PWGPWG

CobolCobol

EJBEJB

JavaJava

etc.etc.etc.etc.

Similaires auxstructures de données

Similaires auxstructures de contrôle

WorkflowWorkflow

CMCCMC

La modélisation par aspects

Pléonasme ?Option différente de la

programmation par aspects (AspectJ, etc.)

Place du modèle de code: organisation centralisée ou décentralisée

Projection et Réification

Le code source comme référentiel global

Directives deMise au point

Directivesd'optimisation

Synchronization

Sécurité

Codeexécutable

Algorithmique

Organisationdu code(include, etc.)

preconditionspostconditions

Hypothèse de base:le seul référentiel est le code.

Schéma classique : les deux opérations

Un aspect

Codeexécutable

projectionréification

Réification

x classx class superclass superclass

x class implements: #+

Basé sur le schéma à modèle unique

MC

C

I

BUS BUS

Modèled'exécution

Modèled'exécution

Modèled'architecture

Modèled'architecture

Modèlede déploiement

Modèlede déploiement

Modèlede domaine

Modèlede domaine

Modèlede conception

Modèlede conception

Modèlede tests

Modèlede tests

Modèled'usage (Use Cases)

Modèled'usage (Use Cases)

Modèlede ressources

Modèlede ressources

Le schéma à modèles séparés en ligne.

Exemple

Modèle de conception

Modèle de validation

Modèle de tests

contrat

Voir aussi les modèles explicites de patterns.

Organisation par modèles séparés en ligne

x class package maintenanceTeam leader

(traversée de plusieurs frontières de modèles)

RemarquesCoût de la gestion des modèles en ligneExtraction des informations

Application au traitement de le QoS

QoS et caractéristiques non-fonctionnelles Fonctionnel : ce que l'on fait Non-Fonctionnel : comment on le fait

Exemples Fiabilité, Disponibilité, Récupérabilité Sécurité Efficacité, Capacité Performance, Réactivité (temps de réponse) Précision Utilisabilité Compatibilité par rapport à des interfaces (normes) Portabilité Modifiabilité, Flexibilité Coût Qualités du code (clarté, etc.) etc.

Les caractéristiques NF sont parfois aussi importantes que les caractéristiques F.

Quelques principes

Toute caractéristique différente de QoS (NFR) a vocation à se trouver dans un modèle séparé.

Chaque modèle séparé est défini par un MM

Chaque MM de produit doit être défini en relation avec les autres MM

À tout MM de produit de QoS il faut associer un MM de processus et éventuellement des MM de profils

Conclusions : Problèmes ouverts

Prise en compte sérieuse de la modularité : par profils ou par méta-modèles.

Prise en compte du quoi (fonctionnel) et du comment (non-fonctionnel, qualité de service, etc.).

Gestion globale régulière des modèles (MIMS Meta-Information Management Systems), y compris systèmes de transformation

Vers une théorie de la traçabilité totale (Total Traceability Management).

Relations entre M. de produits et M. de procédés, entre M. exécutables et non exécutables, etc.

UML et le MOF ont ouvert une voie d’évolution qui ne va pas se refermer de sitôt. La recherche est en retard sur les développements dans ces domaines. Le domaine de recherche des MIMS n’est pas encore reconnu en France.