Post on 15-Sep-2018
Génie logiciel – Conception © 2005-2007 Renaud Marlet 1
Génie LogicielGénie Logiciel
ConceptionConception
Renaud Marlet
LaBRI / INRIA
http://www.labri.fr/~marlet
(d'après A.-M. Hugues)
màj 17/04/2007
Génie logiciel – Conception © 2005-2007 Renaud Marlet 2
Position dans le cycle de viePosition dans le cycle de vie
● Contexte :– étant donnée une spécification
(ce que doit faire le produit)● Phase de conception :
– architecture du produit(comment il est structuré pour faire ce qu'il doit faire)
→ document de conception globale / détaillée
(si cycle de vie en V : + plan d'intégration)
● Phase suivante : codage
Génie logiciel – Conception © 2005-2007 Renaud Marlet 3
Cycle de vie :Cycle de vie :modèle en V (rappel)modèle en V (rappel)
Spécifications
Conception globale
Conception détaillée
Programmation
Qualification
Tests d'intégration
Testsunitaires
(Expressiondes besoins)
(Validationdes besoins)
Génie logiciel – Conception © 2005-2007 Renaud Marlet 4
Deux niveaux de détailDeux niveaux de détail
● Conception globale (ou préliminaire)– choix fondamentaux d'architecture logicielle– en lien éventuel avec l'architecture matérielle
● Conception détaillée– description précise de chaque module– algorithmes mis en œuvre– traitements effectués en cas d'erreur
Génie logiciel – Conception © 2005-2007 Renaud Marlet 5
Conception détailléeConception détaillée
Souvent escamotée– petite taille des modules
→ description précise des algorithmes pas nécessaire
☛ Pas traitée dans ce cours
(on verra des exemples au cas par cas)
Génie logiciel – Conception © 2005-2007 Renaud Marlet 6
Objectifs de la conceptionObjectifs de la conception
● Séparation des problèmes– permet d'appréhender un problème complexe
● Décomposition modulaire du logiciel– permet le développement en parallèle (test y compris) – facilite la maintenance (corrective ou évolutive)
● documentation et isolation des comportements● localisation des modifications
– facilite la réutilisation
Génie logiciel – Conception © 2005-2007 Renaud Marlet 7
Importance de la conceptionImportance de la conception
● Influence considérable sur la réalisation du logiciel– en particulier sur la qualité
● Erreur dans la conception (mauvaise architecture)
→ édifice chroniquement branlant
→ surcoûts récurrents pour palier les défauts
Génie logiciel – Conception © 2005-2007 Renaud Marlet 8
Facteurs de qualitéFacteurs de qualitéde la conception / architecture (1)de la conception / architecture (1)
● Correction– aptitude à réaliser les tâches spécifiées
● Robustesse– aptitude à fonctionner dans des conditions anormales
● Extensibilité– aptitude à s'adapter aux changements de spécification
● Réutilisabilité– aptitude à resservir dans de nouvelles applications
Génie logiciel – Conception © 2005-2007 Renaud Marlet 9
Facteurs de qualitéFacteurs de qualitéde la conception / architecture (2)de la conception / architecture (2)
● Compatibilité– aptitude à être combinée avec d'autres logiciels
● Efficacité– bonne utilisation des ressources
● Portabilité– facilité d'adaptation à différents environnements
● Vérifiabilité– facilité à être vérifiée
Génie logiciel – Conception © 2005-2007 Renaud Marlet 10
Facteurs de qualitéFacteurs de qualitéde la conception / architecture (3)de la conception / architecture (3)
● Sécurité– Intégrité : aptitude à protéger ses composants (y
compris ses données) contre des modifications non autorisées
– Confidentialité : aptitude à masquer des informations privées (à des agents non autorisés)
– ...● ...
Génie logiciel – Conception © 2005-2007 Renaud Marlet 11
Facteurs de qualitéFacteurs de qualitéde la conception / architecture (4)de la conception / architecture (4)
☛ Les facteurs de qualité s'excluent souvent mutuellement– ex. : efficace vs. portable, sûr, ...– ex. : robuste vs. vérifiable
→ faire des compromis
Génie logiciel – Conception © 2005-2007 Renaud Marlet 12
Quelques chiffresQuelques chiffres
● Bonne conception → facilité de maintenance● Coûts de maintenance :
42% modification des besoins utilisateur / solutions proposées
18% modification du format des données
13% correction d'erreurs en urgence
9% correction d'erreurs de routine
6% modification de matériel
5% documentation
4% amélioration de l'efficacité
3% autre
Génie logiciel – Conception © 2005-2007 Renaud Marlet 13
Facilité de maintenanceFacilité de maintenance
Coût de maintenance principal = modification de spécification (60%)
→ Pouvoir effectuer les modifications de manière aussi simple que possible
→ Permettre et exploiter la traçabilité des spécifications
☛ Un outil méthodologique : la modularité
Génie logiciel – Conception © 2005-2007 Renaud Marlet 14
Plusieurs notions de modulePlusieurs notions de module
● Module logique– élément du découpage logique de la solution du
problème● Module de compilation/chargement
– bloc de code pouvant être compilé/chargé séparément– ex. : fichier C (types, variables, fonctions), classe Java
(champs, méthodes), script shell (variables, fonctions)● Module du langage de programmation
– bloc de code nommé pouvant être utilisé (appelé, ...)– ex. : fonction, classe, fichier d'inclusion C (.h), ...
Génie logiciel – Conception © 2005-2007 Renaud Marlet 15
Identifier des modulesIdentifier des modules
Objectif :– forte cohésion à l'intérieur du module– faible couplage entre les modules
30 nœuds, 66 arêtes → 2,2 arêtes par nœud
Génie logiciel – Conception © 2005-2007 Renaud Marlet 16
Identifier des modulesIdentifier des modules
Objectif : – forte cohésion à l'intérieur du module– faible couplage entre les modules
intra-module : 5 à 7 nœuds ; 2 arêtes / nœudinter-module : 5 modules ; 1,2 arêtes / module
Génie logiciel – Conception © 2005-2007 Renaud Marlet 17
Critères de modularitéCritères de modularité
(comment analyser la modularité)(comment analyser la modularité)
● Décomposabilité modulaire● Composabilité modulaire● Compréhensibilité modulaire● Continuité modulaire● Protection modulaire
☛ Pas toujours facile à satisfaire (∃ contre-exemples)
→ être pragmatique, faire au mieux
Génie logiciel – Conception © 2005-2007 Renaud Marlet 18
Décomposabilité modulaireDécomposabilité modulaire
(critère de modularité)(critère de modularité)
Définition– Le module découpe un problème complexe en
problèmes plus petits, solubles isolément
(décomposition souvent récursive)
Exemple– modules issus d'une conception descendante
Contre-exemple– module d'initialisation globale
Génie logiciel – Conception © 2005-2007 Renaud Marlet 19
Composabilité modulaireComposabilité modulaire
(critère de modularité)(critère de modularité)
Définition– Les modules peuvent facilement être utilisés et
combinés, éventuellement dans des contextes différents de ceux pour lesquels ils ont été initialement développés
Exemple– bibliothèque de sous-programmes
Génie logiciel – Conception © 2005-2007 Renaud Marlet 20
Compréhension modulaireCompréhension modulaire
(critère de modularité)(critère de modularité)
Définition– La compréhension d'un module ne nécessite pas la
compréhension des autres
Contre-exemple– dépendances séquentielles : modules conçus de
façon à fonctionner dans un certain ordre ( peu →recommandable)
Génie logiciel – Conception © 2005-2007 Renaud Marlet 21
Continuité modulaireContinuité modulaire
(critère de modularité)(critère de modularité)
Définition– Des petites modifications de spécification n'amènent
pas à revoir l'ensemble du logiciel
(~ extensibilité, évolutivité)
Exemple– constantes symboliques, références uniformes
Contre-exemple– utilisation de la représentation physique des
données, de leur adresse mémoire, ...
Génie logiciel – Conception © 2005-2007 Renaud Marlet 22
Protection modulaireProtection modulaire
(critère de modularité)(critère de modularité)
Définition– Si une condition anormale se produit pendant
l'exécution du module, elle reste localisée au module (ou à quelques modules voisins)
Exemple– validation des données d'entrées au plus tôt
Contre-exemple– exceptions inter-modules (lieu de traitement d'erreur
séparé du lieu de production de l'erreur)
Génie logiciel – Conception © 2005-2007 Renaud Marlet 23
Principes de modularitéPrincipes de modularité
(règles à respecter)(règles à respecter)
● Unités modulaires du langage● Contrôle des tailles● Découpage logique● Minimisation des interfaces● Simplification des interfaces● Interfaces explicites● Masquage de l'information
☛ Pas toujours facile à satisfaire (∃ contre-exemples) → être pragmatique, faire au mieux
Génie logiciel – Conception © 2005-2007 Renaud Marlet 24
Unités modulaires du langageUnités modulaires du langage
(principe de modularité à respecter)(principe de modularité à respecter)
Principe– module = unité syntaxique du langage– bloc de code nommé pouvant être utilisé (appelé, ...)– modules compilables séparément
→ prise en compte partielle du langage dès la conception
Exemple– classes Java, C++ ; fichier C
Contre-exemple– sous-programmes non compilables séparément
Génie logiciel – Conception © 2005-2007 Renaud Marlet 25
Contrôle des taillesContrôle des tailles
(principe de modularité à respecter)(principe de modularité à respecter)
Principe– Un module ne doit être
● ni trop gros (sinon le découper en sous-modules)● ni trop petit (sinon ça ne mérite pas d'être un module)
Exemple– trop gros : un unique module pour une API graphique– trop petit : un module pour remettre un tableau à zéro
Contre-exemple– modules naturellement gros : lecture/écriture d'image,
arithmétique entière en précision arbitraire, ...
Génie logiciel – Conception © 2005-2007 Renaud Marlet 26
Découpage logiqueDécoupage logique
(principe de modularité à respecter)(principe de modularité à respecter)
Principe– Un module doit autant que possible correspondre à
un découpage logique du problème
→ Ne pas découper arbitrairement un module sous prétexte qu'il est trop gros
Exemple– modules qui suivent un modèle conceptuel
Contre-exemple– cas de contraintes matérielles ou logicielles imposant
un découpage en petites unités
Génie logiciel – Conception © 2005-2007 Renaud Marlet 27
Minimisation des interfacesMinimisation des interfaces
(principe de modularité à respecter)(principe de modularité à respecter)
Principe– Tout module doit communiquer avec aussi peu
d'autres modules que possible– S'il y a N modules, le nombre d'interconnexions doit
être plus proche de N-1 que de N(N-1)/2
Critères– protection, continuité
Génie logiciel – Conception © 2005-2007 Renaud Marlet 28
Simplification des interfacesSimplification des interfaces
(principe de modularité à respecter)(principe de modularité à respecter)
Principe– Les modules doivent échanger aussi peu de données
que possible
Exemples– faible nombre d'arguments des fonctions/méthodes– transmission de pointeurs restreinte
Contre-exemple– variables globales
Critères– continuité, protection
Génie logiciel – Conception © 2005-2007 Renaud Marlet 29
Interfaces explicitesInterfaces explicites
(principe de modularité à respecter)(principe de modularité à respecter)
Principe– Lorsque deux modules communiquent, cela doit se
voir clairement dans le texte de l'un et/ou de l'autre
Contre-exemple– modules communicant par partage de données (ex.
variables globales) sans communication apparente (ex. appel de procédure sans argument)
Critères– décomposabilité, composabilité
Génie logiciel – Conception © 2005-2007 Renaud Marlet 30
Masquage de l'informationMasquage de l'information
(principe de modularité à respecter)(principe de modularité à respecter)
Principe– Toute information d'un module est privée, sauf son
interface explicite
Exemples– en C : n'est visible à l'extérieur d'un fichier que ce
qui est déclaré « extern » (variables, fonctions)
Critères– continuité (le contenu d'un module peut changer
sans que les autres modules doivent être modifiés)
Génie logiciel – Conception © 2005-2007 Renaud Marlet 31
Et aussi...Et aussi...
(principes de modularité à respecter)(principes de modularité à respecter)
Autres principes :– Éviter (minimiser) les dépendances circulaires
– Éviter une trop grande profondeur d'appel
– Si possible, définir des modules à comportement prévisible (dépendant uniquement des entrées, sans mémorisation interne, sans état, déterministes)
...
Génie logiciel – Conception © 2005-2007 Renaud Marlet 32
ModularitéModularité
Comment effectuer un découpage en modules ?
(étant donnés les éléments d'un dossier d'analyse des besoins)
Génie logiciel – Conception © 2005-2007 Renaud Marlet 33
Approche fonctionnelle descendanteApproche fonctionnelle descendante
À partir d'un graphe de flot de données, on dérive :– une architecture modulaire
– un graphe d'appel (→)
Principe :– concevoir les fonctions de haut niveau– affiner jusqu'à obtenir une conception suffisamment
détaillée
Génie logiciel – Conception © 2005-2007 Renaud Marlet 34
Graphe d'appelGraphe d'appel
A
B C D
E F
unité
appel
donnéetransmise
y
x u v
y zz
Attention : l'ordre des appels n'est pas représenté
w
Génie logiciel – Conception © 2005-2007 Renaud Marlet 35
Exemple : vérificateur d'orthographeExemple : vérificateur d'orthographe
Algorithme à implémenter :– extraire tous les mots d'un document
– en faire un liste triée et sans doublons
– rechercher chaque mot de la liste dans le dictionnaire● si le mot apparaît dans le dictionnaire, rien à faire● sinon, demander à l'utilisateur
– si l'utilisateur décide que le mot est correct, il est entré dans le dictionnaire
– sinon il est inclus dans la liste résultante des mots mal orthographiés
(☛ N.B. Il existe des méthodes bien plus efficaces !)
Génie logiciel – Conception © 2005-2007 Renaud Marlet 36
Diagramme de flot de donnéesDiagramme de flot de données
obtenir nom de fichier
lire etséparer en mots trier, unifier
rechercher faire confirmer
traiter mots inconnus
entréeutilisateur
nom du document
liste de mots
mots triéssans doublons
motsinconnus
réponseutilisateur
dictionnaire
mots inconnus
nouveauxmots
documents
mots malorthographiés
entréeutilisateur
Génie logiciel – Conception © 2005-2007 Renaud Marlet 37
Un exemple de graphe d'appel Un exemple de graphe d'appel (très plat)(très plat)
vérifierorthographe
obtenir nomde fichier
lire et sépareren mots
trier etunifier
traiter motsinconnus
rechercherdans dico
nomfichier mots mots
triés
motsinconnus
faireconfirmer
motsinconnus
réponseutilisateur
Génie logiciel – Conception © 2005-2007 Renaud Marlet 38
Un exemple deUn exemple de(mauvais) graphe d'appel(mauvais) graphe d'appel
vérifier fichierobtenir nom de fichier
lire et séparer en mots
trier et unifier
traiter mots inconnus
gérer mots inconnus
faire confirmer
vérifier orthographe
vérifier mots
rechercher dans dico
vérifier avec dico
Génie logiciel – Conception © 2005-2007 Renaud Marlet 39
Un autre exemple deUn autre exemple de(mauvais) graphe d'appel(mauvais) graphe d'appel
trouver mots mal othographiés
obtenir nom de fichier lire et séparer en mots
trier et unifier
traiter mots inconnus
trouver mots inconnus faire confirmer
vérifier orthographe
obtenir mots triés et unifiés rechercher dans dico
obtenir mots
Génie logiciel – Conception © 2005-2007 Renaud Marlet 40
Un autre exemple de (meilleur) Un autre exemple de (meilleur) graphe d'appelgraphe d'appel
vérifierorthographe
obtenirmots
lire et sépareren mots
trier etunifier
mettre à jourdico
compulserdico
nomfichier
mots
motstriés
motsinconnus
obtenir nomde fichier
mots
mots
rechercherdans dico
traiter motsinconnus
faireconfirmer
motsinconnus
motsinconnus
motsinconnusmots
réponseutilisateur
nouveauxmots
Génie logiciel – Conception © 2005-2007 Renaud Marlet 41
Approches descendantes, Approches descendantes, montantes, et réutilisationmontantes, et réutilisation
– Approches descendantes (top-down)● fournissent un découpage (au moins logique)
d'un problème complexe● mais ne se préoccupent pas de réutilisabilité
(indépendance des parties découpées)
– Approches montantes (bottom-up)● définition de composants simples et de leur composition● plus grand souci de réutilisabilité● pertinence incertaine : pas de garantie de
– l'existence d'un véritable besoin de réutilisation– le convergence vers une solution du problème
Génie logiciel – Conception © 2005-2007 Renaud Marlet 42
Approche fonctionnelle descendanteApproche fonctionnelle descendante
Il existe une méthode « mécanique »– employée dans l'industrie
Mais si employée trop mécaniquement :– ignore types abstraits (↓) et masquage de l'information
– grande sensibilité aux petits changements– difficile d'isoler des sous-systèmes communs– difficile de réutiliser des composants disponibles
... car trop détachée de la nature logique du programme
Génie logiciel – Conception © 2005-2007 Renaud Marlet 43
Critique de l'approche Critique de l'approche fonctionnelle descendantefonctionnelle descendante
Ce qui se passe souvent en pratique :– on garde une décomposition vague
● espoir d'une clarification près des feuilles● résolution du problème en même temps qu'est structurée
la solution
– quand on s'approche des feuilles, on commence à ajouter plein de hacks () pour que la décomposition tienne
● introduction d'un couplage fort (sensibilité au changement)
→ échec possible
Génie logiciel – Conception © 2005-2007 Renaud Marlet 44
MéthodologieMéthodologie
● Garder l'esprit de l'analyse descendante– concevoir les abstractions (↓) de haut niveau
– affiner jusqu'à une conception suffisamment détaillée● Mais appliquer des heuristiques
– s'appuyer sur le modèle conceptuel– découper en modules de même niveau d'abstraction – veiller à respecter tous les principes de modularité
● Si de la réutilisabilité est recherchée– combiner avec un peu d'approche montante
Génie logiciel – Conception © 2005-2007 Renaud Marlet 45
Les données d'abordLes données d'abord
ImportantImportant résultat de l'expérience :– Le plus souvent, il vaut mieux organiser un système
autour des données qu'autour des fonctions
→ Importance du lien avec le modèle conceptuel– objets, attributs, opérations pour les manipuler
→ Programmation orientée objet (OO)
Génie logiciel – Conception © 2005-2007 Renaud Marlet 46
(Parenthèse)(Parenthèse)
☛ Notions de programmation orientée objet ()
– idées les plus importantes– exemples en Java– comment faire de la programmation objet en C
Génie logiciel – Conception © 2005-2007 Renaud Marlet 47
Type abstrait (1)Type abstrait (1)
● Un type– déclaration/définition selon le langage– ex. : interface Java, (pointeur vers) structure C
● Une interface– déclaration de constantes d'un certain type et de
fonctions (publiques) qui opèrent sur des objets de ce type
– ex. : interface Java, fichier d'inclusion « .h »
Génie logiciel – Conception © 2005-2007 Renaud Marlet 48
Type abstrait (2)Type abstrait (2)
● Une (ou plusieurs) implémentation qui satisfait l'interface– définition des constantes et fonctions (publiques) – autres données et fonctions invisibles (privées)– ex. : classe Java, fichier « .c » qui implémente « .h »
Génie logiciel – Conception © 2005-2007 Renaud Marlet 49
Type abstrait (3)Type abstrait (3)
Intérêt– on peut modifier le contenu d'une implémentation
sans changer ses utilisations (via l'interface)– on peut remplacer une implémentation par une autre
(par ex. plus efficace, suivant le contexte)
☛ = notion très importantetrès importante en génie logiciel
Génie logiciel – Conception © 2005-2007 Renaud Marlet 50
Méthodes de conceptionMéthodes de conceptionorientée objetorientée objet
Méthode de Booch (1986) :– définir le problème ( )→– développer une stratégie informelle de résolution– identifier les objets et leurs attributs– identifier les opérations sur ces objets– établir les interfaces pour ces opérations– implémenter les objets– éventuellement répéter le processus récursivement
Génie logiciel – Conception © 2005-2007 Renaud Marlet 51
Définition du problèmeDéfinition du problème(méthode de Booch)(méthode de Booch)
– Définir le problème en une seule phrase grammaticalement correcte
● ex. « compter les feuilles d'un arbre binaire complet »
– Se concentrer sur ce qui est vraiment important– Ne pas essayer de résoudre le problème– Éviter les phrases imprécises
Génie logiciel – Conception © 2005-2007 Renaud Marlet 52
Stratégie informelle (1)Stratégie informelle (1)(méthode de Booch)(méthode de Booch)
– Exprimer les éléments essentiels de la solution en un seul « paragraphe » grammaticalement correct
– (S'exprimer dans un langage compris de tous)– (Pas plus de quelques heures)– Ce travail doit être revu et corrigé
Génie logiciel – Conception © 2005-2007 Renaud Marlet 53
Stratégie informelle (2)Stratégie informelle (2)(méthode de Booch)(méthode de Booch)
Compter les feuilles d'un arbre binaire complet :– Maintenir une pile des parties d'arbre qui n'ont pas
encore été comptées. Initialement obtenir un arbre et le mettre sur une pile vide ; le compteur de feuilles est initialisé à zéro. Tant que la pile n'est pas vide, enlever un arbre de la pile et l'examiner. Si l'arbre consiste en une seule feuille, incrémenter le compteur de feuilles et jeter cet arbre. Sinon, l'arbre possède deux sous-arbres ; séparer l'arbre en son sous-arbre droit et son sous-arbre gauche, et remettre ces arbres sur la pile. Une fois que la pile est vide, imprimer le compteur de feuilles.
Génie logiciel – Conception © 2005-2007 Renaud Marlet 54
Stratégie informelle (3)Stratégie informelle (3)(méthode de Booch)(méthode de Booch)
Compter les feuilles d'un arbre binaire complet● Maintenir une pile des parties d'arbre qui n'ont pas encore
été comptées.● Initialement obtenir un arbre et le mettre sur une pile vide ;
le compteur de feuilles est initialisé à zéro.● Tant que la pile n'est pas vide, enlever un arbre de la pile
et l'examiner.– Si l'arbre consiste en une seule feuille, incrémenter le compteur
de feuilles et jeter cet arbre.– Sinon, l'arbre possède deux sous-arbres ; séparer l'arbre en son
sous-arbre droit et son sous-arbre gauche, et mettre ces arbres sur la pile.
● Une fois que la pile est vide, imprimer le compteur de feuilles.
Génie logiciel – Conception © 2005-2007 Renaud Marlet 55
Identification des objets et attributsIdentification des objets et attributs(méthode de Booch)(méthode de Booch)
● Souligner dans le texte les formes nominales– ex., « la mise à jour des capteurs est effectuée chaque seconde »
● Éliminer les noms qui ne font pas partie du domaine de la solution– ex. seconde
● Considérer comme opération les noms représentant une activité– ex. mise à jour
● Les noms qui restent correspondent à des objets– ex. capteur
● Regrouper les objets de même type● Associer des identificateurs aux objets (conventions de nommage)● Associer des attributs aux objets et aux types (adjectifs)
– ex., « les capteurs sont lus toutes les 100 ms » : fréquence de lecture
Génie logiciel – Conception © 2005-2007 Renaud Marlet 56
Isoler les noms et adjectifsIsoler les noms et adjectifs(méthode de Booch)(méthode de Booch)
Compter les feuilles d'un arbre binaire complet● Maintenir une pile des parties d'arbre qui n'ont pas encore
été comptées.● Initialement obtenir un arbre et le mettre sur une pile vide ;
le compteur de feuilles est initialisé à zéro.● Tant que la pile n'est pas vide, enlever un arbre de la pile
et l'examiner.– Si l'arbre consiste en une seule feuille, incrémenter le compteur
de feuilles et jeter cet arbre.– Sinon, l'arbre possède deux sous-arbres ; séparer l'arbre en son
sous-arbre droit et son sous-arbre gauche, et mettre ces arbres sur la pile.
● Une fois que la pile est vide, imprimer le compteur de feuilles.
Génie logiciel – Conception © 2005-2007 Renaud Marlet 57
Identification des objets et attributsIdentification des objets et attributs(méthode de Booch)(méthode de Booch)
● Objets● Noms :
– compteur de feuilles, pile, feuille, arbre, sous-arbre, partie d'arbre● Objets :
– compteur_de_feuilles, pile, arbre
● Attributs● Adjectifs :
– vide (pile), gauche (sous-arbre), droit (sous-arbre), seule (feuille)● Attributs :
– pile : est_vide [→ booléen]– arbre : a_une_seule_feuille [→ booléen], sous-arbre_gauche
[→ arbre], sous-arbre_droit [→ arbre]
Génie logiciel – Conception © 2005-2007 Renaud Marlet 58
Identification des opérationsIdentification des opérations(méthode de Booch)(méthode de Booch)
● Souligner les formes verbales– elles correspondent à des opérations
(sauf être / avoir / appartenance → attributs)● Associer un identificateur à chaque opération
– convention de nommage● Associer à chaque opération un objet ou un type (sur lequel
elle est effectuée)– ex. « mettre la chaîne de caractère dans la liste » : opération sur
une liste, pas sur une chaîne ni sur un caractère● Associer des conditions et attributs aux opérations en
examinant les compléments et formes adverbiales– ex., « déclencher l'alarme quand les valeurs sont trop hautes »
● Identifier les relations entre opérations– ex., « allouer un buffer à l'ouverture d'un fichier »
Génie logiciel – Conception © 2005-2007 Renaud Marlet 59
Isoler les formes verbalesIsoler les formes verbales(méthode de Booch)(méthode de Booch)
Compter les feuilles d'un arbre binaire complet● Maintenir une pile des parties d'arbre qui n'ont pas encore
été comptées.● Initialement obtenir un arbre et le mettre sur une pile vide ;
le compteur de feuilles est initialisé à zéro.● Tant que la pile n'est pas vide, enlever un arbre de la pile
et l'examiner.– Si l'arbre consiste en une seule feuille, incrémenter le compteur
de feuilles et jeter cet arbre.– Sinon, l'arbre possède deux sous-arbres ; séparer l'arbre en son
sous-arbre droit et son sous-arbre gauche, et mettre ces arbres sur la pile.
● Une fois que la pile est vide, imprimer le compteur de feuilles.
Génie logiciel – Conception © 2005-2007 Renaud Marlet 60
Identification des opérationsIdentification des opérations(méthode de Booch)(méthode de Booch)
● Opérations● Verbes :
– initialement obtenir (un arbre), mettre sur (la pile), initialiser à zéro (le compteur), enlever (un arbre de la pile), examiner (un arbre), incrémenter (le compteur), jeter (arbre), séparer (arbre)
– consister en (une seule feuille), posséder (deux sous-arbres)● Opérations
– pile : empiler (arbre), dépiler (arbre)– compteur_de_feuilles : initialiser_à_zéro, incrémenter, imprimer
● Attributs (rappel)– pile : est_vide [→ booléen]– arbre : a_une_seule_feuille [→ booléen], sous-arbre_gauche
[→ arbre], sous-arbre_droit [→ arbre]
Génie logiciel – Conception © 2005-2007 Renaud Marlet 61
Spécification et regroupementSpécification et regroupement(méthode de Booch)(méthode de Booch)
– Définir les spécifications des types, objets et opérations visibles
– Déterminer les dépendances et l'imbrication des unités (ex. objets inclus dans d'autres)
– Identifier les regroupements possibles (ex. opérations sur un même type d'objet)
– Rechercher l'héritage (objets et types d'objets admettant plus ou moins d'opérations) et la généricité (parties communes des objets et opérations, et parties variables paramétrables)
Génie logiciel – Conception © 2005-2007 Renaud Marlet 62
Analyse et clarificationAnalyse et clarification(méthode de Booch)(méthode de Booch)
– Examiner les variantes possibles (identifications,
regroupements)– Expliquer les choix de conception– Donner toutes les indications nécessaires à la
réalisation
Génie logiciel – Conception © 2005-2007 Renaud Marlet 63
Autres méthodes...Autres méthodes...(non détaillées ici)(non détaillées ici)
● Merise (MCD)● HOOD (Hierarchical Object Oriented Design)● Modèles à trois plans :
(plans structure, communication, comportement)
(vue temps-contrôle, vue fonctionnelle, vue données)– OMT– OOA-OOD Shlaer et Mellor
Génie logiciel – Conception © 2005-2007 Renaud Marlet 64
Remarques sur la phase de Remarques sur la phase de conceptionconception
● Analyse des besoins et conception sont étroitement mêlées– point de départ : formulation du problème– élaboration/formulation d'une solution– structuration logicielle de cette solution
● C'est le cas également avec UML ( )→
Génie logiciel – Conception © 2005-2007 Renaud Marlet 65
UMLUML
● Langage de modélisation– UML = Unified Modeling Language– notations normalisées
● Pour la résolution de problèmes orientée objet– Mais c'est une notation, pas une méthode !
Génie logiciel – Conception © 2005-2007 Renaud Marlet 66
ModèleModèle
Modèle = abstraction du problème sous-jacent– objets qui interagissent par envoi de messages– attributs des objets (valeurs → état de l'objet)– opérations/comportements des objets– objets de mêmes type = instances d'une classe
Génie logiciel – Conception © 2005-2007 Renaud Marlet 67
(Principaux) diagrammes UML(Principaux) diagrammes UML
– Diagramme de cas d'utilisation (use case)– Diagramme de classe– Diagramme d'objet– Diagramme de séquence– Diagramme de collaboration– Diagramme d'états (statechart)– Diagramme d'activité– Diagramme de composants– Diagramme de déploiement
Génie logiciel – Conception © 2005-2007 Renaud Marlet 68
Diagramme de cas d'utilisation (1)Diagramme de cas d'utilisation (1)
~ Scénario● Ce que le système fait, vu de l'extérieur● Le « quoi », pas le « comment »● Ex. : prise de rendez-vous à la clinique
(d'après Borland)
Génie logiciel – Conception © 2005-2007 Renaud Marlet 69
Diagramme de cas d'utilisation (2)Diagramme de cas d'utilisation (2)(d'après Borland)
Génie logiciel – Conception © 2005-2007 Renaud Marlet 70
Diagramme de cas d'utilisation (3)Diagramme de cas d'utilisation (3)
● Expression de besoins/exigences [angl. requirements]
– nouveau cas d'utilisation → nouvelles exigences● Communication aisée avec le client
– simplicité de notation● Génération de tests
– ensemble de scénarios → ensemble de cas de test
Génie logiciel – Conception © 2005-2007 Renaud Marlet 71
Diagramme de classe (1)Diagramme de classe (1)
● Aperçu du système– classes et relations entre elles
● Vue statique– existence d'interactions mais pas d'information sur
le comportement effectif
Génie logiciel – Conception © 2005-2007 Renaud Marlet 72
Diagramme de classe (2)Diagramme de classe (2)
Ex. : commande client pour une vente au détail
aggregation
(d'après Borland)
Génie logiciel – Conception © 2005-2007 Renaud Marlet 73
Diagramme de packageDiagramme de package
Package = collection d'éléments reliés logiquement
(d'après Borland)
Génie logiciel – Conception © 2005-2007 Renaud Marlet 74
Diagramme d'objets (1)Diagramme d'objets (1)
● Montre les instances et non les classes● Utile pour expliquer les relations récursives● Ex. : département d'université pouvant
comporter des (sous-(sous-))départements– diagramme de classe :
(d'après Borland)
Génie logiciel – Conception © 2005-2007 Renaud Marlet 75
Diagramme d'objets (2)Diagramme d'objets (2)
Instantiation du diagramme de classe précédent
(d'après Borland)
Génie logiciel – Conception © 2005-2007 Renaud Marlet 76
Diagramme de séquence (1)Diagramme de séquence (1)
● Diagramme d'interaction : vue dynamique– comment les objets collaborent entre eux
● Déroulement des opérations– quelles opérations et quand
● Ex. : réservation d'une chambre d'hôtel (→)
Génie logiciel – Conception © 2005-2007 Renaud Marlet 77
Diagramme de séquence (2)Diagramme de séquence (2)(d'après Borland)
Génie logiciel – Conception © 2005-2007 Renaud Marlet 78
Diagramme de collaboration (1)Diagramme de collaboration (1)
● Diagramme d'interaction : vue dynamique– comment les objets collaborent entre eux
● Focalisation sur le rôle des objets– (pas sur le temps ou l'ordre)
● Ex. : réservation d'une chambre d'hôtel (→)
Génie logiciel – Conception © 2005-2007 Renaud Marlet 79
Diagramme de collaboration (2)Diagramme de collaboration (2)(d'après Borland)
Génie logiciel – Conception © 2005-2007 Renaud Marlet 80
Diagramme d'état (1)Diagramme d'état (1)
● Vue du comportement et des états des objets– états, et transitions qui créent des changements
d'état
= diagramme états-transitions vu précédemment (cf. cours sur l'analyse des besoins)
● Ex . : login sur un système bancaire– entrée du numéro de sécurité sociale (SSN)
[Social Security Number]
– numéro d'identification (code PIN)[Personal Identification Number]
Génie logiciel – Conception © 2005-2007 Renaud Marlet 81
Diagramme d'état (2)Diagramme d'état (2)(d'après Borland)
Génie logiciel – Conception © 2005-2007 Renaud Marlet 82
Diagramme d'activité (1)Diagramme d'activité (1)
● Flot d'activité d'un processus (et non d'un objet)– fork et join
● Dépendances entre activités● Ex. retrait d'argent dans un distributeur
Génie logiciel – Conception © 2005-2007 Renaud Marlet 83
Diagramme d'activité (2)Diagramme d'activité (2)(d'après Borland)
Génie logiciel – Conception © 2005-2007 Renaud Marlet 84
Diagramme de déploiement (1)Diagramme de déploiement (1)
● Configuration physique logicielle et matérielle● Ex. : transaction immobilière
Génie logiciel – Conception © 2005-2007 Renaud Marlet 85
Diagramme de déploiement (2)Diagramme de déploiement (2)(d'après Borland)
Génie logiciel – Conception © 2005-2007 Renaud Marlet 86
UML et précisionUML et précision
Tous les niveaux de formalisation :– informel : cas d'utilisation– semi-formel : modèles statiques et dynamiques– formel : OCL (object constraint language)
Génie logiciel – Conception © 2005-2007 Renaud Marlet 87
UML et cycle de vieUML et cycle de vie
● Définition des besoins :– diagramme de cas d'utilisation
● Analyse des besoins– diagrammes d'état, d'activité
● Conception– diagrammes d'état, d'activité– diagrammes de classe, d'objet, de package– diagrammes de séquence, de collaboration– diagrammes de déploiement
Génie logiciel – Conception © 2005-2007 Renaud Marlet 88
ÀÀ retenir retenir
● Conception– séparation des problèmes / décomposition modulaire
● Méthodologie– globalement descendante, parfois montante
● Principes de modularité à respecter– découpage logique ; taille équilibrée ; masquage de
l'information ; interface minimale, simple et explicite● Organiser le système autour des données (!)(!)
– Notion de type abstrait● UML : notations normalisées, vues différentes