Get best of the week

UML für Entwickler

Das Internet ist voll von Artikeln über UML, Sie finden Hunderte von Beispielen für jeden Diagrammtyp und erstellen problemlos Ihre eigenen, die Notation ist nicht kompliziert. Aber ist es wirklich notwendig, Zeit damit zu verbringen? Unser Erfahrungsschatz sagt ja. Wenn Sie mehr als 2 Personen in einem Team und ein Projekt von 3 Monaten oder mehr haben, ist es bereits sinnvoll, 2-3 Diagrammtypen zu zeichnen. Unser Team hat mehr als 30 Mitarbeiter, ein Projekt, das mehr als 3 Jahre dauert, und wir verwenden ... 2-3 Arten von Diagrammen.

Die UML-Notation ist redundant. Andererseits reicht es für den Entwurf verteilter Systeme nicht aus, und hier hilft uns Archimate. In diesem Artikel erklären wir Ihnen, was aus all dieser Vielfalt wirklich nützlich ist, und betrachten als Beispiel den gesamten Zyklus der Erstellung von Diagrammen für ein Projekt.

Was werden wir zeichnen?


Wenn Ihr Ziel „schnell und schön“ ist (z. B. für eine Präsentation oder für diesen Artikel), ist Visio mehr als geeignet: Der Editor ist praktisch und vergibt Abweichungen von der Notation.

Wenn Sie sich mit Design beschäftigen, benötigen Sie ein komplettes System mit Unterstützung für die Beziehungen zwischen Diagrammen. Wir verwenden Enterprise Architect Produkte, billig und fröhlich.
Ein Vergleich von Designsystemen und eine Geschichte über deren korrekte Verwendung ist ein Thema für einen separaten Artikel.

Technische Aufgabe


Wir werden eine hypothetische mobile Anwendung zum Erlernen von Fremdsprachen entwerfen. Die Leistungsbeschreibung wird normalerweise von Analysten erstellt, die den ersten Diagrammstapel erstellen. Entwickler müssen sie in diesem Fall nur korrekt lesen.

Das einfachste Diagramm ist der Anwendungsfall:



Das Diagramm zeigt die Benutzertypen und listet die Funktionen oder Funktionsgruppen auf, die ihnen zugeordnet sind. Das blau hervorgehobene Element, das in UML nicht vorhanden ist, aber häufig fehlt: Anforderung - Anforderung (aus der Archimate-Notation), Klärung der Funktionen.

Sie fragen - und worum geht es? Schließlich kann die Liste der Funktionen einfach in Textform in einer kompakten Liste angegeben werden! Und Sie werden Recht haben, aber es gibt Nuancen.

  1. Einige Funktionen beziehen sich auf mehrere Benutzer, es ist schwierig, den Text anzuzeigen.
  2. Wenn Sie alle Funktionen und Anforderungen im Entwurfssystem zeichnen, können Sie sie auf dieselbe Jira hochladen und sie dann Aufgaben und Fehlern zuordnen, was das Projektmanagement vereinfacht.

Warum haben wir UML und Archimate im selben Diagramm gemischt? Sie müssen sich nicht strikt an die Notizen halten, Sie müssen damit keine Prüfungen an der Universität bestehen, sondern mit dem Team kommunizieren, auf das Sie alles vorbereiten.

Warum haben wir Linien statt Pfeile verwendet, um Elemente zu verbinden? Weil sich niemand daran erinnert, wie die Pfeile "Generalisierung" und "Erweiterung" aussehen und wie sie im Allgemeinen sind. Je einfacher Sie zeichnen, desto mehr Menschen verstehen das Diagramm ohne Ihre Teilnahme.

Die zweite Art von Diagrammen, die Sie in der technischen Aufgabe treffen können, ist das Aktivitätsdiagramm:



Hier ist dem Entwickler alles klar, bis auf eines: Warum ruft die KI Schüler an? Nicht. Dieses Diagramm wird von Analysten gezeichnet, nicht von Programmierern. Sie wissen nicht, wo sich der Client befindet, aber wo sich der Server befindet, und sie sind nicht an Datenströmen interessiert. Im Aktivitätsdiagramm sehen Sie eine Abfolge von Aktionen und nichts weiter. Wie mache ich daraus einen Code? Wir gehen zur Entwurfsphase über.

Architektur-Design


Die Architektur der mobilen Anwendung ist offensichtlich: Client, Server, Datenbank. Wenn wir etwas Ernstes entwerfen, sollten wir uns darum kümmern, das Projekt in Subsysteme zu unterteilen. In unserem Fall ist es zumindest:

  • Subsystem für die Buchung von Lektionen
  • Web Training Subsystem
  • Abrechnung
  • Subsystem zur Verwaltung von Sprachaufzeichnungen

Subsysteme sollten voneinander isoliert sein: eigene Datenbanken ohne relationale Verbindungen zu anderen Subsystemen, Kommunikation zwischen Subsystemen nur über die API. Das Subsystem kann nach Ihrem Ermessen entweder eine Reihe von Mikrodiensten oder ein Monolith sein.

Sie können jedes Subsystem einem dedizierten Entwicklungsteam übergeben, das sich mit seinem Thema befasst und die Kollegen bei ihren unerwarteten Verpflichtungen weniger stört.

Für jedes Subsystem ist ein Architekturschema erforderlich . Wie kann es richtig gezeichnet werden? Dafür gibt es in UML keine geeigneten Diagramme. Schauen wir uns Archimate an:



Auch ohne Kenntnis der Notation ist das Diagramm in der Regel lesbar. Denken Sie daran, dass 90% Ihrer Teammitglieder weder UML noch Archimate kennen und diese Notationen niemals lernen werden. Konzentrieren Sie sich daher auf die Inschriften. Trotzdem ein



paar Worte zu den Würfeln und Pfeilen: Sie können die vollständige Archimate-Spezifikation leicht finden.

Farbe - nach Ihrem Geschmack reguliert die Notation sie in keiner Weise. Färben Sie das aktuelle Subsystem mit einer Farbe, die benachbarten Subsysteme mit dem zweiten, externe Systeme mit dem dritten, dies verbessert die Lesbarkeit der Schaltung erheblich.

Das Diagramm verwendet nur zwei Arten von Pfeilen: Fluss und Zugriff. Der Ablauf zeigt die Richtung der Datenübertragung und den Anruf - wer spricht mit wem? Der Flusspfeil sollte richtig verstanden werden:



Das Flussdiagramm von der mobilen Anwendung zum Server wird im Diagramm nicht angezeigt, obwohl dies tatsächlich der Fall ist (der Stream "Datenanforderung" wird zuerst angezeigt). Dies geschieht, um das Schema leichter lesbar zu machen: Wir zeigen nur das Wichtigste. Die Tatsache, dass es auch eine erste Datenanforderung gibt, ist bereits aus dem Cube mit der Beschriftungs-API ersichtlich.

Detail


Die letzten beiden Diagramme sind sehr nützlich (ein aufmerksamer Leser hat natürlich bemerkt, dass es nicht mehr 2-3 Arten von Diagrammen gibt): Sequenzdiagramm (Klassendiagramm) und Klassendiagramm (Klassendiagramm, aber überhaupt nicht für Klassen).

Manchmal ist die Client-Server-Interaktion mehrstufig und verwendet dritte Ressourcen. Beispiel: Autorisierung mit Oauth2: Eine Textbeschreibung dieses Prozesses ist sehr schwer zu verstehen. Hier hilft uns das Sequenzdiagramm :



Diese Oauth2-Implementierung ist keine Referenz, es kann viele Optionen geben. Das Wichtigste im Diagramm ist, dass dieses Diagramm keine Datenströme enthält, sondern nur Anrufe und Antworten auf Anrufe. Dies hat uns jedoch nicht davon abgehalten, die Flows mit Text auf den Pfeilen anzugeben.

Wenn Sie in die Studie des Sequenzdiagramm zu vertiefen, werden Sie feststellen , dass es Ihnen ermöglicht, Anzeige Schleifen und Verzweigungen, aber missbrauchen sie nicht: Sie müssen nicht die Zweige ziehen müssen „Wenn der Benutzer lokale Zulassung entschieden“ und „Wenn Sie FB Zulassung entschieden“ statt, Zeichnen Sie zwei Schemata für jede Option. Bedingungen, insbesondere verschachtelte, im Sequenzdiagramm verringern die Lesbarkeit der Schaltung erheblich.

Das letzte Diagramm (nicht heute, aber im Allgemeinen) ist das Klassendiagramm . Ihr Name spricht, es wurde angenommen, dass mit Hilfe ihrer Klassen entworfen werden würde. In den alten Tagen der DOS-Texteditoren mag dies gerechtfertigt gewesen sein, aber in modernen Entwicklungsumgebungen können Sie Klassen entwerfen und analysieren, ohne ihre dunklen und hellen Themen zu belassen.

Die praktische Anwendung von Klassendiagrammen bleibt jedoch bestehen - Datenbankdesign:



Wenn Sie wissen, was relationale Datenbanken sind, ist dies mehr als offensichtlich. Attribute im Diagramm werden nicht vollständig signiert. Es werden nur Beziehungen, Datentypen und manchmal Einschränkungen angezeigt.

Versuchen Sie nicht, es in Visio, Enterprise Architect oder einem gleichwertigen Format zu zeichnen. Für das Datenbankdesign gibt es viele spezielle Tools, die auf bestimmte DBMS zugeschnitten sind. Verwenden Sie diese.

Das ist alles. Von allen Diagrammen in UML und Archimate sind in der Praxis mehr als genug aufgeführt. Wie viele Diagramme jedes Typs werden für ein Projekt benötigt? Soll ich sie für jeden Prozess und jedes Subsystem zeichnen? Die Hauptregel ist, dass das Diagramm der Textbeschreibung beiliegt. Es wird nur benötigt, wenn der Text nicht ausreicht, d. H. wo das Team dich nicht versteht.

Vielen Dank für Ihre Aufmerksamkeit, es gab eine Softwareproduktfirma bei Ihnen.

More articles:


All Articles