1 UML partie 2 Jean-Marc Vanel Septembre 2005

20/09/2016UML2 Visite guidée du langage (suite) Les mécanismes généraux Les paquetages Les stéréotypes Les étiquettes Les notes Les contraintes Les diagrammes de base Les diagrammes d’objets Les diagrammes de classes Les diagrammes de séquence Les diagrammes de collaboration Les diagrammes de cas d'utilisation Les diagrammes d'états/transitions Les diagrammes d'activités Les diagrammes de composants Les diagrammes de déploiement

20/09/2016UML3 Exemple classique: appel téléphonique

20/09/2016UML4 Exemple: calcul prix commande: conception centralisée D'après M. Fowler

20/09/2016UML5 Exemple: calcul prix commande: style Orienté Objet

Mutuelle Assure' +taux(): double Prestation +montant(Assure'): int Exemple: calcul remboursement Mutuelle ● La classe Assuré sait calculer un taux de base à partir de ses données privées (âge, situation de famille, etc) ● La classe Prestation encapsule les infos sur un acte médical; la méthode montant(Assuré) a ainsi toutes les billes pour calculer.

20/09/2016UML7 Diagramme de Séquence ● Un cas réaliste – notion de délégation ● chaque classe a ses compétences

20/09/2016UML8 Création & destruction

20/09/2016UML9 Visite guidée du langage Les mécanismes généraux Les paquetages Les stéréotypes Les étiquettes Les notes Les contraintes Les diagrammes de base Les diagrammes d’objets Les diagrammes de classes Les diagrammes de séquence Les diagrammes de collaboration (de communication) Les diagrammes de cas d'utilisation Les diagrammes d'états/transitions Les diagrammes d'activités Les diagrammes de composants Les diagrammes de déploiement

20/09/2016UML10 Diagrammes de cas d'utilisation Les diagrammes de cas d'utilisation représentent un ensemble de cas d'utilisation et d'acteurs (sorte de classe particulière) et leurs relations. Ils permettent de délimiter les frontières du système.

20/09/2016UML11 Relations des cas d’utilisation ● Association, Extension, Utilisation, Généralisation

20/09/2016UML12 Relations des acteurs ● Association, généralisation

20/09/2016Test13 Diagrammes d'états ● Les diagrammes d'état sont des automates à états, composés d'états, de transitions, d'événements et d'activités. ● présentent la vue dynamique d’un système ● modélisation du comportement d'une interface, d'une classe ou d'une collaboration ● Etat – Condition dans laquelle se trouve un objet ● Transition – Chemin entre deux états ● Evénement – Occurrence qui survient dans le domaine

14 Les diagrammes d'états / transitions Le cycle de vie d'une voiture:

15 Diagrammes d'états Détails d'une transition: évènement [condition] / action(arguments) Exemple: coffre-fort protégé par un mécanisme dangereux

16 Diagrammes d'états Activités associées à un état : évènement [condition] / action(arguments) ● entry, exit : évènements prédéfinis ● do : activité durable interruptible Exemple: activités d'un pilier de bistro

20/09/2016Test17 Automates hiérarchiques Généralisation d’états

20/09/2016Test18 Etats concurrents (Parallélisme)

20/09/2016Test19 Exemple plus complexe

20 Les diagrammes d'activités

21 Exemple: Commande: expédition et facturation en parallèle

22 Sous-diagramme d'activité La livraison est à part... et est appelée par le processus global (traitement de commande). A noter le paramètre Commande (Order) en entrée et en sortie. A noter le rateau qui indique la présence d'un sous-diagramme d'activité.

23 Partitions d'un diagramme d'activité Qui fait quoi...

24 Diagrammes d'états - signaux Exemple: « faire valise » et « attendre taxi »; attendre un signal temporel et un signal évènement. Exemple: envoyer et recevoir un signal; il y a une autre activité qui reçoit « Send itinerary » et qui envoie « Itinerary confirmed »

25 Diagrammes d'états – jonctions(pins) et transformations

26 Diagrammes d'états - expansion region (boucle implicite) Le même en raccourci:

27 Diagrammes d'états – flow final (fin d'un flot partiel)

28 Les diagrammes de composants La file de messages est à la fois cliente et implémenteuse de l'interface « sales message », suivant l'état du réseau. Till = caisse enregistreuse

29 Les diagrammes de déploiement Idée: on peut faire tout le déploiement par Ant de Apache.org; alors le diagramme peut être généré par XSLT.Ant de Apache.org

30 Dernière partie: compléments ● Principes de style UML ● Principes de Conception UML ● UML et Programmation Orientée Objet ● Processus de développement ● Outils ● Conclusion

31 Principes de style UML ● Faire passer un message, ne pas tout décrire, ne pas systématiquement utiliser tous les gadgets ● 10 ou 15 classes maximum par diagramme ● Éviter les redondances – exemple association conséquence de deux autres associations: Personne:P2Personne:P1 Personne:P3 grand-père père

32 Principes de Conception UML ● Limiter les dépendances: par navigation à sens unique; utilisation d'interfaces ● Éviter les champs qui ont une structure (exemple adresse postale) – Cf les 4 « formes normales » des bases relationnelles, qui s'appliquent aussi à l'analyse Orientée Objet ● Ne pas utiliser systématiquement l'héritage

33 UML et Programmation Orientée Objet ● Bien distinguer modèle métier pur, et modèle orienté programmation – Les getXXX() et setXXX() n'ont pas à apparaître sur un diagramme ● D'ailleurs UML peut s'utiliser pour spécifier ou pour créer une base relationnelle ou XML ● Il y a un degré de liberté entre un modèle métier et la traduction Java (classes ou interfaces, implémentation associations) ● Les attributs UML ne se traduisent pas seulement par des champs (encapsulation des informations)

20/09/2016UML34 Principes de la conception objet ● Réutilisabilité, extensibilité ● Faible couplage externe, forte cohérence interne ● Nommage qui exprime l'intention (le pourquoi) et non pas l'implémentation (le comment) ● Comment trouver les classes? – Écrire un cas d'utilisation – Relever les noms et les verbes ● Distinguer objets métier et objets d'implémentation

20/09/2016UML35 Dissimulation des informations ● Exemple : – un compte en banque ● une seule donnée importante : le solde ● Pourquoi ne pas accéder directement au solde? ● Non, autrement retraits illimités possibles! ● On veut des contrôles et traitements (journalisation etc) chaque fois qu'on accède au compte ● La donnée peut ne pas être en mémoire: accès via réseau et/ou Base de données ● D'où le concept de dissimulation des informations: – on accède aux données à travers des méthodes: ● déposer(int somme); ● retirer(int somme);int solde();

36 Processus de développement On présente ici un Processus de développement utilisant UML, inspiré par la méthodologie eXtreme Programming. ● Spécification ● Analyse ● Conception ● Implémentation

37 Processus de développement 1 ● Spécification: phrases-clé => Diagramme Cas d'Utilisation ● Analyse: Diagrammes de Séquence, Diagrammes de Classes, (si besoin) Diagrammes d'Etats et d'Activités ● Conception: raffiner Diagrammes de Séquence et de Classes

38 Processus de développement 2 ● Préparer tests; concevoir l'accès aux données, dans le cadre d'un modèle en couches: – Présentation – Logique applicative – Modèle Métier – Accès aux données – Stockage ● Implémentation: coder, tester, corriger, livrer ● Réitérer pour les Cas d'Utilisation suivants

39 Outils ● Editeur de diagramme: ArgoUML, Umbrello et Dia (Linux seulement), TogetherJ, Omondo et Rational pour eclipse ● Générateur: de code(Java, PHP, SQL, etc), de documentation (HTML,...) ● Analyseur de code (inverse du précédent) ● « fusionneur » (permet de pratiquer le « round trip engineering ») ● Bibliothèque manipulant des modèles UML : MDR: ● Vérificateurs de qualité (ArgoUML, ?)

40 Formats ● XMI, format OMG officiel d'échange: versions 1.0, 1.1, 1.2 incompatibles! – avec UML version 1.2, 1.3, 1.4 ==> 9 combinaisons possibles ! ● Rational Rose souvent utilisé ● Avant UML 2.0, la géométrie des diagrammes n'est pas normalisée ● Souvent le plus simple pour interopérer est de passer par du code Java !

41 UML : Conclusion ● L'utilisation raisonnable d'UML est celle d'une normalisation graphique simple – S'il faut une semaine de formation pour comprendre une documentation on rate l'objectif de communication ● Attention à la tentation du «round-trip engineering » – À un instant donné, on ne sait pas quelle est la référence: l'UML ou le source? – Ne favorise pas le partage de code et les corrections rapides – Préférer une utilisation de UML comme « tableau de bord », par ex. avec DoxygenDoxygen

42 Avenir d'UML ● MDA (Model Driven Architecture) est le nouveau mot omniprésent de l'OMG – Trop flou - Une occasion de plus pour les éditeurs de vendre des machins encore plus complexes et moins interopérables – La problématique de la relation entre modèle et logiciel est complexe c'est vrai (POJO~PIM) ● L'avenir est probablement à des types de modèles plus riches et polyvalents: les ontologies (où UML pourrait être le graphisme) – En tous cas il y a là un vrai format d'échange et des modèles disponibles en open source