Télécharger cours informatique en PDF Cours informatique PDF Plan de cours
- Types des diagrammes dans UML
- La notion de orienté objet
- Le diagrammes de Collaboration
- Le diagrammes d’Etats-Transitions
- Le diagrammes d’Activités
- Le diagrammes de Composants
- Le diagrammes de Déploiement
Les diagrammes d’objets sont dérivés des diagrammes de classes, de sorte que les diagrammes d’objets dépendent des diagrammes de classes.
Les diagrammes d’objets représentent une instance d’un diagramme de classes. Les concepts de base sont similaires pour les diagrammes de classes et les diagrammes d’objets. Les diagrammes d’objets représentent également la vue statique d’un système, mais cette vue statique est un instantané du système à un moment donné.
Les diagrammes d’objets sont utilisés pour rendre un ensemble d’objets et leurs relations en tant qu’instance.
Objectif des diagrammes d’objet
Le but d’un diagramme doit être compris clairement pour le mettre en pratique. Les objectifs des diagrammes d’objets sont similaires aux diagrammes de classes.
La différence est qu’un diagramme de classes représente un modèle abstrait composé de classes et de leurs relations. Cependant, un diagramme d’objets représente une instance à un moment particulier, qui est concret dans la nature.
Cela signifie que le diagramme d’objets est plus proche du comportement réel du système. Le but est de capturer la vue statique d’un système à un moment particulier.
Le but du diagramme d’objet peut être résumé comme :
- Ingénierie avant et arrière.
- Relations d’objet d’un système
- Vue statique d’une interaction.
Comprendre le comportement des objets et leur relation d’un point de vue pratique
Comment dessiner un diagramme d’objet?
Nous avons déjà discuté qu’un diagramme d’objet est une instance d’un diagramme de classes. Cela implique qu’un diagramme d’objets est constitué d’instances de choses utilisées dans un diagramme de classes.
Les deux diagrammes sont donc faits des mêmes éléments de base mais sous une forme différente. Dans les éléments de diagramme de classe sont sous forme abstraite pour représenter l’impression bleue et dans le diagramme d’objet les éléments sont sous forme concrète pour représenter l’objet du monde réel.
Profitez de ce manuel de formation en PDF pour comprendre mieux le UML et enrichir votre connaissance.
Commencez à télécharger ce cours adapté pour vous et à apprendre UML.
Modifié le 5/11/04 À 17:11 – Édité le 6/4/10 À 15:04 – Imprimé le 6/4/10 À 15:04 Page 10 sur 44 3. La modélisation Ce chapitre présente les vues proposées par UML, le s modèles et quelques informations pour utiliser les modèles selon le niveau d’abstraction. 3.1. Les vues UML propose différents modèles pour représenter les différents points de vue de la modélisation. Les 4+1 vues sont : · la vue logique (intégrité de conception) : perspective abstraite de la solution (classes, relations, machines états- transitions, etc.) ; · la vue des composants (intégrité de gestion du code) : perspective physi que de l’organisation du code (modules, composants, concepts du langage ou de l’environneme nt d’implémentation) ; · la vue des processus (intégrité d’exécution) : perspective sur les acti vités concurrentes et parallèles (tâches et process us) ; · la vue de déploiement (intégrité de performance) : répartition du systèm e (logiciel) à travers un réseau ; · la vue des cas d’utilisation (intégrité de conception), qui guide et justifie l es autres : moyen rigoureux et systématique pour guider la modélisation (cas d’utilisation, scé narios, collaborations d’objets, machines à états). 3.2. Les modèles Les 9 modèles sont : · diagramme de classes (class diagram ) [Cf. OMT, Booch et autres méthodes objet] : struc ture statique (classes et associations) ; · diagramme d’ objets (object diagram ) : instance du diagramme de classes (objets et lie ns) ; · diagramme de cas d’utilisation (use case diagram ) [Cf. OOSE] : fonctions du système du point de vue des utilisateurs ; · diagrammes de comportement ( behavior diagrams) : · diagrammes d’interaction ( interaction diagrams) : interactions entre les objets (scénarios et flo ts de messages) · diagramme de séquence (sequence diagram ) [Cf. divers modèles ( interaction, message trace , event trace ) d’anciennes méthodes non orientées objet] : aspect temporel des interactions entre les objets (séquence d’événements) ; · diagramme de collaboration (collaboration diagram ) [Cf. notamment Booch ( object diagram) et Fusion (object interaction graph )] : aspect spatial des interactions entre les obje ts (relativement à leurs rôles et aux liens qu’ils ont entre-eux) ; · diagramme d’ activités (activity graph diagram ) [Cf. diagrammes de flots de données ( work flow diagrams) émanant d’anciennes méthodes (objet ou non)] : comportement d’une opération en terme d’actions et d’activités ; · diagramme d’ états-transitions (statechart diagram ) [Cf. travaux de D. Harel] : comportement dynamiqu e des objets (changeant d’état en réaction à des événements) ; · diagrammes de réalisation ( implementation diagram) [Cf. Booch (module et process diagram )] : unités de travail · diagramme de composants (component diagram ) : composants logiciels réalisant l’application (c ode source, bibliothèques, dépendances, etc.) ; · diagramme de déploiement (deployment diagram ) : répartition des composants logiciels sur des ma tériels. De plus, les stéréotypes [nouveauté d’UML] fourniss ent l’un des mécanismes d’extension, utilisés notamment pour étendre la sémantique du méta-modèle, tandis que le langage d’ expression de contrainte objet OCL (Object Constraint Language) [Cf. Syntropy ou Catalysis] est utilisable durant toutes les phases du cycle de développement du logiciel, également utilisé par UML pour spécifier sa sémantique. 3.3. Utilisation des modèles Rappelons qu’il faut dans un premier temps modélise r le métier de l’organisation étudiée, en enchaînant les étape s suivantes : · étude du périmètre et des intervenants extérieurs à l’organisation, · étude des processus de l’organisation, · étude des travailleurs et des entités de l’organisa tion, · étude des flots d’événements des processus, · étude des structures organisationnelles. Un acteur est une abstraction extérieure au système à modéli ser (l’organisation lorsque l’on modélise le métier, le système informatique dans un second temps) qui interagit av ec lui. Il s’agit de rôles joués par des personnes, de logi ciels, de matériels, etc. On détermine un acteur principal en se demandant « À qui est destiné le système à modéliser ? ». Un processus d’une organisation est soit un processus métier (v isible de l’extérieur du système), soit un processus support (interne à l’organisation et donc non visible de l’ extérieur, support aux processus métier pour s’exéc uter), soit un processus de gestion (interne à l’organisation et donc non visib le de l’extérieur, moyens de gestion des processus métier). Un processus métier est l’ensemble des activités internes d’un métier permettant de fournir un résultat observable et mesurable pour un utilisateur individuel du métier. Un processus métier est représenté par un cas d’uti lisation (i.e. dans un diagramme de cas d’utilisation), et inversement.
