Artefact :
|
![]() |
Les classes d'analyse représentent un modèle conceptuel préliminaire pour des éléments du système dotés de responsabilités et de comportements'. |
Autres relations : |
Partie de Modèle d'analyse
|
---|---|
Rôle : | Concepteur |
Caractère facultatif/Occurrence: | Facultatif. Phases d'élaboration et de construction. |
Canevas et rapports : |
|
Exemples : | |
Représentation UML : | Classe, stéréotypée en tant que <<limite>>, <<entité>> ou <<contrôle>>. |
Informations supplémentaires : | |
Entrée d'activités : | Sortie d'activités : |
Les classes d'analyse sont utilisées pour recenser les principaux "blocs de responsabilités" dans le système. Elles représentent les classes prototypes du système et permettent une première appréhension des abstractions majeures que le système devra gérer. Les classes d'analyse peuvent aussi être constituées pour elles-mêmes, lorsqu'un aperçu conceptuel de "haut niveau" du système est désiré. Elles engendrent également les abstractions majeures de la conception du système, à savoir ses classes de conception et ses sous-systèmes.
Nom de la propriété |
Brève description |
Représentation UML |
---|---|---|
nom | nom de la classe | attribut |
description | brève description du rôle de la classe dans le système | attribut |
responsabilités | liste des responsabilités de la classe | attribut |
attributs | attributs de la classe | attribut |
Les classes d'analyse sont identifiées essentiellement au cours de la phase d'élaboration, lors de l'analyse des cas d'utilisation. Certaines peuvent ne pas être déterminées avant la phase de construction (si des cas d'utilisation ne sont analysés qu'à ce stade).
Un concepteur est responsable de l'intégrité de la classe d'analyse et doit s'assurer que :
Les classes d'analyse, considérées dans leur ensemble, représentent un modèle conceptuel préliminaire du système. Ce modèle évolue rapidement, tout en restant fluide pendant un certain temps, lors de l'exploration de diverses représentations et de leurs implications. Une documentation formelle peut entraver ce processus. Prenez donc soin de ne pas consacrer trop d'efforts à la maintenance formelle de ce 'modèle', ou à le peaufiner, puisqu'il est en grande partie éphémère. Les classes d'analyse parviennent rarement jusqu'à la conception définitive sans avoir subi des modifications. Beaucoup d'entre-elles représentent des collaborations complètes d'objets, souvent encapsulées par des sous-systèmes.
Généralement, de simples cartes de notes, comme dans l'exemple ci-dessous, suffisent (basées sur la technique bien connue dénommée CRC Card - Voir [WIR90] pour plus d'informations sur cette technique). Au recto de la carte, indiquez le nom et la description de la classe. Un exemple pour la classe Cours dans un système d'inscription à des cours est fourni ci-dessous :
Nom de la classe | Cours | |||||||||
---|---|---|---|---|---|---|---|---|---|---|
Description | La classe Cours est chargée de conserver des informations portant sur un ensemble de cours avec un sujet, des exigences et un programme communs. | |||||||||
Responsabilités | Conservation d'informations sur le cours. | |||||||||
Attributs |
|
Au verso de la carte, tracez un diagramme de la classe :
Diagramme de la classe Cours
Une carte de classe d'analyse correspond à chaque classe détectée au cours de l'atelier d'analyse de cas d'utilisation.
RUP (Rational Unified Process)
|