2

La calculette
www.thierrycros.net

2 __________________________________________________________________ tude de cas

1
Le projet calculette
La premire tude de cas met en uvre les concepts objets, UML et une dmarche trs simplifie mais conforme au Unified Process. Brivement, lobjectif de cette premire tude de cas est de : Parcourir des itrations afin de dcouvrir les relations entre cas dutilisation, classes danalyse, classe de conception Pratiquer le prototypage de larchitecture afin de la valider le plus tt possible Tester la traduction des lments logiques de conception en lments physiques de programmation Mettre en uvre des principes de base : composants et interfaces qui offrent un couplage plus faible entre implmentation et utilisation. La mise en uvre utilise le langage C++. Toutefois, une programmation dans un autre langage objet comme Java ne pose pas de problme particulier. L'environnement technique prsent pour le graphisme est de type Unix. Grce l'essor des logiciels libres, une plateforme logicielle sophistique de ce type (systme multi-utilisateur, multi-tche, interface graphique, nombreux outillages de dveloppement) est aujourd'hui gratuite. Cette tude est un cas dcole. Les dveloppements raliss ont pour but de traiter en dtail les activits, en rapport avec le langage UML. De faon gnrale, le contenu correspond aux proccupations des dveloppeurs tel ou tel stade de lavancement dun projet. La calculette est un prtexte la mise en pratique, volontairement simple, sur un cas tout de mme rel.

1.1 L'tude de cas

1.1.1 Les fonctionnalits de la calculette
Le systme construire est une calculette-convertisseur Franc/Euro. L'tude est constitue dune version graphique base sur le standard des systmes ouverts : Motif de lOpen Software Foundation (OSF). Les fonctionnalits dtailles seront prcises dans ltude elle-mme, grce aux cas d'utilisation.

www.thierrycros.net

___________________________________________________________ 3 Le projet calculette

1.1.2 Points techniques tudis

Cette premire tude de cas a pour objectif essentiel de traiter un exemple d'approche objet - modlise grce UML depuis une expression de besoins jusqu la programmation du logiciel, dans le cadre dun cycle simplifi de type Unified Process. Expression de besoins avec les cas d'utilisation La calculette est un exemple simple qui permet de comprendre la technique d'expression de besoins par les cas d'utilisation. Les besoins fonctionnels et non-fonctionnels de la calculette seront traits sous forme de cas dutilisation, ce qui est une simplification : gnralement, les besoins non fonctionnels sont exprims dans un dossier spcifique. Les besoins non fonctionnels sont survols dans cette tude. Relations cas d'utilisation objets Les cas dutilisation correspondent une approche par fonction du systme, bien quil existe une diffrence fondamentale avec des techniques strictement fonctionnelles. La relation de collaboration est la cl de la dcouverte des objets du construire.
N O T E La diffrence essentielle entre approche classique fonctionnelle, telle que mise en uvre dans la mthode SADT par exemple et lapproche par les cas dutilisation rside dans la prsence des acteurs. Dun point de vue strictement tymologique, en effet, les cas dutilisation sont des fonctions du systme, mais ces fonctions sont relies des acteurs. Une consquence bnfique de la technique cas dutilisation est le souci de lutilisateur que le dveloppeur acquiert ds le lancement du projet. De ce fait, linterface utilisateur, les tests de saisie, les aides en ligne par exemple pourront tre plus proches des utilisateurs. La connaissance des acteurs est une condition sine qua non de lergonomie des systmes. Afin que chaque utilisateur affirme : ce logiciel me va comme un gant ! (ce qui est la dfinition mme de lergonomie) encore faut-il que le dveloppeur apprenne connatre lutilisateur. Une vritable tude par les cas dutilisation suppose que le dveloppeur ne fait pas lconomie de la connaissance de ses utilisateurs en particulier et du domaine en gnral.

Cas dutilisation, Analyse, Conception Les cas dutilisation forment le fil rouge des dveloppements. Le passage aux modles d'analyse, puis de conception permettra d'exposer les relations qui existent entre ces lments. Nous utiliserons le strotype <<trace>> entre les diffrents lments de modlisation, depuis les cas dutilisation jusquaux modles de conception et de ralisation. Cycle de vie itratif et incrmental La version propose a pour but de mettre en pratique l'incrmentation du logiciel. Dans cette tude de cas simplifie, une seule itration de chaque phase sera ralise. Itrer consiste effectuer les activits (expression de besoins, analyse test) plusieurs fois dans le dveloppement dune version ou release du logiciel. Mise en uvre en C++ La relation entre modle de conception (vue statique des classes) et composants <<file>>, est une tape assez dlicate de la ralisation. Qui n'a pas t confront des fichiers "header" C ou C++ mal conus ? Par ailleurs, l'objectif n'est pas de mettre en uvre des mcanismes sophistiqus du langage C++ tels que lutilisation de classes spcialises de la bibliothque standard ou la gnricit.

4 __________________________________________________________________ tude de cas

1.2 Dmarche simplifie

Le langage UML peut tre compar une belle carrosserie, mais sans moteur. Autrement dit, UML nest pas une mthode. Il reste donc dfinir au pralable une dmarche de mise en uvre des concepts et diagrammes proposs par UML. Cet aspect est fondamental, mme sur un petit projet. En effet, quoi sert, par exemple, un modle "cas dutilisation" parfait si son intgration dans les dveloppements n'est pas clairement dfinie ? Le dveloppement de la calculette est bas sur un cycle de vie simplifi par rapport au cycle complet (cration, laboration, construction, transition) constitu de deux phases : laboration, construction. Release Calculette graphique Elaboration Construction Phase Itration Itration dlaboration Itration de construction

Figure 11 : Itrations de la calculette

Les phases de cration et de transition seront prsentes dans la deuxime tude de cas. Le tableau suivant rcapitule ces itrations et leurs activits.
Jul 99 1 2 3 4 5 6 7 8 9 10 11

Phases / Activits Elaboration calculette Itration d'laboration Expression de besoins Analyse Conception/Architecture Programmation/Test Construction calculette graphique Itration de construction Expression de besoins Analyse Conception Programmation/Test

Figure 12 : Planning du projet

1.2.2.1 Les phases du cycle de vie La version graphique de la calculette fait lobjet de deux phases, chaque phase tant constitue dune itration. laboration version calculette Cette phase couvre aussi le dmarrage du projet qui est habituellement ralis lors de la pr-tude (cration).

www.thierrycros.net

___________________________________________________________ 5 Le projet calculette

Expression des besoins de type calculette/convertisseur. Le rsultat est le modle des cas d'utilisation. Lexpression de besoins nest pas exhaustive dans la mesure o lobjectif est ici de valider larchitecture de la calculette partir de cas dutilisation significatifs. Analyse du systme partir des strotypes proposs dans Unified Process. Le rsultat est le modle d'analyse. Conception dune architecture partir des cas d'utilisation et des exigences en terme d'volution. Le modle de conception et le modle de dploiement constituent le rsultat. Programmation et test des choix de conception, implmentation incomplte qui a pour but de valider larchitecture. Le modle des cas dutilisation correspond lensemble des diagrammes de cas dutilisation qui expriment les besoins des acteurs. Il comprend galement les descriptions textuelles des cas dutilisation ainsi que des diagrammes de squence qui prcisent les interactions acteur/systme lors des scnarios, cest--dire des instances de cas dutilisation. Le modle d'analyse prsente les classes, les relations entre objets sous forme de collaborations, les diagrammes dtat des classes pertinentes du point de vue dynamique. Le modle de conception est une description des mcanismes de base dimplmentation, par exemple pour vrifier la pertinence et la faisabilit des dcisions danalyse en terme de responsabilits de classes. Il est constitu essentiellement de diagrammes de classes et de sous-systmes ainsi que de diagrammes dinteractions. Le modle de dploiement permet de visualiser l'architecture matrielle de la calculette. Il est bas sur les diagrammes de dploiement et de composants. Les diagrammes dinteraction permettent de modliser les relations dynamiques entre les nuds. A lissue de cette premire itration dlaboration, nous devons tre srs de larchitecture. Elle aura t valide par une activit dimplmentation / test. Construction calculette version graphique Cette deuxime phase a pour but de fournir une version exploitable. Expression complte des besoins Analyse Conception partir du prototype ralis en laboration et en tenant compte de limpact de laspect vnementiel du graphisme Programmation en C++ avec utilisation de la bibliothque Motif. Cette itration sera loccasion de prsenter cet environnement graphique particulirement sophistiqu grce UML. Test partir des cas d'utilisation.

1.3 Expression de besoins

6 __________________________________________________________________ tude de cas

Ce paragraphe prsente lactivit dexpression de besoins de la calculette.

Jul 99 1 2 3 4 5 6 7 8 9 10 11

Phases / Activits Elaboration calculette Itration d'laboration

Figure 13 : Itration dans le cycle de dveloppement

La finalit de cette activit est la description gnrale des fonctionnalits du systme. L'tude des besoins n'est pas l'analyse. La question quelles sont les fonctions du systme ?", devient "quels sont les utilisateurs du systme ? Et qu'attendent-ils du systme ?".
Jul 99 1 2 3 4 5 6 7 8 9 10 11

Phases / Activits Elaboration calculette Itration d'laboration Expression de besoins

Figure 14 : Activit dans litration

La dmarche que nous proposons ici est trs classique et naturelle. Elle est fortement simplifie dans la mesure o les cas sont par nature trs lmentaires et galement trs peu nombreux. Dmarche dobtention du modle cas dutilisation La dmarche simplifie est la suivante : Obtenir les cas dutilisation Dfinir les acteurs Lister les cas dutilisation principaux Formaliser par un diagramme de cas dutilisation Prciser par des descriptions textuelles Vrifier les cas dutilisation Approcher le systme par des diagrammes dinteraction acteur / systme

1.3.1 Dfinir les acteurs

Les acteurs sont dtermins par catgorie. De ce point de vue, le systme est destin des utilisateurs de catgorie principale, cest pour eux que le systme est fabriqu. Ils sont la rponse la question : pour qui est fabriqu le systme ?

www.thierrycros.net

___________________________________________________________ 7 Le projet calculette

Le fonctionnement du systme implique trs souvent des oprations dexploitation. Les fonctions de sauvegarde, de configuration ne sont pas les fonctions essentielles du systme, mais elles sont obligatoires pour assurer son intgrit. Autrement dit, le systme nest pas conu pour rpondre ces cas dutilisation, mais ces cas dutilisation secondaires autorisent lexploitation du systme. Les acteurs concerns sont de catgorie secondaire . Ces acteurs sont la rponse la question : qui est ncessaire pour le bon fonctionnement du systme ? A ce stade, il est ncessaire de distinguer acteurs et utilisateurs humains. Lacteur est le rle que joue un utilisateur humain, non lhumain en tant que tel. Une personne peut jouer plusieurs rles. De faon gnrale, la liste des acteurs doit tre trs prcise car elle induit la liste des cas dutilisation qui forment le fil rouge des dveloppements. Ici, le fait dindiquer que la catgorie matriel est non applicable montre que lon sest vraiment pos la question (et accessoirement que l'on a la rponse). Notons enfin quil est possible daffiner ces catgories de base. Les strotypes dUML sont un excellent moyen dadapter le concept dacteur au domaine. A qui est destine la calculette ? Le systme - la calculette - est destin un utilisateur ou oprateur qui souhaite effectuer des calculs et des conversions. Ce dernier cas conversion Franc / Euro - suppose la connaissance du taux de conversion. Ainsi, la valeur du taux, qui doit tre fournie au systme, induit la prsence dun autre rle, donc acteur, qui configure le logiciel. Il sagit alors dun acteur secondaire que nous nommons Comptable. Pourquoi distinguer ces deux acteurs ? Aprs tout, c'est probablement le mme tre humain qui renseignera le taux et qui effectuera les oprations. La rponse est dans la nature des cas dutilisation. Autant il est cohrent de dvelopper une calculette-convertisseur pour quun utilisateur (qui joue un rle donc en situation dacteur) effectue des oprations ou des conversions, autant il serait curieux de crer un systme dans le but de saisir un taux. C'est l toute la diffrence entre un cas principal et un cas secondaire. Notons enfin que la distinction entre acteur principal et secondaire permettra de traiter diffremment les cas relis. Typiquement, des cas dutilisation dacteurs secondaires pourraient supporter par exemple une interface utilisateur moins sophistique ou bien faire lobjet dun excutable spcifique. Il n'est pas rare de crer un excutable par acteur voire cas dutilisation. Le rsultat des questions concernant les acteurs est consign dans un tableau rcapitulatif. Gnralement, les termes sont prciss dans le dictionnaire ou glossaire associ au projet. Le rle Utilisateur est retenu car oprateur prte confusion dans le cadre d'une calculette.
Catgorie Acteurs

Principal Secondaire Matriel Systmes

Utilisateur Comptable N/A (non/applicable) N/A

Figure 15 : Tableau des acteurs de la calculette

8 __________________________________________________________________ tude de cas

Un acteur principal engendre des cas dutilisation principaux. Ces cas dutilisation impliquent la prsence dautres cas, lis dautres acteurs. Ainsi, la liste des acteurs est construite au fur et mesure, en harmonie avec la liste des cas dutilisation. Autrement dit, il ne faut pas esprer obtenir dabord la liste de tous les acteurs, ensuite la liste de tous les cas dutilisation. Au contraire, ce processus est largement itratif. Il suppose un dialogue trs fort avec les utilisateurs du systme. Notons au passage que la dtermination des acteurs induit naturellement une premire liste de cas dutilisation candidats cest--dire qui restent valider. UML permet de dcrire les acteurs dans un diagramme de cas d'utilisation simplifi qui ne contient pas de cas. Il reste juger de la pertinence de ce type de diagramme par rapport un diagramme classique de contexte systme qui visualise ventuellement les proprits (tiquettes, contraintes) des acteurs. Un diagramme d'acteur spcifique permet de ne pas surcharger le diagramme de contexte systme. Ici, l'tiquette documentation permet de dfinir le rle. En rsum, ce type de diagramme met l'accent sur les acteurs alors que le diagramme de cas d'utilisation habituel met l'accent sur les cas. Visuellement, les acteurs apparaissent hors du systme. UML permet de communiquer par l'image. Notez que, par convention maison , l'acteur principal est gauche du systme : il est vu le premier, alors que l'acteur secondaire est droite. Ainsi, l'il le dcouvre naturellement aprs. Bien entendu, ce type de convention ne fait pas partie d'UML, mais il est recommand de faciliter la lecture des diagrammes par de telles conventions dutilisation du langage. Les acteurs sont documents afin de les grer en configuration ( partir de latelier de gnie logiciel, AGL). Cette documentation est ainsi facilement et directement accessible depuis le navigateur de lAGL. La figurine de lacteur Comptable est volontairement diminue, ce qui offre un autre moyen visuel de distinction principal / secondaire.

N O T E

Les manuels utilisateur des logiciels taient dans un premier temps constitus de documents papier tels que classeurs ou livres. De fait, ils taient (trs) peu utiliss. Qui ne connat pas le vieil adage : quand on a tout essay, on consulte la documentation ? Lavnement des interfaces graphiques a gnralis les documentations en ligne hypertexte et lutilisation de moteurs de recherche partir de mot cl. Ce type de documentation est parfaitement complmentaire. Sans remettre en cause la ncessit de documentation papier, les programmeurs utilisent lAGL en tant quaide en ligne, leffet immdiat tant que la documentation est ainsi facilement consulte. Do la ncessit de renseigner les proprits documentation des lments de modlisation, ce qui est alors une autre bonne raison de gnrer la documentation papier partir de lAGL. La gnration automatique de documentation est un problme en soi. Au-del de laspect technique de paramtrage des outils, de qualit du trac aprs transfert entre AGL et traitement de texte, la question porte sur le fond. Certains gnrateurs produisent parfois trop de documentation. Les lecteurs ont face eux des centaines de pages, structures artificiellement partir des possibilits de paramtrage de loutil (possibilits de lquipe linstant t en fonction des connaissances, du temps et pas uniquement capacits intrinsques de loutil). A quoi sert ce type de document ? Autre aspect : la notion mme de gnration automatique suppose que lon automatise a priori une tche au pralable manuelle. Lorsquune quipe met en uvre pour la premire fois les technologies objet, il est important dviter ce pige des gnrateurs. Une tude pralable consiste dfinir une documentation en fonction de la culture de lentreprise, de besoins client, de procdures en vigueur de type ISO9000, etc. Alors, le paramtrage de loutil de gnration de documentation automatisera rellement une tche parfaitement impose par lquipe. Dans certains cas, cest malheureusement le gnrateur qui impose et lquipe qui subit le bavardage textuel. Par ailleurs, la question de la documentation est un vritable projet en elle-mme : par exemple synchroniser une documentation externe (client) et une documentation interne (maintenance).

www.thierrycros.net

___________________________________________________________ 9 Le projet calculette

Calculette

Utilisateur {documentation = Cet acteur principal est celui qui utilise la calculette pour effectuer des calculs et des conversions.}

Comptable {documentation = Cet acteur secondaire intervient pour fournir le taux de conversion franc/euro.}

Figure 16 : Acteurs de la calculette

Un raffinage de cette taxonomie dlments externes consiste dfinir un acteur Acheteur qui dclenche les cas de conversion. Dans cet ordre dide, lAcheteur est un Utilisateur particulier. Le diagramme dacteurs volue et tient compte de cette caractristique. Notons au passage que la gnralisation entre acteurs est pratiquement la seule relation effectivement modlise entre acteurs. En effet, visualiser des relations dinteractions entre lments extrieurs au systme remet en cause la frontire mme du systme. Cest un symptme qui impose probablement la redfinition de cette frontire.

Calculette
Utilisateur

Comptable

Acheteur

Figure 17 : Taxonomie dacteur plus (trop ?) prcise

Cette nouvelle classification sous-entend des situations dutilisation de la calculette distinctes. Nous ne la retiendrons pas au final car elle napporte pas notre sens de valeur ajoute significative. Simplement, il est tout fait normal de manuvrer, de louvoyer, pour

10 _________________________________________________________________ tude de cas

obtenir la liste des acteurs. Cest vrai pour tous les lments de modlisation, les acteurs et les cas dutilisation ont toutefois un impact majeur sur le dveloppement car ils pilotent le dveloppement au moyen de la relation de collaboration. En dernire analyse, tout lment produit par le dveloppement doit tre reli un cas dutilisation. Du moins, sans le prciser explicitement au travers de relations telles que <<trace>>, un dveloppeur devrait pouvoir rpondre toute question de type : quels cas dutilisation cet lment correspond-il ? .

1.3.2 Liste des cas dutilisation principaux

Lutilisateur de la calculette souhaite effectuer des calculs et des oprations. Une liste de cas dutilisation telle que : effectuer une addition, effectuer une soustraction, etc est possible. Trs rapidement, la description textuelle de ces cas dutilisation dmontrerait leur faible valeur ajoute. En effet, une description de quelques lignes est suspecte, elle dnote gnralement un niveau de dtail (granularit) trop fin ou tout simplement une approche fonctionnelle. Notons que le cas dutilisation "Taux de conversion" correspond une synchronisation du systme avec son environnement. Ce cas est une rponse la question : quels sont les changements lextrieur du systme qui doivent tre connus du systme ? Ici, nous pouvons considrer que la connaissance du taux de conversion au 1er janvier 1999 a cr un changement l'extrieur du systme qu'il convient de rpercuter. C'est une question de synchronisation. De mme, un systme d'exploitation synchronise rgulirement le disque partir des buffers en mmoire vive.
Acteur Cas dUtilisation

Utilisateur Comptable

Opration (effectuer une opration) Conversion (convertir une valeur) Taux de conversion
Figure 18 : Liste des cas dutilisation de la calculette

Lutilisateur de la calculette joue le rle dUtilisateur quand il effectue des oprations et des conversions, le rle de Comptable quand il initialise le taux de conversion Franc / Euro.

www.thierrycros.net

__________________________________________________________ 11 Le projet calculette

Calculette
Calcul

Taux

Utilisateur

Conversion

Comptable

Figure 19 : Contexte systme calculette (hors rpertoire)

Notons que les cas dutilisation Calcul et Conversion pourraient tre car il sagit de deux cas extrmement simples et lis fonctionnellement. Par contre, le cas Taux doit tre isol car il sagit dun cas dexploitation. Pourquoi crer un diagramme de contexte ? De faon gnrale, UML permet de visualiser, autrement dit de communiquer, par le dessin. Le rectangle associ au systme montre clairement ce qui est lintrieur et ce qui est lextrieur du systme. Bien entendu, le concept mme dacteur est extrmement clair : un acteur est externe. Simplement, le visualiser ainsi facilite la lecture et la comprhension du diagramme, en particulier lorsque le lecteur nest pas familiaris avec UML. Notons aussi que certains projets se caractrisent par une difficult srieuse dfinir ce qui est et nest pas - lintrieur du systme. Par ailleurs, plusieurs diagrammes de contexte deviennent ncessaires lorsque le systme est trs complexe et que les lments modliser (acteurs et cas) sortent du format dimpression, en gnral le format A4. ICI NOTE SUR LA TAILLE DES DIAGS ET LE NBRE DELSTS CONTENUS

1.3.3 Descriptions textuelles des cas dutilisation

1.3.3.1 La fiche-type de description Les cas dutilisation de la calculette sont ici dcrits au moyen dune fiche-type simplifie : tous les lments ncessaires dans un projet rel ne sont pas repris. Le niveau de dtail des interactions reste grossier car il sagit - dans ces descriptions - de spcifier les changes acteurs / systme au travers des cas, non pas de dfinir prcisment linterface homme-machine (IHM) du systme. Une fiche-type de description est indispensable, afin dharmoniser les descriptions de diffrents analystes. Notons que la partie description peut couvrir plusieurs pages. Le nombre de pages maximum est aussi une dcision de type assurance qualit du projet. Ici, les cas sont trop simples pour que cette question ait un sens. Dans cet ordre dide, le terme fiche ne doit pas prter confusion. Il sagit en ralit de plan type de paragraphes (un par cas) qui sont injects dans la documentation du modle dexpression de besoins.

12 _________________________________________________________________ tude de cas

N O T E

La longueur moyenne de la description des cas est un sujet de discussion. Certains consultants ou experts prconisent des textes de plusieurs pages, par exemple 10 pages au maximum. Dautres prfrent des descriptions beaucoup plus courtes de lordre dune ou deux pages. Le domaine, le projet, lexprience acquise forgent une opinion. Les descriptions courtes ont tout de mme un danger, celui de la dispersion. La rgle qui consiste dire quelques grands cas assure une bonne synthse de lessence du systme. Ici, nous voquons les cas au sens classique, situation dans laquelle un utilisateur est en contact avec le systme. Les relations dorganisation de cas ( extend , include ) limitent la taille relle des descriptions, ce qui est offre un bon compromis. Nous reviendrons sur ce point prcis dans la deuxime tude de cas.

Les rfrences une ventuelle maquette prcisent le style dchanges. La maquette permet de rgler les dtails de linterface. La description des cas d'utilisation et la maquette sont complmentaires et ne font pas double emploi. En effet, une maquette ne permet pas d'noncer facilement et sans ambigut l'enchanement des interactions. Elle ne fournit pas non plus directement l'ensemble des cas alternatifs qui sont intgrs dans la description textuelle, par opposition aux cas normaux. Sans maquette logicielle, des reprsentations papier permettent de matrialiser les changes dcrits dans les cas dutilisation. Toutefois, voquer une maquette, des noms de boutons, etc dans une description textuelle de cas dutilisation prsente un danger. Dune certaine manire, cela limite lexpression de besoins la premire mise en uvre de linterface utilisateur. Le Unified Process propose les descriptions essentielles qui excluent toute rfrence une quelconque mise en uvre pour sen tenir la signification (lessence) des changes entre acteurs et systme.

Titre Acteur(s) Description

<Titre du cas dutilisation> <Ici les acteurs participant au cas dutilisation (au moins un)> <Ici description des interactions (et non pas du comportement interne du systme). Le langage est gnralement naturel. Des mots cls peuvent tre insrs pour simplifier les descriptions de choix ou de boucles. Les choix alternatifs, exceptionnels, les cas limites ou derreur peuvent tre distingus visuellement par des caractres spciaux, par exemple [annulation]. Ils renvoient au champ "Exceptions". > <Ici description des interactions alternatives ou exceptionnelles>
Figure 110 : Fiche Type simplifie de description de cas dutilisation

Exceptions

Le Titre est celui utilis dans la liste des cas dutilisation. Les Acteurs interviennent dans les interactions, qu'ils soient dclencheurs ou non du cas dutilisation. De faon gnrale, un cas dutilisation doit concerner au moins un acteur : le bnficiaire du cas ( qui profite le cas ? ). Thoriquement, un cas dutilisation est dclench par un acteur. La Description textuelle doit tre comprhensible par un non informaticien, sauf dans le cas particulier de systme destin des informaticiens. Mais il est rare que tous les intervenants dun projet (client, financier) soient informaticiens. La description est donc base sur le langage naturel. En effet, l'une des finalits des cas dutilisation est de faciliter le dialogue entre dveloppeurs et utilisateurs, afin d'viter le "syndrome de la balanoire" (clbre ensemble de dessins qui montre les dviations subies par un logiciel depuis les vux de l'utilisateur jusqu' sa ralisation). ICI NOTE AUTRES POSSIBILIOTES DE DESCRIPTION DES CAS E/T

www.thierrycros.net

__________________________________________________________ 13 Le projet calculette

La clause "Exception" correspond la description des interactions spcifiques aux cas alternatifs ou exceptionnels (cas limite, cas d'erreur ou annulation par exemple). La description textuelle des cas dutilisation dmarre lorsque la fiche-type et le niveau de dtail sont tablis. De ce point de vue, un acteur donn devient un objet dun systme englobant au mme titre que le systme lui-mme. Les deux objets (acteur, systme) collaborent lors dun cas dutilisation. La collaboration entre ces objets suppose lenvoi de messages, a priori dans les deux sens. La terminologie consacre pour ces messages est "interactions". Lassocication qui relie les deux classificateurs est une relation de communication.
N O T E Les structures de contrle de flot dexcution : tant quefin tant que, boucle fin boucle, choix parmi peuvent tre injectes dans les descriptions textuelles. Le terme pseudo-code est suspect car il sous-entend quelquefois une conception dtaille pour un dveloppeur. Or, ces structures existent dans la ralit des systmes, sans aucun lien avec des langages de programmation. Par exemple, un comptable calcule une facture et cumule des prix hors taxes "tant que" des produits sont traiter, dans son systme de facturation. De plus, ces structures de contrle ne sont absolument pas destines se transformer lidentique en programmation. En effet, les choix de conception peuvent induire des ralisations dans lesquelles les structures sont invisibles. Dans le cas dinterface graphique, un utilisateur utilisera autant de fois que ncessaire un bouton pour raliser une action, mais le code ne comprendra pas cette structure autant de fois que ncessaire . Cest en quelque sorte le scnario impos par lacteur qui dfinit la boucle et non le code. Attention donc ne pas confondre description de cas dutilisation et conception dtaille prmature.

1.3.3.2 Les descriptions Cas dutilisation Opration Lutilisateur nenvisage pas dans une premire version lenchanement de calculs. Seules des oprations isoles telles que : 20 + 32 sont acceptes. Lutilisateur peut annuler une opration tout moment : c'est un cas alternatif par rapport lutilisation normale qui consiste mener le calcul jusquau bout.

Titre Acteur(s) Description

Opration Utilisateur Ce cas dutilisation est dclench par lUtilisateur lorsquil souhaite effectuer une opration et quil saisit le premier chiffre. Il saisit le premier oprande. La calculette affiche cet oprande au fur et mesure de la saisie des chiffres. Lutilisateur choisit loprateur parmi : + - x / La calculette affiche toujours le premier oprande. LUtilisateur saisit le deuxime oprande. La calculette affiche cet oprande au fur et mesure de la saisie des chiffres. LUtilisateur demande le rsultat. La calculette affiche le rsultat. [Division par zro] Le cas dutilisation est alors termin. [Annulation]

14 _________________________________________________________________ tude de cas

Exceptions

[Annulation] A tout moment, lUtilisateur peut annuler lopration complte en appuyant sur AC . Dans ce cas, la calculette affiche 0 . [Division par zro] Dans ce cas, la calculette affiche 0 .

A ce stade, la maquette de la calculette peut tre (sans tenir compte de la virgule pour simplifier) : 0 1 4 7 AC 2 5 8 0 3 6 9 = / x +

Figure 111 : Maquette temporaire calculette pour cas Calcul

La mise au point de cette description suppose un dialogue intense entre analyste et utilisateur. L'analyste doit obtenir les besoins fonctionnels cas d'utilisation et les spcifications non-fonctionnelles. Ici, la prcision de l'affichage, par exemple six chiffres aprs la virgule, est un exemple de besoin non-fonctionnel. Cette information est alors traite sous forme de contrainte associer au cas d'utilisation. Cela permet simplement de faciliter la traabilit de cette exigence non-fonctionnelle car elle est ainsi partie intgrante du modle gr dans lAGL. Cas dutilisation Conversion Ce cas dutilisation consiste effectuer une conversion Franc vers Euro ou linverse. Il fait apparatre une pr-condition dans la mesure o le taux de conversion doit tre connu pour que ce cas se droule correctement. Une autre solution est de considrer la situation taux inconnu en tant que cas exceptionnel. Titre Acteur(s) Pr-condition Conversion (convertir une valeur) Utilisateur Le taux de conversion doit tre connu de la calculette

www.thierrycros.net

__________________________________________________________ 15 Le projet calculette

Description

Ce cas dutilisation est dclench par lUtilisateur lorsquil souhaite convertir une valeur Franc vers Euro ou linverse et quil saisit le premier chiffre. LUtilisateur saisit la valeur. La calculette affiche cette valeur au fur et mesure de la saisie des chiffres. Lutilisateur choisit lun des lments suivants : FrancEuro) la calculette affiche la conversion en euros [Taux inconnu] EuroFranc) la calculette affiche la conversion en francs. [Taux inconnu] Le cas dutilisation est alors termin. [Annulation]

Exceptions

[Annulation] A tout moment, lUtilisateur peut annuler la conversion en appuyant sur AC . Dans ce cas, la calculette affiche 0 . [Taux inconnu] Lorsque le taux na pas t saisi, la calculette nautorise pas les choix FrancEuro ni EuroFranc. Autrement dit, la connaissance du taux est une pr-condition de ce cas.

A ce stade, la maquette de la calculette devient :

0 E 1 4 7 AC F 2 5 8 0 3 6 9 = / x +

Figure 112 : Maquette temporaire calculette pour Conversion

E pour convertir la valeur en Euros, F pour la convertir en Francs.

16 _________________________________________________________________ tude de cas

Cas dutilisation Taux Le cas dutilisation taux de conversion consiste initialiser le taux de conversion Franc / Euro connu depuis le 1er janvier 1999. Titre Acteur(s) Description Taux de conversion Comptable Le comptable saisit les chiffres qui composent le taux. La calculette les affiche au fur et mesure. Le comptable slectionne Taux . La calculette mmorise ce taux. Le cas dutilisation est alors termin. [Annulation] Exceptions [Annulation] A tout moment, le Comptable peut annuler la saisie en appuyant sur AC . Dans ce cas, la calculette affiche 0 .

La maquette devient alors 0 E 1 4 7 AC F 2 5 8 0 T 3 6 9 . / x + =

Figure 113 : Maquette calculette pour Taux

T : pour mmoriser le taux de conversion Franc / Euro. Ce cas dutilisation implique la prsence du point dcimal. A ce stade, les cas dutilisation de la premire version sont a priori termins. Pourquoi a priori ? Car les activits d'analyse, de conception, voire de programmation imposent parfois des modifications de spcification de besoins. De faon gnrale, nous dirons que larchitecture influence les cas dutilisation.

1.3.4 Vrification des cas dutilisation

Les cas dutilisation doivent tre vrifis plusieurs niveaux. Les acteurs, la liste des cas, les diagrammes, les descriptions textuelles sont autant dlments de modlisation valider avant de passer une vue plus intrieure du systme.

www.thierrycros.net

__________________________________________________________ 17 Le projet calculette

Acteurs Tous les acteurs ont-ils t pris en compte ? La typologie (principal, secondaire) est-elle correcte ? Chaque acteur correspond-il un rle par rapport au systme et non un vritable utilisateur humain (pas dacteur tels que Pierre, Paul ou Jacques) ? Ici, utilisateur est assez pauvre en terme de description de lacteur. Toutefois, la calculette en tant que systme suppose des rles dutilisation trs gnraux. De faon gnrale, les termes tels quutilisateur, exploitant dnotent soit des systmes universels, soit une mconnaissance de lenvironnement dutilisation. Ici, nous opterons pour la premire possibilit Liste des cas dutilisation Tous les cas dutilisation sont-ils pris en compte : par acteur, par vnement de dclenchement ? La synchronisation systme / environnement est-elle assure ? Les cas dutilisation secondaires sont-ils exhaustifs (avez-vous pens sauvegarder les donnes) ? Les cas dutilisation sont-ils majeurs ? Autrement dit, chaque cas est-il une fonctionnalit qui mriterait le dveloppement du systme ? Souvent les cas dfinissent plutt des interactions ou bien des situations particulires de cas plus gnraux. De faon gnrale, la liste des cas dutilisation peut tre diminue en regroupant des cas logiquement lis et considrs dans un premier temps comme spars. Cest le trs haut niveau smantique des cas dutilisation qui explique leur nombre rduit. A contrario, un nombre lev de cas est typique dun niveau de dtail trop fin. Une astuce consiste imaginer tel ou tel acteur (rle jou par un utilisateur rel) o vous voulez sauf devant son cran. Il dcide soudain de venir sa station de travail et de lancer lapplication. Pourquoi ? Pour crer une instance de cas dutilisation (scnario). Cette vision de lutilisation du systme permet de conserver un haut niveau dvaluation des cas dutilisation et dviter la confusion cas / interaction. En dernire analyse, il sagit dpurer la liste de cas, afin de synthtiser la finalit du systme. Ici, une bauche de liste de cas pourrait tre : addition, soustraction ce qui aboutirait une premire liste dune dizaine de cas. Ce nombre est visiblement trop lev pour un systme de ce type. Imaginons la description textuelle du premier cas. A lissue de cette premire description, il est clair que les diffrents cas dopration peuvent tre regroups en un seul texte, donc en un seul cas. Autant il est lgitime de dmarrer avec une liste imparfaite, autant litration sur les cas doit permettre dobtenir in fine une liste correcte. Diagramme de cas dutilisation Comme pour tous les diagrammes, il faut vrifier la nomenclature : titre du diagramme en particulier. Vrifier aussi le souci de lisibilit : les lments du diagramme sont-ils dessins pour faciliter la comprhension du diagramme ? Dans un diagramme de cas dutilisation, une convention pourrait tre : acteurs principaux sur la gauche des ellipses, acteurs secondaires sur la droite. Ici, un seul diagramme, celui de contexte qui montre tous les acteurs et leurs cas dutilisation. Simplement, nous avons pris soin de placer lacteur secondaire sur la droite. Description textuelle Lcueil le plus classique est linsertion de comportements internes. Or, les cas dutilisation reprsentent une vision externe du systme. De ce point de vue, le systme est un objet opaque avec lequel on interagit lors de cas dutilisation. Par ailleurs, le langage utilis est essentiel pour assurer le dialogue entre utilisateurs et dveloppeurs. Des structures de

18 _________________________________________________________________ tude de cas

contrle telles que tant que peuvent tre utilises. Lessentiel est de prserver la valeur doutil de communication des descriptions. Une description du comportement interne du systme est un signe de passage l'exercice d'analyse. Mais il s'agit de ne pas confondre expression de besoins par les cas d'utilisation et analyse. La premire activit permet de dgrossir les fonctionnalits du systme grce un formalisme extrmement et volontairement simple. Un dveloppeur professionnel peut douter de l'efficacit des cas. Il faut les replacer dans leur contexte qui est le dialogue avec la communaut des utilisateurs et ne pas oublier laspect essentiel des cas dutilisation en terme de rfrence constante lors des dveloppements. Ces derniers sont pilots par les cas dutilisation.

1.3.5 Sapprocher du systme

Les cas dutilisation sont une description externe du systme. Lactivit suivante (toujours dans lexpression de besoins) consiste sapprocher du systme, tout en restant lextrieur. Cest la modlisation des interactions sous forme de diagramme de squences. Un premier scnario consiste effectuer une opration telle que 20 + 32 ou mme 1 + 2. Le diagramme de squence qui en dcoule est extrmement simple mais il permet de shabituer aux vnements externes du systme. Il permet aussi de visualiser plus facilement les interactions dcrites textuellement dans les cas.

calculette x : Top Package UC::Utilisateur 1 1 affich + 2 2 affich = 3 affich

Les messages sont de type 'flat'

Figure 114 : Diagramme de squence : calcul normal

Le nom de lacteur est x. Il appartient la classe dacteurs Utilisateur , classe dfinie dans le paquetage Top Package UC impos par UML. En effet, tout lment de modlisation doit appartenir un paquetage. Ainsi, chaque modle est ipso facto muni dun

www.thierrycros.net

__________________________________________________________ 19 Le projet calculette

paquetage racine de tous les autres dans le modle. Comme tout paquetage celui-ci contient Des lments de modlisation, ici acteurs et cas Des diagrammes, ici diagramme de cas et de squence essentiellement ventuellement des sous-paquetages. Un deuxime scnario, issu du mme cas dutilisation Calcul permet dobtenir un nouveau diagramme de squence. Il sagit dun scnario alternatif aussi important que le scnario normal. Quelquefois, la complexit dun systme rside dans ses cas alternatifs essentiellement.

calculette x : Top Package UC::Utilisateur 1 1 affich AC 0 affich

Les messages 'valeur affiche' pourraient tre remplacs par 'lire valeur'

Figure 115 : Calcul cas alternatif dannulation

Notons quune question vient rapidement lesprit : combien de diagrammes de squence dessiner ? Un diagramme quel quil soit doit offrir une certaine valeur ajoute. Si le rdacteur et les lecteurs considrent que la cration puis la lecture de tels diagrammes napportent aucune information pertinente alors il est temps darrter et de passer lactivit suivante. Rien nest plus dsagrable que de crer des diagrammes qui visiblement nont aucune valeur ajoute. De mme, il est dsagrable de sauter des pages entires de document, la recherche du prochain diagramme qui apportera vraiment une information au lecteur. Si les cas sont correctement rdigs, leur lecture doit pouvoir se traduire directement en diagramme de squence. Bien entendu, nous voquons dans ce contexte des cas extrmement simples de la forme :
Lacteur effectue cela, Le systme rpond de telle faon

20 _________________________________________________________________ tude de cas

N O T E

Rappelons tout de mme que ces diagrammes sont une aide lobtention de diagrammes dtat / transition de cas dutilisation ou du systme dans son ensemble. En effet chaque transition ne peut survenir que sur un vnement (ou une fin dactivit ou encore une condition qui devient vraie dans le cas de transitions automatiques). Les diagrammes de squence visualisent parfaitement les transitions possibles : ce sont les diffrents segments de la ligne de vie de lobjet considr. Bien entendu, ltude de la dynamique retiendra uniquement les transitions juges pertinentes parmi toutes les transitions au sens changement de valeur dattribut dans lobjet.

1.3.6 Modle de cas dutilisation

Le rsultat de cette premire activit est le modle de cas dutilisation, constitu des diagrammes de cas dutilisation, des descriptions textuelles et des diagrammes de squence. Notons que les cas dutilisation peuvent tre visualiss munis de leurs proprits et contraintes.

Top Package UC::Calculs {tat = en cours}

{prcision = 6 dcimales, affichage = 6 dcimales, documentation = - l'utilisateur saisit les chiffres du premier oprande - la calculette affiche le premier oprande au fur et mesure de la saisie - l'utilisateur saisit l'oprateur parmi : + - x / ...}

Calcul

{precision = 5 dcimales, affichage = 2 dcimales, conformit = rgles de conversion Franc - Euro}

Conversion

Figure 116 : Cas dutilisation avec proprits

Ce diagramme visualise de nombreuses informations. Il reprsente le paquetage de cas dutilisation nomm Calculs . Cela correspond une certaine organisation des cas dutilisation en fonctionnalits. Nous le reprsentons simplement en tant quexemple. Ltiquette tat montre que ce paquetage est en cours de mise au point. Chaque cas dutilisation possde une tiquette documentation utilise pour renseigner les interactions du cas. Sauf exception, lensemble des interactions ne tient matriellement pas dans cet

www.thierrycros.net

__________________________________________________________ 21 Le projet calculette

espace. Il nest donc pas judicieux de compter sur ce type daffichage pour documenter facilement le cas. Toutefois, le rsum du cas peut y apparatre. Par contre les tiquettes telles que prcision ou affichage permettent de consigner les besoins nonfonctionnels. Lintrt tant que ces informations deviennent des lments de modlisation UML. La relation trace , correctement annote, permettra en analyse, conception, programmation, dassocier des lments de ralisation ces besoins particuliers.

22 _________________________________________________________________ tude de cas

LE PROJET CALCULETTE......................................................................................2 1.1L'tude de cas ..................................................................................................................3

1.1.1 Les fonctionnalits de la calculette ...............................................................................................3 1.1.2 Points techniques tudis ..............................................................................................................3

1.2Dmarche simplifie........................................................................................................4 1.3 Expression de besoins ....................................................................................................6

1.3.1 Dfinir les acteurs .........................................................................................................................7 1.3.2 Liste des cas dutilisation principaux ..........................................................................................11 1.3.3 Descriptions textuelles des cas dutilisation................................................................................12 1.3.4 Vrification des cas dutilisation.................................................................................................18 1.3.5 Sapprocher du systme ..............................................................................................................19 1.3.6 Modle de cas dutilisation .........................................................................................................21

www.thierrycros.net