"UML. Une perspective extérieure »ou« Comment l'UML garde les analystes dans le passé »

Image de www.uml.org Cet



article concerne UML et ses utilisations actuelles. Un peu d'informations historiques, très peu, seuls les points principaux:

• L'UML est né dans les années 90 à la suite d'un travail de création d'un langage de modélisation orienté objet.
• La spécification 1.0 est sortie en 1997.
• La spécification 2.0 a été publiée en 2005.
• À ce jour, UML 2.5, plusieurs profils ont évolué, tels que SysML et SoaML .

Si vous regardez comment UML a été utilisé à l'époque et maintenant, et que vous y réfléchissez, vous pouvez tirer la conclusion suivante: Que la version d'UML soit 2.5 maintenant, mais les principes d'utilisation du langage n'ont pas changé depuis la première version.



Et en conséquence: les analystes utilisent le concept de description des systèmes logiciels, qui a été établi il y a plus de 20 ans. Le concept lui-même est bon, mais vous devez le relier au lieu et au contexte d'utilisation.



Si nous continuons cette analyse de l'application UML, et la corrélons également avec les exigences de l'heure actuelle, les conclusions sont les suivantes:

• Toutes les méthodes d'utilisation d'UML «tout autour» utilisent le développement basé sur des cas.
• Les modèles UML manquent d'intégrité. L'approche choisie consistant à décrire séparément les aspects de la structure et du comportement, les niveaux métier et applicatif complique la perception des modèles dans leur ensemble.
• UML est un langage orienté objet, ce qui rend difficile l'expression d'autres concepts avec lui.

Je ne dirai rien de l’approche du développement basé sur des cas d’utilisation; l’une de ses incarnations est le processus unifié rationnel. Ensuite, je vais parler des deux derniers points.

Aspects de présentation

UML se compose de nombreux diagrammes. Chacun obéit à ses propres règles, utilise des éléments et des flèches dans sa propre compréhension. Et de l'extérieur, il ne ressemble pas à un langage unifié, mais à un ensemble de représentations différentes, qui est souvent présenté comme une opportunité de regarder un domaine de différents points de vue. Avec le même succès, le couteau suisse peut être qualifié d'outil unifié, qui est essentiellement un ensemble composé de lames, tournevis, ouvre-bouteilles, cuillères, fourchettes, et tout cela sur une seule poignée.







Que fait un analyste lorsqu'il essaie de lier tous les graphiques en un seul modèle? Il commence à construire des graphiques hybrides et des tableaux de liens. Le résultat n'est pas un modèle unique, mais un ensemble de diagrammes, auxquels d'autres diagrammes et tableaux ont été ajoutés.

Niveaux de présentation

Supposons qu'un analyste commercial ait décrit un domaine à l'aide de diagrammes UML. Et maintenant, un analyste de systèmes ou le même analyste doit former un modèle de système logiciel. Si l'analyste se concentre sur l'UML, alors il commencera à créer des vues correspondant à celles faites précédemment, mais déjà dans le cadre du système. Cela ressemblera à nouveau à des diagrammes similaires.







Que fera l'analyste lorsqu'il voudra comparer la description du domaine et le modèle du système?



Il recommence à construire des diagrammes hybrides, des tableaux de liens et de traces.



Le résultat est encore une fois beaucoup de graphiques et de tableaux.







Il reste à noter que UML est un langage ancien et qu'il existe un grand nombre de livres et d'exemples anciens.Dans lequel sont décrits principalement les cas de transition d'une entreprise manuelle à une entreprise automatisée. Et les analystes apprennent de ces exemples. Mais aujourd'hui, la technologie de l'information a pénétré partout. L'approche «Business séparément, IT séparément» est inacceptable .

Approche orientée service

UML est un langage orienté objet, ce qui rend difficile l'expression d'autres concepts avec lui. Par exemple, orienté service. Le profil standard UML n'a pas de concept de «service», mais il existe un profil SoaML qui est présenté comme un langage de modélisation d'architecture orienté services.



Je parlerai brièvement d’une approche orientée services, afin que plus tard, on comprenne pourquoi SoaML ne convient pas à sa modélisation. Prenons comme base l'interprétation des définitions de TOGAF .



Pour une simple formalisation d'une approche orientée service, nous avons besoin de 2 abstractions:

• Le processus est le flux de contrôle entre / sur les services. Il faut également dire que le processus est une séquence d'actions qui, ensemble, aboutissent à un certain résultat.
• Service - un élément de comportement qui fournit une certaine fonctionnalité en réponse aux demandes des sujets ou d'autres services. Un service fournit ou prend en charge des capacités , possède une interface explicitement définie et est explicitement contrôlé.

Voyons comment cela est modélisé dans SoaML. Dans le même temps, comparons les différences entre la modélisation orientée objet en UML et la modélisation orientée services dans SoaML.

Homme et boutique

Tâche: décrire le modèle d'achat de marchandises dans le magasin.



L'approche orientée objet, je pense, est claire et simple pour tout le monde. Afin de ne pas perdre de temps, nous ne considérerons pas la couche métier. Je pense que tout le monde peut imaginer dans sa tête le cas d'utilisation conseillé et ses détails sous la forme d'un diagramme d'activité ou d'un diagramme de séquence.







Une personne n'agit pas en tant qu'utilisateur, mais en tant que partie à l'interaction.

Nous allons maintenant résoudre ce problème en utilisant SoaML, strictement en conformité avec les spécifications .







Dans ce diagramme, nous définissons la communauté de personnes en interaction, c'est-à-dire le magasin et la personne.

Nous déterminons le processus commercial «Vendre des marchandises» entre eux, dans lequel le Magasin agit en tant que «vendeur», et la Personne en tant qu '«acheteur».







Sur la base du processus métier, nous pouvons désormais identifier le prochain service métier, dans SoaML, le classifieur ServiceContract est utilisé pour cela.







Dans le cadre de ce service: Le vendeur agit en tant que fournisseur et l'acheteur en tant que consommateur.

Le vendeur, en tant que fournisseur, fournit une opération de «vente». L'analyse commerciale est terminée, nous passons au niveau système.



Nous devons simuler au niveau du système une version mise à jour de notre processus commercial de vente de marchandises. Pour cela j'ai choisi un diagramme de séquence, vous pouvez utiliser n'importe quel autre diagramme de comportement.







À partir du processus commercial mis à jour, nous pouvons distinguer une opération «vendre», nous l'organiserons dans l'interface de base «Qui sait comment vendre».



Ensuite, nous devons décrire les interfaces de service qui seront utilisées pour implémenter le service.



Nous obtenons les interfaces de service suivantes:

• "Désir de vendre", hérité de l'interface "Vendre";
• «Besoin d'acheter», qui dépend de l'interface «capable de vendre».

Vous pouvez maintenant représenter le modèle de service cible sous forme de diagramme de structure composite.







Comparez les résultats de la modélisation orientée objet en UML et de la modélisation orientée services dans SoaML.







Visuellement, toute la différence réside dans ces petits carrés à la frontière des composants. Je les ai marqués en rouge. Est-ce là toute la différence?



Il y a vraiment une différence entre la modélisation orientée objet et orientée service, c'est juste que SoaML a tout réduit à des objets. Mais plus là-dessus plus tard.



Et maintenant, nous terminerons l'examen de SoaML sur un cas plus complexe, puis nous obtiendrons approximativement les schémas suivants.







Qu'est-ce qui ne va pas, à mon avis, avec SoaML.



d'abord: Encore une fois, des problèmes d'intégrité du langage et de relation entre le niveau métier et le niveau applicatif, vous avez vous-même vu à quel point tout est difficile à mettre en relation les uns avec les autres.



Deuxièmement : le service est décrit comme un objet de structure, ce n'est pas bon. Dans le discours russe, la phrase «Le fournisseur représente un service» est courante, il s'agit d'une approche orientée composants qui est implémentée dans SoaML. Mais dans le cas du paradigme orienté service, il est plus correct de dire «Le fournisseur fournit un service». Et si vous traduisez différemment «Service» en russe, tout se met immédiatement en place: «Le fournisseur fournit un service ». De ce point de vue, «Service» n'est pas «Objet», c'est «Comportement».



Troisièmement: Sur la diapositive sur l'architecture orientée services, j'ai parlé de deux abstractions: Process et Service. Les visualiser et les décrire à travers le prisme d'une approche orientée objet est, pour le moins dire, une tâche stressante.

Paradigmes

Revenons à l'UML. UML, à travers son paradigme, tente de décrire d'autres paradigmes.







Et si tout fonctionne avec le paradigme orienté composant, il peut être présenté comme une continuation logique de celui orienté objet. Celui axé sur le service n'a pas bien fonctionné.

Dans ce cas, exprimer un paradigme à travers une autre idée malheureuse.

J'ai démontré l'utilisation d'un tel concept avec SoaML en utilisant l'exemple de la tâche «Man and Shop».



Elle se rapporte mieux aux paradigmes comme indiqué ci-dessous.







Je vais montrer en quoi la modélisation orientée service diffère de la modélisation orientée objet.

Homme et chien

Tâche: Décrivez un modèle d'interaction - Une personne marche avec un chien.



Tout étudiant de la faculté technique résoudra probablement ce problème sans hésitation. La programmation orientée objet est un incontournable dans les écoles et les universités des spécialités concernées. L'approche orientée objet est présentée ci-dessous.







À quoi ressemblerait un modèle orienté services? Je ne sais pas si un élève répondra à une telle question.





Vous pouvez rappeler l'historique de la programmation orientée objet. À quel point étaient sceptiques des personnes très autoritaires comme Edsger Dijkstra et Niklaus Wirth au début de son apparition. Et pourtant, certaines personnes considèrent que la POO ne mérite pas d'attention.



Eh bien, ce modèle peut également provoquer des sourires. Le fait est que le paradigme axé sur les services ne dispose pas d'un soutien suffisant au niveau initial de la programmation et de la conception. Pour les programmeurs, la prise en charge est fournie uniquement par des frameworks, par exemple, Java Enterprise Edition ou Spring. Je pense que les programmeurs y parviennent avec une tête déjà formatée pour une approche orientée objet.

Les analystes construisent leurs idées sur l'architecture orientée services et conçoivent des articles sur Internet qui ont une compréhension différente de ce que c'est, et certains articles sans une immersion profonde dans les détails et les détails techniques ne sont généralement pas clairs. En conséquence, les analystes reviennent aux cas d'utilisation généralement acceptés entre le système et les utilisateurs. Il est également courant que l'architecture du système et la composition de ses composants soient déjà fixées par l'architecte ou en raison de la plateforme choisie. Ensuite, les analystes décrivent à nouveau simplement le cas d'utilisation entre le système et les utilisateurs.



Comparez l'approche orientée objet et celle apparemment ridicule, où l'homme rend le service de marche au chien. Quand cela cessera d'être drôle pour vous, mais que l'approche orientée objet, où l'Humain met en œuvre la méthode de "marcher", vous semblera drôle,à l'entrée à laquelle le Chien est servi !!! C'est à ce moment que vous avez compris le paradigme orienté services.



Il convient de noter que ces paradigmes sont tout à fait compatibles. Une personne peut encore effectuer ses actions habituelles: dormir et danser, et le chien peut aboyer.

Encore un point: dans cet exemple, j'ai introduit un nouveau concept "Service". Dans le même temps, je n'ai pas encore clairement défini les règles de son utilisation, mais cela diffère de celui de SoaML. Ici, vous devez faire attention, vous ne devez pas vous laisser emporter par cela, car de telles extensions sont liées au métamodélisation. Il peut arriver que les modèles créés se révèlent contradictoires et obscurs.

Au lieu d'une conclusion

• UML . , . .
• . , . .
• UML . , . , UML, .