Heg Haute école de gestion de Neuchâtel 14/11/01UML 02 V1-11 Les classes Le monde réel est constitué de très nombreux objets en interaction. Ces objets.

Présentation au sujet: "Heg Haute école de gestion de Neuchâtel 14/11/01UML 02 V1-11 Les classes Le monde réel est constitué de très nombreux objets en interaction. Ces objets."— Transcription de la présentation:

1 heg Haute école de gestion de Neuchâtel 14/11/01UML 02 V1-11 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 lentoure, 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]

2 heg Haute école de gestion de Neuchâtel 14/11/01UML 02 V1-12 La démarche dabstraction [PAM-00 p33] Cycle dabstraction Représentation Global Détail

3 heg Haute école de gestion de Neuchâtel 14/11/01UML 02 V1-13 Classe & objets La classe décrit le domaine de définition dun ensemble dobjets. 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]

4 heg Haute école de gestion de Neuchâtel 14/11/01UML 02 V1-14 Représentation graphique des classes Nom de classe Attributs Opérations()

5 heg Haute école de gestion de Neuchâtel 14/11/01UML 02 V1-15 Exemple de classe

6 heg Haute école de gestion de Neuchâtel 14/11/01UML 02 V1-16 Contrat Une classe passe un contrat avec dautres classes; elle sengage à fournir les services publiés dans sa spécification et les autres classes sengagent à 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 dabstraction. Les traits remarquables sont décrits dans les spécifications alors que les détails sont confinés dans les réalisations. Loccultation des détails de réalisation est appelée encapsulation. [PAM-00 p38]

7 heg Haute école de gestion de Neuchâtel 14/11/01UML 02 V1-17 Compartiments supplémentaires Nom de classe Attributs Opérations Responsabilités Exceptions Messages Contrat

8 heg Haute école de gestion de Neuchâtel 14/11/01UML 02 V1-18 Encapsulation Interfaces Implémentation [PAM-00 p39]

9 heg Haute école de gestion de Neuchâtel 14/11/01UML 02 V1-19 Exemple dencapsulation Propriété privée Opérations publiques Interface

10 heg Haute école de gestion de Neuchâtel 14/11/01UML 02 V1-110 Règles de visibilité Par défaut, les valeurs dattributs dun objet sont encapsulés dans lobjet 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. Lintérêt de briser lencapsulation est par exemple de réduire le temps daccès aux attributs… [PAM-97 p39]

11 heg Haute école de gestion de Neuchâtel 14/11/01UML 02 V1-111 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

12 heg Haute école de gestion de Neuchâtel 14/11/01UML 02 V1-112 Visibilité [BRJ-00 p132] La visibilité est lun des détails les plus importants que lon puisse spécifier pour les attributs et les opérations dun classificateur (ou en simplifiant: dune classe). La visibilité dune caractéristique détermine si dautres classes peuvent lutiliser. En UML, on utilise 3 niveaux de visibilité. 1. public 2. protected 3. private

13 heg Haute école de gestion de Neuchâtel 14/11/01UML 02 V1-113 Critères dencapsulation Les critères dencapsulation reposent sur la forte cohérence interne à lintérieur dune 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 dinformations.

14 heg Haute école de gestion de Neuchâtel 14/11/01UML 02 V1-114 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]

15 heg Haute école de gestion de Neuchâtel 14/11/01UML 02 V1-115 Lassociation Lassociation 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]

16 heg Haute école de gestion de Neuchâtel 14/11/01UML 02 V1-116 Liens entre objets et association entre classes

17 heg Haute école de gestion de Neuchâtel 14/11/01UML 02 V1-117 Rôles Il est possible de préciser le rôle dune classe au sein dune association: un nom de rôle peut être spécifié de part et dautre de lassociation. [PAM-00 p42]

18 heg Haute école de gestion de Neuchâtel 14/11/01UML 02 V1-118 Visualisation des rôles

19 heg Haute école de gestion de Neuchâtel 14/11/01UML 02 V1-119 Multiplicité Les rôles portent également une information de multiplicité qui précise le nombre dinstances qui participent à la relation [PAM-00 p42] 1 ou 1..1Un et un seul 0..1Zéro ou un M..NDe M à N (entiers naturels) * ou 0..*De zéro à plusieurs 1..*De un à plusieurs

20 heg Haute école de gestion de Neuchâtel 14/11/01UML 02 V1-120 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 quelle soit enseignante ou étudiante est obligatoirement immatriculée par une école. Une personne nest employée par une école que si elle est enseignante; de plus, elle ne peut enseigner que dans une et une seule école.

21 heg Haute école de gestion de Neuchâtel 14/11/01UML 02 V1-121 Lecture des rôles et cardinalités Une école « Emploie » Une personne « Enseigne » dans 0..1 école

22 heg Haute école de gestion de Neuchâtel 14/11/01UML 02 V1-122 Lagré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, lassociation représente un couplage faible, les classes associées restant relativement indépendantes lune de lautre. Lagrégation est une forme particulière dassociation qui exprime un couplage plus fort entre classes. Une des classes joue un rôle plus important que lautre dans la relation. Lagrégation permet de représenter des relations de type maître et esclaves, tout et parties ou composés et composants. [PAM-00 p43]

23 heg Haute école de gestion de Neuchâtel 14/11/01UML 02 V1-123 La composition La composition est une forme dagrégation avec un couplage plus important. Ce couplage de composition indique que les composants ne sont pas partageables et que la destruction de lagré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]

24 heg Haute école de gestion de Neuchâtel 14/11/01UML 02 V1-124 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, cest-à-dire copie du ou des « enfant(s) » dans le contexte du « parent » –By value

25 heg Haute école de gestion de Neuchâtel 14/11/01UML 02 V1-125 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 dune voiture. Physiquement impossible! Un composant ne peut être partie de plus dun composite. Une galerie ne peut être installée, simultanément, sur plus dune voiture. [PAM-00 p45]

26 heg Haute école de gestion de Neuchâtel 14/11/01UML 02 V1-126 Cardinalité des compositions (Composite) 0..1 1 0..* Une voiture nest pas obligatoirement équipée dune galerie. La galerie peut être assimilée à un attribut optionnel. Toute voiture est équipée dune galerie. La galerie peut être assimilée à un attribut obligatoire. Une voiture peut être équipée de plusieurs galeries. [PAM-00 p45]

27 heg Haute école de gestion de Neuchâtel 14/11/01UML 02 V1-127 Exemple dagrégat et composition/ Exercice 2

28 heg Haute école de gestion de Neuchâtel 14/11/01UML 02 V1-128 Agrégation réflexive [PAM-00 p43]

29 heg Haute école de gestion de Neuchâtel 14/11/01UML 02 V1-129 Les hiérarchies de classes Les hiérarchies de classes ou classifications permettent de gérer la complexité en ordonnant les objets au sein darborescences de classes dabstraction croissante. –[KETT-98] La généralisation: il sagit 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 sagit de sélectionner des classes existantes (déjà identifiées) et den dériver de nouvelles classes plus spécialisées, en spécifiant simplement les différences. [PAM-00 p47]

30 heg Haute école de gestion de Neuchâtel 14/11/01UML 02 V1-130 Généralisation La généralisation consiste à factoriser les éléments communs dun 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é dabstraction. La mise au point dune 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]

31 heg Haute école de gestion de Neuchâtel 14/11/01UML 02 V1-131 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

32 heg Haute école de gestion de Neuchâtel 14/11/01UML 02 V1-132 Figure 2-68 - Spécialisation Exemple dextension par spécialisation [PAM-00 p48] Extension par spécialisation

33 heg Haute école de gestion de Neuchâtel 14/11/01UML 02 V1-133 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 nest pas instantiable en liens et, de fait, ne porte aucune indication de multiplicité. Généralisation Spécialisation [PAM-00 p49]

34 heg Haute école de gestion de Neuchâtel 14/11/01UML 02 V1-134 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 delle-même. La généralisation est une relation non symétrique: si une classe B dérive dune 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 dune classe B qui dérive elle-même dune classe A, alors C dérive également de A. [PAM-00 p49]

35 heg Haute école de gestion de Neuchâtel 14/11/01UML 02 V1-135 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 dinclusion des ensembles. De ce fait, les objets instances dune 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]

36 heg Haute école de gestion de Neuchâtel 14/11/01UML 02 V1-136 Figure 70 – Exercice 3 -1 [PAM-97 p55]

37 heg Haute école de gestion de Neuchâtel 14/11/01UML 02 V1-137 Exercice 3 – 2 / Héritage des opérations

38 heg Haute école de gestion de Neuchâtel 14/11/01UML 02 V1-138 Exercice 3 – 3 / Héritage des attributs

39 heg Haute école de gestion de Neuchâtel 14/11/01UML 02 V1-139 Généralisation multiple (1) La généralisation - sous sa forme dite multiple – existe également entre arbres de classes disjoints. [PAM-00 p52]

40 heg Haute école de gestion de Neuchâtel 14/11/01UML 02 V1-140 Généralisation multiple (2) Dans le monde des ensembles la généralisation multiple correspond à lintersection de deux ensembles qui ne sont pas sous-ensembles du même sur-ensemble [PAM-97 p56] Y TZ :Y :Z :T

41 heg Haute école de gestion de Neuchâtel 14/11/01UML 02 V1-141 Généralisation multiple (3) Pour que la généralisation multiple puisse être mise en œuvre, il faut que les langages de programmation « objets » supportent lhéritage multiple. Dans notre exemple, comment le compilateur peut-il garantir, lors de limplémentation de la classe T, quil ny ait pas deffet 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 lhéritage multiple.

42 heg Haute école de gestion de Neuchâtel 14/11/01UML 02 V1-142 Partionnement densemble / 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 dune classe abstraite est en italique dans les diagrammes de classes. [PAM-00 p53] Y T Z :Y :Z

43 heg Haute école de gestion de Neuchâtel 14/11/01UML 02 V1-143 Exemple de classes abstraites Classes abstraites Classes concrètes

44 heg Haute école de gestion de Neuchâtel 14/11/01UML 02 V1-144 De la difficulté de classer Les classifications doivent avant tout être stables et extensibles. Il ny a pas une classification, mais des classifications, chacune adaptée à un usage donné. Les classifications doivent comporter des niveaux dabstraction équilibrés. Le critère de génération dune classe doit être statique. [PAM-00 p54-58]

45 heg Haute école de gestion de Neuchâtel 14/11/01UML 02 V1-145 Figure 2-92 – Classification dynamique [PAM-00 p58]

46 heg Haute école de gestion de Neuchâtel 14/11/01UML 02 V1-146 Lhéritage Lhéritage est une technique offerte par les langages de programmation pour construire une classe à partir dune ou de plusieurs autres classes, en partageant des attributs, des opérations et parfois des contraintes au sein dune 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 sils avaient été déclarés localement. [PAM-00 p57]

47 heg Haute école de gestion de Neuchâtel 14/11/01UML 02 V1-147 Figure 89 – Conflit de noms [PAM-00 p60]

48 heg Haute école de gestion de Neuchâtel 14/11/01UML 02 V1-148 Lhéritage multiple Lhéritage est entaché de contingences de réalisation et, en particulier, lhéritage neffectue 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. Lhéritage multiple doit donc être manié avec beaucoup de précautions car les techniques de réalisation de lhé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]

49 heg Haute école de gestion de Neuchâtel 14/11/01UML 02 V1-149 Le principe de substitution Le principe de substitution affirme que: Il doit être possible de substituer nimporte quel objet instance dune sous-classe à nimporte quel objet instance dune 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 dune 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 dune 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]

50 heg Haute école de gestion de Neuchâtel 14/11/01UML 02 V1-150 Le polymorphisme Le terme polymorphisme décrit la caractéristique dun élément qui peut prendre plusieurs formes, comme leau 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 dobjet peut désigner des instances de classes différentes issues dune même arborescence. [PAM-00 p62]

51 heg Haute école de gestion de Neuchâtel 14/11/01UML 02 V1-151 Figure 2-102 / Exercice 4 - 1 [PAM-00 p63]

52 heg Haute école de gestion de Neuchâtel 14/11/01UML 02 V1-152 Exercice 4 - 2 Classe abstraite Définition dune classe abstraite

53 heg Haute école de gestion de Neuchâtel 14/11/01UML 02 V1-153 Exercice 4 - 3 Opération abstraite Définition dune opération abstraite

54 heg Haute école de gestion de Neuchâtel 14/11/01UML 02 V1-154 Figure 2-103 / Exercice 4 - 4

55 heg Haute école de gestion de Neuchâtel 14/11/01UML 02 V1-155 Sélection dune opération

56 heg Haute école de gestion de Neuchâtel 14/11/01UML 02 V1-156 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(); }

57 heg Haute école de gestion de Neuchâtel 14/11/01UML 02 V1-157 Java – Classe Zoo (1) Création de collection public class Zoo { // Liste des animaux du zoo private static Vector animaux = new Vector(); // Constructeur de la classe Zoo public 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); }

58 heg Haute école de gestion de Neuchâtel 14/11/01UML 02 V1-158 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 liste while (parcoursAnimaux.hasMoreElements()) { // récupération de chaque animal de la liste unAnimal = (Animal) parcoursAnimaux.nextElement(); // ordre de se présenter et de dormir à l'animal unAnimal.tonNom(); unAnimal.dormir(); }

59 heg Haute école de gestion de Neuchâtel 14/11/01UML 02 V1-159 Java - Exécution de la méthode dormir() Le message tonNom() se traduit par laffichage de la sous-classe dAnimal et du nom de lanimal sollicité. Le message dormir() affiche pour lanimal le résultat de la méthode polymorphe dormir() réalisée dans lune des sous-classes: Tigre, Lion ou Ours.

60 heg Haute école de gestion de Neuchâtel 14/11/01UML 02 V1-160 Java – Classe Animal Méthode abstraite abstract class Animal { private String nom; // constructeur de la classe Animal protected 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(); }

61 heg Haute école de gestion de Neuchâtel 14/11/01UML 02 V1-161 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"); }

62 heg Haute école de gestion de Neuchâtel 14/11/01UML 02 V1-162 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]

63 heg Haute école de gestion de Neuchâtel 14/11/01UML 02 V1-163 Déclenchement des opérations (1) [PAM-00 p67]

64 heg Haute école de gestion de Neuchâtel 14/11/01UML 02 V1-164 Déclenchement des opérations (2)

65 heg Haute école de gestion de Neuchâtel 14/11/01UML 02 V1-165 Influence du typage – La surcharge Le polymorphisme est résolu sous forme de liaisons dynamiques à lexécution. La surcharge est un moyen doffrir la notion de signature variable, elle est résolue statiquement par le compilateur. [PAM-00 p70]

66 heg Haute école de gestion de Neuchâtel 14/11/01UML 02 V1-166 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. –Lhé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 lagrégation mais la propagation des propriétés doit être réalisée manuellement. [PAM-00 p70]

67 heg Haute école de gestion de Neuchâtel 14/11/01UML 02 V1-167 Exercice 5 - 1 A notre sens: Les sous-classes doivent être dotées dopé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 sendormir! [PAM-00 p73]

68 heg Haute école de gestion de Neuchâtel 14/11/01UML 02 V1-168 Exercice 5-2

69 heg Haute école de gestion de Neuchâtel 14/11/01UML 02 V1-169 Exercice 5 - 3 [PAM-00 p73] Toute personne est dotée dune capacité de sommeil Une occurrence de sommeil appartient à une et une seule personne Lagrégation permet de mettre en évidence que la classe Personne est plus importante que la classe Sommeil

70 heg Haute école de gestion de Neuchâtel 14/11/01UML 02 V1-170 Délégation / Interface [PAM-97 p66] Lhéritage nest pas une nécessité absolue et peut toujours être remplacé par la délégation. [KETT-98] Le concept dinterface a été introduit dans UML pour modéliser des techniques de description de composants quon trouve sur le marché. Une interface est la déclaration dune collection dopérations qui peuvent être utilisées pour définir un service. Une interface spécifie des opérations visibles dune classe, dun composant ou dun paquetage sans en définir la structure interne. Elle ne spécifie souvent quune partie limitée du comportement dune classe. Les interfaces nont ni implémentation, ni attributs, ni états, ni associations. Elles peuvent cependant disposer de relations de généralisation. [PAM-00 p70]

71 heg Haute école de gestion de Neuchâtel 14/11/01UML 02 V1-171 Interface [BRJ-00] Une interface est un ensemble dopérations qui définissent la fonction dune classe ou dun composant. Par conséquent, une interface définit le comportement apparent de cet élément. Elle peut représenter totalement ou partiellement le comportement dune classe ou dun composant et définit les spécifications des opérations (cest-à-dire leur signature), mais jamais leur implémentation.

72 heg Haute école de gestion de Neuchâtel 14/11/01UML 02 V1-172 Exemple de mécanisme de délégation [PAM-97 p67]

73 heg Haute école de gestion de Neuchâtel 14/11/01UML 02 V1-173 Stéréotype Interface

74 heg Haute école de gestion de Neuchâtel 14/11/01UML 02 V1-174 Exercice 6 – 1 Interface [JLS-98 p84] … Une classe fille ne peut hériter que dune seule classe: Java nadmet que lhéritage simple, à la différence dautres langages, comme C++ qui autorisent lhéritage multiple. Les concepteurs du langage Java ont fait ce choix pour éviter la complexité de gestion de lhéritage multiple qui, dans certains cas, peut amener une classe à hériter plusieurs fois dune même superclasse. Comme Smalltalk, Java nadmet que lhéritage simple. Cependant, pour répondre à certaines situations, Java admet une forme dhéritage multiple avec des classes très particulières, que lon appelle des interfaces.

75 heg Haute école de gestion de Neuchâtel 14/11/01UML 02 V1-175 Exercice 6 – 2

76 heg Haute école de gestion de Neuchâtel 14/11/01UML 02 V1-176 Exercice 6 – 3 Réalisation [BRJ-00 p169] Comme une classe, une interface peut participer à des relations de généralisation, dassociation 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 lexécution est garantie par lautre.

77 heg Haute école de gestion de Neuchâtel 14/11/01UML 02 V1-177 Exercice 6 – 4

78 heg Haute école de gestion de Neuchâtel 14/11/01UML 02 V1-178 Exercice 6 – 5

79 heg Haute école de gestion de Neuchâtel 14/11/01UML 02 V1-179 Code Java - Interface public interface Representable { abstract String tonNom(); abstract String infosCompletes(); }

80 heg Haute école de gestion de Neuchâtel 14/11/01UML 02 V1-180 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;} }

81 heg Haute école de gestion de Neuchâtel 14/11/01UML 02 V1-181 Code Java - Héritage class Capitale extends Ville { private String pays; public Capitale (String nomVille, int nbHabitants, String nomPays) { super(nomVille, nbHabitants); pays = nomPays; } // Pour l'interface Representable... public String infosCompletes() { return super.infosCompletes() + "/" + pays + "/";} }

82 heg Haute école de gestion de Neuchâtel 14/11/01UML 02 V1-182 Code Java – Réalisation dune 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 + "/";} }

83 heg Haute école de gestion de Neuchâtel 14/11/01UML 02 V1-183 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; } // Pour l'interface Representable... public String infosCompletes() {return tonNom() + " / " + permis;} }

84 heg Haute école de gestion de Neuchâtel 14/11/01UML 02 V1-184 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()); }

85 heg Haute école de gestion de Neuchâtel 14/11/01UML 02 V1-185 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 linterface Representable new Affiche(vGeneve); new Affiche(cBerne); new Affiche(cTarpin); }

86 heg Haute école de gestion de Neuchâtel 14/11/01UML 02 V1-186 Code Java – Exécution du test

87 heg Haute école de gestion de Neuchâtel 14/11/01UML 02 V1-187 Diagrammes dobjets et de classes En pratique, les diagrammes dobjets et les diagrammes de classes se construisent en parallèle, par de nombreux allers et retours entre les deux représentations. Il ny a aucune raison de définir les classes avant les objets. Il est vrai que chaque objet est instance dune 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 dabord les objets puis den extraire les classes. [PAM-00 p75]

88 heg Haute école de gestion de Neuchâtel 14/11/01UML 02 V1-188 Exemple de correspondance entre classes et objets

89 heg Haute école de gestion de Neuchâtel 14/11/01UML 02 V1-189 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 dobjets Assemblage de patterns et/ou dobjets

90 heg Haute école de gestion de Neuchâtel 14/11/01UML 02 V1-190 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 dune ou plusieurs solutions… –définition dun ensemble de classes ou dobjets collaborants dun niveau de granularité supérieur… – documentation, solution dun problème identifié… –définition dun vocabulaire… [PAM-00 p77]

91 heg Haute école de gestion de Neuchâtel 14/11/01UML 02 V1-191 Exemple de pattern

92 heg Haute école de gestion de Neuchâtel 14/11/01UML 02 V1-192 Les frameworks Les frameworks définissent des ossatures pour des familles dapplications, ce qui implique une architecture générique souvent volumineuse et complexe. Ils se basent sur un assemblage de classes et dobjets, mais à une échelle plus grande que celle des patterns. Chaque framework est une architecture semi-finie dictant larchitecture générale de lapplication ou du sous-système à construire. [PAM-00 p83]

93 heg Haute école de gestion de Neuchâtel 14/11/01UML 02 V1-193 Exemple de framework

94 heg Haute école de gestion de Neuchâtel 14/11/01UML 02 V1-194 Dynamique de lexemple de framework