Ave Coder!
Sie haben eine coole Produktidee, möchten sich aber nicht im Code festsetzen und aufgrund kleiner Details das ganze Bild verlieren? Wollen Sie sich hinsetzen, um einen Unternehmensserver zu grunzen, und Sie müssen etwas Cooles und IT füllen?
Diese Artikelserie widmet sich nützlichen, aber manchmal schwer fassbaren Kenntnissen über junges Wachstum - UML-Diagramme. Und ich beginne mit einem Überblick über vorhandene Diagramme. Lassen Sie uns ein wenig über die Geschichte sprechen und warum es so viele Diagramme geben sollte.
UML ist die Abkürzung für Unified Modeling Language und bekanntlich eine standardisierte Modellierungssprache, die aus einem integrierten Satz von Diagrammen besteht, die System- und Softwareentwicklern helfen sollen, Artefakte von Softwaresystemen zu identifizieren, zu visualisieren, zu konstruieren und zu dokumentieren Zum Beispiel für die Geschäftsmodellierung.
UML ist eine Reihe von Best-Engineering-Praktiken, die sich bei der Modellierung großer und komplexer Systeme als effektiv erwiesen haben und ein sehr wichtiger Bestandteil bei der Entwicklung objektorientierter Software sind.
UML verwendet hauptsächlich grafische Notation, um das Design von Softwareprojekten auszudrücken. Mithilfe der UML können Designteams kommunizieren, potenzielle Projekte untersuchen und das Architekturdesign von Software validieren.
Der Ursprung der UML
Das Ziel von UML ist es, eine Standardnotation bereitzustellen, die von allen objektorientierten Methoden verwendet werden kann, sowie die besten Elemente der Vorgängernotationen auszuwählen und zu integrieren. Die UML wurde für eine Vielzahl von Anwendungen entwickelt. Folglich bietet es Entwürfe für eine breite Palette von Systemen und Aktivitäten (z. B. verteilte Systeme, Analyse, Systemdesign und -bereitstellung).
Die UML ist nicht von Grund auf neu entstanden, sondern es gingen mehrere wichtige Ereignisse, Persönlichkeiten und Methoden voraus. Beispielsweise:
- OMT [James Rumbaugh 1991], .
- Booch [Grady Booch 1994] — . - . , , , , .
- OOSE (- [Ivar Jacobson 1992]) — , — , , .
1994 verblüffte Jim Rambeau, nicht zu verwechseln mit John Rambo, obwohl Jim auch cool war, weil er für eine Sekunde der Schöpfer der oben genannten Objektmodellierungstechnik war, die Software-Welt, als er General Electric verließ und zu Grady Booch bei Rational Corp. kam. Das Ziel der Partnerschaft war es, ihre Ideen in einer einzigen einheitlichen Methode zu kombinieren (der Arbeitsname für die Methode war in der Tat "einheitliche Methode").
Bis 1995 hatte sich auch der Schöpfer von OOSE, Ivar Jacobson, Rational angeschlossen, und seine Ideen (insbesondere das Konzept der "Anwendungsfälle") wurden in eine neue einheitliche Methode integriert, die jetzt als einheitliche Modellierungssprache bezeichnet wird.
Im Gegensatz zur bekannten Viererbande sind Team Rumbo, Buch und Jacobson als die drei Amigos bekannt.
UML wurde auch von anderen objektorientierten Notationen beeinflusst:
- Mellor und Schlaer [1998]
- Coad und Yourdon [1995]
- Wirfs-Brock [1990]
- Martin und Odell [1992]
Die UML enthält auch neue Konzepte, die zu diesem Zeitpunkt in anderen gängigen Methoden nicht gefunden wurden, wie z. B. Erweiterungsmechanismen und die Einschränkungssprache.
Warum UML?
Da der strategische Wert von Software für viele Unternehmen zunahm, suchte die Branche nach Methoden zur Automatisierung der Softwareproduktion sowie zur Verbesserung der Qualität und zur Reduzierung von Kosten und Markteinführungszeiten.
Diese Techniken umfassen Komponententechnologie, visuelle Programmierung, Vorlagen und Strukturen.
Unternehmen suchen auch nach Methoden, um die Komplexität von Systemen bei ihrer Skalierung zu verwalten.
Insbesondere erkennen sie die Notwendigkeit, sich wiederholende Architekturprobleme wie physische Verteilung, Parallelität, Replikation, Sicherheit, Lastausgleich und Fehlertoleranz zu lösen.
Darüber hinaus verschärft die Webentwicklung zwar die Dinge, verschärft diese Architekturprobleme jedoch im Allgemeinen.
Die Unified Modeling Language (UML) wurde entwickelt, um diese Anforderungen zu erfüllen.
Die Hauptziele des UML-Designs sind:
- Stellen Sie Benutzern eine vorgefertigte, ausdrucksstarke visuelle Modellierungssprache zur Verfügung, damit sie aussagekräftige Modelle entwickeln und austauschen können.
- Bereitstellung von Erweiterungs- und Spezialisierungsmechanismen zur Erweiterung der Kernkonzepte.
- Seien Sie unabhängig von bestimmten Programmiersprachen und Entwicklungsprozessen.
- Bereitstellung eines formalen Rahmens für das Verständnis der Modellierungssprache.
- Förderung des Marktwachstums für objektorientierte Werkzeuge.
- Unterstützung für übergeordnete Entwicklungskonzepte wie Zusammenarbeit, Strukturen, Vorlagen und Komponenten.
- Best Practices integrieren.
UML-Diagramme werden in zwei Typen unterteilt - Strukturdiagramme und Verhaltensdiagramme.
Strukturdiagramme zeigen die statische Struktur des Systems und seiner Teile auf verschiedenen Abstraktions- und Implementierungsebenen sowie deren Beziehung. Elemente in einem Strukturdiagramm stellen aussagekräftige Konzepte des Systems dar und können abstrakte, reale und Implementierungskonzepte umfassen. Es gibt sieben Arten von Strukturdiagrammen:
- Zusammengesetztes Strukturdiagramm
- Bereitstellungsdiagramm
- Paketdiagramm
- Profildiagramm
- Klassen Diagramm
- Objektdiagramm
- Komponentendiagramm
Verhaltensdiagramme zeigen das dynamische Verhalten von Objekten im System, das als eine Reihe von Änderungen im System im Laufe der Zeit beschrieben werden kann. Verhaltensdiagramme umfassen:
- Aktivitätsdiagramm
- Anwendungsfalldiagramm
- Zustandsdiagramm
- Sequenzdiagramm
- Kommunikationsdiagramm
- Interaktionsübersichtstabelle
- Zeitdiagramm
Nun ein paar Worte zu jedem von ihnen
Klassen Diagramm
Das Klassendiagramm ist eine zentrale Modellierungstechnik, die in fast allen objektorientierten Methoden verwendet wird. Dieses Diagramm beschreibt die Objekttypen im System und die verschiedenen Arten statischer Beziehungen, die zwischen ihnen bestehen.
Die drei wichtigsten Arten von Beziehungen in Klassendiagrammen (es gibt tatsächlich mehr davon) sind:
Zuordnung, die die Beziehung zwischen Instanzen der Arten darstellt, z. B. eine Person arbeitet für ein Unternehmen, ein Unternehmen hat mehrere Büros.
Vererbung, die in direktem Zusammenhang mit der Vererbung in einem objektorientierten Entwurf steht.
Aggregation, eine Form der Komposition von Objekten in einem objektorientierten Design.
Komponentendiagramm
In der einheitlichen Modellierungssprache zeigt ein Komponentendiagramm, wie Komponenten zu größeren Komponenten oder Softwaresystemen miteinander verbunden werden.
Es zeigt die Architektur von Softwarekomponenten und die Abhängigkeiten zwischen ihnen.
Diese Softwarekomponenten umfassen Laufzeitkomponenten, ausführbare Komponenten und Quellcodekomponenten.
Bereitstellungsdiagramm
Ein Bereitstellungsdiagramm hilft bei der Simulation des physischen Aspekts eines objektorientierten Softwaresystems. Dies ist ein Blockdiagramm, das die Architektur des Systems als Bereitstellung (Verteilung) von Software-Artefakten zeigt.
Artefakte sind spezifische Elemente in der physischen Welt, die das Ergebnis eines Entwicklungsprozesses sind.
Das Diagramm modelliert die Laufzeitkonfiguration in einer statischen Ansicht und visualisiert die Verteilung von Artefakten in der Anwendung.
In den meisten Fällen werden dabei Hardwarekonfigurationen zusammen mit den Softwarekomponenten simuliert, auf denen sie gehostet werden.
Objektdiagramm
Ein statisches Objektdiagramm ist eine Instanz eines Klassendiagramms. Es zeigt eine Momentaufnahme des detaillierten Status des Systems zu einem bestimmten Zeitpunkt. Der Unterschied besteht darin, dass das Klassendiagramm ein abstraktes Modell ist, das aus Klassen und ihren Beziehungen besteht.
Ein Objektdiagramm ist jedoch eine Instanz zu einem bestimmten Zeitpunkt, die spezifischer Natur ist. Die Verwendung von Objektdiagrammen ist eher begrenzt, nämlich um Beispiele für Datenstrukturen zu zeigen.
Paketdiagramm
Ein Paketdiagramm ist ein UML-Strukturdiagramm, das Pakete und die Abhängigkeiten zwischen ihnen zeigt.
Sie können damit verschiedene Systemtypen anzeigen, z. B. ist es einfach, eine mehrstufige Anwendung zu simulieren.
Zusammengesetztes Strukturdiagramm
Das zusammengesetzte Strukturdiagramm ähnelt dem Klassendiagramm und ist eine Art Komponentendiagramm, das hauptsächlich bei der Modellierung von Systemen auf Mikroebene verwendet wird, zeigt jedoch einzelne Teile anstelle ganzer Klassen. Es ist eine Art statisches Strukturdiagramm, das die interne Struktur einer Klasse und die Interaktionen zeigt, die diese Struktur ermöglicht.
Dieses Diagramm kann Interna, Ports, über die Teile miteinander kommunizieren oder über die Klasseninstanzen mit Teilen und mit der Außenwelt interagieren, sowie Konnektoren zwischen Teilen oder Ports enthalten. Eine zusammengesetzte Struktur besteht aus einer Reihe miteinander verbundener Elemente, die zur Laufzeit interagieren, um ein Ziel zu erreichen. Jedes Element hat eine bestimmte Rolle in der Zusammenarbeit.
Profildiagramm
Das Profildiagramm ermöglicht es uns, domänen- und plattformspezifische Stereotypen zu erstellen und Beziehungen zwischen ihnen zu definieren. Wir können Stereotypen erstellen, indem wir Formen von Stereotypen zeichnen und sie über eine ressourcenorientierte Schnittstelle mit Komposition oder Generalisierung verknüpfen. Wir können auch die Bedeutung von Stereotypen definieren und visualisieren.
Anwendungsfalldiagramm
Das Anwendungsfalldiagramm beschreibt die funktionalen Anforderungen des Systems in Bezug auf Anwendungsfälle. Im Wesentlichen ist dies ein Modell der vermeintlichen Funktionalität des Systems (Präzedenzfälle) und seiner Umgebung (Akteure).
Mithilfe von Anwendungsfällen können wir verknüpfen, was wir vom System benötigen, und wie das System diese Anforderungen erfüllt.
Aktivitätsdiagramm
Aktivitätsdiagramme sind grafische Darstellungen von schrittweisen und schrittweisen Workflows mit Unterstützung für Auswahl, Iteration und Parallelität.
Sie beschreiben den Kontrollfluss des Zielsystems, z. B. die Untersuchung komplexer Geschäftsregeln und -vorgänge sowie die Beschreibung von Anwendungsfällen und Geschäftsprozessen.
In UML werden Aktivitätsdiagramme entwickelt, um sowohl rechnerische als auch organisatorische Prozesse zu simulieren.
Zustandsdiagramm
Ein Zustandsdiagramm ist ein Diagrammtyp, der in UML zur Beschreibung des Verhaltens von Systemen verwendet wird und auf David Harels Konzept von Zustandsdiagrammen basiert. Zustandsdiagramme zeigen die aktivierten Zustände und Übergänge sowie die Ereignisse, die diese Übergänge beeinflussen. Es hilft Ihnen, den gesamten Lebenszyklus von Objekten zu visualisieren und somit zustandsbasierte Systeme besser zu verstehen.
Sequenzdiagramm
Ein Sequenzdiagramm modelliert die Interaktion von Objekten basierend auf einer Zeitsequenz. Es zeigt, wie einige Objekte in einem bestimmten Anwendungsfall mit anderen interagieren.
Kommunikationsdiagramm
Wie ein Sequenzdiagramm wird auch ein Kommunikationsdiagramm verwendet, um das dynamische Verhalten eines Anwendungsfalls zu modellieren. Im Vergleich zum Sequenzdiagramm konzentriert sich das Kommunikationsdiagramm eher auf die Darstellung der Interaktion von Objekten als auf die zeitliche Abfolge. Tatsächlich sind ein Kommunikationsdiagramm und ein Sequenzdiagramm semantisch äquivalent und können ineinander fließen.
Interaktionsübersichtstabelle
Das Interaktionsübersichtsdiagramm konzentriert sich auf einen Überblick über den Ablauf des Interaktionsmanagements. Dies ist eine Variante des Aktivitätsdiagramms, bei der die Knoten Interaktionen oder Interaktionsereignisse sind. Das Interaktionsübersichtsdiagramm beschreibt die Interaktionen, in denen Nachrichten und Lebenslinien versteckt sind. Wir können die „echten“ Diagramme verknüpfen und ein hohes Maß an Navigation zwischen den Diagrammen innerhalb des Interaktionsübersichtsdiagramms erreichen.
Zeitdiagramm
Das Zeitdiagramm zeigt das Verhalten der Objekte in einem bestimmten Zeitraum. Tatsächlich ist dies eine spezielle Form eines Sequenzdiagramms, und die Unterschiede zwischen ihnen bestehen darin, dass die Achsen so vertauscht werden, dass die Zeit von links nach rechts zunimmt, und die Lebenslinien in separaten, vertikal angeordneten Fächern angezeigt werden.
Warum gibt es in der UML so viele Diagramme?
Der Grund dafür ist, dass Sie das System aus verschiedenen Blickwinkeln betrachten können, da viele interessierte Parteien an der Softwareentwicklung teilnehmen werden, z. B. Analysten, Designer, Programmierer, Tester, Qualitätskontrolle, Kunden, technische Autoren.
Alle diese Personen interessieren sich für verschiedene Aspekte des Systems, und jeder von ihnen erfordert einen unterschiedlichen Detaillierungsgrad.
Beispielsweise muss der Encoder das Design des Systems verstehen und in der Lage sein, das Design in Code auf niedriger Ebene umzuwandeln.
Im Gegensatz dazu interessiert sich ein technischer Redakteur für das Verhalten des gesamten Systems und muss verstehen, wie das Produkt funktioniert.
Die UML versucht, eine Sprache so ausdrucksstark bereitzustellen, dass alle Beteiligten von mindestens einem UML-Diagramm profitieren können.
Für diejenigen, die zu faul sind, um zu lesen:
Ave!