Embed Size (px)
DESCRIPTION
language
Citation preview
7/17/2019 Unified Modeling Language
http://slidepdf.com/reader/full/unified-modeling-language-568dddf100a88 1/12
Unified Modeling Language
Die Unified Modeling Language (vereinheitlichteModellierungssprache) , kurz UML, ist eine grafischeModellierungssprache zur Spezifikation, Konstruktionund Dokumentation von Software-Teilen und anderenSystemen.[2] Sie wird von der Object ManagementGroup (OMG) entwickelt und ist sowohl von ihr alsauch von der ISO (ISO/IEC 19505 für Version 2.4.1[3])standardisiert. Im Sinne einer Sprache definiert UMLdabei Bezeichner für die meisten bei einer Modellierungwichtigen Begriffe und legt mögliche Beziehungen
zwischen diesen Begriffen fest. UML definiert weitergrafische Notationen für diese Begriffe und für Modellestatischer Strukturen und dynamischer Abläufe, die manmit diesen Begriffen formulieren kann.
UML ist heute die dominierende Sprache für dieSoftwaresystem-Modellierung. Der erste Kontakt zuUML besteht häufig darin, dass Diagramme in UML imRahmen von Softwareprojekten zu erstellen, zu verstehenoder zu beurteilen sind:
• Projektauftraggeber und Fachvertreter prüfen undbestätigen zum Beispiel Anforderungen an ein Sys-
tem, die Wirtschaftsanalytiker bzw. Business Ana-lysten in Anwendungsfalldiagrammen in UML fest-gehalten haben;
• Softwareentwickler realisieren Arbeitsabläufe,die Wirtschaftsanalytiker bzw. Business Ana-lysten in Zusammenarbeit mit Fachvertretern inAktivitätsdiagrammen beschrieben haben;
• Systemingenieure installieren und betreiben Soft-waresysteme basierend auf einem Installationsplan,der als Verteilungsdiagramm vorliegt.
Die grafische Notation ist jedoch nur ein Aspekt, derdurch UML geregelt wird. UML legt in erster Linie fest,mit welchen Begriffen und welchen Beziehungen zwi-schen diesen Begriffen sogenannte Modelle spezifiziertwerden – Diagramme in UML zeigen nur eine graphi-sche Sicht auf Ausschnitte dieser Modelle. UML schlägtweiter ein Format vor, in dem Modelle und Diagrammezwischen Werkzeugen ausgetauscht werden können.
1 Entstehungsgeschichte
Die erste Version von UML entstand in den 1990er Jah-ren als Reaktion auf zahlreiche Vorschläge für Model-lierungssprachen und -Methoden, welche die zu dieser
Zeit aufkommende objektorientierte Softwareentwick-lung unterstützen sollten. Die erste Folge von Sprachver-sionen, auch bekannt unter dem Namen UML 1.x, wurde2005 durch eine grundlegend überarbeitete Version, oftals UML2 bezeichnet, abgelöst.
1.1 Von den Anfängen zur Unified Mode-
ling Language 1.x
Historie der objektorientierten Methoden und Notationen
Die Väter von UML, insbesondere Grady Booch, IvarJacobson und James Rumbaugh, auch „Die drei Ami-gos“ genannt, waren in den 1990er-Jahren bekannte Ver-treter der objektorientierten Programmierung. Sie hat-ten alle bereits ihre eigenen Modellierungssprachen ent-wickelt. Als sie zusammen beim Unternehmen RationalSoftware beschäftigt waren, entstand die Idee, die ver-schiedenen Notationssysteme strukturiert zusammenzu-führen. Eine Vielzahl von unterschiedlichen Modellie-
rungssprachen hatte direkten oder indirekten Einfluss aufdie Konzeption von UML, darunter OOSE, RDD, OMT,OBA, OODA, SOMA, MOSES und OPEN/OML.
Als Resultat dieser Bemühungen entstand die UML.Die Standardisierung, Pflege und Weiterentwicklung derSprache wurde an die OMG übergeben, die die Spracheam 19. November 1997 als Standard akzeptierte.
1.2 Entstehungsgeschichte der Unified
Modeling Language 2
Im August 1999 stieß die OMG die Entwicklung vonUML2 an, indem sie einen entsprechenden Request forInformation (RFI) publizierte.
1
7/17/2019 Unified Modeling Language
http://slidepdf.com/reader/full/unified-modeling-language-568dddf100a88 2/12
2 2 STRUKTURIERUNG
Ein Jahr später, im September 2000, bat die OMG ih-re Mitglieder und weitere interessierte Kreise um Vor-schläge für UML2. Gemäß der neu für UML2 definiertenArchitektur publizierte die OMG drei Requests for Pro- posals (RFP): einen UML 2.0 Infrastructure RFP, einenUML 2.0 Superstructure RFP und einen UML 2.0 OCL
RFP. Wer Vorschläge einreichen wollte, hatte dazu un-gefähr ein weiteres Jahr Zeit.
In einer ersten Runde reichten verschiedene Gruppen undEinzelpersonen Entwürfe ein. Mitte 2002 lagen von die-sen Konsortien mehrmals überarbeitete und konsolidierteAntworten auf einzelne Request for Proposals vor. Erstim Oktober 2002 konnten dann beim Treffen der zustän-digen Arbeitsgruppe in Helsinki alle Vorschläge für dieUML 2.0 Infrastructure und die UML 2.0 Superstructurepräsentiert werden. Einen Termin für eine weitere über-arbeitete Version der Vorschläge legte die Arbeitsgruppeauf Anfang Januar 2003 fest. Die Hauptschwierigkeit be-
stand nun darin, die unterschiedlichen Entwürfe zu einer Spezifikation zu verschmelzen. Einerseits wurde Kritiklaut, dass sich die unterschiedlichen Philosophien in deneingereichten Vorschlägen nur schwerlich würden berei-nigen lassen, andererseits reichte im Januar 2003 ein neu-es Konsortium unter dem Namen 4M einen Vorschlag(UML4MDA) ein, der die Differenzen zwischen den bis-herigen Spezifikationen zu überbrücken versuchte.
Im März 2003 empfahl die zuständige Arbeitsgruppe dieVorschläge des Konsortiums U2 für die UML 2.0 Infra-structure und für die UML 2.0 OCL zur Freigabe, im Maidann auch für die UML 2.0 Superstructure des gleichen
Konsortiums, so dass ab Juni 2003 drei Finalization Task Forces der OMG die Arbeit aufnehmen konnten, um dieTeilspezifikationen abzuschließen. Die Task Forces konn-ten ihre Arbeit jedoch nicht wie geplant bis zum April2004 abschließen und gründeten deshalb eine zweite Fi-nalization Task Force, die die verbleibenden Probleme biszum September 2004 lösen sollte.
Im September 2004 konnten schließlich alle FinalizationTask Forces ihre Arbeit beenden. Für die UML 2.0 OCL[4]
und die UML 2.0 Infrastructure[5] lagen damit endgültigabgenommene Dokumente (Final Adopted Specification)vor. Nur bei der UML 2.0 Superstructure schien sich die-
ser letzte Schritt noch etwas zu verzögern: im März 2005bot der OMG-Webauftritt weiterhin nur ein temporäresDokument mit der informellen Bezeichnung UML 2.0 Su- perstructure FTF convenience document zum Herunterla-den an.
Am 21. Oktober 2008 wurde die Beta 1 von UML Ver-sion 2.2 durch die OMG veröffentlicht, die wiederum imFebruar 2009 in der finalen Version vorlag.[6] Neu hin-zugekommen ist in der Version 2.2 das Profildiagramm,um eigendefinierte Stereotyp-Sammlungen strukturierenzu können.
Im Mai2010 wurde UML 2.3 veröffentlicht. Diese Versi-on enthielt vor allem Bugfixes am Metamodell und Schär-fungen der Semantik von Modellelementen im Spezifika-
tionsdokument der UML. Die aktuelle Version 2.5 wurdeim Juni 2015 veröffentlicht.
2 Strukturierung
Der Umfang der UML ist während der Entwicklung vonUML 1.0 bis UML 2 laufend gewachsen. Sowohl für dieEntwicklung von UML 2 als auch für die Vermittlung, dieAnwendung und nicht zuletzt für die Lesbarkeit der UML2-Spezifikation ist eine Strukturierung sehr wichtig. Wasin den ersten Versionen von UML in einem Dokumentspezifiziert werden konnte, muss deshalb für UML 2 inTeilspezifikationen aufgeteilt werden. In den folgendenAbschnitten wird der Aufbau von UML 2 beschrieben.
2.1 Teilspezifikationen
UML2 ist in drei Teilspezifikationen aufgeteilt. Die UML2.0 Infrastructure Specification legt das Fundament fürUML2, indem sie die am häufigsten verwendeten Ele-mente von UML2 und die Modellelemente beschreibt,die die restlichen Modellelemente spezialisieren. In die-sem Dokument werden Konzepte wie die Klasse, dieAssoziation oder die Multiplizität eines Attributs spezi-fiziert. Die UML 2.0 Superstructure Specification baut aufdem Fundament der UML 2.0 Infrastructure Specifica-tion auf und definiert die Modellelemente von UML2,die sich für bestimmte Einsatzzwecke eignen. Typische
Konzepte, die in diesem Dokument spezifiziert wer-den, sind der Anwendungsfall, die Aktivität oder derZustandsautomat. Schließlich spezifiziert das Dokumentmit dem Titel UML 2.0 Object Constraint Language dieObject Constraint Language 2.0 (OCL2).
Ein weiterer, vierter Teil beschäftigt sich nicht mit demsemantischen Modell von UML, sondern spezifiziert dasLayout der Diagramme. Dieses Dokument trägt den TitelUML 2.0 Diagram Interchange und ist eine Neuerung inUML 2.0; UML 1.x kannte kein standardisiertes Format,mit dem das Diagramm-Layout zwischen unterschiedli-chen Werkzeugen ausgetauscht werden konnte. Die se-
mantischen Informationen in einem UML-Modell konnteein Werkzeug auch bisher an ein anderes Werkzeug über-geben; das Aussehen der Diagramme, das heißt die Posi-tionen und Größe einzelner Diagrammelemente, ging da-bei aber verloren. Diagram Interchange (DI) soll diesesManko beseitigen.
2.2 Metamodellierung
Ähnlich wie sich natürliche Sprachen in Lexika oderGrammatiken selbst beschreiben, wurde auch UML alsein Sprachwerkzeug konzipiert, das sich mit einigenSprachbestandteilen selbst erklärt.
Die Sprachkonzepte sind dazu in vier Schichten M0 bis
7/17/2019 Unified Modeling Language
http://slidepdf.com/reader/full/unified-modeling-language-568dddf100a88 3/12
2.4 Einteilung der Spracheinheiten in Schichten 3
M3: MOF
M2: UML
M1:
M0:
Metametamodell
Metamodell
Modell
System
Benutzermodell
Laufzeitinstanzen
Class
The BigLebowski
name: String
MediumDVD
«instanceOf»
«instanceOf» «instanceOf»«instanceOf»
«instanceOf» «instanceOf» «instanceOf»
«instanceOf»
Generalization AttributeClass
general
specificattributes
Hierarchie der Metamodellierung
M3 gegliedert.
Mit der Meta Object Facility (MOF) werden Modellele-mente von UML2 spezifiziert und dadurch zum Beispielmit dem Format Meta Interchange XMI austauschbar.Diese MOF ist auf Ebene M3 und stellt eine der vierSchichten dar. Es ist die Metasprache der Metasprachen(das Metametamodell ) und beinhaltet grundlegende Ele-mente (wie Pakete, Klassen, Attribute und Assoziatio-nen). Die Metasprache UML2 (M2) ist in MOF definiertund stellt die bekannten Sprachmerkmale zur Verfügung,über die Konzepte von MOF hinaus auch noch Anwen-dungsfälle, Zustandsautomaten und mehr. Die in der Pra-xis erstellten UML-Modelle befinden sich auf der EbeneM1. Damit werden die Objekte der M0-Schicht darge-stellt. Dies sind die konkreten Laufzeitinstanzen des Sys-tems.
Wie in UML2.0 war auch UML1.x auf der dritten vonvier Metamodellierungsebenen eingeordnet. Zu UML 1.xbesteht jedoch ein wesentlicher Unterschied: Die auf denEbenen M2 und M3 verwendeten Modellierungsspra-chen (also MOF und UML) teilen sich die gemeinsameSpracheinheit der Infrastrukturbibliothek (InfrastructureLibrary). Sie wird in der UML 2.0 Infrastructure definiertund bildet einen Kern der grundlegenden Modellierungs-elemente, der sowohl in der UML 2.0 Infrastructure alsauch in der UML 2.0 Superstructure und in der MOF 2.0eingesetzt wird.
2.3 Spracheinheiten
Die UML 2.0 Superstructure ist auf einer ersten Ebenemodular in Spracheinheiten (engl. language units ) aufge-baut. Eine Spracheinheit umfasst eine Menge von eng zu-sammenhängenden Modellierungselementen, mit denenein Benutzer einen ausgewählten Aspekt eines Systemsmit einem bestimmten Formalismus modellieren kann.
Die Spracheinheit Aktivitäten (engl. Activities ) umfasstzum Beispiel Elemente für die Modellierung eines Sys-temverhaltens, das sich am besten mit dem Formalismus
von Daten- und Kontrollflüssen darstellen lässt.
2.4 Einteilung der Spracheinheiten in
Schichten
Auf einer dritten Stufe sind die meisten Spracheinheitenin mehrere Schichten (engl. Compliance Level ) geglie-dert. Die unterste Schicht umfasst jeweils die einfachstenund am häufigsten verwendeten Modellierungselemente,während höhere Schichten zunehmend komplexere Mo-dellierungselemente einführen. Die Spracheinheit Akti-vitäten umfasst beispielsweise FundamentalActivities alsunterste Schicht und darauf aufbauend die Schicht Basi-cActivities . FundamentalActivities definiert zunächst nur,dass Aktivitäten strukturell aus hierarchisch geschachtel-ten Gruppen von Aktionen bestehen. BasicActivities er-weitert dieses Gerüst um Kanten und weitere Hilfsknoten
zu einem Graphen, den man in UML2 dann visuell alsAktivitätsdiagramm darstellt.
3 Spracheinheiten
3.1 Aktionen
Die Spracheinheit Aktionen (engl. actions ) umfasst dieDefinition der Aktionen in UML2. Aktionen sinddie elementaren Bausteine für die Modellierung einesVerhaltens. Sie können Eingabewerte über sogenannte
Eingabepins entgegennehmen und Ausgabewerte an so-genannten Ausgabepins produzieren.
UML2 definiert in dieser Spracheinheit mehrere Gruppenvon grundlegenden Aktionen, siehe Aktion.
Suppe kochenGemüse
Wasser Suppe
Beispiel der graphischen Notation für eine Aktion mit zwei Eingabe- und einem Ausgabepin
3.2 Aktivitäten
Die Aktivität ist das zentrale Element der SpracheinheitAktivitäten. Sie ist gleichzeitig eine Neuerung von UML2gegenüber UML 1.4. Eine Aktivität ist ein Modell fürein Verhalten. Sie besteht aus Aktionen, zwischen denenKontroll- und Datenflüsse existieren. Ein Aktivitätsdia-gramm stellt das dynamische Verhalten eines Software-Systems dar.
Aktivitäten haben die Struktur eines Graphen. Knotendieses Graphen sind Aktionen sowie Punkte, an denen
7/17/2019 Unified Modeling Language
http://slidepdf.com/reader/full/unified-modeling-language-568dddf100a88 4/12
4 3 SPRACHEINHEITEN
Spaghetti kochen
Spaghetti[roh]
Spaghettieinfüllen
Wasser kochen
Spaghetti10min kochen
Spaghetti[al dente]
ein Kontrollfluss
ein Startknoten(ein Kontrollknoten)
ein Objektfluss eine Aktion
ein Pin(ein Objektknoten)
ein Aktivitätsparameterknoten(ein Objektknoten)
Spaghetti-Kochen modelliert als Aktivität
die Flüsse zwischen den Aktionen kontrolliert werden;Kanten stehen fürDaten- und Kontrollflüsse. Das Sprach-paket Aktivitäten definiert alle Typen von Knoten undKanten, die für die Modellierung von Aktivitäten benö-tigt werden.
Knoten werden in Objekt- und Kontrollknoten un-
terschieden, Kanten analog dazu in Objekt- undKontrollflüsse.
Komplexere Aktivitäten können verschachtelt und mitKontrollstrukturen modularisiert werden.
Aktivitäten werden graphisch in Aktivitätsdiagrammenmodelliert.
3.3 Allgemeines Verhalten
Die Spracheinheit Allgemeines Verhalten umfasst die all-gemeinen Modellelemente für die Spezifikation des Ver-
haltens eines mit UML2 modellierten Systems. Hiersind die Modellelemente zusammengefasst, die fürdie Spezifikation von Aktivitäten, Interaktionen oderZustandsautomaten benötigt werden.
Die Spracheinheit definiert die Gemeinsamkeiten jederVerhaltensbeschreibung und dass eine aktive Klasse eineigenes Verhalten haben kann. Verhalten in einem Sys-tem, das mit UML2 modelliert ist, startet immer auf-grund von diskreten Ereignissen. Dieses Sprachpaket de-finiert, welche Arten von Ereignissen UML2 unterstützt.
Die Behandlung der Zeit wird ebenfalls weitgehend indiesem Sprachpaket geregelt. Es definiert Metaklassenfür die Beobachtung der Zeit (TimeObservationAction),für die Notation von Zeitausdrücken (TimeExpression),für die Definition von Zeitintervallen (TimeInterval ) so-wie für das Konzept einer zeitlichen Dauer (Duration).
3.4 Anwendungsfälle
Die Spracheinheit Anwendungsfälle (engl. use case) stelltElemente für die Modellierung von Anforderungen anein System zur Verfügung. Das wichtigste Element istder Anwendungsfall. Anwendungsfälle halten fest, was
ein System tun soll. Das zweite wichtige Element ist derAkteur. Akteure spezifizieren, wer (im Sinne einer Per-son) oder was (im Sinne eines anderen Systems) etwas
mit dem System tun soll.
Graphisch werden Anwendungsfälle inAnwendungsfalldiagrammen dargestellt.
Mobilfunkbetreiber
SMS verschicken
Fotomessageverschicken
Sender
Beispiel für die graphische Darstellung zweier Anwendungsfälleund eines Akteurs
3.5 Informationsflüsse
Den Techniken, die UML2 für die Spezifikation des Ver-haltens eines Systems anbietet, liegen präzise semanti-sche Modelle zugrunde. Das gilt insbesondere für Ver-haltensbeschreibungen mit Hilfe von Interaktionen oderAktivitäten, die zudem darauf ausgerichtet sind, das Ver-halten eines Systems sehr feingranular zu spezifizieren.Soll das Modell eines Systems nur einige grundlegendeInformationsflüsse im System aufzeigen, eignen sich die-se Techniken deshalb nur bedingt.
Die Spracheinheit Informationsflüsse, die in UML2 neueingeführt wurde, stellt Modellelemente zur Verfügung,um diese Situation zu verbessern. Sie bietet die Model-lelemente Informationseinheit und Informationsfluss an,mit denen ein Modellierer Informationsflüsse in einemSystem auf hoher Abstraktionsstufe festhalten kann.
Informationsflüsse können dabei eine Vielzahlvon anderen Modellelementen von UML2 ver-
binden, insbesondere Klassen, Anwendungsfälle,Ausprägungsspezifikationen, Akteure, Schnittstellen,Ports und noch einige mehr.
UML2 gibt keinen Diagrammtyp für Informationsflüssevor. Die graphische Notation für Informationsflüsse undInformationseinheiten kann in allen Strukturdiagrammenvorkommen.
3.6 Interaktionen
Das Verhalten eines modellierten Systems kann in UML2
auf unterschiedliche Art und Weise spezifiziert werden.Eine davon ist die Modellierung von Interaktionen. EineInteraktion ist die Spezifikation eines Verhaltens, das am
7/17/2019 Unified Modeling Language
http://slidepdf.com/reader/full/unified-modeling-language-568dddf100a88 5/12
3.7 Klassen 5
Beispiel eines Strukturdiagramms mit zwei Informationsflüssen
:Koch :Herd
Wasser kochen
einschalten
ausschalten
Beispiel für die Spezifikation einer Interaktion mit Hilfe eines Sequenzdiagramms
besten über den Austausch von Meldungen zwischen ei-genständigen Objekten beschrieben wird. Die Sprachein-heit stellt dafür die geeigneten Modellelemente zur Ver-fügung.
Wer Interaktionen modelliert, geht davon aus, dass das
modellierte System aus einem Netzwerk von Objek-ten besteht, die untereinander Meldungen austauschen.Schickt ein Objekt einem anderen Objekt eine Meldung,
kann manzwei Ereignisauftritte identifizieren: erstens dasAuftreten eines Meldungsereignisses, wenn die Meldungvom ersten Objekt abgeschickt wird sowie zweitens ei-nes Meldungsereignisses, wenn die Meldung beim zwei-ten Objekt ankommt. Weitere Ereignisse treten auf, wenneine Aktion oder ein anderes Verhalten im Kontext eines
Objekts beginnt oder endet. Eine Spur (trace) bezeich-net eine Folge solcher Ereignisse. Interaktionen spezifi-zieren nun ein Verhalten als zwei Mengen von Spuren,einer Menge gültiger und einer Menge ungültiger Spuren.
Damit ist präziser gesagt, was wir meinen, wenn wirvon Interaktionen sprechen: die Bedeutung (Semantik)einer Interaktion ist durch Mengen von Spuren gege-ben. Modelliert werden Interaktionen jedoch als Men-gen von Lebenslinien, auf denen Aktionen und an-dere Verhaltensweisen ablaufen und zwischen denenNachrichten ausgetauscht werden.
Interaktionen modelliert man graphisch inKommunikationsdiagrammen, in Sequenzdiagrammenoder in Zeitverlaufsdiagrammen.
3.7 Klassen
Beispiel für ein Klassendiagramm , das Elemente aus der Sprach-einheit Klassen verwendet
Die Spracheinheit Klassen umfasst den eigentlichen Kernder Modellierungssprache. Sie definiert insbesondere,was man in UML2 unter einer Klasse versteht und welcheBeziehungen zwischen Klassen möglich sind. In dieser
Spracheinheit sind grundlegende Prinzipien von UML2definiert. Die Metaklasse Element ist das Wurzelelementfür alle anderen Modellelemente. Jedes Element kann an-dere Elemente besitzen, auch beliebig viele Kommentare,die wiederum andere Elemente kommentieren können.Zwischen Elementen können Beziehungen definiert wer-den. Elemente können benannt sein und gehören in die-sem Fall zu einem Namensraum. Weiter können gewis-se Elemente einen Typ haben. Sie werden dann als ty- pisierte Elemente bezeichnet. Einem Element kann eineMultiplizität mit einer unteren und einer oberen Schran-ke zugeordnet sein.
Diese Spracheinheit enthält vier Unterpakete. DasUnterpaket Kernel umfasst zentrale Modellierungs-elemente, die aus der UML 2.0 Infrastructure wie-
7/17/2019 Unified Modeling Language
http://slidepdf.com/reader/full/unified-modeling-language-568dddf100a88 6/12
6 3 SPRACHEINHEITEN
derverwendet werden. Dazu gehören die Klasse,die Ausprägungsspezifikation, der Namensraum,das Paket, das Attribut, die Assoziation, dieAbhängigkeitsbeziehung, der Paketimport, diePaketverschmelzung und die Generalisierung. Daszweite Unterpaket, AssociationClasses , umfasst die
Definition von Assoziationsklassen. Interfaces , dasdritte Unterpaket, stellt die Definition von Schnittstellenbereit. Schließlich deklariert das Unterpaket PowerTypes Modellelemente für die sogenannten PowerTypes.
Elemente aus dieser Spracheinheit werden meis-tens in Klassendiagrammen, Objektdiagrammen undPaketdiagrammen dargestellt.
3.8 Komponenten
Komponenten sind modulare Teile eines Systems, die so
strukturiert sind, dass sie in ihrer Umgebung durch eineandere, äquivalente Komponente ersetzt werden könnten.In der Softwareentwicklung verwendet man insbesonde-re das Konzept der Softwarekomponente, um ein Soft-waresystemin modulare Teile zu gliedern. Die Sprachein-heit Komponenten vonUML2 stellt Konstrukte zur Verfü-gung, um Systeme, die aus Komponenten aufgebaut sind,zu modellieren.
Das wichtigste Element ist die Komponente, die eine in-nere Struktur gegen außen abgrenzt. Die Spezifikationeiner Komponente deklariert vor allem den von außensichtbaren Rand und definiert damit eine Black-Box-
Sicht auf die Komponente. Sichtbar sind eine Menge vonangebotenen und erforderlichen Schnittstellen sowie al-lenfalls eine Menge von Ports.
Beispiel einer Komponente mit drei angebotenen und einer benö-tigten Schnittstelle , sowie zwei Ports
Die Spracheinheit umfasst ferner den Delegations- undden Kompositionskonnektor. Der Delegationskonnektorverbindet Ports auf der Hülle einer Komponente mitElementen im Innern der Komponente. Der Kompositi-onskonnektor verbindet angebotene Schnittstellen einerKomponente mit benötigten Schnittstellen einer anderenKomponente.
Die Elemente dieser Spracheinheit werden meistens
in Komponentendiagrammen, zum Teil aber auch inKlassendiagrammen oder Verteilungsdiagrammen darge-stellt.
3.9 Kompositionsstrukturen
Die Spracheinheit Kompositionsstrukturen (engl. Structu-res) bereichert UML2 um einen neuen Ansatz für die Mo-dellierung der inneren Struktur eines zusammengesetztenGanzen. Das „Ganze“ wird dabei als gekapselter Clas-sifier modelliert, für die „Teile“ stellt diese Sprachein-heit die Parts zur Verfügung. Untereinander können Partsdurch Konnektoren verbunden sein. Der gekapselte Clas-sifier steht also für ein System mit klarer Abgrenzung vonInnen und Außen, dessen innere Struktur mit Hilfe vonParts und Konnektoren spezifiziert ist. Damit die Grenzezwischen Innen und Außen zumindest teilweise durchläs-
sig ist, kann der gekapselte Classifier auf der Hülle übereine Menge von Ein- und Ausgangspunkten, so genann-ten Ports, verfügen.
Elemente aus dieser Spracheinheit werden meistens inKompositionsstrukturdiagrammen dargestellt.
3.10 Modelle
Die Spracheinheit Modelle umfasst nur ein Modellele-ment: das Modell.
3.11 Profile
<<profile>>
OrganisationsModellierung
<<stereotyp>>OrganisationsEinheit
kostenstelle: Stringleiter: String
<<metaclass>>
Class
<<model>>
OrganisationFirmaA
<<organisationsEinheit>>
leiter = "Hans Mustermann"
kostenstelle = "AB1234"
<<organisationsEinheit>>Finanzabteilung
<<apply>>
Beispiel für die Definition und die Anwendung eines vereinfach-ten Profils für die Organisationsmodellierung
UML2 stellt mit der Spracheinheit Profile (engl. Pro-files) einen leichtgewichtigen Erweiterungsmechanismuszur Verfügung, mit dem sie spezifischen Einsatzgebie-ten angepasst werden kann. Der Mechanismus wird alsleichtgewichtig bezeichnet, weil er das Metamodell vonUML2 unverändert lässt, oft ein entscheidender Vorteil,denn auf dem Markt erhältliche Werkzeuge für die Er-
stellung und Pflege von UML2-Modellen können oft nurmit Modellen basierend auf dem standardisierten UML2-Metamodell umgehen.
7/17/2019 Unified Modeling Language
http://slidepdf.com/reader/full/unified-modeling-language-568dddf100a88 7/12
3.14 Zustandsautomaten 7
UML2 umfasst in ihren Spracheinheiten verschiedeneMöglichkeiten für die Modellierung der Struktur und desVerhaltens eines Systems, muss dabei aber auf einer ge-nerischen Ebene bleiben. Sie verwendet zum Beispiel diegenerischen Begriffe Aktivität oder Artefakt und kenntden spezifischen Begriff Geschäftsprozess aus der Ge-
schäftsmodellierung oder Enterprise Java Beans der Java-Plattform nicht. Falls diese Begriffe in der Modellie-rung benötigt werden, müssen sie über den Erweiterungs-mechanismus der Profile zu UML2 hinzugefügt werden.Auch spezielle Notationen, zum Beispiel eine realisti-schere Zeichnung anstelle des Strichmännchens, das ei-nen Akteur darstellt, können UML2 mit Hilfe der Profi-le hinzugefügt werden. Weiter können Profile Lücken inder Semantik-Definition der UML2 schließen, die dortabsichtlich für spezifische Einsatzgebiete offen gelassenwurden (engl. semantic variation points ). Schließlich kön-nen Profile Einschränkungen definieren, um die Art und
Weise zu beschränken, wie ein Element aus UML2 ver-wendet wird.
Mit Hilfe des Erweiterungsmechanismus der Profile kanndas Metamodell von UML2 jedoch nicht beliebig ange-passt werden. So könnenzum Beispiel keine Elemente ausdem Metamodell von UML2 entfernt, keine Einschrän-kungen aufgehoben und keine echten neuen Metaklas-sen, sondern nur Erweiterungen (Stereotype) bestehenderMetaklassen deklariert werden.
Die Spracheinheit definiert zunächst das Konzept einesProfils. Ein Profil ist eine Sammlung von Stereotypen,und definiert die eigentliche Erweiterung. Ein Profil ist
ein Paket und wird auf andere Pakete angewendet , womitdie Erweiterung, die das Profil definiert, für das entspre-chende Paket gilt.
UML2 kennt seit der UML 2.2 einen speziellen Dia-grammtyp für Profile. Die graphischen Notationen fürElemente aus dieser Spracheinheit kommen sowohl inPaketdiagrammen als auch in Klassendiagrammen vor.
3.12 Schablonen
Die Spracheinheit Schablonen (engl. Templates ) um-
fasst Modellelemente für die Parametrisierung vonKlassifizierern, Klassen und Paketen.
3.13 Verteilungen
Die Spracheinheit Verteilungen (engl. Deployments ) istauf ein sehr spezifisches Einsatzgebiet ausgerichtet, näm-lich auf die Verteilung von lauffähiger Software in ei-nem Netzwerk. UML2 bezeichnet eine so installier-bare Einheit als Artefakt und geht davon aus, dassdiese auf Knoten installiert werden. Knoten können
entweder Geräte oder Ausführungsumgebungen sein.Eine Verteilungsbeziehung, das heißt eine spezielleAbhängigkeitsbeziehung, modelliert, dass ein Artefakt
:Applikationsserver1
<<artifact>>
Bestellung.jar
<<deploy>>
<<artifact>>
Rechnung.jar
<<deploy>>
Beispiel eines Verteilungsdiagramms mit einem Knoten und zwei Artefakten
auf einem Knoten installiert wird.
Elemente aus dieser Spracheinheit werden normalerweisein Verteilungsdiagrammen dargestellt.
3.14 Zustandsautomaten
neu
registrieren
ausleihbar
ausleihen
zurückbringen
mahnen
ausgeliehen
abschreiben
verschollen
Beispiel eines Zustandsautomaten für die Zustände eines Buchs in einer öffentlichen Bibliothek
Die Spracheinheit Zustandsautomaten (engl. state machi-nes ) umfasst Modellelemente, die für die Modellierungvon Zustandsautomaten eingesetzt werden.
UML2 setzt Zustandsautomaten in erster Linie für dieSpezifikation des Verhaltens eines Systems ein. So kannein Zustandsautomat zum Beispiel das Verhalten der In-stanzen einer aktiven Klasse modellieren. Zusätzlich kön-nen Zustandsautomaten aber auch eingesetzt werden, umeine zulässige Nutzung einer Schnittstelle odereines Ports
zu spezifizieren. Der Zustandsautomat modelliert dabeizum Beispiel, in welcher Reihenfolge Operationen einerSchnittstelle aufgerufen werden dürfen. Im ersten Fall
7/17/2019 Unified Modeling Language
http://slidepdf.com/reader/full/unified-modeling-language-568dddf100a88 8/12
7/17/2019 Unified Modeling Language
http://slidepdf.com/reader/full/unified-modeling-language-568dddf100a88 9/12
9
5 Austausch von Modellen und
Diagrammen
Damit Modelle von einem Werkzeug an andere überge-ben werden können, definiert die Object Management
Group ein standardisiertes Austauschformat, das auch fürUML-Modelle eingesetzt wird. Das Format basiert aufder Auszeichnungssprache XML und heißt XML Me-tadata Interchange (XMI). Die Grundlage für die Aus-tauschbarkeit ist das MOF, auf dessen Konzept beideSprachen, XMI und UML, beruhen.
Für die UML-Versionen 1.x sah das Format keine Mög-lichkeit vor, Diagramme in einem standardisierten For-mat auszutauschen, was von vielen Anwendern als we-sentliche Lücke wahrgenommen wurde. Parallel zur Ent-wicklung von UML2 hat die OMG deshalb auch das stan-dardisierte Austauschformat XMI überarbeitet. Unter an-
derem wurde die beschriebene Lücke geschlossen, indemdie Spezifikation unter dem Namen UML 2.0 DiagramInterchange um ein Format für den Austausch von Dia-grammen erweitert wurde.
Ein Austausch mit anderen Modellierungssprachen istauch mittels Modell-zu-Modell-Transformation möglich.Dazu hat die OMG den Standard MOF QVT definiert.Im Gegensatz zu einem reinen Austauschformat kann ei-ne Transformation auch eine eigene Semantik enthalten.So kann zum Beispiel festgelegt werden, wie ein Klassen-modell auf ein ER-Modell abzubilden ist. Die damit ein-hergehende Flexibilität ist insbesondere auch beim Aus-
tausch zwischen Werkzeugen nützlich, da verschiedeneAnbieter praktisch immer auch individuelle Variantendes UML-Metamodells haben.
6 Siehe auch
• Rational Unified Process
• Round-Trip-Engineering
• UML-Werkzeug
• Verwandte OMG-Initiativen und Sprachempfehlun-gen:
• modellgetriebene Architektur (MDA)
• MOF 2 Query/Views/Transformations (QVT)
• Object Constraint Language (OCL)
• Modeling and Analysis of Real-time and Em-bedded systems (MARTE)
• Systems Modeling Language (SysML)
• Weitere Modellierungsmethoden und Sprachfamili-
en:
• EXPRESS (siehe STEP)
• Fundamental Modeling Concepts (FMC)
• IDEF
7 Literatur
• Heide Balzert: UML 2 in 5 Tagen. W3L, 2005, ISBN3-937137-61-0
• H. Baumann, P. Grässle, Ph. Baumann, UML 2 pro- jektorientiert . Galileo Computing, 2007, ISBN 978-3-8362-1014-0
• Grady Booch, James Rumbaugh, Ivar Jacobson:Das UML-Benutzerhandbuch. Aktuell zur Version2.0. Addison-Wesley, 2006, ISBN 978-3827325709(übersetzt aus dem Amerikanischen).
•
M. Born, E. Holz, O. Kath: Softwareentwicklungmit UML 2. Addison-Wesley, 2004, ISBN 3-8273-2086-0
• B. Brügge, A. H. Dutoit: Objekt-orientierte Software-technik mit UML, Entwurfsmustern und Java. Pear-son Studium, 2004, ISBN 3-8273-7082-5
• M. Fowler, Scott Kendall: UML konzentriert .Addison-Wesley Verlag, 2000, ISBN 3-8273-1617-0
• M. Fowler: UML Distilled . 3. Auflage. Addison-Wesley, 2003, ISBN 0-321-19368-7
• M. Hitz, G. Kappel, E. Kapsammer, W. Retschit-zegger: UML@Work . Dpunkt Verlag, 2005, ISBN3-89864-261-5
• B. Kahlbrandt: Software Engineering mit der Unified Modeling Language. Springer, 2001, ISBN 3-540-41600-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 De-sign mit UML 2.5: Objektorientierte Softwareentwick-lung. Oldenbourg Verlag, 2013, ISBN 978-3-486-72140-9
• Dan Pilone: UML – kurz & gut . O’Reilly, ISBN 3-89721-263-3
• B. Rumpe, Modellierung mit UML. Springer Verlag,2004, ISBN 3-540-20904-2
• Chris Rupp, Stefan Queins, Barbara Zengler: UML2 glasklar. Praxiswissen für die UML-Modellierung.Hanser Verlag, 2007, ISBN 978-3-446-41118-0
• Sinan Si Alhir: Learning UML. O’Reilly, ISBN 0-596-00344-7
7/17/2019 Unified Modeling Language
http://slidepdf.com/reader/full/unified-modeling-language-568dddf100a88 10/12
10 9 EINZELNACHWEISE
• H. Störrle: UML 2 für Studenten. Pearson StudiumDeutschland, 2005, ISBN 3-8273-7143-0
• H. Störrle: UML 2 erfolgreich einsetzen. Addison-Wesley, 2005, ISBN 3-8273-2268-5
7.1 Zur Zertifizierung
• Tim Weilkiens, B. Oestereich: UML2-Zertifizierung.Dpunkt Verlag, 2004, ISBN 3-89864-294-1
• Tim Weilkiens, B. Oestereich: UML2-Zertifizierung: Intermediate Stufe. Dpunkt Verlag, 2005, ISBN 3-89864-312-3
• Tim Weilkiens, B. Oestereich: UML 2.0 Zertifizie-rungsvorbereitung. Fundamental, Intermediate und Advanced . Dpunkt Verlag, 2006, ISBN 3-89864-
424-3
7.2 Gekoppelt mit Vorgehensmodellen
• W. Zuser, T. Grechenig, M. Köhle: Software Engi-neering mit UML und dem Unified Process . PearsonStudium, 2004, ISBN 3-8273-7090-6
• B. Rumpe, Agile Modellierung mit UML. SpringerVerlag, 2004, ISBN 3-540-20905-0
8 Weblinks
Wiktionary: UML – Bedeutungserklärungen,Wortherkunft, Synonyme, Übersetzungen
Commons: Unified Modeling Language – Albummit Bildern, Videos und Audiodateien
8.1 Spezifikationen zur UML2
• UML 2.4.1 Infrastructure Specification (englisch)
(PDF)
• UML 2.4.1 Superstructure Specification (englisch)(PDF)
• UML Specification in allen Versionen
8.2 Weitere
• Übersicht UML-Tools
• MOF 2.0 Core Specification (PDF; englisch)
• MOF 1.4 Specification (PDF; englisch)
• Website der OMG zur UML (englisch)
• Der moderne Softwareentwicklungsprozess mit UML.Online-Buch zur UML (deutsch)
• Death by UML Fever . – Ein kritischer Artikel überUML, erschienen in den Communications of theACM
9 Einzelnachweise
[1] omg.org: OMG Formal Versions of UML
[2] Teil 1 der Spezifikation 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 (Sachbegriff): GND: 4469781-8
7/17/2019 Unified Modeling Language
http://slidepdf.com/reader/full/unified-modeling-language-568dddf100a88 11/12
11
10 Text- und Bildquellen, Autoren und Lizenzen
10.1 Text
• Unified 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 Kühn, Ulrich.fuchs, KarstenSchulz, Magnus, ErikDunsing, El-wood 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 Müller, Juesch, Anfuehrer, Mkogler, Botteler, Gpermant, Mps, Pol-luks, Gutsul, Heinte, Rosenzweig, Diba, Kek00207, He3nry, Sparti, Mm pedia, FlaBot, Hubertl, GFJ, Quirin, Flominator, RedBot, Scooter,Guwac, Gubaer, Kh80, JuTa, Sae1962, Siehe-auch-Löscher, Ma-Lik, Stefan-sander, Olei, Abubiju, RobotE, Krischan111, Amtiss, Ra'ike,Saehrimnir, JanRieke, JFKCom, RMeier, Sterling, RobotQuistnix, Bota47, FabianLange, Littletux, Euku, YurikBot, Ste ba, Omi´s Tört-chen, Savin 2005, Lkwg82, NPunkt, Mdd, Sbremer, EldurLoki, $traight-$hoota, HaraldStoerrle, Gigi2345, DerHexer, Botulph, Revolus,JCS, SpBot, Liberaler Humanist, Nightflyer, Andrea Doria, Fomafix, Kaihuener, Highbrow, Weilkiti, DHN-bot~dewiki, Gontsaru, Robbder Physiker, Mischka., Ben Chumin, Der fette mo, Pendulin, Leo141, Tönjes, Cleverboy, Akribix, Mijozi, Mathetes, Mtmaassmann, Sem-per, Spuk968, Thijs!bot, Leider, El., Escarbot, Horst Gräbner, Fleshgrinder, Kallistratos, Sebastian.Dietrich, Chiccodoro, Scooty, NicolasG., 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, Alle-borgoBot, Krawi, BotMultichill, Loveless, Der.Traeumer, Ivpen, OKBot, Rdennis, Björn Klippstein, L.M. Morgenroth, Jfwagener, Che-miewikibm, 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, WissensDürster, Chris828, Staniko, Almabot, Acky69, RibotBOT, Velocet, HRoestBot, Serols, Nkers-ten, 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, Hiku2und Anonyme: 283
10.2 Bilder
• Datei:Commons-logo.svg Quelle: https://upload.wikimedia.org/wikipedia/commons/4/4a/Commons-logo.svg Lizenz: Public domain Au-toren: This versioncreated by Pumbaa, using a proper partial circle and SVGgeometryfeatures. (Former versions used to be slightly warped.)Ursprünglicher Schöpfer: SVG version was created by User:Grunt and cleaned up by 3247, based on the earlier PNG version, created byReidab.
• Datei:Component-2.png Quelle: https://upload.wikimedia.org/wikipedia/commons/1/19/Component-2.png Lizenz: CC-BY-SA-3.0 Au-toren: Eigenes Werk (Originaltext: Selbst gezeichnet ) Ursprünglicher Schöpfer: Oder Zeichner: Gubaer
•
Datei:Disambig-dark.svg Quelle: https://upload.wikimedia.org/wikipedia/commons/e/ea/Disambig-dark.svg Lizenz: CC-BY-SA-3.0Autoren: Original Commons upload as Logo Begriffsklärung.png by Baumst on 2005-02-15 Ursprünglicher Schöpfer: Stephan Baum
• Datei:Informationflow-1.png Quelle: https://upload.wikimedia.org/wikipedia/de/9/9c/Informationflow-1.png Lizenz: CC-BY-SA-3.0Autoren:
selbst gezeichnet
Ursprünglicher Schöpfer:
Gubaer
• Datei:Klassendiagramm-1.png Quelle: https://upload.wikimedia.org/wikipedia/commons/0/03/Klassendiagramm-1.png Lizenz: CC-BY-SA-3.0 Autoren: Eigenes Werk (Originaltext: Selbst gezeichnet ) Ursprünglicher Schöpfer: Gubaer
• Datei:MetamodelHierarchy_de.svg Quelle: https://upload.wikimedia.org/wikipedia/commons/6/6f/MetamodelHierarchy_de.svg Li- zenz: CC BY-SA 3.0 Autoren: created by author, based on OMG: Unified Modeling Language: Infrastructure. Page 31 Ursprünglicher Schöpfer: 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 Au-toren: File:Objektorientieren methoden historie.png and File:OO-historie.svg Ursprünglicher Schöpfer: File:Objektorientieren methodenhistorie.png : GuidoZockoll, Mitarbeiter der oose.de Dienstleistungen für Innovative Informatik GmbH
• Datei:UML-Diagramme.svg Quelle: https://upload.wikimedia.org/wikipedia/commons/7/7f/UML-Diagramme.svg Lizenz: CC BY-SA3.0 Autoren: Eigenes Werk Ursprünglicher Schöpfer: MetaMarph
• Datei:UML-Diagrammhierarchie.svg Quelle: https://upload.wikimedia.org/wikipedia/commons/d/da/UML-Diagrammhierarchie.svgLizenz: CC BY-SA 4.0 Autoren: Redrawn in SVG, original PNG UML-Diagrammhierarchie.png by Sae1962 Ursprünglicher Schöpfer: 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 Ursprünglicher Schöpfer: 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: Re-drawn in SVG, original PNG Pin-2.png by Gubaer Ursprünglicher Schöpfer: 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 Ursprünglicher Schöpfer: 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 Ursprünglicher Schöpfer: 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 Ursprünglicher Schöpfer: Stkl
7/17/2019 Unified Modeling Language
http://slidepdf.com/reader/full/unified-modeling-language-568dddf100a88 12/12
12 10 TEXT- UND BILDQUELLEN, AUTOREN UND LIZENZEN
• Datei:UmlSequenzdiagramm-1.svg Quelle: https://upload.wikimedia.org/wikipedia/commons/8/89/UmlSequenzdiagramm-1.svg Li- zenz: CC BY-SA 3.0 Autoren: Redrawn in SVG, original PNG Sequenz diagramm-1.png by Gubaer Ursprünglicher Schöpfer: Stkl
• Datei:UmlVerteilungsdiagramm.svg Quelle: https://upload.wikimedia.org/wikipedia/commons/1/1a/UmlVerteilungsdiagramm.svg Li- zenz: CC BY-SA 3.0 Autoren: Redrawn in SVG, original PNG Verteilungsdiagramm.png by Gubaer Ursprünglicher Schöpfer: Stkl
• Datei:Wiktfavicon_en.svg Quelle: https://upload.wikimedia.org/wikipedia/commons/c/c3/Wiktfavicon_en.svg Lizenz: CC BY-SA 3.0Autoren: ? Ursprünglicher Schöpfer: ?
10.3 Inhaltslizenz
• Creative Commons Attribution-Share Alike 3.0
