SOMMAIRE

INTRODUCTION............................................................................................................... 2
I. Qu’est-ce que les Problem-frames ............................................................................. 3
II. Pourquoi les problem-frames................................................................................. 3
III. Fonctionnement des probem-frames ..................................................................... 4
IV. Les cinq principaux problem-frames....................................................................... 6
V. Notions de base et décomposition des problem-frames ....................................... 11
1. Notions de base .............................................................................................................................................11
a. La machine ..................................................................................................................................................11
b. Les phénomènes .........................................................................................................................................11
c. Les domaines ...................................................................................................................................................12
2. Décomposition ...............................................................................................................................................14
VI. Cas concret relatif à l’approche des problem-frames : MVC AFrame ..................... 16
VII. Avantages et inconvénients des problem-frames ................................................. 17
1. Avantages .......................................................................................................................................................17
2. Inconvénients .................................................................................................................................................17
CONCLUSION ................................................................................................................ 18

1
 INTRODUCTION

La complexité des gros logiciels 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.

Une discipline appelée génie logiciel (software engineering) 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 tout 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. 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, 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.

2
 I. Qu’est-ce que les Problem-frames

Les Problem Frames (PF) (schémas de problèmes) sont des moyens 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 ce qui permet
la réutilisation des solutions de problèmes existants pour un nouveau problème de la
même classe. 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.

II. Pourquoi les problem-frames

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. 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 » comme un moyen

de classification, d’analyse et de structuration de domaine de problèmes.

3
III. Fonctionnement des probem-frames

Michael Jackson a proposé une nouvelle approche pour la spécification et l’analyse

des besoins appelée « Problem Frame, PF ».

Les Problem Frames 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 ici sur le problème plutôt que sur la solution.

Pour chaque PF, un diagramme est établi qui est une représentation générale d’un
PF.

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

4
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 besoin
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. 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 termes 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.

5
 En d’autres termes, 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.

IV. Les cinq principaux problem-frames

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 pattern 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. 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.

➢ Required Behaviour PF
Jackson a defini 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 ».
6
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é ci-dessous.

«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».

➢ 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.

7
Ce schéma 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 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 ».

➢ 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 «.

8
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 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 ».

➢ 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. Le
diagramme du Workpiece PF est illustré ci-dessous.

«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…).
9
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.

➢ Transformation PF
La definition 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 ».

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 transfert 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.

«TM » est la machine à développer. Nous 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
effectuer. 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 « OÙ ».

10
V. Notions de base et décomposition des problem-
frames
1. Notions de base
a. 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 deuxième type de problème « la machine ».

b. 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.

11
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.

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 dynamique et qui ont des états changeables à cause des différents événements
qui se produisent dans ce monde.

c. 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. 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. 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.

12
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’autres termes, il contrôle les roues.

❖ Des domaines bitables : 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 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.

13
 2. 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 :

− 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 », etc.

− 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, etc.

− 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 problème initial 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.

14
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.

Pour des cas particuliers de décomposition, les sous problèmes peut avoir des
phénomènes en commun créant par conséquent 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 entre 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.

15
VI. Cas concret relatif à l’approche des problem-
frames : MVC AFrame

Le MVC Aframe est le résultat de la combinaison de commended behaviour PF avec

le style architectural « MVC ».

Le MVC (Model-View-Controller) est un style architectural utilisé pour structurer un

logiciel à travers son interface utilisateur. La figure illustre le diagramme de MVC
Aframe, ses trois composants sont :

− 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.

16
VII. Avantages et inconvénients des problem-frames
1. Avantages

✓ Les problem-frames nous aide à analyser et comprendre le problème que nous

devons résoudre ;
✓ Les problem-frames permettent réutilisation des analyses génériques
existantes des problèmes typiques ;
✓ Les problem-frames accélèrent l'analyse et rende plus complète le résultat
✓ Les problem-frames permettent de concevoir des solutions en adéquation avec
le système dans lequel il sera utilisé

2. Inconvénient

La complexité d’utilisation des problem-frames est tel qu’il n’est pas possible à
n’importe qui de l’utiliser ; il faut avoir un niveau de réflexion poussée

17
 CONCLUSION
Nous avons commencé ce rapport 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’ensemble des problem frames proposés dans la
litérature) 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.

18