Integritätsbedingung: Unterschied zwischen den Versionen
Kowa (Diskussion | Beiträge) Keine Bearbeitungszusammenfassung |
Kowa (Diskussion | Beiträge) Keine Bearbeitungszusammenfassung |
||
(7 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) | |||
Zeile 2: | Zeile 2: | ||
|correctness = 5 | |correctness = 5 | ||
|extent = 5 | |extent = 5 | ||
|numberOfReferences = | |numberOfReferences = 1 | ||
|qualityOfReferences = | |qualityOfReferences = 2 | ||
|conformance = 5 | |conformance = 5 | ||
}} | }} | ||
=Definition= | ==Definition== | ||
[[Integritätsbedingung]]en ('''Zusicherungen''', '''Assertions''') sind Bedingungen, die die Inhalte von [[Variable]]n, [[Objekt]]e oder [[Entität]]en zu bestimmten Zeitpunkten oder dauerhaft erfüllen müssen. Derartigen Bedingungen können durch [[Term|boolesche Terme]] formal dargestellt werden. | [[Integritätsbedingung]]en ('''Zusicherungen''', '''Assertions''') sind Bedingungen, die die Inhalte von [[Variable]]n, [[Objekt]]e oder [[Entität]]en zu bestimmten Zeitpunkten oder dauerhaft erfüllen müssen. Derartigen Bedingungen können durch [[Term|boolesche Terme]] formal dargestellt werden. | ||
Zeile 14: | Zeile 14: | ||
* '''Nachbedingungen''': Diese Bedingungen müssen erfüllt sein, nachdem eine bestimmte [[Methode]]/[[Funktion]] aufgerufen wurde. | * '''Nachbedingungen''': Diese Bedingungen müssen erfüllt sein, nachdem eine bestimmte [[Methode]]/[[Funktion]] aufgerufen wurde. | ||
=Bemerkung= | ==Bemerkung== | ||
Integritätsbedingungen können vom System selbstständig überwacht oder mit Hilfe vom | Integritätsbedingungen können vom System selbstständig überwacht oder mit Hilfe vom | ||
Zeile 25: | Zeile 25: | ||
unkritischer, als Fehler, die erst zur Laufzeit auftreten. | unkritischer, als Fehler, die erst zur Laufzeit auftreten. | ||
=Beispiele= | ==Beispiele== | ||
Für ein Dreiecksobjekt mit den drei Seiten <code>a</code>, <code>b</code> und <code>c</code> gelten folgende Invarianten: | Für ein Dreiecksobjekt mit den drei Seiten <code>a</code>, <code>b</code> und <code>c</code> gelten folgende Invarianten: | ||
Zeile 41: | Zeile 41: | ||
* <code>newvalue(a)=f*oldvalue(a)</code>, <code>newvalue(b)=f*oldvalue(b)</code>, <code>newvalue(c)=f*oldvalue(c)</code> | * <code>newvalue(a)=f*oldvalue(a)</code>, <code>newvalue(b)=f*oldvalue(b)</code>, <code>newvalue(c)=f*oldvalue(c)</code> | ||
==Datentypen und Signaturen== | ===Datentypen und Signaturen=== | ||
[[Datentyp]]en und [[Signatur]]en von [[Methode]]n, [[Prozedure]]n, [[Funktion]]en sind spezielle Integritätsbedingungen. | [[Datentyp]]en und [[Signatur]]en von [[Methode]]n, [[Prozedure]]n, [[Funktion]]en sind spezielle Integritätsbedingungen. | ||
Zeile 49: | Zeile 49: | ||
Siehe auch: [[Klasse (OOP)#Klassenschema|Klasse: Klassenschema]]. | Siehe auch: [[Klasse (OOP)#Klassenschema|Klasse: Klassenschema]]. | ||
==SQL== | ===SQL=== | ||
Gerade in SQL gibt es viele Integritätsbedingungen, die zur Laufzeit automatisch vom System überprüft werden: | Gerade in SQL gibt es viele Integritätsbedingungen, die zur Laufzeit automatisch vom System überprüft werden: | ||
Man kann Not-Null-Bedingungn, [[Primärschlüssel]], [[Unique-Constraint]]s, [[Fremdschlüssel]] und [[Check-Constraint]]s formulieren. Das zugehörige | Man kann Not-Null-Bedingungn, [[Primärschlüssel]], [[Unique-Constraint]]s, [[Fremdschlüssel]] und [[Check-Constraint]]s formulieren. Das zugehörige | ||
System garantiert, dass diese Bedingungen dauerhaft erfüllt sind (Invarianten), indem es dafür sorgt, dass eine Transaktion nicht erfolgreich abgeschlossen wird, wenn irgendwelche derartige Integritätsverletzungen vorliegen. Weitere Integritätsbedingungen (insbesonder Vor- und Nachbedinungen) können mit Hilfe von Triggern formalisiert und überprüft werden. | System garantiert, dass diese Bedingungen dauerhaft erfüllt sind (Invarianten), indem es dafür sorgt, dass eine Transaktion nicht erfolgreich abgeschlossen wird, wenn irgendwelche derartige Integritätsverletzungen vorliegen. Weitere Integritätsbedingungen (insbesonder Vor- und Nachbedinungen) können mit Hilfe von Triggern formalisiert und überprüft werden. | ||
=Quellen= | ==Quellen== | ||
#{{Quelle|Kowarschick, W.: Multimedia-Programmierung}} | |||
<noinclude>[[Kategorie:Objektorientierte Programmierung]] | <noinclude>[[Kategorie:Objektorientierte Programmierung]] | ||
Zeile 63: | Zeile 62: | ||
[[en:Integrity constraint]] | [[en:Integrity constraint]] | ||
[[Kategorie:Kapitel:Multimedia-Programmierung]] | [[Kategorie:Kapitel:Multimedia-Programmierung]] | ||
</noinclude> |
Version vom 27. April 2016, 12:16 Uhr
Dieser Artikel erfüllt die GlossarWiki-Qualitätsanforderungen nur teilweise:
Korrektheit: 5 (vollständig überprüft) |
Umfang: 5 (wesentliche Fakten vorhanden) |
Quellenangaben: 1 (fehlen großteils) |
Quellenarten: 2 (befriedigend) |
Konformität: 5 (ausgezeichnet) |
Definition
Integritätsbedingungen (Zusicherungen, Assertions) sind Bedingungen, die die Inhalte von Variablen, Objekte oder Entitäten zu bestimmten Zeitpunkten oder dauerhaft erfüllen müssen. Derartigen Bedingungen können durch boolesche Terme formal dargestellt werden.
Man unterscheidet verschiedene Arten von Integritätsbedingungen:
- Invarianten: Diese Bedingungen müssen dauerhaft erfüllt sein.
- Vorbedingungen: Diese Bedingungen müssen erfüllt sein, bevor eine bestimmte Methode/Funktion aufgerufen werden kann.
- Nachbedingungen: Diese Bedingungen müssen erfüllt sein, nachdem eine bestimmte Methode/Funktion aufgerufen wurde.
Bemerkung
Integritätsbedingungen können vom System selbstständig überwacht oder mit Hilfe vom
Programmierer eingebauten Tests zu bestimmten Zeitpunkten überprüft werden. Beispielsweise werden Typüberprüfungen in typisierten Sprachen schon vom Compiler vorgenommen. Für die „händische“ Überprüfung von Integritätsbedingungen
gibt es häufig spezielle Befehle (wie z.B. assert
)
oder sogar ganze Testumgebungen wie z.B. Modultests (Unit-Tests).
Die Überprüfungen können zum Zeitpunkt der Übersetzung stattfinden oder erst zur Laufzeit. Im Allgemeinen sind Fehler (d.h. Verletzungen von Integritätsbedingungen), die zum Übersetzungszeitpunkt erkannt werden, wesentlich unkritischer, als Fehler, die erst zur Laufzeit auftreten.
Beispiele
Für ein Dreiecksobjekt mit den drei Seiten a
, b
und c
gelten folgende Invarianten:
a>0
,b>0
,c>0
a+b>c
,b+c>a
,a+c>b
Für die Methode pop
eines Kellerobjekts (Stack) k
gilt die Vorbedingung !k.empty()
,
d.h., das oberste Kellerelement kann nur entfernt werden, wenn der Keller nicht leer ist.
Nachbedingungen haben häufig einen zeitlichen Bezug, d.h. ein Wert, der sich geändert hat, muss in einer bestimmten Beziehung
zu dem ursprünglichen Wert stehen. Zu Beispiel gelten für die Methode scale(f: double): void
, die auf ein Dreieck mit
den drei Seiten a
, b
und c
angewendet werden, folgende Nachbedingungen:
newvalue(a)=f*oldvalue(a)
,newvalue(b)=f*oldvalue(b)
,newvalue(c)=f*oldvalue(c)
Datentypen und Signaturen
Datentypen und Signaturen von Methoden, Prozeduren, Funktionen sind spezielle Integritätsbedingungen.
Zum Beispiel sagt die Variablendefinition var x: int
aus, dass die Variable x
zu jedem Zeitpunkt nur Werte
vom Typ int
enthalten darf. Genauso besagt die Funktionsdefinition function sqrt(x: double): double
,
dass die Funktion nur mit Double-Werten aufgerufen werden darf (Vorbedingung) und dass sie nur Double-Werte als Ergebnis liefert (Nachbedingung).
Siehe auch: Klasse: Klassenschema.
SQL
Gerade in SQL gibt es viele Integritätsbedingungen, die zur Laufzeit automatisch vom System überprüft werden: Man kann Not-Null-Bedingungn, Primärschlüssel, Unique-Constraints, Fremdschlüssel und Check-Constraints formulieren. Das zugehörige System garantiert, dass diese Bedingungen dauerhaft erfüllt sind (Invarianten), indem es dafür sorgt, dass eine Transaktion nicht erfolgreich abgeschlossen wird, wenn irgendwelche derartige Integritätsverletzungen vorliegen. Weitere Integritätsbedingungen (insbesonder Vor- und Nachbedinungen) können mit Hilfe von Triggern formalisiert und überprüft werden.
Quellen
- Kowarschick (MMProg): Wolfgang Kowarschick; Vorlesung „Multimedia-Programmierung“; Hochschule: Hochschule Augsburg; Adresse: Augsburg; Web-Link; 2018; Quellengüte: 3 (Vorlesung)