UML (Unified Modeling Language) est un standard de langage de modélisation visuelle universel utilisé pour décrire, visualiser, construire et documenter les artefacts du système logiciel.
En ce qui concerne le langage, de nombreux amis commencent à avoir peur. Des langages tels que SQL, Java, C# et PHP peuvent flotter dans votre esprit et peuvent effrayer de nombreuses personnes .
Divers langages de programmation
Mais UML n’est pas un langage de programmation, mais un langage de modélisation visuelle. La raison pour laquelle on l'appelle langage est que UML fournit un vocabulaire et des règles de communication. Les utilisateurs peuvent communiquer avec le même logiciel sans barrières dans le cadre de ce vocabulaire et de ces règles, de sorte que différents utilisateurs aient la même compréhension de la même chose.
Depuis la fin des années 1960, avec la vulgarisation continue de la technologie informatique, la demande de logiciels augmente de jour en jour, l'échelle des logiciels s'est également élargie et la complexité des logiciels a également augmenté. En raison du manque de conseils théoriques scientifiques, il est difficile de garantir la progression du développement de logiciels. Les coûts de développement de logiciels augmentent constamment. Les besoins changeants des utilisateurs aggravent encore la situation des logiciels qui ne peuvent pas garantir la qualité. ce qui rend la maintenance des logiciels une tâche fastidieuse. Les gens parlent clairement de crise logicielle.
ce qu'il faut faire? Ensuite, le travail de développement logiciel doit être effectué sous forme de projet. Par conséquent, le concept de génie logiciel a également émergé. Le génie logiciel vise à étudier les lois objectives de la production de logiciels et à établir des concepts, principes, méthodes, technologies et outils pertinents pour la production de logiciels afin de guider les activités de production de logiciels. Bien entendu, les résultats ont été satisfaisants.
Avec l'approfondissement continu des recherches sur le génie logiciel, la programmation orientée objet est entrée dans le champ de vision des gens. Entre les années 1980 et le début des années 1990, de nombreuses méthodes d'analyse et de conception orientées objet sont nées, et un grand nombre d'ouvrages introduisant les méthodes orientées objet sont également parus. Cela ressemble un peu à une centaine d’écoles de pensée qui s’affrontent. Chaque auteur dirige un groupe de praticiens, et les méthodes présentent de nombreuses similitudes mais aussi des différences subtiles.
Cela crée également de la confusion chez les praticiens du même domaine. Lorsqu'ils parlent de la même chose, ils peuvent proposer différentes méthodes de représentation orientées objet, ce qui entrave sérieusement leur compréhension et leur communication de la même chose.
À cette époque, quelqu’un a suggéré que nous unifions et utilisions les mêmes normes. Personne ne semblait entendre son appel et l'ignorait. Il existe une organisation appelée OMG (Object Management Group) qui a également tenté de normaliser l'orientation objet, mais n'a reçu qu'une seule lettre publique de protestation de la part de tous les méthodologistes.
Lorsque Martin Fowler parle de cette situation, il raconte une blague dans son livre "UML Essentials: A Concise Guide to the Standard Object Modeling Language" :
A : Quelle est la différence entre un méthodologiste et un terroriste ?
B : Les terroristes peuvent négocier.
Il existe un énorme écart entre les méthodes de représentation orientées objet
Lors de la réunion annuelle OOPSLA (Object-Oriented Programming Systems, Languages and Applications) de 1995, Grady Booch et Jim Rumbaugh ont décrit publiquement pour la première fois leur approche fusionnée, le Unified Method Document 0.8 (Unitied Method).
Après une série de concours entre diverses parties, en janvier 1997, toutes les organisations ont soumis une proposition de norme de méthode, a collaboré avec d'autres organisations et a publié la version 1.0 du document UML. C'était également la première fois qu'elle était appelée modélisation unifiée. langue.
Après un processus de compétition entre toutes les parties , OMG a adopté la version 1.1 comme norme officielle d'OMG. Après une série de modifications, UML1.4 et UML1.5 sont devenus relativement matures. Par exemple, Rational Rose 2003 a été développé sur la base de ces normes.
Lorsque beaucoup de gens parlent d'UML, ils attribuent principalement le mérite des créateurs à Grady Booch, Ivar Jacobson et Jim Rumbaugh, les appelant les « Trois Amigos ».
Bien sûr, certaines personnes ont exprimé leur opposition et pensaient avoir apporté certaines contributions au début, mais plus tard, les membres du comité OMG ont apporté beaucoup de contributions, et parmi les trois, Jim Rumbaugh était le seul à avoir apporté une contribution. à un stade ultérieur.
Méthodes et aspects de représentation
En termes de méthodes et de représentations apparues dans le passé, UML intègre de nombreux concepts communément acceptés dans les méthodes orientées objet. Pour chaque concept, UML fournit des définitions, des représentations et une terminologie associée claires. UML peut être utilisé pour décrire des modèles établis par diverses méthodes existantes et les décrire mieux que les méthodes originales.
cycle logiciel
En termes de cycle de vie du développement logiciel, UML a des exigences de développement transparentes. Différentes étapes du processus de développement peuvent utiliser le même ensemble de concepts et de représentations, et au sein d'un même modèle, elles peuvent être mélangées sans avoir à convertir les concepts et les représentations. Cette transparence est essentielle au développement logiciel itératif et incrémentiel.
En termes de domaines d'application
En termes de domaines d'application, UML convient à la modélisation dans divers domaines, notamment les données ou l'informatique volumineuses, complexes, en temps réel, distribuées et centralisées, les systèmes embarqués, etc.
Langages de programmation et plateformes de développement
En termes de langages de programmation d'implémentation et de plates-formes de développement, UML peut être appliqué à des systèmes exécutant une variété de langages de mise en œuvre de programmation et de plates-formes de développement différents.
processus de développement
En termes de processus de développement, UML est un langage de modélisation et non un outil permettant de décrire les détails du processus de développement. Tout comme les langages de programmation à usage général, ils permettent de nombreux styles de programmation.
aspects conceptuels internes
En termes de concepts internes, UML accorde une attention particulière à révéler et à exprimer les connexions internes entre les différents concepts. Le processus consistant à essayer d'appréhender les concepts de modélisation de multiples manières qui s'appliquent à des situations connues et inconnues améliorera votre compréhension des concepts et leur applicabilité. Ce n’est pas l’intention initiale d’unifier diverses normes, mais c’est l’un des résultats les plus importants de l’unification de diverses normes.
La composition d’UML peut être illustrée à l’aide du diagramme suivant :
Blocs de construction de base UML et classification graphique
À l'heure actuelle, la dernière version d'UML est passée à la version UML 2.5 et le nombre de diagrammes est passé de 9 à 13. Certaines personnes pensent que la complexité d'UML lui-même peut dépasser la modélisation logicielle elle-même.
Ce qui précède est l'introduction de base d'UML. En tant que langage de modélisation indispensable en génie logiciel, l'histoire du développement d'UML témoigne non seulement des progrès des concepts de conception de logiciels, mais met également en évidence son rôle dans la promotion de la communication au sein de l'équipe, l'optimisation de la conception des systèmes et l'accélération du processus de développement. .rôle clé. Grâce à l'introduction de base de cet article, je pense que vous serez non seulement en mesure de comprendre en profondeur le contexte historique d'UML, mais également de maîtriser ses applications étendues dans l'analyse des exigences, la conception de systèmes et la documentation.