Unied Modeling Language

Die Unied Modeling Language (vereinheitlichte

Modellierungssprache), kurz UML, ist eine grasche
Modellierungssprache zur Spezikation, Konstruktion
und Dokumentation von Software-Teilen und anderen
Systemen.[2] Sie wird von der Object Management
Group (OMG) entwickelt und ist sowohl von ihr als
auch von der ISO (ISO/IEC 19505 fr Version 2.4.1[3] )
standardisiert. Im Sinne einer Sprache deniert UML
dabei Bezeichner fr die meisten bei einer Modellierung
wichtigen Begrie und legt mgliche Beziehungen
zwischen diesen Begrien fest. UML deniert weiter
grasche Notationen fr diese Begrie und fr Modelle
statischer Strukturen und dynamischer Ablufe, die man
mit diesen Begrien formulieren kann.

Zeit aufkommende objektorientierte Softwareentwicklung untersttzen sollten. Die erste Folge von Sprachversionen, auch bekannt unter dem Namen UML 1.x, wurde
2005 durch eine grundlegend berarbeitete Version, oft
als UML2 bezeichnet, abgelst.

1.1 Von den Anfngen zur Unied Modeling Language 1.x

UML ist heute die dominierende Sprache fr die

Softwaresystem-Modellierung. Der erste Kontakt zu
UML besteht hug darin, dass Diagramme in UML im
Rahmen von Softwareprojekten zu erstellen, zu verstehen
oder zu beurteilen sind:
Projektauftraggeber und Fachvertreter prfen und
besttigen zum Beispiel Anforderungen an ein System, die Wirtschaftsanalytiker bzw. Business Analysten in Anwendungsfalldiagrammen in UML festHistorie der objektorientierten Methoden und Notationen
gehalten haben;
Die Vter von UML, insbesondere Grady Booch, Ivar
Jacobson und James Rumbaugh, auch Die drei Amigos genannt, waren in den 1990er-Jahren bekannte Vertreter der objektorientierten Programmierung. Sie hatten alle bereits ihre eigenen Modellierungssprachen entwickelt. Als sie zusammen beim Unternehmen Rational
Software beschftigt waren, entstand die Idee, die verschiedenen Notationssysteme strukturiert zusammenzufhren. Eine Vielzahl von unterschiedlichen Modellierungssprachen hatte direkten oder indirekten Einuss auf
die Konzeption von UML, darunter OOSE, RDD, OMT,
OBA, OODA, SOMA, MOSES und OPEN/OML.

Softwareentwickler realisieren Arbeitsablufe,

die Wirtschaftsanalytiker bzw. Business Analysten in Zusammenarbeit mit Fachvertretern in
Aktivittsdiagrammen beschrieben haben;
Systemingenieure installieren und betreiben Softwaresysteme basierend auf einem Installationsplan,
der als Verteilungsdiagramm vorliegt.
Die grasche Notation ist jedoch nur ein Aspekt, der
durch UML geregelt wird. UML legt in erster Linie fest,
mit welchen Begrien und welchen Beziehungen zwischen diesen Begrien sogenannte Modelle speziziert
werden Diagramme in UML zeigen nur eine graphische Sicht auf Ausschnitte dieser Modelle. UML schlgt
weiter ein Format vor, in dem Modelle und Diagramme
zwischen Werkzeugen ausgetauscht werden knnen.

Als Resultat dieser Bemhungen entstand die UML.

Die Standardisierung, Pege und Weiterentwicklung der
Sprache wurde an die OMG bergeben, die die Sprache
am 19. November 1997 als Standard akzeptierte.

1.2 Entstehungsgeschichte
Modeling Language 2

Entstehungsgeschichte

der

Unied

Die erste Version von UML entstand in den 1990er Jah- Im August 1999 stie die OMG die Entwicklung von
ren als Reaktion auf zahlreiche Vorschlge fr Model- UML2 an, indem sie einen entsprechenden Request for
lierungssprachen und -Methoden, welche die zu dieser Information (RFI) publizierte.
1

2 STRUKTURIERUNG

Ein Jahr spter, im September 2000, bat die OMG ih- tionsdokument der UML. Die aktuelle Version 2.5 wurde
re Mitglieder und weitere interessierte Kreise um Vor- im Juni 2015 verentlicht.
schlge fr UML2. Gem der neu fr UML2 denierten
Architektur publizierte die OMG drei Requests for Proposals (RFP): einen UML 2.0 Infrastructure RFP, einen 2 Strukturierung
UML 2.0 Superstructure RFP und einen UML 2.0 OCL
RFP. Wer Vorschlge einreichen wollte, hatte dazu unDer Umfang der UML ist whrend der Entwicklung von
gefhr ein weiteres Jahr Zeit.
UML 1.0 bis UML 2 laufend gewachsen. Sowohl fr die
In einer ersten Runde reichten verschiedene Gruppen und Entwicklung von UML 2 als auch fr die Vermittlung, die
Einzelpersonen Entwrfe ein. Mitte 2002 lagen von die- Anwendung und nicht zuletzt fr die Lesbarkeit der UML
sen Konsortien mehrmals berarbeitete und konsolidierte 2-Spezikation ist eine Strukturierung sehr wichtig. Was
Antworten auf einzelne Request for Proposals vor. Erst in den ersten Versionen von UML in einem Dokument
im Oktober 2002 konnten dann beim Treen der zustn- speziziert werden konnte, muss deshalb fr UML 2 in
digen Arbeitsgruppe in Helsinki alle Vorschlge fr die Teilspezikationen aufgeteilt werden. In den folgenden
UML 2.0 Infrastructure und die UML 2.0 Superstructure Abschnitten wird der Aufbau von UML 2 beschrieben.
prsentiert werden. Einen Termin fr eine weitere berarbeitete Version der Vorschlge legte die Arbeitsgruppe
auf Anfang Januar 2003 fest. Die Hauptschwierigkeit be- 2.1 Teilspezikationen
stand nun darin, die unterschiedlichen Entwrfe zu einer
Spezikation zu verschmelzen. Einerseits wurde Kritik UML2 ist in drei Teilspezikationen aufgeteilt. Die UML
laut, dass sich die unterschiedlichen Philosophien in den 2.0 Infrastructure Specication legt das Fundament fr
eingereichten Vorschlgen nur schwerlich wrden berei- UML2, indem sie die am hugsten verwendeten Elenigen lassen, andererseits reichte im Januar 2003 ein neu- mente von UML2 und die Modellelemente beschreibt,
es Konsortium unter dem Namen 4M einen Vorschlag die die restlichen Modellelemente spezialisieren. In die(UML4MDA) ein, der die Dierenzen zwischen den bis- sem Dokument werden Konzepte wie die Klasse, die
herigen Spezikationen zu berbrcken versuchte.
Assoziation oder die Multiplizitt eines Attributs speziIm Mrz 2003 empfahl die zustndige Arbeitsgruppe die
Vorschlge des Konsortiums U2 fr die UML 2.0 Infrastructure und fr die UML 2.0 OCL zur Freigabe, im Mai
dann auch fr die UML 2.0 Superstructure des gleichen
Konsortiums, so dass ab Juni 2003 drei Finalization Task
Forces der OMG die Arbeit aufnehmen konnten, um die
Teilspezikationen abzuschlieen. Die Task Forces konnten ihre Arbeit jedoch nicht wie geplant bis zum April
2004 abschlieen und grndeten deshalb eine zweite Finalization Task Force, die die verbleibenden Probleme bis
zum September 2004 lsen sollte.
Im September 2004 konnten schlielich alle Finalization
Task Forces ihre Arbeit beenden. Fr die UML 2.0 OCL[4]
und die UML 2.0 Infrastructure[5] lagen damit endgltig
abgenommene Dokumente (Final Adopted Specication)
vor. Nur bei der UML 2.0 Superstructure schien sich dieser letzte Schritt noch etwas zu verzgern: im Mrz 2005
bot der OMG-Webauftritt weiterhin nur ein temporres
Dokument mit der informellen Bezeichnung UML 2.0 Superstructure FTF convenience document zum Herunterladen an.

ziert. Die UML 2.0 Superstructure Specication baut auf

dem Fundament der UML 2.0 Infrastructure Specication auf und deniert die Modellelemente von UML2,
die sich fr bestimmte Einsatzzwecke eignen. Typische
Konzepte, die in diesem Dokument speziziert werden, sind der Anwendungsfall, die Aktivitt oder der
Zustandsautomat. Schlielich speziziert das Dokument
mit dem Titel UML 2.0 Object Constraint Language die
Object Constraint Language 2.0 (OCL2).
Ein weiterer, vierter Teil beschftigt sich nicht mit dem
semantischen Modell von UML, sondern speziziert das
Layout der Diagramme. Dieses Dokument trgt den Titel
UML 2.0 Diagram Interchange und ist eine Neuerung in
UML 2.0; UML 1.x kannte kein standardisiertes Format,
mit dem das Diagramm-Layout zwischen unterschiedlichen Werkzeugen ausgetauscht werden konnte. Die semantischen Informationen in einem UML-Modell konnte
ein Werkzeug auch bisher an ein anderes Werkzeug bergeben; das Aussehen der Diagramme, das heit die Positionen und Gre einzelner Diagrammelemente, ging dabei aber verloren. Diagram Interchange (DI) soll dieses
Manko beseitigen.

Am 21. Oktober 2008 wurde die Beta 1 von UML Version 2.2 durch die OMG verentlicht, die wiederum im
Februar 2009 in der nalen Version vorlag.[6] Neu hin2.2 Metamodellierung
zugekommen ist in der Version 2.2 das Proldiagramm,
um eigendenierte Stereotyp-Sammlungen strukturieren
hnlich wie sich natrliche Sprachen in Lexika oder
zu knnen.
Grammatiken selbst beschreiben, wurde auch UML als
Im Mai 2010 wurde UML 2.3 verentlicht. Diese Versi- ein Sprachwerkzeug konzipiert, das sich mit einigen
on enthielt vor allem Bugxes am Metamodell und Schr- Sprachbestandteilen selbst erklrt.
fungen der Semantik von Modellelementen im SpezikaDie Sprachkonzepte sind dazu in vier Schichten M0 bis

2.4

Einteilung der Spracheinheiten in Schichten

3
von Daten- und Kontrollssen darstellen lsst.

M3: MOF
Class
Metametamodell
instanceOf

instanceOf

instanceOf

M2: UML

general

Generalization

Class
specic

attributes

Attribute

2.4 Einteilung der Spracheinheiten in

Schichten

Auf einer dritten Stufe sind die meisten Spracheinheiten

in mehrere Schichten (engl. Compliance Level) geglieM1: Benutzermodell
dert. Die unterste Schicht umfasst jeweils die einfachsten
Medium
DVD
name: String
und am hugsten verwendeten Modellierungselemente,
Modell
whrend hhere Schichten zunehmend komplexere Modellierungselemente einfhren. Die Spracheinheit AktiM0: Laufzeitinstanzen
vitten umfasst beispielsweise FundamentalActivities als
The Big
Lebowski
unterste Schicht und darauf aufbauend die Schicht BasiSystem
cActivities. FundamentalActivities deniert zunchst nur,
dass
Aktivitten strukturell aus hierarchisch geschachtelHierarchie der Metamodellierung
ten Gruppen von Aktionen bestehen. BasicActivities erweitert dieses Gerst um Kanten und weitere Hilfsknoten
M3 gegliedert.
zu einem Graphen, den man in UML2 dann visuell als
Mit der Meta Object Facility (MOF) werden Modellele- Aktivittsdiagramm darstellt.
mente von UML2 speziziert und dadurch zum Beispiel
mit dem Format Meta Interchange XMI austauschbar.
Diese MOF ist auf Ebene M3 und stellt eine der vier 3 Spracheinheiten
Schichten dar. Es ist die Metasprache der Metasprachen
(das Metametamodell) und beinhaltet grundlegende Ele- 3.1 Aktionen
mente (wie Pakete, Klassen, Attribute und Assoziationen). Die Metasprache UML2 (M2) ist in MOF deniert Die Spracheinheit Aktionen (engl. actions) umfasst die
und stellt die bekannten Sprachmerkmale zur Verfgung, Denition der Aktionen in UML2. Aktionen sind
ber die Konzepte von MOF hinaus auch noch Anwen- die elementaren Bausteine fr die Modellierung eines
dungsflle, Zustandsautomaten und mehr. Die in der Pra- Verhaltens. Sie knnen Eingabewerte ber sogenannte
xis erstellten UML-Modelle benden sich auf der Ebene Eingabepins entgegennehmen und Ausgabewerte an soM1. Damit werden die Objekte der M0-Schicht darge- genannten Ausgabepins produzieren.
stellt. Dies sind die konkreten Laufzeitinstanzen des SysUML2 deniert in dieser Spracheinheit mehrere Gruppen
tems.
von grundlegenden Aktionen, siehe Aktion.
Wie in UML2.0 war auch UML1.x auf der dritten von
vier Metamodellierungsebenen eingeordnet. Zu UML 1.x
besteht jedoch ein wesentlicher Unterschied: Die auf den
Ebenen M2 und M3 verwendeten ModellierungsspraGemse
Suppe kochen
Suppe
chen (also MOF und UML) teilen sich die gemeinsame
Wasser
Spracheinheit der Infrastrukturbibliothek (Infrastructure
Library). Sie wird in der UML 2.0 Infrastructure deniert
und bildet einen Kern der grundlegenden Modellierungselemente, der sowohl in der UML 2.0 Infrastructure als
Beispiel der graphischen Notation fr eine Aktion mit zwei
auch in der UML 2.0 Superstructure und in der MOF 2.0 Eingabe- und einem Ausgabepin
eingesetzt wird.
Metamodell

instanceOf

instanceOf

instanceOf
instanceOf

instanceOf

2.3

Spracheinheiten

Die UML 2.0 Superstructure ist auf einer ersten Ebene

modular in Spracheinheiten (engl. language units) aufgebaut. Eine Spracheinheit umfasst eine Menge von eng zusammenhngenden Modellierungselementen, mit denen
ein Benutzer einen ausgewhlten Aspekt eines Systems
mit einem bestimmten Formalismus modellieren kann.
Die Spracheinheit Aktivitten (engl. Activities) umfasst
zum Beispiel Elemente fr die Modellierung eines Systemverhaltens, das sich am besten mit dem Formalismus

3.2 Aktivitten
Die Aktivitt ist das zentrale Element der Spracheinheit
Aktivitten. Sie ist gleichzeitig eine Neuerung von UML2
gegenber UML 1.4. Eine Aktivitt ist ein Modell fr
ein Verhalten. Sie besteht aus Aktionen, zwischen denen
Kontroll- und Datensse existieren. Ein Aktivittsdiagramm stellt das dynamische Verhalten eines SoftwareSystems dar.
Aktivitten haben die Struktur eines Graphen. Knoten
dieses Graphen sind Aktionen sowie Punkte, an denen

3 SPRACHEINHEITEN

Spaghetti kochen
Spaghetti
[roh]

mit dem System tun soll.

ein Objektuss

Spaghetti
einfllen

eine Aktion

Spaghetti
10min kochen

Spaghetti
[al dente]

Graphisch
werden
Anwendungsflle
Anwendungsfalldiagrammen dargestellt.

in

ein Kontrolluss

Wasser kochen

ein Pin
(ein Objektknoten)

Mobilfunkbetreiber
ein Startknoten
(ein Kontrollknoten)

ein Aktivittsparameterknoten
(ein Objektknoten)

Spaghetti-Kochen modelliert als Aktivitt

SMS verschicken

die Flsse zwischen den Aktionen kontrolliert werden;

Kanten stehen fr Daten- und Kontrollsse. Das Sprachpaket Aktivitten deniert alle Typen von Knoten und
Kanten, die fr die Modellierung von Aktivitten bentigt werden.

Sender

Fotomessage
verschicken

Knoten werden in Objekt- und Kontrollknoten unterschieden, Kanten analog dazu in Objekt- und
Beispiel fr die graphische Darstellung zweier Anwendungsflle
Kontrollsse.
und eines Akteurs

Komplexere Aktivitten knnen verschachtelt und mit

Kontrollstrukturen modularisiert werden.
Aktivitten werden graphisch in Aktivittsdiagrammen 3.5
modelliert.

3.3

Allgemeines Verhalten

Die Spracheinheit Allgemeines Verhalten umfasst die allgemeinen Modellelemente fr die Spezikation des Verhaltens eines mit UML2 modellierten Systems. Hier
sind die Modellelemente zusammengefasst, die fr
die Spezikation von Aktivitten, Interaktionen oder
Zustandsautomaten bentigt werden.
Die Spracheinheit deniert die Gemeinsamkeiten jeder
Verhaltensbeschreibung und dass eine aktive Klasse ein
eigenes Verhalten haben kann. Verhalten in einem System, das mit UML2 modelliert ist, startet immer aufgrund von diskreten Ereignissen. Dieses Sprachpaket deniert, welche Arten von Ereignissen UML2 untersttzt.
Die Behandlung der Zeit wird ebenfalls weitgehend in
diesem Sprachpaket geregelt. Es deniert Metaklassen
fr die Beobachtung der Zeit (TimeObservationAction),
fr die Notation von Zeitausdrcken (TimeExpression),
fr die Denition von Zeitintervallen (TimeInterval) sowie fr das Konzept einer zeitlichen Dauer (Duration).

3.4

Anwendungsflle

Die Spracheinheit Anwendungsflle (engl. use case) stellt

Elemente fr die Modellierung von Anforderungen an
ein System zur Verfgung. Das wichtigste Element ist
der Anwendungsfall. Anwendungsflle halten fest, was
ein System tun soll. Das zweite wichtige Element ist der
Akteur. Akteure spezizieren, wer (im Sinne einer Person) oder was (im Sinne eines anderen Systems) etwas

Informationssse

Den Techniken, die UML2 fr die Spezikation des Verhaltens eines Systems anbietet, liegen przise semantische Modelle zugrunde. Das gilt insbesondere fr Verhaltensbeschreibungen mit Hilfe von Interaktionen oder
Aktivitten, die zudem darauf ausgerichtet sind, das Verhalten eines Systems sehr feingranular zu spezizieren.
Soll das Modell eines Systems nur einige grundlegende
Informationssse im System aufzeigen, eignen sich diese Techniken deshalb nur bedingt.
Die Spracheinheit Informationssse, die in UML2 neu
eingefhrt wurde, stellt Modellelemente zur Verfgung,
um diese Situation zu verbessern. Sie bietet die Modellelemente Informationseinheit und Informationsuss an,
mit denen ein Modellierer Informationssse in einem
System auf hoher Abstraktionsstufe festhalten kann.
Informationssse knnen dabei eine Vielzahl
von anderen Modellelementen von UML2 verbinden, insbesondere Klassen, Anwendungsflle,
Ausprgungsspezikationen, Akteure, Schnittstellen,
Ports und noch einige mehr.
UML2 gibt keinen Diagrammtyp fr Informationssse
vor. Die graphische Notation fr Informationssse und
Informationseinheiten kann in allen Strukturdiagrammen
vorkommen.

3.6 Interaktionen
Das Verhalten eines modellierten Systems kann in UML2
auf unterschiedliche Art und Weise speziziert werden.
Eine davon ist die Modellierung von Interaktionen. Eine
Interaktion ist die Spezikation eines Verhaltens, das am

3.7

Klassen

5
kann man zwei Ereignisauftritte identizieren: erstens das
Auftreten eines Meldungsereignisses, wenn die Meldung
vom ersten Objekt abgeschickt wird sowie zweitens eines Meldungsereignisses, wenn die Meldung beim zweiten Objekt ankommt. Weitere Ereignisse treten auf, wenn
eine Aktion oder ein anderes Verhalten im Kontext eines
Objekts beginnt oder endet. Eine Spur (trace) bezeichnet eine Folge solcher Ereignisse. Interaktionen spezizieren nun ein Verhalten als zwei Mengen von Spuren,
einer Menge gltiger und einer Menge ungltiger Spuren.
Damit ist prziser gesagt, was wir meinen, wenn wir
von Interaktionen sprechen: die Bedeutung (Semantik)
einer Interaktion ist durch Mengen von Spuren gegeben. Modelliert werden Interaktionen jedoch als Mengen von Lebenslinien, auf denen Aktionen und andere Verhaltensweisen ablaufen und zwischen denen
Nachrichten ausgetauscht werden.
Interaktionen
modelliert
man
graphisch
in
Kommunikationsdiagrammen, in Sequenzdiagrammen
oder in Zeitverlaufsdiagrammen.

3.7 Klassen
Beispiel eines Strukturdiagramms mit zwei Informationsssen

:Koch

:Herd

einschalten

Wasser kochen
ausschalten

Beispiel fr die Spezikation einer Interaktion mit Hilfe eines

Sequenzdiagramms

besten ber den Austausch von Meldungen zwischen eigenstndigen Objekten beschrieben wird. Die Spracheinheit stellt dafr die geeigneten Modellelemente zur Verfgung.

Beispiel fr ein Klassendiagramm, das Elemente aus der Spracheinheit Klassen verwendet

Die Spracheinheit Klassen umfasst den eigentlichen Kern

der Modellierungssprache. Sie deniert insbesondere,
was man in UML2 unter einer Klasse versteht und welche
Beziehungen zwischen Klassen mglich sind. In dieser
Spracheinheit sind grundlegende Prinzipien von UML2
deniert. Die Metaklasse Element ist das Wurzelelement
fr alle anderen Modellelemente. Jedes Element kann andere Elemente besitzen, auch beliebig viele Kommentare,
die wiederum andere Elemente kommentieren knnen.
Zwischen Elementen knnen Beziehungen deniert werden. Elemente knnen benannt sein und gehren in diesem Fall zu einem Namensraum. Weiter knnen gewisse Elemente einen Typ haben. Sie werden dann als typisierte Elemente bezeichnet. Einem Element kann eine
Multiplizitt mit einer unteren und einer oberen Schranke zugeordnet sein.

Wer Interaktionen modelliert, geht davon aus, dass das

modellierte System aus einem Netzwerk von Objek- Diese Spracheinheit enthlt vier Unterpakete. Das
ten besteht, die untereinander Meldungen austauschen. Unterpaket Kernel umfasst zentrale ModellierungsSchickt ein Objekt einem anderen Objekt eine Meldung, elemente, die aus der UML 2.0 Infrastructure wie-

3 SPRACHEINHEITEN

derverwendet werden. Dazu gehren die Klasse,

die Ausprgungsspezikation, der Namensraum,
das Paket, das Attribut, die Assoziation, die
Abhngigkeitsbeziehung,
der
Paketimport,
die
Paketverschmelzung und die Generalisierung. Das
zweite Unterpaket, AssociationClasses, umfasst die
Denition von Assoziationsklassen. Interfaces, das
dritte Unterpaket, stellt die Denition von Schnittstellen
bereit. Schlielich deklariert das Unterpaket PowerTypes
Modellelemente fr die sogenannten PowerTypes.
Elemente aus dieser Spracheinheit werden meistens in Klassendiagrammen, Objektdiagrammen und
Paketdiagrammen dargestellt.

3.8

Komponenten

in Komponentendiagrammen, zum Teil aber auch in

Klassendiagrammen oder Verteilungsdiagrammen dargestellt.

3.9 Kompositionsstrukturen
Die Spracheinheit Kompositionsstrukturen (engl. Structures) bereichert UML2 um einen neuen Ansatz fr die Modellierung der inneren Struktur eines zusammengesetzten
Ganzen. Das Ganze wird dabei als gekapselter Classier modelliert, fr die Teile stellt diese Spracheinheit die Parts zur Verfgung. Untereinander knnen Parts
durch Konnektoren verbunden sein. Der gekapselte Classier steht also fr ein System mit klarer Abgrenzung von
Innen und Auen, dessen innere Struktur mit Hilfe von
Parts und Konnektoren speziziert ist. Damit die Grenze
zwischen Innen und Auen zumindest teilweise durchlssig ist, kann der gekapselte Classier auf der Hlle ber
eine Menge von Ein- und Ausgangspunkten, so genannten Ports, verfgen.

Komponenten sind modulare Teile eines Systems, die so

strukturiert sind, dass sie in ihrer Umgebung durch eine
andere, quivalente Komponente ersetzt werden knnten.
In der Softwareentwicklung verwendet man insbesondere das Konzept der Softwarekomponente, um ein Soft- Elemente aus dieser Spracheinheit werden meistens in
waresystem in modulare Teile zu gliedern. Die Sprachein- Kompositionsstrukturdiagrammen dargestellt.
heit Komponenten von UML2 stellt Konstrukte zur Verfgung, um Systeme, die aus Komponenten aufgebaut sind,
zu modellieren.
3.10 Modelle
Das wichtigste Element ist die Komponente, die eine innere Struktur gegen auen abgrenzt. Die Spezikation Die Spracheinheit Modelle umfasst nur ein Modelleleeiner Komponente deklariert vor allem den von auen ment: das Modell.
sichtbaren Rand und deniert damit eine Black-BoxSicht auf die Komponente. Sichtbar sind eine Menge von
angebotenen und erforderlichen Schnittstellen sowie al- 3.11 Prole
lenfalls eine Menge von Ports.

<<prole>>
OrganisationsModellierung

<<model>>
OrganisationFirmaA

<<metaclass>>
Class
<<apply>>

<<stereotyp>>
OrganisationsEinheit
kostenstelle: String
leiter: String

<<organisationsEinheit>>
leiter = "Hans Mustermann"
kostenstelle = "AB1234"

<<organisationsEinheit>>
Finanzabteilung

Beispiel fr die Denition und die Anwendung eines vereinfachten Prols fr die Organisationsmodellierung
Beispiel einer Komponente mit drei angebotenen und einer bentigten Schnittstelle, sowie zwei Ports

Die Spracheinheit umfasst ferner den Delegations- und

den Kompositionskonnektor. Der Delegationskonnektor
verbindet Ports auf der Hlle einer Komponente mit
Elementen im Innern der Komponente. Der Kompositionskonnektor verbindet angebotene Schnittstellen einer
Komponente mit bentigten Schnittstellen einer anderen
Komponente.
Die Elemente dieser Spracheinheit werden meistens

UML2 stellt mit der Spracheinheit Prole (engl. Proles) einen leichtgewichtigen Erweiterungsmechanismus
zur Verfgung, mit dem sie spezischen Einsatzgebieten angepasst werden kann. Der Mechanismus wird als
leichtgewichtig bezeichnet, weil er das Metamodell von
UML2 unverndert lsst, oft ein entscheidender Vorteil,
denn auf dem Markt erhltliche Werkzeuge fr die Erstellung und Pege von UML2-Modellen knnen oft nur
mit Modellen basierend auf dem standardisierten UML2Metamodell umgehen.

3.14

Zustandsautomaten

UML2 umfasst in ihren Spracheinheiten verschiedene

Mglichkeiten fr die Modellierung der Struktur und des
Verhaltens eines Systems, muss dabei aber auf einer generischen Ebene bleiben. Sie verwendet zum Beispiel die
generischen Begrie Aktivitt oder Artefakt und kennt
den spezischen Begri Geschftsprozess aus der Geschftsmodellierung oder Enterprise Java Beans der JavaPlattform nicht. Falls diese Begrie in der Modellierung bentigt werden, mssen sie ber den Erweiterungsmechanismus der Prole zu UML2 hinzugefgt werden.
Auch spezielle Notationen, zum Beispiel eine realistischere Zeichnung anstelle des Strichmnnchens, das einen Akteur darstellt, knnen UML2 mit Hilfe der Prole hinzugefgt werden. Weiter knnen Prole Lcken in
der Semantik-Denition der UML2 schlieen, die dort
absichtlich fr spezische Einsatzgebiete oen gelassen
wurden (engl. semantic variation points). Schlielich knnen Prole Einschrnkungen denieren, um die Art und
Weise zu beschrnken, wie ein Element aus UML2 verwendet wird.

:Applikationsserver1

<<deploy>>

<<artifact>>
Bestellung.jar

UML2 kennt seit der UML 2.2 einen speziellen Diagrammtyp fr Prole. Die graphischen Notationen fr
Elemente aus dieser Spracheinheit kommen sowohl in
Paketdiagrammen als auch in Klassendiagrammen vor.

<<artifact>>
Rechnung.jar

Beispiel eines Verteilungsdiagramms mit einem Knoten und zwei

Artefakten

auf einem Knoten installiert wird.

Elemente aus dieser Spracheinheit werden normalerweise
in Verteilungsdiagrammen dargestellt.

Mit Hilfe des Erweiterungsmechanismus der Prole kann

das Metamodell von UML2 jedoch nicht beliebig angepasst werden. So knnen zum Beispiel keine Elemente aus 3.14
dem Metamodell von UML2 entfernt, keine Einschrnkungen aufgehoben und keine echten neuen Metaklassen, sondern nur Erweiterungen (Stereotype) bestehender
Metaklassen deklariert werden.
Die Spracheinheit deniert zunchst das Konzept eines
Prols. Ein Prol ist eine Sammlung von Stereotypen,
und deniert die eigentliche Erweiterung. Ein Prol ist
ein Paket und wird auf andere Pakete angewendet, womit
die Erweiterung, die das Prol deniert, fr das entsprechende Paket gilt.

<<deploy>>

Zustandsautomaten

neu

mahnen

registrieren
ausleihen
ausleihbar

ausgeliehen

zurckbringen
abschreiben
verschollen

3.12 Schablonen
Die Spracheinheit Schablonen (engl. Templates) umBeispiel eines Zustandsautomaten fr die Zustnde eines Buchs
fasst Modellelemente fr die Parametrisierung von
in einer entlichen Bibliothek
Klassizierern, Klassen und Paketen.

3.13 Verteilungen

Die Spracheinheit Zustandsautomaten (engl. state machines) umfasst Modellelemente, die fr die Modellierung
von Zustandsautomaten eingesetzt werden.

Die Spracheinheit Verteilungen (engl. Deployments) ist

auf ein sehr spezisches Einsatzgebiet ausgerichtet, nmlich auf die Verteilung von lauhiger Software in einem Netzwerk. UML2 bezeichnet eine so installierbare Einheit als Artefakt und geht davon aus, dass
diese auf Knoten installiert werden. Knoten knnen
entweder Gerte oder Ausfhrungsumgebungen sein.
Eine Verteilungsbeziehung, das heit eine spezielle
Abhngigkeitsbeziehung, modelliert, dass ein Artefakt

UML2 setzt Zustandsautomaten in erster Linie fr die

Spezikation des Verhaltens eines Systems ein. So kann
ein Zustandsautomat zum Beispiel das Verhalten der Instanzen einer aktiven Klasse modellieren. Zustzlich knnen Zustandsautomaten aber auch eingesetzt werden, um
eine zulssige Nutzung einer Schnittstelle oder eines Ports
zu spezizieren. Der Zustandsautomat modelliert dabei
zum Beispiel, in welcher Reihenfolge Operationen einer
Schnittstelle aufgerufen werden drfen. Im ersten Fall

DARSTELLUNG IN DIAGRAMMEN

spricht man von einem Verhaltenszustandsautomaten, im Dazu kommen sieben Verhaltensdiagramme:

zweiten von einem Protokollzustandsautomaten.
das Aktivittsdiagramm,
Zustandsautomaten
werden
graphisch
in
Zustandsdiagrammen dargestellt. Diese sind in UML
eine Variante der klassischen Statecharts.

das Anwendungsfalldiagramm (auch: Use-Case o.

Nutzfalldiagramm genannt),
das Interaktionsbersichtsdiagramm,

Darstellung in Diagrammen

das Kommunikationsdiagramm,

Die Diagramme in UML lassen sich in zwei Hauptgruppen aufteilen: Strukturdiagramme und Verhaltensdiagramme.

das Sequenzdiagramm,
das Zeitverlaufsdiagramm und
das Zustandsdiagramm.

Diagramm

Strukturdiagramm

Klassendiagramm

Proldiagramm

Verhaltensdiagramm

Komponentendiagramm

Kompositionsstrukturdiagramm

Objektdiagramm

Verteilungsdiagramm

Aktivittsdiagramm

Interaktionsdiagramm

Paketdiagramm

Zustandsdiagramm

Kommunikations Interaktionsbersichts-diagramm
diagramm

Sequenzdiagramm

Notation: UML

Anwendungsfall
-diagramm

Zeitverlaufsdiagramm

Hierarchie von Diagrammen in UML 2.2, die wie ein

Klassendiagramm dargestellt wurden.

Nutzerfalldiagramm

Zustandsdiagramm

Include-Beziehung
<<include>>

Nutzerfall B

NF A schliet immer NF B mit ein

<<extend>>

Platz whlen

extension points
: Erluterung

Name des
Erweiterungspunktes

auf Karte
warten

Karte erkannt

Eintrittspunkt
Austrittspunkt

Klassen sind Fachbegrie

Attribute
- i. Allg. ohne Datentypen
- ggfs. mit Multiplizitten
Methoden ohne Parameter und Rckgabewert
Bidirektionale Assoziationen/Aggregationen
Beschreibung von Assoziationen
(Multiplizitten, Rollennamen, Assoziationsnamen (mit Leserichtung)
- ggfs. mit Qualifer
Assoziationsklassen und n-re Beziehungen
Generalisierung / Spezialisierung (Vererbung)
Abgeleitete Attribute und Methoden
Aufzhlungen (Enumerationen)

Entwurfsmodell (fachliche+tech. Sicht)

Klassen -> abstrakt, Interface, Sterotyp,
ggf. Klassen streichen, hinzufgen, umbennen
Attribute -> Sichtbarkeiten, Ableitung, Klassenattribute, Initialisierung, weitere spezielle
Eigenschaften
Operationen -> Parameter, Sichtbarkeiten,
Rckgabewert, Klassenoperation
Assoziationen -> gerichtet, geordnet / sortiert
Ausen von Assoziationsklassen / n-re
Beziehungen
Abhngigkeiten
Packages
Hilfsmethoden (Konstruktoren, getter/setter,
toString() u.a)

gestoppt

Anmeldung
beenden

H* tiefe Historie

[warteschlange.isEmpty()
stopp /

Wahl
besttigen

Passagier
erkannt
anders
identiziert

Klassendiagramm
Analysemodell (fachliche Sicht)

[keine Buchung
zum
Einchecken
bereit ]

Karte auslesen /
Passagierdaten
bereitstellen

H ache Historie

Kreuzung oder
Entscheidung

Condition: {Bedingung}
Name des
extension point: Erweiterungspunktes

Platz gewhlt

Karte
bekommen /

Zustand
Startzustand

Endzustand

Nutzerfall B

Karte ausgeben

::= [[Vorbedingung]] Methodenaufruf / [[Nachbedingung]]

Notationen:

Nutzerfall B

NF A kann, muss aber nicht durch

NF B erweitert werden

<<extend>>

Nutzerfall A

Transition

Extend-Beziehung
Nutzerfall A

Server {protocol}

Einschecken'

spezieller NF 2

Protokollzustandsmaschine (PSM)
Nutzerfall A

Beispiel: Protokollzustandmaschine

abgebrochen

Transition
::= [Auslser] [[Bedingung]] / [Aktion]
Auslser
::= Ereignisse [(Zuweisungen)]
Ereignisse
::= Ereignisse (,Ereignisse)*
Zuweisungen ::= Zuweisung (,Zuweisung)*
Zuweisung
::= Attribut | Attribut : Typ

genereller NF

Nutzerfall
spezieller NF 1

Beispiel: Verhaltenszustandmaschine

Verhaltenszustandsmaschine (BSM)

Generalisierung

Assoziation

[ true] start /
[ warteschlange.isEmpty() ]

gestartet

Karte ausgeben
[ true ]
dienstAufrufen(auftrag) /
[ warteschlange.last() = auftrag ]

[not warteschlange.isEmpty() ]
when(new_job_is_scheduled) /
[warteschlange.length() =
warteschlange@pre.length() -1 ]

Sequenzdiagramm
Eine Assoziation beschreibt eine Beziehung zwischen zwei oder mehr Klassen. An den
Enden von Assoziationen sind hug Multiplizitten vermerkt. Diese drcken aus, wie viele
dieser Objekte in Relation zu den anderen Objekten dieser Assoziation stehen.
Multiplizitten
1

Klasse 1

rolle

Beziehung

Objekt
Lebenslinie
Aktivierungsbalken

Eine Assoziation zwischen

Konto und Kunde

Ordnung
* {ordered}

Klasse 2

Leserichtung

Konto

(unterbrochen)

Ende des
Objektes

Kunde

name: String
saldo: Integer

vorname: String
nachname: String

Rollenbeschreibung

Assoziationsklasse

gerichtete Assoziation

Klasse 1

Klasse 2

Klasse 1

Ein synchroner Aufruf

unterbricht den Aktivierungsbalken solange, bis eine
synchrone Antwort eintrit.
Eine asynchrone Nachricht
verndert nichts am
Aktivierungsbalken.

C
instantiieren

Generalisierung

Unterklasse
1

Aufruf

Unterklasse
2

Aufruf (synchrone Nachricht)

Signal (asynchrone Nachricht)

(schrg bei relevanter Laufzeit)

Check-InAutomat
Passagier
Karte einfhren

Antwort

x=23
Signal

Initialisierung
& Daten laden

mit Laufzeit

Begrung mit Namen

mit Laufzeit

Aggregation
0..*

3..*

UML2 geht aber in anderer Hinsicht weit formaler mit

Diagrammen um als UML 1.4. Neu deniert UML2 unter dem Namen UML 2.0 Diagram Interchange ein Austauschformat fr Diagramme, so dass unterschiedliche
Werkzeuge, mit denen Modelle basierend auf UML2 erstellt werden, die Diagramme austauschen und wiederverwenden knnen. In UML 1.x war das nur fr die
Repository-Modelle hinter den Diagrammen mglich,
aber nicht fr die eigentlichen Diagramme.

Antwort (synchrone Nachricht)

charToInt('A')

Klasse 2

Vorlesung

die Unterklassen erben von der Oberklasse

Nachricht ::= Aufruf | Antwort| Signal

Signal

Oberklasse

Notationen:

Beschreibung:

Die Grenzen zwischen den vierzehn Diagrammtypen verlaufen weniger scharf, als diese Klassizierung vermuten lsst. UML2 verbietet nicht, dass ein Diagramm graphische Elemente enthlt, die eigentlich zu unterschiedlichen Diagrammtypen gehren. Es ist sogar denkbar, dass
Elemente aus einem Strukturdiagramm und aus einem
Verhaltensdiagramm auf dem gleichen Diagramm dargestellt werden, wenn damit eine besonders treende Aussage zu einem Modell erreicht wird.

4.1 Erstellen von Diagrammen

Student

Teil-Ganze Relation. Student ist ein Teil der Vorlesung

Aktivittsdiagramm
Notationen:

Abhngigkeit

Realisierung
<<interface>>

Klasse

Schnittstelle
Realisierung einer Klasse von einer Schnittstelle

Abhngig

Aktivitt
Unabhngig

Sichtbarkeit Operationsname (Parameterliste) : Rckgabetyp

Sichtbarkeit:
Parameterliste: Richtung Name : Typ = Standartwert
+ public element
Richtung: in, out, inout
# protected element
private element
~ package element

Vereinigung oder Gabelung

Beispiel: Aktivittsdiagramm

Sichtbarkeit Attributname : Paket :: Typ [Multipliztt Ordnung] = Initialwert {Eigenschaftswerte}

Eigenschaftswerte : {readOnly}, {ordered}, {composite}

Syntax fr Operationen

Kreuzung oder Entscheidung

Startpunkt
Endpunkt

das abhngige Element benutzt das unabhngige Element

Syntax fr Attribute
<< ... >>

Klasse

Klasse

{ ... }
+ Attr1 : Typ1 = (100,100)
# Attr2: Typ2 = true
+operation1()
+operation2()

<<interface>>

Klasse
i:Element

Klasse
{abstrakt}

Parametrisierbare Klasse

Bestellung
bekommen

[schnelle
Bestellung]

Bestellung
bearbeiten

UML Diagrammbersicht (Auswahl)

UML2.3 kennt sieben Strukturdiagramme:

das Klassendiagramm,

Bezahlung
bekommen

Rechnung
senden

[sonst]

bernacht
Sendung
Normale
Sendung

Bestellung
beenden

Diagramme von UML2 knnen auf verschiedene Arten

erstellt werden. Wenn die Notation von UML2 als gemeinsame Sprache eingesetzt wird, um in einem Analyseteam Entwrfe von Analysemodellen an der Weiwandtafel (Whiteboard) festzuhalten, reichen Stifte und Papier
als Werkzeug. Hug werden Diagramme von UML2
jedoch mit Hilfe von speziellen Programmen (UMLWerkzeugen) erstellt, die man in zwei Klassen einteilen
kann.

Programme in der ersten Gruppe helfen beim Zeichnen

das Kompositionsstrukturdiagramm (auch: Monta- von Diagrammen der UML2, ohne dass sie die Modellelemente, welche den graphischen Elementen auf den
gediagramm),
Diagrammen entsprechen, in einem Repository ablegen.
das Komponentendiagramm,
Zu dieser Gruppe gehren alle Programme zum Erstellen
von Zeichnungen.
das Verteilungsdiagramm,
Die zweite Gruppe besteht aus Programmen, die die Er das Objektdiagramm,
stellung von Modellen und das Zeichnen von Diagrammen von UML2 untersttzen.
das Paketdiagramm und
Siehe auch: UML-Werkzeug
das Proldiagramm.

Austausch von Modellen und

Diagrammen

Damit Modelle von einem Werkzeug an andere bergeben werden knnen, deniert die Object Management
Group ein standardisiertes Austauschformat, das auch fr
UML-Modelle eingesetzt wird. Das Format basiert auf
der Auszeichnungssprache XML und heit XML Metadata Interchange (XMI). Die Grundlage fr die Austauschbarkeit ist das MOF, auf dessen Konzept beide
Sprachen, XMI und UML, beruhen.
Fr die UML-Versionen 1.x sah das Format keine Mglichkeit vor, Diagramme in einem standardisierten Format auszutauschen, was von vielen Anwendern als wesentliche Lcke wahrgenommen wurde. Parallel zur Entwicklung von UML2 hat die OMG deshalb auch das standardisierte Austauschformat XMI berarbeitet. Unter anderem wurde die beschriebene Lcke geschlossen, indem
die Spezikation unter dem Namen UML 2.0 Diagram
Interchange um ein Format fr den Austausch von Diagrammen erweitert wurde.
Ein Austausch mit anderen Modellierungssprachen ist
auch mittels Modell-zu-Modell-Transformation mglich.
Dazu hat die OMG den Standard MOF QVT deniert.
Im Gegensatz zu einem reinen Austauschformat kann eine Transformation auch eine eigene Semantik enthalten.
So kann zum Beispiel festgelegt werden, wie ein Klassenmodell auf ein ER-Modell abzubilden ist. Die damit einhergehende Flexibilitt ist insbesondere auch beim Austausch zwischen Werkzeugen ntzlich, da verschiedene
Anbieter praktisch immer auch individuelle Varianten
des UML-Metamodells haben.

Siehe auch
Rational Unied Process
Round-Trip-Engineering
UML-Werkzeug
Verwandte OMG-Initiativen und Sprachempfehlungen:
modellgetriebene Architektur (MDA)
MOF 2 Query/Views/Transformations (QVT)
Object Constraint Language (OCL)

Fundamental Modeling Concepts (FMC)

IDEF

7 Literatur
Heide Balzert: UML 2 in 5 Tagen. W3L, 2005, ISBN
3-937137-61-0
H. Baumann, P. Grssle, Ph. Baumann, UML 2 projektorientiert. Galileo Computing, 2007, ISBN 9783-8362-1014-0
Grady Booch, James Rumbaugh, Ivar Jacobson:
Das UML-Benutzerhandbuch. Aktuell zur Version
2.0. Addison-Wesley, 2006, ISBN 978-3827325709
(bersetzt aus dem Amerikanischen).
M. Born, E. Holz, O. Kath: Softwareentwicklung
mit UML 2. Addison-Wesley, 2004, ISBN 3-82732086-0
B. Brgge, A. H. Dutoit: Objekt-orientierte Softwaretechnik mit UML, Entwurfsmustern und Java. Pearson Studium, 2004, ISBN 3-8273-7082-5
M. Fowler, Scott Kendall: UML konzentriert.
Addison-Wesley Verlag, 2000, ISBN 3-8273-16170
M. Fowler: UML Distilled. 3. Auage. AddisonWesley, 2003, ISBN 0-321-19368-7
M. Hitz, G. Kappel, E. Kapsammer, W. Retschitzegger: UML@Work. Dpunkt Verlag, 2005, ISBN
3-89864-261-5
B. Kahlbrandt: Software Engineering mit der Unied
Modeling Language. Springer, 2001, ISBN 3-54041600-5
Christoph Kecher, Alexander Salvanos: UML 2.5
Das umfassende Handbuch. Rheinwerk Computing,
2015, ISBN 978-3-8362-297-77
B. Oestereich, Axel Scheithauer: Analyse und Design mit UML 2.5: Objektorientierte Softwareentwicklung. Oldenbourg Verlag, 2013, ISBN 978-3-48672140-9
Dan Pilone: UML kurz & gut. OReilly, ISBN 389721-263-3

Modeling and Analysis of Real-time and Embedded systems (MARTE)

B. Rumpe, Modellierung mit UML. Springer Verlag,

2004, ISBN 3-540-20904-2

Systems Modeling Language (SysML)

Chris Rupp, Stefan Queins, Barbara Zengler: UML

2 glasklar. Praxiswissen fr die UML-Modellierung.
Hanser Verlag, 2007, ISBN 978-3-446-41118-0

Weitere Modellierungsmethoden und Sprachfamilien:

EXPRESS (siehe STEP)

Sinan Si Alhir: Learning UML. OReilly, ISBN 0596-00344-7

10

EINZELNACHWEISE

H. Strrle: UML 2 fr Studenten. Pearson Studium

Deutschland, 2005, ISBN 3-8273-7143-0

Der moderne Softwareentwicklungsprozess mit UML.

Online-Buch zur UML (deutsch)

H. Strrle: UML 2 erfolgreich einsetzen. AddisonWesley, 2005, ISBN 3-8273-2268-5

Death by UML Fever. Ein kritischer Artikel ber

UML, erschienen in den Communications of the
ACM

7.1

Zur Zertizierung

Tim Weilkiens, B. Oestereich: UML2-Zertizierung.

Dpunkt Verlag, 2004, ISBN 3-89864-294-1
Tim Weilkiens, B. Oestereich: UML2-Zertizierung:
Intermediate Stufe. Dpunkt Verlag, 2005, ISBN 389864-312-3
Tim Weilkiens, B. Oestereich: UML 2.0 Zertizierungsvorbereitung. Fundamental, Intermediate und
Advanced. Dpunkt Verlag, 2006, ISBN 3-89864424-3

7.2

Gekoppelt mit Vorgehensmodellen

W. Zuser, T. Grechenig, M. Khle: Software Engineering mit UML und dem Unied Process. Pearson
Studium, 2004, ISBN 3-8273-7090-6
B. Rumpe, Agile Modellierung mit UML. Springer
Verlag, 2004, ISBN 3-540-20905-0

Weblinks

Wiktionary: UML Bedeutungserklrungen,

Wortherkunft, Synonyme, bersetzungen
Commons: Unied Modeling Language Album
mit Bildern, Videos und Audiodateien

8.1

Spezikationen zur UML2

UML 2.4.1 Infrastructure Specication (englisch)

(PDF)
UML 2.4.1 Superstructure Specication (englisch)
(PDF)
UML Specication in allen Versionen

8.2

Weitere

bersicht UML-Tools
MOF 2.0 Core Specication (PDF; englisch)
MOF 1.4 Specication (PDF; englisch)
Website der OMG zur UML (englisch)

9 Einzelnachweise
[1] omg.org: OMG Formal Versions of UML
[2] Teil 1 der Spezikation der Sprache (Infrastruktur)
[3] Webseite der OMG
[4] UML 2.0 OCL
[5] UML 2.0 Infrastructure (PDF)
[6] omg.org/spec/UML/2.2

Normdaten (Sachbegri): GND: 4469781-8

11

10
10.1

Text- und Bildquellen, Autoren und Lizenzen

Text

Unied Modeling Language Quelle: https://de.wikipedia.org/wiki/Unified_Modeling_Language?oldid=146220372 Autoren: Koethnig,

Kku, Zeno Gantner, Jschlosser, Jed, HHK, Gnu1742, Aka, Aheil, Stefan Khn, Ulrich.fuchs, KarstenSchulz, Magnus, ErikDunsing, Elwood j blues, Marioj, Fab, GNosis, Nd, HbJ, Crissov, Matt1971, Tsor, Seewolf, Hubi, Blubbalutsch, Perlentaucher, Nephelin, Mkleine,
Wachs, Srbauer, Zwobot, D, Wolfgang1018, Nikai, Hadhuey, Karl-Henner, MichaelDiederich, Jpp, APPER, Rdb, DominikusH, Peter200,
Schmiddtchen, GuidoZockoll, Haeber, Breeze, Christoph D, Arnomane, Hardenacke, XPhilosoph, Martin-vogel, Ot, Wiegand, P. Birken,
Gerhardvalentin, Wiki-observer, Neg, Progman~dewiki, Sulai, Timekeeper, Philipendula, Sprezzatura, Jae, Maikel, Ri st, Niemeyerstein,
ChristophDemmer, Frank Jacobsen, Thobach, Hajo.thelen, Djj, Aaron Mller, Juesch, Anfuehrer, Mkogler, Botteler, Gpermant, Mps, Polluks, Gutsul, Heinte, Rosenzweig, Diba, Kek00207, He3nry, Sparti, Mm pedia, FlaBot, Hubertl, GFJ, Quirin, Flominator, RedBot, Scooter,
Guwac, Gubaer, Kh80, JuTa, Sae1962, Siehe-auch-Lscher, Ma-Lik, Stefan-sander, Olei, Abubiju, RobotE, Krischan111, Amtiss, Ra'ike,
Saehrimnir, JanRieke, JFKCom, RMeier, Sterling, RobotQuistnix, Bota47, FabianLange, Littletux, Euku, YurikBot, Ste ba, Omis Trtchen, Savin 2005, Lkwg82, NPunkt, Mdd, Sbremer, EldurLoki, $traight-$hoota, HaraldStoerrle, Gigi2345, DerHexer, Botulph, Revolus,
JCS, SpBot, Liberaler Humanist, Nightyer, Andrea Doria, Fomax, Kaihuener, Highbrow, Weilkiti, DHN-bot~dewiki, Gontsaru, Robb
der Physiker, Mischka., Ben Chumin, Der fette mo, Pendulin, Leo141, Tnjes, Cleverboy, Akribix, Mijozi, Mathetes, Mtmaassmann, Semper, Spuk968, Thijs!bot, Leider, El., Escarbot, Horst Grbner, Fleshgrinder, Kallistratos, Sebastian.Dietrich, Chiccodoro, Scooty, Nicolas
G., Xypron, MarkusBuechele79, Themole, CommonsDelinker, Avron, Mgehrmann, PerfektesChaos, Complex, Gerold Broser, Gerakibot,
VolkovBot, Salier100, Kyle the bot, AlnoktaBOT, Tischbeinahe, TXiKiBoT, Cactus26, Dieter66007, Truthpath~dewiki, 08-15-Bot, AlleborgoBot, Krawi, BotMultichill, Loveless, Der.Traeumer, Ivpen, OKBot, Rdennis, Bjrn Klippstein, L.M. Morgenroth, Jfwagener, Chemiewikibm, Christian1985, Ochsenfrosch, Se4598, Vogella, Ute Erb, Alexbot, Kmx94712, GordonKlimm, Ellipse, Edward Montgomery
Harrington, Stkl, Schnark, Schotterebene, Johnny Controletti, SamatBot, Gaius L., Luckas-bot, AxelScheithauer, Empro2, Xqbot, Howwi,
Pwagenblast, Morten Haan, An.ha, WissensDrster, Chris828, Staniko, Almabot, Acky69, RibotBOT, Velocet, HRoestBot, Serols, Nkersten, TobeBot, Akkakk, EmausBot, Commons, JensMDD, MetaMarph, Drcico, Bormaschine, Restfreiheit, Lektorat Cogito, Domspatz,
Van'Dhunter, Axel Naumann, Boshomi, Tuttist, Funkenstern, Addbot, Tkkrd, Natsu Dragoneel, Schnabeltassentier, Eugen1971, Hiku2
und Anonyme: 283

10.2

Bilder

Datei:Commons-logo.svg Quelle: https://upload.wikimedia.org/wikipedia/commons/4/4a/Commons-logo.svg Lizenz: Public domain Autoren: This version created by Pumbaa, using a proper partial circle and SVG geometry features. (Former versions used to be slightly warped.)
Ursprnglicher Schpfer: SVG version was created by User:Grunt and cleaned up by 3247, based on the earlier PNG version, created by
Reidab.
Datei:Component-2.png Quelle: https://upload.wikimedia.org/wikipedia/commons/1/19/Component-2.png Lizenz: CC-BY-SA-3.0 Autoren: Eigenes Werk (Originaltext: Selbst gezeichnet) Ursprnglicher Schpfer: Oder Zeichner: Gubaer
Datei:Disambig-dark.svg Quelle: https://upload.wikimedia.org/wikipedia/commons/e/ea/Disambig-dark.svg Lizenz: CC-BY-SA-3.0
Autoren: Original Commons upload as Logo Begrisklrung.png by Baumst on 2005-02-15 Ursprnglicher Schpfer: Stephan Baum
Datei:Informationflow-1.png Quelle: https://upload.wikimedia.org/wikipedia/de/9/9c/Informationflow-1.png Lizenz: CC-BY-SA-3.0
Autoren:
selbst gezeichnet
Ursprnglicher Schpfer:
Gubaer
Datei:Klassendiagramm-1.png Quelle: https://upload.wikimedia.org/wikipedia/commons/0/03/Klassendiagramm-1.png Lizenz: CCBY-SA-3.0 Autoren: Eigenes Werk (Originaltext: Selbst gezeichnet) Ursprnglicher Schpfer: Gubaer
Datei:MetamodelHierarchy_de.svg Quelle: https://upload.wikimedia.org/wikipedia/commons/6/6f/MetamodelHierarchy_de.svg Lizenz: CC BY-SA 3.0 Autoren: created by author, based on OMG: Unied Modeling Language: Infrastructure. Page 31 Ursprnglicher
Schpfer: Jens von Pilgrim
Datei:OO-historie-2.svg Quelle: https://upload.wikimedia.org/wikipedia/commons/3/33/OO-historie-2.svg Lizenz: CC BY-SA 3.0 Autoren: File:Objektorientieren methoden historie.png and File:OO-historie.svg Ursprnglicher Schpfer: File:Objektorientieren methoden
historie.png : GuidoZockoll, Mitarbeiter der oose.de Dienstleistungen fr Innovative Informatik GmbH
Datei:UML-Diagramme.svg Quelle: https://upload.wikimedia.org/wikipedia/commons/7/7f/UML-Diagramme.svg Lizenz: CC BY-SA
3.0 Autoren: Eigenes Werk Ursprnglicher Schpfer: MetaMarph
Datei:UML-Diagrammhierarchie.svg Quelle: https://upload.wikimedia.org/wikipedia/commons/d/da/UML-Diagrammhierarchie.svg
Lizenz: CC BY-SA 4.0 Autoren: Redrawn in SVG, original PNG UML-Diagrammhierarchie.png by Sae1962 Ursprnglicher Schpfer:
Stkl
Datei:Uml-Activity-Beispiel2.svg Quelle: https://upload.wikimedia.org/wikipedia/commons/a/a1/Uml-Activity-Beispiel2.svg Lizenz:
CC BY-SA 3.0 Autoren: Redrawn in SVG Ursprnglicher Schpfer: Original PNG Activity 2.png by Gubaer
Datei:Uml-Pin-1.svg Quelle: https://upload.wikimedia.org/wikipedia/commons/7/7e/Uml-Pin-1.svg Lizenz: CC BY-SA 3.0 Autoren: Redrawn in SVG, original PNG Pin-2.png by Gubaer Ursprnglicher Schpfer: Stkl
Datei:Uml-UseCase-Beispiel3.svg Quelle: https://upload.wikimedia.org/wikipedia/commons/8/8a/Uml-UseCase-Beispiel3.svg Lizenz:
CC BY-SA 3.0 Autoren: Redrawn in SVG, original PNG Use-case-6.png by Gubaer Ursprnglicher Schpfer: Stkl
Datei:Uml-Zustandsdiagramm-1.svg Quelle: https://upload.wikimedia.org/wikipedia/commons/8/87/Uml-Zustandsdiagramm-1.svg
Lizenz: CC BY-SA 4.0 Autoren: Redrawn in SVG, original PNG Statemachine-1.png by Gubaer Ursprnglicher Schpfer: Stkl
Datei:UmlProfildiagramm-1.svg Quelle: https://upload.wikimedia.org/wikipedia/commons/b/b0/UmlProfildiagramm-1.svg Lizenz:
CC BY-SA 3.0 Autoren: Redrawn in SVG, original PNG Stereotype-4.png by Gubaer Ursprnglicher Schpfer: Stkl

12

10 TEXT- UND BILDQUELLEN, AUTOREN UND LIZENZEN

Datei:UmlSequenzdiagramm-1.svg Quelle: https://upload.wikimedia.org/wikipedia/commons/8/89/UmlSequenzdiagramm-1.svg Lizenz: CC BY-SA 3.0 Autoren: Redrawn in SVG, original PNG Sequenz diagramm-1.png by Gubaer Ursprnglicher Schpfer: Stkl
Datei:UmlVerteilungsdiagramm.svg Quelle: https://upload.wikimedia.org/wikipedia/commons/1/1a/UmlVerteilungsdiagramm.svg Lizenz: CC BY-SA 3.0 Autoren: Redrawn in SVG, original PNG Verteilungsdiagramm.png by Gubaer Ursprnglicher Schpfer: Stkl
Datei:Wiktfavicon_en.svg Quelle: https://upload.wikimedia.org/wikipedia/commons/c/c3/Wiktfavicon_en.svg Lizenz: CC BY-SA 3.0
Autoren: ? Ursprnglicher Schpfer: ?

10.3

Inhaltslizenz

Creative Commons Attribution-Share Alike 3.0