Introduction
Si le modèle de cas d'utilisation indique le contexte comportemental du système, cette tâche vous permet de créer un
modèle logique du système dans son environnement à l'aide des éléments suivants : Produit : Modèle de cas d'utilisation métier , Produit : Spécification métier supplémentaire. Le modèle est utilisé
pour délimiter un diagramme de contexte.
-
Les interfaces qui vont être réalisées par le système (en terme d'opérations que le système fournit,
de protocoles associés pris en charge, de variables d'état et de stockages que le système réalise et
d'attributs).
-
Les entités d'entrée-sortie qui relient le système à ses acteurs.
-
Les interfaces obligatoires pour le système (qui seront réalisées par les acteurs qui interagissent avec le
système) pour obtenir des performances correctes. Si l'acteur représente un système existant avec lequel le système
doit communiquer, ces interfaces obligatoires ne reflètent souvent que les contraintes imposées par cet autre
système.
Un diagramme de contexte indique la collaboration de niveau supérieur entre le système et ses acteurs. Ce diagramme est
l'équivalent structurel du modèle de cas d'utilisation pour le système. Cette collaboration est créée dans le modèle
d'analyse.
Les entités d'entrée-sortie (représentées pour la modélisation comme des classes stéréotypées d'entrée-sortie avec des
attributs mais pas d'opérations) décrivent les choses qui entrent ou qui sortent du système et peuvent, dans le cas du
système général, inclure des parties données, masse, énergie ou physique. Les entités d'entrée-sortie sont associées
(pendant la modélisation) à des paires de système-acteur, indiquant que ces entités d'entrée-sortie circulent entre
l'acteur et le système. Ces entités peuvent être indiquées sur les diagrammes associés à l'acteur et le sens de la
circulation est indiqué sur l'association par la mention "envoie" ou "reçoit", indiquant la direction de l'acteur.
Une opération de système est un service qui peut être requis par un objet pour effectuer un comportement. Une opération
spécifie le nom, le type, les paramètres et les contraintes représentés par l'appel d'un comportement associé. Les
opérations sont regroupées autour des interfaces selon les principales responsabilités du (sous-)système concerné.
L'appel d'une opération de système est une interaction avec le système plus affinée qu'une instance de cas
d'utilisation, et une instance de cas d'utilisation est une composition d'invocations et de réponses d'opération.
Les variables et les magasins d'état sont des attributs définis sur les interfaces réalisées par le système. Ils sont
abstraits et demandent au système de conserver les informations correspondant au type et à la multiplicité de
l'attribut et de permettre le stockage, la suppression et la modification de ces informations. Il n'est pas certain
qu'un attribut du système corresponde directement à l'attribut défini dans l'interface. La différence entre les
variables et les magasins d'état n'est pas prédéfinie, elle reflète seulement la façon dont les attributs sont utilisés
pour contrôler l'opération de la machine d'état du système. Un "état" dure un certain laps de temps, tandis qu'un
événement (comme l'arrivée d'un signal) a lieu à un moment donné. Les machines d'état mentionnées ici sont des machines
d'état finies et la délimitation d'"état" est généralement déterminée par quelques variables ; l'état actuel pourrait,
par exemple, être défini par la valeur d'un attribut unique d'un type énumératif. Toutefois, la réaction d'un système
vis-à-vis d'un événement ne dépend pas seulement de la nature de l'événement (et des informations qu'il contient, comme
les paramètres de l'opération) et de l'état actuel, mais aussi de la valeur d'autres attributs (qui peuvent être
nombreux).
|
Création du diagramme de contexte initial
A mesure que vous modifiez ou ajoutez des détails au modèle de cas d'utilisation (lorsque vous découvrez les acteurs
métier ou si les acteurs et les opérations ont déjà été identifiés, mettant au point leurs interactions), vous pouvez
créer la collaboration initiale et l'illustrer avec un diagramme de contexte. Le diagramme de contexte peut être créé
comme nous l'avons indiqué, avec, au départ, les interfaces du système mises de côté. Le système est décrit comme un
sous-système de niveau supérieur (stéréotypé comme un "système"), qui réalise éventuellement plusieurs interfaces. Les
acteurs métier et leurs associations sont aussi indiqués, mais encore de manière non détaillée.
|
Description détaillée des associations et des interfaces
Ensuite, il faut affiner les associations entre les acteurs métier et le système ainsi que l'interface du système. Vous
pouvez commencer à réfléchir au sujet des opérations et des attributs du système à mesure qu'ils émergent de la Tâche : Identification des acteurs métier et des cas d'utilisation.
Par la suite, vous pourrez utiliser la Tâche:
Description détaillée d'un cas d'utilisation métier). Remarquez que le système apparaît désormais aux acteurs en
montrant l'interface. Cette réalisation peut être indiquée si vous le souhaitez, mais son omission n'entraîne pas une
importante perte d'informations.
A ce stade, essayez d'identifier les entités métier d'entrée sortie en vous basant sur vos connaissances du domaine
ainsi que sur tout travail effectué auparavant lors de la réalisation de cas d'utilisation métier au niveau de
l'entreprise. Remarquez qu'il n'est pas nécessaire que les entités métier d'entrée-sortie soient indiquées dans le
diagramme, mais cela peut être utile lors de la réflexion portant sur les interactions entre les acteurs et le système.
Vous pouvez donc commencer à caractériser les connexions entre l'acteur et le système (comme, par exemple, enregistrer
le protocole requis) et à enregistrer les entités qui circulent entre elles.
|
Description détaillée des opérations métier et autres caractéristiques
Lors de cette étape, vous commencez à construire les scénarios de cas d'utilisation métier (les instances de cas
d'utilisation) à partir desquels vous pouvez décrire les opérations du système métier (fournies et requises). Les
scénarios peuvent être illustrés par des diagrammes d'interaction et d'activité. Chaque étape de boîte noire dans un
cas d'utilisation représente une interaction mieux définie avec le système et se mappe à un appel d'opération (mais pas
nécessairement à une opération unique ; les autres étapes de boîte noire peuvent utiliser la même opération). Les cas
d'utilisation définissent les opérations du système dans le diagramme de contexte (et donc dans le modèle d'analyse
métier), mais ils sont aussi spécifiés sur les opérations invoquées pour la traçabilité. Les opérations héritent aussi
des exigences de performance ou d'autres exigences non fonctionnelles qui ont été allouées aux étapes de boîte noire.
Lors de l'examen des étapes de boîte noire exécutées dans le scénario, vous découvrez l'utilisation de noms qui peuvent
suggérer que le système doit conserver des variables et des magasins d'état pour exécuter le scénario de cas
d'utilisation. Vous pouvez aussi détailler les entités métier d'entrée-sortie requises et les associer aux appels
d'opérations pour former les signaux envoyés entre l'acteur et le système.
Diviser l'interface du système en interfaces plus spécifiques peut faciliter la compréhension ; des exigences
d'interface de spécifications métier supplémentaires peuvent même prendre cela en charge. L'illustration ci-dessous
montre la "transformation" de l'interface du système en "interface de système fournie" pour chaque type d'acteur, bien
que ce ne soit pas une prescription établie. Les acteurs peuvent partager une interface et il peut y avoir plusieurs
interfaces pour un acteur.
Cette analyse peut aussi identifier les interfaces requises par le système, c'est-à-dire les interfaces qui
doivent être prises en charge par les acteurs métier (pour traiter les messages du système). Elles peuvent être
ajoutées au diagramme de symétrique. Un acteur peut prendre en charge plus d'une interface.
Les opérations et autres stocks doivent être ajoutés à une forme étendue des interfaces (dans les parties attribut et
opération) comme indiqué. Comme précédemment, la réalisation des interfaces système fournies peut être omise sans
causer d'importantes pertes d'informations.
Cette collaboration de niveau supérieur, enregistrée dans le diagramme de contexte, permet aux interfaces, aux
connexions, à ce qui entre et sort du système ainsi qu'aux caractéristiques de performance associées d'être définis de
manière rigoureuse.
|
|