Manuscript: ROAD965.

TEX

COMMA: its in°uence on OPEN

B. Henderson-Sellers
Centre for Object Technology Applications and Research
Swinburne University of Technology, Melbourne, Australia

D. Firesmith

Knowledge Systems Corporation, Cary, NC, USA

I.M. Graham

SBC Warburg, London

Printed: September 28, 1998

Deadline: Dec 9

[JOOP (Report on Object Analysis and Design) March/April 1997]

the COMMA (Common Object Methodology Metamodel Architecture) project. Originally,

this was interesting in itself as a way of facilitating convergence between the then existing

several dozen OOAD methodologies. But as time continued it became clear that if those

of us most involved in the COMMA work really believed in convergence, then it was

hypocritical to, at the same time, continue to \market" our own methodological approaches

to systems design.

Over the last two years, we have been working collaboratively, assisted by a large

number of international colleagues, as a single team to create the OPEN methodology.

Originally, a merger of SOMA and MOSES, the OPEN project (OPEN stands for Object-

oriented Process, Environment and Notation) has slowly gained shape and international

credibility. The work undertaken in COMMA1 has also been adopted and extended to

become the OPEN metamodel which, together with the OPEN notation, COMN (Common

Object Modelling Notation), is known as the OPEN Modelling Language, or simply OML

(Figure 1). OML is at the same level of detail as Rational's UML; whilst OPEN, the

method, comprises much more than UML. In other words, the COMMA results have

facilitated the direct merger of SOMA, MOSES and Firesmith. We also anticipate that

further mergers into OPEN will occur in 1997. Thus, one main goal of COMMA has been

realized: the reduction in the available choice of OO methodologies for industry users.

As well as adopting the COMMA static architecture metamodel (Figure 2), we also

needed to extend it to o®er complete coverage. In particular we needed to construct the

OPEN metamodel for relationships, dynamics (STD), task scripts/use cases and the overall

metalevel architecture of these various views. Here we describe the components of OPEN's

metamodel not described in the COMMA metamodel of Henderson-Sellers and Firesmith1 .

1
OPEN's Metamodel for Relationships

De¯nition

A semantically useful metamodel for relationships can be developed in terms of

whether the relationships are de¯nitional or referential. A third type, for the dynamic

model, is the transitional relationship (Figure 3). A de¯nitional relationship creates the

de¯nition of a new entity from an existing one e.g. an object is an instance of an (exist-

ing) object class. In contrast, relationships such as associations and aggregations merely

connect together existing nodes i.e. they provide a reference between nodes. Transitional

relationships describe transitions between states in STDs (see below).

The two relationships of \conforms to" and \is an instance of" are de¯nitional re-

lationships between nodes of di®erent metatypes and can loosely be referred to as \is-a"

relationships. De¯nitional relationships for nodes of the same metatype re°ect the various

\°avours" of what is often called inheritance. These are specialization inheritance (is a kind

of), speci¯cation inheritance (type conformance) and implementation inheritance. Here we

group the latter two together as inheritance whereas the ¯rst (specialization inheritance)

is far removed from the coding level and really pertains to knowledge representation |

here labelled for clarity as \a kind of".

On the second branch of the tree (referential) di®erent metatypes are involved for the

\implements" relationship whereas associations and aggregations are between nodes of the

same metatype. Since linkages are instances of associations, this gives four metaclasses, as

indicated in Figure 3.

2
 On the third branch are transitional relationships which describe various forms of

state transitions (exceptional, normal, leaving and remaining | see discussion of Figure 4

below).

Metamodel

Figure 3 describes the metalevel generalization hierarchy for relationships based on

this simple premise. In addition, we can discriminate, in both branches of this hierarchy,

between relationships which connect together nodes of the same metatype and those which

connect together nodes of a di®erent metatype.

Rationale

A further advantage of this classi¯cation is that a systematic use of symbols in any

notation which supports this hierarchy can be developed. For example, COMN indicates

de¯nitional relationships with a double line, referential and transitional with a single line.

Di®erent metatypes are indicated by a dotted line and similar metatypes with a solid linea .

The two types of inheritance are indicated clearly by white box and black box symbols

and aggregation and containment by visually explicit symbols.

Comparison with UML

Relationships are de¯ned (V0.8 page 8) as either Generalization or Association. Gen-

eralization implies \is-a-kind-of" | although this is clearly not used in the metamodel

graphical description itself, despite the use of UML notation for generalization. UML also

supports a discriminator (as does OML) an an isAnd °ag. In UML, Association subsumes
a
Whilst this is strictly unnecessary since the symbols for the nodes of di®erent
metatypes are distinct, on semiotic grounds it was felt valuable to \duplicate" this in-
formation in the arrow style.

3
usage, links, association, aggregation etc. of Booch, of OMT and of OOSE. Roles (from

OMT) are retained in UML | but eschewed in OML. Role here means \simply an end

of an association where it attaches to a class" (V0.8 page 9). This is very di®erent to the

notion of r^ole modelling in OOram | included in OML but excluded from consideration

in UML.

OPEN's Dynamic Metamodel

De¯nition

One (or sometimes several) dynamic models, in the form of a state transition diagram,

may be attached to a class. Usually STDs are used to express state transitions pertinent to

instances of that class, but sometimes they are applied to the class itself. State is de¯ned

loosely as the agglomeration of the values of the links and attributes at any stated time.

Changes in state occur as a result of incoming messages which are equated to EVENTs

in the STD. An event causes a TRANSITION between states; although generally there is

also some condition attached to this transition. For example, a stack object undergoes a

transition from a state of being \not full" to a state of being \full" when a message to add

an element is received conditional upon the current stack contents being one less than the

maximum. If this condition (or guard) is not met, then incoming messages will have no

e®ect on the overall state (as de¯ned above) of the stack.

Metamodel

Figure 4 shows OPEN's dynamic metamodel. Each OBJECT has a STATE MA-

CHINE which is an aggregate of a number of STATEs and TRANSITIONs. A TRANSI-

TION is a change between two STATEs. The occurrence of the transition is caused by a

4
TRIGGER (a.k.a. EVENT). A trigger is often equated with a message, but may equally

be a resulting exception. The ¯ring of the transition is controlled by a GUARD.

The metaclasses STATE and TRANSITION have, in OPEN, many metasubclasses.

Two important subclasses are STOP STATE and START STATE. Important transition

subtypes are NORMAL/EXCEPTIONAL and LEAVING/REMAINING. Note that unlike

OMT we do not have an ACTIVITY class associated with STATE. An Activity is merely

something that occurs continuously throughout the state. It is therefore a manifestation of

the STATE itself and does not need its own metaclass i.e. it is not an important concept,

merely another view/interpretation of what being in a given state actually means.

An OPERATION (sometimes known as ACTION) may be associated with a STATE.

Once a transition is triggered, EXIT OPERATIONs may be required before the actual

transition is possible. Similarly, before the object is stabilised in the next state, EN-

TRY OPERATION(s) may be required. These could also be visualized as post- and

pre-conditions (respectively) on a given state.

Other elements of the OPEN dynamic metamodel are elaborated graphically in Figure

4.

Rationale

Dynamic behaviour, although it can be inferred from the general semantic nets, is

often preferably shown explicitly. All OO methodologies use some form of state chart or

petri net. Many use Harel directly; OPEN uses Harel as interpreted by Embley, Kurtz and

Wood¯eld and then further elaborated by Firesmith.

Comparison with UML

5
 UML's metamodel, shown in Figure 5, shows STATEs and TRANSITIONS with

EVENTs (a.k.a. messages) | OML uses the word trigger. They add the notion of

a SENDCLAUSE (which is the \e®ect of sending an event to another object") and of

ACTION/ACTIVITY. It is not clear from the V0.8 documentation on the semantics of

ACTION/ACTIVITY. In the metamodel it is clear that these are meant to be synonyms.

However, in the notation part of the documentation, they are de¯ned di®erently. It is said

that an Activity cannot be attached to a Transition yet the metamodel clearly permits

this. The notion of an Activity is something that occurs whilst an object is in a particular

state. This is the meaning from OMT and in UML it should clearly be associated with

STATE not with TRANSITION (Figure 6 re°ects these di®erences). An Event, on the

other hand, occurs at a point in time and causes a state change. Message and trigger would

thus appear to be appropriate synonyms for UML's EVENT metaclass. The coupling of

OPERATIONs (as types of ACTIONs) with STATE and not with TRANSITION has a

close parallel in the OPEN metamodel of Figure 4. Also the CLASS STATE MODEL is

much akin to the OML's STATE MACHINE metaclass.

OPEN's Task Script/Use Case Metamodel

De¯nition

A task script or use case describes the functionality as seen by a typical user of the

system. In some expositions a use case is a single concept, in others a series of actions that

may be stereotypical of the way a user interacts with a system. Basically a use case/task

script model consists of a number of actors and a number of use cases.

6
 An additional clari¯cation is that scenarios are instances of use cases and an essential

use case is a supertype of a use case.

Metamodel

Figure 7 shows the most basic metamodel for use cases. USE CASE MODEL is an

aggregate of ACTOR and USE CASE; which itself participates in a short type hierarchy.

Rationale

Use cases are basically non object-oriented. They should therefore be used with care.

Certainly they provide a link between functionality and classes. However, using them

primarily to drive the whole design process is likely to lead to a functionality-driven solu-

tion which has little object-orientedness about it. Indeed, an associated tool, SOMATiK,

generates use cases.

Comparison with UML

The UML use case model is surprisingly dissimilar in that \a use case contains a set

of scenarios" i.e. it is an aggregation of scenarios (as depicted in the metamodel). This

is in contrast to the statement made publicly in October 1994 by Ivar Jacobson that \a

scenario is an instance of a use case".

A further di®erence is that the authors of UML publicly state that the OO process

should be primarily use-case-driven.

Summary

Metamodelling has provided one tool to facilitate the convergence between OO

methodologies. Building on top of the COMMA metamodel, the OPEN methodology

7
provides in addition a metamodel for relationships and for the dynamic and use case as-

pects of an object model. These metamodels, together with the COMN notation, comprise

the OPEN Modelling Language (OML).

References

[1.] Henderson-Sellers, B. and Firesmith, D., 1997, COMMA: proposed core model, J.

Obj.-Oriented Prog. (ROAD), in press (January)

8
Figure Legends

Figure 1 OML consists of a notation (COMN) and extensions to the COMMA metamodel.

Figure 2 The proposed COMMA core metamodel (after Henderson-Sellers and Firesmith,

1997).

Figure 3 Metalevel hierarchy for relationship types.

Figure 4 OPEN's dynamic metamodel (main elements)

Figure 5 UML's dynamic metamodel (main elements) | as portrayed by graphics in the

metamodelling document.

Figure 6 UML's dynamic metamodel (main elements) | as inferred from textual descrip-

tions.

Figure 7 OPEN's metamodel for use cases/task scripts