UML (Unified Modeling Language) PDF

UML UML (Unified Modeling Langage) est un langage graphique de modélisation objet qui permet à divers intervenants d'échanger de l'information. Le langage a été normalisé par l'OMG (actuellement version 2 depuis 2004, version 2.5.1 en 2017).Il ne s'agit pas d'une méthode, mais d'un outil de communic...

UML UML (Unified Modeling Langage) est un langage graphique de modélisation objet qui permet à divers intervenants d'échanger de l'information. Le langage a été normalisé par l'OMG (actuellement version 2 depuis 2004, version 2.5.1 en 2017).Il ne s'agit pas d'une méthode, mais d'un outil de communication. (https://www.omg.org/) UML offre 14 diagrammes différents, couvrant divers domaines touchant aux systèmes d'informations. 20.09.23 Sylvain Cherrier  Les différents niveaux UML est conçu comme un langage d'échange. Bien que son formalisme soit très précis, certains auteurs encouragent son utilisation à différents niveaux de profondeur. En première approche, simple esquisse, griffonnée sur un papier, à des niveaux plus précis, plus exhaustifs. Différentes granularités, différents usages... Les méthodes agiles de type RUP, XP usent de ce coté ”jetable”. 20.09.23 Sylvain Cherrier  Les différents diagrammes Les diagrammes statiques (ou de structure) : ils montrent l'organisation des données. Les deux principaux : Diagramme de classes : permet de visualiser les classes et leurs interactions, les hiérarchies d'arborescences de classes, Diagramme d'objets : pour illustrer, avec des instances. À utiliser pour renforcer le propos, dans le cas où la compréhension s'avère ardue. 20.09.23 Sylvain Cherrier  Exemple Diagramme Classes/Objets Un diagramme de classe, une classe abstraite et sa concrétisation, avec un petit commentaire... Diagramme d'objets, une voiture, ses 4 roues, et son moteur... 20.09.23 Sylvain Cherrier  Diag de classe d'UML  Diagramme Structurel De Comportement Classes Objets Activité Cas Utiliisation Etats Transitions Interactions Déploiement Paquetage Sequence système Communication [[File:Uml diagram-fr.png|thumb|La hiérarchie des diagrammes UML 2.0 sous forme d'un diagramme de classes.]] -(source Wikipédia) 20.09.23 Sylvain Cherrier  Diagramme de classe 20.09.23 Sylvain Cherrier Source : http://www.esiee.fr/~bureaud/Unites/Old/In413/Java_Beans  Diagramme de classe Source : miage.univ-nantes.fr 20.09.23 Sylvain Cherrier  Diagramme de classe 20.09.23 Sylvain Cherrier Les différents diagrammes 2 Diagrammes comportementaux : services attendus par les utilisateurs (humain/système). * Diagramme des cas d'utilisation (use-cases) : décrit toutes les fonctionnalités que doit fournir le système. * Diagramme états-transitions : décrit les différents stades rencontré par un objet (de sa naissance à sa mort) * Diagramme activités : même chose, mais pour une activité (plusieurs classes, acteurs...) 20.09.23 Sylvain Cherrier Les différents diagrammes 3 Diagrammes d'interactions ou Diagrammes dynamiques : * Diagramme de séquence : représentation séquentielle du déroulement des traitements et des interactions entre les éléments du système et/ou de ses acteurs. 20.09.23 Sylvain Cherrier Use-cases (cas d'utilisation) Deux formes : Une forme graphique (trés typique), et une forme textuelle (Craig Larman insiste sur cette deuxième forme). La finalité du use-case est de détecter et de décrire les besoins fonctionnels -> Comment un système est utilisé par un utilisateur pour atteindre ses objectifs. Il y a toujours un (ou plusieurs) acteur(s), et le use- case montre les scénarii entre ce(s) acteur(s) et le système décrit. Certains scénarii sont des succés, et d'autres des échecs... Les use-cases peuvent être abrégés, ou plus détaillés (granularité)... 20.09.23 Sylvain Cherrier  Use case : les acteurs Un acteur est une entité quelconque ayant un comportement, ce qui inclut le système lui- même quand il fait appel aux services d'autres systèmes. (C. Larman) un acteur permet de décrire les buts de l'utilisateur, ses attentes, son action. Il y a en général un acteur principal (pour un use-case), et parfois un (ou des) acteurs auxiliaires (humains ou système). Le rôle de chacun est différent selon le use-case. 20.09.23 Sylvain Cherrier  Use-case graphique Le ou les acteurs principaux sont habituellement à gauche, les acteurs auxiliaires à droite. Le cas d'utilisation est indiqué dans un ovale. 20.09.23 Sylvain Cherrier  Use-case graphique Ce use-case représente l'enregistrement d'une vente par le système d'information. Ici, le vendeur, utilisateur du système, doit pouvoir traiter sa vente, et peut éventuellement mettre en place une solution de crédit. Selon le schéma, ce crédit est soumis à l'acceptation d'un autre acteur (auxiliaire, celui-là, dans ce cas précis). Ce crédit est optionnel, on dit que ”Mettre en place le crédit” est une EXTENSION du cas ”Réaliser la vente”. Certains clients vont payer à crédit, mais d'autres non. On remarquera qu'on ne sait pas si l'acteur auxiliaire est un humain ou un système... 20.09.23 Sylvain Cherrier  Use case : fiche de scénario Le use-case peut (et doit, selon certains auteurs) être accompagné du scénario sous forme de texte.. Le use-case détaillé est automatiquement sous forme textuelle : toutes les étapes, et les possibilités de réaction du système... Ici, on ne s'intéresse pas au 'Comment' le système résoud le problème, mais on décrit le 'Quoi'.. Qu'est- ce qui se passe ? Qui fait Quoi ? Il ne s'agit pas d'algorithme, mais simplement de la liste détaillée des interactions entre le système et les autres acteurs (le principal, et les acteurs auxiliaires, qui sont souvent d'autres systèmes). 20.09.23 Sylvain Cherrier  fiche de scénario Use-Case Périmètre : Système Commercial Niveau : but utilisateur Acteur Principal : le Vendeur Parties prenantes et intérets : le Vendeur veut enregistrer sa vente, qu'elle soit validée par le système, enregistrée pour sa prime, et que le tout soit simple d'utilisation. L'entreprise veut que les Ventes soient enregistrées, que le système de crédit soit fiable, ne déclenche pas d'impayés, et que le tout soit rapide. Le Service autorisation Crédit souhaite valider le Client auprès de la Banque de France. Pré-conditions : le Vendeur est identifié et authentifié. Post-Conditions : la Vente est enregistrée, le Crédit, si il a été demandé, a été accordé. Scénario principal (succés) 1 : le Vendeur commence sa vente 2 :le Vendeur saisit la quantité, puis le code de l'article. 3 : le système recherche l'article et affiche sa description, son prix et le total 4 : le Vendeur vérifie la cohérence le Vendeur répete 2, 3 et 4 jusqu'à ce que tous les articles soient saisis. 5 : le Système affiche le total, taxes comprises. 6 : Le système génère le ticket Extensions 5a : Demande de Crédit 1 : le Vendeur saisit le numero du compte banquaire du client 2 : le système interroge le système Service autorisation Crédit 20.09.23 etc... Sylvain Cherrier  forme textuelle - détails Périmètre : indique sur quel système on travaille. Niveau : en général, utilisateur (pour un acteur principal). sinon, cela peut être niveau sous-fonction (pour expliciter le détail de comportement d'un comportement particulier qui pourrait être capitalisé, par exemple la procédure pour le crédit, qui pourrait apparaitre dans d'autres use-cases) Acteur principal : en général, un seul Partie prenante : tous les acteurs (humain ou système) Pré et Post Conditions : Les points importants (inutile de dire que le système est en route)... Scénario : détail des interactions entre le système, acteurs, changement d'états du système. Extension : trés important, les branches alternatives 20.09.23 Sylvain Cherrier  Conseils pour le Use-Case Concentrez vous sur l'essentiel : Laissez de coté l'interface utilisateur, il faut plutot penser à ce que veut obtenir l'utilisateur. N'oubliez pas qu'il a un but. Trop souvent, un use-case est une suite d'action sans ”tête”. Un utilisateur ne met pas sa carte bleue dans un DAB pour le plaisir de taper son code. Son but, c'est de retirer de l'argent. Le reste, ce sont les actions qu'il exécute pour y parvenir. L'important, c'est l'intention ! Pas de COMMENT : ne jamais indiquer comment le système s'y prend : par exemple JAMAIS : 6 : le système fait un INSERT dans la BdD !! NON !! 20.09.23 Sylvain Cherrier  Conseils suite Identifiez bien les acteurs. Souvent, il y a des acteurs qui sont eux même d'autres systèmes (par exemple, quand on retire de l'argent à un DAB, ce n'est pas lui qui vérifie le compte : Il interroge un autre système, la banque). Identifiez bien leurs buts (ne posez pas la question : ”que faites vous ?”, mais plutôt ”que voulez vous ?”) Utilisez des verbes à l'infinitif pour vos use-case. Parfois, on peut regrouper : par exemple, ”ajouter un produit”, ”modifier un produit”, etc peut être remplacé par ”Gérer les produits” (CRUD) 20.09.23 Sylvain Cherrier  conseils Use-Case Vous pouvez évaluer vos use-cases à l'aide de tests validants. Selon Craig Larman, voici des tests à appliquer : le Test du patron : votre use-case doit pouvoir répondre à la question du patron suivante : A quoi avez vous passé la journée ? Le test PME : un peu comme le test du patron,à l'inverse : ”Ecrire un programme” n'est pas un use-case (trop gros, trop de temps, ou/et trop d'acteurs). Ce use-case n'est pas un PME (Processus Métier Elementaire). 20.09.23 Sylvain Cherrier Les éléments du schéma use- case Le schéma use-case est un outil de dialogue. Il est inutile d'en faire un outil de description pérenne de l'application. Cela, c'est le code qui le fera (selon la théorie Xtreme Programming). Le cas d'utilisation sert à l'échange entre individus qui travaillent sur le système d'information. 20.09.23 Sylvain Cherrier  Les éléments Les acteurs : le stick-man, à gauche (acteur principal) ou à droite (acteur auxiliaire) le use-case : un ovale, avec un verbe. l'association (entre acteur et use-case) : une ligne. Extension : Un cas particulier, un comportement qui apparait de temps en temps Inclusion : un bout de comportement, qu'on capitalise en le mettant à part (un fragment). spécialisation : variation du cas. Contrairement à extends, il peut couvrir tout le cas (et non un point particulier) On peut ajouter un commentaire sur une association grâce 20.09.23 à des pointillés. Sylvain Cherrier  Un exemple d'inclusion Par exemple, une opération de retrait et une opération de transfert nécessitent toutes deux une opération de vérification de l'identité du client. 20.09.23 Sylvain Cherrier  Un exemple d'extension Par exemple, lors de la conception d’un site marchand pour un fabricant de produit de beauté, on souhaite proposer à certains visiteurs de promouvoir la marque dans leur région. 20.09.23 Sylvain Cherrier  Une généralisation Dans l'UC "Retirer de l'argent", s'il s’agit de retirer de l’argent sur un compte sur livret, le comportement de l'UC peut être tout à fait différent. 20.09.23 Sylvain Cherrier  Exemple Use-Case 20.09.23 Sylvain Cherrier  Use Case Source : http://slideDECK.io 20.09.23 Sylvain Cherrier  Exercices Use-Case Le Distributeur Automatique de Billets: Qui s'en sert ? Pourquoi faire ? Que se passe t'il si le Client du DAB est un client de la Banque à laquelle appartient le DAB ? Que peut il faire de plus ? Quelqu'un d'autre a-t'il accès au DAB ? Qui valide le retrait d'un client d'une autre banque ? 20.09.23 Sylvain Cherrier  Diagramme de séquence système Permet de mettre en valeur les échanges entre les intervenants Il illustre le cas d'utilisation Le système est toujours une ”boite noire”, on ne sait pas ”comment” il fait, on ne définit que les messages envoyés, et leurs réponses. Il rend compte de la séquence des événements que le système reçoit et produit. C'est une sorte d'organigramme, entre les différents acteurs et le système, qui peut comporter des boucles par exemple. 20.09.23 Sylvain Cherrier  le DSS le schéma DSS affiche les différents acteurs et le système sous forme de ligne de vie (un trait vertical). Les échanges entre les différents intervenants sont symbolisés sous forme de messages, représentés par une flèche, indiquant le sens du message. Chaque message doit être nommé (avec un verbe à l'infinitif), et ses arguments fournis (du moins, une idée de ceux- ci). Les réponses du système sont elles en pointillés. 20.09.23 Sylvain Cherrier  Un exemple de DSS 20.09.23 Sylvain Cherrier  Autre exemple avec un vendeur 20.09.23 Sylvain Cherrier  Le DSS en détail... Sur le diagramme précedent, on remarquera : Les messages synchrones (avec le rectangle coté destinaire) et asynchrones (de simples messages) On peut décrire un message synchrone en indiquant directement une variable de stockage de la réponse (tva=calculTaxes(Vente)). D'autre part, les actions combinés (ici avec l'opérateur loop.. Mais il existe aussi alt, else,...) 20.09.23 Sylvain Cherrier  DSS avec alt et else 20.09.23 Sylvain Cherrier  D'autres DSS 20.09.23 Sylvain Cherrier  D'autres DSS 20.09.23 Sylvain Cherrier Source developpez.com  Ex (??) wikipédia  Restaurant-UML-SEQ.gif by LeonardoG Exemple étrange, même si ”Patron” veut dire Client… Serve wine et serve food ? 20.09.23 Sylvain Cherrier  Doc officielle 20.09.23 Sylvain Cherrier  Doc officielle 20.09.23 Sylvain Cherrier  Doc officielle 20.09.23 Sylvain Cherrier  Wikipédia (us)  Exemple plus clair 20.09.23 Sylvain Cherrier  UML Le diagramme de Classe va permettre de représenter une vue statique du système d'information. Pas de dynamisme ici puisqu'on n'évoque pas les stimuli qui font réagir le SI, il s'agit plutôt des relations entre les Classes, des services rendus et utilisés par chacune d'elles et de l'articulation de l'ensemble. Ce diagramme sera souvent utilisé pour vous présenter des design pattern, car il montre bien la structure (figée, statique) de la solution logicielle. 20.09.23 Sylvain Cherrier  Une Classe Elle est représentée de la façon suivante (attention, en fonction du contexte, on peut omettre ce que l'on veut). Cette représentation peut NomClasse (en italique si abstraite) varier selon le moment où elle est utilisée. Si l'analyste en (visibilité + = -) nomAttribut : typeAttribut est à la conception, elle - nb_de_chevaux : int restera plus générique. - client : Person Lorsqu'il en arrivera à l'implémentation, le diagramme peut être bien (visibilité + = -) nomMethode(args) : typeRetour plus complet, et différent (des + getNbCv() : int classes supplémentaires +setNbCv(int) : void apparaissent, des méthodes + getClient() : Person aussi...) 20.09.23 Sylvain Cherrier  Détails sur les Classes En UML, il est toujours possible de sortir du schéma grâce à des commentaires qui peuvent prendre la forme suivante. Ce qui nous donne le schéma suivant. 20.09.23 Sylvain Cherrier  Diag de classes Un exemple généré avec Umbrello 20.09.23 Sylvain Cherrier  Héritage Cette notion 'principe de généralisation/spécialisation' permet de définir les relations sous-Classe/Super-Classe. Notez la formalisation (flèche). 20.09.23 Sylvain Cherrier  Héritage suite L'héritage peut être contraint par divers moyens, être porteur d'informations. Il peut être multiple. Il peut aussi définir des limites dans l'arbre... 20.09.23 Sylvain Cherrier  Les associations. Les associations sont des relations entre Classes. Elles représentent un lien durable ou ponctuel entre deux objets, une appartenance, ou une collaboration. Elles sont représentées par une ligne entre les classes. Sur cette ligne, un verbe à l'infinitif permet d'expliquer la sémantique de l'association (non obligatoire). 20.09.23 Sylvain Cherrier  Les associations. On peut aussi donner un nom de chaque coté de l'association, afin de nommer le rôle de chacun. En théorie, l'association se lit de gauche à droite. Si le verbe se lit dans l'autre sens, il faut l'indiquer. Des cardinalités expriment le nombre d'instances en jeu dans la relation 20.09.23 Sylvain Cherrier Les associations (exemples) Employe FicheSecurite nasE*: int 1 Possede > 1 noF* int nomE: varchar nivS: int villeE: varchar finS: Date Par exemple, on peut lire tout en haut qu'UN EMPLOYE POSSEDE UNE FICHE SECURITE 20.09.23 Sylvain Cherrier Les associations (exemples) Inscription noI: int section: int trimestre: int * * 1 1 Etudiant CoursTrim nasE: int nasE: int nomE:varchar section: int villeE:varchar trimestre:int 20.09.23 Sylvain Cherrier  Association n-aire Il est possible que plusieurs Classes participent à l'association. Ce n'est alors plus une association binaire, mais n-aire. On l'indique par un losange. Méfiez-vous de la complexité induite (l'association implique l'ensemble des classes participantes). 20.09.23 Sylvain Cherrier  Association n-aire Qu'exprime ce diagramme de classe concernant des ventes de revues ? 20.09.23 Sylvain Cherrier  Multiplicité et Navigabilité... La multiplicité indique les cardinalités entre les classe et l'association. On l'exprime souvent par une valeur finie (3, 5 ou 17) ou un intervalle (2..3, 1..17, ou encore 2..*). Dans le cas de 0..*, on note parfois * tout simplement. 20.09.23 Sylvain Cherrier  Multiplicité et Navigabilité... Par défaut, l'association peut être utilisée dans les deux sens. Très souvent, on s'aperçoit que l'association est uni-directionnelle. Elle est donc navigable dans un seul sens. On l'indique avec une flèche sur l'association (la flèche à coté du verbe indique le sens de la phrase...) 20.09.23 Sylvain Cherrier  Exemple navigabilité –Chaque instance de voiture a un lien vers le propriétaire –Chaque instance de Personne a un ensemble de lien vers les voitures –Le service de contravention est associé à une ou plusieurs voiture(s) –La voiture ne connaît pas service de contravention 20.09.23 Sylvain Cherrier  Des contraintes sur l'association Il est possible d'exprimer des contraintes sur une association, afin de limiter les objets mis en jeu. Cela permet de mieux cadrer l'architecture de l'ensemble (bornes, ordonnancement, inclusion d'une association dans une autre). 20.09.23 Sylvain Cherrier  Des contraintes... 20.09.23 Sylvain Cherrier Agrégation et composition... Ce sont deux types d'associations aux caractéristiques spécifiques. Les deux indiquent une dépendance très forte de l'élément par rapport à son contenant. La relation n'est pas symétrique. Il y a appartenance forte. 20.09.23 Sylvain Cherrier  Agrégation et composition... La différence entre ces deux relations d'appartenance réside dans le niveau de dépendance du 'contenu' Si le 'contenu' est lié exclusivement au 'contenant', et qu'il disparait avec lui, alors on dit qu'il y a COMPOSITION (élément constitutif=losange plein). Sinon, il s'agit d'une AGREGATION (plutôt une coopération=losange creux). 20.09.23 Sylvain Cherrier  Exemple Agrégats- composition La suppression de la présentation entraine la disparition des transparents qui la composent 20.09.23 Sylvain Cherrier  Exemple Agrégats- composition 20.09.23 Sylvain Cherrier  Mélange agrégats Compositions Pourquoi y'a t-il parfois composition et parfois agrégation ? 20.09.23 Sylvain Cherrier  La qualification Parfois, un élément (un attribut) permet la sélection d'un sous-ensemble d'objets (de 1 à n) participant à l'association. Souvent, cela permet de réduire la cardinalité de l'extrémité de l'association à 1... Il pourra s'agir d'une clé dans une HashTable, de l'indice d'un tableau, d'un identifiant en général. 20.09.23 Sylvain Cherrier  Les classes d'association. Si vous détectez que votre association est porteuse d'informations, il est possible d'utiliser une classe d'association. Elle comportera attributs, méthodes, etc... 20.09.23 Sylvain Cherrier  Les interfaces Il s'agit la encore de factoriser un ensemble d'attributs et d'opérations, décrivant de la sorte un service cohérent. Il s'agit en général d'un comportement générique qui est décrit, et qui n'est pas décrit par une arborescence de Classe. C'EST UN DESIGN PATTERN !! 20.09.23 Sylvain Cherrier  Les interfaces Ainsi, la faculté d'être Sauvegardable, Comparable, Jouable peut être décrite via une interface, et ainsi implémentée dans de nombreuses Classes diverses. Certaines méthodes vont réclamer un objet qui implémente cette interface, peu importe le type d'Objet Comparable pour TreeSet, en Java par ex. Sortable Draggable droppable (jquery)). 20.09.23 Sylvain Cherrier  Les interfaces suite. Une interface est un contrat. Lorsqu'un objet client d'une interface collabore avec celle-ci, il ne connait pas son type réel mais il sait comment le "manipuler" (quels messages lui envoyer). Le but des interfaces est de diminuer le couplage entre deux classes. L'interface permet de ne présenter au client "que ce qui l'intéresse". 20.09.23 Sylvain Cherrier  Les interfaces suite. 20.09.23 Sylvain Cherrier  les interfaces Une façon usuelle de présenter les interfaces insiste sur le fait que l'interface définit des spécifications. Elle impose la présence de certaines méthodes, quelque soit l'objet et sa position dans une arborescence de Classes. L'objet, lui, est chargé de l'implémentation de la spécification. 20.09.23 Sylvain Cherrier  les interfaces On pourra utiliser n'importe quel objet dont on veut être sûr qu'il implémentera une interface. (en C++ => classe entièrement virtuelle)... int c; Comparable objet1,objet2; Ici, objet1 et objet2 peuvent être des instances très très différentes… mais elles implémentent Comparable 20.09.23 Sylvain Cherrier  Autre exemple. Ici, Triable permet d'indiquer qu'à la fois les Titres et les Compositeurs sont Triables. Cependant, l'héritage aurait été ici une hérésie. 20.09.23 Sylvain Cherrier  Les Packages Ce mécanisme permet de regrouper des éléments (Interface graphique, logique métier, services...) Les éléments à l'intérieur du package auront des accès privilégiés. Le package étant un espace de nommage, tout nom de classe est unique en son sein. 20.09.23 Sylvain Cherrier  Les Packages L'idée du package est de rapprocher les éléments sémantiquement proches, offrant un ensemble de services homogénes et cohérents. Ils séparent le modèle en éléments logiques, et montrent leurs interactions à un plus haut niveau. Par contre, il faut minimiser les liens (dépendances) entre packages. 20.09.23 Sylvain Cherrier  Exemple de package Ici, un package cohérent de gestion de cours, avec des inscriptions dans des séminaires de cours, qui ont lieu dans des endroits. 20.09.23 Sylvain Cherrier