Produit: Modèle d'analyse
Ce produit définit un modèle d'objets qui décrit la réalisation des cas d'utilisation et qui sert d'abstraction au modèle de conception.
Objet

Le modèle d'analyse contient les classes d'analyse et les produits associés. Le modèle d'analyse peut être un produit temporaire, comme dans les cas où il devient un modèle de conception ; ou il peut être conservé tout au long du projet, parfois même après le projet, en servant d'aperçu conceptuel du système.

Relations
RôlesResponsable: Modifié par:
Entrée versObligatoire: Facultatif:
  • Aucun
Externe:
  • Aucun
Sortie de
Description principale
Le modèle d'analyse définit un modèle d'objets qui décrit la réalisation des cas d'utilisation et qui sert d'abstraction au Produit : modèle de conception . Le modèle d'analyse contient les résultats des analyses de cas d'utilisation, les instances de Produit : classe d'analyse.
Propriétés
Facultatif
PlanifiéYes
Illustrations
Personnalisation
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.



Plus d'informations