Design im Softwareentwicklungsprozess. Stand der Dinge & Designziel. fachliche & technische Architektur. generelles Vorgehen bei Grob-Design

Transkript

1 Design im Softwareentwicklungsprozess traditionell Geschäftsprozessmodellierung Requirements Engineering Analyse Design Implementierung Tests Design 1 test-getrieben: nur 1. Design top-down hier testgetrieben endgültiges: bottom-up später Stand der Dinge & Designziel Design: Design 2 für ein gegebenes Problem unter Berücksichtigung gegebener Rahmenbedingungen ein Lösungskonzept entwickeln Bisher: UML-Modelle zur Analyse kennen gelernt: AF-Modelle, Aktivitätsmodelle, Fachklassenmodelle, 1. GUIs Jetzt: von Analysemodellen ausgehen -> 1. Grob-Design entwickeln: ins Pflichtenheft Komponenten pro Entwickler: Inneres von Entwickler selbst Komponentenverteilung auf Hardware Kommunikation zwischen Komponenten: Transferklassen und Kommunikationsmittel (RMI, http, ) Komponententests fachliche & technische Architektur fachliche Architektur (äußere Sicht) Design 3 grundlegende Struktur und Aufteilung aus Anwendungssicht Bsp.: Nutzer greift über Browser auf System zu Daten sind persistent zu halten,... technische Architektur (interne Sicht) frei vom konkreten fachlichen Anwendungsgebiet beschreibt allgemeine Eigenschaften der Architektur beschreibt technische Komponenten & Schichten Bsp.: 3-Schichtenmodell mit Applet als GUI, Oracle-DB,... generelles Vorgehen bei Grob-Design gesucht: UML-Klassenmodelle Design 4 gröber: Komponentenmodell (Services) Lege grobe Architekturstruktur fest: Framework (Schichtenmodell) Schichten in Komponenten zerlegen: Schwimmlinien in Aktivitätsdiagrammen Anwendungsfälle auf Komponenten zerlegen Fachklassenmodell verfeinern, erweitern, zerlegen GUIs & Dialoge weiter verfeinern und strukturieren Komponenten zuordnen Doku Komponententests entwickeln & automatisieren Analyse <-> Design 1

2 Framework (Schichtenmodell) Rahmenarchitektur festlegen z.b.: 3-schichtig s. OOS Darstellung Anwendungslogik Persistenzschicht Verbindungen zwischen Schichten Design 5 Darstellung Anwendungslogik: http Anwendungslogik DB JDBC Komponenten zuordnen einzelne Ebenen verfeiern Verteilung auf Hardware mit Verteilungsdiagrammen Schichtenmodell plattformunabhängig beliebige Endgeräte kein Konfigurationsaufwand plattformunabhängig objektorientierte Architektur verteilte Datenbank: erst 7. Semester -> hier einfach Dateisystem des PCs Design 6 RMI oder http Server: Anwendungslogik JDBC strukturierte Daten Komponenten in UML Design 7 Komponenten aus Aktivitätsdiagrammen Design 8 Ausgangspunkt: Aktivitätsdiagramme mit Schwimmlinien Schwimmlinien <-> 1. Komponenten Komp1 Server Dienste spezifizieren: nach außen, falls Schwimmlinie überschritten nach innen, falls Schwimmlinie nicht überschritten entsprechen Aktivitäten Komp2 Client in SOA: nach außen, grobgranulare Services nach innen, feingranulare Services Wie kommt man an Komponenten und Schnittstellen? 2

3 Bsp.: Komponenten aus Aktivitätsdiagr. Design 9 Aktivitätsdiagramm Komponentenschnittstellen Komponenten aus Fachklassen Gruppierung der Fachklassen zu Komponenten Design 10 Reservierung Partner Vertrag ReservierungWunschAufnehmen() VerfuegbarkeitPruefen() Reservieren() KundeAuswaehlen() KundeAnlegen() KundeBearbeiten() VertragAnlegen() KfzUebergeben() Schnittstellen jeweils zwischen 2 Komponenten, die im Modell verbunden sind kann in beide Richtungen gehen ggf. Fachklasse verfeinern zu mehreren Systemklassen Abrechnung KfzZuruecknehmen() KfzAbrechnen() Reservierung Partner Vertrag Abrechnung in SOA ggf. anders schneiden Bsp.: Komponenten aus Fachklassen Design 11 Bsp.: Komponenten aus Fachklassen 2 Design 12 Kunde Mieter Vermietung Reservierung Kunde Kfz-Vermietung Kfz Kfz Kfz-Typ Kundenm itarbeiter Verm ietung Richtung hängt von Klassendiagramm ab hier in beide Richtungen Kfz hier Komponenten horizontal, innerhalb einer Schicht könnte auch vertikal sein: GUI, Logik, DB-Teil Rücknahm eprotokoll 3

4 Komponenten aus AF und ext. Systeme pro AF eine Anwendungsfallsteuerung Dienste, die den AF implementieren Design 13 ordne diese ggf. Komponenten zu: Kfz-Vermietung pro externes System eine Komponente: DB Legacy-Systeme in Cobol, Pascal, ggf. Adapter oder Fassade implementieren Komponenten-Spezifikationsstruktur Design 14 Signatur (Name, Parametertypen, Rückgabetyp) Vorbedingung (Komponentenzustand vor Ausführung) Nachbedingung (Komponentenzustand nach Ausführung) Invariante (Komponentenzustand während Ausführung) Semantik (Beschreibung der Aufgabe und Bedeutung) für Argumente Spezifikation von: Typprüfungen Wertprüfungen zusätzlich: Komponenten-Tests angeben Dialoge spezifizieren schon in Analyse Entwürfe gemacht jetzt weiter entwickeln Design 15 möglichst universell in verschiedenen Kontexten einsetzen einziger Dialog für Neuanlegen, Bearbeiten, Ansehen bei komplexerer Anlage Assistenten-Dialoge häufig: direkte Beziehung Dialog-Element <-> Fachobjekt Zuordnung zu Komponenten -> weitere Infos zu Komponenten Komponententests Design 16 Basis Akzeptanztests & Runterbrechen auf Komponenten parallel zur Komponentenschnittstellendefinition entwickeln -> ins Pflichtenheft aufnehmen, da Design-Tätigkeit unmittelbar automatisieren & Entwickler zur Verfügung stellen zu jedem AF Tests zum Testen aller Abläufe: Gut Böse erhält oft noch Rückschlüsse auf fehlende Methoden in Schnittstellen -> Vervollständigung der Komponentenschnittstellendefinition nicht testgetriebenes Design oft nur schwierig zu testen führen oft zu einfachen Lösungen 4

5 Design-Pattern in OOS: Factory Template Method MVC Decorator Composite Observer Singleton hier noch: Proxy Fassade Adapter Design 17 Proxy-Pattern RealSubject Subject +Request() +RealSubject Proxy Vorteile der Proxy-Verwendung: Design 18 Proxy implementiert gleiche Schnittstelle wie RealSubject Proxy hat Zugriff auf RealSubject-Objekt Client hat nur Zugriff auf Proxy Bsp.: Client-Orb in OOS dient auf Client-Seite als Ersatz für Server-Objekt (remote) kann Real-Subject erst bei Bedarf erzeugen (virtual) dient als Schutz für Real-Subject (protection) Adapter-Pattern Target Client +Request() Adaptee Adapter +adaptee +SpecificRequest() Vorteile der Adapter-Verwendung: Wiederverwendbarkeit Kontrolle des Zugriffs Design 19 Funktionalität vorhanden, aber Schnittstelle passt nicht zum Client-Aufruf -> setze Adapter dazwischen, der Schnittstelle anpasst und vorhandene Funktionalität nutzt SOA-Einbindung von Legacy Systemen Facade-Pattern Facade Subsystem Classes Vorteile der Facade-Verwendung: Design 20 Funktionalität wild auf mehrere Klassen verteilt. Client soll ohne Kenntnis der wilden Struktur auskommen -> Zugriff durch Client über neu definierte Facade Bsp.: Fixtures bei FIT muss wilde Struktur des Systems nicht preis geben Verwendung in verschiedenen Kontexten kontrollierter Zugriff 5