Informatique S4-POO Programmation Orient Ee Objet - ENIB

Diagramme de classes (4 UC)Relations entre classesAssociation : multiplicitésRABmultBmultAvaleurs possibles du cardinal de l’ensemble des instances associées àune instance de la classe par la relation R.multBmultAcardinal de l’ensemble des instances de la classeB qui sont en relation avec 1 instance de la classeA par la relation R.cardinal de l’ensemble des instances de la classeA qui sont en relation avec 1 instance de la classeB par la relation R.Cédric Buche (ENIB)POO20 novembre 201333 / 135

Diagramme de classes (4 UC)Relations entre classesMultiplicité : notationnotation : min . max1.10.10.*1.*n.m, pabreg.1–*––Cédric Buche (ENIB)significationexactement 1zéro ou un (optionnel)aucun ou plusieursau moins 1entre n et m ou exactement pPOO20 novembre 201334 / 135

Diagramme de classes (4 UC)Relations entre classesAssociation unidirectionnelleCédric Buche (ENIB)POO20 novembre 201335 / 135

Diagramme de classes (4 UC)Relations entre classesContraintes sur une motionelevesPersonne{subset}0.12 delegues0.1*Etablissement �dric Buche (ENIB)*POOenseignants20 novembre 201336 / 135

Diagramme de classes (4 UC)Relations entre classesTypes grégatA3CompositeCédric Buche (ENIB)élémentR3B3CompositionComposantPOO20 novembre 201337 / 135

Diagramme de classes (4 UC)Relations entre classesAgrégationAgrégation : association simple contraintes d’intégrité graphe acyclique éléments partageablesCédric Buche (ENIB)POO20 novembre 201338 / 135

Diagramme de classes (4 UC)Relations entre classesCompositionComposition : agrégation contrainte de durée de vie composants non partageablesCédric Buche (ENIB)POO20 novembre 201339 / 135

Diagramme de classes (4 UC)Relations entre classesAgregation/composition : exempleCédric Buche (ENIB)POO20 novembre 201340 / 135

Diagramme de classes (4 UC)Relations entre classesAgregation/composition : exempleCédric Buche (ENIB)POO20 novembre 201341 / 135

Diagramme de classes (4 UC)Relations entre classesPackagegrouper dans des ensembles cohérents.structurer les diagrammes et donnent une vision globale plus claire.Cédric Buche (ENIB)POO20 novembre 201342 / 135

Diagramme de classes (4 UC)Relations entre classesNavigationpkg1 b10.1#b2AABB0.1-b30.1 op1()#op2()-op3()0.1 c1ABCédric Buche (ENIB)0.1 #c2CCPOO20 novembre 201343 / 135

Diagramme de classes (4 UC)Concepts avancésClasse abstraitePropriété optionnelle d’une classeDéfinition :classe non instanciableensemble de propriétés communes à différentes classesmais partiellement définies.donc, seuls des objets d’une classe dérivée sont instanciablesDeux raisons :12bien que l’instanciation d’un tel objet serait possible cela n’auraitpas de sensex. Personne – Eleve – Profau moins une des propriétés de la classe n’est pas définieex. Shape opération drawNotation : abstract : tagged-value placée après le nom de la classeNomClass : en italiqueCédric Buche (ENIB)POO20 novembre 201344 / 135

Diagramme de classes (4 UC)Concepts avancésAttribut dérivésa valeur se calcule à partir d’autres proprietes de la classe(attributs ou autres)symbolisés par l’ajout d’unCédric Buche (ENIB)/POOdevant leur nom20 novembre 201345 / 135

Diagramme de classes (4 UC)Concepts avancésInterface interface Nom attribut1 attribut2Variables d’état devantêtre maintenues operationA lement un protocole description de servicesCédric Buche (ENIB)POO20 novembre 201346 / 135

Diagramme de classes (4 UC)Concepts avancésRelation de réalisation : entre classes et interfaces interface IBCAattr1service1service2operationACédric Buche (ENIB)service1service2realisationPOO20 novembre 201347 / 135

Diagramme de classes (4 UC)Concepts avancésInterface : ExempleCédric Buche (ENIB)POO20 novembre 201348 / 135

Diagramme de classes (4 UC)Concepts avancésRelations avec une interface interface I1 interface I2 interface I3 interface I4I1I2 interface I3CA interface I5CACB interface I6CBCC interface I7CDI4I5I6CCCDI7Cédric Buche (ENIB)POO20 novembre 201349 / 135

Diagramme de classes (4 UC)Concepts avancésInterface : exempledescription symbolique de l’interfacelien d’utilisationIlogsaisie mot de passePassword uses source de l’interfacesymbole de l’interfaceCédric Buche (ENIB)POO20 novembre 201350 / 135

Diagramme de classes (4 UC)Concepts avancésClasse–associationcas particuliers d’associationAmARrAmBBrBCClasse associationL’association entre les classes A et B est réalisée par un objet de laclasse C (sous sa responsabilité)la classe C a des propriétés qui lui sont propres(attributs, opérations.)Cédric Buche (ENIB)POO20 novembre 201351 / 135

Diagramme de classes (4 UC)Concepts avancésClasse–associationexempleCédric Buche (ENIB)POO20 novembre 201352 / 135

Diagramme de classes (4 UC)Concepts avancésAssociation qualifiéemAARvaleurClé: TypeClérAmBrBBClé : attribut de la relation R permettant de définir (qualifier) lesous-ensemble des instances de la classe B (rôle rB) associées à 1instance de la classe Ale couple (Instance de A, valeur Clé) identifie lesous-ensemble rB.Multiplicité : mB cardinal de rBExemple : annuaire inverséCédric Buche (ENIB)POO20 novembre 201353 / 135

Diagramme de classes (4 UC)Concepts avancésAssociation qualifiée : exempleRepertoireRepertoire1 . *EntrepriseEntreprise1 . *nom fichfonction*contient1 . *contientemploie*Fichiersans qualifiantCédric Buche (ENIB)1emploie1 . *Fichier1 . *Personneavec qualifiantPersonnesans qualifiantPOOavec qualifiant20 novembre 201354 / 135

Diagramme de classes (4 UC)Concepts avancésAssociation qualifiéeexempleCédric Buche (ENIB)POO20 novembre 201355 / 135

Diagramme de classes (4 UC)Concepts avancésAssociation qualifiéeexempleCédric Buche (ENIB)POO20 novembre 201356 / 135

Diagramme de classes (4 UC)ÉlaborationDémarche pour bâtir une diagramme de classes (1/2)1Trouver les classes du domaine étudiéEn collaboration avec un expert du domaine.Les classes correspondent généralement à des concepts ou dessubstantifs du domaine.2Trouver les associations entre classesLes associations correspondent souvent à des verbes, ou desconstructions verbales, mettant en relation plusieurs classes, commeest composé de , pilote , travaille pour .Attention, méfiez vous de certains attributs qui sont en réalité desrelations entre classes.Cédric Buche (ENIB)POO20 novembre 201357 / 135

Diagramme de classes (4 UC)ÉlaborationDémarche pour bâtir une diagramme de classes (2/2)3Trouver les attributs des classesLes attributs correspondent souvent à des substantifs, ou desgroupes nominaux, tels que la masse d’une voiture oule montant d’une transaction .Les adjectifs et les valeurs correspondent souvent à des valeursd’attributs.4Organiser et simplifier le modèleEn éliminant les classes redondantes et en utilisant l’héritage.5Vérifier les chemins d’accès aux classes6Itérer et raffiner le modèleUn modèle est rarement correct dès sa première construction.Cédric Buche (ENIB)POO20 novembre 201358 / 135

Diagramme de cas d’utilisation (1 UC)Plan1Introduction2Diagramme de classes (4 UC)3Diagramme de cas d’utilisation (1 UC)4Diagrammes d’interaction (2 UC)Cédric Buche (ENIB)POO20 novembre 201359 / 135

Diagramme de cas d’utilisation (1 UC)Plan1Introduction2Diagramme de classes (4 UC)3Diagramme de cas d’utilisation (1 UC)4Diagrammes d’interaction (2 UC)Cédric Buche (ENIB)POO20 novembre 201360 / 135

Diagramme de cas d’utilisation (1 UC)IntroductionExprimer les besoinsComment donner un moyen simple d’exprimer les besoinsd’utilisateurs non informaticiens ?Première étape UML d’analyse d’un systèmeCédric Buche (ENIB)POO20 novembre 201361 / 135

Diagramme de cas d’utilisation (1 UC)IntroductionExigences fonctionnellesModèle construit en phase de définition des exigences fonctionnelleset enrichi pendant la phase d’analyse en utilisant d’autres modèles(entre-autres les modèles d’interaction)Objectifs :1identifier les fonctionnalités du logiciel2en définir le périmètre3identifier les éléments externes en interaction directeCédric Buche (ENIB)POO20 novembre 201362 / 135

Diagramme de cas d’utilisation (1 UC)Éléments des diagrammesActeurDéfinition :rôle joué par une entité externe qui interagit avec le systèmeil peut consulter et/ou modifier l’état du système par messagesComment les identifier ?utilisateurs humainssystèmes connexes qui interagissent également avec le systèmeComment les représenter ?mot clef actor Acteur3symboleActeur3stick manActeur1Exemple : Client, Conseiller financier, SI Banque .Cédric Buche (ENIB)POO20 novembre 201363 / 135

Diagramme de cas d’utilisation (1 UC)Éléments des diagrammesCas d’utilisationDéfinition :Séquences d’actions réalisées par le système (résultat observablepour un acteur)Comportement attendu (6 mode de réalisation) :ce que le futur devra fairepas comment il le feraCédric Buche (ENIB)POO20 novembre 201364 / 135

Diagramme de cas d’utilisation (1 UC)Éléments des diagrammesCas d’utilisationComment les identifier ?Ensemble des cas utilisation exigences fonctionnelles du systèmeUn cas fonction métier selon le point de vue des acteursPour chaque acteur :rechercher ses utilisations métiersdéterminer dans le cahier des charges les services attendusNommez les cas d’utilisation (point de vue acteur) :verbe à l’infinitif complémentComment les représenter ?Exemple : Consulter un compte, Retirer de l’argent, Déposer un chèque.Cédric Buche (ENIB)POO20 novembre 201365 / 135

Diagramme de cas d’utilisation (1 UC)Relations entre acteurs et cas d’utilisationCas d’utilisation et acteursNom sujetNom cas utilisation 1Nom cas utilisation 2Nom acteur 2Nom acteur 1Acteur :élément externe en interaction directe avec le sujetCas d’utilisation :ensemble fonctionnel cohérent, identifiable extérieurementet fourni par un classeur (le sujet)Association Acteur – Cas :chemin de communication indiquant la participation de l’acteurà la réalisation du casCédric Buche (ENIB)POO20 novembre 201366 / 135

Diagramme de cas d’utilisation (1 UC)Relations entre acteurs et cas d’utilisationAssociation : ExempleCédric Buche (ENIB)POO20 novembre 201367 / 135

Diagramme de cas d’utilisation (1 UC)Relations entre acteurs et cas d’utilisationActeurs principaux et secondairesUn acteur est qualifié de principal pour un cas d’utilisationlorsque ce cas rend service à cet acteur.Les autres acteurs sont alors qualifiés de secondaires.Un cas d’utilisation a au plus un acteur principal.Le stéréotype primary vient orner l’association reliant un casd’utilisation à son acteur principalLe stéréotype secondaryCédric Buche (ENIB)est utilisé pour les acteurs secondairesPOO20 novembre 201368 / 135

Diagramme de cas d’utilisation (1 UC)Relations entre acteurs et cas d’utilisationActeurs principaux et secondaires : ExempleCédric Buche (ENIB)POO20 novembre 201369 / 135

Diagramme de cas d’utilisation (1 UC)Relations entre cas d’utilisationTypes et représentationCA1CB1CA1 inclut CB11 réalisation de CA1 1 réalisation de CB1CB2CA2 étend CB2dans un certain contexteSelon le contexte,on réalise soit CA2, soit CB2CB3CA3 spécialise CB3Selon le contexte,on réalise soit CA3, soit CB3 include CA2 extend CA3Cédric Buche (ENIB)POO20 novembre 201370 / 135

Diagramme de cas d’utilisation (1 UC)Relations entre cas d’utilisationExemple relation d’inclusionLe cas inclus est ajouté obligatoirement au cas de baseCédric Buche (ENIB)POO20 novembre 201371 / 135

Diagramme de cas d’utilisation (1 UC)Relations entre cas d’utilisationExemple relation d’inclusionIdentifier une partie commune aux différents cas d’utilisation et de lafactoriser dans un nouveau cas inclus dans ces derniers.Cédric Buche (ENIB)POO20 novembre 201372 / 135

Diagramme de cas d’utilisation (1 UC)Relations entre cas d’utilisationExemple relation d’extensionEnrichir un cas d’utilisation par un autre, cependant, cetenrichissement est optionnel.Cédric Buche (ENIB)POO20 novembre 201373 / 135

Diagramme de cas d’utilisation (1 UC)Relations entre cas d’utilisationExemple relation d’extensionL’extension se fait dans le cas d’utilisation de base, en un point précisappelé point d’extensionCédric Buche (ENIB)POO20 novembre 201374 / 135

Diagramme de cas d’utilisation (1 UC)Relations entre cas d’utilisationExemple relation Généralisation/SpécialisationFormaliser les variations importantes sur le même cas d’utilisationCédric Buche (ENIB)POO20 novembre 201375 / 135

Diagramme de cas d’utilisation (1 UC)Relations entre cas d’utilisationExemple completCédric Buche (ENIB)POO20 novembre 201376 / 135

Diagramme de cas d’utilisation (1 UC)Relations entre acteursGénéralisationLa seule relation possible entre deux acteurs est la généralisationun acteur A est une généralisation d’un acteur B si l’acteur A peutêtre substitué par l’acteur Btous les cas d’utilisation accessibles à A le sont aussi à B, maisl’inverse n’est pas vrai.Cédric Buche (ENIB)POO20 novembre 201377 / 135

Diagramme de cas d’utilisation (1 UC)Relations entre acteursGénéralisation : ExempleCédric Buche (ENIB)POO20 novembre 201378 / 135

Diagramme de cas d’utilisation (1 UC)Scénarios : description textuelleScénarioDéfinition :succession particulière d’enchaı̂nements s’exécutant du début à lafin du casUn cas d’utilisation contient :un scénario nominalplusieurs scénarios alternatifs (qui se terminent normalement)plusieurs scénarios d’erreur (qui se terminent par un échec)Cédric Buche (ENIB)POO20 novembre 201379 / 135

Diagramme de cas d’utilisation (1 UC)Scénarios : description textuelleEn pratique .La fiche de description textuelle d’un cas d’utilisation n’est pasnormalisée.Cependant, on peut utiliser la structuration suivante :Sommaire d’identification (obligatoire)Descriptiondesscénarios c Buche (ENIB)non(op-Inclut titre, résumé, dates decréation et de modification, version,responsable, acteurs .Décrit le scénario nominal, lesscénarios d’erreur, les pré/postconditionsAjoute, si c’est pertinent, les informations suivantes : fréquence ; disponibilté, fiabilité, confidentialité .POO20 novembre 201380 / 135

Diagramme de cas d’utilisation (1 UC)Scénarios : description textuelleExemple scénarioSommaireDescriptionScénario nominal Réserver un véhicule1. Le client saisit son code et son login d’identification2. Le système vérifie le code et le login d’identification3. Le système demande au client de saisir les informations surla réservation4. Le client saisit les informations sur la réservation5. Le système interroge l’acteur système bancaire pour vérifierl’acompte6. Le système bancaire donne une réponse favorable7. Le système envoie au client, un message de confirmation dela demandeCédric Buche (ENIB)POO20 novembre 201381 / 135

Diagramme de cas d’utilisation (1 UC)Scénarios : description textuelleExemple scénarioSommaireDescriptionScénario alternatif Réserver un véhiculeSA1 : code d’identification erroné pour la première ou ladeuxième foisSA1 démarre au point 2 du scénario nominal3. Le système indique au client que le code est erroné, pour lapremière ou la deuxième fois.Le scénario nominal reprend au point 1.Cédric Buche (ENIB)POO20 novembre 201382 / 135

Diagramme de cas d’utilisation (1 UC)Scénarios : description textuelleExemple scénarioSommaireDescriptionScénario d’erreur Réserver un véhiculeSE1 : code d’identification erroné pour la troisième foisSE1 démarre au point 2 du scénario nominal3. Le système indique au client que le code est erroné pour latroisième fois.Le cas d’utilisation se termine en échec (l’objectif n’est pas atteint).Cédric Buche (ENIB)POO20 novembre 201383 / 135

Diagramme de cas d’utilisation (1 UC)UtilisationQuand utiliser les cas d’utilisation ?En phase d’élaborationEn discutant avec les utilisateursRemarque : Un projet de 10 années-hommes devrait comprendreenviron 12 cas d’utilisation 11. Résulat issu d’une commission de l’OOPSLACédric Buche (ENIB)POO20 novembre 201384 / 135

Diagrammes d’interaction (2 UC)Plan1Introduction2Diagramme de classes (4 UC)3Diagramme de cas d’utilisation (1 UC)4Diagrammes d’interaction (2 UC)Cédric Buche (ENIB)POO20 novembre 201385 / 135

Diagrammes d’interaction (2 UC)PlanCédric Buche (ENIB)POO20 novembre 201386 / 135

Diagrammes d’interaction (2 UC)IntroductionDu diag. de cas d’utilisation au diag. d’interactionsdiag. cas d’utilisation scénariosscénario diag. seq/commCédric Buche (ENIB)POO20 novembre 201387 / 135

Diagrammes d’interaction (2 UC)IntroductionCas d’utilisation Piloterscénario nominal pourrait être : un pilote démarre une voiture cequi allume un moteur.Comment formaliser les communications entre instances(démarrer, allumer) ? diag. de communication.Comment formaliser le séquencement des interactions (1 :démarrer ; 2 : allumer) ? diag. séquence.Avant cela, il faut représenter les instances (objets) (un pilote, unevoiture, un moteur)Cédric Buche (ENIB)POO20 novembre 201388 / 135

Diagrammes d’interaction (2 UC)IntroductionObjet : instance de classifiernom d’instance : nom de classeExemplejean : Personnepierre : PersonneCédric Buche (ENIB)POO20 novembre 201389 / 135

Diagrammes d’interaction (2 UC)IntroductionObjets : instances de classifiernomObjet::NomClassenomObjet:NomClasse stereotype Classe[etat]attr1 valeur1Cédric Buche (ENIB)POO20 novembre 201390 / 135

Diagrammes d’interaction (2 UC)Diagramme de séquenceDiagramme de séquence : durée de vie et flotstemps (logique) : séquencementobjetsobjet2:objet1:messageflots d’exécutionlignes de vieCédric Buche (ENIB)POO20 novembre 201391 / 135 pag

Introduction Introduction a UML 1 Introduction 2 Diagramme de classes (4 UC) 3 Diagramme de cas d'utilisation (1 UC) 4 Diagrammes d'interaction (2 UC) C edric Buche (ENIB) POO 20 novembre 2013 9 / 135. Introduction Introduction a UML UML : Uni ed Modeling Language Langage graphique de mod elisation pour sp eci er,