développement orienté modèles de logiciel à base de...

REPUBLIQUE ALGERIENNE DEMOCRATIQUE ET POPULAIRE

MINISTERE DE L’ENSEIGNEMENT SUPERIEUR ET DE LA RECHERCHE SCIENTIFIQUE

UNIVERSITE 20 AOUT 1955 − SKIKDA

Faculté des Sciences

Département d’Informatique

Ecole Doctorale de l’Est – Pôle ANNABA

MEMOIRE

Présenté

pour l’obtention du diplôme de MAGISTER en INFORMATIQUE

Ecole Doctorale en Informatique de l’Est – EDI Est

Option : GENIE LOGICIEL

Développement orienté modèles de logicielà base de « Problem Frames »

Par

Walid LAOUAR

Composition du jury

Président Mohamed REDJIMI MC A, Université 20 Août 1955 − Skikda

Rapporteur Mohamed T. KIMOUR Professeur, Université Badji Mokhtar − AnnabaExaminateurs Smaine MAZOUZI MC A, Université 20 Août 1955 − Skikda

Tahar BENSBAA. MC A, Université Badji Mokhtar − Annaba

Remerciements

Je tiens premièrement à prosterner remerciant Allah le tout puissant de m’avoir donné la force, le courage et la patience pour terminer ce travail.

Je remercie ensuite Mr. Mohamed Tahar Kimour professeur à l’université d’Annaba, qui m’a honoré par son encadrement et qui m’a donné une chance immense de soutenir ce travail. Qu’il soit assuré de ma profonde reconnaissance et mon profond respect pour son aide, sa confiance, et aussi pour ses qualitésscientifiques et humaines.

Je tiens à remercier vivement les membres de jury : Dr. Mohamed Redjimi, Dr. Smaine Mazouzi et Dr. Tahar Bensbaa pour m’avoir honoré par leur évaluation de ce travail. J’aimerais remercier tout particulièrement mon encadreur du mémoire d’ingéniorat Dr Smaine Mazouzi pour son aide, sa gentillesse et ses qualités scientifiques et humaines.

J’adresse mes profonds remerciements à Mlle Boukarma Hanene, qui m’a énormément aidé pendant la réalisation de ce travail. Ce travail n’aurait pu aboutir sans son soutien.

J’adresse mes profonds remerciements à tous ceux qui ont contribué de près ou de loin à l’aboutissement de ce travail.

Un immense merci à mes parents pour leur soutien sans faille, à toute ma famille, à tous mes amis, pour leurs encouragements et leurs marques d’affection. Bien que je ne les liste pas ici, je suis certain que chacun s’y reconnaitra.

Résumé

Les problèmes à résoudre par le développement de logiciel sont essentiellement liés à l’environnement dans lequel ce logiciel sera utilisé. De ce fait, les développeurs de logiciels doivent d’abord déterminer les caractéristiques de cet environnement ainsi que ses contraintes.

Récemment, les Problem Frames (PF) (schémas de problèmes) sont introduits comme moyen de classification, d’analyse et de structuration de problèmes. Introduite par Mickael Jackson, l’approche de problem frames fournit des diagrammes, des notations et des concepts permettant une description claire et directe du problème considéré. Elle offre, également, des mécanismes de décomposition de problèmes en sous-problèmes simples ce qui permet la réutilisation des solutions logiciel. L’idée principale repose sur l’identification des problèmes communs et simples qui peuvent être utilisés comme des patterns (patrons) sur lesquels les grands problèmes doivent être décomposés. Michael Jackson a identifié les principales classes de problèmes qu’on trouve dans le développement de logiciels. Chaque classe est capturée par un problem frame, en résultat cinq problem frames élémentaires ont été définis : required behavior PF, commended behavior PF,information display PF, workpiece PF, et transformation PF. En outre, d’autresproblem frames ont été proposés dans la littérature.

Une étude approfondie de l’ensemble des problem frames existants nous a permisd’identifier les classes de problèmes non encore complètement cernés par les problem frames existants. Dans le cadre de ce travail, la contribution que nous avons proposé se répartit selon deux niveaux :

Le premier niveau concerne la définition et la caractérisation d’un nouveau problem frame ; le problem frame proposé « The Archivist » a été validé sur deux études de cas : système de détection des intrusions et système de gestion des boites noires des avions.

Le deuxième niveau concerne la proposition d’une approche de combinaison entre le problem frame proposé et le langage de modélisation graphique UML.

Mots clés : Ingénierie de logiciels, Spécification de besoin, Problem frames (PF), UML.

Abstract

The problems to be solved by software development are primarily related to the environment in which this software will be used. Therefore, software developers must first determine the characteristics of this environment and its constraints.

Recently, Problem Frames (PF) are introduced as a framework of classifying, analyzing and structuring the problems. Introduced by Mickael Jackson, problem frames approach provides diagrams; notations and concepts to describe frequently met problem structures of different kinds. It also provides the mechanisms of problems decomposition into simpler and smaller sub-problems which allows the reuse of software solutions. The main idea is based on identifying common and simple problems that can be used as patterns on which the complex problems must be broken. Michael Jackson has identified several basic classes of problems found in software development. Each class is captured by a frame problem; in result, five basic problem frames were defined: required behaviour PF, commended behaviourPF, information display PF, workpiece PF and transformation PF. In addition, other proposed problem frames have appeared in the literature.

In-depth study on major existing problem frames enables us to identify classes of problems not yet completely surrounded by the existing problem frames. In the context of this work, the proposed contribution is divided into two levels:

The first level concerns the definition of a new problem frame, the proposed problem frame « The archivist » was validated through tows case studies: network security and airplane flight.

The second level concerns the combination of the proposed problem frame with UML language in order to make further UML analysis and design feasible.

Keywords: Software engineering, Requirements specification, Problem frames,

UML.

ملخص

بالبیئة التي یستعمل إن البرامج المطورة لحل مختلف المشاكل المطروحة تتعلق تعلقا وثیقا بھا ھذا البرنامج لذلك وجب على مطوري البرامج معرفة مختلف خصائص و حیثیات البیئة

.التي یوجد بھا المشكل

ھم المقترحة من طرف جاكسون من بین أ) Problem Frames(تعتبر أطر المشاكل كما . الوسائل التي تسمح لنا بوصف و تصنیف و تحلیل المشاكل وكذا وصف البیئة الخاصة بھا

االستفادة منلنا یخوللى مجموعة مشاكل بسیطة و معروفة ماإتسمح لنا بتقسیم مشكل معقد .حلول مسبقة

م تذلكظافة إلى إ. أصناف للمشاكلقام جاكسون باقتراح خمسة أطر أساسیة لثمثیل خمسةلتمثیل أصناف المشاكل التي ال تستطیع في العدید من أعمال البحث العلمياقتراح أطر أخرى

.أطر جاكسون تمثیلھا

:اذ یمكن تقسیمھا إلى محورین أساسیین . في ھذا اإلطار تندرج المساھمة التي قمنا بھا

لتمثیل المشاكل ) The Archivist) (األرشیفي(یتمثل األول في اقتراح إطار جدید للمشاكل بسلوك نظام معین و مختلف الحاالت التي یمر التي نسعى فیھا لجمع وحفظ المعلومات الخاصة

.مدعمین ھذا االقتراح بأمثلة من الواقع. بھا ھذا النظام

لغة النمدجة طار المقترح و لجمع بین اإللطریقةأما فیما یخص المحور الثاني فنقترح فیھ .)UML(الموحدة

، (Problem Frames)ھندسة البرامج ، تحدید المتطلبات ، أطر المشاكل:الكلمات المفتاحیة ). UML(لغة النمدجة الموحدة

I

Table des matières

Table des matières I

Liste des figures IV

Chapitre 1

Introduction générale 1

Chapitre 2

Problem Frames pour l’ingénierie du logiciel 3

2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.2 Notions de base. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.2.1 La machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.2.2 Les phénomènes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2.3 Les domaines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.3 Problem Frames de Jackson . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.3.1 Représentation de l’approche . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.3.2 Les cinq Problem Frames élémentaires . . . . . . . . . . . . . . . . . . . 8 2.3.2.1 Required Behavior PF . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.3.2.2 Commanded Behavior PF . . . . . . . . . . . . . . . . . . . . . . . 9 2.3.2.3 Information Display PF . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.3.2.4 Workpiece PF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.3.2.5 Transformation PF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.4 La décomposition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.5 Travaux relatifs à l’approche de Problem Frames . . . . . . . . . . . . . . . . . 14 2.5.1 I. K. Bray, 2003 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.5.2 Lin et al, 2003 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . 15 2.5.3 Choppy et al 2004 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 2.5.3.1 Update problem frame . . . . . . . . . . . . . . . . . . . . . . . . . . 16 2.5.3.2 Le PF Query . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . 17 2.5.4 Brier et al, 2004 . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . 18 2.5.5 Rapanotti et al, 2004 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.5.5.1 Pipe-and-Filter AFrame . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.5.5.2 MVC AFrame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.5.6 Laney et al, 2004 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.5.7 Survey de Cox et al, 2005 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 2.5.8 Divers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . 24 2.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . 24

Table des matières II

Chapitre 3

Développement de logiciel à base de Problem Frames et UML 26

3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 3.2 Description générale de l’approche de combinaison PF-UML . . . . . . . . 26 3.2.1 Modélisation du domaine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 3.2.2 Spécification de besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 27 3.2.3 Spécification de conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 3.3 UML pour commanded behavior PF . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 3.3.1 Etude de cas: système de contrôle d’ascenseur . . . . . . . . . . . . . . 28 3.3.2 Modélisation du domaine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 3.3.2.1 Modèle UML utilisé : présentation générale . . . . . . . . . . . 28 3.3.2.2 Modélisation du domaine : système de contrôle

d’ascenseur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 3.3.3 Spécification de besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 3.3.3.1 Modèle UML utilisé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 3.3.3.1.1 Diagramme de cas d’utilisation . . . . . . . . . . . . . . 31 3.3.3.1.2 Diagramme de classe . . . . . . . . . . . . . . . . . . . . . 32 3.3.3.2 Spécification de besoins du système de contrôle

d’ascenseur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 3.3.3.2.1 Diagramme de case d’utilisation . . . . . . . . . . . . . 32 3.3.3.2.2 Diagramme de classe . . . . . . . . . . . . . . . . . . . . . 33 3.3.3.2.3 Descriptions de cas d’utilisation . . . . . . . . . . . . . 34 3.3.4 Spécification de conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 3.4 UML pour required behaviour PF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 3.4.1 Etude de cas: système de contrôle de vanne d’eau . . . . . . . . . . . 36 3.4.2 Modélisation du domaine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 3.4.3 Spécification de besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 3.4.4 Spécification de conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 3.5 UML pour commanded information PF . . . . . . . . . . . . . . . . . . . . . . . . . . 39 3.5.1 Etude de cas: système d’information . . . . . . . . . . . . . . . . . . . . . . 39 3.5.2 Modélisation de domaine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 3.5.3 La spécification de besoin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 3.5.3. 1 Diagramme de case d’utilisation . . . . . . . . . . . . . . . . . . . 41 3.5.3. 2 Diagramme de classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 3.5.3.3 Descriptions de cas d’utilisation . . . . . . . . . . . . . . . . . . . . 42 3.5.4 La spécification de conception . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 3.6 UML pour rich Workpieces PF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 3.6.1 Etude de cas: système d’assistance plomberie (Plumbers Frind) . 46 3.6.2 La modélisation du domaine . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 3.6.3 La modélisation de besoin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 3.6.3.1 Diagramme de case d’utilisation . . . . . . . . . . . . . . . . . . . 48 3.6.3.2 Diagramme de classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 3.6.3.3 Descriptions de cas d’utilisation . . . . . . . . . . . . . . . . . . . . 50

Table des matières III

3.6.4 La spécification de conception . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 3.7 UML pour transformation PF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 3.7.1 Etude de cas: analyseur des emails . . . . . . . . . . . . . . . . . . . . . . . 53 3.7.2 Modèle du domaine et spécification de besoins . . . . . . . . . . . . . . 54 3.7.3 La spécification de conception . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 3.8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

Chapitre 4

Contribution à l’approche Problem Frames 57

4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 4.2 Description détaillée du problem frame proposé . . . . . . . . . . . . . . . . . . 57 4.2.1 Définition et notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 4.2.2 Comparaison entre « Archivist » et les cinq PF M. Jackson . . . . 58 4.2.2.1 «Archivist» PF vs. required behavior PF . . . . . . . . . . . . 58 4.2.2.2 «Archivist» PF vs. commanded behaviour PF . . . . . . . . 59 4.2.2.3 «Archivist» PF vs. workpeice PF . . . . . . . . . . . . . . . . . . 59 4.2.2.4 «Archivist» PF vs. display information PF . . . . . . . . . . . 59 4.2.2.5 «Archivist» PF vs transformation PF . . . . . . . . . . . . . . . 60 4.3 Domaine d’application de l’Archivist problem frame . . . . . . . . . . . . . . 60 4.3.1 Etude de cas n°1 : Système de détection des intrusions . . . . . . . . 60 4.3.2 Etude de cas n°2 : Les boites noires des avions . . . . . . . . . . . . . . 62 4.4 UML pour l’Archivist problem frame . . . . . . . . . . . . . . . . . . . . . . . . . . 63 4.4.1 Modélisation du domaine : Présentation générale . . . . . . . . . . . . 64 4.4.2 Modélisation du domaine : Boite noire des avions . . . . . . . . . . . 64 4.4.3 Spécification de besoin : Présentation générale . . . . . . . . . . . . . . 64 4.4.3.1 Diagramme de cas d’utilisation . . . . . . . . . . . . . . . . . . . . 64 4.4.3.2 Description de cas d’utilisation . . . . . . . . . . . . . . . . . . . . 65 4.4.3.3 Diagramme de classe . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 4.4.4 Spécification de besoin : Boite noire des avions . . . . . . . . . . . . . 66 4.4.4.1 Diagramme de cas d’utilisation . . . . . . . . . . . . . . . . . . . . 66 4.4.4.2 Description de cas d’utilisation . . . . . . . . . . . . . . . . . . . . 67 4.4.4.3 Diagramme de classe . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 4.4.5 Spécification de conception : Présentation générale . . . . . . . . . . 69 4.4.6 Spécification de conception : Boite noire des avions . . . . . . . . . . 69 4.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

70

Chapitre 5

Conclusion générale 71

Bibliographie 73

IV

Liste des figures

FIG. 2.1 – Diagramme général d’un problem frame (figure extraite de [27]). 6

FIG. 2.2 – Les préoccupations de base d’un problem frame 8

FIG. 2.3 – Diagramme du Required Behaviour problem frame (figure extraite de [24]). 9

FIG. 2.4 – Diagramme du Commanded Behaviour problem frame (figure extraite de [24]). 10

FIG. 2.5 – Diagramme du Information Display problem frame (figure extraite de [24]). 10

FIG. 2.6 – Diagramme du Workpiece problem frame (figure extraite de [24]). 11

FIG. 2.7 – Diagramme du Transformation problem frame (figure extraite de [24]). 12

FIG. 2.8 – Diagramme du Simulator problem frame (figure extraite de [8]). 14

FIG. 2.9 – Modélisation des menaces par Abuse problem frame (figure extraite de [32]). 15

FIG. 2.10 – Diagramme de Update problem frame (figure extraite de [11]). 16

FIG. 2.11 – Diagramme de Query problem frame (figure extraite de [11]). 17

FIG. 2.12 – Diagramme général d’un problem frame modélisant le système sociotechnique (figure extraite de [18]).

18

FIG. 2.13 – Diagramme de Pipe-and-Filter Aframe avec l'annotation (figure extraite de [36]). 19

FIG. 2.14 – Représentation du Pipe-and-Filter Aframe avec la recomposition proposé dans [36]). 20

FIG. 2.15 – Diagramme de MVC Aframe avec l'annotation (figure extraite de [36]). 20

FIG. 2.16 – Représentation du MVC Aframe avec la recomposition proposé dans [36]. 21

FIG. 2.17 – Modélisation du comportement Préprogrammé par Required behaviour PF (figure extraite de [29]).

22

FIG. 2.18 – Modélisation du comportement Intéractif par Commended behaviour PF (figure extraite de [29]).

22

FIG. 2.19 – Composition frame du système de contrôle de vanne (figure extraite de [29]). 23

FIG. 3.1 – Commanded Behaviour : exemple de l’ascenseur (figure extraite de [10]). 28

FIG. 3.2 – Commanded Behaviour : modélisation du domaine (figure extraite de [10]). 29

FIG. 3.3 – Système de contrôle d’ascendeur : modélisation du domaine−diagramme de classe (figure extraite de [10]).

30

FIG. 3.4 – Système de contrôle d’ascendeur : modélisation du domaine−diagramme d’état (figure extraite de [10]).

30

FIG. 3.5 – Commanded behaviour : spécification de besoins−diagramme de cas d’utilisation (figure extraite de [10]).

31

FIG. 3.6 – Commanded behaviour : spécification de besoins−diagramme de classe (figure extraite de [10]).

32

FIG. 3.7 – Système de contrôle d’ascenseur : spécification de besoins−diagramme de cas d’’utilisation (figure extraite de [10]).

33

Liste des figures

V

FIG. 3.8 – Système de contrôle d’ascenseur : spécification de besoins−diagramme de classe (figure extraite de [10]).

33

FIG. 3.9 – Système de contrôle d’ascenseur : spécification de besoins−description de cas d’appel de l’ascenseur à l’étage f (figure extraite de [10]).

34

FIG. 3.10 – Commanded Behaviour problem frame : spécification de conception (figure extraite de [10]).

35

FIG. 3.11 – Système de contrôle d’ascenseur : spécification de conception−diagramme d’état du cas d’appel de l’ascenseur (figure extraite de [10]).

35

FIG. 3.12 – Modélisation du système de contrôle d’une vanne d’eau par Required Behaviour FP(figure extraite de [14]).

36

FIG. 3.13 – Required Behaviour FP : modélisation du domaine–diagramme de classe (figure extraite de [14]).

36

FIG. 3.15 – Système de contrôle d’une vanne d’eau: spécification de besoins (figure extraite de [14]).

38

FIG. 3.16 – Required Behaviour problem frame: spécification de conception–diagramme de classe (figure extraite de [14]).

38

FIG. 3.17 – Système de contrôle de vanne: spécification de conception (figure extraite de [14]). 39

FIG. 3.18 – Commanded Information problem frame (figure extraite de [14]). 39

FIG. 3.19 – Modélisation du système d’information d’une société par Commanded Information PF (figure extraite de [14]).

40

FIG. 3.20 – Système d’information d’une société : modélisation de domaine (figure extraite de [14]).

40

FIG. 3.21 – Commanded Behaviour PF : spécification de besoins diagramme de cas d’utilisation (figure extraite de [14]).

41

FIG. 3.22 – Commanded Behaviour PF : spécification de besoins–diagramme de classe (figure extraite de [14]).

42

FIG. 3.23 – Commanded Behaviour PF : spécification de besoins description de cas d’utilisation (figure extraite de [14]).

42

FIG. 3.24 – Système d’information d’une société : spécification de besoins diagramme de cas d’utilisation (figure extraite de [14]).

43

FIG. 3.26 – Système d’information d’une société : Diagramme d’état du cas « Show product quantty sold in a period » (figure extraite de [14]).

43

FIG. 3.25 – Système d’information d’une société : spécification de besoins diagramme de classe (figure extraite de [14]).

44

FIG. 3.27 – Commanded Behaviour PF : spécification de conception–vue statique (figure extraite de [14]).

45

FIG. 3.28 – Diagramme Rich Workpieces problem frame (figure extraite de [14]). 46

FIG. 3.29 – Modélisation du système d’assistance plomberie par Rich Workpieces problem frame (figure extraite de [14]).

46

FIG. 3.30 – Rich Workpieces problem frame : modélisation du domaine (figure extraite de [14]). 47

FIG. 3.31 – Système d’assistance plomberie : modélisation du domaine (figure extraite de [14]). 48

FIG. 3.32 – Rich Workpeices problem frame : spécification de besoins diagramme de cas d’utilisation (figure extraite de [14]).

49

Liste des figures VI

FIG. 3.33 – Rich Workpeices problem frame : spécification de besoins–diagramme de classe (figure extraite de [14]).

49

FIG. 3.34 – Système d’assistance plomberie : spécification de besoins diagramme de cas d’utilisation (figure extraite de [14]).

50

FIG. 3.35 – Système d’assistance plomberie : diagramme de classe du cas « création d’une facture » (figure extraite de [14]).

51

FIG. 3.36 – Système d’assistance plomberie : diagramme d’état du cas « création d’une facture » (figure extraite de [14]).

52

FIG. 3.37 – Rich Workpieces problem frame : spécification de conception (figure extraite de [14]). 53

FIG. 3.38 – Modélisation de l’analyseur des emails par Required Behaviour PF (figure extraite de [14]).

53

FIG. 3.39 – Transformation PF : modélisation du domaine et spécification de besoins (figure extraite de [14]).

54

FIG. 3.40 – Analyseur des emails : modélisation du domaine et spécification de besoins (figure extraite de [14]).

54

FIG. 3.41 – Transformation problem frame : spécification de conception (figure extraite de [14]). 55

FIG. 4.1 – Diagramme de l’Archivist problem frame. 58

FIG. 4.2 – Modélisation d’un IDS par l’Archivist problem frame. 62

FIG. 4.3 – Modélisation de la boite noire de l’avion par l’Archivist problem frame. 63

FIG. 4.5 – Archivist PF : Spécification de besoin−Diagramme de cas d’utilisation. 65

FIG. 4.6 – Archivist PF : Spécification de besoin−Description de cas d’utilisation. 65

FIG. 4.7 – Archivist PF : Spécification de besoin−Diagramme de classe. 66

FIG. 4.8 – Boite noire des avions : Spécification de besoin−Diagramme de cas d’utilisation. 67

FIG. 4.9 – Boite noire des avions : Spécification de besoin−Description de cas d’utilisation. 67

FIG. 4.10 – Boite noire des avions : Spécification de besoin−Diagramme de classe. 68

FIG. 4.11 – Archivist PF : Spécification de conception 69

FIG. 4.12 – Boite noire des avions : Spécification de conception 70

1

Chapitre 1

Introduction générale

La complexité des petits programmes est telle qu’une seule personne peut la maîtriser et traiter toute seule le problème de bout en bout. De plus, elle est à même de mémoriser toutes les décisions prise lors de la conception et donc d’apporter par la suite toute modification au logiciel terminé. Il en va tout autrement en ce qui concerne les gros logiciels dont la complexité est telle qu’il n’est plus possible à une seule personne d’en assurer le développement ni d’en connaître toutes les finesses. Le développement devra donc être organisé et coordonné; les personnes en charge du développement devront documenter leur travail de manière exhaustive et standardisée, et les différentes tâches du développement devront être soigneusement synchronisées. En un mot: le projet doit être bien géré.

Une discipline appelée génie logiciel (software engineering) s’occupe de cette activité de la science et de l’industrie informatique. Le génie logiciel propose aux informaticiens de nouvelles techniques et de nouvelles méthodologies spécialement destinées au développement de gros logiciels. Donc on ne parle pas de programmation de logiciel, on parle alors d’un projet de développement de logiciel avec toutes un processus de développement.

Plusieurs d’études ont montré que les échecs dans la mise en œuvre et l’utilisation des systèmes informatiques sont dus à une mauvaise compréhension des besoins auxquels ces systèmes tentent de répondre. Le sous discipline du génie logiciel qui s’occupe de cette préoccupation est l’Ingénierie de Besoin. Il représente le processus qui s’intéresse à la première activité dans le cycle de développement de systèmes logiciels, activité durant laquelle l’ingénieur des besoins cherche à obtenir une compréhension établie en termes de modèles du futur système aussi complète et cohérente que possible avant le passage aux activités de conception et d’implémentation. L’ingénierie de besoin présente alors une étape primordiale dans un projet de développement de système. Sous-estimer cette étape peut mener à l’inachèvement des projets, au dépassement de leurs budgets ou à la défaillance des systèmes développés. Au niveau de cette étape, plusieurs approches de développement ont été proposées. Récemment, l’approche de Problem Frames (PF) (schémas de problèmes) est introduite comme moyen de classification, d’analyse et de structuration de problèmes. Cette nouvelle approche ne permet pas seulement d’identifier les besoins du futur système, mais aussi de réduire les efforts de développement grâce à sa classification des problèmes. L’idée principale repose sur l’identification des problèmes communs et simples qui peuvent être utilisés comme des patterns (patrons) sur lesquels les grands problèmes doivent être décomposés ce

Introduction générale 2

qui permet la réutilisation des solutions de problèmes existants pour un nouveau problème de la même classe.

Michael Jackson, le fondateur de cette approche, a défini cinq problem frames élémentaires: required behaviour PF, commended behaviour PF, information display PF, workpiece PF, et transformation PF. Par la suite, d’autres problem frames ont été proposés dans la littérature.

Le résumé de l’ensemble de problem frames, qui ont à notre disposition, mène à la conclusion suivante : les problem frames existants ne couvrent pas la totalité des problèmes rencontrés dans le développement de logiciel et ce domaine présente une voie de recherche ouverte. C’est dans le cadre de ce contexte que s’inscrit notre travail de recherche qu’on peut définir globalement comme une contribution à l’approche de problem frames. En effet, la première partie de notre contribution vient compléter les problem frames de la littérature par un nouveau PF que nous l’appelons « Archiviste problem frame ».

D’autre part, malgré les avantages multiples de l’approche problem frame, ses moyens de modélisation ne couvrent pas tous les aspects du problème ce qui ne permettre pas d’aller très loin dans le processus de développement. Pour cette raison la combinaison de cette approche avec d’autres approches de développement est nécessaire. Dans ce contexte, nous proposons une méthode de développement qui se à base sur une combinaison de Archivist PF et du langage de modélisation graphique UML.

Après cette introduction (chapitre 1), nous présenterons, dans le chapitre 2, les concepts, les notations et les diagrammes de l’approche problem frame ainsi que les cinq problem frames de Jackson. Ce chapitre inclut également un état de l’art relatif à l’approche problem frame.

Dans le chapitre 3, nous nous intéresserons plus particulièrement à une direction de recherche prometteuse dans le domaine de problem frame qui est la combinaison de cette approche et du langage UML.

Dans le chapitre 4, nous définirons le problem frame proposé et nous validerons cette proposition à travers deux études de cas : système de détection des intrusions et système de gestion des boites noires des avions. Nous présenterons également une poursuite de la modélisation à base de l’Archivist PF qui exploite la richesse et la puissance d’expression du langage UML.

Finalement, nous présenterons, dans le dernier chapitre de ce mémoire, nos conclusions sur nos apports à l’approche de problem frame, et des perspectives de poursuite de notre recherche.

3

Chapitre 2

Problem Frames dans l’ingénierie de

besoins

2.1 Introduction

Des études effectuées dans le domaine de l’ingénierie des logiciels ont montré que, le plus souvent, l’échec du développement est dû à une mauvaise compréhension des besoins auxquels le système tente de répondre. L’ingénierie des besoins est l’étape qui s’intéresse à la définition des besoins de la façon la plus méthodique, complète et cohérente possible.

La satisfaction des besoins exige la prise en compte de toutes les propriétés de l’environnement qui vont influer sur le système. Dans [21], Michael Jackson décrit trois principaux éléments permettant de construire un modèle du futur système: les besoins, le système et les propriétés du domaine. Un domaine est défini par l’ensemble des connaissances relatives à un champ d’application.

Dans ce contexte, M. Jackson introduit les Problem frames « PF » (ou schémas de problèmes) comme un moyen de classification, d’analyse et de structuration de domaine de problèmes. Dans ce chapitre, nous allons mettre l’accent sur cette nouvelle approche comme elle a été définie par M. Jackson.

2.2 Notions de base

2.2.1 La machine

Le but de l’ingénierie de logiciel est de développer des logiciels pour résoudre les différents problèmes existants. Certains problèmes sont de nature abstraite dans le sens mathématique, c’est-à-dire qu’ils résident dans un monde platonique ; tel que la résolution d’une équation de deuxième degré où on ne manipule que des nombres. Cependant, la majorité des problèmes résident dans un monde réel de nature physique où on traite et interagit avec des entités physiques, telles que les boutons, les automobiles, les comptes bancaires, les consommateurs,…etc. On appelle la solution de ce deuxieme type de problème « la machine ».

Problem Frames dans l’ingénierie de besoins

4

Il est donc très important de décrire l’environnement dans lequel la machine doit résider car le but de cette machine est d’influencer et d’interagir avec cet environnement, en focalisant sur tout ce qui concerne la machine dans cet environnement.

2.2.2 Les phénomènes

Pour analyser un problème donné du monde réel, il faut analyser les différents phénomènes dans ce monde, car le but est de construire une machine qui interagit avec son environnement à travers les différents phénomènes qui caractérisent cet environnement. On peut distinguer deux types des phénomènes dans un environnement donné : les individus et les relations entre ces individus.

On a comme individus :

− Les valeurs (V) : qui sont des individus statiques (immutable), tel que les entiers, les chaînes de caractères…etc. Par exemple, 100 est une valeur qui représente le degré de vaporisation de l’eau.

− Les entités (N) : sont des individus dynamiques qui se changent tout le temps, tels que les êtres humains, les automobiles, les boutons…etc.

− Les événements (E) : sont des opérations qui se produisent de temps en temps, par exemple l’ouverture d’une porte, la pression d’un bouton…etc.

Les différentes relations entre ces individus sont :

− Les états (S) : représentent les situations d’une entité. On peut détecter le changement d’une entité donnée par le changement de ses états. Par exemple, la porte ouverte représente l’état d’une porte.

− Les rôles (R) : sont les relations indiquant la participation d’un individu dans un événement. Par exemple, la relation ‘is BUttonIn(b,p)’ exprime le rôles d’un bouton ‘b’ dans l’événement de pression.

− Les vérités (U) : ce sont les relations inchangeables. Par exemple, la relation ‘x>y’ entre les entiers.

On peut classer ces différents individus selon deux catégories : − les phénomènes contrôlables et − les phénomènes symboliques. La première catégorie concerne les événements, les rôles et les états décrivant les entités. Ces éléments sont causés et contrôlés directement par une partie du monde où ils résident. Par exemple, le conducteur d’une voiture peut causer l’événement de freinage. La deuxième catégorie concerne les valeurs, les vérités, et les états. Ces phénomènes symbolisent d’autres phénomènes ainsi que les relations entre eux.

Développement orienté modèles de logiciel à base de « Problem Frames »

5

En se basant sur ces phénomènes, on peut classifier les différentes parties du monde du problème ; par exemples, ceux qui sont de nature statique et qui se caractérisent par l’absence des événements et ont des états non changeables; et ceux qui sont de nature dynamiques et qui ont des états changeables à cause des différents événements qui se produisent dans ce monde.

2.2.3 Les domaines

Pour bien décrire le monde d’un problème donné il faut décrire les différentes parties qui le constituent. On appelle ces parties « Domaines ». Un domaine dans ce sens n’est pas une catégorie générale d’applications, tel que le domaine du système bancaire ou le domaine de contrôle d’un processus. Mais plutôt, un domaine présente une partie spécifique du contexte d’un problème particulier qui peut être étudié et décrit dans une isolation comparative [19]. Par exemple, dans un problème de contrôle d’un patient, le contexte est divisé en: patients, infirmiers, appareils de contrôles…etc. Chaque domaine a ses propres phénomènes et ses propres propriétés qui sont vues comme des relations entre ces phénomènes [20]. Les domaines peuvent partager des phénomènes. En effet, la seule façon que deux domaines interagissent est à travers ces phénomènes partagés.

L’interaction entre la machine et son environnement peut être vue à travers les différents phénomènes partagés entre la machine et les autres domaines constituant le monde du problème. Les états sont également partagés, car l’environnement est doté de capteurs qui offrent les différentes informations sur les états de l’environnement de la machine. Les événements sont aussi partagés car la machine et son environnement participent à chaque occurrence d’événement.

On peut classifier les différents domaines selon trois types :

− Des domaines causals : sont les domaines qui incluent des relations causales et prédictibles entre leurs différents phénomènes. Ces domaines sont généralement des équipements mécaniques ou électroniques qui ont des actions et des réactions prédictibles. Un domaine causal peut contrôler d’autres domaines et peut être lui aussi contrôlé par d’autres domaines. Par exemple, un moteur d’une automobile peut être démarré ou arrêté par le conducteur, il est alors contrôlé par ce dernier; ce moteur gére également la rotation des roues de la voiture, en d’autre terme, il contrôle les roues.

− Des domaines bidables : leur caractéristique principale est leur comportement non prédictible. Ils consistent généralement en des gens. Dans la plupart des cas, le comportement d’une personne n’est pas prédictible car c’est lui qui décide quand il doit initier une action. Par exemple, on ne peut pas forcer une personne à presser le bouton d’un ascenseur pour l’appeler.

− Des domaines lexicaux : un domaine lexical est généralement une représentation physique de données, tel qu’un fichier, une base de données…etc. Il combine spécifiquement les phénomènes symboliques et les phénomènes causals. Les


6

propriétés causales permettent l’écriture et la lecture de données. Ce type de domaine ne peut initier aucun événement. Cependant, via une interface donnée, les autres composants peuvent demander des services du domaine lexical, par exemple, la lecture et l’écriture de son contenu.

2.3 Problem Frames de Jackson

2.3.1 Représentation de l’approche

Michael Jackson a proposé une nouvelle approche pour la spécification et l’analyse des besoins appelée « Problem Frame, PF » [24]. Jackson a défini cette approche comme suit:

« A problem frame is a kind of pattern. It defines an intuitively identifiable problem class in terms of its context and the characteristics of its domains, interfaces and requirement. »

Les PFs se basent essentiellement sur la structuration et l’analyse du problème et du monde dans lequel ce problème réside. Cela se fait en identifiant les différentes parties du monde, les différents phénomènes et l’ensemble des besoins du problème traité.

Cette nouvelle approche ne permet pas seulement d’identifier nos besoins, mais aussi de réduire les efforts de développement grâce à sa classification des problèmes. Cette caractéristique permet la réutilisation et l’adaptation des solutions existantes d’un problème donné à un nouveau problème de la même classe.

Jackson a identifié les classes de base de problèmes qu’on trouve dans le développement de logiciels afin de les réutiliser dans l’analyse des besoins. Chaque classe est capturée par un problem frame. Le principe de cette approche est la décomposition d’un problème complexe en des sous problèmes familiers. Elle repose donc sur l’identification des problèmes communs et simples qui peuvent être utilisés comme des paternes (patrons) sur lesquels les grands problèmes doivent être décomposés. L’analyse repose içi sur le problème plutôt que sur la solution.

Pour chaque PF, un diagramme est établit. La figure 2.1 donne une représentation générale d’un PF.

Machine Requirement Problem world

a b

FIG. 2.1 – Diagramme général d’un problem frame (figure extraite de [27]).


7

Le système à développer est appelé machine, il est représenté par un rectangle avec une double barre. Les différents domaines constituants le monde du problème sont représentés par des rectangles simples.

La machine interagit avec le monde du problème (Problem world) à travers les différents phénomènes partagés «a» entre la machine et le monde du problème. Ils sont notés par une ligne continue reliant la machine et les différents domaines. Les besoins sont notés par un ovale pointillé indiquant leur qualité intangible car le besoin n’est pas une partie tangible du problème mais plutôt une condition sur le monde du problème que la machine doit le garantir. La ligne discontinue «b» entre les besoins et le monde du problème indique les phénomènes de besoin ; ces derniers présentent les phénomènes que l’utilisateur du système (le client) doit l’observer pour déterminer si les besoins sont satisfaits ou non. On distingue deux types de lignes discontinues qui relient les besoins avec les différents domaines : ceux qui sont simple et ceux qui sont dotées par une flèche. La flèche indique que le domaine est une contrainte de besoin, c’est-à-dire que la machine doit garantir que l’état ou le comportement de ce domaine satisfait le besoin. Une ligne discontinue sans flèche indique que le besoins fait référence à un phénomène d’un domaine donnée.

Bien que le produit final soit une description de la machine, une succession de résultats peut être rarement accomplie en décrivant que la machine [22]. En général, on a besoin de faire les descriptions suivantes :

− Le besoin (Requirement) R : représente la description explicite du comportement et des propriétés qu’on souhaite avoir comme résultat d’interaction entre le monde du problème et la machine. Elle s’exprime en terme de phénomène de besoin «b». Elle capture le but pour lequel la machine est développée. Par exemple, la propriété qu’un ascenseur arrive lorsqu’on appuie sur un bouton.

− Les propriétés du monde de problème (World properties) W : est une description des propriétés que le domaine possède intrinsèquement, sans se soucier du comportement de la machine. Par exemple, la propriété que depuis un étage n, l’ascenseur peut aller seulement vers l’étage n+1 ou n-1.

− La spécification de la machine S: est une description du comportement et des propriétés désirées de la machine vis à vis son interface avec le monde du problème. Elle est capturée à travers les différents phénomènes partagés « a ». Par exemple, quand on appuie sur le bouton n (dans certaines circonstances), la machine doit mettre le moteur en marche.

Ces trois descriptions présentent les trois préoccupations de base d’un PF.

Pour montrer que la machine satisfera les besoins, il est indispensable de montrer la relation suivante : S,W├ R [27].


8

Machine Requirement Problem world

a b

Spécification (S) Propriétés du monde de

problème(W)

Les besoins (R)

FIG. 2.2 – Les préoccupations de base d’un problem frame.

En d’autre terme, si la machine satisfait la spécification S qui est installée dans un monde du problème qui satisfait W, donc le besoin R sera également satisfait.

Exemple : si la machine détecte la pression du bouton Btn. Et si elle opère l’ascenseur et le moteur de la porte, tous en accordance avec la spécification, ainsi que la position d’ascenseur et son comportement sont en rapport avec les états des capteurs; et si les paramètres du moteur sont comme ils sont décrits dans la description des propriétés du domaine ; donc l’ascenseur arrive lorsqu’on appuie sur le bouton Btn.

2.3.2 Les cinq Problem Frames élémentaires

L’approche Problème Frame se base essentiellement sur la classification des problèmes en sous classes de problèmes. Chaque classe est représentée par un PF qui est considéré comme un paterne pour cette classe. Généralement, les classes capturées par cette approche sont de nature simple et de complexité réduite, elles ne sont pas très sophistiquées; un problème complexe doit alors être décomposé en sous problèmes. La spécification S, les propriétés des domaines W et le besoin R sont les trois préoccupations de base. Mais pour chaque classe de problème on a des préoccupations supplémentaires.

Dans [24], M. Jackson a proposé cinq problem frames de base pour modéliser cinq classes des problèmes: Required behaviour PF, Commended behaviour PF, Information display PF, workpiece PF et Transformation PF.

2.3.2.1 Required Behaviour PF

Jackson a défini ce PF comme suit : « There is some part of the physical world whose behaviour is to be controlled so that it satisfies certain conditions. The problem is to build a machine that will impose that control ».


9

Required Behaviour PF est proposé pour modéliser les problèmes où on a besoin de développer une machine qui assure le contrôle du comportement d’une partie du monde réel. Ce PF est illustré par la figure 2.3.

CM!C1

CD!C2

Controlled machine (CM)

Required bihavior

C

C3 Controlled Domain (CD)

FIG. 2.3 – Diagramme du Required Behaviour problem frame (figure extraite de [24]).

«CM» représente la machine qu’on doit développer pour assurer le comportement d’une partie du monde réel «CD». «Required behaviour» représente la condition qui doit être vérifiée par le comportement de «CD». Le domaine «CD» est de nature causale (cela est indiqué par le petit C dans le coint inférieure gauche), son comportement est contrôlé par les différentes opérations et événements «C1» fournis par la machine «CM». Généralement, le contrôle est assuré par les différents actionneurs installés dans le système . Les phénomènes «C2» représentent les différents phénomènes que le «CD» doit fournir à la machine, tels que les états de ce domaine. Ces états sont fournis par les différents capteurs installés dans le système. A travers ces capteurs, la machine doit émettre les commandes nécessaires pour contrôler le comportement de «CD». Les besoins sont exprimés à travers les phénomènes «C3».

2.3.2.2 Commanded Behaviour PF

Commanded Behaviour PF a été défini par M. Jackson comme suit: «There is some part of the physical world that has to be controlled, in accordance with commands issued by an operator. The problem is to build a machine that will accept the operator’s commands and impose the control accordingly».

Commanded Behaviour PF est proposé pour modéliser les problèmes dans lesquels on a besoin de développer une machine pour commander une partie du monde réel en accordance avec les commandes fournies par un opérateur.


10

B

CControlled Controlled Domain (CD)

OP!E4 E4

CM!C1 CD!C2

C3

Operator (OP)

Commanded behavior

Controlled Machine (CM)

FIG. 2.4 – Diagramme du Commanded Behaviour problem frame (figure extraite de [24]).

La figure 2.4 décrit le diagramme du Commanded Behaviour PR. Le «CM» est la machine qu’on doit développer pour contrôler le comportement du domaine «CD». La machine doit fournir les différents événements et opérations C1 pour commander le comportement de «CD». Ce PF est similaire à celui de Requiered Behaviour sauf l’ajout de l’opérateur dans Commanded Behaviour PR. Cet opérateur fournit des commandes à la machine pour assurer un certain comportement du domaine «CD». Ces commandes sont illustrées dans le diagramme de la figure 2.4 par les phénomènes partagés E4 qui représentent également les phénomènes de besoin concernant l’opérateur. Le comportement du domaine «CD» est exigé dans les besoins, cela est montré par la flèche discontinue qui relie les besoins avec le «CD» (voir la figure 2.4).

2.3.2.3 Information Display PF

Jackson a défini le problem frame Information Display comme suit : «There is some part of the physical world about whose states and behaviour certain information is continually needed. The problem is to build a machine that will obtain this information from the world and present it at the required place in the required form «.

C

CControlled

Real World (RW)

IM!E2 Y4

RW!C1 C3

Display (DP)

Display ~ Real World Information

Machine (IM)

FIG. 2.5 – Diagramme du Information Display problem frame (figure extraite de [24]).


11

Ce PF est proposé pour modéliser une classe de problèmes dans laquelle on développe une machine pour afficher continuellement des informations sur les états et le comportement d’une partie du monde réel. La figure 2.5 illustre le diagramme de ce PF.

«IM» est la machine à développer. Le domaine causal «RW» est la partie du monde physique dont ses états et son comportement doivent être, régulièrement, affichés. Les états et le comportement du monde réel sont modélisés par les phénomènes de besoin «C3». Ces informations sont transmises du «RW» vers la machine à travers les capteurs (les phénomènes «C1» dans la figure 2.5). La machine affiche ces informations dans une console d’affichage «DP» à travers les différents événements et opérations «E2» générés par la machine. Cet affichage respecte un certain format (entiers, messages…), les informations à afficher sont ainsi modélisées par les phénomènes symbolique «Y4». On note ici que la machine n’a aucune influence sur le comportement du «RW».

2.3.2.4 Workpiece PF

M. Jackson a défini le Workpiece PF comme suit : « A tool is needed to allow a user to create and edit a certain class of computable processable text or graphic objects or similar structures, so that they can be used subsequently copied, printed, analyzed or used in other ways. The problem is to build a machine that can act as this tool «.

Ce problem frame est proposé pour modéliser certains problèmes où on a besoin de développer une machine pour éditer/changer le contenu d’une structure de donnée (texte, graphique, fichier…etc.) en suivant les demandes fournies par l’utilisateur. La figure 2.6 illustre le diagramme du Workpiece PF.

B

XControlled Workpieces

(WP)

US!E3 E3

ET!E1 WP!Y2

Y4

User (US)

Commanded Effects Editing Tool

(ET)

FIG. 2.6 – Diagramme du Workpiece problem frame (figure extraite de [24]).

«ET» est la machine à développer. L’utilisateur «US» fournit les différents événements et opérations «E3» pour changer et éditer le contenu du workpiece «WP». Cela est assuré à travers les différentes routines et procédures de manipulation de «WP». Les phénomènes symboliques «Y2» représentent généralement les états du «WP» (la position d’une image, sa couleur…).


12

Ce PF ressemble un peu à celui du commanded behaviour PF à cause de l’introduction de l’utilisateur et de l’opérateur dans workpiece et commanded behaviour PFs respectivement : l’utilisateur et l’opérateur fournissent des opérations est des commandes à la machine. Mais la différence entre les deux problem frames est que dans le premier on a un domaine lexical à manipuler par contre dans le deuxième le domaine est de nature causale.

2.3.2.5 Transformation PF

La définition de M. Jackson pour Transformation PF est comme suit: « There are some given computable readable input files whose data must be transformed to give a certain required output files. The output data must be in particular format and it must be derived from the input data according to certain rules. The problem is to build a machine that will produce the required outputs ».

X

XControlled Inputs (IN)

TM!Y2

Y4

IN!Y1 Y3

Outputs (OU)

IO relation Transform

Machine (TM)

FIG. 2.7 – Diagramme du Transformation problem frame (figure extraite de [24]).

Transformation PF est proposé pour modéliser une classe de problèmes dans laquelle nous avons besoin de développer une machine capable d’assurer le transfère de données en entrée vers d’autres données en sortie en respectant certaines règles de transformation. Le diagramme du Transformation PF est illustré par la figure 2.7.

«TM» est la machine à développer. Nous avons deux domaines lexicaux : Inputs «IN» qui représente les données à transférer et l’Outputs «OU» qui est le résultat du transfère effectué. Tous les phénomènes du Transformation problem frame sont des phénomènes symboliques car ils représentent généralement la structure de données de l’Inputs «IN» et de l’Output «OU».

2.4 La décomposition

La décomposition de problèmes en sous-problèmes simples suit le principe de « divide-and-conquer », le but est d’identifier des sous problèmes plus petits et moins complexes ce qui permet la réutilisation des solutions logiciels. Dans ce contexte, trois décompositions interdépendantes sont identifiées :


13

− Un besoin peut être décomposé en un ensemble de sous besoins. Par exemple, le besoin « fournir les services d’un ascenseur » peut être décomposé en « commandes des utilisateurs » et « assurance des opérations saines »,..ect.

− Le monde du problème peut être décomposé en domaines. Par exemple, le monde du problème d’ascenseur peut être décomposé en bouton, porte,..ect.

− La machine peut être aussi vue comme un ensemble de sous machines. Dans l’exemple de l’ascenseur, on peut avoir une machine pour fournir les différents services d’ascenseur et une autre pour détecter les anomalies de fonctionnement.

Chaque sous problème est lui-même un problème dans le sens où il a sa propre machine, son propre monde du problème et ses besoins. Le principe est de décomposer le probleme initail en un ensemble de sous problèmes correspondent à des classes de problèmes connus et facilement résolus. Leurs solutions contribuent alors à la solution globale du problème original. Ainsi, chaque classe est représentée par un PF qui est considéré comme pattern de cette classe de problème.

A titre d’exemple, on peut décomposer le problème de l’ascenseur en deux sous problèmes connus: le premier est celui de commandement d’ascenseur par un utilisateur, ce problème est modélisé par Commanded behaviour PF. Et le deuxième problème est celui de l’affichage des différents états de l’ascenseur modélisé par Information display PF.

Cette décomposition diffère des autres approches de décomposition [25] en plusieurs points:

− Elle est parallèle plutôt que hiérarchique,

− Dans la décomposition traditionnelle, l’analyse de l’interaction entre les différents sous problèmes est effectuée au même temps que l’identification des sous problèmes. Par contre, dans l’approche «problem frame», l’identification des sous problèmes est effectuée en premier lieu indépendamment de leur interaction.

Les deux conséquences majores de cette approche sont [26] :

− L’identification des sous problèmes indépendamment des préoccupations de composition nous permet d’appliquer les techniques existantes pour chacun de ces sous problèmes dans la résolution du problème global.

− Les préoccupations de composition sont différées jusqu’à ce que les sous problèmes soient bien compris.

Une fois les sous problèmes sont identifiés et résolus, il est indispensable de recomposer leurs solutions pour contribuer à la solution du problème original. Ainsi, les besoins des sous problèmes peuvent être combinés par des conjonctions logiques, et les machines des sous problèmes par une exécution concurrente.


14

Pour des cas particuliers de décomposition, les sous problèmes peut avoir des phénomènes en commun créant par conséquant des interactions potentielles qui doivent être traitées lors de la décomposition. Généralement, certaines préoccupations de composition apparaissent lorsqu’on a des parties de sous problèmes communes telles que :

− L’interférence : le problème est posé lorsqu’on a un sous problème qui crée des changements dans un domaine d’un autre problème pendant qu’un autre l’utilise (problème d’exclusion mutuelle).

− L’ordonnancement : dans certain cas, l’exécution des sous machines doit suivre un ordre précis.

− Le conflit : deux sous problèmes peuvent avoir des conflits ente eux. Par exemple dans un ascenseur les deux sous besoins «offre les services d’ascenseur aux utilisateurs» et «assurer des opérations saines « peuvent avoir des conflits.

2.5 Travaux relatifs à l’approche de Problem Frames

Aprés avoir identifier les conceptes de base de la proche de problem frames ainsi que les cinq problem frames de base de Michael Jackson, nous présenterons,dans cette section, quelques travaux effectués dans ce domaine de recherche.

2.5.1 I. K. Bray, 2003

Dans [8], Ian K Bray introduit un nouveau problem frame qu’il nomme « Simulator problem frame » et propose de l’utiliser pour modéliser les problèmes de simulation. Dans ce type de problème, le but est de construire un produit artificiel qui simule un phénomène réel. La figure suivante illustre la représentation graphique de ce PF.

FIG. 2.8 – Diagramme du Simulator problem frame (figure extraite de [8]).

Le « simulacrum » est le domaine à construire, il se comporte conformément au comportement exigé « required behaviour » qui ressemble à celui du système original. Le « simulacrum » présente alors une simplification ou une approximation


15

du système original. Pendant l’opération de simulation la machine n’a aucune communication avec le système original (pas de phénomènes partagés entre eux).

Dans son travail, I. K. Bray montre les points de différence entre Simulator PF et les cinq PF de base proposés par M. Jackson.

2.5.2 Lin et al, 2003

Dans [32], Lin et al proposent un nouveau problem frame : « Abuse PF » pour modéliser le problème de sécurité. Leur proposition se base sur le concept d’anti-besoin (anti-requirement AR). L’anti-besoin représente les besoins d’un utilisateur malicieux qui subvertit un besoin existant. Ce concept définit l’ensemble de phénomènes indésirables imposés par un utilisateur malicieux et qui mènent le système à un état contradictoire avec les besoins désirés du système.

FIG. 2.9 – Modélisation des menaces par Abuse problem frame (figure extraite de [32]).

Pour modéliser une menace selon le principe de problem frames, on distingue les éléments suivants :

− Le domaine de la machine : contient les vulnérabilités de l’utilisateur malicieux exploités pour effectuer son attaque.

− Le domaine de la victime identifie les objets attaqués.

− L’utilisateur malicieux.

− Les phénomènes E1 représentent les phénomènes indésirables du domaine de la victime.

Le diagramme de Abuse problem frame est illustré par la figure 2.9.


16

2.5.3 Choppy et al, 2004

Plus récemment Ch. Choppy et al introduisent dans [11] une nouvelle méthode de développement des systèmes d’information. Cette méthode se base sur une combinaison des approches suivantes : problem frame , cas d’utilisation et scénarios, style d’architecture, ingénierie du logiciel basée sur les composants.

Dans ce contexte, les auteurs difinissent deux problem frames pour modéliser les systèmes d’information : update PF et query PF ; ces deux problem frames présentent une extension des deux PFs workpieces et Information display respectivements. Puis, ils décrivent leur démarche de développement qui permet de concilier les bénéfices apportés par les concepts structurants des probleme frames et des styles d’architecture, ainsi que les concepts d’intégration des composants, avec les bases solides apportées par les spécifications formelles [11].

2.5.3.1 Update problem frame

Update PF est proposé pour modéliser le problème de mise à jour de données. Dans ce type de problème, deux opérations de mise à jour ne peuvent pas s’effectuer en même temps, on doit alors utiliser un « verrou » pour empêcher l’exécution simultanée de ces opérations afin de garantir la cohérence de données.

Le PF proposé est considéré comme une extension de workpieces PF . La figure 2.10 illustre le diagramme de update PF.

FIG. 2.10 – Diagramme de Update problem frame (figure extraite de [11]).

La base de données est représentée par le domaine lexical DBM ( DataBase Model); l’utilisateur qui émet les commandes de mise à jour est modélisé par le domaine biddable UPDATE USER. FEEDBACK OUTPUT représente la sortie de rétroaction vers l’utilisateur. Les besoins sont exprimés par les règles de mise à jour. Les interfaces que nous identifions prennent en compte le fait qu’une opération de


17

mise à jour peut être précédée par une requête afin de vérifier que ses préconditions sont vérifiées.

− E4 (aussi dans UU!E4) commande de l’utilisateur impliquant une mise à jour.

− E1 (dans UM!E1) phénomène de requête ou de mise à jour contrôlé par la machine.

− Y2 (dans DBM!Y2) messages d’information sur l’état de la base de données (et sur son historique).

− Y3 (dans UM!Y3) message de sortie contrôlé par la machine informant du succès ou des raisons d’échec de la commande de l’utilisateur

− Y5 effets de la commande de l’utilisateur sur la base de données, en accord avec les règles de mise à jour, et exprimés par des valeurs de données

− Y6 effets de la commande de l’utilisateur sur les messages de sortie, en accord avec les règles de mise à jour, et exprimés par des valeurs de données.

On notera que les interfaces étiquetées par Y5 et Y6 comportent des flèches vers le modèle de base de données et la sortie utilisateur qui expriment des contraintes.

2.5.3.2 Query problem frame

Query PF est proposé pour modéliser le problème de consultations de données dans une base de données.

Dans ce type de problème, plusieurs opérations de consultation peuvent s’effectuer simultanément. La figure 2.11 montre la modélisation de ce probleme par Query PF. Ce dernier présente une extension de Information display PF proposé par M. Jackson.

FIG. 2.11 – Diagramme de Query problem frame (figure extraite de [11]).


18

Le domaine DBM représente la base de données, le domaine lexical output modélise les sorties vers l’utilisateur QUERY USER. Les besoins sont exprimés par les règles de requête, et la machine qui effectue la requête est à concevoir. Les interfaces identifiées par Choppy et al sont les suivantes :

− E4 (aussi dans QU!E4) commande de l’utilisateur impliquant une requête.

− E1 (dans QM!E1) phénomène de requête contrôlé par la machine.

− Y2 (dans DBM!Y2) messages d’information sur l’état de la base de données (et sur son historique).

− Y3 (dans QM!Y3) message de sortie contrôlé par la machine, réponse à la requête de l’utilisateur ou message d’erreur.

− Y5 informations sur l’état de la base de données en rapport avec la commande de l’utilisateur (en accord avec les règles des requêtes), exprimés par des valeurs de données.

− Y6 effets de la commande de l’utilisateur sur les données contenues dans les messages de sortie (en accord avec les règles des requêtes).

2.5.4 Brier et al, 2004

Dans [18], Brier et al discutent la modélisation des systèmes sociotechnique par l’approche problem frame. Dans ce type de systèmes, nous avons besoin de spécifier le comportement des composants sociaux avec celui de la machine. L’interface homme-machine est alors le résultat de l’interaction de la spécification de l’homme avec celle de la machine.

FIG. 2.12 – Diagramme général d’un problem frame modélisant le système sociotechnique (figure extraite de [18]).


19

L’extension du modèle de problem frame original se fait par l’introduction du knowledge domaine qui représente l’utilisateur (voir la figure 2.12). les auteurs introduisent «user interaction frame» pour capturer les problèmes de base du dialogue machine/ utilisateur.

2.5.5 Rapanotti et al, 2004

Dans [36], Rapanotti et al introduisent «Architectural Frames» (AFrames) comme un moyen de combinaison des classes de problèmes et des classes de softwares architectures.

Le AFrame capture la combinaison d’une classe de problèmes représentée par un problem frame et une classe de structures de solution représentée par les styles architecturaux (architectural styles). Il enrichit le diagramme du PF par une annotation supplémentaire du domaine de la machine introduisant ainsi une vision de la solution du problème basée sur un style architectural particulier. AFrames simplifient la tâche de la recomposition en indiquant comment les sous problèmes sont-ils regroupés ensemble et comment les préoccupations de la décomposition sont-elles traitées.

Dans ce travail, les auteurs proposent deux Aframes : « Pipe-and-Filter Aframe » et « MVC Aframe » (Model-View-Controller Aframe).

2.5.5.1 Pipe-and-Filter AFrame

Le Pipe-and-Filter Aframe est le résultat de la combinaison du style architectural «Pipe-and-Filter» et le problem frame transformation (voir le diagramme de transformation problem frame illustré par la figure 2.13)

FIG. 2.13 – Diagramme de Pipe-and-Filter Aframe avec l’annotation (figure extraite de[36]).

Le style architectural Pipe-and-Filter considère un système comme une série de filtre (transformation) appliquée sur des données en entrée (input). La forme adoptée ici est la forme linéaire (linear pipeline), dans laquelle chacun des filtres possède une


20

seule entrée et une seule sortie. Cet Aframe (voir la figure 2.14) permet la décomposition du problème en :

− Des sous-problèmes de transformations : chaque filtre représente un sous problème de transformation capturé par un transformation PF.

− Un sous problème d’ordonnancement (sheduling).

FIG. 2.14 – Représentation du Pipe-and-Filter Aframe avec la recomposition proposé dans

[36]).

2.5.5.2 MVC AFrame

Le MVC Aframe est le résultat de la combinaison de commended behaviour PF (voir la figure 2.15) avec le style architectural «MVC».

FIG. 2.15 – Diagramme de MVC Aframe avec l’annotation (figure extraite de [36]).

Le MVC (Model-View-Controller) est un style architectural utilisé pour structurer un logiciel à travers son interface utilisateur. La figure 2.16 illustre le diagramme de MVC Aframe, ses trois composants sont:


21

− Modèle (Model) : est une représentation abstraite du monde réel ou du domaine du système,

− Contrôleur (conroller) : le contrôleur interprète les entrées de l’utilisateur et les transforme en des commandes applicables sur le modèle pour effectuer le changement approprié.

− Vue (View) : s’occupe de l’affichage des résultats des traitements aux utilisateurs.

En se basant sur la discription de MVC Aframe, deux sous-problèmes sont définis :

− le sous-problème d’affichage : consiste à afficher les états et les représentations du modèle.

− le sous-problème de contrôleur : consiste à agir sur le modèle à travers les commandes des utilisateurs.

FIG. 2.16 – Représentation du MVC Aframe avec la recomposition proposé dans [36].

2.5.6 Laney et al, 2004

Dans [29], Laney et al proposent «Composition frames» pour décrire les besoins lors de la composition des solutions afin de traiter les effets indésirables de cette tâche.

Chaque sous problème est capturé par un problem frame. Composition frame inclut tous les domaines existants dans l’ensemble des sou-problèmes combinés y compris les domaines de la machine. Cependant, des conflits entre les besoin peuvent apparaitre, la mise en place d’un mécanisme pour résoudre ces conflits est alors indispensable.


22

Laney et al montrent l’utilité de ce PF à travers l’exemple du système de contrôle de vanne d’eau où on doit assurer les fonctionnalités suivantes :

− le comportement préprogrammé: La porte de la vanne doit être ouverte pendant dix minutes chaque trois heures, l’ouverture et la fermeture de la porte sont assurées par l’utilisation d’un moteur qui se tourne dans le sens des aiguilles d’une montre (clockw) ou dans le sens inverse (anti).

− le comportement interactif: un utilisateur peut intervenir pour élever, abaisser, ou arrêter le portail (raise, lower, stop).

FIG. 2.17 – Modélisation du comportement Préprogrammé par Required behaviour PF (figure extraite de [29]).

FIG. 2.18 – Modélisation du comportement Intéractif par Commended behaviour PF (figure

extraite de [29]).


23

La modélisation de ce système revient à la modélisation des deux sous-problèmes qui le constitue :

− Le comportement Préprogrammé (P) modélisé par Required behaviour PF (voir la figure 2.17).

− Le comportement interactif (OI) modélisé par Commended behaviour PF (voir la figure 2.18).

Il est clairement constaté que le comportement de deux machines peut mène à un conflit, par exemple lorsque la première machine ferme la vanne pendant que la deuxième l’ouvre. Pour résoudre ce conflit, Laney et al adoptent la configuration suivante :

− Permettre seulement à une des machines de produire des événements partagés avec le domaine de la Porte si ce domaine ne réagit pas actuellement sur l’autre machine.

− Établir des priorités entre les deux machines, afin qu’une des deux soit autorisée à produire des événements partagés avec le domaine de Porte bien que ce domaine réagit actuellement sur l’autre machine, mais non pas vice versa.

Afin d’assurer les besoin du système de contrôle de vanne, une machine appelée « controller » est introduite pour résoudre les problèmes de recomposition. Composition frame est constitué alors de tous les domaine existant y compris les sous machines ainsi que la machine controller (voir la figure 2.19).

FIG. 2.19 – Composition frame du système de contrôle de vanne (figure extraite de [29]).


24

2.5.7 Survey de Cox et al, 2005

Karl Cox et al introduisent, dans [16], un très bon Survey sur le domaine de recherche de Problem Frame. Ils tirent profit de l’avantage de cette approche dans l’ingénierie de logiciel et particulièrement dans l’ingénierie de besoin.

Dans la première partie de ce travail, les auteurs exposent les principes fondamentaux de l’approche problem frame, et ils discutent la différence entre cette approche et certaines d’autres approches connues dans l’ingénierie de logiciel telles que Analysis Patterns, Domain Theory, Use Cases,…etc.

La deuxième partie présente une démarche de modélisation d’un problème donné par l’approche problem frame. Elle inclue également un passage en revu de certain nombre de problem frames proposés dans la littérature. La décomposition de problèmes en sous-problèmes simples est également discutée avec une ouverture sur les propositions les plus prometteuses.

Une partie importante de ce survey est consacrée à l’exposition des propositions de combinaison de PF avec les autres approches de développement de logiciel. Afin de compléter le processus de développement, une démarche intéressante proposée par Choppy et al [14,10] consiste à combiner l’approche problem frame avec le langage de modélisation graphique UML. Une déscription détaillée de cette démarche présente l’objet du chapitre suivant.

Dans la derrière partie de ce Survey, les auteurs exposent des travaux de recherche introduisant la notion de la sémantique dans l’approche de problem frame.

2.5.8 Divers

Dans [33], Nelson et al proposent une suite de 12 problem frames qui sont adressés à modéliser les problèmes d’applications géographiques.

Wieringa [40] introduise un PF déclaratif qui capture les problèmes dans des systèmes réactifs, ce PF est introduit sans représentation graphique.

Dans [28], Konrad et Cheng untrotuisent un problem frame pour modéliser le patron Capteur/actionneur utilisé dans la spécification des systèmes embarqués.

2.6 Conclusion

Nous avons commencé ce chapitre en évoquant les principales notions de l’approche problem frame. Nous avons, par la suite, présenté les cinq problem frames de base de Michael Jackson. Notons que l’ensemnle de problem frames proposés dans la litérature (de Jackson et les autres PFs) ne permet pas de cerner complètement les différents problémes rencontrés dans le développement de logiciel, ce domaine restera alors un domaine de recherche ouvert.


25

Parmi les axes de recherche dans ce domaine, la combinaison de l’approche de problem frames avec d’autres méthodes de dévelopement présente une direction de recherche active et intéressante. Ainsi, nous nous intéresserons, dans le chapitre suivant, à l’intégration de l’approche PF dans un processus de développement à base du langage de modélisation graphique UML.

26

Chapitre 3

Développement de logiciel à base de

Problème Frames et UML

3.1 Introduction

Nous avons présenté précédemment l’approche problem frames avec ses diagrammes, notations et concepts permettant une description claire et directe du problème considéré. Nous avons également présenté un aperçu de la recherche dans ce domaine.

Nous allons maintenant examiner des travaux de la littérature ayant proposé une méthode de développement avec des directives précises pour le développement de logiciels à base de problem frames et UML. Nous concentrerons ici sur les travaux de recherche présentés dans [14] et [10]. Pour chacun des cinq problem frames élémentaires de M. Jackson, Choppy et al proposent une méthode de développement à base d’UML qui exploite les modèles et les diagrammes les plus sémantiquement adéquats au problem frame considéré.

3.2 Description générale de l’approche de combinaison PF-UML

Le travail proposé dans [14] consiste à combiner l’approche problem frame et le langage de modélisation graphique UML. La démarche proposée se compose de deux grandes parties :

− En premier lieu, une modélisation du problème par un des cinq Problem Frames élémentaires est effectuée, cette étape présente une analyse première du problème et donne une idée initiale des principaux éléments du problème traité. On note ici, que le travail de Choppy et al ne découvre pas les autres Problem Frames proposés dans la littérature ; la combinaison de Problem Frames n’est pas également abordée.

−La deuxième partie consiste à associer aux différents éléments du Problem Frame (domaine, machine, opérateur..) certains outils de spécification détaillée. A cette étape, les modèles et les diagrammes UML sont utilisés pour une

Développement de logiciel à base de Problème Frames et UML

27

meilleure spécification, visualisation, et construction de documents nécessaires au bon développement du système. Un ensemble restreint de diagrammes et modèles UML sont sélectionnés en adéquation avec le type de problem frame utilisé. La démarche proposée exige le passage par trois étapes de modélisation : modélisation du domaine (Domain Model), spécification de besoins (Requirement Specification) et spécification de conception (Design Specifications).

3.2.1 Modélisation du domaine

La modélisation du domaine consiste à modéliser le monde réel du problème. Dans [14], les auteurs proposent pour modéliser le domaine du monde une vue statique en utilisant le diagramme de classe d’UML. Les classes peuvent être actives si le type de domaine est causal (comportement dynamique).

3.2.2 Spécification de besoins

La spécification de besoins consiste à éclaire les différente vues du système en l’occurrence:

− La vue de contexte.

− La vue de cas d’utilisations qui sert à montrer l’utilisation du système par les différents acteurs.

− La vue interne qui indique la structure interne du système représentée essentiellement par ces états abstraits. Elle décrit également le comportement des différent cas utilisation.

− Vue de données sert à représenter clairement les données utilisées dans les différentes vues du système.

3.2.3 Spécification de conception

La spécification de conception consiste à modéliser les différentes vues du système, elle concerne essentiellement:

− Vue de donnée : décrire les différents types de données du système.

− Vue statique : introduire les types de classe et les entités formant le système.

− Vue de comportement : décrire le comportement des classes de la vue statique.

Développement orienté modèles de logiciel à base de « Problem Frames » 28

3.3 UML pour Commanded Behaviour PF

3.3.1 Etude de cas: système de contrôle d’ascenseur

Dans cette section, l’étude de cas de système de contrôle d’ascenseur est utilisée pour illustrer l’approche de combinaison de l’UML et Commanded Behaviour PF proposée dans [10]. Ce système se compose des éléments suivants :

− Une station d’ascenseur (lift plant): composée de la cabine, le moteur déplaçant la cabine et les portes des différents étages, on désigne ici par ascenseur la station de l’ascenseur

− Le logiciel de contrôle automatique du fonctionnement ascenseur (le contrôleur),

− Les utilisateurs de l’ascenseur.

Le contrôleur surveille la station d’ascenseur au moyen de capteurs qui communiquent l’état des différents éléments de l’ascenseur (par exemple, le capteur de détection de la position de la cabine), le contrôleur dirige, également, le comportement de l’ascenseur par l’intermédiaire de commandes (par exemple, il peut commander l’ouverture / fermer des portes).

L’ascenseur correspond au Commanded Behaviour frame comme suit (voir la figure 3.1): l’opérateur est l’utilisateur de l’ascenseur (désigné par la suit par utilisateur), le Control machine est le contrôleur de l’ascenseur (le logiciel de contrôle), le Controlled domain est l’ascenseur (désigné par la suite par LiftPlant).

FIG. 3.1 – Commanded Behaviour : exemple de l’ascenseur (figure extraite de [10]).


3.3.2.1 Modèle UML utilisé : présentation générale

Le modèle de domaine dans le Commanded Behaviour frame concerne le domaine contrôlé, il est décrit par un modèle UML qui comprend le fragment suivant (voir la figure 3.2).


29

FIG. 3.2 – Commanded Behaviour : modélisation du domaine (figure extraite de [10]).

Le Controlled domain est équipé de quelques capteurs, qui sont modélisés par les attributs publics : sensor1 ,… sensork . Il est contrôlé via certaines impulsions, qui sont modélisés par les opérations de l’interface Pulses. Cependant, Controlled domain peut changer son état et la façon dont il fonctionne même si il ne reçoit pas une impulsion (par exemple, quand une partie tombe en panne ou quand une entité externe agit sur lui). Ces activités «autonomes» sont modélisées par le biais d’appels des opérations auto1, …. autoh.

Pour décrire l’état de Controlled domain, d’autres attributs privés peuvent être utilisés. En outre, certains capteurs peuvent signaler une valeur dérivée par d’autres attributs. Dans ce cas, le modèle UML doit contenir des contraintes invariantes définissant ces capteurs en fonction des autres attributs.

Le comportement de la classe Controlled domain est alors modélisé par un diagramme d’états nommé Controlled domain behaviour :

− Dont les événements sont des événements de pointage ou des événements d’appels modélisés par les opérations pulse1,… pulsen, auto1,…. autoh,

− Et dont les conditions et les actions examinent et actualisent ses attributs.

3.3.2.2 Modélisation du domaine : système de contrôle d’ascenseur

Dans le système de contrôle d’ascenseur, Controlled domain présente la station de l’ascenseur, il est modélisé par la classe LiftPlant (voir la figure 3.3)

Dans l’ascenseur, un capteur pour révéler la position de la cabine est utilisé (le numéro de l’étage quand l’ascenseur est à un étage, -1 lorsqu’il se situe entre deux étages). D’autres capteurs sont, également, utilisés pour signaler l’état des portes des différents étages (ouvertes ou fermées) et s’il y a quelqu’un à l’intérieur de la cabine. Deux attributs privés enregistrent la distance entre la cabine et la terre, et combien de personnes sont à l’intérieur de la cabine. Les impulsions sont utilisées pour commander l’ouverture et la fermeture de la porte à un certain étage, et pour arrêter ou déplacer vers le haut ou vers le bas le moteur déplaçant la cabine.


La figure 3.4 illustre le diagramme d’états décrivant le comportement de la classe LiftPlant.

FIG. 3.3 – Système de contrôle d’ascendeur : modélisation du domaine−diagramme de classe (figure extraite de [10]).

FIG. 3.4 – Système de contrôle d’ascendeur : modélisation du domaine−diagramme d’état (figure extraite de [10]).


31

Il est à noter que le diagramme précédant montre que les portes ne peuvent être ouvertes/fermées que lorsque la cabine est à l’étage désiré, il montre également que les utilisateurs ne peuvent entrer/sortir de la cabine que lorsque la cabine est à un étage avec porte ouverte. Par conséquent, ces fonctions de sécurité ne seront pas sous la responsabilité du contrôleur logiciel.

L’utilisation de l’approche problem frame oblige le développeur à considérer et à décrire explicitement toutes les parties existantes du monde réel (real world) qui sont en interaction avec le système à développer. Ce point présente un des aspects les plus intéressants de cette approche.


3.3.3.1 Modèles UML utilisés

Dans l’étape de spécification de besoins, les cas d’utilisation sont appropriés pour résumer les exigences du système. Dans ce contexte, les modèles UML utilisés sont constitués d’un diagramme de cas d’utilisation, d’un diagramme de classe et des descriptions de cas d’utilisation.

3.3.3.1.1 Diagramme de cas d’utilisation

La figure 3.5 illustre le diagramme de cas d’utilisation. Le Control machine représente l’application à développer, et les cas d’utilisation Command1,….. Commandm correspondent aux différentes commandes possibles données par l’opérateur. Le dernier cas d’utilisation « Require normal behaviour» modélise le fait que même en l’absence de commandes de l’opérateur, Control machine doit assuré un comportement acceptable. Rappelons que nous considérons comme acteurs toutes les entités en interaction avec l’application et non pas seulement ceux en profitant de ses services; par conséquence Controlled domain est considéré comme un acteur.

FIG. 3.5 – Commanded behaviour : spécification de besoins−diagramme de cas d’utilisation (figure extraite de [10]).


3.3.3.1.2 Diagramme de classe

Le diagramme de classes est donné par la figure 3.6.

FIG. 3.6 – Commanded behaviour : spécification de besoins−diagramme de classe (figure extraite de [10]).

Ce diagramme présente trois classes modélisant les trois parties de Problem frame, il indique également les différentes interfaces mutuelles. ControlMachine interagit avec Controlled domain par l’envoi des impulsions (interface Pulses) et en accédant aux attributs «Sensor». ControlMachine interagit, également, avec Operator en recevant ses commandes (l’interface Commands). On suppose que toutes les commandes sont toujours correctes et acceptables, et donc le retour des messages d’erreur n’est pas nécessaire.

3.3.3.2 Spécification de besoins : système de contrôle d’ascenseur

3.3.3.2.1 Diagramme de case d’utilisation

Le diagramme de cas d’utilisation du système de contrôle d’ascenseur est donné par la figure 3.7. L’utilisateur peut demander l’arrêt de l’ascenseur, il peut aussi envoyer ou appeler la cabine à un certain étage. Quand on ne se sert de l’ascenseur la cabine devrait revenir au premier étage.


33

FIG. 3.7 – Système de contrôle d’ascenseur : spécification de besoins−diagramme de cas d’’utilisation (figure extraite de [10]).

3.3.3.2.2 Diagramme de classe

FIG. 3.8 – Système de contrôle d’ascenseur : spécification de besoins−diagramme de classe

(figure extraite de [10]).

Le diagramme de classe de la figure 3.8 décrit le contexte du contrôleur de l’ascenseur (classe Controller) et comment il peut interagir avec les entités dans un tel contexte (en envoyant des impulsions à la LiftPlant, en interprétant les signaux envoyés par les capteurs et en recevant les commandes de l’utilisateur).


3.3.3.2.3 Descriptions de cas d’utilisation

La figure 3.9 présente la description du cas d’utilisation « Apple de l’ascendeur à un étage donné f «.

FIG. 3.9 – Système de contrôle d’ascenseur : spécification de besoins−description de cas d’appel de l’ascenseur à l’étage f (figure extraite de [10]).


La spécification de conception consiste à modéliser la machine «ControlMachine». Cette tâche peut être difficile à cause de l’existence de plusieurs choix de conception possible.

Dans [10], les auteurs proposent une conception à base du pattern « Asynchronous Simple Control Machine : Contrôle asynchrone simple ». Ce pattern consiste à développer un processus simple qui reçoit des commandes et qui les traite les unes après les autres.

La machine est modélisée par la classe active ConrolMachine, cette classe est définit par le diagramme d’état de la figure 3.10. La figure 3.11décrit la conception du cas d’utilisation « appel de l’ascenseur ».


35

FIG. 3.10 – Commanded Behaviour problem frame : spécification de conception (figure

extraite de [10]).

FIG. 3.11 – Système de contrôle d’ascenseur : spécification de conception−diagramme d’état du cas d’appel de l’ascenseur (figure extraite de [10]).


3.4 UML pour Required Behaviour PF

3.4.1 Etude de cas: système de contrôle de vanne d’eau

L’étude de cas choisie pour présenter l’approche de combinaison de l’UML et Required Behaviour PF, est le système de contrôle d’une vanne d’eau.

La porte de la vanne doit être ouverte pendant dix minutes chaque trois heures. L’ouverture et la fermeture de la porte sont assurées par l’utilisation d’un moteur qui se tourne dans le sens des aiguilles d’une montre (clockwise CL) ou dans le sens inverse (anticlockwise ACL). La modélisation de ce système par required behaviour PF est illustrée par la figure 3.12.

FIG. 3.12 – Modélisation du système de contrôle d’une vanne d’eau par Required Behaviour FP(figure extraite de [14]).


Dans le cas de Required Behaviour problem frame, le modèle du domaine présentant le monde du problème est modélisé par le diagramme de classe UML illustré par la figure 3.13

FIG. 3.13 – Required Behaviour FP : modélisation du domaine–diagramme de classe (figure extraite de [14]).


37

Le domaine contrôlé est équipé par des capteurs qui sont modélisés par des attribues publiques «sensor1,……sensork». Ces derniers sont contrôlés par des impulsions modélisées par les opérations de l’interface Pulses.

La figure 3.14 illustre la modélisation du modèle de domaine dans le cas de l’exemple proposé.

FIG. 3.14 – Système de contrôle d’une vanne d’eau: modélisation du domaine (figure extraite de [14]).

Le diagramme d’état de la figure 3.14 indique les effets des impulsions sur le moteur de la porte. La classe SluiceGate modélise l’effet des impulsions sur le moteur de la vanne et son évolution lors de son déplacement et son arrêt, tandis que ce qui est signalé par les capteurs est décrit par la contrainte dans la même figure.


L’utilisation de diagramme d’état est adéquat pour modéliser le problem frame Required Behaviour, la classe principale est «Controlled Domain» sachant que:

− Les événements sont généralement des événements programmés.

− Les conditions ne concernent que ses attributs.

− Les actions présentent des mises à jour de ses attributs.


Le comportement contrôlé d’un domaine contrôlé est généralement exprimé par des activités à faire. Pour ce cas d’étude, le comportement à modéliser est le suivant: « la porte du vanne doit être ouverte pendant 10 minutes chaque 3 heurs ». Ce comportement est modélisé par la figure 3.15 avec la classe Sluice Gate. Sachant que le temps d’ouverture et de fermeture de la porte est négligeable.

FIG. 3.15 – Système de contrôle d’une vanne d’eau: spécification de besoins (figure extraite

de [14]).


La spécification de conception consiste à modéliser la machine «Controlled machine» par une classe active. Le rôle de cette classe est le capture des signaux émis par les différents capteurs de «Controlled domain» et l’envoie des impulsions.

FIG. 3.16 – Required Behaviour problem frame: spécification de conception–diagramme de classe (figure extraite de [14]).

Le comportement de la machine est modélisé par un diagramme d’état, la spécifi-cation de conception est ainsi modélisée par le diagramme de classe de la figure 4.16 et le diagramme d’état associé à la classe «ControlMachine», sachant que :

− Ses événements ne sont que des événements programmés.

− Ses conditions concernent ses attributs et les capteurs du domaine contrôlé (Controlled Domain).

− Ses actions peuvent modifier ses attributs et faire appel à des opérations de l’interface «Pulses».

La figure 3.17 illustre la spécification de conception du système de contrôle de vanne.


39

FIG. 3.17 – Système de contrôle de vanne: spécification de conception (figure extraite de [14]).

3.5 UML pour Commanded Information PF

Choppy et al introduisent, dans [14], Commanded Information PF qui présente une variante de l’Information display PF [24]. Le PF proposé est utilisé pour modéliser les problèmes où des informations concernant les états et le comportement d’une partie du monde physique sont demandées par des requêtes d’un opérateur. Dans ce PF, les informations sont directement présentées à l’opérateur et non pas par une console. La figure suivante illustre ce PF.

FIG. 3.18 – Commanded Information problem frame (figure extraite de [14]).

3.5.1 Etude de cas: système d’information

L’étude de cas choisie pour présenter la combinaison de l’UML et Commanded Information PF est le système d’information d’une société. Le monde réel est la


société, l’opérateur est le directeur de la société qui a besoin de connaitre certaines informations sur la société pour la prise de décisions.

FIG. 3.19 – Modélisation du système d’information d’une société par Commanded

Information PF (figure extraite de [14]).

3.5.2 Modélisation de domaine

Pour Commanded Information PF, le domaine du modèle est constitue de monde réel (Real World). Ce dernier est modélisé par un diagramme de classe UML avec une classe active nommée RealWord. Sur ce modèle, il est possible d’ajouté les détails nécessaires de description du comportement du monde réel.

La figure 3.20 représente le modèle de domaine qui correspond à l’exemple donné. Le comportement de la classe Company est décrit par le texte attaché à cette classe.

FIG. 3.20 – Système d’information d’une société : modélisation de domaine (figure extraite

de [14]).


41


Le diagramme de cas d’utilisation est adéquat pour modéliser les besoins. La spécification de besoin correspond généralement au besoin Answer rules et aux requêtes de l’opérateur. Le modèle UML établit pour la spécification de besoin consiste à:

3.5.3.1 Diagramme de cas d’utilisation

La figure 4.21 illustre le diagramme de cas d’utilisation, le système est la machine à développer «Answering machine». Les deux acteurs qui participent à ce système sont : l’opérateur et le monde réel (Real world).

FIG. 3.21 – Commanded Behaviour PF : spécification de besoins diagramme de cas

d’utilisation (figure extraite de [14]).

3.5.3.2 Diagramme de classe

Le diagramme de classe est utilisé pour modéliser la vue de données et de contexte ainsi que la vue interne. La classe Realworld _E modélise une spécification de monde réel avec la capacité de signaler les événements à leur arriver.

Les événements sont modélisés par la classe Event. La classe AnsweringMachine interagit avec la classe RealWorld_E par la réception des événements signalés via l’interface Signal. Elle interagit également avec la classe EnquiryOperator par la réception des requêtes via l’interface Enquiries et par l’affichage des informations demandées via l’interface DisplayActs, et éventuellement les erreurs de requêtes via l’interface ErrorMessages (voir la figure 3.22).

Les états internes abstraits du classe AnsweringMachine consistent l’historie du monde réel.


FIG. 3.22 – Commanded Behaviour PF : spécification de besoins–diagramme de classe


3.5.3.3 Description de cas d’utilisation

Chaque cas d’utilisation est décrit par un diagramme d’état. Les deux diagrammes d’état des deux cas d’utilisation RecordEvent et Enquiry sont donnés par la figure 3.23

FIG. 3.23 – Commanded Behaviour PF : spécification de besoins description de cas d’utilisation (figure extraite de [14]).

(a) Cas d’utilisation : Record Event (b) Cas d’utilisation : Enquiry


43

Le diagramme de cas d’utilisation est illustré par la figure 3.24, le diagramme de classe pour ce cas est représenté par la figure 3.25.

FIG. 3.24 – Système d’information d’une société : spécification de besoins diagramme de cas d’utilisation (figure extraite de [14]).

On distingue deux parties dans ce diagramme. La première partie représente la structure des données ; les événements qui se déroulent dans la société concernent principalement la vie d’un ordre (recieved, processed, refused, cancelled), ainsi que l’ajout et la suppression de produit de puis le catalogue de la société. La deuxième partie représente les entités de contexte qui s’interagissent avec la machine CompanyIS.

La figure 3.26 montre le diagramme d’état décrivant le cas d’utilisation « Show product quantty sold in a period »

FIG. 3.26 – Système d’information d’une société : Diagramme d’état du cas « Show product

quantty sold in a period » (figure extraite de [14]).


FIG. 3.25 – Système d’information d’une société : spécification de besoins diagramme de classe (figure extraite de [14]).


45

3.5.4 La spécification de conception

Pour modéliser la vue statique du système à développer, la méthodologie présentée dans [4] propose l’organisation de l’architecture du système en utilisant trois types de classes :

<<boundry>> s’intéresse à l’interaction du système avec les entités externes.

<<store>> s’intéresse au stockage des données.

<<executor>> représente l’ensemble d’activités à faire par le système.

Les associations n’expriment que la vérité qu’une instance d’une classe transmettre des messages à une instance d’autre classe.

La spécification de conception est donnée par la figure 3.27.

FIG. 3.27 – Commanded Behaviour PF : spécification de conception–vue statique (figure extraite de [14]).

3.6 UML pour Rich Workpieces PF

Dans [14], Choppy et al présentent une variante du Workpieces PF de M. Jackson, cette variante est appelée Rich Workpieces PF.

La représentation graphique de Rich Workpieces PF est donnée par la figure 3.28.


FIG. 3.28 – Diagramme Rich Workpieces problem frame (figure extraite de [14]).

3.6.1 Etude de cas: système d’assistance plomberie (Plumbers Frind).

L’étude de cas choisie pour présenter l’approche de combinaison de l’UML et Rich Workpieces PF est le système d’assistance plomberie (Plumbers Frind) [14]. Le rôle de ce système est d’aide les plombiers à gérer leurs documents utilisés dans leur travail. Ces documents sont stockés dans une base de données relationnelle. La figure 3.29 illustre la modélisation de ce système par Rich Workpieces PF.

FIG. 3.29 – Modélisation du système d’assistance plomberie par Rich Workpieces problem frame (figure extraite de [14]).

Dans ce système, des requêtes SQL sont utilisées pour consulter la base de données et faire des mises à jour.


Dans le cas de Rich Workpeices PF, le domaine est le Workpeice, sa modélisation est représentée par le diagramme de classe UML de la figure 3.30.

Operations sont les opérations de modifications du Workpiece (WP). Looks présentent les opérations de consultation du WP. Services «S» sont les services


47

fournis par la machine concernant la manipulation du WP. Messages sont les messages émis par la machine vers l’utilisateur décrivant les résultats des commandes reçus. Shows représentent les communications entre la machine et l’utilisateur concernant les effets de commandes sur le Workpeices.

FIG. 3.30 – Rich Workpieces problem frame : modélisation du domaine (figure extraite de

[14]).

Les opérations de la classe Worpieces sont les opérations définies dans les deux interfaces OPERATION et LOOKS.

La modélisation du domaine selon Rich Workpieces PF du système d’assistance plomberie est illustrée par le diagramme de la figure 3.31.

Dans ce cas d’étude, la modélisation du domaine décrit l’ensemble de documents utilisés par les plombiers (les factures, les fiches clients, … etc.). A titre d’exemple, une facture est modélisée comme un ensemble de plusieurs lignes, dont chacune des lignes peut être un commentaire, une indication de la partie de travail ou une indication de la durée de travail.


FIG. 3.31 – Système d’assistance plomberie : modélisation du domaine (figure extraite de

[14]).


La spécification de besoin consiste à représenter les différents services et leurs signatures.


Le système dans ce type de problème est la machine à développer «Deskto Tool». Selon le travail de recherche présenté dans [3], les acteurs sont toutes les entités en interaction avec le système (utilisateur, Workpeices).

La figure 3.32 illustre la spécification de besoins à base de diagramme de cas d’utilisation de Rich Workpeices PF.


49

FIG. 3.32 – Rich Workpeices problem frame : spécification de besoins diagramme de cas



Dans le diagramme de classe de la figure 3.33, la classe Desktop Tool modélise le système à développer. Ce diagramme montre le contexte de cette machine. Cette dernière interagit avec le «Workpieces» à travers trois interfaces : 1. l’appel des opérations à exécuter (l’interface Commands), 2. la réception des messages concernant le résultat d’exécution des commandes (l’interface UMessage) et 3. la visualisation des informations du Workpieces (l’interface Shows). Ces trois interfaces « Shows, Commands, et UMessages » sont déterminées par les phénomènes partagés dans les différents services de «SERVICES».

FIG. 3.33 – Rich Workpeices problem frame : spécification de besoins–diagramme de classe



3.6.3.3 Description du cas d’utilisation

Dans [3,4], les auteurs décrivent chaque cas d’utilisation par un diagramme d’état qui intègre les interactions entre les différents acteurs du système (utilisateur et Workpieces). Dans ce contexte, les événements se traduisent par les appels des opérations de l’interface Commands. La partie action peut contenir les appels d’opérations des interfaces Looks, UMessages et Shows, ainsi que le statut de modification des attributs de la classe Desktop Tool.

L’utilisation des autres diagrammes UML, tels que le diagramme de séquence, est possible afin de modéliser les informations concernant les classes dans le diagramme de classe et modéliser d’autres vues de cas d’utilisation.

En appliquant cette démarche de spécification sur notre cas d’étude, on obtient le diagramme de cas d’utilisation représenté par la figure 3.34

FIG. 3.34 – Système d’assistance plomberie : spécification de besoins diagramme de cas


En prenant l’exemple du cas d’utilisation « création d’une facture » (create invoice), le diagramme de classe qui décrit ce cas est donné par la figure 3.35.

Le diagramme d’état correspond au cas d’utilisation « création d’une facture » est donné par la figure 4.36.


51

FIG. 3.35 – Système d’assistance plomberie : diagramme de classe du cas « création d’une

facture » (figure extraite de [14]).


FIG. 3.36 – Système d’assistance plomberie : diagramme d’état du cas « création d’une

facture » (figure extraite de [14]).

3.6.4. Spécification de conception

Dans [4], les auteurs proposent l’utilisation du diagramme de classe dans la spécification de conception. La figure 3.37 montre l’architecture proposée pour représenter la machine «Desktop Tool». Une classe de type boundary est utilisée pour modéliser l’accès au Workpeices en utilisant les interfaces Opérations, Messages et Looks précédemment définies. En outre, pour chaque service des classes boundary sont utilisées pour gérer l’interaction avec les utilisateurs ; d’autres classes executor (exécutrices) sont également employées.


53

FIG. 3.37 – Rich Workpieces problem frame : spécification de conception (figure extraite de

[14]).

3.7 UML pour trasformation PF

3.7.1 Etude de cas: analyseur des emails

L’étude de cas choisie pour présenter la combinaison de l’UML et Required Behaviour PF est l’analyseur des emails. Le rôle de ce système est d’analyser les emails et d’établir un rapport décrivant certaines informations telles que le nombre de massages reçus, la source, la destination…etc.

La modélisation de ce système par transformation PF est illustrée par la figure 4.38

FIG. 3.38 – Modélisation de l’analyseur des emails par Required Behaviour PF (figure

extraite de [14]).


3.7.2 Modèle du domaine et spécification de besoins

Dans ce type de problème, le modèle du domaine et la spécification de besoin sont donnés par le diagramme de classe UML illustré par la figure 3.39. Les deux classes correspondent à Input et Output, elles peuvent être décrites en utilisant les contraintes d’UML. Les besoins dans ce PF sont représentés par l’association I/O relation.

FIG. 3.39 – Transformation PF : modélisation du domaine et spécification de besoins (figure

extraite de [14]).

Dans le cas de l’analyseur des emails, le modèle du domaine et la spécification de besoins sont donnés par la figure 3.40. Les attributs sont fournis pour les deux classes Mail et ReportLine comme des invariants dans la classe Mailfiles.

FIG. 3.40 – Analyseur des emails : modélisation du domaine et spécification de besoins



55


La spécification de conception consiste à étendre le modèle de la figure 3.39 par la classe TransformMachine (voir la figure 3.41).

FIG. 3.41 – Transformation problem frame : spécification de conception (figure extraite de [14]).

FIG. 3.42 – Analyseur des emails : spécification de conseption (figure extraite de

[14]).


La spécification de conception de l’analyseur des emails est présentée par le diagramme de la figure 4.42

3.8. Conclusion

Dans ce chapitre, nous avons présenté une approche de développement qui consiste à combiner l’utilisation des problem frames avec le langage de modélisation graphique UML. L’approche problem frame fournit une première structure générale du problème, la méthode présentée montre pour chaque phase de développement l’ensemble de modèles et de diagrammes UML à utiliser.

Nous avons choisi le langage UML car il est largement utilisée vu sa richesse et sa puissance d’expression. Nous avons, ainsi, montré, à travers des cas d’étude, la démarche à suivre pour modéliser les problèmes à base de problem frame et UML.

57

Chapitre 4

Contributions à l’approche de Problem

Frames

4.1 Introduction

Nous présentons dans ce chapitre notre contribution dans le domaine de problem frames.

Une étude de la majorité des problem frames existants dans la littérature nous a permis d’identifier les classes de problèmes non encore complètement cernés par les problem frames existants. Nous proposons ainsi un nouveau problem frame : the Archivist. La définition du problem frame proposé est présentée dans la section 4.1. Dans la section 4.2, nous montrons l’apport de l’Archivist PF à travers deux études de cas. La dernière section décrit une proposition de combinaison entre le problem frame proposé et le langage UML.

4.2 Description détaillée du problem frame proposé

4.2.1 Définition et notation

Le problem frame Archivist [30] est proposé pour modéliser une classe de problèmes dans lesquels nous développons une machine capable de sauvegarder des informations sur l’état et le comportement du système (Real Word), ces informations sont sauvegardées dans des structures de données telles que les bases donnée les enregistrements, les fichiers…etc.

La figure 4.1 illustre le diagramme de l’Archivist PF.

« Archivist Machine » (AM) est la machine à développer. « Real Word » (RW) représente le système ou la partie du monde réel. Le processus de collection et d’archivage d’informations s’applique sur les descriptions d’état et de comportement de RW. Le C dans le coin droit inferieur du rectangle signifie que RW est un domaine causal. L’interface entre la machine AM et le monde réel RW est représentée par les phénomènes C1 qui ne sont contrôlés que par RW, la machine AM n’a alors aucune influence sur le monde de problème, son rôle est la collection et l’archivage des


58

différentes informations décrivant le système. Dans le cas général, les phénomènes C1 représentent les relations entre les capteurs du monde réel et notre machine.

Le domaine « Archive » (AR) est l’emplacement sur lequel les informations collectées sont stockées, le X qui lui est associé indique que c’est un domaine lexical. L’archive peut être des bases de données, des fichiers, des enregistrements, des rapports…etc, son contenu est mis à jour d’une façon périodique.

Nous appelons les besoins par « Archive~Real World », les phénomènes de besoins Y1 représentent les différentes informations sauvegardées dans l’archive, elles sont de type symbolique car ces informations sont généralement des valeurs, des enregistrements, des chaines de caractère…etc. Une correspondance a lieu entre les phénomènes symboliques de besoins Y1 et les phénomènes causals de besoins C2.

Pour sauvegarder les informations Y1 décrivant le monde réel (RW), des mises à jour sont faites en générant certains événements et opérations de mise à jour (adition, modification,…), ainsi que des calculs et d’autre opérations qui peuvent s’appliquer sur un archive. Ces opérations sont modélisées par les phénomènes partagés E1.

L’utilisation de notre problem frame « The archivist » avec les autres problem frames de la littérature est envisagée afin d’assurer une bonne modélisation des problèmes complexes.

4.2.2 Comparaison entre « Archivist » et les cinq PF M. Jackson

Dans cette section, nous comparons notre Archivist PF avec les cinq PF de Michael Jackson.

4.2.2.1 «Archivist » PF vs. required behavior PF

− Comme nous l’avons évoqué précédemment, le rôle de l’Archivist est la collection et le stockage des informations décrivant un monde réel, cependant le rôle de required behavior PF est le contrôle automatique du comportement du monde réel.

A rchivis t M ach ine

(A M )

A rch ive ~ R ea l

W orld

RW !C 1

A M !E 1

C 2

Y 1

R ea l W orld (R W ) C

A rch ive (A R )

X

FIG. 4.1 – Diagramme de l’Archivist problem frame.

Contributions à l’approche de Problem Frames

59

− On distingue deux domaines dans l’Archivist PF, celui du monde réel et celui de l’archive créé à travers le stockage des informations collectées sur le monde réel.

− La machine développée dans l’Archivist PF n’a aucun effet sur le monde du problème, par contre celle développée dans required behavior PF contrôle le comportement du système (le monde réel).

4.2.2.2 «Archivist » PF vs. commanded behaviour PF

− Le point principal qui fait la distinction entre les deux problem frames est le but pour lequel chacun d’entre eux est développé : pour l’Archivist le but est de collecter et stocker des informations sur un monde réel, par contre le but dans commanded behaviour PF est de contrôler un monde réel à travers les opérations et les commandes générées par un opérateur.

− La machine développée dans l’Archivist PF n’a aucun effet sur le monde du problème, par contre dans commanded behaviour PF c’est l’opérateur qui contrôle le comportement d’un système (le monde réel)

4.2.2.3 «Archivist » PF vs. workpeice PF

− Dans les deux PF, une structure de données est utilisée ; sa mise à jour est indispensable pour la cohérence du système.

− Dans l’Archivist, la mise à jour de la structure de données est faite à travers le stockage des informations collectées sur un monde réel, par contre pour workpeice PF l’opération de mise à jour est effectuée par un opérateur.

− Le monde réel est de nature causale dans le cas de l’Archivist PF : ce monde est un système dynamique, par contre dans le Workpeice PF il est de nature lexicale: une édition d’une structure de donnée (une image, un plan….).

4.2.2.4 «Archivist » PF vs. display information PF

− Dans les deux PF, le monde réel est de nature causale (système dynamique).

− Dans les deux PF, la machine n’a aucun effet sur le monde réel, sont rôle est la collection des informations sur ce monde.

− La différence entre les deux PF est que notre PF enregistre les informations collectées dans un archive. Ce dernier peut être utilisé, dans le futur, pour évaluer le système et introduire des modifications et des améliorations. Par contre, pour display information PF, les informations collectées ne sont pas sauvegardées, elles sont affichées sur une console, donc on ne peut pas bénéficier de ces informations.


60

4.2.2.5 «Archivist » PF vs transformation PF

− Le rôle de transformation PF est la transformation des objets en entrée du système en d’autres objets en sortie ce qui le distingue de notre PF.

− Pour l’Archivist PF, le type du monde est causal, en revanche pour transformation PF il est de type lexical.

La table 4.1 synthétise la comparaison entre l’Archivist PF et les cinq PFs de base de Mickael Jackson.

4.3 Domaine d’application de l’Archivist problem frame

A travers notre étude sur le domaine de problem frames, nous avons remarqué une insuffisance au niveau de la modélisation des systèmes dont la collection et le sauvegarde des informations sur le comportement et l’état du système est fortement nécessaire. Notre Archivist PF vient pallier cette insuffisance. En effet l’archivage des informations permet leur future utilisation dans des taches d’évaluation de qualité des services, de modification et d’amélioration du système.

Dans cette section, nous montrons l’apport du problem frame proposé à travers deux études de cas.

4.3.1 Etude de cas n°1 : Système de détection des intrusions

Dans le domaine de la sécurité des réseaux, nous avons besoin de contrôler et de détecter les différentes menaces pesant sur la sécurité des réseaux. Plusieurs stratégies de sécurité sont élaborées pour garantir cette dernière. Les systèmes de détection d’intrusion (IDS : Intrusion Detection System) est une stratégie très utilisée dans la sécurité des réseaux. Un IDS fournit plusieurs informations concernant une intrusion réseau : la date d’intrusion, l’adresse IP source d’intrusion, le port source, le type d’intrusion, les effets d’une intrusion…etc.

Un IDS enregistre ces informations et génère un rapport d’attaque, ce dernier est archivé afin d’améliorer l’élaboration de différents stratégies de défense. Par exemple, si on trouve que le port X est généralement un port source d’une intrusion, on peut tous simplement fermer ce port.

La figure 4.2 illustre la modélisation du problème de détections des intrusions à travers notre Archivist PF.

TAB. 4.1 – Tableau récapitulatif : Comparaison entre l’Archivist PF et les PFs de base de Jackson

Archivist Required Beh. Commanded Beh. Infomation Disp. Workpieces Transformation

Rôle

Collecter/Sauvegarder les infos concernant le comportement et l’état

d’un système

Contrôler un système

Commander un système à travers les

commandes d’un opérateur

Afficher les infos concernant le

comportement d’un système

Editer une structure de données

Transformer des inputs en des outputs

L’effet sur le monde réel

Aucun Oui Oui Aucun Oui Oui

La nature de monde réel

Causal Causal Causal Causal Lexical Lexical

Nombre de domaine

02: le monde réel + l’archive

01: le monde réel 02: le monde réel +

l’opérateur 02: le monde réel +

la console 02: le monde réel +

l’utilisateur 02: input + output

Utilisation de structure de

donnée Archive Aucun Aucun Aucun WorkPieces Output + input


62

− L’IDS est la machine à développer. Le réseau est le monde du problème, son type est causal.

− Les phénomènes partagés a représentent les différents événements tels que les interruptions qui provoquent l’IDS à détecter et sauvegarder les intrusions.

− Les phénomènes c représentent les différentes informations décrivant une intrusion, ces informations sont sauvegardées sur Intrusion Archive.

− Intrusion Archive est, généralement, une base de données qui contient les différents détails sur les intrusions.

− Les détails sur les intrusions sauvegardés dans Intrusion Archive sont modélisés à travers les phénomènes de besoin d.

4.3.2 Etude de cas n°2 : Les boites noires des avions

La boîte noire est un dispositif sur lequel les informations du vol sont enregistrées. Dans la pratique, les boîtes noires sont de couleur orange ou rouge ce qui facilite la recherche si l’avion est détruit. Les informations sauvegardées sont alors indispensable en cas d’un accident.

On distingue deux types d’informations enregistrées sur une boite noire: les enregistreurs phoniques (Cockpit Voice Recorder : CVR) qui sont destinés à enregistrer les conversations du poste de pilotage (cockpit) et les enregistreurs de paramètres (Flight Data Recorder : FDR) qui ont pour rôle d’enregistrer les données de vol (l’altitude, vitesse, température…). Les boites noires sont placées à l’arrière de l’avion car c’est la partie qui est, généralement, la mieux conservée lors d’un impact avec le sol ou la mer.

En pratique, l’ensemble des informations des différents capteurs de l’avion est collecté par le FDAU (Flight Data Acquisition Unit défini par La norme ARINC 717) situé à l’avant de la cabine de pilotage puis renvoyé vers l’arrière de l’avion où est situé l’enregistreur de la boite noire.

FIG. 4.2 – Modélisation d’un IDS par l’Archivist problem frame.

The IDS

Detect and archive

intrusion

a

b

c

d

Network (NET)

C

Intrusion Archive

X

a: NET!{interruptions, events} d:{date/IP/port/kind intrusion}

c: {intrusion information } b: IDS!{arch operation}


63

Le FDAU sélectionne les paramètres acquis, puis les ordonne pour les envoyer à l’archive de la boite noire dans une trame continue. La boite noire enregistre alors directement cette trame dans sa mémoire. Puis les données sont relues par la boite noire et renvoyées au FDAU, qui contrôle alors la cohérence des données qu’il a envoyées et qu’il reçoit en retour (playback FDR). Cela permet de détecter un dysfonctionnement de la boite noire et de le signaler par une alarme dans le cockpit [41].

La figure 4.3 montre la modélisation de ce type de problème en utilisant l’Archivist PF.

− L’avion « Airplane » (AP) est le monde du problème traité.

− La boite noire « Black Box » (BS) est la machine à développer.

− Les phénomènes partagés a représentent les différents signaux et impulsions générés par certains capteurs installés dans l’avion.

− Les phénomènes de besoin c représentent les informations de type CVR et FDR à enregistrer.

− « Black Box Archive » est l’emplacement de stockage de ces informations.

− Les enregistrements CVR et FDR sont stockés dans la boite noire sous forme de fichiers audio et des informations enregistrées dans une base de données. Ces derniers sont modélisés par les phénomènes de besoin d.

− Les phénomènes partagés b représentent les opérations de mise à jour effectuées par la machine BS sur le contenu de la boite noire.

4.4 UML pour l’Archivist problem frame

Dans cette section, une approche de combinaison de l’ Archivist problem frame avec le langage UML est proposée. La démarche suivie repose sur celle décrite dans le chapitre 4, elle consiste à élaborer les phases suivantes :

1− La modélisation du problème traité par l’Archivist problem frame,

2− La modélisation du domaine (Domain Model),

3− La spécification de besoins (Requirement Specification),

4− La spécification de conception (Design Specification).

FIG. 4.3 – Modélisation de la boite noire de l’avion par l’Archivist problem frame.

B l a c k B o x S y s t e m ( B S )

R e c o r d p l a n e

i n f o r m a t i o n

a

b

c

d

A i r p l a n e ( A P )

C

B l a c k B o x A r c h i v e

X

a : A P ! { s i g n a l s , p u l s e s , E v e n t s … } d : { f i l e v o i c e , s p e e d , a l t i t u d e …}

c : { F D R / C V R i n f o } b : B S ! { o p e r a t i o n o f u p d a t e }


64

L’étude de cas choisie pour illustrer l’approche proposée est « la boite noire des avions ». La phase de la modélisation de ce problème par l’Archivist problem frame est présentée dans la section 4.3.2. Dans ce qui suit, nous détaillerons les trois phases restantes de l’approche de combinaison proposée. Pour chacune de ces phases, nous donnerons des directives générales de développement puis nous appliquerons nos propositions sur l’étude de cas choisie.

4.4.1 Modélisation du domaine : Présentation générale

La modélisation du domaine pour l’Archivist problem frame consiste à modéliser le monde réel (Real World). Cette modélisation se traduit par un diagramme de classe UML avec une classe active nommée, dans le cas général, RealWord.

4.4.2 Modélisation du domaine : Boite noire des avions

La classe Airplane représente la modélisation de domaine dans notre cas (voir Fig 4.4).

<<active>> Airplane (AP)

marque type power ……… takeoff () lande () accelerate () ………

4.4.3 Spécification de besoin : Présentation générale

Pour décrire les besoins d’un système modélisé par l’ Archivist problem frame, nous utilisons les diagrammes de cas d’utilisation, les diagrammes de classes et les descriptions des cas d’utilisation.


Le système représente la machine à développer : « ArchivistSystem ». Les deux acteurs qui participent à ce système sont : l’archive et le monde réel.

La figure 4.5 illustre le diagramme de cas d’utilisation. Ce dernier est l’enregistrement des informations concernant le comportement et les états du système (Record info). Il nécessite que le monde réel provoque cette tâche par la signalisation des changements d’état ou de comportement du système.

FIG. 4.4 Boite noire des avions : Modélisation du domaine


65


La figure 4.6 représente une description générale du cas d’utilisation « RecordEvent » par un diagramme d’état. Le système est toujours dans un état de captage des événements. La signalisation d’un événement provoque l’enregistrement des informations requises.


Le diagramme de classe est utilisé pour modéliser la vue de donné et de contexte ainsi que la vue interne. La classe « Realworld _E » modélise une spécification du monde réel avec la possibilité de signaler les événements lorsqu’ils arrivent.

Comme le montre le diagramme de classe donné par la figure 4.7, les événements sont modélisés par la classe « Event ». La classe « ArchivistSystem » interagit avec la classe « RealWorld_E » à travers la réception de ses événements, ces derniers sont signalés via l’interface « Signal ». Par ailleurs, « ArchivistSystem » interagit également avec la classe « Archive » à travers les appels d’opérations de mise à jour de contenu de cette classe. Ces appels se font via l’interface « Opération ».

ArchivistSystem

RecordInfo

SignalEvent Archive

RealWorld_E

<<Include>>

FIG. 4.5 – Archivist PF : Spécification de besoin−Diagramme de cas d’utilisation.

FIG. 4.6 – Archivist PF : Spécification de besoin−Description de cas d’utilisation.

Capturing SignalEvent (e)

Recording

endrecording


66

4.4.4 Spécification de besoin : Boite noire des avions


La figure 4.8 représente le diagramme de cas d’utilisation correspond au problème de la boite noire d’un avion. Les deux entités qui participent dans ce système sont : FDAU et l’archive de la boite noire. Le cas d’utilisation est l’enregistrement des informations de type FDR et CVR. On fait appel ici au cas d’utilisation « SignalEvent » (Fig 4.5) qui inclus le cas de vérification de donné « Chekdata ». Les données reçues par la boite noire sont alors renvoyées au FDAU pour contrôler la cohérence des données.

FIG. 4.7 – Archivist PF : Spécification de besoin−Diagramme de classe.

<<Interface>>

Operations

op1 () ……

opn ()

RealWorld Event

RealWorld_E

ArchivistSystem

<<Interface>>

Signals

signalEvent(Event)

Archive


67


Le système est toujours dans un état de captage des événements (voir Fig 4.6). Lorsqu’un événement est signalé, on procède d’abord à la vérification de la cohérence de données. Une fois cette tâche est terminée un feedback est généré pour confirmer l’enregistrement de données requises. Ensuite le système revient à son état initial de captage des événements pertinents du système (voir Fig 4.9).


La figure 4.10 représente la spécification de besoin de la boite noire d’un avion par le diagramme de classe. La classe « BlackBoxSytem » représente la machine à développer. La partie du monde réel qui nous intéresse le plus est l’unité FDAU qui s’occupe d’envoyer les informations vers la boite noire. On définit deux interfaces « Signals » et Opérations. L’interface « Signals » fournit les différents services de captage et de signalisation des informations requises concernant l’avion vers la boite noire.

La deuxième interface « Opérations » sert à fournir les services de mise à jour de données enregistrées dans la boite noire tel que l’ajout des morceaux de son enregistrés dans le cockpit de l’avion ainsi que les différents données de type FDR (vitesse, altitude, température…).

FIG. 4.8 – Boite noire des avions : Spécification de besoin−Diagramme de cas d’utilisation.

RecordCVR/,FDR

SignalEvent

BlackBoxArchive FDAU

<<Include>>

<<Include>>

Chekdata

FIG. 4.9 – Boite noire des avions : Spécification de besoin−Description de cas d’utilisation.

Capturing SignalEvent (e) ChekingData

endrecording

Recording Feedback


68

Donc l’archive est constitué des deux type de données FDR et CVR ; par conséquent, nous introduisons deux classes FDR et CVR comme étant des agrégats de la classe Archive.

FIG. 4.10 – Boite noire des avions : Spécification de besoin−Diagramme de classe.

Plane Event

FDAU

BlackBoxSystem

<<Interface>>

Signals

signalEvent(Event)

BlackBoxArchive

<<Interface>>

Operations

AddCVRInfo () AddFDRInfo () apdateCVR () apdateFDR ()

………..

FDR CVR


69

4.4.5 Spécification de conception : Présentation générale

La spécification de conception pour l’Archivist PF consiste à élaborer un diagramme de classe qui décrit la machine de l’Archivist. Comme dans [4], nous utilisons une architecture qui se base sur trois types de classe, chacune d’entre eux est représentée par un stéréotype :

<<boundary>> : s’occupe de l’interaction avec les entités externes.

<<store>> : représente les entités contenant les données.

<<executor>> : performe les activités de système en communiquant avec les entités boundary et store

La classe « SingalDetect » s’occupe à la signalisation des événements du monde réel. Nous utilisons des classes de type Executor pour représenter les opérations d’analyse et de filtrage des informations reçues de la part de la classe « SignalDetect ». Les classes de type Store servent à l’enregistrement des informations sur le monde réel. Ces informations sont alors collectées par la classe de type Boudary « SignalDetect » et analysées par les classes de type Executor. L’ensemble de ces classes forme notre archive.

4.4.6 Spécification de conception : Boite noire des avions

En appliquant l’architecture présentée ci-dessus, sur l’exemple de la boite noire d’un avion, on obtient le modèle illustré par la figure 4.12.

FIG. 4.11 – Archivist PF : Spécification de conception

RealWorld_E

<<store>> Stm

<<boundary>>

SingnalDetect

signalEvent(Event)

Archive

<<store>> St1

<<executor>> Exp

<<executor>> Ex1

……

……


70

Les entités de type Store FDR et Store CVR représentent les informations collectées et signalées de puis l’unité FDAU. La classe de type boundary « SignalDetect » s’occupe de l’interaction avec l’unité FDAU. Les deux classes de type Executor « CheckDataFDR » et « CheckDataCVR » s’occupent de la vérification de la cohérence des données signalées de puis la FDAU.

4.5 Conclusion

Dans le contexte de ce chapitre, nous avons proposé, d’une part, un nouveau problem frame « Archivist » qui nous a permet de modéliser les problèmes dont lesquels on a besoin de collecter et de mémoriser des informations concernant l’état et le comportement du système. Nous avons identifié les caractéristiques de ce problem frame ainsi que son importance dans le domaine de développement à travers les deux études de cas présentées. D’autre part, nous avons présenté une approche de développement pour modéliser les problèmes capturés par l’Archivist PF en combinaison avec la notation UML.

FDAU

<<store>> CVR

<<boundary>>

SignalDetect

signalEvent(Event)

<<store>> FDR

<<executor>> ChekdataFDR

<<executor>> ChekdataCVR

Archive

FIG. 4.12 – Boite noire des avions : Spécification de conception

71

Chapitre 5

Conclusions et perspectives

Dans le cadre de ce travail de magister, nous nous sommes principalement intéressés à l’approche problem frames qui présente un des axes de recherche les plus actifs de l’ingénierie de besoin. Cette approche permet l’analyse, la structuration et la classification des problèmes. Elle est orientée problème plutôt que orientée solution ce qui facilite son intégration dans le processus de développement. Nos contributions, dans ce domaine, partent des constats suivants:

− Les problem frames existants, dans la litérature, ne couvrent pas la totalité des problèmes rencontrés dans le développement de logiciel, il est de ce fait intéressant de définir d’autres problem frames. Pour notre cas, nous avons proposé Archivist PF afin de permettre la modélisation des problèmes dont lesquels on a besoin de collecter et d’archiver des informations sur l’état et le comportement du système.

− La modélisation des problèmes à base de problem frames n’englobe pas tous les aspects du problème ce qui ne permettre pas d’aller très loin dans le processus de développement. De ce fait, la combinaison de cette approche avec d’autres approches de développement est nécessaire. Une étude sur l’état de l’art relatif à l’approche problem frame nous indique que la combinaison avec le langage UML permet de tirer profit de l’éventuelle complémentarité et avantage des deux approches.

Ainsi, nous pouvons résumer la contribution mise en évidence dans ce travail à travers les points suivants :

− L’étude de l’état de l’art relatif au domaine de recherche de problem frames.

− La définition d’un nouveau problem frame « the Archivist » et la validation de ce PF à travers deux études de cas.

− La proposition d’une méthode de poursuite de la modélisation à base de l’Archivist PF qui exploite la richesse et la puissance d’expression du langage UML. Et la validation de cette combinaison à travers l’étude de cas du système de gestion des boites boires des avions.

Conclusions et perspectives

72

72

Plusieurs perspectives restent envisageables pour faire évoluer ce travail. Parmi ces perspectives, nous pensons que l’utilisation de notre Archivist PF en combinaison avec les autres problem frames de la littérature est prometteuse afin d’assurer une bonne modélisation des problèmes complexes.

73

Bibliographie

[1] C. Alexander, S. Ishikawa,M. Silverstein, M. Jacobson, I. Fiksdahl-King, et S. Angel. A Pattern Language. Oxford University Press, 1977.

[2] E. Astesiano, M. Cerioli, et G. Reggio. Plugging Data Constructs into Paradigm-Specific Languages: towards an Application to UML (Invited Lecture). In T. Rus, editor, Proc. AMAST 2000, number 1816 in Lecture Notes in Computer Science, pages 273–292. Springer Verlag, Berlin, 2000.

[3] E. Astesiano et G. Reggio. Towards a Well-Founded UML-based Development Method. In A. Cerone and P. Lindsay, editors, Proc. of SEFM ‘03, pages 102–117. IEEE Computer Society, Los Alamitos, CA, 2003.

[4] E. Astesiano et G. Reggio. Tight Structuring for Precise UML-based Requirement Specifications. In M. Wirsing, A. Knapp, and S. Balsamo, editors, Radical Innovations of Software and Systems Engineering in the Future, Proc. 9th Monterey Software EngineeringWorkshop, Venice, Italy, Sep. 2002., number 2941 in Lecture Notes in Computer Science. Springer Verlag, Berlin, 2004.

[5] R. Bace, P. Mell. Intrusion Detection Systems. NIST Special Publication on Intrusion Detection Systems, SP 800-31, 2001.

[6] D. Bjorner, S. Kousoube, R. Noussi, et G. Satchok. Michael Jackson’s Problem Frames: Towards Methodological Principles of Selecting and Applying Formal Software Development Techniques and Tools. In M. Hinchey and L. ShaoYing, editors, Proc. Intl.Conf. on Formal Engineering Methods, Hiroshima, Japan, 12-14 Nov.1997, pages 263–270. IEEE Press, 1997.

[7] S. J. Bleistein, K. Cox, et J. Verner. Problem Frames Approach for e- Business Systems. In K.Cox, J. Hall, and L. Rapanotti, editors, Proc. 1st International Workshop on Advances and Applications of Problem Frames (IWAAPF). IEEE Press, 2004.

[8] I. Bray et K. Cox. The Simulator: Another, Elementary Problem Frame?. Ninth International Conference on Requirements Engineering: Foundation for Software Quality, (REFSQ’03), Velden, Austria, 2003

[9] J. Cheesman et John Daniels. UML Components – A Simple Process for Specifying Component-Based Software. Addison-Wesley, 2001.

Bibliographie

74

[10] C. Choppy and G. Reggio. A UML-Based Method for the Commanded Behaviour Frame. In K. Cox, J. Hall, and L. Rapanotti, editors, Proc. of the 1st International Workshop on Advances and Applications of Problem Frames (IWAAPF 2004), pages 27–34. IEEE Press, 2004.

[11] C. Choppy et M. Heisel. Une approche à base de “patrons” pour la spécification et le développement de systèmes d’information. In AFADL 2004, Approches Formelles dans l’Assistance au Développement de Logiciels, 2004.

[12] C. Choppy et G. Reggio. Using UML for Problem Frame Oriented Software Development. In W. Dosch and N. Debnath, editors, Proc of the ISCA 13th Int. Conf. on Intelligent and Adaptative Systems and Software Engineering (IASSE-2004), pages 239–244. The International Society for Computers and Their Applications (ISCA), 2004.

[13] C. Choppy, D. Hatebur, M. Heisel, “Architectural patterns for problem frames”. IEEE Proceedings – Software, Special Issue on Relating Software Requirements and Architectures, 2005.

[14] C. Choppy, G. Reggio. A UML-Based Approach for Problem Frame Oriented Software Development. information and software technology 47, 2005.

[15] K. Cox, K. Phalp, A. Aurum, S. Bleistein et J. Verner. Connecting Role Activity Diagrams to the Problem Frames approach Proceedings of the 9th Australian Workshop on Requirements Engineering AWRE’04, Adelaide. 6-7 December 2004.

[16] K. Cox, J. G. Hall et L. Rapanotti. Editorial, “A roadmap of problem frames research”. Information and Software Technology 47, pp. 891–902, 2005.

[17] J. G. Hall, M. Jackson, R. C. Laney, B. Nuseibeh, et L. Rapanotti. Relating Software Requirements and Architectures using Problem Frames. In Proceedings of IEEE International Requirements Engineering Conference (RE’02), Essen, Germany, 9-13 September 2002.

[18] J. G. Hall et L. Rapanotti. Problem Frames for Socio-Technical Systems. In J. Mate and A. Silva, editors, Requirements Engineering for Socio-Technical Systems. Idea Group, Inc,2004.

[19] M.Jackson. Problem Architectures. A Position Paper for the ICSE-17 Workshop on Architectures for Software Systems ,1994.

[20] M. A. Jackson, Software Development Method, A Classical Mind: Essays in Honour of C. A. R. Hoare; A. W. Roscoe; Prentice-Hall, Chapter 13 ,1994.

[21] M. Jackson. Software Requirements & Specifications: a Lexicon of Practice, Principles and Prejudices. Addison-Wesley, 1995.

Bibliographie

75

[22] M. Jackson. Problem Analysis Using Small Problem Frames. South African Computer Journal 22, Special Issue on WOFACS’98, pp 47-60, 1999.

[23] M. Jackson. The real world. in millennial perspectives in computer science. In J. Davies, B. Roscoe, et J. Woodcock, editors, Proceedings of the 1999 Oxford-Microsoft symposium in honour of Sir Antony Hoare, pages 157-173. Palgrave.

[24] M. Jackson, “Problem Frames: Analyzing and Structuring Software Development Problems”, Addison-Wesley, 2001.

[25] M.Jackson. Why Software Writing is Difficult and Will Remain So. in J.Fiadeiro, J.Madey and A.Tarlecki (eds), Information Processing Letters Special Issue in Honour of Wlad Turski 88(1-2), 2003

[26] [La référence ???] M. Jackson. Problems, Subproblems and Concerns. Position Paper for the Early Aspects workshop at AOSD 2004.

[27] M. Jackson. Problem frames and software engineering. Information and Software Technology 47, pp: 903–912, 2005.

[28] S. Konrad et B. H. C. Cheng. Requirements Patterns for Embedded Systems. in Proceedings of the 10th Anniversary IEEE Joint International Conference on Requirements Engineering, IEEE Computer Society. pp. 127–136, 2002.

[29] R. Laney, L. Barroca, M.A. Jackson et B. Nuseibeh. Composing requirements using problem frames Proceedings of the 12th Int. Conf. on Requirements Engineering.

[30] W. Laouar et M.T. Kimour. An information gathering problem frame for embedded system engineering, Journées Ecole Doctorale JED’08, Annaba, pp 57-60, 2008.

[31] Z. Li, J. G. Hall, et L. Rapanotti. Reasoning about decomposing and recomposing Problem Frames developments: a case study. In K.Cox, J. Hall, and L. Rapanotti, editors, Proc. 1st International Workshop on Advances and Applications of Problem Frames (IWAAPF). IEEE Press, 2004.

[32] L. Lin, B.Nuseibeh, D. Ince, M. Jackson et J. Moffett. Introducing abuse frames for analyzing security requirements. In Proceedings of the 11th International Conference on Requirements Engineering, pages 371-2, Monterey, California,2003.

[33] M. Nelson, D. Cowan, et P.Alencar. Geographic problem frames. In Proceedings of the 5th IEEE International Symposium on Requirements Engineering, pages 306-7, Toronto, Canada,2001.

[34] M. Nelson, T. Nelson, P. Alencar, et D. Cowan. Exploring problem-frame concerns using formal analysis. In K.Cox, J. Hall, and L. Rapanotti, editors,

Bibliographie

76

Proc. 1st International Workshop on Advances and Applications of Problem Frames (IWAAPF). IEEE Press, 2004.

[35] OMG. UML Specification 1.3, 2000. Available at http://www.omg.org/docs/formal/00-03-01.pdf.

[36] L. Rapanotti, J. G. Hall, M. Jackson et B. Nuseibe, “Architecture-driven Problem Decomposition". In Proceedings of the 2004 International Conference on Requirements Engineering RE’04, Kyoto, IEEE CS Press, 2004.

[37] R. Seater et D. Jackson. Requirement progression in problem frames applied to a proton therapy system. In Proc. of the 14th IEEE Int. Requirements Engineering Conf. RE’06, pages 166{175, Minneapolis, Sept. 2006.

[38] E. Souza, M. Lencastre, R. Melo, L. Ramires et K. Alves, “Analyzing Problem Frames together with Solution Patterns”. Proceeding of 10th workshop on requirement engineering, 2007.

[39] J. Warmer et A. Kleppe. The Object Constraint Language: Precise Modeling with UML. Addison-Wesley, 1999.

[40] R.J.Wieringa. The declarative problem frame: Designing systems that create and use norms. In Proceedings of the 10th International Workshop on Software Specification and Design, pages 75–85, San Diego, USA. IEEE Computer Society. 5–7, 2000

[41] http://fr.wikipedia.org/wiki/Bo%C3%AEte_noire_(a%C3%A9ronautique)

[42] http://www.businessaviationdirectory.com/aviation-attorneys. January 2012.

Résumé

Les problèmes à résoudre par le développement de logiciel sont essentiellement liés à l’environnement dans lequel ce logiciel sera utilisé. De ce fait, les développeurs de logiciels doivent d’abord déterminer les caractéristiques de cet environnement ainsi que ses contraintes.

Récemment, les Problem Frames (PF) (schémas de problèmes) sont introduits comme moyen de classification, d’analyse et de structuration de problèmes. Introduite par Mickael Jackson, l’approche de problem frames fournit des diagrammes, des notations et des concepts permettant une description claire et directe du problème considéré. Elle offre, également, des mécanismes de décomposition de problèmes en sous-problèmes simples ce qui permet la réutilisation des solutions logiciel. L’idée principale repose sur l’identification des problèmes communs et simples qui peuvent être utilisés comme des patterns(patrons) sur lesquels les grands problèmes doivent être décomposés. Michael Jackson a identifié les principales classes de problèmes qu’on trouve dans le développement de logiciels. Chaque classe est capturée par un problem frame, en résultat cinq problem frames élémentaires ont été définis : required behavior PF, commended behavior PF, information display PF, workpiece PF, et transformation PF. En outre, d’autres problem frames ont été proposés dans la littérature.

Une étude approfondie de l’ensemble des problem frames existants nous a permis d’identifier les classes de problèmes non encore complètement cernés par les problem frames existants. Dans le cadre de ce travail, la contribution que nous avons proposé se répartit selon deux niveaux :

Le premier niveau concerne la définition et la caractérisation d’un nouveau problem frame ; le problem frame proposé « The Archivist » a été validé sur deux études de cas : système de détection des intrusions et système de gestion des boites noires des avions.

Le deuxième niveau concerne la proposition d’une approche de combinaison entre le problem frame proposé et le langage de modélisation graphique UML.

Mots clés : Ingénierie de logiciels, Spécification de besoin, Problem frames (PF), UML.

Abstract

The problems to be solved by software development are primarily related to the environment in which this software will be used. Therefore, software developers must first determine the characteristics of this environment and its constraints.

Recently, Problem Frames (PF) are introduced as a framework of classifying, analyzing and structuring the problems. Introduced by Mickael Jackson, problem frames approach provides diagrams; notations and concepts to describe frequently met problem structures of different kinds. It also provides the mechanisms of problems decomposition into simpler and smaller sub-problems which allows the reuse of software solutions. The main idea is based on identifying common and simple problems that can be used as patterns on which the complex problems must be broken. Michael Jackson has identified several basic classes of problems found in software development. Each class is captured by a frame problem; in result, five basic problem frames were defined: required behaviour PF, commended behaviour PF, information display PF, workpiece PF and transformation PF. In addition, other proposed problem frames have appeared in the literature.

In-depth study on major existing problem frames enables us to identify classes of problems not yet completely surrounded by the existing problem frames. In the context of this work, the proposed contribution is divided into two levels:

The first level concerns the definition of a new problem frame, the proposed problem frame « The archivist » was validated through tows case studies: network security and airplane flight.

The second level concerns the combination of the proposed problem frame with UML language in order to make further UML analysis and design feasible.

Keywords: Software engineering, Requirements specification, Problem frames, UML.

ملخصھا ھذا البرنامج لذلك وجب على مطوري البرامج فیالبرامج المطورة لحل مختلف المشاكل المطروحة تتعلق تعلقا وثیقا بالبیئة التي یستعمل إن

.معرفة مختلف خصائص و حیثیات البیئة التي یوجد بھا المشكلالمقترحة من طرف جاكسون من بین أھم الوسائل التي تسمح لنا بوصف و تصنیف و تحلیل ) Problem Frames(تعتبر أطر المشاكل

كما تسمح لنا بتقسیم مشكل معقد إلى مجموعة مشاكل بسیطة و معروفة ما یخول لنا االستفادة من حلول . المشاكل وكذا وصف البیئة الخاصة بھا . مسبقة

افة إلى ذلك تم اقتراح أطر أخرى في العدید من أعمال البحث ضإ. یل خمسة أصناف للمشاكلقام جاكسون باقتراح خمسة أطر أساسیة لثمث .العلمي لتمثیل أصناف المشاكل التي ال تستطیع أطر جاكسون تمثیلھا

:یمكن تقسیمھا إلى محورین أساسیین إذ. في ھذا اإلطار تندرج المساھمة التي قمنا بھالتمثیل المشاكل التي نسعى فیھا لجمع وحفظ المعلومات الخاصة ) The Archivist) (األرشیفي(األول في اقتراح إطار جدید للمشاكل یتمثل

.مدعمین ھذا االقتراح بأمثلة من الواقع،بسلوك نظام معین و مختلف الحاالت التي یمر بھا ھذا النظام .)UML(جة الموحدة ذة للجمع بین اإلطار المقترح و لغة النمأما فیما یخص المحور الثاني فنقترح فیھ طریق

). UML(جة الموحدة ذ، لغة النم(Problem Frames)ھندسة البرامج ، تحدید المتطلبات ، أطر المشاكل:الكلمات المفتاحیة

développement orienté modèles de logiciel à base de...

Documents