Informatique

Kolyang
Introduction au génie logiciel
Analyse des validation
besoins

conception intégration

implémentation

S
c
i
e
n
c
Ka arang
e
Introduction au génie logiciel

de

Kolyang
Université de Ngaoundéré, Cameroun

© Kolyang et Ka’arang : Editions et Média, 2006

Affiliation :
Dr.-Ing. Kolyang
Département de Mathématiques et Informatique
Faculté des Sciences
Université de Ngaoundéré

2
 Table des matières

Chapitre 1 : Introduction générale...................................................................... 5

1.1 Définitions.................................................................................................................................................................. 6
1.2 Facteurs de production................................................................................................................................................8
1.3 Les facteurs de grandeur du projet..............................................................................................................................8
1.4 Facteurs internes et externes....................................................................................................................................... 9
1.4.1 Facteurs externes................................................................................................................................................. 9
1.4.2 Facteurs internes et modularité.......................................................................................................................... 10
1.4.3 Facteurs de qualité et de productivité................................................................................................................ 12
1.5 Aspects de gestion.................................................................................................................................................... 13
Chapitre 2 : Historique sur le développement du logiciel.................................. 14
2.1 Contexte historique..................................................................................................................................................14
2.2. Génie Logiciel......................................................................................................................................................... 16
2.3. Méthodes (semi-)formelles ..................................................................................................................................... 17
2.4. Structuration et abstraction : concepts essentiels.....................................................................................................18
2.5. Modélisation dans le développement des systèmes ................................................................................................ 18
Chapitre 3 : Les modèles du développement des logiciels................................. 20
3.1 Rappels historiques...................................................................................................................................................20
3.2 Les modèles de développement ............................................................................................................................... 21
3.2.1 Modèle en cascade.............................................................................................................................................22
3.2.2 Développement évolutif (à incréments).............................................................................................................23
3.2.3 Modèle en spirale.............................................................................................................................................. 25
3.2.4 Modèles spécifiques.......................................................................................................................................... 27
3.3 Evaluation des procédés........................................................................................................................................... 29
Chapitre 4 : Analyse et définition des besoins................................................... 31
4.1 Structuration de l’analyse des besoins...................................................................................................................... 33
4.2 Validation des Besoins............................................................................................................................................. 35
4.3 Exemple de cahier de charges..................................................................................................................................37
Chapitre 5 : Gestions des versions et des configurations.................................. 43
5.1. Lois de Lehman ...................................................................................................................................................... 43
5.2 Identification des versions ....................................................................................................................................... 46
5.3 Notions de base du versionnage .............................................................................................................................. 47
5.4. La gestion de la configuration................................................................................................................................. 49
5.5 Nature des changements........................................................................................................................................... 50
5.5.1 Les cas classiques.............................................................................................................................................. 51
5.5.2 Cas des progiciels.............................................................................................................................................. 52
Chapitre 6 : Modélisation avec les méthodes semi-formelles............................ 54
6.1. Définition.................................................................................................................................................................54
6.2 Modélisation Entity/Relationship (ER).................................................................................................................... 55
6.3 Diagramme de flux de données................................................................................................................................ 56
6.4 Les modèles de classe ..............................................................................................................................................58
6.5 Modélisation Orientée Objet.................................................................................................................................... 59
6.6 Une introduction à UML ......................................................................................................................................... 59
6.7 Cas d’utilisation........................................................................................................................................................ 60
Chapitre 7 : La modélisation des classes .......................................................... 65
7.1 Les diagrammes des classes......................................................................................................................................65
7.2 Les classes............................................................................................................................................................... 67
7.2.1 L’identification des classes................................................................................................................................67
7.2.2 Les associations................................................................................................................................................. 69
Chapitre 8 : Modélisation formelle avec Z ......................................................... 71
8.1. Z...............................................................................................................................................................................71
8.2 Un exemple introductif : The Birthday Book........................................................................................................... 73
8.3 Modélisation des données avec Z et les diagrammes ER......................................................................................... 76
8.3.1 Equivalence et schémas..................................................................................................................................... 77
8.3.2 Les opérateurs et le calcul des schémas.............................................................................................................79
8.4 Raffinement du Birthday Book.................................................................................................................................81
8.5 Queens Problem (Problème des reines)....................................................................................................................83
Chapitre 9 : Des modèles aux codes.................................................................. 85
3
 9.1 Structuration, contexte et historique......................................................................................................................... 85
9.2 Structuration dans le langage orienté objet...............................................................................................................86
9.3 Classes versus module.............................................................................................................................................. 86
9.3.1 Les interfaces .................................................................................................................................................... 86
9.3.2 Les types et le polymorphisme.......................................................................................................................... 87
9.3.3 L’héritage ..........................................................................................................................................................87
9.4 Du code à partir des diagrammes de classe.............................................................................................................. 88
9.4.1 Les diagrammes de classe..................................................................................................................................88
9.4.2 La généralisation ...............................................................................................................................................89
9.4.3 Les associations ................................................................................................................................................ 89
9.5 Génération de codes à partir de Z.............................................................................................................................90
9.5.1 Les types de données ........................................................................................................................................ 90
9.5.2 les relations........................................................................................................................................................ 91
9.5.3 Les schémas ..................................................................................................................................................... 91
9.5.4 Les techniques de structuration..........................................................................................................................91
Chapitre 10 : les interfaces graphiques............................................................. 93
10.1 Aperçu sur les interfaces graphiques...................................................................................................................... 93
10.2 Recommandations de développement.................................................................................................................... 94
10.3 Technologies concrètes : Java /swing ....................................................................................................................96
10.4 Conclusion ............................................................................................................................................................. 98
Chapitre 11 : La validation et le test des logiciels ............................................ 99
11.1 Vérification et transformation.................................................................................................................................99
11.2 Validation des programmes par inspection...........................................................................................................100
11.3 Le test .................................................................................................................................................................. 101
11.3.1 Différents niveaux de test.............................................................................................................................. 103
11.3.2 Automatisation du test .................................................................................................................................. 104
11.4 Couverture de code...............................................................................................................................................105
Exercices d’application.................................................................................... 107
Questions de cours........................................................................................................................................................108
Sujets d’examen.............................................................................................. 112
Examen 1...................................................................................................................................................................... 112
Examen 2...................................................................................................................................................................... 112
Examen 3...................................................................................................................................................................... 113
Examen 4...................................................................................................................................................................... 114
Bibliographie .................................................................................................. 115

4
Chapitre 1 : Introduction générale

L’ingénierie, dans sa compréhension générale et publique, n’est pas possible

pour le logiciel. Un ingénieur peut construire un pont, étant convaincu qu’il
répond aux exigences et au modèle conçu. En informatique, la théorie et les
outils ne sont pas encore assez bons pour permettre de construire des
logiciels qui répondent à ce standard.
Le présent document a des objectifs moins ambitieux. Il discute des
méthodes de « fabrication » et de conception systématique de logiciels.
Le processus de développement de logiciel est connu pour être très
pernicieux. Au centre de ces procédés d’étude et de réalisation se trouve la
programmation. Tout logiciel ne vient à l’existence qu’avec la codification
dans un langage. La programmation est la description d’un calcul de manière
à l’exécuter sur une machine. L’on distingue généralement la programmation
in-the-small de la programmation in-the-large. La programmation in-the-
small concerne l’écriture de code pour résoudre des tâches claires et précises.
En implémentant couche par couche, l’on se retrouve généralement en train
de réaliser la programmation in-the-large : couler ensemble de larges
modules pour résoudre des tâches probablement mal définies. Ceci devient
alors un défi si les modules n’ont pas été préalablement conçus pour
fonctionner ensemble. C’est l’une des principales tâches du software
engineering, le génie logiciel. Pour mener à bien ces besognes, les
programmeurs ont besoin de plusieurs qualités, pour communiquer les
exigences (requirements), afin de résoudre le bon problème, analyser les
problèmes, les divisant en petites sous-tâches, organiser les solutions d’une
manière sensible, afin qu’elles se laissent comprendre et se changer
facilement, estimer les coûts, en sachant à l’avance si une approche donnée
est faisable ou non et enfin utiliser les mathématiques pour arriver à des
solutions correctes et simples. Dans sa compréhension comme technologie, le
génie logiciel s’occupe de toutes ces exigences.
Une application de grande envergure en opposition à un logiciel pour
une utilisation individuelle a plusieurs utilisateurs et souvent plusieurs
développeurs et techniciens qui en assurent la maintenance. Dans plusieurs
de ces cas, les développeurs, les usagers et les agents de maintenance sont
tous différents. Dans ce sens, le développement et la maintenance d’une
application logicielle nécessitent une approche beaucoup plus systématique
qu’un logiciel d’utilisation individuelle.
5
 La nécessité d’approches systématiques de développement du logiciel se
fait sentir dans les années 1960. Pendant cette décade, le matériel
informatique de la troisième génération est inventée et les logiciels systèmes
de multi-programming et du time-sharing sont développés. Ces facilités ont
introduit la technologie d’une implantation des systèmes informatiques
multi-utilisateur, en ligne et en temps réel. De nouvelles applications sont
développées tels les logiciels de réservation pour les lignes aériennes, les
systèmes d’information médicale, le contrôle des processus, les applications
militaires etc.
Plusieurs de ces systèmes ont été implantés et utilisés, plusieurs autres
tentatives n’ont jamais été réellement mises en service. Parmi celles
réceptionnées, plusieurs étaient sujets à des coûts prohibitifs par
dépassement du budget, réception tardive, inefficacité, et manque
d’acceptance par l’utilisateur. Quand les systèmes informatiques devenaient
de plus en plus larges et complexes, l’on réalisa que la demande pour les
logiciels devenait de plus en plus pressante, et largement au-dessus des
capacités de production. A deux conférences, en 1968 en Allemagne et en
1969 en Italie, organisées par l’OTAN, la notion de Software Engineering fut
émise pour souligner la nécessité d’avoir des techniques relevant de
l’ingénierie pour pouvoir résoudre le problème de production de logiciel.
Aussi la notion de software crisis (crise du logiciel) vit le jour.
Selon Boehm (1976), le génie logiciel concerne «the practical application of
scientific knowledge to the design and construction of computer programs and the
associated documentation required to develop, operate, and maintain them ».
Une autre approche de définition proposée par l’IEEE rapporte que le
software engineering est : « the systematic approach to the development,
operation, maintenance, and retirement of software » pendant que le logiciel
(software) est défini comme “computer programs, procedures, rules, and possibly
associated documentation and data pertaining to the operation of a computer
system”.
Le génie logiciel est une discipline technologique basée sur les
fondements de l’informatique, de la gestion, de l’économie, des techniques
de communication et de l’approche d’ingénierie pour la solution des
problèmes. Le génie logiciel est fondé sur l’informatique pour y puiser les
bases scientifiques tout comme le génie électrique ou le génie chimique sont
fondés sur la physique ou la chimie.
1.1 Définitions
Le génie logiciel diffère de la traditionnelle programmation par le fait
qu’il utilise des techniques et méthodes de l’ingénierie pour spécifier,
concevoir, implémenter, valider et maintenir des produits logiciels dans un
6
temps fixé et des contraintes budgétaires établies par le projet. Ensuite, le
génie logiciel obéit à des techniques de gestion qui sont en dehors du
domaine de la programmation traditionnelle. Dans un projet incluant
plusieurs programmeurs sur de longues périodes, le contrôle de gestion doit
s’occuper de la coordination de ces activités techniques.
Le programmeur est un individu concerné par les détails de
l’implémentation, la modification des structures de données et des
algorithmes écrits dans un langage de programmation. Les ingénieurs du
logiciel doivent en plus prêter attention à l’analyse, la conception, la
vérification et le test, la documentation, la maintenance du logiciel et la
gestion du projet. Les ingénieurs du logiciel doivent avoir considérablement
de l’expérience en tant que programmeurs pour bien estimer les domaines du
problème, les buts et objectifs.
Le terme computer software ou logiciel est souvent synonyme de
programme ou de code source. Souvent, il est aussi synonyme de produit.
Ainsi le logiciel inclut le code source, tous les documents associés et enfin la
documentation. Les documents de définition (requirement), les spécifications
conceptuelles, le code source, les plans de tests, les principes d’opération, les
procédures d’assurance de la qualité, les rapports des problèmes du logiciel,
les procédures de maintenance, les manuels d’utilisateur, les instructions
d’installation, les aides de formation constituent tous des composantes du
produit logiciel (software product). Les produits logiciels incluent aussi bien
les logiciels système que les applications développées dans un but spécifique.
La documentation explique les caractéristiques d’un document. La
documentation interne du code source décrit les caractéristiques du code et la
documentation externe explique les propriétés des documents liés au code.
Le développeur est synonyme de l’ingénieur logiciel. Le client est utilisé
pour désigner un individu ou une institution qui initie la procuration ou la
modification d’un produit logiciel. Le terme client n’induit pas
nécessairement un rapport financier entre le développeur et le client.
La qualité du produit est la préoccupation majeure des ingénieurs
logiciels. Les attributs de qualité les plus cruciaux sont : l’utilité, la clarté, la
fialibilité, l’efficacité et le coût effectif. Le plus important des attributs d’un
produit consiste dans le fait que ce dernier doit faire ce pour lequel il est
conçu. Le produit doit être écrit clairement et facilement compréhensible.
Comme le présent document le montrera, tester et maintenir un produit
consomment une large portion du budget de développement du logiciel.

7
1.2 Facteurs de production
Il existe deux grands facteurs dans le développement du logiciel : les facteurs
de grandeur liés au développement du logiciel, et ceux liés à la qualité et la
productivité. Pour toutes ces grandeurs, l’on a l’effort total dédié au produit
et les catégories de grandeur d’un produit. Le logiciel prend de plus en plus
de place dans les investissements.
La vie typique d’un logiciel est de 1 à 3 ans dans le développement et 5 à
15 ans dans l’utilisation. Le partage de l’effort entre le développement et la
maintenance est souvent présenté comme 40/40, 30/70 et parfois même
10/90. Ceci ne surprend pas si l’on comprend que la maintenance concerne
toutes les activités à partir de la publication initiale du produit.
La maintenance inclut trois aspects importants : l’augmentation des
fonctionnalités du produit, l’adaptation du produit à son environnement et la
correction des bogues.

1.3 Les facteurs de grandeur du projet

La grandeur des projets de logiciels détermine en grande partie la
technique, le niveau de gestion et les types d’outils à utiliser. On distingue les
projets triviaux, les petits projets, les projets de taille moyenne, les grands
projets, les projets très grands et les projets extrêmement grands.
Les projets triviaux sont des projets qui concernent en général un seul
programmeur, occupé quelques jours ou quelques semaines à écrire un
programme de moins de 500 instructions, divisés en 10 à 20 routines. Il s’agit
généralement d’un software personnel.
Quant aux petits projets, il s’agit d’un programmeur s’appliquant
pendant 1 à 6 mois pour un produit de 1000 à 2000 lignes divisées en des
paquets de 25 à 50 routines. Ici, il a très peu d’interaction avec d’autres
programmeurs.
Les projets de taille moyenne occupent 2 à 5 programmeurs travaillant
pendant 1 à 2 ans et résultant dans 10.000 à 20.000 lignes de code groupés en
paquets de 250 à 1000 routines. Une interaction entre les programmeurs, et la
communication avec les clients sont requises.
Les grands projets vont de 5 à 30 programmeurs occupés pendant une
période de 2 à 3 ans pour des lignes de code de 50.000 à 200.000, divisées en
différents sous-systèmes. Ces systèmes sont par exemple des compilateurs,
des bases de données, des systèmes graphiques. L’interaction est requise et la
communication est obligatoire. Déjà ici, les techniques de base du génie
logiciel sont à respecter.

8
 Les projets très grands. Ils utilisent 100 à 1000 programmeurs pour une
période allant de 4 à 5 ans. Le résultat est un système de plus d’un million
d’instructions. Par exemple, le système d’exploitation IBM OS/360 a été
développé par 5000 programmeurs.
2000 à 5000 programmeurs travaillent dans les projets extrêmement
grands pour une période allant jusqu’à 10 ans pour produire 1 à 10 millions
de lines of code (LOC).

1.4 Facteurs internes et externes

Le but fondamental du génie logiciel est la production de logiciel de
qualité. La qualité du logiciel n’est pas un concept facile. Elle comporte
plusieurs facettes. Chacun souhaite des programmes rapides, sûrs, facilement
utilisables, lisibles, modulaires, structurés etc. Mais ces qualificatifs désignent
différentes sortes de qualité.
D’un côté, nous désignons les qualités telles la rapidité ou la facilité
d’utilisation dont la présence ou l’absence peuvent se laisser constater par les
utilisateurs comme des facteurs externes. D’autres facteurs tels la
modularité, la lisibilité constituent des facteurs internes accessibles aux seuls
professionnels de l’informatique.

1.4.1 Facteurs externes

Correction : La correction est la capacité des produits logiciels de remplir
exactement leurs tâches telles que définies par les besoins et la spécification. La
correction constitue, sans ambages, la qualité primaire du logiciel. Quand un
système ne fait pas ce pour lequel il a été conçu, tout le reste est inutile. Mais
cette qualité est généralement plus facile à formuler qu’à atteindre, car
l’atteindre signifie que toutes les exigences du système sont décrites d’une
manière formelle.
Robustesse : Elle est la capacité pour un logiciel de fonctionner dans des
conditions extra-ordinaires. Elle se rapporte à ce qui se passe dans les cas
exceptionnels. Elle diffère de la correction, car ici le comportement du
système est défini pour les cas décrits explicitement dans la spécification.
La robustesse est une notion nécessairement moins claire que la
correction. Ici, elle concerne les cas non explicitement décrits dans la
spécification. Il est impossible de dire comme dans le cas de la correction que
le système doit assurer son travail, car per definitionem cette tâche est
inconnue. Si on pouvait bien le décrire ce cas d’exception deviendrait une
partie de la spécification. Le rôle de l’exigence de robustesse est de garantir

9
que dans des cas éventuels, le système ne livre des résultats catastrophiques.
Il devrait finir correctement sa tâche et passer à un état « d’exception ».
Extensibilité : L’extensibilité décrit la facilité avec laquelle le logiciel peut se
laisser adapter à des changements de spécification. Le logiciel est considéré
comme mou. Et effectivement, rien n’est plus facile que de changer un
programme. Le problème de l’extensibilité se trouve dans l’échelle. Les
changements dans de petits programmes ne constituent en général pas de
sérieux problèmes mais, dans le cas de la programmation in-the-large, ces
modifications peuvent être une vraie entorse au développement du logiciel.
Quand le programme est grand, il est aussi difficile à changer. Deux
principes pour l’amélioration de l’extensibilité consistent en la simplicité de
la conception, car une architecture simple est toujours plus faciler à changer
qu’une architecture compliquée. Aussi la décentralisation où chaque module
du logiciel doit être autonome est une technique importante.
Ré-utilisation : La ré-utilisation des logiciels est la propriété d’utiliser des
composantes pour de nouvelles applications. Le besoin de ré-utilisation apparaît
par l’observation selon laquelle plusieurs éléments des logiciels obéissent aux
mêmes motifs. Il est donc nécessaire de trouver ces similitudes et d’utiliser
ces méthodes au lieu de réinventer de nouvelles solutions. La ré-utilisation
est très importante parce qu’elle permet de réduire les coûts totaux de
développement de logiciels et de se concentrer ainsi sur les aspects tels la
robustesse, la correction etc. Une bonne réutilisation signifie qu’il existe des
bibliothèques.
Compatibilité : Elle est la mesure de la simplicité avec laquelle les produits
logiciels peuvent se laisser combiner avec d’autres. La compatibilité est
importante, car les produits logiciels ne sont pas développés dans un
vacuum : ils doivent interagir avec d’autres.
Il existe d’autres qualités telles l’efficience, la portabilité, la vérifiabilité,
l’intégrité et l’ergonomie.

1.4.2 Facteurs internes et modularité

Comme la structuration et l’ergonomie, la modularité est l’un des mots-
clés du génie logiciel. Mais il manque de définition exacte. La programmation
modulaire se comprenait d’abord comme le processus du développement de
logiciel à partir des petites portions ou sous-programmes. Mais cette
technique ne peut comporter d’avantages pour l’extensibilité et la
réutilisation que si ces portions – appelées aussi modules – sont fermées et
organisées dans des architectures robustes.

10
 Plusieurs critères servent à l’évaluation des méthodes de conception en
rapport avec la modularité : la divisibilité modulaire, la combinaison
modulaire, la compréhensibilité modulaire, la continuité modulaire et enfin
la protection modulaire.
Divisibilité modulaire : Le critère de division modulaire est rempli quand la
méthode de conception permet la division d’un problème en sous-tâches de
manière que la solution à celles-ci soit recherchée d’une manière individuelle.
Par cette méthode, la complexité originale est subdivisée en complexité plus
réduite, puisque le système est subdivisé en sous-systèmes reliés entre eux
par des structures plus simples. Ce critère est absolument nécessaire pour le
développement de logiciels non triviaux. Cette division existe aussi sous la
méthode top-down. Avec cette hiérarchie, l’on commence avec une
description abstraite de la fonctionnalité du système, avant de le raffiner
étape par étape. Chaque sous-système se raffine ensuite en d’autres sous-
systèmes plus petits de manière que les derniers soient directement
programmables parce qu’ils sont à un niveau d’abstraction plus faible.
Combinaison modulaire : Une méthode de développement remplit le critère de
combinaison si elle permet la production des éléments de logiciels qui
peuvent se laisser combiner pour obtenir de nouveaux systèmes plus grands.
Pendant que la division modulaire s’occupe de la dérivation des produits à
partir de la spécification, la combinaison, elle, s’occupe du processus inverse,
avec l’exigence que les éléments de logiciel existants soient utilisés dans la
construction du logiciel en question.
La combinaison se veut réaliser un vieux rêve à savoir rendre le processus
de développement du logiciel comme une activité de construction en
morceaux, de manière que les programmes naissent à partir de la
combinaison des éléments standards par exemple d’une bibliothèque.
Compréhensibilité modulaire : Une méthode favorise la compréhension
modulaire quand elle soutient la construction des modules compréhensibles
par un lecteur humain. Dans le pire des cas, le lecteur ne devrait pouvoir voir
que quelques modules voisins. Ce critère est important pour la maintenance.
Continuité modulaire : Une méthode de conception remplit le critère de
continuité modulaire si une petite altération dans la spécification du
problème ne cause de changement que dans un ou peu de modules qui
peuvent être dérivés à l’aide de cette méthode à partir de la spécification. Un
tel changement ne doit pas modifier l’architecture du système, c’est-à-dire les
relations entre les modules.
Protection de module : Une méthode remplit le critère de protection
modulaire si elle conduit à des architectures dans lesquelles des erreurs

11
pendant l’exécution ne se limitent qu’à ce module ou à des modules
limitrophes.
Les cinq critères sus-discutés conduisent à cinq principes importants pour
la réalisation d’une modularité adéquate. Ils concernent entre autres les
entités modulaires en rapport avec le langage, le nombre réduit d’interfaces,
les interfaces minces (couplage faible), les interfaces explicites et le principe
secret.
Les entités modulaires du langage : Les modules doivent respecter les entités
syntaxiques du langage utilisé. Le formalisme utilisé pour la conception des
programmes doit concourir au principe de la modularité.
Nombre limité d’interfaces : Ce principe limite le nombre total de voies de
communication entre les modules dans une architecture de logiciel. Chaque
module devrait communiquer avec le moins de modules possible. Ici, la
communication peut-être issue d’un appel de procédures pour le partage des
structures de données. Par exemple, si un programme a n modules, alors le
nombre de communication inter modulaires devrait se retrouver autour du
minimum n-1 que du maximum n(n-1)/2.
Interfaces minces (couplage faible) : Ce principe se rapporte à la grandeur des
liaisons inter modulaires et non leur nombre. Quand deux modules
communiquent entre eux, ils doivent échanger le moins d’information possible.
Interfaces explicites : Avec ce quatrième principe, l’on veut établir un
régime totalitaire sur la société des modules. L’on requiert non seulement
que chacun parle avec très peu d’autres modules et que cette conversation se
limite à très peu de mots, mais nous ordonnons encore que cela se passe
publiquement. Quand deux modules A et B communiquent, cette interaction doit
transparaître du texte de A ou de B.
Principe secret (Information hiding) : Chaque information sur un module
doit être interne quand elle n’a pas été déclarée explicitement comme
publique. L’application de ce principe requiert que chaque module est connu
par le reste du monde par une description officielle, appelée interface.
Tous ces principes et facteurs de qualité sont décrits en détail dans Bertrand
Meyer.
1.4.3 Facteurs de qualité et de productivité
Le développement et la maintenance du logiciel sont très complexes. Pour
ceux qui n’ont écrit jusqu’ici que de petits programmes et des devoirs à la
maison, ce constat peut être surprenant. Plusieurs facteurs qui influent sur la
qualité du logiciel doivent être bien maîtrisés. Ils sont la capacité individuelle
(individual ability), la communication d’équipe (team communication), la
complexité du produit (product complexity), une notation appropriée
12
(appropriate notation), une approche systématique (systematic approaches),
le contrôle des changements (change control), le niveau technologique (level
of technology), la confiance requise (required reliability), le temps disponible
(available time), la compréhension du problème (problem understanding), la
stabilité des exigences (stability of requirements), les qualités exigées
(required skills), les moyens et ressources (facilities and ressources), une
formation adéquate (adequacy of training), des qualités de gestion
(management skills), des objectifs appropriés (appropriate goals). Toutes ces
qualités doivent répondre des attentes croissantes (raising expectations)
portées au logiciel.

1.5 Aspects de gestion

Les activités techniques et de gestion sont très importantes dans le succès
d’un projet de développement de logiciel. Les gestionnaires contrôlent les
ressources et l’environnement dans lequel les activités techniques se passent.
Ils ont aussi la responsabilité ultime de livrer le produit dans le temps fixé et
dans les limites des coûts. De surcroît, il faut que le produit respecte la
fonctionnalité et la qualité désirées par le client. Les problèmes les plus
cruciaux dans le développement d’un logiciel et qui relèvent généralement
du domaine de la gestion peuvent se classifier en problèmes de planification,
en difficultés organisationnelles, en problèmes de contrôle et de direction.

13
Chapitre 2 : Historique sur le développement du logiciel

Le logiciel n’est pas un produit naturel. Tout logiciel est construit. La

discipline qui construit les logiciels diffère largement des autres disciplines
scientifiques. Pendant que les autres sciences examine comment les choses
sont et fonctionnent, la production du logiciel construit des modèles du
monde réel avant de les réaliser.
Le développement d’un système informatique d’une certaine grandeur
requiert en moyenne deux à trois ans de développement Aussi 50 à 80 % des
ressources sont consacrées à la maintenance. Ces deux constats ne facilitent
pas la réactivité exigée dans les systèmes informatiques. De surcroît COBOL
(Common Business Oriented Language) reste de loin le langage le plus
utilisé. L’on estime à 100 milliards les lignes de codes dans le monde et 77 %
soient 80 milliards sont en COBOL. Pourtant, depuis près de 40 ans, on
annonce la prochaine fin de COBOL.
Cinquante pour cent (50%) de programmes de gestion fonctionnent sur des
ordinateurs IBM. Malgré les difficultés d’IBM (système non sécurisé, arrêt
brusque et fluctuation des versions du système d’exploitation …), la montée
en puissance du modèle client/serveur et de UNIX, malgré toutes ces
difficultés, seuls 16 % de développeurs utilisent les outils du développement
du génie logiciel (CASE Tools).
Ces statistiques sont alarmantes, seuls environ 70% des projets de
développement des logiciels se terminent avec succès. Sur la période totale
de développement, chaque participant produit moins de 10 lignes de code
exécutable par jour. Pendant la période de développement, l’on trouve sur
1000 lignes de codes 50 à 60 erreurs et après livraison, il existe encore jusqu'à
4 erreurs pour 1000 lignes. Il est nécessaire de savoir comment on est arrivé à
cette situation catastrophique.

2.1 Contexte historique

Au début, la production du logiciel est considérée comme « the art of
computer programming » selon le pape de l’informatique Donath Knuth.
Cette période allant jusqu’au début des années 1960 est marquée par le
développement des logiciels individuels avec une complexité réduite et

14
tournée vers des applications spécifiques dans le mode de traitement de lots
(batch modus) c’est-à-dire un ordinateur, un programme.
Dans cette décade, le logiciel était orienté au traitement de lots (batch) sur
les cartes perforées. La mémoire vive était très petite. La complexité du
système était très simple. La programmation se faisant dans les langages
proches de la machine. Les représentants de ces langages sont : COBOL
(Common Business Oriented Langages), FORTRAN (FORmula
TRANsformation), ALGOL (Algorithmic Language). La mauvaise expérience
réalisée dans le développement des grands systèmes a conduit à l’éveil d’un
intérêt pour les questions de sémantique et de conception. Pendant cette
décade naît la recherche sur les types des données structurées. Elle conduit
aux langages tels ALGO 68, C, Pascal, ADA.
La deuxième période de la décennie 1960 au milieu des années 1970 est
marquée par une augmentation rapide dans l’utilisation du logiciel. Les
raisons se trouvent dans un développement rapide du matériel aussi bien
dans la capacité que dans la vitesse. Une nécessité du développement des
logiciels de base se fait sentir, afin de gérer les ressources « chères » telles la
mémoire et le temps de calcul. L’on aboutit alors à des systèmes de
multiprogrammation et multi-utilisateur. Les données immenses peuvent
être sauvegardées (bases de données) et l’on aboutit à une sorte d’interaction
avec l’ordinateur. Le logiciel devient alors un produit auquel des maisons de
logiciel peuvent se consacrer.
La troisième période, dans la décade du milieu des années 70 au milieu des
années 80, est marquée par l’interconnexion des systèmes matériels, dans des
réseaux locaux et ensuite mondiaux. Poussée par le développement du
Hardware, l’on aboutit à une énorme complexité des solutions logicielles. La
sécurité et l’accessibilité deviennent alors des aspects importants de la qualité
du logiciel. Les ordinateurs individuels révolutionnent le travail de bureau.
La technologie permet de traiter des projets de plus en plus grands. Ces
exigences de l’ingénierie conduisent à de nouveaux problèmes ; entre autres
la programmation en équipe conduisant à la division de la conception, le
partage de l’analyse ainsi que celle de la spécification et de la codification, les
méthodes de programmation structurée n’étant pas scalables, elles ne se
laissent pas utiliser pour des cas larges. Les limites se trouvent dans
l’utilisation des données globales, la construction monolithique et sans
modules, les interfaces mal définies. Les chercheurs acquièrent lentement la
connaissance que le développement du génie logiciel exige une technologie
plus profonde. Cette connaissance soutient les notions telles le Software
Engineering (génie logiciel), la programmation structurée, le Stepwise
refinement (raffinement par étape), la modularisation et les Abstract Data

15
types (ADT). Les résultats de ces recherches sont réalisés dans les logiciels
tels Pascal, Modula-2, ML, C++, JAVA.
Aujourd’hui l’on est en présence d’une complexité ardue. Les micro-
systèmes sont moins chers et massivement distribués. Par exemple, un
véhicule compte aujourd’hui des centaines de micropocesseurs. Ces derniers
sont de plus en plus utilisés dans des situations à sécurité critique : contrôle
des avions, trains, réacteurs nucléaires…
Ici, le fonctionnement correct est exigé. Dans cette armada d’exigences,
quel est le rôle ou quelles sont les possibilités du Génie Logiciel ? De prime
abord il est important de rappeler qu’il n’existe pas dans la programmation
de potion magique ou de panacée. Dans ce sens, le génie logiciel diffère
grandement de l’informatique pratique. Il existe, cependant, des techniques,
des méthodes et des outils qui réduisent la complexité de la construction des
programmes. Il est néanmoins difficile de présenter tous les contenus de ces
techniques car le climat industriel diffère de l’académie et différents problèmes
exigent différentes techniques.

2.2. Génie Logiciel

Le terme Software Engineering (Génie Logiciel) remonte à 1968. C’était le
titre choisi pour une conférence sur la crise du logiciel organisée à l’initiative
de l’OTAN. Cette notion de Software Engineering suggère l’analogie avec les
disciplines tel que le Génie Chimique et a pour but d’alerter les
informaticiens sur le caractère rudimentaire de leur technique de
développement, car il n’existe point de consensus sur ce qu’est le génie
logiciel. Certains chercheurs soulignent les méthodes de construction et les
aspects économiques tels la planification, la création de document, les check
points. D’autres mettent l’accent sur les heuristiques informelles, enfin
d’autres soulignent les méthodes formelles et semi-formelles. Avant de
définir le Génie Logiciel, précisons ce qu’est le logiciel. Nous l’empruntons à
Bertrand Meyer :
« On regroupe sous le terme de logiciel les différentes formes de programmes qui
permettent de faire fonctionner un ordinateur et de l’utiliser pour résoudre des
problèmes, les données qu’ils utilisent et les documents qui servent à concevoir ces
programmes et ces données, à les mettre en œuvre, à les utiliser et à les modifier ».
Cette définition a l’avantage d’inclure dans le logiciel non seulement les
programmes mais aussi les données et la documentation associée.
Dans l’Encyclopaedia Britannica, le Engineers Council for Professional
Development définit le terme « Engineering » comme suit :

16
 « l’application créative des pricinipes sicentifiques à la conception et le
développement des structures, des machines, des appareils ou des processus de
production […] en rapport avec une fonction souhaitée, une économie d’action et de
sécurité de la vie et de la propriété »
On peut maintenant définir le Génie Logiciel selon MEYER :
« On appelle Génie Logiciel l’application des méthodes scientifiques au
développement de théories, méthodes, techniques, langages et outils favorisant la
production de logiciel de qualité ».
Le Génie Logiciel n’est donc pas seulement limité aux outils, il comprend
les méthodes, les théories des langages et les techniques. La particularité de
ces méthodes, outils et techniques… est de s’appliquer à la production du
logiciel.

2.3. Méthodes (semi-)formelles

Un logiciel est dit formel si une syntaxe est fixée et une sémantique est
décrite mathématiquement. Une méthode de développement est dite formelle
si elle est basée sur un logiciel formel pourvu des règles de transformations et
des preuves attachées à sa sémantique.
Dans le domaine du développement du Génie Logiciel, plusieurs méthodes
semi-formelles existent. On retrouve, par exemple, l’Unified Modelling
Language (UML), Vienna Development Method (VDM), RAISE, Atelier B,
etc.
Les techniques formelles de développement possèdent des avantages
parmi lesquels une syntaxe comparativement peu large, la précision dans
l’expression, des règles de transformation précises permettant un traitement
automatique, un cadre unique permettant d’aller de la spécification au test en
passant par les différentes phases du développement. L’inconvénient majeur
de ces techniques réside dans la difficulté de non maîtrise par les non-
techniciens.
Les thèmes essentiels du Génie Logiciel sont la structuration du processus
de développement comportant le modèle du processus et l’aide par des
outils, la construction des modèles, la spécification, le raffinement,
l’implémentation et la vérification.
Dans le processus de développement de logiciel, les langages de
programmation jouent un rôle crucial. Tous les langages ont presque la
même force d’expression. Cependant certains soutiennent mieux le
développement que d’autres à travers le type de données par l’abstraction et
le principe secret, la paramétrisation pour une meilleure réutilisation, les
séquences d’états ou les affectations, le typage sévère ou strict et l’héritage.
17
 Aujourd’hui, il est judicieux d’utiliser Java qui permet une technologie
orientée objet et l’utilisation des bibliothèques et classes. Pour les approches
fonctionnelles, Java ne supporte pas la programmation.

2.4. Structuration et abstraction : concepts essentiels

Pour résoudre la complexité des programmes, deux notions sont
essentielles : la structuration et l’abstraction. La structuration sert à planifier
l’énoncé d’un problème. L’abstraction vise l’élimination des détails peu
importants. Les moyens de structuration et de simplification classiques sont :
 La décomposition fonctionnelle qui consiste en la partition d’une tâche
en sous-tâches ou sous-classes indépendantes.
 La conception paramétrisée et générique qui est une méthode
permettant la réutilisation.
 Les modèles de pensées simples pour une meilleure compréhension des
tâches et des solutions possibles.
 Les niveaux d’abstraction permettant différents degrés de détail.
 le principe secret (information hiding) créant les interfaces et une
description orientée propriétés.
Dans toutes les méthodes, une description claire de l’interface est
nécessaire. Une interface est la transition réelle ou imaginaire entre deux
unités fonctionnelles avec des règles conclues (protocoles) pour la
transmission des données et/ou des signaux.
Une interface est la base de compréhension entre le spécificateur,
l’implémentateur et l’utilisateur. Tout l’essentiel des techniques et de
l’analyse dans le Génie Logiciel traite de l’interface. Deux propriétés
importantes des interfaces doivent être prises en compte. Les propriétés
syntaxiques qui assurent une utilisation correcte de l’unité fonctionnelle, et
les propriétés sémantiques qui documentent le comportement de l’unité
fonctionnelle et un usage correct.

2.5. Modélisation dans le développement des systèmes

Tout développement d’un système vise la résolution d’un problème du
monde réel. Puisque ce dernier est complexe, il est essentiel d’utiliser
l’abstraction pour une bonne approche de solution. Normalement un
problème informel peut se laisser modéliser par divers moyens.
La modélisation joue un rôle important dans les phases initiales du
développement. Toute modélisation vise une fixation précise et univoque des
18
besoins, une liberté par rapport aux algorithmes et structures de données.
Cependant dans l’analyse et la définition des besoins, elle est parfois difficile
à utiliser.
La modélisation occupe une place de choix dans l’architecture des
solutions. Ici, elle se présente sous la forme de composantes, dépendances,
communication selon les éléments. Mais, elle peut aussi se présenter d’une
manière modulaire en entités, interfaces, flux de communication etc.
Le style de la description dépend en majeure partie de la notion de
composante utilisée. On a par exemple les fonctions, les modules, les classes.
En résumé, dans le génie logiciel, il s’agit d’un développement à grande
échelle avec les problèmes que cela comporte. Dans le processus de
développement, des techniques d’abstraction et de structuration sont
utilisées. Une vue formelle permet de préciser la modélisation et raffinement
et de formuler les propositions de preuve sur l’efficacité du produit.

19
Chapitre 3 : Les modèles du développement des logiciels

Analyser un Système d'Information (SI) déroute parfois le non-initié, car

traduire un environnement de travail en symboles cabalistiques n'est pas très
habituel pour qui ne connaît pas. Pourtant, avec une once de théorie et deux
grammes de pratique, on se rend compte que le processus est très abordable,
soumis à quelques règles simples, faciles à acquérir et qui s'appliquent
toujours de la même manière. Pour développer un logiciel de qualité,
plusieurs techniques sont utilisées. Certaines se rapportent directement au
cycle de vie du logiciel.
Le cycle de vie est une modélisation conventionnelle de la succession des
étapes par lequel passe un logiciel, de la conception à la maintenance. Ces
différentes étapes peuvent varier légèrement d’une méthode à une autre. Les
exigences posées aux différentes méthodes concernent généralement le
développement de système avec de bonnes propriétés à savoir l’adéquation
où le système doit remplir les besoins souhaités ; l’ergonomie qui s’occupe des
interfaces appropriées avec la présence d’une documentation ; la fiabilité qui
traite de la correction, de la sécurité et de la robustesse d’un logiciel ; la
maintenance qui doit assurer que le système est facile à améliorer et à
modifier, le coût qui exige que les frais et la durée du développement doivent
être abordables et les ressources minimales.

3.1 Rappels historiques

Les anciens projets de développement de logiciel obéissaient à une
méthodologie de développement dite CODE-AND–FIX dont les étapes sont :
1) écrire le code (programme), 2) l’améliorer (élimination des fautes,
extension de la fonctionnalité, …) et 3) GOTO 1.
Le Code and Fix n’est pas une méthodologie qui aurait un jour un sens. Il est
défini comme la plus primitive et la moins productive possible de toutes les
méthodologies.
Le développement Code and fix n’est en soi pas une stratégie mais un
artefact provenant de la pression imposée aux développeurs de logiciel. Sans
comprendre le processus de conception, les programmeurs se mettent à
produire des lignes de code. A un certain moment, la phase de test
commence (souvent tard dans le développement), alors les bogues que l’on
20
ne pouvait éviter doivent être trouvés et résolus avant que le produit ne soit
livré.
Ce type de méthodologie de développement n’est approprié que pour un
projet individuel ou des exercices d’étudiants. Elle ne s’applique qu’aux
développements à petite échelle. Elle charrie avec elle une pléthore
d’inconvénients qui a conduit à ce que l’on a appelé la crise de logiciel dont
les conséquences sont la diminution continuelle de la maintenabilité et de
l’efficacité. La démission du programmeur conduit inévitablement à l’arrêt
du projet d’où l’inadaptation de cette méthodologie aux grands projets
Enfin, quand le programmeur n’est pas identique avec l’utilisateur, il existe
parfois de grandes divergences quant à la fonctionnalité requise.
L’on définit le processus du développement comme toutes les activités et
résultats se rapportant à la construction d’un logiciel. Ces activités se
regroupent autour de 4 axes principaux :
 La spécification : elle consiste en la définition de la fonctionnalité et des
contraintes à imposer au produit.
 La conception et l’implémentation : elles concernent l’étape de la
construction du produit.
 La validation : elle couvre toutes les vérifications et les tests.
 La maintenance : ce sont les améliorations et l’adaptation future du
produit à son environnement.
La présentation de ces activités diffère d’un modèle à un autre. Elle peut
aussi dépendre du type de produit ou de l’organisation de celle-ci.

3.2 Les modèles de développement

Le principal but du modèle est d’obtenir des processus de développement
rationnels, reproductibles et contrôlables. Il existe plusieurs modèles de
développement que l’on peut classifier en deux groupes. On distingue
grosso-modo la classe descriptive qui répond à la question comment les
systèmes sont-ils développés de la classe prescriptive qui répond à la question
comment les systèmes doivent-ils être développés.
Parmi les modèles, on a, entre autres, le modèle en cascade (water fall). Ici, les
activités sont présentées en des phases séparées. Après chaque phase, le
résultat est examiné. Le modèle évolutif (à incréments), quant à lui, possède les
activités imbriquées c’est-à-dire une activité se retrouve dans une autre. Le
système se développe rapidement à partir d’une spécification grossière. Le
modèle de transformation formelle exige qu’une spécification formelle soit

21
transformée en un programme. Le modèle de construction de composantes
réutilisables concerne une réutilisation des composantes déjà existantes.

3.2.1 Modèle en cascade

Il est aussi désigné de modèle de phases ; il est le premier modèle de
développement proposé par ROYCE en 1970 et existe en plusieurs variantes.
Le processus le développement est partitionné en phases. Chaque phase doit
être close avant que la suivante ne commence. Chaque phase livre un produit
(un document ou un programme).

Requirements
définition

System and
Software Design

Implantation
And Unit Testing

Integration and
System testing
Axe de temps
Operation and
Maintenance

 Analyse et définition des besoins : les applications du système sont fixées de

commun accord avec les clients. Ces besoins sont définis de manière à
être compréhensibles par les deux parties (client et développeur).
 Conception du système : les besoins sont subdivisés en systèmes logiciel et
matériel. L’architecture du système est fixée.
 Implémentation et test des unités : le système est réalisé comme une
collection d’unités fonctionnelles. Chaque unité est testée.
 Intégration et test du système : les unités sont mises ensemble et testées. Le
système est ensuite livré au client.
 Exploitation et maintenance : elle concerne la réparation des fautes et
l’amélioration du système.
L’avantage de ce modèle réside dans sa haute visibilité. Le tableau suivant
donne un aperçu des documents produits :
Activité Document produit
analyse des besoins Une étude de faisabilité et une esquisse de besoins
définition des besoins un plan des besoins
spécification du système la spécification fonctionnelle, un plan de test, la conception de
la documentation pour les usagers.

22
La conception architecturale la spécification architecturale et un plan de test du système.
La conception des interfaces La spécification des interfaces et le plan de texte d’intégration
La conception détaillée La spécification et plan de texte des unités fonctionnelles
Le test des unités Un rapport
Le test des modules Un rapport
Le test d’intégration Un rapport
Le test du système Un rapport et une documentation finale pour les utilisateurs
Le Test d’acceptance Un rapport
La programmation Le programme

La sortie d’une phase constitue l’entrée de la prochaine. Il existe

cependant quelques problèmes avec le modèle en cascade. Il y a trop de
documentation et un déluge de papiers. Ce qui a conduit au développement
des ateliers de génie logiciel qu’on a appelés CASE–Tools (Computer Aided
Software Engineering-Tools). Aussi, les étapes individuelles se recoupent
souvent par retour car les besoins ne sont pas généralement bien précisés au
début. Les idées mûrissent avec l’avancée du projet. Les problèmes sont
souvent repoussés et reprogrammés à la fin autrement.
Alternativement, il existe un affaiblissement du modèle en cascade par
liaison retour. Il en résulte un autre problème qui est celui de la fréquence
itérative. Pour résoudre ce problème, la nécessité des check point se fait
sentir.

Requirements
definition

System and
Software Design

Implantation
And Unit Testing

Integration and
System testing

Operation and
Axe de temps Maintenance

3.2.2 Développement évolutif (à incréments)

L’idée principale du développement évolutif est de développer un
prototype avec l’aide du client et de l’améliorer continuellement. Ce modèle
existe au moins sous trois variantes : la programmation explorative, le prototype
rapide et le prototypage évolutif et participatif.
Le mot prototype signifie échantillon primaire, forme originelle, forme
primitive. Dans l’informatique, prototype signifie système développé comme
modèle de test. Le processus commence généralement avec une analyse des
besoins très grossière. Le prototype et les besoins sont améliorés pas à pas.
23
 Rapid prototyping : Le prototypage rapide provient initialement du
domaine d’ingénieurie de construction. Sous la notion de rapid prototyping,
l’on comprend la construction (rapide) d’un système fonctionnel qui possède
les propriétés essentielles du système logiciel final. (Forbrig, 2001). Les
utilisateurs du système ne sont pas impliqués dans ce développement. Ces
prototypes sont utilisés pour mieux définir les différentes phases de la
planification du logiciel.
Prototypage exploratif (Explorative prototyping): L’on désigne de prototypage
exploratif l’implémentation d’un software pour examiner la faisabilité
technique de certaines parties critiques du système. (Forbrig, 2001). Ce
modèle explore la faisabilité d’un système ou de ses parties. La finalité n’est
pas un système complet. Il s’agit d’un prototypage expérimental.
Prototypage évolutif et participatif : Il se fonde sur deux principes: évolution
et participation. L’aspect évolutif résulte du fait que l’on commence avec une
spécification très grossière. La participation provient de l’implication des
utilisateurs dans tout le processus de développement. En reliant l’évolutif au
participatif permet aux usagers et aux développeurs d’identifier très tôt les
déficiences du produit. Les développurs peuvent alors prendre
d’importantes mesures pour éviter l’insatisfaction des utilisateurs qui
conduit parfois au rejet du produit.

La programmation explorative interroge les clients sur leurs besoins, l’on

débute avec les besoins de base du système sur lesquels se greffent d’autres
possibilités plus tard et le prototype jetable (Throw–Away-Prototyping) qui a
pour but de comprendre les besoins du client à travers un prototype. A l’aide
de ce prototype, on expérimente ensemble avec le client pour mieux
comprendre et définir ses besoins
D’une manière théorique, l’utilisabilité du prototype est grande mais
elle comporte beaucoup d’inconvénients parmi lesquels la non visibilité car il
est difficile de mesurer le progrès, la mauvaise structuration car il est basé sur
les changements continuels et la nécessité d’un savoir profond. Pour ce faire,
l’on a besoin des petits groupes des développeurs excellents et très motivés.

Planification + première définition

du produit

Construction du prototype

oui
Nouveau
prototype Modification de la
nécessair définition du produit

24
non

maintenance
Livraison +implantation
 D’une manière pratique, l’applicabilité est restreinte aux petits systèmes
avec une durée de vie limitée. Un exemple typique est l’intelligence
artificielle où il est difficile de spécifier les capacités et les activités humaines.
Puisque le développement d’un logiciel est en règle normale un service, il
est nécessaire d’assurer un minimum de communication entre les usagers et
les prestataires de service. Ceci ne peut se faire que dans une coopération
étroite entre les développeurs et les utilisateurs futurs du logiciel. C’est
pourquoi le thème du développement participatif de logiciel n’est pas à
séparer des questions de coopération (des développeurs entre eux et des
développeurs avec les utilisateurs). (Dahme et Hesse, 1997).

3.2.3 Modèle en spirale

Ce modèle couvre les aspects évolutifs et l’évaluation du risque dans le
développement logiciel. Chaque tour de spirale correspond au prochain
prototype pendant que l’angle de la spirale correspond au temps et les
rayons aux coûts. Chaque tour du spirale se subdivise en 4 phases
principales.

Le modèle en spirale, une idée de Barry W. Boehm en 1988, met l'accent sur
l'analyse des risques. Il est beaucoup plus général que les précédents et peut
même les inclure. La première des quatres étapes que comporte chaque cycle
est la détermination des objectifs, des alternatives et des contraintes à partir des
résultats du cycle précédent et pour le premier à partir d'une analyse
préliminaire des besoins ; la deuxième concerne l’analyse des risques,
l’évaluation des alternatives, et éventuellement un prototypage; la troisième est
le développement et la vérification de la solution retenue ; la quatrième est la
revue des résultats et la planification du cycle suivant. Le modèle en spirale
utilise systématiquement des prototypes exploratoires afin de guider la
conception. Il est plus adapté aux projets innovants, à risques et dont les
enjeux sont importants. Il est à noter que l'analyse des risques peut également
être introduite dans les modèles classiques, en cascade ou en V.

25
Détermination des buts, Evaluation des alternatives
des alternatives et des conditions Identifier et réduire les risques
du niveau cycle de spirale

Fin de cycle
revues et consensus
de planification

Planification de la continuation du projet par Développement et examen du produit

exemple du prochain cycle de spirale intermédiaire ou actuel

Le modèle en cascade peut être aussi incorporé dans la spirale. L’analyse,

la définition et la conception apparaissent comme des couches propres.
L’implantation et le test sont résumés en un seul cycle.
Modèle en spirale

En résumé, ce modèle reprend l’idée du prototypage et de l’approche

évolutive. Ce modèle reprend d’une manière cyclique les étapes du projet
que sont la planification, l’analyse du risque, la réalisation, l’évaluation.
Ainsi ces étapes ne sont jamais cliniquement séparées mais elles
s’enchevêtrent.

26
3.2.4 Modèles spécifiques
Certains États (gouvernements) imposent pour le développement des
logiciels de qualité des méthodes ou méthodologies spécifiques. En France,
l’on a MERISE, en Allemagne le modèle V, en Angleterre Z, etc.

MERISE : La méthode MERISE (Méthode d’Etudes et de Réalisation des

Systèmes Informatiques par Sous-Ensembles) est française et a plus de 20
ans. Elle est basée sur le modèle entité-association et est un outil simple et
efficace, très répandue chez les développeurs français. La plupart des bases
de données pour PC (dBase, Paradox, Foxpro, Access...) sont imprégnées de
cette technique pour montrer les relations entre les tables au sein d'une base
de données.
MERISE consiste à concevoir un Modèle Conceptuel de Données (MCD), le
transposer en Modèle Logique de Données Relationnelles (MLDR), puis à
générer le Modèle Physique de Données correspondant (MPD). MERISE
permet de générer des dossiers tels le Modèle Conceptuel des Données
(MCD), le Modèle Logique des Données (MLD ), le Modèle conceptuel de
Traitement (MCT), le Modèle Organisationnel de Traitement (MOT), le
Modèle Opérationnel des Traitements (MOPT), le Modèle Physique des
Données (MPD) qui, lui, est une implantation pratique d'un MCD.

Le modèle V :
Il est introduit en 1997. La version actuelle est designée de V-Modell XT
(depuis février 2005). L’administration fédérale de l’Allemagne et les projets
de défense utilisent le Modèle V comme procédure standard de
développement de logiciel. Cette méthode consiste en un modèle pour la
planification et le développement de logiciel. Le modèle V répond à quatre
requêtes importantes de développement : Who? What? When? How?
L’on peut poser la question comme suit: Who has to do what, when, and how
within a project? Qui doit faire quoi, quand et comment dans un projet?
Dans le modèle V, le fond réalise l’implémentation. La branche gauche
définit les différentes spécifications (requirements specification, system
design and software design). La branche droite crée des correlations avec la
partie gauche à savoir la validation du système, la vérification du système et
du logiciel.
L’accent est mis sur la réduction des erreurs. La branche droite permet en
général la détection rapide des erreurs et des anomalies présentes dans la
partie gauche et entreprend des mesures adéquates pour les corriger.

27
 Le modèle V qui est devenu un standard ISO est utilisé aujourd’hui chez
les militaires et dans d’autres grands projets. Il régule toutes les activités et
les projets ainsi que les états du produit et les interactions pendant le
développement et la maintenance. Il se compose de plusieurs sous modèles
qui décrivent le développement du système, l’administration de la
configuration, l’administration du projet (acquisition, planification …).
Au début, le modèle V correspondait à une variante du modèle en cascade.
La branche gauche du V correspond au développement du projet jusqu’à
l’implémentation. La branche droite correspond aux activités d’évaluation et
de test.
Le modèle de la cascade est séduisant de par sa simplicité, mais, souvent, il
lui est préféré celui en V plus récent et plus proche de la réalité de
l'articulation entre les activités de spécification et de conception, avec celles
de validation et vérification. En effet, contrairement au modèle de la cascade,
ce modèle fait apparaître le fait que le début du processus de développement
conditionne ses dernières étapes.

Source: http://www.the-software-experts.de/e_dta-sw-process.htm

La nouvelle version du modèle V supporte l’approche évolutive qui fixe

clairement quelles activités sont à mener dans les phases initiales, qui porte la
responsabilité pour ces tâches et quels sont les outils à utiliser. Les
responsabilités sont définies sous forme de rôle.
Le codage (implémentation) consiste à écrire avec un langage de
programmation chacun des sous-programmes du logiciel. Le développement
peut être confié à une seule personne dans le cas d'une application simple ou
divisé entre plusieurs équipes de développeurs dans le cas de projets

28
importants. Cette phase durant environ 15 pourcents du temps total du cycle
de vie se termine par la production d'un code source.
Les tests unitaires ont pour objectif de vérifier individuellement la
conformité de chaque élément du logiciel (fonctions et variables) par rapport
aux documents de conception détaillée. Toutes les fonctionnalités internes et
externes de chaque sous-programme sont contrôlées méthodiquement. En
outre, un contrôle des performances globales et locales est également
entrepris. Cette phase consomme aux alentours de 5 pourcents du temps total
du cycle de vie et se finalise par la rédaction des résultats des tests.
La phase d'intégration permet de vérifier l'assemblage des différentes
parties du logiciel. Les différents modules du logiciel sont successivement
intégrés jusqu'à aboutir à la construction complète, en respectant
rigoureusement les spécifications des tests d'intégration. Chaque module doit
parfaitement être assimilé sans que le fonctionnement des modules
précédemment intégrés n'en soit affecté. Les résultats de cette phase sont
consignés dans un document des tests d'intégration. Une présentation du
logiciel est également réalisée. Les tests d'intégration représentent en
moyenne 20 pourcents du temps total du cycle de développement.
La dernière phase a pour vocation de valider le logiciel dans son
environnement. Le produit applicatif est mis en situation d'utilisation finale
afin de vérifier s'il répond parfaitement aux besoins énoncés dans les
spécifications textuelles (première phase). Un document appelé résultat de la
recette est produit au terme de la phase de validation qui dure 10 pourcents
du temps total du cycle de vie du développement du logiciel.
La finalité du cycle de vie en V consiste à parvenir sans incident à livrer un
logiciel totalement conforme au cahier des charges. Lors de la phase de
spécification textuelle, une négociation avec le client permet d'affiner ou
d'enrichir les besoins à propos de certains points techniques omis ou obscurs
dans le cahier des charges. Lorsque la spécification est validée, la suite du
processus de développement doit être parfaitement encadré, contrôlé et
approuvé de telle sorte, qu'à aucun moment, il ne soit possible de diverger
des règles énoncées lors de la première phase.

3.3 Evaluation des procédés

Pour évaluer un procédé, les critères suivants s’imposent :
 La compréhensibilité : comment le processus est–il défini exactement ?
Est-il simple à comprendre ?
 La visibilité : les activités livrent-elles des résultats bien définis ?
 Le support : les activités peuvent-elles être soutenues par une machine ?
29
  L’acceptabilité : le processus est-il accepté par les développeurs ?
 La fiabilité : les erreurs sont-elles évitables ou vite découvertes ?
 La robustesse : le processus peut-il être continué malgré les problèmes ?
 La maintenabilité : les changements sont-ils facilement intégrés ?
 Le facteur temps : à quelle vitesse un système peut il être construit ?
Pour avoir une idée de la difficulté de construction d’un logiciel faisons une
comparaison entre la construction de logiciel et une construction navale. Le
logiciel n’est pas palpable alors que le gestionnaire de construction d’un
ouvrage navale peut voir les composantes.
Les méthodes de construction de logiciel ne sont pas standarisées alors que
la construction navale a une longue historique et possède des méthodes de
construction standard. L’on sait comment spécifier un bateau et le tester.
Les produits logiciels ne sont pas standarisés pourtant beaucoup de
bateaux se ressemblent. Un nouveau logiciel est parfois totalement différent
des programmes précédents.
Les erreurs de logiciel sont tolérées alors qu’une société qui fabrique un
bateau qui coule est traîné en justice. Il ne devrait donc point surprendre qu’il
y ait une crise de logiciel surtout quand il s’agit d’un grand projet.

30
Chapitre 4 : Analyse et définition des besoins

En général, dans n’importe quel modèle, l’analyse et la définition des

besoins constituent la première phase. Chaque entité créée par un être
humain est d’abord un concept dans l’esprit. Les systèmes informatiques
comme les autres produits technologiques sont développés en réponse à des
besoins perçus. Les sources des idées pour un produit logiciel incluent les
sources externes telles les besoins gérés par un client, les exigences
organisationnelles internes, les plans de marketing… Le premier pas de
planification d’un projet logiciel est la préparation dans les termes du client
d’un document précis définissant le problème et les contraintes qui existent
pour la solution. Le but de cette phase est de fixer aussi bien et aussi abstrait
que possible les besoins. Cette phase est nécessaire pour comprendre
comment le produit doit être. En effet la programmation absolument inutile
si le problème n’est pas compris. La seule exception est la construction des
prototypes rapides (rapid protoyping) qui servent eux-mêmes à l’analyse du
problème comme contrat avec le client et pour la planification du
développement.
Le résultat de cette phase est désigné de cahier de charges et souligne
aussi les aspects juridiques. La planification est cependant très difficile. Il est
nécessaire de créer des compromis entre les exigences contradictoires des
usagers. Les conséquences à long terme sont généralement inestimables.
Cette phase peut se subdiviser en plusieurs sous-tâches telles que résumées
dans le tableau suivant :

Désignation Pour qui ? (destinataire) De quoi s’agit-il ?

Analyse de besoins -clients (cadres)
-usagers du système
-contractuels et gestionnaires
-architectes du système
Spécification de besoins -clients
-architectes système
-programmeur
Spécification logicielle -architectures de système
-programmeurs
Quel est le problème (grossier) ?
Réponse : ébauche de produit
En langage naturel + figure
Quel est le problème (fin) ?
Réponse : définition du produit (cahier de
charges, document précis et structuré
servant de contrat)
Quelle est la solution (grossière) ?
Réponse : architecture du système

31
 Les différentes parties résultantes d’une analyse de besoins sont donc
l’ébauche du produit, un plan des besoins et la spécification logicielle. La
spécification ou analyse des besoins a pour but de dégager du cahier des
charges toutes les contraintes nécessaires à l'élaboration du logiciel. Trois
sortes de contraintes logicielles sont à prendre en considération :

 Les contraintes externes définissent les caractéristiques d'entrée/sortie

du logiciel attendues par le client (données à utiliser et à afficher, les
exigences ergonomiques, le parc informatique, etc.).

 Les contraintes fonctionnelles caractérisent le fonctionnement interne

du logiciel, c'est-à-dire, les moyens mis en oeuvre pour traiter les
informations d'entrée/sortie du logiciel (méthode de calcul, intervalle
des données, etc.).

 Les contraintes de performances indiquent la vitesse d'exécution du

logiciel ou de ses modules, la résolution d'affichage, la précision des
données.

Les documents produits (plan de développement du logiciel,

spécifications des besoins du logiciel et cahier de recette) au cours de cette
phase permettent de passer à l'étape suivante et également de préparer les
vérifications de conformité du logiciel.

La conception générale (ou analyse organique générale) a pour objectif de

déduire de la spécification, l'architecture du logiciel. Lors de cette phase,
plusieurs solutions peuvent être envisagées afin d'en étudier leur faisabilité.
A l'issue, un document de conception générale du logiciel est réalisé afin de
décrire la structure générale de l'alternative approuvée.

Lors de cette phase, il peut être décidé de découper le logiciel en plusieurs

modules distincts afin de les sous-traiter par plusieurs équipes de
développement. Un module possède une interface permettant son
intégration au logiciel global ou à d'autres modules, et un corps pour son
fonctionnement interne. Ils sont hiérarchisés de telle façon que des modules
de bas niveau s'emboîtent dans des modules intermédiaires, lesquels
s'intègrent à un module de haut niveau (noyau logiciel). Un autre découpage
peut être aussi utilisé pour scinder le logiciel en tâches distinctes.
L'application contient alors plusieurs sous-ensembles ayant en charge des
traitements spécifiques (tâches externes et tâches internes au logiciel),
lesquels s'interconnectent entre eux.

32
 La phase de conception détaillée (ou analyse organique détaillée) en
s'appuyant sur le document de conception générale, énumère l'architecture
approfondie du logiciel jusqu'à parvenir à une description externe de chaque
sous-ensemble et information utilisable dans le futur logiciel. A partir de
cette étape, seront connues toutes les données (variables, constantes,
attributs, champs, etc.) et fonctions (procédures, méthodes, etc.) de
l'application vue de l'extérieur. Le logiciel peut être entièrement écrit en
algorithme. Un langage de programmation est en général validé lors de cette
phase. Un document de conception détaillée ainsi qu'un manuel
d'utilisation sont édités afin respectivement de décrire l'architecture
détaillée et la mise en oeuvre du logiciel. Les phases de conception doivent
prendre environ 25 pourcents du temps total du cycle de développement.

Des spécifications de tests d'intégration et de tests unitaires sont

également produites, à l'issue des deux phases de conception. Elles
permettront de confronter le fonctionnement de l'application à son
architecture générale et détaillée.

4.1 Structuration de l’analyse des besoins

Il n’existe pas de standard de structuration. Chaque firme, chaque
gouvernement fixe spécifiquement ses standards. Cependant, toute
structuration dépend du modèle des processus qui possède des propriétés
générales transcendant les spécificités telles la description des objets, la
fonctionnalité, l’environnement et l’utilisation. Le but primordial est
l’explication abstraite de ce que doit faire le système pour les clients, les
utilisateurs, les managers et les architectes de système. Il existe plusieurs
plans de cahier de charges. Nous présentons ci-dessous quelques exemples :

NASA-STANDARD SMAP-DID-P200-SW
I- Introduction
II- Documentation relative au sujet
III-Ebauche préliminaires et discussion des choix
IV- Exigences aux interfaces externes
V- Spécification des besoins
processus de données
comportement en exécution et qualité requise
sécurité
sécurité et protection des données

33
 limitation d’implémentation
exigences d’installation
buts conceptuels
VI- Répartition pour une liaison étape par étape
VII-Abréviations acronymes et grossière
VIII-Notes
IX-Annexes

STANDARD ANSI-IEEE STD-830-1984 (abrégé)

Chap 1 : Introduction
a. but de la description des besoins
b. grandeur estimée du produit
c. définition acronyque et abréviations
d. références
e. aperçu sur le reste de la description des besoins
Chap 2 : Description Générale
a. perspective du produit
b. fonction du produit
c. carastéristique des utilisateurs
d. limitation et limites générales
e. préréquis et dépendance
Chap 3 : Besoins Spécifiques
Chap 4 : Annexes
Chap 5 : Indexes

STANDARD du modèle V (abrégé)

Chap 1 : Généralités
Chap 2 : Recensement et analyse de la situation actuelle
Chap 3 : Buts relatifs à la sécurité de la technologie
Chap 4 : Analyse des menaces et du risque
Chap 5 : Exigences des besoins techniques
a. description grossière du système
b. intégration organisationnelle
c. utilisation et utilité

34
 d. aspects critiques du système
e. interface externe
f. description de la fonctionnalité
g. exigences de qualité
Chap 6 : Conditions Contextuelles
a. contexte technique
b. contexte organisationnel
c. autres contextes

4.2 Validation des Besoins

Après la définition des besoins, il est nécessaire de les valider. L’on doit
donc examiner l’ébauche des produits selon les concepts suivants :
 Validité : la bonne fonctionnalité est–elle spécifiée ? Et pour qui ?
 Consistance : les besoins ne doivent pas être contradictoires.
 Complétude : toute la fonctionnalité doit être spécifiée.
 Réalisme : Le système doit être implémentable dans les conditions de
temps et de coût données.
Cependant, il est difficile de trouver des mécanismes pour la validation de
ces exigences. Il existe quelques techniques telles les Walkthrough, les
requirement review, la construction des prototypes et les outils logiques.
Malgré les outils, la continuation du projet dépend du modèle des
processus choisi. Le Plan des Besoins contient une ébauche détaillée du
produit qui est une description précise des comportements externes du
système : exigences fonctionnelles et non fonctionnelles. Il combine les
descriptions semi-formelles (notation graphique, langage de description
conceptuelle, …) et non formelles telles les langages naturels. Rarement, une
notation formelle est utilisée (automate, réseau de Petri, …).
Malheureusement, les langages formels sont perçus comme étant non
ergonomiques par les clients.
Le système est modélisé comme transformateur des données. Il décrit les
données et les entrées-sorties des fonctions. Le flux de contrôle n’est pas
déterminé. Les exigences fonctionnelles ne sont modélisées que faiblement.

35
Conception d’un système d’information pour une clinique privée en
utilisant les Data Flow Diagrams (DFD) symptoms

Physical diagnostics
examination

Physician
Légende : prescription

entité

Services performed
Trip to

r
medica
drugstore

List of tests
fonctions
Patient

mémoire
bill

Patient records Medical reference Accounting

books journals system
accounting records

Un autre exemple est la réception de téléphone par modem connecté à un

ordinateur. Il s’agit d’une modélisation évènementielle. Le système est modélisé
comme un modèle réactif constitué d’états réagissant à des événements.
Ici, les modèles sont généralement plus puissants que les automates. Par
exemple, ils peuvent être hiérarchisés ou pourvus le parallélisme. Ils sont
parfois totalement formels et constituent des bases pour les langages de
programmation synchrones ou en temps réels. Les exigences ne sont pas
formalisées. Les formules ne sont pas inclues dans les notations graphiques.

Connect to
Disconnect Detect End of call Hand set

Wait for call Call Acknowledge

connection

Disconnect from Detect End of call Connect to computer

computer

36
4.3 Exemple de cahier de charges
La Firme Teachware organise des séminaires publics et internes avec des formateurs
externes. La firme se compose d’un directeur, qui s’occupe de la planification et de
l’administration des séminaires, une attachée de direction et d’une secrétaire. Depuis peu
l’on a implanté dans la firme le logiciel SEMORG. Le directeur planifie et administre les
séminaires et les formateurs à partir de son PC. L’attaché de direction administre les
clients et les enregistrements à travers un PC. La secrétaire ne travaille pas avec le PC,
mais s’occupe des participants dans les salles du séminaire. Elle s’occupe de surcroît de la
multiplication des documents relatifs au séminaire. A côté de deux PC interconnectés,
l’entreprise possède un téléphone, un appareil de télécopie conventionnelle et une
connexion de fax par PC ainsi qu’une liaison e-mail. L’on veut gérer l’organisation des
séminaires d’une manière efficace.
Donner un cahier de charges pour la gestion de l’organisation des séminaires.

Cahier de charges de l’organisation de séminaires

1. Définition de l’objectif
La firme Teachware doit être renforcée pour pouvoir gérer ses séminaires d’une manière
efficace à travers des ordinateurs.
1.1 Les critères obligatoires
Administrer les séminaires
Administrer les clients (participants/intéressés)
Créer et envoyer des factures
Requêtes : Quand aura lieu le prochain séminaire X ? Quel employé de la firme Y a
participé à quel séminaire Z ?
1.2 Critères souhaités
Des possibilités de requêtes plus avancées
Statistique
Aide pour la sauvegarde des informations
Réutilisation de l’administration des séminaires et des clients
1.3 Critères de délimitation
Pas de gestion financière intégrée (le département de comptabilité reçoit une copie de la
facture et suit les virements)

2. Utilisation du produit
Le produit sert à l’administration des séminaires et des clients dans la firme Teachware.
Aussi plusieurs requêtes doivent être possibles.
2.1 Domaines d’utilisation
Administration des séminaires et des clients. Utilisation commerciale

37
2.2 Groupes cibles
Les collaborateurs de la firme Teachware se subdivisent en deux groupes :
Le traitement des clients et le traitement des séminaires
2.3. Conditions d’exploitation
Environnement de bureau

3 Environnement du produit
Le produit fonctionne sur un poste de travail
3.1 Software
Système d’Exploitation : Windows 95
3.2 Hardware
PC
3.3 Orgware
Liaison de réseau avec l’ordinateur qui gère la comptabilité
3.4 Les interfaces du produit
Une copie des factures établies est enregistrée dans un fichier auquel a accès une fonction
spécifiée dans la comptabilité. Les virements sont enregistrées à travers une fonction
spécifique définie à cette fin.

4. La fonctionnalité du produit
4.1 Administration des clients
/F10/ Première saisie, changement et suppression de clients (participants et intéressés)
/F15/ Première saisie, changement et suppression de firmes, qui envoient leurs employés
au séminaire
/F20/ Enregistrement d’un client avec l’examen
/F30/ - s’il est déjà enregistré
/F40/ - si le séminaire souhaité est possible
/F50/ - si le séminaire est encore libre
/F55/ - quel est la morale de paiement
/F60/ Envoi d’une lettre de confirmation
/F70/ Suppression d’un client avec examen
/F80/ - s’il est même enregistré
/F90/ - si l’enregistrement a été fait 4 semaines avant le séminaire ( 40.000 FCFA de frais
de suppression ou proposition d’un autre candidat)
/F100/ - si l’enregistrement a été fait plus tard que 4 semaines avant le séminaire (100%
de frais ou un remplaçant)

38
/F110/ - si Teachware a annulé le séminaire (pas de facture)
/F115/ Information des candidats, au cas où Teachware annule le séminaire
/F120/ Première saisie, changement et suppression des enregistrements des séminaires
/F125/ Une firme peut commander une formation interne
/F130/ Création des autocollants d’adresse pour la publicité pour tous les clients et les
firmes
/F135/ Envoi d’un courrier en série à tous les clients et les firmes
/F140/ La comptabilité introduit les paiements dans une fonction spécifiée
4.2 Administration des séminaires
/F150/ Première saisie, changement et suppression de séminaires et de types de
séminaires
/F160/ Suppression des calendriers
/F170/ Enregistrement d’un séminaire exécuté
/F180/ Première saisie, changement et suppression des formateurs et leur attribution à
des séminaires et des types de séminaires
/F185/ Tous les formateurs peuvent recevoir une lettre en série pour les informer
/F190/ Etablir une liste de participants à un séminaire X (titre du séminaire, date de ___,
date à ___, Lieu du séminaire, Formateur(s), prénom, Nom, Firme, Lieu)
/F200/ Créer un certificat de participation (Titre, Prénom, Nom, de telle date, à telle date,
Titre du séminaire, Lieu du séminaire, Table de matières, directeur du séminaire).
4.3 Création des factures
/F210/ Dans la règle, une facture est créée et envoyée avec l’enregistrement
/F220/ Les copies des factures sont gardées dans un fichier sur lequel une fonction
spécialisée de la comptabilité a accès.
4.4 Requêtes
/F230/ Quand aura lieu le prochain séminaire X ?
/F240/ Quels collaborateurs de la firme X ont participé au séminaire Y ?
/F250/ D’autres requêtes doivent être possibles : Par exemple : Quelles sont les 10 firmes
avec lesquelles ont a réalisé le plus grand chiffre d’affaires ? Quel est le type de séminaire
qui a eu le plus grand nombre de participants dans l’année écoulée ?

5. Données du produit
5.1 Données des clients
/D10/ Les données suivantes des clients ou des intéressés sont à enregistrer : Numéro de
CNI, Nom (Titre, prénom, nom de famille), Adresse (Lieu, Téléphone), date de naissance,
fonction, chiffre d’affaire, Matériel d’information, client depuis
/D11/ Si le client appartient à une firme, alors les données suivantes sont à enregistrer sur
la firme : L’abréviation de la firme, la désignation de la firme, adresse, téléphone, fax, nom,
39
adresse, département, date de naissance, fonction de la personne de contact, notes, chiffre
d’Affaires, client depuis
/D30/ Un client ou une firme ne peut-il pas payer alors les données suivantes sont à
enregistrer : Date de la facture qui n’est pas encore payée, ainsi que le montant
5.2 Données sur le séminaire
/D40/ Les données suivantes sont à enregistrer sur chaque séminaire : Numéro du
Séminaire, Durée (en jours), De, A, Le début par journée, la fin par journée, début du
premier jour, Fin de la dernière journée, Lieu du séminaire (Hôtel/Firme, Adresse, Salle),
partenaire de coopération, Public(Oui/Non), Prix net, Frais d’annulation, Nombre
minimal de participants, nombre maximum, nombre actuel de participants, Exécuté
(Oui/Non)
/D50/ Les données suivantes sont à enregistrer sur chaque type de séminaire :
Abréviation du séminaire, titre du séminaire, but, méthodologie, table des matières,
présentation de la journée, Durée, Notes, groupe-cibles, pré requis, frais sans TVA,
Nombre minimal de participants, Nombre maximal de participants
/D60/ Les données suivantes sont à enregistrer sur chaque formateur : CNI, nom, adresse,
téléphone, Fax, date de naissance, biographie, honoraire par jour, brève description, notes,
formateur depuis
/D65/ Un séminaire est-il dirigé par un formateur, alors il faut enregistrer ce fait.
5.3 Données de réservation
/D70/ Pour chaque réservation par un client ou une firme, les données suivantes sont à
enregistrer : Enregistré le , Confirmé le , Facture le, supprimé le, Message le

6. Performance du produit
/L10/ Les fonctions /F180/ et /F190/ ne doivent pas durée plus de 15 secondes
d’interaction, toutes les autres doivent être en dessous de 2 secondes
/L20/ Au maximum 50.000 participants/intéressés et au maximum 10.000 séminaires
doivent être gérés
/L30/ 5% de tous les clients sont en difficulté de paiement

7 L’interface d’utilisation
/I10/ Pour un standard, il faut prévoir une interface orientée menu
/I20/ L’interface est à orienter sur l’utilisation de la souris, mais une utilisation sans souris
doit être aussi possible
/I30/ La norme DIN 66324, Partie 8 est à respecter
/I40/ Deux vues sur l’organisation des séminaires sont à distinguer : la vue de celui qui
traite les clients et celle de celui qui traite les séminaires
/I50/ Celui qui traite les clients traite les fonctions /F10/ à /F130/ ainsi que /F230/ à /
F250/. Il ne doit accéder qu’aux données nécessaires à ce traitement. Les droit d’accès
doivent être définis de manière correspondante

40
/I60/Celui qui traite les séminaires traite les fonctions /F150/ à /F200/ ainsi que /F250/
à /F250/. Il ne doit accéder qu’aux données nécessaires à ce traitement. Les droit d’accès
doivent être définis de manière correspondante

8. Définition de la qualité
Qualité du produit Très bien Bien Normal Sans importance
Fonctionnalité
Approprié x
Véracité x
Interopérabilité x
Ordre x
Sécurité x
Fiabilité
Maturité x
Tolérance x
Restaurabilité x
Utilisabilité
Compréhensibilité x
Facilité d’apprendre x
Facilité d’utilisation x
Efficience
Comportement temporel x
Temps de consommation x
Changeabilité
Facilité d’analyse x
Modifiabilité x
Stabilité x
Examinabilité x
Portabilité
Adaptabilité x
Facilité d’installation x
Conformité x
Echangeabilité x

9 Cas de test global

Les séquences de fonctions suivantes sont à tester
/T10/ Enregistrement des participants, première saisie, Suppression, Nouvelle saisie,
Facture, Difficulté de paiement
/T20/ Changement, annulation
/T30/ Annulation, création de facture
/T40/ Enregistrer un séminaire exécuté, création des factures
Les consistances des données suivantes sont à respecter
/T50/ Une réservation ne peut être réalisée que si un client existe ainsi qu’un séminaire
est programmé et que le séminaire n’est pas encore rempli

41
/T60/ Un séminaire ne peut exister que s’il y a un type de séminaire correspondant.

10. Environnement de développement

encore ouvert

42
Chapitre 5 : Gestions des versions et des configurations

En 1975, Brooks mentionne qu’il est quasi impossible d’avoir un produit

dès la première approche. L’on doit donc toujours planifier un throw-one-
away. Le développement d’un produit par la méthode de versions initiales
est raffiné vers des niveaux de capacité plus élevée. Dans cette approche
chaque version successive d’un produit est en soit un système fonctionnel
capable d’exécuter un travail utile.
Le versionnage comme processus itératif se retrouve dans le processus
général de développement de logiciel comme suit :

Analyse des validation

besoins

conception intégration

implantation

La gestion des versions permet de contrôler des versions successives aussi

bien de fichiers que de contenus de dossiers.

Il est à noter que lorsqu'un fichier ou répertoire est sous contrôle de

version, le document original ne peut être modifié que par le biais d'une
version de travail, toute modification en étant interdite. Il en va de même
pour les différentes versions publiées, qui ne peuvent, elles non plus, être
directement modifiées.

5.1. Lois de Lehman

La dynamique d'évolution des programmes est l'étude des modifications
d'un système. La plus grande partie du travail effectué dans ce domaine est
l'oeuvre de Lehman et Belady en 1985. Le résultat de leur étude consiste en
un ensemble de lois (les lois de Lehman) sur les modifications des systèmes.
Ces lois sont invariantes et largement applicables.
43
 Les lois de Lehman constituent l'un des rares exemples en génie logiciel de
théories tirées de l'observation. Les autres sciences se basent essentiellement
sur l'observation, mais en génie logiciel, il est très difficile et coûteux de faire
des observations objectives.

Lehman et Belady ont observé la croissance et l'évolution d'un certain

nombre de grands systèmes logiciels et ont proposé leurs lois sur la base des
mesures qu'ils ont effectuées.

Lois (Hypothèses) de Lehman

1. Loi des modifications perpétuelles
Un logiciel utilisé dans un environnement réel doit nécessairement évoluer sinon il
devient de moins en moins utile dans cet environnement ( maintenance inévitable)
2. Loi de la complexité croissante
Au fur et à mesure qu’un logiciel évolue, sa structure a tendance à se complexifier. Il
sera nécessaire de consacrer des ressources supplémentaires si on veut inverser sa
dégradation.
3. Loi d’évolution de gros logiciels
L’évolution d’un logiciel est un processus auto-regulé. Les attributs du système
comme sa taille, le temps entre 2 versions ou le nombre de bogues signalées ne
varient quasiment pas d’une version à l’autre.
4. Loi de la stabilité organisationnelle
Sur la durée de vie d’un logiciel, le taux de modification est à peu près constant
quelque soit l’effort qu’on lui consacre.
5. Loi de conservation de la familiarité
Sur la durée de vie d’un logiciel, les modifications incrémentales de chaque nouvelle
version sont à peu près constantes.

D'après la cinquième de ces lois, la loi de la conservation de la familiarité, les

modifications incrémentales de chaque évolution sont à peu près constantes
sur la durée de vie du système.

Cette loi est basée sur l'observation de grands systèmes où on a constaté

qu'une évolution contenant un grand nombre de modifications était toujours
suivie de très près par une évolution ne portant presque exclusivement que
sur des corrections. Sur la durée de vie du système, c'est un processus auto-
régulé qui tend vers un nombre constant de modifications par évolution. La
métrique utilisée comptait le nombre de modules modifiés à chaque
évolution.

D'après cette loi, il n'est donc pas conseillé de modifier à outrance les
fonctionnalités du système en une seule fois. En effet, cela risquerait
d'introduire un nombre conséquent de fautes. Une stratégie appropriée

44
consisterait à alterner les évolutions qui corrigent des fautes et celles qui
modifient les fonctionnalités ou le comportement du système.

Si certaines modifications concernent la correction de fautes et d'autres la

modification du comportement du système, on pourrait avoir des problèmes
si on mélangeait ces deux types de modifications. En effet, un rapport de
problème concerne une version donnée. Or, si on modifie cette version, il
faudra vérifier que le rapport de problème est toujours pertinent, ce qui peut
coûter cher. Toutes les fautes sérieuses (celles qui causent des dégâts
systèmes) devront être corrigées avant que l'on applique des modifications
fonctionnelles ou comportementales.

La gestion des évolutions se trouve compliquée par le fait que certains

clients peuvent refuser une nouvelle évolution du système. Un utilisateur du
système peut se trouver entièrement satisfait de la version existante et
considérer que le coût d'un changement n'est pas justifié. Cependant, il se
peut que cet utilisateur se laisse tenter si les fonctionnalités du nouveau
système sont enrichies.

Cela cause néanmoins des problèmes de Gestion de Configurations car les

nouvelles évolutions d'un système ne peuvent pas dépendre des évolutions
précédentes. Supposons que la première évolution d'un système soit
distribuée et mise en service. Arrive une deuxième évolution qui nécessite
que l'on installe de nouveaux fichiers de données, mais certains clients ne
sont pas intéressés par les fonctionnalités et gardent la première évolution. La
troisième évolution ne nécessite pas de nouveaux fichiers en dehors de ceux
de la deuxième version. Cependant, on ne peut pas supposer que ces fichiers
aient déjà été installés partout où l'on doit installer la troisième évolution. Il
faut donc distribuer ces fichiers avec la troisième évolution.
Définition : Le versionnage est l’administration des suites de documents et
leur reconstruction. Les sources primaires sont généralement les sources
codes (*.c ,*.pas., *.java, *.ml,*.tex,…), les sources secondaires sont les fichiers
générés (*.o,*.obj ,*.gz,…). Le versionnage a aussi pour rôle l’optimisation et
la compression du processus de développement. Il gère le développement
partagé et la synchronisation des produits. Enfin, la génération de releases
(publication des logiciels) est aussi un objet de versionnage.

45
5.2 Identification des versions
L'identification des versions d'un système semble immédiate. On appelle
simplement la première version l.0, puis les versions suivantes deviennent
1.1, 1.2, etc... A un moment donné, on décide de passer à 2.0, et on
recommence : 2.1, 2.2, etc... Les versions de base (1.0, 2.0, ...) représentent des
évolutions du système. Cette convention est linéaire, elle est basée sur
l'hypothèse que les versions sont créées en séquence. Les outils de gestion de
version comme RCS (W.F. Tichy, P. Eggert 1985), CVS (D. Grune, B. Berliner
1989) ou SCCS (Rochkind, 1975) supportent cette approche.

En dépit de sa simplicité séduisante, cette convention a quelques

inconvénients:
1. Quand doit-on créer une nouvelle évolution et non une nouvelle version?
2. Si on crée plusieurs versions à partir de la même version-mère, comment
doit-on les numéroter? Doit-on appliquer la numérotation séquentielle et
appeler ces versions 1.1, 1.2, ...?
3. Si on crée et si on distribue plusieurs versions du système à plusieurs
clients différents, le nom de la version doit-il contenir l'identification du
client? Chaque client doit avoir une version unique du système.

On est confronté à des problèmes d'identification parce que la convention de

nommination implique une structure linéaire, alors que la structure
d'évolution des versions est un réseau comme celui de la figure suivante :
Enchaînement des versions

Dans la figure précédente, la version 1.0 est à l'origine de deux versions: 1.1
et 1.1a. La version 1.1 est elle aussi à l'origine de deux versions: 1.2 et 1.1b. La
version 2.0 n'est pas obtenue à partir de 1.2, mais de 1.1a. La version 2.2 n'est
pas issue de 2.0, mais de 1.2. Les nouvelles versions d'un système peuvent
avoir de nouvelles fonctionnalités, ou de meilleures performances, ou elles
peuvent corriger certaines fautes. On peut aussi obtenir une nouvelle version
fonctionnellement équivalente, mais qui est adaptée pour s'exécuter sur
46
différentes configurations matérielles et logicielles. C'est ce qu'on appelle
parfois des variantes du système. Chacune de ces versions peut elle aussi
servir de base à de futurs développements, elle peut donc avoir son propre
ensemble de versions et de variantes.

On peut aussi adopter une convention d’appelation qui ne soit pas

numérique. On choisit alors une convention hiérarchique en utilisant des
noms symboliques. Par exemple, au lieu de s'appeler 1.1.2, l'instance
particulière d'un système s'appelera V1/IBM_WinXP/IBMStation, ce qui
signifie que c'est une version pour ordinateur IBM utilisant le système
d'exploitation Windows XP et configuré pour une VaxStation. Cette
convention a des avantages par rapport à la convention linéaire, mais elle ne
représente pas vraiment la structure de dérivation.

On ne peut pas définir une convention d’appelation universelle qui

convienne à tous les projets. Cependant, il n'est pas rare qu'une équipe de
gestion de configuration doive travailler avec une convention imposée par,
dieu sait, quel outil de gestion de versions. Dans ce cas là, il faut décrire les
caractéristiques et la manière dont on a obtenu chaque version du système.

5.3 Notions de base du versionnage

Le versionnage se rapporte à plusieurs notions couvrant le processus de
développement de logiciel. Dans la gestion des versions, il existe des projets,
des modules, des utilisateurs et les copies de travail. Plusieurs utilisateurs
peuvent accéder concurrentiellement à des données sauvegardées dans une
base de données appelée repository.
Repository
Root

GL adm
teaching

research teaching
com
mit
updat

com
mit
e

update

GL GL

research Index.html Index.html teaching

utilisateur A utilisateur B

47
 À côté de l’interaction entre le repository et l’utilisateur, il existe une
structure interne d’organisation des versions de fichiers appelée branche de
développement .

Un système de gestion du versionnage

Branch 1.2.2.3.1 n’est utile1.2.2.3.1.1
que si les conflits sont
déterminés et des solutions proposées. Ils peuvent être résolus par blocage de
ressources
Branch 1.2.2 (ressource locking) ou par1.2.2.2
1.2.2.1 mélange (merge). 1.2.2.3 1.2.2.4

1.1 1.2 1.3 1.4 Tronc principal.

La solution
V 1.4 V.1.3 1.2.4.1= V 1.4 V.1.3 doit être éditée
Branch 1.2.4 + 1.2.4.2 + 1.2.4.3
= manuellement
V.1.5

Merge sans conflit Merge avec conflit

Plus que la gestion des fichiers isolés, il est nécessaire de constituer des
versions de tous les fichiers constituant un ensemble d’un produit logiciel.
L’on peut aussi avoir un tampon (tag) pour une série de fichiers en
différentes versions.
Un tag (tampon) est un nom symbolique pour un ensemble de révisions.

File 1 file 2 file 3 file 4 file 5

1.1 1.1
1.1 1.2 1.2
Tag 1 1.1 1.2 1.3 1.3 1.1
1.2 1.3
1.3 1.4
1.4. 1.5

Ce principe de tampon est désigné de gestion révision. Il peut aussi se faire

d’une manière partagée entre différents postes d’un réseau ou via Internet.

48
5.4. La gestion de la configuration
Une configuration est un ensemble cohérent de composants permettant, à
un instant donné, d’éditer une version fonctionnelle complète du système. La
gestion de la configuration est une garantie de l'intégrité du système. La
granularité de la configuration est un paramètre économique.
C'est une forme de contrat d'assurance dont le montant est fonction des
risques afférents à un projet bien déterminé.
La gestion de la configuration concerne le suivi et le contrôle des produits
constituant le logiciel pendant le développement du produit, les différentes
revues résultent dans l’acceptance formelle des produits intermédiaires tels le
plan du projet, la spécification des besoins, le plan des tests, le manuel
d’utilisateur, le document de la conception et le code source. Quand un
produit traverse un point crucial de revue, il est placé sous le contrôle de la
gestion de la configuration et chaque changement ne peut se produire
qu’avec l’accord formel du client et du développeur. La gestion de la
configuration administrative et la dépendance des données assurent ainsi la
propagation des changements. Aussi assure t-elle une meilleure construction.
La gestion effective de plusieurs configurations devient aussi possible. La
structure du système de fichiers peut-être aussi soumise à la gestion de la
configuration qui prend en compte la renommination et le déplacement des
dossiers. Puisque la dépendance des données est ainsi versionnée, son
utilisation devient possible.

Les composantes à gérer : Le système est fractionné en constituants

suffisamment petits pour que la réalisation puisse être confiée à un individu.
Chaque système est développé dans un milieu socio-économique avec des
acteurs et des organisations cibles bien précises. Aussi il existe un
environnement technologique avec des plates formes d’exploitation, des
équipements divers, etc. qui influent sur le développement du système. Dans
chaque développement d’un système différents formats d’information
cohabitent : texte libre ou documentation, sources de programmes, binaires
compilés ou exécutables, données structurées/non structurées, messages,
firmware, hardware, etc.
En plus de cet environnement et des outils, plusieurs aspects
complémentaires doivent être pris en compte à savoir l’organisation qui
concerne le regroupement des individus en équipes, les procédés de fabrication
qui traitent des méthodes et des outillages pour le développement et pour
l’intégration et enfin les supports physiques de l'information à savoir stockage
et archivage. Il existe de très fortes interactions entre tous ces éléments et
pièces. Pour tout développement de logiciel, plusieurs constats s’imposent :
49
 Le changement est inévitable. Il est dû à plusieurs raisons internes
générées par le système lui-même, mais aussi des causes externes générées
par l'environnement du système (par exemple les erreurs).
Le changement est déstabilisateur. Cela conduit à des délais de livraison
repoussés, des coûts de la réalisation augmentés qui influent sur la cohérence
et la complétude du système.
La variété de points de vue éventuellement contradictoires. Quand
plusieurs équipes travaillent ensemble, il y a nécessairement des divergences
quant au rôle qu'ils jouent. Aussi les différentes organisations en présence
s’influencent mutuellement dûs surtout aux processus et/ou fonctions de
l’entreprise (développement, intégration, maintenance, assurance qualité,...)
Il se pose alors l’épineux problème à savoir comment gérer au mieux le
changement (Contrat de service, évolution). Ici, il est nécessaire, avant tout,
de mesurer l'impact des changements proposés (Estimation CQFD
Coût/Qualité/Fonctionnalité/Délai). Entre les acteurs, il faut aussi posséder
un équilibre raisonnable entre les communications informelles et les
communications formelles.

5.5 Nature des changements

Pendant le développement d’un logiciel, il existe plusieurs sortes
d’altérations : celles qui sont dépendantes du temps et du lieu.
1. Changements/modifications dans le temps : Ils proviennent généralement
des nouveaux besoins liés à la maintenance et au maintien en condition
opérationnel (MCO). Ceci concerne surtout l’évolution, l’adaptation du
système à son environnement (organisation cible et plates-formes
d’exploitation, nouvelles technologies), des corrections suite à des rapports
d’anomalies signalées par les utilisateurs. Les acteurs concernés sont
essentiellement les équipes de maintenance.
2. Changements/modifications dans l’espace : Ces changements concernent
la distribution de nouvelles versions de logiciel. Ceci est une tâche très
difficile dès que le parc des plates-formes à installer est important.
La cohabitation entre plusieurs versions est généralement inévitable, d’où
le problème très important de compatibilité des versions présentes à l’instant
T. Les acteurs concernés sont essentiellement les équipes de support (hot line)
et d’exploitation et les utilisateurs.

50
5.5.1 Les cas classiques
Les modifications d’un logiciel peut provenir de plusieurs situations parmi
lesquelles les plus fréquentes sont le problème de double maintenance, le
partage des données communes et utilisées dans des développements différents
et enfin les mises à jour simultanées à travers le travail de plusieurs
développeurs.
SYSTÈME A
Modifications
Copie #1 de
1. La double maintenance : Il faut C à T1
de C dans A à
T3
minimiser les duplications car,
inévitablement, les copies multiples C

divergent ; l'augmentation du coût est Copie #2 de

inéluctable. C à T2

SYSTÈME B
2. Le partage des données : Les programmeurs
Programmeur#1 et Programmeur#2 travaillent
tous deux sur le même constituant C. Il existe un Programmeur #1
réel danger : les erreurs de Programmeur#1 Danger

peuvent bloquer Programmeur#2 ; le retard est

inéluctable.
Constituant C
Programmeur #2

3. Les mises à jour simultanées

Programmeur # 1 crée une copie du Programmeur #1
à T4
programme C dans son environnement E1
de travail (E1) à un temps T1. Le
programmeur 2 fait la même chose dans à T1

un environnement E2 à un temps T2.

Ensuite, il réécrit le progamme modifié E2
à T2

dans C à un temps T3. Le programmeur

P1 fait la même chose en un temps T4. à T3
Programmeur #2
Les conflits sont inévitables.

Le "secrétaire" doit garder trace des copies multiples et synchroniser les mises à
jour. Pour cela, il a besoin de discipline et rigueur dans le développement.
Pour donner du confort au Programmeur #1 et au Programmeur #2, et éviter
le problème du partage des données, C a été dupliqué, ce qui nous ramène au
problème de la double maintenance. On est ici en présence d’un dilemme.

51
5.5.2 Cas des progiciels
Les éditeurs cherchent à faire fonctionner le même progiciel (c’est-à-dire le
même code source) sur une variété de plates-formes aussi grande que
possible. Dans ce contexte, il est nécessaire de gérer les dépendances
hardware, celles du système d'exploitation et les évolutions de l’ensemble.
Les difficultés de la gestion de configuration concernent en général le
nombre d'objets à gérer qui dépend quant à lui de la granularité et du type de
nomenclature utilisée dans le développement, la variété des objets (code,
documentation, module, classe, etc), la variété des supports d'archivage et de
stockage (disque durs, CD, disquettes, cassettes, bandes etc.), les
caractéristiques "molles" du logiciel qui résultent en des dépendances
fonctionnelles, canaux cachés, etc., la durée de vie des équipements, des
outils, l’organisation du développement (plus ou moins normalisé) et les
acquisitions en logiciel et matériel. Toutes ces exigences constituent parfois
des boîtes noires dont il est souvent difficile de cerner les contours.
La gestion de configuration est un travail tridimensionnel qui concerne
le processus de gestion. Les trois axes de la gestion de configuration sont
résumés dans le graphe ci-après :
Processus GC
Identification
Contrôle
Administration
Audit
Nature du produit
Hardware
Firmware
Software
Documentation

Processus de développement et MCO

Cycle de vie système et logiciel
Acquisition progressive par paliers
fonctionnels -> N versions successives avec
compatibilité ascendante des versions

Les activités et les tâches du processus de gestion des configurations

concernent un ensemble d’activités manuelles et/ou automatisées permettant
de définir les composants de la configuration et toutes leurs relations, de
suivre les évolutions dans le temps de la configuration, d’archiver les états
livrés successifs, et de s'assurer que chacun des états livrés est cohérent et
complet.

52
Les quatre (4) fonctions principales de la gestion de la configuration sont
l’identification, le contrôle des modifications, l’administration et l’audit.
Le processus gestion de configuration se traduit par un ensemble de
procédures à suivre (workflow de la gestion de configuration). Il existe des
procédures automatiques qui s'appuient sur des outils. Par exemple, au
niveau du système d'exploitation, il existe des systèmes de gestion de fichiers
et un bibliothécaire, des systèmes de gestion des bases de données (SGBD),
les éditeurs de texte, les compilateurs, les traducteurs de langages, les
éditeurs de liens qui tous d’une manière ou d’une autre gèrent des versions.
Sous Unix ou Windows , il existe des logiciels de gestion des versions telles
SCCS, MAKE, RCS. Certains progiciels ont la faculté de gérer des versions
par exemple l’ outil ClearCase de RATIONAL. Cependant des procédures
manuelles de gestion exigent la formation des équipes, la discipline et la
rigueur individuelle où chacun doit nourrir le sens de l'équipe et le sens du
projet.
La bonne mise en oeuvre d'une gestion de configuration nécessite un
bon niveau de maturité de l'organisation de développement. Il s’agit d’un jeu
collectif qui implique la coopération de nombreux acteurs.

53
Chapitre 6 : Modélisation avec les méthodes semi-
formelles

Le but primordial de la modélisation est la définition correcte et abstraite

des besoins. Dans ce chapitre, le contexte est le modèle en cascade qui couvre
une partie de la définition des besoins et toute la phase du system and software
design (conception du système et du logiciel). Les langages et méthodes de
modélisation jouent ici un rôle important.

6.1. Définition
Un modèle est une construction ou un objet mathématique qui décrit un système. Il
peut aussi représenter une théorie. En physique, l’on modélise la distance par
la formule distance = vitesse * temps. En génie civil, un ingénieur modélise
un bâtiment en utilisant le modèle de charge et de poids. En informatique,
nous modélisons les systèmes et leur environnement d’utilisation pour
comprendre leur comportement et analyser leurs propriétés.
La construction de bons modèles est la raison d’être des phases de
planification. Ceci justifie la présence des langages de modélisation et les
méthodes y afférentes. La devise étant : Engineers built models, so should
software engineers. Cependant, il existe une pléthore des langages de
modélisation. Les différences concernent la vue du système qui peut être
statique, dynamique, fonctionnelle ou orientée objet ; le niveau d’abstraction
en ayant par exemple les besoins versus les modules ou structures de classe ;
le degré de formalisme utilisé (informel, semi formel, formel) et enfin la
religion adoptée. Ici, on a l’école orientée objet (OO/OOD, OMT, UML), les
algébristes (ADT : signature, fonction), les sectes de Oxford avec Z et CSP
(Communicating Sequential Processes), le groupe de ASM (Abstract State
Machine), l’église de logique d’ordre élevé HOL (Higher Order Logic), la
congrégation de MERISE, etc…
Il existe plusieurs concepts dans la modélisation. Entre autres, l’on a les
arbres de fonction, les diagrammes de flux des données, les diagrammes E/R,
les diagrammes de syntaxe, le dictionnaire des données, le pseudo code, le
structogramme, les règles et les tables de décision, les variantes d’automates,
les réseaux de Petri, les diagrammes de classe, les cartes CRC (Class –
Responsability - Collaboration), les message-sequent-charts, …

54
 Dans les méthodologies, les langages sont souvent intermixés. Dans
Z/CSP, l’on retrouve deux modèles et deux langages basés sur le fonctionnel
et le modèle dynamique événementiel. Dans la technique Object Modelling
Technique (OMT), l’on retrouve trois modèles, et trois langages (objet,
dynamique et fonctionnel). L’on peut modéliser les diagrammes de classe, les
diagrammes d’état et le flux de données. Dans UML, l’on retrouve neuf
langages (class, objet, uses cases, séquences, collaboration, statecharts,
activités, composant, déploiement). Nous étudierons quelques modèles
simples : le diagramme E/R, le diagramme de flux de données, le modèle de
classes, l’orientation objet, UML, etc.

6.2 Modélisation Entity/Relationship (ER)

Le modèle E/R spécifie les données semblables et leurs relations. Ces
données sont généralement enregistrées d’une manière persistante. E/R a été
développé en 1976 par Peter CHEN pour la modélisation des données. Le
résultat est un modèle conceptuel assez stable contre les changements de
fonctionnalité. Les entités sont des ensembles d’objets individuels qui se
distinguent les uns des autres par leurs propriétés. Les attributs constituent la
propriété commune à un ensemble d’entités. Les relations sont des rapports
(sémantiques) entre les entités. D’une manière visuelle, l’on distingue les
graphismes suivants :
: entité, : attribut, : relation

Exemple : L’on veut modéliser le fait qu’un étudiant est inscrit dans une
unité de valeur(UV). L’on a deux entités : Etudiant et UV. Un étudiant a un
nom, un âge et un numéro matricule. Une UV a un titre et un code.
Dans les langages de programmation, les attributs matricu âg no
correspondent aux types de base alors que les le

entités elles correspondent aux champs ou record. Etudiant

Type Etudiant = Etudiant (nom : string, âge :

sui
cardinal, matricule : string) ;
Type UV=UV (désignation : string, code : UV
string) ;

désignatio Code
n
Les relations sont représentées d’une manière graphique
dans le modèle ER par un losange. Etudiant suit UV sera
représenté par le graphique ci-dessus.

55
 La méthode E/R présente des avantages et des inconvénients. Ces
avantages proviennent de sa simplicité. Les images et les trois concepts sont
faciles à comprendre. Plusieurs outils ont été développés pour supporter la
philosophie E/R et elle a beaucoup de succès dans la pratique. Les
inconvénients proviennent de son caractère non standarisé. En effet, les
relations sont elles binaires ou n-aire, les extensions orientées d’objets ont-
elles un fondement, par exemple la relation is-a ? Ensuite, il existe des
propriétés impossibles à spécifier d’une manière visuelle. Enfin chaque
fonction avec un argument correspond à une relation n+1 arguments.

6.3 Diagramme de flux de données

Un diagramme de flux de données (DFD : Data Flow Diagram) décrit le
chemin des données ou des informations entre les fonctions, les mémoires et
les interfaces et la transformation des données par les fonctions. Il a été
inventé en 1979 par Tom de Marco dans le cadre de sa méthode Structured
Analysis (SA). Un flux de données est comparable à un pipeline dans lequel
coulent les informations. Le DFD se base sur les symboles suivants :

Data Flow Data Store output Fonction interface

L’idée fondamentale du DFD est de se représenter mentalement comme si le

système fonctionnait déjà. L’on ne se soucie pas de savoir comment il est
initialisé et comment il termine. Book request by user

Exemple : Gestion d’une petite bibliothèque

Book title/author
and user name
shelves book

Get a
book
book reception Book reception
List of authors
anthor
title
List of titles book title, user name

title
List of borrowed books
List of topic Search
by
topi
list of titles
Display of titles
topi
Source : Ian Sommerville, Software
Engineering. Topic request by user

56
Ceci constitue une première approche. Il n’existe encore aucune information
sur la manière de trouver un livre. Un raffinement s’impose et est présenté
partiellement comme suit

shelves book

Get a
book
book reception Book reception
List of authors

anthor <shelf#, Book#>

List of titles
Ce raffinement décrit comment un livre est sélectionné mais il n’est pas
encore précis. Le title
titre et le nom de l’utilisateur sont–ils List véritablement
of borrowed books
nécessaires ? De surcroît, la sémantique
Find a n’est mentionnée qu’à travers les
book title, user name
noms des fonctions. Les aspectsbook
de contrôle ne sont pas cités, l’exécution n’est
pas synchronisée. Les DFD sont aussi utilisés dans les méthodes de
développement. On les désigne de BookDFD hiérarchiques et ils livrent une
title/author
structure de modules. La procédure M appelle soit M1 une fois soit M2
and user name

plusieurs fois. M2 transmet B à M1 et en reçoit A et M reçoit C de M2.

Book request
L’architecture résultante du module by user
commande de livre est la suivante :
M
Delivrer a
book

Author title
Book
B
<shelf # , book # >

A <shelf # , book # >

C
Find a Get a
M1 M2 book book

Certains ateliers du génie logiciel (CASE-TOOLS) supportent les DFD. Par

exemple les classes et les signatures peuvent être générées automatiquement
dans les langages de programmation comme entêtes et signatures.

57
6.4 Les modèles de classe
Les modèles de classe soulignent les objets et leurs relations. Le but palpable
étant la compréhensibilité et la réutilisation. Le système est décrit à l’aide des
objets qui par leurs attributs et leurs fonctions soit collectés dans des classes.
Maison familiale Maison familiale Maison familiale
Type: maison de campagne Type : Bungalow Type : maison de ville
Propriètaire : Dr Fam Propriétaire : Kengso Propriétaire : yamlague
Adrees : Idole Adresse : Bamyanga Adresse :calmette
Surface : 400m2 Surface : 250m2 Surface : 200m2
Nbre douches : 3 Douche :2 Douche :2
Piscine : oui Piscine :non Piscine :non
Jardin : 2000m2 Jardin :1500m2 Jardin :400m2
Année : 1970 Année :1986 Année :1990
Prix : 60m Prix :40 Prix 30m
Demander prix Demander prix Demander prix

Maison familiale Maison familiale Maison familiale

Type: maison de campagne Type : Bungalow Type : maison de ville

Propriètaire : Dr Fdam Propriétaire : Kengso Propriétaire : yamlague
Adresse : Idole Adresse : Bamyanga Adresse :calmette
Surface : 400m2 Surface : 250m2 Surface : 200m2
Nbre douches : 3 Douche :2 Douche :2
Piscine : oui Piscine :non Piscine :non
Jardin : 2000m2 Jardin :1500m2 Jardin :400m2
Année : 1970 Année :1986 Année :1990
Prix : 60m Prix :40 Prix 30m
Demander prix Demander prix Demander prix

Immobilier
Propriétaire
Adresse
Année :
Prix

Demander prix

Maison familiale Bâtiment de Bureau

Type de maison
Surface Nombre de bureaux
Douche Nombre d’étages
Piscine garage
Jardin
Demander nombre de
pièces

La hiérarchie de classes exprime à travers l’héritage les propriétés

communes et les méthodes.

58
6.5 Modélisation Orientée Objet
Il existe pour l’orientation objet plusieurs méthodologies : Object
Modelling Technique (OMT), Object Oriented Analysis Technique/Object
Oriented Design (OOAT/OOD), Unified Modelling Language (UML), …
L’OMT couvre par exemple un modèle objet avec la hiérarchie de classes et
les associations entre les classes (par exemple le modèle ER), un modèle
fonctionnel : la description comment les objets agissent globalement ensemble
(par exemple le flux de données) et un modèle dynamique, avec le modèle
orienté événement (par exemple les automates ou les statecharts). Les
avantages sont la bonne modularité et la réutilisation. Cette technique se
rapproche aussi des objets réels. Ses inconvénients proviennent de son
opacité sémantique.
Les langages de modélisation comportent une longue histoire avec deux
branches essentielles : les méthodes formelles et celles semi-formelles.
Les méthodes formelles sont étudiées dans la recherche depuis les années
1960. L’on a les méthodes et langages telles VDM (Vienna Development
Method), Z, la spécification algébrique, les algèbres de processus, … Les
méthodes semi-formelles quant à elles sont issues des années 1970 et
couvrent les diagrammes ER, les flux de données, etc…
Entre les années 1970 et 1990, il y a eu une grande prolifération de
modélisation orientée objet (OOA/OOD, OMT, OOSE…). Il existe une guerre
ouverte entre les langages proposés et leur méthode. L’UML résulte en une
standardisation depuis 1995.

6.6 Une introduction à UML

UML (Unified Modelling Language) est selon ses développeurs un langage
pour la spécification, la visualisation, la construction et la documentation du
logiciel. Il est né des idées des trois gourous Booch, Jacobson et Rumbaugh,
mais s’est enrichi au fils des ans par des idées des partenaires industriels
pour devenir un vrai standard pour la modélisation des spécifications
orientées objet.
Le développement de UML est issu des années 1994 quand Rumbaugh et
Booch ont unifié leurs méthodes. Les deux méthodes étaient déjà très
répandues à l’époque. La force des méthodes de Rumbaugh se trouvait dans
la modélisation orientée objet, alors que celles de Booch étaient dans la
modularisation et la conception. En octobre 1995, s’ajoutait à ce groupe Ivar
Jacobson avec OOSE (Object Orientied Software Engineering) qui introduisit
les cas d’utilisation dans cette discussion des méthodes. Ils publient en 1996
la version UML 0.9 qui leur value la dénomination « les trois amigos ». En
59
1997, OMG a standardisé UML. UML est un conglomérat de plusieurs
notations pouvant modéliser plusieurs aspects dans le système avec
différents niveaux d’abstraction.

UML 1.3
2000

...

UML 1.0

année UML 0.9

Unified Method 0.8

1995

Booch Methods OMT (Rumbaugh) OOSE (Jacobson) Autres concepts et

(Booch) Méthodes

Un Use Case Model décrit le système du point de vue de l’utilisateur. Un

static model décrit les éléments du système et leurs rapports et un dynamic
model décrit le comportement temporel du système.
L’on a au moins 9 diagrammes qui modélisent le processus de
développement du logiciel avec les diagrammes des cas d’utilisation, les
diagrammes de classes, les diagrammes d'objets, les diagrammes de
séquences, les diagrammes de collaboration, les diagrammes d’états, les
diagrammes d’activités, les diagrammes de composants et les diagrammes de
déploiement.

6.7 Cas d’utilisation

Les cas d’utilisation ou use cases constituent une des notations d’UML ayant
pour but essentiel de définir le système du point de vue des utilisateurs et de
fixer les limites précises du système.
Le diagramme des cas d’utilisation est une notation très simple et
compréhensible par tous et qui permet de structurer les besoins (cahier des
charges) et le reste du développement. Un diagramme de cas d’utilisation
décrit les acteurs, les cas d’utilisation et le système. Un modèle de cas
d’utilisation peut être formé de plusieurs diagrammes de cas d'utilisation, de
descriptions textuelles, de diagrammes de séquences. Un cas d’utilisation
(CU) décrit une manière d’utiliser le système en une suite d’interactions entre
60
un acteur et le système. Par exemple, le guichetier peut créer un nouveau
compte. Cette description en diagramme correspond à une fonction visible
par l’utilisateur et lui permet d’atteindre un but.

CreerUnCompte

Client

ConsulterUnCompte

Guichetier
RetirerDeLArgentD
uDistributeur
DeposerDeLArgentSurUn
Compte

RetirerDeLArgentD
UnCompte GererLesCredits Directeur

Le système est un ensemble de cas d’utilisation. Il contient les cas

d’utilisation mais pas les acteurs. Un modèle de cas d’utilisation permet de
définir les fonctions essentielles du système, ses limites, et son rapport avec
l’environnement.
Un Acteur est un élément externe qui interagit avec le système. Un
acteur prend des décisions, des initiatives, il est "actif" (un élément logiciel ne
prend pas de décision). Un acteur est aussi un rôle qu’un utilisateur joue par
rapport au système, par exemple le rôle de client ou de guichetier.
Il ne faut cependant pas confondre la notion d'acteur et de personne
utilisant le système. Une même personne peut jouer plusieurs rôles. Par
exemple, dans une banque le directeur peut jouer le rôle de guichetier.
Plusieurs personnes peuvent jouer un même role. Par exemple, Nawal et
Aoudou sont deux clients. Un acteur n’est pas forcément un être humain, par
exemple un distributeur de billet peut être vu comme un acteur.
Dans les cas d’utilisation, on retrouve les utilisateurs principaux (client,
guichetier) et les utilisateurs secondaires (contrôleur, directeur, ingénieur
système, ...). Aussi distingue-t-on entre périphériques externes (un capteur,
une horloge externe, ...) et systèmes externes (systèmes interbancaires). Pour
chaque acteur, le développeur doit choisir un identificateur représentatif de
son rôle et en donner une brève description textuelle.

61
 Guichetier : Un guichetier est un employé de la banque chargé de faire l’interface entre
le système informatique et les clients qu’il reçoit au comptoir. Le guichetier peut
réaliser les opérations courantes : création d’un compte, dépôt et retrait d’argent, etc.
La définition d’acteurs permet surtout de trouver les cas d’utilisation par
exemple en posant des questions du genre : que peut faire un guichetier ? un
client ? le directeur ? Cependant cette définition des acteurs peut aussi être
utilisée pour définir différents points de vues sur le système, déterminer des
droits d’accès par type d’acteurs, fixer des ordres de priorités entre acteurs, ...
Pour chaque cas d’utilisation, le développeur doit choisir un
identificateur représentatif, donner une description textuelle simple de
manière que la fonction réalisée doit être comprise de tous. Il est absolument
nécessaire d’abstraire des détails encombrants. De ce fait, il est indispensable
de préciser ce que fait le système et ce que fait l’acteur. Pour assurer la
consistance, le dévéloppeur doit éviter que les cas d’utilisation se
chevauchent.

Exemple : RetirerDeLArgentAuDistributeur
Lorsqu’un client a besoin de retirer du liquide il peut en utilisant un distributeur retirer
de l’argent de son compte. Pour cela
- le client insère sa carte bancaire dans le distributeur
- le système demande le code pour l’identifier
- le client choisit le montant du retrait
- le système vérifie qu’il y a suffisamment d ’argent
- si c’est le cas, le système distribue les billets et retire l’argent du compte du client
- le client prend les billets et retire sa carte

Pour la description du cas d’utilisation, certaines informations doivent être

prises en compte. Les plus importantes doivent ressortir dans la description
et couvrent les faits suivants : le début du cas d’utilisation (CU) avec les pré-
conditions, la fin du CU avec ses post-conditions, le chemin correspondant
au déroulement normal, les variantes possibles et les cas d’erreurs, Les
interactions entre le système et les acteurs, les informations échangées et les
éventuels besoins non fonctionnels.

62
 RetirerDeLArgentAuDistributeur
Précondition : Le distributeur contient des billets, il est en attente d’une opération, il
n’est ni en panne, ni en maintenance
Début : lorsqu’un client introduit sa carte bancaire dans le distributeur.
Fin : lorsque la carte bancaire et les billets sont sortis.
Postcondition : Si de l’argent a pu être retire, la somme d’argent sur le compte est égale
à la somme d’argent qu’il y avait avant moins le montant du retrait. Sinon la somme
d’argent sur le compte est la même qu’avant.

RetirerDeLArgentAuDistributeur
Déroulement normal :
(1) le client introduit sa carte bancaire
(2) le système lit la carte et vérifie si la carte est valide
(3) le système demande au client de taper son code
(4) le client tape son code confidentiel
(5) le système vérifie que le code correspond à la carte
(6) le client choisit une opération de retrait
(7) le système demande le montant à retirer
…
Variantes :
(A) Carte invalide : au cours de l ’étape (2) si la carte est jugée invalide, le système
affiche un message d ’erreur, rejette la carte et le cas d ’utilisation se termine.
(B) Code erroné: au cours de l ’étape (5) ...

Contraintes non fonctionnelles : (A) Performance: le système doit réagir dans

un délai inférieur à 4 secondes, quelque soit l’action de l ’utilisateur. (B)
Résistance aux pannes : si une coupure de courant ou une autre défaillance
survient au cours du cas d ’utilisation, la transaction sera annulée, l ’argent
ne sera pas distribué. Le système doit pouvoir redémarrer automatiquement
dans un état cohérent et sans intervention humaine. (C) Résistance à la charge :
le système doit pouvoir gérer plus de 1000 retraits d’argent simultanément ...
Scénario : Pour décrire ou valider un CU, UML prévoit les scénarii. Un
scénario est un exemple, une manière particulière d’utiliser le système par
une personne particulière, dans un contexte particulier. Un cas d’utilisation
est en quelque sorte un ensemble de scénarii.

Exemple de scénario : RetirerDeLArgentAuDistributeur

• Nawal insère sa carte dans le distributeur d2103
• Le système accepte la carte et lit le numéro de compte
• Le système demande le code
• Nawal tape ‘1234 ’
• Le système indique que ce n ’est pas le bon code

63
 • Le système affiche un message et propose de recommencer
• Nawal tape ‘6622’
• Le système affiche que le code est correct
• Le système demande le montant du retrait
• Nawal tape 50000 frs CFA
• Le système vérifie s’il y a assez d ’argent sur le compte
•...

Diagrammes de séquences : Pour décrire un scenario, UML propose un

diagramme de séquences qui permet de décrire une séquence des messages
échangés entre différents objets.
Exemple de scénario Nawal : Client Le système

UML est de facto standard

Insérer carte
dans plusieurs entreprises. Il est
supporté par les outils tels Vérifier
Demander code
Rational. Il est aussi plus ou carte

moins intuitif. Utilisé moins

pour la conception des modèles, Entrer code ‚1234’

UML l’est plus pour l’analyse Vérifier

des besoins. Message d’erreur code

Demander code

Appeler
Dadda Entrer code 6622

L’ensemble de USE CASE décrit la fonctionnalité du système (scenarii).

64
Chapitre 7 : La modélisation des classes

Dans la modélisation orientée objet, les objets constituent l’abstraction

principale. Ces concepts sont aussi bien appropriés pour l’implémentation
que pour la modélisation. Dans un modèle orienté objet d’un système ; les
activités sont des objets et l’interface est orientée événement. Dans la
décomposition fonctionnelle ; les activités sont les fonctions et l’interface est
orientée donnée . On peut interagir avec un objet. Il comporte premièrement
un état et des données qui se compose des attributs et des variables
d’instance. Une partie de l’état peut être changeable. Deuxièment, un objet a
un comportement par le fait qu’il réagit au message par le changement d’état
et d’autre message. Enfin, une identité est associée à l’objet puisqu’un objet
est plus qu’un ensemble de valeurs et de méthodes. Il a une existence et un
nom. Une interface définit quel message un objet peut recevoir. Elle décrit le
comportement sans implémentation d’état. On distingue entre le public
interface et le private interface. Une classe décrit tous les objets ayant une
structure semblable et un comportement dans le domaine de modélisation.
Une classe fixe une interface et définit les attributs, les variables et les
méthodes. Les avantages des classes sont de plusieurs ordres : d’abord sur le
plan conceptuel, plusieurs objets ont les mêmes propriétés, par exemple des
clients ont souvent les mêmes propriétés, par exemple les clients d’une
banque qui gagnent plus de 300 000 francs CFA. Pour l’implémentation, les
classes sont directement codifiables. Il existe plusieurs autres avantages tels
l’héritage et la liaison dynamique.

7.1 Les diagrammes des classes

Les diagrammes de classe modélisent principalement la vue statique d’un
système. Un diagramme décrit les sortes d’objets dans un système et leurs
relations statiques. Les rapports les plus importants sont : les associations
(un client peut emprunter une cassette vidéo) ou des sous-types (une
infirmière est une personne). Les diagrammes de classes constituent un
modèle central pour l’analyse orientée objet. Aussi généralisent-t-ils les
autres formes de modélisation statiques telles le diagramme E/R.

65
Order Multplicity Costumer
Date received is prepaid Name
Number : string Address
Price : money
* 1
Dispatch ( ) class CreditRating ( )
Closed ( ) association
1 { if order. Costumer. generalization
creditrating is « poor »
then order is prepaid
must be true }
*
Order line Constraints Cooperate costumer Personal castumer
quantity : integer ContactName
price : money CreditRating
isStatisfied : attributes CreditLimit CreditCard#
boolean Remind ( )
operations BillForMonth (integer)
* * {creditRating( ) = = « poor »}
sales rep 0..9
employee

product

Les diagrammes de classes sont utilisés dans leur fondement conceptuel sans
rapport direct avec l’implantation. Dans la spécification, ils désignent les
interfaces et les parties de la sémantique. Dans l’implémentation, ils
décrivent ce qui doit être programmé.
En général, UML ne fait pas de distinction formelle. Dans la pratique, il
mélange la notion de spécification et d’implémentation. Les seules
différences se trouvent dans le degré d’abstraction. Dans la phase des
besoins, plusieurs détails sont omis. Les décisions concernant par exemple la
localisation des états, la navigation entre les objets et la division
comportement / implémentation ne sont prises en compte que plus tard.

66
7.2 Les classes
Une classe décrit un ensemble d’objets avec des rôles équivalents dans un
système. Les classes peuvent décrire les choses palpables du monde réel (avion,
tableau, bœufs, …), des rôles (abonnés d’une bibliothèque, étudiants,
enseignants, etc…), des transactions (commandes, compte bancaire, etc.), des
choses d’un ordinateur (des listes, des tableaux de hashing, etc.), des
comportements, des applications , etc.
Dans sa forme visuelle, une classe est représentée par un carré avec ou
sans attributs et des opérations.
Book
Title : String
Book
Copy on self ( ) : integer
BorrowCC : copy

Les attributs définissent les données (états des objets). Les opérations
(méthodes) définissent comment les objets interagissent. L’on peut aussi
nommer les responsabilités.
Model View Control

Responsabilities
--Manages the state of the model
Responsabilities
--renders the model on the screen
--manages movement and resizing Responsabilities
of the view --synchronize changes in
--intercepts user events the models and views

7.2.1 L’identification des classes

Un modèle de classes est bon quand les objets remplissent les exigences
requises. Pour augmenter la maintenabilité et la réutilisation, les classes
doivent présenter les objets persistants du domaine. Comment peut-on
construire une classe ?
Une première possibilité est une inspiration divine. La deuxième est basée
sur une conception orientée donnée (data driven design). Ici, il faut identifier
toutes les données du système et les diviser en classe et ensuite réfléchir aux
opérations. La troisième méthode concerne une conception orientée
responsabilités avant de retrouver les données.

Méthode 1 : Classes comme substantifs : Cette méthode comporte deux

étapes pour l’identification des classes.

67
  identifier : choisir tous les substantifs et les phrases principales ; il faut
utiliser le singulier pour la désignation de ces entités identifiées comme
des noms possibles de classe.
 consolider : éliminer les candidats non appropriés, c’est-à-dire là où le
nom est redondant (plusieurs noms équivalents), non clair (préciser ou
éliminer), un évènement ou une opération (sans états, comportement ou
identité), un attribut simple ou en dehors du système.
L’expérience, la fantaisie créative et la patience sont des atouts.
Méthode 2 : Les cartes CRC : L’idée des CRC a été inventée par
Beck/Cunningham en 1989. Pour chaque classe, l’on note sur une carte le
nom de la classe (Class), ses responsabilités (Responsabilities) et la liste des
classes en collaboration (Collaboration).
Quand il existe plusieurs responsabilités ou collaborations, l’on crée une
nouvelle classe. L’on distribue ensuite les cartes à l’équipe de développement
et l’on choisit un scénario use case. L’on joue alors le scénario et remplace si
possible les collaborateurs. Ainsi on peut découvrir d’autres responsabilités
et des collaborations. Ensuite, l’on y ajoute les attributs et les méthodes. C’est
le brainstorming .
Library member Copy Book
Responsabilities Collaboration Responsabilities Collaboration Responsabilities Collaboration
- Maintain data about -Maintain data about a - Maintain data about
copies currently particular book book
borrowed ; -Inform corresponding - Know wheither
- Meet request to COPY book when borrowed BOOK there are borrowable
borrow and return copy and return copies

UML soutient la modélisation de différents rapports entre les classes et les

objets. En général, l’on a les représentations graphiques suivantes :
Relationship Fonction Notation
Association  Décrit la connexion entre les instances des
Généralisation classes
 Une relation entre une description plus générale
Dépendance et une variété plus spécifique
Réalisation  Relation entre deux éléments d’un modèle
 Relation entre une spécification et son
Utilisation implémentation
 Situation où un élément requiert un autre pour
bien fonctionner

68
7.2.2 Les associations
Les associations décrivent des liens sémantiques entre les objets dans une
classe. Elles illustrent les rapports entre les objets ou les autres instances dans
un système. La sémantique des associations est celle des relations dans le
modèle E/R.
is_copy_of
COPY BOOK

Exemple : Paul emprunte copy 17 du livre XYZ. Un objet de la classe H

envoie un message à n objets de la classe B. Un objet de la classe H crée un objet
de la classe B.
Les associations peuvent aussi être annotées. L’annotation a un nom, une
multiplicité (cardinalité), une navigabilité, un rôle et une direction
nomminelle.
 Nom : is_copy_of est le nom de la relation entre les classes Copy et Book
 Multiplicité : il s’agit d’un nombre n , d’un intervalle n..m ou d’un
nombre quelconque *

STUDENT is_taking MODUL

1..* 6

Ce schéma modélise le fait que chaque étudiant participe exactement à 6

modules et que chaque module a au moins un étudiant (ou participant). En
sémantique, le schéma modélise les contraintes ou les restrictions sur la
relation.
 Navigabilité (direction): une flèche montre la direction de la relation

STUDENT is_taking MODUL

1..* 6

Les objets de la classe MODUL peuvent envoyer des messages aux

étudiants mais pas l’inverse.
 Rôle : il décrit le rôle que les objets ont dans une association.

PERSON COMPANY
Employee Employer

Le rôle rend la relation facile à comprendre et à lire.

69
  Direction nomminelle : elle décrit dans quelle direction quel nom doit être
lu.

works_for
PERSON COMPANY

Dans l’association, l’on retrouve aussi l’agrégation et la composition qui

sont des formes d’associations particulières apparaissant fréquemment.
 Agrégation : rapport d’un tout à une partie.
1 *
COMPANY DEPARTMENT

Le losange décrit le tout implicitement, la relation signifie is a part of.

 Composition : elle est une agrégation ou la partie n’a pas d’existence
indépendante .
1 *
Board Square

Quand le tout est supprimé, la partie disparaît aussi.

chairperson
0..1
School has Department
member

1..* 1..*
assigne

1
dTo

1
Student attends 1..* Course teaches Instructor
1..*

Un exemple de modélisation d’une faculté.

70
Chapitre 8 : Modélisation formelle avec Z

Il existe plusieurs langages de modélisation et des méthodes qui en

résultent. Les différences essentielles sont la vue du système, le niveau
d’abstraction et le degré de formalisme.
Les langages semi-formels incorporent quelques inconvénients. Même si la
modélisation est détaillée et intuitive donc compréhensible aussi par des
profanes ou des gestionnaires, la sémantique des modèles et des diagrammes
reste cependant non précise. Parfois, elle ne se rapporte qu’à la syntaxe. Pour
juguler ces difficultés, l’on utilise les langages formels.
Un langage est dit formel s’il a une syntaxe fixée et une sémantique décrite
d’une manière mathématique. Les langages formels supportent la
conception, le développement, la vérification, le test et la maintenance du
système. Ils éliminent la multiplicité de sens en ajoutant la précision, aident à
la preuve des propriétés de conception et offrent un support technique à
l’aide des outils. Certes, l’utilisation de la mathématique semble lourde mais
elle paye à la longue.

8.1. Z
Le langage Z proposé par Jean Raymond Abrial dans les années 50 possède
une grande force d’expression. Elle est basée sur la logique prédicative de
premier ordre avec égalité (PL1=, first order logic with equality), et la théorie
des ensembles typés. Il possède un outillage de mathématique appelé
mathematical toolkit qui est une bibliothèque de définitions standard de
types abstraits (sets, lists, bags). Ce langage permet la modélisation d’un
système aussi bien statique que dynamique par la modélisation/spécification
des données du système et leur description fonctionnelle (transition d’états).
Z est supporté par différents outils et systèmes et entretient de bons rapports
avec d’autres méthodes formelles basées sur PL1= et la théorie des ensembles
entre autres VDM (Vienna Development Method), B aussi développé par
Jean Raymond Abrial et très utilisé en France.
Il existe d’autres méthodes formelles basées sur d’autres fondements.
D’abord la logique d’égalité (Horn logic) utilisée dans les spécifications

71
algébriques, la logique des prédicats avec égalité (PL1=), la logique de
premier ordre (FOL) et la logique d’ordre élevé (HOL).
Z est utilisé d’une manière très efficace depuis les années 1989 au Oxford
University Computing Laboratory où il est né. Une exigence du
gouvernement britannique impose que tous les systèmes à sécurité critique
doivent se faire avec Z.
Un modèle mathématique qui représente le comportement d’un
programme peut être utilisé comme une spécification formelle. Mais à quoi
sert une spécification si on peut écrire facilement un programme pour ne pas
l’implémenter directement ? La réponse est qu’un programme peut être
crypté. Aussi l’on a besoin d’une spécification qui représente le niveau
d’abstraction appropriée. Par exemple, que fait le programme suivant ?
fun int_root a= (* integer square root*)
let val i =ref(0) ;
val k=ref(1) ;
val sum = ref(1) ;
in while ( ! sum <= a) do
(k : = ! k+2 ;
sum : = !sum+ ! k ;
i : = !i+1) ;

Ce programme est efficace, court et bien structuré. Le nom du programme est

le commentaire suggère que int_root calcule simplement l’« integer root »
de son entrée a, mais, est ce vrai ? Que se passe t-il dans le cas où a=0 ou a=-
3?
Des réponses peuvent se trouver par les code review ou reverse
engineering, mais cela requiert du temps et est problématique par des longs
programmes. La clef est l’abstraction c’est-à-dire que la compréhension d’un
code (programme) est à séparer de sa fonctionnalité. La solution consiste
donc dans une spécification. Spécifier signifie formaliser ce que doit faire le
système sans fixer comment. Nous allons spécifier int-root à l’aide d’une
définition aussi désignée de description axiomatique.

in_root : ∠ déclaration

a : ∠. let y=int_root(a) prédicat

y * y  a < (y+1)*(y+1) prédicat
a : ∠/0 int_root (-a)=0

72
Le dernier prédicat couvre les cas des nombres négatifs en fixant le résultat à
0.
8.2 Un exemple introductif : The Birthday Book
Le birthday book est une petite base de données dans laquelle des noms des
personnes et leurs dates de naissance sont mémorisés. Un modèle essentiel
mais simple est présenté comme suit :
Addbirthday

Remind
Init Birhdaybook

Findbirthday

Les spécifications structurées de Z se construisent en étapes. Il faut (1) définir

les fonctions et types auxiliaires du système, ensuite (2) définir l’espace
d’états du système et enfin (3) définir les opérations du système (basées sur
les relations de l’espace d’états).
Etape 1 : Définition des fonctions et types auxiliaires du système
Basic Types [Name, date ]
Dans cette spécification, la forme exacte des noms et des dates n’est pas fixée.
Etape 2. Définir l’espace d’état du système.

Name of schema
BirthdayBook declaration of typed variables (represent
known :  Name observations of the states)

birthday : Name Date

relations between values or variables (are true
in all states of the system)
known = dom birthday

known est l’ensemble des noms avec des anniversaires mémorisés. birthday
est une fonction partielle qui lie certains noms à des anniversaires. La relation
entre known et birthday constitue l’invariante du système. L’ensemble known
correspond au domaine (dom) de la fonction birthday. Un exemple
d’ensemble d’états est donné comme suit :
known = Susy, Mike, John
birthday = John  25 March ; Susy  20 décembre, Mike  20 décembre}
Invariante : known = dom Birthday

73
Il est à noter qu’il n’y a pas de limitation pour les anniversaires mémorisés et
qu’il n y’a pas d’ordre particulier pour les entrées. Chaque personne n’a
qu’un seul anniversaire (Birthday est une fonction ). Deux personnes peuvent
avoir leur anniversaire le même jour.
Etape 3 : Définir les opérations du système basées sur les relations de l’espace
d’états.
Il existe des opérations qui changent l’état du système et d’autres le laissent
inchangé. Certaines opérations ont des entrées et /ou des sorties.

in ? système out !

La convention de Z est de décorer les entrées avec un point d’interrogation et

les sorties avec un pont d’exclamation.
Opération : Ajout de l’anniversaire d’une personne dans le système

AddBirthday Name of operation

 Birthday Book Structured Import (symbol  )
Input of operation (symbol ? )
name? :NAME Input of operation (symbol ? )
date? : DATE

name? known Precondition for success of operation. Extend the birthday

function if precondition is satisfied
birthday’ =birthday U name?  date?

Ce schéma change l’état du système : il décrit l’état avant (variables sans ’) et

celui d’après (variables avec ‘) de l’opération. Il faut noter que l’on ne dit pas
ce qui se passe quand la précondition de l’entrée n‘est pas remplie. Il est
cependant possible d’étendre la spécification (raffiner) afin qu‘elle renvoie
une erreur. Nous espérons qu’avec AddBirthday. L’ensemble des noms
connus est augmenté avec un nouveau nom c’est-à-dire known’= know 
name?. Nous allons le prouver par la spécification de AddBirthday en
utilisant l’invariante avant et après l’opération.
known’ =dom birthday’ (invariant after )
=dom (birthday  name ?  date? ) (spécification de AddBirthday )
=dom birthday  dom name?  date?  ( fact about dom )
=dom birthday  name? ( fact about dom )
= known  name? (Invariant before )

La démonstration de telles propriétés assure que la spécification est correcte.

L’on peut analyser le comportement du système sans spécification.
74
Opération 1: Retrouver l’anniversaire d’une personne connue du système

FindBirthday Name of operation

 BirthdayBook Structured Import (symbol  )
Input of operation (symbol ? )
name ? :NAME Output of operation (symbol ! )
date ! : DATE
name ? known Precondition for success of operation
date ! = birthday (name) Output of operation ( if Successfull)

FindBirthday
Ce schéma laisse l’état du système inchangé ( : le
symbole d’importation). En effet, rechercher un nom BirthdayBook
n’ajoute rien et n’enlève rien aux noms mémorisés.name ? :NAME
Le schéma précédent est équivalent à celui-ci-contre :date ! : DATE

known’ = known
Opération 2 : Retrouver la liste de toutes les personnes
birthday’= birthday
! est  known
qui ont leur anniversaire à une date donnée. cardsname ?
date ! = birthday (name ?)
l’ensemble des noms auxquels les cartes de voeux sont
envoyées.
Remind
 BirthdayBook

today ? : DATE
cards ! : − NAME

cards ! = {n known |
birthday (n) = today ?}

Etat initial du système

InitBirthdayBook

BirthdayBook
Ici le prédicat known= 
known =  birthday =.

En résumé, que dit la spécification sur l’implantation ? Elle décrit ce que fait
le système sans préciser comment. Par exemple la spécification Z décrite ci-
dessus identifie les opérations et les données légales et illégales. Les
opérations sont, par exemple, l’insertion simultanée des anniversaires de
deux personnes, l’insertion de l’anniversaire d’une personne connue du système
(c’est-à-dire quand name?  known). L’opération ChangeBirthday n’est

75
pas spécifiée et pourrait être ajoutée ou réalisée seulement dans
l’implantation.
Il existe plusieurs outils et systèmes supportant Z. Pour de plus amples
informations, on peut se référer à : http ://archive.comlab.ox.ac.uk/z.html.
Quelques uns des outils sont :
ZETA : environnement ouvert incluant un véritable analyseur de type.
HOL-Z : intégration de Z dans un système de preuve et de théorème
Object-Z : une extension orienté-objet de Z.

8.3 Modélisation des données avec Z et les diagrammes ER

Les diagrammes E/R peuvent être traduits dans les spécifications Z, en
particulier la formalisation des contraintes sur les données qui ne sont
qu’implicites avec le diagramme E/R. La traduction se passe en plusieurs
étapes. D’abord les entités de bases, ensuite les entités d’agrégat, et enfin les
relations sont traduites pas à pas.
Par exemple, l’entité de base correspond au schéma Z avec les contraintes
explicites suivantes
Name

Department
EMPLOYEE Employee

name : NAME
[NAME] Income
Dept ! : DEPARTMENT
DEPARTMENT : := A|B|C Income : 100.000 .. 800.000

If Dept= A then (100.000 < Income)  (Income <

300.000) else if Dept = B then (300.000 < Income) 
(Income < 400.000) else (400.000 < Income) 
(Income < 800.000)
Les Entités agrégats
Dates Room
Meeting ==Date x Room
1 1 ou
Meeting == Room x Date
contain contai

1
1
Dates Room
Meeting

n n

contain contai 76

1
1
 MeetingSeries ==seq (Date) x seq(Room)
ou
MeetingSeries == (Room) x  (Date)

Form
name

1 Employee
Les relations Addres company n
Dep
s emplo
t
SalesPartne
r Incom
e
Cette relation peut être implémentée par la relation partielle suivante dans Z.
Un employé est relié à une entreprise. Les attributs des entités ont disparu.
employs == Employee company

La relation suivante est réalisée comme un produit cartésien.

m n Room
Date takes_place takes_place == Date  Room

Enfin, il faut parfois procéder à des transformations avant de réaliser une

implémentation plus facile ou plus commode. On a donc
Form
companyId
Addre
Addr 1 CompanyId company
company 1
ha SalesPartne
Form
SalesPartn

Cette transformation montre que la relation entre les deux entités est une
injection partielle. C’est pourquoi on peut écrire dans Z
has == company >-+-> companyId

8.3.1 Equivalence et schémas

Deux schémas sont dits équivalents s’ils introduisent les mêmes variables et
leur imposent les mêmes contraintes. Il faut faire cependant très attention car
les contraintes peuvent être cachées dans les déclarations.

BirthdayBook BirthdayBook

known : − Name 77 known : − Name

birthday : Name <--> Date birthday : Name -+-> Date

known = dom birthday known = dom birthday

Ces deux spécifications ont les mêmes contraintes, mais elles sont exprimées
dans deux endroits différents. D’une manière générale, on a
... .....

... …

ab 
(a  b)  ( c v d )
cvd

mais
... .....
... …

 y : T    y : T  (x<y) v (y < x)

x<y v y < x

Un schéma peut être utilisé comme déclaration SchemaOne

par exemple dans une compréhension ou après a : Z
c :  Z
un quantificateur. L’effet est que les variables de
la partie déclarative sont introduites avec les a c
contraintes de la partie prédicative: c

On peut écrire  SchemaOne  a = 0 ce qui est équivalent à  a : Z, c : Z |

(a c)  (c)  a = 0
MONTHS : : = jan|feb|mar|apr|may|jun|jul|aug|sep|oct|nov|dec
Date
Month: MONTHS
Day:1..31

Month  {apr, jun, sep, nov} day  30

Month = feb } day =29

On peut quantifier (avec Q un quelconque quantificateu) sur le schéma Date

comme cela est présenté ci-dessous :
Q Date. P  Q month : MONTHS, day : 1. . . 31 | ( months  { apr, jun, sep, nov}  day 
30 )  ( month = feb  day = 29 )  p
78
 
 Date. (month = feb)  ( day = 29) est vrai
 Date. ( day  30 ) est faux car  ⊳ month ⇝ mar, day ⇝ 31 ⊲
Un schéma peut être utilisé comme prédicat à la seule condition que chaque
composante ait déclaré un élément du bon type. L’effet est d’introduire les
contraintes équivalentes à l’information du prédicat. La partie déclarative est
supprimée, seules les contraintes restent.

SchemaThree
SchemaOne
c:Z
a : Z
a:Z
c :  Z

a c  c a c  c
c  {0,1}

 a. : c : Z , c :  Z| SchemaOne  SchemaThree 
  a. :Z, c :  Z| ( a  c )  (c   )  ( a  c )  (c   )  ( c  { 0,1 } )

les parties déclaratives sont omises. En d’autres termes, toute variable qui
satisfait à SchemaOne doit satisfaire à SchemaThree.

8.3.2 Les opérateurs et le calcul des schémas

Les opérateurs logiques sur les schémas sont : la renommination, l’inclusion,
la décoration, la conjonction, la disjonction, et d’autres (normalisation,
négation, quantification, …). Avec ces opérations l’on peut structurer et
composer séquentiellement les spécifications.
Renommination (renaming) : Avec schema [new/old] l’on peut introduire une
nouvelle variable avec les mêmes motifs de déclaration et de contraintes,
procédant ainsi à une substitution systématique.

SchemaOne SchemaOne
a:Z
c:Z a:Z
s:Z
SchemaOne [ a/a, s/c] 
a c  c
a s  s

79
Schémas géneriques : L’on peut renommer les composantes mais pas changer
leurs types. Pour utiliser un même motif pour plusieurs types, les schémas
génériques avec des paramètres formels sont utilisés.
SchemaOne[X]
a:X SchemaOne
c: X Si X = Z alors on a
a c  c a : Z
s :  Z

a s  s

Exemple : une spécification de TRI sort [X]

[X]
in ?, out ! : seq X
nondecreasing : ( X X )  IP ( seq X ) rel ? : X  X

rel ?  totord x
 R : X  X,  : seq X  (   nondecreasing (R) out !  nondecreasing [X] ( rel ? )
  i , j : dom  |i<j  ((j), (j) )  R items (out ! ) = items (in ? )

Conjonction des schémas : Elle permet la combinaison des spécifications

séparées constituant les parties d’un système global.
S T a :A
a :A b:B
b:B
b:B c :C S /\ T = c :C
A
P Q PQ

Les types des variables déclarées simultanément doivent être les mêmes.

Inclusion des schémas (importation ou héritage) : Elle a le même effet que la

conjonction mais suggère une structure hiérarchique.
x,y: Z
M
L
L u:IP Z
x, y: Z
u:IP Z
v: IP Z
u : IP Z
x<y
xv
xv
x<y 80
Décoration d’un Schéma : Soit un schéma
State’
State a’:A
a:A
b’ :B
b :B

P
P

Sur ce schéma une opération est décrite par deux copies une avant et une
après (avec prime).
Disjonction des schémas : Elle décrit les alternatives dans le comportement du
système
S T a :A
a :A b:B b:B
b:B c :C S \/ T = c :C
A
P Q PQ

8.4 Raffinement du Birthday Book

L’on peut maintenant raffiner la spécification de l’annuaire. On n’a pas
encore formaliser ce qui se passe quand l’entrée de l’opération est incorrecte :
l’entrée est–elle ignorée ? Le système BirthdayBook se plante-t-il ?
AddBirthday

 BirthdayBook
name ? :NAME
date ? : DATE

name ? known
birthday’ =birthday U name ?  date ?

Que se passe-t-il quand name?  known? La solution peut consister en une

description d’erreur qui étend la spécification. L’on introduit une sortie
supplémentaire result! et un type libre
Report :: = ok| already_known|not_known
Nous introduisons un schéma général appelé Success Success
result !: REPORT

81
result ! =ok
quand l’entrée est correcte, l’on a alors
Addbirthday /\ Success.
Quand l’entrée est incorrecte, nous introduisons un
autre Schéma
AlreadyKnown
 Birthday Book
name ? :Name
result ! : Report

name ?  known
date ! = already_known

Ainsi l’on peut écrire

RAddbirthday= ( Addbrithday /\ Success ) \/ AlreadyKnown
Raffinement de la Recherche
FindBirthday
 BirthdayBook

name ? : Name
date ! : Date

name ? known
date ! = birthday (name)

Quand l’entrée est correcte, l’on écrit Findbirthday /\ Success. Quand

l’entrée est incorrecte, nous introduisons un autre Schéma.

NotKnown
 Birthday Book
name ? :NAME
result ! : REPORT

name? known
date! = not_known

Ainsi la partialité disparaît et l’on peut écrire

RFindBirthday = ( Findbirthday /\ Success) \/ NotKnown
RRemind  Remind /\ Success

82
8.5 Queens Problem (Problème des reines)
Huit reines doivent être placées de telle sorte qu’aucune ne menace l’autre
(même ligne, colonne ou diagonale)

Q
Q
Q
Q
Q Q
Q
Q Q
Q
Une menace une solution

Définition de base :
SIZE = = 8, ROWS = = 1 . . SIZE, COLS = = 1 . . SIZE, POS = = ROWS  COLS
Les positions des figures sont définies par Queens = = POS

1er essai : les reines ne doivent pas être sur la même ligne ni colonne.

Queens. IP POS

# queens = SIZE
 q1, q2 : Queens  q1 q2 
first ( q1)  first (q2 ) 
second (q1 )  second (q2 )

En d’autres termes, chaque figure q dans une ligne x possède une colonne
individuelle. Nous sommes en présence d’une bijection.
queens : Rows >-->> cols.
Il ne reste plus qu’à résoudre le problème des diagonales. Chaque champs
(POS ) repose sur deux diagonales et chaque diagonale est décrite par une
valeur sur l’axe y.
DIAG == ( 1-SIZE) .. ( 2* SIZE)

up, down : POS DIAG

83
 x : ROWS, y : COLS  up(x,y) = y-x
 x : ROWS, y : COLS  down(x,y) = y+x
 x
up et down ne sont pas injectifs. Plusieurs champs sur une diagonale sont
attribués à la même valeur y.
En fin de compte, l’on peut remarquer que Queens
l’ensemble des liaisons queens contient toutes les
queens : ROWS >-->> COLS
solutions c’est-à-dire la description de tous les faits
nécessaires pour l’implémentation et que la solution
n’est pas liée à une stratégie d’implémentation. queens  up  POS >--> DIAG
queens  down  POS >--> DIAG

84
Chapitre 9 : Des modèles aux codes

Ce chapitre se rapportant aux phases de modélisation et d’implémentation

étudie les concepts utiles à la structuration de grands systèmes afin d’en
isoler les mécanismes de réutilisation. Dans la conception détaillée, des
éléments des langages sont nécessaires pour les possibilités
d’implémentation. Le présent chapitre étudie le paradigme orienté objet et sa
réalisation dans Java.
La deuxième préoccupation est le passage de la conception au code. Les
modèles doivent être raffinés par étapes. Des informations supplémentaires
sur les propriétés statiques et dynamiques doivent être ajoutés à la
description. Mais, en fin de compte, l’on est obligé de passer du modèle
raffiné au code.
Certains aspects sont faciles, mais d’autres sont complexes. Les
diagrammes de classes par exemple se traduisent en hiérarchie de classes.
Certains ateliers de génie logiciel (CASE-Tools) aident dans le passage du
modèle aux codes.

9.1 Structuration, contexte et historique

L’on distingue plusieurs étapes et historiques. La première est le manque
de contrôle total sur l’interaction des programmes et des données. Ici, un
programme manipule directement les données ou même le code assembleur
d’un autre programme. On est ici dans les années 1950. L’infraction majeure
est le non respect du principe de modularité.
Dans les années 1960, la communication se passe à travers les variables
globales avec l’invention de C et de FORTRAN. Ceci constitue une infraction
contre le principe secret (information hiding). Toujours dans les années 1960,
il a existé l’échange des informations de contrôle, mais il est très erroné. La
méthode standard consiste à échanger des informations à travers des
paramètres ou des procédures. Dans les années 1970, l’échange a lieu à
travers les messages. Enfin, les années 1980 ont introduit les interfaces
explicitement définies et présentées par les mots-clé export, import, uses.
Cette technique est aujourd’hui la méthode standard et constitue un moyen
de structuration nécessaire pour éviter l’échange incontrôlé des messages ou
d’appels des procédures.
85
9.2 Structuration dans le langage orienté objet
L’orientation objet est aussi bien une Weltanschauung qu’une certaine
propriété linguistique qui aide dans la construction de grands projets.
En tant que Weltanschauung, le monde orienté objet se compose d’agents
qui proposent leurs services. Sur le plan technique, les langages orientés objet
offrent plusieurs possibilités de structuration telles : les interfaces, les classes,
l’héritage, le polymorphisme, … ils supportent aussi bien les types abstraits
classiques que la conception orientée objet.
Exemple : Les files comme classes dans Java
import java.util.LinkedList
Class sequences {
private Linkedlistlist
public sequences ( ) { list = new linkedlist ( ) ; }
public void enq ( object * ) { list.addlast (x ) ; }
public object deq ( ) { return list.RemoveFirst ( ) ; }
public object hd ( ) { return list.getFirst ( ) ; }
public boolean isEmpty { return list.Size ( ) == o ; }
}

Le principe secret est réalisé ici par les mots clé import qui spécifie une
classe (LinkedList) dans un paquet (java.util ) et public/private/protected
qui sont des mécanismes de contrôle.

9.3 Classes versus module

Les classes et les modules soutiennent tous deux la définition des interfaces
et le principe secret. Les classes concrètes fixent les détails de
l’implémentation.

9.3.1 Les interfaces

Ce sont des frontières réelles ou imaginaires entre deux systèmes pourvus
d’un protocole de communication. Une interface définit comment les
systèmes interagissent. Si l’on tient véritablement compte des responsabilités,
une interface fixe les propriétés syntaxiques et sémantiques. L’avantage
majeur réside dans la séparation client et développeur. Malheureusement,
Java, C++, . . . , ne peuvent prendre en compte que les aspects statiques (et
très faiblement les aspects sémantiques) ce qui fait que la vérification si une
classe implémentant une interface contient toutes les méthodes spécifiées
n’est pas toujours réalisable.
86
 Exemple : les listes réalisées par le paquet java.util
public Interface collection {
int site ( ) ; // the number of elements in the collection
boolean isEmpty ( ) ; // true if collection contains no elements
boolean contains (Object O ) ; // true if collection contains object O
Iterator iterator ( ) ; // return an iterator over elements in collection
boolean add (Object O ) ; // adds an element, true if collection changed
boolean remove (Object O ) ;
public Interface List extends collection {
int size ( ) ;
Object get ( int index ) ; // Get element at index in a list
Object set ( int index, object ) ; // set an element at index in a list
…
}

Les aspects sémantiques sont introduits après les signes de commentaires

(//).

9.3.2 Les types et le polymorphisme

Dans le monde orienté objet, un type correspond à un ensemble d’objets
qui implémente une certaine interface. Le type nomme tous les opérateurs et
les paramètres d’entrées-sorties.
En polymorphisme, un objet d’un sous-type peut toujours être utilisé là où
un objet d’un supertype est attendu. Par exemple, une LinkedList peut
toujours être utilisée là où une liste est attendue.

9.3.3 L’héritage
Il existe deux sortes d’héritage : l’héritage de l’implémentation où la
déclaration des sous-classes permet la réutilisation des implémentations
(programmes) et l’héritage des interfaces. Java permet l’héritage simple des
programmes et l’héritage multiple des interfaces.
Exemple : Définissons un objet géométrique
public abstract class Shape {
public double area ( ) { return 0.0 ; }
public double volume ( ) { return 0.0 ; }
public abstract string getName ( ) ;
}
public class Point extends Shape {
protected double x ; y ;
public Point (int a, int b) { x = a, y= b; }
. . .
87
 public string getName ( ) { return « point », }
}
public class Circle extends Point {
protected double radius ;
public circle (double r, int a , int b)
…
public string getName ( ) { return « circle », }
}

9.4 Du code à partir des diagrammes de classe

Les diagrammes de classe sont les plus appropriés pour la génération
automatique de code ; en effet, les contraintes statiques ont une sémantique
relativement simple. L’interprétation est souvent définie d’une manière
univoque. Enfin, les composantes des diagrammes reflètent les aspects des
langages orientés objet. La situation est par contre plus difficile pour les
aspects fonctionnels et dynamiques. Les spécifications ne sont pas
constructives et leurs fonctionnalités parfois mal définies. Certaines fonctions
peuvent se laisser implémenter de plusieurs manières.

9.4.1 Les diagrammes de classe

 le cas simple : une classe sans attribut Person
Dans Java, cette classe est définie par :
class Person { public person ( ) { } }
Le système a une classe avec un constructeur. Ce qui s’y est ajouté n’est pas
spécifié.

 les classes avec attributs

Thermometer
- valid : bool
+ value : float

Les annotations peuvent être traduites en public ( + ) et private ( - ), mais

elles peuvent aussi être utilisées pour générer les méthodes get et set.
public class Thermometer {
private boolean valid = false ;
public float value = 0.0 ;
public thermometer ( ) { }
public thermometer ( float value ) { this.value = value ; }}

88
 Ici nous optons pour une conception générale consistante à savoir
l’utilisation de get et set .

Les classes avec opération :

les opérations peuvent être traduites en des entêtes des méthodes.
Thermometer If ( val >0 )&&(val < 100)
- valid : bool { value = val,
+ value : float  return true }
else return false
resetTo ( val : Float) : bool

public class thermometer{

private boolean valid ;
public float value ;
public boolean resetTo ( float val ) { }
}
public boolean resetTo ( float val )
{ if (val > 0 ) && ( val < 100 )
{ value = val ; retur n true ; }
else return false
}

9.4.2 La généralisation « interface »

person Employee
public interface Employee { ... } ;
public class Person { ... } ;
public class Prof extends Person implements
Employee
Prof
{ public prof ( ) { super ( ) ; } // calls
Person

9.4.3 Les associations

Prof Cours
les associations simples et dirigées
On se rappelle que les objets de la classe Cours envoient des messages aux
objets de la classe Prof. L’implémentation se passe à travers une variable
d’instance dans la classe Cours.
public class Cours {
private Prof prof ;
public prof getProf ( ) { return prof ; }
public void setProf ( Prof prof ) { this. Prof = prof ; }}

Les associations avec direction et rôle

Ici l’on crée pour chaque rôle une variable d’instance.
89
public class Class1 {
- rôle1
private class2 rôle1 ;
public class2 rôle2 ;
} + rôle2
public class Class2 { Class 1 Class 2
private class1 rôle3 ;
}
- rôle3

les associations avec cardinalité

1 *
La réalisation se passe par un array. Prof Course
prof duties
public class Prof { public course [ ] }
public class Course { public Prof prof ;}
Les associations peuvent aussi être implémentées à l’aide des bases de
données relationnelles.

9.5 Génération de codes à partir de Z

La synthèse et la spécification des programmes constituent un cours à part.
Ce sont des thèmes difficiles à cause du raffinement des données et la
conception algorithmique. Le raffinement s’occupe de la transformation
d’une spécification abstraite en une spécification concrète.
Abstrait : x’ > x Concret : x’ = x + 1
Implémentation : x’:= x+1 (Pascal ) Raffinement : x’ = x + 1 x’ > x

L’expression x’ =x+1 réalise le cas concret pendant que l’inégalité x’>x est
le cas abstrait. Il existe des méthodes pratiques pour générer des programmes
à partir des spécifications Z. Elles dépendent surtout du langage vers lequel
on veut extraire le code ( HASKELL, C, C++, Java ). L’idée fondamentale est
la suivante : les types en Z sont donnés en définition des types de données.
Les définitions axiomatiques correspondent aux constantes ou des données
non changeables. Les schémas quant à eux représentent des données
changeables.

9.5.1 Les types de données

Les types libres (free types ) correspondent aux types d’énumération dans
les langages de programmation.
Exemple :
Z FAULT : : = overload |lineVoltage| overTemp|groundShort
Pascal type Fault = (overload, lineVoltage, overTemp, groundShort)
C typedef enum {overload= o, lineVoltage = 1, overtemp = 2,
groundShort =3 ) fault

90
9.5.2 les relations
On a à faire ici à une relation entre les naturels et les entiers.
C int u[maxVal]
phone : Name ---> Z Haskell : type Name = string,
type phone = (Name, int)
phones ::  phone 
domaine = subscribes

9.5.3 Les schémas

Ils spécifient des données changeables et correspondent à des déclarations de
variables, par exemple des tableaux ( struct en C ) ou une classe dans les
langages orientés objet .
Schéma en Z Implémentation
S ≘  x, y : Z  C: int x, y
C: typedef struct  int x, y ;  S
Java: public class S  int x, y ; 

Exemple
PS
contractor : switch
preset, setpoint, output: SIGNAL
contractor = open  setpoint= 0
contractor = open  output < 2
Implémentation en C
Type def int SIGNAL ;
Type def enum open, closed  Switch ;
Type def struct powerSupply
{switch contactor ;
signal preset, setpoint , outpoint ;
int faults ’N_faults’  ;
} PS

Les invariantes ne correspondent pas à un programme mais ce dernier doit

fonctionner de manière à respecter celles-ci .

9.5.4 Les techniques de structuration

Z possède une structure globale plate. Par exemple, une opération peut se
définir par op = [ S /x = x +y ]. Dans C, l’implémentation directe
met les variables globales dans leur contexte.
Schéma en Z: C:
op = [ S /x = x +y ] int x,y ;
void ( op void ) {x = x+y }
java :
public class S {
private int x ,y ;

91
 public void op ( ) {x =x + y ; }

On peut représenter aussi une spécification Z dans une classe.

BirthdayBook
known : − Name
birthday : Name -+->
known = dom birthday
Class Birthday {
private Hashset known ;
private Hashtable birthday ;
Date public BirthdayBook ( )
{ known = new Hashset ( ) ;
birthday = new Hashtable () ;
}
}

Chaque schéma  correspond à une méthode.

AddBirthday
public void addBirthday (string Name, string date )
 Birthday Book
if (!known.contains (name))
name ? :NAME
date ? : DATE {birthday.put(name, date ) ;

known.add(name ) ;
name ? known
}
birthday’ =birthday  name ?  date ?
public string findBirthday (string name )
name ? Known  birthday  = birthday  {name ? ↦ date ? } If ( ! known.contains (name))
⊑ if (name ?  known)  birthday  =birthday { name ?↦ date ? { string date=string birthday.get(name ) ;
⊏ if ( !known.contains (name)  birthday.put (name , date )
return date ;

} else return ‘No Entry’

La synthèse d’un programme est un processus créatif. Les outils CASE

n’aident que comme squelette. En général, l’on ne peut pas remplacer la
créativité. Il existe plusieurs variantes orientées objet de Z ( OOZE ; Object-Z,
Z++) qui incorportent les techniques orientées objet et livrent un meilleur
contrôle.

92
Chapitre 10 : les interfaces graphiques

Pour l’introduction d’un système de logiciels dans la pratique, plusieurs

obstacles apparaissent. L’utilisateur a un problème dans l’exploitation du
système. Il a des difficultés avec la fonctionnalité du système. Après un long
temps d’exploitation, l’utilisateur se plaint du travail monotone avec le
système ou de son caractère exigeant.
Tous ces problèmes peuvent conduire à de massives difficultés
d’acceptance. Dans le cas extrême, un refus du système s’en suit.
Où peut-on localiser les sources du problème ?
- Les problèmes d’utilisation sont souvent issus du manque ou de
l’inadéquation d’une interface graphique (GUI : Graphical User Interface )
- Le problème de fonctionnalité montre que l’analyse du système ne
correspond pas aux tâches exigées
- La monotonie et le problème de sous exploitation apparaissent quand la
majeure partie des tâches est réglée automatiquement par le système.
L’ergonomie du logiciel (software ergonomy) vise à adapter le logiciel d’un
ordinateur avec lequel l’utilisateur travaille aux propriétés et besoins de cet
utilisateur afin de lui permettre une utilisation élevée des facilités et des
possibilités du système.

10.1 Aperçu sur les interfaces graphiques

Les interfaces graphiques relèvent du domaine de la communication
homme-machine. L’objectif primordial est de permettre une utilisation
intensive simple adaptée aux facilités, aux backgrounds et aux motivations
humaines. Shneidermann(1998) retient 8 buts conceptuels :
1. la réduction de la recharge, à court terme, de la mémoire
2. la représentation visuelle des objets
3. l’adaptation pour les novices et les experts
4. la consistance de la représentation
5. la confirmité à l’attente des ustilisateurs

93
 6. un feedback informatif et un traitement simplifié des erreurs.
7. Un retour simple sur les actions passées
8. Les dialogues.
Il est nécessaire de se demander si développer une interface graphique
(Graphical User Interface, GUI) est un art ou du génie logiciel. En effet, les
solutions graphiques présentées sur le web et certains programmes font
croire que le GUI est une solution artistique. Cependant la plupart des GUI
sont des tâches d’ingénieurie contrôlées par des guides de styles et de
réaction à la technologie. Les principes de la conception des GUI sont :
- les affichages graphiques avec couleur
- la présence d’un matériel spécial pour le réallumage.
Souvent la technique utilisée est le WIMP c’est-à-dire le Windows Icons
Menue Pointers ou Windows Icons Mice Pulldown Menues.
Le noyau de cette technologie est bien la notion de Widget (Tk) ou des
composantes graphiques (awt/swing) organisées en arbres. Les GUI sont des
systèmes réactifs qui lient des évènements à des actions avec les interfaces
graphiques l’on retrouve tous les problèmes de la programmation
concurrentielle tels la synchronisation, les call-backs, les notificateurs, le
blocage des ressources et le interleaving. Le développement des GUI est
souvent sous-estimé. Leur modélisation se fait à travers les statecharts.

10.2 Recommandations de développement

Comme tout développement de produit qui a un contact avec l’homme il
faut respecter un certain nombre de critères pour que la communication
homme machine soit optimale. La première exigence est de prendre en
compte les métiers des utilisateurs. Il s’agit en effet de considérer les profils,
les processus de métiers qui entrent en jeu dans l’utilisation finale du
produit. Pour arriver à cette fin, il est nécessaire d’élaborer des cas
d’utilisation très en amont du cycle de vie, en associant étroitement les futurs
utilisateurs à la validation de la maquette et/ou du prototype. Ceci permet
très tôt d’éviter de s’écarter trop loin des besoins des utilisateurs en matière
d’ergonomie.
Il faut aussi choisir un outil de construction d’interfaces-homme-machine
(IHM) qui utilise, si possible, le même langage de programmation que le reste
de l’application. En effet, développé dans un autre langage, de sérieux
problèmes d’intégration surviennent très souvent, ce qui peut conduire au
rejet du produit par les utilisateurs. En phase de validation, il faut mettre en
œuvre les scénarii, pour avoir un look-and-feel du produit. Dans la phase de

94
test, il est nécessaire qu’un outil soit utilisé qui permette d’automatiser les
enchaînements, même partiellement. Il est nécessaire que ce soit les
utilisateurs réels ou potentiellement réels qui valident l’interface en utilisant
des métriques comme, par exemple, le calcul des temps moyens pour
accomplir une tâche (par grandes familles de tâches), les fréquences d’erreurs
par profil utilisateur et par type de tâches, la fréquence d’utilisation de l’aide
en ligne et/ou de la documentation utilisateur, la fréquence d’utilisation de
la fonction «undo». Cette phase très importante décide de l’acceptabilité du
produit final. Ici les développeurs peuvent adapter le produit aux besoins des
utilisateurs en jaugeant fonctionnalité et ergonomie.
En ce qui concerne la phase de test unitaire, le développeur doit vérifier la
conformité du comportement de tous les objets graphiques par rapport au
système graphique hôte et à son guide de style (Windows, Macintosh, X-
Window/Motif). Chaque développeur doit respecter l’esthétique de son
produit en termes de couleurs, de l’alignement des groupes de boutons
(radio, case à cocher, etc.) et des polices de caractères (labels, boutons, menus,
etc.). Les aspects généraux telles que les conditions de validation des données
doivent être minutieusement étudiées. Ils concernent surtout les valeurs par
défauts des options, des champs, …, la longueur maximum des chaînes de
caractères, les dates, les valeurs numériques, les messages d’erreurs etc.
Un aspect souvent negligé et qui conduit à la longue à une monotonie
d’utilisation ou des cas de rejet est le confort de navigation. L’utilisateur doit
pouvoir accéder aisément aux fenêtres à partir des menus, de la barre d’outil,
…. Peut-on avoir plusieurs instances d’une même fenêtre (est-ce normal ?).
Les fenêtres sont-elles modales ou non modales?
Il faut tenir compte de la sémantique des données dans les fenêtres de
communication. Quand les données sont-elles prises en compte?
Il est nécessaire ici de vérifier les confirmations (fermeture de la fenêtre,
boîte de dialogue, annulation), de s’assurer des transactions et du «feed-
back» à l’utilisateur.
En terme général, il faut que les champs «read-only» soient grisés. Il faut
de surcroît s’assurer que les boutons «OK» et «annuler » sont groupés et
séparés des autres boutons. Il faut faire la chasse aux abréviations (labels,
boutons, …) et enfin s’assurer que le «focus» est positionné sur le bon objet à
l’ouverture d’une fenêtre ou d’une boîte de dialogue.

95
10.3 Technologies concrètes : Java /swing
Le Java/Swing est une technologie populaire puissante créée par Netscape
et Sun depuis 1996. La conception est basée sur une bibliothèque orientée
objet. Les opérations parallèles se font à travers la Java threads (programmes
qui traitent le parallélisme). Il soutient aussi l’adaptation de l’utilisateur à
travers le look and feel tel Windows, Motif, Metal. Il incorpore des
composantes d’ordre élèvés telles les listes, les tables, les arbres, etc. Il existe
sous deux variantes :
- Java/awt qui est une approche simple mais ayant des problèmes de
portabilité
- Java/swing qui est une approche de painture mais avec des problèmes de
vitesse d’exécution. Les composantes des fenêtres sont organisées dans
une hiérarchie de classe.

Object

Compoment

Container

JComponent
Window

Frame
JPanel JLabel JText Abstractbutt Jlist …
on
JFrame

Component : repaint, setLayout, add, isVisible, setVisible, isShowing,

getLocation, setLocation, getSize.
Window : toFront, toBack
Frame : setResizable, setTitle, set IconImage
Dans Java/Swing, les méthodes sont organisées selon les motifs
conceptuels du model-view controler avec le contenu qui est l’état du GUI
c’est-a-dire l’état des boutons ou des champs des textes, l’apparence visuelle
que l’on appelle configuration comportant la couleur, la grandeur, etc… et le
comportement c’est-à-dire la réaction à un événement. Le layout est géré par
un layout manager. Le layout des bords est organisé comme suit :

96
 Class MyPanel extends JPanel
West {setLayout (new Borderlayout ( ) ;
…
North add (yellowButton,’south’ )
}

East
Center

South

Les événements du niveau bas sont : KeyEvent, MouseEvent, TextEvent,

WindowEvent,…et les autres sont les événements sémantiques :
ActionEvent,WindowEvent,…
Le modèle des événements est basé sur le motif d’observation appelé
observerPattern composé des listeners (écouteurs) et des consommateurs
d’évènements (event-consumers ). Les listeners sont caractérisés par les Java
interfaces. Ici, un exemple de génération d’une fenêtre.
Import Java.awt.* ;
Java.awt.event.* ;
Java.swing.* ;
Class MySimpleExampleFrame extends JPanel Implements KeyListener
{public simpleExampleFrame ( )
{setTitle ( Please enter name : )
setSize (220,110 ) ;
addWindowslistener (new window Adapter ( )
{public void windowClosing (windowEvent e ))
{System. Exit ( 0 ) ;
}
} ;
container contentPane = getContentPane( ) ;
JPanel panel = new JPanel ( ) ;
JLabel label = new JLabel ( name ) ;
panel_add (label ,  west ) ;
entry = new JTextField (12 ) ;
entry.addActionListener (this ) ;
panel.add (entry , East ) ;
contentPane .add (panel , North ) ;
JButton quitButton = new JButton ( Quit  )
quitButton.AddActionListener (newActionlistener ( ))
{public void actionPerformed (actionEvent evt )
{system.exit ( 0 ) ; }
} ) ;
JPanel panel2 = new Jpanel ( ) ;
panel2.add (quitButton )
contentPane.add (panel2 ,  south ) ;
} ;
public void actionPerformed ( ActionEvent evt )
{Object source = evt.getSource ( ) ;
97
 if ( source = entry )
{ string h = entry. getText ( ) ;
}
else { }
} ;
private JTextField entry :
}
public class SimpleExample {
public static void main ( string [ ] args )
{ JFrame f = new simple ExampleFrame ( ) ;
J.show ( ) ;
}

10.4 Conclusion
La conception et l’analyse des GUI peuvent être extrêmement complexes. Il
existe plusieurs problèmes concernant leur analyse et validation même si les
fondements théoriques sont simples et clairs. Le modèle des données est
réglé par les widgets à travers l’héritage : cependant la technologie des motifs
d’observateur est incommode.

Un exemple d’interface.

98
Chapitre 11 : La validation et le test des logiciels

La validation constitue la phase précédant l’implantation du logiciel dans

son environnement de vie.
En termes synoptiques, la validation est la réponse à la double question :
Are we building the right product ? Are we building the product right ?
Il existe plusieurs niveaux de validation : la validation de
l’implémentation, la validation de l’intégration logicielle, la validation de
l’intégration systémique. Le problème de la validation possède 3 dimensions
à savoir les techniques de validation (vérification, inspection, test, etc ), les
niveaux de validation (intégration logicielle, systémique, implémentation) et
les buts de la validation (GUI, noyau fonctionnel, interaction des
composantes, interaction du système avec son environnement ).

11.1 Vérification et transformation

L’idée fondamentale de cette approche est d’utiliser les règles logiques
pour établir les équivalences entre la spécification formelle et
l’implémentation. Elle est aussi désignée d’approche post vérification
given : program, specification
procedure : show (interactively) equivalence in some logic
(Hoare logic dynamic, PL1, HOL, …)
Une variante de l’approche post vérification est le développement par
raffinement.
given : sequence of specs S1, S2, …Sn
procedure : show (semi –interactively ) Si+1 refines Si
for some refinement relation refines
generates automatically code from. Sn
Les systèmes suivants existent et sont fondés sur cette approche : atelier B (Z
logic ) TKWinHol, Isawin (Back Refinement calculus), KIV (dynamic logic).

L’approche transformationnelle elle s’apparente à une spécification mais

en utilisant les règles de transformation.

99
 given : specification S
Procedure : - apply (highly interactive) transformation
rules like Divide and conquer
- produce sequence of specifications such that Si+1
refines Si for some refinement relation refines
Examples of Systems : TAS, KIDS, CIP, TKwinHOL, …
La méthode de transformation et de vérification a des avantages et des
inconvénients. L’avantage principal repose sur son applicabilité principielle
aux algorithmes, à l’intégration logicielle et architecturale. Elle peut produire
des logiciels de qualité très élevée.
Ses inconvénients son nombreux. En effet, elle est trop chère du moins
intellectuellement. L’aide automatique en logique est encore embryonnaire.
Enfin, il est aujourd’hui difficile d’intégrer des vérifications automatiques
dans tous les processus du développement de logiciel. En conséquence, elle
est parfois réservée à une application à sécurité assez critique.

11.2 Validation des programmes par inspection

L’idée fondamentale consiste à faire examiner un programme par
quelqu’un d’autre. Quand l’équipe de développeurs publie une version du
logiciel, un groupe d’évaluateurs (peers) examine plusieurs aspects du
système ligne par ligne. Il existe aussi des réunions de coordination pour
discuter des erreurs trouvées. Des solutions ne sont pas nécessairement
proposées. Le résultat est un protocole sur les erreurs et des statistiques.
Le système est alors corrigé par l’équipe. La seule condition pour obtenir
un effet maximal repose sur une bonne planification des inspections et
l’indépendance des peers. Il est cependant important de noter les facteurs
psychologiques et les expériences des évaluateurs dans la conduite de
l’inspection. Empiriquement, l’on suppose que ces méthodes couvrent 15 à 20
% du coût de développement global et 60 à 70 % des erreurs peuvent être
découvertes. Toutefois, les résultats dépendent des mesures subjectives et de
la formation personnelle des évaluateurs. Cette technique ne peut pas
s’appliquer aux grands systèmes car les coûts sont trop élevés. Aussi les
inspections manuelles constituent parfois des obstacles à l’amélioration. Une
alternative consiste en l’inspection automatique. L’idée de base est d’utiliser
une technique d’analyse statique pour retrouver des éléments dangereux tels
le typage, la conformité de la documentation au canevas de formatage,
l’absence de flux de données ou de contrôle de flux. Ce support automatique
a l’avantage d’être utilisé par les programmeurs. L’inconvénient repose sur la
non-utilisation de la sémantique du programme.

100
11.3 Le test
Le problème fondamental du génie logiciel est le problème de l'erreur.
Comment construire des logiciels qui soient ergonomiques, fiables, évolutifs,
économiques, satisfaisant aux critères Coût/Qualité/Fonctionnalités/Délais
de réalisation (CQFD), garantissant le contrat de service requis par les
usagers ?
Tout logiciel compte des bogues. Les bogues viennent du mot anglais
"bug" qui signifie insecte, parasite. L'utilisation de ce mot pour désigner une
anomalie vient de l'époque des premiers ordinateurs à tubes à vide. En effet,
des cafards, attirés par la chaleur dégagée par ces tubes, venaient se réfugier
dans ces machines et y mouraient cuits. Leurs cadavres provoquaient des
court-circuits, d'ou des pannes qui ont donc été appelées des "bug".
L'Académie Française a proposé d'utiliser le mot bogue qui désigne
l'enveloppe épineuse de la châtaigne, et par comparaison, des problèmes
épineux.
Sous le mot bogue, l’on retrouve diverses notions à savoir l’erreur, le
défaut, la défaillance et la panne. Tous ces termes ont été normés par ISO.
ERROR (Erreur) : Human action that results in software containing a fault.
For instance omission or misinterpretation of user requirements in a software
specification, and incorrect translation or omission of a requirement in the
design specification.
DEFECT (Défaut) : A product anomaly; e.g. (1) omissions and
imperfections found during early life cycle phases and (2) faults contained in
software sufficiently mature for test or operation.
FAULT (Défaillance) : 1) An accidental condition that causes a functionnal
unit to fail to perform its required function. (2) A manifestation of an error in
software. A fault if encountered may cause a failure.
FAILURE (Panne) : The termination of the ability of a functionnal unit to
perform its required function. A failure may be produced when a fault is
encountered.
L'erreur humaine est fréquente dans l'activité logico-mathématique, la
généralisation et la construction des abstractions, la modélisation et la
dynamique des systèmes, la communication (comprendre et être compris au
sein d’un groupe : la sémantique), la traduction (changement de code) sont
ces activités au coeur de la problématique informatique.
L’informatique doit assumer cette responsabilité car les bogues et les
intrusions diminuent la confiance dans l'informatique. Leurs effets coûtent
très cher. Leur réparation est coûteuse.
101
 Les problèmes rencontrés lors de l'utilisation d'un logiciel peuvent avoir
deux sources à savoir des erreurs résiduelles de développement ou
introduites lors des corrections précédentes ou l'utilisation du logiciel dans
un contexte non prévu. Il est impossible de prévoir tous les modes possibles
d'utilisation d'un logiciel, (mais celui-ci devrait "se défendre" contre les
utilisations dangereuses pour lui).
Le coût d'un bogue est très dépendant du moment où il a été détecté. Si
pendant la phase de conception il a un coût 1, pendant la phase d'intégration,
il coûte déjà 10 fois plus et pendant la phase de recette, son coût vaut 100 fois.
Une détection tardive nécessite souvent des retours en arrière dans le projet.
Maurice Rozenberg affirme que "le test n'est pas une science exacte. Il fait
appel au bon sens autant qu'à la haute technologie". Son succès dépend
beaucoup plus de l'attitude psychologique des développeurs et des testeurs
que des techniques mises en œuvre.
Cependant, le test reste la technique la plus usitée pour assurer la qualité
d’un logiciel, malgré qu’il soit parfois utilisé d’une manière non
systématique. Aussi devrait-il être potentiellement complémentaire aux
spécifications formelles. Le test est très cher, couvrant 50 % de coût et 50 %
du temps de développement. Le test ne remplace pas réellement la
vérification.
Program testing can be used to show the presence of bugs and not to
show their absencedit Dijkstra. Le test est admis comme une voie pour
augmenter la véracité d’une spécification et est basé parfois sur les
heuristiques non totalement comprises. Tout au long du processus de
développement, on distingue le test d’acceptance, le test d’intégration, le test
d’unité.
Le test d’acceptance concerne la version préliminaire d’un logiciel appelé
 -test, -test, …

Le test d’intégration procède par des tests le long des interfaces et aussi
l’interaction entre les différentes composantes. Le but étant de découvrir si
les préconditions et les sous-composantes sont respectées. Une entrée
(normale) d’un système ne doit pas produire une violation de résultat dans
un comportement (exceptionnel).
Le test d’unité consiste en des tests d’une fonction ou d’un module. Ce but
primordial étant la fixation des cas pour le comportement normal ou
exceptionnel du système.

Omniprésent tout au long du cycle de développement, le test logiciel n'est

pourtant pas toujours correctement mis en oeuvre.

102
 Bien évidemment, il serait aberrant de vouloir réaliser des tests exhaustifs
de toutes les fonctions et méthodes écrites pour une application : on ne va
pas tester une méthode de calcul avec toutes les possibilités connues.
L'attention va surtout se porter sur l'interaction entre les différentes
fonctions, entre les fonctions et l'interface graphique, entre le logiciel et le
système d'exploitation.

Dans tous les cas, le but avoué du test est de découvrir des défauts. Un
test qui n'en trouve pas n'est pas forcément un test réussi.

11.3.1 Différents niveaux de test

Parce qu'il est impossible de créer un test qui puisse effectivement vérifier le
bon fonctionnement de l'ensemble d'une application, le test est divisé en une
série de tests plus spécifiques, chacun faisant appel à une logique
particulière, ou se portant sur un niveau précis de la conception ou de
l'utilisation. Nous allons survoler ici quelques-unes des méthodes les plus
couramment utilisées, en sachant que la description complète de chacun
prendrait plusieurs pages...

Méthodes affirmation/négation : Ces deux types de test sont

complémentaires : le test par affirmation vérifie la conformité de l'application
face aux spécifications, tandis que le but du test par négation est de montrer
que l'application n'agit pas de la bonne manière. Ainsi, le test par affirmation
suit le "mode d'emploi" à la lettre, tandis que celui par négation fait son
possible pour ne pas le suivre, et agir de la manière la moins logique et
prévisible possible.

Méthodes boîte noire/blanche : Pour la boîte noire, les essais tournent autour
du fonctionnement externe du système : les détails d'implémentation des
composants ne sont pas connus (ou sciemment ignorés), et seul le
comportement extérieur est testé. Pour la boîte blanche, à l'inverse, les détails
d'implémentation des composants sont ici tous connus, et le test teste
spécifiquement ces implémentations.

Le test unitaire: Ce test contrôle chaque unité logicielle (le plus petit
composant compilable) : savoir si elle correspond à ses spécifications, s'il y a
des erreurs de logique. Ce test est généralement fait directement par le
développeur de l'unité, qui conçoit lui-même le test en question. Ce test doit
être fait de manière isolée en premier lieu (pour savoir si l’unité fonctionne
comme on le souhaite, tant dans les entrées que dans les sorties), puis en

103
combinaison avec les unités qui travaillent avec elle. C'est typiquement une
technique boîte blanche qui est utilisée ici.

Le test d'intégration: Premier d'une série de tests (il est généralement suivi
par le test système, puis le test d'intégration système), ce test cherche à tester
la stabilité et la cohérence des interfaces et interactions de l'application. Il est
lui aussi réalisé par l'équipe de développement plutôt qu'une équipe
indépendante. Il s'agit ici d'un test de type boîte noire.

Le test système: On teste ici la fiabilité et la performance de l'ensemble du

système, tant au niveau fonctionnel que structurel., plutôt que de ses
composants. On teste aussi la sécurité, les sorties, l'utilisation des ressources
et les performances.

Le test d'intégration système: Ce test vérifie le bon fonctionnement de

l'application à la fois avec les autres applications qui sont susceptibles de
fonctionner en parallèle sur le système, mais aussi son bon fonctionnement
avec les systèmes auxquels l'application pourrait faire appel.

Le test de recette: Ce test doit confirmer que l'application répond d'une

manière attendue aux requêtes qui lui sont envoyées. Ce sont des utilisateurs
lambda qui font ce test, et surtout pas les développeurs eux-mêmes. Ce test
permet d'adapter l'application aux attentes des futurs clients.

Le test de regression: Ce teste fait suite à une modification de l'application

(du fait d'une mise à jour ou de l'aboutissement du test de recette) : il faut
alors vérifier que l'application n'a pas perdu de fonctionnalités lors de l'ajout
de nouvelles fonctionnalités ou la modification de fonctionnalités existantes.

Les outils de tests les plus connus sont JUnit (Java, porté pour .NET, Python,
Perl, Delphi...), JTest (Java), TeamTest et SilkTest.

11.3.2 Automatisation du test

Il existe différents système et techniques et critères de test. Par exemple au
lieu de s’interroger sur comment obtenir un ensemble de tests il faut
demander comment obtenir le bon ensemble de test et surtout quand a-t-on
testé assez. Pour les critères, l’on distingue le test structurel (structural
testing : coverage of a particular part of a structure of a program or a
specification) du test fonctionnel qui se subdivise en deux parties : le test basé
sur les fautes (fault-based testing, focus on detecting faults of programs) et le
test basé sur les erreurs (error based testing, focus on errors produced by
programs).

104
11.4 Couverture de code
L’analyse de couverture de code est un processus pour retrouver des domaines
de programmes non couverts par des cas de tests, pour créer des cas de test
additionnels pour augmenter la couverture et pour déterminer la mesure
quantitative de couverture qui est une mesure de qualité.
Un aspect optionnel de l’analyse de couverture de code est l’identification
des cas de tests qui n’augmente pas la couverture. Un analyseur de
couverture automatise ce processus. Il faut bien comprendre, la couverture
de code augmente la qualité des cas de test mais pas la qualité du produit.
L’analyse de la couverture de code est une technique de test structurel
(glass box testing and white box testing) qui compare le comportement du
programme en situation du test avec l’intention apparente du code. Ceci est
en opposition au test fonctionnel (black-box testing) qui compare le
comportement du programme à une spécification. Le test structurel examine
comment le programme « marche » en tenant compte des erreurs dans la
structure et la logique, alors que le test fonctionnel s’intérresse à ce que le
programme accomplit sans savoir comment il le fait à l’intérieur.
Le test structurel est aussi appelé test de chemin puisque l’on choisit des
cas de tests qui font suivre différents chemins. Le test structurel ne peut pas
trouver des erreurs d’omission.
Il existe plusieurs mesures de couverture. La première est la mesure de
couverture d’instructions qui répond à la question de savoir si chaque
instruction exécutable a été rencontrée une fois. La couverture des décisions
s’interroge si les expressions booléennes testées dans les structures de
contrôle conduisent à vrai et faux. L’expression booléenne entière est
considérée comme un prédicat livrant true ou false sans savoir s’il contient
des opérateurs or ou and. En plus, cette mesure inclut les instructions de
switch, les exception handlers, and interrupt handlers. La couverture des
conditions tient compte des résultats false ou true de chaque sous-expression
booléenne. Elle est similaire à la couverture des décisions mais est plus
sensible au contrôle de flux.

La couverture de chemin rapporte si chaque chemin possible dans chaque

fonction a été suivi. Un chemin est une séquence unique de branches à partir
de l’entrée de la fonction jusqu’à la sortie. La couverture de chemin a
l’avantage d’exiger un test très serré. La couverture des fonctions, la
couverture des appels, la couverture des flux de données, la couverture des
loops etc. sont des aspects spécificiques de ces techniques.

105
 Chaque projet choisit un certain pourcentage minimum de couverture
avant la première publication pour prévenir les défaillances post-publication.
Les objectifs généraux avant publication sont fixés comme suit :
 Appeler au moins une fonction dans 90% des fichiers sources (ou classes).
 Appeler 90% des fonctions
 Atteindre 90% de couvetrure de condition/décision dans chaque fonction
 Atteindre 100% de couverture de décision/condition.

Dans ce sens, la validation et le test de logiciel sont une activité difficile

mais nécessaire pour créer la confiance du client/utilisateur dans le produit.

106
Exercices d’application

107
Questions de cours

Exercice 1 : Développer une liste de 20 à 30 qualités du logiciel.

Ranger ces attributs d’une manière hiérarchique c’est-à-dire décrire les attributs de niveau
élevé par les attributs les plus fondamentaux. Par exemple la maintenabilité peut se
décrire en termes de modularité, de clarté, de la documentation etc.
Procéder à une définition concise de chaque attribut
Quels sont les critères utilisés pour la classification des attributs en classe de « niveau
élévé » et d’autres de « niveau bas ».
Exercice 2 : Ajuster la liste des attributs à un projet spécifique en les triant par ordre
d’importance
Exercice 3a : Donner les besoins (requirements) pour un projet de logiciel quelconque
Exercice 3b : Examiner ce document sur la présence ou l’absence de besoins vérifiables
(verifiable requirements). Les méthodes utilisées pour la vérification sont-elles adéquates ?
Sélectionner quelques définitions des besoins et définir de meilleures méthodes pour les
vérifier. Identifier des exigences qui sont imprécises et ambiguës. Reformuler ces
exigences ambiguës dans des termes vérifiables et spécifier la technique de vérification.
Exercice 4 : Donner sous forme d’un tableau les différentes étapes pour la planification
d’un projet de développement d’un logiciel
Exercice 5 : Quels sont quatre buts qualificatifs et quantitatifs se rapportant au processus
de développement et au produit ?
Exercice 6 : Expliquer les attributs qualité suivants : portabilité, fiabilité, erreur,
robustesse, correction.
Exercice 7 : Décomposer les attributs qualité en termes de caractéristiques du code-source
Exercice 8 : Quels sont les types de structures de communication existant dans un projet ?
Donner les avantages et les inconvénients.
Exercice 9 : Donner le cycle de vie d’un produit logiciel
Exercice 10 : Expliquer en quelques mots les qualités suivantes d’un document contenant
le plan des besoins : correct, complet, consistant, non ambigu, fonctionnel, vérifiable,
traçable, facilement changeable.
Exercice 11 : Qu’est-ce que l’état d’un système ? Qu’est-ce que son comportement ?
Exercice 12 :. Nommer quelques méthodes formelles pour la spécification d’un problème.
Dire en quoi elles sont importantes.
Exercice 13 : Sur quoi les notations relationnelles sont-elles basées ? Donner quatre
notations relationnelles. Donner des exemples.
Exercice 14 : Donner quatre notations orientées état.
Exercice 15 : Nommer quelques techniques de structuration automatique utilisées dans la
phase de définition des besoins.
Exercice 16 : Utiliser la définition récursive des nombres de Fibonacci à savoir F(0) = 1, F(1)
= 1, F(N) = F(N-1) + F(N-2), pour tout N > 1 pour calculer F(5).
Définir une routine itérative pour calculer F(N). Présenter des arguments convaincants
pour expliquer que cette version correspond à la définition récursive.
Exercice 17 : Une définition récursive pour l’évaluation des polynômes de la forme
P(N, A, x) = A(0)*x**N + A(1) * x**(N-1) + …+ A(N-1) * x + A(N)
est donnée par
P(0, A, x) = A(0)
P(J, A, x) = x * P(J-1, A, x) + A(J), 1 <= J <= N
108
Ecrire une procédure récursive pour évaluer les polynômes basée sur la spécification
récursive. Ecrire une procédure itérative pour évaluer les polynômes basée sur la
spécification récursive.
Présenter des arguments convaincants pour prouver que les deux procédures satisfont la
spécification récursive. Comparer la clarté, l’utilisation de la mémoire et le temps
d’exécution des deux procédures
Exercice 18 : Etant donnée la spécification algébrique suivante
syntaxe
new : () -> Queue
add : (Queue, Item) -> Queue
front :Queue -> Item
remove : Queue -> Queue
empty : Queue -> Boolean
Axioms
1. empty (new) = true
2. empty(add(que, itm)) = false
3. front (new) = error
4. remove (new) = error
5. front (add(que, itm)) = if empty que them itm else front (que)
6. remove (add (que, itm)) = if empty (que) then new else add(remove (que), itm)
Donner une specification en français de cette spécification
Ajouter un opérateur de file, size, qui prend en entrée une file et retourne le nombre
d’éléments de la file.
a. Donner la syntaxe de size
b. Donner les axiomes algébriques pour spécifier les interactions avec size.
Exercice 19 : Définir le principe secret (information hiding). Qui en est l’inventeur ?
Exercice 20 : Expliquer stepwise refinement. Qui en est l’inventeur ?
Exercice 21 : Utiliser la méthode de raffinement par étape (stepwise refinement) pour
calculer les n premiers nombres premiers.
Exercice 22 : Définir logiciel, développeur, programmeur, produit, code-source.
Exercice 23 :. Comment juger ou évaluer un procédé de développement d’un logiciel ?
Exercice 24 : Qu’est-ce que le « Code-and-Fix » ? Donner ses avantages et ses
inconvénients.
Exercice 25 : Donner les avantages et inconvénients d’une structuration souple et ceux
d’une structuration rigide.
Exercice 26 : Quels sont les bons attributs dans un modèle de développement de logiciel ?
Exercice 27 : Qu’est-ce qu’un cahier de charges ?
Exercice 28 : Quels sont les buts de la phase de définition et d’analyse ?
Exercice 29 : Donner les destinataires possibles pendant la phase d’analyse
Exercice 30 : Faites une étude comparative des Standards ANSI/IEEE et le Standard du
Modèle V.
Exercice 31 : Définir génie logiciel
Exercice 32 : Peut-on parler des sciences de l’ingénieur pour le génie logiciel ? Discuter à
partir d’une étude comparée avec une discipline d’ingénieur bien maîtrisée.
Exercice 33 : Qu’est-ce que la crise du logiciel ? Quand est-elle apparue ? Donner les
conditions de sa naissance.
Exercice 34 : Selon quels concepts peut-on valider les besoins ?

109
Exercice 35 : En quoi le développement des prototypes est-il important dans le génie
logiciel ?
Exercice 36 : Définir le versionnage
Exercice 37 : Donner des exemples concrets pour les notions de bases de branches, copies
de travail, repository, résolution de conflit, en rapport avec le versionnage
Exercice 38 : Donner les avantages de la gestion de la configuration (configuration
management) par rapport à la gestion des versions (version management).
Exercice 39 : Traduire les expressions mathématiques suivantes en anglais (français) de
telle manière qu’elles soient les plus naturelles possibles.
 p. person 
 n :person  n is a neighbour of p  p never speaks to n
 p:person 
 p. person 
 t:person   n = t   n lives with t  p knows t
 co:country 
 ci:city  ci in co 
the population of ci is greater than that of the capital of co
Exercice 40 : Evaluer {i :N ; j :N| (j = 2*i)  i+j}
Exercice 41 : Assume the definition of two relations involving the sets People, Instruments
and Actions as follows :
plays == {Ashkenay  piano, Williams guitar, David violin, Huw trumpet,
Alice flute, Alice piano, Kate piano}
worksby =={piano hammering, guitar plucking, harpsichord plucking, trumpet
bowing, flute blowing, violin  bowing, violin scraping}
What are the domain and range of plays and worksby?
What are the types of the domain and range of plays and of worksby?
Exercice 42 : The relation pairsum relates pairs of integers to their sum. What is the type
of pairsum? Give a definition for pairsum
Exercice 43 : Définir validation. Donner les différentes méthodes pour la validation d’un
logiciel. Faire une étude comparative.
Donner la différence entre le test structurel, le test basé sur les fautes et celui basé sur les
erreurs. Donner une définition du test d’acceptance, le test d’intégration et le test d’unité.
Exercice 44 : Quels sont les critères de qualité pour un logiciel ? Qu’appelle-t-on mesures
de qualité ?
Exercice 45 : Faire la différence entre mesures constructives et mesures analytiques pour
l’assurance qualité du logiciel. Citer quelques exemples de chacune de ces mesures.
Exercice 46 : Quelles sont les tâches essentielles de la gestion d’un projet ? Quand dit-on
qu’un projet de développement d’un logiciel est initialisé ?
Exercice 47 : Qui est l’inventeur de la modélisation E/R ? Quels sont les éléments
cardinaux du E/R ? Donner leur syntaxe et leur sémantique. Quel est le but ultime de cette
technique ?
Exercice 48 : Donner la signification des abréviations suivantes : E/A, DFD, OOA, OOD,
UML, CASE, VDM, SA, SD, OMT
Exercice 49 : Qu’est-ce que c’est que le diagramme des flux de données ? A quoi cela sert-
il ? Qui en est l’inventeur ? Quels sont ses éléments primordiaux ? Donner leur syntaxe et
leur sémantique.
Exercice 50 : Comment les DFD peuvent-ils être utilisés dans l’architecture d’un système.

110
Exercice 51 : Ressortir les similitudes et les différences entre la modélisation E/R, la
modélisation orientée objet, les DFD.
Exercice 52 : Qu’est-ce qu’une classe ? Qu’est-ce qu’un CRC ?
Exercice 53 : Enoncer la méthode de substantifs pour identifier les classes. L’appliquer à
un système concret , par exemple la gestion d’une bibliothèque.
Exercice 54 : Donner la syntaxe et la sémantique des notions suivantes : association,
généralisation, dépendance, réalisation, utilisation
Exercice 55 : Quelles sont les différentes annotations que peuvent comporter les
associations ? Les nommer et donner leur sémantique.
Exercice 56 : Quel est l’avantage principal des langages de modélisation formels sur ceux
semi-formels ? Quels sont leurs inconvénients ?
Exercice 57 : Pourquoi l’abstraction est-elle importante dans le génie logiciel?
Exercice 58a : Quels sont les fondements théoriques du langage de spécification Z ?
Exercice 58b : Combien de langages existe-t-il dans UML ? A quoi servent-ils ?
Exercice 59 : Quelles sont les trois étapes selon lesquelles les spécifications sont
construites ?
Exercice 60 : Quelles sont les techniques de structuration présentes dans Z ?
Exercice 61 : Quels concepts de structuration sont supportés par les langages suivants
Basic, Fortran, Pascal, C/C++, Java ?
Exercice 62 : Pourquoi dit-on que la modélisation OO est aussi bien une Weltanschauung
qu’une propriété linguistique ?
Exercice 63 : Donner par des exemples concrets comment l’on peut passer des concepts de
modèle suivants au code : les classes simples ; les classes avec attributs ; les classes avec les
opérations ; la généralisation ; les associations ; les associations avec direction et rôle.
Exercice 64 : Donner l’idée fondamentale sous-jacente pour la génération automatique de
code à partir de Z

111
 Sujets d’examen
Examen 1
Exercice 1 : Définir quelques mots
Ressortir les similitudes et les différences entre la modélisation E/R, la modélisation orientée objet,
les DFD.
Exercice 2 : La firme Teachware teaches software
Dans le scénario ci-dessous, relier les notions techniques telles produit logiciel, logiciel
d’application, Unité de traitement de données, utilisateurs, équipement technique, système
d’information, système d’application aux expressions décrites dans le texte.
La Firme Teachware organise des séminaires publics et internes avec des formateurs externes.
La Firme se compose d’un directeur, qui s’occupe de la planification et de l’administration des
séminaires, une attachée de direction et d’une secrétaire. Depuis peu, l’on a implanté dans la firme
le logiciel SEMORG. Le directeur planifie et administre les séminaires et les formateurs à partir de
son PC. L’attaché de direction administre les clients et les enregistrements à travers un PC. La
secrétaire ne travaille pas avec le PC, mais s’occupe des participants dans les salles du séminaire.
Elle s’occupe de surcroît de la multiplication des documents relatifs au séminaire. A côté de deux
PC interconnectés, l’entreprise possède un téléphone, un appareil de télécopie conventionnelle et
une connexion de fax par PC ainsi qu’une liaison e-mail. L’on veut gérer l’organisation des
séminaires d’une manière efficace.
 Donner les différentes fonctions que doit remplir le produit final.
 Donner les données à enregistrer par rapport aux séminaires et aux clients.
 Ressortir un diagramme de flux données (DFD) pour ce logiciel.

Examen 2
Exercice 1 :Trouver des points dispersés en route
 Définir et expliquer : cycle de vie , modèle en cascade, crise du logiciel, prototypage
 Donner sous forme de schéma le développement évolutif du logiciel
 Assume the definition of two relations involving the sets People, Instruments and Actions as
follows :
plays == {Ashkenay  piano, Williams guitar, David violin, Huw trumpet, Alice 
flute, Alice  piano, Kate piano}
worksby == {piano  hammering, guitar  plucking, harpsichord  plucking, trumpet 
blowing, flute  blowing, violin  blowing, violin  scraping}
1. What are the domain and range of plays and worksby?
2. What are the types of the domain and range of plays and of worksby?
Exercice 2 : Un dictionnaire dans Z
Un dictionnaire bilingue est constitué de deux listes alphabétiques : une pour les mots d’origine et
l’autre pour les mots étrangers. Le vocabulaire est présenté sous forme de paires.
Anglais Espagnol
action acción
final final
possibilit possibilita
y d
death muerte

L’on suppose qu’il existe deux ensembles Native et Foreign pour désigner les deux alphabets. Tous
les mots respectant les règles orthographiques appartiennent à deux ensembles OrthoNative et
OrthoForeign.
 Donner la définition exacte des 2 ensembles OrthoNative et OrthoForeign

112
  Donner un schéma WellFormedVocabs pour un vocabulaire bien formé.
 Donner le schéma AddPair pour ajouter un nouveau vocabulaire, ToForeign pour rechercher
un mot étranger et ToNative pour retrouver la signification d’un mot étranger.

Exercice 3 : Teach where and getting the Bachelor

La Firme Teachware organise des séminaires publics et internes avec des formateurs externes. La
firme se compose d’un directeur, qui s’occupe de la planification et de l’administration des
séminaires, une attachée de direction et d’une secrétaire. Depuis peu l’on a implanté dans la firme le
logiciel SEMORG. Le directeur planifie et administre les séminaires et les formateurs à partir de
son PC. L’attaché de direction administre les clients et les enregistrements à travers un PC. La
secrétaire ne travaille pas avec le PC, mais s’occupe des participants dans les salles du séminaire.
Elle s’occupe de surcroît de la multiplication des documents relatifs au séminaire. A côté de deux
PC interconnectés, l’entreprise possède un téléphone, un appareil de télécopie conventionnelle et
une connexion de fax par PC ainsi qu’une liaison e-mail. L’on veut gérer l’organisation des
séminaires d’une manière efficace.
 Ressortir un diagramme de flux données (DFD) pour ce logiciel avec les fonctions principales
(administrer les formateurs, administrer les séminaires, lire les données des factures,
enregistrer les virements, administrer les clients) et les mémoires (Base de données des
séminaires et des clients, Base de données des factures).
 Donner un raffinement des fonctions administrer les clients et administrer les séminaires

Examen 3
Exercice 1 : Avoir deux faces pour sauver sa face
Avec les nouveaux blocs pédagogiques qui se construisent, l’Université de Ngaoundéré ne veut plus
tomber dans les pièges des planifications hasardeuses. L’on requiert de vous un système de
planification des enseignements.
1 Vous êtes celui qui donne le marché. Ecrire un document de description du problème. Prendre en
compte particulièrement les situations suivantes : Quelles sont les personnes qui vont utiliser le
système ? Quelles sont les personnes qui devront faire la maintenance du système ? Quelles
fonctionnalités (entrée, sortie) le système devrait avoir ? Dans quel environnement de traitement de
données le système devrait-il être intégré ? Quelles sont les personnes ressources (« experts ») qui
livreraient des informations supplémentaires? Quels sont les critères de réception (les sortes de
tests) le système doit-il remplir ?
2 Vous changez de face et êtes maintenant adjudicataire (celui qui a gagné le marché). Sur la base
du document présenté ci-haut, vous devez produire une ébauche pour la phase de définition et
d’analyse. Le document doit être subdivisé en sections.
3 Donner une modélisation en flux de données pour le système.
Exercice 2 : Sans bibliothèque la licence n’a pas de valeur réelle
The University Library needs a system to better manage its collection. You are known to be the
expert required to solve the problem. The following requirements have been handed over to you.
Give Z schemas to solve the problem. Informally the system is described as follows :
 The library comprises a stock of books and a community of registered readers
 Each copy of a book is assigned a unique copy identifier
 At any time a certain number of copies of books are on loan to readers; the remainder of the
stock is on the shelves of the library and ready for loan
 There is a maximum number of books which any reader may have on loan at any one time
The operations to be defined include the following
 Issue a copy of a book to a registered reader
 A reader returns a book to the library
 Add a copy of a book to a stock
113
  Remove a copy of a book from the stock
 Enquire which books are on loan to a given reader
 Register a new reader
 Cancel a reader’s registration
Exercice 3 :Gérer les innombrables versions des têtes bantous
La crise du logiciel a conduit à plusieurs propositions de solutions, entre autres l’emprunt du mot
génie aux sciences de l’ingénieur, l’invention de la gestion des versions et de la configuration.
Qu’est-ce que la crise du logiciel ? Définir versionnage. Donner les avantages de la gestion de la
configuration (configuration management) par rapport à la gestion des versions (version
management).

Examen 4
Exercice 1 : Se jeter à l’eau pour glaner quelques points
Cet exercice s’occupe du modèle water Fall.
Expliquer les faiblesses d’un modèle water fall pur (sans liaison retour) ?
Discuter de l’intégration du modèle water fall dans le modèle V
Exercice 2 : Reconnaître ses faiblesses quand on évolue
Cet exercice s’occupe du modèle évolutif.
Expliquer les faiblesses d’un modèle évolutif.
Discuter de l’intégration du modèle évolutif dans le modèle V
Exercice 3 : Milestones and Deliverables
Discuter pour les points de repère (milestones ou deliverables) sont importants dans les projets de
logiciel. Esquisser les scenarii dans lesquels un projet échoue.
Exercice 4 : Se documenter pour obtenir sa licence
Discuter pourquoi la documentation est absolument importante dans les projets de logiciels. Estimer
la grandeur de la documentation à produire pour les grands projets de logiciel. Esquisser des
scenarii, dans lequel un projet échoue à cause de la documentation ou des manuels d’utilisation non
appropriés. Comment les outils doivent-ils soutenir la documentation ?
Exercice 5 : Code-Fix
Donner une évaluation succincte du processus « Code-and-Fix » et du modèle water fall à l’aide des
attributs suivants : compréhensibilité, visibilité, robustesse et maintenabilité

Exercice 6: Comme une micro-onde qui prépare le repas

Une micro-onde est une machine qui sert à préparer ou à réchauffer les repas. Elle comportent
plusieurs états et des fonctions. Elle se présente comme suit.
Elle a un bouton « Full Power » pour fixer la puissance maximale, un autre « Half Power » pour la
moitié de cette puissance, un bouton « Timer » pour fixer la durée de cuisson et un autre« Start »
pour commencer l’opération donnée. Au début et à la fin La micro-onde est dans l’état « Idle ».
Quand la portière est ouverte et chaque fois qu’on l’ouvre, toutes les fonctions se désactivent
(« operation disable »). Quand elle est fermée et que le temps a été fixé, alors la cuisson peut
commencer jusqu’à ce que le temps fixé soit atteint. Dès que la cuisson est complète, alors une
cloche résonne et la micro-onde se remet dans un état d’attente (« Idle »).
 Donner tous les états de la micro-onde et leur description
 Donner tous les événements (entrée de données) qui permettent de passer d’un état de la
micro-onde à un autre et leur description
 Donner en un schéma les transitions des états (comment les événements c’est-à-dire les
entrées font passer d’un état à un autre).
 Faire une esquisse de programme en Pascal qui résoudrait ce problème

114
Bibliographie

ABELSON, H.; SUSSMAN, G. J.; SUSSMAN, J.: Structure and interpretation of computer programs, Berlin: Springer,
2. Aufl., 1997
BALZERT, H : Algorithmik und Software-Technik. Anwendungen, Heidelberg: Spektrum Akademischer Verlag, 1999
BALZERT, H., Lehrbuch der Software-Technik, Software-entwicklung, Spektrum, Akademischer Verlag, 1996
BALZERT, H.: Software-Entwicklung, Bd. 1, 1. Aufl., 1996
BALZERT, H: Lehrbuch der Software-Technik, Heidelberg: Spektrum Akademischer Verlag, 1. Aufl., 1996-1998.
BALZERT, H: Lehrbuch Grundlagen der Informatik – Konzepte und Notationen in UML, Java und C++.
BALZERT, H: Software-Management, Software-Qualitätssicherung, Unternehmensmodellierung, Bd. 2
BASIN, D.: Softwaretechnik, Kursnotizen, Freiburg, 2000
BAUER, F. L.; GOOS, G.: Informatik 1 – Eine einführende Übersicht, Berlin: Springer, 4. Aufl., 1991
BEIZER, B., "Software Testing Techniques", 2nd edition, New York: Van Nostrand Reinhold, 1990
BOOCH, G., RUMBAUGH, J. and JACOBSON, I.: The Unified Modeling Language User Guide, Addison-Wesley,
1999.
BOOCH, G.: Object Solutions: Managing the Object-Oriented Project, Addison-Wesley, 1996.
BRES, J. : Ateliers de génie logiciel Réalisés et tendances, Dunod, 1999
BROY, M.; SPANIOL, O. (Hrsg.): VDI-Lexikon Informatik und Kommunikationstechnik, Berlin: Springer, 2. Aufl.,
1999
BUNDESMINISTERIUM DES INNERN (2006.08.02): V-Modell XT. URL http://www.v-modell-xt.de/.
CHILENSKI, J.J. and MILLER, S.P.: "Applicability of Modified Condition/Decision Coverage to Software Testing",
Software Engineering Journal, September 1994, Vol. 9, No. 5, pp.193-200.
DAHME, Ch., HESSE W.: Evolutionäre und kooperative Software-Entwicklung in Informatik-Spektrum 20: 3–4
(1997). Springer-Verlag, 1997.
DATE, C. J.: An Introduction to Database Systems I, Amsterdam: Addison Wesley, 6. Aufl., 1995
DATE, C. J.; DARWEN, H.: A guide to the SQL standard, Reading, Mass.: Addison Wesley Longman, 2. Aufl., 1998a
DAVIS, A. M., Software Requirements Analysis and Specification, Prentice-Hall, Inc., Englewood Cliffs, NJ, 1990.
DENERT, E.: Software-Engineering – Methodische Projektabwicklung, Berlin: Springer, 1992
ECO, U.: Wie man eine wissenschaftliche Abschlußarbeit schreibt – Doktor-, Diplom- und Magisterarbeit in den
Geistes- und Sozialwissenschaften, Stuttgart: Uni-Taschenbücher, 7. Aufl., 1998
ENGESSER, H. et. al (Hrsg.): Duden. Informatik – Ein Sachlexikon für Studium und Praxis, München:
Bibliographisches Institut, 2. Aufl., 1993
FAIRLEY, R., Software Engineering Concepts, McGraw Hill, Singapore, 1985
FORBRIG, P., Objekorientierte Softwareentwicklung mit UML, Fachbuchverlag Leibzig, 2001
GAMMA, E., HELM, R.; JOHNSON, R. and VLISSIDES, J.: Design Patterns. Elements of Reusable Object-Oriented
Software, Addison-Wesley, 1995.
GHEZI / ZAZZAYEI / MANDRIOLI : Fundamentals of Software Engineering , 1998
GOOS, G.: Vorlesungen über Informatik – 1. Grundlagen und funktionales Programmieren, Bd. 1, 2. Aufl., 1997a,
GOOS, G.: Vorlesungen über Informatik, Berlin: Springer, 1997-1999.
GOOS, G.: Vorlesungen über Informatik – 2. Objektorientiertes Programmieren und Algorithmen, Bd. 2, 1. Aufl., 1996,
GOOS, G.: Vorlesungen über Informatik – 2. Objektorientiertes Programmieren und Algorithmen, Bd. 2 2. Aufl., 1999
GOOS, G.: Vorlesungen über Informatik – 3. Berechenbarkeit, formale Sprachen, Spezifikationen, Bd. 3 1997b
GOOS, G.: Vorlesungen über Informatik – 4. Paralleles Rechnen und nicht-analytische Lösungsverfahren, Bd. 4, 1998

115
GUMM, H.-P.; SOMMER, M.: Einführung in die Informatik, Oldenbourg, 1998
HAYES, I. : Case Studies Specification, Prentice Hall, 1988
HOWDEN "Weak Mutation Testing and Completeness of Test Sets", IEEE Trans. Software Eng., Vol.SE-8, No.4, July
1982, pp.371-379. 1982
M. SHAW and D. GARLAN, Software Architecture: Perspectives on an emerging Discipline, Prentice-Hall, Inc.,
Englewood Cliffs, NJ, 1996.
MCCABE, T., "A Software Complexity Measure", IEEE Trans. Software Eng., Vol.2, No.6, December 1976, pp.308-
320.
MEYER, B.: Object oriented software construction, New York: Prentice-Hall, 1988,
MEYER, B.: Objektorientierte Softwareentwicklung, Prentice Hall, Hanser Verlag, 1990
MORELL, L., "A Theory of Fault-Based Testing", IEEE Trans. Software Eng., Vol.16, No.8, August 1990, pp.844-857.
NTAFOS, Simeon,"A Comparison of Some Structural Testing Strategies", IEEE Trans. Software Eng., Vol.14, No.6,
June 1988, pp.868-874.
OESTEREICH, B., Objektorientierte Software Entwicklung, Analyse und Design mit der Unified Modeling Language,
Oldenburg, 1998
PAGE, Six : Software Engeneering, 1998
PAULSON, L. :Software Engineering, Lecture Notes, Cambridge, 1999
PRESSMAN, R. S.: Software Engineering – European Edition, Maidenhead: McGraw-Hill, 3. Aufl., 1994.
PRESSMAN, R.S.: Software Engineering A Practitioner’s Approach, 4ème édition, McGraw Hill, 1997. R. Pooley, P.
Stevens, Using UML. Software Engineering with Objects and Components, Addison, Wesley, 1999.
RECHENBERG, P.: Was ist Informatik? – Eine allgemeinverständliche Einführung, München: Carl Hanser, 3. Aufl.,
2000.
RECHENBERG, P.; POMBERGER, G. (Hrsg.): Informatik-Handbuch, München, Wien: Carl Hanser, 2. Aufl., 1999.
RECHENBERG, P.; POMBERGER, G. (Hrsg.): Informatik-Handbuch, München, Wien: Carl Hanser, 1. Aufl., 1997
ROPER, M., "Software Testing", London, McGraw-Hill Book Company, 1994
SILBERSCHATZ, A.; GALVIN, P. B.: Operating System Concepts, Amsterdam: Addison Wesley, 5. Aufl., 1998.
SILBERSCHATZ, A.; GALVIN, P. B.; GAGNE, G.: Applied Operating System Concepts, Weinheim: Wiley-VCH, 1.
Aufl., 1999.
SOMMERVILLE, I.: Software Engineering, Amsterdam: Addison Wesley, 5. Aufl., 1996.
SPIVEY, J.: The Z notation, Prentice Hall, 1987
SZYPERSKI, C.: Component Software, Addison-Wesley, 1998.
TANENBAUM, A. S.: Computernetzwerke, München: Prentice Hall, 3. Aufl., 1998.
TANENBAUM, A. S.: Modern operating systems, Englewood Cliffs, NJ: Prentice Hall, 1992
TANENBAUM, A. S.: Computer networks, München: Prentice Hall, 2. Aufl., 1989
TANENBAUM, A. S.: Moderne Betriebssyteme, München: Carl Hanser, 2. Aufl., 1995
VOSSEN, G.: Datenbankmodelle, Datenbanksprachen und Datenbankmanagementsysteme, München: Oldenbourg R.,
4. Aufl., 2000.
WERNER, D. (Hrsg.): Taschenbuch der Informatik, Leipzig: Fachbuchverlag Leipzig / Hanse, 2. Aufl., 1995
WILHELM, R.: Informatik, Grundlagen, Anwendungen, Perspektiven, CH Beck, Stuttgart, 1996.

116
Index
A
Abstract Data Types 16
abstraction 18
ADA 15
ALGOL 15
analyse et définition des besoins 31
association 69
B
Birthday Book 73
BirthdayBook 81
bogue 101
bug 101
C
cahier de charges 33
carte CRC 68
cas d'utilisation 60
classe 58, 65, 86
COBOL 14
code 85
code and fix 20
code-source 7
compatibilité 10
configuration 49
correction 9
couverture de code 105
crise du logiciel 6
cycle de vie 20
D
Data Flow Diagram 36, 56
défaillance 101
défaut 101
définition des besoins 54
développement évolutif 23
développeur 7
diagramme de classe 65
documentation 7
E
erreur 101
évaluation 29
explorative prototyping 24
export 85
extensibilité 10
F
facteurs de production 8
FORTRAN 15
G
génération automatique e code 88
génie logiciel 6, 17
gestion des versions 43
GUI 93
H
héritage 87
I
import 85
inspection 100
interface 86
interface graphique 93
interface homme machine 94
L
langage formel 71
LOC 9
logiciel 7, 16
lois de Lehmann 44
M
MERISE 27
117
méthodes formelles 17
modèle 54
modèle de développement 21
modèle E/R 55
modèle en cascade 22
modèle en spirale 25
Modèle V 27
modélisation 18
modélisation des données 76
modélisation orientée objet 59, 65
module 32, 86
N
niveau de test 103
O
orienté objet 86
P
panne 101
polymorphisme 87
processus de développement 21
programmation 5
programmeur 7
Q
qualité 12
queens 83
R
raffinement 57, 81, 90
rapid prototyping 24
réutilisation 10
robustesse 9
S
schéma 77
software engineering 6, 16
structuration 18, 86
T
test 101
test d'acceptance 102
test d'intégration 102
test d'unité 102
test de recette 104
test de regression 104
test système 104
U
UML 59
uses 85
V
validation 99
validation des besoins 35
vérification 99
version 43
versionnage 43
W
WIMP 94
Z
Z 71

118