UML
Chapitre 1. Introduction
Chapitre 2. Les concepts objets
Chapitre 3. La conception d'un système
Chapitre 4. Le modèle fonctionnel
Chapitre 5. Le modèle statique
Chapitre 6. Le modèle dynamique
Chapitre 7. UML et la gestion de projet
7.1. UML et les processus de développement
7.2. UML et les processus de développement unifiés
7.3. Importance des cas d'utilisation dans le processus de développement
7.4. Les deux étapes de l'analyse des besoins et de l'analyse
7.5. Les différentes vues de l'architecture d'un projet
7.6. Résumé méthodologique
Chapitre 8. La phase de conception
Chapitre 9. Modèles d'implémentation
Exercices
Page d'accueilTable des matièresNiveau supérieurPage précédenteBas de la pagePage suivanteWebographie du moduleGlossaire du module

7.4. Les deux étapes de l'analyse des besoins et de l'analyse

Description des cas d'utilisation :

Dans l'analyse des besoins, les cas d'utilisation doivent être décrits sous forme textuelles agrémentées de quelques diagrammes d'interactions.
A ce stade : interaction = évènement.
Plus tard : évènement = message = déclenchement d'une opération.

Ensuite, on identifie les acteurs. Un cas d'utilisation doit déterminer ce que chaque acteur attend du système. On considère les cas d'utilisation un par un (vu par un acteur à la fois), on trace le diagramme de collaboration associé dans lequel sont impliqués quelques objets (soit ceux de l'interface, soit ceux du domaine).
De ce diagramme, peut émerger un diagramme de classe, et si on s'intéresse à un objet particulier on modélise ses différents états grâce au diagramme état-transition.

En déroulant ce procédé pour tous les scénarios, les modèles de classes s'enrichissent. Ceci nous donne une segmentation de l'espace des besoins. Cette description est purement fonctionnelle. Il convient de ne pas s'appuyer uniquement sur ces cas d'utilisation au risque d'embrayer vers une décomposition fonctionnelle plutôt que vers une décomposition objet. Les diagrammes de classes qui ont été ébauchés dans l'étape "Analyse des besoins" vont être raffinés (on supprime la redondance).

L'étude de l'existant permet de mieux comprendre les comportements et les relations entre classes.
Les objets métiers sont regroupés dans un paquetage Domaine. Les composants miroirs de ces objets du domaine sont contenus dans le paquetage IHM. La couche la plus basse comprend la catégorie "Persistance" qui encapsule une base de données.


Les 3 étapes et UML

- Dans les activités de spécification des exigences, il convient d'abord de considérer le système comme une boîte noire à part entière afin d'étudier sa place dans le système métier global qu'est l'entreprise. On développe dans ce cas un modèle de niveau contexte qui précise les frontières fonctionnelles du futur système.

- Dans les activités d'analyse, le modèle commence à représenter le système vu de l'intérieur. Il se compose d'objets représentant une abstraction des concepts manipulés par les utilisateurs (de type statique et dynamique).

- Dans les activités de conception, le modèle correspond aux concepts informatiques utilisés par les outils, les langages ou les plates-formes de développement. Le modèle sert ici à, étudier, documenter, communiquer et à anticiper une solution.

Page d'accueilTable des matièresNiveau supérieurPage précédenteHaut de la pagePage suivanteWebographie du moduleGlossaire du module