La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

Modélisation par UML 1 Denis Laurendeau, P.h.D., ing. Département de génie électrique et de génie informatique Modélisation en langage UML.

Présentations similaires


Présentation au sujet: "Modélisation par UML 1 Denis Laurendeau, P.h.D., ing. Département de génie électrique et de génie informatique Modélisation en langage UML."— Transcription de la présentation:

1 Modélisation par UML 1 Denis Laurendeau, P.h.D., ing. Département de génie électrique et de génie informatique Modélisation en langage UML

2 Modélisation par UML 2 UML UML: Unified Modeling Language BoochRumbaughTravail initié par G. Booch et J. Rumbaugh en 1994 Objectif: unifier les méthodes de modélisation de: –Booch –OMT de Rumbaugh Jacobson –OOSE de Jacobson Version 1.0 de UML apparaît en Janvier 1997 OMGL OMG a adopté UML comme langage de modélisation

3 Modélisation par UML 3 Objectifs de UML systèmes concepts orientés objetsModélisation de systèmes divers en utilisant des concepts orientés objets concepts implantationÉtablir un couplage entre les concepts et leur implantation échelle complexesAborder la description des problèmes d échelle propres aux systèmes complexes humainsmachinesOffrir une approche de description utilisable par les humains et les machines

4 Modélisation par UML 4 Usages de UML Systèmes d informationSystèmes d information pour la présentation d informations diverses à des usagers Systèmes techniquesSystèmes techniques pour la commande d équipements Systèmes temps-réelSystèmes temps-réel embarqués Systèmes répartisSystèmes répartis sur des réseaux (locaux ou non) Systèmes logicielsSystèmes logiciels (exploitation, bases de données, interfaces GUI,etc.) Systèmes commerciauxSystèmes commerciaux (description de la structure et du fonctionnement des entreprises: règles, stratégies, politiques, etc)

5 Modélisation par UML 5 Étapes de développement d un système besoinspoints fonctionnelsAnalyse des besoins: recherche des points fonctionnels (Use Cases) AnalyseAnalyse (recherche des abstractions principales composant le système: classes et objets) ConceptionConception des abstractions principales et implantation d abstractions secondaires ProgrammationProgrammation des abstractions dans un langage orienté objet TestsTests du système

6 Modélisation par UML 6 Types de visualisation dans UML Composantes Concurrence Répartition Use-Case Logique

7 Modélisation par UML 7 Use Cases » Visualisation « Use Cases » Use-Case

8 Modélisation par UML 8 Use cases fonctionnalitéDécrivent la fonctionnalité d un système clients concepteursresponsables développement responsablestestsSadressent aux clients, concepteurs, responsables du développement, responsables des tests point fonctionnelUn Use Case décrit un point fonctionnel du système fonctionnement global lensemble des Use CasesLe fonctionnement global du système est décrit par lensemble des Use Cases

9 Modélisation par UML 9 Use Cases dans UML ellipseSont représentés par une ellipse dans laquelle est inscrit le nom du Use Case acteurSont généralement connectés à un acteur avec une association Symbole UML d un Use Case Symbole UML d un acteur Symbole UML d une association

10 Modélisation par UML 10 Liens entre Use Cases extends« extends » signifie qu un Use Case est une spécialisation d un autre Use Case plus général. Le Use Case plus spécifique n inclut pas nécessairement tout le comportement du Use Case qu il spécialise uses« uses » signifie qu un Use Case utilise intégralement la fonctionnalité du Use Case plus général en plus de lui ajouter des fonctionnalités additionnelles

11 Modélisation par UML 11 Description d un Use Case ObjectifsObjectifs du Use Case FlotmessagesacteurUse CaseFlot des messages entre l acteur et le Use Case Flot secondaireFlot secondaire des messages entre l acteur et le Use Case Condition de fininformation retournéeCondition de fin pour le Use Case et information retournée à l acteur lors qu il se termine

12 Modélisation par UML 12 Quest-ce quun bon Use Case fonctionnalité complèteUn bon Use Case représente une fonctionnalité du système qui est complète du début jusqu à la fin. résultat tangibleUn bon Use Case doit normalement apporter quelque chose de valable à un acteur (i.e. un résultat tangible à une de ses commandes ou à une de ses actions sur le système. grosseurIl n y a pas de consensus sur la « grosseur » que devrait prendre un Use Case en termes de fonctionnalité.

13 Modélisation par UML 13 Logique » Visualisation « Logique » Logique

14 Modélisation par UML 14 Types de visualisation logique statique Visualisation statique dynamique Visualisation dynamique

15 Modélisation par UML 15 statique Visualisation statique de Classesd'Objets Diagrammes

16 Modélisation par UML 16 dynamique Visualisation dynamique d'étatsséquentielsde collaborationd'activité Diagrammes

17 Modélisation par UML 17 Vision statique classes Diagrammes de classes

18 Modélisation par UML 18 Classesobjets Classes et objets classegénérique catégorieUne classe sert à décrire de manière générique une catégorie d objets participant aux actions du système objet variabletype procéduralUn objet est relié à une classe de la même manière qu une variable est associée à un type de données dans un langage de programmation procédural classesobjetsrelationsLes fondements de la programmation orientée objet sont les classes, les objets, et les relations entre eux. classesobjetsrelations diagrammesUMLCes classes, objets, et relations sont représentés par des diagrammes en langage UML

19 Modélisation par UML 19 Diagramme de classes statiqueest un modèle statique du système classes relationsdécrit le système en termes de ses classes et des relations entre celles-ci basesert de base aux autres diagrammes où d autres facettes du système sont décrites (tels les diagrammes d états des objets ou les diagrammes de collaboration qui sont des diagrammes dynamiques)

20 Modélisation par UML 20 Recherche des classes créationLa recherche des classes est une étape de création. pour trouver les classes pertinentes à un problème, il faut se poser les questions suivantes: analyséestockée –Est-ce qu une information doit être analysée ou stockée? autres systèmes –Est-ce que le système interagit avec d autres systèmes? patronslibrairiescomposantes réutilisables –Existe-t-il des patrons, des librairies, ou des composantes réutilisables dans le système? périphériques –Le système doit-il manipuler des périphériques (« devices »)? acteurs –Quels rôles les acteurs jouent-ils? pièces structurales (parts) –Le système possède-t-il des pièces structurales (parts)?

21 Modélisation par UML 21 Types classiques de classes Entitycatégories d objets durée de vie importanteEntity: servent à modéliser des catégories d objets qui ont une durée de vie importante dans le système (i.e. elles sont des parties intégrantes du système) Boundarycommunication extérieurBoundary: servent à faciliter la communication des classes Entity avec l extérieur du système (soit un autre système, avec l utilisateur ou encore avec un périphérique) ControlcoordonnerControl: servent à coordonner les échanges de messages entre les autres classes pour réaliser un Use case

22 Modélisation par UML 22 Représentation des classes en UML classe rectangletrois compartimentsune classe est représentée par un rectangle divisé en trois compartiments: nom –le compartiment du nom attributs –le compartiment des attributs opérations –le compartiment des opérations indépendantela syntaxe dans les différents compartiments est indépendante des langages de programmation

23 Modélisation par UML 23 Compartiment de nom Contient le nom de la classe centré dans le compartiment imprimé en caractères gras Le nom ne doit pas être ambigu il doit être tiré du domaine propre au problème

24 Modélisation par UML 24 Compartiment des attributs attributscaractéristiques étatLes attributs servent à décrire les caractéristiques des objets appartenant à la classe (i.e. décrivent l état de l objet) chaque attribut possède: type –un type (primitif ou défini par l usager) niveau de visibilitépublicprotectedprivate –un niveau de visibilité (public (+), protected (#) ou private (-)) valeur par défaut –une valeur par défaut portéeclasse –optionnellement, on peut aussi indiquer qu un attribut possède une portée s appliquant à la classe (class scope) chaîne de propriétés –…et une chaîne de propriétés indiquant les valeurs que peut prendre l attribut

25 Modélisation par UML 25 Exemples de classe avec attributs Private (-) Protected (#) Public (+) type Valeur par défaut

26 Modélisation par UML 26 Compartiment des opérations opérationsmanipulerLes opérations permettent de manipuler les attributs et d effectuer d autres actions. Elles sont appelées pour des instances (objets) de la classe. signatureLa signature des opérations comprend: type –un type de retour nom –un nom paramètres –0 ou plus paramètres (ayant chacun un type, un nom et possiblement une valeur par défaut) visibilité –une visibilité (private(-), protected(#), public(+)) interfaceLes opérations constituent l interface de la classe avec le monde extérieur

27 Modélisation par UML 27 Exemple de classe avec opérations Méthodes public

28 Modélisation par UML 28 Spécification de l opération Pré-conditionsPré-conditions: doivent être vérifiées avant que l algorithme ne s exécute Post-conditionsPost-conditions: doivent être vraies une fois l opération complétée AlgorithmeAlgorithme: effet que l opération a sur l objet

29 Modélisation par UML 29 Relations entre les classes relationsUn diagramme de classes montre les classes d un système mais également les relations entre celles- ci: quatreOn compte quatre principales catégories de relations entre classes: associations –les associations généralisations –les généralisations (héritage) dépendances –les dépendances raffinements –les raffinements

30 Modélisation par UML 30 associations Les associations de classes

31 Modélisation par UML 31 Les associations typesIl existe plusieurs types d associations: normalenormale récursiverécursive agrégationréférenceagrégation par référence agrégationcompositionagrégation par composition

32 Modélisation par UML 32 Association normale connexionUne association normale est une connexion entre classes nomelle possède un nom navigableelle est généralement navigable de manière bidirectionnelle (dans ce cas elle a un nom dans les deux sens si nécessaire) multiplicitéelle a une multiplicité rôleselle peut être dotée de rôles

33 Modélisation par UML 33 Association récursive elle-mêmeUne classe peut être connectée à elle-même via une association récursive connexion sémantique même classeelle représente une connexion sémantique entre des objets mais avec la différence que ceux-ci appartiennent à la même classe

34 Modélisation par UML 34 agrégations Les agrégations de classes

35 Modélisation par UML 35 Agrégation par référence tout- partieIndique une relation tout- partie losangese représente par une ligne avec un losange du côté « tout » de l agrégation. Ce losange ne peut apparaîtra qu à une seule extrémité rôles multiplicitéelle possède des rôles, multiplicité, etc, comme une association normale

36 Modélisation par UML 36 Agrégation par composition tout- partie avec inclusion « physique »Indique une relation tout- partie avec inclusion « physique » losangepleinse représente par une ligne avec un losange plein du côté « tout » de l agrégation. Ce losange ne peut apparaîtra qu à une seule extrémité rôles multiplicitéelle possède des rôles, multiplicité, etc, comme une association normale

37 Modélisation par UML 37 généralisations Les généralisations de classes

38 Modélisation par UML 38 Les généralisations relation généralespécifiqueUne généralisation est une relation entre une classe générale et une classe plus spécifique spécifique sous-classela classe spécifique est appelée sous-classe générale super-classela classe générale est appelée super-classe hérite attributs opérationsla sous-classe hérite des attributs et opérations de la super-classe (en fonction de la visibilité de la généralisation) sous-classesuper-classe hiérarchieune sous-classe peut être la super-classe d une autre classe dans ce que l on appelle une hiérarchie

39 Modélisation par UML 39 Représentation des généralisations généralisations flècheOn représente les généralisations par une flèche allant de la classe spécifique à la classe générale héritage multipleLorsqu une classe spécifique hérite de plusieurs super-classes, on dit qu il y a héritage multiplegénéralisation

40 Modélisation par UML 40 Interfaces interfaces opérationsimplantationLes interfaces sont des classes contenant seulement des opérations sans implantation. implanterUne classe peut implanter une interface flèche pointillée versLe symbole d implantation est une flèche pointillée allant de la classe vers l interface Ici, la classe A implante les interfaces Storable et Runnable et B utilise ces implantations

41 Modélisation par UML 41 Vision statique Packages Les Packages

42 Modélisation par UML 42 Les Packages packagesPour les systèmes comprenant plusieurs classes, il convient de regrouper celles-ci en entités logiques, les packages ensemble de packages classesUn package est un ensemble de packages et de classes reliés sémantiquement entre eux interface classes publicChaque package est muni d une interface (ses classes public) qui lui permet de communiquer sa fonctionnalité aux autres packages qui peuvent l importer

43 Modélisation par UML 43 Les Packages (suite…) dossierUn package est représenté par un dossier (folder) niveau de visibilité relationsdépendance raffinementgénéralisationLes Packages ont eux aussi un niveau de visibilité est des relations qui sont ici: la dépendance, le raffinement, et la généralisation

44 Modélisation par UML 44 Vision statique Templates Les Templates

45 Modélisation par UML 45 Les Templates templates parameterized classesUML supporte les templates (aussi appelés « parameterized classes ») symbole de classe avec un ajout identifiantIls sont symbolisés par un symbole de classe avec un ajout identifiant le fait que le template doit être « instancié » avant de pouvoir créer des objets de la classe correspondant au template « Instanciation » Raffinement

46 Modélisation par UML 46 Qualités Qualités d un modèle statique communiqué membres de l équipe clientLe modèle peut-il être communiqué aux autres membres de l équipe de même qu au client ? utilitéLe modèle a-t-il une utilité pour décrire le système? caractères essentielsLe modèle embrasse-t-il les caractères essentiels du système (permet-il entre autres de bien répéter les use-cases? noms des classes noms des éléments du systèmeLes noms des classes du modèle reflètent-ils les noms des éléments du système (i.e. les noms sont- ils pertinents)? modèles différents même chose intégréscoordonnésDes modèles différents de la même chose sont-ils intégrés et coordonnés entre eux? simplesLes modèles sont-ils simples (même pour les systèmes complexes?

47 Modélisation par UML 47 Ouf Ouf...

48 Modélisation par UML 48 Dynamique » Visualisation « Dynamique »

49 Modélisation par UML 49 Modélisation dynamique objets collaborent fonctionnalitéSert à montrer comment les objets d un système collaborent pour réaliser une fonctionnalité du système. objets messages le client opération le serveur interactionsMontre comment les objets s échangent des messages (i.e. comment un objet, le client, invoque une opération sur un autre objet, le serveur). Ces échanges sont appelés interactions. diagrammesLes interactions sont montrées via trois principaux diagrammes: –séquence –collaboration –activité Un autre diagramme, le diagramme d état décrit le comportement d un objet mais cette fois-ci pris isolément.

50 Modélisation par UML 50 Les 4 modèles dynamiques Diagramme d étatsétats comportement événementschangement d étatDiagramme d états: décrit les états que peut prendre un objet durant son cycle d existence et le comportement de ces états de même que les événements qui provoquent un changement d état de l objet Diagramme séquentiel interagissentcommuniquent tâche tempsDiagramme séquentiel : montre comment les objets interagissent et communiquent entre eux pour accomplir une tâche du système. La variable indépendante est ici le temps.

51 Modélisation par UML 51 Les 4 modèles dynamiques (suite…) Diagramme de collaboration interagissentcommuniquent tâche l espace liensDiagramme de collaboration: montre comment les objets interagissent et communiquent entre eux pour accomplir une tâche du système. La variable indépendante est ici le l espace. Par espace on entend ici les relations (liens) entre les objets dans le système. Diagramme d activité interagissentcommuniquent tâche le travail accompli par les objets.Diagramme d activité: montre comment les objets interagissent et communiquent entre eux pour accomplir une tâche du système. La variable indépendante est ici le le travail accompli par les objets.

52 Modélisation par UML 52 Interactions entre les objets (messages) messagesEn programmation orientée objet, les interactions entre les objets sont modélisées comme des messages envoyés d un objet à un autre appels d opérations valeur de retourCes messages sont simplement des appels d opérations d un objet par un autre avec le contrôle qui revient à l objet appelant avec une valeur de retourSynchrone Asynchrone Simple Synchrone avec retour immédiat

53 Modélisation par UML 53 diagramme d états Le diagramme d états

54 Modélisation par UML 54 Le diagramme d états cycle de vieobjetssous- systèmessystèmesIl sert à décrire le cycle de vie d objets, de sous- systèmes, et de systèmes états événementsmessages reçustemps écouléoccurrence d erreursconditions logiquement vraiesIl montre les états que les objets peuvent prendre et comment les événements (messages reçus, temps écoulé, occurrence d erreurs, conditions logiquement vraies) comportement évolueétat présentUn tel diagramme doit être associé à toute classe dont les objets peuvent prendre des états identifiables. Il décrit le comportement de ces objets et comment celui-ci évolue en fonction de l état présent

55 Modélisation par UML 55 Exemple Nom de l état Transition Actions Etat de départ

56 Modélisation par UML 56 Diagrammes d états - détails un seulpoint de départplusieurspoints d arrivéeCes diagrammes peuvent avoir un seul point de départ et plusieurs points d arrivée départ disqueUn point de départ est symbolisé par un disque. arrivée cercle disqueUn point d arrivée est symbolisé par un cercle circonscrivant un disque état rectangle aux coins arrondisUn état est symbolisé par un rectangle aux coins arrondis transitions flècheLes transitions sont symbolisées par une flèche Point de départ Point d arrivée Etat Transition

57 Modélisation par UML 57 Etats UML3 2 RoseEn UML, un état comprend 3 compartiments. Seulement 2 sont disponibles dans Rose (notation de State Charts de Harel). premier nomLe premier compartiment contient le nom de l état second actions événements entrant entrydurantdo quittantexit conditionLe second compartiment contient les actions (aussi appelées événements) effectuées en entrant (entry), durant (do), en quittant l état (exit), ou sur une condition événements actions sendLes événements peuvent être des actions (do) ou des « send » Actions Send

58 Modélisation par UML 58 Etats (suite…) actions La syntaxe pour les actions dans un état est la suivante: Event-name argument list / action expression transition La syntaxe pour la transition entre les états est la suivante: Event-signature [guard-condition] / action expression ^ send-clause Event-name (parameter, parameter,...) Destination-expression.destination-event-name (argument,...)

59 Modélisation par UML 59 La signature des événements nomliste de paramètresElle consiste en un nom d événement, une liste de paramètres séparés par des virgules. Le type des paramètres peut être indiqué comme suit: Parameter-name : type-expression, Parameter-name: type-expression,... Exemples: Dessine(f:Forme,c:couleur) redessine() redessine imprime(facture )

60 Modélisation par UML 60 Condition de garde expression booléenneC est une expression booléenne placée sur une transition d état. tous les deuxSi elle est combinée à un signature d événement, l événement et la condition de garde doivent tous les deux être vérifiés pour que la transition ait lieu. Exemples de conditions de garde: [t = 15 sec] [nombre de factures = 20] retrait(montant) [solde >= montant ] Conditions seules Avec événement

61 Modélisation par UML 61 Expression d action sur une transition action procédurale appel d opération paramètres dans la signature de l événementElle consiste à une action procédurale qui s exécute lors de la transition. Elle peut s exprimer comme un appel d opération sur l objet proprement dit ou comme paramètres dans la signature de l événement. plusieurs actionsIl peut y avoir plusieurs actions lors d une transition mais il faut les séparer par un « / » Exemples de transitions avec actions: Augmente()/n:=n+1/m:=m+1 additionne(n)/somme := somme + n /clignote Avec événement Sans

62 Modélisation par UML 62 La send-clause actionC est un cas spécial d action. durantElle utilise une syntaxe explicite pour illustrer l envoi d un message durant la transition entre deux états. Par exemple, l action suivante: [temps = max]/descend(premierEtage) peut s écrire avec la syntaxe de send-clause: [temps = max]^self.descend(premierEtage)

63 Modélisation par UML 63 Les événements actionReprésentent une chose qui se produit et qui peut déclencher une action. relation événementaction causaleLa relation entre un événement et une action est causale (i.e. ne peut être probabiliste) quatreUML considère quatre types principaux d événements: condition guard condition –Une condition qui devient « vraie » (représentée par une «guard condition ») réception signal message –la réception explicite d un signal par l objet (le signal est lui-même un objet). On appelle ceci un message) appel dopération message –la réception dun appel dopération par un autre objet (ou par lobjet lui- même). Il s agit également d un message) écoulement temps expression temporelle –l écoulement d une période de temps donnée (représentée par une expression temporelle sur la transition)

64 Modélisation par UML 64 Exemple d un diagramme d état

65 Modélisation par UML 65 diagramme séquentiels Le diagramme séquentiels

66 Modélisation par UML 66 séquentiels Les diagrammes séquentiels objetsIls illustrent comment les objets interagissent entre eux. séquence des messages envoyés entre les objetscomment quandIls se concentrent sur la séquence des messages envoyés entre les objets (c est-à-dire comment et quand les messages sont envoyés et reçus entre les objets) deux axesaxe vertical tempsaxe horizontal objets en interaction scénarioscèneIls possèdent deux axes: l axe vertical montre le temps tandis que l axe horizontal montre l ensemble des objets en interaction dans un scénario ou une scène spécifique d un scénario.

67 Modélisation par UML 67 séquentiels... Les diagrammes séquentiels... formesIls peuvent être utilisés sous deux formes: –forme génériquetous branchementsconditionsboucles –forme générique: elle décrit tous les déroulements possibles d un scénario et peut contenir des branchements, des conditions, et des boucles. –forme d instanciation aspect spécifique aucunbranchement conditionboucle –forme d instanciation: elle décrit le comportement du système pour un aspect spécifique d un scénario et ne peut donc contenir aucun branchement et aucune condition ou boucle.

68 Modélisation par UML 68 Les messages dans les diagrammes séquentiels communication information actionIls représentent une communication entre objets véhiculant une information avec l anticipation qu une action sera entreprise (comme pour les diagramme d états) réceptionmessage événementLa réception d un message est généralement appelée événement. messagessignaux appels d opération RPCRMILes messages peuvent être des signaux («signals»), des appels d opération (ou quelque chose de semblable comme un RPC ou une RMI en Java)

69 Modélisation par UML 69 Les messages... Quand un objet reçoit un message, on dit qu il entre dans sa phase d activation. Un objet dans cette phase peut: –exécuter son propre code –attendre les résultats retournés par un autre objet à qui il a envoyé un message L activation d un objet est représentée par un rectangle étroit sur la ligne de vie de l objet L exemple suivant montre un diagramme séquentiel simple pour les échanges entre une imprimante et un ordinateur

70 Modélisation par UML 70 Diagramme des classes de l exemple

71 Modélisation par UML 71 Diagramme séquentiel de l exemple Message synchrone Nom du message Retour Lignes de vie Activation de l objet Objets

72 Modélisation par UML 72 collaboration Le diagramme de collaboration

73 Modélisation par UML 73 collaboration Les diagrammes de collaboration interactionsliensLes diagrammes de collaboration montrent les interactions et les liens entre un ensemble d objets participant à un scénario. aspect spatialIls focalisent leur attention sur l aspect spatial des interactions. réalisation de use-casesIls sont particulièrement utiles pour montrer la réalisation de use-cases (sans que les aspects temporels des interactions ne soient nécessairement rendus explicites).

74 Modélisation par UML 74 Les diagrammes de... objetsclasses nomssoulignésLes objets sont dessinés comme des classes mais leurs noms sont soulignés. lienslignesLes liens sont illustrés par des lignes (qui ressemblent à des lignes d associations dans les diagrammes de classes mais sans les informations de multiplicité). messageétiquette sens ordonnancementUn message, accompagné d une étiquette, peut être associé à un lien pour montrer le sens et l ordonnancement de la transmission du message.

75 Modélisation par UML 75 Les diagrammes de... Les étiquettes de message associées aux liens adoptent la syntaxe suivante: Predecessor guard-condition sequence-expression return-value := signature synchronisation de threads Expression pour la synchronisation de threads signifiant que les messages reliés à des numéros de séquence spécifiques doivent être traités avant que le message courant soit transmis. Condition Condition à vérifier avant de transmettre le message Syntaxe: [condition] Syntaxe: [integer] | name] [recurrence] : integer: numéro dans la séquence name: thread de contrôle recurrence: répétition. Syntaxe: * [iteration-clause] [condition-clause] signature La «return-value» doit être affectée à la valeur retournée par la signature du message

76 Modélisation par UML 76 liens Les liens dans les diagrammes de collaboration lienconnexionUn lien indique une connexion entre deux objets. rôleLe rôle de chaque objet peut être inclus aux extrémités de la connexion avec les qualificatifs du lien (rappel: les rôles et qualificatifs sont aussi inclus dans le diagramme de classe) stéréotypeLe stéréotype du lien peut aussi être inclus dans la connexion. stéréotypesOn compte les stéréotypes suivants: –globallocalparameterselfvotebroadcast –global, local, parameter, self, vote, broadcast

77 Modélisation par UML 77 stéréotypesliens Les stéréotypes de liens Global globaleGlobal: associé à un rôle du lien pour montrer que l instanciation en présence est globale (visible dans tout le système). LocalLocal: associé à un rôle du lien pour montrer que l instanciation est une variable locale dans une opération. ParameterParameter: montre que l instance est visible parce que c est un paramètre d une opération SelfSelf: montre qu un objet peut s envoyer des messages VoteVote: contrainte imposée à un message limitant l éventail des valeurs de retour (spécifie que la valeur de retour est choisie au vote majoritaire entre différentes valeurs de retour) BroadcastBroadcast: contrainte appliquée à un ensemble de messages pour signifier qu ils ne sont pas exécutés dans un ordre donné

78 Modélisation par UML 78 Classes Exemple pour lascenseur : Classes

79 Modélisation par UML 79 Collaboration Exemple pour lascenseur :Collaboration

80 Modélisation par UML 80 d activité Le diagramme de d activité

81 Modélisation par UML 81 Le diagramme d activités implantationFocalise son attention sur l implantation des opérations dans les classes. activité interneReprésente donc une façon de visualiser l activité interne d un objet non pas en fonction des ses changements d états mais plutôt en termes des activités effectuées dans ces états. actions lignes de code.L implantation d une opération est vue comme une suite d actions reliées entre elles. Ces actions sont par la suite transcrites en lignes de code.

82 Modélisation par UML 82 Le diagramme d activités actions rectangles aux coins arrondis.Les actions sont représentées par des rectangles aux coins arrondis. transitions flèchesLes transitions entre les actions sont représentées par des flèches. un départun plusieursarrivéeLe diagramme comprend un point de départ et un ou plusieurs points d arrivée. événementUn événement peut accompagner la transition du point de départ seulement conditions de garde send-clauses actionsDes conditions de garde, des «send-clauses », et des actions peuvent accompagner les transitions entre les actions. boîtes de décisionDes boîtes de décision (losanges) peuvent faire partie du diagramme. actions concurremmentDes actions peuvent être exécutés concurremment en les plaçant en parallèle sur le diagramme.

83 Modélisation par UML 83 Le diagramme d activités. Exemple... Send-clause Action Transition Départ Arrivée Événement Classe

84 Modélisation par UML 84 Ouf Ouf...

85 Modélisation par UML 85 physique Architecture « physique »

86 Modélisation par UML 86 physique Architecture physique architecture physique hardwaresoftwareL architecture physique du système s intéresse à la description détaillée de celui-ci sur les plans du hardware et du software. hardware nœuds de calculliensElle illustre la structure du hardware en incluant les différents nœuds de calcul et les liens entre ceux-ci structure dépendances distribution processusprogrammes composantesElle montre également la structure, les dépendances entre modules de logiciel qui implantent les concepts et les algorithmes de la description logique, et la distribution de ces modules en termes de processus, programmes et composantes.

87 Modélisation par UML 87 physique Architecture physique... L architecture physique répond aux questions suivantes: programmesprocessusclasses objetsrésidentphysiquement –Dans quels programmes ou processus les classes et objets du modèle logique résident-ils physiquement? processeurprogrammesprocessus exécutent –Sur quel(s) processeur(s) ces programmes et processus s exécutent-ils? types d ordinateurs physiquement –Quels types d ordinateurs composent le système et comment sont-ils reliés physiquement? dépendancesfichiers packages –Quelles sont les dépendances entre les différents fichiers ou packages de classes (lors d un changement de fichier, quels autres fichiers doivent être recompilés)?

88 Modélisation par UML 88 physique Architecture physique... Mapping Composantes, Processus Ordinateurs Physique Classes, Objets, Mécanismes, Messages, Algorithmes, Logique

89 Modélisation par UML 89 Diagrammes Diagrammes de l architecture physique UML deuxdiagrammesEn UML, l architecture physique est principalement décrite par deux diagrammes: diagramme des composantescomponent diagramcomposantes logicielles –le diagramme des composantes (« component diagram »): contient les composantes logicielles du projet (unités de code et fichiers concrets-binaires et sources). diagramme de déploiementdeployment diagram » dispositifs physiquesordinateurs processeurslogiciel –le diagramme de déploiement (« deployment diagram »): décrit l architecture physique du run-time du système en couvrant les dispositifs physiques (ordinateurs, processeurs, etc.) et le logiciel qui leur est respectivement associé.

90 Modélisation par UML 90 hardware Le hardware hardware troisLa partie hardware d un système est divisée en trois éléments: processeurs –Les processeurs: ce sont les ordinateurs qui exécutent les programmes du système. devices –Les «devices»: ce sont les périphériques de support tels les imprimantes, routeurs, lecteurs de disquettes/CD, etc. Ils sont généralement connectés à un processeur qui les contrôle. Il y a souvent peu de différence entre un processeur et un device. connexions –Les connexions: ce sont les liens physiques entre les processeurs (câbles-fibre optique et/ou protocoles p.e. TCP/IP)

91 Modélisation par UML 91 software Le software UMLpackages de classesEn UML, un système logiciel est divisé en packages de classes package classesgroupe logiqueUn package rassemble un certain nombre de classes en un groupe logique mais ne définit aucune sémantique pour le groupe. composantesfaçade seule partie visible interfaceIl est fréquent d utiliser une ou quelques composantes du package comme façade du groupe. Cette façade est la seule partie visible du groupe à l extérieur du package et constitue son interface. interfacedépendance modulesSeule l interface possède une dépendance avec d autres modules.

92 Modélisation par UML 92 software... Le software... packagepackage de façade représentantUn package contient un package de façade qui références d autres éléments mais qui ne contient lui-même aucun élément. Il est en quelque sorte le représentant de son package. stéréotypefaçadeUMLOn lui donne le stéréotype « façade » en UML. classe d interface classeclasse de façadeIl est aussi possible d utiliser une classe d interface au package au lieu d un package de façade. Cette classe devient une classe de façade.

93 Modélisation par UML 93 software... Le software... Les principaux concepts servant à décrire la partie software d un système sont: composantescomponents packaging physique –Les composantes (« components »): elles sont des parties réutilisables qui offrent le packaging physique d un ensemble d instanciations d éléments du modèle (par exemple, un fichier source) qui implantent des éléments du modèle logique. processusthreads flots de contrôleheavyweight lightweightclasses actives stéréotypéesobjets actifs component exécutable –Les processus et les threads: ils représentent respectivement des flots de contrôle « heavyweight » et « lightweight ». Les deux sont décrits comme des classes actives stéréotypées et les objets actifs correspondent à un component exécutable. objetspassifssans –Les objets: les objets passifs sont ceux sans thread propre.

94 Modélisation par UML 94 software... Le software... Deuxdiagrammes physiquementDeux principaux diagrammes servent à décrire physiquement les systèmes: composantescomponents les diagrammes de composantes (« components ») répartitiondeployment les diagrammes de répartition (« deployment » )

95 Modélisation par UML 95 composantes « component diagram » Le diagramme de composantes (« component diagram »)

96 Modélisation par UML 96 Le diagramme de composantes composantes logicielles interdépendanceIl décrit les composantes logicielles et leur interdépendance. structurecodeIl représente par conséquent la structure du code. composantesimplantations physiquesconceptsfonctionnalités modèle logique classesobjetslienscollaborationsLes composantes sont les implantations physiques des concepts et fonctionnalités définis dans le modèle logique du système (i.e., les classes, les objets, les liens et les collaborations). composantesfichiers d implantationLes composantes sont typiquement les fichiers d implantation des éléments logiques du système.

97 Modélisation par UML 97 Les composantes UMLcomposantesUML définit trois types principaux de composantes: composantes sources compilation classes –les composantes sources: ce type de composante prend toute sa signification lors de la compilation. Elle est un fichier source implantant une ou plusieurs classes. composantes binairescode objetcompilation des sources fichier objetlibrairie statique librairie dynamiquecomposante binaire édition des liens librairies statiquesrun-time librairies dynamiques –Les composantes binaires: elles représentent le code objet résultant de la compilation des sources. Il peut s agir d un fichier objet, d une librairie statique, ou d une librairie dynamique. Une composante binaire prend toute sa signification lors de l édition des liens, dans le cas des librairies statiques, ou au run-time, dans le cas des librairies dynamiques. composantes exécutablesprogrammes composantes binaires –Les composantes exécutables: programmes résultant de l édition des liens des composantes binaires.

98 Modélisation par UML 98 Les composantes... UMLcomposante grand rectangleellipsedeux petits rectanglesEn UML, une composante est représentée par un grand rectangle avec une ellipse et deux petits rectangles placés à la gauche du grand rectangle. nomLe nom de la composante est inscrit en dessous ou à l intérieur du grand rectangle. composantestypes exécutables instanciéesLes composantes sont des types et seules les composantes exécutables peuvent être instanciées. diagramme de répartitionLes composantes instanciées sont montrées dans un diagramme de répartition où les différences instances de ces composantes sont allouées et où le processeur sur lequel elles s exécutent est montré.

99 Modélisation par UML 99 Les composantes... dépendances ligne pointilléeflèche simpleLes dépendances entre composantes sont illustrées par une ligne pointillée avec une flèche simple. dépendance définition complèteUne dépendance signifie qu une composante a besoin d une autre pour que sa définition soit complète. compiléDans un langage compilé, si un module A dépend d un module B, cela signifie que module A doit être recompilé si des changements sont apportés à B. exécutablesSi les composantes sont exécutables, les dépendances montrent les librairies dynamiques qui sont nécessaires lors de l exécution d un programme.

100 Modélisation par UML 100 Les composantes... composanteinterfaceUne composante peut avoir une interface qui est visible aux autres composantes. interfaces code source code exécutableCes interfaces peuvent être définies au niveau du code source (comme en Java) ou au niveau du code exécutable utilisable au run-time (comme en OLE). interfaceligne cercleUne interface est montrée par une ligne terminée par un cercle. nominterfaceLe nom de l interface est inscrit près de ce cercle.

101 Modélisation par UML 101 composantes de code source Exemple de diagramme de composantes de code source Composante Dépendance

102 Modélisation par UML 102 composantes run-time Exemple de diagramme de composantes run-time

103 Modélisation par UML 103 répartition « deployment diagram » Le diagramme de répartition (« deployment diagram ») Répartition

104 Modélisation par UML 104 répartition Le diagramme de répartition architecture run-time processeurspériphériques composantes logiciellesCe diagramme montre l architecture run-time des processeurs, des périphériques, et des composantes logicielles qui s exécutent sur cette architecture. description finaletopologie du systèmehardware softwareIl est la description finale de la topologie du système car il unit les facettes hardware et software du système. nœud composantes structures logiquesDans ce type de diagramme, il devrait être possible d observer un nœud de la topologie et de voir les composantes qui s y exécutent, et quelles structures logiques sont implantées dans ces composantes.

105 Modélisation par UML 105 répartition Diagramme de répartition... Il comprend: nœuds –des nœuds connexions –des connexions composantes –des composantes objets –des objets

106 Modélisation par UML 106 répartition Diagramme de répartition... Nœudsphysiques puissance de calcul nœuds typesinstanciations de typesnœud cube en trois dimensions nomNœuds: unités physiques (matérielles) dotées d une puissance de calcul donnée (processeurs, imprimantes,lecteurs de cartes, périphériques de communication, etc). Les nœuds peuvent être des types ou des instanciations de types. Un nœud est représenté par un cube en trois dimensions avec son nom à l intérieur (souligné si c est une instanciation) périphériques nœudsstéréotypeLes périphériques sont aussi représentés par des nœuds avec un stéréotype ou au moins un nom qui indique clairement que le nœud n en est pas un de calcul.

107 Modélisation par UML 107 répartition Diagramme de répartition…exemple simple Nœud Lien Périphérique (device) Process Scheduling

108 Modélisation par UML 108 Ouf Ouf...

109 Modélisation par UML 109 proxy Un dernier exemple: le pattern proxy en UML

110 Modélisation par UML 110 proxy Un dernier exemple: le pattern proxy en UML

111 Modélisation par UML 111 Processus de développement et UML

112 Modélisation par UML 112 Processus de développement Processus de développement de logiciel UMLmodélisationUML est un outil de modélisation de systèmes. développementprocessusorienté objetoutilméthodeIl doit être utilisé dans un contexte de développement contrôlé par un processus orienté objet bien établi. Un outil n est pas une méthode. méthodeorientée objettrois basesUne méthode de design orientée objet repose sur trois bases: notationmodèles –une notation permettant de décrire les modèles; processusmodèles –un processus de construction des modèles; outils –des outils facilitant la construction et la description des modèles.

113 Modélisation par UML 113 Le processus Le processus permet de... exigences fonctionnellesrespecter les exigences fonctionnelles (parfois informelles) du système; conformer aux limitesse conformer aux limites de la machine exécutant le logiciel; ressources disponiblesse conformer aux ressources disponibles; critères de designsatisfaire des critères de design; contrainteslimites processus de designsatisfaire les contraintes et les limites du processus de design lui-même (un design doit être effectué dans un temps raisonnable).

114 Modélisation par UML 114 Le processus Le processus doit permettre de limiter complexitéproblèmela complexité du problème; complexitéprocessusla complexité de gestion du processus de conception du logiciel par une équipe d'ingénieurs: plusieurs solutions sont possibles et il faut choisir la meilleure; complexitéflexibilitéla complexité associée à la flexibilité offerte par le logiciel; complexité systèmes discrets.la complexité associée à la difficulté de décrire des systèmes discrets.

115 Modélisation par UML 115 Le processus Le processus doit tenir compte du fait que... systèmesstructure hiérarchiqueLes systèmes adoptent une structure hiérarchique. composantes de base arbitraireLe choix des composantes de base de ces systèmes est généralement arbitraire; liensintra-composantes liensinter-composantesLes liens intra-composantes sont généralement plus forts que les liens inter-composantes; systèmes sous-systèmesarrangés combinésLes systèmes sont généralement composés d'un nombre restreint de sous-systèmes arrangés de diverses manières ou combinés de façons diverses; systèmessimplesLes systèmes découlent de systèmes plus simples dont ils sont une évolution.

116 Modélisation par UML 116 OOA-OOD-OOP

117 Modélisation par UML 117 OOA-OOD-OOP analyse orientée objet classesd'objetsL analyse orientée objet (OOA) est une méthode qui examine les exigences d'un projet dans une perspective de classes et d'objets tirés du domaine de l'application. conception orientée objetdesign décompositionobjetsnotation modèles logiques/physiquesstatiques/ dynamiquesLa conception orientée objet (OOD) est une méthode de design comprenant un processus ce décomposition par objets et une notation permettant de dépeindre les modèles logiques/physiques et statiques/ dynamiques du système en cours de développement. programmation par objetsd'implantation un ensemble d'objets coopératifs hiérarchie relations d'héritageLa programmation par objets (OOP) est une méthode d'implantation par laquelle les programmes sont organisés en un ensemble d'objets coopératifs, chaque objet représentant une instance d'une classe, chaque classe faisant partie d'une hiérarchie de classes unies par des relations d'héritage.

118 Modélisation par UML 118 Modélisationobjets Modélisation par objets modélisationquatre principauxLa modélisation par objets comporte quatre éléments principaux: –l'abstractioncaractéristiques essentielles –l'abstraction: représentation des caractéristiques essentielles d'un objet qui permettent de le distinguer de tous les autres; –l'encapsulationcompartimentation –l'encapsulation: processus de compartimentation des éléments d'une abstraction qui constituent sa structure et son comportement; modularité cohérentsfaiblement couplés –la modularité: capacité qu'a un système d'être décomposé en un ensemble de modules cohérents et faiblement couplés; hiérarchieordonnancement –la hiérarchie: ordonnancement d'abstractions;

119 Modélisation par UML 119 Modélisationobjets Modélisation par objets troissecondaireset trois éléments secondaires: typage –le typage: renforcement de la classe d'un objet telle que des objets de types différents ne puissent pas être intervertis; concurrenceactifinactif –la concurrence: distingue un objet actif d'un objet inactif. Un objet actif en est un qui représente un thread et implique les notions de synchronisation avec d'autres objets, ce qui n'est pas le cas des objets inactifs qui ne nécessitent pas de synchronisation temporelle avec les autres objets; durabilité temps l'espace –la durabilité: propriété grâce à laquelle un objet peut transcender le temps (i.e. l'objet continue d'exister après que son créateur soit mort) et/ ou l'espace (i.e. l'espace mémoire occupé par l'objet se modifie par rapport à celui où il a été créé).

120 Modélisation par UML 120 Modèle WATERFALL Exigences Design Implantation Test Maintenance Flop!!!

121 Modélisation par UML 121 Modèle WATERFALL(suite) !!!

122 Modélisation par UML 122 Méthode de conception Unified

123 Modélisation par UML 123 Unified Méthode d analyse Unified Développer un modèle du système (analyse) Développer un modèle du système (analyse) Établir les exigences centrales du projet (conceptualisation) Établir les exigences centrales du projet (conceptualisation) Concevoir une architecture du système (design) Concevoir une architecture du système (design) Raffiner l implantation du système (évolution) Raffiner l implantation du système (évolution) Apporter les correctifs au système final (entretien) Apporter les correctifs au système final (entretien)

124 Modélisation par UML 124 Unified Méthode d analyse Unified Identification des classes et des objets Identification des classes et des objets Identification de la sémantique des classes et des objets Identification de la sémantique des classes et des objets Identification de la relation entre les classes et les objets Identification de la relation entre les classes et les objets Définition de l interface et de l implantation des classes et des objets Définition de l interface et de l implantation des classes et des objets

125 Modélisation par UML 125 Application Application de la méthode Processus itératif Processus incrémental

126 Modélisation par UML 126 équipe Formation de l équipe Architecte Développeurs Ing. de réutilisation Contr. de qualité Superviseur Resp. doc.

127 Modélisation par UML 127

128 Modélisation par UML 128

129 Modélisation par UML 129

130 Modélisation par UML 130

131 Modélisation par UML 131

132 Modélisation par UML 132


Télécharger ppt "Modélisation par UML 1 Denis Laurendeau, P.h.D., ing. Département de génie électrique et de génie informatique Modélisation en langage UML."

Présentations similaires


Annonces Google