Chapitre 2 Rappels objet et Présentation des diagrammes UML Conception Objet Chapitre 2 Rappels objet et Présentation des diagrammes UML
Plan du chapitre 2 Rappels sur les objets Modélisation structurelle Modélisation comportementale Démarche et diagrammes
Concepts objets (Rappels) Intérêt de la modélisation objet Modifiabilité Réutilisabilité Lisibilité Une modification d’objet qui ne modifie pas l’interface reste une affaire interne Constitution de bibliothèques de classes. Utilisation de patterns Objet connu que par son interface. Algo et méthodes cachés.
Concepts objets (Rappels) Classes Associations Objets Liens Attributs Opérations et méthodes Messages et stimuli En UML, un concept spécifique s’exprime en utilisant le même symbole que le concept général. Le symbole est étiqueté avec un nom spécifique suivi de : puis du nom du concept général. Classe : type d’objet et ses caractéristiques Associations : relations entre classes Attributs : une classe définit des attributs et un objet possède des valeurs pour ces attributs. Opération : action qu’un objet peut réaliser (comme déclaration de fonction) Méthode : manière dont il réalise l’opération (comme corps de la fonction) Le code n’est pas décrit dans les compartiments des classes UML. Messages et stimuli : dans le paradigme objet, les communications circulent d’un objet émetteur vers un objet récepteur « Le gestionnaire reçoit une requête afin qu’il démarre un projet. L’opération est invoquée afin de la gérer et la méthode est exécutée » Envoi, réception de requête = événements. Une communication entre objets via leurs liens s’appelle un stimulus et une communication entre classes s’appelle un message. Émetteur : client, récepteur : fournisseur.
Concepts Objets (Rappels) Unité de base Possède des traitements Possède des données Défini par son état, son identité Opération Définit le comportement de l’objet Modifie l’état du système avec lequel il collabore
Concepts Objets (Rappels) Visibilité CAPSULE INTERFACE METHODES ATTRIBUTS
Concepts Objets (Rappels) Instance de classe (type abstrait) Attention au point de vue Client vu par le réparateur Client vu par le commercial Un objet possède des attributs et méthodes différentes selon le point de vue
Principes du paradigme objet Abstraction Exclure les informations non pertinentes Encapsulation Cacher les méthodes Généralisation Polymorphisme Localisation = attributs + opérations => réduire le nombre d’endroits où on doit envisager une modification Une méthode doit demeurer opaque pour ses clients (seul le résultat compte), on ne perturbe pas un client si on modifie une méthode Généralisation : capturer et réutiliser les points communs La classe la plus spécifique hérite des attributs, relations et opérations et méthodes d’une classe plus générale Polymorphisme : Une opération peut être décrite par plusieurs méthodes. On peut communiquer des requêtes sans savoir les méthodes qui sont réélement invoquées.
Modélisation structurelle Compréhension Communication Eléments composants un système Fonctionnalité offerte
Modélisation structurelle Diagramme de classes Structure générale d’un système Classes, associations, attributs, opérations
Modélisation structurelle
Modélisation structurelle Diagramme d’objets Structure d’un système à un instant donné Objets, liens, valeurs d’attributs En UML : un concept spécifique même symbolique que concept général Symbole etiqueté Nom spécifique (minuscule) Suivi de : Suivi du nom du concept général (majuscule)
Modélisation structurelle Diagramme de cas d’utilisation Décrit la fonctionnalité du système Acteur, cas d’utilisation, association de communication
Modélisation structurelle Diagramme de composants Décrit l’implémentation d’un système Composants, relations de dépendance Les diagrammes de composants représentent l'organisation et les dépendances au sein d'un ensemble de composants. Ils présentent la vue d’implémentation statique d’un système et sont liés aux diagrammes de classe dans le sens où un composant correspond généralement à une ou plusieurs classes, interfaces ou collaborations
Modélisation structurelle Diagramme de déploiement Décrit l’environnement d’implémentation d’un système Nœud, association de communication Les diagrammes de déploiement représentent la configuration des nœuds de processus en phase d'exécution ainsi que les composants qui y résident. Ils présentent la vue de déploiement statique d'une architecture et sont liés aux diagrammes de composants, dans le sens où un nœud renferme généralement un ou plusieurs composants. Représentation de la structure d’un système lors de son exécution Relation entre composants logiciels et matériels Distributions des composants sur les processeurs Les composants qui n’ont pas d’existence propre à l’exécution se représentent dans les diagrammes de composants
Modélisation comportementale Comment les éléments interagissent et collaborent pour fournir les fonctionnalités d’un système
Modélisation comportementale Diagramme de séquences Comment les éléments interagissent dans le temps Classes et objets, ligne de vie, communication
Modélisation comportementale
Modélisation comportementale Diagramme de collaboration Expression de mécanismes, en montrant la coopération entre objets Comment les éléments interagissent dans le temps et comment ils sont reliés
Modélisation comportementale
Modélisation comportementale Diagramme d’état Décrit le cycle de vie d’un objet Séquences possibles d’états et d’actions qu’une instance de classe peut traiter au cours de son cycle de vie en réaction à des événements (invocation de méthode) S’intéressent à un seul élément du système (ce sont les diagrammes d’interaction qui présentent les liens entre les objets)
Modélisation comportementale Diagramme d’activité Spécifier des traitements Adaptés à la spécification détaillée des traitements en phase de réalisation. Mais aussi de façon plus informelle pour décrire des enchaînements d’actions de haut niveau (pouvoir d’expression proche des langages de programmation) : description détaillée de cas d’utilisation. Description du comportement interne D’une classe D’une méthode D’un cas d’utilisation
Processus et diagrammes Use Cases Spécifications fonctionnelles Diagramme de séquence Diagramme d’activité Analyse Diagramme de classes Diagramme de séquence Diagramme de collaboration Conception : trouver des solutions informatiques et techniques Le comment ? Les modèles construits au cours du développement d'un système à forte composante logicielle ont tendance à évoluer et peuvent être utilisés par de nombreux intervenants selon des approches et à des moments différents. c’est la raison pour laquelle il est courant que l'équipe de développement construise non seulement des modèles correctement mis en forme, mais parfois également des modèles : Partiels Afin de simplifier la représentation graphique, certains éléments sont cachés Incomplets Il manque certains éléments Incohérents L'intégrité du modèle n'est pas garantie Ces modèles imparfaits sont inévitables car les détails d'un système se précisent et se combinent tout au long du cycle de développement logiciel. Les règles d'UML encouragent — mais n'obligent pas — à répondre aux principales questions d'analyse, de conception et d'implémentation qui permettent à ces modèles d'acquérir peu à peu une forme correcte. Informaticiens spécialistes du domaine Diagramme d’états Conception
Processus et diagrammes Diagramme d’activité OU Use Cases Diagramme de séquence Diagramme de classes Diagramme de collaboration Sens recommandé Sens possible Diagramme d’états Modèles équivalents
Processus et diagrammes Monde fonctionnel Diagramme d’activité OU Use Cases Diagramme de séquence Diagramme de classes Diagramme de collaboration Monde des objets Diagramme d’états
Processus et diagrammes Du général au particulier Use Cases : - Cas 1 - Cas 2 Diagramme de séquence 11 Diagramme de séquence 12 Diagramme de séquence 21 Diagramme de séquence 22 Diagramme de collaboration 11 Diagramme de collaboration 12 1 seul diagramme Diagramme de collaboration 21 Diagramme de collaboration 22 Diagramme d’états 2 Diagramme de classes Diagramme d’états 1