Kapitel 5 - Entwurfsprozess

Entwurf

Entwurf - Ziele, Struktur und Prozess

• Ziel ist Spezifikation des Wie's (Also How to Solve?)
• Das Design bringt die Anforderungsspezifikation in Vorlagen für Implementierung
• Entscheidungen über HW und SW Plattform
• Softwarearchitektonische Entwurfsphase (grundlegende Komponenten und Muster)
• Detailierter Entwurf der Module (verfeinern der Komponenten - nur Spezifikation)

Auf welche möglichen künftigen Änderungen soll im Entwurf vorgegriffen werden?

Was sind Patterns?

Was ist eine Softwarearchitektur?

• beschreibt die Struktur des SW-Systems durch Systemkomponenten (z.B. Unterprogramme, abstrakte Datentypen, Klassen) und ihre Beziehungenuntereinander
• Besteht aus Komponenten, der Struktur des Systems und der Kommunikationzwischen den Komponenten
• Entwurf der Architektur setzt viel Intuition und Erfahrung voraus

• Beherrschung der Komplexität des SW-Systems
• Arbeitsteilung im Rahmen eines Teams
• Wiederverwendbarkeit
• einfache Wartbarkeit

Welche Patterns werden in der Softwarearchitektur benutzt (Beispiele)?

• Schichtenarchitektur (wie Schichtenmodell von TCP/IP)
• Pipes und Filters Architektur (Scanners, Parser, Semantikanalyse, Optimierung)
• Broker Architektur (Kommunikationsbasiert für verteilte Systeme)
• Model-View-Controller Architektur (interaktive Applikation mit Modell, View und Events
• Presentation-Abstraction-Control (Präsentation,Abstraktion und Steuerung derAgenten)

Modularisierung

• ist logische Einheit mit klar abgegrenztem Aufgabenbereich
• Kommunikation mit anderen Modulen nur über Ex-/Importschnittstelle
• Geheimnisprinzip - Innere Funkionen und ADT's für Umwelt verborgen
• austauschbar durch anderes Modul mit gleicher Exportschnittstelle
• kann getrennt von anderen Programmteilen entwickelt werden
• positiv für Wartbarkeit, Wiederverwendbarkeit ,Testbarkeit und Portabilität

Modularisierung - USES, IS_USED, IS_COMPONENT_OF

• Modul ist wohl definierte Komponente eines Softwaresystems
• Funktionale Module (Leistung) oder ADT-Module / Datenobjektmodule
• USES Relation für ausgehende Kanten
• IS_USED für eingehende Kanten
• Mit IS_COMPONENT_OF oder CONSISTS_OF wird Hierarchie gebaut

Wie kommunizieren Module (Klassifikation von Moduln)?

• Über Schnittstellen (Variablen, Funktionen etc), welche explizit als Schnittstelle gekennzeichnet werden (exportiert)
• Export (Dienst anbieten) und Import (Dienst anfordern bzw. einfügen)
• Vorteil ist die Abstraction der Module, da Details verschlossen bleiben
• Solange das Interface nicht geändert wird, verursachen Änderungen im Modul keinen Mehraufwandt

Schnittstelle - EXPORTED, IMPORTED, Entwurf

1. sonst zu komplex und unverständlich
2. sonst Fehleranfälligkeit in Implementierung
3. zu viele Informationen könnten missbraucht werden

Notation des Modulentwurfs

• Keine Standartisierte Notation bis jetzt
• Jede Notation ist so Formal wie es die Syntax ist
• die Semantik der Exports wird aber nicht formal spezifiziert
• Textnotation beinhaltet Funktionsrümpfe und Beschreibung in natürlicher Spache
• Graphische Design-Notation zeigt ein Diagramm mit Relationen (USES) und CONSIST_OF-Beziehungen

Was ist ein generisches Modul oder Unterprogramm?

• Generische Module enthalten nur Strukturinformationen
• Anwendungsspezifische Datenfelder werden vom Anwender dazugefügt

Schrittweises Vorgehen und Verfeinern - Vorteile, Nachteile

• Schrittweise Top-Down Verfeinerung beliebteste Methode
• In jedem Schritt wird Problem in Unterprobleme zerlegt
• Subsolutions werden einfach zusammengelinkt über Kontrollstrukturen
• Decomposition Tree zur Darstellung

1. bei großen Programmen schlecht umsetzbar
2. führt nicht immer zur besten Lösung
3. Entwurf ist ein kreativer Prozess, der so nicht umgangen werden kann
4. entdecken anderer Lösungen bleibt so oft auf der Strecke

1. Unterprobleme werden isoliert betrachtet, deshalb keine Generalisierung möglich
2. kaum eine Wiederverwendbarkeit
3. keine Vereinigung mehrerer Subproblems
4. kein Information Hiding, da keine Kapselung
5. falls sich was in Struktur ändern, muss alles überarbeitet werden

Bearbeitung von Anomalien - Ausnahmen

• Unerwartete und unvorhergesehene Umstände müssen abgeschirmt oder abgefangen werden (Exeptions)
• Ein Modul sollte bei einer Anomalie ein Exeption-Signal an den Client senden, der einen Exception Handler aufruft (z.B. für Overflow, Div by Zero etc.)
• Try {...} catch (EXEPTION) { //Exeption bearbeiten}

Verifikation und Tests

• Motivation
• Testfälle und Testmethoden
• black-box-Testen
• white-box-Testen

Verifikation, kleine Programme, große Systeme, Ansätze

• Kleine Programme durch mehrere Beispielanwendungsfälle
• Mit dem Verhalten des Programmes experimentieren = Testen
• Das Programm analysieren = Korrektheit herleiten
• Problem ist das die Verifikation auch zu verifizieren ist

Testen - Problem von Kontinuität

• Das System wird in repräsentativen Fällen getestet
• Es ist nicht mögliche alle Zustände zu testen
• Problem der Kontinuität ist, dass Software nicht weiß, wie Ordnung der Werte bei Vergleichen semantisch korrekt ist

Theoretische Probleme des Testens, vollständiges Testauswahlkriterium

• Konsistenz und Vollständigkeit der Test sind nicht machbar

Empirisches Testen

• Es wird mit verschiedenen Testreihen (Gruppen) verschiedene Use Cases getestet
• Da ein vollständiger Test nicht möglich, wird zum idealen Test Set approximiert
• Die Schwierigkeit besteht darin alle wichtigen Gruppen einer bestimmten Problemklasse zu finden

Unterschiede zwischen White-Box-Testen und Black-Box-Testen

• White-Box Tests benutzen interne Struktur der Software und ignorieren ggf. die Spezifikation
• Black-Bock-Tests basieren ausschließlich auf der Spezifikation, da kein Wissen über Code oder Entwurf vorhanden ist

Abdeckung von Anweisungen, Kanten, Bedingungen, Pfaden

• Abdeckung von Anweisungen (Ein Fehler kann nicht entdeckt werden, wenn der Teil des Programms den Fehler enthält, der nicht ausgeführt wird)
• Deshalb sollte jede elementare Anweisung überprüft werden
• Abdecken von Kanten (jede Kante des Kontroll-Fluss-Graphen muss einmal traversiert werden, was nicht immer geht.. z.B. Loop Condition besteht aus mehreren Konjunktionen)
• Abdecken von Bedingungen (Jede Kante des Kontroll-Fluss-Graphen wird traversiert und dabei jeder mögliche Wert für alle Bedingungen eingesetzt)
• Pfadabdeckung (alle Pfade von Anfangszustand zum Endzustand im Controll-Fluss-Graph werden traversiert. Meistens sind dort zu viele Pfade aufgrund vieler Loops im Programm. Jede Iteration ist ein extra Pfad!)

Syntaxgesteuertes Testen, Testen von Grenzwerten

• Syntaxgesteuertes Testen heißt, das für jede Produktion der BNF ein Testfall bearbeitet wird, d.h. alle Grammatikgesetze werden überprüft

Testen im Großen, Bottom-Up-Integration und Top-Down-Integration, Vorteile, Nachteile

• Big-bang - gar kein integriertes Testen
• Incremental - einfacher Fehler zu finden

• bottom-up (USES Hierarchie)
• top-down (lower level Simulation)

Was ist Debugging?

• Aktivität des Suchen und Behebens von Fehlern, nachdem er entdeckt wurde

Entwurf der Benutzerschnittstelle

• Software wird verworfen
• Es können schnell Fehler gemacht werden
• Heute notwendige Komponenten

• GUI's sollten Fähigkeiten der individuellen User unterstützen
• Konsistenz und Hilfesystem

Konsistenz der Benutzerschnittstelle

• Gleiche Format besitzen
• Parameter immer gleich übergeben
• Untersysteme sollten sich ähneln
• Nutzer sollte beim Erlernen eines Kommandos rückschlüsse auf Bedienung aller Anderen ziehen können

Eingebaute HELP-Unterstützung

• Vom Benutzerterminal erreichbar
• "How to get started?"
• Volle Beschreibung des Systems und wie es zu Nutzen ist
• Strukturierte Hilfe

Schablonen für Benutzerschnittstelle

• Control Panel
• Desktop
• Trash

WIMP-Schnittstelle

• Einfach zu lernen
• Viele Oberflächen zur Interaktion
• Überschaubar und unkompliziert

• Keine Standarts
• Schwer möglich sinnvolle Icons für abstrakte Komponenten zu finden

Systeme mit Menü

• Benutzer müssen nicht den genauen Befehlnamen wissen
• Weniger Tipparbeit
• System kann nicht in Fehlerzustand geführt werden
• Contextsensitive Hilfe
• Pull-Down und Pop-Up Menüs

• Logische Verknüpfungen unmöglich ausdrückbar
• Für Experten Menü langsamer als Commandozeile
• Menühierarchie schnell komplex wenn viele Auswahlmöglichkeiten

Graphische Schnittstelle

• Grafiken werden zu Darstellung von Informationen verwendet
• Bilder sagen mehr als Worte
• Trends sind sichtbar

Textuelle Schnittstelle

• Kommandozeileninterpreter billig und einfach
• Kombinierende Kommandos erweitern Funktionalität und Aufrufkomplexität
• Externe Prozeduren und Programme können eingebunden werden
• Erfahrene Benutzer sehr schnell

• Lernen aufwendig
• Fehler in Kommandos möglich
• Interaktion durch Tastatur (langsam)
• aber nicht für unerfahrene Nutzer sinnvoll

Entwurf von Fehlermeldungen

• Ersteindruck an Nutzer
• Schwer für unerfahrene Anwender
• Eigenschaften: Konsistent, Konstruktiv, Eindeutig und Präzise
• Nachricht sollte Beschreibung zur Fehlerbehebung enthalten
• On-Line Hilfe sollte auftufbar sein

Anwendung von Farbmonitoren

• Nicht zu viele Farben nutzen (4-5)
• Konsistenz bei Farbwiederverwendung
• Farbanpassung sollte durch Nutzer einstellbar sein