ENSTA : in204 Programmation par Objets en Java et Gnie Logiciel

1
ENSTA in204 Programmation par Objets (en
Java)et Génie Logiciel

• Olivier Sigaud
• LIP6/AnimatLab
• olivier.sigaud_at_lip6.fr
• 01.44.27.88.53

2
Plan du cours 12

• De l'analyse à la conception recours au modèle
  MVC
• Découpage en packages
• Couches génériques
• Frameworks
• Problèmes de création
• De la conception à limplémentation

3
De l'analyse à la conception recours au modèle
MVC
4
Rappel Analyse / Conception

• Analyse Comprendre les spécifications, en
  extraire les exigences, présenter formellement le
  problème à résoudre
• Vérifier la conformité de lanalyse aux besoins
• Eviter de figer des choix de conception pendant
  lanalyse
• On ignore quon réalise un logiciel
• Conception Concevoir LA solution au problème
  analysé
• lanalyse ltlt quoi ? gtgt,
• la conception ltlt comment ? gtgt
• On se concentre sur la réalisation dun futur
  logiciel

5
Objectifs

• Lanalyse a permis de dégager un certain nombre
  dobjets métiers manipulés par le futur système
• Le système informatique lui-même na pas encore
  été décomposé en fonction de ses traitements
• Un aspect important du passage à la conception
  consiste à identifier les objets qui manipulent
  les données contenues dans les objets métier
• Approche Model, View, Controller
• Attention les diagrammes subissent des
  modifications importantes entre analyse et
  conception

6
Approche Model, View, Controller (MVC)

• Model les objets métiers, les objets porteurs
  de données manipulées par lapplication
• View les interfaces vers le monde externe, qui
  donnent des vues sur létat des objets métier
• Controller les objets Manager de haut
  niveau qui vont manipuler les objets métiers

7
Démarche MVC du passage à la conception

• Les objets métiers ont été identifiés lors de
  lanalyse
• De même pour les principales fonctionnalités et
  les principaux traitements
• Les Managers regroupent les traitements selon
  les types dobjets métiers auxquels ils
  sappliquent
• Ils reposent sur des structures de données
  élémentaires (Collections)
• Les Views permettent dappeler (via une
  interface) les traitements définis par les
  Managers
• On ajoute enfin des classes intermédiaires de
  conception (généricité, découpage en packages)

8
Le découpage en packages
9
Responsabilité et localité

• Un traitement doit être attribué à la première
  classe qui dispose des données nécessaires pour
  le réaliser
• Permet dassurer une propriété de localité
  maximale
• Exemple
• Une classe listeDAchats contient une liste de
  produits et de quantité, chaque produit connaît
  son coût unitaire
• Le traitement calculerMontantTotal() est associé
  à listeDAchats

10
Objectifs

• Rendre les différents modules aussi indépendants
  que possible
• Permettre la compilation séparée des modules
  (minimiser les imports )
• Eviter à tout prix les dépendances croisées

11
Exemple élémentaire que faire ?
Package 2
Package 1
Classe C1
Classe C2

• Les classes C1 et C2 appellent des méthodes lune
  de lautre

12
Solution 1
Package 2
Package 1
Interface I1
Classe C1
Classe C2

• Le package 2 compile tout seul, et le package 1
  dépend du package 2

13
Solution 2
Package 1
Interface I1
Interface I2
Classe C1
Classe C2
Package 2

• Cette fois, on a isolé une couche abstraite
  indépendante, et une implémentation qui en dépend
• Dautres découpages sont possibles

14
Le pattern observer

• Instance du schéma précédent
• Exemple de Design pattern

15
Plus loin que les packages

• Découpage en composants (cours 14)
• Des modules séparés, compilés une fois pour
  toutes, qui peuvent être connectés ensemble pour
  réaliser une architecture spécifique
• Eventuellement distribués, et dans des langages
  différents
• Tendance lourde du génie logiciel actuel
• A suivre

16
Couches génériques
17
Réutilisation (1)

• Si une classe correspond à un objet concret et si
  ses méthodes sont naturelles, tout programme qui
  la met en uvre peut réutiliser ses méthodes
• Il est donc plus facile de réutiliser des
  morceaux de code en programmation orientée objets
• Il est aussi plus facile d'interpréter ce que
  fait le programme si les noms de classe,
  d'attributs et de méthodes sont naturels

18
Réutilisation (2)

• Plutôt que de réutiliser un module complet, on
  peut vouloir réutiliser des traitements sils
  sont génériques
• Dans ce cadre (fréquent), la réutilisation est
  réalisée à laide de labstraction
• On réalise un traitement pour une classe
  générique, et on pourra le réutiliser pour toutes
  les classes qui en dérivent

19
Couche générique en pratique

• Etant donné une architecture de type MVC
• On abstrait les objets Model sous forme
  dinterfaces génériques
• On réalise des objets Managers qui manipulent
  ces interfaces
• Les traitements pourront être appliqués à tous
  les objets Model qui implémentent ces
  interfaces
• Les objets Model concrets implémentent des
  traitements spécifiques appelés par les
  Managers
• Suppose davoir des View génériques

20
Exemple

• interface Classifier
• public boolean match(Env e)
• class BinaryClassifier implements Classifier
• public boolean match(Env e)if
  (cond.isDontCare()) return true else if
  ((cond.isTrue() e.isTrue()) (cond.isFalse()
  e.isFalse()) return true else return false
• class IntervalClassifier implements Classifier
• public boolean match(Env e)if cond.isDontCare()
  return true else if ((cond.min()lte.val())
  (cond.max()gte.val()) return true else return
  false

21
Frameworks
22
Bibliothèque
Module fourni
Application développée par lutilisateur
Module fourni
Module fourni
23
Framework
Module développé par lutilisateur
Application générique fournie
Module développé par lutilisateur
24
Définition et implications

• Un framework est un logiciel constitué
  principalement dune couche générique, prévue
  pour que les utilisateurs y branchent leur propre
  couche spécifique en implémentant quelques
  interfaces
• Nécessité de clairement spécifier ce quil faut
  dériver ou implémenter
• Nécessité de signatures simples et bien conçues
• Quelques implémentations classiques ou
  exemplaires peuvent être fournies
• Travail dabstraction très délicat prévoir des
  utilisations exotiques
• Plus dur que bibliothèque

25
Difficultés spécifiques

• On ne peut pas prévoir à lavance toutes les
  implémentations
• Il faut donc dégager une couche abstraite,
  cohérente et suffisamment riche pour être
  intéressante (les frameworks imposent des
  contraintes)
• En IA, avoir recours à labstraction mathématique
  pour voir les équivalences entre des
  approches/outils
• Permet de maximiser les classes dapplication
• Suppose une certaine expertise dans le domaine
  modélisé

26
Exemples

• JEO Java Evolutionary Optimization (projet
  2003)
• Permet de faire tourner des algorithmes
  génétiques répartis sur des réseaux ouverts
  (SETI_at_home)
• Il suffit dimplémenter ses génomes (choix dans
  un catalogue ou dérivation) et ses fonctions
  dévaluation
• SFERES dédié à loptimisation de comportements
  par algorithmes génétiques

27
Problèmes de création
28
Création dans un framework

• Dans un framework générique, il peut être
  nécessaire de créer des instances des objets
  manipulés
• Ces instances sont des objets de type spécifiques
• Donc leur type nest pas connu par le concepteur
  du Framework
• Il ne peut pas écrire
• MonInstanceGénérique new MonTypeSpecifique()
• Donc il écrit MaFactory.creeMonInstanceGénérique()
  
• Méthode écrite par lutilisateur, qui encapsulera
  la création de lobjet spécifique

29
Le pattern Factory Method
30
Factory Method

• Classe à laquelle est déléguée la création des
  objets spécifiques
• Définie dans le framework par une interface
• Implémentée par lutilisateur
• interface MaFactoryGenerique
• MonInstanceGénérique creeMonInstanceGénérique()
  
• class MaFactoryConcrete implements
  MaFactoryGenerique
• MonInstanceGénérique creeMonInstanceGénérique()
• return new MonInstanceConcrete()
• Correspond à un besoin important dans le projet
  in204

31
Création exemple

• Création des classeurs spécifiques
• Dans la partie générique
• nouveauClasseur maFactoryGenerique.createClassif
  ier()
• Dans la factory concrète
• class MaFactoryConcrete implements
  MaFactoryGenerique
• public (static) Classifier createClassifier()
• // chaine lue dans un fichier de config
• if (chaine.equals( XCS )) return new
  XCSClassifier()
• if (chaine.equals( ZCS )) return new
  ZCSClassifier()

32
De la conception à l'implémentation
33
Attention !

• Les contraintes defficacité ou des lacunes dans
  la conception peuvent entraîner des modifications
  entre conception et implémentation
• Quand cest le cas, il faut faire évoluer la
  documentation et consulter les partenaires
  concernés
• Sefforcer de concevoir les interfaces de telle
  façon quelles ne soient pas concernées par les
  modifications
• Sefforcer de faire les modifications de façon à
  ne pas toucher aux interfaces

34
Optimisation

• Identifier les traitements qui sont appliqués le
  plus souvent (profiling)
• Chercher à optimiser ces traitements en priorité
• Identifier tous les calculs qui sont effectués
  plusieurs fois peut-on stocker les résultats
  pour ne pas les refaire ?
• On va parfois jusquà loptimisation de bytecode
  (mais cest perdu si on recompile)
• Détail Java éviter les méthodes à plus de trois
  paramètres (deprecated?)