Modellierung mit UML

Transcription

Modellierung mit UML
Thomas Kistel
24. November 2006
Thema - Untertitel • Datum/Semester • Ihr Name • Seite 1
Inhalt
1. Einführung zu UML
2. Zielsetzung von UML
3. Sichten und Diagramme von UML
4. Model Driven Architecture (MDA)
Modellierung mit UML • © 2006 Thomas Kistel • Seite 2
Einleitung
(Motivation)

Modellierung = Abstraktion der Realität mit
Konzentration auf die wesentlichen Aspekte

Für Entwicklung (komplexer) Softwaresysteme ist
Modellierung unabdingbar

Modellierung hilft
• die gewünschte Struktur und das Verhalten eines Systems
zu beschreiben und zu diskutieren
• das System besser zu verstehen, indem man sich zu einem
Zeitpunkt nur auf einen Ausschnitt bzw. einen einzelnen
Aspekt konzentriert
• frühzeitig Probleme des Modells zu erkennen und zu
beheben
Einleitung
(Was ist UML)

UML – Unified Modeling Language

Eine Familie grafischer Notationen, hinter den ein
eiziges Metamodell steht

Notationen helfen bei der Beschreibung und
Entwicklung von Softwaresystemen (insbesondere
OO)

UML ist ein relativ offener Standard
• Wird von der Object Management Group (OMG) kontrolliert
• Entstanden 1995-1997
Einleitung
(Einsatzmöglichkeiten von UML)

UML als Skizze
• Forward Engineering
• Reverse Engineering

Blaupausen
• Verfeinerung des Forward Engineering
– Trifft alle Entwurfsentscheidungen (Vollständigkeit)
– Detaillierungsgrad bis zur Ebene von Schnittstellen für Subsysteme
– Die Implementierung beginnt ab diesem Entwurf
• Reverse Engineering
– Dokumentation der Einzelheiten des Quellcodes
– Bis zur Offenlegung der Einzelheiten einer Klasse

Programmierung
• Viele Tools unterstützen die Generierung von Code aus UML-Diagrammen
• Wechselseitige Anwendung von FE und RE bezeichnet man als Round-Trip
Engineering
Einleitung
(Einsatzmöglichkeiten von UML)

UML ist eine graphische Sprache zur
• Visualisierung
• Spezifikation
• Konstruktion und
• Dokumentation
objektorientierter Systeme in der Entwicklung

Basis eines defacto Standards für
• OOA (Object Oriented Analysis)
• OOD (Object Oriented Design)
Historie zu Programmiersprachen
Quelle: Oestereich, 2006
Historie von UML
Quelle: Oestereich, 2006
Sichten und Diagramme

UML-Konstrukte lassen sich nach verschiedenen Sichten einteilen

Sicht (View)
• Betrachtung des Softwaresystems aus einer bestimmten Perspektive
• Fokussierung auf einen speziellen Sachverhalt

Verschiedene Sichten sinnvoll, da
• bei Erstellung eines Softwaresystems verschiedene Personengruppen
involviert sind
• verschiedene Sichtweisen auf denselben Sachverhalt hilfreich für das
Verständnis sein können

Unterteilung der Sichten in drei Hauptbereiche
• Struktur
• Dynamik und
• Modell-Management
Sichten und Diagramme
Quelle: Syrjakow, TFH Wildau
UML Diagrammtypen

Klassendiagramme

Aktivitätsdiagramme

Objektdiagramme

Kommunikationsdiagramme

Sequenzdiagramme

Kompositionsstrukturen

Paketdiagramme

Komponentendiagramme

Einsatzdiagramme

Kollaborationen

Anwendungsdiagramme

Interaktionsdiagramme

Zustandsdiagramme

Zeitdiagramme
Klassendiagramme

bilden den Kern von UML

zeigen die Elemente eines Systems, ihre Inhalte
und Beziehungen

geben die logische (statische) Struktur des Systems
wieder
Kassendiagramme
Quelle: Fowler, 2004
Kassendiagramme (fortgeschritten)

Qualifizierte Assoziation
class Auftrag
public Auftragsposition getPositionsartikel(Produkt einProdukt);
public void addPositionsartikel(Zahl zahl, Produkt fürProdukt);

Klassenbezogene Operationen und Attribute

Schnittstellen und abstrakte Klassen

Gelenknotation
private List positionsartikel = new ArrayList();

Parametrissierte Klassen (Template Klassen)
• Ursprünglich aus C++
• Jetzt auch Java, C#
class Menge<T>
void insert(T newElement);
void remove(T oldElement);
Objektdiagramme

Oft gibt es Situationen, in denen man mit einem
Klassendiagramm eine Struktur ganz genau zeigen
kann, ohne das diese dabei allerdings anschaulich
wird

Ein Objektdiagramm
zeigt Instanzen statt
Klassen
¾ Instanzdiagramm

Sind nützlich, wenn
Beispiele für
miteinander verbundene
Objekte zeigen möchte
Sequenzdiagramme

dienen zur schematischen Veranschaulichung von zeitbasierten
Vorgängen

zeigen den Nachrichtenaustausch/Zusammenarbeit zwischen
verschiedenen Objekten unter Betonung der zeitlichen Abfolge

chronologische Darstellung von Objekten, die Botschaften
austauschen, auf einer Zeitachse

Eigenen sich weniger um das Verhalten präzise zu definieren
• Zustandsdiagramm: Verhalten eines Objekts über mehrere
Anwendungsfälle hinweg
• Aktivitätsdiagramm: Verhalten über viele Anwendungsfälle oder Threads
beobachten

Graphische Darstellung
• beteiligte Objekte werden horizontal angeordnet
• jedes Objekt hat eine Lebenslinie (Lifeline), die vertikal aufgetragen wird
• Nachrichten (Messages) = Pfeile zwischen den Lebenslinien der beteiligten
Objekte
Sequenzdiagramme
(zur zentralen Steuerung)
Sequenzdiagramme
(zur verteilten Steuerung)
Paketdiagramme

Schaffen bei großen Systemen Überblick über die
Abhängigkeiten zwischen den größeren
Systembestandteilen

Passen gut mit gebräuchlichen
Programmierstrukturen zusammen

Sind ein Mechanismus zur Zusammenfassung von
Elementen zur Kompilierungszeit
• Wenn man allerdings zeigen möchte wie Objekte zur
Laufzeit zusammengesetzt sind, verwendet man
Kompositionsstrukturdiagramme
Paketdiagramme
Zustandsdiagramme

Beschreiben das Verhalten eines Objekts über
mehrere Anwendungsfälle hinweg
• Weniger gut geeignet, um das Verhalten mehrerer
zusammenarbeitender Objekte zu erklären

Werden oft auch zusammen mit anderen
Diagrammformen verwendet

Kann auch zur Veranschaulichung von
Steuerobjekten und Elementen der
Benutzeroberfläche verwendet werden
Zustandsdiagramme
(Beispiel: geheimes Schaltpult)
Zustandsdiagramme
(Geschachtelte, nebenläufige, orthogonale
Zustände)

Die Stärke von Aktivitätsdiagrammen liegt darin, dass sie
Parallelismus unterstützen
• Werkzeug zur Modellierung von Workflows und
Geschäftsprozessen
• UML 2 wurde maßgeblich von Workflow-Modellierern geprägt

Auch für Flussdiagramme einsetzbar

Für parallele Algorithmen und nebenläufige Programme
• Wenig eingesetzt, u.a. weil sie nicht offenlegen wo es zu
Datenverklemmungen kommen kann

Beschreibung von Anwendungsfälle
• Gefahr das diese von Zielpersonen nicht gelesen werden können
Weitere Diagramme (1)

Einsatzdiagramme
• Zeigen physikalische Anordnung eines Systems (welche
Hard- und Software wo eingesetzt wird)

Anwendungsdiagramme
• Modellierung von Anwendungsfällen

Kommunikationsdiagramme
• Sind eine Art Interaktionsdiagramm (Sequenzdiagramm)
• Freie Anordnung der beteiligten Komponenten und
Verbindung durch nummerierte Pfeile
• Betonen Objektbeziehungen besser als Sequenzdiagramme
• In UML 1.x als Kollaborationsdiagramme bezeichnet

Kompositionsstrukturen
• Neuerung in UML 2.0
• Zerlegung einer Klasse (komplexes Objekt in seine Einzelteile)
• Eigenen sich zur Darstellung von Komponenten und Bestandteilen
von Komponenten
• Paketdiagramme sind ähnlich, liefern aber eine
Zusammenfassung von Komponenten zur Kompilierungszeit

Komponentendiagramme
• Darstellung von UML 1 zu UML 2 leicht verändert
• Geeignet zur Zerlegung eines Systems in Komponenten
– Aufzeigen von gegenseitigen Beziehungen durch Schnittstellen
– Schachtelung von Komponenten

Kollaborationen
• Stammt aus UML 1, kein offizielles Diagramm von UML 2
(Kompositionsdiagramm)
• Möglichkeit Interaktionsverhalten zu gruppieren, wenn die
unterschiedlichen Rollen von verschiedenen Klassen übernommen werden
• Sehr wenig verwendet

Interaktionsdiagramme
• Neu in UML 2
• Kombination aus Aktivitäts- und Sequenzdiagramme

Zeitdiagramme
• In der Elektrotechnik schon länger verwendet
• Besondere Rolle bei Hardwareentwicklern
• Nützlich, um Zeiteinschränkungen zwischen Zustandsänderungen
unterschiedlicher Objekte zu zeigen
Übersicht der Diagramme
Model Driven Architekture (MDA)

Oft erwähnt im Zusammenhang mit UML

Stammt ebenfalls von der Object Management Group (OMG)

Probleme bei der Softwareentwicklung
• Termintreue
• Programmfehler
• Geringe Akzeptanz der Anwender
• Ineffizienz der Entwicklung

Diskussion um das optimale Vorgehen bei der Software-Entwicklung
• Evolution der Programmiersprachen: Assembler, 3- und 4-GLs, OOSprachen
• Komplexität der Anwendungen (Verteilung, Sicherheit, Performanz), sowie
der Platformen moderner Systeme hat sich weiter vergrößert
• Vereinfacht ausgedrückt ist Modellierung die nächste (Sprach-) Stufe, um
der Komplexität zu begegnen
Model Driven Architekture (MDA)
Quelle: Petrasch, 2006
MDA und UML

MDA nutzt UML als Basismodelliersprache

MDA teilt die Entwicklungsarbeit in 2 Hauptbereiche:
• Modellierer stellen eine bestimmte Applikation dar, indem sie ein
plattformunabhängiges Modell bauen
(Platform Independent Model, PIM)
– ist ein UML-Modell
– Hängt von keiner Technologie ab
• Werkzeuge wandeln ein PIM in ein plattformspezifisches Modell
um (Platform Specific Model, PSM)
– Modell eines Systems für konkrete Anwendungsumgebung
– Kann in UML verfasst sein, muss aber nicht
– Aus PSM kann dann Code erzeugt werden
SW-Architekturen mit MDA

MDA umfasst eine Sammlung von
Einführungen, Spezifikationen,
Empfehlungen und Hinweise auf
Produkte

Basierend auf historischen
Konzepten wie:
•
Code-Generierung
•
Executable UML
•
Formales UML (OCL)
•
Komponenten-basierte
Softwareentwicklung
•
Metamodellierung
•
Domain Specific Languages
•
Architekturmuster und –stile für SWSysteme
•
Forward-Engineering
•
Analyse und Design Patterns
•
Modelltransformationen
Quelle: Petrasch, 2006
Offizielles Symbol der MDA
Software Tools

UML
• Poseidon for UML (http://www.gentleware.com)
– Apollo for Eclipse
• Omondo Eclipse UML (http://www.omondo.de)
• Innovator
• Jude

MDA
• http://www.programmiermaschine.de (Herr Brunthaler)
• Enterprise Architect (David Schilling)
Literatur und Quellen

Martin Fowler, UML konzentriert, Addison-Wesley,
3. Auflage, 2004

Roland Petrasch & Oliver Meimberg, Model Driven
Architecture, DPunkt-Verlag, 2006

Bernd Oesterreich, Analyse und Design mit UML
2.1, 8. Auflage, Oldenburg-Verlag, 2006