Le génie logiciel

L’analyse et la conception
Analyse /conception en 3 étapes
 ETAPE 1 : Analyser…les exigences
afin de préparer la conception
 ETAPE 2 : Concevoir…l’architecture du
logiciel
 ETAPE 3 : Documenter la conception

2
Analyse / conception

ETAPE 1 : ANALYSER LES EXIGENCES

3
Analyser les exigences
OBJECTIFS DE L’ANALYSE DES EXIGENCES

 Pourquoi une étape préliminaire d’analyse

avant de concevoir ?
 Lorsque la STB (Spécifications techniques du
besoin) (ou le CDC) n’existe pas
 Pour compléter une STB existante
 Pour modéliser (formaliser) les exigences de la
STB

Résultats : STB révisée Spécifications

Et/ou
techniques

4
Analyser les exigences
COMPLETER UNE STB EXISTANTE

 Les spécifications sont souvent incomplètes ou peu

précises, notamment :
 Diagramme de contexte
 Acteurs & catégories d’utilisateurs (+ habilitations)
 Règles métier
 Modèles métier de l’application (domaine, fonctionnel,
comportement)
 Interface utilisateur
 Cas d’erreurs et modes de fonctionnement particuliers
 Autres interfaces & protocoles de communication
 Dimensionnement et limites

5
Analyser les exigences
MODELISER (FORMALISER) LES EXIGENCES DE LA
STB
 Les modèles peuvent être plus ou moins
formels
 Spécifications formelles
 UML : cas d’utilisation, diagramme des classes , de
séquence, d’états …
 Autres
 Ces modèles s’adressent en priorité à
d’autres développeurs

Seulement lorsque c’est nécessaire et avec parcimonie !

6
Analyser les exigences – Modèles UML

UML

7
Analyser les exigences
QUE FAIT- ON AVEC TOUT CELA ?
 Solution 1 : 2 documents
 Vision client -> Compléter le document initial
de spécifications (STB révisée) :
 spécifications fonctionnelles détaillées
 Vision développeur -> Rédiger un nouveau
document : les « spécifications techniques »
 Solution 2 : 1 document
 Intégrer les 2 visions dans les « spécifications
techniques » ou « spécifications fonctionnelles
détaillées »
Avantages – inconvénients ? 8
Analyse / conception

ETAPE 2 : CONCEVOIR L’ARCHITECTURE

9
Concevoir l’architecture
Ce qu’on veut éviter…

10
Concevoir l’architecture
Un exemple bien réel

11
Concevoir l’architecture
Définition de l’architecture
 Architecture : ensemble de vues
 Vue (modèle) : représentation d’un ensemble d’éléments du
système et de leurs connexions possédant un intérêt pour un
acteur

Vue = [style] + éléments + connecteurs + contraintes + acteurs concernés

 Style : mode d’organisation

 Eléments
 Structure : classe / objets, composant, package, sous-système, nœud,
…
 Traitements : action / activité / processus / …
 Comportement : état, transition
 Connecteurs : associer, contenir, utiliser, est-un, …
 Acteurs concernés : utilisateur, intégrateur, architecte,
développeur, …

12
Concevoir l’architecture
QUELQUES STYLES (NAIFS) D’ARCHITECTURE

TDA

TDA : type de données abstraites (organisation modulaire)

13
Concevoir l’architecture
LE STYLE ARCHITECTURE EN COUCHE REVISITE

14
Concevoir l’architecture
Les vues intéressantes

 SCHEMAS D’INSTALLATION
 SCHEMAS DE FONCTIONNEMENT
 SCHEMAS DE FABRICATION
 Implémentation physique : livrables + éléments qui créent des livrables
 Processus de fabrication
 Correspondance entre implémentation physique et structure logique
 SCHEMAS D’ETUDE ou « LOGIQUES »
 Diagramme des packages
 Diagrammes de composants
 Diagrammes de classes
 Diagrammes de communication ou de séquence
 Base de données
 Etc ..

Voir formation ou sur le Web « modélisation orientée objet »

15
Concevoir l’architecture
Les vues intéressantes : installation 1/2

16
Concevoir l’architecture
Les vues intéressantes : installation 2/2

17
Concevoir l’architecture
Les vues intéressantes : ex Fonctionnement 1/2

18
MUA : Mail User Agent MTA : Mail Transport Agent MDA : Mail Delivery Agent
Concevoir l’architecture
Les vues intéressantes : Fonctionnement 2/2

19
Concevoir l’architecture
Les vues intéressantes : fabrication

20
Concevoir l’architecture
Les vues intéressantes : packages/composants

21
Concevoir l’architecture
Objectifs de l’architecture
 Définir l'architecture du logiciel
 Choisir un style d’architecture
 Décomposer le système en éléments : packages / sous-
systèmes / composants / classes
 Effectuant une analyse de robustesse et définir les
connexions entre ces éléments (visibilité,
responsabilités)
 Prendre en compte les contraintes
 Définir la constitution interne des éléments

Résultat : Dossier de
conception
22
Concevoir l’architecture
Architecture et changements
 Concevoir pour le changement (design for change)
 Ne pas penser au système exclusivement en fonction des
exigences actuelles
 Identifier et prendre en compte les changements exigés ou
probables
 Changements qui peuvent être exigés (STB)
 Portabilité
 Modifications des dispositifs d'E/S
 Maintenabilité ?
 Changements probables
 Nouvelles fonctionnalités
 Modifications d'algorithmes, de structures de données
 Changement du matériel, de l'OS, du SGBD, du « framework »
 Remplacement des logiciels ou des systèmes avec lesquels le
logiciel s’interface

23
Concevoir l’architecture
Décomposition en package et sous-systèmes
(hiérarchie)
Un graphe acyclique est un

graphe ne contenant aucun cycle.

24
Concevoir l’architecture
Décomposition en package et sous-systèmes
(exemple : gestion des formations)

25
Concevoir l’architecture
Connections - responsabilités

26
Concevoir l’architecture
Analyse de robustesse – classe stéréotypes

 Classe interface : interface entre le système et

l’extérieur
 Trois types : utilisateur, système, dispositif
 Une classe interface par paire acteur / cas
d’utilisation
 Classe contrôle : coordination des fonctionnalités
d’un cas d’utilisation
 Une classe contrôle pour l’application, chaque sous-
système
 Une classe contrôle par cas d’utilisation
 Plusieurs classes contrôles si cas d’utilisation
complexe
 Classe entité : gestion des concepts du système
 Provient en première approche du modèle du
domaine
 En général persistante

27
Concevoir l’architecture
Analyse de robustesse – stéréotypes de
Jacobson

28
Concevoir l’architecture
Analyse de robustesse – diagramme de
communication

29
Concevoir l’architecture
Analyse de robustesse – associations non
autorisées

30
Concevoir l’architecture
Analyse de robustesse – exemple gestion
des formations

31
Concevoir l’architecture
Analyse de robustesse – exemple gestion
des formations

32
Concevoir l’architecture
Analyse de robustesse – exemple gestion
des formations

33
Concevoir l’architecture
Analyse de robustesse – exemple gestion
des formations

34
Concevoir l’architecture
Analyse de robustesse – exemple gestion
des formations

35
Concevoir l’architecture
Définition du (bon) composant
 Partie modulaire d’une conception d’un
système qui fournit (exporte) des "services"
à d'autres composants (qui les utilisent) via
des interfaces
 Encapsule son contenu
 Possède un comportement et des états
 Utilise éventuellement les services d’autres composants
 [ Est remplaçable dans son environnement (UML2)]
 Service: ressource informatique
 Opérations (procédures, fonctions, méthodes)
 Données / types de données
 Typologie : IHM, métier, technique /
infrastructure, interface, etc.
Un composant peut être implémenté dans tout langage de programmation ! 36
Concevoir l’architecture
Représentation graphique du composant

37
Concevoir l’architecture
Connecteur « utiliser » - définition
 Composant = boîte
 Relation UTILISER les services de = arc entre boîtes
 Ressource exportée = interface fournie

38
Concevoir l’architecture
Connecteur « utiliser » - exemple Club de CD

 On s'inscrit à un Club de CD, et on accepte

d'acquérir 6 CD par an.
 Les commandes peuvent être reçues par le
Club de façon continue. Elles ne sont
cependant expédiées qu'à la fin du mois.
 Le Club vérifie chaque mois que les
adhérents dont l’abonnement arrive à
expiration ont respecté leurs engagements.

39
Concevoir l’architecture
Connecteur « utiliser » - exemple Club de
CD

40
Concevoir l’architecture
CONNECTEUR « EST COMPOSANT DE » - définition
 Si une architecture est complexe, on peut la simplifier ou
améliorer sa compréhension en regroupant plusieurs
composants dans un composant unique
 Structure d’un langage (package, classes imbriquées, namespace)
 Artifice de documentation
 La relation COMPOSANT_DE (et CONTENIR) est une
hiérarchie et implémente donc le concept de niveau

41
Concevoir l’architecture
Exemple d’utilisation des composants – 1/4

42
Concevoir l’architecture
Exemple d’utilisation des composants – 2/4

43
Concevoir l’architecture
Exemple d’utilisation des composants – 3/4

44
Concevoir l’architecture
Exemple d’utilisation des composants – 4/4

45
Concevoir l’architecture
METHODOLOGIE GENERALE DE CONCEPTION

 Approche descendante (TOP-DOWN)

 Système décomposé en sous-systèmes
 Choisir le(s) style(s) appropriés
 Itérations pour chaque sous-système, jusqu'à obtenir des composants
suffisamment simples et élémentaires pour pouvoir être implémentés
par une seule personne
 Approche ascendante (BOTTOM-UP)
 Utilisation de frameworks, de design patterns et de composants
existants
 Composants élémentaires agrégés pour former des composants de
niveau supérieur
 Approche horizontale
 La réalité :
 Utiliser au maximum des frameworks et des composants existants (sur
étagère)
 Approche mixte et …itérative

46
Concevoir l’architecture
UNE METHODE SIMPLE : LES CARTES CRC

47
CRC: Classe/Composant – Responsabilité - Collaboration
Analyse Conception

ETAPE 3 : DOCUMENTER LA CONCEPTION

48
Documenter la conception
 1Domaine d'application
 1.1 Objectifs du système
 1.2 Interfaces utilisateur, logiciels et
matériels
 1.3 Bases de données externes
 1.4 Contraintes générales de
conception
 2. Documents de Référence
 3. Normes, standards et outils
 3.1 Méthode de conception
 3.2 Environnement et outils de
développement
 3.3 Notations utilisées
 3.4 Conventions de nommage
 3.5 Standards de programmation
 4. Conception générale
 4.1 Langage(s) utilisé(s)
 4.2 Diagramme de déploiement
 4.3 [Diagramme de fonctionnement]
 4.4 [Diagramme d’implémentation]
 4.5 Diagramme des composants /
packages
 [4.6 Autres diagrammes]
 4.7 Structure des données globales,
des fichiers et des bases des données
(tables et modèles E/R)
 4.8 Stratégie de traitement des erreurs
(exceptions)
 4.9 Justification du choix d’architecture,
des composants et du langage.
5. Conception détaillée des composants

/ packages Pour chaque composant N
 5.N.1 Objectif du composant
 5.N.2 Interface détaillée
 5.N.3 Composants utilisés
 5.N.4 Données internes
 5.N.5 Traitements
 Pour chaque traitement :
 Pseudo-code des algorithmes
(PDL)
 Détection et traitement des
erreurs
 Justification du choix de
l’algorithme
 Commentaires
 5.N.6 Problèmes rencontrés et résolution
 5. Tableau d'allocation des composants
(mémoire, temps)
 6. Tableau de traçabilité (spécification
<-> conception)
49
Documenter la conception
Matrice de traçabilité

50
Documenter la conception
Normes et standards

 IEEE 1016 – 1987 : IEEE recommanded practice for

software design descriptions
 IEEE 1026.1 – 1993 : IEEE guide to software design
descriptions
 EEE 1471-2000 : IEEE Recommended practice for
architectural description of software-intensive systems
 DOD 2167A – DOD 498 – GAM T17
 ESA (ftp://ftp.estec.esa.nl/pub/wm/wme/bssc/) :
 PSS0504: Guide to the software architectural design phase
 PSS0505: Guide to the software detailed design and
production phase
 CNES (Ariane 5)

51