Scholarly article on topic 'Towards Component Based Systems: Refining Connectors'

Towards Component Based Systems: Refining Connectors Academic research paper on "Computer and information sciences"

CC BY-NC-ND
0
0
Share paper
Keywords
{}

Abstract of research paper on Computer and information sciences, author of scientific article — Matthias Anlauff, Asuman Sünbül

Abstract Component-oriented software development is becoming more and more important for the production of large-scale software applications. Today's systems are constructed by combining different software components rather than built from scratch. Provided component interfaces or informal descriptions are not enough for designing reliable software systems. Therefore we need precise description means for formulating component behavior without uncovering implementation details of the component. In this paper, we will present a model for the design of component-based software systems, where the design aspects of connectors between components play a central role. We will therefore introduce the concept of connector refinement allowing to abstract from technical connector implementations on the design level of a system.

Academic research paper on topic "Towards Component Based Systems: Refining Connectors"

URL : http://www.elsevier.nl/locate/entcs/volume70.html 15 pages

Towards Component Based Systems: Refining

Connectors

Matthias Anlauff1,2 Asuman Siinbiil1,3

Kestrel Institute Palo Alto, California, USA

Abstract

Component-oriented software development is becoming more and more important for the production of large-scale software applications. Today's systems are constructed by combining different software components rather than built from scratch. Provided component interfaces or informal descriptions are not enough for designing reliable software systems. Therefore we need precise description means for formulating component behavior without uncovering implementation details of the component. In this paper, we will present a model for the design of component-based software systems, where the design aspects of connectors between components play a central role. We will therefore introduce the concept of connector refinement allowing to abstract from technical connector implementations on the design level of a system.

1 Introduction:Corriporient Based Systems in Software Architecture

During the last few years, component-based software development (CBSD) has evolved to one of the most popular sub-disciplines of software engineering. But, the degree of reusability not only depends on the facilities of the components themselves, but also on how the components are glued together and what kind of composition mechanisms has been used. The latter aspect has been neglected in the majority of projects dealing with component-based software engineering. Current approaches tackle this problem on the technical layer, using e.g. COEBA, EPC, script languages or event channels etc. . These approaches have a strong emphasis on solving technical component

1 This material is based upon work supported by the Air Force Research Laboratory under Contract No. F30602-00-C-0209 and F30602-01-C-0123.

2 Email: maQkestrel.edu

3 Email: asuQkestrel.edu

©2002 Published by Elsevier Science B. V.

interaction problems. The realization of the overall problem specification is cov ered b y these low-level problems. Therefore, it is important to provide means that allow system design on a high lev el of abstraction. Our main goal is finding high-level composition aspects in the design phase alio wing an abstraction from the concrete tec hnical realization. We think, that a clear separation of concerns must be applied to the connectors in the same way as it is done for the development of the components themselves.

In this work, a soft wire development approach focusing on component composition techniques via connectors is proposed. The semantics of the component model forming the tec hnical basis for the approach is specified using the Abstract State Machines (ASM) [5] method. Additionally, a component model input language (CMIL) is in troduead a user interface to the component model. In CMIL, system design processes are carried out using refinement techniques, especially by connector refinements. Therefore, the notion of abstract connectors is introduced as a means to abstract from concrete connector specifications. The semantics of the refinement techniques is also fully formalized using ASMs, As a side effect, the formalizations contained in the work hav e directly been used to generate an executable v ersion of the ASM rules using an ASM support en vironmert. The generated code, the " CMIL-check er", has also been used to mlidate the examples and case studies presented in different projects [9].

1.1 A F ormalRepresentation of Components and Connectors

In the following, a formal representation of the component model is presented in more detail. The model serves as a basis for formulating the structure of components and connectors, and the relationships between them. The formalization uses the notation of Abstract State Machines (ASMs) as introduced in [?]. ASM basically define states in terms of static algebras and transition rules being used to transform one state to another. We will use ASMs in the folio wing way: The functions and universes describing a state will be used to describe the static structures of the components and connectors, while the ASM rules will be used to describe the consistency rules of our component model.

Representation of components.

Components are modeled to be elements of a

universe Component

In ASMs, a universe stands for a basic set of elements, A component has a name represented as a string, which is modeled using a function Component-Name defined as follows:

function ComponentName(c : Component) —String

F or example, if a eomponert c has the name "Library", the following equation holds:

Component Name(c) = "Library"

Export and import services of components are represented b v universes as well:

universe ExpService, ImpService universe Service = ExpService U ImpService

The fact that a component has a set of export and import services is modeled using the folio wing functions:

functions Exports(c : Component) —{ExpService}, Imports{c : Component) —{ImpService}

F or example, to express that a eomponert c exports services e0, ei, and imports services t0, ¿1 the values of these functions would be as folio ws:

Exports(c) = {e0, 61} Imports(c) = {i,q, ¿1}

The services themselves have a name, a list of parameters each of which has a specific type and a mode describingt\Miatih'^ni", "out", or "inout" parameter, and an optional result type. Types are elements of a universe "Type"; the concrete representation of types is not regarded in the model. However, it is assumed that a function " c onforms-to" exists that returns true, if the two type arguments are conform to each other,

universe Type

universe Parameter Mode = {in, out, inout} functions ServiceName(s : Service) —String, ServiceParameter(s : Service)

—[ (t : Type, m : Parameter Mode) ], ServiceResType{s : Service) —Type external function conforms-to(ti : Type, t2 : Type) Boolean

The function "conforms-to" is an "external" function which is not further specified on this abstraction level. External functions can be seen as "oracles" for the formalization; it is assumed that they return the "right" value for given parameters. Using this tec hnique,one is able to focus on the main issues of a specification; functions marked as "external" can be modeled in further refinement lev els.

Abstraction from concrete Notations.

Our component model abstracts from concrete notations for component usage constraints, service pre- and postconditions, and other specification items

occurring in a concrete system specification. For each class of specification item, we therefore introduce a universe to express the existence of these kinds of items. The advantage of this abstraction is, that our model focuses on the questions arising when building systems using components and connectors without dealing with technical details of the specification techniques used in a specific system specification.

We therefore define the following universes signaling the existence of information needed to express the consistency rules of our component molie

universe Constraint, Specification, UseStructure

These universes are used for the following purposes:

Constraint A constraint formula expresses possible usages of the export services of a component, F orexample, if a component c exports services s0, Si, ,,,, sn and Si,,,,,sn can only be used, if the initialization service s0 has been in v)ked before, the component constraint formula would be the place to formulate this kind of condition. Examples for possible notations of component constraints are temporal logic formulas [11,12], and path expressions [8].

Specification A specification expresses either the functionality of a service exported b v a component or the required functionality of an imported service, No further assumption about the format and notation of this specification is made on the highest abstraction level. Examples for possible service specification formats are abstract data types [8], CSP [1], Z [7], or any other specification language that can be used to express functional behavior,

UseStructure A use structure expresses the usage of imported services in the body of the component. Typically, a use structure is given as a net describing possible orderings of service usages while executing exported services, A use structure must be matched against the constraints given by the components the services of which are used. In [11] and [12] import petri-nets are used to model the usage of imported services of the component.

The following function definitions bring the above universes and the previously introduced components and services of our model together:

functions ComponentConstraint{c : Component) —Constraint, ProvidedSpec{s : ExpService) —Specification, RequiredSpec{s : ImpService) —Specification, IrnportStructure(s : ExpService) —UseStructure

The function containedServices allows to extract the information which services are contained in a specific use structure,

external function containedServices(u : UseStructure) —{ImpService}

This function is marked as "external", because we did not make any assumptions about the format of a use structure. In case the use structures are given as petri-nets, where the used services are modeled as transitions, the con-

tainedServices function could be an algorithm extracting the corresponding transitions from the petri-net.

Similarly, the folio wing functionsare required as externally given in order to express consistency conditions of our component model:

external functions

impliesSpec{expspec : Specification, irnpspec : Specification) —Boolean, rneetsConstraint(u : UseStructure, c : Constraint) —Boolean

The impliesSpec function is responsible for checking whether the specification of an import service Sj can be derived by the specification of an exported service Se- In this case, a necessary condition is fulfilled that the exported service can be "plugged" in the component requiring service Sj. The meets Constraint function is used to check whether the usage of imported services si,...sn in the body of a component is consistent with the constraints specified for the components exporting ,,, sn.

Representation of connectors.

In general, connectors are responsible for interconnecting components. More precisely, a connector maps a required service Sa of a component A to an exported service Sb of a component B. In our model, this is represented as follows:

universe Connector

function ServiceConnector(si : ImpService, se : ExpService) —Connector

Connectors are elements of the universe Connector. If a connector cn maps an import service Sa to an export service Sb, the following condition holds:

ServiceConnector(SA, Sb) = cn

Component Model Consistency Rules.

With the above introduced formalizations of component and connectors we hav e now the framework for expressing consistency rules for our component model. In this paper, we can only sk etc hthis part of the formalization in order to give you an idea, how this kind of rules can be specified.

As an example, we specify the rules for checking whether the signatures of an import and an export service match. These rules are active, whenever a connection should be made between two components. We therefore first define a macro defining the formula for testing two service parameters on equality:

pa ramequal(Pl,P2)_

(iconforms-to(Pl"t, P2"t)) A

(Pl'm = P2"rn)

As one can see, the parameter are equal, if the types are conform to each other and the modes are equal. This macro is used in the following "asm" specifying the rules for signature matching:

asm check si gnatures(simp : ImpService, sexp : ExpService) —Boolean is

function T\ ServiceParameter(simp), r2 ServiceParameter(sexp) if (ti =~ [kpi\kpli]) A (r2 =~ [&p2|&p/2]) then if -iparam,-equal(8zpi, &P2) then

return false else

Ti := Szpli r2 := kpl2 endif

elseif (ti = []) A (r2 = []) then

if -1 parani-equal(ServiceResType(simp), ServiceResType(sexp) then

return false else

return true endif else

return false endif endasm

Each of the parameters of the services are checked to be equal; whenever the parameter list differ, false is returned. The check signatures function only returns true, if all parameters and the optional result parameters are equal,

2 Representing Standard Connector Techniques using CMIL

W're introducing connector refinement as a powerful means to express relationships between an abstract system arc hitectureand more refined versions of it.

By the introduction of abstract connectors, it is possible, to abstract from actual connector implementations in the same way as it is possible to abstract from component realizations by only specifying their export interfaces. In the sequel, we will show how standard connector techniques- like Wrapper and Adapter etc, - are expressed using in CMIL using connector refinement.

In many cases, we will only use the service names without specifying their signatures and assume, that the introduced connectors are consistent with respect to the consistency rules of the component model. We will also make use of graphical representations for describing CMIL components and connectors, where the symbols have the following meaning:

Export Interface

Component Import Interface

stands for a component with export and import in terface. The interfaces contain the signatures of the exported/imported services.

► s2

stands for an "abstract" connector C connecting the export service si from component A with the import service s2 from component B,

same as the abov e, only that the connector is a concrete one. In this case, the connector name may be omitted.

Systems as defined in ('Mil. are represented as dashed boxes with the name of the system in the top left corner.

3 Adapters

A common technique of defining connections between components is the use of "adapter" code for adjusting the provided exported services of a component A to fit to the required import services of a component B. The functionality of the adapter is usually not very complex and is mainly used for performing data type conversions, (hanging the order of parameters, filtering input and output parameters etc, , One the one hand, this adapter code is v erv important to technically compose system components, but on the other hand it should be possible to abstract from this kind of adapter components when presenting the arc hitectural description ofa system.

In ('Mil., abstract connectors can be used to achieve this effect, by introducing in an abstract system R a abstract connector C representing a connector between two non-matching services s\ and s2. In system S the abstract connector C is then refined b v a component providing the required export service s2 and importing the exported service si. The corresponding ('Mil. description is given as follows:

¿liiunur I'-UUifUUl

Fig. 1. Connector Refinement using an adapter component C

system R {

component A { exports { ,s'i }

component B { exports { ... } imports { ,s'2 }

connector C { a :: .si

B :: ,s-2}

system S refines R {

component C {

exports { s-2 }

imports { ,s'i }

connector {

A : : ,si

—y [o\

D : ■ s-2

A corresponding graphical representation of this connector refinement example is contained in Figure 1.

4 Wrapper Connectors

Wrappers are a very common technique in solving interoperation problems. This approach av oids direct modification of the componerts and is more flexible. A wrapper encapsulates a component, in order to make it usable in some new way for another eomponert. Wrappers can be used to expose all or some of the functionality of the component they are wrapping. In CMIL, this situation can be modeled by introducing a wrapper component as follows:

system R {

system S refines R {

wrapper-component W { exports {

component A {

exports { ,s'i }

imports { ,s'2 }

component B {

exports { ... }

imports { s3 }

component C {

Si S 4

exports { ,s'4 }

connector W {

A :: Ä! [W] -)■ B :: ,s-3

.4 :: ,s-i —> [] —> i? :: ,s3

C :: s 4 -» [W] -» A:: s2

C :: ,s4 [] 'A '■'■ ,s2

In this case, the component A exports a service, which is used b yB and requires a service, which is exported by C. In system R, we have modeled this using abstract connectors, because we assume, the the services do not fit together without wrapping A. In the refined system S, such a wrapper component U has been introduced. It refines the two abstract connectors from system R by providing suitable export and import services. The corresponding graphical representation of this connector refinement example is given in Figure 2. 4

5 Blackboard Connectors

Blackboards basically provide the possibility to attach and to query for messages for a certain receiver. In CMIL, a simplified blackboard component would look like this:

4 In this picture, component .4 is drawn inside the wrapper component IF just for illustration purposes; .4 could have been drawn outside the IF component without changing the semantics of the picture.

s4 -- si -■

C : w A ;w B

► s2 ►s3

Fig. 2. Connector refinement using a wrapper component W

assuming that the types Receiver and Message are defined. Assuming, we have given the abstract system description R as shown below, then we could refine the C connector using the blackboard and a suitable wrapper component as folio ws:

system R {

component A {

exports {void ,s'i() }

component B { exports { ... } imports {void ,s2() }

connector C {

.4 :: .si ^ W ^ D :: s2

system S refines R {

types {Receiver Message} include Blackboard component Attach {

exports { ,s'2 } imports {

a,ttach(Receiver, Message)

component Poll { imports {

[Message] query(Receiver)

component C { Attach Poll } connector {Blackboard :: attach

—» C :: attach) connector {Blackboard :: query —» C :: query}

connector {

A:: si [C]

^ B :: s2

The wrapper component C consists of two sub-components: Attach and Poll. Whenever B send a message through its import service s2 the export service s2 of Attach is in \oked. It attaches a messages on the blackboard using the corresponding export service of the component Blackboard. The Poll component periodically polls for messages for A using the query service, and as soon as there is a message attached at the blackboard it inv ok esthe corresponding export service of A. Figure 3 contains the graphical representation of this connector refinement example.

6 Request Broker Connectors

The main purpose of "Request Brokers" is to provide connection services between different soft wire entities, where the location of these entities is not restricted to any pre-determined configuration. That means that the entities using the request broker services may run on the same computer, or are distributed owr a network and link together using technical communication protocols. A popular example of such an request broker component is the Object Request Broker of the CORBA standard [6].

In CMIL, this kind of connectors can on the one hand be directly specified, and on the other hand possible refinements of this kind of connectors can be

si -- -i

A : c B

Fig. 3. Connector refinement using a blackboard component

s2 k s3 1

si s4

Fig. 4. Representation of an abstract request broker connector and its refinement

given using the expressive means of the language. As an example, we consider the four component A, B, D, and E in Figure 4. In the abstract system R on the left-hand-side of this figure they are connected with an abstract connector C consisting of two different connections between the import services of B and E and the export services A and D. In this way,we can regard the abstract connector C as a request broker connector, in the same sense as described above. In the refined system S the realization of the connector is giv enb v specifying a request broker component C providing the services s2 and s3 and requiring the services si and s4 according to the interfaces specified in the abstract system.

In Figure 5 the corresponding textual v ersion of the refinement is given using the syntax of the ('Mil..

SYSTEM R { SYSTEM S REFINES R {

COMPONENT A { REQUESTBROKER-COMPONENT C {

EXPORTS { ,S'i } EXPORTS {

} S-2

COMPONENT B { S3

IMPORTS { S-2 } }

} IMPORTS {

COMPONENT E { Si

IMPORTS { S-i } C S'4

} }

COMPONENT D { }

EXPORTS { ,S'4 } CONNECTOR {

} [C\ E :: .s3

CONNECTOR C { }

.4 :: si [] E : «3} CONNECTOR {

CONNECTOR C { D :: ,s4 -» [C\ D :: s-2

D :: ,s4 W -> D : s2} }

} }

Fig. 5. Refinement of an abstract Request Broker Connector in CMIL

7 Conclusion

In this paper, we hav e presented a set of examples of connector refinement in order to illustrate how the refinement techniques of the component model can be used to approach the concrete realization of a component-connector-svstem step b y step: First you define the general interconnections between the components using abstract connectors, then you refine these connectors to standard connector techniques, as shown in this paper, and finally these refined connectors can be used to directly derive executable program code,

F olio winghe current trends in the field of soft wire engineering, component composition will be the central task for developers in near future. It is therefore important to provide efficient and powerful means to deal with the problems occurring when assembling software systems from existing components, In this paper, we have presetted a basic model for components and connector that can be taken as basis for component-based development methods. Through the notion of connector refinement we have presetted a possibility to apply well-establish design principles of software systems in general to component connectors. The latter aspect is often neglected in traditional software development methods; connectors are mostly just implemented , sometimes even as part of the integration test phase.

This paper does not describe the component model in full detailpecause this would be out of the scope of this paper, A well-elaborated version can be found in [9].

F urthermore,we are working on an implementation of a (graphical) language for translating component structures to the formal models presented in Section 1,1, The consistency rules can be - due to the execution semantics of Abstract State Machines - directly be taken to implement a support system for our approach using ASM implementations like [2],

References

[1] Allen, R., and Garlan, D. F ormalizing architectural connection. In Proceedings of the 1ffl International Conferenc e on Softwae Engineering (May 1994), pp. 71-80.

[2] Anlauff, M. Xasm - an extensible, component-based abstract state machines language. In Proceedings of the ASM 2000 Workshop (2000), vol. 1912 of L ectur Notes in Computer Science.

[3] Anlauff, M., Kutter, P., Pierantonio, A., and Sunbul, A. Using domain-specific languages for the realization of component composition. In Pr ocaMngs of the FASE 2000 Conference (2000).

[4] Garlan, D., and Shaw, M. Software Architecture: Perspectives On An Emerging Discipline. Prentice Hall, 1995.

[5] Huggins, J. The ASM homepage, " http: //www.eecs.umich.edu/gasm/community .htm".

[6] Object Management Group Inc. Corba components, joint revised submission. T ech. rep., OMG TC Documeh, July 2000.

[7] R crcE, W., and R <yce, W. Softw are arc hitecture: In tegrating process and technology. TRW Spac eand Defense (1991).

[8] Schumann, H., and Goedicke, M. Component-oriented softw aredevelopment with n. ISST-Berichte 21/94, ISST, Sept. 1994.

[9] Sunbul, A. Architectural Design of Evolutionary Software Systems in Continuous Software Engineering. PhD thesis, Technical University Berlin, April 2001. DAV, ISBN 3-935316-84-4.

[10] Szyperski, C. Component Software - Beyond Object Oriented Pr gramming. Addison Wesley ,1998.

[11] Weber, H., P adbers, J., and Sunbul, A. Petri net based components for evolvable architectures. IEEE International Conference on Systems Integration.

[12] Weber, H., Sunbul, A., and Padberg, J. Modelling information and communication infrastructures for evolutionary design of busines processes using component technologies. Society for Design and Process Science, IEEE International Conference on Systems Integration.