Artefact :
|
![]() |
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 : |
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.
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. | -" - |
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.
L'architecte logiciel est responsable de l'intégrité du modèle d'analyse et doit s'assurer que :
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 :
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)
|