d'après les textes des groupes de travail de l'OMG Quelques considérations sur l'évolution du formalisme UML [Le court, le moyen et le long terme] d'après les textes des groupes de travail de l'OMG Jean Bézivin Université de Nantes Faculté des Sciences et Techniques 2, rue de la Houssinière BP 92208 44322 Nantes Cedex 3 Tel. 02 51 12 58 13 Cell. 06 14 32 22 36 E.mail. Jean.Bezivin@sciences.univ-nantes.fr

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 Historique Rappel : le processus OMG Quelques rencontres importantes Le court terme : UML 1.4 Le moyen terme : UML 2.0 Le 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 Booch Chief Scientist Rational Software Corporation

Historique : Évolution de UML 0.8 ->0.9 0.9->0.91->1.0 1.0->1.1->1.2->1.3 1.3 1.4 2.0 x.y

La vision OMG de l'unification 1.0 ->1.1->1.2->1.3 -> 1.4 ->…-> 2.0 Soumission de UML 1.0 à l'OMG Pour recommendation (janvier 1997). Industrialisation UML 1.0 Standardisation (juin 96 - oct. 96) UML 0.9 & 0.91 UML expertise des partenaires Retours publics OOPSLA’95 Unified Method O.8 Unification Booch 93 OMT-2 Fragmentation Autres méthodes Booch 91 OMT-1 OOSE

Rappel: Processus d'adoption des technologies proposée par l'OMG Board Approval DTC or PTC Recommendation Final AB Review Evaluation The OMG technology adoption process is based on government-like Request for Proposal cycles: Since adopted technology must be based on commercially-available software, an RFI is issued to establish what technology will shortly be commercially available, and what requirements OMG should and could put on specifications. Then a specific RFP (with a set of requirements) is sent out. Responses comprise both a specification for perusal by the TC, and a set of terms and conditions of license, used by the Architecture Board. The AB is responsible for internal consistency of all OMG specs (existing and proposed), in the contect of business, market and technical realities. After parallel evaluation and recommendation processes within the DTC and PTC, the OMG Board of Directors makes a final decision. RFI RFP AB Review (Architecture Board) DTC = Domain Technical committee. PTC = Platform Technical committee. Task Force

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 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 techniques Nice Montréal Mesa

Réunion de la Task Force OA&D, à Nice le 7 novembre 1996 Minutes of the OMG ADTF Meeting in Nice, France 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. … Nice consacre le choix d'abandonner la recherche impossible de la méthode unifiée. Nice voit le choix stratégique difficile entre la précision et la modularité.

Devant et derrière, Avant et après ... OMT procédés industriels de production. UML SA/RT SADT ERD Merise DFD etc. JSD

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 Moyen terme Court terme

Court terme : UML 1.4 Les profils Corrections 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 RFPs Infrastructure Superstructure OCL Diagram 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 Extensibility – Mandatory requirements – Optional requirements 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

Le RFP Superstructure Structural modeling Behavioral modeling – 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

Les RFP OCL et Echange de Diagrammes – Mandatory requirements – Optional requirements Les RFP OCL et Echange de Diagrammes OCL OCL metamodel Improve expressive power preserving declarative nature Provide formal semantics for OCL Diagram interchange Define MOF-compliant metamodel to specify graphical elements and their layout together with relation to semantic metaclasses

Procédures, Pascal, C, ... Objets, Classes, Smalltalk, C++, ... 1980 1995 2000 Technologie procédurale Technologie des objets Technologie des composants Technologie des modèles Procédures, Pascal, C, ... Objets, Classes, Smalltalk, C++, ... Packages, Frameworks, Patterns, … Modèles, Méta-Modèles, UML, MOF, XML, XMI, XSLT, … Raffinement procédural Composition d'objets Transformation de modèles

De multiples modèles a c b de test e g f d etc. modèle de déploiement modèle d'analyse modèle de conception objets métier c b a d f e g processus règles use cases de test etc. coût ressources

Les deux bus CORBA, IDL, IIOP,... MOF, UML, XML,... Java Cobol C# UML CWM MOF, UML, XML,... Workflow Software Process

Évolution vers le MOF (c) (a) (b) MOF UML MOF UML PWG UML Workflow etc. unModèle UML UML_FBO unModèle Common Warehouse Metadata (CWM) unModèle

Hiérarchie de l'organisation Le MOF M3 Le méta-modèle UML et les autres MMs M2 Des modèles UML et d'autres modèles M1 Diverses utilisations des modèles M0

Organisation comparée EBNF Avantages : Généralité Structuration/Architecture OCL Exemple: Passage d’une approche langage comme QML vers une approche m-modèle. MOF La grammaire de Pascal Le méta-modèle UML Un programme Pascal P Un modèle UML M Une exécution du Programme P Un phénomème correspondant au modèle M

Espaces M1, M2 et M3 M3 M2 M2 M2 M1 M1 M1 M1 M1

Modèles de produits et de procédés MOF Similaires aux structures de données Similaires aux structures de contrôle UML UPM Cobol Java Workflow CMC EJB RUP PWG etc. etc.

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 d'optimisation Hypothèse de base: le seul référentiel est le code. Directives de Mise au point preconditions postconditions Algorithmique Synchronization Sécurité Organisation du code (include, etc.) Code exécutable

Schéma classique : les deux opérations Un aspect projection réification Code exécutable

x class superclass superclass x class implements: #+ Réification x class x class superclass superclass x class implements: #+ Basé sur le schéma à modèle unique MC C I

BUS Le schéma à modèles séparés en ligne. Modèle d'exécution Modèle d'usage (Use Cases) Modèle de tests Modèle de domaine Modèle de ressources Modèle de conception BUS Modèle d'architecture Modèle de déploiement Modèle d'exécution

Exemple Modèle de validation Modèle de conception Modèle de tests contrat Modèle de tests 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) Remarques Coût de la gestion des modèles en ligne Extraction 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.