ARCHITECTURE DE L’OUTIL

Une architecture consiste à créer une représentation simplifiée pour les fonctionnalités d'un système désiré. En effet, l’architecture du système facilite la compréhension de sa mission.

Par exemple, l’utilisation de la spécification semi formelle comme UML, nous permet de définir et de visualiser un modèle à l'aide de plusieurs diagrammes. En effet, un diagramme UML est une représentation graphique, qui s'intéresse à tel aspect. Chaque type de diagramme présent dans UML, possède une structure bien précise. Ci-dessous, nous allons présenter: le diagramme de classe, et le diagramme de cas d’utilisation, afin de montrer les fonctionnalités primaires de notre outil.

2.1. Diagramme de cas d’utilisation

Les diagrammes de cas d'utilisation sont utilisés pour donner une vision globale du comportement fonctionnel d'un système. Ainsi, ils permettent d'identifier les fonctionnalités principales et critiques du système. Ci-dessous, nous allons présenter les deux composants principaux des diagrammes de cas d'utilisation qui sont : les acteurs et les cas d'utilisation.

Les acteurs sont des entités externes, qui interagissent avec le système (comme une personne humaine). Une personne physique peut jouer le rôle de plusieurs acteurs d’un système. C'est pourquoi les acteurs doivent surtout être décrits par leur rôle ; ce rôle décrit les besoins et les capacités de l'acteur. En effet, les acteurs sont représentés par un pictogramme humanoïde sous-titré par le nom de l'acteur (ou bien un rôle).

Chapitre IV- Spécification et Outillage

Figure IV.1- le diagramme de cas d’utilisation

Le cas d'utilisation (use case), permet de décrire l'interaction entre l'acteur et le système. Un cas d’utilisation ne décrit pas une solution d’implémentation, mais il est une description des interactions qui vont permettre à l'acteur d'atteindre son objectif en utilisant le système. En effet, il est représenté par une ellipse sous-titrée par un nom (éventuellement le nom est placé dans l'ellipse). Un acteur et un cas d'utilisation sont mis en relation par une association représentée par une ligne.

Dans la figure ci-dessus (cf. Figure IV.1), on présente le diagramme de cas d’utilisation de notre outil. En fait, l’outil supporte deux cas d’utilisation principaux :

• Décomposition du système désiré, selon la norme de l’EIA-632,

• L’application d’une demande de changement.

La fonctionnalité de décomposition du système selon l’EIA-632 joue un rôle majeur pour l’utilisateur de notre outil. Car, cette première fonctionnalité doit permettre aux parties prenantes, de développer le système selon la décomposition présentée par la norme de l’EIA-632. Cette décomposition est une décomposition du système désiré avec : des projets, des modules, produits capacitants, produits finaux et des technologies capacitants. Durant la présentation du diagramme de classes, nous allons expliquer le détail de ce premier cas d’utilisation.

Appliquer une demande de changement

Analyse d’impact de changement

Analyse d’impact sur la sécurité Decomposer le système Initialiser la demande Evaluation d’impact «Includes» Demandeur Développeur «Uses » Evaluateur «Includes» «Includes»

Chapitre IV- Spécification et Outillage

Le deuxième cas d’utilisation de l’outil est de permettre à une analyse d’impact lors de la demande de changement. Dans notre outil, l’analyse d’impact d’une modification sur la sécurité est basée sur deux types d’analyses différentes (révise chapitre 3, § 4.3.2) :

• La première analyse est une analyse préliminaire pour les constituants impactés par la modification Ces constituants peuvent être des exigences sécuritaires, des exigences techniques, des modules, des fichiers, des produits capacitants, des technologies capacitants.

• La deuxième analyse est une analyse d’impact formelle. Cette analyse sera établie, en analysant les fichiers impactés (qui correspondent à la solution logique d’un tel module et qui contiennent la spécification formelle) par la modification, afin de vérifier la validité des contraintes de sécurité.

Réellement, notre outil ne doit pas supporter une analyse formelle sur la sécurité. Mais, il doit s’interfacer avec un autre outil comme RSL, afin d’analyser l’impact formellement.

2.2. Diagramme de classes

Dans ce paragraphe, nous allons présenter la spécification de l’outil²⁵ en utilisant le diagramme de classes. En effet, le diagramme des classes est un schéma utilisé en génie logiciel pour présenter les classes d'un système, ainsi que les différentes relations entre celles-ci. Il fait partie de la représentation statique d'UML car il fait une abstraction des aspects temporels et dynamiques. Précisément, une classe décrit les responsabilités, le comportement et le type d'un ensemble d'objets. Les éléments de cet ensemble sont les instances de la classe. Une classe est définit avec des fonctions (méthodes) et des données (attributs) qui sont liées ensembles par un champ sémantique.

Effectivement, les classes permettent de modulariser un programme et ainsi de découper une tâche complexe en plusieurs petits travaux simples. Elles peuvent être liées entre elles, avec des associations. Chaque association de ces relations est représentée par un arc spécifique dans le diagramme de classes. Dans notre cas d’étude, on n’a pas présenté les attributs d’une classe, vu que nous voulons les présenter formellement avec RSL.

25

Chapitre IV- Spécification et Outillage

Figure IV.2-Le diagramme de classes

En réalité, les sources d’information durant le développement du système seront présentées dans différents types de documents. Ces documents, contiennent les informations techniques ou non pour le développement du système. Par exemple, des documents contiennent des informations sur les parties prenantes liées au développement du système, leurs adresses, les numéros des téléphones ; les modules ; les produits finaux; les produits capacitants; ainsi que les fichiers qui correspondent au système de développement d’un module,

Dans le diagramme ci-dessus, on remarque que la traçabilité est représentée par l’ensemble des relations qui relient les classes entre eux (concernée_par, concerne, développé_avec,

testé_par, décomposé_avec, etc…). Ces relations représentées explicitement, nous permettent par exemple de connaître les exigences techniques, les produits finaux, les produits capacitants d’un module donné.

Enabling Technology Project Request Change Role Building Block Stakeholders * Goal Test Goal * * * * * * Concernée_par ^Concerne Développé_avec Composé_de End Product Technical Requirement Assign Requirement Sub System Test Case Enabling Product File * _* * * * * *

Testé_par Réalisé_avec Décomposé_avec

Composé_de Composé_de Composé_de Composé_de Actualiser_avec Testé_par

Chapitre IV- Spécification et Outillage