Mod

1
Modélisation et Génie logiciel

• 4 TC
• Frédérique Laforest, Frédéric Le Mouël

2
Objectifs du cours

• Connaître les principes du génie logiciel et
  leurs intérêts, connaitre les outils du génie
  logiciel
• Connaître les principes objet
• Savoir lire et mener une conception de système
  dinformation avec les modèles dUML
• Connaître les principes des Design Patterns, leur
  intérêt ainsi que les plus reconnus

3
Plan global

• Introduction
• Génie logiciel
• UML
• Design Patterns

4
? Outils

• Partie faite par F Le Mouël

5
? Génie logiciel

• 1 Introduction
• 2 Cycle de vie, prototype
• 3 Normalisation
• 4 Tests
• 5 Refactoring

6
1- Introduction Caractéristiques du logiciel

• Produit unique
• conçu et fabriqué une seule fois, reproduit
• Inusable
• défauts pas dus à l'usure mais proviennent de sa
  conception
• Complexe
• le logiciel est fabriqué pour soulager l'humain
  d'un problème complexe il est donc par nature
  complexe
• Invisible
• Fabrication du logicielactivité purement
  intellectuelle
• difficulté de perception de la notion de qualité
  du logiciel
• Technique non mature
• encore artisanal malgré les progrès

7
Constats

• Le coût du développement du logiciel dépasse
  souvent celui du matériel,
• Les coûts dans le développement du logiciel
• 20 pour le codage et la mise au point
  individuelle,
• 30 pour la conception,
• 50 pour les tests d'intégration,
• Durée de vie d'un logiciel de 7 à 15 ans,
• Le coût de la maintenance évolutive et corrective
  constitue la part prépondérante du coût total ,
• Plus de la moitié des erreurs découvertes en
  phases de tests proviennent d'erreurs introduites
  dans les premières étapes,
• La récupération d'une erreur est d'autant plus
  coûteuse que sa découverte est tardive.

8
Les plaintes classiques des clients

• Non respect du cahier des charges,
• Délais et coûts dépassant les prévisions,
• Maintenance corrective et évolutive difficiles,
• Non respect des performances,
• Documentations absentes ou peu claires,
• Fiabilité discutable.
• QUALITE du logiciel, Génie logiciel

9
Génie logiciel

• Ensemble des activités de conception et de mise
  en œuvre des produits et des procédures tendant à
  rationaliser la production du logiciel et son
  suivi.
• Arrêté ministériel du 30/12/1983
• Procédures, méthodes, langages, ateliers, imposés
  ou préconisés par les normes, adaptés à
  l'environnement d'utilisation afin de favoriser
  la production et la maintenance de composants
  logiciels de qualité.
• P. Jaulent

10
Concevoir un SI

• Concevoir se représenter par la pensée,
  comprendre
• La conception mélange de problèmes
• conceptuels (modèles, formalismes),
• organisationnels (structure de l'entreprise),
• techniques (matériel, logiciel),
• économiques (coûts, gains),
• sociaux (changement d'emploi, technicité,
  formation)
• En plus, l'entreprise ne s'arrête pas
• concevoir dans une organisation
• en fonctionnement,
• en perpétuelle évolution.

11
Concevoir un SI

• Cest utiliser une démarche bien gérée
• Pas de travail empirique
• Mais un projet à conduire
• Utiliser une méthode
• Méthode réponse aux questions
• que faire ?
• quand ?
• où ?
• avec qui ?
• comment ?

12
Modèles, méthodes et outils pour les SI

• Modèles
• ensemble de concepts permettant de construire une
  représentation de l'entreprise
• Démarche (Méthode)
• ensemble coordonné de règles opératoires qui
  permet de résoudre un problème en accord avec les
  modèles
• découpe le projets en étapes à suivre
• spécifier, concevoir, développer, tester,
  implanter, maintenir
• Outils logiciels
• ensemble des aides (logiciels) que l'ordinateur
  fournit dans le processus de conception on
  parle d'Atelier Génie Logiciel (AGL) ou Computer
  Aided System Engineering (CASE)

13
2- Cycle de vie les étapes du logiciel
Compréhension du problème et des besoins
Analyse (spécification des besoins)
Description de ce que le système doit faire Le
que faire
conception préliminaire (spécifications)
Le comment faire algorithmes...
conception détaillée
Développement des sources et tests des portions
Codage et tests unitaires
Assemblage planifié des portions, conformité par
rapport aux besoins
Intégration et validation
Vérification de réponse aux spécifications,
performances
Recette
Exploitation et maintenance
Utilisation du logiciel, maintenance corrective
et évolutive
14
Cycle de vie en cascade
Analyse
conception
Codage
Tests
Chaque étape validée n'est plus remise en
cause Ne prend pas en compte l'intégralité du
cycle de vie
15
Modèle en V
Spécification du système et des besoins
Livraison du système
Modèle utilisateur
Conception du système
Test du système
Modèle architectural
Spécification des sous-systèmes
Test des sous-systèmes
Conception des modules
Test des modules
Construction
Modèle d'implantation
16
Modèle de la fontaine
Maintenance
Développements ultérieurs
Utilisation
Test du logiciel
Codage
Conception
Spécification caractéristiques
Spécification besoins
Analyse besoins
Processus incrémental et itératif Chaque étape
peut fournir des résultats modifiant le résultats
des précédentes
17
Modèle en spirale Prototype incrémental
Coût cumulatif
Déterminer les objectifs, les alternatives, les
contraintes
Evaluer les alternatives Identifier et éviter les
risques
Analyse des risques
Revue critique
Proto opérationnel
proto3
proto2
proto1
Progresser par étapes
Prévision besoins projet
Concevoir opérations
Simul.
Modèles
Benchmarks
Spec. besoins
Organisation développement
Conception
Conception détaillée
Intégration et test de l'organisation du projet
Valider conception
Codage
Tests
Organiser les phases suivantes
Accepter tests
Développer et vérifier le prochain niveau du
produit
18
Prototype

• Des buts différents
• fabrication incrémentale du produit
• partir d'une version très allégée
• progressivement ajouter des fonctionnalités
• prototype "produit"
• démonstration de la faisabilité
• implanter une partie des fonctionnalités
• montrer que possible
• prototype "jetable"
• NB maquette
• présentation de l'interface utilisateur, ne
  fonctionne pas

19
3- Normalisation

• A de nombreux niveaux
• Nommage des variables, classes, packages
• Plan-type des documents rédigés (specs, dev,
  tests)
• Numérotation des versions (releases)
• But pérenniser le travail effectué, gagner du
  temps par la suite
• Savoir où chercher quelle info
• Comprendre la structure à partir des libellés
  (noms de classes, variables, titres de
  chapitres)
• Chaque organisation / projet a sa norme

20
Exemple numérotation releases

• Pour le noyau Linux (qui sert souvent de modèle)
  http//en.wikipedia.org/wiki/Linux_kernelVersio
  nsVersion.Majeure.Mineure.Révision
• Fev 06 2.6.15.4
• Changement de
• Version modification radicale de la conception.
• Majeure incompatibilité arrière (gros
  changements). De plus, n pair version stable
  et n impair version de dev.
• Mineure modifications du code source comme
  ajout de fonctionnalité, correction de bugs, etc.
• Révision modification mineure qui ne nécessite
  pas forcément une maj.

21
Exemple numérotation releases

• packages Gentoo, la Révision correspond au -rXX
  eix firefox-bin     www-client/mozilla-firef
  ox-bin         Available versions   1.0.7  
  1.5-r2   1.5.0.1
• NB Gentoo remplace peu à peu les -rXX par un 4e
  chiffre, comme pour le noyau Linux.
• NB2 signifie instable parfois M pour
  masked (en cours de dev!)
• Chez d'autres projets, il n'y a qu'un numéro pour
  Version Majeure eix emacs -a -C
  app-editors     app-editors/emacs        
  Available versions   18.59   21.4-r1
• Chez d'autres encore, il n'y a qu'un numéro tout
  court eix xterm     x11-terms/xterm      
    Available versions   204   207   208

22
Mesurer la qualité dun logiciel

• Il faut définir des  choses  à mesurer
• Les mesures peuvent être qualitatives ou
  quantitatives
• Elles doivent être explicites!
• Approche de Mc Call
• Plan assurance qualité

23
Approche de Mc Call assurance qualité

• Facteurs (11) qualité vue de l'utilisateur
• Critères (23) qualité vue du réalisateur
• Mesures (176) qualité vue du contrôle
• Liaisons (facteur -gt critères -gt mesures)
  intuitives
• Exemple
• facteur fiabilité
• critères cohérence, robustesse simplicité
• mesures présence d'une administration des
  données, couverture des tests, taux de panne...

24
Facteurs de Mc Call

• Conformité
• Fiabilité
• Intégrité
• Maniabilité
• Maintenabilité
• Testabilité
• Evolutivité
• Réutilisabilité
• Portabilité
• Efficacité
• Couplabilité

On pourrait ajouter (France Télécom) confidentiali
té auditabilité intégrabilité
25
Critères de Mc Call
Indépendance vis à vis du système Indépendance
vis à vis du matériel Instrumentation (traces
fonctionnement) Efficacité de stockage Modularité
Précision Contrôle des accès Rapidité Tolérance
aux pannes Simplicité Traçabilité Vérification
des accès
Autodescription Standardisation des
données Standardisation des interfaces Généralité
Clarté Concision Complétude Extensibilité Facilité
d'apprentissage Facilité d'utilisation Homogénéit
é
26
Plan assurance qualité logicielle

• Document "contractuel" énonçant les modes
  opératoires, les ressources, la séquence des
  activités liées à la qualité, se rapportant à un
  produit, service, contrat ou projet particulier.
• Préciser les responsabilités des différents
  partenaires
• Différentes actions d'assurance et de contrôle de
  qualité
• Déterminer les produits attendus et les critères
  d'acceptation du logiciel
• Prévoir l'organisation de la recette des
  sous-produits
• Définir les rôles et les responsabilités des
  experts internes et externes (audit, sécurité,
  ergonomie)
• ...

27
4- Tests du logiciel

• Test technique de contrôle consistant à
  s'assurer, grâce à l'exécution d'un programme,
  que son comportement est conforme à un
  comportement de référence préalablement formalisé
  dans un document
• Le test sert à prouver l'existence d'erreurs
  plutôt que leur absence!

28
E-mail de M. Arnoldi à K. Beck (traduit)

•  Malheureusement, pour moi en tout cas (et pas
  seulement pour moi), les tests vont à lencontre
  de la nature humaine. Quand on lâche le porc
  quon a en soi, on saperçoit quon est capable
  de programmer sans tests. Ce nest quau bout
  dun moment que notre côté rationnel regagne le
  dessus, et quon commence à écrire des tests.
  la programmation en binômes réduit la probabilité
  que les deux partenaires lâchent leur porc
  respectif au même moment. 

29
Tests dans le cycle de vie

• Les tests sont écrits lors de la rédaction des
  spécifications!
• Spécification fonctionnelle -gt tests de
  validation
• Conception préliminaire -gt tests d'intégration
• Conception détaillée -gt tests unitaires (par
  module)

30
Spécifier une fonction

• Ne pas regarder comment elle fait
• Mais préciser
• QUOI elle doit faire (description)
• Dans quel contexte (pré-conditions)
• Avec quel résultat (post-conditions)
• On peut donc, avant de réfléchir au comment faire
• Donner lensemble des cas dutilisation
• En déduire la liste des tests à faire et les
  coder
•  les tests me donnent une occasion de réfléchir
  à ce que je veux obtenir sans considération de la
  façon dont je vais implémenter 

31
Types de tests

• Unitaires ceux du programmeur
• Tests fonction par fonction
• doivent être positifs à 100 sur le code passé et
  courant
• Tests dintégration ceux du concepteur
• groupent plusieurs fonctions
• Tests fonctionnels ceux du client
• Tests scénario par scénario
• Tant que produit non fini, pas forcément positif
  à 100

32
Types de tests

• Autres
• Tests parallèles valider que la nouvelle
  version fait exactement comme la précédente
• Tests en charge
• Tests du singe un ingénu (naive in english) se
  sert du système et fait nimporte quoi
• Boîte noire ou boîte blanche?
• Test boîte noire test fonctionnement sans
  aller voir à l'intérieur, répond-il au besoin?
• Test boîte blanche test structurel en allant
  voir sa composition, répond-il Bien au besoin?

33
Classes de tests

• Test des cas normaux
• utilisation normale du logiciel
• Test des cas anormaux
• exemples
• vérification des données en entrée
• validation des procédures de reprise
• Cas limites et valeurs spéciales
• exemples
• table pleine , table vide
• fichier inexistant

34
Sorganiser pour tester

• Certains langages fournissent des bibliothèques
  de fonctions pour automatiser le lancement des
  tests et la gestion des résultats
• Java Junit par exemple
• Faire des tests indépendants les uns des autres
• Pas de tests imbriqués
• Un test qui échoue ne fait pas échouer les tests
  suivants
• Faire des tests automatisés
• Non équivoques
• Pas de saisie de lutilisateur, tout en dur
• Faire un makefile /ant pour compiler et lancer
  automatiquement tous les tests

35
Conclusion tests

• Prévoir les tests et les rédiger avant de coder
  chaque fonction
• Faire des tests unitaires, puis des tests
  dintégration, puis des tests fonctionnels
• Utiliser un environnement de tests pour aller
  plus vite
• Réutiliser les tests et leurs résultats comme
  documentation

36
5- Refactoring

• Martin Fowler "... process of changing a software
  system in such a way that it does not alter the
  external behavior of the code yet improves its
  internal structure." Just cleaning up code.
• Kent Beck "Programs have two kinds of value what
  they can do for you today and what they can do
  for you tomorrow."
• Don Roberts"The first time you do something, you
  just do it. The second time you do something
  similar, you wince at the duplication, but you do
  the duplicate thing anyway. The third time you do
  something similar, you refactor."
• http//www.cs.usfca.edu/parrt/course/601/lectures
  /refactoring/refactoring.html

37
Refactoring

• Pourquoi?
• Améliorer la conception et la structure du code
• Plus facile à maintenir
• Plus facile à comprendre
• Plus facile à modifier
• Plus facile dajouter des nouvelles
  fonctionnalités
• Un élément-clef de l'eXtreme Programming, où par
  définition le programme peut et doit être
  constamment remanié pour améliorer sa structure
  sans modifier son comportement.

38
Refactoring sous Eclipse

• menu Refactor du menu principal, ou du menu
  contextuel de la zone de code à modifier.
• les fonctions proposées dépendent du code
  sélectionné.
• une vingtaine de fonctions de refactoring.
• Extract Method Crée une nouvelle méthode
  encapsulant les éléments sélectionnés, et
  remplace toutes les références à ces éléments
  (même ailleurs dans le code), par un appel vers
  cette méthode.
• Rename Renomme l'élément sélectionné.
• Move Déplace l'élément sélectionné, par exemple
  enlever la classe du paquetage actuel, et la
  place dans un autre paquetage
• Change Method Signature
• Extract Local Variable crée une nouvelle
  variable assignée à l'expression sélectionnée.
• Inline fonction inverse de Extract Local
  Variable

39
Refactoring sous Eclipse

• Convert Local Variable to Field Transforme une
  variable locale, définie dans une méthode, en
  champ de classe.
• Push Down / Pull Up déplace la sélection vers
  la sous-classe ou la superclasse actuelle.
• Introduce Parameter Remplace une expression par
  une référence à un nouveau paramètre, et met à
  jour toutes les expressions faisant appel à cette
  méthode.
• Extract Constant Crée un champ de classe avec
  attributs static et final à partir des
  expressions sélectionnées, et remplace ces
  dernières par une référence à la constante.
• Use Supertype Where Possible Remplace les
  occurrences d'un type par l'un de ses supertypes,
  non sans avoir identifié auparavant tous les
  emplacements où ce remplacement est possible.

40
Refactoring sous Eclipse

• Generalize Type Présente à l'utilisateur une
  fenêtre dans laquelle il pourra choisir l'un des
  supertypes de la référence sélectionnée, celles
  permettant un changement sans risque de type
  étant colorées.
• Extract Interface À l'instar des précédentes
  fonctions de types Extract, celle-ci se charge de
  prendre les éléments sélectionnes et d'en tirer
  une classe disposant des méthodes de la classe en
  cours, et implémente cette interface sur la
  classe.
• Encapsulate Field Remplace toutes les
  références à un champ de classe, par des méthodes
  get et set pour ce champ.
• Introduce Factory Crée une nouvelle méthode de
  type Factory, en générant pour un constructeur
  donné la méthode statique appropriée.

41
? UML

• ?/?Introduction aux objets
• ?/?Objet, classe
• ?/?Les modèles d'UML
• ?/? Etude de cas

42
?/? Introduction Objets

• Objet
• Association de données et traitements dans une
  même entité
• Idée de base (1966, Simula)
• cacher structure de données par opérations de
  manipulation Types Abstraits de Données (TAD)
• Fondement de l'objet (1976, Smalltalk)
• ajouter des hiérarchies de généralisation entre
  les TAD Classes
• (a également été le berceau de l'écran bitmap
  avec souris)

43
Objets 3 points de vue

• Structurel
• objet instance d'un type avec structure cachée
  par opérations Encapsulation
• Conceptuel
• objetconcept du monde réel qui peut être
  spécialisé
• Acteur
• objetentité autonome qui répond à des messages

44
Objets motivations

• Développement de logiciels complexes
• représenter directement les objets réels sans
  déformation
• réutiliser et étendre l'existant
• environnements de développement riches
• créer rapidement des interfaces homme-machine
  événementielles
• prototypage rapide (implantation partielle)
• facilité d'exploitation du parallélisme

45
?/? Concepts objet objet

• Objet identité état comportement
• Identité (OId)
• identifiant typiquement interne au système
• implantation souvent par pointeurs
• Etat
• valeur simple ou structurée (comportant valeurs,
  objets)
• Comportement
• ensemble d'opérations applicables à l'objet
  définies dans sa classe
• Par extension, objet identité classe état
• représenté dans un rectangle avec texte souligné

46
Concepts objet classe

• Classe instanciation attributs opérations
• Instanciation
• mécanisme de création d'objets
• ensemble des objets instanciés extension de la
  classe
• Attributs (ou variables d'instance)
• structure de la classe
• nom type (simple ou classe)
• Opérations (méthodes)
• opérations qui peuvent être appliquées aux
  instances
• représentée dans un rectangle

47
Concepts objet identité et égalité, visibilité

• Identité et égalité
• Deux objets sont identiques
• OId identiques
• Deux objet sont égaux
• même état
• Liens entre objet références aux OId
• Visibilité
• Membre public
• fait partie de l'interface de la classe
• Membre privé
• fait partie de l'implantation de la classe
• sert uniquement à développer la classe

48
Concepts objet agrégation

• Des objets complexes comprenant d'autre objets
• traduction du verbe avoir
• composition si je détruis l'objet complexe, je
  détruis ses composants
• référence si je détruis l'objet complexe, je ne
  détruis pas ceux reliés
• Exemple type la nomenclature

49
Concepts objet associations entre classes

• On utilise souvent les associations binaires
• Les associations peuvent être aussi traduites par
  des objets

Appartient
Voiture
Propriétaire
Elève
Professeur
Enseignement
50
Concepts objet généralisation

• Lorsque tous les objets d'une classe
  appartiennent aussi à une autre classe plus
  générale
• traduction du verbe être
• la sous-classe possède toutes les propriétés et
  méthodes de la surclasse en plus des siennes
  propres
• Exemple
• La classe C (Carré) et la classe L (Losange)
• On dit que L généralise C et que C spécialise L
• C est une sous-classe de L, L est une sur-classe
  de C

Losange
Carré
51
Concepts objet délégation

• Le client envoie un message à un objet
  "interface" qui propage le message aux objets
  exécutants
• le client ne connaît pas directement le
  fournisseur
• les exécutants peuvent changer dans le temps

Délégué 1
propagation
message
client
"interface"
propagation
Nb cf. Les proxys
Délégué 2
52
?/? Objet vers une notation unifiée

• De nombreuses méthodes (gt100) ayant des avantages
  et des inconvénients différents
• Pour pouvoir passer de l'une à l'autre, une
  notation unifiée UML
• UML Unified Modeling Language
• pas de méthode préconisée
• un glossaire de termes et de représentations
  graphiques
• rapprochement de OOD, OMT, OOSE
• http//www.rational.com

53
UML - historique

• 1994, Rumbaugh rejoint Booch chez Rational
  Software
• but créer une méthode en commun
• 1995 présentation v0.5
• 1995, rachat d'Objectory, arrivée de Jacobson
• 1996, LANGAGE unifié UML
• 1997
• présentation de UML à l'OMG (Object Management
  Group)
• UML 1.1 adopté par la plupart des compagnies

54
UML - principes

• 4 objectifs
• représenter des systèmes entiers par des concepts
  objet
• établir un couplage explicite entre concepts et
  artefacts exécutables
• prendre en compte les facteurs d'échelle
  inhérents aux systèmes complexes et critiques
• créer un langage de modélisation utilisable à la
  fois par les humains et les machines
• Propose 9 diagrammes différents
• A chacun de choisir les diagrammes utiles à son
  cas
• Pas de méthode pour lutilisation des diagrammes

55
UML les mécanismes de base

• Assurent lintégrité de la notation
• Stéréotype
• classer les éléments du modèle en familles
• Etiquette
• paire (nom,valeur) décrivant une propriété
• Note
• commentaire
• Relation de dépendance
• relation d'utilisation entre 2 éléments
• Contrainte
• restriction aux éléments du modèle

56
UML mécanismes de base
Auteur
Relation
écrire
Contrainte
ordonne
Stéréotype
ltltpersistantgtgt Œuvre Etattesté
Etiquette
Note
57
UML Diagramme des cas d'utilisation
diagramme des cas d'utilisation d'un véhicule
Acteur
Cas d'utilisation
Bornes du système
58
UML diagramme des cas d'utilisation

• modéliser
• les fonctionnalités du système
• et les attentes des utilisateurs
• servent également de base pour les jeux dessais
• Un diagramme comprend
• les acteurs,
• le système,
• les cas d'utilisation eux-mêmes

59
UML acteurs

• 4 catégories dacteurs
• acteurs principaux ou utilisateurs des fonctions
  principales du système
• acteurs secondaires qui effectuent des tâches
  administratives ou de maintenance
• matériel externe ou dispositifs incontournables
  faisant partie du domaine de lapplication
• autres systèmes avec lesquels le système doit
  interagir

60
UML cas dutilisation

• Avantage
• simplicité de représentation
• Inconvénients
• pas hiérarchisés et ne prennent pas en compte la
  complexité des SI
• ne font pas apparaître les ressources exploitées
  par les fonctions
• ne permettent pas une bonne traçabilité vers les
  autres diagrammes.

61
UML Diagramme de séquence
62
Autre exemple diagramme de séquence
63
Encore un autre exemple diagramme séquence
Multithread/ multiprocess
appel en interne, récursivité
64
UML Diagramme de classes

• Plus ou moins détaillé selon l'étape
• Classes
• nom, attributs, méthodes
• Relations
• relations de composition et référence ("fait
  partie de")
• relations de généralisation ("est une sorte de")
• relations quelconques ("est produit par", "est
  affilié à", "se trouve à", "est conduit par")
• seront traduites par composition, référence,
  nouvelle classe
• Paquetages
• Interfaces

65
Diagramme de classes Classes
public - privé protégé
66
Diagramme de classes Agrégation
composition
référence
67
Diagramme de classes Généralisation
Contraintes possibles complete, incomplete,
disjoint, overlapping
68
Diagramme de classes Associations
69
Diagramme de classes Paquetages

• Regroupement logique de classes
• clarté
• partage du travail dans une équipe

70
Diagramme de classes Interfaces

• Présenter un objet sous différentes facettes
• une interface une facette
• ensemble de signatures de méthodes sans
  implantation
• Contrat d'implantation de méthodes
• en C des classes virtuelles, en java des
  interfaces
• Exemple
• interface "stockable" pour persistance
• méthodes sauver(), récupérer()
• interface "visualisable" pour présentation
• méthodes afficher(), imprimer()

Abonné
stockable
71
UML diagramme d'objets

• Dérivé du diagramme de classes (souligné objet)
• montrer un état mémoire à un instant t
• faciliter la compréhension des structures
  complexes (récursivité, associations ternaires)

Diagramme de classes
Diagramme d'objets
72
UML diagramme de collaboration

• Interactions entre objets
• diagramme d'objets avec les envois de messages
• corrélé au diagramme de séquences qui insiste sur
  l'aspect chronologique plutôt que sur les
  interactions

portes ascenseur
5 ouvrir
8 fermer
11 ouvrir
13 fermer
1Appui bouton étage gt
ascenseur
3 déplacer gt
contrôleur ascenseur
6Appui bouton ascenseur gt
9 déplacer gt
7 allumer lt
10 éteindre lt
2 allumer gt
12 timer
4 éteindre gt
bouton ascenseur
bouton étage
73
UML diagramme Etats-transitions

• Les changements détat dun objet dune classe
  pendant sa durée de vie

appuiBouton non verrouillée / ouvrir()
Porte fermée
Porte ouverte
appuiBouton non verrouillée / fermer()
74
UML Diagramme dactivités

• Donne la liste des étapes suivies pour accomplir
  une action
• (algorithme dune fonction)

75
Autre exemple diagramme d'activités
Mesurer température
garde
trop froid
trop chaud
Refroidir
Chauffer
synchronisation
Arrêter chauffage
Ouvrir la fenêtre
Donner consigne t
Thermostat
Envoi et réception de signaux
Aérer
Fermer la fenêtre
76
Diagramme dactivités encore
77
UML diagramme de composants
Abonné
78
UML diagramme de déploiement
79
UML les 9 diagrammes

• Cas dutilisation
• vues que les utilisateurs ont du système en
  termes de fonctions
• Classes
• classes et relations qui les lient
• Objets
• instances de classes
• Séquence
• interactions entre objets ordonnées dans le temps
• Collaboration
• interactions entre objets
• ...

80
UML les 9 diagrammes (suite)

• Etats-transitions
• cycles de vie des objets
• Activité
• sémantique dune opération en termes dactions
• Composants
• dépendances de compilation et/ou d'exécution des
  composants d'une application
• Déploiement
• équipements et modes de connexion

81
Classification des diagrammes

• Conception
• cas d'utilisation
• séquence
• Structure
• classes
• objets

• Dynamique
• collaboration
• séquence
• états-transitions
• activités
• Composants
• composants
• Déploiement
• déploiement

82
?/? Etude de cas distributeur de boissons

• Application Distri un distributeur automatique
  de boissons
• Les classes
• acteur Client
• acteur Employé
• Machine Distributeur

83
Distri Diagramme des cas d'utilisation
Machine distributrice
Prendre une boisson
Gérer la machine
84
Distri Diagramme de séquence
Automate Gobelets
Automate Boissons
Etc...
85
Distri diagramme de classes
introduction
1
1..
1
DistributeurDeBoissons
récupérer
rendre
Consommateur
Monnayeur
0..
0..
1
1
choisir
0..1
AutomateBoissons
distribution
1
1
retirer
AutomateGobelets Static nbGobelets
86
Distri diagramme de collaborations
Pièces Monnayeur
selectionnerChoix(unChoix)
1.1.2.3. rendreMonnaie(somme) 1.1.1.1.3.
rendreMonnaie(somme)
leGestionnaire Gestionnaire
unEcran Ecran
1. sommeSuffisante(unChoix)booleen 1.1.2.2.
sommeIntroduite()Somme 1.1.1.1.2.
sommeARendre(unChoix)Somme 1.1.1.1.4.
Stop() 1.2.1. sommeManquante(unChoix)Somme
uneMDB DistributeurDeBoissons
1.1.1. Préparer() 1.1.1.1.1. Verser()
1.1. Placer()
unGobelet AutomateGobelets
uneBoisson AutomateBoissons
87
Nouvelle version diagramme de classes
introduction
rendre
1
1..
1
récupérer
Monnayeur Vector piecesDispo rendreMonnaie()
Consommateur
DistributeurDeBoissons sélectionnerChoix()
0..
1
0..
choisir
1
0..1
AutomateBoissons Préparer() Verser()
distribution
1
1
retirer
AutomateGobelets Static nbGobelets Placer()
88
Conclusion UML

• UML nest pas une méthode, mais un ensemble de
  modèles
• UML est un standard international
• Ces modèles sont simples
• faciles à lire et donc à communiquer
• mais difficiles pour des systèmes très complexes

89
Les Design Patterns

• 4TC-MPO
• Stéphane Frénot
• (tiré de Jia 2000, réadapté par F. Laforest)

90
Design patterns

• Origine Christopher Alexander pour décrire la
  conception d'architectures de bâtiments (253
  modèles)
•  Chaque moule (pattern) décrit un problème qui
  réapparaît de manière régulière dans notre
  environnement, puis il décrit le noyau de la
  solution du problème, de telle manière que vous
  pouvez réutiliser cette solution autant de fois
  que vous le voulez, sans jamais réaliser la
  solution finale deux fois de suite de la même
  manière

91
Architecture bâtiment / conception logiciel

• Des processus de création qui peuvent se décliner
  de nombreuses manières
• Le résultat final doit satisfaire les besoins de
  l'utilisateur
• Le résultat final doit être réalisable par les
  ingénieurs
• Les concepteurs doivent prendre en compte de
  nombreux facteurs de contraintes et de nombreux
  besoins
• Les concepteurs doivent atteindre certains but
  intrinsèques mais peu mesurables (élégance,
  extensibilité)

92
En conception de logiciels

• Un livre-bible
• le GOF
• 23 patterns décrits, classés en 3 catégories
• création
• structuration
• comportements
• Description d'un pattern
• Nom, Catégorie, Objectif, Contexte d'application,
  Structure, Participants...

93
Design Pattern Singleton

• Pour des services "centralisés"

94
Singleton

• Nom Singleton
• Catégorie Création
• Objectif Contraindre qu'une classe ne possède
  qu'une seule instance, et fournir un point
  d'accès unique à cet objet
• Contexte dapplication Utiliser cette classe
  quand il ne faut qu'une seule instance de la
  classe et qu'elle soit accessible de manière
  unique par les clients (e.g. UNE file
  dimpression)
• Structure

95
Exemple d'implantation du Singleton

• public class Singleton

96
Design Pattern Template Method

• Pour factoriser les codes communs

97
Factorisation

• Un des objectifs de la programmation OO est de
  trouver des composants génériques.
• Pour trouver des composants génériques il faut
  trouver le code récurrent dans différents objets
  et le factoriser
• Intérêts maintenance, taille du code ...

98
Principe de factorisation

• Identifier des segments de code qui implantent la
  même logique, souvent dans le même morceau de
  code, dans plusieurs endroits
• Capturer cette logique dans un composant
  générique défini une seule fois
• Réorganiser le code de telle manière que chaque
  occurrence de code est remplacée par
  l'utilisation du composant générique

99
Techniques de factorisation

• Par généralisation des méthodes
• Par héritage
• Par délégation

100
Factorisation de méthodes

• Public class Calcul
• void méthode1 ()
• //
• calculEtape1()
• calculEtape2()
• calculEtape3()
• //
• void méthode2()
• //
• calculEtape1()
• calculEtape2()
• calculEtape3()
• //

Public class CalculFactorisé
101
Factorisation par héritage

• Les méthodes à généraliser sont souvent dans des
  classes différentes

public class CalculA void méthode1 ()
// calculEtape1() calculEtape2()
calculEtape3() //
public class CalculB void méthode1 ()
// calculEtape1() calculEtape2()
calculEtape3() //
public class Commune
public class CalculA
102
Factorisation par délégation

• Utiliser un objet dune autre classe pour faire
  le calcul
• sans utiliser dhéritage (souplesse pour les
  langages sans héritage multiple)

public class CalculA
public class Helper
103
Factorisation allons plus loin

• Insertion de code spécifique au milieu de code
  commun

public CalculA void méthode1 () (code
commun Segment1) (code spécifique au
contexte) (code commun Segment2)
public CalculB void méthode1 () (code
commun Segment1) (code spécifique au
contexte) (code commun Segment2)
104
1ère solution

• Factorisation par héritage ou délégation
• OK si codes 1 et 2 indépendants
• Sinon rupture de logique gt problème

public Commune void codeCommun1 () (code
commun Segment1) void codeCommun2 ()
(code commun Segment2)
105
On préfère Template (Patron)

• Utiliser une classe abstraite
• méthode abstraite pour le code spécifique au
  contexte

public abstract class Commune void code()
(code commun Segment1) appelDeContexte()
(code commun Segment2) abstract void
appelDeContexte ()
106
Design Pattern Template Method

• Nom Template Method
• Catégorie comportement
• Objectif définir le squelette d'un algorithme
  dans une méthode, en laissant certaines étapes
  aux sous-classes. Permet ainsi aux sous-classes
  de redéfinir certaines étapes de l'algorithme
• Domaine d'application il doit être utilisé pour
  
• implanter une seule fois les parties invariantes
  d'un algorithme et laisser aux sous-classes le
  comportement qui peut varier
• factoriser et localiser les comportements communs
  des sous-classes afin d'éviter la duplication de
  code

107
Template Method Structure
108
Design Pattern Strategy

• Pour des fonctionnalités génériques

109
Généralisation

•  La généralisation est le processus qui consiste
  à prendre une solution spécifique à un problème
  et la réorganiser afin qu'elle résolve le
  problème original mais également une catégorie de
  problèmes similaires. 

110
Exemple

• On veut réaliser un outils d'affichage de piles
  protocolaires
• Problème
• Comment séparer les différentes fonctions de
  désencapsulation du code de l'afficheur
• Solution directe
• L'afficheur définit autant de méthodes que de
  fonctions à afficher

public abstract Afficheur abstract double
afficheMAC (Paquet x) abstract double
afficheIP (Paquet x) abstract double
afficheTCP (Paquet x) ...
111
Le problème

• Dans ce cas le code est peu flexible et peu
  élégant
• Des codes similaires seront répliqués dans chaque
  fonction
• Résiste mal à l'évolution de la pile protocolaire
• gt Le mieux est de représenter chaque fonction
  non pas comme une méthode, mais comme un objet

112
Interface

• On définit une interface qui représente le
  comportement voulu pour n'importe quelle
  fonction-objet

public interface Decapsule String
decapsuler(Paquet x)
public class IP implements Decapsule String
decapsuler(Paquet x) // Code de
décapsulation return trameCommentée
113
Rôle de l'afficheur

• L'afficheur maintient alors un tableau sur toutes
  les fonctions à afficher
• Il doit fournir les méthodes qui lui permettront
  d'ajouter et de retirer les fonctions à afficher

114
Design Pattern Strategy

• Nom Strategy
• Catégorie comportement
• Objectif définir une famille d'algorithmes,
  encapsuler chacun et les rendre interchangeables
• Domaine d'application il doit être utilisé
  quand
• De nombreuses classes ne se distinguent que par
  leur comportement (plusieurs types
  d'encapsulation)
• Différentes versions d'algorithmes sont
  nécessaires
• Un algorithme utilise des données qu'un client
  n'a pas à connaître
• Une classe définit plusieurs comportements qui
  sont autant de branches conditionnelles dans ses
  méthodes

115
Strategy Structure
116
Design Pattern Iterator

• Pour des parcours indépendants multiples de
  collections

117
Couplage abstrait

• Technique qui permet à un client de collaborer
  avec un fournisseur de services
• Le client accède au service sans connaître
  l'implantation exacte du service
• Exemples téléphonie, réseau
• Technique Programmer sur une interface et non
  pas sur une implantation

118
Couplage abstrait pour énumérer des éléments

• Soit une classe de gestion de liste chaînée
• Et une classe de description de paquets réseau
• gt Je veux itérer sur tous les éléments de ma
  liste

public class Liste implements List protected
Node head, tail protected int
count //Implantation de la liste class Node
Paquet element Node next, prev
119
Solution 1 Accès direct
Liste maListe //insérer les éléments dans la
liste for (Liste.Node curlist.head cur !
null curcur.next) System.out.println(cur.ele
ment) ...

• Nécessite que les champs et la classe interne
  Node soient accessibles des clients du service

120
Sol. 2 Itérer par l'invocation de méthodes

• On définit une sous-classe de List qui permet
  d'invoquer les méthodes d'itération

public class ListeIterable extends List
public void reset() curhead public
Paquet next() Paquet objnull if
(cur!null) objcur.element
curcur.next return obj public
boolean hasNext() return (cur!null)
protected Node cur
ListeIterable maListe //insérer les
paquets for (list.reset() list.hasNext()
) System.out.println(list.next()) ...
Problème des boucles imbriquées
121
Solution 3 Séparer l'iterateur de la liste

• On définit une classe d'iteration qui contient
  une référence sur la liste de base

public class IterateurDeListe public
IterateurDeListe(Liste uneListe)
this.listeuneListe curliste.head
public Paquet next() Paquet objnull if
(cur!null) objcur.element
curcur.next return obj public
boolean hasNext() return (cur!null)
protected Liste.Node cur protected Liste
liste
Ne fonctionne que sur la classe Liste
122
Sol. 4 La généralisation

• En utilisant le couplage abstrait, le client
  n'utilise qu'une interface itérateur indépendante
  de la collection sous-jacente
• On définit une interface de programmation
  indépendante
• ...qu'on implante dans les classes sur lesquelles
  les itérations sont possibles

public interface Iterator boolean hasNext()
Object next() void remove()
123
Sol 4 Itérateur abstrait
public class Liste // méthodes de la liste

124
Les clients utilisent l'itérateur

• Chercher les paquets de même pile protocolaire
  dans la liste maListe (utiliser la méthode
  isSameStack())

Liste maListenew Liste() // Insertion des
éléments
125
Design Pattern Iterator

• Nom Iterator
• Catégorie comportement
• Objectif Fournit un moyen d'accéder à des
  éléments d'une collection de manière séquentielle
• Domaine d'application il doit être utilisé pour
  
• Accéder au contenu d'une collection sans qu'elle
  publie sa structure interne
• Permettre des traversées multiples de collection
• Fournir une interface d'accès uniforme pour
  traverser les différentes collections (itération
  polymorphe)

126
Iterator structure
127
Design Pattern Usine

• Pour des instanciations génériques

128
Afficheur Schéma UML
129
Problématique

• Encore le couplage abstrait
• La classe cliente du service d'analyse de trame
  doit
• Connaître les algorithmes de désencapsulation
• Réaliser à la fois de l'affichage et de la
  gestion
• Les stratégies ne sont pas suffisamment
  découplées du client
• gt Une solution l'usine de fabrication

130
L'usine schéma UML
131
Design Pattern Usine

• Nom Abstract Factory
• Catégorie création
• Objectif définit une interface de création
  d'objets, mais délègue aux sous-classes quelle
  classe instancier et comment
• Domaine d'application il doit être utilisé
  quand
• Un système doit être indépendant de la manière de
  fabriquer ses produits

132
Usine Structure
133
Design Pattern Composite

• Pour représenter toute hiérarchie de composition

134
Awt Java

• Les widgets
• java.awt.Button
• java.awt.Canvas
• java.awt.Checkbox
• java.awt.Choice
• java.awt.Label
• java.awt.List
• java.awt.MenuBar
• java.awt.MenuItem
• java.awt.TextComponent
• java.awt.TextArea
• java.awt.TextField

Les container java.awt.Window java.awt.Frame jav
a.awt.Dialog java.awt.FileDialog java.awt.Panel
java.applet.Applet

• Tous les composants graphiques sont reliés par
  des relations
• container/contenu

135
Awt Schéma UML
136
Design Pattern Composite

• Nom Composite
• Catégorie structuration
• Objectif Organise les objets dans un arbre pour
  représenter une partie ou la totalité d'une
  hiérarchie. Le composite permet aux clients de
  traiter les objets unitaires et les compositions
  de la même manière
• Domaine d'application il doit être utilisé
  quand
• On veut représenter une hiérarchie partiellement
  ou entièrement
• Le client doit ignorer les différences entre les
  composants et les composés. Traitement des
  éléments de manière homogène

137
Composite UML
138
Design pattern Décorateur

• Pour ajouter dynamiquement des fonctionnalités à
  un objet

139
Les entrées/sorties en Java

• Des classes de base et des classes dérivées
• java.io.OutputStream gt ByteArrayOutputStream,
  FileOutputStream, FilterOutputStream,
  ObjectOutputStream, OutputStream,
  PipedOutputStream
• java.io.InputStream gt AudioInputStream,
  ByteArrayInputStream, FileInputStream,
  FilterInputStream, InputStream,
  ObjectInputStream, PipedInputStream,
  SequenceInputStream, StringBufferInputStream
• java.io.Writer gtBufferedWriter, CharArrayWriter,
  FilterWriter, OutputStreamWriter, PipedWriter,
  PrintWriter, StringWriter
• Dans les classes dérivées, des fonctionnalités
  s'ajoutent à la fonction de base
• Buffer, Compression, Encryption...

140
Imbrication de fonctionnalités

• PrintWriter
• transformer des représentations formattés
  d'objets en flux texte
• BufferedWriter
• utilise un buffer intermédiaire et envoie le flux
  par paquets
• FileWriter
• écrit le flux dans un fichier
• Mettre une représentation d'un objet dans un
  fichier via buffer
• PrintWriter out new PrintWriter(new
  BufferedWriter(new FileWriter("foo.out")))

141
Ajouter des fonctionnalités

• Pour mettre en œuvre des ajouts et combinaisons
• spécialiser les classes
• ou
• utiliser le design pattern décorateur
• Spécialisation dès la conception prévoir des
  classes dérivées
• Décorateur ajoute dynamiquement des
  fonctionnalités à un objet

142
Design Pattern Décorateur

• Nom Decorator
• Catégorie structuration
• Objectif Associer des responsabilités à un
  objet de manière dynamique. Les décorateurs
  fournissent une approche flexible à l'héritage
  pour étendre des capacités
• Domaine d'application il doit être utilisé pour
  
• Ajouter dynamiquement des responsabilités à un
  objet sans affecter les autres objets de la même
  classe
• Pour des responsabilités qui peuvent être
  retirées
• Quand l'extension de l'arbre d'héritage n'est pas
  pratique et amène à une explosion du nombre de
  sous-classes pour pouvoir implanter toutes les
  combinaisons.

143
Décorateur structure
144
Design pattern Médiateur

• Autre nom Proxy
• Pour ne pas donner un accès direct à un objet,
  mais utiliser un intermédiaire

145
Manipuler des objets gourmands

• Affichage et manipulation d'images
• une image est gourmande en espace mémoire
• certaines méthodes ne requièrent pas
  l'instanciation réelle de l'objet image, mais
  seulement d'avoir des informations sur l'image
• Idée
• ne créer l'objet que quand réellement nécessaire
• utiliser un objet intermédiaire qui répond aux
  demandes et crée l'objet si nécessaire

146
Exemple éditeur de document
147
Design Pattern Médiateur

• Nom Proxy
• Catégorie structuration
• Objectif Fournit un subrogé qui représente un
  autre objet
• Domaine d'application quand il est nécessaire
  d'avoir une référence d'objet plus sophistiquée
  ou versatile que la simple référence (pointeur).
  Situations où le médiateur est nécessaire
• remote proxy le proxy (stub) fournit une
  représentation locale d'un objet distant
• virtual proxy lorsqu'on utilise des objets
  consommateurs de temps ou d'espace, le proxy ne
  crée effectivement l'objet que quand c'est
  indispensable
• protection proxy contrôler l'accès à l'objet
  original

148
Médiateur structure
unClient sujet
unProxy sujetReel
unObjetReel
149
Les patterns du GOF
150
Patterns de création (1)

• Abstract factory provide an interface for
  creating families of related or dependent objects
  without specifying their concrete class
• Builder separate the construction of a complex
  object from its representation so that the same
  construction process can create different
  representations
• Factory method define an interface for creating
  an object, but let subclasses decide which class
  to instanciate. Factory method lets a class defer
  instanciation to subclasses

151
Patterns de création (2)

• Prototype specify the kinds of objects to
  create using a prototypical instance, and create
  new objects by copying this prototype
• Singleton ensure a class only has one instance,
  and provide a global point of access to it

152
Patterns de structure (1)

• Adapter converts the interface of a class into
  another interface clients expect
• Bridge decouple an abstraction from its
  implementation so that the 2 can vary
  independantly
• Composite compose objects into tree structures
  to represent part-whole hierarchies
• Decorator attach additional resposabilities to
  an object dynamically

153
Patterns de structure (2)

• Facade provide a unified interface to a set of
  interfaces in a subsystem
• Flyweight use sharing to support large numbers
  of fine-grained objects efficiently
• Proxy provide a surrogate or placeholder for
  another object to control access to it

154
Patterns de comportement (1)

• Chain of responsibility avoid coupling the
  sender of a request to its receiver by giving
  more than one object a chance to handle the
  request
• Command encapsulate a request as an object,
  thereby letting you parameterize clients with
  different requests, queue or log requests, and
  support undoable operations
• Interpreter given a language, define a
  representation for its grammar along with an
  interpreter that uses the representation to
  interpret sentences in the language

155
Patterns de comportement (2)

• Iterator provide a way to access the elements
  of an aggregate object sequentially without
  exposing its underlying representation
• Mediator define an object that encapsulates how
  a set of objects interact
• Memento without violating encapsulation,
  capture and externalize an object's internal
  state so that the object can be restored to this
  state later
• Observer Define a one-to-many dependency
  between objects so that when one object changes
  state, all its dependants are notified and
  updated automatically

156
Patterns de comportement (3)

• State Allow an object to alter its behavior
  when its internal state changes. The object will
  appear to change its class
• Strategy define a family of algorithms,
  encapsulate each one, and make them
  interchangeable
• template method define the skeleton of an
  algorithm in an operation, deferring some steps
  to subclasses
• Visitor represent an operation to be performed
  on the elements of an object structure

157
Frameworks
158
Framework définition

• Ensemble de classes coopérantes
• qui représente