Création de cas d'utilisation d'analyse
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 tâches orientées vers les exigences et les tâches orientées vers l'analyse et la
conception, le Produit : Réalisation de cas d'utilisation sert de passerelle,
permettant de tracer le comportement dans les modèles d'analyse et de conception jusqu'au modèle de cas d'utilisation
et de mettre en place des collaborations autour du concept du 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 celui du 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, voir aussi Technique :
Réalisation de cas d'utilisation.
|
Ajout d'informations à la description du cas d'utilisation
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 guichet automatique, le client du système peut préférer dire que
Le guichet automatique 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 guichet automatique envoie le numéro de compte du client et le numéro d'identification au réseau des guichets
automatiques afin qu'ils soient validés. Le réseau des guichets automatiques renvoie un message positif si le
numéro de compte et le numéro d'identification du client correspondent et si le client est autorisé à effectuer des
transactions, s'il ne l'est pas, le réseau 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 ducas 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 observe 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 flux 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 flux textuel complet, indépendant de la description "externe" du flux d'é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.
|
Recherche de classes d'analyse à partir du comportement de cas d'utilisation
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 concernent les frontières entre le système et ses acteurs, les informations
que le système utilise 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 aussi Technique : Classe
d'analyse. Pour plus d'informations sur les réalisations de cas d'utilisation d'analyse, voir aussi Technique : Réalisation de cas d'utilisation.
Si des mécanismes d'analyse et/ou des patterns d'analyse ont été documentés dans les instructions relatives au projet,
ils doivent être utilisés comme une autre source d'inspiration pour les classes d'analyse.
|
Distribution du comportement aux classes d'analyse
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 flux principal d'événements du cas d'utilisation, ainsi qu'au moins
un diagramme pour chaque flux alternatif/exceptionnel. Des diagrammes séparés sont généralement nécessaires pour
les sous-flux possédant des caractéristiques complexes en terme de délais ou de décision ou pour simplifier les
flux complexes qui sont trop longs pour être facilement inclus dans un diagramme.
-
Identifier les classes d'analyse responsables du comportement requis en examinant le flux d'événements du
scénario afin de vous assurer que tous les comportements nécessaires au cas d'utilisation sont fournis par la
réalisation des cas d'utilisation d'analyse.
-
Illustrer les interactions entre les classes d'analyse dans 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.)
Diagramme de communication pour le cas d'utilisation Réceptionner un article consigné.
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.
|
Description des responsabilités
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.
|
Description des attributs et des associations
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 :
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.
-
Détenue seulement par 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 en dehors du fait de fournir une valeur.
En revanche, si l'information a un comportement complexe, si elle est partagée par deux objets ou plus ou encore si
elle est échangée entre deux objets "par référence", elle doit être modélisée comme une classe à part.
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, entier, nombre.
Commencez par examiner les liens dans les diagrammes d'interaction produits dans Distribution du 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. Il faut donc créer, 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 aussi Technique :
Association et Technique: Agrégation)).
Nous préciserons ces associations et ces agrégations dans la Tâche : 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 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 doit ê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.
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'abonné. Pour plus d'informations, voir aussi Technique : 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 d'association 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 s'abonnant. 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.
|
Conciliation des réalisations des cas d'utilisation d'analyse
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 identique conceptuellement,
mais dans la mesure où les classes d'analyse ont été identifiées par des concepteurs
différents, un autre nom a été utilisé.
Remarque : le nombre de doublons entre les réalisations de cas d'utilisation d'analyse peut être considérablement
réduit si l'architecte logiciel définit correctement l'architecture initiale
(voir aussi Tâche : 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 en remplace une 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 aussi Technique : Classe
d'analyse.
|
Qualification des mécanismes d'analyse
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 être qualifiées par :
Granularité : 2 à 24 kilo-octets 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 être qualifiées par :
Granularité : 2 à 3 mégaoctets par mission
Volume : 4
Fréquence d'accès :
-
Création/ suppression : 1 par jour
-
Mise à jour : 10 par jour
-
Lecture : 100 par heure
|
Mise en place de la traçabilité
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.
|
Revue des résultats
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.
|
Effectuez une revue informelle à la fin de l'atelier, comme point de synchronisation, ainsi qu'à la fin de la Tâche : Analyse de cas d'utilisation.
Utilisez la ou les listes de contrôle pour les produits créés par cette tâche.
|
|