Université d'Alger 1 Ben Youcef Benkhedda

Faculté des Sciences

Département Informatique

Architecture des logiciels

Cours 1 : Introduction à l’ingénierie
de logiciel

W. Guendouzi
www.guend.jimdo.com
Mise à jour : 2021
GL et la Crise de logiciel
 Aspect historique : La crise du logiciel
1950-1960 (cause)

• Évolution de l’informatique
Micro informatique,
BD relationnelle,
Réseaux systèmes distribués,
Informatique embarquée,..etc..
• Chute des coûts du matériel informatique
• Augmentation de la demande sur le matériel et le
logiciel informatique
 Aspect historique : La crise du logiciel
1950-1960 (cause)

• Tâche complexe :
 Taille et complexité des logiciels
 Taille des équipes de
conception/développement
 Des développeurs inexpérimentés et
incompétents

• Mauvaise compréhension des besoins :

 Négligence de la phase d'analyse des besoins du
client
 Manque d'implication du client dans le processus

• Manque de méthodes et de rigueur :

 Manque de méthodes de conception
 Négligence et manque de méthodes et d'outils
des phases de validation/vérification
 Aspect historique : La crise du logiciel
1950-1960 (conséquences de la crise de logiciel)

• Qualité du logiciel déficiente (ne répond pas aux

besoins de l’utilisateur et consomme plus de ressources
que prévu)
 Le logiciel ne correspond pas à la demande (cela
est détecté trop tard; lors de l’utilisation).
 Maintenance de logiciel difficile, couteuse et
souvent à l’origine de nouvelles erreurs.
 Difficulté de réutiliser un logiciel ou un de ces
composants pour réalisation d’un nouveau système.
 Performances médiocres (temps de réponse trop
lents).
 Difficile à utiliser
• Non respect des délais.
• Couts de développement impossible à prévoir et sont
généralement excessifs.
 Aspect historique : La crise du logiciel
Fin des années 60

• Le Comité scientifique NATO a organisé deux célèbres

conférences pour discuter les problèmes critiques dans
le développement des logiciels (1968 en Allemagne et
1969 en Italie)

• Les conférences ont donné naissance à une nouvelle

discipline qui est « l’ingénierie de logiciel »

• Les développeur désormais ont besoin d’apprendre les

bases de l’ingénierie des logiciels qui englobe
essentiellement « la conception »
 Aspect historique : La crise du logiciel
Et après ……

[Image empruntée à Gerard O’Regan

 Génie logiciel
Le génie logiciel : définition (IEEE 610.12)

“Software engineering is the application of a systematic,

disciplined, quantifiable approach to the development,
operation, and maintenance of software; that is, the
application of engineering to software, and the study of
such approaches.”

En d‘autre terme le génie logiciel signifie l’ensemble des

méthodes, des techniques et outils concourant à la
production d’un logiciel.
 Génie logiciel
Le titre « Software engineering »

• Il est utilisé vaguement pour désigner toute personne qui

construit des logiciels, plutôt qu'une personne possédant
un ensemble de connaissances et de compétences de
base.

• Il est en charge de la spécification des besoins, la

conception, la programmation (transformer la
conception en code source), l’inspection des logiciels et
le test des logiciels.

• Les ingénieurs logiciels professionnels doivent suivre les

meilleures pratiques en génie logiciel et les processus de
développement logiciels.
Le développement d’un logiciel devient un projet informatique
Processus de développement
 Processus de développement
(cycle de vie)
Le processus de développement précise :

• les tâches à réaliser (activités ou phases de

développement).
• les résultats attendus (modèles, produits,
spécifications),
• L'ordre qui organise les tâches (le cycle de
développement).
 Processus de développement
(cycle de vie)

L’origine de découpage provient du constat que les

erreurs ont un cout d’autant plus élevé qu’elles sont
détecté tardivement dans le processus de
réalisation. Le cycle de vie permet de maitriser la
qualité du produit, les délais de sa réalisation et les
couts associés.
 Processus de développement
(cycle de vie)
Activités du développement logiciel

• Analyse des besoins

• Spécification
• Conception
• Programmation
• Validation et vérification
• Livraison et maintenance

Pour chaque activité : Utilisation et production de

documents
 Processus de développement
(cycle de vie)
Analyse des besoins : Comprendre les besoins du
client
 Objectifs généraux, environnement du futur
système, ressources disponibles, contraintes de
performance…
 Fournie par le client (expert du domaine
d'application, futur utilisateur…)

Spécification :
 Établir une description claire de ce que doit
faire le logiciel (fonctionnalités détaillées,
exigences de qualité, interface…)
 Clarifier le cahier des charges (ambiguïtés,
contradictions) en listant les exigences
fonctionnelles et non fonctionnelles
 Processus de développement
(cycle de vie)
Conception : Élaborer une solution concrète réalisant
la spécification
 Description architecturale en composants (avec
interface et fonctionnalités)
 Réalisation des fonctionnalités par les composants
(algorithmes, organisation des données)
 Réalisation des exigences non fonctionnelles
(performance, sécurité…)

Programmation :
Implantation de la solution conçue
 Choix de l'environnement de développement,
du/des langage(s) de programmation, de normes
de développement...
 Processus de développement
(cycle de vie)

Validation et vérification
 Validation : assurer que les besoins du client sont
satisfaits (au niveau de la spécification, du produit fini...)
 Vérification : assurer que le logiciel satisfait sa
spécification

Livraison et maintenance
 Correction : identifier et corriger des erreurs trouvées
après la livraison
 Adaptation : adapter le logiciel aux changements dans
l'environnement (format des données, environnement
d'exécution...)
 Perfection : améliorer la performance, ajouter des
fonctionnalités, améliorer la maintenabilité du logiciel
Approches de Modélisation
 Approches de Modélisation

Modèle :
Simplification de la réalité, abstraction, vue subjective
 modèle météorologique, économique,
démographique...

Modéliser un concept ou un objet pour :

 Mieux le comprendre (modélisation en physique)
 Mieux le construire (modélisation en ingénierie)

En génie logiciel :
 Modélisation = spécification + conception
 Aider la réalisation d'un logiciel à partir des besoins
du client
 Approches de Modélisation

Les approches de modélisation ont évoluées en

réponse à la complexité croissante des logiciels. On
distingue :

• Approche structurée orientée donnée (Data-driven

design
• Approche structurée orientée action (Top-down
design)
• Approche orientée objets
• Approche orientée composants
 Approches de Modélisation

• Approche structurée orientée données

Unité de décomposition : ensemble de sous-

programmes qui sont perçus comme unité de
transfert de données input à des données output,

Système = base de donnée + Fonctions communes à

toutes les données

• Approche structurée orientée action

Unité de décomposition : sous traitement

Système = ensemble de fonctions + données partagé

entre les fonctions
 Approches de Modélisation

Inconvénient des approches structurées

• La modification d'un élément du logiciel impacte

d'autres éléments de manière relativement
imprévisible.
• Ne prend pas en compte l’abstraction des données et
leur confidentialité,
 Approches de Modélisation
• Approche Orienté Objet

Le système est perçus comme une collection d’objets

qui coopèrent entre eux. Chaque objet encapsule
actions et données et est considéré comme une
instance d’une classe qui est intégrée dans une
hiérarchie de classes.

Système = ensemble d’objets (un objets = données

fonctions)
 Approches de Modélisation
Avantages des approches orientées objet :

• la localisation de l'erreur se fait plus facilement ce qui

facilite la maintenance.
• Confidentialité des données.
• Autonomie des objets.
• Possibilité de la réutilisation des objets à travers l’héritage
et la généricité.
• Indépendance du modèle par rapport aux
fonctionnalités demandées.
 Approches de Modélisation

• Approche Orienté composants

Assemblage de composants logiciels prédéfinis, orientés

techniques ou métiers,
les composants sont conçus dans le but d'être réutilisés,
ce qui n'est pas forcément le cas d'objets définis dans
un contexte particulier et réutilisés par hasard.

Système = ensemble de composante (un composant =

ensemble d’objets)
Approches de Modélisation

Avancée des technologies, méthodes et outils de la GL

Approche orientée objet
 Approche orientée objet
Éléments de base de l’orienté objet

1. L’abstraction

Show suggests that “a simplified description,

or specification, of a system that emphasizes
some of the system's details or properties while
suppressing others. A good abstraction is one
that emphasizes details that are significant to
the reader or user and suppresses details that
are, at least for the moment, immaterial or
diversionary”

c’est est une simplification indispensable au

processus de modélisation. Un objet UML est
donc une abstraction de l’objet du monde
réel par rapport aux besoins du système, dont
on ne retient que les éléments essentiels.
 Approche orientée objet
Éléments de base de l’orienté objet

1. L’abstraction - exemple -

On s’intéresse aux chevaux pour l’activité de course. Les propriétés

d’aptitude de vitesse, d’âge et d’équilibre mental ainsi que
l’élevage d’origine sont pertinentes pour cette activité et sont
retenues.

On s’intéresse aux chevaux pour l’activité de trait. Les propriétés

d’âge, de taille, de force et de corpulence sont pertinentes
pour cette activité et sont retenues.
 Approche orientée objet
Éléments de base de l’orienté objet

2. Encapsulation

Booch says : “Encapsulation serves to

separate the contractual interface of an
abstraction and its implementation ».
Britton and Parnas call these encapsulated
elements the "secrets" of an abstraction.

L’encapsulation consiste à masquer des

attributs et des méthodes de l’objet vis à vis
des autres objets. C’est les attributs et
méthodes privés de l’objet.

L’encapsulation est une abstraction puisque

l’on simplifie la représentation de l’objet vis-à-
vis des objets extérieurs.
 Approche orientée objet
Éléments de base de l’orienté objet

2. Encapsulation - exemple -
 Approche orientée objet
Éléments de base de l’orienté objet

3. Héritage
• L’héritage est la propriété qui fait
bénéficier à une sous-classe (classe
fille) de la structure et du
comportement de sa surclasse (classe
mère ).
 Approche orientée objet
Éléments de base de l’orienté objet

3. Héritage

• L'heritage est transitif : si B herite de A et C herite de B,

alors C herite de A

• L’héritage permet la réutilisabilité et la généralisation et

abstraction

• L’héritage est une conséquence de la généralisation

/spécialisation
 Approche orientée objet
Éléments de base de l’orienté objet

3. Héritage - exemple -
 Approche orientée objet
Éléments de base de l’orienté objet

3. Héritage
• surclassement ou upcasting

Les instances des classes filles sont également

instances de la classe mère.

tout objet instance de la classe B peut être aussi

vu comme une instance de la classe A.

L’objet c est surclassé

 Approche orientée objet
Éléments de base de l’orienté objet

3. Héritage
• surclassement ou upcasting

emprunté à Philippe Genoud

 Approche orientée objet
Éléments de base de l’orienté objet

4. Polymorphisme
Le polymorphisme est la différence de comportement qui existe entre
des classes filles d’une même classe mère pour les méthodes de même
nom.

on distingue deux types de polymorphisme :

 Surcharge de méthode (overloading ou polymorphisme ad hoc)

 Redefinition des methodes (overriding) :
 Approche orientée objet
Éléments de base de l’orienté objet

4. Polymorphisme
 Surcharge de méthode (overloading ou polymorphisme ad hoc) on définit dans
une même classe ou dans des classes différentes des méthodes ayant le même
nom mais pas les mêmes signatures (paramètres différents).

On parle aussi de surcharge de méthode lorsque les noms et signatures des

méthodes sont les mêmes mais qu'elles sont définies dans des classes non liées
par héritage.

Le polymorphisme ad hoc est surtout utile pour uniformiser les traitements d'objets
de classes non liées par héritage.
 Approche orientée objet
Éléments de base de l’orienté objet

d) Polymorphisme
 Redefinition de methode (overriding) : on définit dans une classe une méthode
ayant le même nom et la même signature qu'une méthode de la classe mère
 Approche orientée objet
Éléments de base de l’orienté objet

5. Classe abstraite / classe concrète

• Une classe concrète possède des instances. Elle constitue un modèle complet
d’objet (tous les attributs et méthodes sont complètement décrits).

• Une classe abstraite ne peut pas posséder d’instance directe car elle ne fournit pas
une description complète.

• Une classe abstraite sert à factoriser des attributs et méthodes communs à ses sous-
classes (spécifier un comportement commun à plusieurs classes)

Manipuler des instances de classes différentes de façon uniforme (Polymorphisme)

• Dans une hiérarchie d’héritage, les classes qui ne sont pas des feuilles sont
généralement abstraites
 Approche orientée objet
Éléments de base de l’orienté objet

5. Classe abstraite / classe concrète

 Approche orientée objet
Éléments de base de l’orienté objet

6. Interface
• Une interface est une classe totalement abstraite, c’est à dire sans attribut (ou
bien uniquement des constantes) et dont toutes les méthodes sont abstraites
et publiques.

• L’implantation des méthodes est réalisée par une ou plusieurs classes

concrètes, sous-classes de l’interface

• Une classe peut également dépendre d’une interface pour réaliser ses
opérations. Cette dernière est alors employée comme type au sein de la
classe (attribut, paramètre de l’une des méthodes ou variable locale de l’une
des méthodes).
Une classe qui dépend d’une interface en est sa cliente.

• Une classe peut implémenter plusieurs interfaces

• Une interface peut hériter d’une autre interface

 Approche orientée objet
Éléments de base de l’orienté objet

6. Interface - exemple -
 Approche orientée objet
Éléments de base de l’orienté objet

6. Classe abstraite Vs Interface

• Une interface ne peut implanter une méthode alors qu'une
classe abstraite peut.
• Une classe peut implanter plusieurs interfaces mais ne peut avoir
qu'une seule superclasse.
• Une interface n'appartient pas à la hiérarchie des classes. Des
classes sans rapport entre elles peuvent implanter la même
interface.
• Plus important, avec Interface on est sûr qu'un objet a
implémenté une méthode (il ne peut différer cette
implantation).
• Une interface peut faire extends de plusieurs autres interfaces
(Le vérifier sur un exemple interface C extends A , B {} )
 Approche orientée objet
Éléments de base de l’orienté objet

7. Rappel sur les relations et stéréotypes en UML

 Approche orientée objet
Éléments de base de l’orienté objet
7. Rappel sur quelques relations et stéréotypes en UML

Association
• C’est un lien faible entre les classes qui ne spécifie pas le type de la
relation ni les contrainte sur le lien
• Les paramètre type que l’on passe a une méthode d’une classe,
• la classe qui exécute la fonction se sert du paramètre mais n’en garde
aucune trace.

[empruntée à Céline ROUDET

 Approche orientée objet
Éléments de base de l’orienté objet
7. Rappel sur quelques relations et stéréotypes en UML

Agregation (delegation)
• les classes agrégées ont une existence indépendante de la classe
agrégat
• attribut de la classe agrégat contient une référence vers la classe
agrégée
• les instances des classes à agréger sont passé au constructeur ou à
des mutateurs avec des paramètres typés.

Tiré de : https://blog.developpez.com/rawsrc/p10377/conception/dependances_et_couplage_des_classes_poo
 Approche orientée objet
Éléments de base de l’orienté objet

7. Rappel sur les relations et stéréotypes en UML

Composition
• Les classes composites ne peuvent exister en dehors de la classe
composee. Les classes composites ne sont pas partageable.
• attribut de la classe composée contient une référence vers la classe
composite
• La classe composée contrôle la totalité de la vie de ses composites
(de leur naissance à leur mort), son constructeur doit se charger de les
instancier et son destructeur de les détruire. L’accès aux composites
est limité et toujours sous contrôle de la classe composée.

Tiré de : https://blog.developpez.com/rawsrc/p10377/conception/dependances_et_couplage_des_classes_poo
 Sources du cours

1.LA PROBLEMATIQUE DU LOGICIEL. Anne-Marie Hugues. 2002

2.Introduction au génie logiciel et à la modélisation. Delphine
Longuet. Polytech Paris-Sud. 2017
3.Software engineering. Ian Sommerville. Book, 9th edition,2011.
4.OBJECT-ORIENTED ANALYSIS AND DESIGN. Grady Booch. Book, 2nd
edition, 1999.
5.Analyse et Conception des Logiciels. Petko Valtchev. Université
de Montréal 2005.
6.Introduction au développement du logiciel Vers le génie logiciel.
Pascal ANDRE. Université de Nantes
7.Visualisation de la cohésion et du couplage du code Java.
Oduar Mejia Lopez. Université de Sherbrooke (Québec) Canada.
2011.
8.Developpez.com
9.UML: initiations, exemple et exercices corrigés. Fien VAN DER
HEYDE et Laurent DEBRAUWER; Boo Second édition.
10.Travaux pratiques en Java. Najib Tounsi
11.Introduction au génie logiciel et à la modélisation. Delphine
Longuet. Polytech Paris-Sud.