Components and Connectors

In the thesis, we regard software architecture as a set of components together with the connectors realizing the interactions among these components similar to Component&Connector (C&C)-Architectures discussed by Taylor et al. [2010]. Hence, we recapitulate the definitions of components and connectors from [Taylor et al., 2010]:

2.2. DESCRIBING SOFTWARE ARCHITECTURES 23 Definition 2.2.1. (Software component) (see for [Taylor et al., 2010, page 69])

“A software component is an architectural entity that (1) encapsulates a subset of the system’s functionality and/or data, (2) restricts access to that subset via an explicitly defined interface, and (3) has explicitly defined dependencies on its required execution context.”

We primarily concentrate on characteristics (2) and (3) since our goal is to synthesize connectors for which interfaces are the access point to a component. From here on, we explicitly exclude the component’s behavior as protocols in the thesis. But we are going to specify behavior abstract as interface semantics using concepts. Thus, from a connector’s point-of-view a component simply consists of a set of provided and required interfaces. Provided interfaces of a component are exposing the components functionality via these interfaces. Whereas its required interfaces are used by the component to receive a functionality provided by other components.

Definition 2.2.2. (Software connector) (see for [Taylor et al., 2010, page 70])

“A software connector is an architectural element tasked with effecting and regulating interaction among components.”

A connector must connect provided interfaces of (possibly several) com- ponents with suitable required interfaces of some other components, where some of the required or provided interfaces may be optional depending on the usage context.

Definition 2.2.3. (Interface type) An interface with name I has the in- terface type I.

Note, that an interface’s type is independent of its methods. The reason for this definition is that software architects use the name of an interface, like IIterator, as a semantical description of the functionality a component provides via this interfaces.

The following special case, depicted for component C in Figure 2.1, occurs often:

Definition 2.2.4. (I-connector) A connector that connects a single pro- vided interface I to a single required interface I is called an I-connector. Example 2.1. An example I-connector is depicted in Figure 2.1. The con- nector C requires an interface I and provides an interface I as well.

C

I

_I

Figure 2.1: I-connector

An I-connector is not necessarily a simple pipe since it may provide further functionality beyond the fact that it connects I to I. For example, it may add security properties, for example a secure channel by using encryption, to the interaction.

Interface types are not sufficient to capture all relevant properties, thus it may be necessary to also include semantic concepts to specify them. Note that the distinction between components and connectors does not have to be sharp. Rather, components and connectors can be regarded as two ends of a continuum as argued by Kell [2007].

Usually, connectors are generic with regard to their usage scenario, i.e., there is a limited number of functional and non-functional general properties that a connector may or may not need to have. The idea of composite connectors (connectors that are assembled out of components) has been advocated by Spitznagel and Garlan [2001] and by Julien and Perry [2008], because of such a genericity and in order to improve reusability. Clearly, a high degree of automation in finding appropriate composite connectors would be an advantage. The idea underlying our approach to connector synthesis is to assume a set of building blocks from which composite connectors may be synthesized for a given usage context. Some of the building blocks may be specialized for exactly such an usage context, whereas others may be more generic. The building blocks may be atomic, i.e., they provide certain interfaces without further requirements. Other more complex building blocks may offer certain functionalities if they are provided with certain functionalities offered by other building blocks. Such complex blocks can be used to build compositions of building blocks and may capture architectural design decisions or even whole architectural styles with regard to software connectors. Note that some building blocks can be components or connectors themselves. Since, in principle, building blocks can be composed in arbitrary way the resulting composite connectors may offer great variability. This variability often makes the manual retrieval and composition of building blocks tedious as well as repetitious and therefore error-prone.

2.2. DESCRIBING SOFTWARE ARCHITECTURES 25 of connectors as described by Hirsch et al. [1999] and by Mehta et al. [2000]. The repository has to be thus designed or specified once for possibly multiple uses in a given usage context. Each building block is linked to an underlying (i.e. hidden from the user by an abstract link) set of code templates, that have been prepared such that they correctly implement the specification of the building block. In the following subsection we will present a rich semantic based description language that can be used to specify building blocks. Once a repository of building blocks has been specified using intersection types

we synthesize connectors by asking suitable inhabitation questions. An

inhabitant can be regarded as a description or blueprint of how certain building blocks should be composed. From such compositions we infer connector descriptions in an ADL. The ADL-description of a connector is used to generate executable code by combining the underlying templates according to a suitable interpretation of the ADL-description.

In order to avoid confusion, we distinguish the terms specification, synthe- sis, and generation.

Definition 2.2.5. (Specification)

We denote a process that constructs a concise logical model including semantics for synthesis from a problem space in a C&C architecture, as specification. Definition 2.2.6. (Synthesis)

We denote a process that constructs a composition plan by means of a logical method, as synthesis.

It means that type inhabitation is a synthesis method producing an inhabitant as composition plan.

Definition 2.2.7. (Generation)

We denote a process that transforms a composition plan into an abstract or textual object, as generation.

The definition also covers the generation of source code, deployment code, and also UML diagrams as concrete generation products.

Summarizing, the Combinatory Logic Connector Synthesis method consists of three essential steps:

1. Using a taxonomy, we semantically specify the building blocks in our repository and link them to a set of templates.

2. We synthesize compositions of building blocks by posing suitable inhab- itation questions.

3. We interpret the resulting inhabitants in an ADL and/or generate code from underlying templates.

An overview of the method is depicted as an abstracted process in Figure 2.2.

Specification Repository Templates Synthesis Generation UML Code C&CDConnectorDSynthesisDProblem Combi natoryDLog icDConnector DSynthesis Input Data ProcessDStep ControlDflow Synthesis

Figure 2.2: Overview of the Combinatory Logic Connector Synthesis method. We follow the discussion of Taylor et al. [2010] and extend their argumenta- tion for software connectors as first-class citizenship in software architecture. Software Connectors as First-Class Citizens

A software connector is an architectural element modeling different prop- erties in a software architecture. In Definition 2.2.2 and in [Taylor et al., 2010], a software connector is responsible for the interactions among software components. The interaction is performed by transferring control and/or data among components. The connector also encodes and enforces rules that govern those interactions. Some simple interactions are procedure calls and shared variable access. Some more complex and semantically rich interactions are client-server protocols, database access protocols, and asynchronous event

2.2. DESCRIBING SOFTWARE ARCHITECTURES 27 multicast. Each connector provides interaction via so called ducts. Ducts [Mehta et al., 2000, Kell, 2007] are channels along which data and control can be passed between components.

The reason for distinguishing between connectors and components is that components provide application-specific functionality whereas connectors provide application-independent interaction mechanisms. The interactions can be more abstract by applying parameterization to connectors. The parametrization allows the specification of complex interactions, because these interactions can be specified independently from the components.

A classification can be used that distinguishes binary from n-ary connectors and asymmetric from symmetric connectors. These concepts will be used later within an ontology of connectors. Different interaction protocols can be identified and are presented in [Taylor et al., 2010]. The global view on an architecture’s interaction model is broken down to a set of local interaction definitions. The global architecture’s interaction emerges from such local architecture interactions. Then, such ideas can be used for a component system for interactions and their information. Such extra-components are called connectors and in a formal model, connector building blocks. Furthermore, the introduction of connectors brings component independence and interaction flexibility.

The benefits of first-class connectors are the conceptual separation of computation from interaction. It minimizes component interdependencies and supports the evolution of software architectures at component-, connector-, and system-level. It offers potential for supporting dynamism in software architectures and facilitates heterogeneity. Software connectors can become partition points as presented in the examples in Chapter 8. The separation of components and connectors also aids the system’s analysis and testing.

Connectors allow modeling of arbitrarily complex interactions because of a local view on interactions. The connector’s flexibility, for example by composition or by individual local adaptations, aids the system’s evolution. Components can be added, removed, replaced, reconnected, and migrated without affecting other components, because connectors isolate effects. A support for connector interchange is also desirable. Then, connectors could be interchanged without affecting the system’s functionality. This can be advantageous with respect to the system’s evolution and also its prototyping.

Also Kell [2007] advocates software connectors as first-class citizens in software architecture and provides a table of connector types and their instances. Balek and Plasil [2001] discuss the importance and effects of software connectors for the deployment of the software. A more general discussion on software connectors with various examples can be found in [Balek, 2002].