Objektorientierte Analyse

Transkript

1 Objektorientierte Analyse 1) Systemanalyse Einführung Prof. Dr. rer. nat. habil. Uwe Aßmann Institut für Software- und Multimediatechnik Lehrstuhl Softwaretechnologie Fakultät für Informatik TU Dresden Softwaretechnologie, Prof. Uwe Aßmann 1

2 Obligatorische Literatur Zuser, Kap. 7-9 Störrle, Kap. 5 Prof. Uwe Aßmann, Softwaretechnologie 2

3 Objektorientierte Analyse und Entwurf Die Arbeitsphase Analyse ermittelt, was der Benutzer vom System benötigt Schnittstellen (Funktionen, Daten, Klassen, Code) Begriffe der Anwendungsdomäne Oft nennt man sie Systemanalyse oder Anforderungsanalyse Die Arbeitsphase Entwurf ermittelt, was der Entwickler zusätzlich zu den Ergebnissen der Analyse ins System aufnehmen muss, was aber der Benutzer nicht sehen muss. Prof. Uwe Aßmann, Softwaretechnologie 3

4 Von der Analyse zum Entwurf Vertrag mit dem Kunden Analyse Anforderungs- Ermittlung Fachliche Modellierung Anforderungs- Spezifikation Produktdefinition (Anforderungen und fachliches Modell) Architektur- Spezifikation Architektur- Entwurf Klassen- Spezifikationen Entwurf Detail- Entwurf Prof. Uwe Aßmann, Softwaretechnologie 4

5 Von den Anforderungen zum Feinentwurf Produktdefinition Textuelle Anforderungen Nutzermodell Anforderungsspezifikation Anwendungsfälle (use cases) Top-levelanalysis Architektur Kontextmodell model (context model, system interface) Fachliches Modell Domänenmodell Architektur- Entwurf Feinentwurf Prof. Uwe Aßmann, Softwaretechnologie 5

6 Von den Anforderungen zum Feinentwurf Problemraum (problem space Produktdefinition Lösungsraum (Systemraum solution space) Textuelle Anforderungen Nutzermodell Anforderungsspezifikation Anwendungsfälle (use cases) Top-levelanalysis Architektur Kontextmodell model (context model, system interface) Fachliches Modell Domänenmodell Architektur- Entwurf Feinentwurf Prof. Uwe Aßmann, Softwaretechnologie 6

7 Schematischer Ablauf der Analyse (Anforderungen und fachliches Modell) preparatory requirements analysis Domain Model real requirements analysis Anforderungen Funktionale Anforderungen GUI Prototyp Produktdefinition basic system analysis Pflichtenheft Top-level architecture Context Model Vertrag Prof. Uwe Aßmann, Softwaretechnologie 7

8 Schematischer Ablauf der Analyse (Anforderungen und fachliches Modell) Stakeholder Analysis (Nutzergruppen) preparatory requirements analysis Domain Analysis (Domain concepts) Domain Model real requirements analysis Function Analysis - Use case analysis GUI Analysis Anforderungen Produktdefinition Funktionale Anforderungen Context Model Context Model Analysis GUI Prototyp basic system analysis Pflichtenheft Top-level Architecture Analysis Top-level architecture Vertrag Prof. Uwe Aßmann, Softwaretechnologie 8

9 Voller Ablauf der Analyse (s. SWT-2) Stakeholder Analysis (Nutzergruppen) Problem Analysis preparatory requirements analysis Domain Analysis (Domain concepts) Domain Model Goal Analysis Function Analysis - Use case analysis Quality Analysis (Non-functional Reqs) real requirements analysis GUI Analysis Anforderungen Funktionale Anforderungen Context Model Analysis GUI Prototyp basic system analysis Produktdefinition Pflichtenheft Context Model Top-level Architecture Analysis Acceptance Criteria Analysis Project Task Planning Acceptance Test Top-level architecture Vertrag Prof. Uwe Aßmann, Softwaretechnologie Acceptance Tests 9

10 Inhalte eines Vertrags Pflichtenheft Produktdefinition. Anforderungsspezifikation (das WAS) Nutzermodell (stakeholders) Domänenmodell Funktionale Anforderungen In SWT 2: Problemmodell, Zielmodell, Nicht-funktionale Anforderungen. Fachliches Modell (das WIE, das der Kunde wissen muss) Kontextmodell GUI-Prototyp Top-level-Architektur Akzeptanztestfälle:. Messbare Akzeptanzkriterien, die bei der Abnahme vom Kunden abgehakt werden können. Ohne bestandenen Akzeptanztest keine Bezahlung! Preisliche Regelung Achtung: In der Literatur wird der Begriff Analysemodell sowohl für die Produktdefinition als auch nur für das fachliche Modell verwendet! Prof. Uwe Aßmann, Softwaretechnologie 10

11 Inhalte der Anforderungspezifikation (WAS?) Nutzermodell (stakeholder model): Liste oder UML-Klassendiagramm aller am System Interessierten In SWT-2 verfeinern wir das, in dem wir über die Ziele der stakeholder nachdenken Enthält die Benutzer des Systems (die Aktoren) Domänenmodell (domain model): Termini, Struktur und Grundkonzepte des Aufgabengebiets Schaffung einheitlicher Terminologie für die Anforderungsspezifikation Aus der Sicht des Kunden Zusammenhang mit Anforderungsspezifikation sichern Implementierungsaspekte ausklammern: Annahme perfekter Technologie Problemmodell, Zielmodell (s. SWT-2) Prof. Uwe Aßmann, Softwaretechnologie 11

12 Inhalte der Anforderungspezifikation Funktionale Anforderungen: Funktionale Essenz des Systems. Was muss das System können? Nicht das Wie, sondern nur das Was möglichst quantitativ (z.b. Tabellenform) eindeutig identifizierbar (Nummern) Notation: Anwendungsfalldiagramme (Nutzfalldiagramme), Funktionsbäume oder textuell. Manchmal auch mathematisch Nicht-funktionale Anforderungen: Qualitätsanforderungen (s. SWT-2) z.b. Antwortzeit, Speicherbedarf, HW/SW-Plattform Entwicklungs- und Produkt-Standards Prof. Uwe Aßmann, Softwaretechnologie 12

13 Inhalte des Fachlichen Modells (Fachkonzept) (Das WIE, das der Kunde wissen muss) Kontextmodell: äussere Schnittstellen des Systems Ein- und Ausgabekanäle, Masken, Abfragen Daten, die ein und aus fliessen, im Domänenmodell typisiert GUI Prototyp: Prototypische Masken, Formulare, Bildschirme, die den GUI ausmachen: Wie sieht das Programm aus? Top-level Architektur (Initiale Architektur, Facharchitektur): Bestimmt die Hauptkomponenten des Systems und ihre Interaktionen, ohne auf Details einzugehen Verfeinert das Kontextmodell um eine Stufe, d.h. die top-level Architektur Stellt das dar, was der Kunde von der Systemarchitektur wissen muss Prof. Uwe Aßmann, Softwaretechnologie 13

14 Objektorientierte Analyse (OOA) Grundidee: Modellierung der fachlichen Aufgabe (Produktdefinition mit Fachlichem Modell und Anforderungsspezifikation) durch kooperierende parallele Objekte. Produktdefinition (OOA Modell) Statisches Modell Dynamisches Modell Anforderungsspez. Klassen: Eigenschaften und Aufgaben von Objekten Beziehungen zwischen Klassen (bzw. Objekten) beschreibt Typische Anwendungsfälle (Anforderungen) Zustände und Verhalten von Objekten System als "Gesellschaft" kooperierender Objekte Stakeholders Domänenmodell Funktionale Anforderungen Fachl.Modell GUI-Prototyp Kontext- Diagramm Top-level Architektur Prof. Uwe Aßmann, Softwaretechnologie 14

15 Von Analysemodellen zu BCE- Entwurfsmodellen (3-Schichtenarchitektur) Stakeholders GUI-Prototyp Domänenmodell Anforderungen (z.b. use cases) Kontext- Diagramm Top-level Architektur OOA- Modell GUI (boundary) GUI-Architektur - Text UI - Web GUI - Java GUI - XML GUI GUI-Schicht Anwendungslogik (control) Architektur Prozesse, Tools, Workflows Feinentwurf Datenhaltung (entity) Entwurf Datenmodell (Entitites, Materialien) Anwendungslogik- Implementierung Datenmodell- Implementierung OOD- Modell OOP Prof. Uwe Aßmann, Softwaretechnologie 15

16 Zum Praktikum mehr als 95% aller Themen im Praktikum sind BCE-Architekturen Oft mit Web-GUI Unterscheidung zwischen GUI, Anwendungslogik und Datenhaltung ist essentiell Man sollte verstehen, dass aus dem Domänenmodell die Datenhaltung folgt die Typen der Daten folgen, die im Kontextmodell und in der Top-Level- Architektur fliessen der GUI-Prototyp stark bestimmt wird (Kommunikation mit dem Benutzer) Die Entwickler oft nur für B, C, oder E zuständig sind Prof. Uwe Aßmann, Softwaretechnologie 16

17 Unified Modeling Language UML Ca. 1990: OOD Booch... OOSE Jacobson OMT Rumbaugh et al. 1995: UML ist eine Notation der 2. Generation für objektorientierte Modellierung UML ist Industriestandard der OMG (Object Management Group) Booch / Rumbaugh / Jacobson 1997: UML : UML : UML : UML : UML 2.0 Prof. Uwe Aßmann, Softwaretechnologie 17

18 Überblick Objektorientierte Analyse 1 Überblick Systemanalyse 2 Strukturelle Modellierung mit CRC-Karten 2b Strukturelle datengetriebene Modellierung mit UML 3 Anwendungsfälle 4 Dynamische Modellierung mit UML Prof. Uwe Aßmann, Softwaretechnologie 18

19 Modeling the Real Solution Prototype of a washing machine Find the right abstractions! Prof. Uwe Aßmann, Softwaretechnologie 19

20 The Basic Laws of Misunderstanding Spoken is not heard Heard is not listened Listened is not understood Understood is not accepted Accepted is not done Prof. Uwe Aßmann, Softwaretechnologie 20

21 The End Teile der Folien sind eine überarbeitete Version der Vorlesungsfolien zur Vorlesung Softwaretechnologie von Prof. H. Hussmann, used by permission. Prof. Uwe Aßmann, Softwaretechnologie 21