Modèle d'objet décrivant la réalisation des cas d'utilisation, abstraction de l'Artefact : Modèle de conception. Le modèle d'analyse contient les résultats de l'analyse des cas d'utilisation, instances de l' Artefact : Classe d'analyse.
Autres relations :  Contient
Rôle :  Architecte logiciel 
Caractère facultatif/Occurrence:  Facultatif. Phases d'élaboration et de construction.
Canevas et rapports : 
     
Exemples : 
     
Représentation UML :  Modèle, stéréotypé en tant que <<modèle d'analyse>>. 
Informations supplémentaires :   
Entrée d'activités :    Sortie d'activités :   

Objet Haut de la page

Le modèle d'analyse contient les classes d'analyse et leurs éventuels artefacts associés. Il peut s'agir d'un artefact temporaire, comme c'est le cas lorsqu'il évolue pour donner un modèle de conception, ou persister pendant une partie du projet, voire même au delà, pour fournir un aperçu conceptuel du système.

Propriétés Haut de la page

Nom de la propriété 

Brève description 

Représentation UML 

Introduction  Description textuelle servant de brève introduction au modèle.  Valeur marquée, de type "texte court". 
Packages d'analyse  Packages contenus dans le modèle, représentant une hiérarchie.  Appartenance via l'association "représente", ou récursivement via l'agrégation "propriétaire de". 
Classes  Classes du modèle, appartiennent aux packages.  Appartenance récursive via l'agrégation "propriétaire de". 
Relations  Relations dans le modèle, appartiennent aux packages.  -" - 
Réalisations de cas d'utilisation  Réalisations des cas d'utilisation du modèle, appartiennent aux packages.  -" - 
Diagrammes  Diagrammes du modèle, appartiennent aux packages.  -" - 

Calendrier Haut de la page

Le modèle d'analyse est créé lors de la phase d'élaboration et mis à jour lors de la phase de construction lorsque la structure du modèle est actualisée.

Responsabilité Haut de la page

L'architecte logiciel est responsable de l'intégrité du modèle d'analyse et doit s'assurer que :

  • Il est mis à jour de sorte à refléter un aperçu abstrait de la conception.

Personnalisation Haut de la page

Normalement, les "classes d'analyse" évoluent directement pour devenir des éléments du modèle de conception : certaines donnent des classes de conception, d'autres des sous-systèmes de conception. L'objet de l'analyse est d'identifier un mappage préliminaire de comportement requis sur des éléments de modélisation du système. L'objet de la conception est de transformer ce mappage préliminaire (et parfois idéalisé) en un ensemble d'éléments du modèle pouvant être implémentés. Par conséquent, le niveau de détail et de précision augmente avec le passage de l'analyse à la conception. Ainsi, les "classes d'analyse" sont souvent assez fluides, modifiables et évoluent considérablement avant d'être figées dans les 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é peut être utile lorsque le système doit être conçu pour des environnements cibles multiples, avec des architectures de conception distinctes. Le modèle d'analyse constitue une abstraction, ou une généralisation, du modèle de conception. Il omet la plupart des détails de la conception afin de fournir un aperçu de la fonctionnalité du système.
  • La conception est complexe, au point où une "conception" simplifiée et abstraite doit être présentée aux nouveaux membres de l'équipe. Ici aussi, une architecture bien définie peut remplir le même objet.
  • Le travail supplémentaire requis pour assurer la cohérence des modèles d'analyse et de conception doit être compensé par l'avantage de disposer d'une vue du système où seuls les aspects les plus importants de son opération sont représentés. Il peut être très coûteux de maintenir un niveau de fidélité élevé entre les deux modèles. Une approche moins ambitieuse peut se contenter de maintenir le modèle d'analyse avec seulement les classes les plus importantes du domaine et les abstractions clés de la conception. Le coût de la maintenance du modèle d'analyse croît avec sa complexité.
  • Dès lors que la maintenance du modèle d'analyse n'est plus assurée, sa valeur fond rapidement. A un certain point, il ne présente plus d'utilité puisqu'il ne reflète plus la conception actuelle du système. La décision d'abandonner la maintenance du modèle d'analyse peut être judicieuse (dans la mesure où il a rempli son but), mais cette décision doit être délibérée.

Dans certaines entreprises où les systèmes peuvent subsister pendant des décennies, ou bien où de nombreuses variantes coexistent, un modèle d'analyse séparé s'est avéré utile.



RUP (Rational Unified Process)   2003.06.15