Formal Specification of Components in a Component-BasedFramework Development Method

Kazuki Yoshida1 and Shinichi Honiden2

1System Integration Technology Center, Toshiba Corporation, Fuchu, 183-8512 Japan

2National Institute of Informatics, Tokyo, and Graduate School of Information Science and Technology, The University of Tokyo, Tokyo, 101-8430 Japan

SUMMARY

This paper presents a technique called FCF (Formallyspecified Component based Framework developmentmethod) to develop frameworks by connecting componentswhose functional aspects are formally specified. In FCF,three rules are imposed on component extraction/designfrom the perspectives of the framework’s hot spot and itsalgebraic specification. Then, on the basis of the rules,problems for specifying the functional aspect of a frame-work which is composed by connecting components areclarified, and these are solved by a descriptive device and atheoretical extension of algebraic specification. Then, usingthese solutions, the components of business transactionprocessing extracted and designed following the rules arespecified, from which the solutions are evaluated. © 2003Wiley Periodicals, Inc. Syst Comp Jpn, 34(8): 62–76, 2003;Published online in Wiley InterScience (www.interscience.wiley.com). DOI 10.1002/scj.10280

Key words: component; application framework;formal specification; algebraic specification.

1. Introduction

Components are now attracting attention as a tech-nology that will be the core to future software development.

The word “component” has a variety of meanings, whichcan lead to confusion when used in technical discussions.This paper defines “component” as follows:

[Definition]

A component is a type of implementation of reusableparts for software. As shown by “Component X” in Fig. 1,a component is a black box part that has one or more objectsinside during execution, with only its interfaces exposed tothe outside.† Normally, components are provided with avisual development environment and are expressed as iconson it. By operating the icons using a mouse, the user candefine compositions of components, customize compo-nents, and immediately execute them. "

The method of developing a framework by connect-ing components is called CBF (Component-Based Frame-work development method) in this paper. CBF improves theproductivity of framework development because it releasesthe developers from the iteration of design/implementationintrinsically enforced by the framework development fromscratch as well as reducing the amount of effort in imple-mentation.

In an application program development based on thismethod, three types of developers are involved: component

© 2003 Wiley Periodicals, Inc.

Systems and Computers in Japan, Vol. 34, No. 8, 2003Translated from Denshi Joho Tsushin Gakkai Ronbunshi, Vol. J85-D-I, No. 2, February 2002, pp. 210–227

†The components referred to here are not limited to specific infrastructuressuch as ActiveX and JavaBeans.

62

developers, framework developers, and application devel-opers (see Fig. 2).

The patterns shown in Ref. 12 provide componentdevelopers with a guideline for component design by help-ing them to understand the structure and interface of com-ponent classes. However, since a component’s functionalaspect is not specified in the patterns, it should be specifiedin other forms by component developers. This would an-swer the question by framework developers: “Are thesecomponents just the ones we’re looking for?”

The specification language should have a descriptivemechanism to generate a composed specification for theframework from a set of specifications for each component,and also have a verification mechanism to prove the consis-tency of application programs based on the framework.These mechanisms would be used by framework develop-ers and application developers, respectively.

According to this technical motivation, this paperproposes FCF (Formally specified Component-basedFramework development method), a specialized version ofCBF, which uses components whose functional aspects areformally specified. Algebraic specification [11] is adoptedas a formal specification language because it is suitable forspecifying the functional aspect of programs and it can beexecuted and verified as a term rewriting system.†

This paper is structured as follows: In Section 2, threerules are imposed on the extraction/design of componentsfrom the perspectives of both hot spots‡ in frameworks andits algebraic specification. In Section 3, problems for speci-fying the functional aspect of a framework which is com-

posed by connecting components are clarified on the basisof the rules. In Section 4, these problems are solved by adescriptive device and a theoretical extension of algebraicspecification. In Section 5, using the solutions in Section 4,the components of business transaction processing ex-tracted and designed following the rules in Section 2 arespecified, from which the solutions are evaluated. In Sec-tion 6, related works are surveyed, and Section 7 concludesthe paper.

2. Rules on Extraction/Design ofComponents

In FCF, three rules are imposed on the extraction/de-sign of components from the perspectives of both hot spotsin frameworks and its algebraic specification, which areexplained below.

In general, the following three points could becomehot spots in programs:

• a sequence of messages (dynamic aspect)• a process within a method (functional aspect)• data to be processed (structural aspect)

In order to cope with hot spots, components should beextracted and designed to provide flexibility on the abovethree points.

As to the first point, a sequence of messages is treatedon the principle that a sequence is determined regularlyfrom the structure composed by connecting a set of com-ponents such as in Fig. 3 and made to be variable byreplacing any one of them with another. This means that in(1) of Fig. 3, for example, the message sequentially flowsfrom “a1” to “b1,” “c1,” “c2,” and “c3,” using Component“b1” that sequentially calls child components. By replacing“b1” with “b2” that calls by selecting one child component,the message is changed to flow by selecting “c2” after themessage passes from “a1” to “b2” as shown in (2).

However, in this case, if more than one messagesequence that is not interrelated to others is crossed on onecomponent in the composition, replacement of this compo-

Fig. 1. Conceptual model of components.

†This paper construes algebraic specifications as those that are based onorder sorted algebra and initial semantics, which is an extended system ofRef. 11.‡According to Ref. 8, a hot spot is defined as “a portion that must be readyto flexibly cope with a situation that cannot be forecasted in an applicationdomain.”

Fig. 2. Three types of developers.

63

nent with another to change the flow of one sequence mayhave a side effect on the flows of others. If a message flowsfrom Component “c1” to “b1” in Fig. 3 (1), the subsequentflow of message will change as in the flow from a1 bychanging “b1” to “b2.” This may not necessarily be whatwas intended. Therefore, caution must be needed in imple-menting the policy of changing a message sequence bychanging a component composition, provided that severalmessage sequences are crossed on one component.

As shown in Fig. 4, let us assume that componentsare connected so that the message always flows in one fixeddirection from one component as the starting point. Whereseveral message sequences mutually have side effects asmentioned above, they are implemented individually.

On the other hand, portions that can be made commonexist in several subsequences of one sequence, the connec-tion from several components to one component that imple-ments the process of this common portion should beallowed as shown in Fig. 4. But the structure should neverpermit a recursive chain of message sequence in it so thatthe sequence can be expressed as a term of algebraic speci-fication. Therefore, the following rule is imposed on theextraction/design of components.

Rule 1

Components are connected in a directed acyclicgraph (DAG) structure with one root and the message

sequence is determined according to the direction of eacharc.

Regarding a process within a method at the secondpoint, the process of hot spots is extracted on a componentlevel so as to allow them to be plugged in each componentin the composition which has been connected beforehandas mentioned above. To accomplish this, extraction of com-ponents has to be done so that the process provided bycomponents does not mutually couple with the process ofothers. Portions that could become hot spots must then beidentified in the processes. They are implemented by otherclasses as shown in Fig. 5.

Such separation only requires a specification of thehot spot to be described depending on where the componentis used, without changing the specification description ofthe component itself. This will clarify description range andreduce description volume for an application developer.

Therefore, the following rule is imposed.

Rule 2

In a process within a method, hot spots should beextracted and implemented separately in other classes.These classes are called customizing classes in this paper.†

As to the third point about data to be processed, itmust be decided in the design phase whether data variationcan be handled by a difference of constituents (i.e., pairs ofkey and value) in the same type or by a different type. Theformer is chosen in case the data is treated passively, andthe variation of processes depending on the data variationis implemented in customizing classes according to Rule 2.The latter is chosen in the other case. This means each typeof data is defined as an individual class, and a processspecialized for the type of data is implemented in the dataclass, not in the component class. The component classsends a message to the data class for the specialized process.Therefore, the following rule is imposed in addition to theprevious two rules.

Fig. 4. A composition and a message sequence.

Fig. 5. Separation of a hot spot from component.

†A framework developer provides a framework composed by connectingcomponents, and an application developer implements customizingclasses for application-specific processes and plugs them in the compo-nents. Therefore, a part to be developed can be treated separately for eachtype of developer and phase in the development process. This also gives aclear separation of the testing range for each type of developer or areduction of the regression testing volume.

Fig. 3. Component’s replacement and message flows.

64

Rule 3

A variation of process depending on the data vari-ation is implemented in customizing classes or data classes.Never implement it directly in component classes.

In FCF, components are supposed to be extracted anddesigned following the above three rules.

3. Problems in Algebraic Specification ofthe Components in FCF

In order to specify the functional aspect of the com-ponents that are extracted and designed following the threerules in Section 2, algebraic specification must solve thefour problems, which originate from the perspective of theterm rewriting system.

For Rule 1,

Problem 1

Composition of components in a DAG structure mustbe expressed as a term.

This problem is broken down into the following fivesubproblems.

Problem 1-1

A message sequence from a root to a leaf must beexpressed as a term, then the execution of the sequence mustbe expressed by way of term rewriting.

Problem 1-2

A component can choose to execute one child com-ponent among many for the succeeding process, so thismust be expressed by way of term rewriting.

Problem 1-3

A component can choose to execute several childcomponents sequentially for the succeeding processes, sothis must be expressed by way of term rewriting.

Problem 1-4

A component can choose to execute several childcomponents in parallel for the succeeding processes, so thismust be expressed by way of term rewriting.

Problem 1-5

A component can choose to execute one child com-ponent iteratively for the succeeding processes, so this mustbe expressed by way of term rewriting.

Problem 2

Both output values and return value of the executionmust be obtained together as a result of the term rewritingcorresponding to the execution.

For Rules 2 and 3,

Problem 3

Undefined must be expressed explicitly in the speci-fication of component for the processes separated intocustomizing classes or data classes.

For convenience to the developer (although it hasnothing to do with any rule),

Problem 4

Premises in which an equation holds should betreated with it.

The above problems are considered to be solved bythe two approaches:

• Descriptive device on algebraic specification toProblems 1 and 2

• Theoretical extension of algebraic specification toProblems 3 and 4

In the next section, these two approaches are explained inturn.

4. Solutions to the Problems

4.1. Interfaces of components

Figure 6 shows input, output, and other elementsrelated to interfaces for executing functions of the compo-nents on an external specification level.

These input, output, and other elements are interre-lated in the process of the methods implemented by thecomponents. When attempting to describe this method inan algebraic specification, generally, the relationships be-tween “Input” and “Input to the child component,” between“Input to the child component” and “Return from the childcomponent,” and between “Return from the child compo-nent” and “Return,” are defined as operators respectively atfirst. Then the method is expressed as a term which iscomposed of the operators. However, an operator of therelationship between “Input to the child component” and“Return from the child component” is specified in a childcomponent. Thus, this expression is not closed in one

Fig. 6. Interfaces of component.

65

component. Originally, the specification of a componentshould be described assuming which component can beconnected as a child is varied by its usage. For this reason,the expression mentioned above is not suitable as a speci-fication description of a component. Thus, instead of de-scribing an entire process collectively, it is divided into a“preprocess” portion in which “Input” is processed and amethod of a child component is called, and into a “post-process” portion in which “Return from the child compo-nent” is processed and the result of it is returned to theparent component as “Return”. The pre- and postprocessportions are specified independently. The “Exception” ishandled as a special case of “Return.” (See Fig. 7.)

4.2. Descriptive device on algebraicspecification

A DAG structure with one root in Rule 1 is decom-posed into two dimensions: vertical composition (see Fig.8) and horizontal composition (see Fig. 9).

For Problem 1-1, a message sequence of the preproc-esses and a return sequence of the postprocesses should beexpressed by way of term rewriting at the same time. Forthis purpose, Process sort is declared as follows:

[]P: Hashtable, Hashtable, Return → Process

Process sort is a set of terms comprising the operator “[]P”with two terms of Hashtable sort (see the Appendix for itsspecification) and one term of Return sort explained later.The first Hashtable represents input data, which enables thehandling of arbitrary numbers of arguments for a method.The second Hashtable represents the external state of acomponent, in which a set of output data to a database, etc.is stored in a Vector (see the Appendix for its specification)associated with a key of the target output name. The Returnsort is declared as follows:

[]R: Hashtable, Object → Return

Return is a set of terms comprising the operator “[]R” witha term of Hashtable expressing the external state of acomponent and a term of Object expressing a return value.

The implementation for a term rewriting system shouldmake it possible to substitute a term of any sort inheritingObject in the return value. This will enable the handling ofreturn value of any sort from a method. The exception isexpressed by the constant term Exception and is also re-turned as a special case of a return value. In the rest of thispaper, terms of Process sort are expressed “[hin, hout, r]P”and terms of Return sort, “[hout, oret]R.”

Using Process sort, the signature of an operator rep-resenting preprocess portion in the method of each compo-nent in Fig. 8 is declared as follows:

Using Return sort, the signature of an operator repre-senting postprocess portion is declared as follows:

Fig. 7. Pre- and postprocess.

Fig. 8. Vertical composition of components.

Fig. 9. Horizontal composition of components.

66

This enables the description of a sequence of callchains between components as a term as follows:

where

r: result of postprocess after executing “method1”, . . . ,“methodn–1” and “methodn”

Pre- and postprocess can be expressed as term rewrit-ing by the following group of equations to this term:

In the above rewriting, the Operators “methodi_in”and “methodi_out” have the following signatures:

These signatures divide the preprocess of “Componenti”into a generative process portion of input data to “Compo-nenti+1” and into an output process portion to the outside.These portions are represented as individual operators.Specific descriptions of their specifications vary from onecomponent to another and are omitted in this paper.

The operator “compose” is specified as follows:

“Substitute2 (r1, r2)” is a special operation to substitute thevalue in “r2” for “r1” and to return “r2.” [“Substitute1(r1, r2)”performs similar substitution and returns r1.] Thus, “com-pose” returns, as a result, a term comprising the subterms“method1

−1,” . . . , “methodn−1−1 ,” and “methodn

−1 ” that weresubstituted in variables connected one after another byreference. In other words, postprocess is expressed as thefollowing term that is configured in the variable “r” as astarting point as a result of the rewriting of the foregoingterm:

In the above term, “hin_i” receives input data to “methodi.”“hout_n” receives the external state of the component imme-diately before executing “methodn.” “null” shows that areturn value does not exist because a child component is notconnected to “Componentn.” Thus, Problem 2 can be solvedtogether.

The variables such as “r” and “r1” in the explanationsabove are supposed to be declared particularly and to bekept maintained in the memory of system during a series ofterm rewriting even though they are not included in termsgenerated by the rewriting. Results of such rewriting fromthe terms substituted in the variables at first are supposedto be maintained in them. In this paper, variables of this kindare declared in specifications by italic letters. The introduc-tion of such variables causes side effects in describing andunderstanding specifications and may impair “simplicity of

*“X” is defined as a set of variable symbols. Hereafter, variable symbolsused in equations are shown in this form.†A constant term of Hashtable sort. This means an empty state in whichHashtable has no element inside. Defined in the Appendix.‡A constant term of Object sort. This exactly means “null.” Defined in theAppendix.

Fig. 10. Operators representing pre- and postprocess invertical composition.

67

semantic definition” and “reference transparency,” whichare the characteristics of algebraic specification. But thepurpose here is to simultaneously accomplish chains of pre-and postprocess by a series of term rewriting, and variablesare used only to configure postprocess terms. The foregoingterm

and the following term for postprocess obtained by rewrit-ing the above term

could be equivalently converted into one term in a synthe-sized form, as shown below, without causing semantic sideeffects:

Here, the operator “[] P” is declared as follows:

[]P: Hashtable, Hashtable → Process

(First Hashtable represents input data, and second Hash-table represents external state of the component.) The op-erators “elemin” and “elemout” are specified as follows:

Nevertheless, the foregoing term contains a repetition ofsub terms

in it and is redundant in its configuration. The meaning ofit is rather difficult to understand intuitively. Therefore, theintroduction of variables can be looked upon as a way tosolve this difficulty that is caused by strictly following theorthodox description based on initial semantics of algebraicspecification.

Consider the cases in which compositions of compo-nents in Problems 1-2, 1-3, and 1-4 are as shown in Fig. 9.In all these problems, the signature of an operator repre-

senting the preprocess portion in the method of “Compo-nent a” can be defined as follows:

As a term, “methoda” can be expressed as follows:

where “hchild” is a variable in which the following term issubstituted, and is used to make descriptions easy to read:

In this term, each of several child components connected toComponent a, which is expressed as a term including a callchain, is described in association with a key.

Only a solution to Problem 1-3 is explained here. Forsimplicity of description, it is assumed that input data froma parent component is handed over to a child component asit is and there is no output to the outside.

Fig. 11. Operators representing pre- and postprocess inhorizontal composition.

*A constant term of Vector sort. This means an empty state in which Vectorhas no element inside. Defined in the Appendix.

68

The operator “sequential” generates a term recur-sively composed by the subterm resulting from the opera-tion “call” and “+.” This recursion continues until the resultof the operation “getkeys” (it is a vector of keys for childcomponents selected as succeeding processes) is gonethrough.

The operator “call” is specified as follows:

This keeps a series of term rewriting going on for a termrepresenting a call chain from a selected child componentby reconfiguring each operator recursively from the outsideof the term till reaching a term of Process sort that ulti-mately becomes an argument, and by substituting it with aterm that has been the result of execution precedent to thechild component.

“t1 + t2” expresses a sequential process in term rewrit-ing, that is, term rewriting for “t2” is started after termrewriting for “t1” has been finished according to the left-most rewriting strategy. “+” is an operator with the follow-ing signature:

+ : Process, Process → Process

“h” and “v” declared as variables in the memory ofsystem are distributed to several sequences in subsequentterm rewriting. In these sequences, “h” and “v” are sup-posed to be referenced commonly and terms in the variablesare rewritten by several sequences.

An iterative execution in Problem 1-5 can be ex-pressed by using the operator “+.” For example, an iterativeexecution from “Componentn–1” to “Componentn” in Fig.10 is specified as follows:

The operator “repeat” recursively generates a termconsisting of “+” and gives it to an argument of “methodn”of a child component to express the start of iterative process.“methodn” is specified as below to show that iterative inputwill be processed:

In describing specifications for Problems 1-3, 1-4,and 1-5, variables for external state and return value of acomponent are declared by “h” and “v,” respectively, andare handed over to child components. In Problems 1-3 and1-5, however, a term configured by “+” and a term forpostprocess obtained by rewriting it can be equivalentlyconverted into one term that has no side effects semanticallyas in Problem 1-1. In Problem 1-4, however, the rewritingof “h” and “v” is randomly performed among child compo-nents so that the equivalent conversion cannot be realized.Therefore, the term cannot be interpreted within initialsemantics and the definition of new semantics is necessaryin the case where several child components are processedin parallel. Establishing how to describe specification forthis problem will be considered in a future work.

Thus, all problems related to Problems 1 and 2 withthe exception of Problem 1-4 can be solved through devicescontrived in describing algebraic specifications.

*“addElement” is an operator that adds an element to a term of Vector sort.Defined in the Appendix.†A constant term of Process Sort. This means processing is not performed.

69

4.3. Theoretical extension of algebraicspecification

In order to solve Problems 3 and 4 mentioned inSection 3, the following two extensions are introduced tothe original algebraic specification language:

1. The symbol “∆” is introduced to express “unde-fined” or “omission of specifying exception handling proc-ess.” This introduction can reduce the description volumeof specification compared with the usual case in definingthe constant symbol of the same meaning because theintroduction is reflected to equational calculus beforehand.

2. The symbol “imply” is introduced to comprise aconditional equation, and along with these two introduc-tions, equational calculus is also extended. Because of theseextensions, it gets easier to specify the case in which processvaries depending on the input data value.

In this section, these extensions are explained theoreticallyas a summary of Ref. 10.

First, “∆” is added in the definition of terms.

Definition 1

An extended set of terms T*(Σ, X) is defined asfollows.

1. A set of terms T(Σ, X) is defined inductively bythe following three rules.

(1) For any variable symbol x ∈ X, x ∈ T (Σ, X).(Σ is an arbitrary signature and X is an arbitrary set

of variables.)(2) For any constant symbol σconst ∈ Σ, σconst ∈ T

(Σ, X).(3) For any operation symbol σope ∈ Σ, if t1, . . . tn

∈ T (Σ, X), then σope (t1, . . . , tn) ∈ T (Σ, X).2. T*(Σ, X) is defined using T(Σ, X) as follows:

(S is an arbitrary set of sorts.) "

Moreover, equational calculus is extended to cope with“imply” along with “∆.”

Definition 2The following set of conditional equations is denoted

by TAUT(Σ).

Definition 3

The following two deduction rules are defined inaccordance with the introduction of “∆” and “imply.”

For any set of conditional equations A,(D1) for any set of equations G and any equation t =

t′ ∈ G,

(D2) if (H imply t = t′) ∈ TAUT(Σ) ∪ A, andA b (G imply a(p) = a(p′))† for any equation

Then this calculus is proved to be complete [10].

Theorem

Let A be an arbitrary set of conditional equations andG be an arbitrary set of equations. Then,

Thus, the theoretical foundation of algebraic specifi-cation for extensions 1 and 2 is guaranteed by this theorem.The validation or verification of the extended algebraicspecification is realized by the conditional term rewritingsystem, which has already been established.

From the above results, Problems 3 and 4 can besolved by the extended algebraic specification.

5. Evaluations in the Example Components

In this section, the evaluations of the solutions in theprevious section are explained in the example components.A set of components for business transaction processingwhich conforms to the three rules in section 2 consists offive components; “TransactionType,” “Classify,” “Split,”“Transform,” “Store.” A framework is composed by con-necting them in a DAG structure using “Transaction Type”

"

"

*φ is an empty set. †a replaces symbols for variables with other symbols.

"

70

as a root and “Store” as a leaf. Figure 12 shows an exampleof connecting them.†

A set of processing with database executed by asequence of messages on this structure is handled as onetransaction. The functional aspect for each of the five com-ponents can be specified in algebraic specification using thesolutions. As an example, the specification for “Transform”(only the normal process portion) is shown in Section 5.1because it is compact but uses many solutions. Then someconsiderations are described in Section 5.2 on the quantita-tive data for the specifications of all components.

5.1. Functional specification of “Transform”component

“Transform” receives a Hashtable object of a dataitem name and its value as an input from the parent compo-nent, and passes it to the customizing class “Trans-formRule.” “TransformRule” generates a set of Hashtableobjects and returns a Vector object containing them. Then“Transform” passes each of them to the child component(see Fig. 13). A return value from “Transform” is void.

A normal process portion in the functional aspect of“Transform” can be specified in algebraic specificationusing the solutions as follows.

5.2. Consideration

A set of components for business transaction proc-essing needs 49 equations for specifying normal processportion in the components, 33 for exceptional process por-tion, and 20 for common process portion shared by compo-nents. Table 1 shows how many equations among them useeach solution.

The solutions for Problems 1-1 and 2 are applied tothe upper layer of specification for each component. Theywould be applicable not only for FCF but also for specify-ing the execution sequence between ordinary programmodules.

The solutions for Problems 1-2, 1-3, and 1-5 areapplied to the middle layer of specification for “Classify,””Split,” and “Transform,” respectively. Generally, a termexpression can be applied smoothly to the process which iscomposed of submodules in bottom up manner, but it needssome descriptive device for the successive chain of proc-esses on the DAG structure from top to bottom. Thus, theyare thought to be solutions generally required in algebraicspecification.

In the normal process portion, the theoretical exten-sion for Problem 3 is applied to “Transform” and “Classify”

Fig. 12. Telephone call billing and tax calculation.

Fig. 13. “Transform” component.

†Service accounts for individual customers (Store) are connected beneath“Network usage duration” (Classify) and “Billing” (Classify). Theseservice accounts are omitted in the diagram.

71

which have customizing classes. And the one for Problem4 is applied to the process for database access in “Store.”Thus, there are low applicabilities in the normal processportion, but on the other hand, they are high in the excep-tional process portion because the exceptional case oftenassumes a complicated precondition. For example, the sec-ond equation for “methodtransform” in the specification of“Transform” is changed into two conditional equationswhen considering the exceptional case.

This specification expresses throwing exception when nullis returned from a customizing class.

Therefore, the theoretical extensions can be con-cluded effective for FCF in specifying the exceptionalprocess portion.

6. Related Work

There are few case studies that apply algebraic speci-fication to frameworks and components. In Ref. 3, a part ofthe event handling mechanism in an application frameworkET++ is specified using Spectrum, a variant of an algebraicspecification language. Three problems in specifying theframework by algebraic specification are described in it:

(1) Specifying superclass by a set of equations asaxioms needs an understanding of its subclasses. Thus, thescope of what should be understood for specifying it israther large.

(2) In ET++, the event handling mechanism can becustomized depending on the context. But this makes itimpossible to specify many of the functions completely.

(3) It is difficult to specify a network structure forobjects interconnected in a complicated manner in alge-braic specification.

In FCF, neither (1) nor (2) can happen because thecustomization of components is always done by plugging-in customizing classes, not using inheritance, so the speci-fications for the customizing classes are separated from theones for components. When nothing is plugged in, “∆” isused in the component specification as “undefined” [10].(3) cannot happen either because FCF assumes a DAGstructure of components composition, whose specificationcan be described using the solutions in this paper.

Because the case studies are so few, related works aresummarized here in a wider range. Reference 1 describesthree approaches in formalizing object-oriented modeling:

1. Replacing part of models informally specified bynatural language with formal language,

2. Extending a formal language by introducing ob-ject-oriented features in it,

3. Integrating informal modeling techniques withformal languages.

With respect to approach 2, extension of many formallanguages has been tried. In algebraic specification, Maudeconcurrent object model [2] is a milestone to enable speci-fying state changes and concurrency. But in this model, aprocess within a method is not specified, so it does not meetthe requirement by FCF.

With regard to specifying components, equivalenceof states in a blackbox component is defined in behavioralsemantics [4–6] from the viewpoint of component users,and a verification method for the equivalence is proposed[5, 6]. In this paper, on the other hand, a state is directlyexpressed in the specification and a state transition causedby the process is specified in each component from theviewpoint of component developers.

With respect to approaches 1 and 3, for example, theactivities in pUML [7] correspond to 3. Although most ofthe researches in 3 focus on generating formal specifica-tions from informal models, the research in pUML is clari-fying mappings from the constructs in the modeling domainto the structure in the semantic domain formally specified.Thus, developers can rigorously analyze the semantic do-main while operating UML models directly.

OCL [8] adopted in UML as a language to specifyconstraints and rules in class diagrams corresponds to 1.Moreover, in pUML mentioned above, Z [9] is adopted asa specification language complementing diagrammatic ex-pression in UML.

Table 1. Equations using solutions

72

7. Conclusion

This paper introduced FCF, the method of developinga framework by connecting components whose functionalaspects had been formally specified. Then, problems forspecifying components of FCF in algebraic specificationwere described, and the solutions by descriptive device andtheoretical extension of algebraic specification wereshown. They were applied to the specifications of compo-nents for business transaction processing and proved to beeffective.

From the algebraic specification of componentsbased on the results in this paper, the component developerscan check the correctness of the components’ functionalspecification before implementation as well as they canunderstand strictly the components which have been imple-mented by others. For the framework developers, on theother hand, they can find the component which is providingthe needed functions, so their framework assembling worksare getting more efficient. Moreover, for the applicationdevelopers, it enables the functional verification of theapplication program based on the framework [13] althoughit is not explained in this paper.

Problems remaining to be solved for growth andspread of FCF can be summarized as follows:

(1) The solutions in this paper are applied in other setsof components and evaluated on their effects.

(2) The productivity of developing framework in FCFis evaluated quantitatively in many cases.

(3) The semantics for the case in which a componentchooses to execute several child components in parallel isdefined, then how to describe the specification for the caseis established.

(4) A verification method of the framework on thelevel of specification is established.

(5) Based on the solutions in this paper and theverification method in (4), a verification system is imple-mented.

Acknowledgments. Special thanks are due to Mr.Naoki Endoh, General Manager, Mr. Shigetoshi Shirabe,Senior Fellow, and Mr. Toshio Okamoto, Group Manager,of System Integration Technology Center of Toshiba Cor-poration, for giving us the opportunity to conduct thisresearch.

REFERENCES

1. France R, Evans A, Lano K, Rumpe B. The UML asa formal modeling notation. UML’98—Beyond thenotation. LNCS. Springer; 1998.

2. Meseguer J. A logical theory of concurrent objectsand its realization in the Maude language. In: Agha,

Wegner, Yonezawa (editors). Research directions inconcurrent object-oriented programming. MIT Press;1993. p 314–390.

3. Bergner K, Rumpe B. Event handling in ET++: Acase study in the algebraic specification of objectoriented application frameworks. TUM-19503, Tech-nische Universitat Munchen, 1995.

4. Diaconescu R, Futatsugi K. CafeOBJ Report, AMAST Series in Computing 6. World Scientific; 1998.

5. Goguen JA, Malcolm G. A hidden agenda. TechnicalReport CS97-538, UCSD Technical Report, 1997.

6. Matsumoto M, Futatsugi K. Test set coinduction—Toward automated verification of behavioral proper-ties. Proc Second Int Workshop on Rewriting Logicand Its Applications. Electronic Notes in TheoreticalComputer Science. Elsevier Science; 1998.

7. The precise UML group home page,http://www.cs.york.ac.uk/puml/

8. OMG. Object Constraint Language Specification,version 1.3. OMG; 1999.

9. Spivey JM. The Z notation: A reference manual, 2nded. Prentice–Hall; 1992.

10. Yoshida K, Ohsuga A, Nagata M, Honiden S. ∆-ex-tension of algebraic specification. J Inf Process1992;15:177–186.

11. Ehrig H, Mahr B. Fundamentals of algebraic specifi-cation 1. Equations and initial semantics. Springer-Verlag; 1985.

12. Gamma E, Helm R, Johnson R, Vlissides J. Designpatterns: Elements of reusable object-oriented soft-ware. Addison–Wesley; 1994.

13. Yoshida K, Honiden S. A formal specification ofapplication programs using component-based frame-work technology. IPSJ SIGSE(2000-SE-129)2000;104:113–120.

14. Pree W. Design patterns for object-oriented softwaredevelopment. Addison–Wesley; 1995.

APPENDIX

1. Specification of the Common ProcessingPortion for All Components

73

2. Specification of the Example Components

2.1. Functional specification of “Split”component

“Split” receives a Hashtable object of a data itemname and its value as an input from the parent component,then according to the mapping definition, generates a set ofHashtable objects, each of which is a subset of an inputHashtable and is passed to the designated child component(see Fig. 14). A return value from “Split” is void.

2.2. Functional specification of “Store”component

“Store” receives a Hashtable object of a data itemname and its value as an input from the parent component,then inserts the input into some table of database when arecord with the same primary key has not yet existed in it,otherwise updates the record with the same primary key bythe input (see Fig. 15). A return value from “Store” is void.

Fig. 14. “Split” component.

*tn is a name of table for insert or update. pk is a name of primary key.

74

AUTHORS

Kazuki Yoshida received his B.E. degree in industrial engineering and management and M.E. degree in system sciencefrom Tokyo Institute of Technology in 1987 and 1989 and joined Toshiba Corporation. From 1995 to 1997, he was a visitingscholar at the University of Illinois at Urbana Champaign. At present, he is a technical specialist at the Systems IntegrationTechnology Center of Toshiba Corporation. His current research interests include software reuse, object-oriented methodology,and formal specification. He is a member of the Information Processing Society of Japan.

Fig. 15. “Store” component.

†hout is supposed to have a set of records as a value associated with a tablename as a key.

‡Only uniqueness of primary key is checked as a constraint for insertprocess due to simplifying the specification in this paper. Thus, otherconstraints generally checked in database are not specified here.

75

AUTHORS (continued)

Shinichi Honiden received his B.E., M.E., and D.Eng. degrees in electrical engineering from Waseda University in 1976,1978, and 1986. From 1978 to 2000 he was with Toshiba Corporation. Since 2000, he has been a professor at the NationalInstitute of Informatics, Japan. He has also been a professor in the Graduate School of Information Science and Technology,The University of Tokyo, since 2001. His research interests include agent technology, object-oriented methodology, and softwareengineering. He is a member of the IEEE Computer Society, the Information Processing Society of Japan (IPSJ), and the JapanSociety for Software Science and Technology. He received the 1986 Paper Award from IPSJ.

76