UML - Einführung

Marcel Lüthi
Departement Mathematik und Informatik

Graphische Modellierungssprachen

Ziel: Software auf hoher Abstraktions-ebene verstehen

Brauchen standardisierte Notationen um Artefakte und Entscheidungen zu

Modellieren
Dokumentieren
Kommunizieren

Wir haben in den letzten Wochen immer wieder informelle Graphische Notationen benutzt, um die Beziehung zwischen Modulen zu verdeutlichen. Diese Graphischen Notationen machen es möglich, Details eines Softwaresystems zu ignorieren, und stattdessen die Grossen Zusammenhänge zu verstehen. Während wir für unsere kleinen Beispiele einfach eine intuitiv verständliche Notation nutzen konnten, ist es in der professionellen Softwareentwicklung unerlässlich, dass wir eine standardisierte Notation nutzen um unsere Software zu modellieren und zu Dokumentieren. In der Zusammenarbeit mit unseren Kollegen, Kunden und Auftraggebern, bilden diese Diagramme eine wichtige Unterstützung um unsere Entscheidungen zu Kommunizieren.

UML

Grafische Modellierungssprache zur Spezifikation, Konstruktion und Dokumentation von Software und anderen Systemen

Quasi standard zur graphischen Modellierung von OO-Systemen
Entwickelt 1990 (G. Booch, I. Jacobson, J. Rumbaugh)
Mittlerweise in der Version 2.5

UML Hype

Von Idotter - http://en.wikipedia.org/wiki/File:Gartner_Hype_Cycle.svg, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=7560534

UML ist kein Wundermittel wie anfang 2000 geglaubt wurde
... aber trotzdem enorm nützlich

UML als Technologie hat einen enormen Hype hinter sich und den typsichen Hypezyklus durchlaufen. Nachdem ende der 90er und anfangs 2000 UML fast als Allerweltsheilmittel in der Softwareentwicklung propagiert wurde, hat man später verstanden, dass auch diese Technologie keine Silverbullet für die Softwareentwicklung ist. Entäuschung hat sich breit gemacht, und UML hat enorm an Stellenwert verloren. Jedoch bleibt der Wert von UML als standardisierte Sprache, die die meisten Softwareentwickler lesen und verstehen können für die Dokumentation und Kommunikation erhalten. Auch dank diesem Hype haben wir heute eine Vielzahl von Werkzeugen für die Modellierung und Dokumentation mittels UML zur Verfügung.

Diagrammarten (UML 2)

Strukturdiagramme
(statisch)

Klassendiagramm
Montagediagramm
Komponentendiagramm
Verteilungsdiagramm
Objektdiagramm
Paketdiagramm
Profildiagramm

Verhaltensdiagramme (dynamisch)

Aktivitätsdiagramm
Use-case Diagramm
Interaktionsdiagramm
Kommunikationsdiagramm
Sequenzdiagramm
Zeitverlaufdiagramm
Zustandsdiagramm

Der UML Standard definiert viele Verschiedene Arten von Diagrammen. Grob kann man diese in zwei Klassen unterscheiden. Strukturdiagramme, die die statische Struktur eines Systems modellieren, und Verhaltensdiagramme, welche benutzt werden um die dynamischen Aspekte eines Systems zu definieren. Wir werden uns in dieser Vorlesung auf die wichtigsten Struktur und verhaltensdiagramme beschränken. Das sind das Klassendiagramm und das Paketdiagramm um die Sturktur zu beschreiben, und Aktivitätsdiagram, Use-case diagramm, Sequenzdiagramm und Zustandsdiagramm um das Verhalten eines Systems zu beschreiben. In dieser Woche beginnen wir mit dem Klassendiagramm und dem Paketdiagramm. Wir werden sehen, dass wir damit unter anderem die bekannten "uses" und "is_component_of" Beziehungen zwischen Modulen modellieren.

Klassendiagramm

Wichtigste Diagrammart in UML
Häufig nur als Werkzeug für das Detaildesign verwendet
Ist aber auch mächtiges Modellierungstool

Klassen entsprechen zu modellierenden Entitäten
Klasse in UML muss nicht Klasse in Implementation entsprechen

Beispiel: Bibliotheksanwendung

Diagramm nach Pfleeger & Atlee, Software Engineering

Hier sehen wir ein Beispiel von einem Klassendiagramm. Die Rechtecke entsprechen den modellierten Klassen. Bei jeder Klasse sehen wir zuoberste den Klassennamen, gefolgt von den Attributen, und darunter die Methoden. Die Linien entsprenden den Beziehungen zwischen Klassen und werden Assoziationen genannt. Diese Assoziationen werden benannt, um die Art der Beziehung klar zu machen. In diesem Beispiel einer Bibliotheksanwendung wird modelliert, dass ein Kunde Publikationen ausleihen kann. Die entsprechenden Daten zum ausgeliehenen Objekt werden in der Klasse Loan verwaltet. Es gibt zwei Arten von Publikationen, nämlich Bücher und Zeitschriften. Jede Zeitschrift besteht dabei aus mehreren Artikeln. Im folgenden Artikeln werden die wichtigsten Elemente dieser Diagramme im Detail erklärt.

Assoziationen

Beziehungen zwischen Klassen, die Implementation unterstützen muss

Optional: Multiplizitäten

Definiert implizit eine "Uses" Beziehung

Für uns ist an dieser Stelle nur wichtig zu wissen, dass eine Assozation immer eine Beziehung beschreibt, die die Klasse in der Implementation unterstützen muss. In unserem Beispiel hier, muss das Kundenobjekt in der Implementation eine Referenz auf das Objekt Publikation haben. Eine Assoziation repräsentiert also immer eine "uses" Beziehung. In der UML lassen sich aber die Art der Beziehung noch viel detaillierter Beschreiben. Zum Beispiel können wir sagen, wie viele Objekte jeweils in die Beziehung involviert sind. In diesem Beispiel symbolisiert das Sternchen, dass ein Kunde mehrere Publikationen ausleihen kann. Umgekehrt wird jede Publikation von einem oder keinem Kunden ausgeliehen.

Paketdiagramm

Zeigt die Struktur des Systems auf Paketebene.

Modelliert "is_component_of" Beziehung

Angabe von Beziehungen möglich

Toolunterstützung

Weite Verbreitung → Gute Toolunterstützung
Empfehlung: Modelio (www.modelio.org)

Modernes und mächtiges Open Source Tool