Génie Logiciel - IMAGINEimagine.enpc.fr/~marletr/LaBRI/teaching/GenLog/slides/GenLog... · Génie logiciel – Conception © 2005-2007 Renaud Marlet 4 Deux niveaux de détail Conception

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


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


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)


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


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)


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


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


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



● 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



● 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)

– ...● ...



☛ Les facteurs de qualité s'excluent souvent mutuellement– ex. : efficace vs. portable, sûr, ...– ex. : robuste vs. vérifiable

→ faire des compromis


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


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é


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), ...


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


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


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


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


Composabilité modulaireComposabilité modulaire


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


Compréhension modulaireCompréhension modulaire


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)


Continuité modulaireContinuité modulaire


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, ...


Protection modulaireProtection modulaire


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)


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


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


Contrôle des taillesContrôle des tailles


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, ...


Découpage logiqueDécoupage logique


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


Minimisation des interfacesMinimisation des interfaces


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é


Simplification des interfacesSimplification des interfaces


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


Interfaces explicitesInterfaces explicites


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é


Masquage de l'informationMasquage de l'information


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)


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)

...


ModularitéModularité

Comment effectuer un découpage en modules ?

(étant donnés les éléments d'un dossier d'analyse des besoins)


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


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


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 !)


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


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


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


gérer mots inconnus

faire confirmer

vérifier orthographe

vérifier mots

rechercher dans dico

vérifier avec dico


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


trouver mots inconnus faire confirmer

vérifier orthographe

obtenir mots triés et unifiés rechercher dans dico

obtenir mots


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


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


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


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


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


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)


(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


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 »



● 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 »



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


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


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


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é



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.



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.


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


Isoler les noms et adjectifsIsoler les noms et adjectifs(méthode de Booch)(méthode de Booch)









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]


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 »


Isoler les formes verbalesIsoler les formes verbales(méthode de Booch)(méthode de Booch)









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]


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)


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


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


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 ( )→


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 !


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


(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


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)


Diagramme de cas d'utilisation (2)Diagramme de cas d'utilisation (2)(d'après Borland)


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


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


Diagramme de classe (2)Diagramme de classe (2)

Ex. : commande client pour une vente au détail

aggregation

(d'après Borland)


Diagramme de packageDiagramme de package

Package = collection d'éléments reliés logiquement

(d'après Borland)


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)


Diagramme d'objets (2)Diagramme d'objets (2)

Instantiation du diagramme de classe précédent

(d'après Borland)


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 (→)


Diagramme de séquence (2)Diagramme de séquence (2)(d'après Borland)


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 (→)


Diagramme de collaboration (2)Diagramme de collaboration (2)(d'après Borland)


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]


Diagramme d'état (2)Diagramme d'état (2)(d'après Borland)


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


Diagramme d'activité (2)Diagramme d'activité (2)(d'après Borland)


Diagramme de déploiement (1)Diagramme de déploiement (1)

● Configuration physique logicielle et matérielle● Ex. : transaction immobilière


Diagramme de déploiement (2)Diagramme de déploiement (2)(d'après Borland)


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)


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


ÀÀ 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

Documents

Génie Logiciel - IMAGINEimagine.enpc.fr/~marletr/LaBRI/teaching/GenLog/slides/GenLog... · Génie logiciel – Conception © 2005-2007 Renaud Marlet 4 Deux niveaux de détail Conception