Nol NOVELLI ; Universit de la Mditerrane ; LIF et Dpartement dInformatique Case 901 ; 163 avenue de Luminy 13 288 MARSEILLE cedex 9

Gnie Logiciel
Merise Modlisation objet UML

MERISE
Les modles de la mthode Merise :
Le modle de flux Le modle conceptuel de donnes Le modle conceptuel de traitements Le modle organisationnel de traitements Le modle logique de donnes Le modle oprationnel des traitements Le modle physique des donnes

En savoir plus sur Merise :

La mthode MERISE - H. Tardieu, A. Rochefeld, R. Colletti
Ce support nest quune adaptation des supports rdigs par Isabelle VALEMBOIS (Thales-services)

MODELISATION OBJET (1/6)

Principaux concepts objet :
Classe
Type dobjet caractris par sa structure de donnes (attributs) et son comportement (mthodes) Un objet reprsente un individu, une entit identifiable relle ou conceptuelle avec un rle bien dfini dans le domaine du problme ou dans un systme (instance de classe) Un attribut est une proprit, une caractristique, une qualit inhrente ou distinctive dun objet (exemples : la couleur ou limmatriculation dune voiture) Une mthode est une action quun objet effectue de sa propre initiative ou la demande (raction un vnement ou un envoi de message). Ces mthodes dcrivent les proprits dynamiques dun objet.

MODELISATION OBJET (2/6)

Principaux concepts objet :
Quelques mthodes "classiques" :
Un constructeur est une mthode qui permet de construire et dinitialiser un objet (instanciation dun objet) Par opposition, un destructeur est une mthode qui permet de dtruire un objet instanci Un accesseur est une mthode qui permet de rcuprer la valeur dun attribut dun objet (get et is) Un modificateur est une mthode qui permet de modifier la valeur dun attribut dun objet (set) Un observateur est une mthode qui permet de retrouver des informations sur lhistoire (ltat) dun objet Un itrateur est une mthode qui permet dappliquer chaque partie dun objet (par exemple dans le cas dun objet de type collection) une action dtermine

Objet

Attribut

Mthode

MODELISATION OBJET (3/6)

Principaux concepts objet :
Association
Une association permet de prciser une relation entre diffrents objets. Une association possde gnralement un nom qui sert dcrire la nature de la relation Une association est galement caractrise par le nombre dobjets pouvant tre relis par lintermdiaire dune instance dassociation : 0..1, 0..n, 1..n, n..n Une agrgation est une relation binaire entre deux objets qui spcifie une inclusion entre une partie et un tout. Une partie peut appartenir dautres agrgations et exister indpendamment Une composition est un type particulier dagrgation qui spcifie une inclusion entre une partie et un tout plus forte que lagrgation : quand on supprime llment composite, il y a obligatoirement suppression des composants

MODELISATION OBJET (4/6)

Principaux concepts objet :

Hritage
Mcanisme permettant une classe dobjets de bnficier de la structure de donnes et du comportement dune classe "mre", tout en lui permettant de les affiner et ce, afin de prendre en compte les spcificits de la classe "fille", sans avoir cependant redfinir ce que les deux classes ont de commun

Agrgation

Gnralisation
Dans le cas dun hritage, on dit quune classe "mre" est une gnralisation des proprits de ses classes "fille"

Composition

Spcialisation
Dans le cas dun hritage, on dit quune classe "fille" est une spcialisation des proprits de sa classe "mre"

MODELISATION OBJET (5/6)

Principaux concepts objet :
Encapsulation (interface)
Mcanisme permettant de dissimuler les dtails du fonctionnement interne dune classe aux autres classes Mcanisme permettant la dissociation entre la dclaration dune classe et son implmentation (interface) Mcanisme permettant dassocier un comportement, une implmentation diffrente en fonction de lobjet auquel on se rfre (par exemple : dessiner lcran un carr ou un cercle). Lmetteur na pas besoin de connatre la classe du receveur, seulement que la smantique du message sera la mme pour toutes les classes similaires (par exemple : la mthode toString en JAVA, les injecteurs en C++)

MODELISATION OBJET (6/6)

Principaux concepts objet :
Message
Mcanisme caractristique des langages objet. Le message est lunique support de communication entre objets. Larrive dun message provoque lexcution dune mthode de lobjet Public Private Protected Mcanisme permettant de dclarer plusieurs constructeurs ou plusieurs fois une mme mthode (mme nom) dans une classe, condition que tous aient une signature diffrente (valeur de retour et/ou paramtres diffrents)

Abstraction (classe abstraite)

Type daccs, porte, visibilit

Polymorphisme

Surcharge de mthode

UML (1/24)
UML (Unified Modeling Language) : Auteurs
James Rumbaugh, Grady Booch et Yvar Jacobson

UML (2/24)
UML nest pas une mode :
Issu du terrain et dun large consensus (industriels, informaticiens, mthodologistes), fruit dun travail dexperts (HP, Microsoft) Norme riche (permet de spcifier du dbut la fin) et ouverte (en constante volution depuis sa cration) Indpendant de la cible Adapt la programmation orient objet Industrialis (il existe de nombreux doutils)

Objectifs
Faciliter la communication entre les diffrents acteurs dun projet Faciliter la communication avec la machine Documenter un projet de bout en bout Spcifier et donc limiter les ambiguts Construire (interprter les diagrammes pour code)

Dfinition
Langage de description des objets permettant une modlisation rigoureuse des systmes complexes Langage Unifi pour la Modlisation objet

Plus dinformations sur UML : http://uml.free.fr

UML (3/24)
Avantages dUML :
Formel et normalis (garantit stabilit et performance dun projet, rduit les risques) Support de communication performant et prouv (permet de cadrer lanalyse et de faciliter la comprhension de reprsentations abstraites : cest lesperanto de lanalyse)

UML (4/24)
Historique

Inconvnients dUML :
Priode dapprentissage Processus de production non couvert

UML (5/24)
Diagrammes UML :

UML (5/24)
Dcouverte des besoins Diagramme de cas dutilisation : dcrit les fonctions du systme (point de vue de ses futurs utilisateurs -Jacobson) Diagramme de squence : reprsentation des interactions temporelles entre objets dans la ralisation dune IHS Analyse Diagramme de classes : structure des donnes Diagramme dobjets : illustration Diagramme collaboratif : reprsentation des interactions entre objets Diagramme dtats : reprsentation du comportement des objets dune classe en terme dtats et de transitions dtats Diagramme dactivits : structure dune opration en actions

UML (5/24)
Conception Diagramme de squence : reprsentation des interactions temporelles entre objets dans la ralisation dune opration Diagramme de dploiement : description du dploiement des composants sur les dispositifs matriels Diagramme de composants : architecture des composants physiques dune application

UML (6/24)
Le diagramme de cas dutilisation :
Il permet didentifier et de dcrire les utilisateurs du systme (acteurs) et leur interaction avec le systme

Dmarche :
Identification des acteurs
Acteur

Identification des cas dutilisation

CU

UML (7/24)
Les relations dans un diagramme de cas dutilisation :
Utilisation : la relation include indique quun CU utilise un autre CU. Si le CU source est vide, alors dcomposition
<< include >>
Imprimer solde Consulter compte

UML (8/24)
Exemple de diagramme de cas dutilisation :

<< include >>

Imprimer ticket

Extension : la relation extend du CU A vers le CU B indique que le CU B peut aussi faire A. Ceci permet aussi les CU avec garde.
<< extend >>
retirer de largent retirer des Francs

<< extend >>

retirer des Euros

Au moins un des deux et pas les deux

UML (9/24)
Les Classes

UML (10/24)
Le diagramme de classes :
Il permet de dcrire les classes dun systme ainsi que les associations et les relations dhritage entre ces classes
Les associations (forme verbale)

+ attributs drivs ou calculables

active,

Personne

Travaille pour >

Socit

rles,

Personne

Employ Employeur

Socit

cardinalit,

Personne

1..* *

Socit

qualification ou restriction

Universit

N tudiant

Etudiant

UML (11/24)
Le diagramme de classes :
Il permet de dcrire les classes dun systme ainsi que les associations et les relations dhritage entre ces classes
Composition et agrgation

UML (12/24)
Le diagramme dobjets :
Le diagramme dobjets est un cas illustr dun diagramme de classes. Selon le contexte, il montre la relation entre les objets

Lhritage

UML (13/24)
Le diagramme de collaboration :
Le diagramme de collaboration est une extension des diagrammes de classes Il montre les interactions entre objets et vise reprsenter du point de vue statique et dynamique les objets impliqus dans la mise en place dune fonction applicative

UML (14/24)
Le diagramme dtats (transitions) :
Il permet de dcrire les changements d'tats d'un objet, en rponse aux interactions avec d'autres objets ou avec des acteurs
Etat initial Etat final

Etat

Un diagramme dtats possde

Un tat initial Au moins un tat final

UML (15/24)
Exemples de diagrammes dtats :
Evnement
Perte demploi() En activit Embauche() Au chmage

UML (16/24)
Le diagramme dtats (suite) :
Actions dans un tat

+ de 60 ans

+ de 60 ans En retraite

Synchronisation

Transition garde
A
Il fait trop chaud [t] Il fait trop chaud [hiver]

climatise

are

UML (17/24)
Le diagramme dtats (suite) :
Gnralisation

UML (18/24)
Le diagramme de squences :

E1 E2 C

Il permet de reprsenter des interactions entre les objets selon un point de vue temporel

Reprsentation dun objet :

Classe (grand rectangle) Axe chronologique (ligne)
classe

A E2

E1

B E2

Dbut et fin de linteraction

(petit rectangle sur laxe)

NB : Il prsente un certain nombre danalogies avec le diagramme de collaboration

UML (19/24)
Le diagramme de squences :
Les messages :
simples synchrones
Objet : classe

UML (20/24)
Le diagramme de squences :
Ajout de pseudo-code Branche conditionnel

Autre objet

asynchrones rflectifs avec dlai

If else end if

UML (21/24)
Exemple de diagramme de squences : Le diagramme dactivits :

UML (22/24)

Il sagit dune variante du diagramme dtattransition reprsentant la dynamique du systme Il sert reprsenter le comportement interne dun cas dutilisation. Son intrt rside dans la reprsentation simplifie des activits.

UML (23/24)
Le diagramme de composants :
Il dcrit les lments physiques et leurs relations dans lenvironnement de ralisation Il montre les choix de ralisation

UML (24/24)
Le diagramme de dploiement :
Il montre la disposition physique des diffrents matriels (nuds) qui entrent dans la composition dun systme et la rpartition des programmes excutables sur ces matriels Il montre les choix de ralisation

OUTILS (1/3)
Outils Merise : Power AMC MS-Designer Outils UML : Rational Rose (rachet et intgr par IBM) Objecteering Together ControlCenter ArgoUML, Posidon Outils de gestion de tests : Mercury TestDirector Compuware QADirector Rational TestManager

OUTILS (2/3)
Critres de slection des outils UML :
Respect des normes UML OS supports Stabilit Exhaustivit des diagrammes Correspondance relationnel Gnration de code Format de documentation Gestion de configuration Reverse engineering Gestion de tests

OUTILS (3/3)
Caractristiques des principaux produits de modlisation :

SPECIFICATIONS (1/5)
La spcification des besoins (ou des exigences)
Point de dpart Dans les activits de spcification des exigences, il convient dabord de considrer le systme comme une bote noire part entire, afin dtudier sa place dans le systme mtier plus global quest lentreprise. On dveloppe pour cela un modle de niveau contexte, qui va prciser les frontires fonctionnelles du systme.

SPECIFICATIONS (2/5)
La spcification des besoins (suite)
Cette activit met donc en uvre un mode de reprsentation fonctionnel sappuyant sur :
Les diagrammes de cas dutilisation qui permettent didentifier et de formaliser les diffrents acteurs ainsi que les services attendus de la future application. La maquette pour sa part, permet de prsenter de manire concrte ces services via les IHM (Interface Homme Machine) de lapplication. Elle est destine plus particulirement faire ragir les utilisateurs de la future application afin dy apporter les mises au point ncessaires une complte adquation entre les services rendus par lapplication et les besoins des utilisateurs.

SPECIFICATIONS (3/5)
La spcification des besoins (suite)
Exemple de diagramme de cas dutilisation :

SPECIFICATIONS (4/5)
La spcification des besoins (suite)
Exemple de description pour le cas dutilisation sauthentifier

SPECIFICATIONS (5/5)
La spcification des besoins (suite)
Exemple de maquette :

ANALYSE (1/8)
Lanalyse
tape intermdiaire entre la spcification des besoins et la conception du systme

ANALYSE (2/8)
Lanalyse statique
Pour identifier les classes de conception intervenant dans les diagrammes dinteraction du modle conceptuel, deux soustapes sont ncessaires :
Construire le modle du domaine. Sorte de glossaire formalis des concepts fondamentaux de lespace du problme, ce modle fournit une partie des classes de conception : celles correspondant directement aux concepts mtier manipuls par les experts du domaine et les utilisateurs. Ces concepts, leurs attributs et leurs relations vont tre dcrits en UML par des diagrammes de classes simplifies. Construire les diagrammes de classes participantes. Afin de prendre en compte galement lIHM et la cinmatique de lapplication, les diagrammes de classes participantes font la jonction entre les cas dutilisation, le modle du domaine, la maquette et les diagrammes de conception logicielle. Il sagit de diagrammes de classes qui dcrivent, par cas dutilisation, les trois principales classes danalyse et leurs relations.

ANALYSE (3/8)
Lanalyse statique (suite)
Les diagrammes de classes participantes :
Les classes de type dialogue : elles permettent les

ANALYSE (4/8)
Lanalyse statique (suite)
Exemple de modle du domaine pour le CU sauthentifier :

interconnections entre lIHM et ses utilisateurs. Ce sont typiquement les crans proposs lutilisateur : les formulaires de saisie, les rsultats de recherche Elles proviennent directement de lanalyse de la maquette. Les classes de type mtier : elles reprsentent les rgles mtier et proviennent directement du modle du domaine mais sont confirmes et compltes pour chaque cas dutilisation. Les classes de type contrle : elles contiennent la cinmatique de lapplication et font la transition entre les dialogues et les classes mtier, en permettant aux crans de manipuler des informations dtenues par un ou plusieurs objets mtier.

ANALYSE (5/8)
Lanalyse statique (suite)
Exemple de diagramme de classes participantes pour le CU sauthentifier :

ANALYSE (6/8)
Lanalyse dynamique
Le modle dynamique permet de dcrire :
Pour chaque cas dutilisation, la squence des interactions entre les acteurs et le systme vue comme une bote noire, reprsente par les diagrammes de squence systme. Ce sont ces diagrammes qui feront le lien entre les cas dutilisation et les diagrammes dinteraction du niveau conceptuel. Dautre part, pour reprsenter de manire formelle lensemble des chemins possibles entre les principaux crans proposs lutilisateur, et partir des informations fournies par la maquette, il reste dtailler les diagrammes dactivits de navigation. Si ncessaire, le cycle de vie commun aux objets dune mme classe, peut tre explicit par les diagrammes dtats.

ANALYSE (7/8)
Lanalyse dynamique (suite)
Exemple de diagramme de squence systme pour le CU sauthentifier :

ANALYSE (8/8)
Lanalyse dynamique (suite)
Exemple de diagramme dactivits de navigation pour le CU sauthentifier :

CONCEPTION (1/3)
La conception du systme
Cible Dans les activits de conception, le modle correspond aux concepts informatiques utiliss par les outils, les langages ou les plates-formes de ralisation. Le modle sert ici tudier, documenter, communiquer et anticiper la solution logicielle.

CONCEPTION (2/3)
La conception du systme (suite)
Dans le cadre de systmes orients objet, la structure du code est dfinie par des classes logicielles et leurs regroupements en ensemble (appels packages). La conception reprsente deux points de vue : la structure statique et le comportement dynamique, deux perspectives qui compltent la comprhension du systme dvelopper. Le modle statique, qui permet de dcrire les diffrents composants logiciels structurant le systme, est reprsent laide de diagrammes de classes de conception. Le modle dynamique, permet quant lui de dcrire lattribution des bonnes responsabilits (services) aux bonnes classes. Tout le comportement du systme est ainsi rparti entre les classes de conception. Cest le rle des diagrammes dinteraction (diagrammes de squence ou de collaboration) de reprsenter graphiquement ces dcisions dallocation de responsabilits ainsi que les collaborations induites.

CONCEPTION (3/3)
La conception du systme (suite) 1 - 2
Exemple de diagramme de classes de conception de Struts :

CONTENU DU DAF (1/2)

Introduction
Objectifs du document Cible du document Terminologie et acronymes Structure du document Documents de rfrence

Spcifications des besoins

Acteurs Diagramme des cas dutilisations Pour chaque CU : description du cas dutilisation Contraintes fonctionnelles

CONTENU DU DAF (2/2)

Analyse
Pour chaque CU :
Modle du domaine Diagramme de classes participantes Diagramme de squence systme Diagramme dactivits de navigation Diagramme dtats le cas chant

STRATEGIE DE TESTS (1/4)

Enjeux de lactivit de tests
Enjeux mtier :
Adquation aux besoins Non rgression

Enjeux techniques :
Niveau de service o Performance o Tolrance aux pannes o Exploitabilit Scurit Prennit et volutivit

Conception
Pour chaque CU :
Diagramme de classes de conception Diagramme de squence ou de collaboration

Annexes
MCD et MPD (le cas chant)

Enjeux conomiques
Rduction des cots de recette Rduction de cots de maintenance

STRATEGIE DE TESTS (2/4)

Les 6 bonnes pratiques de lactivit de tests
Lactivit de test doit tre anticipe Les responsables de lactivit doivent tre identifis Des ressources doivent tre ddies lactivit Lutilisation doutils doit tre favoris Lexhaustivit tant bien souvent utopique, il faut viser la reprsentativit des cas de tests Les tests doivent tre formaliss dans un dossier de test. Celui-ci comportera 5 parties :
Prsentation du plan de test Le cahier de test Le rfrentiel des cas et scnarios de tests fonctionnels Le rfrentiel des cas et scnarios de tests techniques Le journal des tests

STRATEGIE DE TESTS (3/4)

Prsentation du plan de tests
Objectif : dtecter un maximum danomalies susceptibles de perturber le fonctionnement dun logiciel. Les anomalies tant de nature diverse, il est ncessaire de dfinir une stratgie en fonction de chaque type de tests. La dmarche consiste :
dfinir chaque type de test (fonctionnels en excution attendue, fonctionnels en excution dgrade, de performance) tablir pour chacun les objectifs assigner une priorit ces objectifs

construire une matrice de couverture estimer le plan de charges et planifier

STRATEGIE DE TESTS (4/4)

Cahier de test
Il a pour objectif de prsenter les modles de rfrence en terme de tests pour le projet. A ce titre, il contient tous les modles de documents utiliss dans le cadre de lactivit de tests :
cas de test scnario de tests fiche danomalie tableau de bord des anomalies

REUTILISABILITE (1/11)
Dfinitions :
La rutilisabilit est laptitude dun logiciel tre rutilis en tout ou en partie pour de nouvelles applications La rutilisabilit consiste se servir dun composant pour en crer un nouveau

Objectifs :
Optimiser les cots de dveloppement Optimiser les cots de maintenance Fiabiliser les dveloppements Favoriser lvolutivit, ladaptabilit, lutilisabilit

Rfrentiel des cas et scnarios de tests fonctionnels

Il a pour objectif de rassembler les lments suivants :
Cas et scnarios de tests formaliss sur les fiches correspondantes Prsentation de la logique dordonnancement des tests et planning

10

REUTILISABILITE (2/11)
Techniques de rutilisabilit :
La duplication (inconvnient : la maintenabilit). Le pr-processing : trs similaire la technique prcdente, il intgre un outil spcialis, le pr-processeur. Ainsi, les corrections d'erreurs comme les volutions apportes la partie rutilise profitent l'application d'origine (inconvnient : si des modifications sont faites sur le code rutilisable et si tous les utilisateurs ne sont pas informs de ces modifications, ceci peut altrer le fonctionnement peru par les autres utilisateurs). Les bibliothques de composants : cette technique consiste appeler un composant excutable et d'en exiger un certain comportement l'aide de paramtres. Les frameworks : dans les bibliothques de composants, c'est l'application qui invoque une routine de la bibliothque et c'est l'application qui fait le contrle. Dans les frameworks, la situation est inverse, c'est le framework qui dirige les tches et qui fait des appels l'application si ncessaire (Exemple : Struts).

REUTILISABILITE (3/11)
Techniques de rutilisabilit (suite) :
Les techniques cites prcdemment ne sapplique qu la phase dimplmentation La rutilisabilit peut galement tre applique tous les niveaux de dveloppement dun projet Les patterns de conception : ils dcrivent des problmes rcurrents, les solutions ces problmes et les contextes dans lesquels ces solutions sont considres. Un pattern nomme une technique, dcrit ses cots et ses avantages. Il permet, une quipe, de mettre un vocabulaire en commun pour dcrire des modles (Exemple : Model View Controler II)

REUTILISABILITE (4/11)
Les trois grandes familles de design patterns :
Les patterns de cration : ces patterns crent les objets pour vous, au lieu de les instancier directement : Le pattern Factory Method dfinit une interface pour crer un objet, mais laisse les sous classes dcider quelle classe instancier Le pattern Abstract Factory fournit une interface pour crer des familles d'objets lis sans spcifier leurs classes concrtes Le pattern Builder spare la construction d'un objet complexe de sa reprsentation, de telle sorte que plusieurs reprsentations diffrentes peuvent utiliser le mme processus de construction Le pattern Prototype spcifie le type d'objet crer en utilisant une instance "prototype", et cre un nouvel objet en effectuant une copie de cet objet Le pattern Singleton assure qu'une classe a uniquement une instance, et fournit un accs cette instance

REUTILISABILITE (5/11)
Diagramme de classe du pattern singleton :

REUTILISABILITE (6/11)
Les trois grandes familles de design patterns :
Les patterns structurel : ces patterns composent des groupes d'objets en de larges structures, telles que des interfaces graphiques complexes : Le pattern Adapter convertit l'interface d'une classe en une autre interface Le pattern Bridge dcouple une abstraction de sa reprsentation pour que les deux puissent voluer indpendamment Le pattern Composite compose les objets dans une structure arborescente qui reprsente une hirarchie "partie-de" Le pattern Decorator attache de nouvelles responsabilits un objet dynamiquement Le pattern Facade fournit une interface unifie un ensemble d'interfaces dans un sous-systme Le pattern Proxy fournit un supplant pour un objet afin de contrler son accs

REUTILISABILITE (7/11)
Les trois grandes familles de design patterns :
Les patterns comportementaux : ces patterns dfinissent la communication entre les objets du systme et comment le flot de donnes est contrl dans un programme complexe : Le pattern Chain of responsability vite de coupler l'metteur d'une requte et son receveur, en donnant la possibilit plusieurs objets d'y rpondre Le pattern Command encapsule une requte dans un objet, pour permettre de paramtrer des clients avec diffrentes requtes, de grer des queues ou des traces de requtes, ou de permettre des oprations annulables Le pattern Iterator fournit un moyen d'accder squentiellement aux lments d'une agrgation d'objets sans dvoiler sa reprsentation Le pattern Mediator dfinit un objet qui encapsule les interactions dun ensemble dobjets Le pattern Memento, sans violer l'encapsulation, capture et externalise l'tat interne d'un objet pour permettre de restaurer cet tat plus tard Le pattern Observer dfinit une relation un--plusieurs telle que lorsqu'un objet change, tous les objets lis sont notifis de ce changement et mis jour automatiquement

11

REUTILISABILITE (8/11)
Pour utiliser les patterns de conception :
Se familiariser avec lutilisation des patterns de conception Apprendre identifier les bons patterns de conception Comprendre leur applicabilit Apprendre adapter un pattern ses besoins Apprendre valuer efficacement les compromis durant la conception

REUTILISABILITE (9/11)
Exemple dutilisation des patterns de conception : MVC 1 - 2
Lide de dcoupler modle et vues permet de conserver une sparation nette entre le modle et la faon de le reprsenter. Cette ide est applicable un problme plus gnral : dcoupler des objets de faon ce quun changement dun objet puisse affecter un nombre variable dautres objets sans que lobjet qui a chang ait connatre en dtail les autres objets.
Ce problme plus gnral est dcrit par le patron de conception Observer.

Une autre caractristique du modle MVC est de permettre limbrication de vues les unes dans les autres, afin de permettre la construction de vues plus complexes. MVC supporte les vues imbriques laide de la classe CompositeView, une sousclasse de View. Un objet de la classe CompositeView se comporte exactement comme un objet de la classe View, et peut tre utilis partout o un objet de la classe View est utilis, mais en plus, un objet de la classe CompositeView permet de grer des vues imbriques.

REUTILISABILITE (10/11)
Exemple dutilisation des patterns de conception :
Encore une fois, lide dimbriquer des objets et de traiter lobjet rsultant comme un seul objet individuel correspond un problme de conception plus gnral.
Ce problme plus gnral est dcrit par le patron de conception Composite.

REUTILISABILITE (11/11)
Pour dcrire un pattern de conception :
Le nom du patron Son intention Une motivation Son applicabilit Sa structure Les classes ou objets participants Les collaborations entre les participants De mme que des commentaires sur les consquences dutilisation, sur certains compromis possibles, sur limplmentation et sur les patrons relis.

Le modle MVC permet galement de modifier la faon dont ragit une vue une entre faite par lusager sans changer son apparence visuelle. MVC encapsule le mcanisme de rponse dans un objet Controler. Les diffrents types de Controler sont organiss dans une hirarchie de classe, et une vue utilise une instance dune des sous-classes de Controler.
La relation View-Controler est dcrite par le patron de conception Strategy.

REUTILISABILITE
Principes de rutilisabilit (suite) Les patterns de conception :
MVC pour la couche prsentation DAO pour la couche accs aux donnes

Modle Vue Contrle (1/2)

MVC (Model - View - Controller) est un pattern destin la conception dapplications GUI. Son principe de base est la sparation des composants suivants :
Le modle : il conserve toutes les donnes relatives lapplication (sous quelque forme que ce soit : base de donnes, fichiers) et contient la logique mtier de lapplication. La vue : elle a pour rle doffrir une prsentation du modle (IHM). On peut avoir de nombreuses vues pour un mme modle, chacune prsentant les informations de manire diffrente (on pourrait ainsi imaginer une liste darticles prsentable la fois sur lcran dun navigateur web, sur un PALM, sur un minitel ou sur une imprimante) Le contrleur : cest le composant qui rpond aux actions de lutilisateur. Il traduit les vnements de lIHM en modifications du modle et dfinit galement la manire dont lIHM doit ragir face aux interactions de lutilisateur.

Les frameworks techniques :

Struts, Barracuda, Expresso, Turbine, Avalon log4J pour la gestion de log Castor pour le mapping relationnel

Les bibliothques de composants techniques :

taglibs javamail jaxp...

12

Modle Vue Contrle (2/2)

Les avantages du modle MVC sont les suivants :
Les 3 parties de lapplication logique de prsentation, logique mtier et logique applicative sont parfaitement indpendantes. Ainsi, la programmation de chacune peut tre distribue des quipes de dveloppement diffrentes. La maintenance de lapplication est plus souple. Ce dcoupage permet par exemple de modifier la prsentation sans toucher la structure du site ni la logique mtier.

STRUTS (1/2)

Linconvnient du modle MVC est le suivant :

Une architecture de type MVC ncessite un temps dapprentissage non ngligeable.

Au final, cet inconvnient est largement contrebalanc par le temps gagn lors des volutions et de la maintenance.

1-2

STRUTS (2/2)

1-2

13