Side-effect sensitive invariant checking - Revision history

Manus at 10:19, 11 April 2007

2007-04-11T10:19:11Z

Seilerm: /* Status quo of invariant detection */

2007-03-14T18:07:47Z

‎Status quo of invariant detection

Peter gummer at 00:51, 13 March 2007

2007-03-13T00:51:19Z

Konradm at 02:03, 15 November 2006

2006-11-15T02:03:55Z

Konradm at 16:15, 19 October 2006

2006-10-19T16:15:04Z

Konradm at 16:14, 19 October 2006

2006-10-19T16:14:03Z

Konradm: /* Status quo of invariant detection */

2006-10-19T16:12:39Z

‎Status quo of invariant detection

Konradm at 23:28, 18 October 2006

2006-10-18T23:28:53Z

Konradm: /* Side-effect sensitive invariant checking SSIC */

2006-10-18T23:26:27Z

‎Side-effect sensitive invariant checking SSIC

Konradm at 23:20, 18 October 2006

2006-10-18T23:20:20Z

← Older revision		Revision as of 10:19, 11 April 2007
Line 1:		Line 1:
	Author: Matthias Konrad		Author: Matthias Konrad

−	{{Warning\|~~'''Warning''':~~ Article in development and will most probably be skipped}}	+	{{Warning\|Article in development and will most probably be skipped}}

@@ Line 47: / Line 47: @@
 |}
-Out of this reason, EiffelStudio tests invariants not only on feature exit but also on feature entrance. The invariant violation in the above example would still not be detected. In practice the fact that not all the violations are detected is not the real problem, since most are. Invariant violation are often detected to late. It is not only important to detect an invariant violation but also to know who (by which I mean which line of code) is to blame for it.
+Out of this reason, EiffelStudio tests invariants not only on feature exit but also on feature entrance. The invariant violation in the above example would still not be detected. In practice the fact that not all the violations are detected is not the real problem, since most are. Invariant violation are often detected too late. It is not only important to detect an invariant violation but also to know who (by which I mean which line of code) is to blame for it.
 ==Side-effect sensitive invariant checking SESIC==
 SESIC goes one step further. It not only aims to detect all possible invariant violations, it detects them right when they occur.

@@ Line 6: / Line 6: @@
 [[Category:Assertion checking]]
-Invariants are a very powerfull technique for giving meaning to programs. They reveal mission critical information about the behaviour of an object. When invariants are violated something in the system went (terribly) wrong.
+Invariants are a very powerful technique for giving meaning to programs. They reveal mission critical information about the behaviour of an object. When invariants are violated something in the system went (terribly) wrong.
 ==Definition invariant violation==
@@ Line 47: / Line 47: @@
 |}
-Out of this reason, EiffelStudio tests invariants not only on feature exit but also on feature entrance. The invariant violation in the above example would still not be detected. In practice the fact that not all the violatioins are detected is not the real problem, since most are. Invariant violation are often detected to late. It is not only important to detect an invariant violation but also to know who (by which I mean which line of code) is to blame for it.
+Out of this reason, EiffelStudio tests invariants not only on feature exit but also on feature entrance. The invariant violation in the above example would still not be detected. In practice the fact that not all the violations are detected is not the real problem, since most are. Invariant violation are often detected to late. It is not only important to detect an invariant violation but also to know who (by which I mean which line of code) is to blame for it.
 ==Side-effect sensitive invariant checking SESIC==
 SESIC goes one step further. It not only aims to detect all possible invariant violations, it detects them right when they occur.

@@ Line 1: / Line 1: @@
 Author: Matthias Konrad
-Document Status: In Work
+{{Warning|'''Warning''': Article in development and will most probably be skipped}}
 [[Category:Assertion checking]]

← Older revision		Revision as of 16:15, 19 October 2006
Line 1:		Line 1:
	Author: Matthias Konrad		Author: Matthias Konrad
		+
	Document Status: In Work		Document Status: In Work

← Older revision		Revision as of 16:14, 19 October 2006
Line 1:		Line 1:
		+	Author: Matthias Konrad
		+	Document Status: In Work
		+
		+	[[Category:Assertion checking]]
		+
	Invariants are a very powerfull technique for giving meaning to programs. They reveal mission critical information about the behaviour of an object. When invariants are violated something in the system went (terribly) wrong.		Invariants are a very powerfull technique for giving meaning to programs. They reveal mission critical information about the behaviour of an object. When invariants are violated something in the system went (terribly) wrong.

@@ Line 33: / Line 33: @@
        do
           create a.make
           a.l.put ("hello")
        end

← Older revision		Revision as of 23:28, 18 October 2006
Line 1:		Line 1:
	Invariants are a very powerfull technique for giving meaning to programs. They reveal mission critical information about the behaviour of an object. When invariants are violated something in the system went (terribly) wrong.		Invariants are a very powerfull technique for giving meaning to programs. They reveal mission critical information about the behaviour of an object. When invariants are violated something in the system went (terribly) wrong.
		+
		+	==Definition invariant violation==

	==Status quo of invariant detection==		==Status quo of invariant detection==

← Older revision		Revision as of 23:26, 18 October 2006
Line 39:		Line 39:
	Out of this reason, EiffelStudio tests invariants not only on feature exit but also on feature entrance. The invariant violation in the above example would still not be detected. In practice the fact that not all the violatioins are detected is not the real problem, since most are. Invariant violation are often detected to late. It is not only important to detect an invariant violation but also to know who (by which I mean which line of code) is to blame for it.		Out of this reason, EiffelStudio tests invariants not only on feature exit but also on feature entrance. The invariant violation in the above example would still not be detected. In practice the fact that not all the violatioins are detected is not the real problem, since most are. Invariant violation are often detected to late. It is not only important to detect an invariant violation but also to know who (by which I mean which line of code) is to blame for it.

−	==Side-effect sensitive invariant checking ~~SSIC~~==	+	==Side-effect sensitive invariant checking SESIC==
		+	SESIC goes one step further. It not only aims to detect all possible invariant violations, it detects them right when they occur.

← Older revision		Revision as of 23:20, 18 October 2006
Line 38:		Line 38:

	Out of this reason, EiffelStudio tests invariants not only on feature exit but also on feature entrance. The invariant violation in the above example would still not be detected. In practice the fact that not all the violatioins are detected is not the real problem, since most are. Invariant violation are often detected to late. It is not only important to detect an invariant violation but also to know who (by which I mean which line of code) is to blame for it.		Out of this reason, EiffelStudio tests invariants not only on feature exit but also on feature entrance. The invariant violation in the above example would still not be detected. In practice the fact that not all the violatioins are detected is not the real problem, since most are. Invariant violation are often detected to late. It is not only important to detect an invariant violation but also to know who (by which I mean which line of code) is to blame for it.
		+
		+	==Side-effect sensitive invariant checking SSIC==