Side-effect sensitive invariant checking - Revision history

Manus at 10:19, 11 April 2007

2007-04-11T10:19:11Z

← 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}}

Seilerm: /* Status quo of invariant detection */

2007-03-14T18:07:47Z

Status quo of invariant detection

← Older revision		Revision as of 18:07, 14 March 2007
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==		==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.		SESIC goes one step further. It not only aims to detect all possible invariant violations, it detects them right when they occur.

Peter gummer at 00:51, 13 March 2007

2007-03-13T00:51:19Z

← Older revision		Revision as of 00:51, 13 March 2007
Line 6:		Line 6:
	[[Category:Assertion checking]]		[[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==		==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==		==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.		SESIC goes one step further. It not only aims to detect all possible invariant violations, it detects them right when they occur.

Konradm at 02:03, 15 November 2006

2006-11-15T02:03:55Z

← Older revision		Revision as of 02:03, 15 November 2006
Line 1:		Line 1:
	Author: Matthias Konrad		Author: Matthias Konrad

	~~Document Status~~: ~~In Work~~		{{Warning\|'''Warning''': Article in development and will most probably be skipped}}


	[[Category:Assertion checking]]		[[Category:Assertion checking]]

Konradm at 16:15, 19 October 2006

2006-10-19T16:15:04Z

← 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

Konradm at 16:14, 19 October 2006

2006-10-19T16:14:03Z

← 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.

Konradm: /* Status quo of invariant detection */

2006-10-19T16:12:39Z

Status quo of invariant detection

← Older revision		Revision as of 16:12, 19 October 2006
Line 33:		Line 33:
	do		do
	create a.make		create a.make
			a.l.put ("hello")
	a.l.put ("hello")		a.l.put ("hello")
	end		end

Konradm at 23:28, 18 October 2006

2006-10-18T23:28:53Z

← 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==

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

2006-10-18T23:26:27Z

Side-effect sensitive invariant checking SSIC

← 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.

Konradm at 23:20, 18 October 2006

2006-10-18T23:20:20Z

← 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==