Extrait du cours génie logiciel les principaux enchaînements d’activités

IV.3. Processus piloté par les cas d’utilisation
IV.3.1. Intérêt des cas d’utilisation
Le but principal d’un système informatique est de satisfaire les besoins du client. La détermination et la compréhension de ces besoins sont souvent difficiles. Les cas d’utilisation (use cases) est une technique de détermination intégrée dans UML. Ils privilégient le point de vue de l’utilisateur. Ils recentrent ainsi l’expression des besoins sur les utilisateurs, en partant du principe qu’un système est avant tout construit pour ses utilisateurs.
Les cas d’utilisation ont pour objectif de comprendre et structurer les besoins des utilisateurs. Ils guident pour cela la conception, l’implémentation et les tests. C’est à partir du modèle des cas d’utilisation que les développeurs créent une série de modèles de conception et d’implémentation réalisant les cas d’utilisation. Chacun des modèles successifs est ensuite révisé pour en contrôler la conformité par rapport au modèle des cas d’utilisation. Enfin les testeurs testent l’implémentation pour s’assurer que les composants du modèle d’implémentation mettent correctement en œuvre les cas d’utilisation.
Dire que UP est piloté par les cas d’utilisation signifie qu’il procède par une série d’enchaînements d’activités dérivés des cas d’utilisation puisque la plupart des activités (analyse, conception, implémentation et test) sont effectuées à partir des cas d’utilisation. Les cas d’utilisation guident ainsi le processus de développement.
La figure ci-dessous présente le lien que les cas d’utilisation nouent entre les différentes étapes du processus.
En résumé, UP est piloté par les cas d’utilisation parce que ces derniers :
1. permettent d’identifier les véritables besoins : Un cas d’utilisation est une séquence d’actions qu’effectue le système afin de produire un résultat satisfaisant pour un acteur particulier.
L’identification des cas d’utilisation est fondamentale pour le processus unifié. Ils représentent les fonctionnalités que fournit le système pour rendre service à ses utilisateurs. Il faut se placer du point de vue de chaque type d’utilisateur (au sens acteur) et identifier les cas d’utilisation qui lui permettront de faire son travail. Il est donc indispensable de savoir quels sont les utilisateurs du système à produire. Il ne faut pas se mettre à identifier les fonctions du système sans se poser la question de savoir quels sont ceux qui les utiliseront. Cela conduit généralement à l’identification des cas inutiles ou superflus.
2. dirigent le processus : ils aident les chefs de projets à planifier, affecter et surveiller les tâches effectuées par les développeurs.
3. constituent un mécanisme essentiel de traçabilité entre modèles : il est possible de suivre l’évolution d’un cas d’utilisation de la phase d’analyse à sa réalisation et à travers les cas de test qui en assurent la vérification. Cette traçabilité permet de préserver la cohérence du système et de l’actualiser dans son ensemble en fonction de l’évolution des besoins.
4. servent de guide pour les besoins non fonctionnels : A tout besoin fonctionnel, délimité sous forme de cas d’utilisation, peut être associé une grande partie de besoins non fonctionnels (performance, disponibilité, sécurité, …).
IV.3.2. Réalisation des cas d’utilisation
Des cas d’utilisation au modèle d’analyse
Le modèle d’analyse a pour rôle de clarifier en fournissant une spécification détaillée des cas d’utilisation. Il permet une meilleure compréhension de ceux-ci. Il consiste en :
1. une étude/description détaillée des cas d’utilisation l’un après l’autre ;
2. une identification des classificateurs (ainsi que leurs rôles et relations) intervenant dans la réalisation de chaque cas d’utilisation étudié/décrit ;
3. la représentation de la collaboration entre les classes identifiées, chacun jouant effectivement son ou ses rôles.
Le modèle d’analyse tient lieu de première ébauche du modèle de conception, tout en étant un modèle à part entière. La figure ci-dessous illustre la traçabilité entre un cas d’utilisation et sa réalisation dans le modèle d’analyse.
La réalisation d’un cas d’utilisation est représentée par une ellipse en pointillées.
Du modèle d’analyse au modèle de conception
Le modèle de conception est conçu en vue de l’implémentation. Il est ainsi plus proche du modèle d’implémentation. Toutefois, il est d’abord crée à partir du modèle d’analyse avant d’être adapté à l’environnement d’implémentation choisi. A l’instar du modèle d’analyse, le modèle de conception définit les relations entre les classificateurs et les collaborations réalisant les cas d’utilisation. Les
éléments définis dans le modèle de conception sont les équivalents des éléments plus conceptuels spécifiés dans le modèle d’analyse. Les éléments du modèle de conception sont plus « physique » (adaptés à l’environnement d’implémentation) alors que ceux du modèle d’analyse sont plus « conceptuel ».
La réalisation des cas d’utilisation dans les différents modèles obéissent à plusieurs objectifs. Les différentes classes participants à la réalisation d’un cas d’utilisation dans le modèle d’analyse donnent
lieu à des classes de conception plus sophistiquées, adaptées à l’environnement d’implémentation.
Toutefois, la traçabilité permet de remonter des classes de conception du modèle de conception vers les classes d’analyse du modèle d’analyse. On doit ainsi savoir quelles classes d’analyse participent à la réalisation de quel cas d’utilisation, et quelles classes de conception correspondent à quelle classe d’analyse pour la réalisation de quel cas d’utilisation.
……

Sommaire: Cours génie logiciel les principaux enchaînements d’activités

Notes Importantes
Chapitre I . Introduction au Génie Logiciel
I.1. Définition
I.2. Les objectifs du GL
I.3. Les difficultés du GL
I.4. Les logiciels et métiers du GL
I.5. La qualité du logiciel ?
Chapitre II . Les modèles classiques de cycle de vie
II.1. Introduction
II.2. Modèle en cascade
II.3. Modèle en V
II.4. Modèle incrémental
II.5. Modèle en spirale
Chapitre III . Introduction au processus de développement
III.1. Définition
III.2. Historique du processus unifié
III.3. Instances du Processus Unifié
Chapitre IV . Le Processus Unifié
IV.1. Introduction
IV.2. La vie du Processus Unifié
IV.2.1. Axe horizontal
IV.2.2. Axe vertical
IV.3. Processus piloté par les cas d’utilisation
IV.3.1. Intérêt des cas d’utilisation
IV.3.2. Réalisation des cas d’utilisation
IV.4. Processus centré sur l’architecture
IV.4.1. Intérêt de l’architecture
IV.4.2. Architecture et cas d’utilisation
IV.4.3. Construction de l’architecture
IV.5. Processus itératif et incrémental
IV.5.1. C’est quoi itératif et incrémental ?
IV.5.2. Intérêt du développement itératif et incrémental
IV.5.3. La réduction des risques
Chapitre V . Les principaux enchaînements d’activités
V.1. Compréhension du contexte du système
V.2. Expression des besoins
V.2.1. Présentation
V.2.2. Les artefacts
V.2.3. Les travailleurs
V.2.4. Enchaînement d’activités
V.3. Analyse
V.3.1. Présentation
V.3.2. Artefacts
V.3.3. Travailleurs
V.3.4. Enchaînement d’activités
V.4. Conception
V.4.1. Présentation
V.4.2. Artefacts
V.4.3. Travailleurs
V.4.4. Enchaînement d’activités
V.5. Implémentation
V.5.1. Présentation
V.5.2. Artefacts
V.5.3. Travailleurs
V.5.4. Enchaînement d’activités
V.6. Tests
V.6.1. Présentation
V.6.2. Artefacts
V.6.3. Travailleurs
V.6.4. Enchaînement d’activités
V.7. Conclusion

Si le lien ne fonctionne pas correctement, veuillez nous contacter (mentionner le lien dans votre message)
Cours génie logiciel les principaux enchaînements d’activités (1,17 MO) (Cours PDF)