Designing Evolution Aware Components in Java - CiteSeerX

Ready For Evolution : Designing Evolution Aware Components in Java Naiyana Tansalarak

Kajal T. Claypool

Department of Computer Science University of Massachusetts Lowell, MA 01854 ntansala
kajal  @cs.uml.edu

ABSTRACT Change in software systems is inevitable, and occurs as mistakes

1. INTRODUCTION Today, most systems are built on top of component technology.

are discovered in the initial design, or as part of incremental de-

However, building software systems using current component tech-

sign. In current multi-component systems, upgrading systems and

nology typically introduces multiple interactions between the dif-

consequently discovering what components are effected by a given

ferent components, thereby creating many dependencies. These

change is hard, and cannot be handled in an automated manner.

dependencies are typically not managed well and introduce numer-

This is mainly due to the fact that building software systems using

ous problems. We focus on the effects of these dependencies on

current component technology introduces a tangled web of compo-

component evolution. Software evolution in a component-based

nent dependency. All components in the system must be examined

architecture, requires discovering effected components, based on a

when the system is evolved in such a scenario, in order to propa-

change in some component, and the subsequent propagation of the

gate the change to all effected components. To address this compo-

change to all the effected components. In the absence of sophis-

nent dependency problem from a software evolution perspective,

ticated architecture-based tools, searching for effected components

we propose a Component-Connector-Contract (3C) Architecture.

would require tracing the interactions from the changed component

This architecture provides (1) the isolation of behavior and interac-

to all components in the system. For large systems, this search

tion between components; and (2) contracts for each method. The

tends to be an expensive and time-consuming problem, that often

3C architecture thus facilitates automated software evolution by (1)

renders the system unavailable for long periods of time. Clearly

providing a loose coupling of behavior and interaction between

this is unacceptable for mission-critical software systems, such as

components; and (2) providing different levels of dependency of

air traffic control, banking, telephone switching, and high availabil-

components, thereby reducing the search space for all components

ity public information systems, which cannot be taken down for a

effected by a change. In this paper, we provide an overview of the

long period of time for upgrades, thus requiring dynamic upgrade

3C architecture and show how the de-lineation between behavior

[7].

and interaction can be implemented using the current Java standard

It is therefore essential to reduce system-downtime and to in-

and JML. Keywords: component, connector, contract, component-level de-

crease system availability during the evolution process. One ap-

pendency, method-level dependency, 3C Architecture, system architecture

proach to this problem is to reduce the time complexity of the search space for effected components based on a single change, by providing better management of component dependencies. There are several approaches proposed in literature that have taken steps to address this problem of component dependency. To reduce com-

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Copyright 2001 ACM X-XXXXX-XX-X/XX/XX ...$5.00.

ponent dependency, Mediator Pattern (MP) [1] introduces the mediator to govern the interaction between components leading to a loose coupling between the individual components, but a tight coupling between the components and the mediator. However, from

Figure 1: The component-level (a) and method-level (b) dependencies the perspective of software evolution the mediator pattern does not

nents during a software upgrade, opposed to the complete search

offer any reduction in the search space when looking for effected

that would be required otherwise. To illustrate this, consider the

components. Rather it introduces an implicit dependency between

example in Figure 1. Here, component B and component C depend

components by replacing component to component dependency by

on component A via connectors. When methodA-1() of com-

component to mediator dependency which increases the search space.

ponent A is changed, the dependency of components in the system

To help discover what components are effected, Interface Con-

architecture is traced to determine the effected components. Under

nection Architecture (ICA) [5] defines all interactions between the

current architectures, component B, C and D must be examined to

components of a system using only the interface, not the actual

decide if they are effected. With explicit component-level depen-

components. While this aids in reducing the search for effected

dency as shown in Figure 1(a), it is self-evident that components B

components, the actual implementation still resides in components

and C are effected. However, this search for effected components

which makes the actual software upgrade difficult. Moreover, the

can be further refined by the method-level dependency as shown in

implementation of this requires new programming language con-

Figure 1(b). Based on this, it can be seen that only component C is

structs. In our work, we seek to address the deficiency of these

effected.

two approaches and provide (1) explicit dependency between com-

Figure 2 gives a high-level pictorial overview of our approach.

ponents; and (2) an implementation of our approach using current

Our approach has two perspectives: (1) the architectural perspec-

Java [2] technology.

tive; and (2) the implementation perspective. The architectural per-

To accomplish this, we take a two step approach. We first reduce

spective provides the two levels of dependency as described above.

the tight coupling of behavior and interaction between components;

We term this the dependency graph. To automate the evolution

and then use that to reduce the search space when searching for all

process, in the implementation perspective, the implementation of

components in a system effected by a change. To reduce the tight

a system should conform to the dependency graph.

coupling of behavior and interaction in components, we introduce

In this paper, we do not focus on the automation aspect of soft-

a new architectural concept, namely a connector. A connector en-

ware evolution, but rather focus on the dependency graphs and their

capsulates the interaction of one component with all other compo-

conformance in a Java based implementation. Our work makes the

nents in the system. A component then encapsulates only the local

following contributions:

behavior of a traditional component. A side-effect of this isolation of behavior and interaction is a new, explicit level of dependency which we term the component-level dependency. We also introduce contracts for methods. The contracts, introduced by [6], capture not only the pre- and postconditions, but also enable a methodlevel dependency. The two levels of dependency, component-level and method-level, enable a hierarchical search for effected compo-

 3C (Component-Connector-Contract) Architecture: We pro-

pose the 3C architecture that provides multiple levels of component dependency in an explicit way.  Implementation: The implementation of the 3C architecture

via interfaces and classes using current Java [2] technology.  Use of JML (Java Modeling Language): The use of JML

Figure 2: The Big Picture  Initially, the CopyButton and ClearButtons are disabled, and

[4] to validate the conformance of the specification in the implementation.

a list of items are displayed in the KidList.

The paper is organized as follows. Section 2 presents the work-

 When an item in the KidList is selected, the selected item is

ing example we use to discuss the details of our approach in Sec-

copied into into KTextField for editing and the Copybutton

tion 3 and Section 4. Section 5 surveys related work. Finally, Sec-

is enabled.

tion 6 concludes the paper.

2.

 When the CopyButton is clicked, the edited item in KTextField

WORKING EXAMPLE !" #

is added to the PickedList and the ClearButton is enabled.  Finally, when the ClearButton is clicked, the PickedList and

       

the KTextField are cleared, the KidList selection is deselected, and the CopyButton and ClearButtons are disabled. This interaction between the five components can be represented in the sequence diagram given in Figure 4. Here, when a user selects an item in KidList, KidList receives message valueChange(). KidList, then sends messages (1) setEnabled(true) to CopyButton to enable CopyButton, and (2) setText() to TextField to set TextField’s value as the text value passed in. = >? @ A B C D E WXYZ $%'&(% )+*

, -+.+/102, 3+4

Figure 3: The example with two list boxes, two buttons and one text box

6 7 89 :;7
=9 

x>=14 

x:=x+5

This denotes that if x >= 9 is ture before the instruction, then x of a component has a dependency relationship with methods of other components by depending on them. We term this methodlevel dependency. Consider the example in Figure 13. Here both component B and

>= 14 will be guaranteed to be ture after the instruction.

4.2 The Method-Level Dependency Graph Furthermore, Pre- and post-condition capture the interaction with

component C depend on component A. Now consider that methodA-

other components via the methods of their connectors. For exam-

1() of component A is updated which implies that component A has

ple, the select() method of KidConnector has the following

changed. Both component B and component C are considered to be

postcondition :

effected in this case. Ideally, however, only component C should be affected as can be seen in Figure 13. In this scenario, componentlevel dependency alone is not sufficient to reduce the search space

CopyConnector.getEnabled()

true and

iji

PickedConnector.getNumItem()

iji

old Picked-

Connector.add().getNumItem()

when searching for effected components. We thus introduce a new

This implies that the select() method of KidConnector interacts

level of dependency - the method-level dependency. We do so by

with CopyButton component via the getEnabled() method of

providing contracts for each method. As component-level depen-

CopyConnector, and with PickedList component via the add()

dency isolates all component dependency in the connector, we be-

and getNumItem() methods of PickedConnector.

lieve it is sufficient to provide contracts for connector methods only. We discuss contracts in Section 4.1, the method-level dependency

‰/Š‹ŒŽ
  Š

‘’x“•” – “'—

graph in Section 4.2, and implementing with JML in Section 4.3.

4.1 Contracts

its callers. This is done by expressing the specification in boolean expression which may involve some components in the system. The precondition defines the condition under which a call to a

¹
º » ¼ ¹ ¤

TextConnector { | } ~|/}

CopyConnector ˜ ™ š› œ/ ™

ClearConnector ÆxÇ È
É
Ê

£

We propose the addition of pre- and post-condition to each method of a connector to describe the contract [6] that a method defines for

½/¾ ¿'ÀÁÂ
à à ÄÅ

k l mn o/p l

 €  ‚€/

ž Ÿ  Ÿ
¡ ¢

¥ ¦ §
¨
© ª§¦ §
¥ « ¬ ­
®

PickedConnector KidConnector ƒ ¯ ° ± ²
³ ´±° ± ¯ µ ¶ · ¸

q r
s t u
vxw r
yzu

Ë ÌÍ ÎÐÏË Ñ Ò

„x…†… ‡ ˆ

method is legitimate, and the postcondition defines conditions that must be ensured by a method on return. We show this in a correct-

Figure 14: The method-level dependency of KidList component

The method-level dependency graph based on the example in

and run-time checking to check the conformance between specifi-

Section 2 is shown in Figure 14. When user selects an item in

cation and implementation. JML can currently support checking

KidList, KidList receives a message valueChanged() and then

existing variable type in specification, binding of variables in spec-

the interaction begins as follows; (1) the valueChange() method

ifications and implementations, and can generate run-time code to

of KidList sends message select() to KidConnector to inter-

support run-time checking. Currently, however, JML supports run-

act with KTextField and CopyButton via TextConnector and Copy-

time checking with parameter checking in precondition, thereby

Connector respectively, (2) KidConnector sends a message set-

limiting its usability.

Text() to TextConnector, (3) TextConnector sends a message

As in Section 3.3, a connector implements the interaction of its

setText() to TextField to set its value as the selected item passed

component with other components via their connectors by con-

in, (4) KidConnector sends a message setEnabled() to Copy-

forming to its interface. Thus, it is effective to add contracts in an

Connector and (5) CopyConnector sends a message setEnabled()

interface of each connector. See the information between the sym-

to enable CopyButton.

4.3 Implementing with Java and JML

bol /*@ ...

@*/ in Figure 15, and after the symbol //@ in

Figure 16. These are treated as comment in Java compiler but specification in JML. In Figure 15, the model fields are defined as variables used throughout the contracts in the interface. The contract of each method is defined in the form of logical statement right before each method signature. Precondition is specified in the require part and postcondition is specified in the ensure part. In Figure 16, the model fields defined in an interface are bounded with the variables defined in connector. This verifies whether the implementation in a connector conforms to the specification in an interface during run-time.

5. RELATED WORK This section briefly outlines several approaches to the dependency of components which have been proposed in the literature Figure 15: The structure of an interface for a connector with JML

[5, 1]. ÔÐÕCÖØ×CÕ/ÙCÚÛÙ/ÜCÝ

Þàß/áØâCßCã/äÛãCå

æÐçCèØéCç/êCëÛê/ìCæ

Figure 17: OCA Object Connection Architecture (OCA). Figure 17 illustrates this Figure 16: The structure of a connector with JML

approach pictorially. An object connection architecture (OCA)[5] consists of (1) interfaces specifying only features provided by the

One of the key components to fully utilize the usefulness of contracts is the verification of the contracts. We use JML2 [4] as a tool to verify the contracts for each method. JML provides both static Ó

9 JML stands for "Java Modeling Language". JML is a behavioral interface specification tailored to Java and developed by Iowa State University. Visit www.cs.iastate.edu.

module conforming to that interface, (2) a set of modules which each provides implementation of the features specified in the interface which that module conforms to. Thus, the interaction between modules is created and found in modules. This introduces a tangled dependency of components, requiring the searching of all compo-

nents to discover the effected component based on some component change.

Our goal is to make evolution of components less time-consuming and move towards a more automated approach to component upíÐîCïñðCîCòCózòCô/õ

grade. In this paper, we target reducing the time complexity of evolution. In order to achieve this, we focus on (1) reducing the need to search for effected components; and (2) localizing the search for ef-

Interface

fected components to a small sub-system when possible. We, thus propose to (1) isolate the behavior from the interaction between Interface

Interface


/þCý

öÐ÷CøØùC÷/úCûzúCü

ýÐþCÿ

components; and (2) provide contracts for each method of connectors, thereby providing two levels of dependencies, componentlevel and method-level dependencies. In this paper, we present our 3C Architecture and show how this can be implemented in Java [2] and JML [4]. We have presented our approach by walking through

Figure 18: ICA

the simple example in Section 2 as a prototype and implemented Interface Connector Architecture (ICA). Figure 18 illustrates

it with Java and JML. Source code for implementing this example

this approach pictorially. An interface connection architecture (ICA)

can be found at http://www.cs.uml.edu/ ntansala.

[5] is similar to Object Connection Architecture except that the in-

Our approach offers several advantages. It provides the clear dis-

terface specifies both provided and required features rather than

tinction between behavior and interaction, specification as embed-

only provided features. Thus, the interaction between modules is

ded in source code, the explicit component-level and the method-

found in interfaces. This requires new programming language con-

level dependencies and the automated evolution process. Moreover,

structs and the implementation of interaction between components

our introduced architecture can be implemented using the current

still resides in modules which makes the difficulty in software up-

programming language constructs, such as those provided in Java.

grade.

However, we have also now introduced a new entity (connector) to deal with the interaction of component, along with the tight cou-

 
   

pling of these connectors. We have also introduced a level of indirection when referring to components.

7. REFERENCES

! "$# %&

 
 

 
 

Figure 19: MP Mediator Pattern (MP). Figure 19 illustrates this approach pictorially. Mediator pattern (MP) [1] is one of behavior patterns that help define the interaction between components in a system and how the flow is controlled. It promotes loose coupling between the components in a system by introducing the mediator to govern the interaction between components. However, the dependency of components is made implicitly which makes the searching for effected components hard. This implies that all components might be examined.

6.

CONCLUSION

[1] J. W. Cooper. Java Design Patterns : A Tutorial. Addison-Wesley Publishing Company, Reading, Massachusetts, 2001. [2] H. M. Deitel and P. J. Deitel. Java How to Program (4th Edition). Prentice Hall, Upper Saddle River, New Jersey, 2001. [3] G. T. Heineman and W. T. Councill. Component Definition. Addison-Wesley Publishing Company, Reading, Massachusetts, 2001. [4] G. T. Leavens, A. L. Baker, and C. Ruby. Preliminary Design of JML. Iowa State University-http://www.cs.iastate.edu, 2001. [5] G. T. Leavens and M. Sitaraman. Foundations of Component-Based Systems. Cambridge University Press, 2000. [6] B. Meyer. Object-Oriented Software Construction. Prentice Hall PTR, Upper Saddle River, NJ, 1997. [7] P. Oreizy, N. Medvidovic, and R. N. Taylor. Architecture-based runtime software evolution. In Proceedings of the 20th international conference on software engineering. IEEE Computer Society, 1998.