heg haute école de gestion de neuchâtel 14/11/01uml 02 v1-11 les classes le monde réel est...

14/11/01 UML 02 V1-1 1

hegHaute école de gestionde Neuchâtel

Les classes

• Le monde réel est constitué de très nombreux objets en interaction. Ces objets constituent des amalgames souvent trop complexes pour être compris dans leur intégralité du premier coup. Pour réduire cette complexité - ou du moins pour la maîtriser – et comprendre ainsi le monde qui l’entoure, l’être humain a appris à regrouper les éléments qui se ressemblent et à distinguer des structures de plus haut niveau, débarrassées de détails inutiles.

[PAM-00 p33]

14/11/01 UML 02 V1-1 2


La démarche d’abstraction

[PAM-00 p33]

Cycle d’abstractionReprésentation Global

Détail

14/11/01 UML 02 V1-1 3


Classe & objets

• La classe décrit le domaine de définition d’un ensemble d’objets. Chaque objet appartient à une classe. Les généralités sont contenues dans la classe et les particularités sont contenues dans les objets. Les objets informatiques sont construits à partir de la classe, par un processus appelé instantiation. De ce fait, tout objet est une instance de classe.

[PAM-00 p33]

14/11/01 UML 02 V1-1 4


Représentation graphique des classes

Nom de classe

Attributs

Opérations()

14/11/01 UML 02 V1-1 5


Exemple de classe

14/11/01 UML 02 V1-1 6


Contrat

• Une classe passe un contrat avec d’autres classes; elle s’engage à fournir les services publiés dans sa spécification et les autres classes s’engagent à ne pas faire usage de connaissances autres que celles connues dans cette spécification.

• La séparation entre la spécification et la réalisation des classes participe à l’élévation du niveau d’abstraction. Les traits remarquables sont décrits dans les spécifications alors que les détails sont confinés dans les réalisations. L’occultation des détails de réalisation est appelée encapsulation.

[PAM-00 p38]

14/11/01 UML 02 V1-1 7


Compartiments supplémentaires

Nom de classe

Attributs

Opérations

Responsabilités

Exceptions

Messages

Contrat

14/11/01 UML 02 V1-1 8


Encapsulation

Interfaces Implémentation[PAM-00 p39]

14/11/01 UML 02 V1-1 9


Exemple d’encapsulation

Propriété privée

Opérations publiquesInterface

14/11/01 UML 02 V1-1 10


Règles de visibilité

• Par défaut, les valeurs d’attributs d’un objet sont encapsulés dans l’objet et ne peuvent pas être manipulés directement par les autres objets. Toutes les interactions entre les objets sont effectués en déclenchant les diverses opérations déclarées dans la spécification de la classe et accessibles depuis les autres objets.

• L’intérêt de briser l’encapsulation est par exemple de réduire le temps d’accès aux attributs…

[PAM-97 p39]

14/11/01 UML 02 V1-1 11


Règles de visibilité - niveaux

Règles de visibilité

+ Attribut public# Attribut protégé- Attribut privé

+ Opération publique()# Opération protégée- Opération privée

14/11/01 UML 02 V1-1 12


Visibilité

• [BRJ-00 p132] La visibilité est l’un des détails les plus importants que l’on puisse spécifier pour les attributs et les opérations d’un classificateur (ou en simplifiant: d’une classe). La visibilité d’une caractéristique détermine si d’autres classes peuvent l’utiliser. En UML, on utilise 3 niveaux de visibilité.

1. public

2. protected

3. private

14/11/01 UML 02 V1-1 13


Critères d’encapsulation

• Les critères d’encapsulation reposent sur la forte cohérence interne à l’intérieur d’une classe et sur le faible couplage entre les classes. Il ne suffit pas pour obtenir une bonne abstraction, de rassembler des données et de fournir des opérations pour la lecture et l’écriture de ces données.

[PAM-00 p41]

• Une classe doit offrir une valeur ajoutée par rapport à la simple juxtaposition d’informations.

14/11/01 UML 02 V1-1 14


Les relations entre les classes

• A chaque famille de liens entre objets correspond une relation entre les classes de ces mêmes objets.

• 2 sortes de relations entre les classes– Les associations– Les agrégations

[PAM-00 p41]

14/11/01 UML 02 V1-1 15


L’association

• L’association exprime une connexion sémantique bidirectionnelle entre classes.

• Une association est une abstraction des liens qui existent entre les objets instances des classes associées.

• Les associations se représentent de la même manière que les liens.

[PAM-00 p41]

14/11/01 UML 02 V1-1 16


Liens entre objets et association entre classes

14/11/01 UML 02 V1-1 17


Rôles

• Il est possible de préciser le rôle d’une classe au sein d’une association: un nom de rôle peut être spécifié de part et d’autre de l’association.

[PAM-00 p42]

14/11/01 UML 02 V1-1 18


Visualisation des rôles

14/11/01 UML 02 V1-1 19


Multiplicité

• Les rôles portent également une information de multiplicité qui précise le nombre d’instances qui participent à la relation

[PAM-00 p42]

1 ou 1..1 Un et un seul

0..1 Zéro ou un

M..N De M à N (entiers naturels)

* ou 0..* De zéro à plusieurs

1..* De un à plusieurs

14/11/01 UML 02 V1-1 20


Figure 54 / Exercice 1

[PAM-97 p45]

La donnée est corrigée pour que les multiplicités soient correctes.Une école immatricule des personnes; une personne qu’elle soit enseignante ou étudiante est obligatoirement immatriculée par une école.Une personne n’est employée par une école que si elle est enseignante; de plus, elle ne peut enseigner que dans une et une seule école.

14/11/01 UML 02 V1-1 21


Lecture des rôles et cardinalités

Une école « Emploie »

Une personne « Enseigne » dans 0..1 école

14/11/01 UML 02 V1-1 22


L’agrégation

• Une relation exprime une forme de couplage entre abstractions. La force de ce couplage dépend de la nature de la relation dans le domaine du problème. Par défaut, l’association représente un couplage faible, les classes associées restant relativement indépendantes l’une de l’autre. L’agrégation est une forme particulière d’association qui exprime un couplage plus fort entre classes. Une des classes joue un rôle plus important que l’autre dans la relation. L’agrégation permet de représenter des relations de type maître et esclaves, tout et parties ou composés et composants.

[PAM-00 p43]

14/11/01 UML 02 V1-1 23


La composition

• La composition est une forme d’agrégation avec un couplage plus important. Ce couplage de composition indique que les composants ne sont pas partageables et que la destruction de l’agrégat entraîne la destruction des composants agrégés.

• La valeur maximale de multiplicité du côté du conteneur ne doit pas excéder 1 puisque les objets, instances de la classe des composants, doivent tous appartenir au même objet conteneur.

[PAM-00 p44]

14/11/01 UML 02 V1-1 24


Agrégation et composition

• Une agrégation se fait par référence du ou des « enfant(s) » dans le contexte du « parent »– By reference

• Une composition se fait par valeur, c’est-à-dire copie du ou des « enfant(s) » dans le contexte du « parent »– By value

14/11/01 UML 02 V1-1 25


Cardinalité des compositions (Composants)

0..1

1

0..*

Une galerie peut exister sans être installée sur une voiture.

Une galerie ne peut exister que comme partie d’une voiture.

Physiquement impossible! Un composant ne peut être partie de plus d’un composite.Une galerie ne peut être installée, simultanément, sur plus d’une voiture.

[PAM-00 p45]

14/11/01 UML 02 V1-1 26


Cardinalité des compositions (Composite)

0..1

1

0..*

Une voiture n’est pas obligatoirement équipée d’une galerie.La galerie peut être assimilée à un attribut optionnel.

Toute voiture est équipée d’une galerie.La galerie peut être assimilée à un attribut obligatoire.

Une voiture peut être équipée de plusieurs galeries.

[PAM-00 p45]

14/11/01 UML 02 V1-1 27


Exemple d’agrégat et composition/ Exercice 2

14/11/01 UML 02 V1-1 28


Agrégation réflexive

[PAM-00 p43]

14/11/01 UML 02 V1-1 29


Les hiérarchies de classes

Les hiérarchies de classes ou classifications permettent de gérer la complexité en ordonnant les objets au sein d’arborescences de classes d’abstraction croissante.

– [KETT-98] La généralisation: il s’agit de prendre des classes existantes (déjà mises en évidence) et de créer de nouvelles classes qui regroupent leurs parties communes; il faut aller du plus spécifique vers le plus général.

– [KETT-98] La spécialisation: il s’agit de sélectionner des classes existantes (déjà identifiées) et d’en dériver de nouvelles classes plus spécialisées, en spécifiant simplement les différences.

[PAM-00 p47]

14/11/01 UML 02 V1-1 30


Généralisation

• La généralisation consiste à factoriser les éléments communs d’un ensemble de classes dans une classe plus générale appelée super-classe. Les classes sont ordonnées selon une hiérarchie; une super-classe est une abstraction de ses sous-classes.

• La généralisation est une démarche assez difficile car elle demande une bonne capacité d’abstraction. La mise au point d’une hiérarchie est délicate et itérative. Les arbres de classes ne poussent pas à partir de leur racine. Au contraire, ils se déterminent en partant des feuilles car les feuilles appartiennent au monde réel alors que les niveaux supérieurs sont des abstractions construites pour ordonner et comprendre.

[PAM-00 p47]

14/11/01 UML 02 V1-1 31


Figure 2-67 - Généralisation

Exemple de hiérarchie de classes construite par généralisation

[PAM-00 p48]

Abstractions plus générales

14/11/01 UML 02 V1-1 32


Figure 2-68 - Spécialisation

Exemple d’extension par spécialisation

[PAM-00 p48]

Extension par spécialisation

14/11/01 UML 02 V1-1 33


Figure 2-69 – Règles de généralisation (1)

La généralisation ne porte aucun nom particulier; elle signifie toujours: est un ou est une sorte de. La généralisation ne concerne que les classes, elle n’est pas instantiable en liens et, de fait, ne porte aucune indication de multiplicité.

Généralisation

Spé

cial

isat

ion

[PAM-00 p49]

14/11/01 UML 02 V1-1 34


Règles de généralisation (2)

• La généralisation ne porte ni nom particulier ni valeur de multiplicité.

• La généralisation est une relation non réflexive: une classe ne peut pas dériver d’elle-même.

• La généralisation est une relation non symétrique: si une classe B dérive d’une classe A, alors la classe A ne peut pas dériver de la classe B.

• La généralisation est par contre une relation transitive: si C dérive d’une classe B qui dérive elle-même d’une classe A, alors C dérive également de A.

[PAM-00 p49]

14/11/01 UML 02 V1-1 35


Des ensembles aux classes

• Les classes et les sous-classes sont l’équivalent des ensembles et des sous-ensembles. La notion de généralisation correspond à la relation d’inclusion des ensembles. De ce fait, les objets instances d’une classe donnée sont décrits par la propriété caractéristique de leur classe, mais également par les propriétés caractéristiques de toutes les classes parents de leur classe. Les sous-classes ne peuvent pas nier les propriétés caractéristiques de leurs classes parentes.

[PAM-00 p51]

14/11/01 UML 02 V1-1 36


Figure 70 – Exercice 3 -1

[PAM-97 p55]

14/11/01 UML 02 V1-1 37


Exercice 3 – 2 / Héritage des opérations

14/11/01 UML 02 V1-1 38


Exercice 3 – 3 / Héritage des attributs

14/11/01 UML 02 V1-1 39


Généralisation multiple (1)

La généralisation - sous sa forme dite multiple – existe également entre arbres de classes disjoints.

[PAM-00 p52]

14/11/01 UML 02 V1-1 40



Dans le monde des ensembles la généralisation multiple correspond à l’intersection de deux ensembles qui ne sont pas sous-ensembles du même sur-ensemble

[PAM-97 p56]

Y T Z

:Y

:Y

:Y

:Y

:Z

:Z:T

14/11/01 UML 02 V1-1 41



Pour que la généralisation multiple puisse être mise en œuvre, il faut que les langages de programmation « objets » supportent l’héritage multiple.Dans notre exemple, comment le compilateur peut-il garantir, lors de l’implémentation de la classe T, qu’il n’y ait pas d’effet de bord ou de conflit entre les propriétés pZ héritée de la classe Z et pY héritée de la classe Y? Par exemple, JAVA ne supporte pas l’héritage multiple.

14/11/01 UML 02 V1-1 42


Partionnement d’ensemble / Classe abstraite

• Une classe abstraite ne donne pas directement des objets. Elle sert en fait de spécification plus abstraite pour des objets instances de ses sous-classes. Le principal intérêt de cette démarche est de réduire le niveau de détails dans les descriptions des sous-classes. Le nom d’une classe abstraite est en italique dans les diagrammes de classes.

[PAM-00 p53]

Y

T

Z

:Y

:Y

:Y

:Y

:Z:Z

14/11/01 UML 02 V1-1 43


Exemple de classes abstraites

Classes abstraites

Classes concrètes

14/11/01 UML 02 V1-1 44


De la difficulté de classer

• Les classifications doivent avant tout être stables et extensibles.

• Il n’y a pas une classification, mais des classifications, chacune adaptée à un usage donné.

• Les classifications doivent comporter des niveaux d’abstraction équilibrés.

• Le critère de génération d’une classe doit être statique.

[PAM-00 p54-58]

14/11/01 UML 02 V1-1 45


Figure 2-92 – Classification dynamique

[PAM-00 p58]

14/11/01 UML 02 V1-1 46


L’héritage

L’héritage est une technique offerte par les langages de programmation pour construire une classe à partir d’une ou de plusieurs autres classes, en partageant des attributs, des opérations et parfois des contraintes au sein d’une hiérarchie de classes. Les classes enfants héritent des caractéristiques de leurs classes parents; les attributs et les opérations déclarés dans la classe parent, sont accessibles dans la classe enfant, comme s’ils avaient été déclarés localement.

[PAM-00 p57]

14/11/01 UML 02 V1-1 47


Figure 89 – Conflit de noms

[PAM-00 p60]

14/11/01 UML 02 V1-1 48


L’héritage multiple

L’héritage est entaché de contingences de réalisation et, en particulier, l’héritage n’effectue pas une union des propriétés caractéristiques des classes, mais plutôt une somme de ces propriétés. Ainsi, certaines caractéristiques peuvent être indûment dupliquées dans les sous-classes. L’héritage multiple doit donc être manié avec beaucoup de précautions car les techniques de réalisation de l’héritage peuvent induire des problèmes de collisions de noms lors de la propagation des attributs et des opérations des classes parents vers les sous-classes.

[PAM-00 p60]

14/11/01 UML 02 V1-1 49


Le principe de substitution

Le principe de substitution affirme que:

Il doit être possible de substituer n’importe quel objet instance d’une sous-classe à n’importe quel objet instance d’une super-classe sans que la sémantique du programme écrit dans les termes de la super-classe ne soit affectée.

Souvent, une contrainte est traduite par une forme de code particulière, implantée dans la réalisation d’une opération. Comme les langages objet permettent la redéfinition des opérations dans les sous-classes, les programmeurs peuvent involontairement introduire des incohérences entre la spécification d’une super-classe et la réalisation dans une de ses sous-classes. Ces incohérences concernent les contraintes exprimées de manière programmée et non déclarative.

[PAM-00 p61]

14/11/01 UML 02 V1-1 50


Le polymorphisme

Le terme polymorphisme décrit la caractéristique d’un élément qui peut prendre plusieurs formes, comme l’eau qui se trouve à l’état solide, liquide ou gazeux. En informatique, le polymorphisme désigne un concept de la théorie des types, selon lequel un nom d’objet peut désigner des instances de classes différentes issues d’une même arborescence.

[PAM-00 p62]

14/11/01 UML 02 V1-1 51


Figure 2-102 / Exercice 4 - 1

[PAM-00 p63]

14/11/01 UML 02 V1-1 52


Exercice 4 - 2 Classe abstraite

Définition d’une classe abstraite

14/11/01 UML 02 V1-1 53

hegHaute école de gestionde Neuchâtel Exercice 4 - 3 Opération abstraite

Définition d’une opération abstraite

14/11/01 UML 02 V1-1 54


Figure 2-103 / Exercice 4 - 4

14/11/01 UML 02 V1-1 55


Sélection d’une opération

14/11/01 UML 02 V1-1 56


Java – Classe Gardien

public class Gardien {

public static void main (String arg[]){

// Crée la liste des animaux du zoo

Zoo leZoo = new Zoo();

// Ordre de dormir à tous les animaux

leZoo.dormir();

}

}

14/11/01 UML 02 V1-1 57


Java – Classe Zoo (1) Création de collection

public class Zoo {// Liste des animaux du zooprivate static Vector animaux = new Vector();// Constructeur de la classe Zoopublic Zoo (){ // Instantiation des animaux Lion unLion = new Lion("Prince"); Tigre unTigre = new Tigre("Share Khan"); Ours unOurs = new Ours("Petit Jean");

// ajout de chaque animal dans la liste animaux.addElement(unLion);animaux.addElement(unTigre);animaux.addElement(unOurs);

}

14/11/01 UML 02 V1-1 58


Java – Classe Zoo (2) Parcours de collection

public void dormir() { // Interface de parcours de liste Enumeration parcoursAnimaux = animaux.elements();

// un animal de la liste - variable polymorphe Animal unAnimal;// tant qu'il y a des animaux dans la listewhile (parcoursAnimaux.hasMoreElements()) { // récupération de chaque animal de la liste unAnimal = (Animal) parcoursAnimaux.nextElement();

// ordre de se présenter et de dormir à l'animalunAnimal.tonNom();unAnimal.dormir();}

}

14/11/01 UML 02 V1-1 59


Java - Exécution de la méthode dormir()

Le message tonNom() se traduit par l’affichage de la sous-classe d’Animal et du nom de l’animal sollicité. Le message dormir() affiche pour l’animal le résultat de la méthode polymorphe dormir() réalisée dans l’une des sous-classes: Tigre, Lion ou Ours.

14/11/01 UML 02 V1-1 60


Java – Classe Animal Méthode abstraite

abstract class Animal {private String nom;// constructeur de la classe Animalprotected Animal (String nom) { this.nom = nom;}// implémentation de la méthode tonNom()protected void tonNom() { System.out.print(getClass().getName() + " : " + nom + " ");}// déclaration de la méthode abstraite dormir()abstract protected void dormir();

}

14/11/01 UML 02 V1-1 61


Java – Classe Lion Réalisation de méthode

public class Lion extends Animal {

// Constructeur de la classe Lion

public Lion (String nom){

super(nom);

}

// réalisation de la méthode dormir()

public void dormir() {

System.out.println ("dort sur le ventre");

}

}

14/11/01 UML 02 V1-1 62


Exploitation du principe de substitution

Pour que le polymorphisme fonctionne effectivement, il faut –au delà de la syntaxe seule– que le principe de substitution soit vérifié.

[PAM-00 p66]

14/11/01 UML 02 V1-1 63


Déclenchement des opérations (1)

[PAM-00 p67]

14/11/01 UML 02 V1-1 64


Déclenchement des opérations (2)

14/11/01 UML 02 V1-1 65


Influence du typage – La surcharge

• Le polymorphisme est résolu sous forme de liaisons dynamiques à l’exécution.

• La surcharge est un moyen d’offrir la notion de signature variable, elle est résolue statiquement par le compilateur.

[PAM-00 p70]

14/11/01 UML 02 V1-1 66


Héritage / Délégation

[PAM-00 p70] La délégation offre un mécanisme aussi puissant que celui offert par la généralisation.

– L’héritage est une construction rigide mais la propagation des attributs et opérations vers les sous-classes est automatique.

– La délégation est une construction plus souple basée sur l’agrégation mais la propagation des propriétés doit être réalisée manuellement.

[PAM-00 p70]

14/11/01 UML 02 V1-1 67


Exercice 5 - 1

A notre sens:Les sous-classes doivent être dotées d’opérations (méthodes en POO) qui leur permettent d’écouter les berceuses et histoires; ce ne sont pas les bébés qui se chantent des berceuses pour s’endormir!

[PAM-00 p73]

14/11/01 UML 02 V1-1 68


Exercice 5-2

14/11/01 UML 02 V1-1 69


Exercice 5 - 3

[PAM-00 p73]

Toute personne est dotée d’une capacité de sommeil

Une occurrence de sommeil appartient à une et une seule personne

L’agrégation permet de mettre en évidence que la classe Personne est plus importante que la classe Sommeil

14/11/01 UML 02 V1-1 70


Délégation / Interface

[PAM-97 p66] L’héritage n’est pas une nécessité absolue et peut toujours être remplacé par la délégation.[KETT-98] Le concept d’interface a été introduit dans UML pour modéliser des techniques de description de composants qu’on trouve sur le marché. Une interface est la déclaration d’une collection d’opérations qui peuvent être utilisées pour définir un service. Une interface spécifie des opérations visibles d’une classe, d’un composant ou d’un paquetage sans en définir la structure interne. Elle ne spécifie souvent qu’une partie limitée du comportement d’une classe. Les interfaces n’ont ni implémentation, ni attributs, ni états, ni associations. Elles peuvent cependant disposer de relations de généralisation.

[PAM-00 p70]

14/11/01 UML 02 V1-1 71


Interface

• [BRJ-00] Une interface est un ensemble d’opérations qui définissent la fonction d’une classe ou d’un composant. Par conséquent, une interface définit le comportement apparent de cet élément. Elle peut représenter totalement ou partiellement le comportement d’une classe ou d’un composant et définit les spécifications des opérations (c’est-à-dire leur signature), mais jamais leur implémentation.

14/11/01 UML 02 V1-1 72


Exemple de mécanisme de délégation

[PAM-97 p67]

14/11/01 UML 02 V1-1 73


Stéréotype Interface

14/11/01 UML 02 V1-1 74


Exercice 6 – 1 Interface

[JLS-98 p84] … Une classe fille ne peut hériter que d’une seule classe: Java n’admet que l’héritage simple, à la différence d’autres langages, comme C++ qui autorisent l’héritage multiple.

Les concepteurs du langage Java ont fait ce choix pour éviter la complexité de gestion de l’héritage multiple qui, dans certains cas, peut amener une classe à hériter plusieurs fois d’une même superclasse.

Comme Smalltalk, Java n’admet que l’héritage simple. Cependant , pour répondre à certaines situations, Java admet une forme d’héritage multiple avec des classes très particulières, que l’on appelle des interfaces.

14/11/01 UML 02 V1-1 75


Exercice 6 – 2

14/11/01 UML 02 V1-1 76


Exercice 6 – 3 Réalisation

[BRJ-00 p169] Comme une classe, une interface peut participer à des relations de généralisation, d’association ou de dépendance, mais elle peut également être impliquée dans des relations de réalisation. La réalisation est une relation sémantique entre deux classificateurs, selon laquelle un des classificateurs décrit un contrat dont l’exécution est garantie par l’autre.

14/11/01 UML 02 V1-1 77


Exercice 6 – 4

14/11/01 UML 02 V1-1 78


Exercice 6 – 5

14/11/01 UML 02 V1-1 79


Code Java - Interface

public interface Representable {

abstract String tonNom();

abstract String infosCompletes();

}

14/11/01 UML 02 V1-1 80


Code Java - Classe

public class Employe {

private String nom;

private String prenom;

public Employe (String nom, String prenom) {

this.nom = nom;

this.prenom = prenom;

}

// Pour l'interface Representable...

public String tonNom() { return prenom + " " + nom;}

}

14/11/01 UML 02 V1-1 81


Code Java - Héritage

class Capitale extends Ville {

private String pays;

public Capitale (String nomVille, int nbHabitants, String nomPays) {

super(nomVille, nbHabitants);

pays = nomPays;

}


public String infosCompletes() {

return super.infosCompletes() + "/" + pays + "/";}

}

14/11/01 UML 02 V1-1 82


Code Java – Réalisation d’une interface

class Ville implements Representable{ private String nom; private int nbHabitants; public Ville(String nom, int nbHabitants) { this.nom = nom; this.nbHabitants = nbHabitants; } // Pour l'interface Representable... public String tonNom() { return nom;} public String infosCompletes() { return "/" + nom + "/"

+ nbHabitants + "/";}}

14/11/01 UML 02 V1-1 83


Code Java – Héritage multiple

class Chauffeur extends Employe implements Representable{

private char permis;

public Chauffeur (String nom, String prenom, char permis) {

super(nom, prenom);

this.permis = permis;

}


public String infosCompletes() {return tonNom() + " / " + permis;}

}

14/11/01 UML 02 V1-1 84


Code Java – Envois de messages à une interface

public class Affiche {public Affiche(Representable unRepr) {

System.out.println("Classe : " + unRepr.getClass());

System.out.println("tonNom() : " + unRepr.tonNom());

System.out.println("infosCompletes(): " + unRepr.infosCompletes());

}}

14/11/01 UML 02 V1-1 85


Code Java – Programme de test

public class Test{ public static void main(String arg[]){

// Création des objets

Ville vGeneve = new Ville ("GENEVE", 161500); Capitale cBerne = new Capitale ("BERNE", 136300,

"Suisse");Chauffeur cTarpin = new Chauffeur("Tarpin", "Jean", 'A');

// Affichage des objets par la classe Affiche qui// invoque les méthodes spécifiées par l’interface Representable

new Affiche(vGeneve); new Affiche(cBerne); new Affiche(cTarpin); }}

14/11/01 UML 02 V1-1 86


Code Java – Exécution du test

14/11/01 UML 02 V1-1 87


Diagrammes d’objets et de classes

En pratique, les diagrammes d’objets et les diagrammes de classes se construisent en parallèle, par de nombreux allers et retours entre les deux représentations. Il n’y a aucune raison de définir les classes avant les objets. Il est vrai que chaque objet est instance d’une classe, mais la détermination de la classe peut bien être postérieure à celle des objets. Le monde réel qui nous entoure contient des objets et non des classes: il semble donc naturel de trouver d’abord les objets puis d’en extraire les classes.

[PAM-00 p75]

14/11/01 UML 02 V1-1 88


Exemple de correspondance entre classes et objets

14/11/01 UML 02 V1-1 89


Les patterns et les applications semi-finies

Des micro-architectures, appelées patterns, et des architectures semi-finies, appelées frameworks, permettent d’élever la granularité de modélisation.

[PAM-00 p77]

Classes & objets

Micro-architectures

Patterns

Applications semi-finies

Frameworks

Granularité

Assemblage d’objets

Assemblage de patternset/ou d’objets

14/11/01 UML 02 V1-1 90


Les patterns

Un pattern est une solution récurrente qui décrit et résout un problème général dans un contexte particulier.

Les principaux intérêts:– proposition d’une ou plusieurs solutions…– définition d’un ensemble de classes ou d’objets

collaborants d’un niveau de granularité supérieur…– documentation, solution d’un problème identifié…– définition d’un vocabulaire…

[PAM-00 p77]

14/11/01 UML 02 V1-1 91


Exemple de pattern

14/11/01 UML 02 V1-1 92


Les frameworks

Les frameworks définissent des ossatures pour des familles d’applications, ce qui implique une architecture générique souvent volumineuse et complexe. Ils se basent sur un assemblage de classes et d’objets, mais à une échelle plus grande que celle des patterns. Chaque framework est une architecture semi-finie dictant l’architecture générale de l’application ou du sous-système à construire.

[PAM-00 p83]

14/11/01 UML 02 V1-1 93


Exemple de framework

14/11/01 UML 02 V1-1 94


Dynamique de l’exemple de framework

heg haute école de gestion de neuchâtel 14/11/01uml 02 v1-11 les classes le monde réel est...

Documents