Probleme bei Anforderungsermittlung

Ausbuchen

· Striktes Ausbuchen: mit Änderungsreservierung

o Kein Verschmelzungsaufwand

o Immer nur eine Person arbeitet, andere warten

· Optimistisches oder mehrfaches: ohne Änderungsreservierung.

o mehrere gleichzeitig arbeiten, keiner hält die Arbeit auf

o Aufwand bei Verschmelzungen, wenn es Konflikte gibt. (Der erste braucht nicht zu verschmelzen, andere schon)

Anforderungsanalyse und Entwurf sollen auch in Versionskontrolle.

Revision Control System 1983

· Automatisiert

o Aufbewahrung

o Wiederherstellung

o Logbuch

o Automatische Identifikation der Software-Elemente

o Verschmelzen von Versionen

· Versionierung von Verzeichnissen nicht unterstützt

· Nicht netzwerkfähig

· Open source (einer der ersten)

Concurrent Versions System 1990

· Intern RCS, aber netzwerkfähig und speichert ganze Bäume

Subversion SVN 2000

· Weiterentwicklung von CVS

· Internetfähig, mit entferntem Server.

· SVN versioniert gesamten Depot, inkl. Verschieben, Umbenennen, Kopieren von Verzeichnissen und Dateien.

· Einbuchen wird ganz oder gar nicht übertragen, d.h. atomar.

· Optimistisches Ausbuchen

Varianten in SVN

· Keine eingebaute Semantik zur Variantenbildung

· Stattdessen Unterverzeichnisse, die die Alternativen enthalten

· Trunk: Hauptentwicklungslinie

· Tags: Kopien von anderen Verzeichnissen zu einem bestimmten Entwicklungsstand, benutzt um Freigaben einzufrieren.

svn create - wie git init

svn commit führt kein Verschmelzen automatisch.

Bei Konflikten beim einbuchen bricht SVN ab, benutze update zuerst.

Git 2005

 

SWT

DEF Softwaretechnik: ist die technologische und organisatorische Disziplin zur systematische Entwicklung und Pflege von Softwaresystemen, die spezifizierte funktionale und nicht-funktionale Attribute erfüllen.

Beantwortet Fragen:

· Eigenschaften herausfinden (Anforderungsermittlung)

· Eigenschaften beschreiben (Spezifikation)

· Strukturieren, um leicht zu bauen und flexibel verändern(Entwurf)

· Verändern von Software ohne Struktur (Pflege, Restauration)

· Vermeiden und Aufdecken von Mängel (Qualitätssicherung, Test)

· Arbeit Organisieren, um regelmäßig kostengünstige und hochwertige Resultate zu erzielen (Prozessmanagement)

DEF Software: Sammelbezeichnung für Programme und Daten, die für den Betrieb von Rechensystemen zur Verfügung stehen, einschl. der zugehörigen Dokumentation.

DEF Software (eng.): Computer programs, procedures, rules, and possibly associated documentation and data pertaining to the operation of a computer system.

Beispiele für Programme: Quellprogramme, Zwischencode, Objektcode, Bibliotheken, Rahmenarchitekturen, Installationsprogramme, Testprogramme, lauffähige Beispiele.

Beispiele für zugehörige Daten: Initialisierungsdaten, Hilfsinformation, Fehlermeldungen und Dialogtexte (evtl. mehrsprachig), Zeichensätze, Testdaten, erwartete Testausgaben.

Beispiele für Dokumentation: Anforderungsdokumentation, Architekturbeschreibung, Funktionsbeschreibungen der einzelnen Klassen/Methoden, Test-und Abnahmeprotokolle, Anwendungsbeispiele, Benutzerhandbücher, Fragen und Antworten, interaktive Hilfe.

Mit Software nicht gemeint sind reine Daten, z.B. Musikstücke, Bücher, statische Webseiten, Inhalt von Datenbanken.

DEF Softwareprodukt: Produkt aus Software.

Ein Produkt ist ein in sich abgeschlossenes, für einen Auftraggeber oder einen anonymen Markt bestimmtes Ergebnis eines erfolgreich durchgeführten Projekts oder Herstellungsprozesses“

DEF Systeme: sind bei dieser Betrachtungsweise aus Teilen (Systemkomponenten oder Subsystemen, real oder konzeptionell) zusammengesetzt, die untereinander in verschiedenen Beziehungen stehen und wechselwirken können.

DEF Systemsoftware: auch Basissoftware genannt. Für eine spezielle Hardware oder eine Hardwarefamilie entwickelt, um den Betrieb und die Wartung dieser Hardware zu ermöglichen und zu erleichtern

 

DEF Anwendungssoftware: Löst die Aufgaben des Anwenders mit Hilfe von Rechenanlagen.

 

Systementwicklung – Entwicklung eines Systems, das aus Hardware- und Softwarekomponenten besteht.

 

Charakteristiken von Software:

· Immaterieles Produkt

· Unterliegt keinem Verschleiß

· Nicht durch physikalische Gesetze begrenzt

· Nicht leichter als ein physikalisches Produkt änderbar

· Einfacher und schneller zu verteilen und installieren als Physisches

· Altert sich

· Schwer zu vermessen

 

Änderungen in der Software in den letzten Dekaden

· Zunehmende Bedeutung –Software wird zur Wertsteigerungstechnikin vielen Bereichen

· Wachsende Komplexität

· Wachsender Anteil an Software in mobilen Geräten

· Vernetzung und geographische Verteilung

· Zunehmende Qualitätsanforderungen

· Nachfragestau und Engpasstechnik

· Zunehmende Standardsoftware

· Zunehmend „Altlasten“

· Zunehmend „Außer-Haus“-Entwicklung

 

In exportorientierten Branchen der deutschen Wirtschaft übersteigt der Softwareanteil an der Wertschöpfung der Produktehäufig die 50%-Marke. Bei Anlagen der digitalen Vermittlungstechnikentfallen bis zu 80% der Entwicklungskosten auf Software.

 

Während der Entwicklung ändern sich die Produktanforderungen(neue Funktionen, geänderte GUI, neue Schnittstellen), Komponenten von Hardware- Systemsoftware(neuer Prozessor, andere Peripherie, anderes Fabrikat, technische Innovationen), die neue Produktionsmittel, hohe Portabilitätsanforderungen sind einzuhalten.

 

Organisatorische Aspekte:

· Personalfindung

· Arbeitsorganisation

· Leitung(Motivation, Kommunikation von Zielen)

· Kontrolle

 

Entwicklung und Pflege 2/3 der Kosten.

DEF Softwareforschung: ist die Bereitstellung und Bewertung von Methoden, Verfahren und Werkzeugen für die Softwaretechnik

 

Methoden(Konzepte) – Planmäßig angewandte, begründete Vorgehensweisen zur Erreichung von festgelegten Zielen.

Verfahren –sind ausführbare Vorschriften oder Anweisungen zum gezielten Einsatz von Methoden.

Werkzeuge – Dienen der automatisierten Unterstützung von Methoden, Verfahren, Konzepten oder bieten Notationen/Sprachen an(Einhaltung von Methoden, Verfahren, Standards, und Notationen erzwungen und die Produktivität durch Automatisierung erhöht werden)

Werkzeuge automatisieren Tätigkeiten, die:

· hohe Präzision erfordern

· oft wiederholt werden müssen

· eine Überprüfung erfordern

 

 

Planung

(Lastenheft, funktionales Modell)

 

Wasserfallmodell

1. Planung/Anforderungsermittlung (eng. Requirements elicitation) (Lastenheft, Durchführbarkeitsstudie, Plan, Kalkulation)

2. Definition

3. Entwurf

4. Implementierung

5. Testen

6. Abnahme -> Einsatz & Wartung

 

 

Eng.

1. Requierements

2. Design

3. Coding

4. Testing

5. Maintenance

Planungsphase: Lastenheft in Worten des Kunden beschreiben und Durchführbarkeitsstudie.

DEF Anforderung: A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed document. The set of all requirements forms the basis for subsequent development of the system or system component.

Die Planungsphase beginnt mit der Auswahldes Produktes:

· Auftrag eines Kunden

· Forschungsergebnisse

· Vorentwicklungen

· Trendstudien

· Marktanalysen

· Eine Idee!

DEF Szenario: Ist die Beschreibung eines Ereignisses odereiner Folge von Aktionen und Ereignissen.

· Aus Sicht des Benutzers.

· Iterativ erweitert und bearbeitet, wenn die Anforderungen ändern

· Informell

· Als Arbeitspaket angesehen

· Konkrete Beschreibungen

· In der Testphase einsetzen

Kunde gibt keine Anweisungen.

· Helfen den Kunden Fragen zu formulieren

· Kunde hilft Anforderungen zu verstehen

· Anforderungen ändern, währen das Szenario entwickelt wird

Finden von Szenarien:

· Hauptaufgaben

· Welche Daten werden im System operiert

· Änderungen außerhalb, dass System wissen muss

· Änderungen die Benutzer, über die der Benutzer informiert sein muss

Anwendungsfalldiagramme werden während der Planungsphase verwendet, um das von außen sichtbare Verhalten des Systems darzustellen.

DEF Ein Akteur(actor): spezifiziert eine Rolle eines Benutzer oder eines anderen Systems, welches mit dem von uns geplanten System interagiert

DEF Ein Anwendungsfall (use case) stellt eine Klasse von Funktionen dar, welche das System anbietet.

DEF Anwendungsfalldiagramm (use case model) ist die Menge aller Anwendungsfälle, welche die gesamte Funktionalität des Systems beschreiben.

 

Erweiternde Beziehung (engl. Extend relationship):Stellt selten aufgerufene Anwendungsfälle oderaußergewöhnliche Funktionalität dar.

Einschließende Beziehung (engl. include relationship):Stellt Funktionalität dar, welche von mehr als einem Anwendungsfall verwendet wird

 

<< extend>>

<<include>>

­­­Anwendungsfälle finden:

· Begrenzten vertikalen Ausschnitt nehmen, z.B. ein Szenario

· Horizontalen Ausschnitt wählen z.B viele Szenarien

· Prototypen benutzen

· Beobachtung was Benutzer tut, Befragung(ungenau)

Formulieren von Anwendungsfällen:

1. Name

2. Akteure

3. Ereignisfluss

Anforderungsverwaltung

· Anforderungen in einem gemeinsamen Verzeichnis

· Mehrbenutzerunterstütung für den Zugriff

· Spezifikationsdokument automatisch erstellen

· Biete Verfolbarkeit der Anforderungen

Lastenheft

1. Zielbestimmung

2. Produkteinsatz(Wozu, Zielgruppe, Platform)

3. Funktionale Anforderungen

4. Produktdaten

5. Nichtfunktionale

6. Systemmodelle

a. Szenarien

b. Anwendungsfälle

7. Glossar

8. Durchführbarkeitsuntersuchung

a. Fachliche Durchführbarkeit

b. Alternative Lösungsvorschläge

c. Personelle Durchführbarkeit

d. Risiken

e. Ökonomisch

f. rechtlich

 

Definitionsphase

 

Pflichtenheft (Objektmodell, dynamisches Modell (UML),

GUI Konzept)

­­­­­­ DEF Das Pflichtenheft definiert(„modelliert“) das zu erstellende System(oder die Änderungen an einem existierenden System) so vollständig und exakt, dass Entwickler das System implementieren können, ohne nachfragen oder raten zu müssen, was zu implementieren ist.

NICHT WIE, sondern WAS

Verfeinerung des Lastenhefts

Modellarten:

· Funktionales Modell

o Szenarien und Anwendungsfalldiagramme

· Objektmodell

o Klassen und Objektdiagramme

· Dynamisches Modell

o Sequenzdiagramme

o Zustandsdiagramme

o Aktivitätsdiagramme

Wirklichkeit –> Modell –> Code

Benutzen Modelle um:

· Von Realität zu abstrahieren, komplexe Dinge einfacher machen

· Erkenntnisse über Vergangenheit oder Gegenwart zu erhalten

· Vorhersagen über die Zukunft

Softwaremodelle benutzen, um zu sehen, was wir bekommen würden, wenn wir es bauen würden

Beziehungen in die in Realität gültig sind, sind auch in Modell gültig

Modellierung ist relativ (Realität modellieren, dann Modell wieder Modellieren usw.)

Softwareentwicklung heißt Modelltransformation

Verschiedene Realitäten Modellieren:

· Existierendes System modellieren und realisieren

· Idee in Realität modellieren und realisieren

 

UML Klassendiagramme

UML – Unified Modelling Language

Vereinigung dreier Notationen (Booch, OOSE, OMT)

Assoziationen für zusammengehörigen Referenzen aufeinander.

 

Klassendiagramme sind Multigraphen – mehrere Assoziationen.

 

Transaktionalität der Assoziationen: (ACID)

· Atomicity – Unteilbarkeit der Änderung, ganz oder gar nicht

· Consistency – Änderungen hinterlassen einen konsistenten Zustand

· Isolation – Änderungen in nebenläufigen Programmen laufen ohne Beeinflussung durch andere Ausführungsfäden ab

· Durability – Änderungen nach Abschluss dauerhaft zu sehen

Transaktionalität ODER mehrere nötig ODER Zurücknavigation –> Assoziation

Guter Stil: Nur Attribute primitiver Typen

Def. Eine Assoziation (engl. association)definiert Eigenschaften von n-ären Relationen zwischen Mengen:

· Die Mengen werden als Klassen angegeben.

· Multiplizitäten oder Vielfachheiten geben an, in wie vielen Tupeln der Relation Elemente einer geg. Klasse erscheinen dürfen(z.B. eindeutig 1:1, mehrdeutig: 1:n, m:n, sowie Totalität)

· Die Klassen brauchen nicht disjunktzu sein (Selbstreferenz ist erlaubt).

· Ein Tupeleiner Relation heißt Verknüpfung.

· Duplikate von Tupelnsind erlaubt, d.h. die Relationen sind eigentlich Mehrfachmengen oder auch Multigraphen.

 

Assoziation – mögliche Beziehungen, zwischen Klassen angegeben.

Verknüpfung – tatsächliche Beziehungen, zwischen Exemplaren angegeben.

n-äre Assoziation – n-1 Enden festsetzen, die n-te Multiplizität auslesen

{ordered}{unique} unter den Rollen Schreiben

Vererbung

DEF Liskovsches Substitutionsprinzip (engl. Liskov substitution principle): In einem Programm, in dem U eine Unterklasse von K ist, kann jedes Exemplar der Klasse K durch ein Exemplar von U ersetzt werden, wobei das Programm weiterhin korrekt funktioniert.

Gleiche oder schwächere Vorbedingungen (Eingaben)

Gleiche oder stärkere Nachbedingungen (Ausgaben)

Unterklassenmethoden dürfen nicht mehr erwarten und weniger liefern. (Sollen weniger erwarten und mehr liefern)

DEF Signaturvererbung: Implementierte Methode der Unterklasse überträgt nur ihre Signatur auf die Unterklasse.

DEF Implementierungsvererbung: klar

Überschreiben = override

Überladen ­= polymorphie

{abstract} vor der Name der Klasse in UML, oder kursiv

DEF Schnittstelle: Menge der abstrakten Methoden, die implementierende Klassen implementieren müssen.

Schnittstellen haben keine Vererbung sondern Erweiterung.

Parameter-Varianz:

· Def. Varianz (engl.variance): Modifikation der Typen der Parameter einer überschriebenen Methode

· Def. Kovarianz (engl. covariance): Verwendung einer Spezialisierung des Parametertyps in derüberschreibenden Methode

· Def. Kontravarianz (engl. contravariance): Verwendung einer Verallgemeinerung des Parametertyps in der überschreibenden Methode

· Def. Invarianz (engl. invariance): keine Modifikation des Typs

Substitutionsprinzip erfüllen:

 

Dynamische Polymorphie – die speziellste Methode in der Vererbungshierarchie verwenden.

Statische Polymorphie – überladen.

Sichtbarkeit:

· „-“ privat nur die Klasse

· “#” geschützt die Klasse und Abgeleitete

· „+“ öffentlich

· Default öffentlich

 

 

2.2 – weiter UML Diagrammtypen

1.Anwendungsfalldiagramm:

· Anforderungsspezfikation – was will der Benutzer vom System

· Modellieren typischer Interaktionen

· Gewinnung aus Dialog mit Experten oder Benutzer

· Kontrolle, ob das System gewünschte leistet

DEF Anwendungsfall: Typische gewollte Interaktion des Akteuren mit dem System

2. Aktivitätsdiagramm(parallele uns sequenzielle Abläufe):

· Beschreibt einen Ablauf

o Betriebswirtschaftliche oder geschäftliche Prozesse

o Technische Abläufe von Workflows und Anwendugsfällen

o Konkrete algorithmische Abläufe

· Bestehen aus

o Aktions- Objekt- und Kontrollknoten

o Objekt- und Kontrollflussen

Interaktionsdiagramme

Zeigen für einen bestimmten Zweck notwendigen Interaktionen zwischen Objekten.

· Kollaborationsdiagramm

· Zeitdiagramm

· Interaktionsübersicht

· Sequenzdiagramm (exemplarische Darstellung eines möglichen Ablaufs eines Anwendungsfalls) zeigt Aufrufabläufe zwischen mehreren Objekten

If/else

 

 

Operatoren

· Alt – klar

· Break [bedingung] ist wahr, dann wird der Block ausgeführt, dann endet das Szenario

· Opt [bedingung] optionale Sequenz

· Par – parallel

Zustandsdiagramm

Endlicher Automat, beschreibt Zustände, sowie mögliche Zustandsübergänge innerhalb eines einzelnen Objektes

Verwendet für:

· Interaktive Geräte

· Reale Dinge, die als automatisch bezeichnet werden

· Kommunikationsprotokolle

Gültig für den gesamten Lebenszyklus

Kantenbeschriftungen

Guarded transition – wenn es eine Bedingung gibt

ε-Übergang – braucht kein Ereignis, aber die Bedingung ist möglich, Spontanübergang.

at(ausdruck) – exakter absoluter Zeitpunkt

after(ausdruck) relativer Zeitpunkt

Eintrittsaktion (entry action): wird beim Übergang in den Zustand ausgeführt.

Schreibweise: entry / aktion()

 

Austrittsaktion (exit action): wird beim Übergang aus dem Zustand n einen anderen ausgeführt.

Schreibweise: exit / aktion()

 

Es gibt auch Hierarchische Automaten und Automaten mit Gedächtnis und parallele Automaten

5. PaketDiagram

Uses-Relation zwischen Pakete – gestrichelte Pfeil.

Objektmodellierung

Objektmodell ist ein statisches Modell

Objekten findet man als reale Objekte oder bei kommerziellen Systemen in Formularen

Attribute nehmen und zu Klassen erfassen – „bottom-up“

Klassen aus Szenarien, Anforderungen identifizieren – „top-down“

· Syntaktische Analyse (Nomen-Verb-Analyse)

· Linguistische Analyse (2.5)

· Inhaltliches Durchforstern

Keine Klasse, wenn:

· Keine Attribute und keine Operationen sich identifizieren lassen

· Dieselbe Komponenten wie eine andere Klasse enthält

· Nur Operationen, die sich anderen Klassen anordnen lassen

· Die Klasse modelliert Implementierungsdetails

· Nur wenige Attribute, so gehören diese vielleicht zu einer anderen Klasse

Assoziationen finden:

· Dauerhafte Beziehungen zwischen Klassen?

· Sind die Assoziationen problemrelevant?

· -existiert die Beziehung unabhängig von anderen unbeteiligten Klassen?

Assoziationen die keinen neuen Informationen hinzufügen vermeiden.

Je allgemeiner die Klassenname, desto wichtiger die Rolle anzugeben

Rollennamen angeben, wenn:

· Mehrere Assoziationen zwischen zwei Klassen existieren

· Eine Assoziation zwischen Objekten derselben Klasse existiert

· eine Klasse in verschiedenen Assoziationen auch verschiedene Rollen spielt

· durch den Rollennamen die Bedeutung der Klasse in der Assoziation genauer spezifiziert werden kann.

Attribute finden:

· Kann jedes Attribut im Laufe seines Lebens einen Wert annehmen?

· Ist der Wert des Attributes jemals an der Benutzerschnittstelle zu sehen?(Wenn nein – weglassen)

· Ist jedes Attribut relevant für die zu modellierende Anwendung?

· Isoliert von anderen ist das noch ein Attribut?(Wenn nein, wahrscheinlich eine Assoziation)

Kein Attribut wenn:

· Dient aussschließlich zum Identifizieren der Objekte

· Um eine Klasse zu referenzieren

· Beschreibt Entwurfs- oder Implementierungsdetails

· Aus anderen Attributen hergeleitet(meistens)

Im objektorientiertem Modell gibt es viele Assoziationen, aber erstaunlich wenig Vererbungen.

Vererben, wenn die Klasse die Operationen von der Oberklasse haben soll, aber auch muss eigene hinzufügen.

Analytische Schritte

· Besitzt die Operation geeigneten Namen?

· Angemessener Umfang

· Realisiert nur eine Funktion?

Modellierung im Großen:

· Zusammenfassung von ähnlichen Klassen zu einem Subsystem oder Paket.

· Innerhalb des Subsystems starke Kohäsion

· Zwischen Subsystemen schwache Kopplung

Starke Kohäsion:

· Nicht nur die Menge von Klassen, sondern die Subsysteme eine Betrachtung des Systems auf einer höheren Abstraktionsebene ermöglichen

· Aussagekräftiger Name

· Wohldefinierte Schnittstelle

Schwache Kopplung:

· Vererbungen nur vertikal, d.h. in demselben Subsystem

· Aggregat und Komponenten in einem Subsystem

· Die Schnittstelle zwischen Subsystemen soll möglichst wenig Assoziationen erhalten

Linguistische Analyse

Software soll im innen mit denselben Begriffen arbeiten, wie ihr Benutzer draußen.

· Es stehen ihm dieselben Funktionen zur Verfügung wie in der Realität

· Funktionen tun dasselbe in Programm wie in der Realität

· Funktionen finden sich im Programm da, wo sie in der Realität sich finden

· WYSIWG Textverarbeitung(Word)

· Grundidee der objektorientierten Programmierung

Vorgehensweise der OO-Analyse:

· Betrachte die Realität

· Modelliere den Ausschnitt, der unterstützt werden soll

· Erstellen ein Programm, Code

· Führe das Programm aus

=>Die Software arbeitet mit denselben Dingen wie ihr Benutzer draußen.

Kompetenzprobleme:

· Suche ein Softwareingenieur, der beides gelernt hat

· Frage die Domänenexperten

Rollen

· Agens (AG) – der Handelnde – Klasse

· Patiens (PAT) – der Behandelte ­­– Klasse, Methodenparameter bei ACT

· Actus (ACT) – die Handlung von Agens – Methode beim AG

· Instrumentum (INSTR) – Hilfsmittel ­– Klasse, Methodenparameter bei ACT

· Status (STAT) – der Zustandsverben und Nominalisierungen – Beziehung zwischen Klassen

· Locus (LOC) – Ort, Positionsangaben – Klasse

· Omnium (OMN) – das Ganze – Klasse

· Pars(PARS) – ein Teil – Klasse

· Omnium + Pars – gemeinsames Auftreten – Komposition

· Donor (DON) – gibt – Klasse

· Recipiens (RECP) – empfängt – Klasse – 3stellige Assoziation, oder 3 Methoden

· Habitum (HAB) – etwas, was gegeben wird – Klasse

· Creator+(CREA+) – Erzeuger – Klasse

· Creator-(CREA-) – Zerstörer – Klasse

· Opus (OPUS) – das erzeugte zerstörte Werk – Klasse – Rückgabetyp

 

 

Entwurf / Design

· Ausgangspunkt: Anforderungen der Definitionsphase

· Aufgabe: Eine Softwarearchitektur entwickeln, die alle Anforderungen erfüllt

· Entwerfen wird auch Programmieren im Großen genannt

· Beantwortet die Frage „Wie strukturieren wir das?“

· Ausgabe – Softwarearchitektur

DEF Softwarearchitektur:

· Gliederung eines Softwaresystems in Komponenten(Module oder Klassen) und Subsysteme (Pakete, Bibliotheken). Dabei entsteht eine Bestandshierarchie

· Spezifikation der Komponenten und Subsysteme

· Benutzt Relation zwischen Komponenten und Subsystemen

· Optional: Feinentwurf(Angabe der Algorithmen, Datenstrukturen, Pseudocode)

· Optional: Zuweisung von SW-Komponenten zu HW-Einheiten

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

Prozess

· Wird durch Betriebssystem erzeugt

· Enthält Informationen über Programmressourcen und Ausführungszustand, z.B.

o Code-Segment (Programminstruktionen)

o Daten-Segment (für globale Variablen, Keller, Halde)

o Mind. 1 Kontrollfaden

· CPU-Kontrollwechsel zwischen Prozessen langsam

Kontrollfaden (Thread):

· Instruktionsfolge, die ausgeführt wird

· Existiert in einem Prozess

· Ein Faden hat eigenen

o Befehlszeiger

o Keller (Stack)

o Register

· Teilt sich mit anderen Fäden des gleichen Prozesses

o Adressraum

o Code/Daten-Segmente

o Andere Ressourcen (z.B geöffnete Dateien, Sperren)

· CPU-Kontrollwechsel zw. Fäden des gleichen Prozesses schneller, als zw. unterschiedlichen Prozessen

Prinzipielles Vorgehen bei gemeinsamen Speicher:

· Fäden erhalten parallel auszuführende Aufgaben (Instruktionen)

· Informationsaustausch über gemeinsam genutzte Variablen im Speicher

· Synchronisationskonstrukte koordinieren Ausführung im Falle von Daten oder Kontrollabhängigkeiten

· Prozesse und deren Fäden werden grundsätzlich vom Betriebssystem erzeugt und auf Prozessoren bzw. Kerne verteilt

o Schnittstellen dazu meistens in Programmiersprachen eingebaut

Parallelität für Java > 1.0

Der neue Kontrollfaden hat:

· Eigenen Keller und Programmzähler

· Zugriff auf den gemeinsamen Hauptspeicher (Halde)

· Möglicherweise lokale Kopien von Daten des Hauptspeichers(Cache)

Konstrukte zum Erzeugen von Parallelität

· Implementieren von Runnable

· Subklasse von Thread anlegen

· In beiden Fällen run() überschreiben

start() an Thread Instanz aufrufen um zu starten

Runnable leistet bessere Modularisierung.

Runnable ist serialisirbar, Thread nicht.

Grundlegende Koordinationsmechanismen sind eingebaut:

· Wechselseitiger Ausschluss

o Kritische Abschnitte, die nur von einer Akivität gleichzeitig benutzt werden

· Warten auf Ereignisse und Benachrichtigung

o Aktivitäte können auf Zustandsänderungen warten, die durch andere Aktiviäten verursacht werden

o Aktivitäten informieren andere, wartende Aktivitäten über Signale

· Unterbrechungen

Kritischer Abschnitt ist ein Stück Code, wo der Zugriff von mehreren Fäden gleichzeitig stattfindet.

· Nur eine Aktivität darf den kritischen Abschnitt gleichzeitig bearbeiten

· Vor dem Betreten muss sichergestellt werden, dass keine andere Aktivität den bearbeitet

Atomarität – Java garantiert, dass Zugriffe auf einzelne Variablen atomar erfolgen. (Ausgenommen double und long)

Zugriffe auf mehrere Variablen oder aufeinanderfolgende Lese- und Schreiboperationen werden nicht atomar ausgeführt.

Auch wenn Zugriff atomar ist, ist Synchronisation beim Speichern erforderlich.

Monitore zum Schutz kritischer Abschnitte.

· enter() und exit()

Jedes Objekt kann als Monitor verwendet werden (nicht die primitiven Typen)

XC2 monitorenter

0xC3 monitorexit dürfen nur paarweise in einem Block auftreten, damit man exit() nicht vergisst. Vor dem ausführen des Bytecodes wird das überprüft.

Um wait() und notify() aufrufen zu können, muss die akteulle Aktivität mit synchronized den zugehörigen Monitor bereits betreten haben.

Nach dem wait() passiert folgendes:

· Die akteulle Aktivität wird schlafengelegt, d.h. gibt den Prozessor ab

· Die Aktivität wird in eine Wait-Menge an dem Monitor des Objekts, an dem wait aufgerufen war, eingefügt.

· Der betreffende Monitor wird während des Wartens freigegeben.

· Andere Aktivitäten können jetzt um den Monitor konkurrieren

wait(long timeout, int nanos) wartet die Zeit und dann noch bis zur Freigabe des Monitors

notifyAll() weckt alle schlafende Aktivitäten auf, und die konkurrieren erneut um den Monitor

Geht schlafen gleich nach dem wait().

FALSCH: if(bedingung){wait()}; mit if

Gründe:

· Vorher: Kontrollfaden nicht unnötigerweise schlafen gehen

· Nachher: Nicht sichtbar, warum ein Signal geschickt wurde. Soll aber aus wait() rauskommen, nur dann, wenn die Bedingung falsch ist.

Notify mit notifyAll ersetzen

Problem: Wie beendet man eine Aktivität, die auf Signale wartet, die nicht mehr eintreffen werden? Antwort: interrupt() an Thread schicken.

Interrupt() geht nicht verloren, wird bei nächstem wait() executed

Wenn keine Behandlung für InterruptedException gibt, dann weiterleiten mit throw.

Nicht mit leeren catch-Block die InterruptedException empfangen

Trotz synchronized können noch deadlocks entstehen („gib mir Paapier“ und „gib mir den Stift“)

Math.ceil(n/#threads), nicht Math.floor

Nachdem alle Threads gestartet wurden, soll join aufgeruft warden, um bis Ende des Arbeits zu warten.

Java.util.concurrent stellt weitere Klassen zur parallelen Programmierung zur Verfügung, die ansonsten not thread-safe sind.

java.util.concurrent:

· Mengen (collections)

· Kostrukte zur asynchronen Ausführung, Thread Pools

· Synchronisierer (synchronizer)

Einige benutzen aus Performanzgründen keine Monitore, sondern explizite Sperren und volatile-Modifizierer

· Volatile bewirkt, dass ene Variable immer aktualisiert wird, auch wenn es mehrere Kopien davon in Caches gibt.

· Die Kopien selbst werden nicht aktualisiert

BlockingQueue:

· Datentausch zwischen Fäden gemäß dem Erzeuger-Verbraucher Muster

· Erzeuger blockiert, wenn die Schlange voll

· Verbraucher blockiert, wenn die Schlange leer

Verschieden Implementierungen:

· ArrayBlockingQueue – basiert auf Array mit fester Größe

· DelayQueue – ordnet Elemente nach Wartezeiten an

· LinkedBlockingQueue – basiert auf verk Liste

· PriorityBlockingQueue - ordnet Elemente gemäß einer Vergleichsoperation

· SynchronousQueue – basiert auf Schlange mit Kapazität 0, führt zu einem Rendezvous: ablegender und holender Faden warten aufeinander

 

Semaphore – werden zur Synchronisation zwischen Fäden verwendet

· Wird mit einer Anzahl der Genehmigungen initialisiert

· acquire blockiert, bis eine Genehmigung verfügbar ist und erniedrigt anschließend Anzahl der Genehmigungen um

· release erhöht Anzahl der Genehmigungen um 1

CyclicBarrier

· Synchronisiert Gruppe von n Fäden

· Fäden rufen await()-Methode der Barriere auf, die so lange blockiert, bis n Fäden warten

· Danach wird den Fäden erlaubt, ihre Ausführung fortzusetzen

· Beim Vektor Beispiel statt join ansetzbar

· Zyklische Barriere, weil sie in Schleifen wiederholt benutzt werden kann, ohne das es zu Überholungen kommt

Parallele Algorithmen

· Matrix-Vektor Multiplikation

· Matrix-Matrix Multiplikation

· Numerische Integration

· Bewertung von parallelen Algorithmen

· Dateiindizierung

Matrix-Vektor Fall A*b=y

Zeilenweise Aufteilung der Matrix A hat Vorteile gegenüber den spaltenweisen Aufteilung:

· Keine Schreibkonflikte bzgl. Y

· Cache-Effekt: Eine Cachezeile speichert Elemente mit aufsteigenden Adressen, und holt damit einen Teil einer Zeile auf einmal. Elemente einer Spalte sind dagegen in unterschiedlicher Cachezeilen

· Mit Zeilenweise keine Synchronisation von y erforderlich, mit spaltenweise schon.

Blockweise Aufteilung:

· Wenn Speicherzellen nur von einem Prozessor gleichzeitig gelesen werden können, muss der Zugriff koordiniert werden

Matrix-Matrix

· ijk, kij, ikj Algorithmen

· Systolischer Algorithmus

· Cannon-Algorithmus

Programmierrichtlinien

· Konsistenter Stil erleichtert die Lesbarkeit

· Beschleunigt Einarbeitung bei Personalwechsel und Wiedereinarbeitung

· Zeitersparnis bei Fehlerfindung

· Muss konsistent angewandt werden

Regelkreis

· Vorzugsweise werden nur die Normalfälle behandelt

· Sonderfalle und Ausnahmen werden übersehen

· Es werden nur die Fälle erfasst, die man für repräsentativ hält

· Bespiele

o Um eins daneben Fehler

o Indexzählfehler

o Null-Zeiger-Zugriff

Falsche Hypothesen

Programmierer haben Faustregeln entwickelt über die Funktionsweise des Rechners, die sind jetzt aber falsch:

· Multiplikation dauert wesentlich länger als Addition

· Potenzieren ist aufwendiger als Multiplizieren

· Cache Effekte sind unwichtig

Tücken der Maschinenarithmetik:

· Der Computer hält sich nicht an die Regeln der Algebra und Analysis

· Reelle Zahlen werden nur mit begrenzter Genauigkeit dargestellt

Typische Fehler:

· Irreführende Namen

· Unvollständige Bedingungen

· Unverhoffte Variablen

o Verwechslung globaler mit Hilfsvariablen

o Falsche oder vergessene Initialisierung von Variablen

· Trügerische Redundanz

o Durch achtloses Kopieren werden Strukturen geschaffen, die den menschlichen Denkapparat überfordern

o Vermeide Copy/Paste, alles länger als 2 Zeilen ist besser als eine Methode zu kleiden

o Bei Programmänderungen Kommentar wichtig, nicht vergessen

Ein Fehler soll in ein Fehlerbuch eingetragen werden, wenn:

· Die Fehlersuche lange gedauert hat

· Die durch den Fehler verursachten Kosten hoch waren

· Der Fehler lange unentdeckt geblieben ist

Folgende Daten sollen im Fehlerbuch erfasst werden:

· Laufende Fehlernummer

· Datum(wann entstanden, wann entdeckt)

· Aus welcher Phase(Anforederung, Entwurf, Impl)

· Fehlerkurzbeschreibung(Titel)

· Ursache (Verhaltensmechanismus)

· Rückverfolgung:

o Gab es schon ähnliche Fehler?

o Warum waren die früheren Maßnahmen dagegen nicht effektiv?

· Programmierregel, Gegenmaßnahme

· Ausführliches Fehlerbeschreibung

· Dauer

Fehlertypen

Zeitlogbuch

· Ein Zeitlogbuch wird geführt, um die Zeit für einzelne Tätigkeiten zu erfassen

· Man muss für viele Aufgaben eine Schätzung angeben.

· Zeitlogbuch hilft,

o Schätzungen mit hinreichender Genauigkeit geben zu können

o Bei der Schätzung genauer zu werden

· Manuell von Hand in Excel o.ä- erstellt

 

 

Testen

Testing shows the presence oft he bugs, not their absence. (Dijkstra)

Formale Korrektheitsbeweise nur für kleine Programme möglich.

Zentrale Frage: Wann kann man mit dem Testen aufhören, nach Fehlern zu suchen? (Testvollständigkeitskriterien)

Unterscheide:

· Testende Verfahren – Fehler erkennen

· Verifizierende Verfahren – Korrektheit beweisen

· Analysierende Verfahren – Eigenschaften einer Systemkomponente bestimmen

3 Arten von Fehler.:

· Ein Versagen oder Ausfall (failure) ist die Abweichung des Verhaltens der Software von der Spezifikation

· Ein Defekt (defect, bug) ist ein Mangel in einem Softwareprodukt, der zu einem Versagen führen kann. Man sagt, dass sich ein Defekt in einem Versagen manifestiert.

· Ein Irrtum oder Herstellungsfehler (mistake) ist eine menschliche Aktion, die einen Defekt verursacht. Irrtum verursacht Defekt.

Arten von Testhelfern:

· Ein Stummel (stub) ist ein nur rudimentär implementierter Teil der Software und Dient als Platzhalter für noch nicht umgesetzte Funktionalität

· Eine Attrappe (dummy) simuliert die Implementierung zu Testzwecken

· Eine Nachahmung (mock Object) ist eine Attrappe mit zusätzlicher Funktionalität, wie bspw. Das Einstellen der Reaktion der Nachahmung auf bestimmte Eingaben oder das Überprüfen des Verhaltens des Klienten.

Fehlerklassen:

· Anforderungsfehler (Defekt im Pflichtenheft)

o Inkorrekte Angaben der Benutzerwünsche

o Unvollständige Angaben über funktionale Anforderungen, Leistungsanforderungen etc.

o Inkonsistenz der Spezifikation oder des Entwurfs

o Undurchführbarkeit

· Entwurfsfehler (Defekt in der Spezifikation)

o Unvollständige oder Fehlerhafte Umsetzung der Anforderung

o Inkonsistenz der Spezifikation oder des Entwurfs

o Inkonsistenz zwischen Anforderung, Spezifikation und Entwurf

· Implementierungsfehler (Defekt im Programm)

o Fehlerhafte Umsetzung der Spezifikation in ein Programm

Ein Softwaretest, kurz Test, führt eine einzelne Softwarekomponente oder eine Konfiguration von Softwarekomponenten unter bekannten Bedingungen aus und überprüft ihr Verhalten

Die zu überprüfende SW-Komponente oder Konfiguration wird Testling oder Testobjekt oder Prüfling genannt.

Ein Testfall besteht aus einem Satz von Daten für die Ausführung eines Teils oder des ganzen Testlings

Ein Testtreiber oder Testrahmen versorgt Testlinge mit Testfällen und stößt die Ausführung der Testlinge an.

Testtypen:

· Der Komponententest überprüft die Funktion eines Einzelmoduls durch Beobachtung der Verarbeitung von Testdaten. (aus Objektentwurfsdokument)

· Der Integrationstest überprüft schrittweise das fehlerfreie Zusammenwirken von bereits einzeln getesteten System-Komponenten. (Systementwurfsdokument)

· Der Systemtest ist der abschließende Test des Auftragnehmers in realer Umgebung ohne Kunden. (aus Anforderungsanalysedokument)

· Der Abnahmetest ist der abschl. Test in realer Umgebung unter Beobachtung, Mitwirkung ider Federführung des Kunden beim Kunden. (aus Kundenerwartung)

Klassifikation Testender Verfahren:

· Dynamische Verfahren (Testen)

o Strukturtests (white/glass box testing)

§ Kontrollflussorientierte Tests

§ Datenflussorientierte Tests

o Funktionale Tests (black box testing)

o Leistungstests (black box testing)

· Statische Verfahren (Prüfen)

o Manuelle Prüfmethoden (Inspektion, Review, Durchsichten)

o Prüfprogramme (statische Analyse von Programmen)

Dynamische Verfahren

· Das übersetzte Programm wird mit bestimmten Testfällen versehen und ausgeführt

· Das Programm wird in der realen Umgebung getestet

· Stichprobenverfahren: Korrektheit des Programms wird nicht bewiesen

Statische Verfahren

· Das Programm wird nicht ausgeführt, sondern der Quellcode analysiert

White Box ­– mit Kenntnis von Kontrollfluss und/oder Datenfluss

Black Box – ohne Kenntnis, nur Spezifikationen heraus.

Abgrenzung

· Inspektion (inspection) – Überprüfung anhand von Prüflisten oder Lesetechniken

· Überprüfung (review) – Mehr oder weniger formalisierter Prozess zur Überprüfung von schriftlichen Dokumenten durch einen „externen“ Gutachten.

· Durchsicht (walkthrough) – Der Entwickler führt einen oder mehrere Kollegen durch einen Teil des Codes bzw. Entwurfs, den er geschrieben hat. Die Kollegen stellen Fragen und machen Anmerkungen zu Stil, Defekten, Einhalten von Entwicklungsstandards und anderen Problemen.

DEF Inspektion: ist eine formale Qualitätssicherungstechnik, bei der Anforderungen, Entwurf oder Code eingehend durch eine von Author verschieden Person oder eine Gruppe von Personen begutachtet werden. Zweck ist das Finden von Fehlern, Verstößen gegen Entwicklungsstandards und anderen Problemen.

 

Vor und Nachteile von Inspektionen

· Vorteile

o Anwendbar auf alle Softwaredokumente

o Jederzeit und frühzeitig durchführbar

o Sehr effektiv in der industriellen Praxis

· Nachteile

o Gehen nur aufwendig von Hand

o Verbrauchen Zeit mehrerer Mitarbeiter

o Somit ist teuer

o Statisch (im Gegensatz zum Testen)

Zahlen

· Mesit mehr als 50% aller entdeckten Defekte werden in Inspektionen gefunden (bis 90%). Faustregel: (50-75% bei Entwurfsfehlern)

· Verhältnis der Fehlerbehebungskosten durch Inspektion versus durch Testen identifizierter Fehler oft zwischen 1:10 und 1:30

· Return on Investment wird öfter mit 500%+ angegeben.

Warum sind Inspektionen effektiv

· Viele sehen mehr als einer

· Inspektoren haben Abstand zum Software-Dokument

· Inspektoren bringen Erfahrung ein

· Gemeinsame Diskussion über die Identifizierten Problempunkte

o Ist es ein Defekt?

o Ist es eine Schwäche?

o Ist es nur unvorteilhaft?

Phasen einer Inspektion

1. Vorbereitung

a. Teilnehmer und Rollen festlegen

b. Dokumente und Formulare vorbereiten

c. Lesetechniken festlegen

d. Zeitlichen Ablauf planen (optional Initialtreffen)

2. Individuelle Fehlersuche

a. Jeder prüft für sich das Dokument

i. Jeweils etwa 1(+-0.8) Seite pro Stunde pro Inspektor

ii. Teile von 1-4 Seiten netto

b. Benutzt vereinbarte Lesetechnik

c. Schreibt alle Problempunkte und die genaue Stelle im Dokument auf

d. Problempunkte: Defekte, Verbesserungsvorschläge, Fragen

3. Gruppensitzung

a. Individuell gefundene Problempunkte sammeln

b. Jeden einzelnen Problempunkt besprechen

c. Fragen zum Dokument klären

d. Weitere Problempunkte sammeln, die während der Diskussion gefunden werden

e. Verbesserungsvorschläge zur Durchführung von Inspektionen sammeln

4. Nachbereitung

a. Liste mit allen Problempunkten an den Editor des Dokuments übergeben

b. Editor identifiziert tatsächliche Defekte und klassifiziert sie

c. Editor leitet Änderung des Dokuments ein

d. Alle Problempunkte werden bearbeitet

e. Deren Bearbeitung wird überprüft

f. Schätze Restdefekte

i. # nicht entdeckte Defekte etwa= # entdeckte Defekte

ii. 1/6 der Korrekturen ist fehlerhaft/verursacht neuen Defekt

g. Dokument wird freigegeben, wenn #geschätzte Def. < N

5. Prozessverbesserung

a. Prüflisten und perspektiven anpassen

b. Standards für Dokumente erarbeiten

c. Defekt-Klassifikationsschema anpassen

d. Formulare verbessern

e. Planung und Durchführung verbessern

Rollen

· Inspektionsleiter – leitet alle Phasen

· Moderator – leitet die Gruppensitzung (meist Inspektionsleiter)

· Inspektoren – prüfen das Dokument

· Schriftführer – protokolliert Defekte in der Gruppensitzung

· Editor – klassifiziert und behebt Defekte (meist der Autor)

· Autor – hat das Dokument verfasst

Formular für Problempunkte

· Stelle: Seite und Zeile

· Beschreibung

· Wichtigkeit: hoch gering

· Problemtyp: Defekt, Anregung, Frage

· Defekttyp

· Behoben: ja, nein

· Nachgeprüft: ja, nein

Defektklassifikation

· Schwerwiegend odre leicht (major/minor)

· Defekt(defect), Anregung (suggestion), Frage

· Defekttyp z.B nach NASA SEL

Lesetechniken

· Prüflisten

o Liste mit Fragen zum Dokument

o Fragen sollen das Aufspüren von Defekten erleichtern

o Jede Frage bezieht sich auf ein einzelnes Qualitätsmerkmal