Softwaretechnik WS 2004/05

Transkript

1 Softwaretechnik WS 2004/05 1 Softwaretechnik WS 2004/05 Basisveranstaltung im Studiengebiet SSG (Softwaretechnik und Systemgestaltung) Stephan Herrmann Susanne Jucknath-John Matthias Vösgen Softwaretechnik WS 2004/05 2 1

2 Was machen wir heute? Software-Entwurf allgemein Ziele Vorgehen Qualitätsmerkmale Software-Architektur Objektorientierter Entwurf nach Fusion Softwaretechnik WS 2004/05 3 Softwaretechnik WS 2004/05 4 2

3 Software-Entwurf Entwurf der Softwarelösung durch implementierungsnahe Komponenten kreativer Prozess, Wahl einer geeigneten Abstraktionsebene erster Schritt zu einem lauffähigen Programm Basis: Anforderungsdokument (insbesondere Anforderungsspezifikation und Analysemodelle) Ergebnis: Schnittstellenbeschreibung Softwaretechnik WS 2004/05 5 Arbeitsweise beim Entwurf Informeller Entwurf auf Basis des Problemverständnisses und der Analyse grobe Fixierung der Begründung ausgewählter Entscheidungen Kriterien: Erfahrung, Verfügbarkeit wiederverwendbarer Komponenten, Einfachheit, etc. Entwurfs -Beschreibung (teils informell/formalisiert) jeder Abstraktion (Komponenten / Patterns) Wiederholung dieser Schritte bis zu einem Konsens-Entwurf Softwaretechnik WS 2004/05 6 3

4 Entwurfsaspekte Architektur des Produktes Subsysteme (components) Beziehungen zwischen Subsystemen (connectors) Klassifizierung von Subsystemen und deren Beziehungen Schnittstellen zwischen Subsystemen Verfeinerungen von Komponenten Datenstrukturentwurf algorithmischer Entwurf Softwaretechnik WS 2004/05 7 Funktionaler Entwurf eines Compilers Funktionen und Datenflüsse Analyse lexikalisch syntaktisch semantisch Generierung Zeichenstrom Scanner SymTab Kritik: Parser SymTab Syntaxbaum Resolver/ Typechecker SymTab Syntaxbaum Syntaxgraph Generator SymTab Syntaxbaum Syntaxgraph Bytestrom - Wachsende Datenflüsse - Ev. mehrfache Implementierung derselben Strukturen Softwaretechnik WS 2004/05 8 4

5 Abstrakte Datentypen Definition eigenständiger Datenstrukturen Analyse lexikalisch syntaktisch semantisch Generierung Zeichenstrom Scanner Parser Resolver/ Typechecker Generator Bytestrom ADT: SymTab - Gekapselte Daten - Zugriffsoperationen Syntaxbaum Syntaxgraph Softwaretechnik WS 2004/05 9 Software-Architektur Architektur-Stil Klassifikation von Systemen Anwendungsarchitektur Teil des Fach-Entwurfes Technische Architektur Existierende Komponenten (Eigenentwicklung vs. Fremdanbieter) Technische Plattform / Infrastruktur Analyse Entwurf Realisierung Softwaretechnik WS 2004/

6 Architektur-Stile Familien von Applikationen Benennen Ähnlichkeiten in der Grobstruktur Datenflusssysteme Batch-sequentiell, Pipes and Filters Call-and-return Systeme Hauptprogramm und Subroutinen, OO-Systeme, Hierarchische Schichten Unabhängige Komponenten Kommunizierende Prozesse, Ereignisgesteuerte Systeme Virtuelle Maschinen Interpreter, Regelbasierte Systeme Datenzentrierte Systeme (Repositories) Datenbanksysteme, Hypertext-Systeme, Blackboards Softwaretechnik WS 2004/05 11 Struktur: Stile (1): Prozesssteuerung Konzepte: Steuerung kontinuierlicher Prozesse Sensoren und Stellglieder. Regelkreis: Verknüpfung eines Kontrollalgorithmus mit dem zu steuernden Prozess. Abbildung: technische Signale Messwerte Variationen: Aktive Schleife Getaktete Berechnung Ereignissteuerung Softwaretechnik WS 2004/

7 Stile (2): Ereignisbasiert Struktur: Typische Eigenschaften: Ein Teil der Kontrolle wird vom Aufrufer zum Aufgerufenen verlagert ( broadcast subscribe ) Große Offenheit für das Hinzufügen von Komponenten Fast keine Gewissheit über die Reaktionen auf ein Event Nachteil: Nicht kompositional: Effekt eines Events ergibt sich nur bei Betrachtung des gesamten Systems. Softwaretechnik WS 2004/05 13 Struktur: Stile (3): Pipes & Filters Typische Eigenschaften: Daten werden als kontinuierliche Ströme übertragen Berechnungen laufen inkrementell ab Keine weitere Kenntnis/Kommunikation zwischen Komponenten Nachteile: Nicht interaktiv Standardisierung der Datenformate? Softwaretechnik WS 2004/

8 Stile (4): Objektorientierte Organisation Struktur: Typische Eigenschaften: Objektzustand ist gekapselt Objekt ist verantwortlich für seinen Zustand Systemzustand ist auf viele Objekte verteilt Nachteil: Starke Vernetzung: Klassen sind u.u. von Details der Schnittstellen vieler anderer Klassen abhängig Softwaretechnik WS 2004/05 15 Struktur: Stile (5): Schichten Typische Eigenschaften: Innere Schicht ist nur für die direkt umschließende sichtbar Explizite Schnittstellen Abstrakte Maschinen Nachteil: Schichtenlösungen sind häufig schwierig zu finden bzw. ineffizient. Softwaretechnik WS 2004/

9 Stile (6): Repositories Struktur: Typische Eigenschaften: Informationsquellen (Klienten): Erzeugen verändern Daten, können leicht hinzugefügt/ausgetauscht werden Zentrale Datenstruktur: Mehr oder minder aktiver Speicher. Steuerung mittels bidirektionaler Kommunikation Keine direkte Kommunikation zwischen Klienten. Varianten: Insbesondere verschiedene Realisierungen der Kommunikation Softwaretechnik WS 2004/05 17 Architekturstile: Konsequenzen Problemklasse Architekturstil Benötigte Techniken, (Sprachen, Kommunikation, Bibliotheken) Entwicklungsmethode Softwaretechnik WS 2004/

10 Anwendungsarchitektur Fachkomponenten Definiert durch ihre Schnittstellen. Beispiele: Kundenverwaltung Artikelverwaltung Bestellsystem Komposition Benutzung (provided, expected) Klassifikation der Konnektoren Lokal vs. entfernt Prozedural vs. ereignisbasiert Softwaretechnik WS 2004/05 19 Technische Architektur Auswahl von vorgefertigten Komponenten Infrastruktur Betriebssystem Middleware Datenbanksystem Frameworks Programmiersprache(n) Bibliotheken Kompatibilität Durch Beachtung von Standards Unter Berücksichtigung exakter Versionen Durch Adaptierung Softwaretechnik WS 2004/

11 Architektur-Prozesse Ideal: sequentieller Prozess Architekturstil Anwendungsarchitektur technische Architektur Jeweils nur eine Abstraktionsebene! Existierende IT-Landschaft Festlegung auf Techniken Existierende Daten, Datenbanken, Datenformate, Standards... Wiederverwendung Frameworks, Bibliotheken (interne Schnittstellen) Commercial Off The Shelf (COTS) Komponenten (externe S.) Probleme: Funktionsabdeckung Korrektheit Kompatibilität Anpassbarkeit (zw. Fremdsystemen)... Softwaretechnik WS 2004/05 21 K1.v4 K1.v3 Prozesssingularität Gefahr bei Verwendung von COTS: Alle Phasen gleichzeitig: Wartung: K2.v3 K2.v4 OS.v7 KNeu K3.v8 Integration einer neuen Version von Komponente K1.v3 Entwurf: Änderungen an Schnittstellen nachziehen (K2) Abhängigkeiten nachziehen: K1.v4 erfordert K2.v4 erfordert OS.v7 Kunde hat Lizenz nur für OS.v6 K2 kann nicht mehr verwendet werden Analyse: Verteilung der Funktionalität von K2 auf andere Komponenten? Eigenentwicklung eines Ersatzes für K2 (teilweise)? Implementierung/Testen: Ist K1.v4 kompatibel mit K3.v8 (keine Angaben in der Doku)? Softwaretechnik WS 2004/

12 Risikomanagement Kollektive Erfahrung Spezialisierung auf eine Problemklasse Firma definiert ihre Standardarchitektur Technische Prototypen spike solutions (vertikaler Prototyp) Machbarkeitsstudien Alternativ-Architekturen Abhängigkeiten von Herstellern minimieren Softwaretechnik WS 2004/05 23 Dimensionen der Zerlegung Fachkomponenten / Subsysteme Unterteilung der Anwendungs-Domäne Verteilung Räumliche Verteilung Leistungsfähigkeit/Auslastung der Rechner Aspekte Domäne (Anwendungslogik) + Darstellung Ablaufsteuerung/Interaktion Datenhaltung (Persistenz) IT-Sicherheit... Softwaretechnik WS 2004/

13 Model-View-Controller Bewährte Anwendungsstruktur Paradigma? Architektur? Entwurfsmuster? Im Einsatz seit SmallTalk80 Klare Trennung Model = Anwendungslogik View = Darstellung (GUI) Controller = Interaktion/Ablaufsteuerung Softwaretechnik WS 2004/05 25 Model-View-Controller (M) Person name geburtsdatum gibalter() Model Klassen werden aus der Analyse übernommen Keine Kenntnis von GUI o.ä. Einfachheit Unäbhängigkeit Softwaretechnik WS 2004/

14 Model-View-Controller (V) show() store() PersonView Person name geburtsdatum gibalter() read/(write) View Implementiert mithilfe einer GUI-Bibliothek Darstellung des Modells auf dem Bildschirm Auslesen der Modelldaten Eventuell Zurückschreiben geänderter Daten Softwaretechnik WS 2004/05 27 Model-View-Controller (C) PersonController mouseclicked() buttonpressed() entertext() show() store() PersonView Person name geburtsdatum gibalter() read/(write) Controller Reagiert auf Benutzereingaben Liest Model- und View-Zustand Entscheidet über Ausführung von Aktionen Ruft Operationen am Model auf Veranlasst die View zur Änderung der Darstellung Softwaretechnik WS 2004/

15 Neue Klassen im Entwurf View/Controller Datenstrukturen Schnittstellen zu Betriebssystem, Geräten... Zerlegung der Funktionalität Vererbung/Code-reuse Entwurfsmuster für mehr Flexibilität Abstraktion Abstrakte Kopplung Softwaretechnik WS 2004/05 29 Entwurfsmuster - Beispiel Component Composite Leaf Composite Component Composite Composite Composite Objekt-Bäume Rekursiv Einheitlich Rollen: Component (u.u. abstrakt) Leaf (elementar, konkret) Composite (zusammengesetzt) Softwaretechnik WS 2004/

16 Musterbeschreibung Name Ziel Motivation Struktur Rollen Kollaboration Anwendungen Siehe auch... Composite Baumstrukturen, einheitliche Behandlung Bsp. Fenstersystem: hierarchische Anordnung v. Elementen bei gleicher Schnittstelle für elementare und komplexe Elemente. (siehe Diagramm) Component, Composite, Leaf (mit Zuständigkeiten) Benutzung der Schnittstelle Component, Leaf implementiert direkt, Composite delegiert an Elemente Fenstersysteme, Abstrakte Syntaxbäume Visitor, Iterator, Decorator,... Softwaretechnik WS 2004/05 31 Prinzipien des Entwurfs allgemeine Prinzipien: Abstraktion: Wahl von Stilen oder Mustern mit beschränkter Semantik. Verfeinerung von abstrakten Modellierungselementen methodische Grundprinzipien: Modularität Abstrakte Datentypen Softwaretechnik WS 2004/

17 Objektorientierter Entwurf Klassen als modulares Realisierungskonzept abstrakter Datentypen Objekte als Instanzen von Klassen Typhierarchien durch Vererbung von Klassenattributen dezentrale Steuerung durch autonome Objekte Softwaretechnik WS 2004/05 33 Erinnerung: Analyse Entwurf Analyse: was macht das System und was macht es nicht? Gegenstandsbereich Benutzungsdynamik (Außenverhalten und Zustandsänderung) Systemgrenzen Entwurf: wie erfüllt das System seine Aufgaben intern? Kommunikation zwischen Objekten Zugriff auf Objekte (interne!) Klassenschnittstellen Vererbung Softwaretechnik WS 2004/

18 Ziele des Entwurfs nach Fusion abstrakte Beschreibung von Klassenschnittstellen Referenzierungsstruktur zwischen Klassen Generalisierungen, Spezialisierungen und Vererbungen Die Entwurfsmodelle ergänzen die Modelle der Analyse! Analyse und Entwurf sind Grundlage der Implementierung. Softwaretechnik WS 2004/05 35 Fusion: Entwurfsmodelle Anforderungsdefinition Analyse Klassenmodell Entwurf Schnittstellenmodell Lifecycle- Modell Operationsmodell Objektinteraktionsmodell Referenzierungsmodell Use-Case-Modell Timeline-Diagramme Systemklassenmodell Data Dictionary Klassenschnittstellenmodell Vererbungsmodell Softwaretechnik WS 2004/