Modélisation en langage UML

Présentation au sujet: "Modélisation en langage UML"— Transcription de la présentation:

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

2 UML: Unified Modeling Language
Travail initié par G. Booch et J. Rumbaugh en 1994 Objectif: unifier les méthodes de modélisation de: Booch OMT de Rumbaugh OOSE de Jacobson Version 1.0 de UML apparaît en Janvier 1997 L ’OMG a adopté UML comme langage de modélisation Booch, Jacobson et Runbaugh sont tous les troi chez Rtional Software, la compagnie de Booch qui développe des produits pour la conception de systèmes orientés objets.

3 Objectifs de UML Modélisation de systèmes divers en utilisant des concepts orientés objets Établir un couplage entre les concepts et leur implantation Aborder la description des problèmes d ’échelle propres aux systèmes complexes Offrir une approche de description utilisable par les humains et les machines Analogie avec les walk-through en architecture.

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

5 Étapes de développement d ’un système
Analyse des besoins: recherche des points fonctionnels (Use Cases) Analyse (recherche des abstractions principales composant le système: classes et objets) Conception des abstractions principales et implantation d ’abstractions secondaires Programmation des abstractions dans un langage orienté objet Tests du système

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

7 Visualisation « Use Cases »

8 Use cases Décrivent la fonctionnalité d ’un système
S’adressent aux clients, concepteurs, responsables du développement, responsables des tests Un Use Case décrit un point fonctionnel du système Le fonctionnement global du système est décrit par l’ensemble des Use Cases

9 Use Cases dans UML Sont représentés par une ellipse dans laquelle est inscrit le nom du Use Case Sont 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 Liens entre Use Cases « 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 » 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 Description d ’un Use Case
Objectifs du Use Case Flot des messages entre l ’acteur et le Use Case Flot secondaire des messages entre l ’acteur et le Use Case Condition de fin pour le Use Case et information retournée à l ’acteur lors qu ’il se termine

12 Qu’est-ce qu’un bon Use Case
Un bon Use Case représente une fonctionnalité du système qui est complète du début jusqu ’à la fin. Un 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. Il n ’y a pas de consensus sur la « grosseur » que devrait prendre un Use Case en termes de fonctionnalité.

13 Visualisation « Logique »

14 Types de visualisation logique
Visualisation statique Visualisation dynamique

15 Visualisation statique
Diagrammes de Classes d'Objets

16 Visualisation dynamique
Diagrammes d'états séquentiels de collaboration d'activité

17 Vision statique Diagrammes de classes

18 Classes et objets Une classe sert à décrire de manière générique une catégorie d ’objets participant aux actions du système Un 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 Les fondements de la programmation orientée objet sont les classes, les objets, et les relations entre eux. Ces classes, objets, et relations sont représentés par des diagrammes en langage UML

19 Diagramme de classes est un modèle statique du système
décrit le système en termes de ses classes et des relations entre celles-ci sert 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 Recherche des classes La recherche des classes est une étape de création. pour trouver les classes pertinentes à un problème, il faut se poser les questions suivantes: Est-ce qu ’une information doit être analysée ou stockée? Est-ce que le système interagit avec d ’autres systèmes? Existe-t-il des patrons, des librairies, ou des composantes réutilisables dans le système? Le système doit-il manipuler des périphériques (« devices »)? Quels rôles les acteurs jouent-ils? Le système possède-t-il des pièces structurales (parts)?

21 Types classiques de classes
Entity: 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) Boundary: 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) Control: servent à coordonner les échanges de messages entre les autres classes pour réaliser un Use case Ces types classiques sont aussi des stéréotypes comme nous élaborerons plus loin.

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

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 Dans Rational Rose, si la classe est abstraite, son nom apparaît en italique

24 Compartiment des attributs
Les 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: un type (primitif ou défini par l ’usager) un niveau de visibilité (public (+), protected (#) ou private (-)) une valeur par défaut optionnellement, on peut aussi indiquer qu ’un attribut possède une portée s ’appliquant à la classe (class scope) …et une chaîne de propriétés indiquant les valeurs que peut prendre l ’attribut Par portée on entend que l'attribut est static à la classe. Un tel attribut est identifié avec des caractères soulignés. La chaîne de propriétés est simplement comme un enum plus général en C++ par exemple.

25 Exemples de classe avec attributs
type Private (-) Protected (#) Valeur par défaut Public (+) Évidemment, les classes doivent être documentées. Rose permet d ’ajouter du texte de commentaire descriptif pour les classes.

26 Compartiment des opérations
Les opérations permettent de manipuler les attributs et d ’effectuer d ’autres actions. Elles sont appelées pour des instances (objets) de la classe. La signature des opérations comprend: un type de retour un nom 0 ou plus paramètres (ayant chacun un type, un nom et possiblement une valeur par défaut) une visibilité (private(-), protected(#), public(+)) Les opérations constituent l ’interface de la classe avec le monde extérieur Une classe peut contenir des opérations de classe (i.e. des méthodes static qui sont les mêmes pour toutes les instances de la classe. Ces opérations sont identifiées par des caractères soulignés

27 Exemple de classe avec opérations
Méthodes public Une classe peut aussi avoir un stéréotype. Ceci permet de créer d'autres catégories d'éléments de modélisation. Les stéréotypes courants sont: -entity -boundary -control -utility -exception On peut en ajouter d'autres.

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

29 Relations entre les classes
Un diagramme de classes montre les classes d ’un système mais également les relations entre celles-ci: On compte quatre principales catégories de relations entre classes: les associations les généralisations (héritage) les dépendances les raffinements

30 Les associations de classes

31 Les associations Il existe plusieurs types d ’associations: normale
récursive agrégation par référence agrégation par composition

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

33 Association récursive
Une classe peut être connectée à elle-même via une association récursive elle représente une connexion sémantique entre des objets mais avec la différence que ceux-ci appartiennent à la même classe Il existe aussi des types d'associations plus spéciales tels: -qualified association -Or-association -ordered association -ternary associations Il y a aussi des classes d'associations

34 Les agrégations de classes

35 Agrégation par référence
Indique une relation tout-partie se 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é elle possède des rôles, multiplicité, etc, comme une association normale Ici, on a une association avec navigabilité de la classe train vers la classe wagon. Quand le tout disparaît, les parties ne disparaissent pas nécessairement et peuvent continuer d'exister sans celui-ci. Remarquez ici que la classe Wagon est abstraite.

36 Agrégation par composition
Indique une relation tout-partie avec inclusion « physique » se 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é elle possède des rôles, multiplicité, etc, comme une association normale Une association par composition implique que lorsque le tout est détruit, ses parties n'existent plus également et disparaissent avec lui. Faut-il choisir une agrégation par référence ou par composition? Rumbaugh mentionne que les deux sont OK et que c'est le choix du concepteur qui dicte une ligne à suivre à condition d'être logique.

37 Les généralisations de classes

38 Les généralisations Une généralisation est une relation entre une classe générale et une classe plus spécifique la classe spécifique est appelée sous-classe la classe générale est appelée super-classe la sous-classe hérite des attributs et opérations de la super-classe (en fonction de la visibilité de la généralisation) une sous-classe peut être la super-classe d ’une autre classe dans ce que l ’on appelle une hiérarchie Une classe peut être abstraite, ce qui signifie qu'il est impossible de créer des instances de cette classe. Une classe abtraite contient généralement des opérations abstraites. L'intérêt des classes abstraites est qu'elles servent à décrire des attributs communs entre catégories d'objets même si aucun objet n'est assez général pour exister dans un système réel. Les classes non abstraites héritant des classes abstraites doivent implanter toutes les opérations des super-classes ou autrement, elles deviennent elles-mêmes abstraites

39 Représentation des généralisations
On représente les généralisations par une flèche allant de la classe spécifique à la classe générale Lorsqu ’une classe spécifique hérite de plusieurs super-classes, on dit qu ’il y a héritage multiple généralisation

40 Interfaces Les interfaces sont des classes contenant seulement des opérations sans implantation. Une classe peut implanter une interface Le 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 Vision statique Les Packages

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

43 Les Packages (suite…) Un package est représenté par un dossier (folder) Les 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 Vision statique Les Templates

45 Les Templates UML supporte les templates (aussi appelés « parameterized classes ») Ils 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 Qualités d ’un modèle statique
Le modèle peut-il être communiqué aux autres membres de l ’équipe de même qu ’au client ? Le modèle a-t-il une utilité pour décrire le système? Le modèle embrasse-t-il les caractères essentiels du système (permet-il entre autres de bien répéter les use-cases? Les noms des classes du modèle reflètent-ils les noms des éléments du système (i.e. les noms sont-ils pertinents)? Des modèles différents de la même chose sont-ils intégrés et coordonnés entre eux? Les modèles sont-ils simples (même pour les systèmes complexes? Pour voir si notre modèle statique du système est valable, il suffit de se poser les questions suivantes. Même si le système est complexe, les modèles devraient demeurer simples, quitte à ajouter des modèles additionnels pour en décrire les différents aspects.

47 Ouf...

48 Visualisation « Dynamique »

49 Modélisation dynamique
Sert à montrer comment les objets d ’un système collaborent pour réaliser une fonctionnalité du système. Montre 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. Les 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. Le mot opération est ici pris dans le sens qu'on lui donne dans les classes. Un message est simplement une fonction membre qu'un objet (le client) invoque sur un autre objet (le serveur) qui lui retourne une valeur. Ces trois diagrammes montrent différents aspects des interactions selon des points de vue différents

50 Les 4 modèles dynamiques
Diagramme 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 : 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 Les 4 modèles dynamiques (suite…)
Diagramme 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é: 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 Interactions entre les objets (messages)
En programmation orientée objet, les interactions entre les objets sont modélisées comme des messages envoyés d ’un objet à un autre Ces 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 retour Synchrone Asynchrone Simple Synchrone: le message envoyé de même que tous les messages imbriqués sont terminés avant le retour. Asynchrone: lorsqu'il n'y a pas de retour explicite à l'appeleur et où l'envoyeur continue son exécution après l'envoi du message sans attendre que ce message soit traité par le client. C'est fréquent dans les systèmes temps réel où les objets s'exécutent concurremment. Simple: représente un flot de contrôle simple pour lequel les détails de la communication ne sont pas connus. Synchrone avec retour immédiat: appel synchrone et retour avec contrôle remis immédiatement dans les mains de l ’appeleur. Synchrone avec retour immédiat

53 Le diagramme d ’états

54 Le diagramme d ’états Il sert à décrire le cycle de vie d ’objets, de sous-systèmes, et de systèmes Il montre les états que les objets peuvent prendre et comment les événements (messages reçus, temps écoulé, occurrence d ’erreurs, conditions logiquement vraies) Un 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 Exemple Transition Nom de l ’état Etat de départ Actions

56 Diagrammes d ’états - détails
Ces diagrammes peuvent avoir un seul point de départ et plusieurs points d ’arrivée Un point de départ est symbolisé par un disque. Un point d ’arrivée est symbolisé par un cercle circonscrivant un disque Un état est symbolisé par un rectangle aux coins arrondis Les transitions sont symbolisées par une flèche Point de départ Point d ’arrivée Etat Transition

57 Etats En UML, un état comprend 3 compartiments. Seulement 2 sont disponibles dans Rose (notation de State Charts de Harel). Le premier compartiment contient le nom de l ’état Le 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 Les événements peuvent être des actions (do) ou des « send » Actions Send

58 Etats (suite…) La syntaxe pour les actions dans un état est la suivante: Event-name argument list / action expression La syntaxe pour la transition entre les états est la suivante: Event-signature [guard-condition] / action expression ^ send-clause Event-name (parameter, parameter, ...) Event-name peut être entry, do, exit ou tout autre type d'événements. Une transition d'état a normalement un événement attaché à elle mais cela n'est pas nécessaire. S'il y en a un, la transition aura lieu sur l'occurrence de cet événement. Une action do se réalise pendant que le système est dans l'état précis. Si une transition n'a pas d' événement attaché, elle aura lieu lorsque les actions internes à l'état seront complétées. Destination-expression.destination-event-name (argument,...)

59 La signature des événements
Elle 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 Condition de garde C ’est une expression booléenne placée sur une transition d ’état. Si 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: Conditions seules Si la condition de garde n'est pas vérifiée lors de l'événement, ce dernier est ignoré. [t = 15 sec] [nombre de factures = 20] retrait(montant) [solde >= montant] Avec événement

61 Expression d ’action sur une transition
Elle 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. Il peut y avoir plusieurs actions lors d ’une transition mais il faut les séparer par un « / » Exemples de transitions avec actions: Avec événement L'objet est ici celui qui possède tous les états. Augmente()/n:=n+1/m:=m+1 additionne(n)/somme := somme + n /clignote Sans

62 La send-clause C ’est un cas spécial d ’action.
Elle 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 Les événements Représentent une chose qui se produit et qui peut déclencher une action. La relation entre un événement et une action est causale (i.e. ne peut être probabiliste) UML considère quatre types principaux d ’événements: Une condition qui devient « vraie » (représentée par une «guard condition ») la réception explicite d ’un signal par l ’objet (le signal est lui-même un objet). On appelle ceci un message) la réception d’un appel d’opération par un autre objet (ou par l’objet lui-même). Il s ’agit également d ’un message) l ’écoulement d ’une période de temps donnée (représentée par une expression temporelle sur la transition) Les erreurs peuvent également être des événements. UML ne donne pas de traitement particulier aux erreurs mais un stéréotype peut toujours être utilisé pour montrer ce type spécial d'événement. Détails sur la sémantique des événements - les événements sont des triggers qui activent des transitions -les événements sont traités un à la fois -si un événement peut trigger plus d'une transition, seulement l'une d'entre elles sera trigguée. -si un événement survient et qu'une guard condition est fausse, l'événement est ignoré (il n'est pas mémorisé). -une classe peut reçevoir et envoyer des messages, c'est-à-dire appeler des opérations ou des signaux. La signature de l'événement est utilisée pour les deux cas. Quand une opération est appelée, elle s'exécute et produit un résultat. Qaund un signal est envoyé, l' objet qui le reçoit l'attrappe et l'utilise. Les signaux sont généralement des classes et représentent des unités transmises entre les objets. Les classes de signal peutvent être stéréotypées avec le stéréotype "signal", ce qui contraint alors la sémantique de l'objet en signifiant qu'il ne doit servir que comme signal. Il est aussi possible de construire des hiérarchies de signaux et ainsi supporter le polymorphisme dans leur envoi. Java est un bon exemple de cette façon de procéder.

64 Exemple d ’un diagramme d ’état
On pourrait évidemment raffiner notre calcul de l'heure en faisant: heure := (heure + 1) modulo 24 minutes := (minutes + 1) modulo 60 Autres détails concernant les diagrammes d'états: 1- il est possible d'envoyer des messages entre des diagrammes d'état 2-il est aussi possible de mettre des "substates" dans des états. On parle de or-substates ou de and-substates 3-il est aussi possible de placer un "history" indicator dans les états, ce qui permet de mémoriser les états internes etd' y retourner quand on désire revenir à un état après une opération. Ce sont des détails qu'il conviendrait de voir dans un cours plus avancé. Un indicateur d'historique est représenté par un cercle circonscrivant la lettre H.

65 Le diagramme séquentiels

66 Les diagrammes séquentiels
Ils illustrent comment les objets interagissent entre eux. Ils 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) Ils 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. L'axe horizontal montre les objets en interaction. Chaque objet est représenté par un rectangle dans lequel est inscrit le nom de l'objet et ou de la classe en caractères soulignés. L'axe vertical montre le temps et est représenté par une ligne verticale en traits pointillés pour chaque objet. Cette ligne représente laligne de vie de l'objet durant l'interaction. La communication entre les objets (i.e. les messages qu'ils s'envoient) est représentée par une flèche horizontale rejoignant les deux lignes de vie des objets en interaction. Le type de flèche illustre si le message est synchrone, asynchrone ou simple. Pour lire un diagramme séquentiel, il faut commencer en haut du diagramme et le lire en descendant en observant les échanges de messages entre les objets.

67 Les diagrammes séquentiels ...
Ils peuvent être utilisés sous deux formes: 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: 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 Les messages dans les diagrammes séquentiels
Ils représentent une communication entre objets véhiculant une information avec l ’anticipation qu ’une action sera entreprise (comme pour les diagramme d ’états) La réception d ’un message est généralement appelée événement. Les 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 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 Diagramme des classes de l ’exemple

71 Diagramme séquentiel de l ’exemple
Nom du message Objets Message synchrone Activation de l ’objet Retour Détails sur les diagrammes séquentiels -Les messages peuvent avoir une signature ayant la forme print(file:File) -Les messages peuvent aussi avoir un numéro de séquence, ce qui est cependant peu fréquent dans les diagrammes séquentiels étant donné que la séquence des événements est explicite dans le diagramme -Les messages peuvent aussi avoir des conditions qui y sont rattachées .Rose ne semble pas permettre de les inclure dans le diagramme. Types de messages qu'il est possible d'afficher (spécifications des messages): -simple: le message à un seul thread de contrôle -synchrones: l'opération ne s'exécute que lorsque le client envoie un message au fournisseur et que celui-ci lui répond que c'est OK -asynchrone: le client envoie un message au fournisseur et continue son exécution sans attendre de réponse du fournisseur. -balking: le client envoie un message seulement si le fournisseur est immédiatement disponible; il abandonne le message si le fournisseur n'est pas disponible -timeout: le client abandonne l'envoi d'un message si le fournisseur ne peut répondre àl'intérieur d'un espace de temps prescrit. Sémantique des messages (périodicité) Les messages peuvent être: -périodiques: les messages sont envoyés à intervalles de temps réguliers -non-périodiques: les messages sont envoyés à intervalles de temps irréguliers ou n'ont pas de fréquence fixe. Etiquettes et contraintes Les diagrammes séquentiels peuvent aussi contenir des étiquettes pour signifier de situations spéciales. Ces étiquettes ("labels") sont plaçées à la gauche ou à la droite du diagramme. Elles servent à donner des contraintes de temps sur le diagramme ou à spécifier des détails autrement difficiles à placer sur la ligne des messages. Création et destruction d'objets. Il est possible de documenter la destruction des objets en mettant un X quand l'objet cesse d'exister. Récursion. UML prévoir la description des récursions (i.e. une opération qui s'appelle elle-même). On la montre comme une activation appliquée à elle-même).Rose ne semble pas encore supporter ce type de représentation. Lignes de vie

72 Le diagramme de collaboration

73 Les diagrammes de collaboration
Les diagrammes de collaboration montrent les interactions et les liens entre un ensemble d ’objets participant à un scénario. Ils focalisent leur attention sur l ’aspect spatial des interactions. Ils 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 Les diagrammes de... Les objets sont dessinés comme des classes mais leurs noms sont soulignés. Les liens sont illustrés par des lignes (qui ressemblent à des lignes d ’associations dans les diagrammes de classes mais sans les informations de multiplicité). Un message, accompagné d ’une étiquette, peut être associé à un lien pour montrer le sens et l ’ordonnancement de la transmission du message.

75 Les diagrammes de... Les étiquettes de message associées aux liens adoptent la syntaxe suivante: Predecessor guard-condition sequence-expression return-value := signature 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 à 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. * [iteration-clause] [condition-clause] La «return-value» doit être affectée à la valeur retournée par la signature du message

76 Les liens dans les diagrammes de collaboration
Un lien indique une connexion entre deux objets. Le 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) Le stéréotype du lien peut aussi être inclus dans la connexion. On compte les stéréotypes suivants: global, local, parameter, self, vote, broadcast

77 Les stéréotypes de liens
Global: associé à un rôle du lien pour montrer que l ’instanciation en présence est globale (visible dans tout le système). Local: associé à un rôle du lien pour montrer que l ’instanciation est une variable locale dans une opération. Parameter: montre que l ’instance est visible parce que c ’est un paramètre d ’une opération Self: montre qu ’un objet peut s ’envoyer des messages Vote: 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) Broadcast: contrainte appliquée à un ensemble de messages pour signifier qu ’ils ne sont pas exécutés dans un ordre donné On peut aussi montrer la création et la destruction des objets en ajoutant des contraintes {new}, {destroyed}, les objets étant créés et détruits durant une collaboration portent le qualificatif de {transient}

78 Exemple pour l’ascenseur : Classes

79 Exemple pour l’ascenseur :Collaboration
L ’utilisateur appuie sur le bouton de l ’ascenseur. Le bouton transmet une requête au contrôleur d ’ascenseur qui crée une requête et la place dans une queue de jobs (la requête est un paramètre dans la queue). L ’ascenseur va chercher une requête dans la queue et la requête est exécutée. Le diagramme montre différentes informations: -la durée de vie des objets -leur stéréotype (local, paramètre,etc) -la séquence des messages Rose ne supporte actuellement pas toute la sémantique UML pour les diagrammes de collaboration. En plus du diagramme de collaboration, il y a aussi le diagramme d ’activités non supporté par Rose. Il sert à décrire l ’implantation d ’une opération en termes d ’un ensemble d ’actions. C ’est un peu relié aux organigrammes des langages procéduraux traditionnels.

80 Le diagramme de d ’activité

81 Le diagramme d ’activités
Focalise son attention sur l ’implantation des opérations dans les classes. Repré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. 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 Le diagramme d ’activités
Les actions sont représentées par des rectangles aux coins arrondis. Les transitions entre les actions sont représentées par des flèches. Le diagramme comprend un point de départ et un ou plusieurs points d ’arrivée. Un événement peut accompagner la transition du point de départ seulement Des conditions de garde, des «send-clauses », et des actions peuvent accompagner les transitions entre les actions. Des boîtes de décision (losanges) peuvent faire partie du diagramme. Des actions peuvent être exécutés concurremment en les plaçant en parallèle sur le diagramme.

83 Le diagramme d ’activités. Exemple...
Événement Transition Départ Action Send-clause Arrivée On peut ajouter des swimlanes pour voir dans quel objet s ’effectuent les actions. Si des objets sont transmis entre les swimlanes, ils sont représentés par des rectangles et relient les actions entre elles (actions qui s ’échangent cet objet) avec des lignes pointillées. Des signaux peuvent aussi se transmettre des signaux. Les diagrammes d ’activités (avec des swimlines) servent surtout à décrire les organisations. Classe

84 Ouf...

85 Architecture « physique »

86 Architecture physique
L ’architecture physique du système s ’intéresse à la description détaillée de celui-ci sur les plans du hardware et du software. Elle illustre la structure du hardware en incluant les différents nœuds de calcul et les liens entre ceux-ci Elle 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 Architecture physique...
L ’architecture physique répond aux questions suivantes: Dans quels programmes ou processus les classes et objets du modèle logique résident-ils physiquement? Sur quel(s) processeur(s) ces programmes et processus s ’exécutent-ils? Quels types d ’ordinateurs composent le système et comment sont-ils reliés physiquement? 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 Architecture physique...
Classes, Objets, Mécanismes, Messages, Algorithmes, Logique Mapping Composantes, Processus Ordinateurs Physique

89 Diagrammes de l ’architecture physique
En UML, l ’architecture physique est principalement décrite par deux diagrammes: le diagramme des composantes (« component diagram »): contient les composantes logicielles du projet (unités de code et fichiers concrets-binaires et sources). 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 Le hardware La partie hardware d ’un système est divisée en trois éléments: Les processeurs: ce sont les ordinateurs qui exécutent les programmes du système. 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. Les connexions: ce sont les liens physiques entre les processeurs (câbles-fibre optique et/ou protocoles p.e. TCP/IP)

91 Le software En UML, un système logiciel est divisé en packages de classes Un package rassemble un certain nombre de classes en un groupe logique mais ne définit aucune sémantique pour le groupe. Il 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. Seule l ’interface possède une dépendance avec d ’autres modules. Pour celui qui observe le package, c'est la façade qui est intéressante car elle contient les liens avec les autres modules et l'interface avec le package. Souvent, seule cette façade dsoit être représentée dans les diagrammes. Les packages sont utilisés à la fois dans le modèle logique (où un certain nombre de classes est assemblé) et dans le modèle physique (où le package encapsule un nombre donné de composantes, i.e. l'implantation des classes du design logique).

92 Le software... Un 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. On lui donne le stéréotype « façade » en UML. Il 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 Le software... Les principaux concepts servant à décrire la partie software d ’un système sont: 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. 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. Les objets: les objets passifs sont ceux sans thread propre. Les objets passifs n'ont pas de thread propre mais ne s'exécutent que lorsqu'un message leur est envoyé (i.e. une de leurs opérations est appelée). Ils peuvent être alloués dans un processus ou un thread (associé à un objet actif) ou directement à un component exécutable.

94 Le software... Deux principaux diagrammes servent à décrire physiquement les systèmes: les diagrammes de composantes (« components ») les diagrammes de répartition (« deployment » )

95 Le diagramme de composantes (« component diagram »)

96 Le diagramme de composantes
Il décrit les composantes logicielles et leur interdépendance. Il représente par conséquent la structure du code. Les 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). Les composantes sont typiquement les fichiers d ’implantation des éléments logiques du système.

97 Les composantes UML définit trois types principaux de composantes:
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. 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. Les composantes exécutables: programmes résultant de l ’édition des liens des composantes binaires. Note: une librairie dynamique est chargée au run-time par une composante exécutable. Note: les composantes exécutables représentent des unités exécutables exécutées par un processeur.

98 Les composantes... En 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. Le nom de la composante est inscrit en dessous ou à l ’intérieur du grand rectangle. Les composantes sont des types et seules les composantes exécutables peuvent être instanciées. Les 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é. Dans Rational Rose, les composantes ne sont composées que du grand rectangle et des deux petits rectangles.

99 Les composantes... Les dépendances entre composantes sont illustrées par une ligne pointillée avec une flèche simple. Une dépendance signifie qu ’une composante a besoin d ’une autre pour que sa définition soit complète. 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. Si les composantes sont exécutables, les dépendances montrent les librairies dynamiques qui sont nécessaires lors de l ’exécution d ’un programme. Les dépendances sont à peu près ce qu'on devrait retrouver dans un makefile dans Unix.

100 Les composantes... Une composante peut avoir une interface qui est visible aux autres composantes. Ces 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). Une interface est montrée par une ligne terminée par un cercle. Le nom de l ’interface est inscrit près de ce cercle.

101 Exemple de diagramme de composantes de code source
Dépendance

102 Exemple de diagramme de composantes run-time
Les deux dernières diapositives montrent les différents stéréotypes qu'il est possible de donner aux composantes dans des diagrammes. Ces principaux stéréotypes sont par exemple: Pour les composantes de compilation: -file -page -document Pour les composantes exécutables: -application -library -table (pour les databases

103 Le diagramme de répartition (« deployment diagram »)

104 Le diagramme de répartition
Ce diagramme montre l ’architecture run-time des processeurs, des périphériques, et des composantes logicielles qui s ’exécutent sur cette architecture. Il est la description finale de la topologie du système car il unit les facettes hardware et software du système. Dans 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. On devrait aussi pouvoir retracer les éléments de l'analyse initiale des besoins du système.

105 Diagramme de répartition...
Il comprend: des nœuds des connexions des composantes des objets

106 Diagramme de répartition...
Nœ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) Les 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. Les types sont des modèles génériques de processeurs ou d'ordinateurs par exemple. Les instanciations sont des processeurs physiques précis (par exemle mitis, etc). La définition complète des capacités du système peuvent être définies comme des attributs ou des propriétés du noeud.

107 Diagramme de répartition…exemple simple
Nœud Lien Scheduling Process Rose n'offre pour le moment que peu de fonctionalité par rapport à ce que UML définit en termes de structure physique du système. Par exemple, UML prévoit qu'il est possible de placer les icônes des composantes à l'intérieur des noeuds pour montrer que ces composantes s'exécutent sur ceux-ci. Rose ne supporte pas encore ces fonctionnalités de UML. UML prévoit même l'inclusion d'objets résidents dans les noeuds (pour modéliser les agents mobiles par exemple). Rose ne supporte pas encore cette fonctionnalité. Périphérique (device)

108 Ouf...

109 Un dernier exemple: le pattern proxy en UML
Ici, le client invoque l'opération Requête présente dans l'interface de la classe abstraite Sujet. L'interface de Sujet est implantée à la fois dans SujetRéel et dans Proxy. La vraie implantation de l'opération Requête est implantée dans SujetRéel tandis que l'objet Proxy ne fait que transmettre la requête à cet objet. Ce design pattern est intéressant car il permet une plus grande efficacité et une meilleure performance, une plus grande sécurité et une localisation flexible (l'objet SujetRéel et le Proxy peuvent ne pas résider sur le même processeur par exemple).

110 Un dernier exemple: le pattern proxy en UML
Ici, le client invoque l'opération Requête présente dans l'interface de la classe abstraite Sujet. L'interface de Sujet est implantée à la fois dans SujetRéel et dans Proxy. La vraie implantation de l'opération Requête est implantée dans SujetRéel tandis que l'objet Proxy ne fait que transmettre la requête à cet objet. Ce design pattern est intéressant car il permet une plus grande efficacité et une meilleure performance, une plus grande sécurité et une localisation flexible (l'objet SujetRéel et le Proxy peuvent ne pas résider sur le même processeur par exemple).

111 Processus de développement et UML

112 Processus de développement de logiciel
UML est un outil de modélisation de systèmes. Il 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. Une méthode de design orientée objet repose sur trois bases: une notation permettant de décrire les modèles; un processus de construction des modèles; des outils facilitant la construction et la description des modèles. La notation peut par exemple être UML. Le processus peut être la méthode de Booch ou,plus récemment la méthode Objectory de Rational Software elle-même dérivée de la méthode de Booch. Les outils sont par exemple Rational Rose qui permet non seulement de décrire et modéliser mais également de générer du code à partir des modèles ou de générer des modèles à partir de code déjà existant.

113 Le processus permet de... respecter les exigences fonctionnelles (parfois informelles) du système; se conformer aux limites de la machine exécutant le logiciel; se conformer aux ressources disponibles; satisfaire des critères de design; satisfaire les contraintes et les limites du processus de design lui-même (un design doit être effectué dans un temps raisonnable).

114 Le processus doit permettre de limiter
la complexité du problème; la 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; la complexité associée à la flexibilité offerte par le logiciel; la complexité associée à la difficulté de décrire des systèmes discrets.

115 Le processus doit tenir compte du fait que...
Les systèmes adoptent une structure hiérarchique. Le choix des composantes de base de ces systèmes est généralement arbitraire; Les liens intra-composantes sont généralement plus forts que les liens inter-composantes; Les 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; Les systèmes découlent de systèmes plus simples dont ils sont une évolution.

116 OOA-OOD-OOP

117 OOA-OOD-OOP L ’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. La 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. La 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 objets
La modélisation par objets comporte quatre éléments principaux: l'abstraction: représentation des caractéristiques essentielles d'un objet qui permettent de le distinguer de tous les autres; l'encapsulation: processus de compartimentation des éléments d'une abstraction qui constituent sa structure et son comportement; la modularité: capacité qu'a un système d'être décomposé en un ensemble de modules cohérents et faiblement couplés; la hiérarchie: ordonnancement d'abstractions; Une abstraction s'intéresse à l'apparence extérieure d'un objet et permet de séparer le comportement essentiel de l'objet de son implantation. C'est ce qu'on appelle la "barrière de l'abstraction". Il existe plusieurs types d'abstractions: abstraction descriptive: un objet représente un modèle utile d'une composante du problème et de sa solution; abstraction d'action: un objet qui offre un ensemble d'opérations générales dont chacune effectue le même type de fonction; On définit une hiérarchie comme étant un ordonnancement d'abstractions. Il existe deux types importants de hiérarchies: les hiérarchies d'existence ("is a"); les hiérarchies d'appartenance ("has a"). abstraction de machine virtuelle: un objet qui regroupe des opérations qui sont utilisées à un certain niveau supérieur de contrôle ou des opérations qui utilisent un ensemble élémentaire d'opérations; abstraction fortuite: un objet qui contient un ensemble d'opérations qui n'ont aucun lien entre elles.

119 Modélisation par objets
et trois éléments secondaires: le typage: renforcement de la classe d'un objet telle que des objets de types différents ne puissent pas être intervertis; 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; 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éé). static binding (aussi appelé early binding): le type d'une variable est fixé à la compilation. dynamic binding (aussi appelé late binding): le type d'une variable n'est connu qu'au runtime. Le dynamic binding permet à un langage d'offrir l'implantation du polymorphisme, principe par lequel un identificateur (comme par exemple le nom d'une variable) peut représenter des objets appartenant à des sous-classes différentes mais dérivant de la même superclasse.

120 Modèle WATERFALL Exigences Design Implantation Test Maintenance
Flop!!!

121 Modèle WATERFALL(suite)
!!!

122 Méthode de conception Unified

123 Méthode d ’analyse Unified
Développer un modèle du système (analyse) Établir les exigences centrales du projet (conceptualisation) Concevoir une architecture du système (design) Macro-process Le processus macroscopique de développement sert de cadre de contrôle du processus microscopique décrit à la Section 6.2. Ce processus plus large permet à l’équipe de mesurer un certain nombre de paramètres quant au déroulement des activités, de déterminer le niveau de risque d’une étape et de corriger rapidement des erreurs potentiellement coûteuses du processus microscopique tout en permettant de mieux saisir certains aspects de l’analyse et du design au niveau global du projet. Le processus macroscopique de développement implique toute l’équipe et s’étend sur de longues périodes. Certaines pratiques de ce processus macroscopique ne sont pas spécialement réservées au développement de projets orientés objet mais s’appliquent également à tout projet de conception d’un logiciel d’envergure: gestion de la configuration, contrôle de qualité, vérification du code, documentation. Apporter les correctifs au système final (entretien) Raffiner l ’implantation du système (évolution)

124 Méthode d ’analyse Unified
Identification des classes et des objets Identification de la sémantique des classes et des objets Définition de l interface et de l ’implantation des classes et des objets Micro-process Ce processus de développement orienté objet dépend grandement des scénarios et des architectures qui proviennent du processus macroscopique et qui y sont successivement raffinés. En gros, le processus de développement microscopique comporte les activités quotidiennes du concepteur ou d'une petite équipe de concepteurs. Il concerne autant l'ingénieur en génie logiciel que l'architecte du système. Du point de vue de l'ingénieur, le processus microscopique offre des balises pour la prise de décisions tactiques sur une base quotidienne. Du point de vue de l'architecte, il offre un cadre dans laquelle l'architecture peut évoluer et permettre l'exploration de différents designs. Dans ce processus, l'analyse et le design sont étroitement liées et la frontière les séparant est floue. Le processus de développement microscopique s'intéresse (et suit) les activités suivantes: identifier les classes et les objets à un niveau donné d'abstraction; identifier la sémantique des classes et des objets; identifier les relations entre les classes et les objets; spécifier l'interface et l'implantation des classes et des objets. Identification de la relation entre les classes et les objets

125 Application de la méthode
Processus itératif Processus incrémental

126 Formation de l ’équipe Architecte Ing. de réutilisation Superviseur
Développeurs Contr. de qualité Resp. doc. On peut aussi compter un quincallier qui conçoit des outils nécessaires à l'équipe de développeurs et à un ingénieur de réseau qui veille à la bonne marche des outils informatiques, qu'ils soient hardware ou software.

127

128

129

130

131

132