Rattrapage uml

Click here to load reader

  • date post

    15-Aug-2015
  • Category

    Documents

  • view

    39
  • download

    1

Embed Size (px)

Transcript of Rattrapage uml

  1. 1. 1 1 Pr. Jean-Marc Jzquel IRISA - Univ. Rennes I Campus de Beaulieu F-35042 Rennes Cedex Tel : +33 299 847 192 Fax : +33 299 842 532 e-mail : [email protected] http://www.irisa.fr/prive/jezequel Mise Niveau UML (Unified Modeling Language) 2 LElectricien et lInformaticien Un problme, des besoins Un composant virtuel (des entres des sorties) Des portes AND, OR, NOR, Un schma lectrique Le composant lectrique Le programme informatique UML 3 PlanIntroduction Du code aux modles Pourquoi UML ? Lhistorique Etat actuel UML pour lutilisateur Dans la pratique : modlisation selon 4 points de vue principaux : Vision utilisateur du systme Cas dutilisation Base Avance Aspects statiques du systme Description des donnes et de leurs relations Base Avance OCL Structuration en paquetages Aspects dynamiques du systme (comportemental) Vision implantation Quoi de neuf pour UML 2.x Conclusion 4 PlanIntroduction Du code aux modles Pourquoi UML ? Lhistorique Etat actuel UML pour lutilisateur Dans la pratique : modlisation selon 4 points de vue principaux : Vision utilisateur du systme Aspects statiques du systme Aspects dynamiques du systme (comportemental) Diagramme de squences (scnarios) Diagramme de collaborations (entre objets) Diagramme dtats-transitions (Harel) Diagramme dactivits Vision implantation Diagramme de composants et de dploiement Quoi de neuf pour UML 2.x Conclusion 5 1 - Introduction Lingnierie du logiciel aujourdhui 6 Automotive industry: Volkswagen
  2. 2. 2 7 Google 300 000 serveurs rpartis dans une vingtaine de datacenters. Une phnomnale capacit de calcul qui permet Google d'assurer le fonctionnement d'un grand nombre de services Google Earth rpondre plus d'1 milliard de requtes par jour, h i 8 illi d d W b 8 Nokia 1,1 milliard de tlphones portables en circulation 100 millions de plus par an Des milliers de versions de logiciels Time-to-market ~ 3 mois 9 Des logiciels complexes... Logiciels de grande taille des millions de lignes de code des quipes nombreuses dure de vie importante des lignes de produits plateformes technologiques complexes volution continue Logiciels complexes Logiciels critiques ... 15 L'industrie logicielle aujourd'hui end users component developers architects assemblers standardization organization tool vendorsapplication testers site administrators component testers middleware providers 16 middleware providers end users component developers architects assemblers standardization organization tool vendorsapplication testers site administrators component testers De nombreux acteurs des proccupations diffrentes des mtiers diffrents des comptences varies des outils varis diffrents lments logiciels Sparation des proccupations L'industrie logicielle aujourd'hui 17 Point de vue des locataires Point de vue des plombiers Point de vue des lectriciens Point de vue des architectes Point de vue des paysagistes Point de vue du cadastre Point de vue des assureurs Point de vue des pompiers Point de vue des notaires Point de vue des promoteurs Sparations des proccupations systme
  3. 3. 3 18 Point de vue du propritaire Point de vue du plombier Point de vue de l' lectricien Point de vue du maon Point de vue de l' architecte Point de vue du cadastre systme Utile mme pour des systmes "moins" complexes Sparations des proccupations 19 Problmatique Complexit croissante des logiciels Sparations des proccupations Sparations des mtiers Multiplicit des besoins Multiplicit des plateformes volution permanente Logiciel = Code ? Est-ce la solution ? 20 Multiples modles d'un mme systme modles pour les architectes modles pour les notaires modles pour les pompiers systme modles pour le cadastre modles pour l'assureur cadastre modles pour les paysagistes modles pour les lectriciens modles pour les plombiers modles pour les promoteurs 21 Ingnierie Dirige par le Code ou Ingnierie Dirige par les Modles ? Telle est la question... 22 MDO Ce cours montre comment partir de la notation UML il est possible de dfinir un certain nombre de modles plus ou moins abstraits plus ou moins labors mais dcrivant tous une facette complmentaire du systme raliser selon un point de vue ou un mtier diffrent. Laccent est mis sur les rgles de cohrence intra et inter-modles, ainsi que sur la diffrence qui peut tre fait entre modles conceptuels, de spcification et dimplmentation modles mtiers et modles techniques modles produits et modles de processus. 23 En attente En attente du code En vrification En attente du montant carte insre code frappmauvais code En distribution code bon En attente retrait carte carte retire montant correct montant incorrect billets retirs le compte de P.le distrib. la banquepaul retirer 500 fr dbiter 500 fr la carte de P. lire n compte la reserve retirer 500 fr sur le compte n sortir 5 billets de 100 fr prendre la carte confirmer Client 1..4 0..* titulaires Consortium Compte numro solde ... 1..* 0..1 1 Banque numro nom Distributeur 0..* 1 0..* 1..* signataire1 0..* CarteBleue Code retraitMax 1..* AcceptPar> le compte de paul le distributeur la banque la carte de P. la reserve paul 4 : dbiter(500)1 : retirer 500 fr 2 : lire n de compte 5 : confirmer 6 : sortir 5 billet de 100 fr 3 : retirer 500 fr sur compte n le compte de paulle compte de paul le distributeur la banque la carte de P. la reserve paul 4 : dbiter(500)1 : retirer 500 fr 2 : lire n de compte 5 : confirmer 6 : sortir 5 billet de 100 fr 3 : retirer 500 fr sur compte n ClientClient Assurer LaMaintenance Assurer LaMaintenance TechnicienTechnicien Ajouter DesBillets Ajouter DesBillets Transporteur DeBillets DistributeurDeBilletDistributeurDeBillet FaireUnVirementFaireUnVirement RetirerDeLArgentRetirerDeLArgent ConsulterSonCompteConsulterSonCompte systme
  4. 4. 4 34 Synthse Des Modles plutt que du Code Un modle est la simplification/abstraction dun aspect de la ralit Nous construisons donc des modles afin de mieux comprendre les systmes que nous dveloppons Nous modlisons des systmes complexes parce que nous somme incapables de les comprendre dans leur totalit Le code ne permet pas de simplifier/abstraire la ralit 35 2 - Pourquoi UML ? 37 Des Mthodes de modlisation Lapparition du paradigme objet permis la naissance de plusieurs mthodes de modlisation OMT, OOSE, Booch, Fusion, Chacune de ces mthodes fournie une notation graphique et des rgles pour laborer les modles Certaines mthodes sont outilles 38 Trop de Mthodes Entre 89 et 94 : le nombre de mthodes orientes objet est pass de 10 plus de 50 Toutes les mthodes avaient pourtant dnormes points communs (objets, mthode, paramtres, ) Au milieu des annes 90, G. Booch, I. Jacobson et J. Rumbaugh ont chacun commenc adopter les ides des autres. Les 3 auteurs ont souhait crer un langage de modlisation unifi 39 Gnalogie de UML OOA (P. Coad) OMT (J. Rumbaugh et al.) Data-Flow SADT/SA-SD (De Marco) OOA - OODLE (Schlaer & Mellor) Diagrammes Etat-Transition (HAREL) FUSION (HP-Labs) UML (Rumbaugh, Booch, Jacobson) Use-Case (I.Jacobson) Entite-Relation Merise (Chen) OOA-OOD (G.Booch) CLASSE- RELATION (P. Desfray) CRC (R. Wirf-Brooks) JSD (M. Jackson) 40 Historique Autres mthodes Booch91 OMT-1 OOSE Partenaires Booch93 OMT-2 Mthode unifie 0.8 UML 0.9 UML 1.0 UML 1.1 UML 1.2 UML 1.x UML 2.0 1999-2002 Juin 1998 Novembre 1997 Septembre 1997 Janvier 1997 Juin 1996 Octobre 1995 Dfinition en cours par une commission de rvision Soumission lOMG Standardisation par lOMG Soumission lOMG Soumission lOMG Version bta OOPSLA96 OOPSLA95
  5. 5. 5 41 Aujourdhui UML est le langage de modlisation orient objet le plus connu et le plus utilis au monde UML sapplique plusieurs domaines OO, RT, Deployment, Requirement, UML nest pas une mthode RUP Peut dutilisateurs connaissent le standard, ils ont une vision outille dUML (Vision Utilisateur) 5% forte comprhension, 45% faible comprhension, 50% aucune comprhension UML est fortement critiqu car pas assez formel Le march UML est important et saccrot MDA et MDD, UML2.1, IBM a rachet Rational !!! 42 3 UML pour lutilisateur 43 UML Pourquoi Rflchir Dfinir la structure gros grain Documenter Guider le dveloppement Dvelopper, Tester, Auditer 44 La conscration des mthodes fondes sur la modlisation Lapproche par modlisation facilite Communication (et sa prcision) avec donneur dordre entre diffrentes phases de dveloppement et de maintenance Capacit de vrification Cohrence Compltude Continuit entre les diffrentes phases du cycle de vie cf. Jackson et JSD N.B.: continuit isomorphique ou plongement/projection 45 Un peu de Mthodologie... Une mthode de dveloppement de logiciels, cest : Une notation La syntaxe --- graphique dans le cas de UML Un mta-modle La smantique --- paramtrable dans UML (strotypes) Un processus Dtails dpendants du domaine dactivit : Informatique de gestion Systmes ractifs temps-rels Shrink-wrap software (PC) 46 Processus de dveloppement avec UML Approche itrative, incrmentale, dirige par les cas dutilisation Expression des besoins Analyse Elaboration d un modle idal Conception passage du modle idal au monde rel Ralisation et Validation
  6. 6. 6 47 Modlisation UML Modlisation selon 4 points de vue principaux : Vision utilisateur du systme Cas dutilisation Aspects statiques du systme Description des donnes et de leurs relations Structuration en paquetages Aspects dynamiques du systme (comportemental) Diagramme de squences (scnarios) Diagramme de collaborations (entre objets) Diagramme dtats-transitions (Harel) Diagramme dactivits Vision implantation Diagramme de composants et de dploiement 48 Modlisation UML Modlisation selon 4 points de vue principaux : Vision utilisateur du systme Cas dutilisation Aspects statiques du systme Description des donnes et de leurs relations OCL Structuration en paquetages Aspects dynamiques du systme (comportemental) Diagramme de squences (scnarios) Diagramme de collaborations (entre objets) Diagramme dtats-transitions (Harel) Diagramme dactivits Vision implantation Diagramme de composants et de dploiement 49 Use case Concepts de base 50 Sujet longtemps nglig (e.g. OMT) Question de l'expression des besoins pourtant fondamentale Et souvent pas si facile (cible mouvante) cf. syndrome de la balanoire Object-Oriented Software Engineering (Ivar Jacobson et al.) Principal apport : la technique des acteurs et des cas d'utilisation Cette technique est intgre a UML Expression des besoins et OOAD 51 Se comprendre Reprsenter le systme Exprimer le service rendu Dcrire la manire dont le systme est peru Quatre objectifs 52 Modle des cas d utilisation Buts : modliser le point de vue des utilisateurs dfinir les limites prcises du systme Notation trs simple, comprhensible par tous, y compris le client Permet de structurer : les besoins (cahier des charges) le reste du dveloppement Modle communicationnel CasU1 CasU4 CasU5 CasU2 CasU3 A1 A2 S A3
  7. 7. 7 53 Modle des cas d utilisation Moyens : Les acteurs UML Les use-cases UML Utilisation dun dictionnaire du domaine 56 Exemple de cas dutilisation DistributeurDeBillet Banque Centrale Client RetirerDeLArgentAu Distributeur ConsulterSonCompte Assurer LaMaintenance TechnicienAjouter DesBillets Transporteur DeBillets RetirerLes CartesAvales 57 Diagramme de cas d utilisation DistributeurDeBillets Client RetirerDeLArgentAu Distributeur ConsulterSonCompte Assurer LaMaintenance TechnicienAjouter DesBillets Transporteur DeBillets RetirerLes CartesAvales 58 Systme bancaire Diagramme de cas d utilisation RetirerDeLArgentAu Distributeur ConsulterUnCompte DeposerDeLArgent SurUnCompte RetirerDeLArgent DUnCompte Client Guichetier Directeur GererLesPrets CrerUnCompte 59 Modle de cas d utilisation SystmeDeContrleDAcces Capteur AIncendie PorteurDeCarte Entrer DbloquerLesPortes GrerLesCartes Administrateur ListerLes TentativesDeFraudes Gardien Sortir 60 Modle des cas dutilisation Diagramme de cas dutilisation CasU1 CasU4 CasU5 CasU2 CasU3 A1 A2 S A3 Modle de cas dutilisation descriptions textuelles, diagrammes de cas d'utilisation diagrammes de squences Dictionnaire de donnes ...
  8. 8. 8 61 Modle "communicationnel" Modle informel centr utilisateur Avant tout sous forme textuelle Diagramme utilis pour les runion de "brainstorming" pour simplifier la communication pour structurer les documents pour structurer le dveloppement Diagramme = plan du document 62 Langage peu formalis Modle de cas d'utilisation peu standardis par UML Diffrents styles Diffrentes interprtations Modle construit par raffinements successifs et consensus grandissant Peu de formalisme, beaucoup de bon sens et de communication 63 Elements de base Acteurs Cas d'utilisation Systme 64 Cas dutilisation (CU) Cas dutilisation (CU) une manire dutiliser le systme une suite dinteractions entre un acteur et le systme CasDUtilisationX RetirerDeLArgentAu Distributeur Entrer TaperSonCodeEnregistrerEntre EntrerPendant LesHeuresDOuverture Regroupe un ensemble de scnarii correspondant un mme but Correspond une fonction du systme visible par lacteur Permet un acteur d atteindre un but Doit tre utile en soi SIdentifier 65 Le systme Le systme est modlis par un ensemble de cas dutilisation vu comme une bote noire Le systme contient : les cas d utilisation, mais pas les acteurs. Un modle de cas d utilisation permet de dfinir : les fonctions essentielles du systme, les limites du systme, le systme par rapport son environnement, dlimiter le cadre du projet ! SystmeX DistributeurDeBillets SystemeDeControleDAcces SystemeDeScuritIncendie 66 Acteurs Un Acteur = lment externe qui interagit avec le systme (prend des dcisions, des initiatives. Il est "actif".) rle quun "utilisateur" joue par rapport au systme Client Capteur AIncendie PorteurDeCarte AdministrateurGardien
  9. 9. 9 67 Acteurs vs. utilisateurs Ne pas confondre la notion d'Acteur et de personne utilisant le systme Une mme personne peut jouer plusieurs rles ex: Maurice est directeur mais peut jouer le rle de guichetier Plusieurs personnes peuvent jouer un mme rle ex: Paul et Pierre sont deux clients Un rle par rapport au systme plutt que position dans l'organisation ex: PorteurDeCarte plutt qu'Enseignant Un acteur nest pas forcment un tre humain ex: un distributeur de billet peut tre vu comme un acteur Client 68 Diffrents notations possibles Notations alternatives pour les acteurs PorteurDeCarte PorteurDeCarte PorteurDeCarte PorteurDeCarte CapteurAIncendie SystmeBancaire Note de style : utiliser plutot le strotype pour les acteurs non humains 69 Diffrents types d acteurs Liste pour ne pas oublier d'acteurs : Utilisateurs principaux ex: client, guichetier Utilisateurs secondaires ex: contrleur, directeur, ingnieur systme, administrateur... Priphriques externes ex: un capteur, une horloge externe, ... Systmes externes ex: systme bancaires Client 74 Description prliminaire des cas dutilisation Pour chaque cas d utilisation choisir un identificateur reprsentatif notes de style : choisir une forme verbale dcrivant une action l'acteur est gnralement le sujet identification concise mais prcise viter les connecteurs (et, ou, puis, ...) terme provenant autant que possible du mtier utiliser par exemple le style MajMin terme gnrique comme "Grer" en cas de besoin Grer = Crer, Supprimer, Ajouter, Modifier, ... Exemple: GrerLesDroits CasDUtilisationX 75 Description prliminaire des cas dutilisation Pour chaque cas d utilisation choisir un identificateur reprsentatif donner une description textuelle simple la fonction ralise doit tre comprise de tous prciser ce que fait le systme, ce que fait lacteur pas trop de dtails, se concentrer sur le scnario "normal" CasDUtilisationX Retirer DeLArgent AuDistributeur Lorsquun client a besoin de liquide il peut en utilisant un distributeur retirer de largent de son compte. Pour cela : - le client insre sa carte bancaire dans le distributeur - le systme demande le code pour l identifier - le client choisit le montant du retrait - le systme vrifie qu il y a suffisamment d argent - si c est le cas, le systme distribue les billets et dbite le compte du client - le client prend les billets et retire sa carte 76 Attention "A common sign of a novice (or academic) use case modeler is a preoccupation with use case diagrams and use case relationships, rather than writing text. ... Use case diagrams and use case relationships are secondary in use case work. Use cases are text documents. Doing use case work means to write text." [Applying UML and Patterns, Craig Larman]
  10. 10. 10 77 Relations entre lments de base Relations acteurs cas d'utilisation ? Relations acteurs acteurs ? Relations cas d'utilisation cas d'utilisation ? ? ? ? 78 Relation acteur - cas d'utilisation Client RetirerDeLArgent AuDistributeur Point de vue besoin: Rprsente la possibilit d'atteindre un but Point de vue systme: Reprsente un canal de communication Echange de messages, potentiellement dans les deux sens Protocole particulier concernant le cas d'utilisation considr Client RetirerDeLArgent AuDistributeur 79 Relation cas d'utilisation - cas d'utilisation Systme Bancaire Directeur Client RetierDeLArgent ConsulterLesSoldes Communications internes non modlises. UML se concentre sur la description du systme et de ses interactions avec l'extrieur Formalisme bien trop pauvre pour dcrire l'intrieur du systme. Utiliser les autres modles UML pour cela. Autres relations possibles entre CU (slides suivants) 80 Relations sur les use-cases Utilisation (include / uses ) Utilisation dautres use-cases pour en prciser la dfinition Extension (extend / extends ) Un use-case tendu est une spcialisation du use-case pre 81 Relations sur les use-cases : notation Commander Commander chantillon extend Organiser paiement Lire donnes client Slectionner produit include include include 82 Exprimer le service rendu Besoins fondamentaux : manires d'utiliser le systme Reprsentation globale par cas d'utilisation taille du systme, seulement de 3 10 Use Cases Besoins oprationnels : interactions avec le systme Reprsentation dtaille par raffinement des cas d'utilisation Dbut de dcomposition fonctionnelle : ne pas aller trop loin
  11. 11. 11 83 Besoins fondamentaux et oprationnels Besoin fondamental : Conduire une voiture Besoins oprationnels Ouvrir la porte Mettre le contact Acclrer Tourner le volant ... conduire une voiture {fondamental} conduire une voiture {fondamental} ouvrir la porte {oprationnel} mettre le contact {oprationnel} acclrer {oprationnel} tourner le volant {oprationnel} includes includes includes includes 84 Relation de communication acteur-acteur Systme Bancaire Guichetier Client RetirerDeLArgent AuDistributeur ConsulterSonCompte RetirerDeLArgent ParChque Communications externes non modlise UML se concentre sur la description du systme et de ses interactions avec l'extrieur 85 Relation acteur - acteur : gnralisation Guichetier EnChef Guichetier CrerUnCompte RetirerDeLArgent DUnCompte AnnulerUnCompte FermerUnCompte La seule relation entre acteurs est la relation de gnralisation Guichetier EnChef Guichetier CrerUnCompte RetirerDeLArgent DUnCompte AnnulerUnCompte FermerUnCompte 86 Retour sur la relation de communication Client RetirerDeLArgent AuDistributeur Association acteur/CU vu comme un canal de communication Dcrit le comportement du systme vu de l'extrieur Echange de messages Client RetirerDeLArgent AuDistributeur 87 Description de l'interaction Client RetirerDeLArgent AuDistributeur Plus tard dans le cours ... Description via des diagrammes de squences "systmes" 88 Limites du systme interface de communication acteur humain interface homme systme acteur logiciel interface logicielle (e.g. API) Limites du systme et interfaces DistributeurDeBillets Client RetirerDeLArgentAu Distributeur ConsulterSonCompte Technicien RetirerLes CartesAvales SystmeBancaire
  12. 12. 12 89 DistributeurDeBillets Client RetirerDeLArgentAu Distributeur ConsulterSonCompte Technicien RetirerLes CartesAvales SystmeBancaire Description (par la suite) dans les documents de spcification externes Interface homme- systme Interface systme- systme 90 Modle prliminaire de cas d utilisation Equivalent dfinir une table des matires Permet davoir une vision globale du systme Quelques transparents Dcorer le diagramme pour prciser des priorits : MUST, SHOULD, MAY pour prciser des risques pour prciser des critres qualits : utilisabilit pour 91 Exemple de diagramme de CU dcor RetirerDeLArgentAu Distributeur ConsulterUnCompte DeposerDeLArgent SurUnCompte RetirerDeLArgent DUnCompte Client Guichetier Directeur GererLesPrets CrerUnCompte Systme bancaire { MUST } { MUST } { MUST } { MAY } { SHOULD } { SHOULD } { 12/03/02 } { 12/05/02 } { 20/03/02 } { 25/12/02 } { 10/12/02 } { 10/10/02 } 92 Le Processus Unifi (1) Dfinir le modle de cas dutilisation (1.1) Trouver les acteurs (1.2) Dcrire brivement chaque acteur (1.3) Trouver les cas d utilisation (1.4) Dcrire brivement chaque cas d utilisation (1.5) Dcrire le modle comme un tout (2) Dfinir des priorits et les risques entre CU 127 Conclusion 128 ATTENTION "Congratulations: Use Cases Have Been Written, and Are Imperfect" [Applying UML and Patterns, Craig Larman]
  13. 13. 13 129 Modle prliminaire des cas d utilisation quivalent dfinir une table des matires et des rsums pour chaque chapitre Pas de rgles strictes Effectuer les meilleurs regroupement possibles Rester simple ! Structuration possible en termes de paquetages Culture d'entreprise Stabilisation du modle par consensus grandissant 130 Pour en savoir un plus... Chapitre gratuit tlchargeable http://www.craiglarman.com/book_applying_2nd/Applying_2nd.htm http://alistair.cockburn.us/usecases/uctempla.htm Pour un template "standard" de description de cas d'utilisation 131 Pour en savoir encore plus ... Des livres spcialiss 134 Modlisation UML Modlisation selon 4 points de vue principaux : Vision utilisateur du systme Cas dutilisation Aspects statiques du systme Description des donnes et de leurs relations OCL Structuration en paquetages Aspects dynamiques du systme (comportemental) Diagramme de squences (scnarios) Diagramme de collaborations (entre objets) Diagramme dtats-transitions (Harel) Diagramme dactivits Vision implantation Diagramme de composants et de dploiement 135 Classes et Objets Concepts de base 137 Compte Notation pour les classes numro : entier solde : rel dcouvertMax : entier consulterSolde() : entier crditer( somme : entier) dbiter( somme : entier) Nom de la classe Attributs nom type Oprations nom paramtre type du rsultat Contraintes{ inv: solde > dcouvertMax }
  14. 14. 14 138 Notations simplifies pour les classes Compte numro solde : rel dcouvertMax : entier consulterSolde() : entier crditer( somme : entier) dbiter( somme ) Compte numro solde ... crditer() dbiter() ... Compte numro solde ... Compte crditer() dbiter() ... Compte Note de style : les noms de classes commencent par une majuscule les noms d attributs et de mthodes commencent par une minuscule Compte M1 139 Notations pour les objets leCompteDePaul : Compte numro = 6688 solde = 5000 dcouvertMax = -100 leCompteDePaul : Compte leCompteDePaul : Compte Convention : les noms d objets commencent par une minuscule et sont souligns M0 140 Classe vs. Objets Compte numro solde : rel dcouvertMax : entier consulterSolde() : entier crditer( somme : entier) dbiter( somme ) Une classe spcifie la structure et le comportement d'un ensemble d'objets de mme nature Diagramme de classesLa structure d'une classe est constante leCompteDePaul : Compte numro = 6688 solde = 5000 dcouvertMax = -100 leCompteDeMarie:Compte numro = 2275 solde = 10000 dcouvertMax = -1000 :Compte numro = 1200 solde = 150 dcouvertMax = 10 Diagramme d objets Des objets peuvent tre ajouts ou dtruits pendant l excution La valeur des attributs des objets peut changer M0 M1 141 Liens (entre objets) c1 : Compte c2 : Compte paul : Client pierre : Client marie : Client c3 : Compte APourCompte APourCompte APourCompte Un lien indique une connexion entre deux objets Note de style : les noms des liens sont des formes verbales et commencent par une majuscule indique le sens de la lecture (ex: paul APourCompte c1 ) 142 Contrainte sur les liens Au maximum un lien d'un type donn entre deux objets donns* marie : Personnejoseph : Personne APourEpouse APourEpouse 143 Au maximum un lien d'un type donn entre deux objets donns* marie : Personnejoseph : Personne APourEpouse APourEpouse Contrainte importante pour compendre les "classes associatives" (*) Contrainte pouvant tre relache via {nonunique} en UML 2.0 ... voir plus loin les concepts avancs jos : Personne EstEnfantDe madeleine : Personne EstEnfantDe EstGardePar OK Contrainte sur les liens
  15. 15. 15 144 Rles c1 : Comptepierre : Client APourCompte titulaire compte Chacun des deux objets joue un rle diffrent dans le lien Note de style : choisir un groupe nominal pour dsigner un rle si un nom de rle est omis, le nom de la classe fait office de nom 145 pierre : Client 3 noms pour 1 concept c1 : Compte APourCompte titulaire comptea b R utilisations diffrentes selon le contexte fg pierre a pour compte c1 c1 joue le role de compte pour pierre pierre joue le role de titulaire pour c1 a R b b "joue le role de" f "pour" a a "joue le role de" g "pour" b 146 Associations (entre classes) c1 : Compte c2 : Compte paul : Client pierre : Client marie : Client c3 : Compte APourCompte> APourCompte> APourCompte> Client Compte APourCompte Une association dcrit un ensemble de liens de mme "smantique" comptetitulaire Diagramme d objets (exemplaires) Diagramme de classes (modlisation) M0 M1 147 Association vs. Liens Un lien lie deux objets Une association lie deux classes Un lien est une instance dassociation Une association dcrit un ensemble de liens Des liens peuvent tre ajouts ou dtruits pendant l excution, (ce n est pas le cas des associations) Le terme "relation" ne fait pas partie du vocabulaire UML c1 :Compte c2 :Compte paul :Client pierre :Client marie :Client c3 :Compte APourCompte> APourCompte> APourCompte> Client Compte APourCompte> liens association classe objets M1 M0 149 Utiliser les rles pour naviguer Client Compte APourCompte titulaire comptes = {c1} = {c2,c3} = { } = paul = pierre = pierre Nommer en priorit les rles c1 : Compte c2 : Compte paul : Client pierre : Client marie : Client c3 : Compte APourCompte> APourCompte> APourCompte> titulaire titulaire comptes comptes comptes titulaire paul.comptes pierre.comptes marie.comptes c1.titulaire c2.titulaire c3.titulaire M0 M1 150 Cardinalits dune association Prcise combien dobjets peuvent tre lis un seul objet source Cardinalit minimale et cardinalit maximale ( Cmin..Cmax) Doivent tre des constantes Client Compte 1 APourCompte 0..* titulaire comptes Tout client a toujours 0 ou plusieurs comptes Tout compte a toujours 1 et 1 seul titulaire c1 : Compte c2 : Compte paul : Client pierre : Client marie : Client c3 : Compte APourCompte> APourCompte> APourCompte> M0 M1
  16. 16. 16 154 Contraintes entre associations Client Compte numro solde ... 1 0..*titulairePrincipal co-titulaires0..* 0..* /titulaires1..* 0..* (1) Un client ne peut pas tre la fois titulaire principal et co-titulaire d un mme compte. (2) Les titulaires dun compte sont le titulaire principal et les co-titulaires le cas chant Les cardinalits sont loins d'tre suffisantes pour exprimer toutes les contraintes... dcrire les contraintes en langue naturelle (ou en OCL) 155 Diagramme de classes Client 1..4 0..* titulaires Consortium Compte numro solde ... * 1 0..* 1 0..* 1..* signataire1 0..* CarteBleue Code retraitMax Distributeur 1..* EstAcceptPar> 1..* Banque numro nom 156 Diagrammes dobjets c1 : Compte c2 : Compte paul : Client pierre : Client marie : Client c3 : Compte titulaires titulaires : CarteBleue titulaires titulaires signataire : CarteBleue sophie : Client : Banque : Banque fred : Client c4 : Compte titulaires : Banque signataire : Consortium : Consortium : Distributeur : CarteBleue signataire : Distributeur EstAcceptPar> EstAcceptPar> EstAcceptPar> M0 157 Diagrammes de classes vs. dobjets Un diagramme de classes dfini lensemble de tous les tats possibles les contraintes doivent toujours tre vrifies Un diagramme dobjets dcrit un tat possible un instant t, un cas particulier doit tre conforme au modle de classes Les diagrammes dobjets peuvent tre utiliss pour expliquer un diagramme de classe (donner un exemple) valider un diagramme de classe (le "tester") Client 1..4 0 . . * titulaires Consortium Compte numro solde ... * 1 0 . . * 1 0 . . * 1 . . * signataire1 0 . . * CarteBleue Code retraitMax Distributeur 1 . . * EstAcceptPar> 1 . . * Banque numro nom c1 : Comp te c2 : Comp te paul : Client pierre : Client marie : Client c3 : Comp te t i t u l a i r e s t i t u l a i r e s : Carte Bleue t i t u l a i r e s t i t u l a i r e s s i g n a t a i r e : Carte Bleue sophi e : Client : B a n q u e : B a n q u e s i g n a t a i r e : Cons ortiu m : Distri buteu rEstA ccept Par > EstA ccept Par > c1 : Comp te c2 : Comp te paul : Client pierre : Client marie : Client c3 : Comp te t i t u l a i r e s t i t u l a i r e s : Carte Bleue t i t u l a i r e s ti tu la i re s s i g n a t a i r e : Carte Bleue sophi e : Client : B a n q u e : B a n q u e s i g n a t a i r e : Cons ortiu m : Distri buteu r EstA ccept Par > EstA ccept Par > 158 Diagrammes de classes vs. dobjets t i t u l a i r e s t i t u l a i r e s : Ban que sign atair e :Distributeur :Compte :Compte:Client :Client :Compte t i t u l a i r e s : t i t u l a i r e s : :Client : Ban que : Ban que :Client : : :Consortium :Consortium :Distributeur : : > > > ... :Compte :Compte:Client :Client :Compte t i t u l a i r e s : t i t u l a i r e s : :Client : Ban que : Ban que :Client : : :Consortium :Consortium :Distributeur : : > > > t1 t2 t3 Client 1..4 0..* titulaires Consortium Compte numro solde ... * 1 0..* 1 0..* 1..* signataire1 0..* CarteBleue Code retraitMax Distributeur 1..* EstAcceptPar> 1..* Banque numro nom :Compte :Compte :Client :Compte t i t u l a i r e s : t i t u l a i r e s : :Client : Ban que : Ban que :Client : : :Consortium :Consortium :Distributeur : : > > > M1 M0 159 Gnralisation / Spcialisation Une classe peut tre la gnralisation dune ou plusieurs autres classes. Ces classes sont alors des spcialisations de cette classe. "Super classe" "Sous classes" Personne FemmeHomme Compte Compte Epargne Cas gnral Cas spcifique Deux points de vue li (en UML) : relation d'hritage relation de sous-typage
  17. 17. 17 160 Relation d'hritage Compte solde crditer() dbiter() CompteEpargne tauxIntrt ajouterIntrts () Les sous-classes hritent des proprits des super-classes (attributs, mthodes, associations, contraintes) Banque* CompteEpargne solde tauxIntrt crditer() dbiter() calculIntrts () * {inv: solde > -5000 et tauxIntrt < 100} Banque {inv: solde > -5000} {inv: tauxIntrt < 100} 161 Relation d'hritage et redfinitions Compte solde crditer() dbiter() CompteEpargne crditer() dbiter() ajouterIntrts () PEL crditer() dbiter() ajouterIntrts () PEC dbiter() PET dbiter() Une opration peut tre "redfinie" dans les sous-classes Permet d'associer des mthodes spcifiques chaque pour raliser une mme opration 162 Relation de sous typage, Vision ensembliste tout objet dune sous-classe appartient galement la superclasse Compte Epargne ce1 Compte Compte CompteEpargne ce2 ce3 c3 c4 c4 c1 c2 M1 M0 163 Synthse des concepts de base Classe attribut mthode Association rle cardinalit o1 o2 o1 o2 o3 o4 o5 o1 o2 o3 Objet Lien Inclusion ensembliste Hritage M1 M0 164 Classes et Objets Utilisation avance 165 UML ? ... une question de style et de contexte S'adapter ... au niveau d'abstraction au domaine d'application aux outils utiliss aux savants et ignorants ingnierie vs. retro-ingnierie
  18. 18. 18 166 + # - Visibilit des lments Restreindre l'accs aux lments d'un modle Contrler et viter les dpendances entre classes et paquetages + public visible # protg visible dans la classe et ses sous-classes - priv visible dans la classe uniquement ~ package visible dans la package uniquement Utile lors de la conception et de l'implmentation, pas avant ! N'a pas de sens dans un modle conceptuel (abstrait) N'utiliser que lorsque ncessaire La smantique exacte dpend du langage de programmation ! 167 Dclaration d'attributs [/] [ visibilit ] nom [ : type ] [card ordre] [ = valeur-initiale ] [ { props... } ] exemples: age +age /age - solde : Integer = 0 # age : Integer [0..1] # numsecu : Integer {frozen} # motsCls : String [*] {addOnly} nbPersonne : Integer Adapter le niveau de dtail au niveau d'abstraction 168 Dclaration d'oprations [/] [ visibilit ] nom [ ( params ) ] [ : type ] [ { props... } ] params := [ in | out| inout ] nom [ : type] [ =defaut ] [{ props... } ] /getAge() + getAge() : Integer - updateAge( in date : Date ) : Boolean # getName() : String [0..1] +getAge() : Integer {isQuery} +addProject() : { concurrency = sequential } +addProject() : { concurrency = concurrent } +main( in args : String [*] {ordered} ) Adapter le niveau de dtail au niveau d'abstraction 169 Attributs drivs Attributs dont la valeur peut tre dduite d autres lments du modle e.g. ge si l on connat la date de naissance notation : /age En termes danalyse, indique seulement une contrainte entre valeurs et non une indication de ce qui doit tre calcul et ce qui doit tre mmoris 170 Reprsentation des invariants Des contraintes peuvent tre ajoutes aux lments du modle UML notation entre { } Invariants = Proprits vraies pour l'ensemble des instances de la classe dans un tat stable, chaque instance doit vrifier les invariants de sa classe exprims l aide d OCL Object Constraint Language e.g. {solde >= plancher} Compte {solde>=plancher} solde: Somme plancher: Somme crditer (Somme) dbiter (Somme) 171 Reprsentation des pr/post conditions Prconditions {precondition expression boolenne OCL} Abrg en: {pre: expression boolenne OCL} Postconditions {postcondition expression boolenne OCL} Abrg en: {post: expression boolenne OCL} Operateur valeur prcdente (idem old Eiffel): expression OCL @pre
  19. 19. 19 172 Etre abstrait et prcis avec UML Compte {solde>=plancher} solde: Somme plancher: Somme crditer (montant : Somme) {pre: montant > 0} {post: solde = solde @pre + montant} dbiter (s: Somme) {pre: montant > 0 and montant