Upload
aerona
View
44
Download
3
Embed Size (px)
DESCRIPTION
Conception 2 users.info.unicaen.fr/~ ionona /gl2009. Visibilité d’un objet B par un objet A. Pour que A puisse envoyer un message à B, il faut que B soit visible par A. CatalogueProduit. Registre. dP=getDescriptionProduit(codeArticle). Registre. CatalogueProduit. 1. *. - PowerPoint PPT Presentation
Citation preview
Conception 2users.info.unicaen.fr/~ionona/gl2009
Visibilité d’un objet B par un objet A
• Pour que A puisse envoyer un message à B, il faut que B soit visible par A
Registre CatalogueProduit
dP=getDescriptionProduit(codeArticle)
Registre CatalogueProduit*1
Types de visibilités (durée de vie)• Visibilité d’attribut. B est un attribut de A. • dv : tant que A et B existent• Visibilité de paramètre. B est un paramètre d’un
méthode de A.• dv: celle de la méthode• Visibilité locale. B est une variable locale d’une
méthode de A.• Dv: celle de la méthode• Visibilité globale. B est visible par tous les objets.• Dv: tant que A et B existent
Services externes dotés d’interfaces différentes
• Le système doit se connecter à des services tiers externes: Calculateur de taxes, service de comptabilité, Autorisation de crédit
• Mais pour chaque type de service peut exister différents fournisseurs tiers avec son API propre chacun (différent mais stable)
• Ex. Il existe calculateurTaxe1, calculateurTaxe2, calculateurTaxe3
•
Recours à des services tiers externes
Polymorphisme
AdaptateurCalculTaxes1AdaptateurCalculTaxes2
IAdaptateurCalculTaxes
getTaxes(v : vente)
<<Interface>>Registre
0..n1 0..n1
AdaptateurCalculTaxesFutur
Fabrique concrète (Factory)• Quel objet crée les adaptateurs de services ?• Un objet du domaine ? Registre ? Non car diminue la
cohésion• Séparer les attributions, chaque classe a un objectif
cohérent• Construire un objet Fabrication pure nommée
FabriqueConcrete pour gérer la création
FabriqueServicesadaptateurCalculTaxes : IAdaptateurCalculTaxesadaptateurCompta : IAdaptateurCompta
getAdaptateurCalculTaxes()getAdaptateurCompta()
Qui crée l’objet FabriqueDeServices ?
• De combien d’instances de
FabriqueDeServices a-t-on besoin ?
• Comment s’assurer que getInstance() soit
visible partout ?
Singletonclasse qui ne produit qu’une instance unique
FabriqueServices<<static>> instance : FabriqueServicesadaptateurCalculTaxes : IAdaptateurCalculTaxesadaptateurCompta : IAdaptateurCompta
<<static>> getInstance()getAdaptateurCalculTaxes()getAdaptateurCompta()
<<singleton>>
// static methodpublic static synchronized FabriqueDeServices getInstance(){if ( instance == null )instance := new FabriqueDeServices()return instance}}
Ex. de calcul de taxes
: Magasin : Magasin : Registre : Registre : FabriqueServices : FabriqueServices
: AdaptateurCalculTaxes2 : AdaptateurCalculTaxes2
initialiser
getAdaptateurCalculTaxes()
create
getTaxes(vente)
Comment choisir l’adaptateur à créer ?
• Chargement dynamique de la classe• Le nom de la classe étant enregistré dans un fichier de
configuration système
• IAdaptateurCalculTaxes getAdaptateurCalculTaxes{• if ( adaptateurCalculTaxes1 == null )• {• String className = System.getProperty( "calculateurTaxes.class.name" );• adaptateurCalculTaxes=
(IAdaptateurCalculTaxes) Class.forName( className ).newInstance();• }• return adaptateurCalculTaxes1 ;• }
Algorithmes variables mais apparentés
• Stratégie• Pb: les politiques de tarification sont variables
mais apparentés, pouvant évoluer• Sol: définir chaque algorithme, politique,
stratégie dans une classe distincte mais avec une interface commune
Ex de tarification composite
• Réduction 15% le mercredi• Réduction 5% pour cartes privilèges sur toute
vente supérieur à 200 euros• Réduction fixe de 20 euros le lundi pour toute
vente supérieure à 500 euros
• Tarification nombreuse et conflictuelle pouvant coexister
• Solution partielle: définir une stratégie de résolution de conflit: ex. politique la « plus avantageuse pour le client »si … alors
• Tarification peut dépendre• Du type de client• Du type du produit
Pattern Composite
Strategie PourcentageRemise
getTotal(v : vente)
strategie RemiseParDate
getTotal(v : vente)
strategieComposite orienteeClient
getTotal(v : vente)
strategieComposite orienteeMagasin
getTotal(v : vente)
ventedate
getTotal()
strategie tarificationComposite
getTotal(v : vente)ajouter(s : IStrategieTarification)
IStrategieTarification
getTotal(v : vente)11 1..n
+strategies
1..n
Facade (d’un sous-système)
Façade IHM (push-from-below)
Modèle de délégation d’événements• Diffusion-souscription• Observateur (souscripteur, auditeur) - observable (diffuseur) • Pb: différents types d’objets souscripteurs (observateurs) sont
concernés par les changements d’états et les événements diffuseurs (observable) et veulent réagir chacun à leur manière lorsque le diffuseur génère un événement
• De plus, le diffuseur veut maintenir une faible couplage avec les souscripteurs
• Solution: définir une interface « souscripteur » ou « listener ». Les souscripteurs implémentent cette interface. Le diffuseur peut enregistrer dynamiquement les souscripteurs intéressés par un événement et le leur signaler
• Le diffuseur délègue le traitement de l’information au souscripteur
Affichage totalcode articlesetc.
Autre affichage total
Couche présentation- couche domaine
Serveur
:vente1:vente1 :vente1
:vente1
souscripteurs
diffuseurs
L’observateur FrameVente souscrit auprès du diffuseur vente
: Registre : Registre
fmv : FrameVente
fmv : FrameVente
v : ventev : vente auditeursDePropriétés[i] : auditeurDePropriétés
auditeursDePropriétés[i] : auditeurDePropriétés
initialiser(v: vente)
ajouterAuditeurDeProprietes(fmv)
ajouter(fmv)
La vente diffuse un événement à l’intention des souscripteurs
: vente : venteAuditeursDePropriétés[i] :
auditeurDePropriétésAuditeursDePropriétés[i] :
auditeurDePropriétés
setTotal(ntotal)
diffuserEvenementProprietes("vente.total", ntotal)
*[i=1...n] evenementSurPropriete(v, "vente.total", ntotal)
Autres diagrammes UML
Diagrammes d’états
• Objet état-indépendant: répond toujours de la même manière à un événement
• Objet état-dépendant: réagit différemment aux événements selon leur état
Machines à états• Utiliser pour objets réactifs à comportement complexe• Équipements physiques controlés par logiciels• Transaction et objets métiers (vente, commande, paiement)• Objets qui changent de rôle. Ex Personne civile devient
militaire
• Protocoles et séquences légales– Flots page/fenêtre IHM– Contrôleur flots ou session d’une interface utilisateur– Opérations systèmes des cas d’utilisations (ex.
creerPaiement ne peut survenir avant fin vente)
déf• Événement: occurrence d’un fait significatif ou
remarquable• État: condition d’un objet à un moment
donné, y demeurre jusqu’à arrivée nouvel événement
• Transition: relation entre deux états indiquant que l’objet change d’état lorsqu’un événement se produit
exercice• Dessiner un diagramme d’états de la
séquence légale des opérations du CU « traiter une vente »
Diagramme de package
Package : unité de de base de développement et de livraisonEmboitablesDépendances entre packages: Ventes et Payements font appel à des éléments de « concepts communs »
Partitionner Modèle du domaine en package
• Regrouper les:• Les éléments situés dans le même domaine
(étroitement liés par leur concept ou leur vocation)
• Éléments situés dans la même hiérarchie de classes
• Éléments participant aux mêmes cas d’utilisation
• Éléments fortement associés
Communs divers
Ventes utilise core:register et core:store
Conception packages
• Organiser en partitions verticales et horizontales fonctionnellement cohésives
• Packager une famille d’interfaces dans un package distinct de ceux des implémentations
• Créer un package par tâche et par groupe de classes instables
• Ex si P1 contient 40 classes dont 10 instablesAlors scinder P1 en 2: P1-a et P1-b
Conception package• Les packages les plus responsables (qui engendrent les plus
de dépendances) doivent être les plus stables• Factoriser les types (classes, interfaces) indépendants pour
être réutilisés ( peut être division par fonctionnalité n’offre pas granularité suffisante)
Conception package
• Utiliser des Fabrications pour limiter la dépendance aux packages concrets• Ex objet Registre et PayementMapping créent PayementCredit• Crée dépendance entre un objet et son créateur
Réduire couplage avec Fabrique
Pas de cycles dans les packages• Factoriser les types qui participent aux cycles dans un
nouveau package plus petit• Rompre le cycle à l’aide d’une interface
Exercice
Diagramme de déploiementune vue statique représentant utilisation de l'infrastructure physique par le
système et la manière dont les composants du système sont répartis ainsi que leurs relations entre eux. Utilise des nœuds (physiques, environnement d’exécution) les composants, les associations entre eux
Déploiement d’une architecture 3-tier