Qualit¨atssicherung in der Softwareentwicklung VU 3 DI Dr. Bernhard K. Aichernig

(1)

DI Dr. Bernhard K. Aichernig

Institut f¨ur Softwaretechnologie (IST) TU Graz

Sommersemester 2012

DI Dr. Bernhard K. Aichernig Qualit¨atssicherung in der Softwareentwicklung

(2)

Ubersicht der Vorlesung ¨

1

Invarianten in JML

2

Refinement

3

Spezifikation von Methoden

4

Spezifikationsstile in JML

5

Modellbasierte Spezifikationen

Beispiel: Alarmsystem

(3)

JML Beispiele

Invariant

package org.jmlspecs.samples.jmlrefman

Purse [Burdy et al. 2005]

(4)

Invarianten in JML

Definition (Klasseninvariante, JML)

Invarianten sind Eigenschaften die in allen sichtbaren Zust¨ anden gelten m¨ ussen.

Invarianten werden vererbt.

(5)

Sichtbare Zust¨ ande

Definition (Sichtbarer Zustand eines JML Objektes)

Ein Zustand ist sichtbar f¨ ur ein Objekt o , in einem der folgenden Augenblicke:

am Ende eines Konstruktoraufrufs der o initialisiert,

am Beginn eines Destruktoraufrufs (Finalizer) der o beendet.

am Beginn und am Ende einer nicht-statischen Methode mit o als Empf¨ anger.

am Beginn und am Ende einer statischen Methode in der Klasse oder einer Superklasse von o

wenn keine der oben genannten Kon-, Destruktoren und Methoden mit o als Empf¨ anger in Bearbeitung sind.

Beginn und Ende von Hilfsmethoden (helper-Deklaration) sind keine sichtbaren Zust¨ ande.

(6)

Definition (Sichtbarer Zustand, JML Typen) Ein Zustand ist sichtbar f¨ ur einen Typen T ,

nachdem die statische Initialisierung abgeschlossen wurde und

der Zustand in einem Object vom Typ T sichtbar ist.

(7)

Statische vs. Instanzinvarianten

Definition (Statische Invariante, JML)

Eine statische Invariante bezieht sich nur auf statische Felder eines Objects.

Definition (Instanzinvariante, JML)

Eine Instanzinvariante kann sich auf Beides, statische und nicht-statische Felder, beziehen.

Invarianten in Interfacedeklarationen sind per default statisch.

Statische Invarianten halten in allen sichtbaren Zust¨ anden von Typen.

Invarianten in Klassendeklarationen sind per default Instanzinvarianten.

Instanzinvarianten halten in allen sichtbaren Zust¨ anden von Objekten.

(8)

Refinement

Wird in OpenJML nicht mehr unterst¨ utzt!

Refinements bezeichnen Verfeinerungen von Deklarationen bzw. Spezifikationen

refine x.java: Die Deklarationen in x.java werden verfeinert.

um Java-Deklarationen zu verfeinern:

um Spezifikationen hinzuzuf¨ ugen ohne den Source Code zu

¨ andern.

um Spezifikationen zuerst zu schreiben und vom Source Code zu trennen.

um Spezifikationen zu verfeinern:

st¨ arkere Bedingungen in der Nachbedingung (Postcondition) erweiterter Definitionsbereich durch abschw¨ achen der Vorbedingung (z.B. zus¨ atzliche Exceptions)

Bsp. Person

(9)

Spezifikation von Methoden

Spezifikation von Annahmen (requires) Schr¨ ankt die Dom¨ ane der Spezifikation ein.

Welche Felder werden ver¨ andert? (assignable) Schr¨ ankt die Dom¨ ane einer Spezifikation weiter ein.

Spezifikation von normalen Verhalten (ensures) Bedingung nach erfolgreicher Terminierung.

Spezifikation von anormalen Verhalten (signals) Bedingungen nach den Exceptions einer Methode.

am Beispiel Purse.

(10)

Parameter in Nachbedingungen

Parameter einer Methode werden in Java by-value ¨ ubergeben.

Es folgt daher:

Parameter k¨ onnen nie in einer assignable-Deklaration stehen.

Parameter haben immer den Wert im Vorzustand (pre-state) in Nachbedingungen (ensures und signals). Implizites

\old(p) um Parameter p.

(11)

Spezifikationsstile in JML

siehe Kapitel 9 im JML Reference Manual Heavyweight: wenn Stichw¨ orter behavior, normal behavior, or exceptional behavior Lightweight: keines dieser Stichw¨ orter

Lightweight kann als syntaktische Abk¨ urzung von Heavyweight verstanden werden.

(12)

Modellbasierte Spezifikationen

Motivation:

Beobachtung: Vor- und Nachbedingungen sind sehr eng an die innere Datenrepr¨ asentation einer Klasse gekoppelt.

Vorteile:

Genaue Beschreibung des Verhaltens der Implementierung.

Genaue Dokumentation der Repr¨ asentationsinvarianten.

Nachteile:

Bei ¨ Anderung der Felder einer Klasse muß auch die Spezifikation ge¨ andert werden.

Die Felder m¨ ussen vor der Spezifikation feststehen.

Kann nicht zur Spezifikation von Interfaces und Abstrakten Klassen verwendet werden!

Fazit

Wir brauchen Abstraktion von Datenrepr¨ asentationen — Modelle

(13)

Modelle in JML

model Modifier um Felder, Methoden und Typen zu definieren zum Zwecke der Spezifikation.

model-Felder, Methoden, Typen k¨ onnen nur in Spezifikationen, nicht in Java, verwendet werden.

Modellfelder sind Abstraktionen von einen oder mehreren konkreten Java Feldern.

Modelle k¨ onnen importiert werden: Modellbibliotheken (Mengen, Listen, etc.).

(14)

Pure Methoden

Eine pure Methode (pure) hat keine Seiteneffekte.

Implizites assignable \nothing

Ein purer Konstruktor kann nur nicht-statische Variablen initialisieren.

Implizites assignable this.*

Ein purer Konstruktor bzw. eine pure Methode m¨ ussen immer terminieren.

Implizites diverges false

Implizites requires true

Modellklassen sollen pure sein.

(15)

Anforderungen f¨ ur ein Alarmsystem

Eine chemische Fabrik ist mit einer Anzahl von

Uberwachungseinrichtungen ausger¨ ¨ ustet, welche abh¨ angig vom Zustand der Fabrik Alarme ausl¨ osen k¨ onnen. Wird ein Alarm ausgel¨ ost, muß ein Experte angefordert werden. Experten haben verschiedene Qualifikationen um mit verschiedenen Alarmen umgehen zu k¨ onnen.

(16)

Anforderungen f¨ ur ein Alarmsystem (cont.)

R1 Es ist ein computerbasiertes System zu entwickeln, welches die Alarme in dieser Fabrik managed.

R2 Vier Arten von Qualifikationen werden gebraucht um mit den Alarmen umzugehen. Diese sind elektrische, mechanische, biologische und chemische

Qualifikationen.

R3 Es m¨ ussen w¨ ahrend allen festgelegten Zeitperioden Experten abrufbereit sein.

R4 Jeder Experte hat eine Liste von Qualifikationen.

(17)

Anforderungen f¨ ur ein Alarmsystem (cont.)

R5 Jeder Alarm, der an das System gemeldet wird hat eine zugeordnete Qualifikation und eine Beschreibung des Alarms, die ein Experte verstehen kann.

R6 Wann immer ein Alarm vom System empfangen wird, soll ein Experte mit der richtigen Qualifikation gefunden werden, so daß er angepaged werden kann.

R7 Die Experten sollen die Systemdatenbank abfragen k¨ onnen, um zu ¨ uberpr¨ ufen wann sie abrufbereit sein werden/m¨ ussen.

R8 Es muß m¨ oglich sein die Anzahl der abrufbaren Experten abzufragen.

(18)

M¨ ogliche Klassen und Methoden

Klassen (Typen) Methoden AlarmSystem expertToPage

Qualification expertIsOnDuty Alarm numberOfExperts Period

Expert

(Description)

(19)

Deklaration der Methoden

R6:

public int numberOfExperts(Period p);

R7:

public Period[] expertIsOnDuty(Expert e);

R8:

public Expert expertToPage(Alarm a, Period p);

(20)

Modell des Systems

R1 impliziert eine Art Zeitplan:

/*@ public model instance JMLObjectToObjectRelation schedule;

@ public invariant

@ (\forall JMLType dv, rv; schedule.has(dv,rv);

@ dv instanceof Period &&

@ rv instanceof Expert);

@*/

(21)

Modell des Systems (cont.)

Alle m¨ oglichen Alarme werden modelliert:

/*@ public model instance JMLValueSet alarms;

@ public invariant

@ (\forall JMLType e; alarms.has(e);

@ e instanceof Alarm);

@*/

(22)

Sicherheitsinvariante des Systems

Es m¨ ussen zu jedem Zeitpunkt die erforderlichen Experten anwesend sein!

/*@ public invariant

@ (\forall Alarm a; alarms.has(a);

@ (\forall JMLType per; schedule.isDefinedAt(per);

@ qualificationOk(schedule.elementImage(per),

@ a.needed)));

@*/

(23)

Hilfsfunktion

Eine Hilfsfunktion macht die Invariante leserlicher:

/*@

public model pure boolean

qualificationOk(JMLObjectSet exs, Qualification q) {

return

(\exists Expert ex; exs.has(ex);

(\exists int i; 0 <= i && i < ex.quali.length;

ex.quali[i].equals(q)));

}

@*/

Leider nicht JML-konform! :(

(24)

Hilfsfunktion (cont.)

So geht es :)

/*@ ensures (\exists Expert ex; exs.has(ex);

@ (\exists int i; 0 <= i && i < ex.quali.length;

@ ex.quali[i] == q));

public model pure boolean

qualificationOk(JMLObjectSet exs, Qualification q) {

return true;

}

@*/

(25)

Methode 1

Explizite Beschreibung des Resultats mittels Operatoren des Modells:

/*@ requires schedule.isDefinedAt(p);

@ ensures \result == schedule.elementImage(p).int_size();

@*/

public int numberOfExperts(Period p);

Der Aufruf macht nur Sinn wenn der Zeitraum im Zeitplan definiert ist.

(26)

Methode 2

Explizite Beschreibung des Resultats mittels einer SetComprehension:

/*@

@ ensures \result ==

@ (new JMLObjectSet

@ {Period p | schedule.domain().has(p) &&

@ schedule.has(p,e)}).toArray();

@*/

public Period[] expertIsOnDuty(Expert e);

R7: Die Methode gibt die Menge aller Zeitr¨ aume zur¨ uck, in denen

der Experte Bereitschaft hat.

(27)

Methode 3

Implizite Beschreibung des Resultats:

/*@ requires schedule.isDefinedAt(p) && alarms.has(a);

@ ensures

@ schedule.has(p,\result) &&

@ (\exists int i; i >= 0 && i < \result.quali.length;

@ \result.quali[i].equals(a.needed));

@*/

public Expert expertToPage(Alarm a, Period p);

R6 sagt nichts ¨ uber die Methode um zu bestimmen welcher Experte gefunden werden soll, solange er nur die richtige Qualifikation hat.