Hol' Dir diese Lernkarten, lerne & bestehe Prüfungen. Kostenlos! Auch auf iPhone/Android!

Die Softwaretechnik befasst sich mit Entwicklung und Anwendung von Prinzipien, Methoden und Werkzeugen zur Erstellung, zum Betrieb und zur Wartung von großen Softwaresystemen.

Eselsbrücke: (A - V - N - Ü / Z - A - L - A)
1. Analogieprinzip: Konventionen, ähnliches ähnlich behandeln.
2. Vollständigkeitsprinzip: Robustheit, alles erfassen!
3. Nachweisbarkeitprinzip: Beweis das Ziel erreicht ist.
4. Überaschungsminimierung: Produkt möglicht nach am Ideal
5. Zerlegungsprinzip: Strukturierung, Flexibilität
6. Abkapselungsprinzip: Wartbarkeit, Flexibilität
7. Abstraktionsprinzip: Redundanzarmut, Wartbarkeit.
8. Lokalitätsprinzip: was zusammengehört ist zusammenzufasse.

9. Prinzip der Trennung der Belange:  in Zusammenhang mit Punkt 8 dinge die nicht zusammengehören sind zu trennen.

1. Problemstellung
    * Analysieren
2. Studie(Problemanalyse)
    * Durchführbarkeitsstudie: [Sommerville]:
    * Definieren
3. Anforderungsdefinitionsphase
    * Entwerfen und Spezifizieren
4. Architektur und Bausteinspezifikation
    * Implementieren und Integrieren
5. (fertiges) System + Dokumentation
    * Installieren
6. System in Zielumgebung
    * Betreiben und Warten

Die Anforderungsdefinitionsphase (Pflichtenheft). Hier werden nach meiner Ansicht die Grundlagen geschaffen, daher sollte man hier solange verharren, bis keine Fragen mehr offen sind.

Der Aufwand zwischen Entwicklung und Wartung/Pflege verteilt sich im Verhältnis zu

Nein
    es handelt sich um ein (logisches)konzeptuelles Modell, das die wesentlichen Aktivitäten erfassen soll.

   1. Stakeholder definieren,
   2. Gespräche führen,
   3. Dokumente analysieren und
   4. Vorgänge erfassen (z.B. mit Anwendungsfalldiagrammen).
          * In der Anforderungsdefinitionsphase werden
                o Strukturierungstechniken (z.B.Mindmaps),
                o Kreativitätstechniken (z.B. Brainstorming,            Metaplantechnik, CNB, 6-3-5 Methode) und
                o weitere Techniken, wie Interviews etc. verwendet.

Zusätzlich notiert man noch eine Gewichtung (muss, soll, kann) und eine entsprechende Anforderungsnummer (zwecks traceability)

Die Dokumente sind

    * Glossar(Terminologie des Anwendungsbereiches),
    * Protokolle und
    * Anforderungslisten (Erklärung siehe Frage 1)

Ein Glossar
    ist ein lexikonartige Beschreibung der wesentlichen Begriffe des Anwendungsbereichs (z.B. Entitäten, Beziehungen...). Es stellt im Allgemeinen die Grundlage für erste Entwurfsdokumente (Klassendiagramm, Anwendungsfalldiagramm, Datenflussdiagramn) dar.

   1.  Mit Use-Case-Diagrammen kann eine grobe Erfassung der vorhandenen Abläufe (Vorgänge) durchgeführt werden.
   2. Jeder Anwendungsfall kapselt dabei genau eine Leistung des Systems ab.
          * Alle Anwendungsfälle zusammen decken die gesamte Funktionalität des Systems ab.

    * Entwerfen (d.h. das Konkretisieren eines Bausteins durch weitere Bausteine und deren Beziehungen) ist erfahrungsbasiert.
    * Es existiert keine generelle Entwurfsmethode.
          o Je nach Sicht geht man mit Strukturierter Analyse oder Objektorientiertem Entwurf vor.
          o Man kann verschiedene Architekturstile verwenden, bestehend aus der Angabe einer Architektursicht (Paradigma) und einer Architekturstruktur.

    *  SA erlaubt iterative Topdown-Entwicklung entlang der Funktionalität.
         1. Anforderungen erstellen
         2. Funktionalität in Datenflussdiagramme zergliedern
         3. Prozesse iterativ verfeinern (parallel ER-Diagramme entwickeln)
         4. Nicht verfeinerte Prozesse mit Minispecs spezifieren
    * Bei OOA werden Modelle inkrementell weiterentwickelt.
         1. Anforderungen aufstellen
         2. Erstes Klassendiagramm aufstellen
         3. Anwendungsfälle weiterentwickeln und Verantwortlichkeiten der Klassen herleiten.
         4. Klassendiagramme untersuchen und weiterentwickeln. Dabei Entwurfsmuster berücksichtigen und die Klassenbeschreibung (Attribute, Methoden) konkretisieren.

    *  Phasenübergreifende Aktivitäten sind
          o Management (d.h. planen, steuern, überwachen),
          o Qualitätssicherung (d.h. beweisen, testen, inspizieren) und
          o Dokumentation.
    * Phaseninterne Aktivitäten siehe Frage 1.

    *  Requirements Engeneering umfasst das
          o Analysieren
          o d.h. das Verstehen und Erfassen von Problemen und das Abschätzen der Durchführbarkeit und der Erfolgsaussicht eines Projekts,
          o sowie das Definieren
          o d.h. das Feststellen von Anforderungen.

    * Man kann Anforderungen noch weiter strukturieren:
          o Name/Nummer
          o Detaillierungsgrad
          o Text
          o Begründung
          o Abmahnekriterien
          o Historie

Stakeholder sind vom Requirements Engineering betroffene Personen, beispielsweise Auftraggeber, Anwender, Benutzer, Hersteller oder Softwareingenieure.

Typische Rollen sind Projektleiter, Systemanalytiker,Anwendungsspezialist,Qualitätsbeauftragter, Softwareergonom, technischer Redakteur.

    *  In einem Vorgehensmodell wird festgelegt, welche Aktivitäten in welcher Reihenfolge von welchen Personen erledigt werden und welche Ergebnisse (Artefakte) dabei entstehen und wie diese in der Qualitätssicherung überprüft werden. Es können anzuwendende Standards, Methoden und Tools festgelegt werden. [Balzert]
    * Vorgehensmodelle sind nützliche Abstraktionen, die benutzt werden können, um verschiedene Ansätze der Softwareentwicklung zu erläutern. [Sommerville]

    *  Phasenmodelle
          o Wasserfallmodell
          o V-Modell
    * Prototypisierungsmodelle
    * Inkrementelle Modelle
          o Spiralmodell
          o Rational Unified Process (RUP)
    * Agile Methoden
          o Extreme Programming (XP)

Bei XP wird in kleinen Teams (2-10 Personen) und mit ständigem Testen in Paarprogrammierung so entwickelt, dass jederzeit eine lauffähige Konfiguration existiert. XP geht iterativ vor. Die Iterationen werden durch “user stories” vorangetrieben und dauern 3-4Wochen.

Schlagworte sind:
    * Kommunikation (communication) und Einbeziehung von Feedback
    * Einfachheit (simplicity) durch saubere und einfache Softwarestruktur
    * Mut (courage) durch frühe Auslieferung
    * dauerndes Testen und permanente Anpassung

Die Abbildung zeigt die Phasen des V-Modells. Die V-Form ergibt sich, wenn man die Grafik so interpretiert, dass der Detaillierungsgrad von oben nach unten zunimmt (Y-Achse) und die Zeit von links nach rechts vergeht (X-Achse). Der rechte Zweig des V-Modells, der auf derselben Ebene liegt wie der linke Teil, validiert diesen.

Vorgehensmodelle beschreiben auf oberster Ebene,welche Aktivitäten wann ausgeführt werden (den Workflow). Code-and-Fix eignet sich lediglich für einfache, klar überschaubare Probleme. Für größere Problemstellungen sind klarere Vorgehensmodelle erforderlich. Ein Prozessmodell beschreibt den organisatorischen Rahmen der Softwareentwicklung (Aktivitäten, Zuständigkeiten, Artefakte). [Balzert]

#  Wasserfallmodell und V-Modell sind Phasenmodelle. Phasenmodelle sind Vorgehensmodelle.
# Phasenmodelle eignen sich für überschaubare und gut verstandene Aufgaben.
# Es werden Meilensteine (d.h. definierte Enden von Phasen mit einem überprüfbaren Ergebnis) gesetzt und die vollen Anforderungen erfüllt. Beim inkrementellen Modell liefert man eine einfache Systemversion aus, bewertet diese und passt sie inkrementell den Anforderungen an. Dies bietet die Vorteile der Risikominimierung, Kundeneinbeziehung (Feedback) und Lerneffekt.
# Nein! Es ist ein konzeptuelles (logisches) Modell

RUP ist ein generisches Vorgehensmodell, das an konkrete Anwendungsumgebungen anpassbar ist, bzgl. Organisation, Anwendungsbereich, Werkzeuge. Schlagworte: * iterativ und inkrementell  * dokumentenorientiert  * anwendungsfallgetrieben  * architekturzentriert

Der RU Prozess verläuft in Zyklen. Jeder Zyklus produziert eine neue Auslieferung (Release). Der Zyklus besteht aus Phasen:
•  Konzeptualisierung (inception): Grundidee und Umfang des Systems, Use Case Diagramme, Anforderungen auf hoher Ebene, erster Projektplan (häufig auch Prototyp)
•  Ausarbeitung (elaboration): Problemanalyse, architektonische Grundlage, verfeinerter Projektplan, Systemanforderungen
•  Konstruktion (construction): Beschreibung aller Anforderungen und Akzeptanzkriterien, implementierte und geteste Software (Beta)
•  Übergang (transition): Entfernung der letzten Bugs, Fertigstellung letzter Funktionen, Produktionssystem Workflows / Disziplinen

Insgesamt gibt es in der UML 2.0 13 Diagrammarten. In der Vorlesung (WS 05/06) kennengelernt haben wir die folgenden:

    * Strukturdiagramm
          o Klassendiagramm
          o Objektdiagramm
    * Verhaltensdiagramm
          o Anwendungsfalldiagramm
          o Aktivitätsdiagramm
          o Zustandsdiagramm
          o Interaktionsdiagramm
                + Sequenzdiagramm

Mit Metamodellen wird ein Diagramm durch ein weiteres Diagramm beschrieben. Die Syntax visueller Sprachen lässt sich beispielsweise mit Klassendiagrammen beschreiben.

    * Metamodelle können den folgenden Zwecken dienen:
          o konzeptuelle Beschreibung einer Sprache
          o Festlegung einer abstrakten Syntax
          o Erstellung einer Repository-Struktur

Metamodelle können für die Umsetzung von CASE-Tools eingesetzt werden und um Diagramme automatisch zu validieren.

Aktivitätsdiagramme, mit denen man Kontrollfluss und Datenfluss darstellen kann.

Szenarien werden immer natürlichsprachlich beschrieben. Sie können zusätzlich durch Sequenzdiagramme, durch Aktivitätsdiagramme, oder durch Zustandsdiagramme beschrieben werden. Ein Szenario ist ein konkreter Fall (Instanz) eines Anwendungsfalles.

In der UML kann Datenfluss bereits durch Aktivitätsdiagramme dargestellt werden. Zusätzlich Datenflussdiagramme in der UML beizubehalten wäre redundant.

UML-Klassendiagramme sind eine visuelle, formale Sprache, die es erlaubt, statische Beschreibungen von Objekten und deren Beziehungen zu modellieren.
Bestandteile sind Klassen und Beziehungen.
    * Klassen haben
          o Attribute und
          o Operationen.
    * Beziehungen sind
          o Assoziation,
          o Aggregation,
          o Komposition und
          o Generalisierung
Mit Ausnahme der Generalisierung können zu den Beziehungen Assoziationsnamen, Multiplizitäten und Rollennamen angegeben werden. Klassendiagramme haben im Gegensatz zu ER-Diagrammen ein Verhalten (Operationen).

Die Menge von Instanzen einer Klasse, die zu einem Zeitpunkt existieren.

    *  Aggregation
          o ist eine Teil-Ganzes-Beziehung
          o Besser wäre die Aggregation mittels Person - Professor zu erklären
    * Komposition
          o ist eine Teil-Ganzes-Beziehung erweitert um eine physische Inklusion, d.h.
          o wird das Ganze gelöscht, werden auch alle Teile gelöscht.

    * Assoziationen stehen für Beziehungen zwischen Objekten, die in der Schema-Ebene aus Bezeichner und Leserichtung bestehen.
    * Die Generalisierung/Spezialisierung ist eine Beziehung zwischen Klassen. * Klasse B wird von Klasse A abgeleitet:
    * C++: classB : public classA
    * Java: classB extends classA

Die allgemeinere Klasse in einem Klassendiagramm nennt man
    * Superklasse (Oberklasse), die speziellere entsprechend
    * Subklasse (Unterklasse)

Anmerkungen:
    * Mehrfachvererbung gibt es nicht in Java
    * "Diamond Inheritances" sollten vermieden werden, da es insbesondere bei der Implementierung zu Problemen kommt
          o "Wer erbt von wem was und warum nicht anders herum??"

Abstrakte Klassen, die keine Implementation beinhalten (sondern nur Attribut- und Operationsstrukturen festlegen) bezeichnet man als Interface

Entscheidungstabelle ist eine visuelle Repräsentation von Regelwerken (Regel = Aktion(en) unter bestimmten Bedingung(en) ausführen)

    * Eine Entscheidungstabelle besteht aus vier Teilbereichen:
         1. Einer Auflistung der zu berücksichtigenden Bedingungen
         2. Einer Auflistung der möglichen Aktionen
         3. Einem Bereich, in dem die möglichen Bedingungskombinationen zusammengestellt sind
         4. Einem Bereich, in dem jeder Bedingungskombination die jeweils durchzuführeden Aktivitäten zugeordnet sind.
    * Vollständigkeit:
          o Eine Entscheidungstabelle ist vollständig, wenn sämtliche möglichen Bedingungskombinationen erfasst sind.
          o Bei  n Bedingungen sind dies Kombinationen.
          o Das bedeutet aber nicht zwangsläufig, dass es Regeln geben muss ( Redundanz)

   1. Use-Case-Diagramme bestehen aus
          * Anwendungsfällen innerhalb einer Systemgrenze,
          * Akteuren,
          * Assoziationen zwischen Akteuren und Anwendungsfällen
          * Beziehungen der Art
                o UseCase A <<extend>> UseCaseB : A wird in einem Sonderfall von B verwendet
                o UseCase A <<include>> UseCaseB : A verwendet B
   2. Ein Akteur beschreibt eine Einheit, die mit dem System interagiert — dies muss also nicht zwangsläufig ein Mensch sein.

1. Ein Anwendungsfall (use case) ist eine Klasse von Abläufen, die eine
    * Funktionalität realisieren und zu beobachtbaren Ergebnissen führen.

2. Bezeichner:
    * Use-Cases sollte man mit der Gerundium-Form (verkaufen) oder eine Substantiv-Verb-Kombination (Verkauf abwickeln) bezeichnen.
    * Akteuere durch Substantive bezeichnet werden

3. Linie:
    * Die Linie steht für Kommunikation (d.h. den Austausch von Signalen und Daten) zwischen Akteur und Use-Case.

    *  "Ein Stereotyp klassifiziert Elemente eines UML-Modells. [...] Stereotypen werden in französischen Anführungszeichen (guillements) mit Spitzen nach außen angegeben. [...] Ein Stereotyp kann sinnvoll verwendet werden, um die Zugehörigkeit einer Klasse zu einer bestimmten Entwurfskomponente, z.B. zur GUI-Schicht, zu zeigen." [Balzert]
    * "Über Stereotype lässt sich das Vokabular von UML erweitern Sie erlauben es Ihnen, neu Arten von Bausteinen zu erzeugen, die zwar von bestehenden Bausteinen abgeleitet, aber speziell auf Ihre Problemstellung zugeschnitten sind." [Booch et al.]
    * Beispiele für von der UML vordefinierte Stereotypen sind
          o <<include>> <<extend>> <<interface>> <<use>> <<bind>> <<enumeration>>

Ein Mealy-Automat ist ein endlicher Automat (hat ein Endzustand), dessen Ausgabe von seinem Zustand und seiner Eingabe abhängt. Anschaulich bedeutet das, dass jeder Kante im Zustandsdiagramm ein Ausgabewert zugeordnet wird.

Bsp.: Pfeil mit Beschriftung 1/0 von Zustand("state") S0 auf S1 bedeutet : Bei Eingabe von "1" geht man von Zustand S0 in Zustand S1 über und gibt "0" aus Dem Automat gibt man also allgemien ein Wort wie z.b "110011". Beim Anfangszustand (doppelt umrandeter Kreis) wird angefangen. Beendet wird in einem Endzustand oder durch ein Ausgabewort welches anzeigt ob das Ende erreicht ist.

Ein Moore-Automat ist ein endlicher Automat, welcher deterministisch (eindeutug bestimmter Folgenzustand bei Eingabe eines Zeichens aus Eingabealpabet) oder nichtdeterministisch (mehrere Übergänge möglich) sein kann. Im Gegensatz zum Mealy-Automaten hängt seine Ausgabe ausschließlich von seinem Zustand ab (und nicht zusätzlich von der Eingabe). Beim Erreichen eines Zustandes wird eine Ausgabe erzeugt, welche unabhängig vom Übergang in diesen Zustand ist.

Bsp.: Ein Zustand (Kreis) beinhaltet S0/"s" und eine ausgehende Kante an der "z" steht, die auf den Zustand S1/"t" führt. Trifft man in S0 ein wird "s" ausgegeben, per Eingabe von "z" gelangt man in S1 worauf sofort "t" ausgegeben wird.

Der Unterschied zwischen Mealy und Moore besteht darin "wovon" eine Ausgabe abhängt :

    * Mealy : Zustand + Eingabe (S0+"Z" = "A")
    * Moore : Zustand (S0 = "A")

    * State Charts werden zur zustandsorientierten Beschreibung der Dynamik verwendet.
    * Sie werden häufig für reaktive Systeme (wie Telefon, Auto oder Haushaltsgeräte) eingesetzt.

   1. Ein atomarer Zustand besitzt im Gegensatz zu einem Blob keine Unterzustände.
   2. Ein Blob (Klecks) besteht wie ein Klecks (Tropfen) aus mehreren "Atomen" (atomare Zustände)

Der Konfigurationsraum ist das Kreuzprodukt der Räume der Regionen.

    *  Eingehende Transition auf den Rand des zusammengesetzten Zustands:
          o Unter-Automat beginnt am Startzustand oder
          o im zuletzt aktiven Zustand, wenn sich ein History State im Automaten befindet.
    * Ausgehende Transition vom Rand des Zustands:
          o Endzustand des Unter-Automaten wurde erreicht oder
          o Automat wird unterbrochen.

   1.  AND-Blobs ermöglichen parallel aktive Zustände.
   2. Es gibt
          * Voneinander abhängige und
          * voneinander unabhängige Zustände.

XOR-Blobs ermöglichen eine hierarchische Verfeinerung und dienen der Strukturierung.

   1. Orthogonalität in AND-Blobs,
   2. Bedingungen in den Transitionen und
   3. Hierarchie in den Unterzuständen (XOR-Blobs).

Mit Sequenzdiagrammen lassen sich Interaktionen modellieren (d.h. der Austausch von Nachrichten zwischen Objekten).

    * Die UML 2.0 bietet neben Sequenzdiagrammen noch
          o Kommunikationsdiagramme,
          o Timing-Diagramme und
          o Interaktionsübersichtsdiagramme zur Beschreibung von Interaktionen

Use-Case-Diagramme können durch Szenarios verfeinert werden, die beispielsweise in Form von Sequenzdiagrammen dokumentiert werden. In Sequenzdiagrammen finden sich die Akteure aus den entsprechenden Use-Case-Diagrammen wieder

    *  Ist eine Nachricht asynchron (Aufrufer wartet nicht auf Antwort des Aufgerufenen),
          o besitzt die Linie eine Pfeilspitze in Strichdarstellung.
    * Ist die Nachricht synchron (Aufrufer muss auf Antwort des Aufgerufenen warten bevor er weiter machen kann),
          o weist die Nachricht eine ausgefüllte dreieckige Pfeilspitze auf.
          o Die Ergebnisrückgabe auf eine synchrone Nachricht wird durch einen gestrichelten Pfeil mit einer Pfeilspitze in Strichdarstellung dargestellt.

Eine Architektur ist eine Zerlegung in

    * Bausteine und
    * Beziehung.

Eine Architektursicht (Architekturparadigma, Viewpoint) ist charakteristisch durch die Arten der Bausteine und Beziehungen, die zur Beschreibung verwendet werden.
Architektursichten werden durch i. Allg. sehr einfach, grobgranulare Metamodelle charakterisiert

Die Architekturstruktur wird durch die Gestalt des zugrundeliegenden TGraphen definiert.

TGraph gerichteter Graph, dessen Knoten und Kanten attributiert und typisiert sein können.

Eine Architektur wird aus einer Sicht beschrieben, je nachdem welche Bausteins- und Beziehungsarten man unterscheidet (z.B. Klassensicht, Struktursicht, Datenflusssicht). Bausteine werden rekursiv zerlegt. Sie sollten abgekapselt sein, so dass die Umgebung nur über Schnittstellen mit dem Baustein in Beziehung treten kann.

ja dies ist jedem selbst überlasten

Versionsverwaltungssysteme wie SVN oder CVS oder eine integrierte Entwicklungsumgebung (IDE), deren verschiedene Werkzeuge auf einen gemeinsamen Datensatz zugreifen.

   1. Es folgt Betreiben und Warten.
   2. Warten ist das Beheben von Fehlern und das Anpassen, Weiterentwickeln und Verbessern von Produkten nach der Auslieferung.

Spezifizieren ist das Präzisieren von Anforderungen, die an einen Baustein für dessen Realisierung und dessen Benutzung gestellt werden.
    * Man kann
          o natürlichsprachlich oder
          o formal spezifizieren.
                + Die algebraische und die konstruktive Spezifikation sind zwei Schulen der formalen Spezifikation.

    * Auf breiter Front durchgesetzt hat sich (unter anderem durch den Zeitdruck Software schnell zur Marktreife zu bringen) einzig die natürlichsprachliche Spezifikation.
    * Formale Methoden wurden jedoch erfolgreich bei kritischen Systemen, etwa zur Überwachung des Luftverkehrs, bei Signalsystemen für den Schienenverkehr, Raumfahrtsystemen oder medizinischen Kontrollsystemen eingesetzt. [Sommerville]

    *  Eine Klasse lässt sich
          o natürlichsprachlich oder
          o formal mit Object Z spezifizieren.
    * Dem Konstruktor der Klasse entspricht in Object Z dem initialem Zustandsschema,
    * die Methoden der Klasse werden durch die Operationsschemata festgelegt.

Die Spezifikation eines Bausteins muss in einer disziplinierten Sprache geschrieben sein, so dass sie zusammen mit der Signatur als Implementationsvorlage ausreicht.
   * Zur Spezifikation sind
         1. Signatur (Syntax),
         2. Vorbedingung,
         3. Nachbedingung und
         4. mögliche Ausnahmen (Semantik) erfoderlich.
    * In Java wird die natürlichsprachliche Spezifikation mit dem Werkzeug javadoc verwaltet,
    * unter C++ kann man beispielsweise doxygen einsetzen.

            /* \fn real sqrt(real x)
             * \brief A squareroot function
             * \param x a real number.
             * \exception -1 for negative param x
             * \return a real number .
             *
             * Liefert für x größer oder gleich 0 die Quadratwurzel von x.
             * Für x kleiner 0 wird -1 zurückgegeben.
             */
            real sqrt(real x);

Es ist darauf zu achten, dass in der Spezifikation einer Methode alle Bezeichner der Schnittstelle erwähnt werden. Jeder Parameter, das Ergebnis und die Veränderungen am Objekt müssen im Text vorkommen.

konstruktive Spezifikation
    Z bringt viele mathematische Konstrukte bereits mit, die man sich in der algebraischen Spezifikation zuvor noch selbst spezifieren muss. 

"Enthält eine Klasse keine extends-Klausel, so besitzt sie die implizite Vaterklasse Object. Jede Klasse, die keine extends-Klausel besitzt, wird direkt aus Object abgeleitet. Jede explizit abgeleitete Klasse stammt am oberen Ende ihrer Vererbungslinie von einer Klasse ohne explizite Vaterklasse ab und ist damit ebenfalls aus Object abgeleitet. Object ist also die Superklasse aller anderen Klassen." [Krüger]

Nein
    Das Pflichtenheft ist ein natürlichsprachliches Dokument, das die Anforderungen an das Produkt möglichst genau (aber nicht formal) festhält.

Objekte werden in Java immer per call-by-reference übergeben. Daher können bar und baz ebenfalls Ausgaben sein. In Java gibt es demnach keine Möglichkeit zu sehen, welche Attribute verändert und welche nur gelesen werden.

    *  Z ist eine Notation für konstruktive Mengenlehre und Prädikatenlogik.
    * Mit Object-Z lässt sich Software formal spezifizieren.
          o Ein Z-Dokument besteht primär aus erklärendem Text
          o und sekundär aus einem formalen Anteil.

Z hat folgende Sprachelemente:
   1. Grundmengendefinitionen (given set definitions)
   2. Freie Typdefinitionen (free type definitions)
   3. Abkürzungsdefinitionen (abbreviation definitions)
   4. Axiomatische Definitionen (axiomatic definitions)
   5. Schemadefinitionen (schema definitions)

    *  Man verwendet Object-Z zur formalen Spezifikation
          o eine Alternative wär eine natürlichsprachliche Spezifikation

  1. Spezifikation
          * Die Oberflächensignatur der Funktion muss im Deklarationsteil des Schemas stehen und
          * die Semantik der Funktion im Bedingungsteil.
   2. Bedingung für eine Wurzel-Funktion
          * Die Bedingung für die Wurzel von x würde lauten, dass x größer oder gleich Null sein muss.
   3. Spezifiaktion der Wurzelfunktion in Z:

|—sqrt ————————
| x? : R
| z! : R
|——————————————
| x? >= 0
| z! ^ 2 = x
|——————————————

Vor- und Nachbedingung lassen sich aus dem Bedingungsteil des Schemas ablesen.

|—sqrt ————————
| x? : R
| z! : R
|——————————————
| x? >= 0        < Vorbedingung
| z! * z! = x?   < Nachbedingung
|——————————————

    *  Die Oberflächensignatur steht im
          o Deklarationsteil des Operationsschemas.
    * Die Tiefensignatur (Semantik) umfasst zusätzlich den
          o Bedingungsteil des Schemas.

1. Whitebox-Tests sind ein
    * dynamisches Testverfahren über die Programmstruktur;
    * sie dienen der analytischen Qualitätssicherung von Software.
    * Neben dem kontrollflussorientieren Testen können Whiteboxtest auch den Datenfluss testen.

    "Strukturelle Tests sind ein Testansatz, bei dem die Tests aus der Kenntnis der Softwarestruktur und der Implementierung abgeleitet werden. Dieser Ansatz wird manchmal White-Box-Test, Glass-Box-Test oder auch Clear-Box-Test genannt, um den Gegensatz zum Black-Box-Test zu verdeutlichen." [Sommerville]

2. Wie kann man Daten automatisch analysieren
    * Mit Hilfe der symbolischen Ausführung lassen sich Programme automatisch analysieren.

    * c0 ist die Anweisungsüberdeckung,
    * c1 die Kantenüberdeckung und
    * c_unendlich ist die Pfadüberdeckung. [18]

Normalerweise kommen Kantenüberdeckungstests (c1) zum Einsatz, da sich alleine mit Anweisungsüberdeckung viele Fehler nicht finden lassen und die Pfadüberdeckung nur praktikabel ist, wenn man bestimmte Einschränkungen in Kauf nimmt (wie beim Strukturierten Pfadtest oder dem Boundary-Interior-Pfadtest).

Pfadüberdeckungstests sind eine Strategie des strukturellen Testens, deren Ziel in der Erprobung jedes einzelnen unabhängigen Ausführungspfades eines Programms oder einer Komponente besteht. Wenn jeder unabhängige Pfad ausgeführt worden ist, müssen alle Anweisungen mindestens einmal abgearbeitet sein.

    *  Da ein Pfadüberdeckungstest nicht praktikabel ist,
          o ist die Kantenüberdeckung meistens das minimale Testkriterium.
    * Der Kantenüberdeckungstest (C1-Test) fordert die Ausführung aller Kanten im Kontrollflussgraphen.
          o Dadurch wird die Semantik von Auswahlkonstrukten geprüft.
    * Voraussetzung ist eine Instrumentierung des Quellcodes
          o d.h. das Setzen von Zählern an bestimmten Stellen um Code, die für jeden Durchlauf inkrementiert werden.

    *  Der Mutationen-Test zählt zur Gruppe der Diversifizierenden Testmethoden.

"Der Mutationen-Test ist keine Testtechnik im engeren Sinne, sondern ein Test der Leistungsfähigkeit anderer Testmethoden, sowie der verwendeten Testfälle. Die verschiedenen Versionen entstehen durch künstliches Einfügen von typischen Fehlern. Es wird dann geprüft, ob die benutzte Testmethode mit den vorhandenen Testdaten diese künstlichen Fehler findet. Wird ein Fehler nicht gefunden, so werden die Testdaten um entsprechende Testfälle erweitert. Diese Technik beruht auf der Annahme, dass ein erfahrener Programmierer meist nur noch “typische” Fehler macht." [Wikipedia, 17.09.2007]

    *  Im Beispiel ist eine Funkltion swap(a,b)=> a==b; b==a gezeigt
    * In dem Beispiel (rechts) zur symbolischen Ausführung zu nachstehendem Algorithmus werden
         x := x - y;                         (1)
         y := x + y;                        (2)
         x := y - x;                         (3)         
          o lateinische Bezeichner (x, y) für die Programmwelt, während
          o griechische Bezeichner () für die Symbolwelt stehen.

* Es werden Substitutionen von Variablen durch symbolische Ausdrücke verwaltet.         * Es ist zu zeigen, dass ausgehend von der Vorbedingung die Nachbedingung immer erfüllt ist.