Vereinigte modellierende Sprache

Unified Modeling Language (UML) ist eine standardisierte modellierende Mehrzwecksprache im Feld der objektorientierten Softwaretechnik. Der Standard wird geführt, und wurde von Object Management Group geschaffen. Es wurde zuerst zur Liste von OMG hinzugefügt hat Technologien 1997 angenommen, und ist der Industriestandard seitdem geworden, um softwareintensive Systeme zu modellieren.

UML schließt eine Reihe von grafischen Notationstechniken ein, um Sehmodelle von objektorientierten softwareintensiven Systemen zu schaffen.

Übersicht

Unified Modeling Language (UML) wird verwendet, um die Kunsterzeugnisse eines objektorientierten softwareintensiven Systems unter der Entwicklung anzugeben, sich zu vergegenwärtigen, zu modifizieren, zu bauen und zu dokumentieren. UML bietet eine Standardweise an, sich architektonische Entwürfe eines Systems einschließlich Elemente zu vergegenwärtigen, wie:

  • Tätigkeiten
  • Schauspieler
  • Geschäftsprozesse
  • Datenbankdiagramme
  • (logische) Bestandteile
  • Programmiersprache-Behauptungen
  • Mehrwegsoftwarebestandteile.

UML verbindet Techniken vom Datenmodellieren (Entitätsbeziehungsdiagramme), das Geschäftsmodellieren (Arbeitsflüsse), Gegenstand-Modellieren und Teilmodellieren. Es kann mit allen Prozessen, überall im Softwareentwicklungslebenszyklus, und über verschiedene Durchführungstechnologien verwendet werden. UML hat die Notationen der Methode von Booch, der Gegenstand modellierenden Technik (OMT) und Objektorientierten Softwaretechnik (OOSE) durch das Schmelzen von ihnen in eine einzelne, allgemeine und weit verwendbare modellierende Sprache synthetisiert. UML hat zum Ziel, eine modellierende Standardsprache zu sein, die gleichzeitige und verteilte Systeme modellieren kann. UML ist ein De-Facto-Industriestandard, und entwickelt sich unter der Schirmherrschaft von Object Management Group (OMG).

UML Modelle können in andere Darstellungen (z.B Java) mittels QVT ähnlicher Transformationssprachen automatisch umgestaltet werden. UML ist mit zwei Mechanismen für die Anpassung ausziehbar: Profile und Stereotypien.

Geschichte

Vor UML 1.x

Nachdem Rational Software Corporation James Rumbaugh von General Electric 1994 angestellt hat, ist die Gesellschaft die Quelle für die zwei populärsten objektorientierten modellierenden Annäherungen des Tages geworden: Die Gegenstand modellierende Technik (OMT) von Rumbaugh, die für die objektorientierte Analyse (OOA) und die Methode von Booch von Grady Booch besser war, die für das objektorientierte Design (OOD) besser war. Ihnen wurde bald bei ihren Anstrengungen von Ivar Jacobson, dem Schöpfer der Methode der objektorientierten Softwaretechnik (OOSE) geholfen. Jacobson hat sich Vernünftig 1995 angeschlossen, nachdem seine Gesellschaft, Objectory AB, durch den Vernünftigen erworben wurde. Die drei methodologists sind insgesamt die Drei Freunde genannt geworden.

1996, Vernünftig hat beschlossen, dass der Überfluss am Modellieren von Sprachen die Adoption der Gegenstand-Technologie verlangsamte, so Umpositionierung die Arbeit an einer vereinigten Methode, sie haben die Drei Freunde mit der Entwicklung einer modellierenden Vereinigten Nichteigentumssprache stark beansprucht. Vertreter von konkurrierenden Gegenstand-Technologiegesellschaften wurden während OOPSLA '96 befragt; sie haben Kästen gewählt, um Klassen aber nicht die Wolkensymbole zu vertreten, die in der Notation von Booch verwendet wurden.

Unter der technischen Führung der Drei Freunde hat ein internationales Konsortium gerufen die UML-Partner wurde 1996 organisiert, um die Spezifizierung von Unified Modeling Language (UML) zu vollenden, und es als eine Antwort auf den OMG RFP vorzuschlagen. Der UML der UML Partner 1.0 Spezifizierungsentwurf wurde dem OMG im Januar 1997 vorgeschlagen. Während desselben Monats haben die UML-Partner eine Semantik-Einsatzgruppe gebildet, die von Cris Kobryn den Vorsitz geführt ist, und haben durch Ed Eykholt als Verwalter fungiert, um die Semantik der Spezifizierung zu beenden und es mit anderen Standardisierungsanstrengungen zu integrieren. Das Ergebnis dieser Arbeit, UML 1.1, wurde dem OMG im August 1997 vorgelegt und durch den OMG im November 1997 angenommen.

UML 1.x

Als eine Modellieren-Notation herrscht der Einfluss der OMT Notation (zum Beispiel, mit Rechtecken für Klassen und Gegenstände) vor. Obwohl die "Wolken"-Notation von Booch, die Fähigkeit von Booch fallen gelassen war anzugeben, dass Designdetail der niedrigeren Ebene umarmt wurde. Die Gebrauch-Fall-Notation von Objectory und die Teilnotation von Booch wurden mit dem Rest der Notation integriert, aber die semantische Integration war in UML 1.1 relativ schwach, und wurde bis zum UML 2.0 Hauptrevision nicht wirklich befestigt.

Konzepte von vielen anderen OO Methoden wurden auch mit UML mit der Absicht lose integriert, dass UML alle OO Methoden unterstützen würde. Viele andere haben auch, mit ihrer Annäherungswürze die vielen Modelle des Tages beigetragen, einschließlich: Tony Wasserman und Peter Pircher mit der Notation "von Object-Oriented Structured Design (OOSD)" (nicht eine Methode), das "Systemdesign von Ray Buhr mit Ada", der Gebrauch-Fall von Archie Bowen und Timing-Analyse, die Datenanalyse von Paul Ward und "der Statecharts" von David Harel; weil die Gruppe versucht hat, breiten Einschluss im Echtzeitsystemgebiet zu sichern. Infolgedessen ist UML in einer Vielfalt von Technikproblemen, vom einzelnen Prozess, den einzelnen Benutzeranwendungen auf gleichzeitige, verteilte Systeme nützlich, UML reich sondern auch groß machend.

Die Vereinigte modellierende Sprache ist ein internationaler Standard:

:ISO/IEC 19501:2005 Informationstechnologie - Offene Verteilte Verarbeitung - Version 1.4.2 von Unified Modeling Language (UML)

UML 2.x

UML ist bedeutsam seit UML 1.1 reif geworden. Mehrere geringe Revisionen (UML 1.3, 1.4, und 1.5) haben Mängel und Programmfehler mit der ersten Version von UML befestigt, der vom UML 2.0 Hauptrevision gefolgt ist, die durch den OMG 2005 angenommen wurde.

Obwohl UML 2.1 als eine formelle Spezifizierung nie veröffentlicht wurde, sind Versionen 2.1.1 und 2.1.2 2007, gefolgt von UML 2.2 im Februar 2009 geschienen. UML 2.3 wurde im Mai 2010 formell veröffentlicht. UML 2.4.1 wurde im August 2011 formell veröffentlicht.

Es gibt vier Teile zum UML 2.x Spezifizierung:

  1. Der Oberbau, der die Notation und Semantik für Diagramme und ihre Musterelemente definiert
  2. Die Infrastruktur, die den Kern metamodel definiert, auf dem der Oberbau basiert
  3. Object Constraint Language (OCL), um Regeln für Musterelemente zu definieren
  4. Der UML Diagramm-Austausch, der definiert, wie UML 2 Diagramm-Lay-Outs ausgetauscht werden

Die jetzigen Versionen dieser Standards folgen: UML Oberbau-Version 2.4.1, UML Infrastruktur-Version 2.4.1, OCL Version 2.3.1 und UML Diagramm-Austausch-Version 1.0.

Obwohl viele UML Werkzeuge einige der neuen Eigenschaften von UML 2.x unterstützen, stellt der OMG kein Testgefolge zur Verfügung, um Gehorsam seiner Spezifizierungen objektiv zu prüfen.

Themen

Softwareentwicklungsmethoden

UML ist nicht eine Entwicklungsmethode allein; jedoch wurde es entworfen, um mit den objektorientierten Hauptsoftwareentwicklungsmethoden seiner Zeit (zum Beispiel OMT, Methode von Booch, Objectory) vereinbar zu sein. Seitdem sich UML entwickelt hat, sind einige dieser Methoden umgearbeitet worden, um die neuen Notationen (zum Beispiel OMT) auszunutzen, und neue Methoden sind gestützt auf UML wie IBM Rational Unified Process (RUP) geschaffen worden. Andere schließen Abstraktionsmethode und Dynamische Systementwicklungsmethode ein.

Das Modellieren

Es ist wichtig, zwischen dem UML Modell und dem Satz von Diagrammen eines Systems zu unterscheiden. Ein Diagramm ist eine teilweise grafische Darstellung eines Modells eines Systems. Das Modell enthält auch Dokumentation, die die Musterelemente und Diagramme (wie schriftliche Gebrauch-Fälle) steuert.

UML Diagramme vertreten zwei verschiedene Ansichten von einem Systemmodell:

  • Statisch (oder strukturell) Ansicht: Betont die statische Struktur des Systems mit Gegenständen, Attributen, Operationen und Beziehungen. Die Strukturansicht schließt Klassendiagramme und zerlegbare Struktur-Diagramme ein.
  • Dynamisch (oder Verhaltens-) Ansicht: Betont das dynamische Verhalten des Systems durch die Vertretung von Kollaborationen unter Gegenständen und Änderungen zu den inneren Staaten von Gegenständen. Diese Ansicht schließt Folge-Diagramme, Tätigkeitsdiagramme und Zustandmaschinendiagramme ein.

UML Modelle können unter UML Werkzeugen durch das Verwenden des XMI-Austausch-Formats ausgetauscht werden.

Diagramm-Übersicht

UML 2.2 hat 14 Typen von in zwei Kategorien geteilten Diagrammen. Sieben Diagramm-Typen vertreten Strukturinformation, und die anderen sieben vertreten allgemeine Typen des Verhaltens, einschließlich vier, die verschiedene Aspekte von Wechselwirkungen vertreten. Diese Diagramme, können hierarchisch wie gezeigt, im folgenden Klassendiagramm kategorisiert werden:

UML schränkt UML Element-Typen auf einen bestimmten Diagramm-Typ nicht ein. Im Allgemeinen kann jedes UML Element auf fast allen Typen von Diagrammen erscheinen; diese Flexibilität ist in UML 2.0 teilweise eingeschränkt worden. UML Profile können zusätzliche Diagramm-Typen definieren oder vorhandene Diagramme mit zusätzlichen Notationen erweitern.

In Übereinstimmung mit der Tradition von Technikzeichnungen, einer Anmerkung oder Zeichen-Erklären-Gebrauch, Einschränkung oder Absicht wird in einem UML Diagramm erlaubt.

Struktur-Diagramme

Struktur-Diagramme betonen die Dinge, die im System da sein müssen, das wird modelliert. Da Struktur-Diagramme die Struktur vertreten, werden sie umfassend im Dokumentieren der Softwarearchitektur von Softwaresystemen verwendet.

  • Klassendiagramm: Beschreibt die Struktur eines Systems durch die Vertretung der Klassen des Systems, ihrer Attribute und der Beziehungen unter den Klassen.
  • Teildiagramm: Beschreibt, wie ein Softwaresystem in Bestandteile aufgeteilt wird und die Abhängigkeiten unter diesen Bestandteilen zeigt.
  • Zerlegbares Struktur-Diagramm: Beschreibt die innere Struktur einer Klasse und der Kollaborationen, die diese Struktur möglich macht.
  • Aufstellungsdiagramm: Beschreibt die Hardware, die in Systemdurchführungen und den Ausführungsumgebungen und auf der Hardware aufmarschierten Kunsterzeugnissen verwendet ist.
  • Gegenstand-Diagramm: Zeigt, dass eine ganze oder teilweise Ansicht von der Struktur eines Beispiels System in einer spezifischen Zeit modelliert hat.
  • Paket-Diagramm: Beschreibt, wie ein System in logische Gruppierungen durch die Vertretung der Abhängigkeiten unter diesen Gruppierungen aufgeteilt wird.
  • Profil-Diagramm: Funktioniert am metamodel Niveau, um Stereotypien als Klassen mit zu zeigen

File:BankAccount.png|Class Diagramm

File:Component-4.png|Component Diagramm

File:Composite Struktur-Struktur-Diagramm des Diagramms png|Composite

File:UML Diagramm Deploiement.gif|Deployment Diagramm

File:Instance Diagramm der Spezifizierung 3.png|Object

File:Package import-1.png|Package Diagramm

</Galerie> </Zentrum>

Verhaltensdiagramme

Verhaltensdiagramme betonen, was im System geschehen muss, das wird modelliert. Da Verhaltensdiagramme das Verhalten eines Systems illustrieren, werden sie umfassend verwendet, um die Funktionalität von Softwaresystemen zu beschreiben.

  • Tätigkeitsdiagramm: Beschreibt das Geschäft und die betrieblichen schrittweisen Arbeitsabläufe von Bestandteilen in einem System. Ein Tätigkeitsdiagramm zeigt den gesamten Fluss der Kontrolle.
  • Maschinendiagramm des Staates UML: Beschreibt die Staaten und Zustandübergänge des Systems.
  • Gebrauch-Fall-Diagramm: Beschreibt die Funktionalität, die durch ein System in Bezug auf Schauspieler, ihre Absichten zur Verfügung gestellt ist, vertreten als Gebrauch-Fälle und irgendwelche Abhängigkeiten unter jenen Gebrauch-Fällen.

Image:Activity Tätigkeitsdiagramm des Diagramms 1.jpg|UML

Image:UML setzen Diagramm png|State Maschinendiagramm fest

Image:UML_Use_Case_diagram.svg|Use Fall-Diagramm

</Galerie> </Zentrum>

Wechselwirkungsdiagramme

Wechselwirkungsdiagramme, eine Teilmenge von Verhaltensdiagrammen, betonen den Fluss der Kontrolle und Daten unter den Dingen im System, das wird modelliert:

  • Nachrichtendiagramm: Zeigt die Wechselwirkungen zwischen Gegenständen oder Teilen in Bezug auf sequenced Nachrichten. Sie vertreten eine Kombination der Information, die von der Klasse, der Folge und den Gebrauch-Fall-Diagrammen genommen ist, die sowohl die statische Struktur als auch das dynamische Verhalten eines Systems beschreiben.
  • Wechselwirkungsübersicht-Diagramm: Stellt eine Übersicht zur Verfügung, in der die Knoten Nachrichtendiagramme vertreten.
  • Folge-Diagramm: Shows, wie Gegenstände mit einander in Bezug auf eine Folge von Nachrichten kommunizieren. Auch zeigt die Lebensspanne von Gegenständen hinsichtlich jener Nachrichten an.
  • Timing von Diagrammen: Ein spezifischer Typ des Wechselwirkungsdiagramms, wo der Fokus auf dem Timing von Einschränkungen ist.

Diagramm von Image:Kommunikations diagramm-2.png|Communication

Image:Iau-Diagramm-1.png|Interaction-Übersicht-Diagramm

Diagramm von Image:Sequenz diagramm-1.png|Sequence

</Galerie> </Zentrum>

Die Protokoll-Staatsmaschine ist eine Subvariante der Staatsmaschine. Es kann an Musternetznachrichtenprotokolle gewöhnt sein.

Meta, die modelliert

Object Management Group (OMG) hat eine metamodeling Architektur entwickelt, um Unified Modeling Language (UML), genannt Meta-Object Facility (MOF) zu definieren. Die Meta-Gegenstand-Möglichkeit ist ein Standard für die mustergesteuerte Technik, entworfen als eine vier-layered Architektur, wie gezeigt, im Image am Recht. Es stellt ein meta-meta Modell an der Spitzenschicht, genannt die M3 Schicht zur Verfügung. Dieses M3-Modell ist die durch die Meta-Gegenstand-Möglichkeit verwendete Sprache, metamodels, genannt M2-Modelle zu bauen. Das prominenteste Beispiel einer Schicht 2 Meta-Gegenstand-Möglichkeitsmodell ist der UML metamodel, das Modell, das den UML selbst beschreibt. Diese M2-Modelle beschreiben Elemente der M1-Schicht, und so M1-Modelle. Das, würden zum Beispiel, in UML geschriebene Modelle sein. Die letzte Schicht ist die M0-Schicht oder Datenschicht. Es wird verwendet, um Laufzeitbeispiel des Systems zu beschreiben.

Außer dem M3-Modell beschreibt die Meta-Gegenstand-Möglichkeit die Mittel, Modelle und metamodels durch das Definieren von CORBA Schnittstellen zu schaffen und zu manipulieren, die jene Operationen beschreiben. Wegen der Ähnlichkeiten zwischen dem Meta-Gegenstand-MöglichkeitsM0-Modell und den UML Struktur-Modellen wird Meta-Gegenstand-Möglichkeit metamodels gewöhnlich als UML Klassendiagramme modelliert. Ein Unterstützen-Standard der Meta-Gegenstand-Möglichkeit ist XMI, der ein XML-basiertes Austauschformat für Modelle auf dem m3-, m2-, oder M1-Schicht definiert.

Kritiken

Obwohl UML ein weit anerkannter und verwendeter Modellieren-Standard ist, wird er oft für den folgenden kritisiert:

Standards bloat: Bertrand Meyer, in einem satirischen Aufsatz hat sich als eine Bitte eines Studenten um eine Rang-Änderung, anscheinend kritisierten UML bezüglich 1997 entwickelt, um zur objektorientierten Softwareentwicklung ohne Beziehung zu sein; eine Verzichterklärung wurde später hinzugefügt darauf hinweisend, dass seine Gesellschaft dennoch UML unterstützt. Ivar Jacobson, ein Co-Architekt von UML, hat gesagt, dass Einwände gegen UML 2.0's Größe gültig genug waren, um die Anwendung intelligenter Agenten zum Problem zu denken. Es enthält viele Diagramme und Konstruktionen, die überflüssig oder selten verwendet sind.

Probleme im Lernen und Übernehmen: Die in dieser Abteilung zitierten Probleme machen das Lernen und Übernehmen UML problematisch besonders nach Bedarf Ingenieure, die an den erforderlichen Sachkenntnissen Mangel haben. In der Praxis ziehen Leute häufig Diagramme mit den durch ihr FALL-Werkzeug zur Verfügung gestellten Symbolen, aber ohne die Bedeutungen sind jene Symbole beabsichtigt, um zur Verfügung zu stellen. Einfache Benutzerberichte z.B, "was ich bei der Arbeit tue...", haben sich gezeigt, um viel einfacher zu sein, zu registrieren und mehr sofort nützlich.

Sprachinkohärenz: Die Standards sind zitiert worden als, zweideutig und inkonsequent zu sein. Der UML 2.0 Standard erträgt noch viele Probleme

Fähigkeiten zu UML und Durchführungssprachfehlanpassung: Typisch für andere notational Systeme ist UML im Stande, einige Systeme kürzer oder effizient zu vertreten, als andere. So wird ein Entwickler von Lösungen angezogen, die an der Kreuzung der Fähigkeiten zu UML und der Durchführungssprache wohnen. Dieses Problem wird besonders ausgesprochen, wenn die Durchführungssprache an der orthodoxen objektorientierten Doktrin nicht klebt, seitdem die Kreuzung zwischen UML untergegangen ist und Durchführungssprache dass viel kleiner sein kann.

Dysfunctional wechseln Format aus: Während der XMI (XML Metadata Austausch) Standard entworfen wird, um den Austausch von UML Modellen zu erleichtern, ist es im praktischen Austausch von UML 2.x Modelle größtenteils unwirksam gewesen. Diese Zwischenfunktionsfähigkeitsunwirksamkeit ist mehreren Gründen zuzuschreibend. Erstens ist XMI 2.x groß und in seinem eigenen Recht kompliziert, da er vorgibt, ein technisches Problem zu richten, das ehrgeiziger ist als das Austauschen von UML 2.x Modelle. Insbesondere es versucht, einen Mechanismus zur Verfügung zu stellen, für den Austausch jeder willkürlichen modellierenden von Meta-Object Facility (MOF) des OMG definierten Sprache zu erleichtern. Zweitens hat der UML 2.x Diagramm-Austausch-Spezifizierung an genügend Detail Mangel, um zuverlässigen Austausch von UML 2.x Notationen zwischen dem Modellieren von Werkzeugen zu erleichtern. Da UML eine modellierende Sehsprache ist, ist dieser Fehler für Modellierer wesentlich, die ihre Diagramme nicht neu entwerfen wollen. Dieser Fehler wird durch die Diagramm-Definition OMG Projekt gerichtet, für das ein vorgeschlagener Standard bereits verfügbar ist.

Cardinality Notation: Als mit der Datenbank ER Diagramme werden Klassenmodelle angegeben, um zu verwenden, "schauen - über" cardinalities, wenn auch mehrere Autoren (Merise, Elmasri & Navathe unter anderen) dieselbe-Seite oder "Blick hier" für Rollen und sowohl Minimum als auch Maximum cardinalities bevorzugen. Neue Forscher (Feinerer, Dullea und. alia) haben gezeigt, dass "-über die" durch UML verwendete Technik schauen und ER Diagramme weniger wirksam und wenn angewandt, auf n-stufige Beziehungen der Ordnung> 2 weniger zusammenhängend ist.

:In-Feinerer es sagt "Probleme, entstehen, wenn wir unter dem Blick - über die Semantik, wie verwendet, für UML Vereinigungen funktionieren. Hartmann untersucht diese Situation und zeigt, wie und warum verschiedene Transformationen scheitern." (Obwohl die erwähnte "Verminderung" unecht ist, weil sind die zwei Diagramme 3.4 und 3.5 tatsächlich dasselbe), und auch, "Wie wir auf den nächsten paar Seiten sehen werden, führt der Blick - über die Interpretation mehrere Schwierigkeiten ein, die die Erweiterung von einfachen Mechanismen vom binären bis n-stufige Vereinigungen verhindern."

Exklusiv: Der Begriff "Vereinigter" wendet nur auf die Vereinigung der vielen vorherigen vorhandenen und konkurrierenden Gegenstand Orientierte Sprachen an. Wichtige weithin bekannte und populäre Techniken, die fast allgemein in der Industrie, wie Datenflussschemen und Struktur-Karten verwendet sind, wurden in die Spezifizierung nicht eingeschlossen.

Modellierende Experten haben Kritiken von UML, einschließlich Brian Henderson-Sellers und Cesar Gonzalez-Perez im "Gebrauch und den Missbräuchen des Stereotypie-Mechanismus in UML 1.x und 2.0" geschrieben.

UML das Modellieren von Werkzeugen

Der wohl bekannteste UML das Modellieren des Werkzeugs ist IBM Rational Rose. Andere Werkzeuge, schließen in alphabetischer Reihenfolge, ArgoUML, BOUML, Dia, Unternehmensarchitekten, MagicDraw UML, Modelio, PowerDesigner, Vernünftige Rhapsodie, Vernünftiger Softwarearchitekt, StarUML und Umbrello ein. Einige von populären Entwicklungsumgebungen bieten auch UML das Modellieren von Werkzeugen z.B an: Eklipse, NetBeans und Sehstudio.

Siehe auch

  • Das Wörterverzeichnis der Vereinigten modellierenden Sprache nennt
  • Das flinke Modellieren
  • Entitätsbeziehungsmodell
  • Rechtskräftiger UML
  • Grundsätzliche modellierende Konzepte
  • I-OOA
  • Liste von UML Werkzeugen
  • Anwendungen von UML
  • Das Meta-Modellieren
  • Musterbasierte Prüfung
  • Mustergesteuerte Integration
  • Softwareentwurf
  • SysML
  • UML färbt
  • UML tauschen Format aus
  • Das Modellieren von UN/CEFACT der Methodik
  • Nachrichtenfolge-Karte, ein anderer Typ von Wechselwirkungsdiagrammen
  • Gegenstand-Prozess-Methodik, eine Alternative "... zum Entwerfen von Informationssystemen durch das Zeichnen von ihnen, Gegenstand-Modelle und Prozessmodelle verwendend". Und, diese in einer vereinigter Ansicht präsentierend.

Weiterführende Literatur

Außenverbindungen


Ulfilas / UML
Impressum & Datenschutz