Génie Logiciel
GL/S4 & SMI/S6
Génie Logiciel
Prof. : M. BENADDY
Génie Logiciel
Chapitre 6 : Conception
Prof. M. Benaddy Génie logiciel 2
Sommaire
Introduction
Modélisation du système
Architecture logicielle
Conception orienté objet
Prof. M. Benaddy Génie logiciel 3
Introduction
Concevoir l’architecture
Qui fera quoi et où ?
Concevoir les interfaces utilisateurs du logiciel
Concevoir les bases de données
Concevoir les contrôles du logiciel
Mise en œuvre de tous les aspects liés au contrôle, à
la correction, à la sécurité, à la tolérance aux fautes, à
la protection des données, etc.
Concevoir le réseau
Communication entre les processus distribués
Prof. M. Benaddy Génie logiciel 4
Introduction
Définir précisément le système.
Convertir le quoi des spécifications en
comment.
Document de conception suffisamment
détaillé pour implémenter le système.
Prof. M. Benaddy Génie logiciel 5
Introduction
Étape cruciale du développement logiciel
Analyse → conception → implémentation
Décomposition du produit en unités
(modules, classes) plus simples
Difficile car elle exige de la créativité
Une bonne conception contribue à la qualité
du logiciel
Fiabilité
Correction
Prof. M. Benaddy Génie logiciel 6
Introduction
Conception architecturale (haut niveau)
Définir la structure et l'organisation générale du logiciel à
développer.
Décrire les principaux modules, les relations entre eux,
les contraintes à respecter.
Conception détaillée (bas niveau)
Réalise chacun des cas d'utilisation
Respecte le plan de la conception architecturale
Décrit le fonctionnement interne de chacun des modules
Permet l'implémentation dans un langage de
programmation
Prof. M. Benaddy Génie logiciel 7
Objectifs
Cohésion forte : les éléments ne sont pas réunis dans
un même module (ou même classe) par hasard, ils
forment un tout pour réaliser une tâche.
Faible couplage : les modules (ou classes) sont
relativement indépendants, ils ne dépendent le moins
possible des éléments d'autres modules
Abstraction : une décomposition intuitive et qui
permet de se concentrer sur un module (ou classe) à
la fois.
Encapsulation et masquage d'information : les
détails d'implémentation sujets au changements sont
cachés derrière une interface stable.
Prof. M. Benaddy Génie logiciel 8
Objectifs
La conception doit tenir en compte
Les besoins existants
Les besoins à venir
Pour obtenir une conception qui facilite
l'adaptation du logiciel aux changements
Évolutivité
Anticipation du changement
Prof. M. Benaddy Génie logiciel 9
Modélisation du système
Le développement de modèles abstraits du
système, chaque modèle présente une vue
ou une perspective du système.
UML est souvent utilisé pour modéliser un
tel système.
Les modèles sont utilisés pour
communiquer avec le client et les membres
de l'équipe de développement.
Prof. M. Benaddy Génie logiciel 10
Modélisation du système (modules)
Module : unité fournissant des ressources
et/ou des services :
Déterminer les modules M={M1, M2, …,
Mn}
Quelles sont les relations entre les
modules
Afin de déterminer la structure du logiciel à
développer.
Prof. M. Benaddy Génie logiciel 11
Modélisation du système (relations modules)
Relation contient : regroupement en
paquetages, classe internes
(agrégation/composition)
Relation utilise : association, agrégation /
composition, généralisation, liens de
dépendance, ...)
Prof. M. Benaddy Génie logiciel 12
Modélisation du système (Interfaces)
Interface : partie publique
L'ensemble des ressources (opération,
attributs, …) rendues accessibles aux
modules clients.
La conception d'un module M ne nécessite
que les interfaces des autres modules que M
pourra utiliser
Implémentation : partie privé
Façon dont les ressources sont concrètement
représentées et réalisées dans le module
Prof. M. Benaddy Génie logiciel 13
Architecture logicielle
C'est le processus de conception qui identifie les
sous-systèmes qui composent le système et leur
cadre de contrôle et de communication.
Décrit l'organisation générale du logiciel, les
modules et leurs interfaces, l'agencement des sous-
systèmes, des modules et des composants (leurs
propriétés, leurs composition et leurs collaborations)
Dépend des besoins fonctionnels et non
fonctionnels
La sortie de ce processus de conception est une
description de l'architecture logicielle.
Prof. M. Benaddy Génie logiciel 14
Architecture logicielle (utilité)
Modèles connus : de décomposition
éprouvés et enrichis par l’expérience de plusieurs
développeurs
Mode d’interaction établi entre modules via une
interface générique
Fournit une plate-forme d’intégration pour connecter
les différentes sous-parties du logiciel à développer
Meilleure qualité du logiciel : compréhensibilité,
maintenance, facilité d’évolution, réutilisation,
performance, documentation, etc.
Prof. M. Benaddy Génie logiciel 15
Conception Architecturale
C'est un stade précoce de la phase de
conception.
Représente le lien entre les processus de
spécification et de conception .
Souvent menée en parallèle avec des
activités de spécification.
Il s'agit d'identifier les principaux
composants du système et de leur
communication.
Prof. M. Benaddy Génie logiciel 16
Conception Architecturale
Prof. M. Benaddy Génie logiciel 17
Abstraction en architecture
Petite architecture : l'architecture des
programmes individuels. A ce niveau, nous
sommes préoccupés par la façon dont un
programme individuel est décomposé en
composants.
Grande architecture : l'architecture des
systèmes d'entreprise complexes qui incluent
d'autres systèmes, des programmes et des
composants. Ces systèmes sont répartis sur
différents ordinateurs, qui peuvent être détenues
et gérées par des sociétés différentes.
Prof. M. Benaddy Génie logiciel 18
Type : l'architecture en couches
Utilisé pour modéliser l'interfaçage entre les sous-
systèmes.
Organise le système en un ensemble de couches
(ou machines abstraites) chacune qui fournie un
ensemble de services.
Prend en charge le développement incrémental de
sous-systèmes dans les différentes couches.
Quand une interface de couche change, seule la
couche adjacente est affectée.
Cependant, souvent artificiel pour structurer les
systèmes de cette façon.
Prof. M. Benaddy Génie logiciel 19
Type : l'architecture en couches
Name Layered architecture
Description Organizes the system into layers with related functionality associated with each
layer. A layer provides services to the layer above it so the lowest-level layers
represent core services that are likely to be used throughout the system. See Figure
6.6.
Example A layered model of a system for sharing copyright documents held in different
libraries, as shown in Figure 6.7.
When used Used when building new facilities on top of existing systems; when the development
is spread across several teams with each team responsibility for a layer of
functionality; when there is a requirement for multi-level security.
Advantages Allows replacement of entire layers so long as the interface is maintained.
Redundant facilities (e.g., authentication) can be provided in each layer to increase
the dependability of the system.
Disadvantages In practice, providing a clean separation between layers is often difficult and a high-
level layer may have to interact directly with lower-level layers rather than through
the layer immediately below it. Performance can be a problem because of multiple
Prof. M. Benaddy levels of interpretation of a service request as it is processed at each layer.
Génie logiciel 20
Type : l'architecture en couches
Prof. M. Benaddy Génie logiciel 21
Type : l'architecture en couches
Prof. M. Benaddy Génie logiciel 22
Type : l'architecture client-serveur
Modèle de système distribué qui montre
comment les données et les traitement sont
distribué à travers une gamme de composants.
Il peut être implémenté sur une seule
machine.
Ensemble de serveurs qui offre des services
spécifiques, tels que l’impression, la gestion
des données, …
Le réseau qui permet aux clients d'accéder aux
serveurs.
Prof. M. Benaddy Génie logiciel 23
Type : l'architecture client-serveur
Name Client-server
Description In a client–server architecture, the functionality of the system is organized into services, with
each service delivered from a separate server. Clients are users of these services and access
servers to make use of them.
Example Figure 6.11 is an example of a film and video/DVD library organized as a client–server
system.
When used Used when data in a shared database has to be accessed from a range of locations. Because
servers can be replicated, may also be used when the load on a system is variable.
Advantages The principal advantage of this model is that servers can be distributed across a network.
General functionality (e.g., a printing service) can be available to all clients and does not need
to be implemented by all services.
Disadvantages Each service is a single point of failure so susceptible to denial of service attacks or server
failure. Performance may be unpredictable because it depends on the network as well as the
system. May be management problems if servers are owned by different organizations.
Prof. M. Benaddy Génie logiciel 24
Type : l'architecture client-serveur
Prof. M. Benaddy Génie logiciel 25
Type : l'architecture n tiers
Architecture par niveaux
2 niveaux (2-tiers)
Client Serveur
3 niveaux (3-tiers)
Présentation Logique d'application Gestion de données
Stockage de
Multi niveaux (n-tiers) données
Présentation Logique d'application Traitement de données
Stockage de
données
Prof. M. Benaddy Génie logiciel 26
Type : l'architecture tableau noir
Modèle Tableau noir : médium de communication
Communication étendue à tous les partenaires
Un des sous-système est désigné comme le tableau noir
On ne peut recevoir et transmettre des informations que
via le tableau
Utile lorsqu’on ne connaît pas de solution déterministe
Prof. M. Benaddy Génie logiciel 27
Type : l'architecture tableau noir
Les sous-systèmes répondent aux
événements
Appropriée pour les logiciels dont les composants
doivent interagir avec l’environnement
Les sous-systèmes s’abonnent pour recevoir les
annonces de certains types d’événements
Prof. M. Benaddy Génie logiciel 28
Type : l'architecture MVC -Modèle Vue Contrôleur
Inventé en 1978 par Trygve Reenskaug (U.
Oslo)
Lors d’une visite à Xerox PARC
Problème: permettre à des utilisateurs de contrôler
de grands et complexes ensembles de données
Maximum de flexibilité et de réutilisation possible
Peut être vu comme
Un patron de conception
Un type d’architecture
Un cadre d’applications (framework)
Prof. M. Benaddy Génie logiciel 29
Type : l'architecture MVC -Modèle Vue Contrôleur
Modèle : représente les connaissances dans le
système
Vue : Une représentation visuelle du modèle
Souligne certains aspects du modèle et en ignore
d’autres
Contrôleur : L’interface entre l’utilisateur et le
système
Responsable des entrées (buttons, etc.) et des sorties
(placer les vues sur un moniteur, etc.)
Prof. M. Benaddy Génie logiciel 30
Type : l'architecture MVC -Modèle Vue Contrôleur
• Encapsule l’état de l’application
• Répond aux demandes d’état
• Expose les fonctions de
l’application
Modèle • Notifie les vues de
Demandes
de rapport changements
d’état Notifications de
changement
Sélection des vues
Vue Contrôleur
Actions de l’utilisateur
• Fait le rendu du modèle • Définit le comportement de
• Demande des mises à jour du l’application
modèle • Mappe les actions de
• Envoie des actions de l’utilisateur aux mises à jour du
l’utilisateur au contrôleur modèle
• Permet au contrôleur de • Sélectionne une vue pour la
sélectionner une vue réponse
Prof. M. Benaddy Génie logiciel 31
Génie Logiciel
Conception Orientée Objet
Prof. M. Benaddy Génie logiciel 32
Conception orienté objet
Conception orientée objet structuré implique
l'élaboration d'un certain nombre de modèles
de systèmes différents.
La maintenance et le développement de ces
modèles nécessitent beaucoup d'efforts. Mais
pour les petits systèmes cela a un coût réduit.
Toutefois, pour les grands systèmes
développés par différents groupes, les
modèles de conception objet sont un
mécanisme de communication important.
Prof. M. Benaddy Génie logiciel 33
Etude de cas ''Weather station''
A weather station is a package of software controlled instruments
which collects data, performs some data processing and transmits this
data for further processing. The instruments include air and ground
thermometers, an anemometer, a wind vane, a barometer and a rain
gauge. Data is collected periodically.
When a command is issued to transmit the weather data, the weather
station processes and summarises the collected data. The summarised
data is transmitted to the mapping computer when a request is
received.
Prof. M. Benaddy Génie logiciel 34
Contexte du système et interaction
Prof. M. Benaddy Génie logiciel 35
Cas d'utilisation
Prof. M. Benaddy Génie logiciel 36
Conception architecturale
Une fois les interactions entre le système et son
environnement ont été comprises, vous utilisez
cette information pour la conception de
l'architecture du système.
Identifiez les principaux éléments qui composent
le système et leurs interactions, puis on peut
aussi organiser les composants à l'aide d'un
modèle architectural comme le modèle en couche
ou un modèle client-serveur.
Prof. M. Benaddy Génie logiciel 37
Conception architecturale
Prof. M. Benaddy Génie logiciel 38
Conception architecturale
Prof. M. Benaddy Génie logiciel 39
Identification des classes d'objets
Il n'existe aucune «formule magique» pour
l'identification des classes d'objet. Elle s'appuie
principalement sur la compétence, l'expérience et
le domaine des connaissances des concepteurs.
L'identification des classes d'objet est un
processus itératif. Vous êtes peu probable
d'obtenir un modèle parfait dès la première fois.
Prof. M. Benaddy Génie logiciel 40
Identification des classes d'objets
Utiliser une approche grammaticale basée sur une
description en langue naturelle du système
(utilisée dans la méthode de Hood OOD).
Fonder l'identification sur des objets réels dans le
domaine de l'application.
Utilisez une approche comportementale et
identifier les objets en fonction de leur participation
à un comportement.
Utilisez une analyse basée sur des scénarios. Les
objets, attributs et méthodes dans chaque scénario
sont identifiés.
Prof. M. Benaddy Génie logiciel 41
Identification des classes d'objets (Weather station)
L'identification des classes d'objet dans le système de la station
météo peut être fondée sur les objets réels (le matériel) et les
données dans le système :
Thermomètre du sol (Ground Thermometer), anémomètre
(Anemometer), baromètre (Barometer).
Les objets du domaine d'application qui sont des objets «
matériel » associés à des instruments dans le système.
Weather Station
L'interface de base de la station météo à son environnement.
Elle reflète donc les interactions définies dans le modèle de
cas d'utilisation.
Weather data
Encapsule le résumé des données délivrées par les
instruments.
Prof. M. Benaddy Génie logiciel 42
Identification des classes d'objets (Weather station)
Prof. M. Benaddy Génie logiciel 43
Identification des classes d'objets (Weather station)
L'identification des classes d'objet dans le système de la station
météo peut être fondée sur les objets réels (le matériel) et les
données dans le système :
Thermomètre du sol (Ground Thermometer), anémomètre
(Anemometer), baromètre (Barometer).
Les objets du domaine d'application qui sont des objets «
matériel » associés à des instruments dans le système.
Weather Station
L'interface de base de la station météo à son environnement.
Elle reflète donc les interactions définies dans le modèle de
cas d'utilisation.
Weather data
Encapsule le résumé des données délivrées par les
instruments.
Prof. M. Benaddy Génie logiciel 44
Les modèles de conception objet
Les modèles de conception montrent les objets et
classes d'objets et les relations entre ces entités.
Les modèles statiques décrivent la structure
statique du système en termes de classes
d'objets et les relations entre elles.
Les modèles dynamiques décrivent les
interactions dynamiques entres les objets.
Prof. M. Benaddy Génie logiciel 45
Les modèles de conception objet
Les modèles de conception montrent les objets et classes
d'objets et les relations entre ces entités.
Les modèles statiques décrivent la structure statique du
système en termes de classes d'objets et les relations
entre elles.
Les diagrammes de classes d'objet (UML)
Les diagrammes de paquetage (UML) pour les sous
systèmes.
Les modèles dynamiques décrivent les interactions
dynamiques entres les objets.
Les diagrammes de séquence et d'états de transition
(UML)
Prof. M. Benaddy Génie logiciel 46
Document de l'architecture
Les modules qui composent les système et leurs
interactions
Description des fonctionnalités de chaque module.
Description des interactions en terme de données
échangées.
Explication du choix de l'architecture choisie.
Les prototypes (squelettes) des classes et méthodes les
plus importantes
Définir les méthodes et leur portée.
Définir les attributs et leur portée (public, privée,…)
Commenter les différentes méthodes et attributs (javadoc
si le langage utilisé est java)
Prof. M. Benaddy Génie logiciel 47
