Ave Coder!
Vous avez une bonne idée de produit, mais vous ne voulez pas rester coincé dans le code et perdre l’image entière à cause de petits détails? Êtes-vous sur le point de vous asseoir pour grogner un serveur d'entreprise et vous avez besoin de remplir quelque chose de cool et informatique?
Cette série d'articles sera consacrée à une connaissance utile, mais parfois insaisissable, de la jeune croissance - diagrammes UML. Et je vais commencer par un examen des diagrammes existants, parlons un peu de l'histoire et pourquoi il devrait y avoir autant de diagrammes.
UML est l'abréviation de Unified Modeling Language, et comme nous le savons, c'est un langage de modélisation normalisé composé d'un ensemble intégré de diagrammes conçus pour aider les développeurs de systèmes et de logiciels à définir, visualiser, concevoir et documenter les artefacts du système logiciel, et , par exemple, pour la modélisation d'entreprise.
UML est un ensemble de meilleures pratiques d'ingénierie qui se sont avérées efficaces dans la modélisation de systèmes volumineux et complexes et constitue une partie très importante du développement de logiciels orientés objet.
UML utilise principalement la notation graphique pour exprimer la conception de projets logiciels. L'utilisation de l'UML aide les équipes de conception à communiquer, à explorer des projets potentiels et à valider la conception architecturale des logiciels.
L'origine de l'UML
Le but de l'UML est de fournir une notation standard qui peut être utilisée par toutes les méthodes orientées objet, et de sélectionner et d'intégrer les meilleurs éléments des notations précédentes. L'UML a été conçu pour une grande variété d'applications. Par conséquent, il fournit des conceptions pour un large éventail de systèmes et d'activités (par exemple, les systèmes distribués, l'analyse, la conception et le déploiement de systèmes).
L'UML n'est pas sortie de zéro, elle a été précédée de plusieurs événements, personnalités et méthodologies significatifs. Par exemple:
- OMT [James Rumbaugh 1991], .
- Booch [Grady Booch 1994] — . - . , , , , .
- OOSE (- [Ivar Jacobson 1992]) — , — , , .
En 1994, Jim Rambeau, à ne pas confondre avec John Rambo, bien que Jim était cool aussi parce qu'il était, pendant une seconde, le créateur de la technique de modélisation d'objets susmentionnée, a stupéfait le monde du logiciel quand il a quitté General Electric et rejoint Grady Booch chez Rational Corp. Le but du partenariat était de combiner leurs idées en une seule méthode unifiée (le nom de travail de la méthode était en fait - «La méthode unifiée»).
En 1995, le créateur d'OOSE, Ivar Jacobson, avait également rejoint Rational, et ses idées (en particulier le concept de "cas d'utilisation") ont été incorporées dans une nouvelle méthode unifiée, désormais appelée langage de modélisation unifié.
Contrairement au célèbre Gang of Four, l'équipe Rumbo, Buch et Jacobson est connue sous le nom de Three Amigos.
UML a également été influencé par d'autres notations orientées objet:
- Mellor et Schlaer [1998]
- Coad et Yourdon [1995]
- Wirfs-Brock [1990]
- Martin et Odell [1992]
UML inclut également de nouveaux concepts, qui à l'époque n'étaient pas dans d'autres méthodes de base, telles que les mécanismes d'extension et les contraintes de langage.
Pourquoi UML?
Alors que la valeur stratégique des logiciels augmentait pour de nombreuses entreprises, l'industrie a recherché des méthodes pour automatiser la production de logiciels, ainsi que pour améliorer la qualité et réduire les coûts et les délais de mise sur le marché.
Ces méthodes comprennent la technologie des composants, la programmation visuelle, les modèles et les structures.
Les entreprises recherchent également des méthodes pour gérer la complexité des systèmes à mesure qu'ils évoluent.
En particulier, ils reconnaissent la nécessité de résoudre les problèmes architecturaux récurrents tels que la distribution physique, la concurrence, la réplication, la sécurité, l'équilibrage de charge et la tolérance aux pannes.
De plus, le développement web, tout en simplifiant les choses, aggrave généralement ces problèmes d'architecture.
Le langage de modélisation unifié (UML) a été développé pour répondre à ces besoins.
Les principaux objectifs de la conception UML sont:
- Fournissez aux utilisateurs un langage de modélisation visuelle expressif prêt à l'emploi afin qu'ils puissent développer et partager des modèles significatifs.
- Fournir des mécanismes d'extensibilité et de spécialisation pour étendre les concepts de base.
- Être indépendant des langages de programmation et des processus de développement spécifiques.
- Fournir un cadre formel pour comprendre le langage de modélisation.
- Encourager la croissance du marché des outils orientés objet.
- Prise en charge de concepts de conception de haut niveau tels que la collaboration, les structures, les modèles et les composants.
- Intégrez les meilleures pratiques.
Les diagrammes UML sont divisés en deux types - ce sont les diagrammes structurels et les diagrammes de comportement.
Les diagrammes structurels montrent la structure statique du système et de ses parties à différents niveaux d'abstraction et de mise en œuvre, ainsi que leurs relations. Les éléments d'un diagramme de structure représentent des concepts significatifs du système et peuvent inclure des concepts abstraits, réels et d'implémentation. Il existe sept types de diagrammes de structure:
- Diagramme de structure composé
- Tableau de déploiement
- Diagramme de paquet
- Diagramme de profil
- Diagramme de classe
- Diagramme d'objets
- Tableau des composants
Les diagrammes de comportement montrent le comportement dynamique des objets dans un système, qui peut être décrit comme une série de changements dans le système au fil du temps. Les diagrammes de comportement comprennent:
- Diagramme d'activité
- Diagramme de cas d'utilisation
- Diagramme d'état
- Diagramme de séquençage
- Diagramme de communication
- Tableau de présentation des interactions
- Diagramme temporel
Maintenant, quelques mots sur chacun d'eux
Diagramme de classe
Le diagramme de classes est une technique de modélisation centrale qui est utilisée dans presque toutes les méthodes orientées objet. Ce diagramme décrit les types d'objets dans le système et les différents types de relations statiques qui existent entre eux.
Les trois types de relations les plus importants dans les diagrammes de classes (il y en a en fait plus) sont:
Association, qui représente la relation entre les instances des types, par exemple, une personne travaille pour une entreprise, une entreprise a plusieurs bureaux.
Héritage directement lié à l'héritage dans une conception orientée objet.
Agrégation, qui est une forme de composition d'objet dans une conception orientée objet.
Tableau des composants
Dans un langage de modélisation unifié, un diagramme de composants montre comment les composants se réunissent pour former des composants ou des systèmes logiciels plus gros.
Il illustre l'architecture des composants logiciels et les dépendances entre eux.
Ces composants logiciels incluent des composants d'exécution, des composants exécutables et des composants de code source.
Tableau de déploiement
Un diagramme de déploiement permet de simuler l'aspect physique d'un système logiciel orienté objet. Il s'agit d'un schéma de principe qui montre l'architecture du système en tant que déploiement (distribution) d'artefacts logiciels.
Les artefacts représentent des éléments spécifiques du monde physique qui sont le résultat du processus de développement.
Le diagramme modélise la configuration d'exécution dans une vue statique et visualise la distribution des artefacts dans l'application.
Dans la plupart des cas, cela inclut la modélisation des configurations matérielles ainsi que les composants logiciels sur lesquels elles se trouvent.
Diagramme d'objets
Un diagramme d'objets statique est une instance d'un diagramme de classes; il montre un instantané de l'état détaillé du système à un moment donné. La différence est qu'un diagramme de classes est un modèle abstrait de classes et de leurs relations.
Cependant, un diagramme d'objets est une instance à un moment spécifique, qui est de nature spécifique. L'utilisation de diagrammes d'objets est plutôt limitée, à savoir pour montrer des exemples de structures de données.
Diagramme de paquet
Un diagramme de package est un diagramme structurel UML qui montre les packages et les dépendances entre eux.
Il vous permet d'afficher différents types de systèmes, par exemple, il est facile de simuler une application à plusieurs niveaux.
Diagramme de structure composé
Le diagramme de structure composite est similaire au diagramme de classes et est une sorte de diagramme de composants utilisé principalement dans la modélisation du système au niveau micro, mais il représente des pièces individuelles au lieu de classes entières. Il s'agit d'un type de diagramme de structure statique qui montre la structure interne d'une classe et les interactions que cette structure rend possibles.
Ce diagramme peut inclure des pièces internes, des ports à travers lesquels des pièces interagissent les unes avec les autres ou à travers quelles instances de classe interagissent avec des pièces et le monde extérieur, et des connecteurs entre des pièces ou des ports. Une structure composite est une collection d'éléments interdépendants qui interagissent au moment de l'exécution pour atteindre un objectif. Chaque élément a un rôle dans la collaboration.
Diagramme de profil
Le diagramme de profil nous permet de créer des stéréotypes spécifiques au domaine et à la plate-forme et de définir des relations entre eux. Nous pouvons créer des stéréotypes en dessinant des formes de stéréotypes et en les associant à la composition ou à la généralisation via une interface orientée ressources. Nous pouvons également définir et visualiser la signification des stéréotypes.
Diagramme de cas d'utilisation
Un diagramme de cas d'utilisation décrit les exigences fonctionnelles d'un système en termes de cas d'utilisation. Il s'agit essentiellement d'un modèle de la fonctionnalité prévue du système (cas d'utilisation) et de son environnement (acteurs).
Les cas d'utilisation nous permettent de lier ce dont nous avons besoin du système avec la façon dont le système répond à ces besoins.
Diagramme d'activité
Les diagrammes d'activités sont des représentations graphiques de flux de travail étape par étape et étape par étape avec prise en charge de la sélection, de l'itération et de la concurrence.
Ils décrivent le flux de contrôle du système cible, comme l'exploration de règles et opérations commerciales complexes, et la description de cas d'utilisation et de processus métier.
Dans UML, les diagrammes d'activités sont conçus pour simuler à la fois des processus informatiques et organisationnels.
Diagramme d'état
Un diagramme d'états est un type de diagramme utilisé en UML pour décrire le comportement des systèmes, basé sur le concept de diagrammes d'états de David Harel. Les diagrammes d'états montrent les états et transitions activés, ainsi que les événements qui affectent ces transitions. Il vous aide à visualiser l'ensemble du cycle de vie des objets et vous aide ainsi à mieux comprendre les systèmes basés sur des états.
Diagramme de séquençage
Un diagramme de séquence modélise l'interaction des objets en fonction d'une séquence temporelle. Il montre comment certains objets interagissent avec d'autres dans un cas d'utilisation spécifique.
Diagramme de communication
Comme un diagramme de séquence, un diagramme de communication est également utilisé pour modéliser le comportement dynamique d'un cas d'utilisation. Comparé au diagramme de séquence, le diagramme de communication est plus axé sur la représentation de l'interaction des objets plutôt que sur la séquence temporelle. En fait, un diagramme de communication et un diagramme de séquence sont sémantiquement équivalents et peuvent se fondre l'un dans l'autre.
Tableau de présentation des interactions
Le diagramme de vue d'ensemble des interactions se concentre sur une vue d'ensemble du flux de gestion des interactions. Il s'agit d'une variante du diagramme d'activité où les nœuds sont des interactions ou des événements d'interaction. Le diagramme de vue d'ensemble des interactions décrit les interactions dans lesquelles les messages et les lignes de vie sont masqués. Nous pouvons lier les diagrammes «réels» et atteindre un degré élevé de navigation entre les diagrammes à l'intérieur du diagramme de synthèse des interactions.
Diagramme temporel
Le chronogramme montre le comportement du ou des objets dans une période de temps donnée. En fait, il s'agit d'une forme spéciale du diagramme de séquence et les différences entre eux sont que les axes sont interchangés de sorte que le temps augmente de gauche à droite et que les lignes de vie sont affichées dans des compartiments séparés situés verticalement.
Pourquoi y a-t-il tant de diagrammes dans l'UML?
La raison en est que vous pouvez regarder le système de différents points de vue, car de nombreux acteurs seront impliqués dans le développement logiciel, tels que: analystes, concepteurs, codeurs, testeurs, contrôle qualité, clients, auteurs techniques.
Toutes ces personnes s'intéressent à différents aspects du système, et chacun nécessite un niveau de détail différent.
Par exemple, le codeur doit comprendre la conception du système et être capable de convertir la conception en code de bas niveau.
Au contraire, un rédacteur technique s'intéresse au comportement du système dans son ensemble et doit comprendre le fonctionnement du produit.
UML essaie de fournir le langage d'une manière si expressive que toutes les parties intéressées peuvent bénéficier d'au moins un diagramme UML.
Pour ceux qui sont trop paresseux pour lire:
Ave!