Upload
montasser-taktak
View
8
Download
0
Embed Size (px)
Citation preview
*Gnie logicielUML : Unified Modeling Language
A. Madani ([email protected])
*Gnie LogicielUMLIntroductionCycle de vie dun logicielHistorique dUMLDiagrammes UMLDiagrammes de classes et d'objetsDiagrammes des cas d'utilisationAutres diagrammesPassage vers le codeDe UML vers JavaUML et les bases de donnesLangage de contraintes : OCLtudes de casDe lanalyse des besoins au code
*Cycle de vie dun logicielA. Madani ([email protected])*Processus (ensemble dactivits) ncessaire au dveloppement et la maintenance dun logicielCompos de plusieurs phases autonomes mais dpendantes (interdpendantes).Chaque tape se termine par la remise de un ou plusieurs documents valid conjointement par lutilisateur et le dveloppeur.
*Cycle de vie dun logicielA. Madani ([email protected])*tapes ncessaires la ralisation dun logiciel:AnalyseConceptionCodage (Implmentation)TestsLivraisonMaintenance
*Cycle de vie dun logicielModle en Cascade (WaterFall)*A. Madani ([email protected])
*Cycle de vie dun logicielAnalyseElle a pour but de dgager le problme tudier. Le rsultat de l'analyse est le cahier de charges (exprim dans une langue naturelle) contenant les besoins du futur systme.Cette spcification est informelle.3 phases:(Faisabilit, Spcifications des besoins, Organisation du projet)
*A. Madani ([email protected])
*Cycle de vie dun logicielFaisabilitA. Madani ([email protected])*Premire tape du cycle de vie dun logicielRpondre deux questions :Est-ce que le logiciel est ralisable ?Est-ce que le dveloppement propos vaut la peine dtre mis en uvre ?
tudier le march pour dterminer sil existe un march potentiel pour le produit.
*Cycle de vie dun logicielSpcification des besoinsA. Madani ([email protected])*Permet de dfinir ce que doit faire le logiciel et non comment il le faitQuatre types de spcificationsSpcifications gnralesSpcifications fonctionnellesSpcifications dinterfaceSpcifications techniques
*Cycle de vie dun logicielSpcification des besoinsA. Madani ([email protected])*La spcification gnrale consiste identifier :Objectifs atteindre Contraintes (utilisation du matriel et outils existants)Rgles de gestion respecter
*Cycle de vie dun logicielSpcification des besoinsA. Madani ([email protected])*Spcification fonctionnelles est la description des fonctionnalits du futur logiciel de manire dtaille que possible
Spcification dinterface dcrit les interfaces du logiciel avec le monde extrieur : homme (IHM), autres logiciel (Middleware), machines
*Cycle de vie dun logicielSpcification des besoinsA. Madani ([email protected])*Spcification technique :(tude de lexistant)Moyens daccs (local, distant, Internet, )Temps de rponse acceptable (gestion des GAB, gestion des emplois de temps, )Plateforme (Windows, Unix, )Quantit dinformations stocker (choix du SGBDR, )
*Cycle de vie dun logicielOrganisation du projetA. Madani ([email protected])*Appele aussi Planification et gestion de projetPermet de dterminer la manire de dvelopper le logicielLa phase de planification permet de :dcouper le projet en tchesdcrire leur enchanement dans le temps, affecter chacune une dure et un effort
*Cycle de vie dun logicielOrganisation du projetA. Madani ([email protected])*Plusieurs tapes :Analyse des cots: estimation du prix du projetPlanification: calendrier pour le dveloppement (jours ouvrables, jours fris, nombre dheures de travail par jours, )Rpartition des tches: distribuer les tches et les sous tches (affectation des ressources aux tches)
*Cycle de vie dun logicielConceptionPermet de fournir une description fonctionnelle (formelle) du systme en utilisant une mthode. Les mthodes proposent des formalismes (dans la plupart des temps graphiques) pour concevoir le systme.Deux types de conception :Conception gnraleConception dtaille
*A. Madani ([email protected])
*Cycle de vie dun logicielConception gnraleA. Madani ([email protected])*Appele aussi : Conception architecturaleSe focaliser sur larchitecture gnrale du systme : dcomposition du systme en sous systmeExemple, pour la gestion scolaire :Estudiantine (tudiants, notes, prof, filires, )Administrative (personnel administratif, )Bibliothque (Ouvrages, auteurs, adhrents, )
*Cycle de vie dun logicielConception dtailleA. Madani ([email protected])*Produire une description externe de chacune des procdures, fonctions et des structures de donnes (conception classique)Produire de manire prcise les contenus des objets en terme de proprits et de mthodes (conception Oriente Objet)
*Cycle de vie dun logicielimplmentation (Ralisation)Des programmes seront labors afin de mettre en uvre des solutions techniques prcdemment retenuesPlusieurs types langages sont utiliss:Langages classiques (C, Pascal, Fortran, )Langages orients objets (C++, Java, C#, )*A. Madani ([email protected])
*Cycle de vie dun logicielCodage et TestsA. Madani ([email protected])*On distingue plusieurs types de tests :Test unitaire: tester les parties du logiciel par les dveloppeursTest dintgration: tester pendant lintgration des modulesTest systme: tester dans un environnement proche celui de productionTest alpha: tests faits par le client sur le site de dveloppementTest bta: tests faits par le client sur le site de productionTest de rgression: enregistrer les rsultats des tests et les comparer avec ceux des anciens versions pour dterminer si la nouvelle na pas apport de dgradation de performance.
*Cycle de vie dun logicielLivraisonA. Madani ([email protected])*Fournir au client une solution logiciel qui fonctionne correctement.Plusieurs tches :Installation: rendre le logiciel oprationnel sur le site du clientFormation: enseigner aux utilisateurs se servir de ce logicielAssistance: rpondre aux questions de lutilisateur
*Cycle de vie dun logicielMaintenanceA. Madani ([email protected])*Mettre jour et amliorer le logicielLa maintenance comprend :Corrective : correction des erreurs et anomaliesAdaptative : adaptation de nouveaux environnementsvolutive ou Perfective : ajout de nouvelles fonctionnalits
*Cycle de vie dun logicielDocumentsA. Madani ([email protected])*Cahier des charges : description des fonctionnalits dsires (dcrites par lutilisateur)Spcifications : dcrit ce que doit remplir le logiciel (dcrites par le dveloppeurs) :Modle Objet : Classes et objetsScnarios des cas dutilisation : diffrents enchanements possibles du point de vue de lutilisateurIHM : propositions des interfaces homme-machines
*Cycle de vie dun logicielDocumentsA. Madani ([email protected])*Calendrier du projet: indique les tches, les dlais et les ressourcesPlan de test: indique les procdures de tests appliquerManuel dutilisateur: mode demploi du logiciel dans sa version finale
*Cycle de vie dun logicielDocumentsA. Madani ([email protected])*Code source: code complet du produit finiRapport des tests: dcrit les tests effectus et les ractions du systmeRapport des dfauts: dcrit les comportements du systme qui nont pas satisfait le client.
*HistoriqueDeux approchesApproche fonctionnelle1960 fin 1970l'important c'est les traitementsSparation nette des donnes et traitementsApproche objet1980 dbut 1990 : premires gnrationL'important c'est l'objetObjet = donnes + traitements
*HistoriqueDbut des annes 1990les premiers processus de dveloppement OO apparaissentprolifration des mthodes et notations taient la cause de grande confusion :mthode OOD de Grady Booch (1991)mthode OMT de James Rumbaugh (1991)mthode OOSE de Ivar Jacobson (1991)mthode OOA/OOD de Coad and Yourdon (1992)mthode de Schlaer and Mellor (1992)Etc.
*HistoriqueFin 1994J. Rumbaugh rejoint G. Booch chez Rational Software OMT + OOD Unified Method (oct 1995)Fin 1995I. Jacobson les rejoint chez Rational SoftwareUnified Method + OOSE UML 0.9 (juin 1996)Dbut 1997Partenaires divers : Microsoft, Oracle, IBM, HP et autres leaders collaborent UML 1.0 (jan 1997)Fin 1997lOMG (Object Management Group) retient UML 1.1 comme norme de modlisation
Madani - OMG (fonde en 1989) Organisation Internationale regroupant plus de 800 membres : vendeurs de systmes, dveloppeurs de logiciels, utilisateurs, ...
*HistoriqueLes versions se succdent :Dbut 1998UML 1.2En 1998UML 1.3En 2001UML1.4En 2003UML 1.5En 2005UML 2.0
Madani - OMG (fonde en 1989) Organisation Internationale regroupant plus de 800 membres : vendeurs de systmes, dveloppeurs de logiciels, utilisateurs, ...
*Quest ce que UML ?UML(Unified Modeling Language) un langage de modlisation unifiLangage = syntaxe + smantique :syntaxe : notations graphiques consistant essentiellement en des reprsentations conceptuelles d'un systmesmantique : sens prcis pour chaque notation
*Quest ce que UML ?UML est caractris par :un travail d'expertutilise lapproche oriente objetnormalis, richeFormel : sa notation limite les ambigut et les incomprhensionslangage ouvertINDPENDANT du langage de programmationDomaine d'application : permet de modliser n'importe quel systmeSupport par plusieurs outils (AGL) : Objecteering, Open tools, Rational Rose, PowerAMC, WinDesign,
*Quest ce que UML ?AttentionUML est un langage (et non pas une mthode) qui :permet de reprsenter les modlesne dfinit pas le processus d'laboration des modles.
*Diagrammes d'UMLUML1.1 comprend 9 de diagrammes :
*Diagrammes d'UMLUML dfinit deux types de diagrammes, structurels (statiques) et comportementaux (dynamiques)Modlisation de la structurediagramme de classesdiagramme dobjetsdiagramme de composantsdiagramme de dploiementModlisation du comportementdiagramme de cas d'utilisationdiagramme dtatsdiagramme dactivitsdiagramme de collaborationdiagramme de squence
*Diagramme dUMLLes diagramme dUML peuvent tre utiliss pour reprsenter diffrents points de vues :Vue externe : vue du systme par ses utilisateurs finauxVue logique statique : structure des objets et leurs relationsVue logique dynamique : comportement du systmeVue dimplmentation : composants logicielsVue de dploiement : rpartition des composants
*Diagramme dUMLObjetsClasses
*UMLDiagrammes de classes et dobjets
*Diagramme de classesPermet de donner une vue statique du systme en terme de :Classes d'objetsRelations entre classesAssociationsagrgation/compositionhritageLa description du diagramme de classes est centre sur trois concepts:Le concept dobjetsLe concept de classes dobjets comprenant des attributs et des oprationsLes diffrents types de relations entre classes.
*Concept d'objetObjet = un concept, abstraction ou une chose autonome qui a un sens dans le contexte du systme modliserune personne : le client El Alami M.un objet concret : le livre intitul Initiation un objet abstrait : le compte bancaire n 1915233C
*Concept d'objetRemarqueUn objet doit :tre autonomeAvoir une signification dans le systmeEn relation avec d'autres objetsNe pas confondre "autonomie" avec "indpendance"!!ExemplesGestion de stock : Clients, Commandes, Articles, Gestion scolaire : tudiants, Modules, Filires,
*Concept d'attributUn attribut est une proprit, caractristique dun objet. Par exemple : un client a un nom, un prnom, une adresse, un code client, un compte bancaire a un numro, un solde, Un attribut doit (gnralement) avoir une valeur atomique
*Concept d'attributLa description dun attribut comporte :Visibilit attribut:type[= valeur initiale]O :Visibilit:+ (publique, public): visible par tous- (prive, private): visible seulement dans la classe# (protge, protected): visible seulement dans la classe et dans les sous-classes de la classe.Nom dattributType de lattributValeur initiale (facultative)
*Concept d'attributLe type dun attribut peut tre :Un type de base : entier, rel, Une expression complexe : tableaux, enregistrements, Une classeExemples dattributs:- couleur: enum{Rouge, Vert, Bleu}# b: boolean = vrai- Client : Personne
*Concept d'attributLorsquun attribut peut tre driv ou calcul partir d'autres attributs, il est prcd dun /. Par exemple, une classe Rectangle peut contenir les attributs suivants:longueur: rel,largeur: rel,/surface: rel.
*Concept d'attributOn distingue deux types d'attributs :Attribut d'instance :Chaque instance de la classe possde une valeur particulire pour cet attributNotation : Visibilit attribut:type[= valeur initiale] Attribut de classeToutes les instances de la classe possde la mme valeur pour cet attributNotation : Visibilit attribut:type[= valeur initiale]quivalent en C++, Java : static
*Concept d'attributOprations d'instancesOprations de classesAttributs d'instancesAttributs de classes
*Concept d'opration et mthodeUne opration est :un service offert par la classeune fonction ou une transformation qui peut tre applique aux objets dune classe. permet de dcrire le comportement dun objet. Par exemple, Embaucher, Licencier et Payer sont des oprations de la classe Socit.
*Concept d'opration et mthodeUne mthode estlimplmentation dun service offert par la classe (opration).de diffrents types :accesseurs (get...): renvoie une information sur l'tat d'un objet (fonction)modifieurs (set...): modifie l'tat de l'objet (procdure)constructeurs: initialise une nouvelle instance
*Concept d'opration et mthodeLa description dune opration comporte :Visibilit opration([arguments:type[=valeur initiale]]):type de rsultat
Visibilit de lopration (-, +, #)Nom de loprationListe des arguments avec leurs types et ventuellement leurs valeurs par dfautLe type du rsultat retourn
*Concept d'opration et mthodeExemples d'oprations :
*Concept de classes dobjetsClasse = ensemble dobjets ayant les mmes proprits (attributs) et le mme comportement (oprations)tous les clients sont dcrits par un nom, un prnom, et peuvent marcher, parler,courir, tous les comptes bancaires ont un numro, un solde, et sur lesquels on peut dposer ou retirer l'argent, ou les consulter Un objet est instance dune classe, et le fait de crer un objet d'une classe est dite instanciation.
*Concept de classes dobjetsClasse reprsente par un rectangle trois parties :Partie 1 : Nom de la classePartie 2 : Attributs (proprits, champs)Partie 3 : Mthodes (fonctions, oprations)
*Concept de classes dobjets
*Concept de classe d'objetsOn peut ne pas visualiser les attributs et/ou les oprations, afin de ne pas alourdir inutilement le schma.Nom de la classeAttributsOprationsNom de la classeAttributsNom de la classeNom de la classeOprations
*Encapsulation, visibilit et interfaceEncapsulation est le mcanisme de regrouper les attributs et les oprations au sein dune mme entit (classe)Ce regroupant permet dempcher daccder directement aux donnes par un autre moyen que les services proposs (oprations)Ces services offerts aux utilisateurs dfinissent ce que lon appelle linterface de la classe.
*Encapsulation, visibilit et interface
Donnes
Traitement}}Partie statique, passivePartie cache, privePartie dynamique, comportementalePartie visible, publiqueInterface avec lextrieur
*Mthodes et classes abstraitesUne mthode est dite abstraite si on connat son entte, mais pas la manire dont elle peut tre raliseUne classe est dite abstraite lorsquelle dfinit au moins une mthode abstraite
*Classe Interface Une interface est une classe spciale dont toutes les mthodes sont abstraitesUne interface se note en UML avec le strotype ou symbole
*PackageUn package permet de regrouper des classes, des interfaces et des packages.Les classes, les interfaces et les packages ne peuvent quun seul package dans lequel ils sont regroups
*PackageUn package est reprsent par un rectangle possdant un onglet dans lequel est inscrit le nom du package
*Import des packagesLa relation dimport permet une classe dun package dutiliser les classes dun autre package.La relation est monodirectionnelle : elle comporte un package source et un package cible.
*Import de packagesLa relation dimport sexprime avec une flche en pointillDans lexemple, la classe Afficheur a besoin des classes du package Dessin
*AssociationsRelation existant entre une, deux ou plusieurs classes.Une association porte un nom (signification)Reprsente par une ligne rectiligne
*AssociationsRemarquesune association fonctionne (gnralement) dans les 2 sens (bidirectionnelle) termes associs : Nom, Sens de lecture, degr (arit), Multiplicit, Rle, navigabilit et le qualificateur
*Associations Nom et sens de lectureDcrit la nature (signification) de lassociationMontre la direction de lecture de lassociation
*Associations Rle dune associationDcrit le rle dune classe dans une association
*AssociationsRle dune associationUtile surtout dans deux cas :Lorsquon a plusieurs associations entre deux classes avec des rles diffrentsune relation rflexive : relation entre deux instances dune mme classe
*AssociationsClasse association
Une association peut avoir des attributs = classe-association
*AssociationsClasse associationLes classes association sont utiles quand il y a des attributs qui sont pertinents lassociation, mais aucune des classes impliques.
*Associations
degr dune association = nombre de classes participantesAssociation unaire : relie 2 instances d'une classe association binaire : relie 2 classes association ternaire : relie 3 classes association n-aire : relie n classes
*Associations
Multiplicit = nombre de participations dune classe dans uneassociation indique chaque extrmit dune association sous la forme min..max min, max = 0, 1, * Exemple gnral Exemple concret
*Associations
Exemple ternaire Pour un couple dinstances de la classe A et de la classe B, il y a au min. r1 instances de la classe C et au max. r2 instances,
*Associations
Notation abrge des multiplicits :1 1..1 (exactement 1)* 0..* (0 ou plusieurs)n n .. n (exactement n)1..* 1 ou plusieurs (1 ou plus)0..1 0 ou 1 (au plus un)1..100 entre 1 et 1002,4,5 2, 4 ou 5
*AssociationNavigabilitUne association est par dfaut bidirectionnelle.
Cependant, il peut tre utile de se limiter une seule direction association navigable
*AssociationNavigabilit (Exemple)Spcification : on doit tre en mesure de savoir le client qui a fait la commande et non toutes les commandes dun clientConception :
Implmentation : la classe commande doit avoir un champ faisant rfrence la classe client
*AssociationNavigabilit (Exercice)Un tudiant peut avoir jusqu 5 copies dexamens. un tudiant sont associes ses copies dexamens, mais on ne doit pas autoriser laccs lauteur de la copie (notamment avant la correction des copies)
*Qualification d'une associationLa qualification dune association permet de restreindre la multiplicit dune association.La qualification se reprsente par un rectangle plac au niveau de la classe source du qualificatif.
*Qualification d'une associationExemple : une banque contient plusieurs comptes, d'o le diagramme :BanqueCompte11..*
BanqueCompteNCompte11Par contre, si on connat le NCompte, il y a un et un seul compte, on obtient alors :
*Qualification d'une associationExerciceUn avion est compos de plusieurs siges, mais dans une range il y a seulement quatre siges.
*AgrgationType particulier dassociation dans laquelle :Classe agrgat (compos), classes agrge (composant)Entre les deux, il existe une relation de type est composde AgrgatAgrge
*AgrgationLes parties (les composants) sont sparables de Lagrgat (le tout)La suppression dune quipe nimplique pas la suppression des personnes qui la composent
*AgrgationUn agrgat (compos) peut tre multiple.
*CompositionLa composition est un cas particulier dune agrgation dans laquelle la vie des composants (lment) est lie celle de lagrgat (compos): si lagrgat est dtruit (ou dplac), ses composants le sont aussi.Dun autre ct, et contrairement lagrgation, une instance de composant ne peut tre lie qua un seul agrgat.La composition se reprsente par un losange noir (plein).
*Composition la suppression dun objet agrgat entrane la suppression des objets agrgs
*CompositionUn document est compos de plusieurs paragraphes, qui, son tour, est compos de plusieurs phrasesRemarquer la propagation des oprations (copie, suppression,)
*Gnralisation / Spcialisation et hritageLa gnralisation est la relation entre une classe et une ou plusieurs de ses versions raffines.On appelle la classe dont on tire les prcisions la super-classe et les autres classes les sous-classes.Cest une relation de type est un (is a) ou est une sorte de.La notation utilise pour la gnralisation est le triangle
*Gnralisation / Spcialisation et hritage gnraliser = mettre en facteur des classes super-classe spcialiser = dcrire de nouveaux dtails sous-classes comparable une association de type est un, is a, kind of une sous-classe hrite des attributs et oprations de sa super-classe (classe mre)
*Gnralisation / Spcialisation et hritageLa classe spcialise (sous-classe)hrite les mthodes et les attributs de la classe gnrale (super-classe)peut ajouter ses propres attributs et mthodes.peut redfinir le comportement dune mthode.
*Gnralisation / Spcialisation et hritage
*Gnralisation / Spcialisation et hritageRemarquesLa gnralisation et la spcialisation sont deux faons pour voir la mme relation, top-down (spcialisation) ou bottom-up (gnralisation).L'hritage est limplmentation de la relation de la gnralisation/spcialisation.Une classe peut hriter de plusieurs classes, on parle alors dun hritage multiple.
*Gnralisation / Spcialisation et hritageSpcialisationGnralisationSuper classe, classe mreSous classesClasses fillesClasses drives
*Gnralisation / Spcialisation
une classe peut hriter de plusieurs super-classes= hritage multiple
*Gnralisation / Spcialisation
polymorphisme = oprations de mme nom, polymorphisme = comportement spcifique
*Contraintes sur les associationsConcepts avancs des associationsPermettent dimposer des rgles respecter lors du passage limplmentationIl est possible dattribuer toutes sortes de contraintes une associationLes contraintes sont reprsentes entre accolades et peuvent tre exprimes dans nimporte quel langage (y compris OCL)
*Contraintes sur les associationsLes contraintes (prdfinies) souvent utilises :{ordonn}{sous ensemble}{xor}{addOnly}{frozen}
*Contraintes sur les associationscontrainte {ordonn}Indique que les objets seront ordonns chaque opration de cration, modification, suppression, Les comptes dune personne sont ordonns
*Contraintes sur les associationscontrainte {sous-ensemble}Indique quune collection est incluse dans une autreNcessite la prsence dau moins deux relationsLes personnes qui jouent le rle de dlgu font partie des personnesqui jouent le rle de parents dlves Parent dlveDlgu
*Contraintes sur les associationscontrainte {xor}Indique que parmi un groupe dassociations, une seule est valide la foisUn PC Portable est aliment soit partirdune batterie, soit partir dun secteur
*Contraintes sur les associationscontrainte {addOnly}La contrainte prdfinie {addOnly} autorise lajout de nouveaux objets, mais pas leur suppression ni leur mise jour.
*Contraintes sur les associationscontrainte {frozen}La contrainte prdfinie {frozen} interdit lajout, la suppression ou la mise jour des liens dun objet vers les objets de la classe associe, aprs linitialisation du premier.
*Contraintes sur les associationsExercicesModliser sous forme de diagrammes de classes :Le prsident dun comit doit tre membre du comitUne personne qui soumit un article un journal ne peut pas valuer son propre article
*Contraintes sur les associationsExercicesModliser sous forme de diagrammes de classes :Un vhicule est compos dau moins 2 roues. Le nombre de roues dun vhicule ne peut pas varierLes employs de lhtel nont pas le droit de prendre une chambre dans le mme htel.
*Contraintes sur les associationsExercicesUne personne Est ne dans un pays (ce pays ne peut tre modifie)A visit un certain nombre de pays, dans un ordre donn, et que le nombre de pays visits ne peut que crotreAimerait encore visiter toute une liste de pays, et que cette liste est ordonne.
*Exemple de diagramme de classes(Distributeur Automatique de Banque : DAB)
*Diagramme dobjetsReprsente les objets (instances de classes) et les liens (instances de relations) un instant donnPeut tre utilis pour :Illustrer le modle de classes en montrant un exemple qui explique le modlePrciser certains aspects du systmeExprimer une exception en modlisant des cas particuliersEtc.
*Diagramme dobjetsLe nom dun objet est soulignNom : ClasseNom:Classe
*Diagramme dobjetsExemple :Une entreprise emploie au moins deux personnesUne personne travaille dans au plus deux entreprises
*Diagramme dobjetsExemple
*Etapes pour tablir un diagramme
A partir dune description du systme :Identifier un premier ensemble de classes candidatesIdentifier les associations et les attributsIdentifier les gnralisationsLister les traitements, choisir les oprationsVrifier le modle obtenuItrer jusqu satisfaction Supprimer les transitivitsSassurer que le schma rpond la demande
*UMLDiagrammes de cas d'utilisation
*Diagramme des cas dutilisationDcrit, sous forme dactions et de ractions, le comportement dun systme du point de vue dun utilisateur.Permet de dfinir les limites du systme et ses relations avec lenvironnement.
*Diagramme de cas d'utilisationSert modliser les aspects dynamiques d'un systme (Contrairement aux diagrammes de classes).Fait ressortir les acteurs et les fonctions offertes par le systme.Utilis pour modliser les exigences (besoins) du client
*Diagrammes des cas d'utilisationComportent plusieurs lments :ActeursCas d'utilisationRelations de dpendances, de gnralisations et d'associations
*ActeursUML nemploi pas le terme dutilisateur mais dacteur.Le terme acteur ne dsigne pas seulement des utilisateurs humains mais galement les autres systmes (machines, programmes, )Un acteur est un rle jou par une entit externe qui agit sur le systme (Comptabilit, service commercial, ), en changeant de linformation (en entre et en sortie)
*ActeursRemarquesLa mme personne physique peut jouer le rle de plusieurs acteurs (Chef dagence est un client de la banque).Dautres part, plusieurs personnes peuvent jouer le mme rle, et donc agir comme un mme acteur (plusieurs personnes peuvent jouer le rle dadministrateur).
*ActeursPeut tre reprsent de deux manires diffrentes :
Petit personnage (stick man)
Classe strotype
Nom Acteur
*ActeursLes acteurs peuvent tre de trois types :Humains : utilisateurs du logiciel travers son interface graphique, par exemple.Logiciels : disponibles qui communiquent avec le systme grce une interface logicielle (API, ODBC, )Matriels : exploitant les donnes du systme ou qui sont pilots par le systme (Imprimante, robots, automates, )
*Acteurs
*ActeursMais du point de vue systme on distingue deux types :Acteurs principaux : utilisent les fonctions principales du systme. Par exemple, le client pour un distributeur de billets.Acteurs secondaires : effectuent des tches administratives ou de maintenance. Par exemple, la personne qui recharge la caisse contenue dans le distributeur.
*ActeursUn acteur peut tre une spcialisation d'un autre acteur dj dfini.
Dans ce cas, on utilise la relation de gnralisation/spcialisation.
*Cas d'utilisationIntroduit par Ivar Jacobson en 1992 dans sa mthode Object-Oriented Software Engineering (OOSE).Technique de description du systme tudi privilgiant le point de vue de l'utilisateur.Repris par UML dans la but de :Effectuer une bonne dlimitation du systmeAmliorer la comprhension de son fonctionnement interne
*Cas d'utilisationLes cas dutilisationsPermettent de modliser les attentes (besoins) des utilisateursReprsentent les fonctionnalits du systmeSuite dvnements, initie par des acteurs, qui correspond une utilisation particulire du systmeLimage dune fonctionnalit du systme, dclenche en rponse la stimulation dun acteur externe.
*Cas d'utilisationUn cas d'utilisation est reprsent par une ellipse en trait plein, contenant son nom.
* Structuration des cas d'utilisation
Aprs avoir identifi les acteurs et les cas d'utilisation, il est utile de restructurer l'ensemble des cas d'utilisation que l'on a fait apparatre afin de rechercher les :Comportements partagsCas particuliers, exceptions, variantesGnralisations/spcialisations.
*Structuration des cas d'utilisationUML dfinit trois types de relations standardises entre cas d'utilisation :Une relation d'inclusion, formalise par la dpendance includeUne relation d'extension, formalise par la dpendance extendUne relation de gnralisation/spcialisation
*Relation d'inclusionLors de la description des cas d'utilisation, il apparat qu'il existe des sous-ensembles communs plusieurs cas d'utilisation, il convient donc de factoriser ces fonctionnalits en crant de nouveaux cas d'utilisation qui sont utiliss par les cas d'utilisation qui les avaient en commun.
*Relation d'inclusionA inclut B : le cas A inclut obligatoirement le comportement dfinit par le cas B; permet de factoriser des fonctionnalits partagesLe cas d'utilisation point par la flche (dans notre cas B) est une sous partie de l'autre cas d'utilisation (A, dans notre exemple).
*Relation d'inclusionLes cas d'utilisation "Dposer de l'argent", "Retirer de l'argent", "Effectuer des virements" et "Consulter solde" incorporent de faon explicite le cas d'utilisation "S'authentifier", un endroit spcifi dans leurs enchanements.
*Relation d'inclusionOn utilise cette relation pour viter de dcrire plusieurs fois un mme enchanement d'actions. Ainsi, on est amen factoriser un comportement commun plusieurs cas d'utilisation dans un cas d'utilisation part.
*Relation d'inclusionRemarquesLa relation include na pour seul objectif que de factoriser une partie de la description dun cas dutilisation qui serait commune dautres cas dutilisation. Le cas dutilisation inclus dans les autres cas dutilisation nest pas proprement parl un vrai cas dutilisation car il na pas dacteur dclencheur ou receveur dvnement. Il est juste un artifice pour faire de la rutilisation dune portion de texte.
*Relation d'inclusionRsumUne instance du cas source inclut obligatoirement le comportement dcrit par le cas dutilisation destinationPermet de dcomposer des comportements et de dfinir les comportements partages entre plusieurs cas dutilisation Factoriser
*Relation d'extension
La relation strotype extend permet d'tendre les interactions et donc les fonctions dcrites dans les cas d'utilisation, mais sous certaines contraintes.
*Relation d'extensionLe CU source (B) ajoute, sous certaines conditions, son comportement au CU destination (A)En dautres termes, le CU B peut tre appel au cours de lexcution du CU A
Le comportement ajout sinsre au niveau dun point dextension dfinit dans le CU destination
*Relation d'extensionLe cas d'utilisation de destination peut fonctionner tout seul, mais il peut galement tre complt par un autre cas d'utilisation, sous certaines conditions.On utilise principalement cette relation pour sparer le comportement optionnel (les variantes) du comportement obligatoire.
*Relation d'extensionExemple :Au moment de l'authentification, il se peut que le guichet retient la carte.
*Relations dinclusion VS d'extensionLa relation extend" montre une possibilit d'excution d'interactions qui augmenteront les fonctionnalits du cas tendu, mais de faon optionnelle, non obligatoire, La relation "include" suppose une obligation d'excution des interactions dans le cas de base.
*Relation d'hritageIl peut galement exister une relation d'hritage entre cas d'utilisation.Cette relation exprime une relation de spcialisation/gnralisation au sens classique.
*Relation d'hritage : ExempleDans un systme d'agence de voyage, un acteur "Touriste" peut participer un cas d'utilisation de base qui est "Rserver voyage", qui suppose par exemple, des interactions basiques au comptoir de l'agence. Une rservation peut tre ralise par tlphone ou par Internet.
*Relation d'hritage : ExempleOn voit qu'il ne s'agit pas d'une relation "extend", car la rservation par Internet n'tend pas les interactions ni les fonctionnalits du cas d'utilisation "Rserver voyage".Les deux cas d'utilisation "Rservation voyage" et "Rserver voyage par Internet" sont lis : la rservation par Internet est un cas particulier de rservation.De faon gnrale en objet, une situation de cas particulier se traduit par une relation de gnralisation/spcialisation.
*Relation d'hritage : Exemple
*Structuration entre cas dutilisationRsumLes cas peuvent tre structures par des relations :A inclut B : le cas A inclut obligatoirement le comportement dfinit par le cas B; permet de factoriser des fonctionnalits partagesA tend B : le cas A est une extension optionnelle du cas B un certain point de son excution.A gnralise B : le cas B est un cas particulier du cas A.
*Relations entre cas dutilisation : ExempleUn client peut effectuer un retrait bancaire. Le retrait peut tre effectu sur place ou par Internet. Le client doit tre identifi (en fournissant son code daccs) pour effectuer un retrait, mais si le montant dpasse 500DH, la vrification du solde de son compte est ralise.
*Relations entre cas dutilisation
*Description des cas dutilisationLe diagramme de cas dutilisation dcrit les grandes fonctions dun systme du point de vue des acteurs.Mais il nexpose pas de faon dtaille le dialogue entre les acteurs et les cas dutilisation. ncessit de dcrire ce dialogue
*Description des cas dutilisationDeux faons sont couramment utilises pour dcrire les cas dutilisation :Description textuelleDescription laide dun diagramme de squence (voir chapitre suivant)
*Description des cas dutilisation (description textuelle)IdentificationNom du cas : retrait dargentObjectif : dtaille les tapes permettant un guichetier deffectuer des oprations de retrait par un clientActeurs : Guichetier (Principal), Systme central (Secondaire)
*Description des cas dutilisation (description textuelle)ScnariosScnario nominalLe Guichetier saisit le numro de compte clientLapplication valide le compte auprs du SCLapplication demande le type dopration au GuichetierLe Guichetier slectionne un retrait de 200 DHLe systme interroge le SC pour sassurer que le compte est suffisamment approvisionn.Le SC effectue le dbit du compteLe systme notifie au guichetier quil peut dlivrer le montant demand
*Description des cas dutilisation (description textuelle)ScnariosScnario alternatif (exception)En (5) : si le compte nest pas suffisamment approvisionn .
*Description des cas dutilisation (description par diagramme de squence)
*Intrts des cas dutilisationLes CU obligent les utilisateurs :Dfinir la manire dont ils voudraient interagir avec le systmePrciser quelles informations ils entendent changer avec le systmeDcrire ce qui doit tre fait pour obtenir le rsultat escompt
*Diagramme des cas d'utilisationLe diagramme des cas d'utilisation regroupe dans un mme schma les acteurs et les cas d'utilisation en les reliant par des relations. Le systme tant dlimit par un cadre rectangulaire.La reprsentation de base d'un cas d'utilisation est une ellipse contenant le nom du cas. L'interaction entre un acteur et un cas d'utilisation se reprsente comme une association. Elle peut comporter des multiplicits comme toute association entre classes.
*Diagramme des cas d'utilisation
*tapes de construction du diagramme des cas d'utilisationPour modliser le diagramme des cas d'utilisation, il faut :Identifier les acteurs qui entourent le systme. Certains acteurs utilisent le systme pour accomplir des tches (acteurs principaux), d'autres effectuent des tches de maintenance ou d'administration (acteurs secondaires).Organiser les acteurs selon une hirarchisation de gnralisation/spcialisationIntgrer les acteurs au diagramme en spcifiant les cas d'utilisation auxquels ils se rapportentStructurer les cas d'utilisation pour faire apparatre les comportement partags (relation d'inclusion), les cas particuliers (gnralisation/spcialisation) ou options (relation d'extension)
*UMLDiagrammes de squences
*Diagramme de squencesReprsenter les interactions entre objets en prcisant la chronologie des changes de messagesReprsente une instance dun cas dutilisation (les scnarios possible dun cas dutilisation donn)Montre sous forme de scnarios, la chronologie des envoies de messages issus dun cas dutilisationLe diagramme de squence fait ressortir :Les acteursLes objetsLes messages
*Diagramme de squences
*Diagramme de squencesUn objet est reprsent par un rectangle et une ligne verticale (ligne de vie de lobjet)Les objets communiquent en changeant des messages reprsents par des flches orientes de lmetteur au rcepteurLordonnancement verticale des messages indique la chronologie
*Diagramme de squencesUn message reu par un objet dclenche lexcution dun oprationUn message envoy par objet correspond :Demander un service dun autre objetRenvoyer le rsultat dun opration
*Diagramme de squences : ExempleLe client demande un service (dposer de largent) lobjet CompteLe compte reoit le message et dclenche lopration de mme nomLe compte retourne le rsultat (le solde actuel)
*Diagramme de squencesPlusieurs concepts additionnels :Priode dactivitTypes de messagesCration et destruction dobjetsStructures de contrles
*Priode dactivitCorrespond au temps pendant lequel un objet fait une actionReprsente par une bande rectangulaire superpose la ligne de vie de lobjet
*MessagesTraduisent les interactions (change dinformations) entre objetsReprsents par des flches orientes de lmetteur au rcepteurPlusieurs types :Message simpleMessage minut (Timeout)Message synchroneMessage asynchroneMessage rcursif
*Message simpleMessage pour lequel on ne spcifie aucune information denvoi ou de rception
*Message minut (Timeout)Bloque lexpditeur pendant un temps donn, en attendant la prise en compte du message par le rcepteurAprs le dlai, lexpditeur est libr et peut envoyer
*Message minut (Timeout) : ExempleLa porte dun ascenseur souvre pendant un certain dlai avant dtre referme.
*Message synchrone (appel de procdure)Bloque lexpditeur jusqu la prise en compte du message par le rcepteurLe contrle est pass de lmetteur au rcepteur qui devient son tour metteur (actif)
*Message synchrone (appel de procdure) : ExempleCommunication client serveur : Sockets
*Message asynchroneNinterrompt pas lexcution de lexpditeurLexpditeur peut mettre sans attendre la rponse du rcepteur
*Message rcursifAppel aussi message rflexiveMessage envoy dun objet vers lui-mme.
*Message rcursif : ExempleLorsque le client introduit sa carte de guichet, ce dernier vrifie la validit de la carte avant de demander le code daccs
*Cration et destruction dobjetsUn message peut crer ou dtruire un objetCration dobjetDestruction dobjetObjet cr au cours de lexcution du scnarioObjet dtruit dans un scnario
*Traduction des messagesEnvoyer un message cest demander un service dun autre objet (sauf le cas dun message de retour).Les messages sont traduits par des oprations dans la classe de lobjet ayant reu le message
*Traduction des messagesclass Voiture{Public void demarrer(){}}class Conducteur{private Voiture voiture;public void conduire(){voiture.demarrer();}} main(String[] arg){conducteur.conduire();}
*Structures de contrleLe diagramme de squences peut inclure un certain nombre de structuresBranchements (tests)Rptitions (itrations, boucles)
*Les test (branchements)La condition prcde le message et elle est dlimite par des crochets
*Les test (branchements) : ExemplePour accder au centre de recherche, lutilisateur doit prsenter son badge. Sil a droit daccs, un voyant vert est allum et la porte souvre
*Les boucles (rptitions)La boucle se note comme le test, mais la condition est prcde dun astrisque
*FragmentsPermet de dcomposer une interaction complexe en fragments simplesReprsent par un rectangle dont le coin suprieur gauche contient un pentagoneDans le pentagone figure le type du fragmentloop : bouclealt : alternativeref : rfrence
*UMLDiagrammes de collaboration
*Diagramme de collaborationReprsente les interactions entre objets et relations structurelles permettant celles-ci.Permettent la description:Du comportement collectif dun ensemble dobjetsDes connexions entre ces objetsDes messages changs par les objetsInteraction ralise par un groupe dobjets qui collaborent en changeant des messages
*Diagrammes de collaborationReprsentation graphique de lvolution dun ensemble dobjets pour effectuer une actionDiffrences avec diagrammes de squence pas daxe temporeltemps modlis par numrotation
*Diagrammes de collaborationlments dune interactionInstances qui collaborent avec d'autres objets en changeant des informationsReprsents parliens qui sont des supports de messagesReprsents comme des associationsmessages dclenchant les oprationsIndiqus par des flches
*Diagrammes de collaborationExemple : Appel tlphonique :Appelant:Ligne:Appel1. Dcrocher2. Tonalit3. Numrotation4.1a. Tonalit sonnerie6.1a. Arrt tonalit4.1b. Sonnerie5. Dcrocher6.1b. Arrt sonnerie
*Diagrammes de collaborationAspect temporel modlis par numrotation des messagesType et Smantique des numrotations1, 2, 3, 4 : Numrotation simplesquencement des messages1, 1.1, 1.2, 1.2.1, 1.2.2, 1.2.3 : Dot notationsquencement + un point : ne peut tre termin que si ses sous points le sont aussi1, 1.1a, 1.1b, 1.2, 1.3 : Dot notation + concurrenceidem dot notation, mais les points 1.1a et 1.1b peuvent tre effectus en parallle
*Diagrammes de collaborationMmes types contraintes que pour les diagrammes de squenceItration : *[condition]Conditions : [condition]
Exemple : rservation darticles:Stock:Vendeur2. vrifier(n, item)3. [disponible]rserver(n, item):Client1. commander(n, item)4. livrer(n, item)
*Diagrammes de collaborationLes objets cres ou dtruits au cours dune interaction peuvent respectivement porter les contraintes :{Nouveau}{Dtruit}
*Diagrammes de collaborationConclusionReprsentation spatiale Aspect temporel plus difficile suivre que pour les Diagramme de squenceDure dexcution dune contrainte difficile valuerDiagramme niveau instanceLimite : taille des diagrammesPlus dinstances peuvent tre reprsentes sur un mme diagramme que pour les diagrammes de squence
*Exemple : Ascenseur (Squence)
*Exemple : Ascenseur (Collaboration)
*UMLDiagramme tat-transition
*Diagramme tat-transitionLe diagramme tat-transition :Fait partie des modles dynamiquesDcrit l'enchanement de tous les tats d'un objetPropre une classe donne. Il dcrit :Les tats des objets de cette classeLes vnements auxquels ils ragissentLes transitions qu'ils effectuent
*Diagramme tat-transitionLe diagramme tat-transition manipule plusieurs concepts :tatTransitionvnementGarde
*tatL'tat d'un objet est dfini par l'ensemble des valeurs de ses attributs (fentre affiche, fentre cache, )Un tat dpend de l'tat prcdent et de l'vnement survenuUn tat est reprsent par un rectangle aux coins arrondis
*TransitionC'est le passage d'un tat un autrePeut tre nomm par un vnementReprsent par une flche oriente de l'tat source vers l'tat cible
*vnementFait (externe) survenu qui dclenche une transition (changement d'tats)Peut tre rflexif et conduire au mme tatConduit l'appel d'une mthode de la classe de l'objetPeut possder des attributs : paramtres ports par des vnementsReprsents entre parenthses
Exemple*Soit le diagramme dtats/transitions de lobjet Fentre
*GardiensConditions ou fonctions boolennes associes une transitionUne transition garde ne peut tre effectue que si le gardien est vrifiUn gardien est reprsent entre crochets
*Formalisme et exemple
*Actions et activitsUn objet qui reoit un vnement dclenche une ou plusieurs oprationsOn distingue deux types d'oprations :Action : associe un tat ou une transitionActivit : associe un tat
*ActivitOpration d'une certaine dure, qui est excute tant que lobjet se trouve dans ltatAssocie un tat d'un objetReprsente dans l'tat prcde par la notation "do/"
*ActionOpration instantane non interrompuePeut tre associe aussi bien l'tat d'un objet qu'a une transitionElle peut intervenir soitEn entre de l'tat (prfixe : "entry/")En sortie de l'tat (prfixe : "exit/")En rponse un vnement (prfixe :"evt/")Au cours d'une transition (prfixe : "evt/")
*Formalisme et exemple
*ExerciceModliser ltat de saisie dun mot de passe :Au dbut, la zone de saisie est masque chaque saisie dun caractre, il stockLa touche F1 permet dafficher laideLe bouton dannuler permet de fermer la fentre la fin de la saisie (validation) le mot de passe est test (valide ou invalide)
*tat initial et tats finauxUn diagramme tat-transitionDbute toujours par un tat initialSe termine par un ou plusieurs tats finaux (sauf o le diagramme reprsente une boucle)
*Exemple (Feu de signalisation)
*Point de dcisionPermettent de reprsenter des partages de transitions ou des alternatives pour le franchissement dune transitionOn utilise deux mcanismes :Points de jonction (petit cercle plein) : pour partager des segments de transitionPoints de choix (losange) : pour choisir une ou une autre transition
*Point de jonction
Points de choix*
*tat compositeUn tat composite (#tat simple) est dcompos en deux ou plusieurs sous tatsCette dcomposition est rcursiveUn tat composite est reprsent comme un tat simple, sauf que les sous tats sont contenus dans le compartiment infrieur.
*Exemple
*HistoriqueOn reprsente le pseudo tat historique par un H cerclUne transition ayant pour cible ltat historique est quivalente une transition ayant pour cible le dernier tat visit dans la rgion contenant le HH* (historique profond) est un tat valable pour tous les niveaux
ConcurrencesPour reprsenter la concurrences dans un diagramme dtats/transitions, on utilise :tats concurrentsTransitions concurrentes*
*tats concurrentstat composite pour reprsenter lexcution de plusieurs automates sexcutant indpendammentOn utilise un sparateur en pointillsLobjet peut tre simultanment dans plusieurs tats concurrents
*tats concurrents
*Transitions concurrentesDeux transitions particulires : fork et joinLa transition fork correspond la cration de deux tats concurrentsLa transition join permet de supprimer la concurrences (barre de synchronisation)Pour pouvoir franchir la barre de synchronisation, toutes les tches concurrentes doivent tre acheves
*Transitions concurrentes
*UMLDiagramme d'activits
*IntroductionVariante des diagrammes d'tat-transitionPermet de dcrire le flot de contrle entre les oprations :ChoixSquencesItrationsParalllismeAu niveau macroscopique : dcrit les enchanements des oprationsAu niveau microscopique : dcrit l'algorithme d'une action du diagramme d'tats
*Concepts de basePlusieurs concepts sont manipuls :tatActivitTransition (squentielle, alternatives ou conditionnelle)Synchronisation (disjonction et conjonctions dactivits)ItrationSwimlanes
*Comportement conditionnelAppel aussi le branchementSymbolise une transition entrante garde par une condition et plusieurs transitions sortantes mutuellement exclusives
*Comportement conditionnel : Exemple
*SynchronisationFusion (conjonction) : plusieurs transitions entrantes et une seule sortanteComportement parallle : La barre de synchronisation permet d'ouvrir et de fermer les branches parallles au sein d'un flot d'excutionLes transitions partantes d'une barre ont lieu en mme tempsLa barre n'est franchie qu'aprs ralisation de toutes les transitions qui s'y rattachent
*Synchronisation : ExempleBarre de synchronisationFusion (conjonction)Comportement parallleDisjonction
*Itration : Exemple
*SwimlanesExtension des diagrammes d'activits permettant de reprsenter l'organisation.Reprsente le lieu, le responsable des activits.
*Rsum notation
*Exemple rcapitulatif
*Exemple rcapitulatif
*Exercice 1Reprsenter les tats suivants sous forme de diagramme d'activit :Vrification commandeEnregistrement commandeRejet commandeInformer erreur au client
*Exercice 1 : solution
*Exercice 2Dans le domaine de gestion de stock, on considre les tats suivants indiquant le flot de contrle de rception d'une livraison :Rception livraison, contrle qualit, contrle quantit et enregistrement livraison. Proposez un diagramme d'activit reprsentant ce flot d'information
*Exercice 2 : solution
*Exercice 3Construire un diagramme dactivit pour modliser le processus de commander dun produit. Le processus concerne les acteurs suivants:Comptable : enregistrement commande, envoie la facture et enregistrement paiement du clientClient : paiement de la facture
*Exercice 3 : solution
*Exercice 4Construire un diagramme dactivit pour modliser le processus de commander dun produit. Le processus concerne les acteurs suivants:Client: qui commande un produit et qui paie la factureCaisse: qui encaisse largent du clientVente: qui soccupe de traiter et de facturer la commande du clientEntrept: qui est responsable de sortir les articles et dexpdier la commande.
*Exercice 4 : solution
*UMLDiagrammes de Composants et de Dploiement
*Diag de Composants/ DploiementPermettent de modliser les aspects physiques dun systme orient-objetDiagramme de Composants : se focalise sur lorganisation et les dpendances entre un ensemble de composantsDiagrammes de Dploiement : se focalise sur la configuration en temps d'excution des nuds de traitement et de composants qui sont actifs
*Diagramme de composantsDans le monde de btiment, tout ce qui est propos par larchitecte (plan) constitue une vue logique : visualiser, spcifier, documenterLors de la construction, on utilise des composants physiques du monde rel : murs, fentres, portes,
*Diagramme de composantsDe mme, tout ce que nous avons vu jusqu prsent constitue le modle logique : visualiser, spcifier et documenter la structure et le comportement des objetsLa construction va sappuyer sur les composants du monde rel de lordinateur : fichiers, tables, librairies,
*Diagramme de composants Permet de dcrire l'architecture physique et statique d'une application en terme de composants:code source,bibliothques, excutables, Il montre la mise en oeuvre physique des modles de la vue logique dans l'environnement de dveloppementPermet de spcifier :ComposantsInterfacesRelations (dpendance, gnralisation, association, ralisation).
*ComposantUn composant est une partie physique et remplaable dun systme qui sait faire et fournit la ralisation dun ensemble dinterfaceLes composants peuvent tre organiss en paquetages
*ComposantNom du composant :Permet de distinguer un composant des autres composantsIl peut tre un nom simple ou un nom compos qui indique le paquetage auquel appartient le composantStrotypes : spcifient un composant qui dsigne:executable: un programme pouvant sexcuter sur un nud library : une bibliothque statique ou dynamiquetable: une table de base de donnesfile : un fichier contenant du code source ou des donnesdocument : un documentNom du composant
*ConceptsInterface : Est une collection doprations utilises pour spcifier les services dune classe ou dun composantRelations avec les interfacesRalisation : Dfinie entre linterface et le composant qui fournit les services pour les autres composants Cette interface est appele interface exporte Dpendance :Dfinie entre linterface et le composant qui utilise les services fournis par un autre composantCette interface est appele interface importe.
*Interface
*Relations entre les composantsDpendance :Cela signifie quun des lments dun composant a besoin des services que les lment de lautre composant ralisentNotation UML
*Relations entre les composantsContenance :Un composant peut tre contenu dans un autre composantNotation UMLComponent 1
*Systme Vente(diagramme de classes)utiliseLigne de vente-quantit : integer+setQuantit(In quantit:integer)Vente-Date : undefined-Heure : undefined+initierPaiement(In montant:real)Magasin+nom : string+adresse : stringPaiement-montant : real-mode : stringcontenu dans1..*11*enregistreest paye par111Catalogue+ObtenirSpec(In Item:undefined):SpcificationProduitSpcificationProduit-Description : string-Prix : real+getDescritption(In Item:undefined):string+getPrix(In Item:undefined):real11..**Contient
*Diagramme de composants(Exemple)Systme Vente
IHM_Caisier
CatalogueProduits
Enregistrement-Produits
InterfaceProduitInterfaceCatalogue
Gestion d'autorisationInterfaceAutorisation
GestionPaiementInterfacePaiement
JavaSwingGestion d'ImptsInterfaceImpts
*Diagramme de dploiementMontre la configuration des nuds de excution et des composants quy rsidentMontre les relations physiques entre les composants logiciels et matriels dun systmePermet de spcifierNuds Relations : (dpendance, associations)
*NudEst un lment physique qui existe pendant lexcution et reprsente une ressource informatique dans la plupart de cas il sagit dun lment matrielEn gnral un nud possde sa propre mmoire et une capacit de traitementLensemble de composants qui est associ aux nuds est appel unit de rpartitionLes nuds prennent en charge lexcution des composants.
*NudNom du nud :Permet de distinguer un nud des autres nudsLe nom peut tre compos du nom de paquetage qui contient le nudStrotypes : un nud peut possder un strotype qui permet de le distinguer des autres types de ressources (permettant de spcifier le types de ressources)
CPU : une unit de calcul memory : une unit de stockage device: un dispositif tel quun capteur
Nom du nud
*Relations entre nuds et composantsDpendance :Montre la capacit dun nud de supporter un composantPeut tre galement exprime entre les composants rsidant dans un mme nud Notation UML
*Relations entre deux nudsAssociationIndiquent une voie physique entre deux nudsExemple:Une connexion EthernetUn bus de communicationNotation UML
*Diagramme de dploiement(Exemple)Systme VenteServeur de CalculInterfaceAutorisationInterfaceImptsInterfacePaiement
Gestion d'autorisation
Enregistrement-Produits
GestionPaiementGestion d'ImptsVentes
IHM_Caisier
JavaSwingServeur de Donnes InterfaceCatalogue
CatalogueProduitsLAN11..*LAN11
*Diagramme de dploiement Base de DonnesTCP / IP11..*ServeurOrdonnanceur
Base de Donnes
*Diagramme de dploiement
*Correspondance UML et [email protected]
*Traduction dune classeLa classe est le concept fondamental de toute technologie objet. Le mot-cl correspondant existe bien sr galement en Java.De plus, chaque classe UML devient par dfaut un fichier .java.
*Traduction dune classeclass Personne{.}
*Traduction dune classeUne classe abstraite est simplement une classe qui ne sinstancie pas directement mais qui reprsente une pure abstraction afin de factoriser des proprits.Elle se note avec {abstract} en UML et se traduit par le mot-cl abstract en Java.
*Traduction dune classeabstract class Personne{...}
*Traduction dune classeUne interface est une classe spciale dont toutes les mthodes sont abstraitesUne interface se note en UML avec le symboleEn java, elle traduite par le mot cl interface
*Traduction dune classeinterface Forme {}
*Traduction des attributsLes attributs UML deviennent simplement des attributs en JavaLeur type est soit un type primitif (int, etc.), soit une classe.La visibilit des attributs est montre graphiquement en UML en les faisant prcder par + pour public, # pour protg (protected), - pour priv (private).Les attributs de classe en UML deviennent des membres statiques en Java (static).
*Traduction des oprationsLes oprations UML deviennent trs directement des mthodes en Java.Leur visibilit est dfinie graphiquement avec les mmes conventions que les attributs.Les oprations de classe deviennent des mthodes statiques (static).Les oprations abstraites (en italiques) se traduisent par le mot-cl abstract en Java.
*Traduction des oprationsclass Personne {private int code;private String nom;private static int nombre;public Personne() {}public static int getNombre(){}public String getInf(){}}
*Traduction des relationsLes relations UML entre concepts statiques sont trs riches. On peut distinguer les relations de :Gnralisation (hritage)RalisationAssociation, avec ses variantes : agrgation et composition.
*Traduction des relations(La gnralisation)Le concept UML de gnralisation se traduit directement par le mcanisme de lhritage dans les langages objets.Java, contrairement C++ interdit lhritage multiple entre classes.
*Traduction des relations (La gnralisation)Class Personne{}Class Employe extends Personne{}
*Traduction des relations(La ralisation )Une classe UML peut implmenter plusieurs interfaces.Contrairement C++, le langage Java propose directement ce mcanisme.
*Traduction des relations(Ralisation)interface A{}interface B{}class C implements A, B {}
*Traduction des relations(Les associations)Les associations navigables UML se traduisent par du code Java qui dpend de :la multiplicit de lextrmit concerne (pointe par la flche)mais aussi de lexistence ou pas dune contrainte {ordered} ou dun qualificatif. Nous allons voir tout cela du plus simple au plus complexe :Une association navigable avec une multiplicit 1Une association navigable avec une multiplicit *
*Traduction des relations (Les associations)Une association navigable avec une multiplicit 1 se traduit par une variable dinstance de type rfrence vers une instance de classe.Une multiplicit * va se traduire par un attribut de type collection de rfrences dobjets au lieu dune simple rfrence sur un objet.
*Traduction des relations (Les associations)La difficult consiste choisir la bonne collection parmi les trs nombreuses classes de base que propose Java.Bien quil soit possible de crer des tableaux dobjets, ce nest pas forcment la bonne solution.En pratique, on prfre plutt recourir des collections, parmi lesquelles les plus utilises sont : ArrayList, SortedList et HashTable.Utilisez ArrayList si vous devez respecter un ordre et rcuprer les objets partir dun indice entierUtilisez HashTable si vous souhaitez rcuprer les objets partir dune cl arbitraire.
*Traduction des relations (Les associations)
*Traduction des relations (Les associations)Une association bidirectionnelle se traduit simplement par une paire de rfrences, une dans chaque classe implique dans lassociation.Les noms des rles aux extrmits dune association servent nommer les variables de type rfrence.
*Traduction des relations (Les associations)
*Traduction des relations (Les associations)
*Traduction des relations(La classe association)Elle possde tout la fois les caractristiques dune association et dune classe et peut donc porter des attributs qui se valorisent pour chaque lien.Ce concept UML avanc nexiste pas dans les langages de programmation objet, il faut donc le traduire en le transformant en classe normale, et en ajoutant des variables de type rfrence.
*Traduction des relations (La classe association)
*[email protected]*UMLDe UML vers le modle relationnel
*[email protected]*De UML vers le modle relationnelCette partie traite le passage de la conception faite par UML vers le modle relationnelLa traduction concerneClasses, instances, attributsRelations entres classes : Associations,Agrgation,Composition,Gnralisation spcialisation
*[email protected]*Classe en RelationnelDans le cas gnral une classe est traduite par une tableChaque objet est conserv dans une ligne de la tableUn champ jouant le rle de cl primaire est ajout mme s'il n'existait pas dans la classe
*[email protected]*Traduction d'une classeEn RelationnelCompte(NCompte, Solde)En SQLCreate table Compte(NCompte smallint,Solde decimal,Primary key PK_Compte (NCompte))
*[email protected]*Gnralisation/spcialisation en RelationnelPlusieurs mthodes de traduction en Relationnel :Reprsenter toutes les classes dune arborescence dhritage par une seule table relationnelleReprsenter chaque classe par une table
*[email protected]*Gnralisation/spcialisation en RelationnelLa solution la plus simple est de modliser toute une hirarchie de classes dans une mme tableChaque classe ajoutant ses propres attributs comme de nouveaux champs. Il nous suffit alors dajouter un champ contenant le type de linstance pour pouvoir charger les champs correspondants.
*[email protected]*Gnralisation/spcialisation en Relationnel
*[email protected]*Associations en Relationnel(Association un--un)Deux solutions sont possibles :une cl trangre dans chacune des tables associes la fusion des deux tables dans une seule
*[email protected]*Associations en Relationnel(Association un--un)1re SolutionPays(IdPays, NomP,#IdCapitale)Capitales(IdCapitale, NomC, #IdPays)
2ime SolutionPays(IdPays, NomP, NomC)
*[email protected]*Associations en Relationnel(Association un--un)1re Solutioncreate table Pays(IdPays integer primary key,IdCapitale integer foreign key references capitales (IdCapitale))etcreate table Capitales(IdCapitale integer primary key,, IdPays integer foreign key refernces pays(IdPays))2ime SolutionPays(IdPays integer primary key,NomP varchar(20),NomC varchar(20))
*[email protected]*Associations en Relationnel(Association un--plusieurs)Une seule solution est possible : migration de la cl du ct de 1 vers la table du ct de plusieursLa cl migre jouera le rle de cl trangre
*[email protected]*Associations en Relationnel(Association un--plusieurs)En RelationnelDept(IdDept, Nomdept)Emp(IdEmp, NomEmp, #IdDept)En SQLCreate table dept()Create table emp(IdEmp integer primary key,NomEmp varchar(20),IdDept integer foreign key references Dept(IdDept))
*[email protected]*Associations en Relationnel(Association plusieurs--plusieurs)Lassociation est traduite par une table dont la cl primaire est la concatnation des cls primaires des tables associesLa table rsultante aura :Une seule cl primaireDeux cls trangres
*[email protected]*Traduction des associations en Relationnel(Association plusieurs--plusieurs)En RelationnelArticles(Ref, Des, PU)Commandes(NBC, DateC, Client)Dtails(#NBC, #Ref, Qt)
*[email protected]*Traduction des associations en Relationnel(Association plusieurs--plusieurs)En SQLcreate table Article(Ref integer primary key, )create table Cde(NBC integer primary key, )create table Detail(NBC integer, Ref integer,, constraint PK primary key(NBC, Ref),constraint FK1 foreign key(NBC) references cdes(NBC),Constraint FK1 foreign key(NBC) references cdes(NBC))
*OCL
*ContraintesUne contrainte est une condition ou une restriction smantique exprime sous forme dinstructions dans un langage textuel qui peut tre naturel ou formelElle doit tre applique lors de limplmentationReprsente sous forme dune chane place entre accolades({})
*ContraintesNous avons vu comment exprimer certaines contraintes avec UML{ordered}{subset}{frozen}{xor}
*Contraintes Exemple -Dans cet exemple, on exprime le fait quun solde doit rester toujours positif (utilisation dun langage formel).
*Contraintes Exemple -Dans cet exemple, on exprime un contrainte avec un langage textuel non formel
*IntroductionOCL est un langage de contraintes associ UMLIl peut tre utilis pour contraindre nimporte quel diagramme
*ContexteUne contrainte est toujours associe un lment du modleCet lment constitue le contexte de la contrainteDeux manires pour exprimer le contexte dune contrainte :En crivant la contrainte entre {} dans une note (voir exemple prcdent)En utilisant le mot cl context dans un document accompagnant le modle
*ContexteSyntaxecontext O : : peut tre une classe, un attribut, une opration, etc.Pour faire rfrence un lment dune classe, il faut utiliser les ::
*ContexteLe contexte de la classe Comptecontext CompteLe contexte de lopration getSolde() de la classe Comptecontext Compte::getSolde():RealLe contexte de lopration deposer() de la classe Comptecontext Compte::deposer(somme:Real)
*InvariantsUn invariant exprime une contraintes sur un objet ou un groupe dobjets qui doit tre respecte en permanenceSyntaxe :inv : Lexpression logique doit tre toujours vraie
*InvariantsExemple :Le solde dun compte doit tre toujours positif
context Compteinv : solde>0
*Prconditions et postconditionsUne prcondition permet de spcifier une condition qui doit tre vrifie avant lappel dune opration.Une postcondition permet de spcifier une condition qui doit tre vrifie aprs lappel dune opration.
*Prconditions et postconditionsDans lexpression de la contrainte de la postcondition, deux lments particuliers sont utiliss :result : la valeur retourne par lopration@pre : la valeur de lattribut avant lappel de lopration
*Prconditions et postconditionsSyntaxe de la prconditionpre :
Syntaxe de la postconditionpost :
*Prconditions et postconditionsExemples :context Compte::debiter(somme : Real)pre : somme>0post : solde=solde@pre-somme
context Compte::getSolde():Realpost : result=solde
*Rsultat dune oprationLexpression de contrainte body permet dfinir directement le rsultat dune oprationSyntaxe :body : : expression qui retourne le rsultat dont le type est compatible avec le type de retour de lopration
*Rsultat dune oprationExempleLa mthode getSolde() de la classe Compte retourne le solde actuel
context Compte::getSolde():Realbody : solde
*Dfinition des attributs et de mthodesMotivation : une sous expression peut tre utilise plusieurs fois dans une expressionDeux expressions de contraintes :let : permet de dclarer et dinitialiser un attribut qui peut tre utilis dans lexpression qui suit le mot cl indef : fait la mme chose que let.
*Dfinition des attributs et de mthodesSyntaxes :let = in
Lattribut dclar recevra le rsultat de la dans toute l
def : =
*Dfinition des attributs et de mthodesExemplescontext Personneinv : let argent=compte.solde->sum() in age>=18 implies argent>0context Personnedef : argent : Real = compte.solde->sum()context Personneinv : age>=18 implies argent>0
*Initialisation et volution des attributsLe type de contrainte init permet de prciser la valeur initiale dun attribut ou dune terminaison dassociationLa valeur dun attribut driv est dfinie par la contrainte derive.Syntaxes :init : derive :
*Initialisation et volution des attributsExempleQuand on cre une personne, la valeur initiale de lattribut mari est faux, et la personne ne possde pas demployeur.context Personne::mari:Booleaninit : falsecontext Personne::employeur:Set(Socit)init : set{}
*Initialisation et volution des attributsExempleLge dune personne est la diffrence entre la date courante et la date de naissance de la personne.context Personne::age:Integerderive : Date::current() date_de_naissance
*Types et opration OCLLe langage OCL possde un certain nombre de types prdfinis et doprations prdfinies sur ces types :BooleanIntegerRealString
*Types et opration OCL
TypeoprateursBooleanAnd, or, xor, not, implies, ifthenelseendifInteger+,-, *, /, abs(), Real+,-, *, /, abs(), floor(), StringConcat(), size(), substring(),
*Types et opration OCL
aba and ba or ba xor ba implies bVVVVFVVFFVVFFVFVVVFFFFFV
*Types et opration OCLIf
Then
Else
Endif
notVFFV
*CollectionsLe langage OCL manipule plusieurs collections :Set : collection non ordonne dlments uniquesorderedSet : collection ordonne dlments uniquesBag : collection non ordonne dlmentsSequence : collection ordonne dlments
*Collections
Collectionlments ordonneslments uniquesSetNonOuiOrderedSetOuiOuiBagNonNonSequenceOuiNon
*Quelques oprations sur les collections- Opration de base -La syntaxe : collection->operation()size() : nombre dlmentscount() : nombre doccurrencessum() : somme des lmentsisEmpty() : est videnotEmpty() : non videincludes(el) : appartenanceexcludes(el) : non appartenanceincludesAll(col) : inclusionexcludesAll(col) : exclusion
*Quelques oprations sur les collections- Filtrage -select(cond) : retient les lments qui vrifient la conditionreject(cond) : limine les lments qui vrifient la conditionany(cond) : retourne lun des lments qui vrifie la conditionforAll(cond) : true si tous les lments vrifient la conditionexists(cond) : true si au moins un lment vrifie la conditionisUnique(exp) : true si une et une seule valeur de la collection qui vrifie la condition
*Opration ensembliste- Set ou OrederedSet -union(ens) : union- : diffrence (ens1 ens2)including(el) : ajoute un lmentexcluding(el) : retire un lment
*Accs aux donnes de lobjet courantPour faire rfrence une donne (attribut ou opration) dun objet dsign par le contexte :Utiliser le nom de llmentFaire prcder le nom de llment du mot cl self
*Accs aux donnes de lobjet courantExempleDans le contexte de la classe Compte :Context CompteInv : solde > 0
Context Compte::debiter(somme : Real)Pre : somme > 0Post : self.solde = self.solde@pre - somme
*Navigation travers une associationPour faire rfrence un objet (ou un groupe dobjets) associ via une association, On utilise :Le nom de la classe associe en minusculeLe nom du rle ct de la classe associe
*Navigation travers une associationDans le contexte de la classe Personne, on fait rfrence la classe socit avec lune des deux mthodes :employeursocitDe mme pour accder ladresse de la socit :employeur.adressesocit.adresse
*Navigation travers une associationLutilisation du rle est indispensable si :Il existe plusieurs associations entre lobjet dsign par le contexte et lobjet auquel on dsire accderLassociation est rflexive
*Navigation travers une associationLe type du rsultat dpend de :la multiplicit de lobjet rfrenctype de lobjet rfrence proprement dit.Si lobjet rfrenc est T, alors le rsultat est de type :T, si la multiplicit est 0..1 ou 1..1Set(T), si la multiplicit est *OrderedSet(T), si la multiplicit est * avec {ordered}
*Navigation travers une associationExemple : Type du rsultat
*Navigation travers une association qualifieDans une association qualifie, on utilise les valeurs (les instances) des qualificatifs entre crochets ([])context Banqueinv : self.compte[8900].solde>0
*Navigation vers une classe associationDans le contexte de Socit, self.poste.salaire: salaire de tous les employsDans le contexte de Personne, self.mariage[epouse].date : dates de mariages des femmes
*Navigation depuis une classe associationcontext Posteinv : self.employe.age>21 (ou aussi, self.personne.age>21)
*Accs une mthode redfinieUne sous classe peut redfinir une mthode de sa classe mreLaccs la mthode de la classe parente est toujours possible et se fait par : oclAsType()
*Accs une mthode redfinieDans le contexte de B :Self.f() : accs f() de BSelf.oclAsType(f()) : accs la mthode de A
*
************************************Dans le cadre de la modlisation des SI, on distingue 2 approches :Approches fonctionnelles : entre 1690 et 1970, mettent laccs sur les traitements. Cette approche fait la distinction entre les donnes et les traitements (MCD et MCT dans Merise, par exemple)Approches objet : mettent laccs sur le concept de lobjet, chaque objet est caractris par des donnes et des traitements. La 1re gnration : 1980-dbut 1990.* la fin des annes 90, il yavait une prolifration des mthodes : 1984 1994, le nombre de mthodes OO a pass de 10 plus de 50 (guerre de mthodes).Chaque mthode met laccent sur un aspect diffrent (OMT est oriente vers lanalyse, OOD est plus oriente vers la conception, OOSE insiste sur la spcification des besoins). Dautre part, chaque mthode propose ses propres concepts et sa propre notation. ceci est la source dune grande confusion dune part, et la difficult de passage dune mthode une autre.
******UML propose de dcrire le systme laide de 9 (13) diagrammes. Chacun de ces diagrammes correspond :Soit la description dune partie du systmeSoit la description du systme selon un point de vue particulierDiagramme de cas dutilisation : destin reprsenter les besoins des utilisateurs par rapport au systme. Point de vue de lutilisateurDiagramme de classes : reprsente la partie statique du systme en intgrant dans chaque classe la partie ddie aux donnes et celles consacre aux traitements. Cest le diagramme pivot de la modlisation du systme.Diagramme objets : reprsente les instances des classes du diagramme de classes.Diagramme dtat/transitions : montre les diffrents tats par lesquels passe un objet en ractions aux vnements.Diagramme dactivits : donn une vision des enchanements des activits propres une opration ou un cas dutilisation.Digramme de squences : permet de dcrire les scnarios de chaque cas dutilisation en mettant laccent sur la chronologie des interactions entre objets. *Diagramme de collaboration : une autre reprsentation des scnarios des cas dutilisation qui met laccent sur les objets et les messages changs.Diagramme de composants : reprsente les diffrents constituants logiciel dun systme en terme de modules : fichiers source, librairies, excutables, etc.Diagramme de dploiement : montre la disposition physique des matriels qui composent le systme et la rpartition des composants sur ces matriels.***********************************Rponse
***
*Lagrgation est une association qui permet de reprsenter un lien de type ensemble comprenant des lments :Ensemble : agrgatlments : agrgs***La relation de composition est une agrgation dans laquelle il existe une contrainte de dure de vie entre la classe composant et la ou les classes composes*****************Question 1
Question 2*Question 1
Question 2********Un cas dutilisation permet de dcrire linteraction entre lacteur et le systme.La description de linteraction est ralise suivant le point de vue de lutilisateur.Les cas dutilisation constituent un moyen de recueillir et de dcrire les besoins des acteurs du systme.***************************************************************************************************
