Tâche: Définition d'un contexte système
Cette tâche explique comment créer un diagramme de contexte du système qui indique la collaboration de niveau supérieur entre le système et ses acteurs.
Objet
  • En fonction du modèle de cas d'utilisation, afin de créer une collaboration de niveau supérieur indiquant le système (sous forme de sous-système de niveau supérieur), ses interfaces et ses relations avec ses acteurs, dont les entités E/S externes entre acteur et système.
Relations
RôlesPrincipal: Complémentaire: Auxiliaire:
EntréesObligatoire: Facultatif:
  • Aucun
Externe:
  • Aucun
Sorties
Etapes
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)

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)

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)

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.

Propriétés
Plusieurs occurrences
Commandé par les événements
En cours
Facultatif
Planifié
Réitérable