Options de représentation |
Représentation UML : Modèle, stéréotypé comme un <<modèle d'analyse>>.
Un modèle d'analyse peut avoir les propriétés suivantes :
-
Introduction : Description textuelle servant de brève introduction au modèle.
-
Packages d'analyse : Packages contenus dans le modèle, représentant une hiérarchie.
-
Classes : Classes contenues dans le modèle, appartenant aux packages.
-
Relations : Relations contenues dans le modèle, appartenant aux packages.
-
Réalisations de cas d'utilisation : Réalisations de cas d'utilisation contenues dans le modèle,
appartenant aux packages.
-
Diagrammes : Diagrammes contenus dans le modèle, appartenant aux packages.
Généralement, les "classes d'analyse" se transforment directement en éléments dans le modèle de conception : certains
deviennent des classes de conception, d'autres des sous-systèmes de conception. Le but de l'Analyse est d'identifier un
mappage préliminaire du comportement requis vers des éléments de modélisation dans le système. Le but de la Conception
est de transformer ce mappage préliminaire (quelque peu idéalisé) en un ensemble d'éléments de modèle qui peuvent être
implémentés. Ainsi, le passage de l'Analyse à la Conception implique davantage de détails et de précisions. Par
conséquent, les "classes d'analyse" sont souvent plus vagues, et évoluent énormément avant de se stabiliser dans le
cadre des activités de conception.
Points à prendre en compte pour déterminer si un modèle d'analyse séparé est nécessaire :
-
Un modèle d'analyse séparé est utile si le système doit être conçu pour de multiples environnements cible, avec des
architectures de conception différentes. Le modèle d'analyse est une abstraction, ou une généralisation, du modèle
de conception. Il omet volontairement tous les détails de la conception pour fournir une vue d'ensemble des
fonctionnalités du système.
-
La conception est tellement complexe qu'une "conception" abstraite et simplifiée est nécessaire pour présenter le
projet aux nouveaux membres de l'équipe. Encore une fois, une architecture bien définie peut remplir la même
fonction.
-
Le travail supplémentaire nécessaire pour s'assurer que les modèles Analyse et Conception restent cohérents doit
être évalué par rapport à l'avantage de disposer d'une vue du système qui représente uniquement les points les plus
importants sur ses fonctionnalités. Une cohérence parfaite entre le modèle d'analyse et le modèle de conception
peut engendrer des coûts importants. Une approche plus raisonnable pourrait consister à gérer le modèle d'analyse,
avec uniquement les principales classes de domaine et abstractions de la conception. Plus le modèle d'analyse
devient complexe, plus les coûts nécessaires à sa gestion augmentent.
-
En outre, une fois que le modèle d'analyse n'est plus tenu à jour, sa valeur décline rapidement. A un certain
stade, il perd même toute utilité dans la mesure où il ne reflète plus avec exactitude la conception actuelle du
système. Il peut être judicieux de cesser de mettre à jour le modèle d'analyse (s'il n'est plus utile), mais c'est
une décision qui doit être prise en toute connaissance de cause.
Dans certaines entreprises qui ont des systèmes pouvant perdurer pendant des décennies ou des systèmes comptant de
nombreuses variantes, le choix de conserver un modèle d'analyse séparé s'est avéré judicieux.
|