Information Systems Frontiers 4:4, 379391, 2002C 2002 Kluwer Academic Publishers. Manufactured in The Netherlands.

A Theory of Object-Oriented DesignAmnon H. EdenCenter for Inquiry, Amherst, NY, USAE-mail: eden@acm.org

Abstract. Progress was made in the understanding of object-oriented (O-O) design through the introduction of patterns ofdesign and architecture. Few works, however, offer methods ofprecise specification for O-O design.

This article provides a well-defined ontology and an under-lying framework for the formal specification of O-O design:(1) We observe key design motifs in O-O design and archi-tectures. (2) We provide a computational model in mathemat-ical logic suitable for the discussion in O-O design. (3) Weuse our conceptual toolkit to analyze and compare proposedformalisms.

Key Words. software design theory, software architecture, objectoriented programming, formal foundations, design patterns

1. Introduction

Architectural specifications provide software with aunifying or coherent form or structure (Perry andWolf, 1992). Coherence is most effectively achievedthrough formal manifestations, allowing for unambigu-ous and verifiable representation of the architecturalspecifications.

Various formalisms and Architecture DescriptionLanguages (ADLs) (Medvidovic and Taylor, 1997)were proposed for this purpose, each of which de-rives from an established formal theory. For example,Allen and Garlan extend CSP (Hoare, 1985) in WRIGHT(Allen and Garlan, 1997); Dean and Cordy (1995) usetyped, directed multigraphs; and Abowd, Allen, andGarlan (1993) chose Z (Spivey, 1989) as the underly-ing theory. Other formalisms rely on Statecharts (Harel,1987) and Petri Nets (Petri, 1962).

In contrast, techniques idiosyncratic to the object-oriented programming (OOP) paradigm, such as in-heritance and dynamic binding (Craig, 1999), induceregularities of a unique nature. Consequently, O-Osystems deviate considerably from other systems intheir architectures. We would expect the architec-

tural specifications of O-O systems to reflect theiridiosyncrasies.

Unfortunately, architectural formalisms largely ig-nore the O-O idiosyncrasies. Few works (Section 4)recognized the elementary building blocks of designand architecture patterns. As a result of this oversight,any attempt to use formalisms for the specification ofO-O architectures is destined to neglect key regularitiesin their organization.

Only naturally, coherent specifications warrantthe recognition of the underlying abstractions of theparadigm (Odenthal and Quibeldey-Cirkel, 1997). Thisis equally true for O-O programs. Hence, we observeprimitives (building blocks) in O-O design, such asthe inheritance class hierarchies (Definition IV) andclans (Definition V), which reflect the mechanisms thatunderlie the paradigms idiosyncrasies (inheritanceand dynamic binding, respectively.)

1.1. PatternsMore than any other form of documentation, softwarepatterns (Coplien and Schmidt, 1995; Vlissides,Coplien, and Kerth, 1996; Martin, Riehle andBuschmann, 1997; Schmidt et al., 2000), in particulardesign patterns, proved effective in capturing recurringmotifs in O-O software architecture. Each article ofthese catalogues addresses a distinct design pattern,documented in a structured format, and distinguishedby a name which carries its intent. Patterns captureabstractions that facilitate communicating problemsand solutions. It is safe to argue that the best insightinto the regularities of O-O design is provided by thepatterns literature.

Yet the genre suffers from a few shortcomings, mostprominent appear to be the following:

1. Ambiguity. The informal and ultimately fuzzydescriptions puzzle patterns users and cause

379

380 Eden

substantial confusion. Even the very pattern writersdemonstrate disagreement over their true mean-ing (e.g., pattern discussion1 and gang-of-four-patterns2).

Debates that frequent patterns users include thefollowing:

Instance-of (Definition III): Whether a particularimplementation conforms to a certain pattern;

Refinement (Definition VII): Whether one patternis a special case of another.

2. Unstructured knowledge. With the growth in thenumber of patterns published, the accumulation ofinformation is evolving into an unstructured masswhich lacks effective means of indexing.

Clearly, these two problems result from the useof imprecise means of specification, such as verbaldescriptions, class diagrams, and concrete exam-ples. This problem can be alleviated by providingformal specifications, which may allow for unam-biguous specifications, enable reasoning about therelationships between patterns (e.g., refinement), andpromote the structuring of the rapidly growing bodyof patterns.

1.2. IntentThis article introduces the following contributions:

1. Define an ontology that serves as a frame of refer-ence for the discussion in the essential concepts ofO-O design. In particular:

Observe the building blocks of O-O design,namely, a small set of rudimentary elements thatcan be used to represent effectively the designof many programs;

Provide precise definitions for intuitive terms usedwith reference to O-O patterns, such as pattern ais a special case of pattern b.

2. Analyse declarative formalisms for the specificationof O-O design patterns. In particular:

Reconcile formalisms proposed by translatingsample expressions to a unifying framework;

Provide criteria for assessing the properties ofprospective specification languages (e.g., expres-siveness and completeness).

1.2.1. A terminological note. Our use of the termpattern diverges from its use within the patterns com-munity. Inspired by the work of Christopher Alexander(Alexander et al., 1977, Alexander, 1979), a patternis a prescription for solving a category of problems ina specific manner. This prescription is intended for thedissemination of specialized knowledge and to createan instrumental vocabulary.

At the same time, many use pattern (particularlywith reference to design patterns) as a shorthand fora specific segment of the respective article, which fo-cuses primarily is the architectural abstraction mani-fested in the solution part of the pattern (also microar-chitecture, lattice (Eden, 1998), and leitmotif (Eden,2000)). We adhere to the second practice.

1.2.2. A methodological note. We employ symboliclogic as means for precise specification and reasoning.Yet, as in other scientific disciplines where the subjectof the statements made (verbal descriptions of patterns)is informal, there is no rigorous way to prove the cor-rectness of some of the statements we make. Theseclaims can only be treated as approximations for somenatural phenomena (Popper, 1969). As in standardscientific practice, we may only demonstrate evidencethat support our hypotheses.

2. Setting the Scene

In this section, we provide a foundation for a formaldiscourse in O-O design.

2.1. SemanticsProgrammers are aware of the conceptual model thataccompanies every O-O program: A universe inhabitedby classes, operations, attributes, and relations amongthem. Some of these relations are explicitly expressedas syntactic, built-in constructions of some program-ming languages, such as inheritance, member-of, andso forth.

There is a lot to be gained by making this conceptualstage into an explicit logic structure. Many unsub-stantiated claims, such as this pattern is just a specialcase of another, become straightforward facts in thisstructure.

We propose to render this structure explicit exactlylike any other mathematical structure, such as algebraicband, boolean algebra, or geometry of points and lines.

A Theory of Object-Oriented Design 381

The crux of our contribution is, to start with, in recog-nising the participants, their essential collaborations,and the suitable way of manifesting them. This practiceis not entirely unlike distinguishing the participants ingeometric discoursepoints and lines, and the primaryrelationspoint x is in line y. Finally, we consider thestaging. In the geometric context, for instance, weask whether the relation line x is parallel to line y is el-ementary, or whether it is deduced from other relations.Similarly we ask whether lines are atomic entities, orperhaps should be represented as sets of points, namely,as more elaborated constructs.

The framework we propose incorporates classes andmethods as its atomic entities and relations such asclass d inherit from class b, method f is defined inclass c, and method f creates instances of class c, asthe ground relations amongst them.

In our discussion, a program3 is abstracted to asimplified representation in mathematical logic calleddesign model (Definition 1). Example 1 demonstrateshow a simple Java program translates to a design model.Extract 1 gives the class diagram of the same program.

In comparison, object notations (e.g., UML (Booch,Jacobson, and Rumbaugh, 1999), OMT (Rumbaughet al., 1991), Booch (1994), OPEN (Firesmith, Graham,and Henderson-Sellers, 1998)), more specifically classdiagrams, were used in the specification of designpatterns. Class diagrams and other diagrams in ob-ject notations, however, are clearly inadequate repre-sentation as they only incorporate constant symbols(such as Decorator and Decorator::Draw()in Extract 1.) Architectural specification, however,specify a set of programs indirectly through their

Extract 1. OMT diagram of a segment of the DECORATOR (Gammaet al., 1994) pattern.

properties (Perry and Wolf, 1992). The absence of vari-able symbols is a one of the major shortcomings of classdiagrams. Furthermore, some information about thepattern can only be conveyed using informal notes.

In the framework we propose, both methods andclasses are represented as primitive elements. Hence,the Design Model (Definition I) of a program consistsonly of ground entities and of ground relations,just as a structure in mathematical logic.

For example, the association between classDecorator and methodDraw therein is representedusing the DefinedIn relation as follows:

DefinedIn (Draw,Decorator) (1)

Example 1. Program vs. its model.

abstract class Decorator {abstract void Draw();

}class BorderDecoratorextends Decorator

{void Draw() {

Decorator.Draw(); //...}int BorderWidth;

}

The model of this program consists of the following:Ground Entities (participants)

Decorator, BorderDecorator, int oftype class, and BorderDecorator.Draw,Decorator.Draw of type method.

Relations (collaborations)DefinedIn (Decorator.Draw,Decorator)DefinedIn (BorderDecorator.Draw,BorderDecorator)

Inherit (BorderDecorator,Decorator)Reference (BorderDecorator,int)Invoke (BorderDecorator.Draw,Decorator.Draw)

Abstract (Decorator)Abstract (Decorator.Draw)ReturnType (Decorator.Draw,void)ReturnType (BorderDecorator.Draw,void)

Similarly, the relation Reference represents the asso-ciation between class BorderDecorator and thetype int of its attribute as follows:

Reference (BorderDecorator,int) (2)

382 Eden

The simplification of programs into design modelsis an essential step towards the abstraction that is nec-essary at the architectural level.

In the following definition, the term object languagerefers to the language used for writing source code.For instance, the object language used in Example 1 isJavaTM (Gosling, Joy, and Bracha, 2000).

Definition 1 (Design model). Let us denote L as theobject language, T = {F,C} as a set of participanttypes, and R = {Inherit, Abstract, . . .} as a set of re-lation symbols. We assume a mapping function Msuch that for each program p in L, participantsM(p)is a set of ground entities, each of a type in T, andcollaborationsM(p) is a set of n-tuples of entities inparticipantsM(p), such that each tuple belongs to arelation in R.

We define M =M(p) as the design model of paccording to M (in short: the model of p) as thestructure arising from the ground entities in parti-cipantsM(p) and the relations in collaborationsM(p).

Further discussion in composition of the sets T andR appears in Section 3.

Definition 1 gives rise to a well-defined universe ofdesign models, which we denoteP . Being abstractionsrather than actual programs, an unbounded number ofprograms are effectively treated as equivalent. Thus,from this point in this article, we disregard programsin their original sense and use the term with referenceto their abstraction. As we do not refer directly to pro-grams in their original representation, we do not see adifficulty in using this alias.

2.1.1. Static vs. dynamic models. Regardless thechoice of object language, static and dynamic con-ceptual models stand at the heart of the sys-tems design and they exist throughout its lifecycle.Similarly, design patterns determine both structural(namely, static) and behavioural (namely, dynamic)properties.

We focus our discussion on the static model forvarious reasons. The static components and their cor-relations are the ingredients of the systems struc-ture and serve as a scaffold that delineates itsbehaviour. Static properties are far easier to specify,prove or refute, and most importantly, to comprehend.If indeed the primary reason for the continuous soft-ware crisis (Gibbs, 1994) is lack of abstraction, then

there is enough room to improve the structural pictureof software systems.

Also, the elements of O-O architecture we observed(listed in Section 3) support the view that, predomi-nantly, design patterns characterize static attributes ofthis universe. Many of the patterns that appear dy-namic (behavioural patterns, as characterized inGamma et al. (1994)) actually describe a configura-tion in the static model. By studying leitmotifs of thebehavioural patterns, one recognizes that, essentially,the behaviour manifested in these abstractions can beexpressed through static relations. The examples pro-vided in Section 4 illustrate this observation. Additionalexamples are provided in Eden (2000).

Finally, OOP is distinguished by inheritance, an en-tirely static abstraction mechanism. This is true notonly for statically, strongly typed languages, but alsofor dynamically typed OOP languages. The graph ofinheritance relations is predominant in the character-ization of the topology of O-O libraries. Moreover,the organisation of classes, methods, and their re-lations, is the stage on which the dynamic mani-festation of the program takes place, where classesmaterialise as objects, and methods take the form ofmessages.

2.2. SyntaxWe use higher order predicate calculus in our dis-cussion. Constant names appear in fixed type-face and variables in italics. We designate the do-main of methods by F, and the domain of classes byC. Given a set S, we use P(S) to denote the power setof S.

Variables should not be confused with constants;thus,

Draw F (3)Factories: P(C) (4)

expression (3) indicates that the symbol Drawrepresents a specific method (function member),while (4) declares a variable that ranges over sets ofclasses.

As established by the principle of least constraint(Perry and Wolf, 1992), architectural specificationsshould not constrain the implementations unnecessar-ily. This is a desired property of both design patternsand architectural styles, as each specifies a set of de-sired properties rather that detailing a concrete solution(i.e., a program.)

A Theory of Object-Oriented Design 383

We conclude that O-O architectural specificationscan be expressed as constraints on properties of par-ticipants and relations (Definition 1) and formulatedin higher-order logic. This conclusion leads to thefollowing definition:

Definition 2 (Pattern). A pattern is defined as aformula (x1, . . . , xn), where x1, . . . , xn are free vari-ables in . We say that x1, . . . , xn are the participants,and that the relations in are the collaborations, thatthe pattern dictates.

Naturally, Definition 2 is too broad. It offers, how-ever, a baseline for a formal discussion in specificationsof patterns in different formal languages. In conjunc-tion with Definition 1, it allows for the formal defini-tion of other useful intuitions, such as an instance ofa pattern (Definition 3) and refinement of a pattern(Definition 7).

2.3. ReasoningA significant advantage to the use of a formal frame-work is in the ability to apply rigorous inference rulesso as to allow reasoning with the specifications andderive conclusions on their properties.

We can demonstrate simple reasoning by using vari-ables to rephrase the intuitive distinction between thepattern , an instance of (an implementation of ),and a program that contains an instance of .

The following definition formulates the distinctionbetween a pattern and an instance of a pattern:

Definition 3 (Instance of a pattern). Let (x1, . . . , xn)be a pattern. LetM designate a model containing then-tuple of ground entities: (a1, . . . , an). Let A be theconsistent assignment of a1, . . . , an to the free variablesx1, . . . , xn in . If the result of assignment A in istrue inM then we say that (a1, . . . , an) is an instanceof in the context of A (alsoM contains an instanceof ).

Similarly, we say that a modelM is satisfies ifthere exists some assignment A such that M is aninstance of in the context of A.

To illustrates Definition 2, consider the followingtrivial pattern:

Invoke ( f1, f2) (5)It is easy to show that the model in Example 1 sat-

isfies (5). To prove this, consider the assignment of

BorderDecorator.Draw to f1 and of Deco-rator.Draw to f2. If we apply this assignment, weget:

Invoke (BorderDecorator.Draw,Decorator.Draw) (6)

which is true in Example 1.

Corollary 1. From Definition 1 and Definition 2 weconclude that each pattern (regardless the specificationlanguage used) specifies a subset of P .

3. The Building Blocksof O-O ArchitectureIn this section, we observe the elements of O-O archi-tecture, which we refer to as rudiments, and illustratedthem using examples from (Gamma et al., 1994). Thediscussion is broken down along the distinction be-tween participants and collaborations as the elementsof patterns (Gamma et al., 1994).

3.1. ParticipantsThis section is dedicated to abstractions that representelementary and composite participants.

3.1.1. Rudiment A: Ground entities. The predomi-nant agents in O-O software, as well as the partici-pants of every single pattern in Gamma et al. (1994),are classes, methods, and objects. Since we focus instatic specifications, we will only discuss the first two.Formula (7) illustrates a declaration of the participantsin Example 1:

Decorator,BorderDecorator,intCDecorator.Draw,BorderDecorator.Draw F (7)

We regard classes and methods as atomic (prim-itive) elements, or ground entities. Their properties,e.g., the arguments of a method, data members of aclass, and so forth, are expressed through relations(Rudiment E).

3.1.2. Rudiment B: Higher-order entities. Mostoften, participants appear in unbounded sets consistingof elements of a uniform type, namely, either classes ormethods. Uniform sets of participants playing a specific

384 Eden

role (e.g., creators, visitors, products, etc.) areomnipresent in design patterns. Numerous examplesappear in every pattern.

Higher order sets (i.e., uniform sets of uniformsets) are also omnipresent. Higher order sets are alsouniform in the sense that their elements are of uniformtype and order. Consider, for example, the participantsin the ABSTRACT FACTORY pattern: products is a setof sets of classes, while factory methods is a set ofsets of methods. Similarly, observe the set of setsof visit (elementi ) methods of the VISITOR pattern.Formally:

Definition 4 (Higher-dimension entity).(i) A ground entity is said to have dimension 0;

(ii) A set that comprises classes (methods) of di-mension d 1 is called a a class (method) ofdimension d;

For example, we can refer to the set of Visitor classesas a class of dimension 1, and to the set of Visit methodsas a method of dimension 2.

3.1.3. Rudiment C: Clans. Dynamic binding, themechanism for the dynamic selection of a method, isfundamental to OOP. It is enabled by a combination ofinheritance and shared signatures. A clan is the staticmanifestation of the family of methods that share aparticular dispatch table. Formally:

Definition 5 (Clan). W say that method F is a clan inclass C iff the following conditions hold:

(i) All methods in F share the same signature;(ii) Each method in F is defined in a different class

in C .

A formulation of Definition 5 in predicate calculus,which uses the relations SameSignature and DefinedIncan be found in Eden (2000). Observe that a clan isalways defined with relation to a given set of classes,not as an isolated property.

Clans are ubiquitous and occur wherever dy-namic binding is used. The following are examplesof clans: the set of visit (elementi ) methods of theVISITOR pattern; the set of create (producti ) of theABSTRACT FACTORY; the set of the update methods ofthe OBSERVER pattern; the set of ConcreteAlgorithmsof the STRATEGY pattern; and so forth. In fact, everytime inheritance is used there is a very high chance thatdynamic binding is also present.

Observe another common construction: A set ofclans T such that every clan F T is defined in classC . This abstraction is termed tribe and it can be foundin almost every pattern (Eden, 2000).

3.1.4. Rudiment D: Hierarchies. Inheritance is alsofundamental to OOP, and inheritance class hierarchiesoccur in every O-O program. Most dominant, how-ever, is a particular construction that consists of asingle inheritance hierarchy. A 1-dimensional class istermed hierarchy if it contains an abstract (root) classfrom which all other ground classes inherit (possiblyindirectly).

In the following definition, R+ designates thetransitive closure of (one or more) occurrences of therelationR.

Definition 6 (Hierarchy). A 1-dimension class h is ahierarchy if the following condition holds:

root h Abstract (root) cls h Inherit+(cls, root)) (8)

Observe also the occurrences of sets of hierarchies,e.g., the set of product hierarchies in the ABSTRACTFACTORY (Extract 4).

Almost every pattern in Gamma et al. (1994) con-tains one or more hierarchies. For example: Theset of concrete-observers with the abstract observer(OBSERVER pattern); the set of concrete-productswith the abstract product (FACTORY METHOD pat-tern); and the set concrete-commands with the ab-stract Command (COMMAND pattern). Henceforth, theterm hierarchy is used only in the sense definedabove.

3.2. CollaborationsIn this section, we observe key regularities in the cor-relations among the patterns participants.

3.2.1. Rudiment E: Ground Relations. We identify asmall group of ground relations which, as illustrated inEden, Hirshfeld, and Yehudai (1999), is sufficient to ac-count for most types of collaborations that occur amongground entities in the GoF patterns. Principal relationsare listed in Table 1. Example 1 illustrated how groundrelations model correlations among the elements of aprogram.

A Theory of Object-Oriented Design 385

Table 1. Intuitive interpretations for ground relations

Abstract: FCIndicates whether the entity is abstract (In Eiffel: deferred)

Assign: FCCIndicates that a reference from one class to the other is assignedwithin the body of a given method.

Create: FCIndicates that the body of the method contains an expressionwhose evaluation creates an instance of the class. Suchexpressions include, for example:

new int number; (Java)int numbers[2]; (C++)if (string("A") == s) (C++)!INTEGER! num.make; (Eiffel)

DefinedIn: FCIndicates that the method is a member in the class

Forward: FFForward ( f, g) means that f invokes g with the additional requi-rement that the actual arguments in the invocation expressionare the formal arguments of f . Such a method in C++ willlook as follows:

void TCPConnection::ActiveOpen(int t){ state->ActiveOpen(t); }

Invoke: FFInvoke ( f, g) indicates that f may invoke g, namely, thatwithin the body of method f there is an expression whose eva-luation invokes g. Note that we ignore the control flow

Inherit: CCIndicates that the class on the left inherits from the class onthe right

Reference [-To-Many]: CCIndicates that class on the left defines an attribute [multipleattributes] whose type is specified by the class on the right

ReturnType: FCIndicates the return type of a method

SameSignature: FFIndicates that the two functions have the same name and formalarguments.

3.2.2. Rudiment F: Bijections. Consider the follow-ing quote from the specification of the PROXY (Gammaet al., 1994, p. 270): each proxy operation ... forwardsthe request to the subject. It implies that for everymethod p in class Proxy there is exactly one methods in class Subject such that Forward (p, s). In otherwords, the relation Forward is a bijective function be-tween the sets.

It is particularly interesting to observe bijections inhigher-dimensional entities. Consider, for example, therelation which occurs in the ABSTRACT FACTORY be-tween the set of clans create (producti ) (namely, a clanfor each product), denoted FactoryMethods, and the set

of product hierarchies, which we denote Products.Their collaboration is described as follows: Abstract-Factory ... defines a different operation for each kindof product it can produce. (Gamma et al., 1994, p. 87)This description implies that Create is a bijectionbetween FactoryMethods, which is a 2-dimensionalmethod, and Products, a 2-dimensional class.

Bijections exist in almost every pattern of the GoFcatalogue, as demonstrated in Eden (2000).

4. Specification LanguagesMathematical logic provides numerous formalismsfor deliberating algebraic constructs such as the oneproposed in Definition I, from first order predi-cate calculus to higher order languages, which af-ford the representation of higher order sets, functions,and relations. Different publications present differentviews on the suitable formalism for the representa-tion of patterns. Below we discuss a selection of theselanguages.

Observe that the publications discussed provide oneor two examples each, and, with the exception ofLEPUS, do not provide a complete semantic specifica-tion. This greatly limits the scope of our analysis. Thus,this section focuses on examples rather than completedefinitions. We hope more comprehensive results canbe obtained in the future.

4.1. DisCoDefined as an extension of temporal logic of ac-tions (Lamport, 1994), DisCo (Mikkonen, 1998) con-sists of constructions that express the composition ofclasses and the semantics of methods. Although thetemporal logic-based formalism focuses on dynamicspecifications, many specifications clearly map to ourstatic framework. Consider for example Extract 2, the

class Subject={Data}class Observer={Data}relation (0..1)Attached(*):

Subject ObserverAttach (s:Subject; o:Observer):

sAttachedo s Attachedo

Extract 2. OBSERVER in DisCo (Mikkonen, 1998).

386 Eden

specification of the OBSERVER pattern (Gamma et al.,1994). It describes the relationships between threeclasses and defines the semantics of one method interms of pre- and postconditions. Despite the seeminglydynamic nature of this specification, formula (9)demonstrates how we can rephrase it in terms of staticrelations.

Subject, Observer, Data :C (9)Attach :F

Reference (Subject, Data)Reference (Observer, Data)Assign (Attach, Subject, Observer)

4.2. Constraint diagramsDescribed as a precise visual specifications languagecombined with elements in UML (Booch, Jacobson,and Rumbaugh, 1999), constraint diagrams (Lauderand Kent, 1998) are a visual representation of first or-der set-theoretic relations. Extract 3 depicts the rolemodel of the ABSTRACT FACTORY pattern.

Rather than repeating here the interpretation ofExtract 3, we both explain it and demonstrate howit translates to our static framework in a singleformula.

AbsFactory, AbsProduct :C (10)

ConcFactory, ConcProduct Inherit+(ConcFactory, AbsFactory) Inherit+(ConcProduct, AbsProduct)

fm :F DefinedIn (fm, ConcFactory) Create (fm, ConcProduct)

Extract 3. Role Diagram of the ABSTRACT FACTORY.

Factories : HProducts : P(H)FMs : P(S)

Create (FMsFactories,Products)ReturnType (FMsFactories,Products)

Extract 4. ABSTRACT FACTORY in LEPUS.

4.3. LEPUSLEPUS (Eden, 2000) is a language for the specificationof O-O software architecture. Consider for examplethe symbolic specification of the ABSTRACT FACTORY inLEPUS, which appears in Extract 4. The interpretationof Extract 4 is as follows:

1. H is the domain of hierarchies, so that Factories isa hierarchy variable and Products ranges over setsof hierarchies.

2. S is a domain of all signatures of methods. Thus,FMs is a variable which represents the set of signa-tures of the factory methods.

3. The expression FMs Factories incorporates theselection operator and yields all methods definedin (a class in) Factories whose signature is in FMs,namely, the set of factory-method clans.

4. The abbreviation R(V, W ) represents a bijection(Rudiment F) between the sets V, W . Thus, the twostatements below the dividing line indicate that forevery factory method fm there is a product p suchthat is Create( fm,p) and ReturnType( fm,p).

These examples demonstrate how the framework wepropose sheds light on the difference between variousformalisms.

In addition to the results analysed above, followingis a short overview of other results that were reportedin literature.

4.4. Design patterns formalismsFormal Languages for the specification of design pat-terns are described in several publications. Helm,Holland and Gangopadhyay (1990) defined Con-tracts, an extension to first order logic with represen-tations for function calls, assignments, and an orderingrelation between them. The behavioural composi-tions described do not address structural relations butonly behavioural characterizations.

A Theory of Object-Oriented Design 387

4.5. Tool supportFlorijn, Meijers, and van Winsen (1997) propose a toolthat supports the application of design patterns. Theyuse the Fragments Model for the representation ofpatterns, a graph with labelled arcs, whose nodes standfor the participants in the pattern, and its arcs describethe roles of the connecting nodes. Predominantly, thepatterns wizard (Eden, Gil, and Yehudai, 1997) sup-ports the application of patterns through their represen-tation as metaprogramming algorithms, namely, by thesequence of steps in their application. Other tools sup-porting the application of design patterns are describedin Pal (1995), Budinsky et al. (1996), QuintessoftEngineering (1997), Brown (1996), Alencar et al.(1999), Kramer and Prechelt (1996), Bosch (1996),and OCinneide and Nixon (1999), most of whichare reviewed in Eden, Hirshfeld, and Yehudai(1999).

4.6. Ground relationsOther works have observed elementary relationsbetween entities. Keller et al. (1999) list Call Ac-tions and Create Actions (corresponding to Invokeand Create relations of Table 1, respectively) amongthe information their reverse engineering environmentmaintains for the representation of O-O programs, aswell as information on the relations between classes(e.g., Inheritance, Reference). Chiba (1995) describesa metaprogramming environment for manipulatingC++ programs whose features are classified underFunction Invocation and Object Creation, among otherfeatures.

5. Relations Among Patterns

This section discusses relations among patterns as sug-gested by informal means and offers precise definitionsfor these terms by means of the framework definedso far.

5.1. RefinementTwo articles (Agerbo and Cornils, 1998; Vlissides,1997), describe one pattern as a refinement ofanother, meaning that one is a special case of the other.Cargill (1996) describes categories of patterns,where one category refines the other. Kim andBenner (1996) describe the push and pull models asrefinements of the OBSERVER pattern (Gamma et al.,

1994). Similarly, Rohnert (1996) describes special-izations of the PROXY pattern, such as CACHE PROXYand PROTECTION PROXY. The following definitionformalises this intuition:

Definition 7 (Refinement). We say that pattern refines pattern , written as: |= , iff for everyassignment A that satisfies in some model M, Aalso satisfies inM.

By Definition 7, refinement is equivalent to semanticentailment (Huth and Ryan, 2000). Thus, we may con-clude that whenever our specification language allowsfor a proof theory and a complete and sound relationL, then the refinement relation |= holds if andonly if L holds.

The difficulty in handling refinement in the lack ofa formal theory is well demonstrated in a classic ex-ample (Vlissides, 1997). The article reports a debatebetween the authors of the OBSERVER pattern (Gammaet al., 1994), which could not agree whether it isindeed refined by the MULTICAST (a pattern proposed byJ. Vlissides). Eden, Gil, Hirshfeld, and Yehudai (1998),show how the debate can be resolved using LEPUS(Section 4).

5.2. ProjectionIn simple terms, projection is obtained by replacing auniform set of participants X with a single participantx of the same type. Formally:Definition 8 (Projection). A projection of the freevariable X : P(T) in (X ) is a formula (x) resultingin the consistent replacement of X with x : T in .

We say that (X ) is an abstraction of x in (x).

Example 2 illustrates this definition:

Example 2 (Projection). Extract 4 gives the definitionof the ABSTRACT FACTORY pattern in LEPUS. The spec-ification of the FACTORY METHOD is obtained merelyby modifying the dimension of two variables in theABSTRACT FACTORY as follows:

ABSTRACT FACTORYFACTORY METHOD Description

Products: P(H) Products: H A hierarchy vs. a setof hierarchies

FMs: P(S) FMs: S A signature vs. a setof signatures

388 Eden

6. Comparative Criteria

With the increase in the popularity of design patterns,we expect that even more formalisms should arise.The purpose of this section is to define properties thatcan be used as criteria in comparing between suchformalisms.

We maintain that shorter expressions contribute to aclearer language. The concision criterion allows us tojudge the relative shortness of expressions.

In the following definition, L,L1 and L2 designatespecification languages, is a set of patterns, isthe expression of pattern in L, and c is a numericconstant.

Definition 9 (Concision). Let us assume a metricfunction that measures the length of expressions in L1and L2:

Len : L1 L2 NLet 1 and 2 be specifications in L1,L2, respectively.We say that 1 is more concise than 2 iff

Len(1) < Len(2)

We say that L is c-concise with respect to iff forevery in , the following is true:

Len( ) < c

Naturally, different formalisms give rise to differentsubsets of P , and thus may or may not accountfor subsets of interest. Yet the question whether acertain formula expresses an informal description isdifficult to answer conclusively exactly because thecontemporary means of specification are ambiguous.As a step towards measuring their capacity we defineexpressiveness by means of the rudiments made inSection 3:

Definition 10 (Expressiveness). We say that a speci-fication language L is expressive if it incorporates therudiments listed in Section 3, namely:

participants of any dimension (Definition 4) ground and set relations (Rudiment E and

Rudiment F) clans (Definition 5) hierarchies (Definition 6)

Observe that, while different formalisms may in-terpret class and method differently, Definition 10does not depend on these variations. And justly so,as architectural specifications need not be affected bythese variations.

7. Future Directions

We observe several directions of future research:

7.1. CompactnessDefinition 10 is satisfied by any language that assimi-lates the rudiments of Section 3, such as higher orderlogic.4 Observe, however, the risk of getting a speci-fication language that is too expressive or too large,meaning that it incorporates many more expressionsthan necessary.5 For example, an architectural spec-ification language is not expected to account for thefollowing sets of programs:

The set of programs that guarantee liveness The set of programs that can be written in the JavaTM

programming language The set of programs that the do not terminate

A leaner language is better because of the follow-ing reasons, among others:

1. Clarity. Excessive number of possible expressionsincreases the complexity of the specification lan-guage and makes it difficult for its users to under-stand it and to use it.

2. Reasoning. The properties of simpler andsmaller languages can be reasoned upon moreeasily.

3. Discovery. Semi-automation of a discovery pro-cess, namely, the search for new patterns inprograms, may become more feasible by reduc-ing the set of candidate patterns. By restrict-ing the specification language and constraining itssearch, a tool is more likely to create meaningfulresults.

4. Abstraction. As abstractions, patterns depict onlyessentials and eliminate irrelevant details. Elimi-nation of details is expected to lead to a smallerlanguage.

To summarize, compactness has the intuitive mean-ing of the property which characterizes languages

A Theory of Object-Oriented Design 389

with fewer unreasonable patterns. It would be use-ful to convey the idea of unreasonable patternsby providing a measurement for compactness at thispoint.

Dynamic specifications. Despite the achievement inspecification through static properties, our frameworkdoes not allow the expression of certain behaviouralconditions. Formalisms that may be of use are Tem-poral Logic of Actions (Lamport, 1994), as in Mikko-nen (1998), and Abstract State Machines (Gurevich,1994).

Applying the criteria. Once complete definitions anda sufficient number of examples are provided for pro-posed formalisms, our analysis can be improved inmany ways. An interesting result can be achieved byapplying the criteria suggested so as to compare samplespecifications.

8. Conclusions and Summary

We present a formal framework for the discussion inO-O software architecture by observing elementary andcomposite abstractions in its specification and by of-fering a logic model for representing and deliberatingthese abstractions. We have demonstrated how exam-ples in various pattern specification languages map toour framework. We have used our framework to defineinformal concepts in formal terms. Finally, we offeredmeans for comparing the properties of architecturalformalism.

Acknowledgments

This work would not have been possible if not forthe significant contributions of Yoram Hirshfeld ofTel Aviv University. Special thanks to Bjorn Victorof Uppsala University for his insights and detailedcomments. Many thanks to Peter Grogono for hisfeedback.

Notes

1. pattern-discussion. Mailing list: http://hillside.net/patterns/Listss.html

2. gang-of-four-patterns. Mailing list: http://hillside.net/

3. For the purpose of this article, program is any text that is con-sidered well-formed by the rules of the respective programminglanguage.

4. A construction of these elements in higher order logic appears inEden, Hirshfeld, and Yehudai (1999).

5. UML is an example that comes to mind.

ReferencesAbowd G, Allen R, Garlan D. Using style to understand de-

scriptions of software architecture. In: Proceedings of the ACMSIGSOFT Symposium on the Foundations of Software Engineer-ing, December 1993.

Agerbo E, Cornils A. How to preserve the benefits of design pat-terns. In: Proceedings of the Conference on Object-Oriented Pro-gramming, Systems, Languages, and Applications, 1822, Oct.,Vancouver, Canada, 1998:134143.

Alencar P, Cowan D, Dong J, Lucena C. A pattern-based approachto structural design composition. IEEE 23rd Annual Interna-tional Computer Software and Application Conference, 1999:160165.

Alexander C. The Timeless Way of Building. New York: OxfordUniversity Press, 1979.

Alexander C, Ishikawa S, Silverstein M, Jacobson M, Fixdahl-KingI, Angel S. A Pattern Language. New York: Oxford UniversityPress, 1977.

Allen R, Garlan D. A formal basis for architectural connection.ACM Transactions on Software Engineering and Methodology1997;6(3):213249.

Booch G. Object Oriented Analysis and Design with Applications,2nd edn. Benjamin/Cummings, 1994.

Booch G, Jacobson I, Rumbaugh J. The Unified ModelingLanguage Reference Manual. Reading, MA: Addison-Wesley,1999.

Bosch J. Relations as object model components. Journal of Program-ming Languages, 1996;4(1):3961.

Brown K. Design Reverse-Engineering and Automated Design Pat-tern Detection in Smalltalk M. Sc. Thesis, University of Illinois,1996

Budinsky FJ, Finnie MA, Vlissides. JM, Yu PS. Automatic codegeneration from design patterns. IBM Systems Journal, 199635(2):151171.

Cargill T. Localized ownership: Managing dynamic objects in C++.In: Vlissides JM, Coplien JO, Kerth NL, eds. Pattern Lan-guages in Program Design 2. Reading, MA: Addison-Wesley,1996.

Chiba S. A metaobject protocol for C++. In: Proceedings of theTenth Annual Conference on Object-Oriented Programming Sys-tems, Languages, and Applications, 1519, Oct., Austin, USA1995:285299.

Coplien J, Schmidt D, eds. Pattern Languages of Program Design.Reading, MA: Addison-Wesley, 1995.

Craig I. The Interpretation of Object-Oriented Programming Lan-guages. Berlin: Springer-Verlag, 1999.

Dean TR, Cordy JR. A syntactic theory of software archi-tecture. IEEE Transactions on Software Engineering, 1995;21(4).

390 Eden

Eden AH. Giving The quality a name. Journal of Object OrientedProgramming 1998;11(3):511.

Eden AH. Precise specification of design patterns and tool supportin their application. Ph.D. Dissentation, Department of ComputerScience, Tel Aviv University, 2000.

Eden AH, Gil J, Yehudai A. Precise specification and au-tomatic application of design patterns. In: Proceedings ofthe Twelve IEEE International Automated Software Engi-neering Conference (ASE 1997), 35, Nov, Lake Tahoe,Nevada, Los Alamos: IEEE Computer Society Press, 1997:143152.

Eden AH, Hirshfeld Y, Yehudai A. MulticastObserver = typed mes-sage. C++ Report, 1998;10(9):3339.

Eden AH, Hirshfeld Y, Yehudai A. Towards a mathematicalfoundation for design patterns. Technical Report 1999-004,Department of Information Technology, Uppsala University,1999.

Firesmith DG, Graham I, Henderson-Sellers B. Open ModelingLanguage (Olm) Reference Manual. Cambridge University Press,1998.

Florijn G, Meijers M, van Winsen P. Tool support in design patterns.In: Askit M, Matsuoka S, eds. Proceedings of the 11th EuropeanConference on Object Oriented ProgrammingECOOP 97,Lecture Notes in Computer Science, vol. 1241. Berlin: Springer-Verlag, 1997.

Gamma E, Helm R, Johonson R, Vlissides J. Design Patterns:Elements of Reusable Object Oriented Software. Reading, MA:Addison-Wesley, 1994.

Gibbs WW. Softwares chronic crisis. Scientific American 1994;8695.

Gosling J, Joy B, Bracha G. The JavaTM Language Specifi-cation, 2nd edn. Reading, MA: Addison Wesley Longman,2000.

Gurevich Y. Evolving algebras. In: Pehrson B, Simon I, eds. IFIP 13thWorld Computer Congress 1994, vol. I: Technology and Founda-tions, 1994:423427.

Harel D. Statecharts: A visual formalism for complex systems. Sci-ence of Computer Programming 1987;8(3):231274.

Helm R, Holland IM, Gangopadhyay D. Contracts: Specifying be-havioral compositions in object-oriented systems. In: Proceed-ings of the European Conference on Object-Oriented Program-ming on Object-Oriented Programming Systems, Languages,and Applications, 2125, Oct., Ottawa, Canada, 1990:169180.

Hoare CAR. Communicating Sequential Processes. New Jersey:Prentice-Hall, 1985.

Huth MR, Ryan MD. Logic in Computer Science: Modeling andReasoning About Systems. Cambridge, UK: Cambridge UniversityPress, 2000.

Keller RK, Schauer R, Robitaille S, Page P. Pattern-based reverseengineering of design components. In: Proceedings of the Twenty-First International Conference on Software Engineering, LosAngeles, CA: IEEE, 1999:226235.

Kim JJ, Benner KM. Implementation patterns for the observer pat-tern. In: Vlissides J, Coplien JO, Kerth NL, eds. Pattern Lan-guages in Program Design 2. Reading, MA:Addison-Wesley,1996.

Kramer C, Prechelt L. Design recovery by automated search for struc-tural design patterns in object-oriented software. In: Proceedings

of the Working Conference on Reverse Engineering, 810, Nov.,Monterey, CA, 1996:208215.

Lamport L. The temporal logic of actions. ACM Transactionson Programming Languages and Systems 1994;16(3):872923.

Lauder A, Kent S. Precise visual specification of design patterns.In: Proceedings of the 12th European Conference on Object Ori-ented Programming, Brussels, Belgium, Lecture Notes in Com-puter Science, vol. 1445, Jul, Eric, ed. Berlin: Springer-Verlag,1998.

Martin R, Riehle D, Buschmann F, eds. Pattern Languagesof Program Design 3. Reading, MA: Addison-Wesley,1997.

Medvidovic N, Taylor RN. A framework for classifying and com-paring architecture description languages. In: Proceedings of theSixth European Software Engineering Conference, with FifthACM SIGSOFT Symposium on the Foundations of SoftwareEngineering, 2225, September, Zurich, Switzerland, 1997:6076.

Mikkonen T. Formalizing design patterns. In: Proceedings of theInternational Conference on Software Engineering, 1925, April,Kyoto, Japan, 1998:115124.

OCinneide M, Nixon P. A methodology for the automated intro-duction of design patterns. In: Proceedings of the IEEE Interna-tional Conference on Software Maintenance, 30 August3 Sept.,1999.

Odenthal G, Quibeldey-Cirkel K. Using patterns for de-sign and documentation. In: Proceedings of the Euro-pean Conference of Object Oriented Programming, 1997,Lecture Notes in Computer Science. Berlin: Springer,1997.

Pal PP. Law-governed support for realizing design patterns. In: Pro-ceedings of 17th Conference on Technology of Object-OrientedLanguages and Systems (TOOLS 17), Englewood Cliffs, NJ:Prentice Hall, 1995.

Perry DE, Wolf AL. Foundation for the study of software architec-ture. ACM SIGSOFT Software Engineering Notes 1992;17(4):4052.

Petri CA. Communications with automata. Technical Report RADC-TR-65-377, Applied Data Research, Princeton, NJ, 1962.

Popper K. Conjectures and Refutations. London: Rutledge,1969.

Quintessoft Engineering, Inc. C++ Code Navigator 1.1.http://www.quintessoft.com, 1997.

Rohnert H. The proxy design pattern revisited. In: Vlissides J,Coplien JO, Kerth NL, eds. Pattern Languages in Program De-sign 2. Reading, MA: Addison-Wesley, 1996.

Rumbaugh J, Blaha M, Premerlani W, Eddy F, Lorensen W. ObjectOriented Modeling and Design. Englewood Cliffs, NJ: PrenticeHall, 1991.

Schmidt D, Stal M, Rohnert H, Buschmann F. Pattern-Oriented Soft-ware Architecture, Vol. 2: Patterns for Concurrent and NetworkedObjects. New York: John Wiley & Sons, 2000.

Spivey JM. The Z Notation: A Reference Manual. New Jersey:Prentice-Hall, 1989.

Vlissides J. Multicast. C++ Report, vol. 9, no. 8. New York, NY:SIGS Publications, 1997.

Vlissides JM, Coplien JO, Kerth NL. Pattern Languages in ProgramDesign 2. Reading, MA: Addison-Wesley, 1996.

A Theory of Object-Oriented Design 391

Amnon H. Eden graduated the 4th class of the inter-disciplinary programme of excellence in Tel AvivUniversity and received his Ph.D. in 2000. He workedas a consultant with software firms and chairedthe software engineering transition programme at

the Tel Aviv College of Management. Presently,Dr. Eden is with the Department of ComputerScience at the University of Essex, UK, and a re-search scholar at the Center for Inquiry in Amherst,NY.