E183 - Institut f. Rechnergestützte Automation Department of Automation Forschungsgruppe für Industrielle Software (INSO) www.inso.tuwien.ac.at E188 - Institut f. Softwaretechnik und Interaktive Systeme, Information & Software Engineering Group Quality Software Engineering (QSE) Research qse.ifs.tuwien.ac.at UML Tutorial Erik Gostischa-Franta Vienna University of Technology Institute of Software Technology and Interactive Systems gostischa-franta@qse.ifs.tuwien.ac.at http://qse.ifs.tuwien.ac.at Inhalt 1. UML Einführung & Domänen 2. Anwendungsfall-diagramm 3. Anwendungsfall-beschreibung 4. Klassendiagramme Institut f. Softwaretechnik und Interaktive Systeme, IFS, Quality Software Engineering (QSE) Research 2
UML Allgemein 1/2! UML, Unified Modelling Language, ist standardisiert! UML ist Standardsprache für Visualisierung, Spezifikation, Konstruktion und Dokumentation komplexer Softwaresysteme.! UML kombiniert Konzepte aus:! Objektorientierter Modellierung! Datenmodellierung (Entity Relationship Diagrams)! Business-Modellierung (work flow)! Component Modeling! UML bietet Entwicklern und Kunde die Möglichkeit zur Diskussion von z.b. Softwareentwürfen und -entwicklungen auf einer einheitlicher Basis. Institut f. Softwaretechnik und Interaktive Systeme, IFS, Quality Software Engineering (QSE) Research 3 UML Allgemein 2/2 Die Unified Modelling Language ist: nicht perfekt nicht vollständig keine Programmiersprache keine rein formale Sprache nicht spezialisiert auf ein Anwendungsgebiet kein vollständiger Ersatz für Textbeschreibung keine Methode oder kein Vorgehensmodell Institut f. Softwaretechnik und Interaktive Systeme, IFS, Quality Software Engineering (QSE) Research 4
Diagramme der UML Strukturdiagramme Verhaltensdiagramme Klassen- Paket- Objekt- Kompositionsstruktur- Komponenten- Verteilungsdiagramm Use-Case- Aktivitäts- Zustandsdiagramm Interaktionsdiagramme Sequenz- Kommunikations- Timing- Interaktionsübersichtsdiagramm! Gekennzeichnete Diagramme werden häufig in der SE&PM LU verwendet. Institut f. Softwaretechnik und Interaktive Systeme, IFS, Quality Software Engineering (QSE) Research 5 Zweck des UML-Tutorials! Using UML! Praktische Verwendung von UML im Software Engineering! Schon zu Projektbeginn wird mit UML Modelliert (z.b.domänenmodell), aber im weiteren Projektverlauf steht mehr und mehr echte Software hinter dem Konzeptionellen Modell.! Vorbereitung auf das Einzelbeispiel und Gruppenphase! Wo und Wie soll UML Verwendet werden?! UML Anwendungsfälle: Erhebung der Anforderungen! UML Klassendiagramme: Technisches Design & Projektplanung! Inhalt des UML Tutorials ist Prüfungsstoff für den Einstiegstest! Grundkenntnissen der Programmierung (EPROG, OOP) und Domänenmodellierung (Datenmodellierung, OOM) sind notwendig um die in diesem Tutorial beschriebenen Konzepte und Vorgehensweisen anzuwenden. Institut f. Softwaretechnik und Interaktive Systeme, IFS, Quality Software Engineering (QSE) Research 6
Domäne "MP3-Player" Anhand einer MP3-Player Applikation soll hier im weiteren Verlauf UML an praktischen Beispielen erläutert werden. Es handelt sich um ein sehr einfaches System zum:! Abspielen von Musik! Playlist Verwaltung! Importieren/Suchen/Löschen/Sortieren! Verwalten von Musik Dateien! Create, Read, Update, Delete (CRUD)! Anzeigen von musikspezifischen Infos! LastFM, Lyric Wiki, MusicBrainz Institut f. Softwaretechnik und Interaktive Systeme, IFS, Quality Software Engineering (QSE) Research 7 Domäne "Bibliotheksverwaltungssystem" Anhand eines Bibliotheksverwaltungssystem soll hier im weiteren Verlauf UML an praktischen Beispielen erläutert werden. Es handelt sich um ein sehr einfaches System zur:! Verwaltung der Bücher! Buchdaten, Zustandsbeschreibungen, Standortinformationen! Verwaltung der personenbezogenen Daten! Mitarbeiter und Kunden! Tägliche Routine! Suchen und Ausleihen der Bücher Institut f. Softwaretechnik und Interaktive Systeme, IFS, Quality Software Engineering (QSE) Research 8
Inhalt 1. UML Einführung & Domänen 2. Anwendungsfall-diagramm 3. Anwendungsfall-beschreibung 4. Klassendiagramme Institut f. Softwaretechnik und Interaktive Systeme, IFS, Quality Software Engineering (QSE) Research 9 UML Anwendungsfälle Ein Anwendungsfall (engl. use case) beschreibt das Verhalten eines Aktors, welches einen Teil der Funktionalität des Gesamtsystems repräsentiert. Ein Anwendungsfall sollte primär einen logischen zusammengehörigen, wiederkehrende Ablauf von Aktionen innerhalb des Systems darstellen welcher ein beobachtbares Resultat für den Aktor zu folge hat. Was definiert einen Anwendungsfall?! Name: kurzer Ausdruck mit einem möglichst starken Verb! Primäre Aktoren, Vorbedingungen, Nachbedingungen, Szenario, Alternativszenario (Anwendungsfallbeschreibung) Anwendungsfälle können mit einem Anwendungsfalldiagramm graphisch dargestellt werden. Institut f. Softwaretechnik und Interaktive Systeme, IFS, Quality Software Engineering (QSE) Research 10
UML Anwendungsfalldiagramm Übersicht Kommunikationslinie <include> Include Beziehung <extends> Extends Beziehung Generalisierung Institut f. Softwaretechnik und Interaktive Systeme, IFS, Quality Software Engineering (QSE) Research 11 UML Extension Points! Anwendungsfalldiagramm! Anwendungsfallbeschreibung 12 Name: Bücher suchen Primärer Aktor:... Vorbedingungen:... Szenario: 1.... 2. Extension Point: Suchergebnis drucken 3....
Aktorenhierarchie Ein Aktor ist ein bestimmter Benutzer, der im System genau definierte Rechte und Aufgaben hat. Ein Aktor benützt das System und führt Anwendungsfälle aus. Aktorenliste Aktorename Rechte Anmerkungen Beziehungs- Hierarchie Admin (AD) Mitarbeiter (MA) Uneingeschränkte Rechte im System Darf neue Bücher anlegen und bestehende Bücherdaten ändern, kann auch neue Bücher bei diversen Büchhändlern bestellen Systemtechniker besitzen uneingeschränkten Zugriff auf alle Bereiche im System Keine Kunde (KD) Kann Bücher suchen, reservieren und bestellen Dieser User kann keine bestehenden Daten ändern außer die von ihm angelegten Reservierungen Institut f. Softwaretechnik und Interaktive Systeme, IFS, Quality Software Engineering (QSE) Research 13 Anwendungsfalldiagramm! Ein Anwendungsfall wird in Form einer Ellipse dargestellt.! Die Bezeichnung des Anwendungsfalls wird in die Ellipse eingeschrieben.! Ein Anwendungsfalldiagramm wird durch seine Systemgrenzen definiert.! Akteure stehen klar außerhalb des Systems! Ein Aktor hat genau dann eine Beziehung zu einem Anwendungsfall, wenn er ermächtigt ist, diesen durchzuführen bzw. mit diesen zu kommunizieren Institut f. Softwaretechnik und Interaktive Systeme, IFS, Quality Software Engineering (QSE) Research 14
Anwendungsfall Beispiele! MP3-Player: save playlist, delete song listen to playlist-mix, play recently imported songs maintain music library, collect song information = system-level use case = user-level use case = enterprise-level use case! Bibliotheksverwaltung: verschicke E-Mail Benachrichtigung, Buch speichern Buch entlehnen, Buch reservieren, Student eintragen Buch katalogisieren, gesamten Buchbestand erfassen = system-level use case = user-level use case = enterprise-level use case Institut f. Softwaretechnik und Interaktive Systeme, IFS, Quality Software Engineering (QSE) Research 15 Abstraktionsstufen! Es werden drei Arten von Anwendungsfällen unterschieden! System Level: Buch speichern (z.b. in der Datenbank)! User Level: Buch entlehnen (auch User Goals genannt)! Enterprise-Level: Buchbestand katalogisieren! Alle UML Diagrammarten haben Abstraktionsstufen! Z.B. Klassendiagramme:! Domänenmodell! Komponentendiagramm! Klassendiagramm (Impl)! Ein gutes UML Tool erlaubt Einfügen eines Modelelements in mehreren UML Diagrammen! Ein UML Diagramm ist ein Ausschnitt des UML Models. Institut f. Softwaretechnik und Interaktive Systeme, IFS, Quality Software Engineering (QSE) Research 16
Modelle und Diagramme! Im Anwendungsfalldiagramm udx1 realisiert die Kollaboration einen Anwendungsfall.! Jene Kollaboration wird im Klassendiagramm cdx2 von Klassen A und B implementiert.! Verhalten der Klassen in X2 wird im Sequenzdiagramm sdx3 dargestellt.! Ein UML-Modell ist eine Menge von Modellelementen (Klassen, Attribute, Interaktionen, Anwendungsfälle, etc.)! Ein UML-Diagramm ist eine graphische Darstellung eines Ausschnitts des Modells (eine Sicht auf ein Modell)! Elemente in unterschiedlichen Diagrammen können sich auf ein und das selbe Modellelement beziehen. Institut f. Softwaretechnik und Interaktive Systeme, IFS, Quality Software Engineering (QSE) Research UML Anwendungsfälle Übungsbeispiel 1! Welcher User hat mehr Rechte im System, Admin oder Mitarbeiter?! Welche Anwendungsfälle kann der Mitarbeiter ausführen?! Welche Anwendungsfälle kann der Admin ausführen? Institut f. Softwaretechnik und Interaktive Systeme, IFS, Quality Software Engineering (QSE) Research 18
UML Anwendungsfälle Übungsbeispiel 2! Modellieren Sie folgende Anwendungsfälle:! Im System gibt es die User Mitarbeiter und Admin.! User Admin hat mehr Rechte im System als Mitarbeiter.! Beide können sich im System einloggen.! Nach dem Einloggen können beide ihr persönliches Passwort ändern.! Weiters haben beide die Möglichkeit neue Buchdaten einzugeben.! Der Admin hat außerdem noch die Möglichkeit Benutzer zu sperren und neue Benutzer anzulegen. Institut f. Softwaretechnik und Interaktive Systeme, IFS, Quality Software Engineering (QSE) Research 19 UML Anwendungsfälle Übungsbeispiel 2 Lösung Institut f. Softwaretechnik und Interaktive Systeme, IFS, Quality Software Engineering (QSE) Research 20
UML Anwendungsfälle Übungsbeispiel 3! Modellieren Sie folgende Anwendungsfälle:! Ein Student kann sich in der Bibliotheksverwaltung entweder per Matrikelnummer/Passwort oder per Retinascan einloggen.! Der Student kann Bücher suchen! Beim Suchen nach Bücher kann entschieden werden ein bestimmtes Buch zu entlehnen.! Um ein Buch zu entlehnen muss der Student eingeloggt sein. Institut f. Softwaretechnik und Interaktive Systeme, IFS, Quality Software Engineering (QSE) Research 21 UML Anwendungsfälle Übungsbeispiel 3 Lösung Student Institut f. Softwaretechnik und Interaktive Systeme, IFS, Quality Software Engineering (QSE) Research 22
Inhalt 1. Einführung in UML 2. Anwendungsfalldiagramm 3. Anwendungsfallbeschreibung 4. Klassendiagramme Institut f. Softwaretechnik und Interaktive Systeme, IFS, Quality Software Engineering (QSE) Research 23 UML Anwendungsfallbeschreibung Jeder Anwendungsfall bedarf einer genauen Beschreibung, die man wie folgt einteilen kann: 1. Identification summary : Titel des Anwendungsfalles (2-7 Wörter mit starkem Verb) Scope (Use Case Package) Level (User, System, Enterprise) Welche Aktoren sind beteiligt Kurzbeschreibung des Anwendungsfalles ( Aktor interests ) 2. Scenarios : Vorbedingungen Hauptszenario Fehlersituationen Alternativszenario Voraussetzungen für erfolgreiche Ausführung (andere Use Cases) was soll abgebildet werden was passiert im Fehlerfall, Systemzustand gibt es Alternativabläufe, wo sind die Abweichungen? Nachbedingungen Systemzustände nach erfolgreicher Ausführung (andere Use Cases) 3. Non-functional constraints - NFAs, Bemerkungen, Angaben über Häufigkeit, Institut f. Softwaretechnik und Interaktive Systeme, IFS, Quality Software Engineering (QSE) Research 24
Anwendungsfallbeschreibung Beispiel 1/2 1. Identification summary Titel: Buch suchen Scope: Suche Level: User Goal Aktoren: Student Kurzbeschreibung: Der Student sucht nach einem bestimmten Buch. 2. Scenarios : Vorbedingungen: Student authentifizieren/einloggen Hauptszenario: Der Anwender gibt die Suchkriterien für ein Buch ein (Titel, Autor, Verlag, Kategorie). Das System zeigt die zu den Kriterien gefundenen Bücher an. Der Anwender wählt einen Datensatz aus und die Liste mit den Suchergebnissen wird geschlossen. Fehlerszenario: Kann der Connect zur Datenbank nicht aufgebaut werden, dann wird noch 2x versucht den Connect zur DB herzustellen. Sind alle 3 Versuche erfolglos wird eine Fehlermeldung ausgegeben. Alternativszenario: Das System kann kein Buch zu den angegebenen Kriterien finden, es wird eine Fehlermeldung ausgegeben. Nachbedingungen: Student kann ein gefundenes Buch entlehnen (andere Use Cases) Institut f. Softwaretechnik und Interaktive Systeme, IFS, Quality Software Engineering (QSE) Research 25 Anwendungsfallbeschreibung Beispiel 2/2 1. Identification summary 2. Scenarios : 3. Nonfunctional Constraints oder Special Requirements Der User sollte nicht zu lange auf das Suchergebnis warten müssen (max. 10 sek) Der Anwendungsfall Buch suchen wird sehr häufig in einer Bibliothek Verwendung finden. Institut f. Softwaretechnik und Interaktive Systeme, IFS, Quality Software Engineering (QSE) Research 26
Scenario Darstellungsformen 1. User Story 1. Eine User Story (Benutzergeschichte) ist eine in Alltagssprache formulierte Anforderung an die Software und umfasst in der Regel nicht mehr als ein paar Sätze. 2. Liste von Aktivitäten 1. Der Ablauf des Anwendungsfalls wird in Teil-Abläufe (Aktivitäten) zerteilt und als nummerierte Liste aufgeschrieben. Dieser Stil ermöglicht leichtes referenzieren von anderen Anwendungsfällen (extend, include). 3. Ereignis/Aktions Stil ( Flow of Events ) 1. Um viele Verzweigungen im Ablauf oder viele Alternativ- bzw. Fehlerszenarien übersichtlich darzustellen ist der Ereignis/Aktions Stil sehr hilfreich. 4. Aktivitätsdiagramm 1. Um den Ablauf eines Anwendungsfalls übersichtlich darzustellen, etwa für ein Management Review, kann von einer User Story oder Liste von Aktivitäten ein UML Aktivitätsdiagramm gezeichnet werden. Institut f. Softwaretechnik und Interaktive Systeme, IFS, Quality Software Engineering (QSE) Research 27 Flow of Events Scenario Häufige Anwendung finden auch Beschreibungen die in Ereignis und Aktion aufgegliedert werden: E1) Der Anwender gibt Suchkriterien für ein Buch ein. (Titel, Autor, Kategorie) A1) Das System sucht nach Büchern, die den eingegebenen Suchkriterien entsprechen. E2) Es existieren Bücher, die den angegeben Suchkriterien entsprechen A2) Die Daten der Bücher werden angezeigt AE2) Es wurde kein Buch mit den angegeben Suchkriterien gefunden AA2) Fehlermeldung ausgeben AE3) Mit diesen Kriterien wurden zu viele Bücher gefunden AA3) Der Benutzer wird aufgefordert, die Suchkriterien zu verfeinern E3) Der Anwender wählt einen der angezeigten Datensätze aus A3) Die Liste mit den Suchergebnissen wird geschlossen und der ausgewählte Datensatz eventuell als Parameter an einen weiteren Anwendungsfall übergeben Institut f. Softwaretechnik und Interaktive Systeme, IFS, Quality Software Engineering (QSE) Research 28
Liste von Aktivitäten mit UML Aktivitätsdiagramm Auch UML Aktivitätsdiagramme können verwendet werden um das Szenario eines Anwenungsfalls zu beschreiben: Institut f. Softwaretechnik und Interaktive Systeme, IFS, Quality Software Engineering (QSE) Research 29 Inhalt 1. Einführung in UML 2. Anwendungsfalldiagramm 3. Anwendungsfallbeschreibung 4. Klassendiagramme Institut f. Softwaretechnik und Interaktive Systeme, IFS, Quality Software Engineering (QSE) Research 30
UML Klassendiagramm Sichtbarkeit 1. Abschnitt 2. Abschnitt 3. Abschnitt Public (+) Private (-) Protected (#) Package (~) Jedes andere Element hat uneingeschränkten Zugriff. Nur Instanzen der Klasse, die das Attribut definiert, dürfen zugreifen. Nur Instanzen der Klasse, die das Attribut definiert, und Instanzen abgeleiteter Klassen dürfen zugreifen. Das Attribut ist für alle Elemente, die sich im selben Packet wie die definierte Klasse befinden, sicht- und zugreifbar. Ad 1) Klassename und Schlüsselwörter (Zwingend) Ad 2) Attribute (Attributname: Typ) (Optional) Ad 3) Methoden, die die Klasse ausführen kann (Verhalten der Klasse) (Optional) Institut f. Softwaretechnik und Interaktive Systeme, IFS, Quality Software Engineering (QSE) Research 31 UML Klassendiagramm Assoziationen 1/2 Klassen stehen zueinander in unterschiedlichen Beziehungen. Dies wird in Assoziationen dargestellt. Jede Assoziation wird durch eine Kardinalität mitbestimmt. Diese gibt an, wie viele Instanzen einer Klasse zu einer Instanz der Klasse am gegenüberliegenden Ende der Assoziation in Beziehung stehen können. An den Enden der Linie werden die Kardinalitäten angegeben, welche folgende Formen haben können:! Ein beliebiger Wert aus den natürlichen Zahlen wird durch einen Stern dargestellt (d.h. 0 bis beliebig viele) Institut f. Softwaretechnik und Interaktive Systeme, IFS, Quality Software Engineering (QSE) Research 32
UML Klassendiagramm Assoziationen 2/2 Ein einzelner ganzzahliger positiver Wert (z.b. 1) Ein Bereich von Werten, wobei der niedrigste vom höchsten Wert durch zwei Punkte getrennt ist Institut f. Softwaretechnik und Interaktive Systeme, IFS, Quality Software Engineering (QSE) Research 33 UML Klassendiagramm Generalisierung! Allgemeine Gemeinsamkeiten werden in so genannten Oberklassen zusammengefasst. Generalisierung ist eine Relation zwischen einem allgemeineren (Eltern-) und einem spezielleren (Kind-) Element.! Das Kindelement ist mit dem Elternelement verträglich und fügt weitere Informationen hinzu.! Ein typisches Beispiel dafür ist Mitarbeiter und Kunde. Institut f. Softwaretechnik und Interaktive Systeme, IFS, Quality Software Engineering (QSE) Research 34
UML Klassendiagramm Aggregation! Eine Aggregation drückt eine Teile-Ganzes-Beziehung aus.! Im Kern ist die Aggregationsbeziehung nichts anderes als eine abkürzende Schreibweise der Rollen besteht aus und ist Teil von! Dieses Beispiel bedeutet, dass ein Mensch Teil keiner, einer oder mehrerer Personengruppen ist. Eine Personengruppe besteht aus mind. einer Personen, kann aber auch mehrere Personen beinhalten. Institut f. Softwaretechnik und Interaktive Systeme, IFS, Quality Software Engineering (QSE) Research 35 UML Klassendiagramm Komposition! Eine strengere Form des Zusammenhanges wird durch die Komposition definiert. Teile und Ganzes bilden eine Einheit.! Deshalb gilt hier auch die verschärfende Einschränkung, dass ein Teil zu einem Zeitpunkt genau einem Ganzen zugeordnet sein darf.! Die Lebensdauer der Teile hängt von der Leibensdauer des Ganzen ab. Wird das Ganze zerstört, sterben auch die dazugehörigen Teile. Institut f. Softwaretechnik und Interaktive Systeme, IFS, Quality Software Engineering (QSE) Research 36
UML Sichten auf Softwarestrukturen! Konzeptionelle Sicht Gibt eine Übersicht über den zu untersuchten Problembereich z.b. Domänenmodell! Spezifizierende Sicht Hier betrachten wir Software, aber wir betrachten Schnittstellen, keine Implementierungen. z.b. Komponentendiagramm! Implementierende Sicht Bei dieser Sichtweise haben wir wirklich Klassen, und wir legen die Grundlage für die Implementierung. Dies ist vermutlich die am häufigsten eingenommene Betrachtungsweise. z.b. Klassendiagramm nach Martin Fowler und Kendall Scott: UML konzentriert Institut f. Softwaretechnik und Interaktive Systeme, IFS, Quality Software Engineering (QSE) Research 37 Konzeptionelle Sicht! Beispiel: MP3-Player Domänenmodell! Klassifizierung der Objekte der Realen Welt (Anwendungsbereich der Applikation) Institut f. Softwaretechnik und Interaktive Systeme, IFS, Quality Software Engineering (QSE) Research 38
Spezifizierende Sicht! Beispiel:! MP3-Player Komponente Persistance! Interfaces! ITaggingDAO! ISongDAO! Benötigte Typen (Interfaces)! javax.sql.datasource Institut f. Softwaretechnik und Interaktive Systeme, IFS, Quality Software Engineering (QSE) Research 39 Implementierende Sicht! Beispiel:! MP3-Player Playlist Feature Klassendiagramm! Patterns:! Interface! Facade! Data Access Object Institut f. Softwaretechnik und Interaktive Systeme, IFS, Quality Software Engineering (QSE) Research 40
Komponentenorientierter Entwurf mit UML Klassendiagrammen! Das Domänenmodell entsteht im Projektverlauf als erstes! Multiplizitäten der Assoziationen, auch Aggregats und Kompositionsbeziehungen, sollen Verwendet werden.! Falls bereits bekannt bzw. wichtig, können Attribute der Klassen eingezeichnet werden.! UML Stereotypen << >> können verwendet werden um Klassen zu typisieren für eine spätete Verfeinerung (sog. UML-Profiles) Institut f. Softwaretechnik und Interaktive Systeme, IFS, Quality Software Engineering (QSE) Research 41 UML Klassendiagramm Übungsbeispiel 1/2 (Implementations-Sicht)! Ein Buch kann entweder ein Sachbuch oder ein Roman sein.! Ein Sachbuch hat einen Titel, eine Nummer und ein Wissenschaftsgebiet.! Ein Roman hat eine Nummer, einen Titel und Seitenzahlen als Attribute.! Die Nummer des Buches wird immer mit 1 initialisiert.! Eine Roman ist entlehnbar. Ein Sachbuch nicht. Bei beiden kann man sich jedoch ein Datenblatt ausdrucken lassen.! Jeder Raum einer Bibliothek enthält Bücher.! Eine Bibliothek kann mehrere Räume haben, hat eine Adresse, eine Bezeichnung, einen Fachbereich und eine eindeutige Nummer.! Ein Raum hat eine Raumnummer, die mit 01 initialisiert wird, und eine Bezeichnung Institut f. Softwaretechnik und Interaktive Systeme, IFS, Quality Software Engineering (QSE) Research 42
UML Klassendiagramm Übungsbeispiel 1/2 Lösung Institut f. Softwaretechnik und Interaktive Systeme, IFS, Quality Software Engineering (QSE) Research 43 UML Klassendiagramm Übungsbeispiel 2/2 (Konzeptionelle-Sicht) Entwerfen Sie ein neues Domänenmodel aus folgendem Sachverhalt:! Eine Bibliothek besteht aus mehreren Fachabteilungen und aus mehreren Räumen.! Jede Fachabteilung hat verschiedene Kategorien bzw. ist auf mehrere Räume aufgeteilt.! In jedem Raum kann 1 oder mehrere Regale stehen.! Eine Kategorie besteht aus mehreren Büchern. Institut f. Softwaretechnik und Interaktive Systeme, IFS, Quality Software Engineering (QSE) Research 44
UML Klassendiagramm Übungsbeispiel 2/2 Lösung1 Institut f. Softwaretechnik und Interaktive Systeme, IFS, Quality Software Engineering (QSE) Research 45 UML Klassendiagramm Übungsbeispiel 2/2 Lösung2 Institut f. Softwaretechnik und Interaktive Systeme, IFS, Quality Software Engineering (QSE) Research 46
UML Klassendiagramm Zusammenfassung Mit Hilfe der Notation von UML Klassendiagrammen können in der SE&PM Übung folgende Arten von Daten modelliert werden! Domäneninformationen (Domänenmodell)! Systemkomponenten/Schnittstellen (UML Komponentendiagramm)! Struktur der implementierten OO Klassen (UML Klassendiagramm)! Auch Datenbankschemata können in UML Klassendiagrammnotation ausgedrückt werden, ER oder EER ist jedoch üblicher. Institut f. Softwaretechnik und Interaktive Systeme, IFS, Quality Software Engineering (QSE) Research 47 UML Ausblick: Management Reviews In der SE&PM Gruppenphase wird beim MR-2 verlangt die Systemarchitektur dem Assistenten zu präsentieren.! Architektur in SE&PM entsteht durch die Interaktion von vielen verschiedenen Arbeitsvorgängen! Modellierung, Design! Konfiguration; Verwendete Werkzeuge, Frameworks! Implementation; Patterns und Algorithmen! UML Diagramme für Management Reviews! Klassendiagramm aus der Konzeptionellen Sichtweise (Domänenmodell)! Anwendungsfälle, Use Cases! Verteilungsdiagramm, Komponentendiagramm (Spez. Sichtweise)! Klassendiagramme aus der Implementierenden Sichtweise eher Gruppen- (Entwickler-) interne Artefakte Institut f. Softwaretechnik und Interaktive Systeme, IFS, Quality Software Engineering (QSE) Research 48
Kritik: UML Diagramme zu fad für Management Reviews! UML & Beschreibung der Systemarchitektur! Aber:! Model: Domänenobjekte + Teile der Persistenz und Service(BL) Schicht! Struktur: Klassen-, Komponenten-, Verteilungsdiagramm! Verhalten: Anwendungsfall-, Aktivitäts-, (Zustands-, Sequenzdiagramm)! Bei MR s sollten Diagramme verwendet werden um eine Übersicht der Architektur zu bekommen.! Die meisten besprochenen Struktur Diagramme sind sehr technisch, kompliziert bzw. fad! UML & Erweiterungen (in SE&PM)! <<Stereotypen>>! Einbindung von Graphiken bzw. Farbliche Markierungen für Stereotypen Institut f. Softwaretechnik und Interaktive Systeme, IFS, Quality Software Engineering (QSE) Research 49 Bad-Practice Systemarchitektur! Unnötiges Eye-Candy! Statt Stereotypen, Wolke und Zylinder Graphiken verwendet! Die Komponenten selbst sagen wenig aus! Was wirklich interessant ist, sind die Verbindungen zwischen den Komponenten! Davon abgesehen, dass dies zwei völlig unterschiedliche Diagramme sind. Institut f. Softwaretechnik und Interaktive Systeme, IFS, Quality Software Engineering (QSE) Research 50
Verteilungsdiagramm Beispiel (ASE LU) Institut f. Softwaretechnik und Interaktive Systeme, IFS, Quality Software Engineering (QSE) Research 51 Komponentendiagramm Beispiel (ASE LU) Institut f. Softwaretechnik und Interaktive Systeme, IFS, Quality Software Engineering (QSE) Research 52
Andere nützliche UML Diagramme (SE&PM Eingangsphase)! Struktur der Software Schichtendiagramme Können mittels UML-Packages modelliert werden Schicht impliziert Zugriff (Access) nach unten! Verhalten der Software UML Aktivitätsdiagramme Als Unterstützung bei Use Cases Institut f. Softwaretechnik und Interaktive Systeme, IFS, Quality Software Engineering (QSE) Research 53 UML Book to get for SE&PM and ASE! Beginner Perdita Stevens; Using UML: Software Engineering Objects and Components; 2nd Edition, 02.2006, Addison Wesley, 272 Seiten, 0321269675! Intermediate Grady Booch, James Rumbaugh, Ivar Jacobson; The Unified Modeling Language User Guide; 2nd Edition, 05.2005, Addison Wesley, 496 Seiten, 0321267974! Advanced Craig Larman; Applying UML and Patterns: An Introduction to Object Oriented Analysis and Design and Interactive Development; 3rd Edition, 11.2004, Prentice Hall, 736 Seiten, 0131489062! OR: Any UML Book that has using or applying as a Focus Point " Institut f. Softwaretechnik und Interaktive Systeme, IFS, Quality Software Engineering (QSE) Research 54