UML Modelle
This commit is contained in:
		
							parent
							
								
									0c42cf9ba9
								
							
						
					
					
						commit
						f8e5954ad6
					
				| @ -116,11 +116,219 @@ Modelle für: | ||||
| ## Objektorientierung | ||||
| - bessere Strukturierung für komplexe Zusammenhänge | ||||
| - Abstraktere Sichtweise | ||||
| - Objekt hat | ||||
| - Grundprinzip: Zerlegung; Teile und Herrsche | ||||
| - ein System besteht aus vielen Objekten | ||||
| - ein Objekt hat | ||||
|   - definiertes Verhalten | ||||
|     - Menge genau definierter Operationen | ||||
|     - Operation wird beim Empfang einer Nachricht ausgeführt | ||||
|   - inneren Zustand | ||||
|     - Zustand des Objekts ist Privatsache | ||||
|     - Resultat einer Operation hängt vom aktuellen Zustand ab | ||||
|   - eindeutige Identität | ||||
| - Klasse: gleichartige Objekte mit ggf versch Zu | ||||
|     - Identität ist unabhängig von anderen Eigenschaften | ||||
|     - Mehrere verschiedene Objekte mit identischem Verhalten und identischem inneren Zustand im gleichen System möglich | ||||
| - Klasse | ||||
|   - Gleichartige Objekte mit ggf. verschiedenen Zuständen | ||||
|   - Verhaltensschema – Operationen | ||||
|   - Innere Struktur – Attribute | ||||
| 
 | ||||
| Vorteile der Objektorientierung | ||||
| - Zuständigkeitsbereiche | ||||
|   - Daten, Operationen und Zustand: lokal und gekapselt | ||||
| - Klare Schnittstellen | ||||
|   - Definiertes Objektverhalten, Nachrichten | ||||
| - Hierarchie | ||||
|   - Vererbung und Polymorphie (Spezialisierung), Klassenschachtelung | ||||
| - Baukastenprinzip | ||||
|   - Benutzung vorgefertigter Klassenbibliotheken, Anpassung durch Spezialisierung (mittels Vererbung) | ||||
| 
 | ||||
| 
 | ||||
| ## Unified Modeling Language | ||||
| - Grafisches Beschreibungsmittel für Aspekte des Softwareentwurfs diskreter Systeme | ||||
|   - Spezifikation, Entwurf, Visualisierung, Konstruktion, Dokumentation von Software | ||||
|   - Für OO-Softwareentwicklung und -prozess geeignet | ||||
|   - UML ist weder Methode noch Prozess | ||||
| 
 | ||||
| Warum UML? | ||||
| - Objektorientierung ist zur Zeit das vorherrschende Modellierungs-Paradigma, Industrie-Standard | ||||
| - Kombination von Struktur-, Verhaltens-, Interaktions-, und Verteilungsmodellen | ||||
| - Für Analyse, Entwurf, Implementierung und Test einsetzbar | ||||
| - Gute Werkzeugunterstützung für Editieren, Versionierung, Codegenerierung | ||||
| - Erweiterbarkeit der UML mit Stereotypen und Tags | ||||
| - Semi-formale Modelle, z.T. verschiedene Interpretationen | ||||
| - Offenheit: Erweiterung mit stereotypes, tags, constraints | ||||
| 
 | ||||
| Nachteile UML | ||||
| - UML ist in vielen Facetten nicht präzise festgelegt | ||||
| - Werkzeuge für Transformation, Analyse etc. fehlen noch | ||||
| - UML ist keine „kleine Sprache“: Lernaufwand notwendig | ||||
| - Komponenten sind nicht adäquat darstellbar | ||||
| - Sprachen wie die UML werden erlernt durch Übung! | ||||
| - Aber: LV SWT ist kein kompletter UML-Kurs | ||||
| 
 | ||||
| ### Überblick über Modelle | ||||
| - 14 Diagrammarten | ||||
| - Struktur-Diagramme | ||||
|   - Klassen-, Objekt-, Komponenten-, Kompositions-Struktur-, | ||||
|   - Paket- und Verteilungsdiagramm | ||||
|   - Profildiagramm – zur UML-Erweiterung | ||||
| - Verhaltens-Diagramme | ||||
|   - Use-Case-, Aktivitäts- und Zustandsdiagramms | ||||
|   - Interaktionsdiagramme: Sequenz-, Kommunikations-, Timing- und Interaktionsübersichts-Diagramm | ||||
| 
 | ||||
| #### Use-Case-Diagramm | ||||
| - Beschreiben Systemfunktion aus Benutzersicht (Was, nicht Wie) | ||||
| - Erste Anforderungsspezifikation (requirements) | ||||
| - Planbare Einheiten als Inkremente für die Entwicklung | ||||
| - Keine Modellierung eines Ablaufs! | ||||
| - Erstellen von Testfällen (test case generation) | ||||
| - Grundelemente | ||||
|   - Anwendungsfall: Use Case | ||||
|   - Beteiligte: Aktor | ||||
| - Verfeinerung mittels Use-Case-Realisierung notwendig | ||||
|   - Textuelle Beschreibung | ||||
|   - Verhaltensdiagramme | ||||
| 
 | ||||
| #### Klassendiagramm | ||||
| - Modellierung der Struktur (Aufbau) eines Systems | ||||
| - Modellierung von statischen Aspekten | ||||
| - Modellierung der Struktur von Daten | ||||
| - Klasse im Mittelpunkt | ||||
|   - Aufbau: Attribute, Operationen | ||||
|   - Beziehungen zueinander: Assoziationen, Vererbung | ||||
| - Verbreitetstes und bekanntestes Diagramm der UML | ||||
| 
 | ||||
| #### Objektdiagramm | ||||
| - Struktur des Systems zur Laufzeit zu einem Zeitpunkt | ||||
| - Tatsächliche Zusammenhänge und Belegungen von Attributen von Objekten zu einem Zeitpunkt | ||||
| - Eine detaillierte Sicht auf einen Aspekt | ||||
|   - Keine vollständige Beschreibung (zu komplex) | ||||
|   - Für kompliziertere Abhängigkeiten (z.B. Rekursion) | ||||
| - Objektdiagramm für alle Arten von Exemplaren | ||||
|   - z.B.: Klasse (Objekt), Komponente, Knoten, ... | ||||
| - Keine Exemplare von Operationen -> Ablauf -> Verhaltensdiagramme / Interaktionsdiagramme | ||||
| - Kein Verlauf der Wertebelegung über die Zeit | ||||
| 
 | ||||
| #### Paketdiagramm | ||||
| - Gliederung (Strukturierung) des Systems in Teile (Pakete) | ||||
| - Zuordnung von Elementen zu einem Paket | ||||
| - Bildung von Hierarchien (Enthält-Beziehung) | ||||
| - Abhängigkeiten zwischen den Paketen | ||||
|   - "Include" von Quellcode-Dateien (<<import>>) | ||||
| - Anwendung: | ||||
|   - Zum Grobentwurf von Systemen | ||||
|   - Definition von Schichten | ||||
| 
 | ||||
| #### Komponentendiagramm | ||||
| - Strukturierung des Systems durch Komponenten | ||||
| - Komponente: Modulare, austauschbare Einheit (Substitution) | ||||
| - Modellierung der Abhängigkeiten zwischen Komponenten | ||||
| - Modellierung der inneren Struktur von Komponenten | ||||
| - Definition von Schnittstellen | ||||
| 
 | ||||
| #### Kompositionsstrukturdiagramm | ||||
| - Teile-Ganzes-Strukturen -> Kompositionsstruktur | ||||
| - Strukturell statische Kompositionsstrukturen: | ||||
|   - Kurzschreibweise bei vielen Kompositionen | ||||
|   - Modellierung des Aufbaus komplexer Systeme | ||||
| - Strukturell dynamische Kompositionsstrukturen: | ||||
|   - Notwendige Strukturen zur Realisierung eines Verhaltens | ||||
|   - Definition von Rollen, zur Lösung wiederkehrender Probleme -> Modellierung von Mustern | ||||
| - Starke Verwandtschaft mit dem Klassendiagramm | ||||
| - Spezialisierte Kompositionsbeziehung -> erweiterte Semantik | ||||
| 
 | ||||
| #### Aktivitätsdiagramm | ||||
| - Modellierung von | ||||
|   - Kontrollflüssen | ||||
|   - Datenflüssen | ||||
|   - Parallelem Verhalten | ||||
|   - Verzweigungen, bedingten und gewichteten Abläufen | ||||
| - Geschäftsprozessmodellierung möglich | ||||
| - Abstrakte und detaillierte Verhaltensbeschreibung möglich | ||||
| - Grundlage zur Codegenerierung | ||||
| - Zur Verfeinerung von | ||||
|   - Use-Cases | ||||
|   - Operationen / Interaktionen | ||||
|   - anderen Aktionen und Aktivitäten | ||||
| 
 | ||||
| #### Interaktionsdiagramme | ||||
| - Modellierung von | ||||
|   - Kommunikation zwischen Kommunikationspartnern (Lebenslinie) | ||||
|   - Operationen (Modellierung eines Programms) | ||||
|   - Informationsaustausch / Nachrichten | ||||
| - Gemeinsames Grundkonzept der Interaktionsdiagramme | ||||
| - Sehr detaillierte Diagramme | ||||
|   - Meist nicht zur vollständigen Beschreibung eines Systems | ||||
|   - Betrachtung eines wichtigen Teilaspekts | ||||
| - Grundlage zur Codegenerierung | ||||
| 
 | ||||
| #### Sequenzdiagramm | ||||
| - Genaue zeitliche Abfolge von Nachrichten | ||||
| - Umfangreichstes Interaktionsdiagramm | ||||
| - Kontrollelemente möglich (Schleifen, Verzweigungen) | ||||
| 
 | ||||
| #### Kommunikationsdiagramm | ||||
| - Kommunikationsbeziehungen der Kommunikationspartner stehen im Vordergrund | ||||
| - Welche Komponenten arbeiten wie zusammen, um eine Funktion zu erfüllen | ||||
| 
 | ||||
| #### Timing-Diagramm | ||||
| - Genaue zeitliche Darstellung von Zustandsübergängen | ||||
| - Kommunikation abhängiger Zustandsautomaten | ||||
| - Modellierung einzelner Interaktion | ||||
| 
 | ||||
| ##### Prinzipieller Aufbau | ||||
| - Zeitlicher Verlauf senkrecht | ||||
| - Kommunikationspartner waagerecht (unsortiert) | ||||
| - Lebenslinie | ||||
|   - Rechteck mit gestrichelter senkrechter Linie | ||||
|   - Start, Ende und Dauer der Ausführung einer Operation | ||||
|   - Rekursive Aufrufe möglich | ||||
| - Ereignisspezifikation | ||||
|   - Stelle des Sendens / Empfangens der Nachricht | ||||
|   - Definition der Reihenfolge des Auftretens | ||||
|   - Trace: Folge von Sende- und Empfangsereignissen | ||||
| 
 | ||||
| ##### Weitere Elemente des Sequenzdiagramms | ||||
| - Nachrichten ohne Sender | ||||
|   - z.B. am Beginn einer Interaktion | ||||
| - Verlorene Nachrichten (ohne Empfänger) | ||||
|   - Nachricht ohne dargestellten Empfänger | ||||
|   - z. B. am Ende einer Interaktion | ||||
| - Erzeugen von Lebenslinien | ||||
|   - Gestrichelte Linie mit geöffnetem Pfeil | ||||
|   - Keine Rückgabenachricht | ||||
|   - Zeitliche Einrückung des Rechtecks | ||||
| - Zerstören von Lebenslinien | ||||
|   - Durchgezogene Linie mit Dreieckende | ||||
|   - Kann Rückgabenachricht erzeugen | ||||
| 
 | ||||
| ##### Nachrichten in Interaktionsdiagrammen | ||||
| - Ereignis des Sendens bzw. Empfangens von Nachrichten | ||||
| - Typen: | ||||
|   - Operationsaufruf (synchron / asynchron) | ||||
|   - Antwort Nachricht | ||||
|   - Signal (asynchron), Create-/ Delete Message | ||||
| - Operationsaufruf: Parameterliste muss kompatibel sein | ||||
| - Nachrichtentypen | ||||
| 
 | ||||
| #### Zustandsdiagramm | ||||
| - Modellierung des (vollständigen?) Verhaltens | ||||
|   - Zustände von Klassen / Objekten / Komponenten | ||||
|   - Übergänge zwischen den Zuständen | ||||
|   - Ereignisse, die Zustandswechsel auslösen | ||||
| - Modellierung von endlichen Automaten (Zustandsmaschinen) | ||||
|   - Deterministische | ||||
|   - Nichtdeterministische | ||||
| - Verfeinerung von Zuständen möglich | ||||
| - Modellierung von verteilten Systemen / parallelem Verhalten | ||||
| - Grundlage zur Codegenerierung | ||||
| 
 | ||||
| 
 | ||||
| 
 | ||||
| # Analyse | ||||
| # Grobentwurf | ||||
| # Feinentwurf | ||||
| # Implementierung | ||||
| # Vorgehensweise | ||||
| # Projektmanagement | ||||
		Loading…
	
		Reference in New Issue
	
	Block a user