RUP Analyse und Design: Überblick

Transkript

1 Inhaltsverzeichnis Übersicht [, 2, 8] 3. Vorgehensweise Planungsmethoden Definitionsphase Rational Unified Process [5, 6] und UML [3, 4] RUP Überblick Use-Case-l RUP Analyse und Design Aris Unified Process (AUP) [7] 4 4. Steuerungssicht Funktionssicht Datensicht RUP Analyse und Design: Überblick Übersetzung der Requirements in eine Spezifikation Grundlage: Robuste Architektur Eigenschaften des Designs sollten folgendes für die Implementierung ermöglichen: Performance Robustheit Skalierbarkeit Testmöglichkeiten RUP Analyse und Design Analyse vs. Design Analyse Nicht funktionale Anforderungen werden vernachlässigt Die Implementierungsumgebung wird nur eingeschränkt betrachtet Analyse l ist eine idealisiertes l Design Anpassung der Ergbnisse der Analyse an die nicht funktionalen Anforderungen Anpassung der Ergbnisse der Analyse an die Implementierungsumgebung 4 6

2 Klassendiagramm Person Student * «attribute» Datum Geburtsdatum; String Name; «method» void noteneintragen() Relation Kurs Prof Datum String 7 Analyse und Design l Klasse 9 Use-Case Analysis Use-Case Class Component Object Design Deplyment Deploym. Sequence Colaboration Implem. Test Statechart Activity Klassen werden dargestellt Attribute werden mit ihren Typen angegeben Methoden werden mit ihren Typen angegeben 8 20

3 Assoziationen Komposition es werden Beziehungen zwischen Klassen modelliert Karidinalitäten geben die jeweilige Anzahl der Objekte an, die in Beziehung zu einander stehen Aggregationen 2 Starke Form der Aggregation komponiertes Objekt kann nur Bestandteil dieses einen Objekts sein Beispiel: String der den Namen des Studentes darstellt kann niergendwo anders vorkommen Dagagen kann ein Geburtsdatum auch das Geburtsdatum eines anderen sein. 23 Vererbung ist Bestand von Beziehung Beispiel: Objekt der Klasse Datum ist Bestand von eines Objektes der Klasse Student ein Objekt spezialisiert ein anderes Objekt Beispiel: Student ist ein Spezialfall von Person Prof ist ein Spezialfall von Person 22 24

4 Objektdiagramm UML Zustandsdiagramme I Zustände können Namen haben oder können anonym sein. Ein benannter Zustand kann der übersichtlichkeitshalber mehrfach in einem Zustandsdiagramme vorkommen. Zustände können mit Aktionen (Aktivitäten) verbunden sein. entry Aktion: atomare Aktion, die bei Eintritt in den Zustand ausgeführt wird. exit Aktion: atomare Aktion, die beim Austritt aus dem Zustand ausgeführt wird. Es gibt einen Anfangszustand (Pseudozustand). Es gibt einen Endzustand (Pseudozustand). Instanzen von Person Hans Maier und Karin Fritz stehen in Relation zu der Instanz von Kurs IT 2007 Transitionen verbinden zwei Zustände und werden stets durch ein Ereignis ausgelöst Zustandsdiagramme allgemein UML Zustandsdiagramme II Zustand ist ist eine Zeitspanne in der ein Objekt auf ein Ereignis wartet. Ein Objekt kann nacheinander mehrere Zustände durchlaufen. Zu einem bestimmten Zeitpunkt befindet sich Objekt in genau einem Zustand. Ein Zustand hängt sowohl vom vorherigen Zustand, als auch vom eintretenden Ereignis ab. Bemerkung: Ein Zustandsdiagramm ist ein Deterministischer Endlicher Automat. Ein Ereignis kann sein: eine Bedingung die wahr wird ein Signal eine Botschaft (Aufruf einer Methode) eine verstrichene Zeit das Eintreten eines bestimmten Zeitpunkts Eine Transition kann mit einem Wächter beschriftet sein (Bedingung, die erfüllt sein muss)

5 Vorlesung planen [exit] /Vorlesung planen wird ausgewählt [Termin eintragen ausgewählt] Vorlesung planen gestartet entry /Vorlesungsobjekt wird angelegt exit /Vorlesungsobjekt in DB speichern Termin eintragen do /Termin in Vorlesungsobjekt eintragen do /Termin in Terminplan eintragen [Raum eintragen ausgewählt] Raum eintragen do /in Raumplan eintragen do /Raum in Vorlesungsobjekt eintragen [Dozent eintragen ausgewählt] Dozent eintragen do /Dozent in Vorlesungsobjekt eintragen Workflow: Perform Architectural Synthesis Erstellen einer Architekturbasis 29 3 Workflow Workflow: Define Candidate Architecture Erstellen eines initialen Entwurfs des Systems Identifizieren von Analyseklassen von signifikanten Use Cases Updaten der Use Cases im Zusammenspiel mit den Analyseklassen 30 32

6 Workflow: Refine the Architecture Bilden der Übergänge aus der Analyse zum Design Erhalten der Konsistenz und Integrität der Architektur Beschreiben der Laufzeit des Systems Organisation des Implementierungsmodells Workflow: Design Components Design des System Verhalten Updaten der Use Cases im Zusammenspiel mit dem System Verhalten Review des Designs und Entwicklung Workflow: Analyse Behaviour Umwandeln der dynamischen Anteile der Use Cases in Analyse Elemente Workflow: Design the Database Idetifizieren der zu haltenden Daten in den Designklassen Designen der Datenbankstruktur Festlegen von Mechanismen zur Speicherung und Wiederherstellung der Daten unter Einhaltung der Performancekriterien

7 Aufgaben Klassendiagramm I Die Aufgabe bezieht sich auf das BAsys Lastenheft (Folie 52) Entwickeln Sie ein Klassendiagramm das den Use Cases Stundentafel erstellen / pflegen und für Kursplanung / Semesterplanung zu Grunde liegt. Aufgabe Zustandsdiagramme I Entwckeln Sie ein Zustandsdiagramm für den Use Case Kursplanung / Semesterplanung Aufgaben Klassendiagramm II Aufgabe Zustandsdiagramme II Einwickeln Sie für die Use Cases der Aufgabe Java Programm compilieren auf Folie 85 ein Klassendiagramm. Entwckeln Sie ein Zustandsdiagramm für den Use Case Java Programm compilieren