Vorlesung Informatik II Universität Augsburg Wintersemester 2011/2012 Prof. Dr. Bernhard Bauer Folien von: Prof. Dr. Robert Lorenz Lehrprofessur für Informatik 01. Softwareentwurf 1 Softwareentwurf Teilgebiet des Software-Engineering Ziel: Systematisierung / Vereinheitlichung des Entwurfs Teilweise computergestützt (Softwareentwicklungstools) 2 Softwareentwurf Forderungen Systematischer und nachvollziehbarer Entwurf zur Erleichterung der Pflege, Wartung und Erweiterung des Programms Arbeitsteiliger Entwurf (bei großen Problemstellungen) - frühzeitige Strukturierung - Zerlegung in Teilprobleme 3 Softwareentwurf Entwurfsprinzipien Allgemeingültige und anerkannte Konzepte, Richtlinien und Techniken des Entwurfs Unterstützen ingenieurmäßige Konstruktion von "guter" Software. die wichtigsten Konzepte sind: - Strukturierung - Schrittweise Verfeinerung - Modularisierung 4 Strukturierung Mit Strukturierung wird eine adäquate Darstellung der logischen Eigenschaften von Daten und Abläufen und der Zusammenhänge zwischen ihnen bezeichnet. 5 Strukturierung Algorithmische Strukturierung (Informatik 1): Strukturierte Darstellung des logischen Ablaufs durch Sequenzen, d.h. lineare Abfolgen von Anweisungen Verzweigungen in Abhängigkeit von Bedingungen Wiederholungen von Anweisungsfolgen 6 Strukturierung Datenstrukturierung (Informatik 1+2): Darstellung der logischen Eigenschaften und Beziehungen zwischen den zu bearbeitenden Objekten durch geeignete Datentypen 7 Strukturierung Vorgehen Elementare Operationen (und Datenstrukturen) einer komplexen Anwendung sind meist sehr einfach. Wenn man die Funktionalitäten einer Anwendung als komplexe Operationen auffasst, die sich aus vielen elementaren Operationen und Ablaufstrukturen zusammensetzen, so stellt sich folgende Frage: Wie gestaltet man den Schritt von den elementaren Operationen zu der komplexen Funktionalität einer Anwendung und umgekehrt möglichst überschaubar und einfach? 8 Schrittweise Verfeinerung Prinzip 1: Top-Down-Vorgehen Programmiersprachen-unabhängiger Entwurf der groben Funktionalität einer Anwendung mit abstrakten Operationen und Datentypen (Benutzerorientiert) Verfeinerung der im ersten Schritt benutzten Operationen, d.h. "Implementierung" mit weniger abstrakten Operationen und Datentypen. Wiederholung des Verfeinerungsschrittes, bis nur noch (Programmiersprachen-abhängig) zur Verfügung stehende Ablaufstrukturen und Elementaroperationen verwendet werden. 9 Schrittweise Verfeinerung Prinzip 1: Top-Down-Vorgehen Erfordert simultane, aufeinander abgestimmte Verfeinerung und Konkretisierung von: – Operationen, – Kontrollflüssen (Ablaufstrukturen), – Datenstrukturen d.h. die einzelnen Bestandteile von Algorithmen sollten auf gleichem Niveau verfeinert werden. 10 Modularisierung Prinzip 2: Bottom-Up-Vorgehen (Informatik 1) Abgeschlossene Teilaufgaben werden zuerst durch Programmstücke realisiert. Anschließend Zusammenfügen der Teillösungen zu größeren Einheiten. Erfordert Modularisierung des Problems in Teilprobleme (Teilaufgaben) 11 Modularisierung Beispiele für Bottom-Up-Vorgehen aus Informatik 1 Mathematische Aufgabenstellungen: zunächst einfache arithmetische Operationen später komplizierte Operationen (Matrizenrechnung, numerische Integration) Erstellung von Programmbibliotheken: zunächst einfache Standardalgorithmen spätere Verwendung beim Entwurf komplizierter Algorithmen 12 Modularisierung Definition Modularisierung Zerlegung von Problemen in Teilprobleme, die – klar voneinander abgegrenzt sind – getrennt bearbeitet werden können – weitgehend unabhängig voneinander sind – deren Lösungen nebenwirkungsfrei gegen Alternativlösungen austauschbar sind (keine "Seiteneffekte"). 13 Modularisierung Vorteile Reduzierung der Komplexität eines Problems durch Zerlegung in überschaubare Einzelprobleme Einzelne Module können unabhängig voneinander getestet oder verifiziert werden Einzelne Module sind austauschbar und erweiterbar (Baukastenprinzip) Erlaubt unproblematischen Übergang zu Nachfolgeversionen eines Softwareprodukts durch Austausch einzelner Module 14 Modularisierung Charakteristika von Modulen: Keine Berücksichtigung von Reihenfolgeabhängigkeiten (im Unterschied zur schrittweisen Verfeinerung) Spezifikation weitgehend unabhängiger Teilaufgaben mit klar definierten Schnittstellen (Prinzip der Einkapselung) Späteres Zusammenfügen der einzelnen Teillösungen über die vereinbarten Schnittstellen 15 Modularisierung Prinzip der Einkapselung Zusammenfassung bestimmter Programmteile (Daten, Funktionen) Bereitstellung einer bestimmten Funktionalität Implementierung für den Anwender nicht wichtig Schutz dieser Programmteile vor direktem Zugriff Implementierung darf nicht verwendet werden (wegen Austauschbarkeit) Aufruf nur über fest definierte Schnittstelle Sicherstellung von Datenstruktur-Invarianten 16 Modularisierung Datenstruktur-Invariante Eine Eigenschaft einer Datenstruktur, die nach Initialisierung gilt und durch alle Operationen darauf erhalten bleiben soll, heißt Invariante der Datenstruktur. Durch beliebigen Zugriff kann ein Zusammenhang zwischen den beteiligten Variablen gestört werden. (Bsp.: Fallstudie am Ende) 17 Modularisierung Beispiel für Einkapselung: Funktionen (siehe Informatik 1) Wiederholt ausgeführte, ähnliche Teile werden durch Parametrisierung zusammengefasst Implementierung stellt Datenstruktur-Invarianten sicher Implementierung ist für den Anwender einer Funktion nicht wichtig, sondern die Funktionalität Benutzung über die Schnittstelle von Eingabe- und Ausgabeparametern Aber: Funktionen reichen nicht, um Größen durch Einkapselung vor beliebigem Zugriff zu schützen (Bsp.: Fallstudie am Ende) 18 Modularisierung Definition Modul Ein Modul besteht aus einer Sammlung von VariablenVereinbarungen und Funktionen Variablen und Funktionen werden in öffentliche und private aufgeteilt. Die öffentlichen sind außerhalb des Moduls verfügbar, die privaten nur innerhalb (diese sind also eingekapselt) Kein beliebiger Zugriff auf private Variablen und Funktionen 19 Modularisierung Typische Realisierung von Modulen Eine Datenstruktur wird meist als Sammlung privater Variablen realisiert Die öffentlichen Funktionen werden dann so angelegt, dass sie die erwünschten Datenstrukturinvarianten erhalten Damit ist der unkontrollierte Zugriff auf private Variable unterbunden 20 Modularisierung Schnittstelle eines Moduls Die Sammlung der öffentlichen Variablen und FunktionsDeklarationen eines Moduls nennt man dessen Schnittstelle (interface). Angabe durch die Signatur: Bezeichner der Variablen und Konstanten mit Typ Prototypen der Funktionen Beispiel: h-Datei in C 21 Modularisierung Fallstudie: Implementierung einer Menge ganzer Zahlen Öffentlicher Teil der Schnittstelle für eine Datenstruktur Set zur Repräsentation von Mengen in C: Set * emptyset(); Initialisierung leere Menge int iselem (int, Set *); Enthaltensein eines Elements Set * insert (int, Set *); Einfügen eines Elements Set * delete (int, Set *); Löschen eines Elements Set * union (set *, Set *); Vereinigung von Mengen Set * intersection (Set *,Set *); Durchschnitt von Mengen int getsize (Set *); Größe einer Menge void printset (Set *); Ausgabe einer Menge 22 Modularisierung Fallstudie: Implementierung einer Menge ganzer Zahlen Implementiere Set als einfach verkettete Liste: typedef struct knoten { int wert; struct knoten * next; } Knoten; typedef struct set { knoten * start; int size; } Set; 23 Modularisierung Fallstudie: Implementierung einer Menge ganzer Zahlen Implementiere Set als einfach verkettete Liste: Datenstrukturinvarianten: „Liste sortiert und wiederholungsfrei“ „Wert von size entspricht Anzahl der Knoten“ Leere Menge: Menge {1,2,4}: null 1 2 4 null 24 Modularisierung Fallstudie: Implementierung einer Menge ganzer Zahlen Implementiere Set als Bitvektor fester Länge: typedef struct set { int werte[1000]; int size; } Set; 25 Modularisierung Fallstudie: Implementierung einer Menge ganzer Zahlen Implementiere set als Bitvektor fester Länge: Datenstrukturinvarianten: „Vektor werte hat nur die Werte 0 und 1“ „Wert von size entspricht Anzahl der 1sen im Vektor werte“ Vektor 0 0 0 0 0 0 ... Index 0 1 2 3 4 5 ... Menge {1,2,4}: Vektor 0 1 1 0 1 ... Index 0 1 3 4 ... Leere Menge: 2 26 Modularisierung Fallstudie: Implementierung einer Menge ganzer Zahlen DISKUSSION: Welche Implementierung ist (in welchen Fällen) weniger Speicherplatz- bzw. Zeitaufwendig? Überlege verschiedene Möglichkeiten, wie ein Programmierer dummerweise Datenstruktur-Invarianten zerstören könnte ZUSÄTZLICHE SPRACHKONSTRUKTE FÜR EINKAPSELUNG NOTWENDIG 27 Modularisierung Zusammenfassung Zerlegung eines großen Programmsystems in einzelne, überschaubare und sinnvolle Teile Abschirmung und damit Schutz privater Variablen Verbergen von Implementierungsdetails: Trennung „Was wird getan“ (deklarativ) von „Wie wird es getan“ (operationell) Austauschbarkeit von Implementierungen Möglichkeit zur unabhängigen Implementierung der Teile, wenn die Schnittstellen geklärt sind. 28 Modellbasierter Entwurf Entwicklung komplexer Anwendungen benötigt Strukturierung Modellbildung vor Programmierung UML (Unified Modeling Language) zur Programmiersprachen-unabhängigen Modellierung komplexer Systeme: Statische Modelle: Strukturierung der Daten (Klassendiagramm) Dynamische Modelle: Strukturierung der Abläufe (Sequenzdiagramm) 29 UML Charakteristika: Modellierungssprache zur Dokumentation von Analyse, Entwurf und Implementierung objektorientierter Software Vereinigt eine Vielzahl graphischer und textueller Beschreibungsmethoden (Diagrammtypen) Beinhaltet kein Vorgehensmodell zur Software-Entwicklung, gibt aber einen Rahmen vor. Vorteile: Unabhängigkeit von Programmiersprache Graphische Darstellung (verständlich für Anwender) 30 UML UML in dieser Vorlesung Sprachumfang zu umfangreich zur Darstellung in einer Vorlesung Viele Details erst in der Anwendung voll verständlich Vorlesung ist keine vollständige UML-Dokumentation! Stattdessen: Einführung in Grundkonzepte der wichtigsten Diagrammtypen (Klassen-, Sequenz-Diagramm) Entwicklung einer Basis für Entwicklung einfacherer Anwendungen und selbstständige detailliertere Einarbeitung 31 Ein Vorgehensmodell zur Modellierung Top-Down-Vorgehen grob in 3 Phasen: Analyse Was soll gemacht werden? (UML) Entwurf Wie wird’s gemacht? (UML) Implementierung (konkrete Programmiersprache) Test 32 Ein Vorgehensmodell zur Modellierung Analys e Pflichtenheft Analysemodell Prototyp Entwurf Entwurfsmodell Fachkonzept Analysemodell Bibliotheken Benutzeroberfläche Datenhaltung Datenbank (Java-)Programm 33 Ein Vorgehensmodell zur Modellierung Manche Diagramme lassen sich eindeutig einer der Modellierungsphasen (Analyse, Entwurf) zuordnen Andere Diagramme werden in beiden Phasen verwendet, in der Analyse werden aber nicht alle Aspekt berücksichtigt Die Trennung in Analyse und Entwurf erfährt man am besten in der Praxis Wir werden das Vorgehensmodell und die Trennung in Analyse- und Entwurfsphase nicht besprechen 34 Ein Vorgehensmodell zur Modellierung Sinn, Zweck und Bedeutung von Vorgehensmodellen „Die Qualität eines Programms kann nicht im Nachhinein ‚hineingetestet‘ werden“ (Produktverbesserung durch Prozessverbesserung, d.h. durch Verbesserung der methodischen Vorgehensweise zur Erstellung eines Produkts) „If you wait for a complete and perfect concept to germinate in your mind, you are likely to wait forever“ (deMarco) (Die Methodik soll eine Hilfsstellung sein und nicht zu bürokratisch ausgelegt werden) 35 Ein Vorgehensmodell zur Modellierung Womit fängt man an? Beschreibung der Systemidee in 5-20 Sätzen: Was soll mit dem System erreicht werden (nicht wie wird das Ziel erreicht) Dokumentenanalyse: Formulare, Bedienungsanleitungen, Fragebögen, … Re-Engineering: Anleitungen, Hilfesystem, Bildschirmmasken, Benutzerdialoge, Funktionalität Pflichtenheft: Textuelle Beschreibung dessen, was das System leisten soll, detaillierter als das Analysemodell 36