„UML. Eine Außenperspektive "oder" Wie die UML Analysten in der Vergangenheit hält "

Bild von www.uml.org Der



Artikel widmet sich der UML und den Besonderheiten ihrer gegenwärtigen Anwendung. Ein bisschen historische Information, sehr wenig, nur die Hauptpunkte:

• Die UML entstand in den 90er Jahren als Ergebnis der Arbeit an einer objektorientierten Modellierungssprache.
• Die Spezifikation 1.0 wurde 1997 veröffentlicht.
• Die Spezifikation 2.0 wurde 2005 veröffentlicht.
• Bis heute, UML 2.5, haben sich mehrere Profile entwickelt, wie z. B. SysML und SoaML .

Wenn Sie sich ansehen, wie die UML damals und heute angewendet wurde, und darüber nachdenken, können Sie die folgende Schlussfolgerung ziehen: Lassen Sie die UML-Version jetzt 2.5 sein, aber die Prinzipien der Verwendung der Sprache haben sich seit der ersten Version nicht geändert.



Und als Konsequenz: Analysten verwenden das vor mehr als 20 Jahren festgelegte Konzept der Beschreibung von Softwaresystemen. Das Konzept selbst ist gut, aber Sie müssen es mit dem Ort und dem Kontext der Verwendung in Beziehung setzen.



Wenn wir diese Analyse der UML-Anwendung fortsetzen und sie auch mit den Anforderungen der aktuellen Zeit korrelieren, sind die Schlussfolgerungen wie folgt:

• Alle Methoden zur Verwendung von UML "umgehen" Use Case Driven Development.
• UML-Modelle sind nicht integer. Der gewählte Ansatz, Aspekte der Struktur und des Verhaltens sowie der Geschäfts- und Anwendungsebenen getrennt zu beschreiben, erschwert die Wahrnehmung von Modellen als Ganzes.
• UML ist eine objektorientierte Sprache, die es schwierig macht, andere Konzepte damit auszudrücken.

Ich werde nichts über den Use Case Driven Development-Ansatz sagen. Eine seiner Inkarnationen ist der Rational Unified Process. Als nächstes werde ich über die letzten beiden Punkte sprechen.

Präsentationsaspekte

Die UML besteht aus vielen Diagrammen. Jeder von ihnen gehorcht seinen eigenen Regeln, verwendet Elemente und Pfeile in seinem eigenen Verständnis. Und von außen sieht es nicht wie eine einheitliche Sprache aus, sondern wie eine Reihe verschiedener Darstellungen, die oft als Gelegenheit präsentiert werden, den Themenbereich aus verschiedenen Blickwinkeln zu betrachten. Mit dem gleichen Erfolg können Sie das Schweizer Messer als ein einheitliches Werkzeug bezeichnen, das aus Klingen, Schraubendrehern, Öffnern, Löffeln, Gabeln und allem auf einem Griff besteht.







Was macht ein Analyst, wenn er versucht, alle Diagramme zu einem Modell zu verknüpfen? Er beginnt mit dem Aufbau von Hybrid-Charts und Link-Tabellen. Das Ergebnis ist kein einzelnes Modell, sondern eine Reihe von Diagrammen, zu denen weitere Diagramme und Tabellen hinzugefügt wurden.

Präsentationsstufen

Angenommen, ein Business Analyst hat einen Themenbereich mithilfe von UML-Diagrammen beschrieben. Und jetzt muss ein Systemanalytiker oder derselbe Analyst ein Modell eines Softwaresystems bilden. Wenn sich der Analyst auf die UML konzentriert, beginnt er mit der Erstellung von Ansichten, die denen entsprechen, die zuvor erstellt wurden, jedoch bereits im Rahmen des Systems. Es wird wieder wie in ähnlichen Diagrammen aussehen.







Was wird der Analytiker tun, wenn er die Beschreibung des Themenbereichs und das Modell des Systems vergleichen möchte?



Er beginnt wieder, hybride Diagramme, Tabellen mit Links und Spuren zu erstellen.



Das Ergebnis sind wieder viele Diagramme und Tabellen.







Es sollte auch hier angemerkt werden, dass UML eine alte Sprache ist und es viele Bücher und alte Beispiele dafür gibt.Dies beschreibt hauptsächlich Fälle des Übergangs von einem nicht automatisierten zu einem automatisierten Geschäft. Und Analysten lernen aus diesen Beispielen. Aber heute sind Informationstechnologien überall eingedrungen. Der Ansatz "Geschäft getrennt, IT getrennt" ist nicht akzeptabel .

Serviceorientierter Ansatz

UML ist eine objektorientierte Sprache, die es schwierig macht, andere Konzepte damit auszudrücken. Zum Beispiel serviceorientiert. Das UML-Standardprofil hat kein Konzept für "Service", aber es gibt ein SoaML- Profil , das als serviceorientierte Architekturmodellierungssprache angepriesen wird.



Ich werde kurz auf den serviceorientierten Ansatz eingehen, damit später klar wird, warum SoaML nicht für die Modellierung geeignet ist. Basierend auf der Interpretation der Definitionen von TOGAF .



Für eine einfache Formalisierung des serviceorientierten Ansatzes benötigen wir zwei Abstraktionen:

• Prozess ist der Kontrollfluss zwischen / über Services. Es muss auch gesagt werden, dass ein Prozess eine Folge von Aktionen ist, die zusammen ein bestimmtes Ergebnis erzielen.
• Service ist ein Verhaltenselement, das bestimmte Funktionen als Antwort auf Anforderungen von Subjekten oder anderen Services bereitstellt. Ein Dienst bietet oder unterstützt Funktionen , verfügt über eine explizit definierte Schnittstelle und wird explizit gesteuert.

Mal sehen, wie dies in SoaML modelliert wird. Vergleichen wir gleichzeitig, wie sich die objektorientierte Modellierung in UML und die serviceorientierte Modellierung in SoaML unterscheiden.

Mann und Laden

Ziel: Beschreiben Sie das Modell für den Kauf von Waren im Geschäft.



Ich denke, der objektorientierte Ansatz ist für alle klar und einfach. Um keine Zeit zu verschwenden, werden wir die Geschäftsschicht nicht berücksichtigen. Ich denke, jeder kann sich in seinem Kopf den beratenden Anwendungsfall und seine Detaillierung in Form eines Aktivitätsdiagramms oder eines Sequenzdiagramms vorstellen.







Eine Person handelt nicht als Benutzer, sondern als eine der Parteien der Interaktion.

Jetzt lösen wir dieses Problem mit SoaML streng nach Vorgabe .







In diesem Diagramm definieren wir die Community der interagierenden Personen. Dies ist der Store und die Person.

Wir definieren den zwischen ihnen ablaufenden Geschäftsprozess „Verkauf von Waren“, bei dem das Geschäft als „Verkäufer“ und die Person als „Käufer“ fungiert.







Basierend auf dem Geschäftsprozess können wir nun den folgenden Geschäftsservice identifizieren: In SoaML wird hierfür der ServiceContract-Klassifikator verwendet.







Im Rahmen dieser Dienstleistung: Der Verkäufer fungiert als Anbieter und der Käufer als Verbraucher.

Der Verkäufer als Lieferant bietet eine "Verkaufs" -Operation an. Die Geschäftsanalyse ist abgeschlossen, wir gehen zur Systemebene über.



Wir müssen auf Systemebene eine aktualisierte Version unseres Geschäftsprozesses für den Produktverkauf modellieren. Dafür habe ich ein Sequenzdiagramm gewählt, Sie können jedes andere Verhaltensdiagramm verwenden.







Aus dem aktualisierten Geschäftsprozess kann man einen "Verkaufs" -Vorgang unterscheiden. Wir werden ihn in der grundlegenden "Able to Sell" -Schnittstelle ausführen.



Als Nächstes müssen wir die Dienstschnittstellen beschreiben, die zur Implementierung des Dienstes verwendet werden.



Wir erhalten folgende Serviceschnittstellen:

• "Desire to Sell", das von der "Selling" -Schnittstelle geerbt wird;
• "Need to Buy", was von der "Selling" -Schnittstelle abhängt.

Jetzt können Sie sich das Zieldienstmodell in Form eines zusammengesetzten Strukturdiagramms vorstellen.







Vergleichen wir die Ergebnisse der objektorientierten Modellierung in UML und der serviceorientierten Modellierung in SoaML.







Optisch liegt der ganze Unterschied in diesen kleinen Quadraten am Rand der Komponenten. Ich habe sie rot markiert. Ist das der ganze Unterschied?



Es gibt wirklich einen Unterschied zwischen objektorientierter und serviceorientierter Modellierung. Es ist nur so, dass SoaML alles auf Objekte reduziert hat. Aber dazu später mehr.



Und jetzt wollen wir die Betrachtung von SoaML in einem komplexeren Fall beenden, dann werden wir uns mit den folgenden Schemata befassen.







Was ist meiner Meinung nach mit SoaML falsch?



Erstens: Auch bei Problemen mit der Integrität der Sprache und der Beziehung zwischen der Unternehmensebene und der Anwendungsebene haben Sie selbst gesehen, wie schwierig alles miteinander zusammenhängt.



Zweitens : Service wird als Objekt der Struktur beschrieben, das ist nicht gut. In der russischen Sprache ist der Ausdruck "Der Anbieter repräsentiert einen Dienst" üblich. Dies ist ein komponentenorientierter Ansatz, der in SoaML implementiert ist. Im Fall des serviceorientierten Paradigmas ist es jedoch korrekter zu sagen: "Der Lieferant bietet einen Service an." Und wenn Sie "Service" anders ins Russische übersetzen, passt sofort alles zusammen: "Der Lieferant bietet einen Service an ." Unter diesem Gesichtspunkt ist "Service" kein "Objekt", sondern ein "Verhalten".



Drittens: Auf der Folie über serviceorientierte Architektur habe ich über zwei Abstraktionen gesprochen: Prozess und Service. Sie durch die Linse eines objektorientierten Ansatzes zu betrachten und zu beschreiben, ist, gelinde gesagt, eine herausfordernde Aufgabe.

Paradigmen

Kehren wir zur UML zurück. Die UML versucht, andere Paradigmen durch ihr Paradigma zu beschreiben.







Und wenn sich alles mit einem komponentenorientierten Paradigma herausstellt, kann es als logische Fortsetzung eines objektorientierten dargestellt werden. Das mit einem serviceorientierten stellte sich schlecht heraus.

In diesem Fall ein Paradigma durch eine andere unglückliche Idee ausdrücken.

Ich habe die Verwendung eines solchen Konzepts mit SoaML am Beispiel der Aufgabe „Man and Shop“ demonstriert.



Gilt besser für Paradigmen wie unten angegeben.







Ich werde zeigen, wie sich die serviceorientierte Modellierung von der objektorientierten Modellierung unterscheidet.

Mensch und Hund

Ziel: Beschreiben Sie das Interaktionsmodell - Eine Person geht mit einem Hund spazieren.



Ohne einen zweiten Gedanken wird diese Aufgabe wahrscheinlich von jedem Studenten der technischen Fakultät gelöst. Objektorientierte Programmierung ist in Schulen und Universitäten in den jeweiligen Fachgebieten ein Muss. Der objektorientierte Ansatz wird im Folgenden vorgestellt.







Wie würde ein serviceorientiertes Modell aussehen? Ich weiß nicht, ob ein Schüler eine solche Frage beantworten wird.





Sie können sich an die Geschichte der objektorientierten Programmierung erinnern. Wie skeptisch waren zu Beginn seines Auftritts sogar sehr maßgebliche Personen wie Edsger Dijkstra und Niklaus Wirth. Und bis heute halten einige Leute OOP für unwürdig.



Nun, dieses Modell kann auch ein Lächeln verursachen. Tatsache ist, dass ein serviceorientiertes Paradigma auf der anfänglichen Ebene der Programmierung und des Designs nicht ausreichend unterstützt wird. Für Programmierer wird die Unterstützung nur von Frameworks bereitgestellt, z. B. Java Enterprise Edition oder Spring. Ich denke, dass Programmierer mit einem Kopf zu ihnen gelangen, der bereits für einen objektorientierten Ansatz formatiert ist.

Analysten entwickeln ihre Ideen zur serviceorientierten Architektur und zum Entwerfen von Artikeln im Internet, die ein anderes Verständnis davon haben, was es ist, und einige Artikel ohne tiefes Eintauchen in die Einzelheiten und technischen Details sind im Allgemeinen unverständlich. Infolgedessen kehren Analysten zum allgemein akzeptierten Anwendungsfall zwischen dem System und den Benutzern zurück. Es ist auch üblich, dass die Architektur des Systems und seine Komponentenzusammensetzung bereits vom Architekten festgelegt oder von der gewählten Plattform bestimmt werden. Und dann beschreiben Analysten einfach den Anwendungsfall zwischen dem System und den Benutzern.



Vergleichen Sie den objektorientierten Ansatz mit diesem scheinbar lächerlichen, bei dem der Mann dem Hund einen "Walk" -Dienst leistet. Wenn es für Sie nicht mehr lächerlich ist und der objektorientierte Ansatz lächerlich erscheint, wenn die Person die „Walk“ -Methode implementiert,am Eingang, an dem der Hund serviert wird !!! Dann haben Sie das serviceorientierte Paradigma verstanden.



Es ist anzumerken, dass diese Paradigmen durchaus kompatibel sind. Eine Person kann immer noch ihre üblichen Handlungen ausführen: schlafen und tanzen und der Hund bellen.

Noch ein Punkt: In diesem Beispiel habe ich ein neues Konzept "Service" eingeführt. Ich habe die Regeln für die Verwendung noch nicht klar definiert, aber sie unterscheiden sich von denen in SoaML. Hier müssen Sie vorsichtig sein, lassen Sie sich nicht zu sehr mitreißen, da sich diese Art der Erweiterung auf Metamodellierung bezieht. Es kann vorkommen, dass sich die erstellten Modelle als widersprüchlich und undurchsichtig herausstellen.

Anstelle einer Schlussfolgerung

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