Remerciez-le!

Remerciez @Admin pour avoir partagé cet document gratuitement, de la manière la plus simple, en partageant sur les réseaux sociaux.

Chapitre 3 : UML 1. UML: Unified Modeling Language UML est le résultat du trava

Chapitre 3 : UML 1. UML: Unified Modeling Language UML est le résultat du travail initié par G. Booch et J. Rumbaugh en 1994. L’objectif de ce travail était d’unifier les méthodes de modélisation de: Booch OMT de Rumbaugh OOSE de Jacobson La Version 1.0 d’UML apparaît en Janvier 1997. L ’OMG a adopté UML comme langage de modélisation 1.1. Objectifs de UML Les objectifs d’UML sont : Modéliser des 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 1.2. 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.) 1.3. É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 1 2. Types de visualisation dans UML 2.1. Visualisation « Use Cases » Les cas d’utilisation (Use cases) décrivent la fonctionnalité d’un système. Ces diagrammes s’adressent aux clients, concepteurs, responsables du développement, responsables des tests Un Use Case décrit un point fonctionnel du système et le fonctionnement global du système est décrit par l’ensemble des Use Cases 2.1.1. Use Cases dans UML Les use cases sont représentés par une ellipse dans laquelle est inscrit le nom du Use Case Ils sont généralement connectés à un acteur avec une association 2.1.2. Liens entre Use Cases « extends » signifie qu’un Use Case est une spécialisation d’un autre Use Case plus général. L’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 2 2.1.3. Description d’un Use Case Un use case est décrit par : Ses Objectifs Le Flot des messages entre l’acteur et le Use Case Le Flot secondaire des messages entre l’acteur et le Use Case Les Condition de fin pour le Use Case et information retournée à l ’acteur lors qu’il se termine 2.1.4. 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. Il 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é. 2.2. Visualisation « Logique » Il existe deux types visualisation logique : Visualisation statique et Visualisation dynamique La visualisation statique est décrite par les diagrammes de classes et d’objets. La visualisation dynamique est décrite par les diagrammes d’états, séquentiels (de séquence), de collaboration et d’activité 2.2.1Vision statique 2.2.1.1. Diagrammes de classes 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 Le diagramme de classes est un modèle statique du système qui décrit le système en termes de ses classes et des relations entre celles-ci. Il sert de base aux autres diagrammes où d’autres 3 facettes du système sont décrites (tels les diagrammes d ’états des objets ou les diagrammes de collaboration qui sont des diagrammes dynamiques) 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)? 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 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 méthodes (opérations) La syntaxe dans les différents compartiments est indépendante des langages de programmation a. Compartiment de nom  Il contient le nom de la classe.  Il est centré dans le compartiment.  Il est imprimé en caractères gras.  Le nom ne doit pas être ambigu et doit être tiré du domaine propre au problème. b. 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 4 Optionnellement, on peut aussi indiquer qu’un attribut possède une portée s’appliquant à la classe (class scope) ou une chaîne de propriétés indiquant les valeurs que peut prendre l’attribut. Exemples de classe avec attributs c. 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 Exemple de classe avec opérations Spécification de l’opération Une méthode (opération) est spécifiée par :  les Pré-conditions: doivent être vérifiées avant que l’algorithme ne s’exécute  les Post-conditions: doivent être vraies une fois l’opération complétée  l’Algorithme: effet que l’opération a sur l’objet 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 5 –les raffinements Les associations de classes Il existe plusieurs types d’associations:  normale  récursive  agrégation par référence  agrégation par composition a. 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 b. 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 c. Agrégation par référence Elle indique une relation tout-partie. Elle 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é. Une agrégation par référence possède des rôles, multiplicité, …etc., comme une association normale. d. Agrégation par composition 6 Elle indique une relation tout-partie avec inclusion « physique ». Elle 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é. Une agrégation par composition possède des rôles, multiplicité, …etc., comme une association normale Les généralisations de classes 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 et 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 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 parlera d’héritage multiple Les 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 7 uploads/Management/ cours-uml-partie1.pdf