d'après les textes des groupes de travail de l'omg
Post on 22-Jan-2016
24 Views
Preview:
DESCRIPTION
TRANSCRIPT
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.
top related