Index of /GestionProjetInfo/Activités de GL/Spécification

Icon  Name                                 Description
[PARENTDIR] Parent Directory                     
<style>
#contenu h1 { padding: 2px 10px;}
#contenu h1>* { background-color: rgba(255, 238, 221, 0.8);margin: 0 10px;padding: 0 10px;border: 2px solid #114499;} 
</style>
<h1><span>Génie Logiciel : activité de spécification</span></h1>

<style>
#contenu dl dt { padding-top:6px;padding-bottom:2px;text-decoration:underline;color: #114499;} 
#contenu dl:after {clear:both; content:' ';display:block; }
#contenu table th:last-child {background-color: rgba(255, 238, 221, 0.8);margin: 0 10px;padding: 0 10px;border: 1px solid #114499;}
#contenu i { color: #114499; }
</style>

<table style="width:96%;margin:0 2%;"><tr>
<th>Activité</th><th> Spécifier (= définir le <i>quoi</i>) </th>
</tr><tr>
<th>Description</th>
<td> 
Décrire ce que doit faire le logiciel (comportement en boite-noire). 
Décrire comment vérifier en boite-noire que le logiciel fait bien ce qui est exigé.
</td>
</tr><tr>
<th>Entrées</th>
<td> 
Client qui a une idée de ce qu’il veut.
</td>
</tr><tr>
<th>Sorties</th>
<td> 
Une spécification (description des besoins du client).
Des procédures de validation.
</td></tr></table>

<p>
Une spécification peut suivre de nombreux formalismes: cas d’utilisation, modèles UML, user-stories, exigences ...
<br />
Les procédures de validation peuvent être des procédures manuelles ou des tests.
</p>

<img src="Activités de GL/_images/phaseSpecification.png" style="width:420px;float:right" />

<p>
La phase de spécification est construite sur le même modèle que la phase d'analyse.  
Cette phase est réalisée de manière artisanale, dans l'objectif 
de préparer à la phase d'implémentation qui serait elle le plus possible automatisée.
Les essais lors des phases de spécification sont approuvés ou rejetés 
pendant l'étape de vérification (qui consiste à vérifier la construction interne à une phase) 
ou pendant l'étape de validation 
(qui consiste à vérifier que le produit correspond à la spécification).
</p>


<style>
.exemple {background-color: rgba(221, 238, 255, 0.8);border: 1px dotted #114499;padding:0 4px;margin:0 10px; }
.exemple:after {clear:both; content:' ';display:block; }
</style>

<h2>Exemple</h2>

<div class="exemple">
<p>
En entrée de la spécification, il y a un <b>besoin d’un client</b> :
</p>
<ul><li> Le logiciel DigitalTuner doit s’interfacer avec la radio numérique DigitalRadio.
</li><li> Le logiciel affiche la fréquence et le nom de la station à l’écoute.
</li><li> Le logiciel peut mémoriser la station à l’écoute.
</li><li> L’utilisateur sélectionne une station mémorisée pour l’écouter.
</li><li> L’utilisateur incrémente/décrémente la fréquence à l’écoute.
</li><li> L’utilisateur passe à la précédente/prochaine station radio dans la bande de fréquence.
</li><li> Faire un premier produit embarqué sur automobile. Prévoir un produit embarqué sur téléphone portable, puis un produit embarqué sur lecteur MP3.
</li></ul>
</div>
<p>
Le besoin est trop vague, il faut le clarifier: c’est la <b>spécification</b>.
</p><p>
Un préalable est la <b>définition des termes</b>, 
qu'il s'agisse des termes spécifiques au métier du logiciel à développer,
comme du vocabulaire décrivant la gestion de projet.
</p><p>
Ensuite, le <b>recueil du besoin</b> 
(<em lang="en">requirement document</em>, <em lang="en">identification of needs</em>)
doit conduire à l'élaboration d'une liste d'<b>exigences</b>,
chacune d'elle devant être <b>mesurable</b> : 
à chaque exigence doit être associée un <b>test</b> et une <b>recette</b>, 
comme par exemple "<i>répondre en moins de 10mn dans 90% des cas</i>".
</p>

<h2>Cas d'utilisation</h2>

<p>UML est un langage de modélisation, 
qui sert à consigner les décisions prises en phase d'analyse et de conception.
Voir <a href="?page=Outils/Langage de modélisation/">page=Outils/Langage de modélisation/</a>
</p><p>
La phase de spécification est la première application du langage UML, 
pour représenter les cas d'utilisation.
</p><p>
Le cas d'utilisation représente l'interaction typique d'un utilisateur avec le système 
quand il s'agit d'atteindre un objectif donné.
Par exemple, si on utilise un logiciel de traitement de texte, un des cas d'utilisation est 
"<i>effectuer une vérification orthographique</i>", une autre "<i>créer un index</i>".
</p><p>
L'élément essentiel est que chaque cas d'utilisation indique une fonction 
que l'utilisateur peut comprendre et qui a de la valeur pour lui.
Un développeur peut répondre par des éléments spécifiques, par exemple : 
</p><p style="font-style:italic;margin:4px 10px;">
Il me faudra deux mois pour réaliser la fonction d'indexation. 
J'ai aussi un cas d'utilisation pour la fonction de vérification grammaticale, que j'estime à 3 mois.
Nous n'avons que trois mois de délai. Laquelle voulez-vous ?
</p><p>
Les cas d'utilisation sont la base de la communication 
entre clients et développeurs lors de la planification du projet.
</p><p>
L'un éléments les plus importants de la phase d'élaboration consiste à découvrir
tous les cas d'utilisation potentiels du système à construire.
En pratique, ce n'est pas possible, mais il faut en obtenir le plus possible, 
en particulier les plus importants et ceux qui comportent le plus de risques.
</p><p>
Sans détailler à outrance, un texte d'un à trois paragraphe doit les décrire 
en étant assez précis pour que les utilisateurs puissent comprendre l'idée maîtresse 
et pour que les développeurs  voient approximativement ce qu'elle couvre.
</p>


<div class="exemple">
<img src="Activités de GL/Spécification/_images/exemple-UML-casDUtilisation.png" style="width:480px;float:right" />
<p>
Dans le cas de l'exemple initial (du début de cette page) le diagramme de classe UML suivant 
définit que le composant DigitalRadio doit permettre de:
</p>
<ul><li> L’utilisateur utilise le logiciel Tuner pour sélectionner une station à capter. 
Il y a différentes manières de faire (inc/dec, next/prev, selectMemorized) 
Eventuellement, il peut mémoriserla station captée.
</li></ul>
</div>


<h2>Modélisation du domaine : support de l'Image globale</h2>
<p>
Les cas d'utilisation ne représentent pas l'image globale.
Un autre tâche importante consiste à produire un squelette de modèle conceptuel du domaine.
Par exemple, dans le cas de la conception d'un logiciel de gestion d'entreprise,
un ou plusieurs utilisateurs ont en tête une image de la façon dont l'entreprise fonctionne : 
</p><p style="font-style:italic;margin:4px 10px;">
Nos clients peuvent avoir plusieurs sites, et nous fournissons différents services à ces sites. 
Actuellement, le client reçoit une facture pour tous les services fournis à un site donné.
Nous voulons que tous les services à tous les sites figurent sur la même facture.
C'est ce que nous appelons le regroupement des factures.
</p><p>
Ce passage contient les mots "client", "site" et "service". Que signifient ces termes ?
Comment s'emboîtent-t-ils ? Un modèle conceptuel du domaine commence par répondre à ces questions
et pose en même temps les bases du <b>modèle  du domaine</b> 
pour désigner tout modèle objet qui représentera ultérieurement les objets du système. 
L'expression <b>modèle du domaine</b> est utilisée ici pour désigner
<i>tout modèle dont le principal sujet est 
le monde dans lequel le système informatique s'inscrit, 
quel que soit le stade du processus</i>.
</p><p>
La principale technique utilisée pour la modélisation du domaine est le <b>diagramme de classe</b>,
réalisé d'un point de vue conceptuel. 
Ces diagrammes peuvent servir à agencer les concepts des experts et les liens qu'ils établissent entre eux.
A plus d'un titre, les diagrammes de classe permettent de définir un vocabulaire rigoureux
quand il s'agit de décrire le domaine.
</p><p>
Si le domaine a également une forte composante "<i>flux de travaux</i>" (<em lang="en">workflow</em>),
il est décrit au moyen de <b>diagrammes d'activité</b>.
L'aspect essentiel de ceux-ci est d'encourager la découverte de processus parallèles, 
ce qui importe lorsqu'il s'agit d'éliminer les séquences inutiles dans les processus métier.
</p></p>
Les <b>diagrammes d'interaction</b> sont utilisés pour explorer 
les différents rôles joués par les participants au développement du projet
 — ce que le processus unifié nomme <i>travailleur</i> (<em lang="en">worker</em>) — 
 et leurs interactions. 
 Il semble que le système y soit plus facile à comprendre 
 en pensant simultanément aux travailleurs et aux activités
 pour déterminer les priorités et les rôles alloués aux différents travailleurs.
 </p><p>
 La modélisation du domaine peut constituer un complément important aux cas d'utilisation.
 Lors de la collecte des cas d'utilisation, l'intervention d'un expert du domaine 
 permet d'explorer la façon dont il envisage l'activité de l'entreprise 
 à l'aide de diagrammes d'activité et de diagramme de classe conceptuels.
 Il s'agit de se concentrer sur les questions importantes et les éléments qui comportent des risques,
 sans se préoccuper de la cohérence ni des connexions ou des relations entre les diagrammes.
 Ce processus apporte de nombreux éléments de compréhension et permet d'identifier 
 les cas 'utilisation correspondant aux différents utilisateurs. 





<div class="exemple">
<img src="Activités de GL/Spécification/_images/exemple-UML-diagrammeDeClasse.png" style="width:300px;float:right" />
<p>
Dans le cas de l'exemple initial (du début de cette page) le diagramme de classe UML suivant 
définit que le composant DigitalRadio doit permettre de:
</p>
<ul><li> positionner la fréquence à capter 
</li><li> lire l’énergie du signal capté
</li><li> lire le nom de la station captée
</li></ul>
</div>


<p>
Après avoir abordé la plupart des secteurs pertinents, les différents diagrammes sont consolidés pour obtenir un modèle du domaine, unique et cohérent.
Un ou deux experts sont alors utiles pour approfondir la modélisation.
La perspective conceptuelle est conservée, mais en adoptant plus de rigueur.
Le modèle alors obtenu doit pouvoir servir de point de départ pour la constitution des classes lors de la phase de construction.
Si le modèle est important, il peut être décomposé en "<span lang="en">package</span>".
Les diagrammes de classe et d'activité sont consolidés et 
quelques diagrammes d'état pour les classes dont le cycle de vie est crucial ou intéressant 
sont tracés.
</p>

<h2>Squelette et prototypes</h2>
<p>
Ce modèle initial doit être considéré comme un <b>squelette</b>, non comme un modèle de "<b>haut niveau</b>". 
Cette expression implique l'absence de nombreux détails.
</p><p>
On peut adopter l'approche inverse et construire un modèle détaillé, 
ce qui prend un temps considérable et conduit à un risque de "paralysie de l'analyse".
La difficulté consiste à identifier et à se concentrer sur les détails importants.
La plupart des détails seront traités au cours du développement itératif.
C'est pourquoi il est préférable de considérer ce modèle comme un squelette.
Le squelette est la base du reste du modèle : il est détaillé mais ne constitue qu'une petite partie de l'ensemble.
</p><p>
Le problème de l'analyse peut-être illustré par la métaphore : "différencier la chair des os".
La modélisation du domaine est également pilotée par les coas d'utilisation, à mesure qu'on les découvre.
L'équipe doit alors examiner pour évaluer s'ils contiennent un élément 
qui aura un impact important sur le modèle du domaine.
Si c'est le cas, elle doit les approfondir ; sinon, elle doit les mettre de côté pour l'instant.
</p><p>
L'équipe qui construit le modèle du domaine doit être un petit groupe (de 2 à 4 personnes)
et comprendre des développeurs et des experts du domaine (donc au moins un développeur et un expert).
Pendant la période d'élaboration, l'équipe doit travailler intensivement 
jusqu'à ce qu'elle ait <b>fermé</b> le modèle, 
mais en veillant à ce que les membres de l'équipe 
ne s'enlisent pas dans le détails sans toutefois se situer à un niveau tellement abstrait que leurs pieds ne touchent plus terre 
(rôle du pilote).
Une fois l'objectif compris, le plus grand danger est de s'embourber. Une échéance stricte permet aux esprits de se concentrer.
</p><p>
Pour bien comprendre les besoins, il faut bâtir un <b>prototype</b> de toutes les parties délicates des cas d'utilisation.
Le prototypage est une technique précieuse qui permet de mieux comprendre la dynamique des interactions.
</p><p>
On a recours au prototypage quand on n'est pas sûr qu'une partie du système va fonctionner. 
Il faut aller jusqu'au point qui permet d'en comprendre assez pour évaluer le risque et estimer l'effort nécessaire.
En général, on ne construit pas de prototype de l'ensemble, 
mais on utilise un modèle global du domaine
pour déceler les zones qui nécessitent un prototypage.
</p><p>
Il semble cependant que ceux qui découvrent UML doivent utiliser lus de prototypes. 
Ceux-ci les aident à se familiariser avec les correspondances entre les diagrammes et la programmation effective.
</p><p>
Quand on utilise un prototype, il ne faut pas se laisser contraindre pas l'environnement finale de développement
(l'environnement dans lequel sera réellement développé le logiciel par la suite).
On peut faire de prototypes d'analyse en Smalltalk, même si le système sera développé ensuite en C++.

<h2>Evaluation des risques</h2>
<p>
Les risques peuvent être classés en quatre catégories :
</p>
<ol>
<li>Les risques liés aux <i>spécifications</i></li>
<dd>
Quels sont les besoins du système ? 
Le grand danger est de construire le <em>mauvais</em> système, 
autrement dit un système qui ne répond pas aux besoins de l'utilisateur.
</dd>
<li>Les risques <i>technologiques</i></li>
<dd>
Quels sont les risques technologiques auxquels vous devrez faire face ?
Aves-vous choisi la technologie qui convient ?
Les différents éléments s'emboiteront-ils correctement ?
</dd>
<li>Les risques liés aux <i>compétences</i></li>
<dd>
Pouvez-vous constituer l'équipe et obtenir l'expertise dont vous avez besoin ?
</dd>
<li>Les risques <i>politiques</i></li>
<dd>
Des forces politiques peuvent-elles s'interposer et affecter gravement votre projet ?
</dd>
</ol>
<p>
Il peut y en avoir d'autres, mais les risques qui relèvent de l'une de ces catégories sont presque toujours présents.
</p>

<h3>Gestion des risques technologiques</h3>
<p>
La chose la plus importante à faire à ce niveau 
est de construire des prototypes qui permettent de tester les éléments technologiques envisagés.
</p><p>
Il faut savoir que les risques les plus importants sont inhérents à la façon 
dont les composants de la conception s'emboîtent, plutôt qu'aux composants eux-mêmes.
Il convient donc d'intégrer à ce stade précoce les différentes technologies qui devront être exploitées.
Par exemple, une base de données et un langage de programmation 
devraient être combinées dans une application simple prouvant leur intégrabilité. 
C'est l'occasion pour les développeurs de se familiariser avec les outils 
et les technologies éventuellement exotiques au départ pour eux.
</p><p>
Les décisions concernant l'architecture doivent aussi être validée à ce stade : 
elles prennent généralement la forme d'idées sur ce que seront les composants majeurs
et la façon dont ils seront construits. 
Cette étape est particulièrement importante si vous envisagez un système réparti.
</p><p>
Il faut aussi se concentrez sur les éléments qui semblent difficiles à modifier ultérieurement.
Il s'agit de faire en sorte que la conception permette d'apporter 
des modifications relativement aisées (et indépendantes).
Posez-vous des questions : 
<br /> Que se passera-t-il si un élément technique ne fonctionne pas ?
<br /> Que se passera-t-il si nous ne parvenons pas à emboiter deux pièces du puzzle ?
<br /> Quelles est la probabilité d'un dysfonctionnement ? Comment réagirons-nous dans ce cas ?
</p><p>
Comme pour le modèle du domaine, il faut examiner les cas d'utilisation 
pour déterminer s'ils contiennent un élément qui risque de bloquer la conception. 
Si vous craignez qu'ils ne contiennent un 
<span lang="en">purple worm</span> (en référence au célèbre jeu Mud), 
étudiez la question plus avant.
</p><p>
Les diagrammes de classe et les diagrammes d'interaction sont utiles pour mettre en évidence
la façon dont les composants communiquent.
<br />
Les diagrammes de <span lang="en">package</span> peuvent aussi 
montrer une image de haut niveau des composants.
<br />
Les diagrammes de déploiement peuvent fournir une vue d'ensemble 
de la façon dont les éléments sont distribués.
</p>

<h3>Gestion des risques liés aux compétences</h3>
<p>
Commettre des erreurs prend du temps et le temps coûte de l'argent.
La formation permet d'éviter de faire des erreurs, 
parce que les formateurs s'appuient sur leur expérience de les avoir commises.
La dépense peut-être comparable, mais l'absence de formation rallonge le projet.
</p><p>
Faire appel à un tuteur est souvent une bonne solution. 
A défaut d'un tuteur pour accompagner le démarrage du développement, 
il faut envisager d'accélérer la cadence des revues de projet.
Un tuteur peut alors intervenir juste avant les revues. 
Son rôle est alors de  
mettre l'accent sur les éléments qui peuvent poser problème, 
suggérer des idées complémentaires, 
attirer l'attention sur des techniques dont l'équipe n'a peut-être pas connaissance, 
et ainsi de mettre en lumière les éléments clés qui peuvent être améliorés.
</p><p>
Les compétences peuvent également être améliorées en participant à des groupes de lecture.
La communauté des modèles  (<span lang="en">patterns</span>) considère que les groupes de lecture sont particulièrement utiles.
Voir <a href="http://www.hillside.net/patterns">http://www.hillside.net/patterns</a> où plusieurs groupes de lecture sur les modèles ont vu le jour.
</p><p>
En phase d'élaboration, repérez les domaines dans lesquels 
vous manquez de compétences ou d'expérience et planifiez l'acquisition de celles-ci 
avant le moment où vous en aurez besoin.
</p>

<div class="exemple">
<img src="Activités de GL/Spécification/_images/exemple-UML-diagrammeDeClasseDetaille.png" style="width:560px;float:right" />
<p>
L'interface du composant DigitalRadio doit vérifier :
</p>
<ul><li> Le nom de la station correspondant à la fréquence captée est donné par la sortie tunedStationIdent.
</li><li> Si la fréquence captée ne correspond à aucune station, la sortie tunedStationIdent vaut « ».
</li><li> Le nom d’une station radio est disponible N s après avoir positionné la fréquence à capter.
</li><li> Une station est identifiée par un pic d’énergie sur la sortie measuredEnergy du composant DigitalRadio.
</li><li> La commande freqToTune est lue et les sorties tunedStationIdent et measuredEnergy sont écrites cycliquement à la fréquence F.
</li></ul>
</div>


<h2>Exigences allouées</h2>
<p>
Les spécifications aboutissent à un accord sur une liste d'exigences.
Ces exigences sot regroupées généralement sous 3 catégories, reflétant leur criticité pour le client : 
</p>
<ul><li> prioritaires pour le client (doivent y être, absolument)
</li><li> optionnelles mais importantes (si ça y est c'est mieux)
</li><li> optionnelles (pas grave si ça n'y est pas)
</li></ul>

<div class="exemple">
<p>
Dans le cas de l'exemple initial (du début de cette page) 
les exigences allouées au composant DigitalRadio sont :
</p>
<p> [1.1] L’utilisateur peut utiliser le logiciel DigitalTuner pour incrémenter la fréquence captée. Dans ce cas, la commande freqToTune du composant DigitalRadio est incrémentée de dF Hz.
<br /> [1.2] Si l’utilisateur incrémente la fréquence à l’écoute au-delà de Fmax, alors la fréquence à l’écoute devient Fmin.
<br /> [2.1] L’utilisateur peut utiliser le logiciel DigitalTuner pour décrémenter la fréquence captée. Dans ce cas, la commande freqToTune du composant DigitalRadio est décrémentée de dF Hz.
<br /> [2.2] Si l’utilisateur décrémente la fréquence à l’écoute au-dessous de Fmin, alors la fréquence à l’écoute devient Fmax.
<br /> [3.1] L’utilisateur peut utiliser le logiciel DigitalTuner pour capter la prochaine station sur la bande de fréquences [Fmin .. Fmax].
<br /> [3.2] S’il ne reste plus de signal à capter jusqu’à Fmax, la recherche repart de Fmin.
<br /> [4.1] L’utilisateur peut utiliser le logiciel Tuner pour capter la précédente station sur la bande de fréquences [Fmin .. Fmax].
<br /> [4.2] S’il ne reste plus de signal à capter jusqu’à Fmin, la recherche repart de Fmax.
<br /> [5.1] L’utilisateur peut mémoriser la fréquence captée.
<br /> [5.2] Même après avoir rallumé la radio, l’utilisateur peut sélectionner une fréquence précédemment mémorisée. La commande freqToTune du composant DigitalRadio est positionnée à la fréquence mémorisée.
<br /> [5.3] A la mise sous tension, le logiciel DigitalTuner demande à DigitalRadio de capter la fréquence écoutée à la fin de la dernière mise sous tension.
<br /> [6.1] L’utilisateur peut lire la fréquence du signal capté.
<br /> [6.2] Si la fréquence captée est une station, alors l’utilisateur peut lire le nom de la station.
</p>
</div>



<p class="signature" style="text-align:right;font-size:80%;font-style:italic;"> Ce contenu est largement inspiré 
du <a href="http://manu40k.free.fr/CoursGenieLogiciel.pdf">support de cours de E. Chenu</a>
pour l'ESISAR. </p>