Uml
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

Uml

  • 5,974 views
Uploaded on

cours uml avec des études de cas

cours uml avec des études de cas

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
5,974
On Slideshare
5,974
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
463
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. UML Unified Modeling LanguageRéalisé par : mohammed.zaoui11@gmail.com https://www.facebook.com/groups/ISP.2011/ Créé le : mercredi ‎ 1 ‎ ars ‎ 009 1 m 2
  • 2. UML : Introduction UML offre une manière élégante de représenter le systèmeselon différentes vues complémentaires grâce aux diagrammes.Lorsquune entreprise désire un logiciel, elle le réalise parfoisen interne, mais le fait plus généralement réaliser par unesociété de services. Dans un cas comme dans lautre il estnécessaire de définir lensemble des fonctionnalités que lelogiciel doit possèder. Le demandeur du logiciel na parfois pasde compétences particulières en informatique et exprime doncses souhaits sous forme dun CdCF (Cahier des ChargesFonctionnelles), cest-à-dire un document décrivant sous formetextuelle lensemble des particularités que le logiciel doitpossèder, les conditions quil doit remplir (système(s)dexploitation visé(s)), les écueils à éviter, ainsi que les délaisimpartis, éventuellement des clauses sur le coût, les langages àutiliser, ...
  • 3. UML : Introduction (suite) Le CdCF est ainsi distribué à différentes sociétés deservices (dans le cas dune sous-traitance) sous formedun appel doffre, auquel les sociétés vont répondrepar un coût, un délai, ...Lorsquune société obtient le marché et quelle décide(si elle a le choix) dopter pour un langage orientéobjet, il lui faut dans un premier temps créer unmodèle (cest là quintervient UML) à fin: • de présenter au client la façon de laquelle ellecompte développer le logiciel. • daccorder tous les acteurs du projet.
  • 4. UML : Historique
  • 5. UML : Caractéristiques UML (Unified Modeling Language, que lon peut traduire par "langage de modélisation unifié) est une notation permettant de modéliser un problème de façon standard. Ce langage est né de la fusion de plusieurs méthodes existant auparavant, et est devenu désormais la référence en terme de modélisation objet, à un tel point que sa connaissance est souvent nécessaire pour obtenir un poste de développeur objet. UML n‟est pas une méthode: UML est un langage qui permet de représenter des modèles, mais il ne définit pas le processus délaboration des modèles. Qualifier UML de "méthode objet" nest donc pas tout à fait approprié.
  • 6. UML : Caractéristiques (suite) UML est un support de communication: UML est avant tout un support de communication performant, qui facilite la représentation et la compréhension de solutions objet. UML est basé sur un méta-modèle: UML est un moyen dexprimer des modèles objet en faisant abstraction de leur implémentation, cest-à-dire que le modèle fourni par UML est valable pour nimporte quel langage de programmation. UML est un langage qui sappuie sur un méta-modèle, un modèle de plus haut niveau qui définit les éléments dUML (les concepts utilisables) et leur sémantique (leur signification et leur mode dutilisation).
  • 7. UML : Diagrammes (définition) Un diagramme UML est une représentation graphique, qui sintéresse à un aspect précis du modèle. Cest une perspective du modèle, pas "le modèle". Chaque type de diagramme UML possède une structure (les types des éléments de modélisation qui le composent sont prédéfinis). Un type de diagramme UML véhicule une sémantique précise (un type de diagramme offre toujours la même vue dun système). Combinés, les différents types de diagrammes UML offrent une vue complète des aspects statiques et dynamiques dun système. Par extension et abus de langage, un diagramme UML est aussi un modèle (un diagramme modélise un aspect du modèle global).
  • 8. UML : Diagrammes (types) Il existe 2 types de vues du système qui comportent chacune leurs propres diagrammes : - les vues statiques : o diagrammes de cas dutilisation o diagrammes dobjets o diagrammes de classes o diagrammes de composants o diagrammes de déploiement - les vues dynamiques : o diagrammes de collaboration o diagrammes de séquence o diagrammes détats-transitions o diagrammes dactivités
  • 9. UML : Unified Modeling Language Diagramme des cas d’utilisation
  • 10. Diagramme des cas d’utilisation: Définition Les cas d‟utilisation(use cases)permettent de structurer les besoins des utilisateurs et les objectifs correspondants dun système. Ils centrent lexpression des exigences du système sur ses utilisateurs : ils partent du principe que les objectifs du système sont tous motivés. Description de l‟interaction entre l‟utilisateur et le système Une fois identifiés et structurés, ces besoins : - définissent le contour du système à modéliser (ils précisent le but à atteindre), - permettent didentifier les fonctionnalités principales (critiques) du système.
  • 11. Diagramme des cas d’utilisation: Acteur L’acteur: Un acteur représente un rôle joué par une personne ou une chose qui interagit avec le système. (la même personne physique peut donc être représentée par plusieurs acteurs en fonction des rôles qu‟elle joue). un acteur n‟est pas nécessairement une personne physique : il peut être un service, une société, un système informatique … Il existe 4 catégories d‟acteurs : - les acteurs principaux : les personnes qui utilisent les fonctions principales du système - les acteurs secondaires : les personnes qui effectuent des tâches administratives ou de maintenance. - le matériel externe : les dispositifs matériels incontournables qui font partie du domaine de l‟application et qui doivent être utilisés. - les autres systèmes : les systèmes avec lesquels le système doit interagir.
  • 12. Diagramme des cas d’utilisation: Acteur (suite) Un acteur se représente par un petit bonhomme avec son nom (son rôle) inscrit au dessous. Il est également possible de représenter un acteur sous la forme d‟un classeur stéréotypé << actor >>
  • 13. Diagramme des cas d’utilisation: Le cas d’utilisation Le cas d’utilisation: Le cas d‟utilisation (ou use case) correspond à un objectif du système, motivé par un besoin d‟un ou plusieurs acteurs. Lensemble des use cases décrit les objectifs (le but) du système. Un cas d‟utilisation se représente par une ellipse contenant le nom (un verbe à l‟infinitif) et optionnellement, au dessous du nom un stéréotype . Dans le cas ou l‟on désire présenter les attributs ou les opérations du cas d‟utilisation,il est préférable de le représenter sous la forme d‟un classeur stéréotypé <<use case>>.Nous reviendrons sur les notions d‟attributs et d‟opérations lorsque nous traiterons les diagrammes de classes et d‟objets.
  • 14. Diagramme des cas d’utilisation: Exemples Exemple 1 Exemple 2
  • 15. Diagramme des cas d’utilisation: Exemples Exemple 3 Exemple 4
  • 16. Diagramme des cas d’utilisation: La relation Elle exprime l‟interaction existant entre un acteur et un cas d‟utilisation. Il existe 3 types de relations entre cas d‟utilisation : - la relation de généralisation - la relation d‟extension - la relation d‟inclusion1. La relation de généralisation: Dans une relation de généralisation entre 2 cas d‟utilisation, le cas d‟utilisation enfant est une spécialisation du cas d‟utilisation parent.
  • 17. Diagramme des cas d’utilisation: La relation (suite) NB : un acteur peut également participer à des relations de généralisation avec d‟autres acteurs. Les acteurs « enfant » seront alors capables de communiquer avec les mêmes cas d‟utilisation que les acteurs « parents ».
  • 18. Diagramme des cas d’utilisation: La relation (suite)2. La relation d’inclusion: Elle indique que le cas d‟utilisation source contient aussi le comportement décrit dans le cas d‟utilisation destination. Cette relation permet ainsi de décomposer des comportements et de définir des comportements partageables entre plusieurs cas d‟utilisation. Cette dépendance est symbolisée par le stéréotype <<include>> Pour réaliser l‟objectif <<virement», on utilise obligatoirement «identification ».
  • 19. Diagramme des cas d’utilisation: La relation (suite)3. La relation d’extension: Elle indique que le cas d‟utilisation source ajoute son comportement au cas d‟utilisation destination. L‟extension peut être soumise à condition. Le comportement ajouté est inséré au niveau d‟un point d‟extension défini dans le cas d‟utilisation destination. Cette relation permet de modéliser les variantes de comportement d‟un cas d‟utilisation (selon les interactions des acteurs et l‟environnement du système). Cette dépendance est symbolisée par le stéréotype <<extend>>
  • 20. Diagramme des cas d’utilisation: La relation (suite)Exemple :
  • 21. Diagramme des cas d’utilisation: Les scénarios Un cas d‟utilisation est une abstraction de plusieurs chemins d‟exécution. Une instance de cas d‟utilisation est appelée : « scénario ». Chaque fois qu‟une instance d‟un acteur déclenche un cas d‟utilisation, un scénario est créé (le cas d‟utilisation est instancié). Ce scénario suivra un chemin particulier dans le cas d‟utilisation. Les scénarios peuvent être classés en : - scénarios principaux : il correspond à l‟instance principal du cas d‟utilisation. C‟est souvent le chemin « normal » d‟exécution du cas d‟utilisation qui n‟implique pas d‟erreurs. - Scénarios secondaires : il peut être un cas alternatif (un choix), un cas exceptionnel ou une erreur.
  • 22. UML : Unified Modeling Language Diagramme de classes
  • 23. Diagramme de classes : Définition Le diagramme de classes exprime la structure statique du système en termes de classes et de relations entre ces classes. L‟intérêt du diagramme de classe est de modéliser les entités du système d‟information. CLASSE OBJETS Maison 234 Des érables $180 000 Adresse 1986 50 Laurier Valeur $150 000 Date construction 1959 765 Bellevue $210 000 1996 ...
  • 24. Diagramme de classes : La notion de classe une classe est une description abstraite (condensée) d‟un ensemble d‟objets du domaine de l‟application : elle définit leur structure, leur comportement et leurs relations. Représentée par un rectangle comprenant 3 compartiments: le nom, les attributs et les opérations. Les compartiments non pertinents peuvent ne pas être affichés Nom de classe Nom de classe Nom de classe Attribut 1 Attribut 1 Attribut 2 Attribut 2 Opération 1 Opération 2
  • 25. Diagramme de classes : Stéréotypes UML définit les stéréotypes de classe suivants : - « classe implémentation » : il s’agit de l’implémentation d’une classe dans un langage de programmation. - « énumération » : il s’agit d’une classe qui définit un ensemble d’identificateurs formant le domaine de la valeur. - « métaclasse » : il s’agit de la classe d’une classe, comme en Smalltalk. - « powertype » : une classe est un métatype : ses instances sont toutes des sous-types d’un type donné. - « processus » : il s’agit d’une classe active qui représente un flot de contrôles lourd. - « thread » : il s’agit d’une classe active qui représente un flot de contrôles léger. - « type » : il s’agit d’une classe qui définit un domaine d’objets et les opérations applicables à ces objets. - « utilitaire » : il s’agit d’une classe réduite au concept de module et qui ne peut être instanciée.
  • 26. Diagramme de Classes : La notion d’attribut  Une classe correspond à un concept global d‟information et se compose d‟un ensemble d‟informations élémentaires, appelées attributs de classe.  Un attribut représente la modélisation d‟une information élémentaire représentée par son nom et son format.  Caractéristique d‟une classe d‟objets.  Syntaxe: Visibilité Nom_attribut : Type_Attribut = Valeur_Initiale  Visibilité: définie en trois niveaux: + :public, visible par toutes les classes; # :protégé, visible par les classes amies et classes dérivées; - :privé, visible seulement par les classes amies;  Dérivé (/): attribut obtenu par le traitement d‟autres attributs. Rectangle + longueur : /Surface = longueur * largeur entier + largeur: entier
  • 27. Diagramme de Classes : La notion d’opération  L‟opération représente un élément de comportement des objets, défini de manière globale dans la classe.  Une opération est une fonctionnalité assurée par une classe. La description des opérations peut préciser les paramètres d‟entrée et de sortie ainsi que les actions élémentaires à exécuter.  Syntaxe: Visibilité Nom_Opération. La classe rectangle contient les Rectangle attributs longueur et largeur et + Longueur: entier l’opération surface qui + Largeur: entier encapsule le calcul de surface obtenu avec la longueur et la + Surface largeur du rectangle. (longeur:entier * largeur:entier) : entier
  • 28. Diagramme de Classes : Association  Représente des relations structurelles entre classes d‟objets.  Représentée par une forme verbale, active ou passive, en italique au milieu de la ligne qui symbolise l‟association.  Le sens de lecture du nom est indiqué par un petit triangle dirigé vers la classe désignée par la forme verbale.
  • 29.  Peut être représentée < habite par des traits est habitée par > Maison Personne rectilignes ou obliques. < possède est possédée par > Il peut y avoir deux ou plusieurs associations de nature différente entre les deux mêmes classes. < est mariée à est mariée à > Peut être récursive, i.e. qui affecte une Personne seule classe.
  • 30. Diagramme de Classes : Le rôle  Le rôle est l’extrémité d’une association qui décrit comment une classe en voit une autre à travers une association.  Il est placé à l’extrémité d’une association sans être en italique. < habite habitant Maison habitation est habitée par > Personne parent Personne enfant
  • 31. Diagramme de Classes : Classe-association  On ajoute une classe-association à une association lorsqu‟elle a des attributs ou des opérations.  Une classe de ce type est une classe comme les autres et peut participer à d‟autres relations dans le modèle.
  • 32. Diagramme de Classes : Association n-aire •Relations entre plus de 2 classes (à éviter si possible)
  • 33. Diagramme de Classes : La multiplicité des associations  La multiplicité définit le nombre d‟instances de l‟association pour une instance de la classe. La multiplicité est définie par un nombre entier ou un intervalle de valeurs. La multiplicité est notée sur le rôle (elle est notée à l‟envers de la notation MERISE).  Indique le nombre minimum et maximum d‟objets de la classe qui peuvent être liés à un objet de l‟autre classe.  Une association possède deux cardinalités.
  • 34. Exemple: Une personne travaille pour 0 à plusieurs sociétés (*) et une société est employeur de 1 à plusieurs personnes (1..*). Pour un emploi donné, un patron dirige de zéro à plusieurs travailleurs (0 ..*) et un travailleur est dirigé par zéro à un patron (0..1). Société < Travaille pour 1..* Personne * employeur employé Emploi patron Salaire 0..1 travailleur 0..* <Dirige
  • 35. Diagramme de Classes : Contraintes sur les associations  Peut affecter une relation ou un groupe de relations.  Chaîne de caractères entre accolades { } positionnée sur l‟association affectée ou entre les associations affectées.
  • 36. Diagramme de Classes : Agrégation Association non symétrique dans laquelle une des extrémités joue un rôle prédominant par rapport à l‟autre extrémité (agrégat). Les deux classes existent indépendamment, c‟est-à-dire qu‟elles “survivent” à la “destruction” de l‟autre classe. Ne concerne qu‟un seul rôle de l‟association. Symbolisé par un losange vide du côté de l‟agrégat. Symbole d’agrégation
  • 37. Diagramme de Classes : Composition La composition est un cas particulier de l‟agrégation dans laquelle la vie des composants est liée à celle des agrégats. Association symétrique entre deux classes dont une classe (partie) compose l‟autre (composite). Les deux classes sont dépendantes, c‟est-à-dire que la partie “ne survit pas” à la “destruction” du composite. Symbolisée par un losange plein du coté du composite. Symbole de composition
  • 38. Diagramme de Classes : Agrégation/CompositionExemple 1: < fait partie de 1,1 < compose de 0,N Livre Page Mot comprend de 1,N > comprend de 1,N >Exemple 2:
  • 39. Diagramme de Classes : Généralisation/Spécialisation Le principe de généralisation / spécialisation permet d‟identifier parmi les objets d‟une classe (générique) des sous-ensembles d‟objets (des classes spécialisées) ayant des définitions spécifiques. La classe plus spécifique (appelée aussi classe fille, classe dérivée, classe spécialisée, classe descendante …) est cohérente avec la classe plus générale (appelée aussi classe mère, classe générale …), c‟est-à-dire qu‟elle contient par héritage tous les attributs, les membres, les relations de la classe générale, et peut contenir d‟autres. - La généralisation : il s‟agit de prendre des classes existantes déjà mises en évidences) et de créer de nouvelles classes qui regroupent leurs parties communes ; il faut aller du plus spécifique au plus général. - La spécialisation : il s‟agit de sélectionner des classes existantes (déjà identifiées) et d‟en dériver des nouvelles classes plus spécialisées, en spécifiant simplement les différences.
  • 40. Diagramme de Classes : Généralisation multiple Les classes peuvent avoir plusieurs superclasses ; dans ce cas, la généralisation est dite multiple et plusieurs flèches partent de la sous-classe vers les différentes superclasses. La généralisation multiple consiste à fusionner plusieurs classes en une seule classe.
  • 41. Diagramme de Classes : Contraintes de généralisation
  • 42. Diagramme de Classes : Contraintes de généralisation
  • 43. Diagramme de Classes : Classe abstraite  Classe sans instance immédiate  Super-classe non instanciable directement, i.e. qui ne donne pas naissance à des objets mais sert de concept plus général pour les sous-classes.  Elle s‟applique uniquement pour la généralisation et jamais pour la spécialisation.
  • 44. Diagramme de Classes : Dépendance Les relations de dépendance sont utilisées lorsqu‟il existe une relation sémantique entre plusieurs éléments qui n‟est pas de nature structurelle. Une relation de dépendance définit une relation unidirectionnelle entre un élément source et un élément cible. Une dépendance est une relation entre deux éléments de modélisation dans laquelle toute modification effectuée sur un élément de modélisation (lélément influent) affecte lautre élément (élément dépendant). UML définit 4 types de relation de dépendance. Pour chaque type de dépendance, un mot clé ou stéréotype entre guillemets peut être ajouté à la relation de dépendance pour préciser sa nature.
  • 45. Diagramme de Classes : Dépendance (suite) Les 4 types de relation sont :  Abstraction :Il s‟agit d‟une relation de dépendance entre éléments qui représentent un même concept à différents niveaux d‟abstraction ou selon des points de vue distincts.  Les mots-clés sont : o « « dérive » » : représente un élément défini ou calculé à partir d‟un autre. Par exemple, un attribut ou un rôle peut dériver d‟autres attributs ou rôles. o « « raffine » » : représente une relation de dépendance entre des éléments sémantiques différents (analyse et conception par exemple). o « « réalise » » : représente une relation de dépendance entre une spécification (cible) et l‟élément qui implémente cette spécification (source). o « « trace » » : représente l‟historique des constructions présentes dans les différents modèles.  Liaison : Les paramètres formels d‟une classe ou collaboration paramétrables doivent être liés à des valeurs.  Le mot clé est : o « « lie » »
  • 46. Diagramme de Classes : Dépendance (suite) Permission: Un élément (source) a le droit d‟accéder à un espace de nommage (cible)o « « ami » »: Représente un élément source (paquetage, classe, opération …) qui a accès à l‟élément destination (paquetage, classe, opération …) quelle que soit la spécification de visibilité de ce dernier. Utilisation: Un élément (source) requiert la présence d‟un autre élément (cible) pour son bon fonctionnement ou son implémentation.o « « utilise » »o « « appelle » » Représente une relation de dépendance entre une opération qui invoque une opération d‟une autre classe. Cette relation est représentée en connectant les opérations ou les classes qui possèdent ces opérations.o « « crée » »: Représente le classificateur source qui crée une instance du classificateur cible.o « « instancie » »: Représente une relation de dépendance entre classificateurs due à la création d‟une instance du classificateur cible par une opération du classificateur source. Exemple
  • 47. Diagramme de Classes : L’interface Une interface définit le comportement visible d‟une classe. Ce comportement est défini par une liste d‟opérations ayant une visibilité « public ». Aucun attribut ou association n‟est défini pour une interface. Une interface est en fait une classe particulière (avec le stéréotype « « interface » »). UML représente les interfaces : - soit au moyen de petits cercles reliés par un trait à l‟élément qui fournit les services décrits par l‟interface - soit au moyen de classes avec le mot clé « « interface » ». Cette notation permet de faire figurer dans le compartiment des opérations la liste des services de l‟interface. L’exemple illustre la modélisation de 2 interfaces crédit et assurance d’une classe banque. Une relation de réalisation indique que la classe banque réalise l’interface assurance.
  • 48. Diagramme de Classes : Package  Mécanisme général pour la partition des modèles et le regroupement des éléments de modélisation  Est représenté graphiquement Nom du par un dossier package  Correspond à un sous-ensemble du modèle
  • 49. Diagramme de Classes : Package (suite) Peut contenir entre autre des classes, des objets, des relations et d‟autres paquetages, sans limite du niveau d‟emboîtement. Les relations possibles entre paquetages sont les dépendances et les généralisations. Paquetage racine Classe Dépendance Généralisation Sous-paquetage
  • 50. Diagramme de Classes : Package (suite)  Une classe contenue par un paquetage peut également apparaître dans un autre paquetage sous la forme d‟un élément importé. Cela crée une relation de dépendance indiquée par le sens de la flèche. Limites Administratives Socio-économique <<import>> Ville LA::Ville classe importée
  • 51. Diagramme de classes : Étude de cas
  • 52. Diagramme de classes : Étude de casSoit le cas ’’Réservation de vols dans une agence de voyage’’
  • 53. Diagramme de classes : Étude de casSoit le cas ’’Réservation de vols dans une agence de voyage’’1° Des compagnies aériennes proposent différents vols.
  • 54. Diagramme de classes : Étude de casSoit le cas ’’Réservation de vols dans une agence de voyage’’1° Des compagnies aériennes proposent différents vols.2° Un vol est ouvert à la réservation et fermé sur ordre de la compagnie.
  • 55. Diagramme de classes : Étude de casSoit le cas ’’Réservation de vols dans une agence de voyage’’1° Des compagnies aériennes proposent différents vols.2° Un vol est ouvert à la réservation et fermé sur ordre de la compagnie.3° Un client peut réserver un ou plusieurs vols, pour des passagers différents.
  • 56. Diagramme de classes : Étude de casSoit le cas ’’Réservation de vols dans une agence de voyage’’1° Des compagnies aériennes proposent différents vols.2° Un vol est ouvert à la réservation et fermé sur ordre de la compagnie.3° Un client peut réserver un ou plusieurs vols, pour des passagers différents.4° Une réservation concerne un seul vol, et un seul passager.
  • 57. Diagramme de classes : Étude de casSoit le cas ’’Réservation de vols dans une agence de voyage’’1° Des compagnies aériennes proposent différents vols.2° Un vol est ouvert à la réservation et fermé sur ordre de la compagnie.3° Un client peut réserver un ou plusieurs vols, pour des passagers différents.4° Une réservation concerne un seul vol, et un seul passager.5° Une réservation peut être annulée ou confirmée.
  • 58. Diagramme de classes : Étude de casSoit le cas ’’Réservation de vols dans une agence de voyage’’1° Des compagnies aériennes proposent différents vols.2° Un vol est ouvert à la réservation et fermé sur ordre de la compagnie.3° Un client peut réserver un ou plusieurs vols, pour des passagers différents.4° Une réservation concerne un seul vol, et un seul passager.5° Une réservation peut être annulée ou confirmée.6° Un‎vol‎a‎un‎aéroport‎de‎départ‎et‎un‎aéroport‎d’arrivée.
  • 59. Diagramme de classes : Étude de casSoit le cas ’’Réservation de vols dans une agence de voyage’’1° Des compagnies aériennes proposent différents vols.2° Un vol est ouvert à la réservation et fermé sur ordre de la compagnie.3° Un client peut réserver un ou plusieurs vols, pour des passagers différents.4° Une réservation concerne un seul vol, et un seul passager.5° Une réservation peut être annulée ou confirmée.6° Un‎vol‎a‎un‎aéroport‎de‎départ‎et‎un‎aéroport‎d’arrivée.7° Un‎vol‎a‎un‎jour‎et‎une‎heure‎de‎départ‎et‎un‎jour‎et‎une‎heure‎d’arrivée.
  • 60. Diagramme de classes : Étude de casSoit le cas ’’Réservation de vols dans une agence de voyage’’1° Des compagnies aériennes proposent différents vols.2° Un vol est ouvert à la réservation et fermé sur ordre de la compagnie.3° Un client peut réserver un ou plusieurs vols, pour des passagers différents.4° Une réservation concerne un seul vol, et un seul passager.5° Une réservation peut être annulée ou confirmée.6° Un‎vol‎a‎un‎aéroport‎de‎départ‎et‎un‎aéroport‎d’arrivée.7° Un‎vol‎a‎un‎jour‎et‎une‎heure‎de‎départ‎et‎un‎jour‎et‎une‎heure‎d’arrivée.8° Un vol peut comporter des escales dans des aéroports.
  • 61. Diagramme de classes : Étude de casSoit le cas ’’Réservation de vols dans une agence de voyage’’1° Des compagnies aériennes proposent différents vols.2° Un vol est ouvert à la réservation et fermé sur ordre de la compagnie.3° Un client peut réserver un ou plusieurs vols, pour des passagers différents.4° Une réservation concerne un seul vol, et un seul passager.5° Une réservation peut être annulée ou confirmée.6° Un‎vol‎a‎un‎aéroport‎de‎départ‎et‎un‎aéroport‎d’arrivée.7° Un‎vol‎a‎un‎jour‎et‎une‎heure‎de‎départ‎et‎un‎jour‎et‎une‎heure‎d’arrivée.8° Un vol peut comporter des escales dans des aéroports.9° Une‎escale‎a‎une‎heure‎d’arrivée‎et‎une‎heure‎de‎départ.
  • 62. Diagramme de classes : Étude de casSoit le cas ’’Réservation de vols dans une agence de voyage’’1° Des compagnies aériennes proposent différents vols.2° Un vol est ouvert à la réservation et fermé sur ordre de la compagnie.3° Un client peut réserver un ou plusieurs vols, pour des passagers différents.4° Une réservation concerne un seul vol, et un seul passager.5° Une réservation peut être annulée ou confirmée.6° Un‎vol‎a‎un‎aéroport‎de‎départ‎et‎un‎aéroport‎d’arrivée.7° Un‎vol‎a‎un‎jour‎et‎une‎heure‎de‎départ‎et‎un‎jour‎et‎une‎heure‎d’arrivée.8° Un vol peut comporter des escales dans des aéroports.9° Une‎escale‎a‎une‎heure‎d’arrivée‎et‎une‎heure‎de‎départ.10° Chaque aéroport dessert une ou plusieurs villes.
  • 63.  Modélisation de la phrase : 1° Des compagnies aériennes proposent différents vols.
  • 64.  Modélisation de la phrase : 1° Des compagnies aériennes proposent différents vols. CompagnieAerienne et Vols sont 2 objets métiers : 2 classes
  • 65.  Modélisation de la phrase : 1° Des compagnies aériennes proposent différents vols. CompagnieAerienne et Vols sont 2 objets métiers : 2 classes CompagnieAerinne Propose Vol 1..*
  • 66.  Modélisation de la phrase : 1° Des compagnies aériennes proposent différents vols. CompagnieAerienne et Vols sont 2 objets métiers : 2 classes CompagnieAerinne Propose Vol 1..*• Un vol est réalisé par une seule compagnie mais partagé par plusieurs affréteurs
  • 67.  Modélisation de la phrase : 1° Des compagnies aériennes proposent différents vols. CompagnieAerienne et Vols sont 2 objets métiers : 2 classes CompagnieAerinne Propose Vol 1..*• Un vol est réalisé par une seule compagnie mais partagé par plusieurs affréteurs CompagnieAerinne Propose Vol 1..* 1..* affréteur
  • 68.  Modélisation de la phrase : 2° Un vol est ouvert à la réservation et fermé sur ordre de la compagnie.
  • 69.  Modélisation de la phrase : 2° Un vol est ouvert à la réservation et fermé sur ordre de la compagnie. CompagnieAerinne Propose Vol 1..* 1..* état (ouvert, fermé) affréteur
  • 70.  Modélisation de la phrase : 2° Un vol est ouvert à la réservation et fermé sur ordre de la compagnie. CompagnieAerinne Propose Vol 1..* 1..* état (ouvert, fermé) affréteur Tout objet peut avoir un état (diagramme d‟états). Dans un diagramme de classes tout concept dynamique est modélisé en opération. Il faut représenter la 2° phrase par 2 opérations : ouvrirReservation( ) et fermerReservation( ) Dans quelle classe ? Responsabilité d‟une classe
  • 71.  Modélisation de la phrase : 2° Un vol est ouvert à la réservation et fermé sur ordre de la compagnie. CompagnieAerinne Propose Vol 1..* 1..* état (ouvert, fermé) affréteur Tout objet peut avoir un état (diagramme d‟états). Dans un diagramme de classes tout concept dynamique est modélisé en opération. Il faut représenter la 2° phrase par 2 opérations : ouvrirReservation( ) et fermerReservation( ) Dans quelle classe ? Responsabilité d‟une classe CompagnieAerinne Propose Vol 1..* 1..* affréteur ouvrirVol( ) fermerVol( )
  • 72.  Modélisation de la phrase : 2° Un vol est ouvert à la réservation et fermé sur ordre de la compagnie. CompagnieAerinne Propose Vol 1..* 1..* état (ouvert, fermé) affréteur Tout objet peut avoir un état (diagramme d‟états). Dans un diagramme de classes tout concept dynamique est modélisé en opération. Il faut représenter la 2° phrase par 2 opérations : ouvrirReservation( ) et fermerReservation( ) Dans quelle classe ? Responsabilité d‟une classe CompagnieAerinne Propose Vol 1..* 1..* affréteur ouvrirVol( ) fermerVol( )  Les opérations sont déclarées dans l‟objet dans lequel elles doivent s‟exécuter  Les autres pourront déclencher ces opérations par envoi de messages  Le classe CompagnieAerienne a une association avec la classe vol.
  • 73.  Modélisation des phrases : 3° Un client peut réserver un ou plusieurs vols, pour des passagers différents. Réservation Client 1 a effectué 0..* concerne Vol Annuler( ) 0..* 1 Confirmer( ) 0..* concerne 1 Passager
  • 74.  Modélisation des phrases : 3° Un client peut réserver un ou plusieurs vols, pour des passagers différents. Il faut discerner un client d‟un passager Réservation Client 1 a effectué 0..* concerne Vol Annuler( ) 0..* 1 Confirmer( ) 0..* concerne 1 Passager
  • 75.  Modélisation des phrases : 4° Une réservation concerne un seul vol, et un seul passager. 5° Une réservation peut être annulée ou confirmée.
  • 76.  Modélisation des phrases : 4° Une réservation concerne un seul vol, et un seul passager. 5° Une réservation peut être annulée ou confirmée. La réservation et le passager sont 2 concepts métier : 2 classes d‟objets Un réservation concerne un seul vol et un seul passager: donc 2 associations entre „‟Vol’’ et ‟‟Réservation’’ et entre ’’Réservation’’ et „‟Passager’’. La 5° phrase se traduit par l‟ajout de 2 opérations annuler( ) et confirmer( ) dans ‘’Reservation’’.
  • 77.  Modélisation des phrases : 4° Une réservation concerne un seul vol, et un seul passager. 5° Une réservation peut être annulée ou confirmée. La réservation et le passager sont 2 concepts métier : 2 classes d‟objets Un réservation concerne un seul vol et un seul passager: donc 2 associations entre „‟Vol’’ et ‟‟Réservation’’ et entre ’’Réservation’’ et „‟Passager’’. La 5° phrase se traduit par l‟ajout de 2 opérations annuler( ) et confirmer( ) dans ‘’Reservation’’. Réservation Vol concerne dateDepart heureDepart Annuler( ) 1 dateArrivee Confirmer( ) heureArrivee ouvrirVol( ) fermerVol( ) concerne 1 Passager
  • 78.  Modélisation des phrases : 6° Un vol a un aéroport de départ et un aéroport d’arrivée.
  • 79.  Modélisation des phrases : 6° Un vol a un aéroport de départ et un aéroport d’arrivée. Par quoi peut-on représenter l‟élément „‟Aéroport‟‟ ?3 réponses sont envisageables :
  • 80.  Modélisation des phrases : 6° Un vol a un aéroport de départ et un aéroport d’arrivée. Par quoi peut-on représenter l‟élément „‟Aéroport‟‟ ?3 réponses sont envisageables : 1. Soit avec une classe et une association de multiplicité 2
  • 81.  Modélisation des phrases : 6° Un vol a un aéroport de départ et un aéroport d’arrivée. Par quoi peut-on représenter l‟élément „‟Aéroport‟‟ ?3 réponses sont envisageables : 1. Soit avec une classe et une association de multiplicité 2 Vol dateDepart Aéroport heureDepart 2 dateArrivee nom { ordered} heureArrivee aeroportDepart aeroportArivvee ouvrirVol( ) fermerVol( )  Modélisation peu parlante.
  • 82.  Modélisation des phrases : 6° Un vol a un aéroport de départ et un aéroport d’arrivée.
  • 83.  Modélisation des phrases : 6° Un vol a un aéroport de départ et un aéroport d’arrivée. 2. Soit avec 2 classes
  • 84.  Modélisation des phrases : 6° Un vol a un aéroport de départ et un aéroport d’arrivée. 2. Soit avec 2 classes Vols dateDepart 1 AeroportDepart heureDepart dateArrivee Aéroport heureArrivee nom aeroportDepartr 1 aeroportArivvee AeroportArrivee ouvrirReservation( ) fermerReservation( )  Modélisation non correcte. Tout aéroport peut être de départ et d‟arrivée.
  • 85.  Modélisation des phrases : 6° Un vol a un aéroport de départ et un aéroport d’arrivée.
  • 86.  Modélisation des phrases : 6° Un vol a un aéroport de départ et un aéroport d’arrivée. 2. Soit avec 2 associations
  • 87.  Modélisation des phrases : 6° Un vol a un aéroport de départ et un aéroport d’arrivée. 2. Soit avec 2 associations Vol dateDepart Départ Aéroport heureDepart dateArrivee 1 Nom heureArrivee … Arrivée 1 ouvrirVol( ) fermerVol( )  Le rôle de chaque association précise son sens.
  • 88.  Modélisation des phrases : 7° Un vol a un jour et une heure de départ et un jour et une heure d’arrivée.
  • 89.  Modélisation des phrases : 7° Un vol a un jour et une heure de départ et un jour et une heure d’arrivée. Les dates et les heures de départ et d‟arrivée ne représentent que des valeurs : attributs.
  • 90.  Modélisation des phrases : 7° Un vol a un jour et une heure de départ et un jour et une heure d’arrivée. Les dates et les heures de départ et d‟arrivée ne représentent que des valeurs : attributs. CompagnieAerinne Propose Vol 1..* 1..* dateDepart affréteur heureDepart dateArrivee heureArrivee ouvrirVol( ) fermerVol( )
  • 91.  Modélisation des phrases : 7° Un vol a un jour et une heure de départ et un jour et une heure d’arrivée. Les dates et les heures de départ et d‟arrivée ne représentent que des valeurs : attributs. CompagnieAerinne Propose Vol 1..* 1..* dateDepart affréteur heureDepart dateArrivee heureArrivee ouvrirVol( ) fermerVol( ) Pour savoir si un élément doit être représenté en attribut ou en objet : S‟il n‟ y a que sa valeur qui est intéressante : c‟est plutôt un attribut. Si plusieurs questions peuvent concerner l‟élément, alors il faut le représenter en objet.
  • 92.  Modélisation des phrases : 8° Un vol peut comporter des escales dans des aéroports. 9° Une escale a une heure d’arrivée et une heure de départ.
  • 93.  Modélisation des phrases : 8° Un vol peut comporter des escales dans des aéroports. 9° Une escale a une heure d’arrivée et une heure de départ.  Une escale a les propriétés heure d‟arrivée et heure de départ, c‟est donc un objet.
  • 94.  Modélisation des phrases : 8° Un vol peut comporter des escales dans des aéroports. 9° Une escale a une heure d’arrivée et une heure de départ.  Une escale a les propriétés heure d‟arrivée et heure de départ, c‟est donc un objet. Vol dateDepart Depart Aéroport heureDepart dateArrivee 1 nom heureArrivee Arrivee ouvrirVol( ) fermerVol( ) 1 Escale heureArrivee heureDepart 0..*
  • 95.  Modélisation des phrases : 8° Un vol peut comporter des escales dans des aéroports. 9° Une escale a une heure d’arrivée et une heure de départ.  Une escale a les propriétés heure d‟arrivée et heure de départ, c‟est donc un objet. Vol dateDepart Depart Aéroport heureDepart dateArrivee 1 nom heureArrivee Arrivee ouvrirVol( ) fermerVol( ) 1 Quelles sont alors les multiplicités entre Escale „’Vols’’ et „’Escale’’, entre „’Escale’’ et heureArrivee ‘’Aeroport’’ et entre ‘’Aeroport’’ et ’Vols’’ ? heureDepart 0..*
  • 96.  Modélisation des phrases : 8° Un vol peut comporter des escales dans des aéroports. 9° Une escale a une heure d’arrivée et une heure de départ.  Une escale a les propriétés heure d‟arrivée et heure de départ, c‟est donc un objet. Vol dateDepart Depart Aéroport heureDepart dateArrivee 0..* 1 nom heureArrivee Arrivee ouvrirVol( ) fermerVol( ) 0..* 1 1 1..* Quelles sont alors les multiplicités entre Escale „’Vols’’ et „’Escale’’, entre „’Escale’’ et heureArrivee ‘’Aeroport’’ et entre ‘’Aeroport’’ et ’Vols’’ ? heureDepart 0..* 0..*
  • 97.  Modélisation des phrases : 8° Un vol peut comporter des escales dans des aéroports. 9° Une escale a une heure d’arrivée et une heure de départ.
  • 98.  Modélisation des phrases : 8° Un vol peut comporter des escales dans des aéroports. 9° Une escale a une heure d’arrivée et une heure de départ. „’Escale’’ a peu d‟informations propres. Elle n‟est qu‟une partie de ’’Vol’’ .
  • 99.  Modélisation des phrases : 8° Un vol peut comporter des escales dans des aéroports. 9° Une escale a une heure d’arrivée et une heure de départ. „’Escale’’ a peu d‟informations propres. Elle n‟est qu‟une partie de ’’Vol’’ . On peut la représenter comme une spécialisation de ’’Aéroport’’ . Mais elle n‟est pas totalement un aéroport.
  • 100.  Modélisation des phrases : 8° Un vol peut comporter des escales dans des aéroports. 9° Une escale a une heure d’arrivée et une heure de départ. „’Escale’’ a peu d‟informations propres. Elle n‟est qu‟une partie de ’’Vol’’ . On peut la représenter comme une spécialisation de ’’Aéroport’’ . Mais elle n‟est pas totalement un aéroport. La meilleure solution serait de la modéliser comme une classe d‟association entre et ’Vols’’ et ‘’Aéroport’’.
  • 101.  Modélisation des phrases : 8° Un vol peut comporter des escales dans des aéroports. 9° Une escale a une heure d’arrivée et une heure de départ. „’Escale’’ a peu d‟informations propres. Elle n‟est qu‟une partie de ’’Vol’’ . On peut la représenter comme une spécialisation de ’’Aéroport’’ . Mais elle n‟est pas totalement un aéroport. La meilleure solution serait de la modéliser comme une classe d‟association entre et ’Vols’’ et ‘’Aéroport’’. Vol Départ dateDepart Aéroport heureDepart 0..* 1 dateArrivee Arrivée nom heureArrivee 0..* 1 ouvrirVol( ) fermerVol( ) Escale 0..* 0..* {Ordered} Escale heureArrivee heureDepart
  • 102.  Modélisation des phrases : 10° Chaque aéroport dessert une ou plusieurs villes.
  • 103.  Modélisation des phrases : 10° Chaque aéroport dessert une ou plusieurs villes.  On ne peut pas savoir la multiplicité de „’Aéroport’’
  • 104.  Modélisation des phrases : 10° Chaque aéroport dessert une ou plusieurs villes.  On ne peut pas savoir la multiplicité de „’Aéroport’’ Aéroport dessert Ville 1..*
  • 105.  Modélisation des phrases : 10° Chaque aéroport dessert une ou plusieurs villes.  On ne peut pas savoir la multiplicité de „’Aéroport’’ Aéroport dessert Ville 0..* 1..*
  • 106.  Modélisation des phrases : 10° Chaque aéroport dessert une ou plusieurs villes.  On ne peut pas savoir la multiplicité de „’Aéroport’’ Aéroport dessert Ville 0..* 1..*  Si on considère que desservir une ville signifie l‟aéroport le plus proche, il n‟ en y a qu‟un : la multiplicité est de 1  Si on considère que desservir une ville signifie les aéroports dans un rayon de 35 km : la multiplicité est de 0..*
  • 107. Client nom Prénom CompagnieAerinne adresse nom téléphone e-mail 1..* Propose 1 a effectué 0..* 1..* départ Réservation Vol Aéroport dateDepart 0..* 1 date concerne heureDepart nom arrivée numéro dateArrivee 0..* 1Annuler( ) heureArrivee 0..* 1Confirmer( ) ouvrirVol( ) escale 0..* fermerVol( ) 0..* 0..* concerne {ordered} 1 InfosEscale Passager heureArrivee Ville heureDepart nomnom Prénom
  • 108.  Le diagramme des classe complet est : Client nom Prénom CompagnieAerinne adresse nom téléphone e-mail 1..* Propose 1 a effectué 0..* 1..* départ Réservation Vol Aéroport dateDepart 0..* 1 date concerne heureDepart nom arrivée numéro dateArrivee 0..* 1 Annuler( ) heureArrivee 0..* 1 Confirmer( ) ouvrirVol( ) escale 0..* fermerVol( ) 0..* 0..* concerne {ordered} 1 InfosEscale Passager heureArrivee Ville heureDepart nom nom Prénom
  • 109. Client nom Prénom CompagnieAerinne adresse nom tél e-mail numéro 1..*{frozen} 1 Propose a effectué 0..* 0..1 départ Réservation Vol Aéroport dateDepart 0..* 1 date concerne heureDepart nom arrivée numéro dateArrivee 0..* 1 heureArrivee 0..* 1 Annuler( ) {frozen} Confirmer( ) ouvrirVol( ) escale 0..* fermerVol( ) 0..* 0..* concerne {ordered} 1 InfosEscale Passager heureArrivee Ville heureDepart nom nom Prénom
  • 110.  Diagramme des classe complet et annoté: Client nom Prénom CompagnieAerinne adresse nom tél e-mail numéro 1..* {frozen} 1 Propose a effectué 0..* 0..1 départ Réservation Vol Aéroport dateDepart 0..* 1 date concerne heureDepart nom arrivée numéro dateArrivee 0..* 1 heureArrivee 0..* 1 Annuler( ) {frozen} Confirmer( ) ouvrirVol( ) escale 0..* fermerVol( ) 0..* 0..* concerne {ordered} 1 InfosEscale Passager heureArrivee Ville heureDepart nom nom Prénom
  • 111. Client CompagnieAérienne nom Prénom 1..* nom adresse Affréteur téléphone e-mail numéro 1{frozen} 1 propose Propose a effectué 0..1 0..* ‘’ métaclasse ‘’ départ VolGenerique Aéroport Réservation 0..* jour 0..* 1 date concerne heureDépart arrivée nom Vol heureArrivée numéro 0..* 1 dateDépart /durée 0..* 1 périodevalidité Annuler( ) {frozen} dateArrivée escale Confirmer( ) ouvrirVol( ) ouvrirVol( ) fermerVol( ) 0..* 0..* 0..* fermerVol( ) {ordered} concerne {AddOnly} 0..* {frozen} 1 1 InfosEscale Passager décrit heureArrivée Ville heureDépart nom nom Prénom
  • 112.  Le diagramme des classe complet devient : Client CompagnieAérienne nom Prénom 1..* nom adresse Affréteur téléphone e-mail numéro 1 {frozen} 1 propose Propose a effectué 0..1 0..* ‘’ métaclasse ‘’ départ VolGenerique Aéroport Réservation 0..* jour 0..* 1 date concerne heureDépart arrivée nom Vol heureArrivée numéro 0..* 1 dateDépart /durée 0..* 1 périodevalidité Annuler( ) {frozen} dateArrivée escale Confirmer( ) ouvrirVol( ) ouvrirVol( ) fermerVol( ) 0..* 0..* 0..* fermerVol( ) {ordered} concerne {AddOnly} 0..* {frozen} 1 1 InfosEscale Passager décrit heureArrivée Ville heureDépart nom nom Prénom
  • 113.  Le diagramme des classes peut être réorganisé en packages:
  • 114.  Le diagramme des classes peut être réorganisé en packages: Client nom Prénom CompagnieAerinne 1..* nom adresse Affréteur tééphonel e-mail numéro 1..* {frozen} 1 propose Propose a effectué 0..1 0..* ‘’ metaclasse „‟ départ VolGenerique Aéroport Réservation 0..* jour 0..* 1 date concerne heureDepart arrivée nom Vol heureArrivee numero 0..* 1 dateDepart /durée 0..* 1 periodevalidite Annuler( ) {frozen} dateArrivee escale Confirmer( ) ouvrirVol( ) ouvrirVol( ) fermerVol( ) 0..* 0..* 0..* fermerVol( ) {ordered} concerne {AddOnly} 0..* {frozen} 1 InfosEscale 1 décrit heureArrivee Ville Passager heureDepart nom nom Prénom
  • 115.  Le diagramme des classes peut être réorganisé en packages: Client nom Prénom CompagnieAerinne 1..* nom adresse Affréteur tééphonel e-mail numéro 1..* {frozen} 1 propose Propose a effectué 0..1 0..* ‘’ metaclasse „‟ départ VolGenerique Aéroport Réservation 0..* jour 0..* 1 date concerne heureDepart arrivée nom Vol heureArrivee numero 0..* 1 dateDepart /durée 0..* 1 periodevalidite Annuler( ) {frozen} dateArrivee escale Confirmer( ) ouvrirVol( ) ouvrirVol( ) fermerVol( ) 0..* 0..* 0..* fermerVol( ) {ordered} concerne {AddOnly} 0..* {frozen} 1 InfosEscale 1 décrit heureArrivee Ville Passager heureDepart nom nom Prénom
  • 116.  Le diagramme des classes peut être réorganisé en packages: Client nom Prénom CompagnieAerinne 1..* nom adresse Affréteur tééphonel e-mail numéro 1..* {frozen} 1 propose Propose a effectué 0..1 0..* ‘’ metaclasse „‟ départ VolGenerique Aéroport Réservation 0..* jour 0..* 1 date concerne heureDepart arrivée nom Vol heureArrivee numero 0..* 1 dateDepart /durée 0..* 1 periodevalidite Annuler( ) {frozen} dateArrivee escale Confirmer( ) ouvrirVol( ) ouvrirVol( ) fermerVol( ) 0..* 0..* 0..* fermerVol( ) {ordered} concerne {AddOnly} 0..* {frozen} 1 InfosEscale 1 décrit heureArrivee Ville Passager heureDepart nom nom Prénom
  • 117. Réservations Vol Réservation Vol date dateDepart numéro concerne dateArrivee Annuler( ) 0..* 1 ouvrirVol( ) Confirmer( ) {frozen} fermerVol( )
  • 118. Réservations Vol Réservation Vol date dateDepart numéro concerne dateArrivee Annuler( ) 0..* 1 ouvrirVol( ) Confirmer( ) {frozen} fermerVol( ) Réduire la dépendance mutuelle afin d‟augmenter la modularité et l‟évolutivité d‟une application
  • 119. Réservations Client nom Prénom adresse téléphone e-mail {frozen} 1 a effectué 0..* Réservation date numéro Annuler( ) Confirmer( ) 0..* concerne 1 Passager nom Prénom
  • 120. Réservations Vol Client CompagnieAerinne nom Prénom 1..* nom adresse Affréteur téléphone e-mail numéro 1 {frozen} 1 propose Propose a effectué 0..1 0..* ‘’ metaclasse ‘’ départ VolGenerique Aéroport Réservation 0..* jour 0..* 1 date heureDepart arrivée nom Vol heureArrivee numéro dateDepart /durée 0..* 1 Annuler( ) dateArrivee periodevalidite ouvrirVol( ) escale Confirmer( ) ouvrirVol( ) fermerVol( ) 0..* 0..* 0..* fermerVol( ) {ordered} concerne {AddOnly} 0..* {frozen} 1 InfosEscale 1 decrit heureArrivee Ville Passager heureDepart nom nom Prénom
  • 121. Réservations Vol Client CompagnieAerinne nom Prénom 1..* nom adresse Affréteur téléphone e-mail numéro 1 {frozen} 1 propose Propose a effectué 0..1 0..* ‘’ metaclasse ‘’ départ VolGenerique Aéroport Réservation concerne 0..* jour 0..* 1 date heureDepart arrivée nom Vol heureArrivee numéro 0..* 1 dateDepart /durée 0..* 1 Annuler( ) {frozen} dateArrivee periodevalidite ouvrirVol( ) escale Confirmer( ) ouvrirVol( ) fermerVol( ) 0..* 0..* 0..* fermerVol( ) {ordered} concerne {AddOnly} 0..* {frozen} 1 InfosEscale 1 decrit heureArrivee Ville Passager heureDepart nom nom Prénom
  • 122. Réservations Vol Client CompagnieAerinne nom Prénom 1..* nom adresse Affréteur téléphone e-mail numéro 1 {frozen} 1 propose Propose a effectué 0..1 0..* ‘’ metaclasse ‘’ départ VolGenerique Aéroport Réservation concerne 0..* jour 0..* 1 date heureDepart arrivée nom Vol heureArrivee numéro 0..* 1 dateDepart /durée 0..* 1 Annuler( ) {frozen} dateArrivee periodevalidite ouvrirVol( ) escale Confirmer( ) ouvrirVol( ) fermerVol( ) 0..* 0..* 0..* fermerVol( ) {ordered} concerne {AddOnly} 0..* {frozen} 1 InfosEscale 1 decrit heureArrivee Ville Passager heureDepart nom nom Prénom
  • 123. Généralisation et réutilisation
  • 124. Généralisation et réutilisation On veut élargir ce domaine aux voyages par bus que des transporteurs assurent. Un voyage en bus à une ville de départ et un ville d‟arrivée avec des dates et des heures associées. Un trajet peut comporter des arrêts dans des villes intermédiaires. Un client peut réserver un ou plusieurs voyages pour un ou plusieurs passagers
  • 125. Généralisation et réutilisation On veut élargir ce domaine aux voyages par bus que des transporteurs assurent. Un voyage en bus à une ville de départ et un ville d‟arrivée avec des dates et des heures associées. Un trajet peut comporter des arrêts dans des villes intermédiaires. Un client peut réserver un ou plusieurs voyages pour un ou plusieurs passagers ReservationsBus VoyagesBus ReservationBus VoyageEnBus date numéro concerne dateDepart dateArrivee 0..* 1 Annuler( ) Confirmer( ) {frozen} OuvrirVoyage( ) fermerVoyage( )
  • 126. ReservationsBus VoyagesBus Client Voyagiste nom Prénom nom adresse téléphone e-mail référence 1 {frozen} 1 Propose a effectué 0..1 0..* VoyageEnBus départ ReservationBus concerne dateDepart 0..* 1 Ville date heureDepart arrivée dateArrivee nom numéro {frozen} heureArrivee 0..* 1 Annuler( ) /durée ouvrirVoyage( ) arrêt Confirmer( ) fermerVoyage( ) 0..* 0..* 0..* {ordered} concerne InfosArret 1..* heureArrivee Passager heureDepart nom Prénom
  • 127. ReservationsBus VoyagesBus Client Voyagiste nom Prénom nom adresse téléphone e-mail référence 1 {frozen} 1 Propose a effectué 0..1 0..* VoyageEnBus départ ReservationBus concerne dateDepart 0..* 1 Ville date heureDepart arrivée dateArrivee nom numéro {frozen} heureArrivee 0..* 1 Annuler( ) /durée ouvrirVoyage( ) arrêt Confirmer( ) fermerVoyage( ) 0..* 0..* 0..* {ordered} concerne InfosArret 1..* heureArrivee Passager heureDepart nom Prénom
  • 128. Fusion des 2 modèles
  • 129. Fusion des 2 modèles 1. Il faut isoler les classes communes dans des packages 2. Il faut factoriser les propriétés communes
  • 130. Fusion des 2 modèles 1. Il faut isoler les classes communes dans des packages 2. Il faut factoriser les propriétés communes
  • 131. Fusion des 2 modèles 1. Il faut isoler les classes communes dans des packages 2. Il faut factoriser les propriétés communes AVION BUS ReservationBus ReservationVols Vols VoyagesBus Lieux
  • 132.  Il faut isoler les classes communes dans des packages
  • 133.  Il faut isoler les classes communes dans des packages Classe Réservations abstraite Client Réservation concerne nom Prénom a effectué Passager date 0..* 1 adresse numéro 1 0..* nom Prénom tél Annuler( ) e-mail {frozen} Confirmer( ) ReservationVol ReservationBus (from ReservationsVols) (from ReservationsBus) concerne concerne 1 {frozen} 1 {frozen} Vol VoyageEnBus (from Vols) (from VoyagesBus)
  • 134. Package généralisé RéservationsPackages spécialisés ReservationsBus ReservationsVols
  • 135. Package généralisé RéservationsPackages spécialisés ReservationsBus ReservationsVols VoyagesBus Vols
  • 136. Package généralisé RéservationsPackages spécialisés ReservationsBus ReservationsVols VoyagesBus VolsPackage réutilisable Lieux
  • 137. UML : Unified Modeling Language Diagramme d’objets
  • 138. Diagramme d’objets : Objectif Le diagramme d‟objets permet de mettre en évidence des liens entre les objets. Les objets, instances de classes, sont reliés par des liens, instances d‟associations. A l‟exception de la multiplicité, qui est explicitement indiquée, le diagramme d‟objets utilise les mêmes concepts que le diagramme de classes. Ils sont essentiellement utilisés pour comprendre ou illustrer des parties complexes d‟un diagramme de classes.
  • 139. Diagramme d’objets : Objet Notion‎d’Objet Une abstraction du monde réel c.-à-d. des données informatiques regroupant des caractéristiques du monde réel. Un objet est une instance dune classe. Exemple une personne, une voiture, une maison, ...
  • 140. Diagramme d’objets : Objet Chaque objet est unique et a un identifiant qui le distingue des autres objets. Les objets peuvent avoir un nom suivi de deux points et du nom de la classe. Trois représentations possibles des instances :
  • 141. Diagramme d’objets : Exemple
  • 142. UML : Unified Modeling Language Diagramme de composants
  • 143. Diagramme de composants : Objectif Les diagrammes de composants décrivent les composants et leurs dépendances dans l‟environnement de réalisation. En général, ils ne sont utilisés que pour des systèmes complexes. Les diagrammes de composants permettent de décrire larchitecture physique et statique dune application en terme de modules : fichiers sources, librairies, exécutables, etc. Ils montrent la mise en œuvre physique des modèles de la vue logique avec lenvironnement de développement.
  • 144. Diagramme de composants : Le composant Un composant est un élément physique qui représente une partie implémentée d‟un système. Un composant peut être du code (source, binaire ou exécutable), un script, un fichier de commandes, un fichier de données, une table, etc. Il peut réaliser un ensemble d‟interfaces qui définissent alors le comportement offert à d‟autres composants.
  • 145. Diagramme de composants : La relation Les relations de dépendance sont utilisées dans les diagrammes de composants pour indiquer qu‟un élément d‟implémentation d‟un composant fait appel aux services offerts par les éléments d‟implémentation d‟un autre composant.
  • 146. Diagramme de composants : Stéréotypes  UML définit 5 stéréotypes aux composants : - «« document »» : un document quelconque - «« exécutable »» : un programme qui peut s‟exécuter - «« fichier »» : un document contenant un code source ou des données - «« bibliothèque »» : une bibliothèque statique ou dynamique - «« table »» : une table de base de données relationnelle
  • 147. Diagramme de composants : Exemple
  • 148. UML : Unified Modeling Language Diagramme de déploiement
  • 149. Diagramme de déploiement : Objectif Les diagrammes de déploiement montrent la disposition physique des différents matériels (les noeuds) qui entrent dans la composition d‟un système et la répartition des instances de composants, processus et objets qui « vivent » sur ces matériels. Le diagramme de déploiement modélise les composants matériels utilisés pour implémenter un système et lassociation entre ces composants. Les diagrammes de déploiement sont donc très utiles pour modéliser l‟architecture physique d‟un système.
  • 150. Diagramme de déploiement : Le composant Un composant représente une entité logicielle du système. (fichier de code source, programmes, documents, fichiers de ressource .etc.). Sur un diagramme de déploiement, les composants sont placés dans des noeuds pour identifier lendroit de leur déploiement.
  • 151. Diagramme de déploiement : Le nœud  Un noeud représente un ensemble déléments matériels du système. Cette entité est représentée par un cube tridimensionnel.
  • 152. Diagramme de déploiement : L’association  Les noeuds sont connectés entre eux, à laide dun support de communication.  une association, représentée par une ligne pleine entre deux noeuds, indique une ligne de communication entre les éléments matériels.
  • 153. Diagramme de déploiement : Exemple  Le diagramme de déploiement ci-dessous montre que le composant SiteConfig est déployé sur le serveur Web et le composant Base DB est déployé sur le serveur APP. Nous pouvons également déterminer que le serveur Web communique avec le serveur APP, et le serveur APP communique avec le serveur de base de données et une imprimante.
  • 154. UML : Unified Modeling Language Diagramme de collaboration
  • 155. Diagramme de collaboration: Objectif Le diagramme de collaboration permet de mettre en évidence les interactions entre les différents objets du système. Dans le cadre de l‟analyse, il sera utilisé - pour préciser le contexte dans lequel chaque objet évolue - pour mettre en évidence les dépendances entre les différents objets impliqués dans l‟exécution d‟un processus ou d‟un cas d‟utilisation. Un diagramme de collaboration fait apparaître les interactions entre des objets et les messages qu‟ils échangent.
  • 156. Diagramme de collaboration: Les interactions Une interaction définit la communication entre les objets sous la forme d‟un ensemble partiellement ordonné de messages. L‟objet émetteur envoie un message à l‟objet récepteur. Les objets représentés dans les diagrammes de collaboration ne sont pas nécessairement des instances d‟entités. Certains messages peuvent avoir pour origine des acteurs que l‟on pourra représenter. l‟interaction se représente par une flèche avec un texte décrivant le message.
  • 157. Diagramme de collaboration: Les messages Les messages sont le seul moyen de communication entre les objets. Ils sont décrits essentiellement par l‟objet émetteur et l‟objet récepteur. Leur description peut être complétée par un nom, une séquence, des arguments, un résultat attendu, une synchronisation, une condition d‟émission. La séquence permet de préciser l‟ordre d‟émission des messages. Le message 1 peut avoir comme arguments l‟intitulé du produit souhaité, la quantité et la catégorie du client.
  • 158. Diagramme de collaboration: Les messages (suite) Certains messages peuvent solliciter un résultat. Ce cas peut être modéliser de 2 façons : - un message de demande et un message de réponse - indiquer sur le premier message le résultat attendu (lorsque le message en retour est attendu immédiatement). ou Ici, le message émis par le gérant implique la restitution immédiate du résultat du calcul:la valeur du stock.
  • 159. Diagramme de collaboration: Les messages (suite) NB : l‟émission de message peut également être soumis à une condition, qui s‟exprime alors sur le texte du message.  Exemple : la demande de réapprovisionnement n‟est envoyée au magasinier que lorsque la quantité en stock est inférieure au seuil de réapprovisionnement.
  • 160. UML : Unified Modeling Language Diagramme de séquence
  • 161. Diagramme de séquence: Objectif Le diagramme de séquence est une variante du diagramme de collaboration. Les diagrammes de séquences permettent de représenter des collaborations entre objets selon un point de vue temporel. Le diagramme de séquence permet de visualiser les messages par une lecture de haut en bas. L‟axe vertical représente le temps, l‟axe horizontal les objets qui collaborent. Une ligne verticale en pointillé est attachée à chaque objet et représente sa durée de vie.
  • 162. Diagramme de séquence: La ligne de vie La ligne de vie des objets est représentée par une ligne verticale en traits pointillés, placée sous le symbole de l‟objet concerné. Cette ligne de vie précise l‟existence de l‟objet concerné durant un certain laps de temps. En général, une ligne de vie est représentée sur toute la hauteur du diagramme de séquence. Par contre, elle peut débuter et s‟interrompre à l‟intérieur du diagramme. La destruction est indiquée par la fin de la ligne de vie et par une croix (X), soit à la hauteur du message qui cause la destruction, soit après le dernier message envoyé par un objet qui se suicide.
  • 163. Diagramme de séquence: Les catégories de message Message simple: message dont on ne spécifie aucune caractéristique denvoi ou de réception particulière. Message minuté (timeout): bloque lexpéditeur pendant un temps donné (qui peut être spécifié dans une contrainte), en attendant la prise en compte du message par le récepteur. Lexpéditeur est libéré si la prise en compte na pas eu lieu pendant le délai spécifié. Message synchrone: bloque lexpéditeur jusquà prise en compte du message par le destinataire. Le flot de contrôle passe de lémetteur au récepteur (lémetteur devient passif et le récepteur actif) à la prise en compte du message. Message asynchrone: ninterrompt pas lexécution de lexpéditeur. Le message envoyé peut être pris en compte par le récepteur à tout moment ou ignoré (jamais traité). Message dérobant: ninterrompt pas lexécution de lexpéditeur et ne déclenche une opération chez le récepteur que sil sest préalablement mis en attente de ce message.
  • 164. Diagramme de séquence: Les catégories de message (suite)Exemple :
  • 165. Diagramme de séquence: Le message réflexif Un objet peut s‟envoyer un message. Formalisme : Cette situation se représente par une flèche qui revient en boucle sur la ligne de vie de l‟objet.
  • 166. Diagramme de séquence: Les activations  Les diagrammes de séquence permettent de représenter les périodes d‟activité des objets.  Une période d‟activité correspond au temps pendant lequel un objet effectue une action, soit directement, soit par l‟intermédiaire d‟un autre objet qui lui sert de sous- traitant.  les périodes d‟activité se représentent par des bandes rectangulaires placées sur la ligne de vie des objets.  Pour représenter de manière graphique une exécution conditionnelle dun message, on peut documenter un diagramme de séquence avec du pseudo-code et représenter des bandes dactivation conditionnelles.
  • 167. Diagramme de séquence: Les activations Exemple : Ne confondez la période dactivation dun objet avec sa création ou sa destruction. Un objet peut être actif plusieurs fois au cours de son existence
  • 168. Diagramme de séquence: Les contraintes temporelles Une flèche qui symbolise un message peut être représentée en oblique pour matérialiser les délais de transmission non négligeables par rapport à la dynamique générale de l‟application.
  • 169. Diagramme de séquence: Exemple
  • 170. UML : Unified Modeling Language Diagramme détats-transitions
  • 171. Diagramme d’états-transitions: Objectif  Ils ont pour rôle de représenter les traitements (opérations) qui vont gérer le domaine étudié. Ils définissent lenchaînement des états de classe et font donc apparaître lordonnancement des travaux.  Le diagramme détats-transition est associé à une classe pour laquelle on gère différents états : il permet de représenter tous les états possibles ainsi que les événements qui provoquent les changements détat.  Décrit le comportement des objets d‟une classe au moyen d‟un automate d‟états associé à la classe.
  • 172. Diagramme d’états-transitions: Notion d’état  Un état correspond à une situation durable dans laquelle se trouvent les objets dune classe.  On lui associe les règles de gestion et les activités particulières.  un état = étape dans le cycle de vie d‟un objet durant lequel • il satisfait à certaines conditions • il réalise certaines actions • ou attend certains événements  La représentation symbolique des états dune classe dobjets est la suivante (rectangle aux bords arrondis) :
  • 173. Diagramme d’états-transitions: Notion d’état (suite)  Chaque diagramme d‟états-transitions comprend un état initial.  Pour un niveau hiérarchique donné, il y a un et un seul état initial, mais plusieurs états finaux correspondant chacun à une fin de vie de l‟objet différente.  Il est possible de n‟avoir aucun état final : ex : un système que ne s‟arrête jamais.  Létat initial dun objet : il est obligatoire et unique  Létat final : selon les événements, il peut exister plusieurs états finaux
  • 174. Diagramme d’états-transitions: Evénements et transitions Un objet passe dun état à un autre suite à un événement, certains événements pouvant ne pas provoquer de changement détat. un événement est une information instantanée qui doit être traitée dans l’instant où il se produit. Une transition est une relation entre 2 états. Elle est orientée ce qui signifie que létat 2 est possible si certains événements sont vérifiés. Sa représentation symbolique est une flèche sur laquelle est annoté lévénement qui concourt au changement détat.
  • 175. Diagramme d’états-transitions: Evénements et transitions Exemple : Une commande passera dans létat "En attente" dès lors quelle aura été expédiée La transition peut être soumise à la vérification dune expression appelée "expression de garde". Une garde est une condition booléenne qui permet ou non le déclenchement d‟une transition lors de l’occurrence d‟un Événement. Exemple : La commande nest expédiée que si la commande comporte au moins 3 produits.
  • 176. Diagramme d’états-transitions: actions et activités Les opérations de description des classes sont décrites dans le diagramme détatstransitions sous forme dactions et dactivités. Une action est une opération élémentaire et instantanée. Elle peut être associée à lévénement lui-même ou à lentrée dans létat ou à la sortie de létat. • l‟action d’entrée (entry) est exécutée de manière instantanée et atomique. • l‟action de sortie (exit) est exécutée à la sortie de l‟état. l‟action sur un événement interne (on) est exécutée lors de l‟occurrence d‟un événement qui ne conduit pas à un autre état
  • 177. Diagramme d’états-transitions: actions et activités (suite) Une activité est une opération qui dure et qui est donc associée à un état. Elle peut être séquentielle ou cyclique :• La fin dune activité séquentielle correspond à la sortie de létat : une transition automatique est générée.• Une activité cyclique ne se termine que par une transition de sortie identifiée. Le mot clé do: indique une activité. Lorsqu‟une activité se termine, les transitions automatiques (sans événement), mais éventuellement protégées par des gardes, sont déclenchées.
  • 178. Diagramme d’états-transitions: actions et activités (suite)  Six manières d‟associer une opération à une transition : • l‟action associée à la transition d’entrée (op1) • l‟action d’entrée de l’état (op2) • l’activité dans l’état (op3) • l’action de sortie de l’état (op4) • l‟action associée aux événements internes (op5) • l‟action associée à la transition de la sortie de l’état (op6)
  • 179. Diagramme d’états-transitions: hiérarchie d’états En cours de modélisation avec un diagramme d‟états, il peut être judicieux de regrouper plusieurs états en un seul ou bien de décomposer un état en plusieurs sous-états. Exemple: Ici, l‟état „état4‟ est un sur-état des états „état1‟, „état2‟, „état3‟. Les deux transitions qui rentrent dans l‟état „état4‟ spécifient dans quel sous-état on arrive. La transition sortante de l‟état „état4‟ exprime que, quel que soit le sous-état dans lequel l‟objet se trouve, si l‟événement „ev3‟ arrive, alors l‟objet sort de l‟état „état4‟.
  • 180. Diagramme d’états-transitions: ExempleDiagramme d’états-transitions du Distributeur Automatique de Boissons
  • 181. UML : Unified Modeling Language Diagramme d’activités
  • 182. Diagramme d’activités : Objectif  Les diagrammes d‟activités permettent de mettre l‟accent sur les traitements.  les diagrammes dactivité sont utilisés pour documenter le déroulement des opérations dans un système.  En regardant un diagramme dactivité, vous trouverez des éléments des diagrammes détat. En fait, le diagramme dactivité est une variante du Diagramme détat où les „états‟ représentent des opérations, et les transitions représentent les activités qui se produisent quand lopération est terminée. Lusage général des diagrammes dactivité permet de faire apparaître les flots de traitements induits par les processus internes par rapport aux évènements externes.  Ce diagramme pourra comporter des synchronisations pour représenter les déroulements parallèles.  La notion de couloir dactivité va décrire les responsabilités en répartissant les activités entre les différents acteurs opérationnels.
  • 183. Diagramme d’activités : Synchronisation  Les diagrammes d‟activités représentent les synchronisations d‟activités au moyen de barres de synchronisation. Formalisme: Exemple :
  • 184. Diagramme d’activités : Nœuds d’activités Un nœud d‟activité est un type d‟élément abstrait permettant de représenter les étapes le long du flot d‟une activité. Il existe trois familles de nœuds d‟activités : les nœuds d‟exécutions: les nœuds objets: et les nœuds de contrôle.
  • 185. Diagramme d’activités : Nœuds d’activités (suite) Un nœud exécutable est un nœud d‟activité qu‟on peut exécuter. Il possède un gestionnaire d‟exception qui peut capturer les exceptions levées parle nœud, ou un de ses nœuds imbriqués. Il y‟a deux types de la Nœud Exécutable: Nœud d’action: est un nœud d‟activité exécutable qui constitue l‟unité fondamentale de fonctionnalité exécutable dans une activité. Nœud d’activité structurée: Un nœud d‟activité structurée est un nœud d‟activité exécutable qui représente une portion structurée d‟une activité donnée qui n‟est partagée avec aucun autre nœud structuré, à l‟exception d‟une imbrication éventuelle. Un nœud de contrôle est un nœud d‟activité abstrait utilisé pour coordonner les flots entre les nœuds d‟une activité. Il existe plusieurs types de nœuds de contrôle : Nœud initial, nœud final, nœud de décision et de fusion, nœud de bifurcation et d‟union
  • 186. Diagramme d’activités : Nœuds d’activités (suite) Nœud initial: Un nœud initial est un nœud de contrôle à partir duquel le flot débute lorsque l‟activité enveloppante est invoquée. Nœud final: Un nœud final est un nœud de contrôle possédant un ou plusieurs arcs entrants et aucun arc sortant. Nœud de décision: est un nœud de contrôle Qui permet de faire un choix entre plusieurs flots sortants. Il possède un arc entrant et plusieurs arcs sortants. Ces derniers sont généralement accompagnés de conditions de garde pour conditionner le choix. Nœud de fusion: Un nœud de fusion est un nœud de contrôle qui rassemble plusieurs flots alternatifs entrants en un seul flot sortant. Nœud de bifurcation: Un nœud de bifurcation, également appelé nœud de débranchement est un nœud de contrôle qui sépare un flot en plusieurs flots concurrents. Un tel nœud possède donc un arc entrant et plusieurs arcs sortants. Nœud d’union: Un nœud d‟union, également appelé nœud de jointure est un nœud de contrôle qui synchronise des flots multiples. Un tel Nœud possède donc plusieurs arcs entrants et un seul arc sortant.
  • 187. Diagramme d’activités : Nœuds d’activités (exemple)
  • 188. Diagramme d’activités : Nœuds d’activités (suite) un nœud d’objet: permet de définir un flot d‟objet (un flot de données) dans un diagramme d‟activités. Ce nœud représente l‟existence d‟un objet généré par une action dans une activité et utilisé par d‟autres actions. Pin d‟entrée ou de sortie: Pour spécifier les valeurs passées en argument à une activité et les valeurs de retour, on utilise des nœuds d‟objets appelés pins (pin en anglais) d‟entrée ou de sortie. Les valeurs sont passées par copie : une modification des valeurs d‟entrée au cours du traitement de l‟action n‟est visible qu‟à l‟intérieur de l‟activité.
  • 189. Diagramme d’activités : Nœuds d’activités (suite) Pin de valeur: Un pin valeur est un pin d‟entrée qui fournit une valeur à une action sans que cette valeur ne provienne d‟un arc de flot d‟objets. Un pin valeur est toujours associé à une valeur spécifique. Graphiquement, un pin de valeur se représente comme un pin d‟entrée avec la valeur associée écrite à proximité. Flot d’objet: Un flot d‟objets permet de passer des données d‟une activité à une autre. Un arc reliant un pin de sortie à un pin d‟entrée. Il existe une autre représentation possible d‟un flot d‟objets, représenté par un rectangle dans lequel est mentionné le type de l‟objet (souligné). Le nom d‟un état, ou d‟une liste d‟états, de l‟objet peut être précisé entre crochets après ou sous le type de l‟objet. On peut également préciser des contraintes entre accolades, soit à l‟intérieur, soit en dessous du rectangle du nœud d‟objet.
  • 190. Diagramme d’activités : Nœuds d’activités (suite) Nœud tampon central: est un nœud d‟objet qui accepte les entrées de plusieurs nœuds d‟objets ou produit des sorties vers plusieurs nœuds d‟objets. Nœud de stockage des données: est un nœud tampon central particulier qui assure la persistance des données. Lorsqu‟une information est sélectionnée par un flux sortant, l‟information est dupliquée et ne disparaît pas du nœud de stockage des données comme ce serait le cas dans un nœud tampon central. Lorsqu‟un flux entrant véhicule une donnée déjà stockée par le nœud de stockage des données, cette dernière est écrasée par la nouvelle.
  • 191. Diagramme d’activités: Les couloirs dactivités Le diagramme dactivités fait intervenir les acteurs de chaque activité. Chaque activité sera placée dans une colonne (couloir) qui correspond à lacteur. permettent d‟organiser les nœuds d‟activités dans un diagramme d‟activités en opérant des regroupements.
  • 192. UML : Unified Modeling Language Modélisation dynamique en UML : Étude de cas
  • 193. Cas du publiphone :
  • 194. Cas du publiphone :1. Le prix minimal d’une communication interurbaine est de 1€.
  • 195. Cas du publiphone :1. Le prix minimal d’une communication interurbaine est de 1€.2. Après l’introduction de la monnaie, l’utilisateur a 2 mn pour composer son numéro (ce délai est décompté par le standard).
  • 196. Cas du publiphone :1. Le prix minimal d’une communication interurbaine est de 1€.2. Après l’introduction de la monnaie, l’utilisateur a 2 mn pour composer son numéro (ce délai est décompté par le standard).3. La ligne peut être libre ou occupée.
  • 197. Cas du publiphone :1. Le prix minimal d’une communication interurbaine est de 1€.2. Après l’introduction de la monnaie, l’utilisateur a 2 mn pour composer son numéro (ce délai est décompté par le standard).3. La ligne peut être libre ou occupée.4. Le correspondant peut raccrocher le premier.
  • 198. Cas du publiphone :1. Le prix minimal d’une communication interurbaine est de 1€.2. Après l’introduction de la monnaie, l’utilisateur a 2 mn pour composer son numéro (ce délai est décompté par le standard).3. La ligne peut être libre ou occupée.4. Le correspondant peut raccrocher le premier.5. Le publiphone consomme de l’argent dès que l’appelé décroche et à chaque unité de temps (UT) générée par le standard.
  • 199. Cas du publiphone :1. Le prix minimal d’une communication interurbaine est de 1€.2. Après l’introduction de la monnaie, l’utilisateur a 2 mn pour composer son numéro (ce délai est décompté par le standard).3. La ligne peut être libre ou occupée.4. Le correspondant peut raccrocher le premier.5. Le publiphone consomme de l’argent dès que l’appelé décroche et à chaque unité de temps (UT) générée par le standard.6. On peut ajouter des pièces à tout moment.
  • 200. Cas du publiphone :1. Le prix minimal d’une communication interurbaine est de 1€.2. Après l’introduction de la monnaie, l’utilisateur a 2 mn pour composer son numéro (ce délai est décompté par le standard).3. La ligne peut être libre ou occupée.4. Le correspondant peut raccrocher le premier.5. Le publiphone consomme de l’argent dès que l’appelé décroche et à chaque unité de temps (UT) générée par le standard.6. On peut ajouter des pièces à tout moment.7. Lors du raccrochage, le solde de monnaie est rendu.
  • 201.  Démarche en plusieurs points : Identifier les acteurs et construire le diagramme des use case. Construire le diagramme de séquences système. Construire le diagramme de contexte dynamique. Élaborer le diagramme d’états du publiphone.
  • 202.  Le diagramme des use case
  • 203.  Le diagramme des use case Les acteurs
  • 204.  Le diagramme des use case Les acteurs 0..1 «system» 0..* Publiphone «system» 0..1 0..1 Téléphone Appelant «actor» 0..* 0..1 Appelé Standard
  • 205.  Le diagramme des use case Les acteurs 0..1 «system» 0..* Publiphone «system» 0..1 0..1 Téléphone Appelant «actor» 0..* 0..1 Appelé Standard
  • 206.  Le diagramme des use case Les acteurs 0..1 «system» 0..* Publiphone «system» 0..1 0..1 Téléphone Appelant «actor» 0..* 0..1 Appelé Standard  Le diagramme des use case
  • 207.  Le diagramme des use case Les acteurs 0..1 «system» 0..* Publiphone «system» 0..1 0..1 Téléphone Appelant «actor» 0..* 0..1 Appelé Standard  Le diagramme des use case Publiphone «actor» Standard secondaire Appelant téléphoner
  • 208.  Le diagramme de séquence sysème
  • 209.  Le diagramme de séquence sysème :publiphone :standard:appelant décrocherCombiné introduirePièce(1€) vérifierPièce incrémenterCrédit(1€) composerNuméro(04 78 77 23 23) acheminerNuméro(04 78 77 23 23) tonalité(libre) tonalité(libre) débuterComm taxer(1€) introduirePièce(1€) vérifierPièce incrémenterCrédit(1€) UT taxer(1€) raccrocherCombiné FinComm
  • 210.  Le diagramme de contexte dynamique 
  • 211.  Le diagramme de contexte dynamique  Représenter les messages émis et les messages reçus par le publiphone . :appelant :publiphone :standard
  • 212.  Le diagramme de contexte dynamique  Représenter les messages émis et les messages reçus par le publiphone . - Messages reçus déclenchent des transitions entre états. décrocherCombiné ; introduirePièce(p) ; composerNuméro(n) ; raccrocherCombiné ; voixAppelant :appelant :publiphone acheminerNuméro(n) finComm ; voixAppelant timerNumérotation :standard
  • 213.  Le diagramme de contexte dynamique  Représenter les messages émis et les messages reçus par le publiphone . - Messages transitions entre états. reçus déclenchent des - Messages émis donnent lieu à des actions sur les transitions. décrocherCombiné ; introduirePièce(p) ; composerNuméro(n) ; raccrocherCombiné ; voixAppelant :appelant tonalité(type) voixAppelé rendrePièce :publiphone débuterComm acheminerNuméro(n) UT finComm ; voixAppelant tonalité(type) voixAppelé timerNumérotation État(Ligne) :standard validitéNumérotation(v) finComm TimeroutNumérotation
  • 214.  Le diagramme d’états     
  • 215.  Le diagramme d’états  Démarche itérative et incrémentale :  Représenter les séquences d’états décrivant le comportement d’une instance avec les transitions associées.  Ajouter les transitions correspondant aux comportements ‘’alternatifs’’ ou d’exception.  Compléter les actions sur les transitions et les activités dans les états.  Structurer le diagramme en sous états et utiliser les notations ( entry, exit, …)
  • 216.  Le diagramme d’états  Démarche itérative et incrémentale :  Représenter les séquences d’états décrivant le comportement d’une instance avec les transitions associées.  Ajouter les transitions correspondant aux comportements ‘’alternatifs’’ ou d’exception.  Compléter les actions sur les transitions et les activités dans les états.  Structurer le diagramme en sous états et utiliser les notations ( entry, exit, …) Événement interne décrocherCombiné When(crédit  1€) raccroché attente pièce communication attente N° raccrocherCombiné Réception composerNuméro message débuterComm numéroValide attente attente validité décrochage
  • 217. Événement interne décrocherCombiné When(crédit  1€) raccroché attente pièce communication attente N° raccrocherCombinéRéception composerNuméromessage débuterComm numéroValide attente attente validité décrochage
  • 218. Événement interne décrocherCombiné When(crédit  1€) raccroché attente pièce raccrocherCombiné raccrocherCombiné communication attente N° raccrocherCombinéRéception composerNuméromessage débuterComm numéroValide attente attente validité raccrocherCombiné décrochage raccrocherCombiné
  • 219.
  • 220.  décrocherCombiné raccroché raccrocherCombiné
  • 221.  décroché décrocherCombiné raccroché raccrocherCombiné
  • 222.  décroché décrocherCombiné When(crédit  1€) raccroché attente pièce communication attente N° raccrocherCombiné composerNuméro débuterComm numéroValide attente attente validité décrochage
  • 223.  décroché décrocherCombiné When(crédit  1€) raccroché attente pièce communication attente N° raccrocherCombiné composerNuméro débuterComm numéroValide attente attente validité décrochage
  • 224. La solution bleue n’est pas intéressante décroché décrocherCombiné When(crédit  1€) raccroché attente pièce communication attente N° raccrocherCombiné composerNuméro débuterComm numéroValide attente attente validité décrochage
  • 225.
  • 226.  Modéliser l’ attente des pièces pour que le crédit devienne suffisant :
  • 227.  Modéliser l’ attente des pièces pour que le crédit devienne suffisant : introPièce(p)/incrémenterCrédit(p) When(crédit  1€) attente pièce attente N°
  • 228.
  • 229. Le diagramme devient :
  • 230. Le diagramme devient : décroché introPièce(p)/incrémenterCrédit(p) décrocherCombiné When(crédit  1€) raccroché /crédit=0 attente pièce Fin UT[créditInuffisant] communication attente N° raccrocherCombiné /taxer /rendrePièce UT[créditInsuffisant] /taxer communication composerNuméro débuterComm /taxer numéroValide attente validité attente décrochage
  • 231.   
  • 232.  Modéliser la phrase 6 : « on peut rajouter des pièces à tout moment »  On peut rajouter une transition à chaque sous état (solution lourde, effet secondaire : à chaque introPièce(p) le publiphone revient à son état initial (attente pièce c.a.d. raccroché)).  On peut utiliser une transition interne introPièce(p)/incrémenterCrédit(p) à l’intérieur de l’état « décroché »
  • 233.  Modéliser la phrase 6 : « on peut rajouter des pièces à tout moment »  On peut rajouter une transition à chaque sous état (solution lourde, effet secondaire : à chaque introPièce(p) le publiphone revient à son état initial (attente pièce c.a.d. raccroché)).  On peut utiliser une transition interne introPièce(p)/incrémenterCrédit(p) à l’intérieur de l’état « décroché » décroché introPièce(p)/incrémenterCrédit(p) décrocherCombiné When(crédit  1€) raccroché /crédit=0 attente pièce Fin UT[créditInsuffisant] communication attente N° raccrocherCombiné /taxer /rendrePièce UT[créditInsuffisant] communication /taxer composerNuméro débuterComm /taxer numéroValide attente attente validité décrochage
  • 234.  Modéliser la phrase 6 : « on peut rajouter des pièces à tout moment »  On peut rajouter une transition à chaque sous état (solution lourde, effet secondaire : à chaque introPièce(p) le publiphone revient à son état initial (attente pièce c.a.d. raccroché)).  On peut utiliser une transition interne introPièce(p)/incrémenterCrédit(p) à l’intérieur de l’état « décroché » décroché introPièce(p)/incrémenterCrédit(p) décrocherCombiné When(crédit  1€) raccroché /crédit=0 attente pièce Fin UT[créditInsuffisant] communication attente N° raccrocherCombiné /taxer /rendrePièce UT[créditInsuffisant] communication /taxer composerNuméro•Même la transition propre sur débuterComm /taxer«communication» doit être numéroValidetransformée en transition interne. attente attente validité décrochage•On préfère les transitions propres,car visuelles.
  • 235.    
  • 236.  Les phrases 1, 5, 6, 7 dont modélisées.   
  • 237.  Les phrases 1, 5, 6, 7 dont modélisées. Les phrases 2, 3 et 4 sont à compléter.   
  • 238.  Les phrases 1, 5, 6, 7 dont modélisées. Les phrases 2, 3 et 4 sont à compléter. Phrase 2 : deux messages sont introduits :  timerNumérotation envoyé par le publiphone au standard.  timeoutNumérotation envoyé par le standard au publiphone. 
  • 239.  Les phrases 1, 5, 6, 7 dont modélisées. Les phrases 2, 3 et 4 sont à compléter. Phrase 2 : deux messages sont introduits :  timerNumérotation envoyé par le publiphone au standard.  timeoutNumérotation envoyé par le standard au publiphone.  Utilisation du concept UML «send» pour envoyer un message 
  • 240.  Les phrases 1, 5, 6, 7 dont modélisées. Les phrases 2, 3 et 4 sont à compléter. Phrase 2 : deux messages sont introduits :  timerNumérotation envoyé par le publiphone au standard.  timeoutNumérotation envoyé par le standard au publiphone.  Utilisation du concept UML «send» pour envoyer un message Phrase 3 : Le standard renvoie un message sur l’état de la ligne.  État(Ligne) (où état peut être libre, occupé, en dérangement).
  • 241.  Les phrases 1, 5, 6, 7 dont modélisées. Les phrases 2, 3 et 4 sont à compléter. Phrase 2 : deux messages sont introduits :  timerNumérotation envoyé par le publiphone au standard.  timeoutNumérotation envoyé par le standard au publiphone.  Utilisation du concept UML «send» pour envoyer un message Phrase 3 : Le standard renvoie un message sur l’état de la ligne.  État(Ligne) (où état peut être libre, occupé, en dérangement). Phrase 4 : Transition entre les états «communication» et «fin communication».
  • 242.
  • 243. Le diagramme d’états final est alors après ajouts et compléments :
  • 244. Le diagramme d’états final est alors après ajouts et compléments : décroché introPièce(p)/incrémenterCrédit(p) When(crédit  1€) /send standard.timerNumérotation attente pièce phrase4 Fin timeoutNumérotation raccrochage appelé communication ou erreur UT[créditInsuffisant] attente N° /taxer UT[crédit Numéro composerNuméro Insuffisant] Communication /send standard. invalide /taxer acheminerNuméro do /transmettrevoix débuterComm étatLigne(occupée) /taxer phrase3 timeoutappel attente attente décrochage numéroValide validité
  • 245. Le diagramme d’états final est alors après ajouts et compléments : décroché introPièce(p)/incrémenterCrédit(p) Décrocher When(crédit  1€) /send standard.timerNumérotationraccroché attente Combiné pièce /crédit=0 phrase4 Fin timeoutNumérotation raccrochage appelé communication ou erreur UT[créditInsuffisant] attente N° raccrocherCombi /taxer né /rendrePièce UT[crédit Numéro composerNuméro Insuffisant] Communication /send standard. invalide /taxer acheminerNuméro do /transmettrevoix débuterComm étatLigne(occupée) /taxer phrase3 timeoutappel attente attente décrochage numéroValide validité
  • 246. UML : Unified Modeling Language Conclusion : • UML intègre l’objet et a été conçu pour et autour de l’objet. • UML permet donc de modéliser une application selon une vision objet. • L’appréhension d’UML est complexe car UML est à la fois : - une norme, - un langage de modélisation objet, - un support de communication, - un cadre méthodologique. • Il faut penser ce langage comme une boite à outils riche et complexe; à utiliser intelligemment face à des besoins précis.
  • 247. UML : Unified Modeling Language
  • 248. UML : Unified Modeling Language FIN