Integritätsbedingung: Unterschied zwischen den Versionen
Kowa (Diskussion | Beiträge) (Die Seite wurde neu angelegt: „{{In Bearbeitung}} =Definition= Integritätsbedingungen ('''Zusicherungen''', '''Assertions'''') sind Bedingungen, die ein Objekt oder eine Entität z…“) |
Kowa (Diskussion | Beiträge) Keine Bearbeitungszusammenfassung |
||
(19 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) | |||
Zeile 1: | Zeile 1: | ||
{{ | {{Qualität | ||
=Definition= | |correctness = 5 | ||
[[Integritätsbedingung]]en ('''Zusicherungen''', '''Assertions | |extent = 5 | ||
Zeitpunkten oder dauerhaft erfüllen | |numberOfReferences = 1 | ||
|qualityOfReferences = 2 | |||
|conformance = 5 | |||
}} | |||
==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. | |||
Man unterscheidet verschiedene Arten von Integritätsbedingungen: | Man unterscheidet verschiedene Arten von Integritätsbedingungen: | ||
* Invarianten: Diese Bedingungen müssen | * '''Invarianten''': Diese Bedingungen müssen dauerhaft erfüllt sein. | ||
* Vorbedingungen: Diese Bedingungen müssen erfüllt sein, bevor eine | * '''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 | * '''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 | Integritätsbedingungen können vom System selbstständig überwacht oder mit Hilfe vom | ||
Programmierer zu bestimmten Zeitpunkten überprüft werden. | 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. <code>assert</code>) | |||
oder sogar ganze Testumgebungen wie z.B. [[Modultest]]s (Unit-Tests). | oder sogar ganze Testumgebungen wie z.B. [[Modultest]]s (Unit-Tests). | ||
=Beispiele= | 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 <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 31: | 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=== | ||
[[Datentyp]]en und [[Signatur]]en von [[Methode]]n, [[Prozedure]]n, [[Funktion]]en sind spezielle Integritätsbedingungen. | |||
Zum Beispiel sagt die Variablendefinition <code>var x: int</code> aus, dass die Variable <code>x</code> zu jedem Zeitpunkt nur Werte | |||
vom Typ <code>int</code> enthalten darf. Genauso besagt die Funktionsdefinition <code>function sqrt(x: double): double</code>, | |||
dass die Funktion nur mit Double-Werten aufgerufen werden darf (Vorbedingung) und dass sie nur Double-Werte als Ergebnis liefert (Nachbedingung). | |||
Siehe auch: [[Klasse (OOP)#Klassenschema|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-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. | |||
==Quellen== | |||
#{{Quelle|Kowarschick, W.: Multimedia-Programmierung}} | |||
<noinclude>[[Kategorie:Objektorientierte Programmierung]] | <noinclude>[[Kategorie:Objektorientierte Programmierung]] | ||
[[Kategorie:Glossar]][[Kategorie: | [[Kategorie:Glossar]][[Kategorie:Datenmanagement]] | ||
[[en:Integrity constraint]] | [[en:Integrity constraint]] | ||
[[Kategorie:Kapitel:Multimedia-Programmierung]] | [[Kategorie:Kapitel:Multimedia-Programmierung]] | ||
</noinclude> |
Aktuelle Version vom 3. August 2019, 14:44 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)