• No results found

CAT: Component Architecture for Tailorability - Textual syntax and a possible graphical representation

N/A
N/A
Protected

Academic year: 2021

Share "CAT: Component Architecture for Tailorability - Textual syntax and a possible graphical representation"

Copied!
6
0
0

Loading.... (view fulltext now)

Full text

(1)

CAT: Component Architecture for Tailorability

-Textual syntax and a possible graphical representation

Oliver Stiemerling

University of Bonn

Department of Computer Science III Römerstraße 164

53117 Bonn

os@informatik.uni-bonn.de Introduction

This technical report contains the description of syntax (textual and graphical) of CAT (Component Architecture for Tailorability), a component-oriented language designed to describe highly tailorable (or adaptable) software architectures. CAT is concerned with the description of the current (adaptation-)state of an application. The language is supposed to be the foundation for the specification of tailoring operations (i.e. application transformations). These operations, however, are not within the scope of this report.

CAT is similar to the configuration language DARWIN (see Magee et al. (1995)). DARWIN, however, was developed especially for the specification of distributed system architectures and does not, for example, include explicit bindings of configuration parameters between different hierarchical levels. The configuration parameters described by CAT represent customizable properties of the implemented components.

Textual syntax

In this section, we want to describe the textual syntax of CAT, using a simple context free grammar (see Hopcroft and Ullman (1979)). For certain definitions (simple types, identifiers, and literals) we will draw on the official Java Language Specification (see Gosling et al. (1996)), because our primary goal for this version of the language is its implementation using the JavaBeans component architecture.

A CAT-program describes the architecture of an application as a composition of components. At the lowest level there are implemented components. These components actually have a programmatic definition somewhere outside the CAT-program (e.g. in JavaBeans JAR-files, see JavaSoft (1997)). Their properties are defined first. Then (optionally) they are aggregated over several levels of abstract components. The final (mandatory) component is the system component, which contains all other components. It should be noted, that the implemented, abstract and system component constructs describe types of components, which can be reused in different parts of the application (except for the unique system component). At system-startup, the system component construct serves as a unique starting point for the recursive instantiation of the application. Here, however, we are only concerned with the description of an component-oriented application architecture. Implementation issues are not within the scope of this report.

A first time reader is advised to first take a look at the example at the end of the section, as many aspects of the language are supposed to be “intuitive”.

(2)

Program Body

The Program body is described by the following grammatical productions. It contains a list of implemented component types, a list of abstract component types, and a system component:

CAT È Implemented_components_list Abstract_components_list System_component Implemented_components_list System_component

Implemented_components_list È Implemented_components_list Implemented_component Implemented_component

Abstract_components_list È Abstract_components_list Abstract_component Abstract_component

Implemented Components

Implemented component types are described by the following productions. The component body consists of a list of provided ports, a list of required ports, and a list of parameter definitions. The provided ports represent services which the component can offer if it is composed with other components. The required ports represent services which the component needs if it is composed with other components. The notion of ports and services is rather abstract. If CAT is used in conjunction with an implemented component model, it has to be mapped to the composition mechanism of the respective component model (e.g. Event-mechanisms in JavaBeans, or Remote Method Invocation in CORBA (see OMG (1995))).

Implemented_component È i_component comp_type_name { i_component_body } i_component_body È ports parameters

ports È required_list provided_list required_list È required_list required_port

required_port

Every port has a name and a type. The type represents the composition mechanism which applies to this port (e.g. Push-Event-Source in a hypothetical JavaBeans Button). The name is local to the component. In CAT the port types can be used to check the compositional correctness of the program (i.e. whether all port connections are legal).

required_port È required port_name type_name;

provided_list È provided_list provided_port provided_port

provided_port È providedport_name type_name;

The parameters of an implemented component are supposed to map to the properties of the respective component implementation (e.g. as a JavaBean). Therefore, they support the basic Java types.

parameters È parameter_list parameter parameter

parameter È config_parameter parameter_name javatype;

config_parameter parameter_name javatype := javaliteral;

Types, Literals, and Names in CAT

As mentioned above, due to its current purpose, CAT makes use of the definition of simple types and literals of Java as described in Gosling et al. (1996). However, in order to include the string type (which is - in Java - not specified as a primitive type, but as a class) we have used a construct naming all used types including strings. For the definition of literals, however, we refer to page 19 in Gosling et al. (1996). All non-terminals ending with _name are IdentifierChars (see p. 17 in Gosling et al. (1996)), but not CAT-keywords (i_component, a_component, s_component, subcomponent, required, provided, config_parameter, bind, boolean, integer, byte, short, int, long, char, float, double, string).

(3)

javatype È boolean integer byte short int long char float double string

javaliteral È Literal (p. 19 in Gosling et al. (1996))

*_name È IdentifierChar (p. 17 in Gosling et al. (1996)) but not CAT-keyword

Abstract components

Abstract components are aggregations of implemented components or other already specified -abstract components. Thus, recursive specification of -abstract components is not allowed. In addition to the components ports and parameters, the component body contains the specification of subcomponents and bindings. The bindings can be between subcomponents only or between a subcomponent and the abstract component. In former case, only required and provided ports of the same type can be bound. In the latter case required ports can only be bound to required ports, and provided ports only to provided ports. Again the type restriction applies. All ports of subcomponents and all newly defined ports of the abstract component have to be bound.

Parameters of subcomponents can either be statically defined within the subcomponent parameter settings body or bound to parameters of the abstract component. As abstract components have no implementation, all parameters of the abstract component have to bound to parameters of subcomponents. Type restriction applies.

Abstract_component È a_component comp_type_name { i_component_body a_component_body } a_component_body È subcomponents bindings

subcomponents È subcomponents subcomponent

subcomponent È subcomponent local_name comp_type { parameter_settings };

subcomponent local_name comp_type; parameter_settings È parameter_settings parameter_setting

parameter_setting

paramerter_setting È parameter_name := javaliteral;

bindings È component_bindings parameter_bindings component_bindings È component_bindings component_binding

component_binding È bind local_name . port_name -> local_name . port_name ;

bind port_name -> local_name . port_name ; bind local_name . port_name -> port_name ; parameter_bindings È parameter_bindings parameter_binding

parameter_binding È bind parameter_name -> local_name . parameter_name ;

System component

The System component is similar to an abstract component, the difference being that it has no ports of its own. It represent a closed system. The system component can have, however, configuration parameters, which - again - have to bound to parameters of subcomponents.

(4)

s_component_body È paramters subcomponents bindings

Remarks on the textual syntax

The grammar presented here is designed for easy understanding and not for use in a compiler.

Example

The example presented here is drawn from Magee et al. (1995), extended with the notion of configuration parameters. Regard the following CAT-program:

i_component low-pass-filter { required in sound_signal; provided out sound_signal;

config_parameter border_frequency integer; }

i_component high-pass-filter { required in sound_signal; provided out sound_signal;

config_parameter border_frequency integer; }

a_component band-pass-filter { required in sound_signal; provided out sound_signal;

config_parameter upper_border_frequency integer; config_parameter lower_border_frequency integer; subcomponent filter1 low-pass-filter;

subcomponent filter2 high-pass-filter; bind filter1.in -> in;

bind filter1.out -> filter2.in; bind filter2.out -> out;

bind upper_border_frequency -> filter1.border_frequency; bind lower_border_frequency -> filter2.border_frequency; }

s_component filter-system {

config_parameter frequency integer; subcomponent filter3 band-pass-filter {

upper_border_frequency := 1000; };

bind band-pass-filter.lower_border_frequency -> frequency; }

The example presented here contains the important elements of the CAT-language. At first, two implemented components are specified. Both have an in- and out-port each. The ports are of the type sound-signal, which is not interpreted in CAT, just statically checked within a bind-construct. The components each have one configuration parameter, which allows to customize the filters to a specific lower, resp. upper frequency-border.

The abstract component defines a band pass filter, which consists of a pair of serially connected low pass and a high pass filters. The abstract components defines two configuration parameters which are bound to the respective frequencies parameters of the subcomponents. The ports of the abstract component are bound to the in-port of the first filter, resp. the out port of the second filter. The out-port of the first filter is connected to the in-port of the second filter.

The system component finally specifies the whole system as consisting of one band pass filter component fixed to a upper frequency of 1000, while the lower frequency is bound to a configuration parameter of the system.

(5)

The specification of an application using the textual syntax is precise, however not readily understandable. In the following section we will introduce a graphical representation of the language, again building on DARWIN (see Magee et al. (1995)).

Graphical representation

In this section we describe how a graphical representation of an application is derived from a given textual description. Starting with the system component we evaluate the textual CAT -program backwards. In the following we will use the filter example from the last section.

We begin with the system component. All components are represented by rectangular boxes. Parameters are represented by little squares, labeled with parameter name and type. Thus, the system component in the example is presented in figure 1:

Figure 1: Graphical representation of system component in the example

Subcomponents are completely within the area of the respective abstract (or, on the top-level, system) component and do not touch the border of the enclosing component. Ports are represented by circles on the border of the respective component. Required ports are empty (‰), provided port are filled (l). Ports are labeled with port name and type. Parameter bindings are represented by lines connecting the respective parameter representations (squares). Thus, from the system component we go backwards to the last (and, in the example, only) abstract component, as shown in figure 2:

Figure 2: Graphical representation of abstract component and parameter binding

The abstract component in the example consists of two implemented subcomponents which are represented using the same conventions as above. Port bindings are represented by lines connecting the respective port representations (circles). After evaluating the two subcomponents we are finished and the graphical representation of the abstract component is shown in figure 3 (Figure 3 does not show the complete representation, only the "internals" of filter3 in figure 2.):

(6)

Figure 3: Graphical representation of abstract component with port bindings

The graphical representation is designed to quickly present parts of an application. It would be rather cumbersome to fully display a complex application with several abstraction levels in one representation.

Bibliography

[1] Gosling, J., Joy, B., and Steele, G., The Java Language Specification. Reading, Mass.: Addision-Wesley, 1996.

[2] Hopcroft, J. E. and Ullman, J. D., Introduction to Automata Theory, Languages, and

Computation. Reading, Mass.: Addison-Wesley, 1979.

[3] JavaSoft, “JavaBeans 1.0 API Specification,” . Mountain View, California: SUN Microsystems, 1997.

[4] Magee, J., Dulay, N., Eisenbach, S., and Kramer, J., “Specifying Distributed Software Architectures,” in: Proceedings of 5th European Software Engineering Conference, Barcelona, 1995.

[5] OMG, “The Common Object Request Broker: Architecture and Specification,” , 2.0 ed: Object Management Group, 1995.

References

Related documents

Comparison of flagging, walking, trapping, and collecting ticks from hosts as sampling methods for northern deer ticks, Ixodes dammini, and lone star ticks, Amblyomma americanum

Standardization of herbal raw drugs include passport data of raw plant drugs, botanical authentification, microscopic & molecular examination, identification of

This essay asserts that to effectively degrade and ultimately destroy the Islamic State of Iraq and Syria (ISIS), and to topple the Bashar al-Assad’s regime, the international

[r]

innovation in payment systems, in particular the infrastructure used to operate payment systems, in the interests of service-users 3.. to ensure that payment systems

dementia or Alzheimer’s or cognitive impairment or cognitive dysfunction AND counsel* or psychotherap* or therapy or therapeutic intervention AND care* or family or informal care*

a Number of circulating CD34 + CD133 + CD45 + progenitor cells in non-COPD and COPD patients grouped according to DLco above or below the median value (60% predicted); (b) Number

 HCC is developing in 85% in cirrhosis hepatis Chronic liver damage Hepatocita regeneration Cirrhosis Genetic changes