1 Année master ISI

Notes de Cours
Conception avancée des logiciels

Cours 1
Introduction

Présenté par
Mr KHELIFA N.
 Introduction
 Le génie logiciel a été défini officiellement par la communauté scientifique dans:

 Une conférence internationale du 7 au 11 octobre 1968, à Garmisch-Partenkirchen,

Allemagne, sous le parrainage de l'OTAN.

 Une conférence après constat:

◦ De la montée en puissance des performances du matériel (arrivé des semi-conducteur) et
◦ Le nombre de logiciel défaillant ou non aboutit qui ne cessé de croitre ce qui a causé
«La crise du logiciel »

 Cette crise du logiciel ce décrivait par:

● délais de livraison non respectés

● budgets non respectés
● ne répond pas aux besoins de l'utilisateur ou du client
● difficile à utiliser, maintenir, et faire évoluer

 La crise du logiciel n’est pas terminée jusqu’à maintenant

 Définition
• Définition 1 [IEEE] : Application d’une approche systématique, discipliné
et quantifiable au développement, exploitation et maintenance du logiciel,
c’est-à-dire l’application l’ ingénierie au logiciel

 Objectif: (FCDQ)

◦ Le système développé doit assurer les fonctionnalités attendues ;

◦ Les coûts du développement doivent rester dans les limites prévues au
départ ;
◦ Les délais doivent rester dans les limites prévues au départ ;
◦ La qualité du logiciel correspond au contrat de service initial

délais (échéance), coûts et qualité

 Génie logiciel
La solution imaginé :
◦ l’industrialisation de la production du logiciel :
 organisation des procédés de production (cycle de vie, méthodes,
notations, outils),
 organisation en équipes de développement,
 établir des plans qualités rigoureux

cycle de vie d'un logiciel

 Est la période de temps s'étalant du début à la fin du processus du
logiciel.
 Il commence avec la proposition ou la décision de développer un
logiciel et se termine avec sa mise hors service.
 désigne toutes les étapes du développement d'un logiciel
cycle de vie de logiciel
 Les activités courantes
 Etude préalable (feasibility)
◦ S\Phase exploratoire
 Y-a-t-il lieu de réaliser le logiciel ?
 Fixer les conditions générales
 sortie: Dossier d’entretiens, Décisions (faire, ne pas faire, acheter,…),Budget approximatif
◦ S\Phase conception
 Cahier des charges et plan de projet
 sortie : Cahier des charges, Plan général du projet, Budget précis….

 Spécification (requirements, besoin, exigence)

◦ Processus qui dresse la liste de ce qui est attendu du système, ainsi que les contraintes sur
l’exécution du système et son développement
◦ Requirement engineering process
 Etude de faisabilité : est il techniquement et financièrement faisable de construire le système ?
 analyse des besoins: Qu’est-ce que les parties prenantes du système attendent de ce système?
 Spécification des exigences: On définit les exigences en détail
 Validation des exigences : On vérifie la validité des exigences
 sortie: Document de spécification (fonctions et performances), Première version du manuel
utilisateur, Plan détaillé du reste du projet, Plan de validation
 Les activités courantes
 Conception générale (product design)
◦ Architecture du système
◦ Principales structures de données
◦ Décomposition du système en modules
 sortie : Définition des principales structures de données, Décomposition du
système en modules (architecture), Description du rôle de chaque module

 Conception détaillée (detailed design)

◦ Raffinement des éléments précédents jusqu’à l’obtention d’une forme
permettant d’écrire immédiatement les programmes
 sortie : Description détaillée des structures de données et des modules

 Codage (coding)
◦ Écriture des textes des programmes
 sortie : Texte des programmes, Chaque module est vérifié séparément
 Les activités courantes
 Intégration
◦ Regroupement des divers modules
◦ Construction de l’architecture générale
◦ Validation globale/recette
 sortie : Compte rendu de recette, Rapports d’inspection et de validation
 Validation globale/recette
◦ vérifier qu’on construit le bon système
 sortie: Satisfaction des users (ou non), Acceptation du produit (ou non) / Logiciel accepté , Rapport des
tests
 Diffusion
◦ Préparation et distribution des différentes versions
 sortie : Versions des programmes et de leur documentation adaptées
 Exploitation
◦ Mise en place du système dans son environnement opérationnel
 sortie : Programme en fonctionnement, Rapports d’incidents et de correction
 Maintenance
◦ Processus qui permet de garder opérationnel un logiciel ou de l'améliorer
◦ La maintenance peut être:
 Corrective (erreurs dormantes)
 Adaptatif (par rapport à l’utilisateur)
 Evolutif (par rapport à l’environnement)
 Perfective (optimisation, amélioration,..)
 La conception
 Spécifier
→ c’est définir le quoi.
 Concevoir → c’est définir le comment

 Conception :
◦ processus de définition de
 l'architecture logicielle,
 des composants(module),
 interfaces et
 données d'un système logiciel pour satisfaire aux exigences spécifiées

 Phase de conception :
◦ période du cycle de vie du logiciel pendant laquelle les définitions ou
conceptions d'architecture, de composants logiciels, les interfaces et les
données sont créées, documentées et vérifiées pour satisfaire aux exigences
Modèle général du processus de conception
 Modèle général du processus de conception

 Conception de l’architecture
◦ Identification de la structure globale du système
◦ Les principaux composants
◦ Leurs relations
 Conception des interfaces
◦ On définit les interfaces du système
 Conception des composants
◦ Conception de chaque composant de façon indépendante
 Conception de la base de données et classes
◦ Conception de la structure de la base de données et des classes
La place de la conception dans CVL
 La place de la conception dans CVL
 Chacun des éléments du modèle d'exigences fournit informations nécessaires pour créer
les quatre modèles de conception requis pour une spécification complète de la conception.
 La conception de données/classe transforme les modèles de classe en classe de
conception réalisations et les structures de données requises nécessaires à la mise en
œuvre du logiciel
 La conception architecturale définit la relation entre les principaux éléments structuraux
du logiciel en utilisant les styles et patron architecturaux
 La conception de l'interface décrit comment le logiciel communique avec les systèmes qui
interagissent avec lui, et avec les humains qui l'utilisent.
◦ Une interface implique un flux d'informations (par exemple, données et/ou contrôle) et un type de
comportement spécifique.
◦ Par conséquent, les scénarios d'utilisation et les modèles comportementaux fournissent une grande
partie de l'information requis pour la conception de l'interface.
 La conception au niveau des composants transforme les éléments structurels de l’
architecture du logiciel en une description procédurale des composants logiciels.
 Informations obtenus à partir des modèles basés sur les classes et les modèles
comportementaux servent de base pour la conception des composants.
 PRINCIPES DE CONCEPTION
Le principe de séparation des responsabilités
◦ vise à organiser un logiciel en plusieurs sous-parties, chacune ayant une
responsabilité biendéfinie.
◦ Au moment où un nouveau besoin se fera sentir, il suffira d'intervenir
sur la ou les sous-parties concernées
Le principe de responsabilité unique
◦ à lui que chaque sous-partie atomique d'un logiciel (exemple : une
classe) doit avoir une unique responsabilité (une raison de changer) ou
bien être elle-même décomposée en sous-parties
Encapsulation maximale
◦ Ce principe de conception recommande de n'exposer au reste de
l'application que le strict nécessaire pour que la sous-partie joue son
rôle.
 PRINCIPES DE CONCEPTION
 Modularité
◦ Un système est modulaire s’il est composé de sous systèmes plus simple ou
modules
◦ La modularité permet de considère séparément le contenu du module et les
relations entre modules
◦ La modularité facilite , la réutilisation , l’adaptation et permet le travail d’équipe
 Cohésion
◦ On mesure la cohésion (“cohesion”) d’un composant aux nombres de ses sous-
composants qui effectuent des tâches similaires et ont des interactions continues.
 Couplage
◦ On mesure couplage (l’interdépendance) entre deux composants A et B à la
quantité de modifications à faire sur B lorsque A est modifié (et réciproquement).
 Un bon indicateur de la qualité de la modularisation.
haute cohésion, basse interdépendance
 PRINCIPES DE CONCEPTION
 DRY (DON'T REPEAT YOURSELF)
◦ Ce principe vise à éviter la redondance au travers de l'ensemble de l'application.
◦ Elle a les conséquences néfastes suivantes :
 Augmentation du volume de code ;
 Diminution de sa lisibilité ;
 Risque d'apparition de bogues dû à des modifications incomplètes

 KISS (KEEP IT SIMPLE, STUPID)

◦ on peut le traduire par « Ne complique pas les choses ».
◦ Ce principe vise à privilégier autant que possible la simplicité lors de la construction d'une
application. Il part du constat que la complexité entraîne des surcoûts de développement puis de
maintenance, pour des gains parfois discutables

 YAGNI (YOU AIN'TGONNA NEED IT)

◦ Corollaire du précédent, il consiste à ne pas se baser sur d'hypothétiques évolutions futures pour
faire les choix du présent, au risque d'une complexification inutile (principe KISS).
◦ Il faut réaliser l'application au plus simple et en fonction des besoins actuels. Le moment
venu, il sera toujours temps de procéder à des changements (refactorisation ou refactoring) pour
que l'application réponde aux nouvelles exigences.
 Les lignes directrices pour une bonne
conception
 considérez ce qui suit des lignes directrices:

 1. Une conception doit présenter une architecture qui

◦ est créée à l'aide styles ou modèles architecturaux reconnaissables,
◦ est composée de composants qui présentent de bonnes caractéristiques de
conception, et
◦ peut être mis en œuvre de manière évolutive, facilitant les tests.

 2.Une conception doit être modulaire ; c'est-à-dire que le logiciel doit être
partitionné logiquement en éléments ou sous-systèmes.

 3.Une conception doit contenir des représentations distinctes des données,

de l'architecture, des interfaces, et composants.

 4. Une conception doit conduire à des structures de données adaptées à la

classes à implémenter et sont tirées de données reconnaissables patrons.
 Les lignes directrices pour une bonne
conception
 5.Une conception doit conduire à des composants qui
présentent des caractéristiques fonctionnelles indépendantes.

 6. Une conception doit conduire à des interfaces qui réduisent la

complexité des connexions entre les composants et avec
l'environnement extérieur.

 7.Une conception doit être dérivée à l'aide d'une méthode

reproductible basée sur informations obtenues lors de l'analyse
des exigences logicielles.

 8.Une conception doit être représentée à l'aide d'une notation

qui exprime efficacement son sens .
 Les trois types de conception
 Conception générique,
◦ la conception générique, qui définit les composants nécessaires à la construction
de l’architecture technique.
◦ Cette conception est la moins dépendante possible des aspects fonctionnels.
◦ Elle a pour objectif d’uniformiser et de réutiliser les mêmes mécanismes pour tout
un système.

 Conception préliminaire,
◦ explique comment organiser un modèle de conception au vu des regroupements
d’analyse et des couches logicielles d’architecture.
◦ Il illustre notamment l’identification des composants métier et techniques d’un
système logiciel.

 Conception détaillée,
◦ illustre la modélisation de solutions, en appliquant différents design patterns,
suivant les couches que l’on désire réaliser.
 Conception vs implémentation
Différencesentre conception et
implémentation ?

◦ L’implémentation est la mise en œuvre des choix

issus de la conception.
◦ L’implémentation doit pouvoir répondre aux
contraintes de réalisation sans mettre en cause les
choix de conception.
UML
 UML
UML est un langage pour visualiser, spécifier,
concevoir et documenter les artefacts d’un système à
base logicielle »
◦ Langage : syntaxe abstraite (élément et leurs relations),
syntaxe concrète (élément graphique)
, sémantique
◦ Visualiser : représentation graphique
◦ Spécification : précis, complet, non-ambigu
◦ Construction : translation vers des langages de
programmation
◦ Documentation : des besoins aux tests
Les diagrammes UML
 UML et OMG
 Travail de standardisation réalisé par l’OMG (object Management
Group) au tours d UML s’intéresse à plusieurs axe, parmi eux:

 UML infrastructure: cette partie vise à aligner UML avec les autres
standards de modélisation développés par OMG en utilisant la méta
modélisation

 UML superstructure : la partie la plus utilisée, elle contient les

concepts d’UML

 UML OCL : les bases de méta modélisation du de l’OCL (Object

Constraint Language)

 UML diagram interchange :proposition pour standardiser un format

d’échange de diagrammes
Merci de votre attention