Introduction au langage de modélisation unifié (LMU)

Les applications d’entreprise de grande taille – celles qui exécutent les applications métier essentielles et permettent à une entreprise de continuer à fonctionner – doivent constituer plus qu’un groupe de modules de code. Ils doivent être structurés de manière à permettre l’évolutivité, la sécurité et une exécution robuste dans des conditions difficiles, et leur structure – souvent désignée par leur architecture – doit être définie suffisamment clairement pour que les programmeurs de maintenance puissent (rapidement!) Trouver et corriger un bogue apparaît bien après que les auteurs originaux se soient tournés vers d’autres projets. Autrement dit, ces programmes doivent être conçus pour fonctionner parfaitement dans de nombreux domaines, et la fonctionnalité métier n’est pas la seule (bien qu’il s’agisse du noyau essentiel). Bien entendu, une architecture bien conçue profite à tous les programmes, et pas seulement aux plus grands, comme nous l’avons indiqué ici. Nous avons d’abord mentionné les applications volumineuses, car la structure permet de gérer la complexité. Par conséquent, les avantages de la structure (et de la modélisation et de la conception, comme nous le montrerons) sont complexes à mesure que la taille de l’application augmente. Un autre avantage de la structure est qu’elle permet la réutilisation du code: le temps de conception est le moment le plus facile pour structurer une application en tant que collection de modules ou de composants autonomes. Finalement, les entreprises créent une bibliothèque de modèles de composants, chacun représentant une implémentation stockée dans une bibliothèque de modules de code. Lorsqu’une autre application a besoin des mêmes fonctionnalités, le concepteur peut importer rapidement son module à partir de la bibliothèque. Au moment du codage, le développeur peut tout aussi rapidement importer le module de code dans l’application.

La modélisation est la conception d’applications logicielles avant le codage. La modélisation est un élément essentiel des grands projets logiciels et est également utile pour les projets de taille moyenne et même petite. Un modèle joue un rôle analogue dans le développement logiciel que les plans et autres plans (cartes de site, élévations, modèles physiques) jouent dans la construction d’un gratte-ciel. À l’aide d’un modèle, les personnes responsables du succès d’un projet de développement logiciel peuvent s’assurer que la fonctionnalité métier est complète et correcte, que les besoins des utilisateurs finaux sont satisfaits et que la conception du programme prend en charge les exigences d’évolutivité, de robustesse, de sécurité, d’extensibilité et autres, avant la mise en œuvre. dans le code rend les changements difficiles et coûteux à faire. Les enquêtes montrent que les grands projets logiciels ont une très grande probabilité d’échec – en fait, il est plus probable qu’une grande application logicielle ne satisfera pas à toutes ses exigences dans les délais et dans les limites du budget qu’elle sera couronnée de succès. Si vous exécutez l’un de ces projets, vous devez faire tout ce qui est en votre pouvoir pour augmenter les chances de succès. La modélisation est le seul moyen de visualiser votre conception et de la comparer aux exigences avant que votre équipe ne commence à coder.

RELEVER LE NIVEAU D’ABSTRACTION

Les modèles nous aident en nous permettant de travailler à un niveau d’abstraction supérieur. Un modèle peut le faire en masquant ou en masquant des détails, en donnant une vue d’ensemble ou en mettant l’accent sur différents aspects du prototype. Dans UML 2.0, vous pouvez effectuer un zoom arrière sur une vue détaillée d’une application vers l’environnement dans lequel elle s’exécute, en visualisant les connexions à d’autres applications ou, encore plus loin, vers d’autres sites. Vous pouvez également vous concentrer sur différents aspects de l’application, tels que le processus métier qu’elle automatise ou la vue des règles métier. La nouvelle capacité à imbriquer des éléments de modèle, ajoutée à UML 2.0, supporte directement ce concept.

Le langage UML® (Unified Modeling Language ™) d’OMG vous aide à spécifier, visualiser et documenter des modèles de systèmes logiciels, y compris leur structure et leur conception, de manière à répondre à toutes ces exigences. (Vous pouvez également utiliser UML pour la modélisation métier et la modélisation d’autres systèmes non logiciels.) À l’aide de l’un des nombreux outils UML du marché, vous pouvez analyser les besoins de votre future application et concevoir une solution qui réponde à ces besoins. représentant les résultats à l’aide des treize types de diagrammes standard d’UML 2.0.

Vous pouvez modéliser à peu près n’importe quel type d’application, fonctionnant sur n’importe quel type et combinaison de matériel, système d’exploitation, langage de programmation et réseau, en UML. Sa flexibilité vous permet de modéliser des applications distribuées qui utilisent à peu près n’importe quel middleware sur le marché. Construit sur des concepts OO fondamentaux, y compris classe et opération, il convient parfaitement aux langages et environnements orientés objet tels que C ++, Java et le C # récent, mais vous pouvez également l’utiliser pour modéliser des applications non-OO, par exemple, Fortran, VB ou COBOL. Les profils UML (c’est-à-dire des sous-ensembles d’UML adaptés à des objectifs spécifiques) vous aident à modéliser les systèmes transactionnels, en temps réel et à tolérance de pannes de manière naturelle.

VOUS POUVEZ FAIRE D’AUTRES OBJETS UTILES AVEC UML TOO

Par exemple, certains outils analysent le code source existant (ou, selon certains, le code objet!) Et le désossent dans un ensemble de diagrammes UML. Autre exemple: certains outils du marché exécutent les modèles UML, généralement de l’une des deux manières suivantes: Certains outils exécutent votre modèle de manière interprétative de manière à vous permettre de confirmer qu’il fait vraiment ce que vous voulez, mais sans l’évolutivité et la rapidité besoin dans votre application déployée. D’autres outils (généralement conçus pour fonctionner uniquement dans un domaine d’application restreint, tel que les télécommunications ou la finance) génèrent du code de langage de programme à partir d’UML, produisant la plupart des applications déployables sans bugs qui s’exécutent rapidement si le générateur de code incorpore des modèles évolutifs conformes aux meilleures pratiques. , par exemple, opérations de base de données transactionnelles ou autres tâches courantes du programme. (Les membres d’OMG travaillent actuellement sur une spécification pour l’exécutable UML.) Notre dernière entrée dans cette catégorie: Un certain nombre d’outils sur le marché génèrent des suites de test et de vérification à partir de modèles UML.

ARCHITECTURE® CONÇUE PAR LES MODÈLES UML ET OMG (MDA®)

Il y a quelques années (en fait, étonnamment peu!), Le plus gros problème rencontré par un développeur lors du démarrage d’un projet de programmation distribuée était de trouver un middleware doté des fonctionnalités dont il avait besoin, fonctionnant sur le matériel et les systèmes d’exploitation exécutés dans son magasin. Aujourd’hui, confronté à une gamme de plates-formes middleware extrêmement riche et embarrassante, le développeur rencontre trois problèmes de middleware différents: premièrement, en sélectionner un; deuxièmement, le faire fonctionner avec les autres plates-formes déjà déployées non seulement dans son propre magasin, mais également dans celui de ses clients et de ses fournisseurs; et troisièmement, interagir avec (ou, pire encore, migrer vers) une nouvelle “Meilleure chose à faire” lorsqu’une nouvelle plate-forme se présente et attire l’imagination des analystes et, nécessairement, des DSI partout.

Grâce à sa riche palette et à son indépendance en termes de middleware, UML constitue l’un des fondements de Model Driven Architecture® (MDA®) d’OMG. En fait, un modèle UML peut être indépendant de la plate-forme ou spécifique à une plate-forme, et le processus de développement de la MDA utilise les deux formes suivantes: Chaque norme ou application MDA est basée, de manière normative, sur un modèle indépendant de la plate-forme (PIM). ), qui représente très précisément la fonctionnalité et le comportement de l’entreprise, mais n’inclut pas les aspects techniques. Depuis le PIM, les outils de développement compatibles MDA suivent les mappages standardisés par OMG pour produire un ou plusieurs modèles spécifiques à la plate-forme, également en UML, un pour chaque plate-forme cible choisie par le développeur. (Cette étape de conversion est hautement automatisée, mais pas magique: avant que l’outil ne produise un PSM, le développeur doit annoter le PIM de base afin de produire un PIM plus spécifique, mais indépendant de la plate-forme, qui inclut des détails sur la sémantique souhaitée et guide les choix que l’outil En raison des similitudes existant entre les plates-formes de middleware d’un genre donné – à base de composants ou de messagerie, par exemple – ce guide peut être inclus dans un PIM sans le rendre spécifique à une plate-forme. affinez les PSM produits dans une certaine mesure, plus au début de MDA mais de moins en moins à mesure que les outils et les algorithmes progressent.)

Le PSM contient les mêmes informations qu’une implémentation, mais sous la forme d’un modèle UML au lieu d’un code en cours d’exécution. À l’étape suivante, l’outil génère le code en cours d’exécution à partir du PSM, ainsi que les autres fichiers nécessaires (notamment les fichiers de définition d’interface, les fichiers de configuration, les fichiers Make et d’autres types de fichiers). Après avoir donné au développeur la possibilité d’ajuster à la main le code généré, l’outil exécute les makefiles pour produire une application finale déployable.

Les applications MDA sont composables: si vous importez des PIM pour des modules, des services ou d’autres applications MDA dans votre outil de développement, vous pouvez lui demander de générer des appels à l’aide des interfaces et des protocoles requis, même s’ils sont multi-plateformes. Et les applications MDA sont à l’épreuve du temps: lorsqu’un nouveau “Next Best Thing” est disponible sur le marché, les membres d’OMG génèrent et standardisent un mappage, et votre fournisseur met à niveau son outil compatible MDA pour l’inclure. Tirant parti de ces développements, vous serez en mesure de générer des invocations multiplates-formes vers la nouvelle plate-forme et même de lui transférer automatiquement vos applications MDA existantes, à l’aide de vos PIM existants.

MODELES VS. METHODOLOGIES

Le processus de collecte et d’analyse des exigences d’une application, et de leur intégration dans une conception de programme, est complexe et l’industrie prend actuellement en charge de nombreuses méthodologies qui définissent des procédures formelles spécifiant la marche à suivre. Une des caractéristiques d’UML – en fait, celui qui permet au secteur de bénéficier d’un large soutien dont bénéficie le langage – est qu’il est indépendant de la méthodologie. Quelle que soit la méthodologie que vous utilisez pour effectuer votre analyse et votre conception, vous pouvez utiliser UML pour exprimer les résultats. Et, à l’aide de XMI® (XML ™ Metadata Interchange, une autre norme OMG), vous pouvez transférer votre modèle UML d’un outil à un référentiel ou à un autre outil afin de l’affiner ou de passer à l’étape suivante du processus de développement que vous avez choisi. Ce sont les avantages de la normalisation!

QUE POUVEZ-VOUS MODELER AVEC UML?

UML 2.0 définit treize types de diagrammes, répartis en trois catégories: six types de diagrammes représentent la structure d’application statique; trois représentent des types généraux de comportement; et quatre représentent différents aspects des interactions:

  • Les diagrammes de structure incluent le diagramme de classes, le diagramme d’objets, le diagramme de composants, le diagramme de structures composites, le diagramme de packages et le diagramme de déploiement.
  • Les diagrammes de comportement incluent le diagramme de cas d’utilisation (utilisé par certaines méthodologies lors de la collecte des exigences); Diagramme d’activité et diagramme de la machine d’état.
  • Les diagrammes d’interaction, tous dérivés du diagramme de comportement plus général, comprennent le diagramme de séquence, le diagramme de communication, le diagramme de temps et le diagramme de vue d’ensemble des interactions.

Nous ne souhaitons pas que cette page Web d’introduction soit un didacticiel UML complet. Nous n’allons donc pas répertorier ici les détails des différents types de diagramme. Pour en savoir plus, vous pouvez consulter l’un des nombreux tutoriels en ligne ou acheter un livre. (La dernière fois que nous avons vérifié, taper “UML” dans la boîte de recherche des principaux libraires en ligne avait renvoyé une liste de plus de 100 titres!). Ou, si vous êtes technique et que vous souhaitez l’histoire complète, vous pouvez télécharger le format UML. spécification du site Web OMG. C’est gratuit, bien sûr, mais c’est aussi très technique, concis et très difficile à comprendre pour les débutants. (Pour quelques autres paragraphes expliquant pourquoi les spécifications sont difficiles à lire, regardez ici.)

Je suis sur le point de démarrer mon premier projet de développement basé sur UML. QU’EST-CE QUE JE DOIS FAIRE?
Trois choses, probablement (mais pas nécessairement) dans cet ordre:

  1. Sélectionnez une méthodologie: une méthodologie définit formellement le processus que vous utilisez pour rassembler les exigences, les analyser et concevoir une application qui les respecte à tous les égards. Il existe de nombreuses méthodologies, chacune différant d’une manière ou d’une autre des autres. Il existe de nombreuses raisons pour lesquelles une méthodologie peut être meilleure qu’une autre pour votre projet particulier: par exemple, certaines sont mieux adaptées aux grandes applications d’entreprise, tandis que d’autres sont conçues pour concevoir de petits systèmes intégrés ou à sécurité critique. Sur un autre axe, certaines méthodes prennent mieux en charge un grand nombre d’architectes et de concepteurs travaillant sur le même projet, tandis que d’autres fonctionnent mieux lorsqu’elles sont utilisées par une seule personne ou un petit groupeOMG, en tant qu’organisation indépendante du fournisseur, qui n’a pas d’opinion sur une méthodologie.
  2. Sélectionnez un outil de développement UML: étant donné que la plupart (bien que pas tous) des outils basés sur UML implémentent une méthodologie particulière, dans certains cas, il peut ne pas être pratique de choisir un outil, puis d’essayer de l’utiliser avec une méthodologie pour laquelle il n’a pas été construit. . (Pour d’autres combinaisons outil / méthodologie, cela peut ne pas être un problème, ou il peut être facile de contourner le problème.) Cependant, certaines méthodologies ont été mises en œuvre sur plusieurs outils, de sorte qu’il ne s’agit pas d’un environnement à choix unique. Vous pouvez trouver un outil si bien adapté à votre application ou à votre organisation que vous êtes prêt à changer de méthodologie pour l’utiliser. Si tel est le cas, continuez – notre conseil de choisir une méthodologie est d’abord général et peut ne pas s’appliquer à un projet spécifique. Autre possibilité: vous pouvez trouver une méthodologie que vous aimez, qui n’est pas implémentée dans un outil qui convient à la taille de votre projet ou à votre budget, vous devez donc basculer. Si vous rencontrez l’un de ces cas, essayez de choisir une autre méthodologie qui ne diffère pas trop de celle que vous aviez préférée à l’origine. Comme pour les méthodologies, OMG n’a pas d’opinion ni d’évaluation des outils de modélisation basés sur UML, mais nous avons des liens vers un certain nombre de listes ici. Cela vous aidera à commencer à faire votre choix.
  3. Formation: vous et votre personnel (sauf si vous avez la chance d’engager des architectes expérimentés en langage UML) aurez besoin d’une formation en langage UML. Il est préférable de suivre une formation qui explique comment utiliser l’outil choisi avec la méthodologie choisie, généralement fournie par le fournisseur de l’outil ou le méthodologiste. Si vous décidez de ne pas suivre cette voie, consultez la page de formation d’OMG pour un cours qui répond à vos besoins. Une fois que vous avez appris le langage UML, vous pouvez devenir un professionnel UML certifié OMG – consultez ici pour plus de détails.

UML 2.0 – UNE MISE À NIVEAU IMPORTANTE
La version “disponible” de la spécification UML 2.0 Superstructure (c’est-à-dire la version qui a terminé sa première version de maintenance et qui a été intégrée aux produits du fournisseur) est terminée et peut être téléchargée gratuitement à tout le monde. Trois parties distinctes d’UML 2.0 – l’infrastructure (c’est-à-dire le méta-métamodèle), le langage de contrainte d’objet et l’échange de diagrammes – font toujours l’objet de leur première maintenance et deviendront des spécifications disponibles une fois cette opération terminée. Vous trouverez une description de l’état actuel des quatre spécifications et des liens vers chacune d’elles, ici.

QUOI DE NEUF DANS UML 2.0
Nous avons déjà intégré les nouvelles fonctionnalités dans cet article, mais voici un résumé:

Classificateurs imbriqués: C’est un concept extrêmement puissant. En UML, presque tous les blocs de construction de modèle avec lesquels vous travaillez (classes, objets, composants, comportements tels que les activités et les machines d’état, etc.) constituent un classificateur. En UML 2.0, vous pouvez imbriquer un ensemble de classes dans le composant qui les gère ou incorporer un comportement (tel qu’une machine à états) dans la classe ou le composant qui l’implémente. Cette fonctionnalité vous permet également de créer des comportements complexes à partir de comportements plus simples, la fonctionnalité qui définit le diagramme de synthèse d’interaction. Vous pouvez superposer différents niveaux d’abstraction de différentes manières: par exemple, vous pouvez créer un modèle de votre entreprise et effectuer un zoom avant sur les vues de site incorporées, puis sur les vues départementales du site, puis sur les applications d’un département. Vous pouvez également imbriquer des modèles de calcul dans un modèle de processus métier. Le groupe de travail sur le domaine d’intégration des entreprises d’OMG (BEI DTF) travaille actuellement sur plusieurs nouvelles normes intéressantes en matière de processus et de règles d’activité.
Modélisation comportementale améliorée: dans UML 1.X, les différents modèles comportementaux étaient indépendants, mais dans UML 2.0, ils découlent tous d’une définition fondamentale d’un comportement (à l’exception du cas d’utilisation, légèrement différent mais qui participe toujours à la nouvelle organisation. ).
Amélioration de la relation entre les modèles structurels et comportementaux: comme nous l’avons souligné sous Classificateurs imbriqués, UML 2.0 vous permet d’indiquer qu’un comportement représenté par (par exemple) une machine à états ou un diagramme de séquence est le comportement d’une classe ou d’un composant.
Autrement dit, le nouveau langage va bien au-delà des classes et des objets bien modélisés par UML 1.X et permet de représenter non seulement les modèles comportementaux, mais également les modèles architecturaux, les processus et règles métier, ainsi que d’autres modèles utilisés dans de nombreuses parties différentes. des disciplines informatiques et même non informatiques.

Au cours du processus de mise à niveau, plusieurs ajouts au langage y ont été incorporés, notamment le langage OCL (Object Constraint Language) et la sémantique d’action.

 

Source : http://www.uml.org/what-is-uml.htm