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.

Présentation au sujet: "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."— Transcription de la présentation:

1 1 UML partie 2 Jean-Marc Vanel Septembre 2005

2 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

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

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

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

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

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

8 20/09/2016UML8 Création & destruction

9 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

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

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

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

13 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 14 Les diagrammes d'états / transitions Le cycle de vie d'une voiture:

15 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 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

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

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

19 20/09/2016Test19 Exemple plus complexe

20 20 Les diagrammes d'activités

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

22 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 23 Partitions d'un diagramme d'activité Qui fait quoi...

24 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 25 Diagrammes d'états – jonctions(pins) et transformations

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

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

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

34 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

35 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 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 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 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 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: http://mdr.netbeans.org/ http://mdr.netbeans.org/ ● Vérificateurs de qualité (ArgoUML, ?)

40 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 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 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