2 Vue générale du cours ) Introduction au langage de modélisation UML points de vue et diagrammes cas d'utilisation, analyse, conception, implémentation 2) Le diagramme des cas d utilisations acteur cas d'utilisation et scénario 3) Notion de classes et objets et leur diagramme introduction aux classes, aux objets notion de relation, de composition et d'héritage recherche d'un diagramme de classes à partir du cahier des charges 4) Modèle dynamique diagramme de séquences, de collaboration, d'état et d'activité réalisation des cas d'utilisation par les diagrammes de séquences réalisation des cas d'utilisation par les diagrammes de collaboration 5) Conception diagramme de déploiement et de composants 6) Le langage de contrainte OCL
3 ) Introduction au langage de modélisation UML Unified Modeling language OMT-2 James Rumbaugh Booch 93 Grady Booch OOSE Ivar Jacobson 4 Proposé à un standard OMG fin997 OOPSLA 95 WWW Juin96 UML 0.8 Partenaires Divers UML.0 Standard OMG, ADTF fin997 UML. Task Force UML 0.9 UML.2 998 200 2003 2005 UML.3 UML.4 UML.5 UML 2.0 2
Pourquoi modéliser 5 ƒ Un modèle est une simplification de la réalité qui permet de mieux comprendre le système à développer. ƒ Il permet - De visualiser le système comme il est ou comme il devrait l'être. - De valider le modèle vis à vis des clients - De spécifier les structures de données et le comportement du système. - De fournir un guide pour la construction du système. - De documenter le système et les décisions prises. Les principes de la modélisation 6 ) Le modèle doit être connecté au monde réel 2) Un modèle peut être exprimé avec différents niveaux de précision 3) Un simple modèle n'est pas suffisant, il y a plusieurs façons de voir un système. ƒ plan de masse ƒ vue de face, de coté, ƒ plan des niveaux ƒ plan électrique ƒ plan de plomberie ƒ plan des calculs de construction 3
Qu apporte la modélisation objet 7 ƒ Plus grande indépendance du modèle par rapport aux fonctionnalités demandées. ƒ Des fonctionnalités peuvent être rajoutées ou modifiées, le modèle objet ne change pas. ƒ Plus proche du monde réel. 8 Les objectifs d UML Représenter des systèmes entiers Etablir un couplage explicite entre les concepts et les artefacts exécutables Prendre en compte les facteurs d échelle Créer un langage de modélisation utilisable à la fois par les humains et les machines Recherche d un langage commun : ƒ Utilisable par toutes les méthodes ƒ Adapté à toutes les phases du développement ƒ Compatible avec toutes les techniques de réalisation 4
UML un langage 9 ƒ UML n est pas une méthode ƒ UML est un langage de modélisation objet ƒ UML a été adopté par toutes les méthodes objet ƒ UML est dans le domaine public, c est une norme UML un langage pour 0 ƒ visualiser ƒ chaque symbole graphique a une sémantique ƒ spécifier ƒ de manière précise et complète, sans ambiguïté, ƒ construire ƒ les classes, les relations SQL peuvent être générées automatiquement ƒ documenter ƒ les différents diagrammes, notes, contraintes, exigences seront présentés dans un document. 5
UML et les domaines d utilisation ƒ Systèmes d'information des entreprises ƒ Les Banques et les services financiers ƒ Télécommunications ƒ Transport ƒ Défense et aérospatiale ƒ Scientifique ƒ Applications distribuées par le WEB Les trois éléments de base en UML ) les blocs de base pour construire ƒ les entités utilisées ƒ la notion de relation les diagrammes ƒ 2) les règles à observer pour utiliser ces blocs de base ƒ règles sémantiques règles de présentation ƒ 3) les mécanismes communs ƒ spécification ƒ présentation ƒ extension des modèles Entités structurelles Entités de comportement Entités de regroupement Entité d'annotation 2 6
3 Les entités structurelles Chien race age couleur Comparable Interface observateur Collaboration emprunte Cas d utilisation aboyer() mordre () obéir () Classe Producteur Noyau Serveur suspend() run() Nœud Classe Active Composant Les entités de comportement 4 appel Message emprunté Etat Les entités de groupement Accès BD Paquetage Le livre a été emprunté Note Les entités de notation 7
Les relations 5 dépendance association héritage réalisation 6 Stéréotypes et icônes associées <<contrôle>> Gestion Commande gestion Commande <<entité>> Stockage Commande stockage Commande <<frontière>> Réception Commande réception Commande 8
Les 9 diagrammes en UML 7 Diagrammes Cas d'utilisation Classes Etats- Transitions Activité Déploiement Objets Séquences Collaboration Composants Aspect statique : classes et objets paquetages 5 façons de voir un système (4+ vues de Kruchten) Aspect dynamique : d'interaction (séquences, collaboration), d'états-transitions et d'activité Aspect statique : les paquetages les méthodes les threads 8 Vue logique Vue implantation Vue des cas d'utilisation Vue des processus Vue de déploiement Aspect parallélisme : threads processus tâches interactions Aspect fonctionnel : Cas d'utilisations acteurs classes collaboration Aspect répartition : diagramme de déploiement nœuds, modules 9
Point de vue des cas d utilisation 9 ƒ Vue du système par ses utilisateurs finaux ƒ Regroupe le comportement du système selon ƒ Priorité: critique, important, accessoire ƒ Risques à circonscrire ƒ Options disponibles ƒ Couverture de l architecture ƒ Autres objectifs tactiques et contraintes Point de vue logique 20 ƒ Décomposition orientée-objet ƒ Décomposition en objets et classes ƒ Regroupement en paquetages. ƒ Connexions par héritage, association, etc. ƒ Accent sur l abstraction, l encapsulation, l uniformité. ƒ Réalisation des scénarios des cas d'utilisation. 0
Point de vue processus 2 ƒ Décomposition en tâches et processus ƒ Regroupement des groupes de processus ƒ Communication ƒ Information sur les caractéristiques suivantes ƒdisponibilité, fiabilité ƒintégrité, performance ƒcontrôle Point de vue implantation 22 ƒ Décomposition en modules et niveaux ƒ Regroupement de modules en paquetages ƒ Organisation des sous-systèmes en niveaux pour : ƒ Réduire le couplage et la visibilité ƒ Augmenter la robustesse ƒ Information sur les caractéristiques suivantes : ƒ Facilité de développement ƒ Potentiel de réutilisation ƒ Gestion de configuration
Point de vue déploiement 23 ƒ Décomposition en nœuds d exécution ƒ Rôle d un nœud ƒ Inter-connectivité, topologie ƒ Information sur les caractéristiques suivantes : ƒ Performance, disponibilité ƒ Installation, maintenance Les trois composantes d une modélisation 24 Modèle Fonctionnel Que fait le système Aspect dynamique : diagrammes d'interaction (séquences, collaboration), d'états-transitions et d'activité Séquencement des actions dans le système Modèle temporel Aspect fonctionnel : diagrammes des cas d'utilisation Modèle structurel (objet) Sur quoi le système agit Aspect statique : diagramme de classes et d'objets 2
25 Phases de la modélisation Cahier des charges Expression des besoins S accorder sur ce qui doit être fait dans le système Analyse Comprendre les besoins et les décrire dans le système Conception S accorder sur la manière dont le système doit être construit Implémentation Codage du résultat de la conception Test Le système est-il conforme au cahier des charges? Code exécutable Rôle de l'expression des besoins ƒpermettre une meilleure compréhension du système 26 ƒcomprendre et structurer les besoins du client ƒ clarifier, filtrer et organiser les besoins, ne pas chercher l exhaustivité ƒune fois identifiés et structurés, ces besoins : ƒ définissent le contour du système à modéliser (ils précisent le but à atteindre), ƒ permettent d'identifier les fonctionnalités principales (critiques) du système. 3
27 Expression des besoins ƒ Comprendre le contexte du système en définissant un modèle du domaine et du métier ƒ Recenser les besoins fonctionnels et les définir par des cas d'utilisations ƒ Noter les contraintes, exigences non fonctionnelles. Le modèle du domaine regroupe les objets qui se situent dans le contexte du système : - entités existantes ou événements qui s'y produisent. Exigences non fonctionnelles 28 ƒ Contraintes de concurrence ƒ Contraintes de temps de réponse ƒ Contraintes de distribution ƒ Contraintes de performance ƒ Contraintes de répartition 4
Dépendances entre phases de modélisation 30 spécifié par modèle cas d'utilisation vérifié par implémenté par Modèle de test Modèle d'analyse réalisé par Modèle de conception Modèle d'implémentation L analyse 3 ƒ Le but de l analyse est de traduire dans un langage proche de celui des informaticiens les modèles exprimés dans l'expression des besoins. ƒ Cependant pour rester compréhensible par les clients ou utilisateurs, il n'intervient que des entités du domaine (métier) considéré. ƒ Elle sert d'interface, avec l'expression des besoins, aux dialogues et aux contrats avec les clients et les utilisateurs. ƒ L'analyse doit servir de support pour la conception, l'implémentation et la maintenance. 5
Expression des besoins : vue orientée utilisateur 32 Cahier des charges Dialogue clients et futurs utilisateurs Cas d utilisation Système Scénarios d'utilisation Définition des fonctionnalités du système Analyse du système Système Cahier des charges 33 Cas d utilisation Diagramme de classes Propagation des événements dans le système Diagramme de collaboration ou de séquences Diagramme d'états-transitions 6
La notation graphique 34 BUT : ƒ Modéliser les objets, les relations entre objets, les interactions avec le système. ƒ Servir de support de communication entre l'analyste, le client, et les utilisateurs. Cahier des charges : gestion de bibliothèque ƒ Un gérant de bibliothèque désire automatiser la gestion des prêts. ƒ Il commande un logiciel permettant aux utilisateurs de connaître les livres présents, d'en réserver jusqu'à 2. L'adhérent peut connaître la liste des livres qu'il a empruntés ou réservés. ƒ L'adhérent possède un mot de passe qui lui est donné à son inscription. ƒ L'emprunt est toujours réalisé par les employés qui travaillent à la bibliothèque. Après avoir identifié l'emprunteur, ils savent si le prêt est possible (nombre max de prêts = 5), et s'il a la priorité (il est celui qui a réservé le livre). ƒ Ce sont les employés qui mettent en bibliothèque les livres rendus et les nouveaux livres. Il leur est possible de connaître l'ensemble des prêts réalisés dans la bibliothèque. 35 7
36 2) Le diagramme des Use Cases ou des cas d utilisation Ce que doit faire le système sans spécifier comment il le fait But des Use Cases Les cas d'utilisation représentent les fonctionnalités que le système doit savoir faire. Chaque cas d'utilisation peut être complèté par un ensemble d'interactions successives d'une entité en dehors du système (l utilisateur) avec le système lui même. Système 37 Les Uses Cases permettent : De connaître le comportement du système sans spécifier comment ce comportement sera réalisé. De définir les limites précises du système Au développeur de bien comprendre l'attente des utilisateurs et les experts du domaine. De plus les Use Cases sont : Des instruments de validation et de test du système en cours et en fin de construction. 8
Modèle des cas d'utilisations 38 ƒ Un diagramme de cas d utilisation définit : ƒ le système ƒ les acteurs ƒ les cas d'utilisations ƒ les liens entre acteurs et cas d'utilisations ƒ Un modèle de cas d'utilisation se définit par : ƒ des diagrammes de cas d utilisation ƒ une description textuelle des scénarios d'utilisation ƒ une description de ces scénarios par : ƒ les diagrammes de séquences ƒ les diagrammes de collaboration Les Acteurs 39 ƒ Un acteur représente une personne ou un périphérique qui joue un rôle (interagit) avec le système. ƒ Relation entre acteurs : généralisation (héritage) abonné bibliothécaire abonné Héritage relation entre acteurs un bibliothécaire est un abonné un administrateur est un bibliothécaire un administrateur est un abonné Acteur bibliothécaire administrateur 9
Les cas d utilisation (use-case) 40 ƒ Un cas d utilisation est un moyen de représenter les différentes possibilités d'utiliser un système. ƒ Il exprime toujours une suite d'interactions entre un acteur et l'application. ƒ Il définit une fonctionnalité utilisable par un acteur. Emprunter Réserver Regarder la liste des livres Organisation des Use Cases : include 4 ƒ La relation "include" précise qu'un cas d utilisation contient le comportement défini dans un autre cas d utilisation. ƒ Cette relation permet de mettre en commun des comportements communs à plusieurs cas d'utilisation.. Emprunt <<include>> Identification abonné Réservation <<include>> 20
Organisation des Use Cases : extend ƒ La relation "extend" précise qu'un cas d utilisation peut dans certains cas augmenter le comportement d'un autre cas d'utilisation. ƒ Une condition devra valider cette augmentation. ƒ Le point d'utilisation de cette augmentation peut être défini dans un "point d'extension". 42 Réservation Extensionpoints avant le choix du livre <<extend>> avant le choix du livre Regarder liste des livres ƒ Dans cet exemple, le cas d'utilisation "Regarder la liste des livres" augmente le cas d'utilisation d'une réservation, avant le choix du livre, si l'utilisateur en fait la demande. Organisation des Use Cases : généralisation 43 ƒ Cette relation "est un" introduit la notion d héritage. ƒ Les cas d'utilisation "Vérification par mot passe" et "Vérification par carte" sont des spécialisations du cas d'utilisation "Identification abonné". ƒ Autrement dit : si l'on dit que l'on fait une "Identification abonné", ce peut être une "Vérification par carte" ou une "Vérification par mot passe". héritage Identification abonné Vérification par mot passe Vérification par carte 2
Modélisation d un système: obtenir les cas d'utilisation ƒ Identifier les acteurs qui utilisent, qui gèrent, qui exécutent des fonctions spécifiques. ƒ Organiser les acteurs par relation d héritage. ƒ Pour chaque acteur, rechercher les cas d utilisation avec le système. En particulier, ceux qui modifient l état du système ou qui attendent une réponse du système. ƒ Ne pas oublier les variantes d interactions (cas d erreur, cas interdits). ƒ Organiser ces interactions par héritage, par utilisation et par extension. 44 Le système ƒ Le système définit l'application informatique, il ne contient donc pas les acteurs, mais les cas d'utilisation et leur associations Gestion de bibliothèque 45 Réserver un livre Connaître les livres empruntés Connaître les livres présents Ajouter de nouveaux livres Remettre un livre Réaliser un emprunt 22
46 Les diagrammes de cas d utilisation Bibliothèque Acteurs Client Réserver un livre Connaître les livres empruntés Connaître les livres présents Cas d utilisation Ajouter de nouveaux livres Employé Remettre un livre Réaliser un emprunt Les diagrammes de cas d utilisation Bibliothèque 47 Connaître les livres empruntés Client Employé Réserver un livre Extension point avant la réservation <<extends>> Connaître les livres présents Ajouter de nouveaux livres Remettre un livre Réaliser un emprunt <<include>> << include >> Identification Identification par mot de passe Identification par carte 23
Scénarios d'un cas d'utilisation 48 ƒ La description d un cas d utilisation se fait par des scénarios qui définissent la suite logique des interactions qui constituent ce cas. ƒ On peut définir des scénarios simples ou des scénarios plus détaillés faisant intervenir les variantes, les cas d'erreurs, etc. ƒ Cette description se fait de manière simple, par un texte compréhensible par les personnes du domaine de l'application. ƒ Elle précise ce que fait l'acteur et ce que fait le système ƒ La description détaillée pourra préciser les contraintes de l'acteur et celles du système. Scénarios d'un cas d'utilisation 49 Réservation d'un livre description simplifiée Le client se présente devant un terminal: () Le système affiche un message d accueil. (2) Le client choisit l opération réservation parmi les différentes opérations proposées. (3) Le système lui demande de s'authentifier. (4) Le client donne son identification (nom, mot de passe). (5) Le système lui demande de choisir un livre. (6) Le client précise le livre qu'il désire. (7) Le système lui précise si un exemplaire du livre lui est réservé. 24
Scénarios d'un cas d'utilisation 50 Réservation d'un livre description détaillée Pré-conditions: Le client doit être inscrit à la bibliothèque Le client ne doit pas avoir atteint le nombre maximum de réservation Un exemplaire du livre doit être enregistré Post-conditions: (Si l'opération s'est bien déroulée) Le client a une réservation supplémentaire Le nombre d'exemplaires disponibles du livre est décrémenté de Scénarios d'un cas d'utilisation Réservation d'un livre Cas normal description détaillée. () Le système affiche un message d accueil sur le terminal avec un choix d'opérations 2. (2) Le client choisit l opération réservation parmi les différentes opérations proposées. 3. (3) Le système lui demande de s'authentifier. 4. (4) Le client donne son identification (nom, mot de passe). 5. (5) Le système demande le titre du livre en donnant la possibilité de choisir dans une liste. 6. (6) Le client précise le livre qu'il désire. 7. (7) Le système lui précise que un exemplaire du livre lui est réservé. variante en (6) le client demande à connaître les livres présents 5 variante 2 variante 3 variante 4 en (4) le client n'est pas reconnu, dans ce cas, tant qu'il n'est pas reconnu, on lui redemande de s'authentifier en (4) le client est reconnu, mais le mot de passe est incorrect, il peut avoir 5 essais, par la suite le client sera interdit pendant heure. en (4) le client n'a plus le droit de réserver variante 5 en (7) le livre n'est pas libre 25
Scénario par diagramme de séquences ƒ Suite aux descriptions textuelles, le scénario peut être représenté en utilisant un diagramme de séquences. Le diagramme de séquences permet : ƒ de visualiser l aspect temporel des interactions ƒ de connaître le sens des interactions (acteur vers système ou contraire) 52 Client Réserver un livre Afficher message d accueil Choix de l opération réservation Demande d identification du client Identification du client Demande identification du livre Identification du livre Message «le livre est réservé» :Système de prêts temps Variation du scénario 53 Client Réserver un livre Afficher message d accueil Choix de l opération réservation Demande d identification du client Identification du client Refus trop de livres réservés :Système de prêts 26
Cas d utilisation: Distributeur de billets Distributeur de billets Effectuer un virement Cas d utilisation 54 Client Acteur client Retirer l argent Consulter un compte Gérer le distributeur Banque Acteurs gestionnaires Effectuer la Maintenance Employé Diagramme de séquences Use Case Retirer de l'argent Client Retirer l argent Afficher message d accueil Insère la carte Demande de mot de passe Entre mot de passe Demande type opération Entre demande retrait Demande somme Entre somme Distribue l'argent Demande prendre les billets Prendre les billets Imprimer le reçu Ejecter la carte Demande de prendre la carte Prendre la carte Afficher message d accueil :Distributeur de billets 55 27
56 3) Concepts objets et diagrammes de classes La classe CLASSE Personne nom age adresse mot de passe nbre livres empruntés Caractéristiques attributs données membres informations propriétés Famille d'objets ayant mêmes caractéristiques et même comportement 57 changeradresse() donnerage() donneradresse() vérifiermotdepasse() Comportement opérations méthodes fonctions procédures messages services CLASSE Personne 28
58 La classe et ses membres Personne nom : String âge : Integer adresse : String mot de passe : String nbre livres empruntés : Integer 0<= nbre livres empruntés <=5 <<constructeur>> Personne(nom:String, âge : Integer adresse:string, motdepasse:string) <<caractéristiques>> changeradresse (String) <<authentification>> vérifiermotdepasse(string) : Boolean changermotdepasse(old:string, new:string) La classe et l objet instance de un objet 59 CLASSE Personne nom age adresse mot de passe nbre livres empruntés Attributs :Personne nom = Alain Dupont age = 45 adresse = France mot de passe = 4RSA67 nbre livres empruntés = 4 changeradresse() obtenirage() obteniradresse() vérifiermotdepasse() Comportement :Personne : Personne André Roué 25 France 6FT34 0 29
Protection des attributs et des opérations : principe de l'encapsulation ƒ Peut-on accéder à tous les attributs ou à toutes les méthodes d'un objet? NON ƒla classe définit ce qui est accessible. C'est le principe de l'encapsulation. Un objet complexe ne peut être utilisé qu'au travers de ce qui est accessible. Exemple : ƒon ne peut utiliser une voiture qu'à travers son volant, son frein, son accélérateur, etc. ƒl accès au carburateur est impossible sauf par les méthodes qui le font de manière cohérente (méthode accélérer de l accélérateur). 60 Protection des attributs et des opérations : usage et notation ƒ Les attributs sont en général inaccessibles (secret). ƒ Ils sont alors qualifiés de : ƒ "protected" (notation UML : # ) ƒ ou "private" (notation UML: - ) ƒ Leur lecture ou modification n'est possible qu'au travers de certaines opérations (accesseurs : changeradresse(), obtenirage(), etc.) ƒ Les opérations sont en général accessibles (publiques) : ƒ Elles sont alors qualifiées de : ƒ "public" (notation UML: + ) ƒ Certaines opérations peuvent cependant être privées et certains attributs peuvent être publics (non souhaitable / principe d encapsulation) 6 30
Protection des attributs et des opérations : notation UML 62 CLASSE - nom - âge - adresse Personne + : attribut public # : attribut protected - : attribut private # changeradresse() # obtenirrue() + obtenirage() + : opération public # : opération protected - : opération private 63 Attributs et opérations de classe Personne - nom - age - adresse - mot de passe - nbrelivresempruntés - nbrelivresempruntables = 5 + changeradresse() + obtenirage() + obteniradresse() + vérifiermotdepasse() + getnblivresempruntables() Le nombre de livres empruntables n'est pas une caractéristique d'alain Dupont (objet). C'est une caractéristique valable pour l'ensemble des personnes (la classe). une_personne:personne nom = Alain Dupont age = 45 adresse = France mot de passe = 4RSA67 nbrelivresempruntés= 4 La méthode getnblivresempruntables() utilise la valeur nbrelivresempruntables connue par la classe. Cette méthode peut être appliquée directement à la classe Personne et bien sûr aussi aux objets instances de Personne. 3
Attributs et opérations de classe Notation UML 64 CLASSE Personne - nom - âge - adresse - nombrepersonne # changeradresse() # obtenirrue() + obtenirage() +obtenirnombrepersonne() + : attribut public # : attribut protected - : attribut private : attribut de classe + : opération public # : opération protected - : opération private : opération de classe La réification 65 Chien Mariage entité physique race age couleur événement époux épouse date aboyer() mordre () obéir () semarier () divorcer () relation Appartenir propriétaire date voiture vendre () acheter () prêter () situation Cours professeur salle élèves assister () quitter () 32
Modèle du type abstrait Pile 66 PileEntier - contenu - hauteur - taille +empiler (valeur : Integer) +dépiler () +elementsommet () : Integer +nombreelements : Integer +estvide : Boolean Surcharge et polymorphisme 67 Personne nom : String age : Integer adresse : String Fichier nom : String taille : Integer propriétaire : String changeradresse(sonadresse : String) obtenirage() : entier obteniradresse() : String imprimer() imprimer() imprimer(nombrelignes : entier) notions : polymorphisme surcharge signature 33
68 Classes paramétrables Pile Element taille : Integer +Pile() +empiler(valeur : Element) +dépiler () : Element +nombreelements() : Integer +estvide (): Boolean +estpleine() : Boolean return nombreelements() ==taille Pile <Integer,34> Pile <Point,20> <<bind>>(personne, 00) Guichet Association entre classes Nom d association Sens de lecture du nom d association 69 Livre titre apourauteur Auteur nom unlivre : Livre titre = La peste apourauteur unhomme : Auteur nom = Camus 34
70 Multiplicité, nom d association, nom de rôle Société nom adresse employeur 0.. nom de rôle emploie estemployée employé * (par défaut) (explicite) Personne nom patron patron adresse 0.. grade ouvrier * multiplicité 3 0.. *.. * 6..28 3 0 ou 0 ou plusieurs ou plusieurs intervalle dirige nom d association Lien entre objets 7 constructeur : Société nom : Peugeot adresse : Sochaux employeur emploie employé contremaître : Personne nom = Dupont 35
Lien entre objets 72 constructeur : Société Nom : Peugeot adresse : Sochaux employeur estemployée emploie e m p l o i e ledirecteur : Personne nom = Madec uncontremaître : Personne nom = Simon ouvrier patron d i r i g e uncadre : Personne nom = Dupont ouvrier 73 Classe d association Société Nom adresse 0.. emploie Emploi * Personne Nom adresse grade salaire grade salaire Classe d association 36
Qualificateurs : restriction de la cardinalité Banque gère * CompteBancaire numérocompte 74 Banque numérocompte gère CompteBancaire Répertoire gère * Fichier nom Répertoire nom gère Fichier Contraintes sur les associations 75 CompteChèque * * appartient {or} Personne Société Conférence assiste organise * {sous-ensemble} * Personne 37
Attribut dérivé 77 {Contexte Personne Inv : age = datecourante - datenaissance } Personne Nom adresse grade datenaissance /age Attribut dérivé Les associations ternaires Cours 78 Cours Enseignant Salle Elève 38
79 Agrégation C'est une association qui exprime un couplage fort lié à une relation de subordination, elle est asymétrique du type ensemble/élément. Règles permettant de choisir une agrégation : Est ce une partie de? Les opérations appliquées à l'ensemble sont elles appliquées à l'élément? Les changements d'états sont-ils liés? Polygone E-mail Mais un élément agrégé peut être lié à d'autres classes la suppression de l'ensemble n'entraîne pas celle de l'élément *.. * attaché * Polycopié 3.. * Point {ordonnés}.. * * Titre Destinataire Texte Fichier * Composition : agrégation forte La composition est une agrégation forte qui lie les cycles de vie entre le composé (ensemble) et les composants (élements). 80 Le choix entre composition et agrégation peut être laissé à la phase de conception. Document * Paragraphe * Phrase Voiture 4 Roue Carrosserie 2-5 Porte Moteur Habitacle 39
Association, agrégation ou composition?. Règles obligatoires pour l'agrégation : Est ce une partie de? Les opérations appliquées au composé sont elles appliquées au composant? Les changements d'états sont-ils liés? 8 2. Règles obligatoires pour la composition : La suppression du composé entraîne t-elle la suppression des composants? Les attributs du composé sont-ils utilisés dans les composants? Les composants sont des instances du composé? Un composant ne peut pas être en relation avec d'autres classes externes au composé. Magasin gère *??? Client Magasin Magasin gère gère * * Client Client Composition 82 Fenêtre scollbar Ascenceur contrôle Bordure 2 contenu Panel Fenêtre scollbar [2]: Ascenceur contrôle : Bordure contenu : Panel 40
Navigabilité 83 Par défaut une association est bidirectionnelle. Il est possible de réduire la portée en la rendant unidirectionnelle. En général, ce choix se fait dans la phase de conception. Agenda * Réunion alieu TrancheHoraire fin début Flèche de navigabilité : Association unidirectionnelle Date 84 Eléments sur une association ordonnancement cardinalité navigabilité rôle Polygone {ordered} 3..* Point nom d association qualificateur +contenu montre agrégation composition visibilité - support numéro Canevas Présentation {frozen} couleur texture changeable densité 4
85 3) Concepts objets et diagrammes de classes Héritage Héritage : buts et principes /3 Nouvelles classes dérivées de classes existantes 86 BUT Permettre une réutilisation optimale des classes déjà écrites, utilisées et validées ƒ réutilisation de la structure des données héritées ƒ réutilisation du code des services hérités PRINCIPE Ne pas modifier les classes déjà écrites cela modifierait l'utilisation qui en est faite. ƒ ne pas hésiter à créer des classes, extensions d'autres déjà validées 42
Héritage : adaptation 87 Hérite est un est une sorte de MoyenTransport vitesselimite désignation prixht annéeconstruction prixttc() obtenirvitesse() changerprix() obtenirage() Camion nombreessieux capacité charge estplein() Voiture nombreportes couleur Tramway nombrepassagers niveaubruit nombrepassagers() prixttc() VoitureEssence nombrebougies VoitureDiesel typeinjecteur redéfinition Héritage : buts et principes 2/3 Ajout d une classe de base (analyse) 88 BUT 2 Permettre une factorisation des caractéristiques et des comportements communs à plusieurs classes ƒ mise en commun des structure des données ƒ mise en commun du code des services PRINCIPE Lorsque plusieurs classes ont des caractéristiques et des comportements communs la création d'une classe ancêtre permet de regrouper ce qui est commun. Cette classe ancêtre peut correspondre à une classe concrète ou à une classe abstraite 43
89 Héritage : généralisation Factorisation des propriétés Permanent numérobureau spécialité nombrecours nom numérosécu Vacataire nombrevacation nombrecours spécialité nom numérosécu 90 Héritage : généralisation Factorisation des propriétés Enseignant nombrecours Spécialité nom numérosécu Permanent numérobureau Vacataire nombrevacation 44
9 Héritage : généralisation Factorisation des propriétés Avocat nombreaffaires adressecabinet nom numérosécu Vendeur ancienneté nomdustand nom numérosécu Enseignant nombrecours Spécialité nom numérosécu Permanent numérobureau Vacataire nombrevacation 92 Héritage : généralisation Factorisation des propriétés Personne nom numérosecu {disjoint,incomplete} Avocat nombreaffaires adressecabinet Vendeur ancienneté nomdustand {disjoint,complete} Enseignant nombrecours spécialité Permanent numérobureau Vacataire nombrevacation 45
Héritage multiple et répété 93 Véhicule {overlapping} Véhicule terrestre Véhicule marin Voiture Voiture amphibie Bateau Véhicule Véhicule marin Véhicule terrestre Voiture amphibie Bateau Voiture Classe abstraite Un média peut être transporté, dupliqué, affiché. Le transport et la duplication sont indépendants du type du média (copie de fichiers). Par contre, tout média peut être affiché et ce n'est pas la même chose pour l'audio, la vidéo, le graphisme, le texte. Un média ne peut pas définir comment s'afficher tant qu'il ne sait pas ce qu'il est. Notation UML : nom de classe italique ou stéréotype <<abstract>> Média auteur titre date création transporter() dupliquer() afficher() 94 Il n'y a pas d'instance de la classe média. Un média n existe qu en tant que livre, chanson, graphique ou vidéo. Livre afficher() Chanson durée afficher() Graphique largeur hauteur afficher() Vidéo durée afficher() 46