Java Components in BoxScript

Yi Liu and H. Conrad Cunningham Department of Computer and Information Science, University of Mississippi, University, MS, 38677 {liuyi, cunningham}@cs.olemiss.edu

Abstract Component-oriented software development has become Component-oriented software development has become an an important approach to building complex software important approach to building complex software systems. systems. Object-oriented programming (OOP) languages This paper describes the component-oriented language have been the predominant approach to the design of BoxScript whose design seeks to support the concepts of component-oriented programming applications. However, components in a clean, simple, Java-based language. This practice shows that OOP technology does not fully provide paper presents the key concepts and syntax of BoxScript the above properties and leaves unsatisfied some of the and how it supports compositionality and flexibility and needs for development of complex component-oriented gives an example to illustrate its usage. applications [14]. The main difficulties lie in the implementation inheritance feature and composition 1. Introduction strategy of OOP languages. Implementation inheritance is Component-oriented programming is a programming whitebox reuse [5]. A derived class is very tightly coupled paradigm in which a software system can be built quickly to its base classes and thus breaks the base class and reliably by assembling a group of separately developed encapsulation. This may also bring safety problems, e.g., software components to form the system. The two most the fragile base class problem [9]. In component-oriented important properties of component-oriented programming applications, if implementation inheritance is applied across are flexibility and compositionality. Flexibility allows different components, then the strong encapsulation among programmers to adapt a component-oriented system to components is broken and any changes made to the base changing requirements by replacing, adding, or removing a class may cause unpredictable effects. The resulting few components. A component-oriented application is built component is not compositional. The composition strategy by assembling components. This requires the selection of in OOP is awkward and inefficient because programmers suitable components and effective strategies for assembly. may need to build extra classes to accomplish composition. The components should be compositional. That is, when There is a need for programming languages that can components are selected and assembled into a system, the provide safer composition strategies and cleaner component behavior of the system should be predictable based on the concepts. This research is to design a component-oriented behavioral specifications of the components. Strong programming language that should be easy for novices to encapsulation of the internal details of components is learn and should provide convenient syntactic support for needed to provide the desired flexibility and component concepts. compositionality. The initial motivation for this work arose from the A component can be represented as shown in the diagram authors’ experience in a college class on component in Figure 1. A component’s internal design and programming [2]. For design, the class used methods implementation are strongly encapsulated and it exclusively similar to the “UML Components” approach [1]. For the communicates with other components through its interfaces. programming projects, the class used the Enterprise A required interface of a component can connect to a JavaBeans (EJB) component technology [13]. Although provided interface of another component when the two EJB is a reasonable solution for commercial client/server interfaces match each other. That leads to inter-component systems, the complexity of the EJB technology and its lack dependencies being restricted to individual interfaces rather of simple composition strategies means it is not ideal for than encompassing the whole component specification. use in an academic course. The technology got in the way of teaching the students how to “think in components” provided required provided cleanly. As a result of the experience in the class, the first interface author undertook the design of a simple, component- oriented language with features that support its use in i nner component Component 1 Component 2 teaching. The language is named BoxScript. The prototype Figure 1. Components and Their Interconnections of BoxScript is intended primarily for educational and research purposes. However, a full implementation of these ideas should also be useful for building real applications. This paper is organized as follows. Section 2 presents the In BoxScript, we use interface type to refer to a general key concepts and syntax of BoxScript. Section 3 describes interface with method declarations, in particular, a Java the processing stages for building a box. Section 4 gives an interface. Figure 2 shows an interface named DayCal. The example to demonstrate the usage of BoxScript. Section 5 term interface handle refers to the interface as a way of compares BoxScript with several existing component- describing a specific feature of a box. An interface handle oriented programming languages and discusses its has an interface type. Interface handles are specified in the properties. Section 6 suggests the possible future work and box description for the corresponding box. The provided Section 7 concludes the paper. interfaces in a box are specified using the keyword provided interface followed by interface type and 2. BoxScript interface handle pairs. Similarly, required interfaces are BoxScript is a Java-based, component-oriented program- specified using the keyword required interface ming language whose design seeks to address component followed by interface type and handle pairs. concepts in a clean, simple language. The concept of component is based on Figure 1 and the assumed method 2.1.2 Abstract box for component specification is similar to the “UML An abstract box is a box that only contains the Components” approach [1]. descriptions of provided interfaces and required interfaces. It does not include the implementations of the provided 2.1 Key Concepts interfaces. An abstract box should be implemented by A component is called a box in BoxScript. A box is a concrete boxes, i.e., atomic boxes or compound boxes. blackbox entity; that is, it strongly encapsulates its internal All kinds of boxes, both abstract and concrete, must have details while only exposing its interfaces. The user of a box box descriptions. In BoxScript, an abstract box should have does not need to know its implementation details. A box, no a box description that declares the box as abstract, matter how small or large, has the functionality needed to gives the box name, and specifies its provided interface and satisfy some requirements and can be used either required interface descriptions. Figure 3 shows an abstract individually or as a part of a larger box. A box can be either box named DateAbs, which has one provided interface small enough so that it contains no other boxes or DayCal. Declaration of interface DayCal is given in composed from several smaller constituent boxes. Every Figure 2. Dc is the interface handle that is used in box box has the ability to be composed with other boxes to form DateAbs for type DayCal. a larger box. The necessary units of code for building a box are a box abstract box DateAbs description, interfaces and their implementations, { provided interface DayCal Dc; configuration information, and box manager code. A box //Dc is handle of interface DayCal } description (a file with an extension of .box) gives declarations for the features of the box. The configuration Figure 3. DateAbs.box information file gives the additional information that is not included in the box description. The box manager code is a 2.1.3 Atomic box An atomic box is a basic element in BoxScript. An Java class with the same name as the box that is generated atomic box does not contain other boxes. It must provide by the BoxScript compiler. The box manager code is for implementations for its provided interfaces. For an atomic concrete boxes only. box, the box description gives the box name and, if 2.1.1 Interfaces appropriate, the name of the abstract box it implements. If it There are two types of interfaces in BoxScript. One is a implements an abstract box, it is said to be a variant of the provided interface, which describes the operations that a abstract box. Also, the atomic box describes its provided box implements and that other boxes may use. The other is and required (if there are any) interface types with the a required interface, which describes the operations that the interface handles corresponding to these types. Figure 4 box requires and that must be implemented by another box. shows the box description for atomic box Date that A box has one or more provided interfaces and zero or implements the abstract box DateAbs. more required interfaces. box Date implements DateAbs public interface DayCal { provided interface DayCal Dc; } { Figure 4. Date.box public void setDay(int y, int m, int d); public int getWeekday(); An atomic box must provide the implementations of its // 0 for Sunday, 1 for Monday and so on provided interfaces. By default, an implementation of a } provided interface is a Java class file that implements the Figure 2. Interface Daycal interface type and whose filename is formed by suffixing Imp to the interface handle name. However, the implementation of the interface type could be a Java class interface handle references from the constituent boxes to with a file name other than what is described above. If an the compound box. implementation does not use a default file name, the implementation file name needs to be specified in the 2.1.5 Application configuration information as a pair consisting of the An application, or say, a system, is an executable box interface handle and the Java class file name that that meets some particular requirements to fit a problem implements the interface type of the handle. For example, domain. An application should expose no required Figure 5 gives an implementation for the provided interface interfaces. DayCal of box Date shown in Figure 4. This 2.2 Composition in BoxScript implementation takes a default name combined interface The composition process in BoxScript is illustrated in handle Dc with suffix Imp. Figure 6. Suppose we wish to compose Box1 and Box2 import java.util.*; into a compound box Box1_2. (In the following, Box1 import java.io.*; really means an instance of Box1 and Box2 means an public class DcImp implements DayCal instance of Box2.) A provided interface of a box might { public DcImp(BoxTop myBox) connect to a matching required interface of the other box, { _box = myBox; } such as P11 of Box1 connects to R21 of Box2 and P21 of public int getWeekday(int y,int m,int d) Box1 connects to R13 of Box2. In such a way, the boxes throws IllegalArgumentException are “wired” together. The required interfaces of both Box1 { year = y; month = m; day = d; if (!isValid()) and Box2 would be required interfaces of Box1_2 except throw new for those satisfied by the other box. Similarly, the provided IllegalArgumentException(); i n te r fa c e s o f b o th Box1 and Box2 would be the candidate return (toJulian() + 1) % 7; provided interfaces of Box1_2. In Figure 6.b, required } private boolean isValid() {…} interfaces R11 and R12 from Box1 and R22 from Box2 are private int toJulian() {…} exposed to be required interfaces of Box1_2; provided private BoxTop _box; interfaces P11 from Box1 and P22 from Box2 are exposed private int year, month, day; to be provided interfaces of Box1_2. Box1_2 does not } need to implement its provided interfaces since the Figure 5. DcImp.java implementations are available from Box1 and Box2. An atomic box has a box manager that is generated by the R11 R12 R13 R21 R22 BoxCompiler. The box manager code includes a R equired Required constructor for the atomic box object and code that I nterfaces interfaces instantiates the interface handle objects. P11 P21 Box1 Box2 P12 P22 2.1.4 Compound box Provided Provided A compound box is composed from atomic boxes or Interfaces Interfaces other compound boxes. A compound box does not need to Figure 6.a Box1 and Box2 develop implementations for its provided interfaces because R11 R12 R22 they exist in the boxes from which it is composed. The box Required Interfaces description for a compound box not only supplies the R13 information given in the atomic box, but also specifies three Box1_2 R21 P11 P21 additional pieces of information: the box names from which Box1 Box2 this compound box is composed, the interface sources from P12 P22 which the provided and required interfaces of this compound box come, and the connection information that Provided interfaces describes how the boxes connect interfaces together to Figure 6.b Composition of Box1 and Box2 compose this compound box. Detailed information on the strategy for composition and the description of the When components are composed, the composition must compound box are presented in Section 2.2. follow the rules below: In addition to a box descriptor and any necessary i. All their provided interfaces are hidden unless explicitly configuration information file, a compound box has a box exposed by the compound box. manager that is generated during compilation. It has a ii. A component box must expose every required interface constructor for the compound box object and code that that is not wired to a provided interface of another box. instantiates the boxes that comprise it. It passes the The compound box is the only type of box that needs handle DayC of box handle boxC (i.e., boxC.DayC) is composition. Composition is specified in the box connected to the provided interface handle Dc of box description for the compound. Each constituent box of the handle boxD (i.e. boxD.Dc). The composition process is compound box has a box handle, which is a way of illustrated in Figure 8. The full example is described in describing the constituent box as a specific feature of Section 3. composition. As discussed in section 2.1.4, a compound DayCal box should specify three additional pieces of information required DayC about the participants in the composition: names for the interfaces constituent boxes, sources of its provided interfaces and required interfaces, and connection information. DateAbs CalendarAbs provided Consider the component box BuildCalendar shown in provided interfaces interfaces Figure 7, BuildCalendar is composed from boxes Date DayCal Display and Calendar, which extend abstract boxes DateAbs and Dc Dis CalendarAbs, respectively. In this example, we use Figure 8.a DateAbs and CalendarAbs abstract boxes DateAbs and CalendarAbs instead of BuildCalendar DayCal concrete boxes Date and Calendar in describing the required composition that forms BuildCalendar. A concrete DayC interfaces compound box gives the box names from which it is DateAbs CalendarAbs composed in the declaration portion composed from. We boxD boxC assign a box handle for each box, and the box handles help p rovided describe other composition information. In interfaces provided BuildCalendar, boxD and boxC are the box handles interfaces Diaplay DayCal for abstract boxes DateAbs and CalendarAbs, Dc Dis respectively. Figure 7.a shows the box description for provided abstract box BuildCalendarAbs. Figure 7.b shows the interfaces Display box description for concrete compound box D BuildCalendar that implements BuildCalendarAbs. Figure 8.b Composition abstract box BuildCalendarAbs { provided interface Display D;} A box is strongly encapsulated with only its interfaces Figure 7.a BuildCalendarAbs.box exposed. The behavior of a box remains unchanged unless the state of the box is changed. The state of a box can only box BuildCalendar be changed when an action on a provided interface method implements BuildCalendarAbs is performed. The match of a provided interface to a { composed from DateAbs boxD, required interface guarantees that the results of calls to the CalendarAbs boxC; methods of a required interface are expected by the box // boxD is box handle for DateAbs, with no side effects. That means, the behavior changes of a //boxC is box handle for CalendarAbs box are predictable. provided interface Display D from boxC.Dis; 2.3 Flexibility in BoxScript connect boxC.DayC to boxD.Dc; BoxScript introduces the concept of variant to support } flexibility, especially to enable substitution of one Figure 7.b BuildCalendar.box alternative implementation for another. An atomic or Each interface of the concrete compound box is from one compound box can be either an implementation of an of the boxes that compose it. In provided interface abstract box or a standalone box that has no related abstract and required interface declarations, after each box. For the former case, all the implementations of an interface type and interface handle is given, the source of abstract box are considered to be variants of the box; one the interface handle should be given as the description of variant of a box can be substituted for another. For the latter the abstract box name and the interface handle in that case, the atomic or compound box is considered to have no abstract box. In BuildCalendar, interface handle D of variant; if the box is replaced by a newer version, the new interface Display is from interface handle Dis in box version must continue to use the same name. An abstract CalendarAbs (its handle is boxC). box can extend another abstract box and the former one is The connect statement gives information on how the considered to be a variant of the latter one. boxes are wired. The syntax is to connect a required When one box is replaced by another box, the new one interface handle of a box to a provided interface handle of should conform syntactically to the original one. another box. In buildCalendar, the required interface • Box B conforms to box A if and only if box stores the box description and configuration file. The (∀p: p ∈ provided interfaces(A): directory interfaces holds the interface types and (∃q : q∈ provided interfaces (B) : q extends p)) and directory datatypes holds the utility data types that are (∀r: r ∈ required interfaces(B): used in the boxes. Data types refer to the types that are not (∃s : s∈ required interfaces (A) : s extends r)). standard Java data types but which are defined by the users • Box interface x extends box interface y if and only if for certain purposes. In particular, these may be user- interface handle (x) = interface handle(y) and defined types for parameters passed to or values returned type (x) extends type(y) in Java. from operations on an interface. That is, the provided interfaces of B should provide at least warehouse_root the operations of A, and the required interfaces of B should be at most as much as that of A. For example, BoxA has boxes interfaces datatypes provided interfaces Pa, Pb and Pc and required interfaces Figure 9. Directory Structure Ra and Rb; BoxB has provided interfaces Pa, Pb, Pc and Pd and required interface Ra. We say the BoxB conforms The stage after locating is compiling. Every box must be to BoxA. In addition to conforming syntactically, the boxes processed by the BoxScript compiler, called BoxCompiler. must conform semantically, which is discussed in [3]. Figure 10 shows the relationship between the BoxCompiler To support flexibility, in the composition of a compound and the Java compiler. BoxCompiler takes the box box, the constituent boxes that are composed to form it are description and other necessary files as input, checks the shown as abstract box names in the box description. The syntax and interface conformity, and generates the box abstract box name allows the ability to plug in different manager code for the concrete boxes. variants of the constituent boxes. Consider the example in Box Java Figures 3, 4 and 7. When the compound box BoxCompiler Java BuildCalendar is executed, the concrete boxes Date code code Compiler and Calendar that implement the abstract boxes Figure 10. BoxCompiler and Java Compiler (DateAbs and CalendarAbs) should be accessed. So, we introduce a configuration file to indicate which concrete When a BoxScript application is ready to be executed, it box is used for each abstract box in the compound box needs to be copied into a directory that the user chooses. specification. In the configuration file, there is a pair for We call this process shipping. The tool for shipping is matching each box handle with the concrete box that is called BoxShipper. On shipping, BoxShipper detects used. In this example, boxD (the box handle of DateAbs) changes in the box’s directory. If any changes are detected, and Date would be a pair, the former is the box handle that the box is re-compiled. BoxShipper bundles the necessary denotes the abstract box and the latter is the concrete box files for the application into a Java archive (jar) file and that the compound box accesses when executing. When a stores it into the appointed directory. The separation of the new version of Date, say DateNew, is substituted for storage and the execution locations of an application Date, no box source files other than the configuration file ensures that the modification of the source code does not needs to be changed: pair boxD and Date should be effect the execution of a previously compiled version. changed into pair boxD and DateNew. After the application is shipped into the appointed directory, the boxes of that application reach their last 3. Box Processing Stages processing stage – executing. The application cannot be There are five stages for building a box: editing, locating, modified while it is running. If any changes occur, such as compiling, shipping and executing. the substitution of a new version of a box for the old one, After being edited, a box should be placed into a the application should be ceased first and then replaced by directory structure called a warehouse as shown in Figure the new version. 9. This is the locating stage. The warehouse directory has subdirectories boxes, interfaces and datatypes. The 4. Example directory boxes is a multi-layer structure. The top layer This section uses a simple example of displaying a holds the abstract box packages and box packages that do calendar to illustrate the use of BoxScript. To display a not extend any abstract boxes. Each box has a directory calendar for a certain month or months in a given range, we whose name is the same as its box name. An abstract box’s need to do two things: calculate the day of the week for directory stores its box description. A variant of an abstract each day in a month and display each month in a group of box is in a subdirectory of the abstract box directory. The days with the weekdays illustrated. We can decompose the directory of an atomic box stores its box description, the system into two boxes, one for calculating the day of the implementation of the provided interfaces and the week for a given date, the other for displaying the calendar configuration file if it has one. The directory of a compound for a given interval. We design these as atomic boxes. To allow variants of boxes, we assign each an abstract box, 5. Discussion calling the first DateAbs and the second CalendarAbs. The concepts of component-oriented programming are Box DateAbs (shown in Figure 3) has one provided not simple. Most of the commercial languages for building interface DayCal (shown in Figure 2). DayCal has two component software introduce complicated environments, methods: setDay() for setting a particular date and which make the component-oriented programming even getWeekday()for getting the weekday for the day that more complicated. C# [4] is probably the first commercial was set by the setDay() method. The concrete box that component-oriented programming language. Component implements DateAbs is called Date and is shown in Pascal [11] is a dialect of Oberon 2. It combines object Figure 4. Since Date is an atomic box, it needs to provide orientation with modules in a language whose syntax is the implementation of its provided interfaces. The similar to Pascal. However, the component concepts in both implementation (shown in Figure 5) uses a default file name C# and Component Pascal are different from the one shown DcImp, which is combined with Dc, the interface handle of in Figure 1, which we assume here. Jiazzi [8] and DayCal in Date and a suffix Imp. ComponentJ [12] are two extensions to Java that are built Box CalendarAbs, which is shown in Figure 12, has upon the component model shown in Figure 1. However, one provided interface Display and one required interface Jiazzi’s scripting language provides explicit names for the DayCal. The interface Display is shown in Figure 11. composite components in a connection; there is thus no Display takes the time range from the user and displays support for flexibility [7]. ComponentJ gives provided and the calendar. Display uses DayCal to calculate the day of required interface specifications and gives the method week for each date. The atomic box that implements implementations of the provided interfaces in the CalendarAbs is called Calendar, which is illustrated in component definition. However, the method Figure 13. Figure 14 gives the implementation of the implementations make the component definition crowded; provided interface Display, supplied by box Calendar. moreover, the user of the component does not necessarily The implementation is named DisImp, which is a default know the detailed implementations of the provided name that combines Dis, the interface handle of Display interface. in Calendar, and suffix Imp. In DisImp, class BoxScript is built upon a clear concept of component and InterfaceName that is used by method generateSeq is provides a simple language syntax. It supports the a public class provided by BoxScript. Method requirements for flexibility and compositionality of getRequiredItf enables a program to get the interface component-oriented programming. Boxes in BoxScript, reference by its interface handle name. being separated by boundaries, are strongly encapsulated. The possible changeable aspects (secrets) of a component public interface Display { //display a single month calendar should be designed to be inside a box. Implementation //according to input year and month inheritance is not allowed across box boundaries. Under public void displayCalendar(int year, such a design, when a change occurs, only the boxes that int month); hold the affected secrets would need to be changed. Any //display months of a calendar // according to input years and months box that is modified should keep its interface unchanged. public void displayCalendar(int year1, Also, boxes that allow variants are described by abstract int month1, int year2, int month2); boxes. The configuration files give matching pairs of } abstract boxes and concrete boxes that are really being Figure 11. Display.java used. When a new version of a box comes, only the abstract box CalendarAbs { provided interface Display Dis; configuration file needs to be modified by replacing the old required interface DayCal DayC; box package by this new package. The implementation code } for the box should not need to change. Thus, no changes Figure 12. CalendarAbs.box should be needed in the other boxes in that application. In box Calendar implements CalendarAbs BoxScript, three kinds of information participate in { provided interface Display Dis; composition: interfaces, box descriptions of the boxes to be required interface DayCal DayC; } composed, and configuration file. No additional work is Figure 13. Calendar.box needed to compose boxes. Meanwhile, the rules guarantee the composition to be safe. The calendar system BuildCalendar is composed The three main programming units of BoxScript are box from DateAbs and CalendarAbs. The composition is descriptions, interfaces and implementations of the illustrated in Figure 8. The box description of interfaces. BoxScript separates an interface from its BuildCalendar and its abstract box implementations. Originally designed for an educational BuildCalendarAbs are shown in Figure 7. purpose, BoxScript adapts its interfaces and interface implementations to a Java style that is familiar to students. public class DisImp implements Display for (yy = startY+1; yy <= endY - 1; yy++) { private BoxTop _box; { for (mm = 1; mm <= 12; mm ++) DayCal d; //required interface { generateSeq(yy, mm); public DisImp(BoxTop myBox) display(yy, mm); { _box = myBox; } InterfaceName name = } new InterfaceName("DayC"); // print the last year d =(DayCal)_box.getRequiredItf(name); for (mm = 1; mm <= endM; mm ++) } { generateSeq(endY, mm); public void displayCalendar(int year, int month) display(endY, mm); { setDate(year,month, 0,0); } generateSeq(year, month); } display(year,month); private void setDate } (int y1, int m1, int y2, int m2) public void displayCalendar throws IllegalArgumentException (int year1,int month1,int year2,int month2) { year1 = y1; month1 = m1; { setDate(year1,month1,year2,month2); year2 = y2; month2 = m2; processCalendar(year1,month1,year2,month2); dateArr = new int [WEEKS][WEEKDAYS]; } if (!isValid()) private void generateSeq(int y, int m) throw { int i = 0, weekday; new IllegalArgumentException(); int totaldays = getDays(y,m); } ClearDateArr(); private boolean isValid() weekday = d.getWeekday(y,m,1); { boolean mark = false; dateArr[i][weekday] = 1; if (year2!=0) for(int t = 2; t <= getDays(y,m); t++) mark = month2 > 0 && month2 <= 12; { dateArr[i][weekday] = t; else if (weekday == 6) mark = month2 == 0; { i++; weekday = 0;} return year1 > 0 && month1 > 0 else && month1 <= 12 && mark; weekday ++; } } private int getDays(int y, int m) } { switch (m) private void display(int y, int m) { case 1: case 3: case 5: case 7: { System.out.println case 8: case 10: case 12: ("\n" + y + " " + monthStr(m)+ "\n"); return 31; for (int i = 0; i < WEEKS; i++) case 4: case 6: case 9: case 11: { if (! ((i == WEEKS-1) return 30; && dateArr[i][0] == 0 ) ) } System.out.println("Sun" + "\t" + if ((y % 4) == 0) "Mon" + "\t" + "Tue" + "\t" + return 29; "Wed" +"\t" + "Thu" + "\t" + return 28; "Fri" + "\t" + "Sat" ); } for (int j = 0; j < WEEKDAYS; j++) private String monthStr(int m) if (dateArr[i][j] == 0) { switch (m) System.out.print(" \t"); { case 1: return "January"; else case 2: return "February"; System.out.print case 3: return "March"; (dateArr[i][j] + "\t"); case 4: return "April"; System.out.println(); case 5: return "May"; } case 6: return "June"; } case 7: return "July"; private void processCalendar case 8: return "August"; (int y1, int m1, int y2, int m2) case 9: return "September"; { int startY = y1, endY = y2; case 10: return "October"; int startM = m1, endM = m2; case 11: return "November"; int yy, mm; case 12: return "December"; if (y2 < y1) } { startY = y2; endY = y1; return null; startM = m2; endM = m1; } } private void clearDateArr() if ((y2 == y1) && (m2

References [1] J. Cheesman and J. Daniels. UML Components: A Simple Process for Specifying Component-Based Software, Addison Wesley, 2001. [2] H. C. Cunningham, Y. Liu, P. Tadepalli, and M. Fu. “Component Software: A New Software Engineering Course,” Journal of Computing Sciences in Colleges, Vol. 18, No. 6, pp. 10-21, June 2003. [3] H. C. Cunningham, Y. Liu, and P. Tadepalli. “Toward Specification and Composition of BoxScript Components,” In Proceedings of the Workshop on Specification and Verification of Component-based Systems (SAVCBS), pp. 114 -117, November 2004.