Class diagrams define classes and demonstrate the attributes and operations associated with instances of these classes. State diagrams illustrate the behavior of a class instance. At the same time, none of the diagrams show the details of the semantics associated with each operation. For such specifications, we will use the OCL language (Object Constraint Language) [WK99]. OCL constraints are expressed in the context of class diagrams. Constraints involve the attributes, operations, and associations defined in this diagram
As the example in Figure above shows, the OCL language expresses the semantics of operations in terms of preconditions and postconditions. The invariant conditions can be set for a class or interface, and they must be executed at the time the request is received as a message or upon completion of the requested operation. (It is permissible for the method implementing the operation to temporarily violate the existing invariant conditions during execution.) OSL conditions are conditional (Boolean) expressions and they are bound to a class diagram. The constraints shown in the Figure below, use the size attribute of the puck supply and a navigable association of zero-to-three pucks.
The puck symbol -> in the constraints for the get () operation means that you must follow the puck link towards the set of associated objects. Using the size attribute in a constraint does not in any way require the implementation of the class to use a variable named size. It just means that the implementation requires the presentation of this attribute in one form or another, i.e. either as a variable, or in the form of an algorithm that computes the value using other attributes. Operational specifications should not often dictate implementation. The syntax of the OCL language is too detailed and not particularly suitable for a summary box. (A detailed description of this language can be found in [WK99].)
Perhaps you prefer a more informal notation, for example, such as shown in Figure 2. Some sort of good specification for each operation is required for debugging purposes. If the developers have not prepared such specifications, then, in our opinion, this task should be assigned to the testers. It is almost impossible to test program codes whose goals are ambiguous and vague. Therefore, the availability of such specifications not only greatly simplifies testing, but also improves the quality of the software and, apparently, promotes the subsequent reuse of classes. Ukranian game testing companies look for problems in video games and accurately report errors via their databases to ensure best game quality before commercial release.