The Object Modeling Language (OML) Specification - CiteSeerX

The Object Modeling Language (OML) Specification JIM SNYDER ULRICH FLEMMING REVISED : 2/8/95

Deparment of Architecture and Engineering Design Research Center Carnegie Mellon University Pittsburgh, PA 15213

Table of Contents 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 2 Agent Communication Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3 Definitions of Terms and Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1 Agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.2 Schemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.3 Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.4 Relationship Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.5 Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.6 Class Categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.7 Value Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.8 Relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.9 Triggers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.10 Extended Modelling Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.10.1 Derived Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.10.2 Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.10.3 Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.10.4 Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4 BNF Grammar of the Object Specification Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.1 Base Data Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.2 Aggregation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.3 Element List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.4 Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.5 Subdomain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.6 Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.7 Forward Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.8 Attribute List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.9 Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.10 Trigger Action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.11 Literal List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.12 Literal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.13 Argument . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.14 Variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.15 Relationship Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.16 Container Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.17 Expression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.18 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.19 Relation Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.20 Structured Value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.21 Arg List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.22 Conditional Expression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.23 Condition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.24 Relative Operator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

ACL Object Model Specifcation Language

2/10/95

Page i

4.25 Builtin Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 5 BNF Grammar of the Instance Manipulation Language . . . . . . . . . . . . . . . . . . . . . . . . . . 17 5.1 Frame Action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 5.2 Value Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 5.3 Frame Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 5.4 Value Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 5.5 Relationship Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 5.6 Variable Setting Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 5.7 Evaluation Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 5.8 Value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 6 Event Notification and Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 7 Language Bindings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 7.1 Domain Maps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 7.2 Embedded Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 7.3 Class Maps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 7.4 Complex Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 7.4.1 Embedded Object Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 7.4.2 Class Maps and Inheritance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 7.4.3 Relationship Maps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 7.5 Builtin Object Model Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 8 Example Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 8.1 Example Object Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 8.2 Federation Architecture Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 9 Annotated Bibliography with References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Page ii

2/10/95

ACL Object Model Specification Language

List of Figures FIGURE 1. . . . . . . . . . . . . . . . . . . . . .Example ACL Software Architecture FIGURE 2. . . . . . . . . . . . . . . . . . . . . . . . . . Object Model in OMT Notation FIGURE 3. . . . . . . . . . . . . . . . . . . . . Instance Network in OMT Notation FIGURE 4. . . . . . . . . . . . . . . . . . . . . Instance Network in OMT Notation FIGURE 5. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Basic Translation Process

5 9 15 19 23

1

Introduction The ACL project addresses problems of distributed collaboration in the context of building design across multiple, geographically dispersed teams, each representing a different discipline involved in the building process. The computer tools that send, receive and process data at the different geographical sites in order to accomplish design tasks are usually called agents in the collaborative design literature. These agents are implemented on machines with different architectures, written in different programming languages, and based on different conceptualizations of their respective domains, which include different assumptions about the way in which they interact with users. During collaboration, these users may interact with other users through their respective agents or directly through parallel communication mechanisms such as telephone or video. Major technical and conceptual issues that have to resolved if this type of set-up is to work are the following: •

the packaging and unpackaging of data reflecting heterogeneous machine architectures

•

the syntax and semantics of the language in which data are transmitted. This will require that the agents phrase and transmit their messages in terms of a shared vocabulary or with the use of translators, which in turn, reflect shared notions and concepts.

•

a communication mechanism that allows new agents to be added with ease and provides selective (content-based) routing; that is, a message posted by one agent (for example, about a recent design change) is only sent to agents that are interested in that type of change.

•

coordination between transmissions. For example, a request for a piece of information or a design change must not only be received, but answered in timely fashion by the appropriate agent, which may actually operate in a different time zone. Complexity is added to this exchange between agents if, at the same time, also the users interact with each other, with their own agent, and through these, with the other agents.

•

the storage and retrieval of design information that is of interest to more than one agent, including the management of different design versions.

A basic assumption underlying the ACL project is that the individual agents maintain their own internal representations and generate from these the views most appropriate to the tasks they execute. Most of the agents participating in the ACL project use an objectcentered representation of design information that is rich in content and highly structured; that is, relations between objects are of prime importance. These representations are con-

ACL Object Model Specification Language

2/10/95

Page 1

sistent with the vast majority of design representations that have been developed throughout computer science, the engineering disciplines, and architecture. Given such a distributed representation, the individual agents are responsible for capturing design updates or changes made by other agents in their own internal representation and for maintaining consistency with the other agents’ representations. This configuration reduces drastically the transaction and view problems that arise when agents share a common work space or global design representation. However, it also raises several issues, some of which are addressed in this document. It is first of all clear that each description of an object that is communicated between agents must contain the class to which the object belongs: an agent simply has to know if an object is a room, a column etc. Furthermore, an agent has to know the superclasses to which an object belongs. For example, if an agent wants to evaluate a path between two rooms and has received information about objects that belong to classes like ‘corridor’ and ‘stair’, it has to know that all of these belong to the superclass ‘public circulations space’ and can thus be used for public circulation. Furthermore, the class/superclass relations must be shared consistently between agents. If we share this information, we may as well share more general inheritance relations because this allows us to inherit attributes, which greatly reduces the amount of data that have to be passed along in object descriptions. The information received by any agent must be interpreted by this agent so that it is semantically consistent with the interpretation of the sending agent. Specifically, relationships between objects that are not implied by inheritance must be communicated between agents. For example, if an object a is a part of an object b and the geometric attributes of a are relative to a local origin established by b, the part of relationship cannot be recognized by an agent that did not create the objects and their relationships. A remote agent is then unable to locate the object correctly in its own coordinate space; that is, this part-of relationship has to be communicated explicitly. This may be advisable even for relationships that can, in principle, be rediscovered at remote sites by reasoning with communicated attribute values (like geometric coordinates) because it may reduce the computational loads on the agent at the remote site and, more importantly, be an important indicator of the intent of the agent who created the relationship. How else would we be able to distinguish between intended and accidental relationships? For example, more rooms are usually adjacent to each other on a floor than need be for functional reasons, and an agent trying to rearrange some of these rooms may need to know which of the existing adjacencies can be ignored. Furthermore, an understanding of the concepts and relationships needed at any specific site is evolving and never stable: the attributes of an object may change, or new objects or relationships may be introduced. This means that the translators between object repre-

Page 2

2/10/95

ACL Object Model Specification Language

sentations are also evolving, which creates the need to maintain semantic consistency between these evolving translators across agents at all times. This suggests that the maintenance of the translators should not be left to the individual sites and manual procedures, but be governed by a shared methodology that automates as much of the process as possible, including the automatic generation of parts of the translators, using algorithms that are known to produce correct results. This document addresses these issues and proposes a methodology that resolves them. We mention in passing some other problems that the ACL team has to face in the near future as a result of the selected communication approach without making suggestions about ways to resolve them: •

if a design elaboration or change made by one agent conflicts with the goals pursued or requirements maintained by another agent, these agents must negotiate about how to resolve the conflict

•

it is not clear at any time which parts of the distributed representations constitute the current version of the design or any other version; likewise, it is not immediately clear when a design is finished.

This document deals with the communication method for software objects and their relationships between agents and the syntax and semantics of the communication language. It provides a reasonably precise definition of an object model specification language and its intended semantics. The language syntax is specified in a BNF-style, which facilitates the development of translators for the language. For example, specifications written in this language can be translated to object database classes, C++ classes or to KIF sentences (first order logic). The grammar specification is presented along with examples of how it is intended to be used. In addition, this document describes a language binding mechanism to an object model of the proposed kind.

ACL Object Model Specification Language

2/10/95

Page 3

2

Agent Communication Method The following three general methods of integrating software agents have been described in the literature: cooperative distributed problem solving (CDPS)[1], common vocabulary (schema)[1], and schema translation. The ACL project team members have decided to use the schema translation method because they assume from the start that a common vocabulary cannot be generated for this project and is in any case not desirable. The team members decided furthermore to use an augmented Federation Architecture for this project, where a facilitator provides schema translation. A possible software architecture for this approach is shown in Figure 1 on page 5. The shaded boxes represent a local object model which captures the communication descriptions that need to be received and transmitted by an agent. These object models are based on a shared syntax and semantics of schema definition, but each model needs to represent only what input it needs (interests) and what outputs it can produce (capabilities). In addition, the object model provides the mechanisms needed to bind objects in the model to a programming language such as C++ or Lisp. An important advantage of this architecture is that it can be formally specified in a computable model and therefore formally verified. The object model contains both classes and instances. However, a language binding can be developed that would not store instances in the model: only classes are stored, while changes to instances are mapped directly to the bound language. This is a design decision the ACL team needs to make.1

1.

Page 4

If instances are not stored in the object model, more robust representations, such as rules, methods, or derived values, cannot be implemented in the future. My personal recommendation is to keep instances in the object model (JS).

2/10/95

ACL Object Model Specification Language

LAYOUT

ARCHAGT

CONFIG

SEED AGENT

AGENT

CONGEN

Facilitator

AGENT

ACE

BLAST

COSTING FIGURE 1. Example ACL Software Architecture

ACL Object Model Specification Language

2/10/95

Page 5

3

Definitions of Terms and Notation The following sections define the minimum set of concepts needed to communicate information between agents whose primary representations are object-centered. Collectively, these concepts define a schema, and analogies to database schemas and semantic networks of frames can easily be drawn. Figure 2 on page 9 presents these concepts in the OMT style of object notation section [25].

3.1

Agents An agent is defined as a software component that performs tasks on behalf of someone(thing) else. As a result, an agent must have the ability to specify its input and output as well as answer or perform requests made of it.

3.2

Schemas A schema is a collection of classes, domains, relationship types, and class categories. Each of these concepts is described below. It is assumed that each agent has its own schema, and that the facilitator is to provide the translation rules from one schema to another one.

3.3

Classes A class is defined as a collection of attributes, some of which may be inherited from a parent class (single inheritance). Attributes can be refined into several types, and the following three types are essential: value, relationship, and trigger; they are defined below. A class represents a concept that has a computable representation; it is the principal mechanism used in object-centered representations. For this specification, it is assumed that a class Object is defined from which all classes are derived.

3.4

Relationship Types Relationship types establish a behavior for a relationship and have, as a minimum, a name and an associated container (i.e. set, vector or bag, and link). Additional information can be specified in a relationship, for example, what should be done with objects in the container under copy and delete events. Another way of viewing relationship types is the kind of association they establish between objects (e.g. one-to-many, etc.).

3.5

Domains Domains establish a legitimate set of values in the same way as database domains do. Domains have a name and an associated set of axioms that constrain the allowable values. Without the notion of a domain, it is impossible to define, for example, a computable method for translating S.I. units into English units.

Page 6

2/10/95

ACL Object Model Specification Language

3.6

Class Categories Class categories allow classes to be ‘tagged’ with a special significance. For examples, certain classes that need to be communicated automatically to other agents can be tagged for this purpose. These tags are independent of the class hierarchy (i.e. they are not inherited from a parent class). OML supports three predefined class categories: INPUT, OUTPUT, and I/O. The INPUT category states that all attributes of the class generated from another agent and any local changes are not received from other agents. In INPUT classes, tagging an attribute as PRIVATE prevents broadcasting to other agents. The OUTPUT category states that all attributes are generated by the defining agent and changes will be broadcast to other agents. In OUTPUT classes, tagging an attribute as PRIVATE prevents broadcasting to other agents. The I/O category states that a class has both INPUT and OUTPUT attributes with OUTPUT as the default; In I/O classes, tagging an attribute as INPUT or PRIVATE prevents broadcasting to other agents. Specifying any other class category states that attributes are PRIVATE to the agent and are not broadcast or received.

3.7

Value Attributes Value attributes are similar to basic data types found in programming languages, but are much more abstract because they are not bound to a hardware architecture such as 32bit integers. Value attributes are defined by name/domain pairs, where a domain is a specification of a data type. Domains have associated simple axioms that are guaranteed to be enforced and are different from constraints that can be violated; axioms cannot be violated. Default values are inherited by an instance from a parent class upon instantiation. However, specifying a new default value in a subclass overrides the inherited default value. Instances can override any inherited value.

3.8

Relationships Relationship attributes specify “links” between objects. They have several important properties. First, relationships imply a containment relationship between two objects. The containment types supported by this language are defined via the relationship type defined in section 3.4. Additionally, relationships specify the types of objects that can go in the container. By implication, any subclass of the specified class can go in the container.

3.9

Triggers Triggers allow events to be captured and associated actions to be performed. At this time, a complete list of event types has not yet been identified, but will include addition and deletion of objects. A reference to the current instance of a class can be via the predefined variable named this.

ACL Object Model Specification Language

2/10/95

Page 7

3.10 Extended Modelling Capabilities The following sections describe extended modelling capabilities that are not mandatory, but can provide important complexity management capabilities. They are intended to address more sophisticated representational capabilities traditionally found in information modelling or knowledge representation frameworks. 3.10.1 Derived Values Derived values are values that are derived from other values and must therefore be recalculated automatically when these values change. For example, the area of a rectangular space is derived from its length and width and should be updated if its length and with are changed. A close analogy exists between derived attributes and cells in a spreadsheet. 3.10.2 Rules (Should we expound on this?) 3.10.3 Methods (Should we expound on this?) 3.10.4 Constraints (Should we expound on this?)

Page 8

2/10/95

ACL Object Model Specification Language

SCHEMA

contains-domains

addDomain addClass addClassCategory addRelationshipType

DOMAIN name validValues

contains-categories

contains-subclasses

contains-classes

CLASS name

hasa-category

CLASS_CATEGORY

addValue addTrigger addRelationship makeInstance inherit

name

hasa-attribute

contains-relationshiptypes

RELATIONSHIPTYPE

META_ATTRIBUTE

name container type

name

hasa-class hasa-domain hasa-relationshiptype META_RELATION

META_TRIGGER

META_VALUE

makeInstance

action expression

defaultValues makeInstance

FIGURE 2. Object Model in OMT Notation

ACL Object Model Specification Language

2/10/95

Page 9

4

BNF Grammar of the Object Specification Language Items which are italicized are grammar element names. Items in bold type are keywords in the language. Items enclosed in single quotes are literal characters of the language. Alternative right hand side clauses are separated by a vertical bar ( | ). Any grammar clause name (for example ) which ends with “-name” is intended to represent a character string for the name of an object. Grammar elements enclosed within brackets (i.e. [ ] ) are optional elements within the clause.

4.1

Base Data Type Base data types define the underlying representation of a value. The notation described here is borrowed from SQL.

: number ‘(‘ [ ‘,’ ] ‘)’ | char ‘(‘ ‘)’ | date

4.2

Aggregation An aggregation defines constraints on a collection of base data type values. Matrix and interval aggregations are defined for real numbers.

: RANGE | SET | ONEOF | CONST | SINGLE | MANY | EXPR | MATRIX | INTERVAL | VECTOR | TUPLE ‘(‘ ‘)’

4.3

Element List

: | ‘,’ :

Page 10

2/10/95

ACL Object Model Specification Language

4.4

Domain A domain is defined by a name and an aggregation. By naming a set of values, other systems (e.g. a facilitator) can easily map values from one to another.

: DECLARE DOMAIN ‘;’

4.5

Subdomain Subdomains refine a domain by adding additional constraints on the parent domain. When a subdomain is declared, no relationship with the parent domain is maintained.

: DECLARE SUBDOMAIN [ ] ‘;’ : ONEOF | /* parent must be ONEOF */ SET | /* parent must be SET or MANY */ RANGE /* low and high literal must be in the parent */

4.6

Class A class defines a collection of attributes some of which can be inherited from a parent class. A predefined class named Object always exists.

: DECLARE CLASS SUBCLASS OF ‘(‘ [ ] ‘)’ ‘;’

4.7

Forward Class Forward classes are used to break circular references of classes.

: DECLARE FORWARD CLASS ‘;’

4.8

Attribute List

: | ‘,’

4.9

Attribute

: [ ] [ DYNAMIC ] VALUE [ ] | RELATION | TRIGGER ON ‘’’ ‘’’

ACL Object Model Specification Language

2/10/95

Page 11

: INPUT | OUTPUT | PRIVATE

4.10 Trigger Action Triggers can be specified for the addition/deletion of a frame instance to/from an instance network. : ADD | DELETE

4.11 Literal List : | ‘,’

4.12 Literal : | | | | | NIL | MAXINT | MAXFLOAT

4.13 Argument Arguments are automatically numbered by the runtime system starting at 1. : ‘$’

4.14 Variable : ‘$’

4.15 Relationship Type : DECLARE RELATIONTYPE ’;’

4.16 Container Type Container types specify the cardinality and duplication constraints on a relationship. Link defines that a single value can exist in the container. Vector is an ordered list. Set is an ordered list with no duplications.

1.

Page 12

The issue of expressions and methods can be added here if the group sees the benefit. I believe that an object model cannot be specified without this type of capability. Some behavior must be specified to be complete.

2/10/95

ACL Object Model Specification Language

: LINK| VECTOR| SET

4.17 Expression : ‘(‘ ‘)’ | ‘+’ | ‘-’ | ‘*’ | ‘/’ | ‘^’ | ‘;’ | | this ‘:’ [ ] | this ’:’ [ ] ‘:=’ | ‘:’ | ‘:’ | ‘:’ ‘:=’ | ‘:’ | |

4.18 Index : | : | : | : ‘{‘ ‘}’ | ‘[‘ ‘]’

4.19 Relation Index : ‘[‘ [ ] ‘]’

ACL Object Model Specification Language

2/10/95

Page 13

4.20 Structured Value : | : ‘{‘ ‘}’ | ‘[‘ ‘]’ | ‘{‘ ‘}’ | ‘[‘ ‘]’ : StructuredValue | StructuredValueList StructuredValue : SimpleValue| SimpleValueList SimpleValue : | | | NIL |

4.21 Arg List : ‘(‘ [ ] ‘)’

4.22 Conditional Expression : if ‘(‘ ‘)’ then else endif

4.23 Condition : and | or | ‘(‘ ‘)’ | not ‘(‘ ‘)’ | |

4.24 Relative Operator : ‘>’ | ‘ ‘myself->setHeight(value)’, VALUE material materialMap ‘material’, RELATION footing-container ADD => ‘myself->footings->add(theInstance);’ ADD ‘myself->footings->remove(theInstance)’ DELETE