OCL - Revision history

Suhridk: /* Assertion Inheritance */

2012-01-08T00:03:57Z

Assertion Inheritance

2012-01-08T00:03:11Z

Invariants

2012-01-07T23:53:46Z

Generalizations

2012-01-05T21:03:26Z

Operations on objects and collections

2012-01-05T14:21:03Z

OCL Context

2012-01-05T14:16:10Z

Iterated Traversals

2012-01-05T14:15:21Z

Iterated Traversals

2012-01-05T13:31:56Z

Design by contract

2012-01-05T13:29:49Z

Assertions

2011-11-05T11:49:44Z

← Older revision		Revision as of 00:03, 8 January 2012
Line 356:		Line 356:
	* The responsibility of ensuring that the invariant is true is spread across the classes.		* The responsibility of ensuring that the invariant is true is spread across the classes.
	** Constructors, methods etc must ensure the invariant is true. Although during operations, the invariant could be false.		** Constructors, methods etc must ensure the invariant is true. Although during operations, the invariant could be false.
−
−	~~== Assertion Inheritance ==~~
−
−	* As in inheritance, the contract must be maintained at all times, so
−	* Preconditions in subclasses must be weaker or the same.
−	* Postconditions in subclasses must be stronger or the same.
−	* Example:
−
−	~~<syntaxhighlight lang="java5">~~
−
−	~~class Adult {~~
−
−	~~void check(int age) {~~
−	~~//pre~~
−	~~assert age > 18;~~
−
−	~~//post~~
−	~~assert age > 18;~~
−	}
−
−	}
−
−	~~class Driver extends Adult {~~
−
−	~~void check(int age) {~~
−	~~//pre - is weaker~~
−	~~assert (age > 16);~~
−
−	~~//post - is stronger~~
−	~~assert (age > 16 && licenseValid==true);~~
−	}
−
−	}
−
−	~~//Clients will always be happy when they are using the original contract of the Adult class~~
−
−	~~Adult a = new Adult();~~
−	~~a.check(19);~~
−	~~Adult d = new Driver();~~
−	~~d.check(19); //original contract satisfied~~
−	~~d.check(17); //weaker condition also satisfied~~
−
−	~~</syntaxhighlight>~~
−
−	~~[[Category:OODE]]~~

@@ Line 310: / Line 310: @@
 * If the client gets ElectricStove class where it has strengthened the invariant ... temp of ElectricStove cant be more than 150, it will be safe in the clients env.
 * Now, if ElectricStove weakens the constraint, then it is no longer safe to use with clients who expect to be using a Stove class.
 = Constraints in Prog Languages =

@@ Line 282: / Line 282: @@
 * e.g. a:Account and a.oclIsKindOf(CurrentAccount)
-* There are some recommendations that subclasses must adopt when it comes to constraints. (These are like the Java rules on what subclasses can do with exceptions for e.g.)
+== Inheritance ==
-TODO: Wife, husband example first one also, one check is enough ?
+* There are some recommendations that subclasses must adopt when it comes to constraints.
 = Constraints in Prog Languages =

@@ Line 177: / Line 177: @@
 * How this works is that staff (self.staff) where self refers to a department instance will return a bag of Person objects. staff.contract will then return a bag of contract objects (contracts for all person objects in previous bag), similarly a bag of grade objects, followed by a bag of salary objects. The operation sum() is then applied to this bag.
-=== select ===
+=== Iterating operations ===
 * An operation which allows us to specify criteria by which we can pick certain objects from a collection.
@@ Line 189: / Line 196: @@
 Here the select is working on bag of Person that employees produces. The first part of select specifies on which object we are applying the condition, then a '|' separator character, then the condition for the select. Then the operator isEmpty() is applied which will return true if the collection returned by the select is true.
-=== collect ===
+==== collect ====
 * Takes an expression as an argument and makes a collection which '''contains all values''' of the expression.
@@ Line 215: / Line 222: @@
 [TODO: ? Isnt the second notation simpler, isnt collect supposed to take an expression ]
 === constraints ===

@@ Line 57: / Line 57: @@
 * Note it does '''not''' have the same meaning as static.
 * This means the balance for '''''any''''' BankAccount object must be within 0 and 250000.
-* self means the same thing as "this".
+* self means the same thing as "this". Whenever self is used it refers to the instance of the type that is the context of the OCL constraint. If the context is BankAccount, self refers to an instance
 * In this case, self need not be mentioned (doesnt make a difference though)

@@ Line 106: / Line 106: @@
 === Iterated Traversals ===
-* Iterated traversals produces bags.
+* Iterated traversals can produce bags.
 * Navigations can be composed of multiple references - we can denote more paths through a diagram.
 * e.g All the people who work for a comapany

@@ Line 24: / Line 24: @@
 * A pre and post condition can be viewed as a '''contract''' between an operation and its invokers.
 * Something like - "If the client promises to invoke the operation with the precondition satisfied, then the operation guarantees that its implementing methods will deliver a final state in which the postcondition is true".
 * So the invoker doesn't care about how final state is produced

@@ Line 10: / Line 10: @@
 * In a program, assertions express constraints on program state that must be true at a '''specified point''' during execution.
 * In a model/diagram, they document what must be true of an '''implementation''' of a modelling element.
-* Can have optional preconditions - (must be true when operation is invoked). for e.g. an argument to a certain operation cannot be null.
-* Can have optional postconditions - (must be true when operation completes). for e.g. the operation must update the database when it completes.
+== Pre and Post Conditions ==
 = Design by contract =