Vous êtes sur la page 1sur 21

tre Agile

Expression de Besoins avec UML

Modlisation, Expression de Besoins avec UML

Thierry Cros http://etreagile.thierrycros.net

Copyright Ce document est sous licence Creative Commons selon ces termes : vous pouvez reproduire, distribuer, communiquer et modifier ce document dans les conditions suivantes : citer l'origine de cet article en incluant l'information suivante : Auteur Thierry Cros, http://etreagile.thierrycros.net pas d'utilisation commerciale de ce document Distribuer, communiquer, adapter ce document en citant explicitement ce contrat initial CC/BY-NC-SA. Support UML v2 1/21

tre Agile

Expression de Besoins avec UML

Illustrations
Illustration 1: Modliser pour mieux comprendre.........................................3 Illustration 2: lments, formalismes, diagrammes......................................4 Illustration 3: Acteurs et cas d'utilisation...................................................5 Illustration 4: Navigateur : modle, paquetages, lments de modlisation et diagrammes..........................................................................................6 Illustration 5: Contexte Systme..............................................................7 Illustration 6: Nouveau contexte.............................................................11 Illustration 7: Relation <<include>>.......................................................12 Illustration 8: Contenu du Navigateur avec relation include.........................13 Illustration 9: Hritage entre acteurs.......................................................16 Illustration 10: Navigateur contenant un hritage d'acteurs........................16 Illustration 11: Relation <<extend>> entre cas........................................17 Illustration 12: Point d'extension.............................................................18 Illustration 13: Navigateur : extend.........................................................18 Illustration 14: Diagramme d'activit associ un cas d'utilisation...............19 Illustration 15: Classes du domaine.........................................................20 Illustration 16: Compte Vue.................................................................20 Illustration 17: Etats Transitions d'un Compte Vue..................................21 Illustration 18: Navigateur ....................................................................21

Index des tables


Tableau Tableau Tableau Tableau Tableau 1: 2: 3: 4: 5: Description d'un cas d'utilisation................................................8 Description textuelle de "DialogueBanque"................................10 Gestion des cas d'utilisation....................................................12 Description de DialogueBanque avec <<include>>.....................13 Tableau de bord des cas, y compris niveaux..............................14

Support UML v2

2/21

tre Agile

Expression de Besoins avec UML

1. Introduction
Ce support traite de l'expression de besoins avec UML, autrement dit avec les cas d'utilisation pour l'essentiel. Mais dans un premier temps, voyons ce qu'est un modle UML.

2. Modliser

Illustration 1: Modliser pour mieux comprendre Le systme dont nous nous occupons ici est un logiciel ou, pour reprendre une expression issue du processus unifi : un systme forte composante logicielle, ce qui est plus prcis, au vu de l'importance que prennent les matriels dans la solution complte. Un modle, dans UML, reprsente le systme selon un certain point de vue et est constitu :

d'un paquetage principal qui reprsente le systme lui-mme selon le point de vue du modle et donc contient tout le reste soit : des lments de modlisation (les objets, les classes, les tats...) des diagrammes qui reprsentent ces lments (voir ce sujet l'article Diagrammez correctement vos modles !) des paquetages (qui sont donc des sous-paquetages).

Un paquetage est l'lment d'organisation du modle, tout comme un rpertoire organise des fichiers dans un ordinateur. Un paquetage offre aussi Support UML v2 3/21

tre Agile

Expression de Besoins avec UML

un espace de noms, un lment pouvant alors tre public ou priv. Autre point important : un modle repose sur deux visions complmentaires :

aspect dynamique (communication, squence...) structurel (classes, paquetages).

C'est l'quilibre entre ces deux piliers qui forme un modle pertinent. Les modeleurs n'implmentent que rarement la notion de modle. Or, c'est pourtant l'unit du langage UML ! Une solution est d'utiliser la notion de paquetage pour simuler le modle, toujours prsente.

Illustration 2: lments, formalismes, diagrammes...

3. Acteurs et cas d'utilisation


Acteurs et cas d'utilisation sont les vedettes de l'expression de besoins avec UML. Or, la vrit est (juste un peu...) diffrente. La vritable star de l'expression de besoins est... l'interaction acteur / systme dans une situation d'utilisation appele cas . Retenez bien ceci car c'est la cl non seulement de l'expression de besoins mais aussi du pilotage du projet (par les cas d'utilisation bien entendu). Cela ne vous rappelle rien ? Bien sr : l'interaction ou la communication, la collaboration... ce sont des concepts objet ! Donc, considrez un acteur comme un objet, le systme comme un autre objet, une boite noire actuellement. Cet objet assume des responsabilits qui se retrouvent dans les situations de son utilisation par l'acteur. Cela compris, vous avez acquis les de la comprhension de ces concepts. Support UML v2 4/21

tre Agile

Expression de Besoins avec UML

Alors... acteurs, cas... voyons tout cela de plus prs.

Illustration 3: Acteurs et cas d'utilisation Rappel de la cl : Un cas d'utilisation est un ensemble d'interactions Si vous oubliez cela, vous obtiendrez quelque chose... et ce quelque chose ne sera certainement pas un modle cas d'utilisation juste.

Obtenir les acteurs et les cas


Les acteurs sont externes au systme (ce qui pose la question des frontires de ce systme d'ailleurs). Un acteur peut tre

humain : acteur principal, bnficiaire du systme ou bien acteur secondaire tel que exploitant... autre systme : une application ou un systme avec lequel notre systme dialogue est un acteur.

La toute premire question (mais le processus est itratif : nous obtenons une premire rponse, plus tard nous reposerons la question) est donc : quels sont les acteurs de ce systme ? La rponse prcise les frontires du systme, qui peuvent tre l'enjeu principal de la modlisation. La deuxime question est alors : quelles sont les situations dans lesquelles ces acteurs vont utiliser le systme ? Ces premires listes tablies (qui n'est finalement ce stade qu'une liste d'acteurs et situations candidates), nous pouvons les reprsenter dans une toute premire version du modle d'expression de besoins. Support UML v2 5/21

tre Agile

Expression de Besoins avec UML

Etude de cas Cette tude porte sur l'information d'une agence bancaire. L'objectif est de proposer aux clients un logiciel de gestion de leur compte. La particularit (la nouveaut) de ce logiciel est qu'il offre, en plus des fonctionnalits habituelles de gestion de compte via internet ou minitel, une capacit dialoguer avec la banque, via un systme type dialogue simultan, coupl aux comptes du Client. Un Client possde ncessairement un Compte vue , ventuellement un livret et un Plan Epargne Logement . Le logiciel modeleur possde plusieurs zones :

menu, etc navigateur ou browser zone d'dition des diagrammes.

Notez que le navigateur est un lment important de votre modeleur : c'est lui qui permet de naviguer facilement (ou non...) dans vos modles.

4. Crer le modle d'expression de besoins


La saisie des lments de modlisation obtenus dans une premire recherche nous permet d'obtenir le contenu de navigation suivant.

Illustration 4: Navigateur : modle, paquetages, lments de modlisation et diagrammes Ce navigateur prsente le contenu :

Systme (souvent appel projet dans le modeleur), ici GestionBancaire Le modle d'expression de besoins (ici un paquetage)

Support UML v2

6/21

tre Agile

Expression de Besoins avec UML

Le systme dans ce modle (ici une vue dans le modeleur, appele Gestion Bancaire en cas d'utilisation) un diagramme de contexte (voir ci-dessous) qui reprsente les cas d'utilisation ainsi que les acteurs, les lments de modlisation : acteurs et cas d'utilisation.

Plus tard, lorsque nous ajouterons des modles, nous pourrons ainsi jouer sur le navigateur et ouvrir ou fermer les modles, les paquetages, etc. Pour l'instant, voici le diagramme de contexte, ce point de l'tude.

Illustration 5: Contexte Systme Ce diagramme indique les situations d'utilisation du systme par deux acteurs : Banquier et Client. Ce sont des rles jous par des personnes. Un cas d'utilisation est un ensemble d'interactions. Si ces interactions peuvent se modliser par un diagramme de squence, la quantit et la complexit des choix possibles rend cette solution insense, sauf peut-tre pour quelques cas particuliers de scnarios typiques. Un scnario est une lecture particulire, spcifique des interactions. La solution est le plus souvent une description textuelle. Cela n'empche pas l'apport de concepts et formalismes UML pour consolider le modle d'expression de besoins. Comme pour tout modle, tout concept ( de rares exceptions prs) et donc tout formalisme peut tre utilis. Cela tient au fait que les concepts de base (objet message) sont rellement universels. Voici donc un exemple de description textuelle simple. Notez que la longueur de cette description est un aspect important : au plus elle sera longue, au plus elle sera difficile apprcier, voire lire tout simplement. Quelques pages (2 ou 3) semblent donc tre une bonne mesure. Bien entendu, cela dpend de la Support UML v2 7/21

tre Agile

Expression de Besoins avec UML

nature du cas d'utilisation. Nous verrons un peu plus tard des possibilits les relations entre cas qui permettent de limiter cette question pragmatique. Une description textuelle est base sur une expression en franais des interactions, ce qui peut paratre verbeux dans un premier temps. Nom du cas d'utilisation Dclenchement/Rsum
Voir tout simplement le modle Quelques infos concernant le contexte de dclenchement de cas : quand cette situation d'utilisation se produit-elle ? Quel tat du systme ? Voir aussi le modle : quels sont les acteurs qui participent ces interactions ? L'ensemble des interactions quand tout se passe normalement Les cas particuliers dans les interactions Dans quel tat se trouve le systme ? Que doit-il mmoriser par exemple ?

Acteurs Interactions normales Interactions alternatives Etat du systme en fin de cas Commentaires sur la description

Tableau 1: Description d'un cas d'utilisation Prenons le cas de la situation DialogueBanque. Notez au passage qu'un cas d'utilisation est une situation, un nominatif si vous prfrez. C'est pour cela qu'il me semble plus judicieux de nommer les cas par des noms plutt que des verbes. L'obtention des interactions s'obtient en dialoguant avec un Utilisateur expert. Comment ? Il s'agit de poser des questions qui lui permettent de voir le systme comme une boite noire et donc d'imaginer les interactions. Notez que la description se concentre sur le contenu, la signification, des interactions et pas sur leur forme. En effet, une maquette de type IHM ou plus gnralement des changes entre systme et acteurs peut tre ralise en parallle afin de traiter de cet aspect de l'expression de besoins. On parle alors de cas d'utilisation essentiel, car il dcrit l'essence des interactions. Quelques questions poser l'Utilisateur expert (ou au collge d'Utilisateurs qui participent l'expression de besoins).

Dans quels cas allez-vous utiliser GestionBancaire ? 8/21

Support UML v2

tre Agile

Expression de Besoins avec UML

Quels cas souhaitez-vous dcrire en priorit ? (ici, le Commanditaire du logiciel peut faire des choix qui ne seraient pas ncessairement celui du Dveloppeur) Quand ce cas est-il dclench ? Pourquoi ? Quel est le processus mtier dans lequel ce cas s'inscrit ? Que souhaitez-vous que GestionBancaire vous prsente comme information, comme choix... ?

Voici donc un exemple de description textuelle. DialogueBanque / version 1

Dclench par le Client lorsqu'il souhaite dialoguer avec son banquier, en s'appuyant sur les infos de son compte (dclenchement alatoire pendant les heures d'ouverture de la banque). Acteurs : Client et banquier pour dialoguer1 1. Le Client se connecte (interactions dfinir affiches en fond jaune) et dclenche ce cas en choisissant DialogueBanque ; 2. GestionBancaire envoie alors un message au Banquier atitr du Client ; 3. Le Banquier accepte la connexion [cas alternatif : le Banquier refuse] ; 4. GestionBancaire avertit alors le Client que le dialogue est tabli avec le Banquier, pour cela une boite de dialogue est cre sur les deux crans ; 5. GestionBancaire affiche le numro et le solde de tous les comptes du Client (affiche pour le Client et pour le Banquier) 6. Le Client choisit, ventuellement plusieurs fois de suite, l'un des comptes sur lequel il veut dialoguer 7. GestionBancaire affiche les 10 dernires oprations de ce compte (client et banquier) ainsi que son solde ; 8. Eventuellement plusieurs fois de suite : 9. Le client envoie son message au banquier ; 10. GestionBancaire transcrit ce message au banquier ; 11. le Banquier rpond au message; 12. le Client indique qu'il souhaite terminer le dialogue 13. GestionBancaire envoie un message de fin au Client et au Banquier.

Le Banquier refuse le dialogue GestionBancaire envoie un message au Client lui indiquant que le dialogue est impossible (pas que le banquier refuse) / fin. En fin de dialogue, celui-ci est mmoris par GestionBancaire. Les interactions de connexion ne sont pas encore dfinies, c'est un pb car c'est un aspect crucial du systme (scurit).

Tableau 2: Description textuelle de "DialogueBanque"


1 Cela provoque alors une volution du modle : ajout d'une association de communication entre Banquier et DialogueBanque.

Support UML v2

9/21

tre Agile

Expression de Besoins avec UML

Illustration 6: Nouveau contexte Prvoyez ds le dpart un tableau de gestion des situations d'utilisation. Ce tableau de bord permet de faire le point rgulirement sur les cas d'utilisation :

Les cas en cours de rdaction, ou bien valids, ou encore plus tard en cours de dveloppement... Et encore plus tard les cas en exploitation ! Ce tableau est un embryon de gestion de configuration des cas d'utilisation. En effet, comme pour tout lment produit par le cycle de vie du projet, ces cas peuvent voluer : une gestion de changement, mme minimaliste au dbut, s'impose donc. Enfin, prvoyez une zone Commentaires qui permet de stocker toute info qui peut tre utile.

Ce tableau est important dans le cas d'un pilotage par les cas d'utilisation. Nous verrons un peu plus tard qu'il est plus judicieux de parler de Pilotage par les scnarios de cas d'utilisation. Si le besoin apparat il sera alors possible d'quiper ce tableau de scnarios, afin de correspondre la ralit du projet. Un peu d'excellerie (ou de tableur OpenOffice gratuit) est largement suffisante pour implmenter ce tableau. Souvenez-vous que ce tableau est un outil de gestion de projet : sa finalit est donc d'tre lu et utilis pour piloter le projet. Il pourra tre prsent en Comit de Pilotage Projet, modifi en runion d'avancement, etc.

Support UML v2

10/21

tre Agile
Situation (cas) CreationCompte OprationsCAV DialogueBanque OprationsLivret OprationsPEL Suppression Etat
identifi

Expression de Besoins avec UML


Version 1 Priorit V.A. ++ ++ +++ + + + Commentaires Voir le processus mtier 'cration nouveau client' Traiter en particulier le virement de compte compte du client Le plus que l'on offre nos clients Vrifier le nombre de clients concerns idem On a toujours l'ancien systme pour supprimer les comptes

identifi

En rdaction identifi

Tableau 3: Gestion des cas d'utilisation Avancons un peu. Quid des interactions de connexion au systme ? Si nous observons les diffrents cas d'utilisation, nous constatons que ces interactions sont obligatoires dans tous les cas. Nous pouvons attendre de les rdiger deux fois, dans deux descriptions textuelles ce qui serait le plus sr pour justifier ce qui va suivre ! Nous pouvons aussi dcider de crer un cas d'utilisation un peu particulier, qui est simplement un ensemble d'interactions. Cela pose deux questions : 1. Comment reprsenter, modliser, la relation entre tous ces cas ? 2. Comment grer cela, car nous pressentons que nous avons affaire des cas d'utilisation de niveau diffrent ?

5. Relations entre cas d'utilisation et niveaux des cas


Relation include
La relation d'inclusion d'interactions est parfaitement adapte la modlisation que nous sommes en train de raliser.

Illustration 7: Relation <<include>> Support UML v2 11/21

tre Agile

Expression de Besoins avec UML

Cette relation qui prend un caractre obligatoire indique que les interactions de Connexion sont incluses un point d'inclusion donn dans les interactions de DialogueBanque. Si vous connaissez le C++, c'est le mme mcanisme d'inclusion qui s'applique avec la directive #include "fichier.h". Il reste simplement prciser cette inclusion dans la description textuelle. DialogueBanque / version 1.1

Dclench par le Client lorsqu'il souhaite dialoguer avec son banquier, en s'appuyant sur les infos de son compte (dclenchement alatoire pendant les heures d'ouverture de la banque). Acteurs : Client et banquier pour dialoguer (include Connexion) GestionBancaire envoie un message au Banquier atitr... ...

Tableau 4: Description de DialogueBanque avec <<include>> La syntaxe de l'inclusion est une dcision de modlisation ou description textuelle qui est tablir. Elle s'utilise l'endroit o il faudrait normalement rdiger les interactions qui sont incluses. Le surlignage de couleur n'a rien d'obligatoire ! Faisons un petit tour dans le navigateur de notre modeleur.

Illustration 8: Contenu du Navigateur avec relation include Nous voyons que ce modle possde maintenant deux diagrammes de cas. Le premier est celui de Contexte Systme, le deuxime est celui cr particulirement pour reprsenter les relations du cas DialogueBanque.

Les niveaux des cas d'utilisation


Cela pose la question des niveaux de cas d'utilisation tels que dfinis et Support UML v2 12/21

tre Agile

Expression de Besoins avec UML

manipuls jusqu' prsent. Nous pouvons dire que le cas d'utilisation DialogueBanque est bien un cas systme, autrement dit une situation d'utilisation volontaire du systme alors que le cas Connexion a un ct souscas. Alistair Cockburn propose une reprsentation sympathique des niveaux que je reprends ici en adaptant la terminologie. 1. Niveau mtier ou Mouette : ce sont des descriptions qui sont en fait des descriptions de processus mtier ; il est normal que ces descriptions apparaissent car l'Utilisateur expert invente (et donc exprime) actuellement un produit qui a des rpercussions sur ces processus, ces protocoles ou procdures mtier; parfois simplement sur les notes de services. 2. Niveau systme ou Mer : se sont les cas tels que ceux invents au dpart, ils offrent une vritable valeur ajoute en terme de mtier. 3. Niveau paquet d'interaction ou sous-cas ou Crabe : ce sont les cas tels que Connexion qu'il faut bien grer mais qui n'offrent pas toute la couverture d'un cas systme. Ajoutons alors une colonne notre tableau de bord.
Situation (cas) Niveau CreationCompte OprationsCAV
Mer

Etat
identifi

Version Priorit V.A. ++ ++

Commentaires Voir le processus mtier 'cration nouveau client' Traiter en particulier le virement de compte compte du client Le plus que l'on offre nos clients Justification : scurit. Prvoir les interactions de modification de mot de passe Vrifier le nombre de clients concerns idem On a toujours l'ancien systme pour supprimer les comptes

Mer

identifi

DialogueBanque Connexion

Mer

En rdaction identifi

1 -

+++ +++

Crabe

OprationsLivret OprationsPEL Suppression

Mer

identifi

+ + +

Mer Mer

identifi identifi

Tableau 5: Tableau de bord des cas, y compris niveaux Rdigeons alors les interactions du cas Connexion. Notez qu'il apparat un Utilisateur, qui recouvre aussi bien Client que Banquier. Le modle sera alors mettre jour. Support UML v2 13/21

tre Agile

Expression de Besoins avec UML

Connexion
Dclench par inclusion de DialogueBanque ( modifier) donc par le Client. 1. Pendant trois fois maximum [cas alternatif : trois erreurs] : 2. GestionBancaire demande le code utilisateur du systme et le mot de passe numrique 3. L'utilisateur saisit ces informations 4. Si elles sont errones, GestionBancaire envoie un message d'erreur Trois erreurs GestionBancaire envoie un message indiquant que la connexion est dsormais impossible ; l'Utilisateur est bloqu En fin de cas, l'Utilisateur est connect GestionBancaire Il faudrait aussi prvoir une procdure pour imposer le changement rgulier de mots de passe.

Une question se pose ce niveau : quid de la connexion du Banquier dans le cas DialogueBanque ? Une modification dans le tableau 2 (description textuelle du cas DialogueBanque) : le pas numro 4 des interactions mriterait alors un pas complmentaire : 4.1 include (Connexion) pour le Banquier ; Le modle volue pour tenir compte de ce pseudo acteur : Utilisateur. En fait, nous pourrions dire qu'il s'agit d'un acteur abstrait, au sens classe abstraite, donc non instanciable. Son nom apparat alors en italiques.

Illustration 9: Hritage entre acteurs Cela indique qu'il n'existe pas d'Utilisateur du systme en tant qu'Utilisateur concret et heureusement : Utilisateur est certainement un nom d'acteur bien mdiocre !

Support UML v2

14/21

tre Agile

Expression de Besoins avec UML

Notre modle s'enrichit peu peu. Nous constatons ici un phnomne tout fait normal : nous travaillons sur plusieurs artefacts (ou docs ). Ainsi, les uns consolident les autres. C'est ce que nous retrouvons aussi au niveau d'un modle : l'aspect structurel permanent consolide l'aspect dynamique et inversment. De mme, un modle en consolide un autre : typiquement le modle d'analyse consolide l'expression de besoins.

Illustration 10: Navigateur contenant un hritage d'acteurs Etude de cas, suite Le commanditaire indique, l'tude de la description textuelle du cas DialogueBanque, qu'il serait judicieux de prsenter de nouveaux produits bancaires au Client, l'occasion de cette situation du systme. Ces informations Marketing sont optionnelles et sont discrtion du banquier. Cette configuration d'interactions optionnelles est caractristique de la relation <<extend>> entre cas d'utilisation.

Support UML v2

15/21

tre Agile

Expression de Besoins avec UML

Illustration 11: Relation <<extend>> entre cas Les conditions d'extension peuvent tre prcises : Point d'extension : l'endroit dans la description du cas tendu o les interactions qui tendent peuvent prendre place (ce peut tre une plage d'interactions dans le cas tendu) Condition d'extension : ce qui fait que ces interactions se droulent. Le diagramme devient alors :

Illustration 12: Point d'extension C'est en fin de dialogue que le Banquier peut dcider ou non du droulement des interactions du cas crabe InfosMarketing. Support UML v2 16/21

tre Agile

Expression de Besoins avec UML

Le navigateur est alors le suivant :

Illustration 13: Navigateur : extend...

6. Consolider le modle d'expression de besoins


Nous venons de voir les lments de modlisation directement lis l'expression de besoins par les cas d'utilisation. Or, il est bien souvent utile d'ajouter des artefacts qui viennent amliorer la comprhension du modle. Un modle mtier est une ressource parfois utilise (voir le document consacr ce modle), nous y reviendrons dans un instant. Un diagramme d'activit ou tat-transition est un bon moyen de prciser le droulement d'un cas d'utilisation, les activits sont celles du systme et ventuellement celles des acteurs pendant la situation d'utilisation. Prenons un cas simple pour exhiber un premier diagramme d'activit dans ce support. Le commanditaire du projet explique que chaque compte vue se voit attribuer une facilit de caisse, soit un seuil de solde ngatif ne pas dpasser. Si le solde rsultant du dbit est infrieur ce seuil, le dbit est impossible. Si le compte est en facilit de caisse pendant plus de 30 jours il est bloqu. Le dbit est un ensemble de scnarios possibles du Cas d'Utilisation OperationsCAV.

Support UML v2

17/21

tre Agile

Expression de Besoins avec UML

Ce droulement d'interactions est modlis par un diagramme d'activits. Un diagramme Etat-Transition pourrait aussi tre associ un cas d'utilisation, pour indiquer les tats et leurs changements dans le droulement des interactions du cas.

Illustration 14: Diagramme d'activit associ un cas d'utilisation Ci diagramme prsente les formalismes suivants :

pseudo tat initial de dmarrage de l'activit activits : calcul nouveauSolde, etc une dcision (ce losange est aussi une fusion de transitions) qui se traduit par deux transitions qui visualisent l'algorithme du dbit.

Note : la pertinence et la valeur ajoute de ce type de diagramme reste valider : parfois un texte vaut mieux que 1000 dessins ! Revenons au modle mtier. Si un modle mtier complet n'est pas toujours ncessaire, il peut tre toutefois utile de prciser, dans le modle d'expression de besoins, quelques objets du domaine, voire quelques processus mtier, en termes de consolidation de l'expression de besoins.

Support UML v2

18/21

tre Agile

Expression de Besoins avec UML

Illustration 15: Classes du domaine Finalement, un diagramme Etat/Transition peut tre associ une classe afin de prciser la nature des objets de cette classe.

Illustration 16: Compte Vue

Support UML v2

19/21

tre Agile

Expression de Besoins avec UML

Illustration 17: Etats Transitions d'un Compte Vue Le modle d'expression s'enrichit donc rapidement.

Illustration 18: Navigateur Le modle ici est constitu de deux paquetages (illustration 18), ce qui est formellement un dviance par rapport UML. Nous touchons ici du doigt la diffrence entre le langage UML norm d'une part et le langage UML pratiqu d'autre part. Cette diffrence est due en particulier aux interprtations que font les concepteurs de modeleurs en fonction de leur comprhension de l'UML... et aussi en fonction des impratifs marketing de leur socit2 !

2 Pour tre honnte, j'interprte moi aussi UML finalement ! Pour une vision de l'UML vritablement standard consultez le site OMG : Introduction to the OMG's UML

Support UML v2

20/21

tre Agile

Expression de Besoins avec UML

Dans cet exemple, nous n'avons pas trait la question de la rorganisation du modle. Nous en reparlerons propos du modle de conception zro (ou analyse). Les copies-cran du navigateur au fur et mesure de l'avancement du modle ont pour but de montrer l'importance stratgique (en terme de modlisation) de cet aspect du modeleur. Je vous invite donc bien tudier cette progression dans la navigation et prendre le temps de bien matriser l'organisation de la navigation de vos modles.

Support UML v2

21/21

Vous aimerez peut-être aussi