Philippe Desfray – Laurent Fourmy

1. L'épopée de UML Philippe Desfray – Laurent Fourmy

2. UML : Les origines • La diversité des modèles de données et de traitement : par exemple, Entité association (Chen 1974), Machines à états fini, Automates de Harel, etc. • Les modèles à Objet réunissent ces premiers modèles (+70 en 1994, 30 réellement industriels) • Les leaders du marché : OMT, Booch, Jacobson fusionnent • Effort de l’OMG pour standardiser les méthodes objet : accent sur l’interopérabilité (1996) • L’OMG standardise UML 1.1 (1997) • L’OMG maintient UML (UML 1.3, UML 1.4) • L’OMG prévoit une révision majeure de UML (UML2.0 - 2002?)

3. UML – Définition(fournie dans les tutoriaux OMG) The UML is a graphical language for • specifying • visualizing • constructing • documenting the artifacts of software systems

4. UML Les bénéfices • Une notation unique et standard : • Connue de tous • Pour tous les domaines informatiques • Exploitable pour la plupart des niveaux de développement (Analyse préliminaire … code) • Utilisée même en dehors du domaine de l’informatique (Organisation d’entreprise, Ingénierie des systèmes, etc.) • Une sémantique définie par un métamodèle • Un format d’échange entre ateliers

5. UML : Le contenu • 9 types de diagrammes (class, use case, deployment, composants, collaboration, state, sequence, activity, object) • Un mécanisme d’extension : les profiles UML (tagged values, stereotypes, constraints)

6. Se déplacer Ecouter de la musique Téléphoner CONDUCTEUR GARAGISTE Faire la vidange Changer les bougies Modèle des USE CASE Acteur Cas d’utilisation

7. USE CASES : Utilisation • Très employé, bon outil pour formaliser les besoins • Identification des acteurs «aisée» • Découverte et décomposition des Use Case plus délicate: • Granularité des Use Case? • Exhaustivité des définitions de Use Cases? • Niveau de description d’un Use Case?

8. DIAGRAMME DE SÉQUENCE : PRINCIPE Objet2:Classe2 Objet3:Classe3 Objet1:Classe1 message1 () message2 (p1,p2) message3 ()

9. Diagrammes de séquence : Utilisation • Faciles à faire, faciles à comprendre • Attention à définir la juste quantité : niveau de détail potentiellement infini ! • Attention à travailler au bon niveau : il est aisé de fournir des détails opérationnels intéressant la conception lors de l’analyse • UML 2.0 : Fournir des moyens de structuration des diagrammes de séquence

10. DIAGRAMME DE COLLABORATION : PRINCIPE 1: messageX () Objet1:Classe1 Objet2:Classe2 role att1 = 10 att2 = «hello» 2: messageY (1,«x») Objet3:Classe3

11. DIAGRAMME DE COLLABORATION • La notion de rôle, sous jacente est peu employée • Expression de mécanismes, en montrant la coopération entre objets, • A un aspect redondant avec les diagrammes de séquence • Difficultés pour limiter le niveau de détail nécessaire • UML 2.0 : Améliorer la gestion de l’imbrication d’objets, pour mieux gérer les architectures. Améliorer la modélisation de patterns

12. DIAGRAMME DE CLASSES : EXEMPLE EtatAvancement visualiser( ) imprimer( ) etatCourant 1 1 0..* historique Activite Projet Lot nom : string nom : string nom : string lot tempsPrevu : float tempsPrevu : float 0..* creerLot (unNom : string temsConsomme : float tempsConsomme : float / tempsRestant : float 0..* activite / tempsRestant : float historiserEtatCourant( ) visualiser( ) 1 1 membreEquipe 0..* 0..* chefDeProjet Collaborateur trigramme : string motDePasse : string modifierMotDePasse (unMot : string) :

13. Diagramme de classes : Le cœur du modèle • Le plus utilisé, le plus indispensable • Partie la plus décisive, pour le succès et la qualité d’un développement • Nécessité de précision et d’exhaustivité • Grande difficulté pour définir les diagrammes de classes : trouver les classes, faire les bon choix de formes de modélisation... • UML 2.0 : • Positionner les classes vs types vs rôles, vs interface et restructurer le métamodèle. • Débat sur une sémantique plus fine des associations (types d’agrégation, etc.)

14. DIAGRAMME DE PACKAGES : EXEMPLE LIVRAISONS LIVREURS VEHICULES COLIS

15. Diagrammes de Packages : Mode d’emploi • Très utilisés, indispensables pour les grands modèles, • Indispensable pour définir l’architecture d’un modèle, pour gérer un modèle, et son développement par une équipe • Utile dès l’analyse et fondamental en conception • Il est très difficile de définir la bonne structure d’un modèle (itération nécessaire sur la définition des packages) • UML 2.0 : Nécessité de retravailler les sous-systèmes, de positionner les composants (CBD) et la notion de modèle

16. DIAGRAMME D’ETAT

17. DIAGRAMME D’ETAT • Utilisé beaucoup dans les applications “temps réel”, très peu dans les systèmes de gestion • Peut décrire : • 1 le comportement de classes réactives • 2 le protocole d’utilisation de toute classe • UML 2.0 : structurer les state diagrams, définir de manière plus claire les protocol state diagrams, définir la signification de l’héritage de state diagrams

18. Activity diagrams

19. DIAGRAMME D’ACTIVITÉ • Utile pour représenter des aspects dynamiques d’un système à un niveau assez général • Principalement utilisé dans les applications de gestion • Uml 2.0 : supprimer la dépendance avec les state diagrams, et clarifier la sémantique; définir une notion plus générale de flot de données

20. DIAGRAMME DE DÉPLOIEMENT ET COMPOSANTS : EXEMPLE

21. Diagrammes de déploiement • Expriment la localisation des différents constituants d’un système • Utiles pour les applications réparties/distribuées. • (UML 2.0) Doivent être re-visités pour mieux modéliser le déploiement de composants

22. Utilisation des modèles UML Modèle Exemple d’utilisation Nature Use case Expression du besoin D Classe et package Modèle conceptuel, modèle de données, S organisation Séquence Exemple de fonctionnement D Collaboration Coopération entre objets D Explication d’architecture Etat/transition Dynamique de fonctionnement D Activité Workflow, Dynamique de fonctionnement D Composant Modèle physique, organisation des ressources S Déploiement Distribution, diagramme d’architecture S

23. Well-Formedness Rules : Langage OCL • Example of semantic rule: Class [1] • English: If a Class is concrete, all the Operations of the Class should have a realizing Method in the full descriptor. • OCL: not self.isAbstract implies self.allOperations->forAll (op | self.allMethods->exists (m | m.specification-> includes(op)))

24. Profiles UML : UML adapté à chaque domaine LES PROFILES STRUCTURENT LES EXTENSIONS UML <<profile>> UML 1.3 <<profile>> <<profile>> <<profile>> <<profile>> EDOC REAL TIME CORBA EJB <<profile>> COMPONENT UML 1.4, sous la conduite de SOFTEAM à l’OMG, étend la définition des profiles

25. Nom standard Etat RFP Réponse intermédiaire Date standardisation Description UML Profile for CORBA Standardisé en septembre Correspondance UML/CORBA Software Process Engineering Management Voté Deux réponses en compétition Q1 2001 SOFTEAM a chairé cet effort, et fait partie des répondant : technique de modélisation du process logiciel. UML profile for Enterprise Distributed Object Computing (EDOC) Voté Deux réponses en competition fusionnent Q1 2001 Très orienté « Composants ». Les partenaires « COMBINE » de SOFTEAM participent. UML Profile Scheduling for performances and Time Voté Oui. Les acteurs majeurs du temps réel sont unis. Juin 2001 Annotation permettant de raisonner sur les consommations de ressources et de temps. UML profile for EAI Voté Oui Q1 2001 EAI est un domaine important, connecté avec EDOC QoS and fault tolerance Décembre 15 Aout 2001 Adaptation de UML à chaque domaine : Les standards prévus

26. > 8 7-8 5-6 3-4 1-2 Retours OMG sur l’utilisation de UML 4.1.5. What parts of the language should be removed?4.1.4. What parts of the language need clarification?4.1.3. What constructs in the language are least used?4.1.2. What constructs in the language are most used? Legend (responses)

27. Utilisation de UML dans l’industrie Modèle Niveau d’utilisation Classe et package 5 Le plus utilisé, le plus essentiel Use case 3 Dépend des cultures. Il y a des domaines où cela a peu d’intérêt Séquence 3 Assez employé, bien compris Collaboration 2 Les diagrammes d’objet sont utilisés, mais la modélisation des collaboration et des rôles est encore marginale Etat/transition 2 Très utilisé dans le temps réel, peu utilisé dans le tertiaire. Activité 1 Arrivée tardive dans les ateliers, habitude culturelle locale à certaines parties du tertiaire Composant/Déploiement 1 Peu de personnes l’utilisent, sur peu de parties de leurs applications

28. UML : Un très grand nombre d’apports hétérogènes Role modeling, Notion de type vs classes Notion d’interface (Java, CORBA) Notion de design patterns Temps réel Modélisation des processus de gestion Diagrammes d ’états avec plusieurs interprétations Use cases

29. UML 2.0 : Le futur (2002…) • Faire de UML une famille de langages en clarifiant le noyau • Supporter la modélisation de composants • Fournir plus d’outils pour le temps réel • Clarifier les notions, éviter les redondances ou les notions vagues, Clarifier la généralisation

30. UML - Bilan • Un standard universellement reconnu et appliqué • Une consolidation progressive (UML 1.4) et une révision majeure en vue (UML 2.0) • Supporté par un très grand nombre d’outils : Case Tools, mais aussi des environnements de développement et des « repositories » divers • Un effort considérable sur la sémantique, qui nécessite encore des consolidations