Abstract

In an effort to manage increasing complexity and to maximisethe reuse of code, the software engineering community has inrecent years put considerable effort into the design and develop-ment of component-based software development systems andmethodologies. The concept of building software from existingcomponents arose by analogy with the way that hardware is nowdesigned and built, using cheap, reliable standard “off-the-shelf”modules. Because of the analogy with wiring hardware compo-nents, component-based software development is a natural candi-date for visual expression. Various component softwaretechnologies have emerged as a result of this attention, but theirevolution has been rather ad hoc. In fact, some systems are definedpurely by their implementation with little or no precise defini-tion. In an attempt to address this shortcoming, we propose awell-defined syntax and semantics for a component softwaremodel that captures the essential concepts.

1 Introduction

Software reuse has long been one of the major issues inthe world of software engineering, where code reuse is seen asthe key to many benefits, such as increased productivity,improved reliability, and ease of maintenance. As a result,many software reuse technologies have been developed overthe past few years, see for example [8,9].

Software reuse was first realised in the late 50’s with thedevelopment of libraries of pre-compiled subroutines such aslarge numerical libraries for engineering and scientific com-putation. Reuse via subroutines has limited applicability,however, because of the difficulty of encapsulating high-levelfunctionality in subroutines.

A major step forward was made with the advent of object-oriented programming (OOP), which provided inheritanceas its primary reuse mechanism. As OOP research and prac-tice has progressed, other reuse techniques have been devised,such as object composition. More significantly, object-ori-ented application frameworks have emerged, providing themeans to capture very large application design patterns in theform of “inverted libraries” which call the code supplied bythe application developer, rather than the other way round aswith traditional libraries [10].

Another popular reuse technique involves design patterns,which provide guidance during the design phase of softwareby suggesting high-level organisations for the necessaryabstractions [6]. Design patterns provide methodology butnot tools.

A recent trend in software engineering is towards softwaredevelopment using components. This development method-ology is based on the observation that hardware design anddevelopment has evolved well beyond the “build-from-

scratch” era. Hardware these days is built from “off-the-shelf ” components which are customisable to a degree, cheapbecause they are manufactured in large quantities, are welltested and reliable, and have a well defined interface. Theaim of component-based software development is to attainreuse, economy, reliability and so forth by creating large cata-logues of software components for assembling into softwaresystems [19]. This approach has some other desirable conse-quences as well, such as standardisation, resulting in softwareproducts from different developers working correctlytogether.

The analogy with hardware components on which thenotion of software components rests, leads naturally to avisualisation of component-based software as a network ofboxes communicating with each other via connecting wires.In recent years several software development tools haveappeared that provide visual programming based on compo-nents. Visual Age for Java [3], Parts for Java and Java Studiouse Java Beans as the underlying component mechanism. InVisual Age and Parts, the visual programming by wiringcomponents together is largely limited to programming theuser interface. Components that implement user interfaceitems are represented in the visual program by their usualinterface appearance, and wires connect them to indicate theflow of messages between these visible components and oth-ers which have no visual representation. A more direct repre-sentation of the box-and-wire metaphor is provided by JavaStudio (no longer available), in which icons representing thecomponents are wired together.

Another visual manifestation of components can be seenin Microsoft Office products where “objects” of differingtypes (word processor document, spreadsheet, picture) canbe embedded in each other. The objects are components, andare linked together and pass messages to each other accordingto a standard protocol, Object Linking and Embedding(OLE).

Apple Computer spent several years designing and build-ing a similar but more flexible system called OpenDoc, inwhich documents consisting of communicating componentscould be built by dragging components into a workspace [2].

Like many other good ideas, the concept of componentshas developed in a rather

ad hoc

way. Even though the vari-ous component technologies have very similar capabilities,they are all different in detail, and few of them are defined inclear, concise terms the way programming languages are (orcan be).

In the following, we attempt to address this shortcomingby providing a formal definition of the syntax and semanticsof components as exemplified by the above systems. This def-inition• captures the essence of component-based software at a

high level;

A Formal Model for Component-Based Software

Philip T Cox* Baoming Song†

*Dalhousie University, Halifax, Canada

†

Telecommunications and Informatics Services, Government of Canada

• provides a simple but precise characterization of compo-nents which may help dispel confusion resulting from therapid evolution of many subtly different component tech-nologies;

• describes an underlying structure on which the syntax ofcomponent-based languages can be based, as well as asemantics for such languages;

• provide a basis for a formal testing and verification meth-odology;

• allows recursive components which none of the existingcomponent technologies provide;The definition has been implemented in a prototype

development environment in which simple component-based programs can be built. The pictures used to illustratethe definitions were generated by this prototype.

Before presenting our definitions in Section 3, we give abrief overview of component models.

2 Component models

Just as there are a variety of similar but not identical com-ponent technologies, so are there many similar but not iden-tical definitions of

component.

Two examples are:

“A component is a coherent package of software that can beindependently developed and delivered as a unit, and that offersinterfaces by which it can be connected, unchanged, with othercomponents to compose a larger system.”

[5]and:

“A software component is a unit of composition with contrac-tually specified interfaces and explicit context dependencies only.A software component can be deployed independently and is sub-ject to composition by third parties.”

[19]Although these definitions differ in detail, they both

assert that a component is an independent software packagethat provides functionality via well-defined interfaces. Theyalso emphasise the “black box” nature of a component: thatis, a component can be incorporated in a software systemwithout regard to how it is implemented.

Given these approximately equivalent definitions, thereare two questions to be answered: how is a component devel-oped and how is the component applied in software develop-ment? A component model should address both questions.

The three main component models currently in commer-cial use are CORBA, COM, and JavaBeans.

2.1 CORBA

The Common Object Request Broker Architecture(CORBA), was proposed by the Object Management Group(OMG) as a standard for communication between compo-nents. It forms part of a larger model, Object ManagementArchitecture (OMA) that defines at a high level of abstrac-tion a context within which components operate and inter-act, including standard services that components can rely on.

A CORBA component provides functionality via aninterface defined in the CORBA Interface Definition Lan-guage, and interacts with other components only via thatinterface.

Other CORBA-related component models are IBM’s Sys-tem Object Model (SOM) which adds some extensions, andOpenDoc based on COM.

2.2 COM

The Component Object Model (COM) due to Microsoftis implemented only on Microsoft platforms [12].

COM specifies a standard for communication betweenCOM components, consisting of COM interfaces and a sys-tem for registering and passing messages between compo-nents via these interfaces. COM interfaces are defined inMicrosoft Interface Description Language (MIDL).

COM defines incoming interfaces as those interfaces thatreceive calls from other components and outgoing interfacesas those interfaces through which other components arecalled. COM uses outgoing interfaces to define events.

Other component models have been developed usingCOM. OLE deals with compound documents as mentionedin the previous section. Active X, like Java Applets, supportsInternet and distributed computing. ActiveX componentscommunicate with each other via events.

2.3 JavaBeans

According to the JavaBeans specification [18], a Java Beanis

“a reusable software component that can be manipulated visu-ally in a builder tool.”

A Java Bean component may have avisual representation, for example, a user-interface compo-nent, or may be non-visual, for example, a database connec-tivity component .

Java Bean components communicate with each other bysending events. The interface between components is there-fore provided by the event model in the Java language. Com-ponents have properties which can be set by the programmerto achieve some customisation.

Enterprise JavaBeans (EJB) is an extension of the JavaBean model that provides a mechanism for encapsulating aJava Bean component as a CORBA component.

2.4 Common characteristics

The table below summarises the similarities and differ-ences between the above three component technologies.

Ignoring differences in technical details such as imple-mentation language, component implementation restric-tions, parameterisation mechanisms, interface definitionmethodologies and self-documentation capabilities, we seethat these technologies have essentially similar architecturesand functionality. Each defines a component as a self-con-tained “black box” sending messages to and receiving mes-sages from other components via a well defined interface,and performing its computation in response to the receipt ofa triggering message (event).

Although these component technologies all have somerelationship with object-oriented programming, object-ori-entation is orthogonal to the key concepts, as the table belowshows.

2.5 Formalisations

Some attempts have been made to formally specify com-ponent models. A formal specification of CORBA using theZ specification language is used by the OMG member com-panies to ensure that facilities added to CORBA are correct.

There appears to be no the formalisations of the Java Beancomponent model, although there is a formal specification ofthe subset of the Java language on which JavaBeans is based[4].

There have been two attempts to formalise the COMcomponent model. One of them, a language called COMEL(Component Object Model Exemplary Language), providesa formal syntax and semantics embodying COM’s informaland complex rules [7]. The other, developed in an industrial

setting to ensure the design integrity of a commercial systememploying COM components, consists of a model based onfirst-order set theory, expressed in Z [17].

Each of the above formalisations describes a particularcomponent model, and is intended for a particular purpose.None of them serves as a general definition of the key con-cepts summarised in section 2.4.

The component technologies described above arose fromfocussed development aimed at solving specific practicalproblems in industrial software development. For example,COM and OLE arose from a need to make common end-user applications operate seamlessly together.

Broader software engineering research by a somewhat dif-ferent route has arrived at a similar point. Module Intercon-nection Languages (MILs) have long been studied as a meansto specify the architecture of software systems [13], and havemore recently evolved into Architecture Description Lan-guages (ADLs) for formalising the syntax and semantics ofhigh-level software design patterns [15].

Two examples of ADLs, are Darwin [11] and Wright [1],both of which provide general mechanisms for specifyingsoftware architectures in terms of connected “components”,where a component in these languages is a module that usesthe services of, and provides services to, other components.As general ADLs, neither provide a specific characterisationof the commercial component technologies that we addresshere, although they may well admit such characterisations, aswould general software modelling languages such as Z [16].

3 A component model

3.1 Notational conventions

When an entity X is defined as a tuple, we can refer to theconstituents of X in various ways. For example, consider def-inition 3.2.5 below. If X is a simple component, we can referto the first constituent of X as

inports

(X), or by the phrase“the inports of X”. If X is understood in context, we can omitthe X, and simply write

inports

or refer to “the inports”. If anitem is a set, we will usually give it a plural name so that wecan refer to its members in the singular. For example, if X is asimple component, we can use phrases such as “an inport ofX”.

If f is a function with domain S and range T, and S’ is asubset of S, then f(S’) denotes the subset { f(s) | s

∈

S’ } of T.If S’ is an

n

-tuple or sequence of elements of S for some

n

,then f(S’) denotes the

n

-tuple or sequence of elements of Tobtained by applying f to each element of S’. When it is con-venient to do so, we will treat a tuple or sequence as if it werea set, in which case we mean the set consisting of all elementsoccurring in the tuple or sequence.

3.2 Syntax

3.2.1 Definition - domain

The

domain

D is a set which does not include the element

none

. A is an arbitrary but fixed infinite set called the set of

attributes

, each element x of which is associated with a subsetof D denoted

τ

(x) called the

type

of x.Three important concepts are introduced in this defini-

tion:

domain

,

attribute

, and

type

. The domain D mightinclude values from any data type such as integers, strings, orinstances of classes. Attributes can be thought of as variablesor data fields.

τ

is a function that defines the set of all ele-ments of D that can be values of an attribute. For example,suppose D includes the set

Z

of all integers, and for someattribute x of A,

τ

(x) =

Z

, then

τ

defines the type of x as inte-ger.

3.2.2 Definition - component

A

component over

A is either a source over A, a sink overA, a simple component over A, a compound component overA, or a prototype over A.

3.2.3 Definition - source

A

source

over A is an attribute. IfX is a source,

attributes

(X) and

out-ports

(X) are both defined to be theset consisting of the single attributeX.

In general, a component pro-duces data at its outports inresponse to the arrival of data at itsinports. A source component hasno inports, so from the point ofview of the application in which it is embedded, a sourcecomponent spontaneously generates data. For example, a

JavaBeans COM CORBA

Component Module containing multi-ple classes

Module containing multiple classesor other implementation

Module containing anyimplementation

Interface Java language OLE IDL, which defines interfaces ascollection of functions

OMG IDL

Connection Via event and listener. Via interface pointers Via Interface DefinitionLanguage

Variabilitymechanism

Inheritance and aggregation Genericity, containment and aggre-gation

Inheritance and aggrega-tion

Platform Multiple platforms Windows Multiple platformsImplementationLanguage

Java Any languages, but primarily useC++ and Visual Basic

Any languages

DistributionMechanism

EJB, Internet, RMI (remotemethod invocation)

DCOM, Internet An ORB

Self-description Support via introspection No No

Figure 1: VisualRepresentation

of a SourceComponent

button component generates an output value when the but-ton is clicked rather than in response to receiving an input.

Pictorially, a source can be represented as a box with theoutport represented by an arrow on the perimeter pointingout from the box as shown in Figure 1.

3.2.4 Definition - sink

A

sink

over A is an attribute. If X is a sink,

attributes

(X)and

inports

(X) are both defined to be the set consisting ofthe single attribute X.

A sink is a component with nooutports as shown in Figure 2. Itreceives its input data via its inports.Just as sources are active compo-nents, sinks are passive ones. Thevisual representation of a sink issimilar to that of a source exceptthat the single attribute is repre-sented by an arrow pointing intothe box. An example of a sink is atext field which displays the data itreceives on its inport.

3.2.5 Definition - simple component

A

simple component over

A is a 4-tuple X of the form(

inports

,

outports

,

function

,

triggers

) where:•

inports

is an

n

-tuple (a

1

, …, a

n

) of attributes for someinteger

n

≥

0;•

outports

is an attribute distinct from a

1

, …, a

n

;•

function

is an n-ary function from

τ

(a

1

)

x

…

x

τ

(a

n

) into

τ

(

outports

);•

triggers

is a set of pairs of the form (

target

,

relation

),where

target

is an attribute distinct from the outport, and

relation

is a binary relation on

τ

(

target

);•

attributes

(X) is defined to be the set of attributes consist-ing of the inports, the outport and the targets of X.The role of simple components in a component-based

system is analogous to that of primitive functions such asarithmetic operations or library routines in a programminglanguage: that is, they provide services implemented using adifferent formalism or language. Ports (

inports

and

out-ports

) provide the interface through which the componentinteracts with other components. The functionality of acomponent is implemented through

function

. Triggers pro-vide the mechanism for initiating execution of the compo-nent, the importance of which will be seen in the followingdefinitions.

Figure 3 shows the visual representation of a simple com-ponent, represented by a box with inports and triggerslocated on the left and outports on the right. Since a triggermay or may not be an inport, there are three possible combi-nations on the left of box. An inport is represented by anarrow pointing into the box; a trigger is represented by a

small gun-like icon; and a combined inport and trigger isrepresented by an icon with an arrow on one end and a gun-like icon on the other.

An example of a simple component is one that sums twointeger values, and could be the one depicted in Figure 3. Inthis simple example,

inports

is a pair of attributes (

a

1

,

a

2

)and

outports

is an attribute

b

.

function

adds two integer val-ues together and assigns the result to the outport

b

. Two trig-gers exist for this simple component. One trigger is

a

2

whichhas the relation {(

m, n

) |

m

≠

n

} meaning that the functionwill be executed if the new value if

a

2

is not equal to its oldvalue. Another trigger is

a

3

with relation {(

m, n

) |

m

= 1},meaning that the function will be evaluated if the new valueof

a

3

is equal to 1.The function of the simple component will be evaluated

if and only if the relation for one of its triggers is true. In theabove example, the sum of

a

1

and

a

2

will be calculated only ifthe relation for trigger

a

2

is true, which will be the case if anew value arrives at this inport, or the relation for the trigger

a

3 is true, which occurs if the value 1 arrives at a3. This mayhappen if, for example, a button linked to this trigger isclicked. Precise semantics will be given in a later section.3.2.6 Definition - compound component

A compound component over A is a 4-tuple X of the form(components, inports, outports, connections) such that:• inports is a sequence of distinct attributes.• outports is a sequence of distinct attributes.• components is a set of components, not including X.• attributes(X) is defined as the set inports(X) ∪ out-

ports(X) ∪ { x | ∃Y ∈ components(X) such that x ∈attributes(Y) }.

• The sets inports(X), outports(X), attributes(Y) andattributes(Z) are pairwise disjoint for any Y, Z ∈ compo-nents(X).

• connections is a set of pairs of the form (origin, destina-tions) such that if K is a connection, then • origin(K) is either an inport of X or an outport of a

component of X;• destinations(K) is a set of attributes of X not containing

origin(K);• For each destination d of K, τ(origin(K)) ⊆ τ(d).A compound component is a network of connected com-

ponents. A connection associates an outport of one compo-nent, the origin of the connection, with the inports of one ormore other components, the destinations of the connections.A connection indicates the passage of data from origin todestinations. Each destination must be able to accept anyvalue it receives from the origin, so its type must be a subsetof the type of the origin.

Figure 4 shows the visual representation of a compoundcomponent as it appears within another compound compo-nent. It is similar to a simple component except for its colourand the fact that it can have several outports and cannot havetriggers.

Figure 5 depicts the internal structure of the compoundcomponent in Figure 4. In this example, the compoundcomponent consists of four inports, two outports, and twosimple components f1 and f2 each of which has two inportsand a trigger. f1 is used to calculate the sum of two integersand f2 is used to calculate the difference between two inte-

Figure 2: VisualRepresentation

of a SinkComponent

Figure 3: Visual Representation of aSimple Component

Inport a1

Inport & trigger a2

Trigger a3

Outport b

gers. This compound component can provide the sum of ordifference between the two integers arriving on inports a2and a3, depending on which of the trigger relations of thetwo components holds.

Compound compo-nents provide anabstraction mecha-nism for dealing withthe complexity of acomponent-based pro-gram. Note that theconcept “compoundcomponent” realisesthe notion of “pro-gram”: that is, we canbuild a component-based software system by constructing acompound component.

3.2.7 Definition - equivalenceTwo components X and Y are equivalent iff there exists a

bijection Φ: attributes(X) → attributes(Y) such that• for all x ∈ attributes(X), τ(x) = τ(Φ(x)).• inports(Y) = Φ(inports(X)).• outports(Y) = Φ(outports(X)).• if X and Y are compound components, then

• connections(Y) = Φ(connections(X)).and there is a bijection Ψ: components(X) → compo-nents(Y) such that for each component Z of X• Ψ(Z) is equivalent to Z;• Φ(attributes(Z)) = attributes(Ψ(Z)).

• if X and Y are simple components, then• function(Y) = function(X);• triggers(Y) = { (Φ(t), C[x1, x2]) | (t, C[x1, x2]) ∈ trig-

gers(X) }.• if X and Y are prototypes, then class(X) = class(Y).

According to this definition, components are equivalent ifthey are syntactically identical. It is easy to show that therelation “equivalence” is, in fact, an equivalence relation oncomponents, which leads to the next definition.

3.2.8 Definition - classIf U is the set of all components, then U is partitioned

into equivalence classes by the equivalence relation definedabove. Each such class is called a component class.

Since the semantics of components, provided below,ascribes identical behavior to equivalent components, thepartitioning provided by equivalence provides a basis for pro-cedural abstraction, as follows. 3.2.9 Definition - prototype

A prototype over A is a triple X of the form (class, inports,outports) where• class is a component class the elements of which are com-

pound components.• inports and outports are mutually exclusive sequences of

distinct attributes of the same lengths respectively asinports(Y) and outports(Y) for any Y ∈ class.

• attributes(X) is defined to be the set inports(X) ∪ out-ports(X).Note that since prototypes can occur in compound com-

ponents, the procedural abstraction mechanism provided byprototypes naturally includes recursion, which is not nor-mally a feature of component software models.

Figure 6 shows the representation of a prototype of theclass of which the compound component in Figure 5 is a rep-resentative. Its colour (green) distinguishes it from simplecomponents (blue) and compound components (yellow).3.3 Semantics

3.3.1 Definition - occurrenceA component Y is said to occur in a component X iff

either X = Y or X is a compound component and Y occurs ina component of X.

A connection K is said tooccur in a component X iffeither X is a compound com-ponent and K is a connectionof X, or K occurs in a compo-nent that occurs in X.3.3.2 Definition - state

A state of the set A ofattributes is a function σ: A →D such that σ(x) ∈ τ(x) ∪ {none} for each x ∈ A.

A state is an assignment of values to all attributes. As weshall see, an execution of a component assumes a certainstarting state, which is transformed as the execution pro-ceeds.3.3.3 Definition - execution

If X is a component and σ is a state, an execution of X fromσ is a sequence of the form (σ0, X0, S0), (σ1, X1, S1), (σ2,X2, S2), … where• for each i ≥ 0, σi is a state, Xi is a component, and Si is a

subset of the simple components occurring in Xi.• σ0 = σ; X0 = X; S0 = ∅.• for each i ≥ 1

• (σi, Xi, Si) is a propagation of (σi-1, Xi-1, Si-1) if oneexists;

• otherwise, (σi, Xi, Si) is an expansion of (σi-1, Xi-1, Si-1)if one exists;

Figure 4: A CompoundComponent

a1

a2

a3

a4

b1

b1

a11

a12

a13

a23

a22

a21

a1

a2

a3

a4

b1

b1

b11

b21

Figure 5: Internal Structure of aCompound Component

Figure 6: A Prototype

• otherwise, (σi, Xi, Si) is an evaluation of (σi-1, Xi-1, Si-1)if one exists.

This definition divides execution of a component intothree phases: propagation, expansion and evaluation definedbelow. Note that if none of the three rules apply, the execu-tion sequence terminates.

The propagation rule, as its name implies, moves valuesthat have been generated by a component along connectionsfrom the component’s outports to other components. Dur-ing this process, some of these values may arrive at triggers ofsome simple components, which may become ready to exe-cute as a result.

The third item in each of the elements of an execution isthe set of all simple components which are ready to execute.During evaluation, the function of each simple componentin this set is evaluated and the result is passed to the outportof the simple component.

The expansion rule operates on prototypes. Duringexpansion, a prototype will be replaced by a compound com-ponent that is a member of the class of the prototype. 3.3.4 Definition - propagation

If σ and σ’ are states, X is a component, and S and S’ aresubsets of the simple components occurring in X, then (σ’,X, S’) is a propagation of (σ, X, S) iff for all x ∈ A• if x is a destination of a connection K occurring in X such

that σ(origin(K)) ≠ none, then σ’(x) = σ(origin(N)),where N is a connection of which x is a destination andσ(origin(N)) ≠ none.

• if x is the origin of a connection occurring in X such thatσ(x) ≠ none then σ’(x) = none.

• otherwise σ’(x) = σ(x).• S’ = S ∪ { Y | Y is a simple component occurring in X

∧ Y has a trigger τ ∧ τ is a destination of a connection K occurring in X∧ σ(origin(K)) ≠ none∧ (σ’(target(τ)), σ(target(τ))) ∈ relation(τ) }.

3.3.5 ExampleConsider the compound component X shown in Figure

7, consisting of two source components Sr1 and Sr2, a sim-ple component Sc, and a sink component Si, connected asshown. All attributes are of integer type. The function f of Scis defined by f(x) = x2 for any integer x, and the relation ofthe trigger of Sc is { (x,y) | x≠y}. Assume the current triplecharacterizing the execution is (σ, X, S) where σ(a1) = 2, andσ(a2) = σ(b) = σ(c) = σ(d) = none. Propagation produces thetriple (σ’, X, S), where σ’(b) = 2 since a1 has a value otherthan none and the value of a2 is none, and σ’(a1) = σ’(a2) =σ’(c) = σ’(d) = none. Since σ’(b) ≠ σ(b) the relation of thetrigger of Sc holds so Sc is ready to execute; therefore S = {Sc }. From this example, we can see that propagation assignsnew values to attributes that occur in a component, as well asrandomly choosing one of the incoming values from amongthose which are not none.3.3.6 Definition - expansion

If σ and σ’ are states, X and X’ are components, and S is asubset of the simple components occurring in X, then (σ’,X’, S) is an expansion of (σ, X, S) iff

either X is a compound component, Y ∈ components(X)and X’ is a compound component identical to X in every

respect except that components(X’) = components(X) – {Y}∪ Y’ where (σ’,Y’,∅) is an expansion of (σ,Y,∅).

or X is a prototype, σ(y) ≠ none for some inport y of X,and X’ is a compound component such that X’ ∈ class(X),inports(X’) = inports(X) and outports(X’) = outports (X)and σ’(x) = σ(x) if x ∈ attributes(X) and σ’(x) = none other-wise.

Expansion replaces a prototype with a compound compo-nent which is an instance of its class. As we have alreadymentioned, this process is the equivalent of proceduralabstraction in programming languages, and therefore pro-vides the basis for recursion. This is illustrated by Example3.4 below.3.3.7 Definition - evaluation

If σ and σ’ are states, X is a component, and S is a subsetof the simple components occurring in X, then (σ’, X, ∅) isan evaluation of (σ, X, S) iff for all x ∈ A• if x is an outport of Y for some Y ∈ S, then σ’(x) = func-

tion(Y) (σ(a1), …, σ(an)) where inports(Y) = (a1, …, an);• if x is an outport of some source occurring in X, then σ’(x)

∈ τ(x) ∪ {none};• otherwise σ’(x) = σ(x).

The evaluation rule describes the execution of a simplecomponent. Consider Example 3.3.5 where applying propa-gation resulted in the triple (σ’, X, { Sc }) where σ’(b) = 2,and σ’(a1) = σ’(a2) = σ’(c) = σ’(d) = none. Applying evalua-tion leads to the triple (σ”, X, ∅) where σ”(b) = 2, σ’(a1) =σ”(a2) = σ”(d) = none and σ”(c) = σ”(b)2 = 4.3.4 Discussion with an Example

In this section we work through an example, the recursivecomputation of factorial, which is clearly not intended toillustrate the value of component-based software, but to illus-trate the above definitions.

We assume domain D includes integers and that allattributes in this example have integer type. The compoundcomponent fact shown in Figure 8 is comprised of three sim-ple components, one prototype of fact itself, one inport x,one outport y, and five connections.

Formally, the component fact is defined as follows.fact = ({ f1, f2, f3, factPro},(x), (y), {(x, {t1, t2, i3}), (o2, {tf }),

(of, {t3}), (o1, {y}), (o3, {y})})

Figure 7: A Compound Component

The three simple components f1, f2, f3, are as follows.f1 = ((t1), o1, F1, {(0,m), (1,m) } ) where F1(i) = 1 for all

integers if2 = ((t2), o2, F2, {(n,m) | n > 1} ) where F2(i) = i - 1 for all

integers if3 = ((t3, i3), F3, {(n,m) | either n ≠ m or n = 1} )

where F3(i,j) = i *j for all integers i and jThe prototype factPro is defined as follows.

factPro = (factClass, tf, of )Where factClass is the class that contains the compound

component fact. These three components not only perform the basic com-

putations, but also control the execution flow of program.The function of f1 is to decide whether or not to invoke thebase case, and the function of f2 is to decide whether or notto invoke the recursive case, passing a value to f3 only if theincoming integer is greater than 1. The function of f3 is tocalculate the result as the product of the original integer andthe factorial computed by the prototype.

To illustrate the above definitions, we now describe theexecution of fact given a starting value of 2. The paragraphsthat follow describe successive triples in the execution, andshow how each triple is derived from the previous one. Ineach paragraph, we describe the new state by giving only theattribute values which have changed: attributes not men-tioned have the same values as in the previous state.

(σ0, fact, ∅)• σ0(x) = 2, and σ0(a) = none for all attributes a ≠ x.• Propagation applies since x ≠ none and x is the origin of

three connections. (σ1, fact, {f2})

• σ1(x) = none, and σ1(t1) = s1(t2) = σ1(i3) = 2.• Since σ1(t1) is not 1 or 0, f1 is not triggered. Since

σ1(t2) > 1, f2 is triggered.• Propagation does not apply since there is no origin with

a value other than none.• Expansion does not apply since the third element of the

triple is not ∅.• Evaluation applies, yielding the following triple.

(σ2, fact, ∅)

• σ2(o2) = 1.• Propagation applies since o2 ≠ none and is the origin of a

connection. (σ3, fact, ∅)

• σ3(tf ) = 1, and σ3(o2) = none.• Propagation does not apply since there is no origin with

a value other than none.• Expansion applies since σ3(tf ) ≠ none.

(σ4, fact’, ∅)• fact is replaced by fact’ as shown Figure 9(a). The com-

ponent fact” occurring in fact’ is shown in Figure 9(b).Like factPro, factPro’ is a prototype for the class ofwhich fact is a member.

• σ4(a) =σ3(a) if a is an attribute occurring in fact andσ4(a) = none otherwise.

• Propagation applies since tf ≠ none and is the origin ofthree connections.

(σ5, fact’, {f1’})• σ5(tf ) = none, and σ5(t1’) = σ5(t2’) = σ5(i3’) = 1.• Since σ5(t1’) is 1, f1’ is triggered. Since σ5(t2’) = 1, f2 is

not triggered.• Evaluation applies, yielding the following triple.

(σ6, fact’, ∅)• σ6(o1’) = 1.• Propagation applies since o1’ ≠ none and is the origin of

a connection. (σ7, fact’, ∅)

• σ7(o1’) = none, σ7(of ) = 1.• Propagation applies since of ≠ none and is the origin of a

connection (see Figure 9(a)). (σ8, fact’, {f3})

• σ8(of ) = none, and σ8(t3) = 1.• Since σ8(t3) is 1, f3 is triggered. • Evaluation applies, yielding the following triple.

(σ9, fact’, ∅)• σ9(o3) = σ1(i3)* σ8(t3) = 2*1 = 2.• Propagation applies since o3 ≠ none and is the origin of a

connection. (σ10, fact’, ∅)

• σ10(o3) = none, and σ10(y) = 2.• No rules are applicable so the execution sequence termi-

nates.The output, provided via outport y, is 2 which is the fac-

torial of 2.Although the above example is rather trivial, it does dem-

onstrate most features of our definitions. From the example,we see that the notion of “recursive component” is a naturalextension of the usual concept of component, and that theconcept of compound component includes the notion of“program”.

4 Further investigation As mentioned previously, the definitions presented above

have been implemented in a prototype software developmentenvironment consisting of a visual editor for building com-ponents by directly manipulating visual representations, andan interpreter.

Figure 8: The Compound Component fact

t2tf of

o2

x

t1 o1

i3

t3o3

y

Although the prototype is implemented in Java, it cur-rently does not take advantage of that fact by generatingbeans or by producing any other form of executable Javacode. However, Java is used to code the textual parts, that is,the functions of components and the relations of triggers.

In further development of the prototype, we will investi-gate the possibility of generating components according todifferent component standards, starting with JavaBeans.Although our definition covers the fundamental commonfeatures of the various component models, each model alsohas its own unique features. We need to find a way of “plug-ging in” modules that will accommodate these features.

Another visual language project that we are involved withis implementing the visual dataflow language, JGraph, thatprovides the features of Java and supports both the visualdevelopment of Java programs, and visualisation of programswritten in Java [14]. Component software development sys-tems require an underlying programming language to buildthe algorithmic portions of systems not addressed by compo-nent models. For example, Visual Age relies on Java (or otherlanguages); COM components interface with Visual Basic,Visual C++ and other languages. Since JGraph and the com-ponent model described here provide two complementarysoftware development methodologies via visual program-ming interfaces, we feel that merging the two could result ina much more consistent and natural combination of compo-nents and algorithmic programming than that achieved inproducts such as Visual Age.

5 AcknowledgementsThis research was supported by Natural Sciences and

Engineering Research Council of Canada Research GrantRGPIN124-99.

6 References[1] Allen R., Garlan D., (1997), A Formal Basis for Archi-

tectural Connection, ACM Trans. on Software Engineer-ing and Methodology, v6, n3, 213–249.

[2] Apple Computer Inc., (1993), OpenDoc – ShapingTomorrow’s Software White paper.

[3] Carrel-Billiard, M.; Akerley J., (1998), Programmingwith VisualAge for Java, IBM redbook.

[4] Drossopoulou S. and Eisenbach S., (1998), Towards anOperational Semantics and Proof of Type Soundness in

Java [online]. Available: http://www-dse.doc.ic.ac.uk/projects/slurp/pubs.html#towards

[5] D’Souza D. F. and Wills A.C., (1997). Objects, Compo-nents, And Frameworks with UML – the CatalysisApproach, Addison-Wesley, Reading, Mass.

[6] Gamma E., Helm R., Johnson R. and Vlissides J.,(1994). Design Patterns – Elements of Resuable Object-Oriented Software, Addison-Wesley, Reading, MA.

[7] Ibrahim R. and Szyperski C., (1998). Formalization ofComponent Object Model (COM) – The COMELLanguage, Proc. 8th PhD Workshop, ECOOP’98

[8] Jacobson I., Griss M., and Jonsson P., (1997). SoftwareReuse, Architecture Process and Organization for BusinessSuccess, ACM Press, Addison-Wesley Longman, NJ.

[9] Leach R. J., (1997). Software Reuse - method, models, andcosts, McGraw-Hill, NJ.

[10]Lewis T., Rosenstein L., Pree W., Weinand A., GammaE., Caulder P., Andert G., Vlissides J. and SchmuckerK., (1995). Object Oriented Application Frameworks,Manning Publications Co., Greenwich, CT.

[11]Magee J.,Dulay N., Eisenbach S., Kramer J., (1995),Specifying Distributed Software Architectures, Proc. 5thEuropean Software Engineering Conf., Spain, Springer-Verlag, Berlin, 137-153.

[12]Microsoft Corporation, (1995). The Component ObjectModel Specification, Version 0.9 [online]. Available http://www.microsoft.com/Com/resources/comdocs.asp>.

[13]Prieto-Diaz R., Neighbours J., (1986), Module Inter-connection Languages, Journal of Systems and Software 6,4 , 307-334.

[14]Risley, C.C., JGraph: A Java Compatible Visual Lan-guage, MCompSci Thesis, Dalhousie University.

[15]Shaw M., Garlan D., (1996), Software Architecture: Per-spectives on an Emerging Discipline, Prentice-Hall., NJ.

[16]Spivey J.M., (1989), The Z Notation, a Reference Man-ual, Prentice Hall, Englewood Cliffs, NJ.

[17]Sullivan K. J., Socha J., and Marchukov M., (1997).Using Formal Methods to Reason about ArchitecturalStandards, Proceedings of 19th International Conferenceon Software Engineering, Boston, USA

[18]Sun Microsystems, (1997). JavaBeans for Java Studio:Architecture and API, White paper.

[19]Szyperski C., (1998). Component Software, BeyondObject-Oriented Programming, ACM Press, Addison-Wesley, NJ.

t2tf of

o2

x

t1 o1

i3

t3o3

y

t2’tf ’ of ’

o2’

tf

t1’ o1’

i3’

t3’o3’

of

Figure 9: The expansion of fact(a) The component fact’ (b) The component fact”