featuresmatrix intro pageThis row includes information on the object models used in various objectanalysis and design methods (hence this row itself contains entries formultiple models). The descriptions of these models are based on the descriptionsof the methods as published in books. It is important to realize that theobject model described here is not necessarily the object model of theauthor(s); it is the result of an attempt to capture the object model describedin the book. The book may have been misinterpreted; the book may have usedonly a part of the author(s) complete object model; that model may havechanged since the publication of the book.
Some authors have published more than one book. Sometimes these booksseparately cover analysis and design. Sometimes different sections of onebook are devoted to analysis and to design. In any case, it is informativeto note the elements of the object model used in analysis, and new or differentelements used in design. Accordingly, the matrix entries sometimes distinguishthe analysis model from the design model. In the cases of some authors,subsequent books in some sense replace an earlier book or books. In thesecases, the model described is that of the book or books mentioned in 14.Background and References. When an author elaborates a concept of themodel under the heading of construction, this is sometimes also indicated.
Where possible, the definitions of terms used by the author(s) havebeen quoted. The matter in "double quotes" is quoted directlyfrom the books. Terms under discussion are enclosed in 'single quotes'when the term is mentioned, as opposed to a referent of the term. Matterin [square brackets] was inserted by the row submitter.
The analysis and design models included, and their identifications,are:
D: Booch Design
CA: Coad et al. Analysis
CD: Coad et al. Design
EA: Embly et al. Analysis
FA: Coleman et al Analysis
FD: Coleman et al Design
FC: Coleman et al Construction
HA: Henderson-Sellers et al. Analysis and Design
JA: Jacobson et al. Analysis
JD: Jacobson et al. Design
MD: Meyer Design
MC: Meyer Construction
NA: Waldén et al. Analysis and Design
OA: Odell et al. Analysis
RA: Rumbaugh et al. Analysis
RD: Rumbaugh et al. Design
SA: Shlaer et al. Analysis
SD: Shlaer et al. Design
WD: Wirfs-Brock et al. Design
0. Intended Use
These models are intended to be used in analysis and design, as opposedto the construction of systems. This is not to imply that the same modelwould not be used during construction and maintenance. In fact, some authorsstress that this is their intention: that the transition to constructionbe 'seamless,' have no 'impedance mismatch' or 'semantic gap.'
1. Basic Concepts
2. Objects
SA: "Definition: An object is an abstraction of a set of real-worldthings: such that:
'Object' is used in two senses: 1. a typical unspecified instance 2.the class of all instances.
CA: "An abstraction of something in the domain of a problem orits implementation, reflecting the capabilities of a system to keep informationabout it, interact with it, or both; an encapsulation of Attribute valuesand their exclusive Services. (Synonym: an Instance.)"
RA: "A discrete, distinguishable entity which quantizes data.""A concept, abstraction, or thing with crisp boundaries and meaningfor the problem at large." Instance.
JA: "An object is characterized by a number of operations and astate which remembers the effect of these operations." Instance
WD: "The primitive element of object-oriented programming is anobject. ... an object retains certain information, and knows how to performcertain operations." Instance.
MD: An object is a data structure of a specified abstract data type."...a class is a type, an object is an instance of a type. ...an objectis a purely dynamic concept, which belongs not to the program text, butto the memory of the computer, where objects occupy some space at run-timeonce they [have] been created..."
EA: "An object is a person, place, or thing. An object may be physicalor conceptual."
FA: "An object corresponds to a concept, abstraction, or thingthat can be distinctly identified. During analysis, objects have attributesand may be involved in relationships with other objects. [The authors donot maintain a distinction between 'thing of interest' and 'abstractionrepresenting thing.'] "The reader should note that the notion of objectduring analysis is different from that usually employed. Many methods permitanalysis objects to exhibit dynamic behavior and have a method interface;this is not the case in [this method], where analysis object have no interfaceand no dynamic behavior."
FD: "During design, the notion of object is extended by the introductionof methods and object attributes."
FC: "In the implementation phase the notion of object is determinedby the programming language."
OA: "An object is anything to which a concept applies. It is aninstance of a concept." 'Object' is used both for the model of a thingand for the thing itself.
BD: "An object has state, behavior, and identity; the structureand behavior of similar objects are defined in their common class; theterms instance and object are interchangeable."
'Object' is used both for the model of a thing and for the thing itself.
"...[S]ome things ... are distinctly not objects. For example,[some] attributes ... On the other hand, these things are all potentiallyproperties of other objects."
HA: "An object is a particular instance of a class".
NA: An object is an instance of a class "built according to thedescription in [the] class."
2.1 Operations
SD: "An instance-based operation is one in which the caller ofthe operation supplies an instance of the underlying data structure...The operation then manipulates that data structure." "Operationsfor which the caller does not supply a particular instance of the underlyingdata structure are known as class-based. Class-based operations includequeries, iterators, and create operations.
CA:
RA: "A function or transformation that may be applied to or byobjects in a class."
JA: "An instance of an actor does a number of different operationsto the system."
WD: The term is used and taken as understood.
MD: "Routines are the implementations of the operations of theinstances of a class."
EA: "An action may be composed of one or more individual operations.""An action may cause events, create or destroy objects and relationships,observe objects and relationships, and send or receive messages."
FA: "An input event and the effect it can have are called a systemoperation. At any point in time, only one system operation can be active."System operations are invoked by agents in the environment of the system."Note that all the operations in an operation model operate on thesame global state."
OA: "An operation is a process that can be requested as a unit."Operations carry out state changes. See 9.6 Other: Control Condition.
BD: "An operation is some action that one object performs uponanother in order to elicit a reaction."
HA: "Operations are services of a class that lead to changes inthe state of an object of that class. Operations may be viewed as commandson the object; that is, requests for the object to do something. Operationsshould not return information about the outcome of the operation; thisshould only be visible via the services termed properties. "
NA: "The only visible part of an abstract data type is its operations..." "... [T]he term ... feature ... cover[s] both the operationalaspects and the state aspects of class operations."
2.2 requests
SA: Instances make requests by generating events.
CA: Instances make requests via message connections. "A MessageConnection is a mapping of one Object into another (or occasionally toa Class, to create a new Object), in which a 'sender' sends a message toa 'receiver.' to get some processing done."
RA:
JA: An actor instance "inputs a stimulus, the use case instanceexecutes and starts a transaction belonging to the use case." See2.10 events.
WD: "When one object sends a message to another object, the senderis requesting that the receiver of the message perform the named operation,and (possibly) return some information."
WD: Rather than make requests, programs apply an operation to an object.
EA: A request is one kind of interaction.
FA: An input event is a request for a system operation.
OA: "A means by which an operation is invoked. It consists of anoperation name and zero or more actual parameters." A request is issuedto cause an operation to be performed."
BD: Instances make requests by sending messages or invoking member functions.The term used depends on the implementation language.
HA: "... [T]he basic model of communication between objects istaken from Coleman et al. (1992). In this model, services are requestedfrom a client object such that the provider of the service is directlynamed by the client. Information flow can be bi-directional such that theresult of a request is returned to the client. The communication mechanismis synchronous. "
NA: Objects 'call' or 'invoke' features upon objects. See 2.3 messages.
2.3 messages
SA: There is no explicit concept of messages. Instances generate eventsfor themselves or other instances. Events carry parameters.
CA: See 2.2 requests. "...each Message Connection representsvalues sent within the context of a particular service need, and a responsereceived as a result."
RA: There is no explicit concept of messages. Instances generate eventsfor themselves or other instances. Events carry parameters.
JA: "The dynamics in an object-oriented model is created throughthe dynamic relations, by means of objects [instances] sending stimulito other objects. We denote by the concept stimulus the event when an objectcommunicates with another object. In a programming context, the word 'message'is often used instead, but in order to avoid the message-semantic, we usethe stimulus concept."
WD: "A message consists of the name of an operation and any requiredarguments."
MD: The term 'message' is not used. Routines are applied to objects.The routines may have parameters.
EA: "The most common type of interaction among objects is communication.""Two objects communicate when one object sends a message to anotherobject. ...[M]essages are tangible or intangible objects transmitted inan interaction."
FA: "A system operation is always invoked by an [external] agent,not an object; the analysis phase is not concerned with internal messagingbetween objects."
FD: "Message passing is a directed point-to-point communication,and is realized as a function or method call." "A message mayinvolve bi-directional data flow when the invocation of a method returnsa value." "When a message is sent to an object it results inthe invocation of a method. The method call completes before control isreturned to the caller. If the invoked method also sends messages to otherobjects, the methods that are invoked must all complete before the initialinvocation completes." "The object interaction graph definesthe sequence of messages that occur between a collection of objects torealize a particular operation."
OA: "Messages ... are a more restricted case of requests. A messagesupplies only one object in its request for an operation along with anynumber of object parameters. A request is not limited to one object itrequests for an operation."
BD: "The terms message, method, and operation are usually interchangeable."See 2.1 operations.
HA: "Message are the triggers for activating services. Messagesare instantaneous in time." "Once a message is received, theappropriate service is activated."
NA: "Message[:] A feature call." "[W]e switch freelybetween the message passing metaphor and the feature call metaphor (objectsinvoking operations on each other) ..." "[S]ending a messageto an object, calling a class feature, or invoking an operation on an object... always mean the same thing."
2.4 specification of behavioral semantics
SA: The model uses diagrammatic and declarative specification of behavior.Behavior of instances is specified in a four step process. A Moore statediagram [E.F. Moore, "Gedanken-experiments on Sequential Machines."in Automata Studies, Princeton: Princeton University Press, 1956.] is preparedfor each (interesting) class; the behavior of an instance on entry to eachstate is described with text; a data flow diagram is prepared for eachstate, showing in more detail the behavior on entering the state; eachprocess of the data flow diagram is further specified with text.
The model allows for both synchronous and asynchronous interaction.
The model uses constraints common to entity relationship diagramming.
CA: The model uses diagrammatic and declarative specification of behavior.A state diagram is prepared for each class. Behavior of services is specifiedby 'service charts,' a form of flow chart, with behavior further specifiedby preconditions, triggers, and text blocks.
The model uses constraints common to entity relationship diagramming.
RA: "The dynamic model shows the time-dependent behavior of thesystem and the objects in it." It consists of 'event traces' and state-transitiondiagrams. "The functional model shows how values are computed, withoutregard for sequencing, decisions, or object structure." It is "amodel of those aspects of a system concerned with transformations of values--functions,mappings, constraints, and functional dependencies." It consists ofdata flow diagrams. [It is unclear, but the diagrams appear to be organizedby functional decomposition.]
"Constraints are functional relationships between entities of theobject model. The term entity includes objects [instances?], classes, attributes,links, and associations. A constraint restricts the values that entitiescan assume. ... We favor expressing constraints in a declarative manner.... Object models capture some constraints through their very structure."
JA: "The use case model uses 'actors' and 'use cases' to specifybehavior. When an [actor] inputs a stimulus, the use case instance executesand starts a transaction belonging to the use case. This transaction consistsof different actions to be performed." The behavior is specified innatural language. "A use case class is a description. This descriptionspecified the transactions of the use case. The set of all use case descriptionsspecifies the complete functionality of the system."
WD: A brief description of each method is provided in natural language;the collaborations required are noted.
MD: One "... may associate with an element of executable code [oran element of a design] -- instruction, routine, class -- an expressionof the element's purpose. Such an expression (which states what the elementmust do, independently of how it does it) will be called an assertion...Mathematically, the closest notion is predicate, although the assertionlanguage [used] has only part of the power of full predicate calculus.""The task performed by a routine may be specified by two assertionsassociated with the routine: a precondition and a postcondition.""A class invariant is ... a list of assertions, expressing generalconsistency constraints that apply to every class instance as a whole;this is different from preconditions and postconditions, which characterizeindividual routines."
EA: "[W]e use state nets to model object behavior. A state netis a configuration of symbols representing states and state transitionsfor all objects in a particular object class. We consider a state net tobe a 'behavior template' that specifies the expected behavior for instancesof an object class. When we associate a state net with an object class,we declare that every instance of the object class has the behavior describedby the state net."
"To describe a system more satisfactorily ... we often wish tostate additional properties ... by imposing constraints." The modelincludes a number of named kinds of constraints, each with its own formof 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 specifies the behavior of system operationsdeclaratively by defining their effect in terms of changes of state andthe events that are output" "...using preconditions and postconditions...The precondition characterizes the conditions under which a system operationmay be invoked The postcondition describes how the system state is changedby a system operation and what events are sent to agents." "Theoperation model specification says nothing about the intermediate statesthrough which the system passes while the operation is active. These statesare dependent on the way the operation is implemented and are therefornot the legitimate concern of the analyst." "The effect of invokingan operation when the precondition is false is undefined." "...the semantics of the object models are defined, but only informally."See 11. Object Languages.
"A cardinality constraint restricts the number of objects whichmay be associated with each other in a relationship." The "...total marker ... indicates that the objects in the adjacent class mustappear in the relationship."
"An invariant is an assertion that some property must always hold.... They are expressed as textual notations."
FD: "A description of the method is given by text in the data dictionary.""Each method can then be considered in turn to design how it shouldbe decomposed into suboperations." "Sequencing information canbe explicitly show by introducing sequence labels in parentheses abovethe message name [in an object interaction graph]. ... "Decorationson sequencers ... [indicate] conditional selection in a method responsiblefor sending the message.... [Graphs may also indicate repetition of a message,that is zero or more messages are sent. ... [M]essages with the same sequencelabel occur in an unspecified order... Messages with no sequencer occurin any order."
FC: The method "permits anything [author's emphasis] tohappen when a precondition is violated. This grants implementors the freedomto do anything they like..."
OA: "Behavioral specification tends to be represented in two basicways-state-related and nonstate-related. ... The two primary forms of state-relatedapproaches are finite-state machine and scenario specification. The twoprimary forms of state-related approaches include decision-based specificationand language." Pre-and postconditions are another alternative discussed.
Constraint "A constraint is a property that is always expectedto be true ... and is usually categorized as being structural or behavioralin nature." Types of constraint are distinguished and discussed indetail.
Rule "Rules are declarations of policy or conditions that mustbe satisfied."
BD: The model uses diagrammatic and declarative specification of behavior.Scenarios are described, are elaborated as scripts, and responsibilitiesare stated, all in natural language. State transition diagrams, interactiondiagrams, and object diagrams are used to "illustrate ... the semanticsof mechanisms in the logical design." "... [T]o a large degree,an interaction diagram is simply another way of representing an objectdiagram." Interfaces and data structures are defined in the implementationlanguage.
Constraints are indicated by "an expression ... adjacent [on adiagram] to the class or relationship for which the constraint applies.'Invariant,' 'precondition,' and 'postcondition' are mentioned once brieflybut not further used.
HA: 'Behavior' is used as a synonym for 'service. ' Services also havea protocol and a contract. Behavior of object classes is described by 'objectcharts';behavior at the subsystem level are described by scenarios/use cases andevent models.
NA: "The precondition states a predicate that must be true whenthe feature is called by a client." "The postcondition statesa predicate that must be true when the feature has been executed.""The class invariant [a predicate] must be satisfied before and afterexecution of any public feature of the class." Thus is behavior specified.
2.5 methods
SA: The concept 'method' is not used in analysis.
CA: Service. A Service is a specific behavior that an object is responsiblefor exhibiting. It is possible for the receiver of a message to returna result and then continue to take ongoing action. A service can have triggerand terminate constraints, so that it can activate itself without the needfor a message to be sent to it.
RA: "A method is the implementation of an operation for a [particular]class."
JA: The concept 'method' is not used in analysis. However, "[e]achobject [instance] is able to receive a specified number of stimuli. Theobject interprets this stimulus and performs an operation or, perhaps,directly accesses a variable. In Smalltalk, this stimulus is called a messageand the operation executed as a result of receiving a message is calleda method."
WD: "A method is a step-by-step algorithm executed in responseto receiving a message whose name matches the name of the method."
MD: The term 'method' is not used. The features of classes include routines,which may be procedures or functions.
EA: The term 'method' is not used in this method of analysis.
FA: "The analysis concept of object does not include any notionof method interface. Methods are the means whereby objects communicateto perform some task. In the analysis phase, we concentrate on specifyingwhat task a system has to perform. Discussion of object communication ispostponed to the design phase."
FD: "When a message is sent, the receiver invokes the correspondingmethod in the interface. [The appearance in an object interaction graphof a] message m to a server object C means that all objects of class Cwill include a method corresponding to m in the method interface. Eachmethod invocation may alter object attributes and return a result. "
OA: "A method is a processing specification for an operation.""An operation may have more than one method defined for it."
BD: "The terms message, method, and operation are usually interchangeable."See 2.1 operations.
HA: "A method implements a service by calculation (as opposed tostorage)."
NA: Not used. Defined as: "Method (of a class)[:] A class feature."['Method' is used by the authors in the sense of 'a method of analysisand design.']
2.6 state
SA: "A state [of a class] represents a stage in the life cyclefor instances of the object [class] concerned." States are modeledwith a Moore diagram.
CA: "An Object State is the identification of Attribute value(s)which reflects a change in Object behavior."
RA: "An abstraction of the attribute values and links of an objectwherein sets of values are grouped together in states according to theproperties that affect the gross behavior of the object."
JA: States are modeled with a Mealy diagram augmented by conditionson the transition edges.
"The internal state is what characterizes all the values of thosevariables that are important for description, as well as variables relatingto the application and variables that are included due to the implementationenvironment."
"The computational state describes how far we have come in theexecution [of a use case], as well as the potential future execution."
WD: Not used
MD: "The notion of state used here is simple: every instance ofa class has a certain number of fields, corresponding to the attributesof the class. The values of these fields at any point during system executiondetermine the state of the object." ...[T]he state is a pure abstraction,never accessed directly, but only manipulated through commands [procedures]and queries [functions]."
EA: "A basic part of behavior modeling is the set of states anobject exhibits in a system. ...[A] state represents an object's status,phase, situation, or activity."
FA: "In the analysis phase, the state of a system is modeled asa set of objects [and their attributes] that participate in relationships.""Note that all of the operations in an operation model act on thesame global state... The operation model specification says nothing aboutthe intermediate states through which the system passes while the operationis active."
FD: "Each class has an abstract state space that defines the semanticstate of the class. The actual concrete representation of that state isencapsulated. The complete abstract state space of a class should be reachablefrom the class interface."
FC: "A state machine is some collection of states and labeled transitionsbetween them." The states are translated from analysis, and remainglobal states.
OA: "State is a collection of associations an object has with otherobjects and object types."
BD: "The state of an object encompasses all of the (usually static)properties of the object plus the current (usually dynamic) values of eachof these properties." "The state of an object represents thecumulative results of its behavior."
HA: State is the combination of values of the attributes and associations.
NA: "System state[:] The sum of all information stored in a system.""Object state[:] That part of the system state that has an effecton the future behavior of an object. Object state often corresponds toone or more attributes of an object, but this does not necessarily meanthat data is stored in the object itself."
2.7 object lifetime
SA: The lifetime of an instance is explicit in the state diagram ofthe class. Each class either has a "circular" life cycle andinstances always exist, or has a "born and die" life cycle andinstances are created and destroyed as a result of events.
CA: Create and release services are implicit in all classes. Releasedisconnects any existing message connections and deletes the instance.
RA: No explicit concept of instance life cycle.
RC: "Objects [instances] can be allocated statically (at compiletime), dynamically (from a heap), or on a stack." The lifetime ofstatic objects "is the duration of the program." "Most temporaryand intermediate objects will be implemented as stack-based... The advantageis that they are automatically allocated and deallocated... [when] thedeclaring block [is] exited." "One allocated, dynamic objectspersist until they are explicitly deallocated. ... Some languages ... providegarbage collection, which removes the burden of deallocation from the programmer..."
JA: "When a class in instantiated, a instance is created that followsa path in [a state transition graph] throughout its lifetime." [ihave not yet found the discussion of the end of the lifetime, though thisis implicit in the correlation of use case instances with instances ofcontrol objects.]
WD: Instance lifetime is discussed as a language issue.
MD: Objects are explicitly created; they exist until they are no longerreferenced.
EA: The special interaction, "[c]reate brings an object into existencewithin the analysis system being modeled." The special interaction,"[d]estroy causes an existing object to cease to exist as far as theanalysis model is concerned."
FA: "The keyword new preceding an object identifier [in the Changesclause of an operation model schema] indicates that the system operationcreates a new object in the system state."
FC: "An important issue... is that of object destruction."This issue is treated as language dependent.
OA: "In a creation event an entirely new object appears.""[E]ach time an object is created, is must become a member of someobject type's set." "In a termination event, an object is removedfrom our awareness." "[A]fter termination the object is no longeran instance of any object type."
BD: Object lifetime is determined in accordance with the possibilitiesprovided by the implementation language.
HA: No explicit concept. Objectcharts show initial and final states.
NA: Discussed as an implementation issue in terms of the possibilityof garbage collection as a language capability, and the necessity in anycase of providing for the eventual destruction of persistent objects.
2.8 behavior/state grouping
SA: An event is always directed to a specific instance. Behavior dependson the instance and its state: in each state, an instance will respondto only to specified events; other events directed to the instance areignored and lost to the system. The behavior in response to an event isdetermined by the state to which the instance moves as a result of theevent. Uses the 'classical' object model.
CA: Behavior is specific to a class. "An Object State is the identificationof Attribute value(s) which reflects a change in Object behavior. The currentstate may be tested in a service chart and behavior modified as a resultof the test." Uses the 'classical' object model.
RA: [The contributor does not understand Rumbaugh et al. here.] Usesthe 'classical' object model.
JA: See 2.6 state. Uses the 'classical' object model.
WD: Responsibilities are assigned to a particular class; uses the 'classical'object model.
MD: "...[B]y introducing a state and operations on this state,we make the abstract data type specification richer as it has more functionsand more properties. ... In the end the view of objects as state machinesreflects abstract data types which are more operational, but this in noway makes them any less abstract." Uses the 'classical' object model.
EA: Actions may be associated with both states and transitions. Usesthe 'classical' object model.
FA: "A life-cycle expression defines the allowable sequences ofoperations that a system may participate in over its lifetime. In at anypoint the system receives an event that is not allowed according to thelife cycle, then the system ignores it and leaves the state of the systemunchanged." Uses the 'classical' object model.
OA: 'Classical' and 'generalized' object models are considered to bean implementation issue. "During analysis, however, we do not makesuch implementation-related choices. As such, we should index those operationshaving multiple input variables with multiple object types." "Thisis sometimes referred to as multiple polymorphism."
BD: "... [W]e may say that all methods are operations, but notall operations are methods: some operations may be expressed as free subprograms.In practice, we are inclined to declare most operations as methods, although... there are sometimes compelling reasons to do otherwise, such as whena particular operation affects two or more objects of different classes,and there is no particular benefit in declaring that operation in one classover another." Uses both 'classical' and 'generalized' object models.
HA: Uses the 'classical' object model.
NA: Does not use state machines in analysis. Uses the 'classical' objectmodel.
2.9 communication model
2.10 events
SA: "An event is the abstraction of an incident or signal in thereal world that tells us that something is moving to a new state. in abstractingan event, four aspects of the event are specified: meaning, destination[class], label, [and] event data." Event data includes "identifierdata [which] specifies the instance... that is going to receive the event."
CA:
RA: "An individual stimulus from one object [instance] to anotheris an event." "An event is a one way transmission of informationfrom one object to another. ... An object sending an event to another objectmay expect a reply, but the reply is a separate event under the controlof the second object, which may or may not choose to send it."
JA: The event when an object communicates with another object. See thediscussion of 'stimulus' elsewhere.
WD: Not used
MD: [find again the discussion of events.]
EA: "An event is any change within a system. Examples include thecreation or deletion of an object, a change in a relationship set, a changeof state for an object, starting or stopping an activity, and the receptionof a command or message."
FA: "An event is an instantaneous and atomic unit of communicationbetween the system and its environment. An input event is sent by an agentto the system; an output event is sent by the system to an agent. The communicationis asynchronous, as the sender does not wait for the event to be received.The sender may supply data values and objects with an event. When a systemreceives an event it can cause a change of state and the output of events.The effect of an event is determined by the values that are supplied withit and the state of the system when it is received."
OA: "An event is a noteworthy change in state."
BD: "An event is some occurrence that may cause the state of asystem to change." " An event may be a symbolic name (or a namedobject), a class, or the name of some operation. ... We may take the strategythat all events are just symbolic names and that each class with interestingevent-ordered behavior provides an operation that can consume such namesand carry out the appropriate action. ... For more generality, we may treatevents as objects, and so define a hierarchy of event classes that provideour abstraction of specific events. ... Lastly, we might define an eventsimply as an operation ... This approach is similar to that of treatingevents as symbolic names, except that we no longer require an explicitevent-dispatching operation."
HA: The term is not used. "Messages are the triggers for activatingservices"
NA: Used only for occurrences external to the system. "System event[:]Something to which a system will respond with a certain behavior."
2.11 transition rules
Editor's Note: This subsection has been added to describe an aspectof a number of Analysis and Design Methods.
SA: Each class has a set of transition rules which "specify whatnew state is achieved when an instance in a given state receives a particularevent."
CA: Transitions rules are shown as a part of the service charts.
RA: Not explicit
JA: Not explicit
WD: Not used
MD: Not used
EA: "The events and actions that activate state transitions arecalled triggers." "A trigger gives the conditions that, whenmet, may cause the transition to fire."
FA: "A life-cycle expression defines the allowable sequences ofinteraction that a system may participate in over its lifetime. If at anypoint the system receives an event that is not allowed according to thelife cycle, then the system ignores it and leaves the state of the systemunchanged. ... Life cycles are simple extensions to regular expressionsor grammars." [The method] "does not use state machines duringanalysis. "
FD: A node of a state machine.
OA: 'Triggers' and 'control conditions' determine what state changetakes place when an event occurs. See 9.6. 'Operations' are associatedwith states, transitions, or both. "The current trend is to employa combination of Mealy and Moore modeling techniques."
BD: [A] "change of state [caused by an event] is called a statetransition." "Each ... event is likely to trigger some action..." The actions are shown as text on the state transition diagram.
HA: State transitions are modeled using objectcharts.
NA: Not used.
3. Binding
SD: "In OOD it is common to define published operations of thesame name in several different classes. In such a situation the selectionof exactly which operation to invoke varies in a language-dependent manner."
CD: Time of binding is considered to be a language feature. "Dynamicbinding (which could also be referred to as dynamic dispatching) describesthe ability of an application to choose or bind a particular service atrun time..."
RD: Time of binding is considered to be a language feature. "...methodresolution at run time (also known as dynamic binding) [is used] to implementpolymorphic operations." It "is the process of matching an operationon an object [instance] to a specific method."
JA: "The linking of the received stimulus to the appropriate operationto be executed is performed by binding the stimulus to this operation.If this binding occurs during compilation, it is said to be a static binding.... If this binding occurs when the stimulus is actually being sent, thatis during run-time, it is said to be dynamic binding. Other names for thisare late, delayed, or virtual binding.
WD: Not used. Type checking is discussed as a language issue.
MD: "The rule known as dynamic binding implies that the dynamicform of the object determines which version of the operation is applied.""The ability of operations to automatically adapt to the objects towhich they are applied is one of the most important properties of objectoriented systems."
EA: Not used.
FC: "Dynamic binding is the process whereby the actual method codefor a method invocation is selected. It is required when a method acceptsarguments of any subtype of its argument type, and the compiler cannotdetermine as compile time what the actual type of an argument is."
OA: Considered an implementation issue.
BD: Binding is determined in accordance with the possibilities providedby the implementation language.
HA: Considered an implementation issue.
NA: "Dynamic binding[:] A mechanism permitting different behaviorto result from the same feature call." Dynamic binding is consideredan essential characteristic of the analysis model.
4. Polymorphism
SD: "At design time, a polymorphic invocation is a invocation ofone of a set of instance-based published operations, where all of the publishedoperations in the set have the same module name but differing class names.When indicating a polymorphic invocation, the designer is stating that(1) the published operations to be invoked will be selected at run time,and (2) the selection will be based on the type of the instance."
CD: [It appears to the present editor that Coad has successfully describeda method of 'object-oriented' analysis and design without invoking theconcept polymorphism.]
RA: "The same operation may apply to many different classes. Suchan operation is polymorphic: that is, the same operations takes on differentforms in different classes."
JA: "Polymorphism means that the sender of a stimulus does notneed to know the class of the receiving instance." See 3. Binding.
WD: "Polymorphism is the ability of two or more classes of objectto respond to the same message, each in its own way."
MD: "Polymorphism means the ability to take several forms. In objectoriented programming this refers to the ability of an entity to refer atrun-time to instances of various classes." "This kind of polymorphismdoes not involve objects changing their form a run time, or being convertedfrom one format to another, it simply means that a given entity may referto objects of various kinds." "...[E]very ... entity has a statictype (class) and the dynamic types it may take are restricted to the descendantsof that class. "
EA: Apparently not used.
FD: "The same method [may] apply to two different classes, perhapstaking on different implementations (thus making it polymorphic.) "
OA: "An operation may have more than one method defined for it.... One common reason for multiple methods is due to differences betweenthe input variables. ... In other words, the same operation can supportdifferent types of objects-each with its own method. This phenomenon isknown as polymorphism..."
BD: "... [P]olymorphism ... represents a concept in type theoryin which a single name (such as a variable declaration) may denote objectsof many different classes that are related by some common superclass. Anyobject denoted by this name is therefore able to respond to some commonset of operations. The opposite of polymorphism is monomorphism, whichis found in all languages that are both strongly typed and statically bound,such as Ada."
HA: "Polymorphism is the ability of abstractions to share services.It can be defined as 'a concept in type theory in which a name may denoteobjects of many different classes related by some common base class. Thus,any object denoted by this name is able to respond to some common set ofoperations in different ways' (Booch and Vilot, 1990b). "
NA: "Polymorphism[:] A mechanism by which a named reference ...can be attached to objects of different type at different points in time."
5. Encapsulation
SD: "Note that in this architecture we have defined the publishedinterface of the class in terms of event takers [a kind of method], ratherthan the actions (or even processes that make up the action.) This providestrue semantic encapsulation of the state of an instance."
CA: "A principle, used when developing an overall program structure,that each component of a program should encapsulate a single design decision...The interface to each module is designed in such a way as to reveal aslittle as possible about its inner workings.[quoted from The Oxford Dictionaryof Computer Science]" The second sentence gives the sense used.
RA: "Encapsulation (also information hiding) consists of separatingthe external aspects of an object [instance], which are accessible to otherobjects [instances], from the internal implementation details of the object,which are hidden from other objects."
JA: "The behavior and information are encapsulated in the object[instance]. the only way to affect the object is to perform operationson it. Objects thus support the concept of information hiding, that is, they hide their internal structure from their surroundings."
WD: Encapsulation is "building ... a conceptual barrier aroundsome collection of things. ... Encapsulation transforms many into one byadding a new layer of meaning."
"The object has a public interface and a private representation,and keeps these two facets quite distinct. This principle is known as informationhiding. Information-hiding allows us to remove from view some portion[emphasis added--ed.] of those things which have been encapsulatedby the object."
MD: "The information hiding principle may be stated as follows:All information about a module should be private to the module unless itis specifically declared to be public. " In certain cases it is usefulto hide a feature from all but one or a few classes.
EA: Apparently not used. Nothing in the analysis model is hidden. Thereare no attributes. An objects may interact with itself.
FD: "Data abstraction: The details of a classes representationare visible only to its methods."
OA: "... [E]ncapsulation provides a protective encasement aroundeach object's data. The object's data becomes accessible only by particularoperations associated with the object."
BD: "Encapsulation is the process of compartmentalizing the elementsof an abstraction that constitute its structure and behavior; encapsulationserves to separate the contractual interface of an abstraction and itsimplementation." "Encapsulation is most often achieved throughinformation hiding, which is the process of hiding all the secrets of anobject that do not contribute to its essential characteristics; typically,the structure of an object is hidden, as well as the implementation ofits methods."
HA: "At the implementation level, code and data can be encapsulatedtogether into a class (i.e., gathered together in a code module) yet remainvisible to other classes. ... On the other hand, information hiding requiresthe visibility of data to be restricted to within the (encapsulated) module.In other words, encapsulation does not guarantee information hiding. Similarly,information hiding does not necessitate encapsulation of the concept ina module. In OT the aim is to use both mechanisms to encapsulate a conceptwithin one module and to hide the details of that concept's implementationvia information hiding. "
NA: "Information hiding[:] A technique whereby implementation details... are hidden from the authors of client modules, who are instead presentedwith a public interface."
6. Identity, Equality, Copy
Note: 'Equality' and 'copy' do not appear to be used by any of the authorson analysis and design, except for Booch and Coleman et al. Meyer usesthem in discussing language.
SA: All objects have identity, based on values of primary identifierattributes. No concept of equality of objects. "An identifier is aset of one or more attributes whose values uniquely distinguish each instanceof an object [class.]"
CA: "...[D]eferred to design is the selection of actual identificationsmechanisms... Every Object needs such identifiers. ...each Object has animplicit identifier" in analysis.
RA: "Explicit object identifiers are not required in an objectmodel. Each object has its own unique identity."
JA: "Each instance also has a unique identity."
WD: Not used.
MD: See the separate matrix entry on the Eiffel language.
EA: Not used.
FA: "An object is thing that can be distinctly identified.""[T]here can be many distinct objects with the same attribute values."
In the data dictionary and the schemata "[t]he infix operator '=='` is used to compare the identity of two references to objects: Do thereferences refer to the same object or not? The infix operator '=' is usedto compare the contents of two objects, by comparing their attributes forequality. If the equality of objects depends not only on their attributes,but on relationships in which they are involved, a definition for the equalityoperator should be supplied."
OA: Not used.
BD: "Identity is that property of an object that distinguishesit from all other objects." Equality is determined in accordance withthe possibilities provided by the implementation language. The effect ofcopying is determined in accordance with the possibilities provided bythe implementation language. The relationship of assignment to copyingis discussed as a language and implementation issue.
HA: "Objects have identity"
NA: "The concept of a unique identity which distinguishes an objectfrom all other objects, regardless of whether their internal structuresand values coincide or not. All objects are created with a unique identityin an object oriented system, so the user need not worry about introducingaccess keys."
7. Types and Classes
SA: Type: "Now we take all the attributes that are common to allof the separate objects [classes or, strictly, typical unspecified instances]--thesubtype objects--and use these attributes as the basis for generalizinga new object, which we call the supertype object." "Attributesthat are common to all the subtype objects are places in the supertypeobject. The subtype objects will also have additional attributes to supportthe more specialized abstractions represented by each subtype." "Ina subtype-supertype construct, one real-world instance is represented bythe combination of an instance of the supertype and an instance of exactlyone subtype."
SD: Class: the external view of a class is represented in design bya diagram showing the name of the class, the name and type of each logicaldata component, the name of each published operations (instance- and class-based)along with the name, type, and cardinality of each of the input and outputparameters of the operation; conditional parameters and deferred operationsare identified.
"... each class is designed around a data type appropriate forstoring information about an instance of that class."
Type: footnote: "* A supertype object is therefor analogous toa parent abstract class in Smalltalk and the parent deferred class in Eiffel.Subtype objects are analogous to child classes in virtually all object-orientedprogramming languages."
CA: "Class. A description of one or more Objects [instances], describablewith a uniform set of Attributes and Services; in addition, it may describehow to create new Objects in the Class." Type does not appear to bea part of the object model.
RA: "An object class describes a group of objects [instances] withsimilar properties (attributes), common behavior (operations), common relationshipsto other objects, and common semantics."
JA: "A class is sometimes called the object's type. However, atype and a class are actually not the same thing. As we mentioned above,an abstract data type is defined by a set of operations. A type is definedby what manipulations you can do with the type. A class is more than that.You can also look inside the class, for example to see its informationstructure. We would therefore rather view the class as one (of possiblymany) specific implementation[s] of a type.
WD: 'Type' is discussed only in the context of type checking by compilersand run time systems.
MD: "...[A] class is an abstract data type implementation, notthe abstract data type itself." "A language construct combiningthe module and type aspects is called a class."
"...[T]rue object -oriented programming all but identifies themotion of module with the notion of type. ... The fusion of two apparentlydistinct notions is what gives object-based design its distinctive flavor."
EA: The term 'type' is not used. "[A] set of objects that belongtogether for some logical reason is called an object class." "Theidea of an object class is similar in concept to the technique of biologicalclassification, where biologists group living things together that sharecommon traits." [Note that in biological classification a 'type' isan individual which exemplifies the classification. --ed.]
FA: "Objects are grouped into sets called classes. A class is anabstraction, which represents the idea or general notion of a set of similarobjects. Associated with each class there is a predicate that defines thecriteria for class membership." "class: A set of objects thatshare a common structure and a common behavior. " "An objectis an instance of a class if its type is that class or a subtype of it.""Generalization allows a class, called the supertype, to be formedby factoring out the common properties of several classes, called subtypes."
OA: "A concept ... is just a word or symbol we can use in placeof repeating its definition. ... The prevalent term for concept in theobject-oriented analysis standards is object type. (Some use the term class.Most standards organizations, however, consider classes as implementationsof object types.) Therefore ... the name object type will be used insteadof concept."
BD: "A class is a set of objects that share a common structureand a common behavior."
BD: "... [A] type [is t]he definition of the domain of allowablevalues that an object may posses and the set of operations that may beperformed on the object. The terms class and type are usually (but notalways) interchangeable; a type is a slightly different concept than aclass, in that it emphasizes the importance of conformance to a commonprotocol."
HA: "A class is an implementation of an Abstract Data Type (ADT)"."... the ADT is the specification and the class the implementationof the ADT." It is "possible to construct more than one versionof a class that implements the same ADT."
NA: "[A] class is viewed as the implementation of an abstract datatype..." "Abstract data type[:] A type of data structure ...defined exclusively through its external behavior. An [abstract data type]is defined by a number of applicable operations, how each operation maybe invoked (the signature), and its effect (the semantics)." "Atype is roughly equivalent to a class in this book, except that parameterizedclasses give rise to different types, depending on the type of the furnishedparameters."
8. Inheritance and Delegation
SA: Multiple inheritance is used in data modeling. No explicit conceptof delegation.
CA: Inheritance may be single or multiple. The terms used are 'hierarchygeneralization-specification structure' and 'lattice generalization-specificationstructure.' No explicit concept of delegation.
RA: "Inheritance is a mechanism for implementing generalization,in which the behavior of a superclass is shared by all its subclasses.Sharing of behavior is justifiable only when a true generalization relationshipoccurs, that is, only when it can be said that the subclass is a form ofthe superclass."
"Delegation consists of catching an operation on one object andsending it to another object that is part of o r related to the first object."
JA: Inheritance: "The descendent has all of the properties of theancestor. ...the descendant knows of its ancestor, but the ancestor doesnot know of its descendants.
Extends: "One object extends another object" by providingadditional functionality. This concept corresponds to 'delegation.'
Jacobson et al. refer to delegation as reuse of code through composition,rather than inheritance.
WD: "Collaborations represent requests from a client to a serverin fulfillment of a client responsibility. A collaboration is the embodimentof the contract between a client and a server. An object can fulfill aparticular responsibility itself, or it may require the assistance of otherobjects. We say that an object collaborates with another if, to fulfilla responsibility, it needs to send the other objet any messages."
"... [S]ubsystems delegate each contract to a class within themthat actually supports the contract."
MD: "(Inheritance): A class may be defined as an extension or restrictionof another.
"...[I]f types are identified with modules, then it is temptingto identify the reusability mechanisms provided by both concepts: On theone hand, the possibility for a module to directly rely on entities definedin another. On the other hand, the concept of subtype, whereby a new typemay be defined by adding new properties to an existing type. In object-basedlanguages, this is know as the inheritance mechanism, with which a classmay be defined as an extension or restriction of a previously defined one."
EA: '... [T]he essential idea for is a relationships sets is that oneobject class is a subset/superset of another." "A superset objectclass is called a generalization, and a subset object class is called aspecialization." "Since the members of a specialization are alsomembers of a generalization, they all participate in the relationship setsof a generalization. The converse, however, does not hold because somemembers of a generalization may not be members of a specialization, andmay, therefore, not participate in the relationship sets of the specialization.This observation leads to the notion of inheritance." "A specializationinherits the relationship sets of its generalization." There are noattributes in the model.
"... [W]e have multiple inheritance when a class is a specializationof two or more generalizations."
FA: "In a generalization, the attributes and relationships of thesupertype are 'inherited' by the subtypes. Each subtype may have additionalattributes and participate in additional relationships. Specializationis the converse case in which a new subtype is defined as a more specializedversion of a supertype."
"During analysis, abstract subtype relationships between classesare identified. Specialization defines a semantic relationship betweentow classes: the general and specific ones. This semantic relationshipis inherent in the domain of the system. Specialization and generalizationare properties of the domain model and not of the system design or implementation."
"Multiple specialization allows a new subtype to be defined asa specialization of more than one immediate supertype. ... The subclassinherits the attributes and relationships of all its superclasses."
FD: "At design ... the inheritance relationship is a property ofthe system and not necessarily of the domain."
"... [C]ollaborators collaborate and cooperate with the controllerto implement the system operation."
OA: "...[T]he word inheritance has not been used in conjunctionwith generalization. In OO analysis, this term is not appropriate ... torefer to the application of a type's properties to its subtypes. It isappropriate, however, for OO design. In OO programming, inheritance isthe mechanism that facilitates the reuse of program code from a class toits subclasses."
BD: "... [I] defines a relationship among classes, wherein oneclass shares the structure or behavior defined in one or more classes (denotingsingle inheritance and multiple inheritance, respectively).
"An alternative approach to inheritance involves a language mechanismcalled delegation, in which objects are viewed as prototypes (also calledexemplars) that delegate their behavior to related objects, thus eliminatingthe need for classes."
HA: Delegation: "Contracting with an O/C to provide a service placesa responsibility on that O/C... However, it is of no interest to the clientwhether the supplier fulfills its contract itself or by subcontractingto one or more other classes.
Generalization/specialization (or specialization inheritance) representsthe is-a-kind-of relationship. Specification inheritance permits polymorphicsubstitutability but not necessary specialization inheritance. Implementationinheritance "focuses on code inheritance, rather than on behaviorand substitutability". Multiple generalization and multiple inheritanceare both allowed.
NA: "A class may inherit from one class (single inheritance), fromseveral classes (multiple inheritance), or several times from the sameclass (repeated inheritance). Inheritance is simply defined as the inclusionin a class ... of operations and contract elements defined in other classes..." "Delegation[:] Refers to shared behavior in object-orientedsystems using prototypes instead of classes ..." as in the language,Self. [See Self entry--ed.]
9. Noteworthy Objects
9.1 relationships
SA: Relationship includes ordinary ERD relationships and the 'is-a'relationship for sub/supertyping and inheritance. Relationships are notconsidered to be objects.
CA: 'Association,' is used, defined generally as "the union orconnection of ideas." The technical meaning does not seem to be definedexplicitly. This term corresponds to the term 'relationship' as used byothers. Associations are not considered to be objects.
RA: "A link is a physical or conceptual connection between objectinstances." Links are not considered to be objects.
"An association describes a group of links with common structureand common semantics." The terms 'link' and 'association' correspondto the term 'relationship' as used by others, while distinguishing betweeninstances of relationships and the class of all such instances.
"A link attribute is a property of the links in an association."
"A role is one end of an association...which may have a role name."
"A qualified association relates two object [classes] and a qualifier.The qualifier is a special attribute that reduces the effective multiplicityof an association. One-to-many and many-to-many associations may be qualified.... Qualification usually reduces multiplicity from many to one, but notalways."
JA: "The models objects [instances] ... have relations with eachother. ... These relations can be of two sorts. First, static relations,namely relations existing over a longer period, which means that two objectsknow about each other's existence. Secondly, dynamic relations, namelyrelations by which two objects actually communicate with each other. Thereis an abundance of different static relations in connection with semanticmodeling" Relationships are not considered to be objects.
Inheritance relations are an association between classes.
"A class association ... is an association between classes."
An instance association is an association between instances.
"An acquaintance association is a static association between instancesand means that the instance knows of the existence of another instance."
"A communication association models communication between two objects.Through these associations, an object sends an receives stimuli."
"There is a large and fundamental difference between data modelingand object orientation. In data modeling, you think of the model as a flatstructure viewed from above. In this way it is natural to see the relationshipas a binding between two objects. The relationship here is often bi-directional.In object orientation, however, the view is instead made from an object[instance], you place yourself at an object and then see what referencesyou have to other objects. This fundamental difference is hard to get usedto for people used to data modeling."
WD: Types of relationship include: "depends-upon," "has-knowledge-of,""is-analogous-to," "is-kind-of," and "is-part-of."Relationships are not considered to be objects.
MD: [A] "field [of an object, and, likewise, an attribute of aclass] may contain references to other objects." The relationshipsindicated by these references are to objects. Relationships are not consideredto be objects.
EA: "A relationship establishes a logical connection among objects.""A relationship set is a set of relationships where each matches thesame template ["with object classes designating slots for objectsand phrases that express a logical connection among the objects"]and has as its name the text of the same template." "Specialtypes of relationship sets include... the is a relationship set, the partof relationship set, and the is member of relationship set." Relationshipsare not considered to be objects.
FA: "A relationship is a tuple of objects..." "The objectmodel shows classes, not objects. Thus we extend the notion of relationshipto classes. In the object model a relationship is used to model the ideaof associations or correspondence between the objects belonging to classes."Relationships are not considered to be objects.
OA: "Associations provide a means to link objects of various typesin a meaningful way. While object types involve sets of objects, associationsinvolve connections of objects between sets. ... This collection of connectionsbetween object types forms a special kind of object type called a relationshiptype. Furthermore, using these connections enables us to map the objectsof one set into objects of another-and back again. Together, relationshiptypes and mappings are two techniques for describing associations betweenobjects."
BD: "In all, there are three kinds of class relationships[:]"generalization/specialization, whole/part, and association. Associationis "[a] relationship denoting a semantic connection between two classes."...A"link [b]etween two objects is one instance of an association."Associations do not indicate direction; links are unidirectional.
HA: "Relationships between classes ... are association, aggregationand generalization." "Association is a meaningful relationshipbetween two O/Cs such that one O/C may request a service from another.This represents the direct use of the services of one O/C by another"
NA: "Relation[:] A dependency between two entities; used ... asan abbreviation for the term relationship." There are three kindsof relationships. "Only two kinds of static relations are needed inobject oriented systems, inheritance relations and client relations.""For the [dynamic] relationship between a calling object and the callee,we use the term ... message relation ..."
9.2. attributes
SA: "An attribute is an abstraction of a single characteristicpossessed by all entities that were themselves abstracted as an object."They are atomic in the sense of RDB first normal form. These attributesare not objects.
CA: "An attribute is some data (state information) for which eachObject in a Class has its own value." Normalization, in the RDB sense,is deferred to design. These attributes are not objects.
RA: "An attribute is a data value held by the objects [instances]in a class. ... An attribute should be a pure data value, not an object.Unlike objects, pure data values do not have identity."
JA: "To store information, objects [instances] use attributes.To each entity object we can thus tie several attributes. Each attributehas a type, which can be of a primitive data type, ... but it can alsobe of a composite data type which is more complex and that is especiallydefined." The attributes of an object are modeled by an associationwith a name, a cardinality, and a type. These attributes are not objects.
WD: Attributes are not modeled during design, instead the model is interms of "the responsibilities of an object to maintain information..."
MD: "[A]n attribute is a component in a class that will give afield in each object of the class. These attributes are not objects.
EA: None.
FA: "In addition to being able to be identified, an object canhave one or more values associated with it. ... The attribute values ofan object can be changed, but the number and name of the attributes arefixed. ... [D]uring the analysis phase, the values of attributes are notallowed to be objects. Attributes assume values from types such as integers,booleans, text, and enumerations." "Relationships as well asobjects can have attributes." During design "... some data attributesand object-valued attributes are established."
OA: An attribute is "[a]n identifiable association that an objecthas with some other object or set of objects that is represented withinan object type." The term, attribute, is also used in discussion ofentity-relationship-attribute modeling.
BD: "...[A]n attribute denotes part of an aggregate object ...used... to express a singular property of the class. To be precise, anattribute is equivalent to an aggregation association with physical containment,whose label is the attribute name and whose cardinality is one."
HA: "Properties are services (responsibilities) of a class thatinvolve information being disclosed about the state of an object. Propertiesmay be viewed as queries on the state of an object and hence should nothave side effects on state (Meyer, 1988a). Properties that return objectsare viewed no differently from properties that return 'values'." "...[T] is no conceptual distinction between 'values' and 'objects' (Beeri,1990).
Properties that return 'values' are often termed 'attributes' althoughthis does not necessarily imply a physical piece of stored data.""The word attribute is reserved for those data stored privately (privateservices) - the decision to define the internal data structure may be takenat almost any stage of the lifecycle although preferably left until latein the design process."
NA: "Attribute[:] A property of an object manifested as a functionreturning a value."
9.3 literals
This concept seems to belong to languages and software construction,rather than to analysis and design.
9.4 containment
[Note: The contributor takes 'containment' to refer to the concept wherebyobjects are considered to be composite, that is, to be composed of otherobjects which are contained within the composite object. This sense correspondsto the implementation whereby component objects are 'physically contained'within the composite object (thinking of a composition mechanism is possiblein C++, but not in Smalltalk). As will be seen, the term is used differentlyby most authors.]
SA: Containment is considered to be a kind of ordinary relationship.An object is not 'within' another object; rather, an object has a "referentialattribute," identifying the other object. Instances of containmentrelationships are not necessarily objects.
RD: "Many implementation data structures are instances of containerclasses. Such data structures include arrays, lists, queues, stacks,sets, bags, dictionaries, associations, trees, and many variations on these..."
JA: "A special type of acquaintance association [See 9.1 relationships]is the consists-of association, which is used to express that an objectis composed of other objects. Such a structure where a uniting object hasassociations with participating parts is sometimes called an aggregate."Instances of this relationship are not necessarily objects.
WD: Containment is modeled by the "is-part-of" relationship.A distinction is made between "composite classes" and "containerclasses." A composite class has responsibilities with respect to itsparts and will commonly collaborate with or delegate to them. An exampleis car, composed of wheels and other parts. A container class has a weakerrelationship to its contents. Examples are array and hash table. Instancesof both kinds of classes are, of course, objects; however, container classesare designed specifically to model containment.
MD: "It is often convenient to introduce ... objects that referto other objects. ... One technique is to allow objects to contain otherobjects... This technique is indeed possible... [b]ut it does not permitsharing. To allow for shared objects, fields may contain references toother objects."
EA:
OA: "Composition is often confused with containment or topologicalinclusion. Topological inclusion is the relationship between a container,area, or temporal duration and that which is contained." See 9.5aggregates.
BD: "Aggregation may or may not denote physical containment."
HA: "A structure that may be useful in Implementation is that ofthe composite class: a class defined with internal classes whose definitionsare local and are not externally visible, i.e. lexically included classes"
NA: "...[W]e should define a standard set of generic [container]classes ... for use as specification elements for very high-level informationstructures." [See matrix entry for Eiffel.]
9.5 aggregates
[Note: The contributor takes 'aggregation' to refer to the mechanismwhereby a (composite) object has relationships to other objects, whichrelationships mean that it is composed of the other (component) objects.(Strictly, that the composite object represents something composed of otherthings represented by the component objects). This sense corresponds tothe implementation whereby a composite object consists of, or otherwisemaintains access to, the identifiers of a fixed number (or a variable number,zero or more) of other objects (thinking of the only possible compositionmechanism in Smalltalk). Most authors use the term in this sense.]
SA:
CA: Classes may be organized in whole-part structures.
RA: "Aggregation is a strong form of association in which an aggregateobject is made of components. Components are part of theaggregate. The aggregate is semantically an extended object that is treatedas a unit in many operations, although physically it is made of severallesser objects." "Aggregation is a special form of association,not an independent concept."
JA: "A special type of acquaintance association [See 9.1Relationship.] is the consists-of association, which is used to expressthat an object is composed of other objects. Such a structure where a unitingobject has associations with participating parts is sometimes called anaggregate."
WD: Aggregation is modeled by the "is-part-of" relationship.A distinction is made between "composite classes" and "containerclasses." A composite class has responsibilities with respect to itsparts and will commonly collaborate with or delegate to them. An exampleis car, composed of wheels and other parts. A container class has a weakerrelationship to its contents. Examples are array and hash table. Instancesof both kinds of classes are, of course, objects; however, container classesare designed specifically to model containment.
MD: Aggregates are to be found in or built for a library.
EA: The is part of "relationship set declares that an object, calleda superpart or aggregate, is composed of other objects called subpartsor components."
FA: "Aggregation: a mechanism for structuring the object modelwhereby a new class in constructed from several other classes and [(optionally)]relationships." "An aggregation may be used to 'wrap up' a relationship.In this case the tuples of the aggregate must respect the contained relationship."
OA: "Composition (also referred to as aggregation) is a mechanismfor forming a whole from component parts." Types of composition aredistinguished and discussed in detail.
BD: "Aggregation denotes a whole/part hierarchy, with the abilityto navigate from the whole (also called the aggregate) to its parts (alsoknown as its attributes). In this sense, aggregation is a special kindof association."
HA: "Aggregation structures represent the is-part-of relationship."
NA: "An aggregation relations between a client class and a supplierclass is a special case meaning that whenever an i
9.6 other
SA: Ternary and higher order relationship.
SA: Associative object "To formalize a many-to-many relationship,create an associative object--a separate object [class or, strictly, typicalunspecified instance)] that contains references to the identifiers of eachof the participating instances."
SA: Assigner "When dealing with relationships for which there isa competition, we must first formalize the relationship in as associativeobject [See above in 9.6 Other] on the information model. Next webuild a state model that is responsible for creating instances of the relationshipby associating instances of the participating objects with one another."
SD: Architectural class: Finite State Model, Transition, Active Instance,Timer.
CA: Message connection: " an indication of processing dependency,indicating a need for services in order to fulfill responsibilities."A message connection may be from one object to many objects.
RA: Ternary Association
RA: Association modeled as a class: "Sometimes it is useful tomodel an association as a class. Each link becomes one instance of theclass. ... It is useful to model an association as a class when links canparticipate in associations with other objects or when links are subjectto operations."
JA: Actor: "Models one, or several, roles that an interactor tothe system can play. The interactor may be either human or machine.""We regard an actor as a class and users as instances of this class.These instances exist only when the user does something to the system.The same person can thus appear as instances of several actors."
JA: Use Case: "A special sequence of transactions in a dialoguebetween a user and the system. Each use case is thus a specific way ofusing the system. A use case may have one basic course and several alternativecourses." A use case may be regarded as a class. "Each use caseis a specific way of using the system and every execution of the use casemay be viewed as an instance of the use case."
JA: Entity Object: "The entity object models information in thesystem that should be held for a longer time, and should typically survivea use case.
JA: Interface Object: "The interface object models behavior andinformation that is dependent on the interface to the system. Thus everythingconcerning any interface of the system is placed in an interface object."
JA: Control Object: "The control objects model functionality thatis not naturally tied to any other object. Typically such behavior ...consists of operating on several different entity objects, doing some computationsand then returning the result to an interface object."
JA: Subsystem: "A subsystem groups several objects. ... Subsystemsmay include other subsystems." "The task of subsystems is topackage the objects so that the complexity is reduced." "Theaim is to have a strong functional coupling within a subsystem and a weakcoupling between subsystems."
JD: Block: "The design model will be composed of blocks which arethe design objects. These will make up the actual structure of the designmodel and show how the system is designed." Blocks are implementedby one or several classes.
JD: Object Module: "The module level of the programming languagewe denote by the generic term object module. ... In an object orientedlanguage these ... will be the actual classes."
WD: Collaborator "Collaborations represent requests from a clientto a server in fulfillment of a client responsibility. A collaborationis the embodiment of the contract between a client and a server.""We say an object collaborates with another if, to fulfill a responsibility,it needs to send the other object any messages." "It may takeseveral collaborations to completely fulfill a single responsibility; onthe other hand, some objects will fulfill a responsibility without collaboratingwith any other objects."
WD: Contract "A contract is the list of requests a client can makeof a server. Both must fulfill the contract: the client by making onlythose requests the contract specifies, and the server by responding appropriatelyto those requests." "The contract between client and server doesnot specify how things get done, only what gets done."
WD: Protocol "A protocol is the set of signatures to which a classwill respond."
WD: Responsibility "A responsibility is something one object doesfor other objects, either performing some action or responding with someinformation." Responsibilities are meant to convey a sense of thepurpose of an object and its place in the system." "The responsibilitiesof an object are all of the services it provides for all of the contractsit supports."
WD: Signature "A signature is the name of a method, the types ofits parameters, and the type of the object that the method returns."
MD: Contract "The relationship between a class and its clientsis viewed as a formal agreement, expressing each party's rights and obligations."See 'assertion.'
MD: Exception The occurrence of one of seven specified "abnormalcondition during the execution of a software element."
MD: Failure "...[T]he inability of a software element to satisfyits purpose." "A routine may either succeed or fail. It succeedsonly if it fulfills its contract." Failure occurs "if an exceptionoccurs during [the] execution [of a routine] and the routine terminates... by signaling an exception" to its caller. See the separate matrixrow for Eiffel.
MD: Error "...[T]he presence in the software of some element notsatisfying its specification."
EA: Association "We use the is member of relationship set to forma set of objects which we wish to consider as a single object." "Theobject class whose objects are sets is called the set class or the associationclass and the object class whose objects are members is called the memberclass or the universe. Association denotes that the members associate togetherto form an object."
EA: Exception "An exception is a system event or condition thatis not part of normal system behavior." Exceptions are modeled asdistinguished paths in the state net model. Exceptions may be associatedwith a state, a trigger, or a state transition; they may refer to a constraint.
FA: Ternary and higher relationship.
FA: Invariant "An invariant is an assertion that some propertymust always hold."
FA: Role "The classes participating in relationships have roles.Each role can be named... Role names are useful when it is unclear in whichorder to read relationship names."
FD: Controller or interface objects "One distinguished role isthat of the controller. The controller receives the request to invoke thesystem operation. The system operation is part of the method interfaceof the controller." The controller is "responsible for respondingto a system operation request." "A design should have interfaceobjects for each related set of operations at the subsystem interface."
FD: Collaborator "[T]he collaborators collaborate and cooperatewith the controller to implement the system operation."
FD: Collection A collection is "a relevant subset of objects identifiedin the design process. ... The objects in a collection may change overtime. Typical implementations of such collections will be lists or arrays."... "By default, when a message is sent to objects in a collection,all the objects in that collection receive the message."
FD: Reference "Each object must have a reference to another objectto communicate with it. Another way of looking at this is to say that aserver object must be visible to a client for the client to send a messageto the server." "For each relationship on the system object model,we expect that there is a path of visibility between the correspondingobjects at design."
FC: Error: "... [T]he violation of a precondition."
OA: Control Condition "A control condition is a mechanism that,when triggered, permits it associated operation to begin only when itsconstraints are met."
OA: Event Type Event types are a kind of object type. "An eventtype is a type or classification of event." Events are instances ofthe type.
OA: Mapping "A mapping assign the objects of one type to objectsof another type. ... A more formal definition of mapping (or function)is a process that maps one set into a powerset (or set of sets) of another."
OA: Trigger "A trigger invokes an operation when an event occurs.A trigger rule specifies that when a specific type of event occurs, a particularoperation will be invoked."
BD: "Actor[:] An object that can operate upon other objects butis never operated upon by other objects; is come contexts, the terms activeobject and actor are interchangeable."
BD: "Server[:] An object that never operates on other objects;it is only operated on by other objects."
BD: "Agent[:] An object that can both operate upon other objectsand be operated upon by other objects; an agent is usually created to dosome work on behalf of an actor or other agent.
HA: 'Scenarios' (use cases) are used.
NA:
10. Extensibility
10.1 dynamic
SA: No such concept.
CA: No such concept.
RA: No such concept.
JA: The object model is modeled in its own terms, and therefore is,in principle, extensible.
WD: No such concept.
MD: The concepts class and object "belong to different worlds:the program text only contains classes; at run-time only objects exist.This is not the only possible approach. One of the subcultures of object-orientedprogramming, views classes as objects themselves."
EA: No such concept.
FA: No such concept.
FD: No such concept.
OA: "A single framework model can be used to describe itself, aswell as, the enterprise." The model describes itself using a "kernelmeta-model" which is a part of the model. "The only reason forinhibiting changes to the kernel meta-level is to maintain standardization."
BD: Dynamic extensibility is determined in accordance with the possibilitiesprovided by the implementation language.
HA:
NA:
10.2 metaclasses/metaobject protocol
SA: No such concept.
CA: No such concept.
RA: No such concept.
JA: No such concept.
WD: No such concept.
MD: No such concept.
EA: No such concept.
FA: No such concept.
FD: No such concept.
OA: Implementing metamodels is discussed briefly in terms of the possibilitiesprovided by the implementation language.
BD: In the context of Smalltalk and C++, 'metaclass' is used to referto the place where features of the class (as opposed to those of instances)are found (e.g. Smalltalk 'class variables' and 'class methods' and C++'static members.') In the context of CLOS, 'metaclass' is used to referto the place where the semantics of the class may be dynamically changed(e.g. dynamic redefinition of methods or dispatching algorithms).
HA:
NA:
10.3 introspection
SA: No such concept.
CA: No such concept.
RA: No such concept.
JA: No such concept.
WD: No such concept.
MD: See the matrix entries for Eiffel.
EA: No such concept.
FA: No such concept.
FD: No such concept.
OA: No such concept.
BD: "[R]untime type identification" is determined in accordancewith the possibilities provided by the implementation language.
HA:
NA:
11. Object Languages
SA: N/A
CA: N/A
RA: N/A
JA: N/A
WA: N/A
MD: The language used is Eiffel; See the matrix entries for Eiffel.
EA: An "appendix formally defines [the object model]. In particular,if formally defines what it means for a model instance to be a valid ...model instance. As part of the formal definition, we give a ... meta-modelin terms of Object-Relationship-Model diagrams." "In our approachto formally defining valid ... model instances, we begin by providing amapping from an Object-Relationship-Model instance to a first-order languageand a set of first-order rules. We then map the first-order language toa mathematical model instance consisting of a universe of objects, a setof relations, a set of constants, and a set of functions. Using this lattermapping, we can check the validity of the mathematical model instance byascertaining the truth of the rules. If all the rules hold, the ... instanceis valid." "To formally define ... model instances, we then usethe meta-model... All valid mathematical model instances for the ... meta-modelare valid model instances."
FA: "To have a guarantee of consistency requires that it be possibleto semantically check the models fully. This is not possible without theuse of a formal specification language, such as Vienna Development Method[sic] VDM or Z, Unfortunately these techniques are only practical in safetycritical and other systems where defects must be avoided at all costs.... the semantics of the object models are defined, but only informally."
OA: N/A
OD: N/A
BD: N/A
HA:
NA: "This appendix [A] presents a formal syntax specification ofthe BON textual notation..." "Nothing can compensate for theprecision of a formal notation when it comes to communicating the difficultcases unambiguously."
12. Semantics of Base Classes (+type constructors)
SA: N/A
CA: N/A
RA: N/A
JA: N/A
MD: See the matrix entries for Eiffel.
EA: N/A
FA: "Attributes assume values from types such as integers, booleans,text, and enumerations." These are not further defined.
OA: N/A
BD: The author provides extensive examples in C++, using the base typesof that language.
HA:
NA: N/A
13. Background and References
BD:
Grady Booch, Object-Oriented Analysis and Design with Applications--SecondEdition, Redwood City, California: Benjamin/Cummings, 1994.
CA:
Peter Coad and Edward Yourdon, Object-Oriented Analysis--Second Edition,Englewood Cliffs: Prentice Hall, 1991.
CD:
Peter Coad and Edward Yourdon, Object-Oriented Design, Englewood Cliffs:Prentice Hall, 1991.
EA:
David W. Embly, Harry D. Kurtz, and Scott N. Woodfield, Object-OrientedSystems Analysis, Englewood Cliffs: Prentice-Hall, 1992.
FA, FD, FC:
Derek Coleman, Patrick Arnold, Stephanie Bodoff, Chris Dollin, HelenaGilchrist, Fiona Hayes, and Paul Jeremaes, Object-Oriented Development,Englewood Cliffs: Prentice-Hall, 1994 [sic, though published in 1993].
HA:
Brian Henderson-Sellers and J. M. Edwards, Book Two of Object-OrientedKnowledge: The Working Object, Sydney: Prentice-Hall, 1994.
JA, JD:
Ivar Jacobson, Magnus Christerson, Patrik Jonsson, and Gunnar Övergaard,Object-Oriented Software Engineering--A Use Case Driven Approach, Reading,Massachusetts: Addison-Wesley ("ACM Press"), 1992
MD, MC:
Bertrand Meyer, Object-oriented Software Construction, Englewood Cliffs:Prentice Hall, 1988.
NA:
Kim Waldén and Jean-Marc Nerson, Seamless Object-Oriented SoftwareConstruction-Analysis and Design of Reliable Systems, Hemel Hempstead,Hertfordshire: Prentice Hall, 1995
OA:
James Martin, and James J. Odell, Object-oriented Methods--A Foundation,Englewood Cliffs: Prentice Hall, 1995.
RA, RD, RC:
James Rumbaugh, Michael Blaha, William Premerlani, Frederick Eddy, andWilliam Lorensen, Object-Oriented Modeling and Design, Englewood Cliffs:Prentice Hall, 1991.
SA:
Sally Shlaer and Steven J. Mellor, Object-Oriented Systems Analysis--Modelingthe World in Data, Englewood Cliffs: Prentice Hall, 1988.
Sally Shlaer and Steven J. Mellor, Object Life Cycles--Modeling theWorld in States, Englewood Cliffs: Prentice Hall, 1992.
SD:
Sally Shlaer and Stephen J. Mellor, Object Life Cycles--Modeling theWorld in States, Englewood Cliffs: Prentice Hall, 1992.
Sally Shlaer and Stephen J. Mellor, "Real Time Recursive Design,"Berkeley: Project Technology, 1992.
WD:
Rebecca Wirfs-Brock, Brian Wilkerson, and Lauren Wiener, Designing Object-OrientedSoftware, Englewood Cliffs: Prentice Hall, 1991.