UtilisationSupportUml

retour page d'accueil du wiki

Dans cette page, simplement quelques éléments complémentaires au support. La liste d'informations propose également des compléments au support (voir la page d'accueil du site Web). Support UML voir la page : http://www.thierrycros.net/produitSupportUML.html

TCR 26.02.05 Les diagrammes de séquence de l'UML présentent l'aspect temporel des interactions entre objets (en fait entre n'importe quoi dans UML v2...). Il existe plusieurs formalismes pour représenter plusieurs types de messages (synchrones, asynchrones...). En particulier, l'acquittement d'un message, ou le retour d'un d'un message synchrone, peut être représenté par une flèche en pointillés. Les diapos du support : http://www.thierrycros.net/formation/supportUML/img60.html http://www.thierrycros.net/formation/supportUML/img81.html s'en tiennent à une utilisation la + simple de ces diags. Personnellement ils me permettent en particulier de régler la création des objets dans les phases d'init, dans les cas où un séquencement précis est nécessaire pour faciliter la conception. Le plus souvent, je préfère - et de loin - les diags de collaboration qui me semblent "plus objet" et qui sont pour moi une traduction UML d'une table de CRC cards.

Ce qui est important dans UML

• Concepts, en particulier objet et message
• Ce qu'est un modèle, son contenu
• Jouer alors avec les piliers dynamique et structurel
• Rester réaliste et efficace

21.11.2004 Nouvelle présentation, plus légère

Plus rapide à charger, les pages font grosso modo 15 Ko contre 60 au préalable. Le fichier PDF est de 2,6 Mo contre 3,5.

Element de modélisation et diagramme

TCr 181104 Il faut bien distinguer les deux. Les éléments de modélisation sont le résultat de l'application des concepts UML au système. Un élément de modélisation est donc un cas d'utilisation, un acteur, une association, un état, une transition etc. Ces éléments sont organisés en (sous)paquetages dans le modèle qui est lui-même un paquetage qui représente le système selon le point de vue considéré (expression de besoins, conception...). D'un autre coté, le diagramme permet de visualiser les éléments de modélisation et leurs relations. Il n'y a strictement aucune bijection entre les deux. Autrement dit, un élément de modélisation peut exister sans diagramme ou bien être visualisé dans 3 diagrammes différents par exemple. Peut-être les outils jouent-ils de trop avec cette ambiguïté en permettant par exemple la création d'élément de modélisation depuis le diagramme (pas depuis le browser de modèle). Cette fonctionnalité a le mérite d'être "pratique". A l'inverse, supprimer un élément de modélisation parce qu'on supprime sa visualisation dans un diagramme me semble purement et simplement anti-uml !

Pratiquez !

Le support propose une étude de cas. C'est réellement le meilleur moyen de se "frotter" à UML. N'hésitez pas à créer vos diagrammes, montrez-les, suscitez un feedback de la part de vos lecteurs, contactez-moi pour relecture. TCr 121104

Trucs et astuces

• La diapo identifiée "slide 3" contient la cartographie du support. Elle est accessible depuis n'importe qu'elle diapo car l'image en bas à gauche (la pile de livres) est un lien vers cette diapo.
• FCI/FCE est un principe fondamental de conception : Forte Cohérence Interne et Faible Couplage Externe. Exprimé ainsi de façon élliptique, il pourrait par exemple être affiché au fronton de chaque plateau-projet :-). Ce principe s'applique à tous les niveaux : méthode, classe, paquetage, application.
• Vous utilisez un modeleur UML ? Profitez-en pour vous intéresser à sa fenêtre "browser" ou navigateur. Vous permet-elle de créer un "modèle" ? Que contient ce modèle ? Veillez à la facilité de compréhension de votre système grâce à l'utilisation judicieuse de ce browser. Cela correspond en fait simplement à une organisation en paquetage rigoureuse : stockez disons... de 10 à 20 éléments par paquetage, sauf exception. Testez l'impact de votre empaquetage sur la lisibilité du modèle dans le browser.
• Différence entre modèle et diagrammes. Le modèle - mais il me semble que c'est dit dans le support ;-) - est la représentation du système (l'application) selon un certain point de vue. Il contient (passons les détails formels) des éléments de modélisation, des paquetages, des diagrammes. Tout cela n'est peut-être pas très cohérent (certains modeleurs séparent les diagrammes dans une fenêtre différente du browser de modèle), il faut bien distinguer les éléments de modélisation des diagrammes. Au pire (!) le modeleur doit vous permettre de créer tout votre modèle sans aucun diagramme. De même, un élément de modélisation doit pouvoir être visualisé dans différents diagrammes (par exemple avec des niveaux de détails différents). Le problème à ce niveau est que certains modeleurs prennent pas mal de liberté et suppriment par exemple automatiquement un élément de modélisation dans le modèle alors qu'il est supprimé simplement dans un diagramme. C'est incorrect d'un point de vue UML (et ce n'est pas très correct pour la personne qui utilise cette apli...).

Le principe de base du pilotage des développements par les cas d'utilisation

Cette diapoe est certainement l'une des plus importantes du support.

• Un cas est décliné en N scénarios (pas nécessairement lors de la même itération, voire de la même version).
• Chaque scénario est traduit en collaboration entre objets. Ce qui ne signifie pas qu'il faut utiliser à ce stade un modeleur UML, plutôt un tableau ou un paper-board.
• Chaque collaboration vient alors enrichir la partie "structurelle" "permanente" du modèle (ici il s'agit du modèle d'analyse ou plus tard de conception).

Utiliser un paper-board

C'est réellement l'outil le plus adapté à UML, après (peut-être) le crayon-gomme. Munissez-vous de papier collant, feuilles A4 pour éventuellement coller une nouvelle feuille sur une partie du papier qui doit être reprise. Dans cet ordre d'idée, un appareil photo numérique est un excellent moyen de mémoriser les diagrammes de collaboration, en particulier pour l'équipe de développement qui peut se créer ainsi un véritable document de conception à base de copier/coller de photos.

Prévoyez aussi des pages qui modélisent la partie structurelle permanente car les diags de collaboration l'enrichissent continuellement.

Wall-communication

Cette technique de communication simple et efficace consiste à utiliser abondamment les murs pour afficher l'état de la modélisation. Dans cet ordre d'idée, les photocopieuses sont munies de fonctions de zoom. Profitez-en !