UML - Guide rapide

UML est un langage standard pour spécifier, visualiser, construire et documenter les artefacts des systèmes logiciels.

UML a été créé par l'Object Management Group (OMG) et un projet de spécification UML 1.0 a été proposé à l'OMG en janvier 1997.

OMG s'efforce continuellement de créer une véritable norme industrielle.

  • UML signifie Unified Modeling Language.

  • UML est différent des autres langages de programmation courants tels que C ++, Java, COBOL, etc.

  • UML est un langage pictural utilisé pour créer des plans logiciels.

  • UML peut être décrit comme un langage de modélisation visuelle à usage général pour visualiser, spécifier, construire et documenter un système logiciel.

  • Bien que UML soit généralement utilisé pour modéliser des systèmes logiciels, il n'est pas limité dans cette limite. Il est également utilisé pour modéliser des systèmes non logiciels. Par exemple, le flux de processus dans une unité de fabrication, etc.

UML n'est pas un langage de programmation mais des outils peuvent être utilisés pour générer du code dans divers langages à l'aide de diagrammes UML. UML a une relation directe avec l'analyse et la conception orientées objet. Après une certaine normalisation, UML est devenu un standard OMG.

Objectifs d'UML

Une image vaut mille mots , cet idiome correspond parfaitement à la description d'UML. Les concepts orientés objet ont été introduits bien avant UML. À ce moment-là, il n'existait aucune méthodologie standard pour organiser et consolider le développement orienté objet. C'est alors que UML est entré en scène.

Il y a un certain nombre d'objectifs pour développer UML, mais le plus important est de définir un langage de modélisation à usage général, que tous les modélisateurs peuvent utiliser et il doit également être simple à comprendre et à utiliser.

Les diagrammes UML ne sont pas seulement conçus pour les développeurs, mais également pour les utilisateurs professionnels, les gens ordinaires et toute personne intéressée à comprendre le système. Le système peut être un système logiciel ou non logiciel. Ainsi, il doit être clair que UML n'est pas une méthode de développement mais qu'il accompagne des processus pour en faire un système performant.

En conclusion, l'objectif d'UML peut être défini comme un simple mécanisme de modélisation pour modéliser tous les systèmes pratiques possibles dans l'environnement complexe d'aujourd'hui.

Un modèle conceptuel d'UML

Pour comprendre le modèle conceptuel d'UML, nous devons d'abord clarifier ce qu'est un modèle conceptuel? et pourquoi un modèle conceptuel est-il nécessaire?

  • Un modèle conceptuel peut être défini comme un modèle composé de concepts et de leurs relations.

  • Un modèle conceptuel est la première étape avant de dessiner un diagramme UML. Cela aide à comprendre les entités du monde réel et comment elles interagissent les unes avec les autres.

Comme UML décrit les systèmes en temps réel, il est très important de créer un modèle conceptuel puis de procéder progressivement. Le modèle conceptuel d'UML peut être maîtrisé en apprenant les trois éléments majeurs suivants -

  • Blocs de construction UML
  • Règles pour connecter les blocs de construction
  • Mécanismes communs d'UML

Concepts orientés objet

UML peut être décrit comme le successeur de l'analyse et de la conception orientées objet (OO).

Un objet contient à la fois des données et des méthodes qui contrôlent les données. Les données représentent l'état de l'objet. Une classe décrit un objet et forme également une hiérarchie pour modéliser le système réel. La hiérarchie est représentée comme un héritage et les classes peuvent également être associées de différentes manières selon l'exigence.

Les objets sont les entités du monde réel qui existent autour de nous et les concepts de base tels que l'abstraction, l'encapsulation, l'héritage et le polymorphisme peuvent tous être représentés en utilisant UML.

UML est suffisamment puissant pour représenter tous les concepts qui existent dans l'analyse et la conception orientées objet. Les diagrammes UML sont une représentation de concepts orientés objet uniquement. Ainsi, avant d'apprendre UML, il devient important de comprendre le concept OO en détail.

Voici quelques concepts fondamentaux du monde orienté objet -

  • Objects - Les objets représentent une entité et le bloc de construction de base.

  • Class - La classe est le schéma d'un objet.

  • Abstraction - L'abstraction représente le comportement d'une entité du monde réel.

  • Encapsulation - L'encapsulation est le mécanisme de liaison des données entre elles et de les cacher au monde extérieur.

  • Inheritance - L'héritage est le mécanisme de création de nouvelles classes à partir de classes existantes.

  • Polymorphism - Il définit le mécanisme d'exister sous différentes formes.

Analyse et conception OO

OO peut être défini comme une enquête et pour être plus précis, c'est l'investigation d'objets. Le design signifie la collaboration d'objets identifiés.

Ainsi, il est important de comprendre l'analyse OO et les concepts de conception. Le but le plus important de l'analyse OO est d'identifier les objets d'un système à concevoir. Cette analyse est également effectuée pour un système existant. Désormais, une analyse efficace n'est possible que lorsque nous sommes capables de commencer à penser de manière à identifier les objets. Après avoir identifié les objets, leurs relations sont identifiées et finalement le design est produit.

Le but de l'analyse et de la conception OO peut être décrit comme:

  • Identifier les objets d'un système.

  • Identifier leurs relations.

  • Faire un design, qui peut être converti en exécutables en utilisant les langages OO.

Il y a trois étapes de base où les concepts OO sont appliqués et mis en œuvre. Les étapes peuvent être définies comme

OO Analysis → OO Design → OO implementation using OO languages

Les trois points ci-dessus peuvent être décrits en détail comme -

  • Lors de l'analyse OO, l'objectif le plus important est d'identifier les objets et de les décrire de manière appropriée. Si ces objets sont identifiés efficacement, le prochain travail de conception est facile. Les objets doivent être identifiés avec des responsabilités. Les responsabilités sont les fonctions exécutées par l'objet. Chaque objet a un certain type de responsabilités à accomplir. Lorsque ces responsabilités sont associées, le but du système est rempli.

  • La deuxième phase est la conception OO. Au cours de cette phase, l'accent est mis sur les exigences et leur satisfaction. Dans cette étape, les objets sont collaborés selon leur association prévue. Une fois l'association terminée, la conception est également terminée.

  • La troisième phase est la mise en œuvre OO. Dans cette phase, la conception est implémentée à l'aide de langages OO tels que Java, C ++, etc.

Rôle d'UML dans la conception OO

UML est un langage de modélisation utilisé pour modéliser des systèmes logiciels et non logiciels. Bien que UML soit utilisé pour les systèmes non logiciels, l'accent est mis sur la modélisation des applications logicielles OO. La plupart des diagrammes UML discutés jusqu'à présent sont utilisés pour modéliser différents aspects tels que statique, dynamique, etc. Quel que soit l'aspect, les artefacts ne sont que des objets.

Si nous examinons le diagramme de classes, le diagramme d'objets, le diagramme de collaboration, les diagrammes d'interaction, tous seraient essentiellement conçus en fonction des objets.

Par conséquent, la relation entre la conception OO et UML est très importante à comprendre. La conception OO est transformée en diagrammes UML selon l'exigence. Avant de comprendre l'UML en détail, le concept OO doit être appris correctement. Une fois l'analyse et la conception OO terminées, l'étape suivante est très simple. L'entrée de l'analyse et de la conception OO est l'entrée des diagrammes UML.

Comme UML décrit les systèmes en temps réel, il est très important de créer un modèle conceptuel puis de procéder progressivement. Le modèle conceptuel d'UML peut être maîtrisé en apprenant les trois éléments majeurs suivants -

  • Blocs de construction UML
  • Règles pour connecter les blocs de construction
  • Mécanismes communs d'UML

Ce chapitre décrit tous les blocs de construction UML. Les blocs de construction d'UML peuvent être définis comme -

  • Things
  • Relationships
  • Diagrams

Des choses

Thingssont les blocs de construction les plus importants d'UML. Les choses peuvent être -

  • Structural
  • Behavioral
  • Grouping
  • Annotational

Choses structurelles

Structural thingsdéfinir la partie statique du modèle. Ils représentent les éléments physiques et conceptuels. Voici les brèves descriptions des éléments structurels.

Class − La classe représente un ensemble d'objets ayant des responsabilités similaires.

Interface − L'interface définit un ensemble d'opérations, qui spécifient la responsabilité d'une classe.

Collaboration −La collaboration définit une interaction entre les éléments.

Use case −Le cas d'utilisation représente un ensemble d'actions effectuées par un système pour un objectif spécifique.

Component −Le composant décrit la partie physique d'un système.

Node − Un nœud peut être défini comme un élément physique existant au moment de l'exécution.

Choses comportementales

A behavioral thingse compose des parties dynamiques des modèles UML. Voici les choses comportementales -

Interaction − L'interaction est définie comme un comportement qui consiste en un groupe de messages échangés entre des éléments pour accomplir une tâche spécifique.

State machine −La machine à états est utile lorsque l'état d'un objet dans son cycle de vie est important. Il définit la séquence d'états qu'un objet traverse en réponse à des événements. Les événements sont des facteurs externes responsables du changement d'état

Regrouper des choses

Grouping thingspeut être défini comme un mécanisme pour regrouper les éléments d'un modèle UML. Il n'y a qu'un seul élément de regroupement disponible -

Package − Le package est le seul élément de regroupement disponible pour rassembler des éléments structurels et comportementaux.

Choses annotatives

Annotational things peut être défini comme un mécanisme pour capturer des remarques, des descriptions et des commentaires d'éléments de modèle UML. Note- C'est le seul élément d'annotation disponible. Une note est utilisée pour rendre les commentaires, les contraintes, etc. d'un élément UML.

Relation

Relationshipest un autre élément constitutif le plus important d'UML. Il montre comment les éléments sont associés les uns aux autres et cette association décrit la fonctionnalité d'une application.

Il existe quatre types de relations disponibles.

Dépendance

La dépendance est une relation entre deux choses dans laquelle le changement d'un élément affecte également l'autre.

Association

L'association est essentiellement un ensemble de liens qui relie les éléments d'un modèle UML. Il décrit également le nombre d'objets qui participent à cette relation.

Généralisation

La généralisation peut être définie comme une relation qui relie un élément spécialisé à un élément généralisé. Il décrit essentiellement la relation d'héritage dans le monde des objets.

La concrétisation

La réalisation peut être définie comme une relation dans laquelle deux éléments sont liés. Un élément décrit une certaine responsabilité, qui n'est pas mise en œuvre et l'autre les met en œuvre. Cette relation existe dans le cas des interfaces.

Diagrammes UML

Les diagrammes UML sont le résultat ultime de toute la discussion. Tous les éléments, les relations sont utilisés pour créer un diagramme UML complet et le diagramme représente un système.

L'effet visuel du diagramme UML est la partie la plus importante de l'ensemble du processus. Tous les autres éléments sont utilisés pour le compléter.

UML comprend les neuf diagrammes suivants, dont les détails sont décrits dans les chapitres suivants.

  • Diagramme de classe
  • Diagramme d'objets
  • Diagramme de cas d'utilisation
  • Diagramme de séquençage
  • Diagramme de collaboration
  • Diagramme d'activité
  • Diagramme d'états
  • Diagramme de déploiement
  • Diagramme de composants

Tout système réel est utilisé par différents utilisateurs. Les utilisateurs peuvent être des développeurs, des testeurs, des professionnels, des analystes et bien d'autres. Par conséquent, avant de concevoir un système, l'architecture est conçue avec différentes perspectives à l'esprit. La partie la plus importante est de visualiser le système du point de vue de différents spectateurs. Mieux nous comprenons, mieux nous pouvons construire le système.

UML joue un rôle important dans la définition des différentes perspectives d'un système. Ces perspectives sont -

  • Design
  • Implementation
  • Process
  • Deployment

Le centre est le Use Casevue qui relie tous ces quatre. UNEUse Casereprésente la fonctionnalité du système. Par conséquent, d'autres perspectives sont liées au cas d'utilisation.

Designd'un système se compose de classes, d'interfaces et de collaboration. UML fournit un diagramme de classes, un diagramme d'objets pour prendre en charge cela.

Implementationdéfinit les composants assemblés pour former un système physique complet. Le diagramme de composants UML est utilisé pour prendre en charge la perspective d'implémentation.

Processdéfinit le flux du système. Par conséquent, les mêmes éléments que ceux utilisés dans la conception sont également utilisés pour soutenir cette perspective.

Deploymentreprésente les nœuds physiques du système qui forme le matériel. Le diagramme de déploiement UML est utilisé pour prendre en charge cette perspective.

Il est très important de faire la distinction entre le modèle UML. Différents diagrammes sont utilisés pour différents types de modélisation UML. Il existe trois types importants de modélisation UML.

Modélisation structurelle

La modélisation structurelle capture les caractéristiques statiques d'un système. Ils se composent des éléments suivants -

  • Diagrammes de classes
  • Diagrammes d'objets
  • Diagrammes de déploiement
  • Diagrammes de package
  • Diagramme de structure composite
  • Diagramme de composants

Le modèle structurel représente le cadre du système et ce cadre est le lieu où tous les autres composants existent. Par conséquent, le diagramme de classes, le diagramme de composants et les diagrammes de déploiement font partie de la modélisation structurelle. Ils représentent tous les éléments et le mécanisme pour les assembler.

Le modèle structurel ne décrit jamais le comportement dynamique du système. Le diagramme de classes est le diagramme structurel le plus utilisé.

Modélisation comportementale

Le modèle comportemental décrit l'interaction dans le système. Il représente l'interaction entre les diagrammes structurels. La modélisation comportementale montre la nature dynamique du système. Ils se composent des éléments suivants -

  • Diagrammes d'activités
  • Diagrammes d'interaction
  • Utiliser des diagrammes de cas

Tout ce qui précède montre la séquence dynamique du flux dans un système.

Modélisation architecturale

Le modèle architectural représente le cadre général du système. Il contient des éléments structurels et comportementaux du système. Le modèle architectural peut être défini comme le modèle de l'ensemble du système. Le diagramme de package relève de la modélisation architecturale.

UML est populaire pour ses notations schématiques. Nous savons tous que UML sert à visualiser, spécifier, construire et documenter les composants des systèmes logiciels et non logiciels. Par conséquent, la visualisation est la partie la plus importante qui doit être comprise et mémorisée.

Les notations UML sont les éléments les plus importants de la modélisation. L'utilisation efficace et appropriée des notations est très importante pour créer un modèle complet et significatif. Le modèle est inutile, à moins que son objectif ne soit correctement décrit.

Par conséquent, l'apprentissage des notations doit être souligné dès le début. Différentes notations sont disponibles pour les choses et les relations. Les diagrammes UML sont créés en utilisant les notations des choses et des relations. L'extensibilité est une autre caractéristique importante qui rend UML plus puissant et plus flexible.

Le chapitre décrit en détail les notations UML de base. Ceci est juste une extension de la section des blocs de construction UML abordée dans le chapitre deux.

Choses structurelles

Les notations graphiques utilisées dans les choses structurelles sont les plus largement utilisées dans UML. Ceux-ci sont considérés comme les noms des modèles UML. Voici la liste des éléments structurels.

  • Classes
  • Object
  • Interface
  • Collaboration
  • Cas d'utilisation
  • Classes actives
  • Components
  • Nodes

Notation de classe

La classe UML est représentée par la figure suivante. Le diagramme est divisé en quatre parties.

  • La section supérieure est utilisée pour nommer la classe.
  • Le second est utilisé pour montrer les attributs de la classe.
  • La troisième section est utilisée pour décrire les opérations effectuées par la classe.
  • La quatrième section est facultative pour montrer les composants supplémentaires.

Les classes sont utilisées pour représenter des objets. Les objets peuvent être tout ce qui a des propriétés et des responsabilités.

Notation d'objet

L' objet est représenté de la même manière que la classe. La seule différence est le nom qui est souligné comme indiqué dans la figure suivante.

Comme l'objet est une implémentation réelle d'une classe, qui est connue comme l'instance d'une classe. Par conséquent, il a le même usage que la classe.

Notation d'interface

L'interface est représentée par un cercle comme illustré dans la figure suivante. Il a un nom qui est généralement écrit sous le cercle.

L'interface est utilisée pour décrire la fonctionnalité sans implémentation. L'interface est comme un modèle dans lequel vous définissez différentes fonctions, pas l'implémentation. Lorsqu'une classe implémente l'interface, elle implémente également la fonctionnalité selon les besoins.

Notation de collaboration

La collaboration est représentée par une éclipse en pointillé, comme illustré dans la figure suivante. Il a un nom écrit à l'intérieur de l'éclipse.

La collaboration représente des responsabilités. Généralement, les responsabilités sont dans un groupe.

Notation de cas d'utilisation

Le cas d'utilisation est représenté comme une éclipse avec un nom à l'intérieur. Il peut contenir des responsabilités supplémentaires.

Le cas d'utilisation est utilisé pour capturer les fonctionnalités de haut niveau d'un système.

Notation d'acteur

Un acteur peut être défini comme une entité interne ou externe qui interagit avec le système.

Un acteur est utilisé dans un diagramme de cas d'utilisation pour décrire les entités internes ou externes.

Notation de l'état initial

L'état initial est défini pour indiquer le début d'un processus. Cette notation est utilisée dans presque tous les diagrammes.

L'utilisation de la notation d'état initial est de montrer le point de départ d'un processus.

Notation de l'état final

L'état final est utilisé pour montrer la fin d'un processus. Cette notation est également utilisée dans presque tous les diagrammes pour décrire la fin.

L'utilisation de la notation d'état final est de montrer le point de terminaison d'un processus.

Notation de classe active

La classe active ressemble à une classe avec une bordure pleine. La classe active est généralement utilisée pour décrire le comportement concurrent d'un système.

La classe active est utilisée pour représenter la concurrence dans un système.

Notation des composants

Un composant en UML est illustré dans la figure suivante avec un nom à l'intérieur. Des éléments supplémentaires peuvent être ajoutés si nécessaire.

Le composant est utilisé pour représenter n'importe quelle partie d'un système pour laquelle des diagrammes UML sont créés.

Notation de nœud

Un nœud en UML est représenté par une boîte carrée comme illustré dans la figure suivante avec un nom. Un nœud représente le composant physique du système.

Node est utilisé pour représenter la partie physique d'un système comme le serveur, le réseau, etc.

Choses comportementales

Les parties dynamiques sont l'un des éléments les plus importants d'UML. UML dispose d'un ensemble de fonctionnalités puissantes pour représenter la partie dynamique des systèmes logiciels et non logiciels. Ces fonctionnalités incluent les interactions et les machines d'état .

Les interactions peuvent être de deux types -

  • Séquentiel (représenté par un diagramme de séquence)
  • Collaboratif (représenté par un diagramme de collaboration)

Notation d'interaction

L'interaction est essentiellement un échange de messages entre deux composants UML. Le diagramme suivant représente différentes notations utilisées dans une interaction.

L'interaction est utilisée pour représenter la communication entre les composants d'un système.

Notation de machine d'état

La machine d'état décrit les différents états d'un composant dans son cycle de vie. Les notations sont décrites dans le schéma suivant.

La machine d'état est utilisée pour décrire différents états d'un composant système. L'état peut être actif, inactif ou tout autre selon la situation.

Regrouper des choses

L'organisation des modèles UML est l'un des aspects les plus importants de la conception. Dans UML, il n'y a qu'un seul élément disponible pour le regroupement et c'est le package.

Notation de paquet

La notation de package est illustrée dans la figure suivante et est utilisée pour envelopper les composants d'un système.

Choses annotatives

Dans tout schéma, l'explication des différents éléments et de leurs fonctionnalités est très importante. Par conséquent, UML a une notation de notes pour prendre en charge cette exigence.

Notation de note

Cette notation est illustrée dans la figure suivante. Ces notations sont utilisées pour fournir les informations nécessaires sur un système.

Des relations

Un modèle n'est complet que si les relations entre les éléments sont correctement décrites. La Relation donne un sens propre à un modèle UML. Voici les différents types de relations disponibles dans UML.

  • Dependency
  • Association
  • Generalization
  • Extensibility

Notation de dépendance

La dépendance est un aspect important des éléments UML. Il décrit les éléments dépendants et le sens de la dépendance.

La dépendance est représentée par une flèche en pointillé, comme illustré dans la figure suivante. La tête de flèche représente l'élément indépendant et l'autre extrémité représente l'élément dépendant.

La dépendance est utilisée pour représenter la dépendance entre deux éléments d'un système

Notation d'association

L'association décrit comment les éléments d'un diagramme UML sont associés. En termes simples, il décrit le nombre d'éléments qui participent à une interaction.

L'association est représentée par une ligne pointillée avec (sans) flèches des deux côtés. Les deux extrémités représentent deux éléments associés, comme illustré dans la figure suivante. La multiplicité est également mentionnée aux extrémités (1, *, etc.) pour montrer combien d'objets sont associés.

L'association est utilisée pour représenter la relation entre deux éléments d'un système.

Notation de généralisation

La généralisation décrit la relation d'héritage du monde orienté objet. C'est une relation parent-enfant.

La généralisation est représentée par une flèche avec une tête de flèche creuse comme illustré dans la figure suivante. Une extrémité représente l'élément parent et l'autre extrémité représente l'élément enfant.

La généralisation est utilisée pour décrire la relation parent-enfant de deux éléments d'un système.

Notation d'extensibilité

Tous les langages (programmation ou modélisation) ont un mécanisme pour étendre ses capacités telles que la syntaxe, la sémantique, etc. UML dispose également des mécanismes suivants pour fournir des fonctionnalités d'extensibilité.

  • Stéréotypes (représente de nouveaux éléments)
  • Valeurs balisées (représente les nouveaux attributs)
  • Contraintes (représente les limites)

Les notations d'extensibilité sont utilisées pour améliorer la puissance du langage. Il s'agit essentiellement d'éléments supplémentaires utilisés pour représenter un comportement supplémentaire du système. Ces comportements supplémentaires ne sont pas couverts par les notations standard disponibles.

Dans les chapitres précédents, nous avons discuté des blocs de construction et d'autres éléments nécessaires d'UML. Nous devons maintenant comprendre où utiliser ces éléments.

Les éléments sont comme des composants qui peuvent être associés de différentes manières pour créer une image UML complète, connue sous le nom de diagramme. Ainsi, il est très important de comprendre les différents schémas pour mettre en œuvre les connaissances dans des systèmes réels.

Tout système complexe est mieux compris en créant une sorte de diagrammes ou d'images. Ces diagrammes ont un meilleur impact sur notre compréhension. Si nous regardons autour de nous, nous nous rendrons compte que les diagrammes ne sont pas un nouveau concept mais qu'ils sont largement utilisés sous différentes formes dans différentes industries.

Nous préparons des diagrammes UML pour comprendre le système d'une manière meilleure et simple. Un seul schéma ne suffit pas pour couvrir tous les aspects du système. UML définit différents types de diagrammes pour couvrir la plupart des aspects d'un système.

Vous pouvez également créer votre propre ensemble de diagrammes pour répondre à vos besoins. Les diagrammes sont généralement réalisés de manière incrémentielle et itérative.

Il existe deux grandes catégories de diagrammes et ils sont à nouveau divisés en sous-catégories -

  • Diagrammes structurels

  • Diagrammes comportementaux

Diagrammes structurels

Les diagrammes structurels représentent l'aspect statique du système. Ces aspects statiques représentent les parties d'un diagramme, qui forment la structure principale et sont donc stables.

Ces parties statiques sont représentées par des classes, des interfaces, des objets, des composants et des nœuds. Les quatre schémas structurels sont -

  • Diagramme de classe
  • Diagramme d'objets
  • Diagramme de composants
  • Diagramme de déploiement

Diagramme de classe

Les diagrammes de classes sont les diagrammes les plus couramment utilisés dans UML. Le diagramme de classes se compose de classes, d'interfaces, d'associations et de collaboration. Les diagrammes de classes représentent essentiellement la vue orientée objet d'un système, qui est de nature statique.

La classe active est utilisée dans un diagramme de classes pour représenter la concurrence du système.

Le diagramme de classes représente l'orientation objet d'un système. Par conséquent, il est généralement utilisé à des fins de développement. Il s'agit du schéma le plus utilisé au moment de la construction du système.

Diagramme d'objets

Les diagrammes d'objets peuvent être décrits comme une instance de diagramme de classes. Ainsi, ces schémas sont plus proches de scénarios réels où nous implémentons un système.

Les diagrammes d'objets sont un ensemble d'objets et leur relation est comme les diagrammes de classes. Ils représentent également la vue statique du système.

L'utilisation des diagrammes d'objets est similaire aux diagrammes de classes, mais ils sont utilisés pour construire le prototype d'un système d'un point de vue pratique.

Diagramme des composants

Les diagrammes de composants représentent un ensemble de composants et leurs relations. Ces composants sont constitués de classes, d'interfaces ou de collaborations. Les diagrammes de composants représentent la vue d'implémentation d'un système.

Pendant la phase de conception, les artefacts logiciels (classes, interfaces, etc.) d'un système sont organisés en différents groupes en fonction de leur relation. Désormais, ces groupes sont appelés composants.

Enfin, on peut dire que des diagrammes de composants sont utilisés pour visualiser l'implémentation.

Diagramme de déploiement

Les diagrammes de déploiement sont un ensemble de nœuds et de leurs relations. Ces nœuds sont des entités physiques sur lesquelles les composants sont déployés.

Les diagrammes de déploiement sont utilisés pour visualiser la vue de déploiement d'un système. Ceci est généralement utilisé par l'équipe de déploiement.

Note- Si les descriptions et usages ci-dessus sont observés attentivement, il est très clair que tous les schémas ont des relations les uns avec les autres. Les diagrammes de composants dépendent des classes, interfaces, etc. qui font partie du diagramme de classes / objets. Là encore, le diagramme de déploiement dépend des composants, qui sont utilisés pour créer des diagrammes de composants.

Diagrammes comportementaux

Tout système peut avoir deux aspects, statique et dynamique. Ainsi, un modèle est considéré comme complet lorsque les deux aspects sont entièrement couverts.

Les diagrammes comportementaux capturent essentiellement l'aspect dynamique d'un système. L'aspect dynamique peut être davantage décrit comme les parties changeantes / mobiles d'un système.

UML a les cinq types de diagrammes comportementaux suivants -

  • Diagramme de cas d'utilisation
  • Diagramme de séquençage
  • Diagramme de collaboration
  • Diagramme d'états
  • Diagramme d'activité

Diagramme de cas d'utilisation

Les diagrammes de cas d'utilisation sont un ensemble de cas d'utilisation, d'acteurs et de leurs relations. Ils représentent la vue de cas d'utilisation d'un système.

Un cas d'utilisation représente une fonctionnalité particulière d'un système. Par conséquent, un diagramme de cas d'utilisation est utilisé pour décrire les relations entre les fonctionnalités et leurs contrôleurs internes / externes. Ces contrôleurs sont appelésactors.

Diagramme de séquençage

Un diagramme de séquence est un diagramme d'interaction. D'après le nom, il est clair que le diagramme traite de certaines séquences, qui sont la séquence de messages circulant d'un objet à un autre.

L'interaction entre les composants d'un système est très importante du point de vue de la mise en œuvre et de l'exécution. Le diagramme de séquence est utilisé pour visualiser la séquence d'appels dans un système pour exécuter une fonctionnalité spécifique.

Diagramme de collaboration

Le diagramme de collaboration est une autre forme de diagramme d'interaction. Il représente l'organisation structurelle d'un système et les messages envoyés / reçus. L'organisation structurelle se compose d'objets et de liens.

Le but du diagramme de collaboration est similaire au diagramme de séquence. Cependant, le but spécifique du diagramme de collaboration est de visualiser l'organisation des objets et leur interaction.

Diagramme d'états

On s'attend à ce que tout système en temps réel réagisse à une sorte d'événements internes / externes. Ces événements sont responsables du changement d'état du système.

Le diagramme d'états est utilisé pour représenter le changement d'état d'un système en fonction des événements. Il décrit essentiellement le changement d'état d'une classe, d'une interface, etc.

Le diagramme d'état est utilisé pour visualiser la réaction d'un système par des facteurs internes / externes.

Diagramme d'activité

Le diagramme d'activité décrit le flux de contrôle dans un système. Il se compose d'activités et de liens. Le flux peut être séquentiel, concurrent ou ramifié.

Les activités ne sont rien d'autre que les fonctions d'un système. Des nombres de diagrammes d'activités sont préparés pour capturer l'ensemble du flux dans un système.

Les diagrammes d'activités sont utilisés pour visualiser le flux des contrôles dans un système. Ceci est préparé pour avoir une idée de la façon dont le système fonctionnera une fois exécuté.

Note- La nature dynamique d'un système est très difficile à saisir. UML a fourni des fonctionnalités pour capturer la dynamique d'un système sous différents angles. Les diagrammes de séquence et les diagrammes de collaboration sont isomorphes, ils peuvent donc être convertis les uns des autres sans perdre aucune information. Ceci est également vrai pour Statechart et diagramme d'activité.

Le diagramme de classes est un diagramme statique. Il représente la vue statique d'une application. Le diagramme de classes n'est pas seulement utilisé pour visualiser, décrire et documenter différents aspects d'un système, mais également pour construire le code exécutable de l'application logicielle.

Le diagramme de classes décrit les attributs et les opérations d'une classe ainsi que les contraintes imposées au système. Les diagrammes de classes sont largement utilisés dans la modélisation de systèmes orientés objet car ce sont les seuls diagrammes UML, qui peuvent être mappés directement avec des langages orientés objet.

Le diagramme de classes montre une collection de classes, d'interfaces, d'associations, de collaborations et de contraintes. Il est également connu sous le nom de diagramme structurel.

Objectif des diagrammes de classes

Le but du diagramme de classes est de modéliser la vue statique d'une application. Les diagrammes de classes sont les seuls diagrammes qui peuvent être directement mappés avec des langages orientés objet et donc largement utilisés au moment de la construction.

Les diagrammes UML comme le diagramme d'activité, le diagramme de séquence ne peuvent donner que le flux de séquence de l'application, mais le diagramme de classes est un peu différent. C'est le diagramme UML le plus populaire de la communauté des codeurs.

Le but du diagramme de classes peut être résumé comme suit:

  • Analyse et conception de la vue statique d'une application.

  • Décrivez les responsabilités d'un système.

  • Base pour les diagrammes de composants et de déploiement.

  • Ingénierie directe et inverse.

Comment dessiner un diagramme de classes?

Les diagrammes de classes sont les diagrammes UML les plus utilisés pour la construction d'applications logicielles. Il est très important d'apprendre la procédure de dessin du diagramme de classes.

Les diagrammes de classes ont de nombreuses propriétés à prendre en compte lors du dessin, mais ici, le diagramme sera considéré à partir d'une vue de niveau supérieur.

Le diagramme de classes est essentiellement une représentation graphique de la vue statique du système et représente différents aspects de l'application. Une collection de diagrammes de classes représente l'ensemble du système.

Les points suivants doivent être rappelés lors du dessin d'un diagramme de classe -

  • Le nom du diagramme de classes doit être significatif pour décrire l'aspect du système.

  • Chaque élément et leurs relations doivent être identifiés à l'avance.

  • La responsabilité (attributs et méthodes) de chaque classe doit être clairement identifiée

  • Pour chaque classe, un nombre minimum de propriétés doit être spécifié, car des propriétés inutiles compliqueront le diagramme.

  • Utilisez des notes chaque fois que nécessaire pour décrire certains aspects du diagramme. À la fin du dessin, cela devrait être compréhensible pour le développeur / codeur.

  • Enfin, avant de faire la version finale, le diagramme doit être dessiné sur du papier ordinaire et retravaillé autant de fois que possible pour le rendre correct.

Le diagramme suivant est un exemple de système de commande d'une application. Il décrit un aspect particulier de l'ensemble de l'application.

  • Tout d'abord, la commande et le client sont identifiés comme les deux éléments du système. Ils ont une relation un-à-plusieurs car un client peut avoir plusieurs commandes.

  • La classe Order est une classe abstraite et elle a deux classes concrètes (relation d'héritage) SpecialOrder et NormalOrder.

  • Les deux classes héritées ont toutes les propriétés de la classe Order. De plus, ils ont des fonctions supplémentaires comme dispatch () et receive ().

Le diagramme de classe suivant a été dessiné en tenant compte de tous les points mentionnés ci-dessus.

Où utiliser les diagrammes de classes?

Le diagramme de classes est un diagramme statique utilisé pour modéliser la vue statique d'un système. La vue statique décrit le vocabulaire du système.

Le diagramme de classes est également considéré comme la base des diagrammes de composants et de déploiement. Les diagrammes de classes ne sont pas seulement utilisés pour visualiser la vue statique du système, mais ils sont également utilisés pour construire le code exécutable pour l'ingénierie en amont et en aval de n'importe quel système.

Généralement, les diagrammes UML ne sont pas directement mappés avec des langages de programmation orientés objet, mais le diagramme de classes est une exception.

Le diagramme de classes montre clairement le mappage avec des langages orientés objet tels que Java, C ++, etc. D'après l'expérience pratique, le diagramme de classes est généralement utilisé à des fins de construction.

En un mot, on peut dire que les diagrammes de classes sont utilisés pour -

  • Décrire la vue statique du système.

  • Montre la collaboration entre les éléments de la vue statique.

  • Décrire les fonctionnalités réalisées par le système.

  • Construction d'applications logicielles utilisant des langages orientés objet.

Les diagrammes d'objets sont dérivés de diagrammes de classes, donc 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 particulier.

Les diagrammes d'objets sont utilisés pour rendre un ensemble d'objets et leurs relations comme une instance.

Objectif des diagrammes d'objets

Le but d'un diagramme doit être clairement compris pour le mettre en œuvre de manière pratique. Les objectifs des diagrammes d'objets sont similaires à ceux des 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 de nature concrète.

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 donné.

Le but du diagramme d'objets peut être résumé comme suit:

  • Ingénierie directe et inverse.

  • Relations d'objets 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'objets?

Nous avons déjà discuté du fait qu'un diagramme d'objets est une instance d'un diagramme de classes. Cela implique qu'un diagramme d'objets se compose d'instances d'objets utilisés dans un diagramme de classes.

Les deux diagrammes sont donc constitués des mêmes éléments de base mais sous une forme différente. Dans le diagramme de classes, les éléments sont sous forme abstraite pour représenter le modèle et dans le diagramme d'objet, les éléments sont sous forme concrète pour représenter l'objet du monde réel.

Pour capturer un système particulier, le nombre de diagrammes de classes est limité. Cependant, si nous considérons les diagrammes d'objets, nous pouvons avoir un nombre illimité d'instances, qui sont uniques par nature. Seules les instances qui ont un impact sur le système sont prises en compte.

D'après la discussion ci-dessus, il est clair qu'un diagramme d'objet unique ne peut pas capturer toutes les instances nécessaires ou plutôt ne peut pas spécifier tous les objets d'un système. Par conséquent, la solution est -

  • Tout d'abord, analysez le système et décidez quelles instances ont des données et des associations importantes.

  • Deuxièmement, ne considérez que les instances qui couvriront la fonctionnalité.

  • Troisièmement, faites une optimisation car le nombre d'instances est illimité.

Avant de dessiner un diagramme d'objets, les choses suivantes doivent être rappelées et clairement comprises -

  • Les diagrammes d'objets sont constitués d'objets.

  • Le lien dans le diagramme d'objets est utilisé pour connecter des objets.

  • Les objets et les liens sont les deux éléments utilisés pour construire un diagramme d'objets.

Après cela, les choses suivantes doivent être décidées avant de commencer la construction du diagramme -

  • Le diagramme d'objets doit avoir un nom significatif pour indiquer son objectif.

  • Les éléments les plus importants doivent être identifiés.

  • L'association entre les objets doit être clarifiée.

  • Les valeurs des différents éléments doivent être capturées pour être incluses dans le diagramme d'objets.

  • Ajoutez des notes appropriées aux points où plus de clarté est nécessaire.

Le diagramme suivant est un exemple de diagramme d'objets. Il représente le système de gestion des commandes dont nous avons parlé dans le chapitre Diagramme de classes. Le diagramme suivant est une instance du système à un moment particulier de l'achat. Il a les objets suivants.

  • Customer

  • Order

  • SpecialOrder

  • NormalOrder

Désormais, l'objet client (C) est associé à trois objets de commande (O1, O2 et O3). Ces objets d'ordre sont associés à des objets d'ordre spécial et d'ordre normal (S1, S2 et N1). Le client a les trois commandes suivantes avec des numéros différents (12, 32 et 40) pour le temps particulier considéré.

Le client peut augmenter le nombre de commandes à l'avenir et dans ce scénario, le diagramme d'objets reflétera cela. Si des objets d'ordre, d'ordre spécial et d'ordre normal sont observés, vous constaterez qu'ils ont des valeurs.

Pour les commandes, les valeurs sont 12, 32 et 40, ce qui implique que les objets ont ces valeurs pour un moment particulier (ici le moment particulier où l'achat est effectué est considéré comme le moment) où l'instance est capturée

Il en va de même pour les objets de commande spéciale et de commande normale dont le nombre de commandes est égal à 20, 30 et 60. Si un moment d'achat différent est pris en compte, ces valeurs changeront en conséquence.

Le diagramme d'objets suivant a été dessiné en tenant compte de tous les points mentionnés ci-dessus

Où utiliser les diagrammes d'objets?

Les diagrammes d'objets peuvent être imaginés comme l'instantané d'un système en cours d'exécution à un moment donné. Prenons un exemple de train en marche

Maintenant, si vous prenez une photo du train en marche, vous trouverez une image statique de celui-ci ayant ce qui suit -

  • Un état particulier qui est en cours d'exécution.

  • Un nombre particulier de passagers. qui changera si le cliché est pris à un moment différent

Ici, nous pouvons imaginer que le claquement du train en marche est un objet ayant les valeurs ci-dessus. Et cela est vrai pour tout système simple ou complexe réel.

En un mot, on peut dire que les diagrammes d'objets sont utilisés pour -

  • Faire le prototype d'un système.

  • Ingénierie inverse.

  • Modélisation de structures de données complexes.

  • Comprendre le système d'un point de vue pratique.

Les diagrammes de composants sont différents en termes de nature et de comportement. Les diagrammes de composants sont utilisés pour modéliser les aspects physiques d'un système. Maintenant, la question est de savoir quels sont ces aspects physiques? Les aspects physiques sont les éléments tels que les exécutables, les bibliothèques, les fichiers, les documents, etc. qui résident dans un nœud.

Les diagrammes de composants sont utilisés pour visualiser l'organisation et les relations entre les composants d'un système. Ces diagrammes sont également utilisés pour créer des systèmes exécutables.

Objectif des diagrammes de composants

Le diagramme de composants est un type particulier de diagramme en UML. Le but est également différent de tous les autres diagrammes discutés jusqu'à présent. Il ne décrit pas la fonctionnalité du système mais décrit les composants utilisés pour créer ces fonctionnalités.

Ainsi, de ce point de vue, les diagrammes de composants sont utilisés pour visualiser les composants physiques d'un système. Ces composants sont des bibliothèques, des packages, des fichiers, etc.

Les diagrammes de composants peuvent également être décrits comme une vue d'implémentation statique d'un système. L'implémentation statique représente l'organisation des composants à un moment donné.

Un diagramme à un seul composant ne peut pas représenter l'ensemble du système mais une collection de diagrammes est utilisée pour représenter l'ensemble.

Le but du diagramme des composants peut être résumé comme suit:

  • Visualisez les composants d'un système.

  • Construisez des exécutables en utilisant l'ingénierie directe et inverse.

  • Décrivez l'organisation et les relations des composants.

Comment dessiner un diagramme de composants?

Les diagrammes de composants sont utilisés pour décrire les artefacts physiques d'un système. Cet artefact comprend des fichiers, des exécutables, des bibliothèques, etc.

Le but de ce diagramme est différent. Les diagrammes de composants sont utilisés pendant la phase d'implémentation d'une application. Cependant, il est préparé longtemps à l'avance pour visualiser les détails de mise en œuvre.

Au départ, le système est conçu à l'aide de différents diagrammes UML, puis lorsque les artefacts sont prêts, des diagrammes de composants sont utilisés pour se faire une idée de l'implémentation.

Ce diagramme est très important car sans lui l'application ne peut pas être mise en œuvre efficacement. Un diagramme de composants bien préparé est également important pour d'autres aspects tels que les performances de l'application, la maintenance, etc.

Avant de dessiner un diagramme de composants, les artefacts suivants doivent être clairement identifiés -

  • Fichiers utilisés dans le système.

  • Bibliothèques et autres artefacts pertinents pour l'application.

  • Relations entre les artefacts.

Après avoir identifié les artefacts, les points suivants doivent être gardés à l'esprit.

  • Utilisez un nom significatif pour identifier le composant pour lequel le diagramme doit être dessiné.

  • Préparez une mise en page mentale avant de produire les outils d'utilisation.

  • Utilisez des notes pour clarifier les points importants.

Voici un diagramme des composants du système de gestion des commandes. Ici, les artefacts sont des fichiers. Le diagramme montre les fichiers de l'application et leurs relations. En réalité, le diagramme des composants contient également des dll, des bibliothèques, des dossiers, etc.

Dans le diagramme suivant, quatre fichiers sont identifiés et leurs relations sont produites. Le diagramme de composants ne peut pas être mis en correspondance directement avec d'autres diagrammes UML décrits dans la mesure où il est dessiné dans un but complètement différent.

Le diagramme de composants suivant a été dessiné en tenant compte de tous les points mentionnés ci-dessus.

Où utiliser les diagrammes de composants?

Nous avons déjà décrit que les diagrammes de composants sont utilisés pour visualiser la vue d'implémentation statique d'un système. Les diagrammes de composants sont des types spéciaux de diagrammes UML utilisés à des fins différentes.

Ces schémas montrent les composants physiques d'un système. Pour le clarifier, on peut dire que les diagrammes de composants décrivent l'organisation des composants dans un système.

L'organisation peut être davantage décrite comme l'emplacement des composants dans un système. Ces composants sont organisés d'une manière spéciale pour répondre aux exigences du système.

Comme nous l'avons déjà évoqué, ces composants sont des bibliothèques, des fichiers, des exécutables, etc. Avant d'implémenter l'application, ces composants doivent être organisés. Cette organisation des composants est également conçue séparément dans le cadre de l'exécution du projet.

Les diagrammes de composants sont très importants du point de vue de la mise en œuvre. Ainsi, l'équipe d'implémentation d'une application doit avoir une bonne connaissance des détails des composants

Les diagrammes de composants peuvent être utilisés pour -

  • Modélisez les composants d'un système.

  • Modélisez le schéma de la base de données.

  • Modélisez les exécutables d'une application.

  • Modélisez le code source du système.

Les diagrammes de déploiement sont utilisés pour visualiser la topologie des composants physiques d'un système, où les composants logiciels sont déployés.

Les diagrammes de déploiement sont utilisés pour décrire la vue de déploiement statique d'un système. Les diagrammes de déploiement sont constitués de nœuds et de leurs relations.

Objectif des diagrammes de déploiement

Le terme Déploiement lui-même décrit l'objectif du diagramme. Les diagrammes de déploiement sont utilisés pour décrire les composants matériels, là où les composants logiciels sont déployés. Les diagrammes de composants et les diagrammes de déploiement sont étroitement liés.

Les diagrammes de composants sont utilisés pour décrire les composants et les diagrammes de déploiement montrent comment ils sont déployés dans le matériel.

UML est principalement conçu pour se concentrer sur les artefacts logiciels d'un système. Cependant, ces deux diagrammes sont des diagrammes spéciaux utilisés pour se concentrer sur les composants logiciels et matériels.

La plupart des diagrammes UML sont utilisés pour gérer les composants logiques, mais les diagrammes de déploiement sont conçus pour se concentrer sur la topologie matérielle d'un système. Les diagrammes de déploiement sont utilisés par les ingénieurs système.

L'objectif des diagrammes de déploiement peut être décrit comme suit:

  • Visualisez la topologie matérielle d'un système.

  • Décrivez les composants matériels utilisés pour déployer les composants logiciels.

  • Décrivez les nœuds de traitement d'exécution.

Comment dessiner un diagramme de déploiement?

Le diagramme de déploiement représente la vue de déploiement d'un système. Il est lié au diagramme de composants car les composants sont déployés à l'aide des diagrammes de déploiement. Un diagramme de déploiement se compose de nœuds. Les nœuds ne sont rien d'autre que du matériel physique utilisé pour déployer l'application.

Les diagrammes de déploiement sont utiles pour les ingénieurs système. Un diagramme de déploiement efficace est très important car il contrôle les paramètres suivants -

  • Performance

  • Scalability

  • Maintainability

  • Portability

Avant de dessiner un diagramme de déploiement, les artefacts suivants doivent être identifiés -

  • Nodes

  • Relations entre les nœuds

Voici un exemple de diagramme de déploiement pour donner une idée de la vue de déploiement du système de gestion des commandes. Ici, nous avons montré les nœuds comme -

  • Monitor

  • Modem

  • Serveur de cache

  • Server

L'application est supposée être une application Web, qui est déployée dans un environnement en cluster à l'aide du serveur 1, du serveur 2 et du serveur 3. L'utilisateur se connecte à l'application via Internet. Le contrôle circule du serveur de mise en cache vers l'environnement en cluster.

Le diagramme de déploiement suivant a été dessiné en tenant compte de tous les points mentionnés ci-dessus.

Où utiliser les diagrammes de déploiement?

Les diagrammes de déploiement sont principalement utilisés par les ingénieurs système. Ces diagrammes sont utilisés pour décrire les composants physiques (matériel), leur distribution et leur association.

Les diagrammes de déploiement peuvent être visualisés comme les composants matériels / nœuds sur lesquels résident les composants logiciels.

Les applications logicielles sont développées pour modéliser des processus métier complexes. Des applications logicielles efficaces ne sont pas suffisantes pour répondre aux exigences de l'entreprise. Les exigences commerciales peuvent être décrites comme la nécessité de prendre en charge le nombre croissant d'utilisateurs, le temps de réponse rapide, etc.

Pour répondre à ces types d'exigences, les composants matériels doivent être conçus de manière efficace et rentable.

Les applications logicielles actuelles sont de nature très complexe. Les applications logicielles peuvent être autonomes, basées sur le Web, distribuées, basées sur un mainframe et bien d'autres. Par conséquent, il est très important de concevoir efficacement les composants matériels.

Des diagrammes de déploiement peuvent être utilisés -

  • Pour modéliser la topologie matérielle d'un système.

  • Modéliser le système embarqué.

  • Pour modéliser les détails matériels d'un système client / serveur.

  • Pour modéliser les détails matériels d'une application distribuée.

  • Pour l'ingénierie directe et inverse.

Pour modéliser un système, l'aspect le plus important est de capturer le comportement dynamique. Le comportement dynamique désigne le comportement du système lorsqu'il fonctionne / fonctionne.

Seul le comportement statique n'est pas suffisant pour modéliser un système plutôt qu'un comportement dynamique est plus important que le comportement statique. Dans UML, cinq diagrammes sont disponibles pour modéliser la nature dynamique et le diagramme de cas d'utilisation en fait partie. Maintenant que nous devons discuter du fait que le diagramme de cas d'utilisation est de nature dynamique, il devrait y avoir des facteurs internes ou externes pour faire l'interaction.

Ces agents internes et externes sont appelés acteurs. Les diagrammes de cas d'utilisation se composent d'acteurs, de cas d'utilisation et de leurs relations. Le diagramme est utilisé pour modéliser le système / sous-système d'une application. Un diagramme de cas d'utilisation unique capture une fonctionnalité particulière d'un système.

Par conséquent, pour modéliser l'ensemble du système, un certain nombre de diagrammes de cas d'utilisation sont utilisés.

Objectif des diagrammes de cas d'utilisation

Le but du diagramme de cas d'utilisation est de capturer l'aspect dynamique d'un système. Cependant, cette définition est trop générique pour décrire l'objectif, car quatre autres diagrammes (activité, séquence, collaboration et Statechart) ont également le même objectif. Nous examinerons un objectif spécifique, qui le distinguera des quatre autres schémas.

Les diagrammes de cas d'utilisation sont utilisés pour rassembler les exigences d'un système, y compris les influences internes et externes. Ces exigences sont principalement des exigences de conception. Ainsi, lorsqu'un système est analysé pour rassembler ses fonctionnalités, des cas d'utilisation sont préparés et les acteurs sont identifiés.

Lorsque la tâche initiale est terminée, des diagrammes de cas d'utilisation sont modélisés pour présenter la vue extérieure.

En bref, les objectifs des diagrammes de cas d'utilisation peuvent être les suivants:

  • Utilisé pour rassembler les exigences d'un système.

  • Utilisé pour obtenir une vue extérieure d'un système.

  • Identifiez les facteurs externes et internes qui influencent le système.

  • Montrer l'interaction entre les exigences sont des acteurs.

Comment dessiner un diagramme de cas d'utilisation?

Les diagrammes de cas d'utilisation sont pris en compte pour l'analyse des exigences de haut niveau d'un système. Lorsque les exigences d'un système sont analysées, les fonctionnalités sont capturées dans des cas d'utilisation.

On peut dire que les cas d'utilisation ne sont rien d'autre que les fonctionnalités du système écrites de manière organisée. La deuxième chose qui est pertinente pour les cas d'utilisation sont les acteurs. Les acteurs peuvent être définis comme quelque chose qui interagit avec le système.

Les acteurs peuvent être un utilisateur humain, certaines applications internes ou certaines applications externes. Lorsque nous prévoyons de dessiner un diagramme de cas d'utilisation, nous devons identifier les éléments suivants.

  • Fonctionnalités à représenter comme cas d'utilisation

  • Actors

  • Relations entre les cas d'utilisation et les acteurs.

Des diagrammes de cas d'utilisation sont dessinés pour capturer les exigences fonctionnelles d'un système. Après avoir identifié les éléments ci-dessus, nous devons utiliser les directives suivantes pour dessiner un diagramme de cas d'utilisation efficace

  • Le nom d'un cas d'utilisation est très important. Le nom doit être choisi de manière à pouvoir identifier les fonctionnalités réalisées.

  • Donnez un nom approprié aux acteurs.

  • Montrez clairement les relations et les dépendances dans le diagramme.

  • N'essayez pas d'inclure tous les types de relations, car le but principal du diagramme est d'identifier les exigences.

  • Utilisez des notes chaque fois que nécessaire pour clarifier certains points importants.

Voici un exemple de diagramme de cas d'utilisation représentant le système de gestion des commandes. Par conséquent, si nous examinons le diagramme, nous trouverons trois cas d'utilisation(Order, SpecialOrder, and NormalOrder) et un acteur qui est le client.

Les cas d'utilisation SpecialOrder et NormalOrder sont étendus du cas d'utilisation Order . Par conséquent, ils ont une relation prolongée. Un autre point important est d'identifier la limite du système, qui est montrée dans l'image. L'acteur Client se situe en dehors du système car il est un utilisateur externe du système.

Où utiliser un diagramme de cas d'utilisation?

Comme nous l'avons déjà mentionné, il existe cinq diagrammes en UML pour modéliser la vue dynamique d'un système. Désormais, chaque modèle a un objectif spécifique à utiliser. En fait, ces objectifs spécifiques sont différents angles d'un système en cours d'exécution.

Pour comprendre la dynamique d'un système, nous devons utiliser différents types de diagrammes. Le diagramme de cas d'utilisation est l'un d'entre eux et son objectif spécifique est de rassembler les exigences du système et les acteurs.

Les diagrammes de cas d'utilisation spécifient les événements d'un système et leurs flux. Mais le diagramme de cas d'utilisation ne décrit jamais comment ils sont implémentés. Le diagramme de cas d'utilisation peut être imaginé comme une boîte noire où seules l'entrée, la sortie et la fonction de la boîte noire sont connues.

Ces schémas sont utilisés à un très haut niveau de conception. Cette conception de haut niveau est affinée encore et encore pour obtenir une image complète et pratique du système. Un cas d'utilisation bien structuré décrit également la pré-condition, la post-condition et les exceptions. Ces éléments supplémentaires sont utilisés pour créer des cas de test lors de l'exécution des tests.

Bien que les cas d'utilisation ne soient pas un bon candidat pour l'ingénierie directe et inverse, ils sont néanmoins utilisés d'une manière légèrement différente pour faire de l'ingénierie directe et inverse. La même chose est vraie pour la rétro-ingénierie. Le diagramme de cas d'utilisation est utilisé différemment pour le rendre adapté à l'ingénierie inverse.

Dans l'ingénierie aval, des diagrammes de cas d'utilisation sont utilisés pour créer des cas de test et dans des cas d'utilisation d'ingénierie inverse, ils sont utilisés pour préparer les détails des exigences de l'application existante.

Les diagrammes de cas d'utilisation peuvent être utilisés pour -

  • Analyse des besoins et conception de haut niveau.

  • Modélisez le contexte d'un système.

  • Ingénierie inverse.

  • Ingénierie avancée.

À partir du terme Interaction, il est clair que le diagramme est utilisé pour décrire certains types d'interactions entre les différents éléments du modèle. Cette interaction fait partie du comportement dynamique du système.

Ce comportement interactif est représenté en UML par deux diagrammes appelés Sequence diagram et Collaboration diagram. L'objectif de base des deux schémas est similaire.

Le diagramme de séquence met l'accent sur la séquence temporelle des messages et le diagramme de collaboration met l'accent sur l'organisation structurelle des objets qui envoient et reçoivent des messages.

Objectif des diagrammes d'interaction

Le but des diagrammes d'interaction est de visualiser le comportement interactif du système. Visualiser l'interaction est une tâche difficile. Par conséquent, la solution consiste à utiliser différents types de modèles pour capturer les différents aspects de l'interaction.

Les diagrammes de séquence et de collaboration sont utilisés pour capturer la nature dynamique mais sous un angle différent.

Le but du diagramme d'interaction est -

  • Pour capturer le comportement dynamique d'un système.

  • Pour décrire le flux de messages dans le système.

  • Décrire l'organisation structurelle des objets.

  • Décrire l'interaction entre les objets.

Comment dessiner un diagramme d'interaction?

Comme nous l'avons déjà discuté, le but des diagrammes d'interaction est de capturer l'aspect dynamique d'un système. Donc, pour capturer l'aspect dynamique, nous devons comprendre ce qu'est un aspect dynamique et comment il est visualisé. L'aspect dynamique peut être défini comme l'instantané du système en cours d'exécution à un moment particulier

Nous avons deux types de diagrammes d'interaction en UML. L'un est le diagramme de séquence et l'autre est le diagramme de collaboration. Le diagramme de séquence capture la séquence temporelle du flux de messages d'un objet à un autre et le diagramme de collaboration décrit l'organisation des objets dans un système participant au flux de messages.

Les éléments suivants doivent être clairement identifiés avant de dessiner le diagramme d'interaction

  • Objets participant à l'interaction.

  • Le message circule parmi les objets.

  • L'ordre dans lequel les messages circulent.

  • Organisation d'objets.

Voici deux diagrammes d'interaction modélisant le système de gestion des commandes. Le premier diagramme est un diagramme de séquence et le second est un diagramme de collaboration

Le diagramme de séquence

Le diagramme de séquence comporte quatre objets (Customer, Order, SpecialOrder et NormalOrder).

Le diagramme suivant montre la séquence de messages pour l' objet SpecialOrder et le même peut être utilisé dans le cas de l' objet NormalOrder . Il est important de comprendre la séquence temporelle des flux de messages. Le flux de messages n'est rien d'autre qu'un appel de méthode d'un objet.

Le premier appel est sendOrder () qui est une méthode de l' objet Order . L'appel suivant est confirm () qui est une méthode de l' objet SpecialOrder et le dernier appel est Dispatch () qui est une méthode de l' objet SpecialOrder . Le diagramme suivant décrit principalement les appels de méthode d'un objet à un autre, et il s'agit également du scénario réel lorsque le système est en cours d'exécution.

Le diagramme de collaboration

Le deuxième diagramme d'interaction est le diagramme de collaboration. Il montre l'organisation des objets comme le montre le diagramme suivant. Dans le diagramme de collaboration, la séquence d'appels de méthode est indiquée par une technique de numérotation. Le nombre indique comment les méthodes sont appelées les unes après les autres. Nous avons utilisé le même système de gestion des commandes pour décrire le diagramme de collaboration.

Les appels de méthode sont similaires à ceux d'un diagramme de séquence. Cependant, la différence étant le diagramme de séquence ne décrit pas l'organisation des objets, alors que le diagramme de collaboration montre l'organisation des objets.

Pour choisir entre ces deux schémas, l'accent est mis sur le type d'exigence. Si la séquence temporelle est importante, alors le diagramme de séquence est utilisé. Si une organisation est requise, un diagramme de collaboration est utilisé.

Où utiliser les diagrammes d'interaction?

Nous avons déjà discuté du fait que les diagrammes d'interaction sont utilisés pour décrire la nature dynamique d'un système. Maintenant, nous allons examiner les scénarios pratiques où ces diagrammes sont utilisés. Pour comprendre l'application pratique, nous devons comprendre la nature de base du diagramme de séquence et de collaboration.

L'objectif principal des deux diagrammes est similaire car ils sont utilisés pour capturer le comportement dynamique d'un système. Cependant, l'objectif spécifique est plus important à clarifier et à comprendre.

Les diagrammes de séquence sont utilisés pour capturer l'ordre des messages circulant d'un objet à un autre. Les diagrammes de collaboration sont utilisés pour décrire l'organisation structurelle des objets participant à l'interaction. Un seul diagramme n'est pas suffisant pour décrire l'aspect dynamique d'un système entier, c'est pourquoi un ensemble de diagrammes est utilisé pour le capturer dans son ensemble.

Les diagrammes d'interaction sont utilisés lorsque nous voulons comprendre le flux de messages et l'organisation structurelle. Le flux de messages désigne la séquence du flux de contrôle d'un objet à un autre. L'organisation structurelle désigne l'organisation visuelle des éléments d'un système.

Des diagrammes d'interaction peuvent être utilisés -

  • Modéliser le flux de contrôle par séquence temporelle.

  • Modéliser le flux de contrôle par les organisations structurelles.

  • Pour l'ingénierie avancée.

  • Pour la rétro-ingénierie.

Le nom du diagramme lui-même clarifie le but du diagramme et d'autres détails. Il décrit les différents états d'un composant dans un système. Les états sont spécifiques à un composant / objet d'un système.

Un diagramme d'états décrit une machine d'état. La machine à états peut être définie comme une machine qui définit différents états d'un objet et ces états sont contrôlés par des événements externes ou internes.

Le diagramme d'activité expliqué dans le chapitre suivant est un type spécial de diagramme d'états. Comme le diagramme Statechart définit les états, il est utilisé pour modéliser la durée de vie d'un objet.

Objectif des diagrammes d'états

Le diagramme d'états d'état est l'un des cinq diagrammes UML utilisés pour modéliser la nature dynamique d'un système. Ils définissent différents états d'un objet pendant sa durée de vie et ces états sont modifiés par les événements. Les diagrammes d'états sont utiles pour modéliser les systèmes réactifs. Les systèmes réactifs peuvent être définis comme un système qui répond à des événements externes ou internes.

Le diagramme d'états décrit le flux de contrôle d'un état à un autre état. Les états sont définis comme une condition dans laquelle un objet existe et ils changent lorsqu'un événement est déclenché. Le but le plus important du diagramme d'états est de modéliser la durée de vie d'un objet de sa création à sa terminaison.

Les diagrammes d'états sont également utilisés pour l'ingénierie directe et inverse d'un système. Cependant, l'objectif principal est de modéliser le système réactif.

Voici les principaux objectifs de l'utilisation des diagrammes d'états -

  • Modéliser l'aspect dynamique d'un système.

  • Modéliser la durée de vie d'un système réactif.

  • Décrire les différents états d'un objet pendant sa durée de vie.

  • Définissez une machine à états pour modéliser les états d'un objet.

Comment dessiner un diagramme d'états?

Le diagramme d'états d'état est utilisé pour décrire les états de différents objets dans son cycle de vie. L'accent est mis sur les changements d'état sur certains événements internes ou externes. Ces états des objets sont importants pour les analyser et les implémenter avec précision.

Les diagrammes d'états sont très importants pour décrire les états. Les états peuvent être identifiés comme la condition des objets lorsqu'un événement particulier se produit.

Avant de dessiner un diagramme d'états, nous devons clarifier les points suivants -

  • Identifiez les objets importants à analyser.

  • Identifiez les états.

  • Identifiez les événements.

Voici un exemple de diagramme d'états dans lequel l'état de l'objet Order est analysé

Le premier état est un état inactif à partir duquel le processus démarre. Les états suivants sont arrivés pour des événements tels que l'envoi de la demande, la confirmation de la demande et la commande d'expédition. Ces événements sont responsables des changements d'état de l'objet de commande.

Pendant le cycle de vie d'un objet (ici objet d'ordre), il passe par les états suivants et il peut y avoir des sorties anormales. Cette sortie anormale peut se produire en raison d'un problème dans le système. Lorsque le cycle de vie complet est terminé, il est considéré comme une transaction complète, comme illustré dans la figure suivante. L'état initial et final d'un objet est également illustré dans la figure suivante.

Où utiliser les diagrammes d'états?

À partir de la discussion ci-dessus, nous pouvons définir les applications pratiques d'un diagramme d'états. Les diagrammes d'états sont utilisés pour modéliser l'aspect dynamique d'un système comme les quatre autres diagrammes abordés dans ce didacticiel. Cependant, il présente certaines caractéristiques distinctives pour modéliser la nature dynamique.

Le diagramme d'états d'états définit les états d'un composant et ces changements d'état sont de nature dynamique. Son objectif spécifique est de définir les changements d'état déclenchés par les événements. Les événements sont des facteurs internes ou externes qui influencent le système.

Les diagrammes d'états sont utilisés pour modéliser les états ainsi que les événements opérant sur le système. Lors de la mise en œuvre d'un système, il est très important de clarifier les différents états d'un objet pendant sa durée de vie et des diagrammes d'états sont utilisés à cette fin. Lorsque ces états et événements sont identifiés, ils sont utilisés pour le modéliser et ces modèles sont utilisés lors de la mise en œuvre du système.

Si nous examinons la mise en œuvre pratique du diagramme Statechart, il est principalement utilisé pour analyser les états d'objet influencés par les événements. Cette analyse est utile pour comprendre le comportement du système lors de son exécution.

L'utilisation principale peut être décrite comme -

  • Pour modéliser les états d'objet d'un système.

  • Modéliser le système réactif. Le système réactif se compose d'objets réactifs.

  • Identifier les événements responsables des changements d'état.

  • Ingénierie directe et inverse.

Le diagramme d'activité est un autre diagramme important dans UML pour décrire les aspects dynamiques du système.

Le diagramme d'activité est essentiellement un organigramme pour représenter le flux d'une activité à une autre activité. L'activité peut être décrite comme une opération du système.

Le flux de contrôle est tiré d'une opération à une autre. Ce flux peut être séquentiel, ramifié ou simultané. Les diagrammes d'activité traitent de tous les types de contrôle de flux en utilisant différents éléments tels que fork, join, etc.

Objectif des diagrammes d'activités

Les objectifs de base des diagrammes d'activités sont similaires à ceux des quatre autres diagrammes. Il capture le comportement dynamique du système. Quatre autres diagrammes sont utilisés pour montrer le flux de messages d'un objet à un autre, mais le diagramme d'activité est utilisé pour montrer le flux de messages d'une activité à une autre.

L'activité est une opération particulière du système. Les diagrammes d'activités ne sont pas seulement utilisés pour visualiser la nature dynamique d'un système, mais ils sont également utilisés pour construire le système exécutable en utilisant des techniques d'ingénierie directe et inverse. La seule chose qui manque dans le diagramme d'activité est la partie message.

Il n'affiche aucun flux de messages d'une activité à une autre. Le diagramme d'activité est parfois considéré comme l'organigramme. Bien que les diagrammes ressemblent à un organigramme, ils ne le sont pas. Il montre différents flux tels que parallèle, ramifié, simultané et unique.

Le but d'un diagramme d'activités peut être décrit comme -

  • Dessinez le flux d'activité d'un système.

  • Décrivez la séquence d'une activité à une autre.

  • Décrivez le flux parallèle, ramifié et concurrent du système.

Comment dessiner un diagramme d'activité?

Les diagrammes d'activités sont principalement utilisés comme organigramme qui se compose des activités effectuées par le système. Les diagrammes d'activité ne sont pas exactement des organigrammes car ils ont des capacités supplémentaires. Ces capacités supplémentaires incluent le branchement, l'écoulement parallèle, le couloir de bain, etc.

Avant de dessiner un diagramme d'activités, nous devons avoir une compréhension claire des éléments utilisés dans le diagramme d'activités. L'élément principal d'un diagramme d'activités est l'activité elle-même. Une activité est une fonction exécutée par le système. Après avoir identifié les activités, nous devons comprendre comment elles sont associées aux contraintes et aux conditions.

Avant de dessiner un diagramme d'activités, nous devons identifier les éléments suivants -

  • Activities

  • Association

  • Conditions

  • Constraints

Une fois les paramètres mentionnés ci-dessus identifiés, nous devons faire une disposition mentale de l'ensemble du flux. Cette disposition mentale est ensuite transformée en diagramme d'activités.

Voici un exemple de diagramme d'activité pour le système de gestion des commandes. Dans le diagramme, quatre activités associées à des conditions sont identifiées. Un point important doit être clairement compris qu'un diagramme d'activité ne peut pas être exactement mis en correspondance avec le code. Le diagramme d'activités est fait pour comprendre le flux d'activités et est principalement utilisé par les utilisateurs métier

Le diagramme suivant est dessiné avec les quatre activités principales -

  • Envoyer la commande par le client

  • Réception de la commande

  • Confirmer la commande

  • Expédier la commande

Après réception de la demande de commande, des vérifications de l'état sont effectuées pour vérifier s'il s'agit d'une commande normale ou spéciale. Une fois le type de commande identifié, une activité d'expédition est effectuée et est marquée comme la fin du processus.

Où utiliser les diagrammes d'activités?

L'utilisation de base du diagramme d'activité est similaire aux quatre autres diagrammes UML. L'utilisation spécifique est de modéliser le flux de contrôle d'une activité à une autre. Ce flux de contrôle n'inclut pas les messages.

Le diagramme d'activités convient pour modéliser le flux d'activités du système. Une application peut avoir plusieurs systèmes. Le diagramme d'activité capture également ces systèmes et décrit le flux d'un système à un autre. Cette utilisation spécifique n'est pas disponible dans d'autres schémas. Ces systèmes peuvent être des bases de données, des files d'attente externes ou tout autre système.

Nous allons maintenant examiner les applications pratiques du diagramme d'activités. D'après la discussion ci-dessus, il est clair qu'un diagramme d'activités est établi à un niveau très élevé. Cela donne donc une vue de haut niveau d'un système. Cette vue de haut niveau est principalement destinée aux utilisateurs professionnels ou à toute autre personne qui n'est pas une personne technique.

Ce diagramme est utilisé pour modéliser les activités qui ne sont que des exigences métier. Le diagramme a plus d'impact sur la compréhension de l'entreprise que sur les détails de mise en œuvre.

Le diagramme d'activité peut être utilisé pour -

  • Modélisation du flux de travail à l'aide d'activités.

  • Modélisation des besoins métiers.

  • Compréhension de haut niveau des fonctionnalités du système.

  • Enquêter sur les besoins commerciaux à un stade ultérieur.