GÉNIE LOGICIEL

ENSEIGNANT:
PROF. DR.-ING. HABIL. KOLYANG/M. NOUNAMO D. P.
UNIVERSITÉ DE MAROUA
ECOLE NATIONALE SUPÉRIEURE POLYTECHNIQUE
ANNÉE ACADÉMIQUE 2018-2019
Informations générales
 Types de cours

 Cours magistral
 Travaux dirigés
 Travaux pratiques
 Travail Personnel de l'Etudiant

 Organisation des évaluations

 Contrôle continu+Travaux dirigés = Contrôle continu final

 Travaux pratiques
 Travail Personnel de l'Etudiant
 Examen
 Rattrapage
Objectifs
A la fin de ce cours, l’étudiant sera capable :

 D’assimiler le cycle de vie des logiciels

 Apprendre les modèles de processus de

développement du logiciel

 L'importance des phases de définition des besoins

 L'importance des phases de spécification et de

vérification.
 PLAN DU COURS
Introduction générale
Historique sur le développement du logiciel
Introduction à la qualité logicielle
Notion de cycle de vie des logiciels
Chapitre 1: Notion de processus de développement des
logiciels

A)Choix du modèles du développement des logiciels (Les

catégories de modélisation)
B) Analyse et définition des besoins
C)Modélisation avec les méthodes semi-formelles (Introduction à
UML)
D)Modélisation formelle avec Z
E)Des modèles aux codes
Introduction générale
Introduction générale
Le Génie logiciel (‘Software Engineering’ en anglais), GL, est un domaine
des ‘sciences de l’ingénieur’dont la finalité est
la conception,
la fabrication
et la maintenance de systèmes logiciels complexes, sûrs et de qualité.

Cependant, 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.

Le présent cours n'a pas pour objectif de développer les théories et les
outils pour permettre de construire des logiciels qui répondent à un
standard. Il discute des méthodes de « fabrication et de conception
systématique de logiciels ».
Introduction générale
 Au centre des procédés d’étude et de réalisation des SI se trouve la
programmation.

 La programmation est la description d’un calcul de manière à

l’exécuter sur une machine.
 programmation in-the-small :
 écriture de code pour résoudre des tâches claires et précises

 programmation in-the-large :
 couler ensemble de larges modules pour résoudre des tâches
probablement mal définies.
 C’est l’une des principales tâches du software engineering, le génie
logiciel.
Brève historique
Le terme ‘génie logiciel’ a été introduit pour la première fois en 1968
lors d’une conférence internationale consacrée à des discussions sur
la ‘crise du logiciel’.
Un symptôme de cette crise :
Le coût du logiciel dépassait le coût du matériel.
La non qualité des systèmes produits.
Les risques humains et économiques sont importants

- Mission VENUS : passage à 500000 km au lieu de 5000 km

à cause du remplacement d’une virgule par un point,
- Avion C17 de McDonnell Douglas livré avec un
dépassement de 500 millions de $ ... (19
calculateurs hétérogènes et 6 langages de
programmation différents),
- Mauvais pilote automatique de la commande d’une bombe
au cobalt en milieu hospitalier : 6 morts,
- Echec d’Ariane 5 (mauvaise réutilisation du logiciel de
 Brève historique
Le journal « Le Monde » publie le 23/10/01 :
D’après le cabinet de conseil en technologies de l’information
Standish Group International, les pannes causées par des
problèmes de logiciel ont coûté l’an dernier aux entreprises du
monde entier environ 175 milliards de dollars, soit deux fois
plus au moins qu’il y a 2 ans.

La solution imaginée pour répondre à cette crise à été

l’industrialisation de la production du logiciel : organisation des
procédés de production (cycle de vie, méthodes, notations, outils), des
équipes de développement, plan qualité rigoureux, etc.

MAIS

le GL reste aujourd’hui moins avancé et moins bien codifié que

d’autres ‘sciences de l’ingénieur’
Brève historique
•le logiciel est un objet immatériel, très malléable au sens de facile à
modifier,
• ses caractéristiques attendues sont difficiles à figer au départ et
souvent remises en cause en cours de développement,
• les défaillances et erreurs ne proviennent ni de défauts dans les
matériaux ni de phénomènes d’usure dont on connaît les lois mais
d’erreurs humaines, inhérentes à l’activité de développement,
• le logiciel ne s’use pas, il devient obsolète (par rapport aux
concurrents, par rapport au contexte technique, par rapport aux autres
logiciels...),
• le développement par assemblage de composants est encore
balbutiant dans le domaine logiciel
(beans, EJB, composants CORBA...).
 Définitions
Le GL se définit souvent par opposition à la ‘programmation’,
c’est-à-dire

la fabrication collective d’un système complexe, concrétisée par un

ensemble de documents de conception, de programmes et de jeux de
tests avec souvent de multiples versions, et considérée comme
‘difficile’ par opposition à la production d’un programme par un
individu unique, considérée comme ‘facile’.
 Définitions
 Software engineering : «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 ». Boehm, 1976

 software engineering est : « the systematic approach to the

development, operation, maintenance, and retirement of software »
IEEE

 Software : “computer programs, procedures, rules, and possibly

associated documentation and data pertaining to the operation of a
computer system”.
 Synonyme de code source, produit
 Définitions
 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 sont plus expérimentés que
programmeurs pour bien estimer les domaines du
problème, les buts et objectifs.
- 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.
Les qualités exigées au programmeur
Un bon programmeur doit pouvoir :
 Communiquer les exigences, afin de résoudre le bon problème,
 Analyser les problèmes, les divisant en petites sous-tâches,
 Organiser les solutions, 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
 Utiliser les mathématiques pour arriver à des solutions correctes et
simples.
 Facteurs de production
On distingue deux grands facteurs :
- Ceux liés au développement du logiciel (facteurs de grandeur)
- Ceux liés à la qualité et la productivité.

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.

La maintenance concerne toutes les activités à partir de la publication

initiale du produit.
Elle inclut trois aspects importants :
- L’augmentation des fonctionnalités du produit,
- L’adaptation du produit à son environnement et
- La correction des bogues.
Grandeurs des projetsFacteurs liés au
développement du logiciel ( facteurs de grandeur)
Projets triviaux : 1 seul programmeur, quelques jours ou quelques
semaines, moins de 500 instructions, divisés en 10 à 20 routines.
• Un software personnel.

Petits projets : 1 programmeur, 1 à 6 mois,1000 à 2000 lignes en

paquets de 25 à 50 routines.
• Peu d’interaction avec d’autres programmeurs.

Projets de taille moyenne, 2 à 5 programmeurs, 1 à 2 ans, 10.000 à

20.000 lignes de code groupés en paquets de 250 à 1000 routines.
• interaction entre les programmeurs,
• communication avec les clients.
 Grandeurs des projetsFacteurs liés au
développement du logiciel ( facteurs de grandeur)
grands projets : 5 à 30 programmeurs, 2 à 3 ans, 50.000 à 200.000
LOC, divisées en différents sous-systèmes.
•L’interaction est requise et la communication est obligatoire.
•techniques de base du génie logiciel sont à respecter.

projets très grands. 100 à 1000 programmeurs, de 4 à 5 ans. plus d’un

million d’instructions.
Exemple : le système d’exploitation IBM OS/360 a été développé par
5000 programmeurs.

projets extrêmement grands : 2000 à 5000, jusqu’à 10 ans pour

produire 1 à 10 millions de (LOC).
Facteurs externes et internes

Facteurs externes: se laissent constater par des usagers

Facteurs internes concernent les spécialistes

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.

 Robustesse : Elle est la capacité pour un logiciel de fonctionner dans

des conditions extra-ordinaires.
 Extensibilité : L’extensibilité décrit la facilité avec laquelle le logiciel
peut se laisser adapter à des changements de spécification.

 Ré-utilisation : La ré-utilisation des logiciels est la propriété d’utiliser

des composantes pour de nouvelles applications.

 Compatibilité : Elle est la mesure de la simplicité avec laquelle les

produits logiciels peuvent se laisser combiner avec d’autres.

 Autres qualités : efficience, portabilité, vérifiabilité, intégrité et

ergonomie.
 Facteurs internes
 Divisibilité modulaire : division d’un problème en sous-tâches,
méthode top-down.

 Combinaison modulaire : la production des éléments de logiciels

peuvent se laisser combiner pour obtenir de nouveaux systèmes plus
grands.

Compréhensibilité modulaire : la construction des modules

compréhensibles par un lecteur humain.

Continuité modulaire : une petite altération dans la spécification du

problème ne cause de changement que dans un ou peu de modules

Protection de module : des erreurs pendant l’exécution ne se limitent qu’à

ce module ou à des modules limitrophes.
principes importants pour la réalisation d’une
modularité adéquate
Les cinq critères sus-discutés conduisent à cinq principes importants
pour la réalisation d’une modularité adéquate.
1. 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é.

1. Nombre réduit 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. La communication
peut-être issue d’un appel de procédures pour le partage des structures de
données.
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.
- Les 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.
- Les 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.
- Le principe secret.
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.
Facteurs de qualités et productivités
capacité individuelle (individual ability),
la communication d’équipe (team communication),
la complexité du produit (product complexity),
une notation appropriée (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),
des qualités de gestion (management skills),
Informatique, science universelle ?

L’informatique est la
machinisation du travail
intellectuel.

 En effet, là où il y a un travail
intellectuel, l’ordinateur peut mieux
faire que l’homme.
 Chapitre 1:

Les modèles du
développement des logiciels
Rappels historiques
 Les anciens projets de développement de logiciel
obéissaient à une méthodologie de développement
dite CODE-AND–FIX.

Les étapes sont :

1) écrire le code (programme),

2) l’améliorer (élimination des fautes, extension de la
fonctionnalité, …) et
3) GOTO 1.
Rappels historiques
 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.

 Sans comprendre le processus de conception, les

programmeurs se mettent à produire des lignes de code.

 A un certain moment, la phase de test commence, alors

les bogues que l’on ne pouvait éviter doivent être trouvés
et résolus avant que le produit ne soit livré.
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.

 Exemple: Unified Modelling Language (UML), Vienna

Development Method (VDM), RAISE, Atelier B, Z, etc.
Les techniques formelles
Avantages
 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.

Inconvénient
 la difficulté de non maîtrise par les non-techniciens.
Thèmes du génie Logiciel
 la structuration du processus de développement (modèle
du processus, outils),
 la construction des modèles,
 la spécification,
 le raffinement,
 l’implémentation et
 la vérification.
Structuration et abstraction
 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.
Structuration
 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étré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.
Interface
 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.
 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 :

 propriétés syntaxiques qui assurent une utilisation correcte de
l’unité fonctionnelle,
 propriétés sémantiques qui documentent le comportement de
l’unité fonctionnelle et un usage correct.
Abstraction et modélisation
 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.

 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 besoins, une liberté par rapport aux
algorithmes et structures de données.
Modélisation
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.
Cycle de vie du logiciel : Définition
Traduire un environnement de travail en symboles
cabalistiques n'est pas très habituel pour qui ne connaît pas.
Une once de théorie + deux grammes de pratique = (processus
est très abordable, soumis à quelques règles simples, faciles à
acquérir)

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.
Cycle de vie du logiciel : Les exigences
Les exigences posées aux différentes méthodes sont :

 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.
Le processus du développement
 Processus du développement = 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.
Les modèles de développement
La présentation des activités ci-dessus citées diffère d’un
modèle à un autre.

But du modèle : obtenir des processus de développement

rationnels, reproductibles et contrôlables
 Les modèles de développement :
Le modèle en cascade ou 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)
 Les modèles de développement :
Le modèle en cascade ou modèle de phases
 Les modèles de développement :
Le modèle en cascade ou modèle de phases
 L’avantage de ce modèle réside dans sa haute visibilité

 Les documents produits à chaque phase sont :

 Les modèles de développement :
Le modèle en cascade ou modèle de phases
 Problèmes :
 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).

 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.
 Les modèles de développement :
Le modèle en cascade ou modèle de phases
 Il existe un affaiblissement du modèle en cascade par
liaison retour.

 Problème: Problème de la fréquence itérative.

 Solution : Pour résoudre ce problème, la nécessité des
check point se fait sentir.
 Les modèles de développement :
Le modèle évolutif ( à incréments)
Idée principale : Développer un prototype (échantillon primaire,
système développé comme modèle de test) avec l’aide du client et de
l’améliorer continuellement.
 Les modèles de développement :
Le modèle évolutif ( à incréments)

 Ce modèle existe au moins sous trois variantes :

 la programmation explorative,

 le prototype rapide,

 le prototypage évolutif et participatif.

 Les modèles de développement :
Le modèle évolutif ( à incréments)
 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.

 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).

La finalité n’est pas un système complet. Il s’agit d’un prototypage

expérimental.
 Les modèles de développement :
Le modèle évolutif ( à incréments)
 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 l’on permet aux usagers et aux
développeurs d’identifier très tôt les déficiences 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
 Les modèles de développement :
Le modèle évolutif ( à incréments)
 Inconvénients
 La non visibilité car il est difficile de mesurer le progrès,
 La mauvaise structuration car il est basé sur les changements
continuels
 La nécessité d’un savoir profond.

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).
 Les modèles de développement :
Le modèle en spirale
 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.

 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.
 Il est plus adapté aux projets innovants, à risques et dont les
enjeux sont importants.
 Chaque tour du spirale se subdivise en 4 phases principales.
 Les modèles de développement :
Le modèle en spirale
Evaluer éventuellement un prototypage
à partir des résultats du cycle précédent
L'analyse des risques peut également être
et pour le premier à partir d'une analyse
introduite dans les modèles classiques, en
préliminaire des besoins
cascade ou en V.

De la solution retenue
 Les modèles de développement :
Le modèle en spirale
 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.
 Les modèles de développement :
Les 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.
 Les modèles de développement :
Les modèles spécifiques
 MERISE consiste à concevoir

 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.
 Les modèles de développement :
Les modèles spécifiques
Le modèle V
 Il est introduit en 1997. La version actuelle est designée de
V-Modell XT (depuis février 2005). Au début, il
correspondait à une variante du modèle en cascade.
 Il 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? »

 Les modèles de développement :
Les modèles spécifiques
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.
Les modèles de développement :
Les modèles spécifiques
 Les modèles de développement :
Les modèles spécifiques
 Le modèle V qui est devenu un standard ISO est utilisé aujourd’hui chez les
militaires et dans d’autres grands projets.
 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.

 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
importants. Cette phase durant environ 15 pourcents du temps total du cycle
de vie se termine par la production d'un code source.
 Les modèles de développement :
Les modèles spécifiques
 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.
 Les modèles de développement :
Les modèles spécifiques
 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.
 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 ?
 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 ?
 Evaluation des procédés
 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 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.
Chapitre 4: Gestions des versions
et des configurations
Chapitre 5: Gestions des versions
et des configurations
Historique
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 :
Historique
Historique du Logiciel

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.
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.
5.1. Lois de Lehman

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.
 5.1. Lois de Lehman

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
consisterait à alterner les évolutions qui corrigent des fautes et celles qui
modifient les fonctionnalités ou le comportement du système.
 5.1. Lois de Lehman
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.
 5.1. Lois de Lehman
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.
 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:
Quand doit-on créer une nouvelle évolution et non une nouvelle version?
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, ...?
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.
5.2 Identification des versions

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

5.2 Identification 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 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.
5.2 Identification des versions

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.
 5.3 Notions de base du versionnage

À 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 n’est utile que si les conflits

sont déterminés et des solutions proposées. Ils peuvent être résolus
par blocage de ressources (ressource locking) ou par mélange
(merge).
 5.3 Notions de base du versionnage

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.
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.
 5.4. La gestion de la configuration
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.
 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.
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.
1. La double maintenance : Il faut minimiser les duplications car,
inévitablement, les copies multiples divergent ; l'augmentation du coût est
inéluctable.
 5.5 Nature des changements
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 :
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
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 réel danger : les erreurs de
Programmeur#1 peuvent bloquer Programmeur#2 ; le retard est inéluctable.
3. Les mises à jour simultanées
Programmeur # 1 crée une copie du programme C dans son environnement de travail (E1) à
un temps T1. Le programmeur 2 fait la même chose dans un environnement E2 à un temps
T2. Ensuite, il réécrit le programme modifié dans C à un temps T3. Le programmeur P1 fait la
même chose en un temps T4. 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.

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.
 5.5 Nature des changements
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 :
 5.5 Nature des changements
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.
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.
 Chapitre 6 :
Modélisation avec les méthodes
semi-formelles
 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…
 6.1. Définition

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, …
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.
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 :

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.
Exemple : Gestion d’une petite bibliothèque
6.3 Diagramme de flux de données
 6.3 Diagramme de flux de données

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
 6.3 Diagramme de flux de données

Ce raffinement décrit comment un livre est sélectionné mais il n’est pas encore
précis. Le titre et le nom de l’utilisateur sont–ils véritablement nécessaires ? De
surcroît, la sémantique n’est mentionnée qu’à travers les noms des fonctions. Les
aspects 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 DFD
hiérarchiques et ils livrent une structure de modules. La procédure M appelle soit
M1 une fois soit M2 plusieurs fois. M2 transmet B à M1 et en reçoit A et M reçoit C
de M2. L’architecture résultante du module commande de livre est la suivante :
 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
 6.4 Les modèles de classe

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

propriétés communes et les méthodes.
 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
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.
6.6 Une introduction à UML
 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 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.
 6.7 Cas d’utilisation

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.
 6.7 Cas d’utilisation
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.
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
 6.7 Cas d’utilisation
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.

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.
 6.7 Cas d’utilisation
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 ...
 6.7 Cas d’utilisation

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
• 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
6.7 Cas d’utilisation

Exemple de scénario
 Chapitre 7:

La modélisation des classes

 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
Les diagrammes des classes
 Les diagrammes des classes
 Les diagrammes de classes sont utilisés dans leur
fondement conceptuel sans rapport direct avec
l’implantation.

 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.
 Les classes
 Une classe décrit un ensemble d’objets (les choses palpables du monde
réel)avec des rôles équivalents dans un système.

Dans sa forme visuelle, une classe est représentée par un

carré avec ou sans attributs et des opérations.

 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.
 L‘identification des classes
 Un modèle de classes est bon quand les objets remplissent les
exigences requises.

 Les classes présente les objets persistants du domaine =

Augmenter la maintenabilité et la réutilisation

 Comment peut-on construire une classe ?

1) Une première possibilité est une inspiration divine.
2) La deuxième est basée sur une conception orientée donnée
(data driven design) : Il faut identifier toutes les données du
système et les diviser en classe et ensuite réfléchir aux
opérations.
3) La troisième méthode concerne une conception orientée
responsabilités avant de retrouver les données.
 L‘identification des classes :
les méthodes
 Méthode 1 : Classes comme substantifs : Cette méthode
comporte deux étapes pour l’identification des classes.

 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
 L‘identification des classes :
les méthodes
 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 .
 L‘identification des classes :
les méthodes

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

 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
 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 *
 Les associations
 Navigabilité (direction): une flèche montre la direction de
la relation.

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.

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

 Les associations
 Direction nomminelle : elle décrit dans quelle direction quel
nom doit être lu.

 Agrégation : rapport d’un tout à une partie. 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.

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

Un exemple de modélisation d‘une
faculté.
 Chapitre 8:

Modélisation formelle avec Z

 Introduction
 Les différences essentielles entre les langages de
modélisation sont la vue du système, le niveau
d’abstraction et le degré de formalisme.

 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.
 Z
 Le langage Z proposé par Jean Raymond Abrial dans les
années 50 possède une grande force d’expression 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.
 Z est utilisé d’une manière très efficace depuis les années
1989 au Oxford University Computing Laboratory où il est
né
 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.
 Z
 Un modèle mathématique qui représente le comportement d’un
programme peut être utilisé comme une spécification formelle.
 Question : À quoi sert une spécification si on peut écrire
facilement un programme pour ne pas l’implémenter
directement ?
 Réponse : Un programme peut être crypté. Aussi l’on a besoin
d’une spécification qui représente le niveau d’abstraction
appropriée.
 Z
Que fait le programme suivant ?

Ce programme est efficace, court et bien structuré.

 int_root calcule simplement l’« integer root » de son entrée a.
MAIS!

Que se passe t-il dans le cas où a=0 ou a=-3 ?

 Z

 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 : la compréhension d’un code

(programme) est à séparer de sa fonctionnalité.
 Solution : Elle réside dans une spécification.
 Spécifier = formaliser ce que doit faire le système sans fixer
comment.
 Z
 Spécifions int-root à l’aide d’une description
axiomatique.
 Z
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.

 Les spécifications structurées de Z se construisent en

étapes.
 Z
 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.

 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.
 Z
 Exemple d’ensemble d’états :
known = Susy, Mike, John
birthday = John 25 March ; Susy 20 décembre, Mike 20 décembre}
Invariante : known = dom Birthday

 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
 Z
 La convention de Z est de décorer les entrées avec un
point d’interrogation et les sorties avec un pont
d’exclamation

 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.
 Z
 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.

 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.
 Z

Ce schéma laisse l’état du système inchangé ( : le symbole d’importation).

Le schéma précédent est équivalent à celui-ci-contre :

 Z
 Opération 2 : Retrouver la liste de toutes les personnes qui ont leur
anniversaire à une date donnée. cards ! est l’ensemble des noms
auxquels les cartes de voeux sont envoyées.
 Z
 La spécification décrit ce que fait le système sans préciser
comment.
 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).

 Outils et systèmes supportant Z:

 Confére
 http ://archive.comlab.ox.ac.uk/z.html.
 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.
 Modélisation des données avec Z et les diagrammes ER
 Les diagrammes E/R peuvent être traduits dans les spécifications Z
 ETAPES:
 D’abord les entités de bases, ensuite les entités d’agrégat, et
enfin les relations sont traduites pas à pas l’entité de base correspond au
schéma Z avec les contraintes
explicites suivantes
Modélisation des données avec Z et les diagrammes ER
Les Entités agrégats Les Relations
Modélisation des données avec Z et les diagrammes ER

 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

Modélisation des données avec Z et les diagrammes ER
 Enfin, il faut parfois procéder à des transformations avant
de réaliser une implémentation plus facile ou plus
commode. On a donc

 Cette transformation montre que la relation entre les deux

entités est une injection partielle. C’est pourquoi on peut
écrire dans Z
Equivalence et schémas