Nichtfunktionale Anforderungen

Nur eine Untermenge der NF Anforderungen kann gleichzeitig erfüllt werden. Ansonsten „Good, fast, cheap. Pick any two“

Zwei Entwurfsmethoden:

1. Modularer Entwurf

2. Objekt-Orientierter Entwurf

a. Erweiter den modularen Entwurf um Vererbung, Polymorphie und Datenmodellierung

Modularer Entwurf

Systemarchitektur beim Modularen Entwurf:

1. Modulführer (Grobentwurf, module guide, swoftware architecture)

· Gliederung in Komponenten und Subsysteme

· Beschreibung der Funktion jedes Moduls

· Benutzt Entwurfsmuster, z.B. Schichtenarchitektur oder Fließbandarchitektur

2. Modulschnittstellen (module interfaces)

· Genaue Beschreibung der von jedem Modul zur Verfügung gestellten Elementen

· Für Module mit Eingaben und Ausgaben auch genaue Beschreibung der entsprechenden Formate

3. Benutzt Relation

· Gliederung in Komponenten und Subsysteme

· Beschreibt wie sich Module und Subsysteme untereinander benutzen

4. Feinentwurf

· Beschreibung modul-internen Datenstrukturen und Algorithmen

· Bei Assembler auch pseudocode

· Der Pseudocode ist meistens in einer höheren hypothetischen Sprache abgefasst und wird in Implementierungsphase in Assembler umgesetzt

Externer Entwurf 1 und 2

Interner Entwurf 3 und 4

Module sollen unabhängig voneinander bearbeitet und benutzt werden sollen

Ein Modul sollte ohne Kenntnis seines internen Aufbaus benutzt werden können

Starke Kohäsion innerhalb des Moduls, soll einfach genug sein, um für sich selbst voll verstanden zu sein.

DEF. Modul: Ein Modul ist eine Menge von Programmelementen, die nach dem Geheimnisprinzip gemeinsam entworfen und geändert werden.

Programmelemente sind Typen, Klassen, Konstanten, Variablen, Datenstrukturen, Prozeduren, Funktionen, Prozesse (Fäden), Prozess-Eingänge, Makros etc.

DEF Geheimnisprinzip: Jedes Modul verbirgt eine wichtige Entwurfsentscheidung hinter einer wohldefinierten Schnittstelle, die sich bei einer Änderung der Entscheidung nicht mit ändert.

Grund: Nur was verborgen und unbenutzt ist, kann ohne Risiko geändert werden.

Voraussehbare Änderungen sollten ohne Schnittstellenänderungen möglich sein, damit der Rest des Systems nicht angepasst werden soll.

Nur seltene Änderungen sollten Schnittstellen von oft benutzten Modulen beeinflussen.

 

Vorgehensweise beim Entwurf nach dem Geheimnisprinzip:

· Bilde Liste von Entwurfsentscheidungen, die schwierig sind, oder die sich voraussichtlich ändern werden

· Weise jede Entscheidung einem Modul hinzu und definiere die Schnittstellen so, dass sie sich bei den Änderungen nicht mit ändern.

Kandidaten für Verbergung:

· Klassiker: Datenstrukturen und Operationen an denen

· Maschinennahe Details

· Betriebssystemnahe Details

· Grundsoftware wie Datenbanken, Oberflächenbibliotheken

· Ein- Ausgabeformate

· Benutzungsschnittstellen

· Text von Dialogen, Beschriftungen, Ausgaben

· Größe von Datenstrukturen

· Reihenfolge der Verarbeitung

Ergebnis: Modulführer(Grobentwurf), der beschreibt:

· Die Entwurfsentscheidungen, die das Geheimnis des Moduls sind

· Die Funktion des Moduls

· Die Gliederung von Subsystemen in Modulen

Vorteile von sorgfältig aufgestelltem Modulführer:

· Vermeidet Duplikation

· Vermeidet Lücken

· Liefert eine Zerlegung des Problems

· Erleichtert das Auffinden von betroffenen Modulen während der Wartung

Dokumentation von Modulschnittstellen enthält nur genau die Informationen die sowohl für die Benutzung als auch für die Implementierung des Moduls erforderlich sind.

Beschreibung der Modulschnittstellen:

· Liste der öffentlichen Programmelemente

· Ein-/Ausgabeformate (falls E/A-Modul)

· Parameter und Rückgabewerte der Unterprogramme/Operationen

· Beschreibung des Effekts der Unterprogramme Zeitverhalten, Genauigkeit, Speicherplatzbedarf und andere Qualitätsmerkmale, wo erforderlich

· Fehlerbeschreibung und Fehlerbehandlung

· Ausnahmen, die ausgelöst und nicht behandelt werden.

 

Module sind Klassen und Interfaces in OO-Sprachen

 

DEF. Benutztrelation: Programmkomponente A benutzt Programmkomponente B genau dann, wenn A für den korrekten Ablauf die Verfügbarkeit einer korrekten Implementierung von B erfordert.

 

Verfügbarkeit heißt:

· A delegiert Arbeit nach B

· A greift auf eine Variable von B zu

· A ruft B und brauch dann den korrekten Ablauf

· A legt eine Instanz eines Typs B an

· A steuert B durch Unterbrechungen oder Ereignisse an

 

 

A soll B benutzen wenn:

· A wird durch Benutzung von B einfacher

· B wird nicht wesentlich komplexer dadurch, dass es A nicht benutzen darf

· Es gibt mind eine nützliche untermenge, die B, aber nicht A enthält

· Es gibt keine Untermenge, die A, aber nicht B enthält

DEF: Wenn die Benutztrelation zyklenfrei ist, dann heißt sie Benutzthierarchie

Benutztrelation zwischen Modulen soll eine Hierarchie sein

Nachteil von Zyklen: Nothing works until everything works

Vorteil von Zyklen:

· Schrittweiser Ablauf und Testen möglich

· Bildung von Untermengen

o Zum Einbau in andere Systeme

o Zur Eigenständigen Entwicklung

o Zur Teillieferung bei entwicklungsverzögerungen

Callbacks sind keine Benutztrelationen, weil sie die Korrekte implementierung nicht brauchen.

Objektorientierter Entwurf

Im Objektorientiertem Entwurf behalten die Prinzipien aus modularen Entwurf ihre Gültigkeit

Schnittstellen verbergen die Entwurfsentscheidungen, die veränderbar sein sollen.

Externer Entwurf:

· Die Analoga zum Modul sind die Klassen und das Paket

· Im Paket werden mehrere Klasse mit gemeinsamen Ziel zusammengefasst.

· Eine Klasse kann ein Modul verwirklichen, aber oft braucht man mehrere Klassen.

Externer Entwurf:

· Anstelle des Modulführers tritt Paket- und Klassenführer. Das sind UML Klassendiagramm und UML Packetdiagramm.

· Analog zu den Modulschnittstellen sind die Interfaces von Klassen, abstrakte Klassen und reine Schnittstellen

Interner Entwurf:

· Die Benutztrelation wird auf der Ebene der Paketen und alleinstehenden Klassen dokumentiert.

· Der Feinentwurf liefert die Beschreibung von Modulinternen Datenstrukturen und Algorithmen, sowie Pseudocode, wo erforderlich.

Zusätzlich sind neu im OO-Entwurf:

· Mehrfach-Instanziierung von Klassen

· Vererbung und Polymorphie

· Variantenbildung in einem Programm durch Mehrfachimplementierung einer Schnittstelle

Deswegen sind Entwurfsmuster entstanden.

 

Entwurfsmuster

http://www.jetpunk.com/user-quizzes/27013/entwurfsmuster

http://www.vincehuston.org/dp/patterns_quiz.html

 

DEF: Ein Software-Entwurfsmuster beschreibt eine Familie von Lösungen für ein Softwareentwurfsproblem.

· Zweck ist die Wiederverwendung.

· Entwurfsmuster sind für Programmieren im Großen, was die Algorithmen für Programmieren im Kleinen sind.

Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice.

Muster verbessern die Kommunikation im Team.

Muster erfassen wesentliche Konzepte und bringen sie in eine verständliche Form.

· Muster helfen Entwürfe zu verstehen

· Muster dokumentieren Entwürfe kurz und knapp

· Muster verhindern Architektur-Drift(Verschlechterung bei Änderungen)

· Muster verdeutlichen Entwurfswissen

Muster dokumentieren und fördern den Stand der Kunst:

· Muster helfen wenig erfahrenen Entwerfer

· Muster vermeiden die Neuerfindung des Rades

· Muster sind keine feste Regeln sondern ein Vorschlag, Anpassung erforderlich.

· Muster können die Code-Qualität und Struktur verbessern.

 

Entwurfsmuster Kategorien

1. Entkopplungs-Muster (Entkopplungs-Muster teilen ein System in mehrere Einheiten, so dass einzelne Einheiten unabhängig voneinander erstellt, verändert, ausgetauscht und wiederverwendet werden können. Der Vorteil von Entkopplung ist, dass ein System durch lokale Änderungen verbessert, angepasst und erweitert werden kann, ohne das ganze System zu modifizieren.)

Mehrere der Entkopplungsmuster enthalten ein Kopplungsglied, das entkoppelte Einheiten über eine Schnittstelle kommunizieren lässt.

· Adapter (wenn existierende Klasse verwendet sein soll)

· Beobachter

· Brücke

· Iterator

· Stellvertreter

· Vermittler

2. Varianten-Muster (In Mustern dieser Gruppe werden Gemeinsamkeiten von verwandten Einheiten aus ihnen herausgezogen und an einer einzigen Stelle beschrieben. Wiederholungen desselben Codes werden vermieden)

· Abstrakte Fabrik

· Besucher

· Fabrikmethode (Variation von Klassen der erzeugten Objekten)

· Kompositum (oft zusammen mit Dekorierer)

· Schablonenmethode

· Strategie (Variation der Operationen)

· Dekorierer

3. Zustandshandhabungs-Muster (Die Muster dieser Kategorie bearbeiten den Zustand von Objekten, unabhängig von deren Zweck.)

· Einzelstück

· Fliegengewicht (z.B. Buchstaben in Word, nur Position getrennt speichern)

· Memento

· Prototyp

· Zustand

4. Steuerungs-Muster(Steuerungsmuster steuern den Kontrollfluss. Sie bewirken, dass zur richtigen Zeit die richtigen Methoden aufgerufen werden)

· Befehl

· Master/Worker

5. Bequemlichkeits-Muster (Diese Muster sparen etwas Schreib- oder Denkarbeit)

· Bequemlichkeits-Klasse

· Bequemlichkeits-Methode

· Fassade

· Null-Objekt

6. Virtuelle Maschinen

i. Virtuelle Maschinen erhalten Daten und ein Programm als Eingabe und führen das Programm selbständig an den Daten aus.

ii. Sind in Software und nicht in Hardware implementiert.

Die Implementierungsphase

· UML in ablauffähigen Code umwandeln

· Programmierrichtlinien anwenden und überprüfen können

· Selbstkontrolliertes Programmieren anwenden können

Implementierungsphase:

· Programmierung, Dokumentierung und Testen der Systemkomponenten aufgrund vorgegebener Spezifikationen der Systemkomponenten

Systemkomponente sehen so aus bei:

· Modularer Entwurf

o Funktionales Modul

o Datenobjekt Modul

o Datentyp Modul

· OO-Entwurf

o Schnittstelle, Klasse

o Paket (Menge von integrierenden Klassen)

Voraussetzungen:

· Für jede Systemkomponente existiert eine Spezifikation

· Die Softwarearchitektur ist so ausgelegt, dass die Implementierungen pro Funktion, Zugriffsoperation bzw. Methoden wenige Seiten nicht überschreiten.

Aktivitäten:

· Konzeption von Datenstrukturen und Algorithmen

· Strukturierung des Programms durch geeignete Verfeinerungsebenen

· Dokumentation der Problemlösung und der Implementierungsentscheidungen

· Umsetzung der Konzepte in die Konstrukte der verwendeten Programmiersprache

· Angaben zur Zeit- Speicherkomplexität

· Evtl. Programmoptimierungen

· Test oder Verifikation des Programms einschl. Testplannung und Testfallerstellung

· Programmieren im Kleinen genannt

· Alle Teilprodukte aller Systemkomponenten müssen später integriert und einem Systemtest unterzogen werden

 

Teilprodukte:

· Quellprogramm einschl. integrierter Dokumentation

· Objektprogramm

· Ausführbare Testfälle und Testprotokoll bzw. Verifikationsdokumentation