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 :   

Objet Haut de la page

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.

Propriétés Haut de la page

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 

Calendrier Haut de la page

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).

Responsabilité Haut de la page

Un concepteur est responsable de l'intégrité de la classe d'analyse et doit s'assurer que :

  • Elle est complète et cohérente sur le plan logique.
  • Toutes ses informations (voir propriétés ci-dessus) ont été répertoriées et sont correctes.

Personnalisation Haut de la page

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
Nom Description Type
Titre du cours Nom du cours chaîne
Description Brève description du cours chaîne

Au verso de la carte, tracez un diagramme de la classe :

Diagramme de la classe Cours

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)   2003.06.15