GÉNIE LOGICIEL

Chapitre 0 : Introduction

Chapitre 1 : Modèles de Cycles de Vie

Chapitre 2 : Analyse et Définition des Besoins

Chapitre 3 : Diagramme des cas d’utilisation

Chapitre 4 : Diagramme des classes & des objets

Chapitre 5 : Conception des Logiciels : Approche O.O

Chapitre 6 : Vue Statique

Chapitre 7 : Vue Dynamique

 INTRODUCTION

1\ Crise du logiciel :
Cette crise est apparue dans les années 60 car les méthodes
de développement de l'époque n'étaient plus en adéquation
avec les logiciels qui devenaient de plus en plus complexes,
pour résumer les projets souffraient de :
- Retards dans les livraisons (parfois des années)
- Surcoûts considérables dépassant largement les budgets
- Produits qui ne répondaient pas aux besoins des utilisateurs
(peu fiables, peu performants, difficiles à maintenir, etc)
- Produits peu sûrs comportant parfois des erreurs pouvant
avoir des répercussions graves sur la mission du système

C’est en cette période (1968) qu’est né le terme Génie logiciel

2\ Définition :
Le Génie Logiciel est une science de l’ingénieur qui vise à
proposer des méthodes d’ingénierie, des techniques, des
langages et des outils pour développer des produits logiciels de
bonne qualité, dans les meilleurs délais, et avec les moindres
coûts possibles

3\ Qualités d'un logiciel :

La qualité logicielle est une appréciation globale basée sur de
nombreux critères, on note 2 types de qualités :
1) Qualités Externes : intéressent le client :
- Validité & Fiabilité
- Ergonomie
- Efficacité & Performances
- Maintenabilité

2) Qualités Internes : Intéressent le développeur :

- Réutilisation
- Adaptabilité
- Maintenabilité
- Conception Modulaire

Validité des Besoins : les tâches sont spécifiées à travers des

cas d’utilisations et pour chaque tâche il doit exister une ou
plusieurs fonctionnalités permettant de l’accomplir, il faut que
l’implémentation de la fonction soit appropriée avec le besoin

Fiabilité : désigne la capacité d’un logiciel à maintenir son

niveau de service dans des conditions précises pendant une
certaine durée, beaucoup de bugs sont le symptôme d’un
manque de fiabilité

Efficacité : c’est l’optimisation rationnelle de la gestion des

ressources, c'est-à-dire avoir le bon ratio entre la quantité de
ressources utilisées (moyens matériels, temps, personnel) et la
quantité de résultats délivrés, par exemples : économie de
mémoire, rapidité d'exécution ...
Ergonomie : c’est la facilité d'utilisation, qui porte sur l'effort
nécessaire pour apprendre à manipuler le logiciel, les logiciels
doivent être intuitives, accessibles et bien documentés

Maintenabilité : c’est la facilité du système à être réparé et

modifié, les logiciels ayant une longue durée de vie, doivent
être conçus et réalisés de façon à minimiser les coûts

Portabilité : c'est l'aptitude d'un logiciel de fonctionner dans

différents environnement matériel ou logiciel, en plus de la
facilité d'installation et de configuration

Remarque : il est difficile d'optimiser tous ces facteurs en

même temps car certains s'excluent mutuellement, il est donc
nécessaire de faire des compromis entre les qualités, par
exemple : une belle interface utilisateur peut réduire l'efficacité,
un système efficace en temps réelle augmente les coûts …

Parmi les qualités citées précédemment, 4 d’entre elles sont

générales (indispensables) :
- Fiabilité
- Efficacité
- Ergonomie
- Maintenabilité
 MODÈLES DE CYCLES DE VIE

1\ Définition :
Le cycle de vie d’un logiciel est constitué de l'ensemble des
étapes successives de la fabrication depuis la commande du
logiciel par le maître d'ouvrage jusqu'à sa mise en exploitation
et lancement de la maintenance. On distingue dans tout cycle
de vie 2 sous cycles internes : le cycle de développement et le
cycle de maintenance

2\ Modèles de cycles de vie :

On distingue 3 classes, chacune se distingue des autres selon
sa logique d’enchaînement des étapes et la participation des
clients au processus de développement :

1) Modèles Linéaires : le système logiciel est développé dans

sa totalité en appliquant les étapes de manière séquentielle. Le
client intervient uniquement au début et à la fin du cycle de
développement

Exemples : Modèles en Cascade et en V

Avantage : ils permettent de développer des logiciels avec un

bon ratio qualité/coût, quand les besoins sont clairs, stables et
faciles à cerner

Inconvénient : les erreurs de définition des besoins sont

détectées tardivement par le client surtout quand les besoins du
client sont ambigus
2) Modèles évolutifs : le projet est réalisé en appliquant
plusieurs cycles de développement, en faisant intervenir le
client pendant au moins un cycle de développement

Exemples : Modèles par prototypage et par incréments

Avantage : les erreurs de définition des besoins sont détectées

par le client pendant les premières étapes de développement,
cela permet de développer des logiciels de bonne qualité,
quand les besoins du client sont ambigus et difficiles à cerner

Inconvénient : ces modèles sont coûteux en termes de délais

et budgets, de plus ils nécessitent un personnel de
développement qualifié afin d’éviter des risques liés

3) Modèles Hybrides : on décompose le grand système en

plusieurs sous-systèmes, en se basant sur l’analyse du risque
on choisit l’approche appropriée pour chaque sous-système :
- Pour les sous-systèmes ayant des spécifications à hauts
risques : utilisation du prototypage
- Pour les parties bien connues qui ont des besoins stables et
clairs : Modèle linéaire

Avantage : les produits logiciels sont souvent de meilleure

qualité, c’est la meilleure solution pour les grands systèmes

Inconvénient : le coût reste toujours très élevé, le contrôle et

l’intégration des changements sont souvent plus difficiles
3\ Modèle en V :
Dans ce modèle, les premières étapes du développement du
logiciel doivent préparer pour les étapes finales, les données
liées aux activités de validation et de vérification

4\ Maquettage & Prototypage :

On détermine d'abord un ensemble minimum de fonctions elles-
mêmes incomplètes de façon à réaliser rapidement un premier
incrément du logiciel dont on se sert pour analyser son
fonctionnement, l'utilisateur fournit en retour des informations
au concepteur qui modifie le prototype, ce processus
d'évolution de prototypes continue jusqu'à ce que l'utilisateur
soit satisfait du système livré

Prototype jetable / non jetable : quelqu’un qui utilise cette

méthode doit toujours se poser cette question : faut-il garder et
faire évoluer le prototype ou bien le jeter et développer le
logiciel en se basant sur le cahier des charges corrigé ?
La réponse dépend en grande partie de la maintenabilité du
prototype (facilité de le corriger et de le faire évoluer) Les
contraintes de délai et de budget rentrent aussi en compte

5\ Modèle par incréments :

Un seul sous ensemble des composants d’un système est
développé à la fois, un noyau est tout d’abord développé, puis
des incréments sont successivement développés et intégrés

Avantages :
- Chaque développement est moins complexe
- Les intégrations sont progressives
- Il peut y avoir des livraisons et des mises en services après
chaque intégration d’incrément
- Il permet de bien répartir le temps, l’effort de développement
et les effectifs par rapport aux modèles en cascade et en V

Risques :
- Le mauvais choix du noyau
- La mauvaise décomposition du système en incréments
- La mauvaise définition des interfaces entre incréments

6\ Modèle en Spirale :
Chacune des activités de développement est réalisée en
suivant un cycle multi-étape où les objectifs et les contraintes
ainsi que les alternatives doivent être énumérés et précisés au
départ, ensuite chaque alternative subit une série d’examens
et d’analyses de risque en faisant appel à la technique du
prototypage et ce afin de choisir la solution optimale

Chaque cycle de la spirale se déroule en 4 phases :

1) Détermination des objectifs du cycle, des alternatives pour
les atteindre et des contraintes
2) Analyse des risques, évaluation des alternatives et
éventuellement maquettage
3) Développement et vérification de la solution retenue
4) Revue des résultats et planification du cycle suivant
 ANALYSE & DÉFINITION DES BESOINS

1\ Définition :
Les problèmes soumis aux ingénieurs logiciels sont souvent
d’une complexité extrême, il est donc important de préciser en
détails les besoins exprimés par l’utilisateur.
L’analyse et définition des besoins est un processus visant à
établir quelles fonctionnalités le système doit fournir et les
contraintes auxquelles il sera soumis, c’est la première grande
étape du cycle de vie d’un logiciel

2\ Cahier des charges :

Le résultat de l’analyse & définition des besoins est le cahier
des charges, il doit décrire le futur système logiciel que l’on veut
bâtir de manière précise et complète tout en éliminant les
informations non pertinentes, superflue ou incomplète. Ce n’est
pas un document de conception, il doit juste décrire ce que le
système doit faire sans spécifier comment il doit le faire

Critères du cahier des charges :

- spécifier uniquement le comportement externe du système
- spécifier les contraintes de réalisation
- doit être facile à mettre à jour
- servir d’outil de référence aux programmeurs de maintenance
- contenir des indications concernant les étapes ultérieures du
cycle de vie du système
- spécifier les réponses acceptables aux événements non
désirables
3\ Structure d’un cahier des charges :

1) Introduction : décrit la raison d’être d’un tel système et place

celui-ci dans son contexte, donne brièvement ses fonctions,
précise la structure du document …

2) Matériel : définit le matériel utilisé par le système

3) Modèle conceptuel : définit une vue à très haut niveau des

fonctions majeures et de leurs relations, décrit par une notation
graphique

4) Besoins fonctionnels : décrit les services fournis à l’utilisateur

5) Les besoins en matière de base de données : décrit

l’organisation logique des données manipulées par le système
et leurs relations

6) Besoins non fonctionnels : décrit les contraintes sous

lesquelles le logiciel doit opérer, et les relier aux besoins
fonctionnels, par exemple : contraintes de temps, espace
mémoire, représentation des données, langage de
programmation …

7) Information destinée à la maintenance : décrit les hypothèses

fondamentales sur lesquelles le système est fondé ainsi que les
changements prévus du fait de l’évolution du matériel, des
besoins des utilisateurs …
8) Glossaire : définit les termes techniques utilisés dans le
document et ce de manière précise et sans faire aucune
présupposition sur l’expérience ou la formation du lecteur

9) Index : une liste alphabétique (ou par chapitre) des termes

ou sujets importants abordés dans le cahier des charges,
accompagnés des numéros de page correspondants

4\ Besoins fonctionnels :
La majeure partie du cahier des charges est consacrée à la
définition des besoins fonctionnels. Les besoins fonctionnels
définissent les services attendus par l’utilisateur. En principe, ils
doivent constituer un ensemble complet et cohérent. il y’a 3
façons d’exprimer les besoins fonctionnels :

1) Langage naturel : c’est le plus utilisé car il est le plus

expressif et le plus compréhensible par les utilisateurs et les
développeurs à la fois

2) Langage structuré : repose sur le langage naturel mais suit

une certaine structure pour définir les besoins, peut même
disposer d’une notation graphique, le plus connu est l’UML

3) Langages formel : toujours au stade de recherche et est très

peu utilisée en réalité
5\ Besoins non fonctionnels :
Correspond à une restriction ou à une contrainte placée sur une
des fonctions du système comme par exemple : contraintes sur
le temps de réponse maximum, limitations sur l'espace
mémoire nécessaire, restrictions sur la représentation des
données. Les besoins non fonctionnels peuvent rentrer en
conflit et interagir les uns avec les autres et même avec des
besoins fonctionnels, par exemple : conflit entre vitesse
d'exécution et occupation mémoire

6\ Validation des besoins :

- Aucun besoin ne peut être en conflit avec un autre besoin
- L'ensemble des besoins exprimés doit être complet
- Les besoins doivent être réalistes vis à vis de la technologie
des matériels et logiciels
- Les besoins des utilisateurs doivent être valides
 DIAGRAMME DES CAS D’UTILISATION

1\ Définition :
L’UML (Unified Modeling language) est un langage de
modélisation qui permet de modéliser selon une approche
orientée objet les éléments et les comportements des
systèmes, l’UML offre différentes vues (diagrammes) :
• Aspects fonctionnels
• Aspects statiques
• Aspects dynamiques

2\ Les cas d’utilisation :

Les cas d’utilisation décrivent sous la forme d’actions et de
réactions le comportement d’un système du point de vue d’un
utilisateur, le modèle des cas d’utilisation comprend : les
acteurs, le système et les cas d’utilisation eux-mêmes

Acteur : représente un rôle joué par une personne ou une

chose qui interagit avec un système pour activer une
fonctionnalité (cas d’utilisation)
3\ Scénarios :
Les cas d’utilisation doivent être vus comme des classes dont
les instances sont les scénarios, chaque fois qu’un acteur
interagit avec le système, le cas d’utilisation instancie un
scénario, un use case comprend au moins 2 scénarios : un où
tout se passe bien, et un autre où il y a problème
Un cas d’utilisation décrit de manière abstraite une famille de
scénarios
4\ Relations dans un diagramme cas d’utilisation :
il existe 4 types de relations :
- Relation de communication
- Relation d’inclusion
- Relation d’extension
- Relation de généralisation

1) Relation de Communication : représente une interaction

entre un acteur et un cas d'utilisation, elle indique que les
entités impliquées communiquent entre-elles

Notation : Une flèche simple sans barre d'association relie

l'acteur au cas d'utilisation

2) Relation d’inclusion (include) : utilisée pour montrer qu'un

cas d'utilisation inclut le comportement d'un autre cas
d'utilisation

Notation : Une flèche avec une pointe ouverte pointant vers le

cas d'utilisation inclus
3) Relation d'extension (extend) : indique qu'un cas d'utilisation
peut être étendu par un autre cas d'utilisation dans certaines
conditions

Notation : Une flèche avec une pointe ouverte pointant vers le

cas d'utilisation étendu, une condition peut être spécifiée en la
notant le long de la flèche
4) Lien de généralisation : un lien de généralisation entre 2 cas
d’utilisation signifie que le cas d’utilisation spécialisé est plus
spécifique que le cas d’utilisation général. Le spécialisé hérite
de toutes les propriétés et les associations du cas d’utilisation
généralisé et peut être augmenté de nouvelles propriétés et
associations, le même principe peut être appliqué aux acteurs,
c’est l’équivalent de l’héritage en POO

Notation : Une flèche avec une pointe en forme de triangle

pointant vers le cas d'utilisation (ou acteur) général

5\ Documentation :
Chaque acteur et cas d'utilisation doit être nommé et avoir une
description concise en quelques phrases
 DIAGRAMME DES CLASSES & DES OBJETS

1\ Définition :
La classe décrit le domaine de définition d’un ensemble
d’objets, chaque objet appartient à une classe, les généralités
sont contenues dans la classe et les particularités sont
contenues dans les objets, les objets informatiques sont
construits à partir de la classe, par un processus appelé
instanciation, de ce fait, tout objet est une instance de classe

Encapsulation : par défaut, les valeurs d’attributs d’un objet

sont encapsulées dans l’objet et ne peuvent pas être manipulés
directement par les autres objets. Toutes les interactions entre
les objets sont effectuées en déclenchant les diverses
opérations déclarées dans la spécification de la classe

Visibilité : détermine si d’autres classes peuvent l’utiliser cette

caractéristique, en UML, on utilise 4 niveaux de visibilité :
1) Public (+)
2) Protected (#)
3) Private (-)
4) Package (~)
A chaque famille de liens entre objets correspond une relation
entre les classes de ces mêmes objets, 2 types de relations :
1) Associations
2) Agrégations

2\ Association :
Exprime une connexion sémantique bidirectionnelle entre
classes, les associations se représentent de la même manière
que les liens

Rôles : il est possible de préciser le rôle d’une classe au sein

d’une association, un nom de rôle peut être spécifié de part et
d’autre de l’association
Multiplicité : les rôles portent une information qui précise le
nombre d’instances qui participent à la relation

Classes d’associations : une classe d’association encapsule les

informations concernant une association
Associations réflexives : Une association est réflexive si elle
s’applique à des objets d’une même classe

Relations n-aires : les relations n-aires sont modélisables, on

les détecte lorsqu'il est nécessaire d'avoir un identifiant multiple

Contraintes : c’est une relation sémantique quelconque entre

les éléments de modélisation qui définit des propositions devant
être maintenues à vraies pour garantir la validité du système
Stéréotype : permet aux utilisateurs
(méthodologistes, constructeurs d’outils,
analystes et concepteurs) d’ajouter de
nouvelles classes d’éléments de modélisation
en plus du noyau prédéfini par UML

Interfaces : décrit le comportement d’une classe, d’un

composant, d’un sous-système, d’un paquetage ou de tout
autre classificateur, elle possède uniquement la spécification
d’un comportement visible, sous forme d’un ensemble
d’opérations (pas d’attributs et d’associations) et ne fournit
aucune implémentation de ses services

Remarque : Une relation exprime une forme de couplage entre

abstractions, par défaut, l’association représente un couplage
faible car les classes associées restent relativement
indépendantes l’une de l’autre
3\ Agrégation :
C’est un type particulier d’association qui exprime un couplage
plus fort entre classes, une des classes joue un rôle plus
important que l’autre dans la relation. L’agrégation permet de
représenter des relations de type maître et esclaves

Composition : c’est une forme d’agrégation avec un couplage

plus important, ce couplage de composition indique que les
composants ne sont pas partageables et que la destruction de
l’agrégat entraîne la destruction des composants agrégés

Remarque : pour faire la différence entre agrégation et

composition, on doit se poser ces 2 questions :

1) La suppression du grand implique la suppression du petit ?

2) est-ce que le petit peut appartenir à plusieurs grands ?

non & oui  agrégation

oui & non  composition

Exemples :

Si une équipe est dissoute, les membres continuent d’avoir une

existence propre donc c’est une agrégation
Si un livre est détruit, ses chapitres sont détruits également
donc c’est une composition
4\ Hiérarchies de classes :
Les hiérarchies de classes ou classifications permettent de
gérer la complexité en ordonnant les objets au sein
d’arborescences de classes d’abstraction croissante

Généralisation : il s’agit de prendre des classes existantes et de

créer de nouvelles classes qui regroupent leurs parties
communes, il faut aller du plus spécifique vers le plus général
Spécialisation : il s’agit de sélectionner des classes existantes
et d’en dériver de nouvelles classes plus spécialisées, en
spécifiant simplement les différences

5\ Généralisation :
Consiste à factoriser les éléments communs d’un ensemble de
classes dans une classe plus générale appelée super-classe
Les classes sont ordonnées selon une hiérarchie, une super-
classe est une abstraction de ses sous-classes

Règles de généralisation :
- La généralisation ne porte ni nom particulier ni valeur de
multiplicité.
- Une classe ne peut pas dériver d’elle-même (relation non
réflexive)
- si une classe B dérive d’une classe A, alors la classe A ne
peut pas dériver de la classe B (relation non symétrique)
- Si C dérive d’une classe B qui dérive elle-même d’une classe
A alors C dérive également de A (relation transitive)
Généralisation multiple : pour utiliser cette
généralisation, il faut que les langages de
programmation supportent l’héritage
multiple, par exemple le C++ le supporte,
le JAVA lui ne le supporte pas

6\ Autres concepts :

Classe abstraite : ce type de classe ne donne pas directement

des objets, elle sert juste de spécification plus abstraite pour
des objets instances de ses sous-classes, le principal intérêt de
cette démarche est de réduire le niveau de détails dans les
descriptions des sous-classes
L'héritage : c’est une technique permettant de construire une
classe en se basant sur une ou plusieurs autres classes, elle
permet le partage d'attributs, d'opérations, et parfois de
contraintes au sein d'une hiérarchie de classes, les classes
enfants héritent des caractéristiques de leurs parents, cela
facilite la réutilisation du code et favorise une organisation
logique et hiérarchique des fonctionnalités dans un programme

Polymorphisme : un nom d’objet peut désigner des instances

de classes différentes issues d’une même arborescence
Diagramme des Objets : ce diagramme est un outil de
recherche et de test, il peut aider à comprendre un problème ou
à valider un diagramme de classes en représentant des
exemples, il est constitué de 2 éléments : les objets et les liens