Analyse

Cette étape correspond à la première description de l’aspect opérationnel du système. Nous nous concentrons donc sur la spécification des exigences fonctionnelles qui conduiront à l’établissement des cas d’utilisation et à leur description par des scénarii. La Fig.13 montre le

5 _{Le stéréotype « formal_requirement » est une extension de SysML. Le méta-modèle introduisant ce stéréotype est}

présenté dans le chapitre IV section 2.1.

<<formal_requirement>> Formal_Requirement id = “211”

Formal specification= (logic or visual language) kind=“non-functional” criticality = high <<derive>> <<requirement>> Informal_Requirement id = “211” text=“ … ” kind=“non-functional” criticality = high <<test case>>

System with Verification techniques

<<verify>> <<satisfy>> <<requirement>> Function id = “210” text=” … “ kind=“functional” criticality = high

Méthodologie de conception de systèmes temps réel et distribués en contexte UML/SysML

diagramme d’activités étendu de l’étape d’analyse complet. Il est composé de trois sous-activités qui sont : la description de l’environnement, la construction des fonctionnalités et la définition des scénarii décrivant dans un premier temps chaque fonctionnalité individuellement. Par la suite, ces scénarii élémentaires seront structurés dans des scénarii de plus haut-niveaux permettant de définir des scénarii d’utilisation du système incluant plusieurs fonctionnalités.

Dans un premier temps, il faut définir le périmètre du système et séparer celui-ci de ses utilisateurs et de son environnement. La base de données construite dans l’étape 1.1.2 (cf. § 3.1.1) sert de point de départ à la définition des acteurs qui rentrent en jeux dans les exigences fonctionnelles. Les acteurs extérieurs au système sont répartis en deux catégories : les acteurs qui utilisent le système et l’environnement (matériel/logiciel) sur lequel repose le système. La seconde étape correspond à la définition du périmètre du système.

Fig.13. DP de l’étape d’analyse

(1.2.3.) Scenario (1.2.1) Périmètre du système

Distinguer environnement et acteurs

[Fonctionnalités élémentaires] [Fonctionnalités de haut niveau]

Base de données répertoriant les

exigences à traiter

Répertorier et hiérarchiser les exigences fonctionnelles (N_UReq) et N=0

Insérer Point d’Observation Associer fonctionnalités avec acteurs et environnements

Diagramme de cas d’utilisation

Définir liste d’acteurs déduits de la base de données

(1.2.2) Fonctionnalités

[Exigence temporelle associée] [Sinon] (1.2.3.1) Unitaires [Niveau supérieur de fonctionnalités] (1.2.3.2) Haut niveau [Sinon] Diagramme de séquences

Décrire fonctionnalité par un scénario Diagramme global d’interaction Diagramme d’exigences

Décrire un scénario de haut niveau intégrant des

Les fonctionnalités du système qui décrivent l’aspect opérationnel du système sont ensuite exprimées. Comme mentionné dans [HUL 04] [ROQ 04], les exigences fonctionnelles du système sont équivalentes aux fonctionnalités du système et donc en termes UML aux cas d’utilisation. Ceux- ci peuvent être reliés entre eux pour produire des inclusions ou des extensions entre fonctionnalités. Les stéréotypes de relation de dépendance entre cas d’utilisation sont respectivement « include » et « extend ». Les cas d’utilisation peuvent aussi se spécialiser et se généraliser par des relations d’héritage. Ces différentes fonctionnalités sont ensuite associées aux acteurs adéquats. Le diagramme de cas d’utilisation s’enrichit, comme le montre la flèche en pointillé sortant de l’activité Associer fonctionnalités avec acteur et environnement sur la Fig.13).

Les fonctionnalités du système ayant été définies (activité (1.2.2) dans un diagramme de cas d’utilisation, nous passons à l’étape de définition des scénarii. Chaque fonctionnalité est, dans un premier temps, décrite par un scénario élémentaire où l’on fait intervenir les différentes entités et acteurs concernés par cette fonctionnalité (activité 1.2.3.1). Ceci est fait en construisant un diagramme de séquences. On peut alors relier les fonctionnalités aux exigences non-fonctionnelles produites en section 3.1.1, en insérant des points d’observations présentés dans la section 3.1.1 de ce chapitre (étape Insérer points d’observations de la Fig.13). Ces points d’observations correspondent aux événements définissant l’exigence (cf. § 3.1.1) et leur placement est un point très délicat. En effet, si ces points ne sont pas correctement placés alors l’exigence ne sera pas correctement vérifiée. Le placement correct des points d’observation fait l’objet de la section 3 du chapitre V.

Une fois construits, les scénarii élémentaires sont structurés par des scénarii de plus haut niveau. Ces derniers sont composés de fonctionnalités élémentaires incluses dans la fonctionnalité décrite par un diagramme global d’interaction (activité 1.2.3.2.).

Instanciation sur le profil TURTLE

La Fig.14 illustre le placement des points d’observation dans un diagramme de séquences générique non tributaire d’un processus spécifique. Les points d’observations sont représentés par des activités internes étiquetées selon les choix de l’utilisateur, par exemple, par PO_Start pour la première occurrence décrivant l’exigence et PO_End pour la seconde occurrence décrivant la fin de l’exigence. Il est très important de placer les points d’observation immédiatement après les messages qui vont conduire d’une part à l’exécution du processus (Start_Process) et d’autre part à la fin du processus (End_Process). Les règles définies dans le chapitre V section 3 (éléments de preuves), montrent que si les points d’observations étaient placés avant l’événement déclenchant une exigence temporelle alors l’observateur délivrerait un mauvais diagnostic. Notons ici que les points d’observation peuvent être placés dans des objets différents.

Méthodologie de conception de systèmes temps réel et distribués en contexte UML/SysML

A partir de ces informations, une ébauche de modèle peut être construite du point de vue architectural (en représentant les interactions définies dans le diagramme de séquences entre objets du système, les acteurs et l’environnement) et comportemental (déduits de la description des scénarii sous forme de diagrammes de séquences et de diagrammes globaux d’interactions).