features matrixintro pageObject models differ in how and to what extent the behavior of objectsis specified. Most object models limit the declarative specification ofobject behavior (operations) to the specification of a signaturefor each operation. The signature consists of the name of the operation,and the argument and result types. The semantics of the operations areoften defined operationally (by means of the code of the methods providedto implement the operations). Other object models allow declarative specificationof behavioral semantics, in the form of invariants that should be preservedby all operations, pre- and post-conditions for operations, other formsof constraints on the operations' behavior, or by a declarative specificationof the methods themselves. These models specify behavioral semantics ina precise and implementation-independent manner. Some of the models useformal notations based on mathematics (like Z, Object Z, LOTOS, etc.) fordoing so. These formal specifications may be translated into stylized English,in order to enhance their understanding by customers who are not mathematically-trained.See also entries under 2.1 operations.
Editor's note: Since we changed the heading from "interactionmodels" to "specification of behavioral semantics", someof the following entries must now be updated. The former feature 11.Integrity Constraints has been merged with this feature.
OODBTG Reference Model
The encapsulation characteristic makes it possible to define consistencyrules as part of the object definition that are enforced by the system.These consistency rules are known as "integrity constraints".Integrity constraints can be defined in several ways including:
o informally, in natural language or in an informal specification language.Such integrity constraints cannot be enforced.
o as procedures, in an object manipulation language. These may include"triggers" and " before- and after-methods".
o as "assertions", in a predicate-based language. Importantkinds of assertional integrity constraints include: "preconditions"and "postconditions", and invariants".
"Preconditions" and "postconditions" are Booleanexpressions associated with an operation which specify the PREconditionwhich should be TRUE immediately before execution of the operation andthe POSTcondition which should be TRUE as a result of its execution, i.e.,immediately after execution of the operation. If the precondition or postconditionis not true, the operation results in an error. A precondition and a postconditiontogether constitute a contract that can be used to specify an operation.
"Invariants" are operation-independent conditions associatedwith a collection of classes that must be true at all times NOT withinan operation on those classes. The concept of class-level invariants canbe used to provide a means of defining concepts like "relationships"and "containment."
Examples of some important kinds of integrity constraints include:
o Only pre-specified operations should be allowed on objects; i.e.,the protocol of objects should be enforced.
o Constraints may be expressed on the allowed types of operands andresults of operations and on the allowed types of values for propertiesof objects.
o Uniqueness constraints may be expressed on values of a property, acrossthe domain of instances of a class, or across members of some collection.
o Referential constraints, including rules governing identity and existence,are enforced. These include rules governing creation of object identifiersand rules that insure that referenced items exist.
Constraints may apply to all instances of a class, or only to specificinstances. Depending on the database system, constraints may be automaticallyenforced at run-time, may be enforced at compile time, and/or may be performedonly when a particular request is sent or when some system event occurs(e.g., transaction commit).
In addition, one of the principles for creating class libraries is thatoperations, assertions, or invariants can be jointly shared by more thanone class in a library. In this manner, associations between classes andtheir integrity rules may be specified.
OMG CORBA IDL
The CORBA specification does not specify the behavior of objects. Itdefines interfaces and allows interfaces to be defined in terms of operationsignatures. These operations can be invoked on objects resulting in methodsbeing dispatched which execute the service requested by the operation.The behavior of the object is defined by the methods that implement theobjects behavior. The actual semantics of an objects implementation isdefined by the object implementer and is outside the scope of the CORBAspecification.
ODMG
Object behavior is modeled through operations (see 2.1 Operations).An operation signature (part of a type specification) specifies argumenttypes, result types and exceptions that can be raised. "There is noformal specification of the semantics of an operation" (p. 25).
EXPRESS
EXPRESS provides for the specification of constraints on the populationand its members, but does not support any other behavioral specifications.It is likely that future versions of EXPRESS will support behavioral modeling.
Open Distributed Processing
Behavior (of an object) is defined as follows" "A collectionof actions with a set of constraints on the circumstances in which theymay possibly occur. The nature of the constraints which may be expresseddepends on the specification language in use. In general, there existsa set of possible sequences of observable actions consistent with any givenbehavior. A behavior may include internal actions. The actions that actuallytake place are restricted by the environment in which they object is placed.(part 2). The set of all sequences of operations that can occur from theinitial state based on legal state transitions determined by the pre-conditionsand post-conditions of the operations. (part 4).
Part 4 of the Reference Model for Open Distributed Processing describeshow architectural semantics of the Prescriptive Model (Part 2) may be specifiedusing several formal description techniques. These descriptions provideda very useful feedback for clarifying corresponding Clauses of Part 2.
Integrity constraints are considered a property of the model generatedfor the Information Language. Constraints are special relationships, whereeach relationship is associated with a predicate.
Management Information Model
Part of the definition of a managed object class is behavior. The behaviorcan define:
(a) the semantics of the attributes, operations and notifications;
(b) the response to management operations being invoked on the managedobject;
(c) the circumstances under which notifications will be emitted;
(d) dependencies between values of particular attributes, which mustbe expressed in a way that takes account of the possible presence or absenceof conditional packages;
(e) the effects of relationships on the participating managed objects;
(f) consistency constraints on attributes;
(g) preconditions that identify the conditions when operations and notificationscan be assumed to have valid meaning;
(h) postconditions that identify the results of the processing of amanagement operation or the emission of a notification;
(i) invariants that are in effect for the entire lifetime of the managedobject and that describe conditions that are true for an operation of themanaged object;
(j) synchronization properties of the managed object. [Part 1]... Thebehavior <of a relationship> specified by means of the invariantdefines, in particular, any dependencies this relationship class has onother relationship classes. [US Comments]
Behavior definitions specify behavioral aspects of managed object classesas a whole and also those specific to their characteristics (e.g., packages,attributes, actions, notifications, parameters, etc.). Behavior definitionsare essential to the understanding of an information model and are intendedto supplement the more formal specifications (i.e., template definitions)for which the behavior is provided.
A behavior definition is a string of text (that may be delimited) specifyingthe behavior of the managed object class. The most commonly used delimitersinclude double quotes (") and exclamation points (!). NOTE: It isstrongly recommended that specification authors use delimited text to facilitatemachine parsing and human readability.
The behavior definitions are intended to provide a wide variety of information,including, but not limited to, invariants for the managed object, preconditionsand postconditions for performing operations on the managed object, attributeusage restrictions, integrity constraints between attributes of the sameobject or interactions with other managed objects, instantiation rules,and rules for conditional package inclusion.
The text of a behavior definition may also include a reference to anotherpart of the same document or to another document. The current approachis to specify a behavior definition using text, although a formal descriptionlanguage, such as [Z], [LOTOS], or [ESTELLE] may be used in the future.The use of formal description languages in the context of OSI/CMISE informationmodels is currently under consideration as a new work item in ISO. Thiswill provide a precise method to specify the semantics associated withan OSI/CMISE information model just as the syntax associated with an OSI/CMISEinformation model is currently specified using ASN.1 [CCITT X.208, ASN.1].
Part of the definition of a managed relationship class is a relationshipdescription which can be used to describe:
(a) invariants: the consistency constraints that are in effect for theentire lifetime of the relationship. These are the constraints that mustbe maintained among the participants of the managed relationship....
(b) pre-conditions for operations: the conditions that must be met beforeinvoking operations that are used to manage the managed relationship...
(c) post-conditions for operations: the conditions that must be metimmediately following the operations that are used to manage the managedrelationships... [GRM 93, Clause 7.1.2]
For a formal technique to be appropriate for the description of managedobjects, it must fit into the framework prescribed in the standards. Thismeans that the method must deal with operations as a key concept.The method must be able to handle inheritance, and it must be compatiblewith ASN.1 data descriptions. Also, for a formal technique to beuseful and appropriate for use in standards, it must be based onmathematical concepts and have a well-defined meaning orsemantics. ... The appropriateness of a method depends very much on theapplication. For the description of formal methods from the criteria outlinedabove, we conclude that a logic-based method seems most suitable. ... Sinceinheritance is important, object-oriented flavors of either VDM or Z wouldbe most suitable for this task. Standardization of the methods, includingthe object-oriented extensions, is also necessary. Since Z is gaining popularitymore quickly than VDM, we recommend that the standards bodies choose anobject-oriented version of Z, such as Object-Z, for the formal descriptionof managed objects and managed relationships. [SMI Rapporteur Group 93]
See [X3T5.4] 1.1., 4., 9.4., 9.5. <where invariants, preconditionsand postconditions are proposed and used for defining behavior>
SQL3
Routines (procedures and functions) that define aspects of the behaviorof the ADT may be encapsulated within the ADT definition (these routineshave access to the ADT's PRIVATE attributes; routines may also be definedoutside an ADT definition). A number of these routines have predefinednames. For example, when an ADT is defined, a constructor function is automaticallydefined to create new instances of the type. The constructor function hasthe same name as the type and takes zero arguments. It returns a new instanceof the type whose attributes are set to their default values. The constructorfunction is PUBLIC. For every attribute, observer and mutator functionsare also automatically defined (these functions may also be explicitlydefined by the user). These functions are used to read or modify the ADTattribute values. EQUAL and LESS THAN functions may be defined to specifytype-specific functions for comparing ADT instances. RELATIVE and HASHfunctions can be specified to control ordering of ADT instances. CAST functionscan also be specified to provide user-specified conversion functions betweendifferent ADTs.
Other routines associated with ADTs include function definitions fortype-specific user-defined behavior. ADT function definitions return eitherBOOLEAN, if the result is to be used as a truth value in a Boolean predicate,or a single value of a defined data type, if the result is to be used asa value specification. Functions may either be SQL functions, completelydefined in an SQL schema definition, or external function calls to functionsdefined in standard programming languages.
See also 2. Objects and 2.5 methods.
Matisse
Objects stored on disk contain a reference to methods and messages whichinvoke them. The object code of a method is stored on the client workstationand executes on the client (except for certain operations which will occuron the server for performance optimization). Operations are function callswhich execute on the client. Method object code can be generated from anylanguage.
Referential integrity is automatically maintained by the database byautomatic support of inverse linkages between objects. Attributes, relationships,and classes all have user specified constraints. In addition, since Matissesupports pre- and post-condition triggers on all attributes and relationships,any computable user constraint can be implemented.
C++
The behavior of a C++ object is defined by its member functions. (see2.1 Operations and 2.5 methods). A definition of a memberfunction specifies argument types and the result type. There is no formalspecification of the semantics of an operation; the semantics are specifiedby the code of the member function.
Smalltalk
Behavior in Smalltalk is defined by methods specified in classes whichare implemented as class instances and execution is triggered in thoseinstances by message requests.
A set of standard classes having common behavior across all Smalltalkimplementations is being proposed by the X3J20 Smalltalk Language Technicalcommittee. Many of them are already implemented by Smalltalk suppliers.These methods fall into categories where common behavior is inherited byobject instances, classes, collections, associations, streams, basic geometry,or file I/O.
Eiffel
Behavioral semantics of objects can be specified in two ways: firstby the signature of the operations and secondly by assertions in the formof preconditions, postconditions and a class invariant.
The signature of an Eiffel operation specifies the name of the operation,any formal parameters (including their types) and optionally the type ofa return result.
Assertions are used to specify contracts between two objects. The objectusing an operation of another is called a client while the object providingthe operation is the supplier.
Assertions in Eiffel are boolean expressions that must evaluate to true.The expressions may refer to any operation or attribute within the classand also any actual parameters passed to the operation.
The part of the contract binding on the client is the precondition.A precondition specifies the conditions in which an operation can be called.This may be requirements for the object to be in a particular state orfor particular values of actual parameters.
The operation must abide by the postcondition. i.e.,. the postconditionis binding on the supplier. A postcondition may refer to the value of entitiesprior to the execution of the operation. This can be used to compare `old'values with new values.
The class invariant is used to specify general consistency constraintson an object.
The properties of a loop can also be specified using assertions. Loopvariants and invariants can specify that each iteration of the loop willmake some progress towards the termination condition and values that mustbe maintained during each iteration of the loop (invariant).
Finally additional arbitrary properties of objects and their operationscan be specified using assertions in the form of `check' statements. Wherebythe assertion(s) in a check statement will be evaluated when the statementis reached.
The failure of an assertion causes an exception. Exceptions may be handledin two of ways: an attempt to fix the problem, or failure. An operationmust either succeed in its execution or fail. A failure in an operationcauses an exception in the caller.
Operations may attempt to fix the problem by catching the exceptionin a `rescue' clause. The rescue clause may try to adjust the state ofthe object so that it is correct and then either retry the operation orfail.
SELF
Behavior in SELF is defined by specifying the corresponding methods.There are no types or classes in SELF, and therefore no separate specificationsof operation signatures or other descriptive information about behavior.
System Object Model (SOM)
SOM defines object behavior by permitting the specification of operationsignatures which consist of an operation name, and the argument and resulttypes. The semantics of the operations on an object are defined by themethods that implement these operations.
Analysis and Design Methods
SA: The model uses diagrammatic and declarativespecification of behavior. Behavior of instances is specified in a fourstep process. A Moore state diagram [E.F. Moore, "Gedanken-experimentson Sequential Machines." in Automata Studies, Princeton: PrincetonUniversity Press, 1956.] is prepared for each (interesting) class; thebehavior of an instance on entry to each state is described with text;a data flow diagram is prepared for each state, showing in more detailthe behavior on entering the state; each process of the data flow diagramis further specified with text.
The model allows for both synchronousand asynchronous interaction.
The model uses constraints common toentity relationship diagramming.
CA: The model uses diagrammatic and declarativespecification of behavior. A state diagram is prepared for each class.Behavior of services is specified by 'service charts,' a form of flow chart,with behavior further specified by preconditions, triggers, and text blocks.
The model uses constraints common toentity relationship diagramming.
RA: "The dynamic model shows thetime-dependent behavior of the system and the objects in it." It consistsof 'event traces' and state-transition diagrams. "The functional modelshows how values are computed, without regard for sequencing, decisions,or object structure." It is "a model of those aspects of a systemconcerned with transformations of values--functions, mappings, constraints,and functional dependencies." It consists of data flow diagrams. [Itis unclear, but the diagrams appear to be organized by functional decomposition.]
"Constraints are functional relationshipsbetween entities of the object model. The term entity includes objects[instances?], classes, attributes, links, and associations. A constraintrestricts the values that entities can assume. ... We favor expressingconstraints in a declarative manner. ... Object models capture some constraintsthrough their very structure."
JA: "The use case model uses 'actors'and 'use cases' to specify behavior. When an [actor] inputs a stimulus,the use case instance executes and starts a transaction belonging to theuse case. This transaction consists of different actions to be performed."The behavior is specified in natural language. "A use case class isa description. This description specified the transactions of the use case.The set of all use case descriptions specifies the complete functionalityof the system."
WD: A brief description of each methodis provided in natural language; the collaborations required are noted.
MD: One "... may associate withan element of executable code [or an element of a design] -- instruction,routine, class -- an expression of the element's purpose. Such an expression(which states what the element must do, independently of how it does it)will be called an assertion... Mathematically, the closest notion is predicate,although the assertion language [used] has only part of the power of fullpredicate calculus." "The task performed by a routine may bespecified by two assertions associated with the routine: a preconditionand a postcondition." "A class invariant is ... a listof assertions, expressing general consistency constraints that apply toevery class instance as a whole; this is different from preconditions andpostconditions, which characterize individual routines."
EA: "[W]e use state nets to modelobject behavior. A state net is a configuration of symbols representingstates and state transitions for all objects in a particular object class.We consider a state net to be a 'behavior template' that specifies theexpected behavior for instances of an object class. When we associate astate net with an object class, we declare that every instance of the objectclass has the behavior described by the state net."
"To describe a system more satisfactorily... we often wish to state additional properties ... by imposing constraints."The model includes a number of named kinds of constraints, each with itsown form of expression. "Users of the [model] may write general constraintsas they wish. A formalist may prefer some variation of predicate-calculusnotation, whereas others may prefer a concise natural language characterization."
FA: "The operation model specifiesthe behavior of system operations declaratively by defining their effectin terms of changes of state and the events that are output" "...usingpreconditions and postconditions... The precondition characterizes theconditions under which a system operation may be invoked The postconditiondescribes how the system state is changed by a system operation and whatevents are sent to agents." "The operation model specificationsays nothing about the intermediate states through which the system passeswhile the operation is active. These states are dependent on the way theoperation is implemented and are therefor not the legitimate concern ofthe analyst." "The effect of invoking an operation when the preconditionis false is undefined." "... the semantics of the object modelsare defined, but only informally." See 11. Object Languages.
"A cardinality constraint restrictsthe number of objects which may be associated with each other in a relationship."The "... total marker ... indicates that the objects in the adjacentclass must appear in the relationship."
"An invariant is an assertion thatsome property must always hold. ... They are expressed as textual notations."
FD: "A description of the methodis given by text in the data dictionary." "Each method can thenbe considered in turn to design how it should be decomposed into suboperations.""Sequencing information can be explicitly show by introducing sequencelabels in parentheses above the message name [in an object interactiongraph]. ... "Decorations on sequencers ... [indicate] conditionalselection in a method responsible for sending the message.... [Graphs mayalso indicate repetition of a message, that is zero or more messages aresent. ... [M]essages with the same sequence label occur in an unspecifiedorder... Messages with no sequencer occur in any order."
FC: The method "permits anything[author's emphasis] to happen when a precondition is violated. This grantsimplementors the freedom to do anything they like..."
OA: "Behavioral specification tendsto be represented in two basic ways-state-related and nonstate-related.... The two primary forms of state-related approaches are finite-statemachine and scenario specification. The two primary forms of state-relatedapproaches include decision-based specification and language." Pre-andpostconditions are another alternative discussed.
Constraint "A constraint is a propertythat is always expected to be true ... and is usually categorized as beingstructural or behavioral in nature." Types of constraint are distinguishedand discussed in detail.
Rule "Rules are declarations ofpolicy or conditions that must be satisfied."
BD: The model uses diagrammatic and declarativespecification of behavior. Scenarios are described, are elaborated as scripts,and responsibilities are stated, all in natural language. State transitiondiagrams, interaction diagrams, and object diagrams are used to "illustrate... the semantics of mechanisms in the logical design." "...[T]o a large degree, an interaction diagram is simply another way of representingan object diagram." Interfaces and data structures are defined inthe implementation language.
Constraints are indicated by "anexpression ... adjacent [on a diagram] to the class or relationship forwhich the constraint applies. 'Invariant,' 'precondition,' and 'postcondition'are mentioned once briefly but not further used.
HA: 'Behavior' is used as a synonym for'service. ' Services also have a protocol and a contract. Behavior of objectclasses is described by 'objectcharts'; behavior at the subsystem levelare described by scenarios/use cases and event models.
NA: "The precondition states a predicatethat must be true when the feature is called by a client." "Thepostcondition states a predicate that must be true when the feature hasbeen executed." "The class invariant [a predicate] must be satisfiedbefore and after execution of any public feature of the class." Thusis behavior specified.features matrixintro page