Objet
  • Identifier les classes effectuant le flot d'événements d'un cas d'utilisation
  • Distribuer le comportement de cas d'utilisation à ces classes en utilisant les réalisations de cas d'utilisation d'analyse
  • Identifier les responsabilités, les attributs et les associations des classes
  • Noter l'utilisation de mécanismes architecturaux
Rôle :  Concepteur 
Fréquence : Une fois par itération, pour un ensemble de cas d'utilisation et/ou de scénarios de cas d'utilisation (cas développés dans l'itération actuelle). 
Etapes

Les tâches suivantes sont effectuées pour chaque cas d'utilisation de l'itération actuelle :

Les tâches suivantes sont effectuées une fois par itération :

Commentaire : Les étapes ci-dessus sont présentées dans un ordre logique, mais vous devrez peut-être les effectuer en alternance ou exécuter certaines d'entre elles en parallèle.

Artefacts d'entrée :    Artefacts de sortie :   
Guides d'utilisation de l'outil :   
Plus d'informations : 

Détails de l'enchaînement des activités :   

Créer une réalisation de cas d'utilisation d'analyse Haut de la page

Objet Créer l'élément de modélisation utilisé pour exprimer le comportement du cas d'utilisation. 

Les cas d'utilisation représentent le point d'intérêt central des premières tâches d'analyse et de conception. Pour permettre la transition entre les activités orientées vers les exigences et les activités orientées vers l'analyse et la conception, l'Artefact : Réalisation de cas d'utilisation sert de passerelle, donnant la possibilité de suivre le comportement des modèles d'analyse et de conception jusqu'au modèle de cas d'utilisation, ainsi que de mettre en place des collaborations autour du concept de cas d'utilisation.

Si aucune n'est disponible, créez une réalisation de cas d'utilisation d'analyse dans le modèle d'analyse pour le cas d'utilisation.  Le nom de la réalisation de cas d'utilisation d'analyse doit être le même que le cas d'utilisation associé, et une relation de "réalisation" doit être établie de la réalisation de cas d'utilisation d'analyse à son cas d'utilisation associé.

Pour plus d'informations sur les réalisations de cas d'utilisation, voir Principes et conseils : Réalisation de cas d'utilisation.

Compléter la description du cas d'utilisation Haut de la page

Objet Consigner les informations supplémentaires nécessaires afin de comprendre le comportement interne requis du système qui pourrait ne pas figurer dans la description du cas d'utilisation écrite pour le client du système. 

La description de chaque cas d'utilisation ne suffit pas toujours pour identifier les classes d'analyse et leurs objets. Le client n'est souvent pas intéressé par les informations concernant ce qui se passe à l'intérieur du système, donc les descriptions de cas d'utilisation ne traiteront généralement pas ces informations. Dans ce cas, la description de cas d'utilisation se lit comme une description de "boîte noire", dans laquelle les détails internes de la réponse du système par rapport aux actions d'un acteur sont absentes ou décrites très rapidement. Pour trouver les objets qui exécutent le cas d'utilisation, vous devez avoir la description "structurelle" de ce que le système fait d'un point de vue interne.

Exemple

Dans le cas d'un distributeur de billets, le client du système peut préférer dire que

    "Le distributeur valide la carte du client de la banque."

pour décrire le comportement d'authentification de l'utilisateur par le système. Cela peut suffire au client, mais cela ne nous donne pas d'idée précise sur ce qui se passe concrètement dans le distributeur pour valider la carte.

Pour obtenir une présentation interne de la façon dont le système fonctionne, à un niveau de détail suffisant pour identifier des objets, nous aurons peut-être besoin d'informations supplémentaires. En prenant comme exemple l'activité de validation de carte du distributeur, la description étendue serait la suivante :

    "Le distributeur envoie le numéro de compte du client et son code au réseau de distributeurs afin qu'ils soient validés. Le réseau de distributeurs renvoie un message positif si le numéro de client et le code correspondent et si le client est autorisé à effectuer des transactions, sinon le réseau de distributeurs renvoie un message d'échec."

Ce niveau de détails donne une idée claire du type d'information nécessaire (numéro de compte et code) et de qui est responsable de l'authentification (le réseau de distributeurs de billets, un acteur du modèle de cas d'utilisation). A partir de ces informations, nous pouvons identifier deux objets potentiels (un objet client, avec des attributs de numéro de compte et de code, et une interface de réseau de distributeurs de billets) ainsi que leurs responsabilités.

Examinez la description du cas d'utilisation pour voir si le comportement interne du système est clairement défini. Le comportement interne du système ne doit pas être ambigu, pour que l'action du système soit claire. Il n'est pas nécessaire de définir les éléments qui, à l'intérieur du système (les objets), sont responsables de l'exécution de ce comportement - il suffit d'une définition claire de ce qui doit être fait.

Les sources d'information pour ce détail incluent les experts du domaine qui peuvent aider à définir ce que le système doit faire. Une bonne question à se poser, lorsqu'on considère un comportement spécifique du système est "que signifie cette action pour le système ?". Si l'action accomplie par le système pour exécuter ce comportement n'est pas assez bien définie pour répondre à cette question, il est probablement nécessaire d'obtenir plus d'informations.

Vous trouverez ci-dessous des alternatives pour compléter la description du flot d'événements :

  • Ne pas le décrire du tout. Cela peut être le cas si vous pensez que les diagrammes d'interaction sont suffisamment explicites ou si le flot d'événements du cas d'utilisation correspondant fournit une description suffisante.
  • Compléter la description existante du flot d'événements. Ajoutez des descriptions supplémentaires au flot d'événements dans les domaines dans lesquels les textes existants ne sont pas assez clairs par rapport aux actions devant être effectuées par le système.
  • Le décrire comme flot textuel complet, indépendant de la description "externe" du flot des événements du cas d'utilisation. Cette approche est adaptée dans les cas où le comportement interne du système est très éloigné du comportement externe du système. Dans ce cas, une description complètement indépendante, associée à la réalisation du cas d'utilisation d'analyse plutôt qu'au cas d'utilisation, est justifiée.

Trouver les classes d'analyse à partir du comportement de cas d'utilisation Haut de la page

Objet Identifier un ensemble potentiel d'éléments de modèle (classes d'analyse) qui pourront effectuer le comportement décrit dans les cas d'utilisation. 

Trouver un ensemble potentiel de classes d'analyse est la première étape de la transformation du système d'une simple déclaration de comportement requis à une description de la manière dont le système fonctionnera. Dans cet effort, les classes d'analyse sont utilisées pour représenter les rôles d'éléments de modèle fournissant le comportement nécessaire pour répondre aux exigences fonctionnelles définies par les cas d'utilisation et les exigences non-fonctionnelles définies par les exigences supplémentaires. Alors que l'intérêt principal du projet devient la conception, ces rôles deviennent un ensemble d'éléments de conception réalisant les cas d'utilisation.

Les rôles identifiés dans l'analyse de cas d'utilisation expriment principalement le comportement des couches supérieures du système - le comportement relatif à l'application et relatif au domaine. Les classes liées aux limites et au contrôle deviennent généralement des éléments de conception de couche application, alors que les classes d'entité deviennent des éléments de conceptions relatifs au domaine. L'élément de conception de la couche inférieure évolue généralement à partir des mécanismes d'analyse utilisés par les classes d'analyse identifiées ici.

La technique décrite ici utilise trois points de vue du système différents pour permettre l'identification de classes potentielles. Les trois perspectives sont les frontières entre le système et ses acteurs, les informations utilisées par le système, et la logique de contrôle du système. Les stéréotypes, frontières, entités et contrôles de classe correspondants sont utilisés pour plus de commodité pendant l'analyse et disparaissent dans la conception.

L'identification des classes signifie précisément cela : elles doivent être identifiées, nommées, et décrites brièvement en quelques phrases.

Pour plus d'informations sur l'identification des classes d'analyse, voir Principes et conseils : Classe d'analyse. Pour plus d'informations sur les réalisations de cas d'utilisation d'analyse, voir Principes et conseils : Réalisation de cas d'utilisation.

Si des mécanismes d'analyse et/ou des modèles d'analyse spécifiques ont été documentés dans les recommandations relatives au projet, ils doivent être utilisés comme autre source d'"inspiration" pour les classes d'analyse.

Distribuer le comportement aux classes d'analyse Haut de la page

Objet Exprimer le comportement du cas d'utilisation en terme de classes d'analyse en collaboration. Déterminer les responsabilités des classes d'analyse. 

Pour chaque sous-flot (scénario) indépendant :

  • Créer un ou plusieurs diagrammes d'interactions (de communication ou de fonctionnement). Au moins un diagramme est généralement nécessaire pour le flot principal d'événements du cas d'utilisation, ainsi qu'au moins un diagramme pour chaque flot alternatif/exceptionnel. Des diagrammes séparés sont généralement nécessaires pour les sous-flots possédant des caractéristiques complexes en terme de délais ou de décision ou pour simplifier les flots complexes qui sont trop longs pour être facilement inclus dans un diagramme.
  • Identifier les classes d'analyse responsables du comportement requis en examinant l'ensemble du flot d'événements du scénario afin de s'assurer que tous les comportements requis par le cas d'utilisation sont fournis par la réalisation des cas d'utilisation d'analyse.
  • Illustrer les interactions entre les classes d'analyse et le diagramme d'interaction. Le diagramme d'interaction doit également montrer les interactions du système avec ses acteurs (les interactions doivent commencer avec un acteur, car c'est toujours un acteur qui appelle le cas d'utilisation).
  • Inclure des classes représentant les classes de contrôle des cas d'utilisation utilisés. (Utiliser un diagramme d'interaction séparé pour chaque cas d'utilisation d'extension, montrant uniquement le changement de comportement du cas d'utilisation d'extension.)

exemple de diagramme de communication

Un diagramme de communication pour le cas d'utilisation Recevoir un article de stock.

Si des mécanismes et/ou des modèles d'analyse spécifiques ont été documentés dans les recommandations relatives au projet, ils doivent se répercuter dans l'attribution de la responsabilité et les diagrammes d'interaction qui en découlent.

Décrire les responsabilités Haut de la page

Objet Décrire les responsabilités d'une classe d'objets identifiée à partir du comportement de cas d'utilisation. 

Une responsabilité est une déclaration d'une action que l'on peut demander d'un objet. Les responsabilités évoluent en une (ou généralement plusieurs) opérations sur des classes lors de la conception ; elles peuvent désigner :

  • les actions pouvant être effectuées par l'objet
  • les connaissances maintenues par un objet et qu'il transmet aux autres objets

Chaque classe d'analyse doit avoir plusieurs responsabilités ; une classe n'ayant qu'une responsabilité est probablement trop simple, alors qu'une en possédant une douzaine ou plus n'est pas recommandée et doit éventuellement être séparée en plusieurs classes.

Il est évident que tous les objets peuvent être créés et supprimés ; inutile d'enfoncer des portes ouvertes sur ce point à moins que l'objet n'effectue un comportement particulier lors de sa création ou de sa suppression. (Certains objets ne peuvent pas être supprimés si certaines relations existent.)

Identifier les responsabilités

Les responsabilités sont extraites de messages dans les diagrammes d'interaction. Pour chaque message, examinez la classe de l'objet à laquelle celui-ci est envoyé. Si la responsabilité n'existe pas encore, créez une nouvelle responsabilité procurant le comportement requis.

D'autres responsabilités découleront d'exigences non-fonctionnelles. Lorsque vous créez une nouvelle responsabilité, vérifiez les exigences non-fonctionnelles pour voir s'il existe des exigences associées pouvant s'appliquer. Développez la description de la responsabilité ou bien créez une nouvelle responsabilité pour traduire cela.

Documenter les responsabilités

Les responsabilités sont documentées à l'aide d'un nom court (quelques mots maximum) et d'une description courte (quelques phrases maximum). La description explique ce que l'objet fait pour réaliser la responsabilité, et le résultat renvoyé lorsque la responsabilité est appelée.

Décrire les attributs et les associations Haut de la page

Objet Définir les autres classes dont dépend la classe d'analyse.
Définir les événements des autres classes d'analyse que la classe doit connaître.
Définir les informations que la classe d'analyse doit maintenir. 

Afin de mener à bien leurs responsabilités, les classes dépendent fréquemment d'autres classes qui doivent fournir le comportement requis. Les associations documentent les relations inter-classes et nous aident à comprendre le regroupement de classes ; une meilleure compréhension d'un regroupement de classes, et une limitation de celui-ci si possible, peut nous aider à construire un meilleur système, plus souple.

Les étapes suivantes définissent les attributs des classes et les associations entre les classes :

Définir des attributsHaut de la page

Les attributs sont utilisés par une classe pour stocker des informations. Les attributs sont utilisés plus particulièrement lorsque l'information est :

  • Référencée par "valeur"; c'est-à-dire que l'élément important est seulement la valeur de l'information et non son emplacement ou son identifiant objet.
  • La "propriété" seule de l'objet auquel elle appartient ; aucun autre objet ne fait référence à l'information.
  • Accessible par des opérations qui se contentent d'obtenir, de définir ou d'effectuer de simples transformations sur l'information : l'information n'a pas de "véritable" comportement outre le fait de fournir une valeur.

Si, par contre, l'information a un comportement complexe, est partagée par deux objets ou plus ou est transmise "par référence" entre deux objets ou plus, l'information doit être modélisée en tant que classe séparée.

Le nom d'attribut doit être un nom exprimant clairement le type d'information contenu par cet attribut.

La description de l'attribut doit décrire les informations stockées dans l'attribut ; cela peut être optionnel lorsque l'information stockée est évidente à partir du nom d'attribut.

Le type d'attribut est le simple type de données de l'attribut. Exemples : chaîne, nombre entier ou nombre.

Etablir des associations entre les classes d'analyse Haut de la page

Commencez par examiner les liens dans les diagrammes d'interaction produits dans Distribuer le comportement aux classes d'analyse. Les liens entre les classes indiquent que les objets des deux classes doivent communiquer ensemble afin d'exécuter le cas d'utilisation. Une fois la conception du système débutée, ces liens peuvent être réalisés de diverses manières :

  • L'objet peut avoir une portée "globale" et dans ce cas tout objet du système peut lui envoyer des messages
  • Un objet peut se voir transmettre le second objet comme paramètre, à la suite de quoi il peut envoyer des messages à cet objet transmis.
  • L'objet peut être associé de façon permanente à l'objet auquel les messages sont envoyés.
  • L'objet peut être créé et détruit dans le cadre de l'opération (c'est-à-dire un objet "temporaire") - ces objets sont considérés comme "locaux" par rapport à l'opération.

A ce stade peu avancé de la "vie" de la classe, il est néanmoins trop tôt pour commencer à prendre ces décisions : nous ne possédons pas assez d'informations pour prendre des décisions éclairées. Nous créons donc, pendant l'analyse, des associations et des agrégations pour représenter (et "transporter") tous les messages devant être envoyés entre les objets de deux classes. (L'agrégation, une forme spécifique d'association, indique que les objets participent à une relation "tout/partie" (voir Principes et conseils : Association et Principes et conseils : Agrégation).

Nous préciserons ces associations et ces agrégations dans l'Activité : Conception de classe.

Pour chaque classe, dessinez un diagramme de classe montrant les associations que chaque classe possède avec d'autres classes :

exemple de diagramme de classe, montrant les associations et les agrégations

Exemple de diagramme de classe d'analyse pour une partie du système de saisie des commandes

Concentrez-vous uniquement sur les associations nécessaires pour réaliser les cas d'utilisation ; n'ajoutez pas d'associations qui selon vous "pourraient" exister à moins qu'elles ne soient nécessaires d'après les diagrammes d'interaction.

Attribuez aux associations des noms de rôles et des multiplicités.

  • Un nom de rôle doit être un nom exprimant le rôle que l'objet associé joue par rapport à l'objet associant.
  • Supposez une multiplicité de 0..* (zéro à plusieurs) à moins que vous ne possédiez une preuve claire d'un cas contraire. Une multiplicité de zéro implique que l'association est optionnelle : assurez-vous que c'est bien le cas ; si un objet peut ne pas être présent, les opérations qui utilisent l'association devront s'adapter en conséquence.
  • Des limites plus restreintes de multiplicité peuvent être définies (comme 3..8).
  • A l'intérieur des fourchettes de multiplicité, vous pouvez définir des probabilités. Ainsi, si la multiplicité de 0..*, est prévue entre 10 et 20 dans 85 % des cas, notez-le ; cette information sera cruciale pendant la conception. Par exemple, si un stockage permanent être implémenté en utilisant une base de données relationnelle, des limites plus restreintes faciliteront l'organisation des tables de la base de données.

Rédigez une brève description de l'association pour indiquer comment celle-ci est utilisée ou quelles relations l'association représente.

Décrire les dépendances d'événement entre les classes d'analyseHaut de la page

Les objets doivent parfois savoir quand un événement a lieu dans un objet "cible" donné, sans que la "cible" ne connaisse tous les objets qui doivent être notifiés du moment où l'événement a lieu. Une commande abrégée permet de montrer cette dépendance de notification d'événement ; il s'agit d'une association d'abonnement qui vous permet d'exprimer cette dépendance d'une manière compacte et concise.

Une association de souscription entre deux objets indique que l'objet abonneur sera informé lorsqu'un événement spécifique aura lieu dans l'objet abonné. Une association d'abonnement possède une condition définissant l'événement qui entraîne la notification de l'abonneur. Pour plus d'informations, voir Principes et conseils : Association d'abonnement.

Les conditions de l'association d'abonnement doivent être exprimées en terme de résumé de caractéristiques plutôt que selon ses attributs ou fonctionnements spécifiques. Ainsi, l'objet associant reste indépendant du contenu de l'objet d'entité associé, qui peut très bien changer.

Une association d'abonnement est requise :

  • si un objet est influencé par un événement ayant lieu dans un autre objet
  • si un nouvel objet doit être créé pour se charger d'un événement ; par exemple, lorsqu'une erreur se produit, une nouvelle fenêtre doit être créée pour notifier l'utilisateur
  • si un objet doit être informé lorsqu'un autre objet est instancié, changé ou détruit

Les objets qui sont "abonnés" sont généralement des objets d'entité. Les objets d'entité sont souvent des banques d'information passives, dont les comportements sont généralement liés à leurs responsabilités de stockage d'information. De nombreux autres objets doivent être informés lorsque les objets d'entité changent. L'association d'abonnement évite à l'objet d'entité de connaître ces autres objets - ils se contentent d'"enregistrer" leur intérêt pour l'objet d'entité et sont notifiés lorsque l'objet d'entité change.

Il s'agit simplement d'un "tour de passe-passe d'analyse" : en conception nous devons définir comment fonctionne exactement cette notification. Nous pouvons acheter une infrastructure de notification toute faite ou bien en concevoir et en construire une nous-mêmes. Mais pour l'instant, il suffit de noter que la notification existe.

La direction de l'association montre que seul l'objet abonnant connaît la relation entre les deux objets. La description de l'abonnement reste dans le cadre de l'objet abonneur. L'objet d'entité associé est ensuite défini normalement sans prendre en compte le fait que d'autres objets peuvent s'intéresser à cette activité. Cela implique également qu'un objet abonné peut être ajouté ou supprimé du modèle sans changer l'objet auquel il s'abonne.

Concilier les réalisations des cas d'utilisation d'analyse Haut de la page

Objet Concilier les réalisations individuelles des cas d'utilisation d'analyse et identifier un ensemble de classes d'analyse possédant des relations cohérentes. 

Les réalisations de cas d'utilisation d'analyse ont été développées par le biais de l'analyse d'un cas d'utilisation spécifique.  A présent les réalisations individuelles de cas d'utilisation d'analyse doivent être conciliées.  Examinez les classes d'analyse et les associations complémentaires définies pour chaque réalisation de cas d'utilisation d'analyse.  Identifiez et résolvez les incohérences et supprimez les doublons. Par exemple, deux réalisations de cas d'utilisation d'analyse distinctes peuvent inclure une classe d'analyse qui est conceptuellement la même, mais dans la mesure où les classes d'analyse ont été identifiées par des concepteurs différents, un autre nom a été utilisé. 
Commentaire : Les doublons entre les différentes réalisations de cas d'utilisation d'analyse peuvent être considérablement réduits si l'architecte logiciel définit correctement une architecture initiale (voir Activité : Analyse architecturale).

Lors de la conciliation des éléments modèles, il est important de prendre leurs relations en considération.  Si deux classes sont fusionnées ou si une classe remplace l'autre, assurez-vous de transmettre les relations de la classe d'origine à la nouvelle classe.

L'architecte logiciel doit participer à la conciliation des réalisations de cas d'utilisation d'analyse car celle-ci requiert une compréhension du contexte métier ainsi qu'une prévoyance de l'architecture et de la conception logicielle pour que les classes d'analyse représentant le mieux les domaines de problèmes et de solutions soient sélectionnées.

Pour plus d'informations sur les classes, voir Principes et conseils : Classe d'analyse.

Nuancer les mécanismes d'analyse Haut de la page

Objet Identifier les mécanismes d'analyse (s'il y en a) utilisés par les classes d'analyse. Fournir des informations complémentaires sur la façon dont les classes d'analyse appliquent le mécanisme d'analyse. 

Dans cette étape, on examine les mécanismes d'analyse s'appliquant à chaque classe d'analyse identifiée.

Si une classe d'analyse utilise un ou plusieurs mécanismes d'analyse, les informations supplémentaires consignées aideront l'architecte logiciel et les concepteurs à déterminer les capacités requises des mécanismes de conception architecturale. Le nombre d'instances de la classe d'analyse, leur taille, leur fréquence d'accès et leur durée de vie prévue sont certaines des propriétés importantes pouvant assister les concepteurs dans la sélection de mécanismes appropriés.

Pour chaque mécanisme d'analyse utilisé par une classe d'analyse, nuancez les caractéristiques pertinentes devant être prises en considération lors de la sélection de mécanismes de conception et d'implémentation adaptés. Elles varieront selon le type de mécanisme ; donnez des fourchettes lorsque c'est adapté, ou lorsqu'il y a encore beaucoup d'incertitudes. Différents mécanismes architecturaux auront différentes caractéristiques, ces informations sont donc purement descriptives et doivent être seulement suffisamment structurées pour consigner et transmettre l'information. Pendant l'analyse, cette information est généralement assez spéculative, mais la consignation a de la valeur dans la mesure où les estimations conjecturales peuvent être révisées lorsque des informations supplémentaires sont découvertes.

Les mécanismes d'analyse utilisés par une classe et leurs caractéristiques associées n'ont pas besoin d'être consignées de façon formelle ; un commentaire attaché à un diagramme ou une extension à la description de la classe suffit pour transmettre l'information. A ce stade de l'évolution de la classe, les informations sur les caractéristiques sont assez fluides et spéculatives, l'accent est donc mis sur la consignation des valeurs prévues plutôt que sur la formalisation de la définition des mécanismes.

Exemple

Les caractéristiques du mécanisme de persistance utilisé par une classe de vol peuvent inclure :

Granularité: 2 à 24 kilo-octet par vol

Volume: Jusqu'à 100 000

Fréquence d'accès:

  • Création/ suppression : 100 par heure
  • Mise à jour : 3 000 mises à jour par heure
  • Lecture : 9 000 accès par heure

Exemple

Les caractéristiques du mécanisme de persistance utilisé par une classe de mission peuvent inclure:

Granularité: 2 à 3 méga-octets par mission

Volume: 4

Fréquence d'accès:

  • Création/ suppression : 1 par jour
  • Mise à jour : 10 par jour
  • Lecture : 100 par heure

Etablir la traçabilité Haut de la page

Objet Maintenir les relations de traçabilité entre le modèle d'analyse et les autres modèles. 

Les recommandations relatives au projet définissent la traçabilité requise pour les éléments de modèle d'analyse.

Par exemple, s'il existe un modèle séparé de l'interface utilisateur, il peut être utile de suivre des écrans ou d'autres éléments d'interface utilisateur de ce modèle par rapport aux classes de frontière du modèle d'analyse.

Réviser les résultats  Haut de la page

Objet Vérifier que les objets d'analyse répondent aux exigences fonctionnelles faites au système.
Vérifier que les objets et les interactions d'analyse sont cohérents. 

Effectuer une revue informelle à la fin de l'atelier, comme point de synchronisation, ainsi qu'à la fin de l'Activité : Analyse de cas d'utilisation.

Utilisez les points de contrôle pour les sorties d'artefacts par cette activité.



RUP (Rational Unified Process)   2003.06.15