d'apr

1
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

• Jean Bézivin
• Université de Nantes

2
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é.

3
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

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

5
Questions centrales

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

6
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

7
Historique Évolution de UML

• 0.8 -gt0.9
• 0.9-gt0.91-gt1.0
• 1.0-gt1.1-gt1.2-gt1.3
• 1.3

1.4
2.0
x.y
8
La vision OMG de l'unification
1.0 -gt1.1-gt1.2-gt1.3 -gt 1.4 -gt-gt 2.0
Soumission de UML 1.0 à l'OMG Pour
recommendation (janvier 1997).
Industrialisation
UML 1.0
Standardisation
UML 0.9 0.91
(juin 96 - oct. 96)
UML expertise des partenaires
Retours publics
OOPSLA95 Unified Method O.8
Unification
Booch 93
OMT-2
Fragmentation
Autres méthodes
Booch 91
OOSE
OMT-1
9
Rappel Processus d'adoption des technologies
proposée par l'OMG
Board Approval
DTC or PTC Recommendation
Final AB Review
Evaluation
RFI
RFP
AB Review (Architecture Board)
DTC Domain Technical committee. PTC Platform
Technical committee.
Task Force
10
(No Transcript)
11
Groupes de travail
12
ANALYSIS DESIGN TASK FORCE Plenary Meeting
Agenda Burlingame, CA, USA 13 September 2000
13

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

14
Le travail de la RTF
15

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

16
Quelques rendez-vous importants

• Analyse des contributions de quelques réunions
  techniques
• Nice
• Montréal
• Mesa

17
Réunion de la Task Force OAD,à 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é.

18
Devant et derrière,Avant et après ...
OMT
UML
procédés industriels de production.
SA/RT
SADT
ERD
Merise
DFD
etc.
JSD
19
Proposition IBM/Objectime
20
Réunion de la Task Force OAD,à Montréal le 26
juin 1997

• Mary Loomis a animé une discussion sur les
  propositions dactivité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
• Lingénierie de projection aller-retour
  (round-trip engineering)
• La connexion CDIF (subject area OAD)  Echange
  par fichiers
• Interopérabilité entre outils OAD et autres
  outils tel que simulateurs
• Définition des correspondances entre SDL et UML
• Mécanismes dextensibilité  à 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 lanalyse 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é.

21
Réunion de la Task Force OAD,à 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

22
Evolution d'UML
Moyen terme
Court terme
23
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

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

25
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

26
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

27
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

28
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

29
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

30
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

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

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

33
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

34
Le RFP Infrastructure
Mandatory requirements Optional requirements

• 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

35
Le RFP Superstructure
Mandatory requirements Optional requirements

• 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

36
Les RFP OCL et Echange de Diagrammes
Mandatory requirements Optional requirements

• 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

37
2000
1980
1995
Technologie procédurale
Technologie des composants
Technologie des objets
Technologie des modèles
Objets, Classes, Smalltalk, C, ...
Procédures, Pascal, 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
38
De multiples modèles
39
Les deux bus
Java
CORBA, IDL, IIOP,...
Cobol
C
UML
CWM
MOF, UML, XML,...
Workflow
Software Process
40
Évolution vers le MOF
(c)
(a)
(b)
MOF
UML
MOF
UML
PWG
Workflow
etc.
UML
unModèle
UML_FBO
unModèle
Common Warehouse Metadata (CWM)
unModèle
41
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
42
Organisation comparée
EBNF
Avantages Généralité Structuration/Architectur
e OCL Exemple Passage dune 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
43
Espaces M1, M2 et M3
44
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
RUP
PWG
EJB
CMC
etc.
etc.
45
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

46
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
47
Schéma classique les deux opérations
Un aspect
projection
réification
Code exécutable
48
Réification

• x class
• x class superclass superclass
• x class implements
• Basé sur le schéma à modèle unique

MC
C
I
49
Le schéma à modèles séparés en ligne.
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
50
Exemple
Modèle de validation
Modèle de conception
contrat


Modèle de tests


Voir aussi les modèles explicites de patterns.
51
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

52
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.
53
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

54
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 nest
  pas encore reconnu en France.