Introduction
Alors que le modèle de cas d'utilisation indique le contexte comportemental du système, dans cette tâche, vous créez un
modèle logique du système dans son environnement, en utilisant le Produit :
modèle de cas d'utilisation et le Produit : spécifications supplémentaires pour délimiter, dans un
Diagramme de contexte :
-
Les interfaces que le système doit réaliser (en termes d'opérations fournies par les systèmes, et les
protocoles associés pris en charge, les variables d'état et les stockages que le système réalise, et
les attributs caractérisés par des Mesures de performances techniques).
-
Les entités E/S entre le système et ses acteurs.
-
Les interfaces requises par le système (à réaliser par les acteurs qui agissent avec le système) pour une
performance correcte. Souvent, si l'acteur représente un système existant avec lequel le système doit communiquer,
ces interfaces requises reflètent simplement les contraintes imposées par cet autre système.
Un diagramme de contexte indiquer la collaboration de niveau supérieur entre le système et ses acteurs. Il s'agit de
l'analogique de structure 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 E/S (représentées pour la modélisation sous forme de classes stéréotypées "E/S" avec des attributs mais
sans opérations) décrivent des éléments qui entrent ou sortent du système et peuvent, dans le cas de système général,
comprendre données, masse, énergie ou parties physiques. Les entités E/S sont associées (lors de la modélisation) à des
paires acteur-système, qui indiquent que ces entités E/S particulières agissent entre acteur et système. Elles peuvent,
de façon facultative, être indiquées sur les diagrammes, associées à l'acteur, et la direction du flux est indiqué par
un stéréotype "envoyer" ou "recevoir" sur l'association, indiquant la direction par rapport à l'acteur.
Une opération de système est un service qui peut être demandé par un objet pour un effet sur le comportement. Une
opération indique le nom, le type, les paramètres et les contraintes permettant d'invoquer un comportement associé. Les
opérations sont groupées autours des interfaces en fonction des principales responsabilités du (sous-)système en cours
d'analyse. Une invocation d'opération de système représente une interaction plus détaillée avec le système qu'une
instance de cas d'utilisation, et une instance de cas d'utilisation est une composition des invocations d'opération et
des réponses.
Les variables d'état et les stockages sont des attributs définis sur les interfaces réalisées par le système. Ceux-ci
sont abstraits et nécessitent que le système gère les informations correspondantes au type et à la multiplicité de
l'attribut et permette le stockage, la récupération et la modification de ces informations. Rien n'implique qu'un
attribut dans le système correspond directement à l'attribut défini dans l'interface. La différence entre les variables
d'état et les stockages n'est pas intrinsèque, elle reflète simplement la façon dont les attributs sont utilisés pour
contrôler l'opération de la machine d'état du système (abstrait). Un "état" est conservé pendant un certain temps,
contrairement à un événement (comme par exemple l'arrivée d'un signal) qui se produit à un moment donné. Les machines
d'état mentionnées ici sont des processus d'état, et la délimitation d'un "état" est généralement décidée par
relativement peu de variables ; par exemple, l'état actuel peut être spécifié par la valeur d'un seul attribut d'un
type d'énumération. Cependant, la réaction du système par rapport à un événement peut dépendre non pas uniquement de la
nature de l'événement (et des informations qu'il comporte, par exemple, dans les paramètres d'opération), et l'état
actuel, mais également de la valeur d'autres attributs (qui peuvent être nombreux).
Une mesure de performance technique (TPM) est un attribut technique clé sélectionné parmi les spécifications
supplémentaires ou le modèle de cas d'utilisation comme indicateur critique de l'efficacité du système qui, s'il n'est
pas satisfait, met le développement du système dans une situation à risque qui peut entraîner un coût de
surfonctionnement, des contraintes de calendrier ou de performance. Les valeurs qui apparaissent de tels attributs sont
suivies tout au long de la vie du projet. Par exemple, il peut être important que le poids livré d'un système soit
maintenu en-dessous d'une certaine limite, et la réussite de cette cible doit être suivie au fur et à mesure de la
conception et la construction. Le poids du système livré est évidemment un attribut (ce qui peut être détecté de
plusieurs façons) d'une instance du système, et n'est pas nécessairement le même que le poids cible lors du
développement (pour qu'un système soit lancé en orbite, il faudra probablement qu'il soit inférieur). Une valeur
marquée UML peut être utilisée pour annoter un attribut TPM afin d'indiquer la cible de performance, par exemple :
Poids "TPM" {poids_maximum = 1000 kg}
Les mesures de performances techniques peuvent également s'appliquer à d'autres caractéristiques non structurelles,
comme par exemple le temps de réponse de l'opération. Des valeurs marquées peuvent être appliquées aux opérations du
système, ou au système lui-même, pour les enregistrer.
|
Créer un diagramme de contexte initial
Les étapes suivantes indiquent des niveaux de détail du système en contexte qui évoluent. L'exemple illustré est celui
d'un système de sécurité, qui protège la propriété d'une intrusion non autorisée, qui, en plus de ressembler à une
alarme, a la capacité de signaler des violations à une sorte de service de réponse.
Au fur et à mesure que vous avancez et détaillez le modèle de cas d'utilisation (en découvrant les acteurs ; ou si un
modèle de gestion a été réalisé, et des acteurs et peut-être des opérations déjà identifiés, en élaborant leur
interaction), vous pouvez créer la collaboration initiale et l'illustrer par un diagramme de contexte. Le diagramme de
contexte peut être créé tel qu'indiqué, d'abord en résumant les interfaces du système. Le système est décrit comme un
sous-système de niveau supérieur ("système" stéréotypé), qui finalement réalise plusieurs interfaces. Les acteurs et
leurs associations sont également indiqués, à nouveau, sans détail au début.
Diagramme de contexte (initial)
|
Détailler les associations et interfaces
Ensuite, vous détaillez les associations entre les acteurs et le système et l'interface du système. Vous pouvez
commencer par réfléchir aux opérations du système et aux attributs du système tels qu'ils apparaissent dans Tâche : Identifier les acteurs et les cas d'utilisation
(Ultérieurement : Tâche : Détailler un cas d'utilisation). Notez que désormais, le
système apparaît aux acteurs, en affichant l'interface. La réalisation de cela peut être indiquée si vous le souhaitez
(soulignée par le cercle en pointillés dans le diagramme), mais peut être omise sans grande perte d'informations.
A ce stade, tentez uniquement d'identifier les entités E/S, en fonction des connaissances dans le domaine et de tout
travail effectué auparavant en réalisant des cas d'utilisation au niveau de l'entreprise. Notez qu'il n'est pas
nécessaire que les entités E/S soient indiquées sur le diagramme, mais cela peut être utile pour discuter des
interactions acteur-système.
Par conséquent, vous pouvez commencer à caractériser la ou les connexion(s) entre acteur et système (par exemple,
enregistrer le protocole requis) et enregistrer les entités entre eux.
Diagramme de contexte (préliminaire)
|
Détailler les opérations du système et d'autres caractéristiques du système
Dans cette étape, vous commencez à construire des scénarios de cas d'utilisation (instances de cas d'utilisation) à
partir desquels vous pouvez décrire les opérations du système (fournies et requises). Les scénarios peuvent être
illustrés par des diagrammes d'interactions ou d'activités. Chaque étape de boîte noire dans un cas d'utilisation
représente une interaction plus détaillée avec le système et dirige vers une invocation d'opération (mais pas
nécessairement une opération unique ; d'autres étapes de boîte noire peuvent utiliser la même opération). En plus de
définir les opérations du système dans le diagramme de contexte (et donc dans le modèle d'analyse), les cas
d'utilisation sont également annotés, à des fins de traçabilité, sur les opérations invoquées. Les opérations héritent
également de toute exigence de performance ou autre exigence non fonctionnelle qui ont été attribuées aux étapes de
boîte noire. Lorsque vous examinez chaque étape de boîte noire réalisée dans le scénario, vous découvrez l'utilisation
de noms qui peuvent suggérer des variables d'état et des stockages que le système doit gérer pour exécuter le
scénario de cas d'utilisation. Vous pouvez également détailler les entités E/S qui sont requises et les associer à des
invocations d'opérations pour former des signaux envoyés entre acteur et système.
Cela peut aider à comprendre pour diviser l'interface du système en plusieurs interfaces spécifiques ; il peut exister
des exigences d'interface dans la spécification supplémentaire pour cela. L'illustration ci-dessous indique l'évolution
de l'interface du système en une "interface de système fournie" pour chaque type d'acteur, bien que ce ne soit pas une
prescription fixe. Des acteurs peuvent partager une interface ; il peut y avoir plus d'une interface par acteur.
Cette analyse peut également identifier des interfaces requises par le système, c'est-à-dire des interfaces qui
doivent être prises en charge par les acteurs (pour traiter des messages à partir du système). Elles peuvent être
ajoutées au diagramme de façon symétrique (par exemple, voir l'"interface de système requise" services IE/ESS réalisée
par l'acteur Services d'urgence dans le diagramme ci-dessous). Encore une fois, (bien que ce ne soit pas indiqué),
un acteur peut prendre en charge (réaliser) plus d'une interface.
Les opérations, stockages etc., doivent être ajoutés à une forme étendue des interfaces (dans les compartiments
d'attribut et d'opération) tel qu'indiqué. Le diagramme n'est élaboré que partiellement (dans l'intérêt d'espace).
L'interface d'environnement physique, l'acteur, etc., n'ont pas été étendus. Une fois encore, la réalisation des
interfaces du système fournies peut être omise sans grande perte d'informations.
Diagramme de contexte (final).
Cette collaboration de niveau supérieur, enregistrée dans le diagramme de contexte, permet aux interfaces, connexions,
ce qui entre et sort du système et aux caractéristiques de performance associées d'être rigoureusement spécifiés, en
permettant au développement du système de s'effectuer en quelque sorte indépendamment des autres éléments du contexte
du système.
|
|