ENSTA : in204 Programmation par Objets en Java et Gnie Logiciel - PowerPoint PPT Presentation

Loading...

PPT – ENSTA : in204 Programmation par Objets en Java et Gnie Logiciel PowerPoint presentation | free to view - id: 2a8860-ZDc1Z



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

ENSTA : in204 Programmation par Objets en Java et Gnie Logiciel

Description:

Conduite de projet : de la conception l'impl mentation. De l'analyse la conception : ... On abstrait les objets ' Model ' sous forme d'interfaces g n riques ... – PowerPoint PPT presentation

Number of Views:62
Avg rating:3.0/5.0
Slides: 35
Provided by: olivier102
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: 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?)
About PowerShow.com