Architecture Descriptions of Software Systems: Complex Connectors vs

Realisability

Mert Ozkaya

Istanbul Kemerburgaz University, Istanbul, Turkey

Keywords:

Architectural Languages, Interaction Protocols, Realisability.

Abstract:

With the advent of software architectures, architectural languages have become an active research area for the

speciﬁcation of software architectures in terms of components & connectors and for some extra capabilities

such as formal analysis and code generation. In this paper, the existing architectural languages have been

analysed for two important language features - i.e., interaction protocols and realisability. The analysis results

show that only a few languages support interaction protocols via their ﬁrst-class connector elements (also

referred to as complex connectors). However, complex connectors of those languages lead to unrealisable

speciﬁcations due to enabling global constraints which may not be possible for distributed systems. Therefore,

practitioners cannot implement the system in the way speciﬁed, and any analyses (e.g., performance) made on

the unrealisable speciﬁcations will all be invalid.

1 INTRODUCTION

Software architecture (Clements et al., 2003; Perry

and Wolf, 1992; Garlan and Shaw, 1994) has been

proposed in the early nineties as a high-level design

method for specifying software systems in terms of

components and their relationships (i.e., connectors).

Since then, many architectural languages (ALs) have

been developed through which software architectures

can be speciﬁed at varying levels of abstractions and

further used for some useful operations such as formal

analysis and code generation.

According to the recent analyses (Lago et al.,

2015; Malavolta et al., 2012), there are approxi-

mately 120 known ALs

. These ALs can be either

UML-like languages, architecture description lan-

guages (ADLs), and formal speciﬁcation languages.

UML-like languages derive from UML (Rumbaugh

et al., 2005) , which is an informal modelling lan-

guage that offers a visual (i.e., diagrammatic) no-

tation set for designing software systems including

architectural design. ADLs (Medvidovic and Tay-

lor, 2000) are precise languages that are exclusively

used for architectural design. ADLs can be either

general-purpose (used for any systems) or domain-

speciﬁc. General-purpose ADLs are useful for the

The list of ALs can be accessible here: https://sites.

google.com/site/ozkayamert1/als

high-level speciﬁcations and their formal analysis to

detect high-level design errors such as deadlocking

components. Domain-speciﬁc languages are better

for detailed speciﬁcations of systems in particular do-

mains which can then be used for, e.g., implementa-

tion generation. Formal speciﬁcation languages (e.g.,

ProMeLa (Holzmann, 2004) and FSP (Magee et al.,

1997)) are based on formal syntax and semantics (i.e.,

mostly algebraic), which enable the exhaustive for-

mal analysis of architectural models. Given so many

ALs with different scopes and capabilities, one might

expect ALs to be so popular among practitioner in

industry. However, this has never been the case -

ALs remain in the focus of research communities only

(Malavolta et al., 2012; Ozkaya, 2016b). As stated in

(Malavolta et al., 2012), there are very few ALs, such

as UML (Rumbaugh et al., 2005) and AADL (Feiler

et al., 2006), which practitioners prefer in their ar-

chitectural modelling. Most ALs are either (i) used

by expert practitioners who have deep knowledge and

experience in architectural modelling or (ii) used for

research purposes only.

Lago etal (Lago et al., 2015) proposed a frame-

work for classifying ALs on a set of requirements

that are grouped as language deﬁnition, language fea-

tures, and tool support (Lago et al., 2015). Language

deﬁnition is concerned with the syntax and semantics

of languages, e.g., support for ﬁrst-class components

and connectors. Language features are concerned

382

Ozkaya M.

Architecture Descriptions of Software Systems: Complex Connectors vs Realisability.

DOI: 10.5220/0006139503820391

In Proceedings of the 5th International Conference on Model-Driven Engineering and Software Development (MODELSWARD 2017), pages 382-391

ISBN: 978-989-758-210-3

with the capabilities of languages in specifying soft-

ware architectures, e.g., support for multiple view-

points and extensibility. Tool support is mainly to do

with formal analysis and implementation code gener-

ation facilities. Inspired from Lago etal’s classiﬁca-

tion framework, I analysed the existing 120 ALs for

a number of requirements (Ozkaya, 2016a). My anal-

ysis sheds light into many interesting issues that may

have been ignored by the language designers which

may however affect the practical use of the languages.

In this paper, I focus on two key requirements, i.e.,

component & connector view and realisability, which

I believe are highly important for the practical use of

the languages by practitioners. Components & con-

nectors view separates high-level complex interaction

mechanisms (i.e., interaction protocols) from compo-

nents’ computations and considers them as connec-

tors. Note that connectors encapsulating interaction

protocols are referred to as complex connectors in the

rest of the paper. Realisability is, informally, the ca-

pability of implementing a software system in exactly

the same way as its software architecture speciﬁca-

tion. That is, the implemented system is expected to

have the same components that behave and interact in

the same way. The goal of this paper is to analyse the

existing languages for these two key requirements and

discuss the relationship between complex connectors

and realisability.

In the rest of the paper, languages’ support for

complex connectors (i.e., interaction protocol) is dis-

cussed ﬁrstly. This is then followed by the discus-

sion of the realisability of the languages. Lastly, the

relationship between supporting complex connectors

and guaranteeing the realisability of software archi-

tectures is discussed.

2 COMPLEX CONNECTOR

SUPPORT

To describe complex connectors, one should start

from one of the best regarded deﬁnition of software

architecture made by Garlan and Shaw (Garlan and

Shaw, 1994): an architecture of a speciﬁc system is

treated as a collection of computational components

– or simply components – together with a descrip-

tion of the interactions between these components –

the connectors. So, while components are the units

of computations, connectors in software architectures

represent the units of interactions for the compo-

nents. A connector can be as simple as communica-

tion links through which components exchange syn-

chronous/asynchronous messages among each other.

Procedure call and event-broadcasting are some fa-

miliar examples of simple connectors, which simply

describe the style of communications. A complex

connector also deals with the constraints on the way

the communicating components interact with each

other, which is also known as the protocols of in-

teractions. An interaction protocol (Kloukinas and

Ozkaya, 2012) essentially describes for a set of com-

municating components the order of messages that the

components exchange so as to be composed together

to a successful system.

Specifying software architectures in terms of com-

ponents and complex connectors enhances the modu-

larity and thus the practical use of the languages. First

of all, architectural designs will be more understand-

able as one can easily distinguish between the com-

putation (i.e., components) and interaction (i.e., com-

plex connectors). Modularity also aids in the analy-

sis of software architectures. Indeed, detecting any

design errors due to wrong (e.g., deadlocking) inter-

action protocols that hinder the composition of sys-

tem components or wrong computations of compo-

nents will be easier since the computations and in-

teraction protocols are cleanly separated. Moreover,

ﬁnding out the optimum design decisions will be eas-

ier too as components can easily be re-used and ex-

perimented with different interaction protocols.

In the rest of this section, the languages are evalu-

ated for their complex connector (i.e., interaction pro-

tocols) support. Each language is taken into consid-

eration in terms of their support for components and

complex connectors. However, due to the space re-

striction, only the most well-known languages (i.e.,

most cited by industry and academia) are considered

herein that have inspired many of the existing lan-

guages today. The full list of ALs can be found in

(Ozkaya, 2016a).

Wright. (Allen and Garlan, 1997). A component

type in Wright is speciﬁed with interfaces and a com-

putation. A component interface can operate as many

actions as desired in its environment. A component

computation is used (optionally) to specify either (i) a

conﬁguration of component and connector instances,

or, (ii) a protocol for coordinating the interface be-

haviours.

Connector Support. In Wright, besides ﬁrst-class

component elements, connectors are also ﬁrst-class

elements, thus enabling the explicit speciﬁcation of

interactions among components. Indeed, one can de-

scribe with Wright connectors either simple intercon-

nection mechanisms (e.g., procedure call) or complex

ones (e.g., complex interaction protocols such as an

auction).

Connectors in Wright are instantiated from con-

Architecture Descriptions of Software Systems: Complex Connectors vs Realisability

383

nector types, which enables reuse of the same interac-

tion pattern on different contexts and also the analysis

of connectors in isolation. A connector type is de-

scribed with roles representing the participating com-

ponents and a glue coordinating the behaviour of the

roles. Roles and glue are each speciﬁed with a proto-

col representing their behaviours.

C2. (Medvidovic et al., 1996; Taylor et al., 1996).

A component type in C2 is speciﬁed with an interface

and a computation. A component interface speciﬁca-

tion is two-fold: a top_domain and a bottom_domain.

The top_domain represents requests, which are emit-

ted by the component, and notiﬁcations, which it

reacts to. The bottom_domain represents requests,

which can be received, and notiﬁcations, which can

be sent. For a component computation, it comprises

a set of methods, representing the inner functionality

of the component, and a behaviour part, coordinating

the calls made to these methods.

Connector Support. C2 does not allow for spec-

ifying complex interaction mechanisms. However, it

offers a connector element that can either route event

messages between components or broadcast messages

from a component to multiple components. Connec-

tors allow also the ﬁltering of messages via a set of

built-in policies, i.e., no ﬁltering, notiﬁcation ﬁlter-

ing, prioritised, and message sink.

A connector is speciﬁed with roles consisting of

top- and bottom-domains, which are used to specify

the components it connects together.

Moreover, connectors in C2 are speciﬁed as part

of the architecture element, which is used to specify

a conﬁguration of components and connectors for a

system. So unlike Wright connectors, C2 connectors

cannot be speciﬁed as abstractions and re-used in dif-

ferent conﬁgurations. Within the body of architec-

ture, the style of the connector is speciﬁed that de-

scribes its policies for message ﬁltering. Then, in its

architecture_topology, the bottom and top domains of

the connector are associated with components.

Darwin. (Magee and Kramer, 1996). Darwin is

one of the ﬁrst architecture description languages, in-

tended as a general-purpose language for specifying

distributed systems as conﬁgurations of components.

In Darwin, software architectures are speciﬁed in

terms of hierarchical components. Component types

in Darwin are speciﬁed with interfaces they provide

to their environment and require from them too. Each

interface of a component is responsible for the com-

munication of a single message.

Connector Support. Darwin does not support the

speciﬁcation of connectors in architectural designs.

Components interact with each other through bind-

ings speciﬁed in composite component types. How-

ever, bindings cannot describe the way interaction oc-

curs between components, thus resulting in the pro-

tocols of interactions being hard-wired inside com-

ponents. This not only overcomplicates component

speciﬁcations but also reduces their re-usability and

hampers the architectural evaluation of different can-

didate interaction protocols.

Rapide. (Luckham, 1996). A component type in

Rapide is speciﬁed with interfaces, which serve for ei-

ther asynchronous (observing and generating events)

or synchronous communication (providing and re-

quiring functions). Each interface consists of actions

that represent asynchronous events or synchronous

functions. An interface also include behaviour spec-

iﬁcations, representing the external behaviours of the

components.

Connector Support. Like Darwin, Rapide adopts

an approach that considers system architectures as

collections of components which are wired together

via mere connections. So, unlike Wright, there is

no ﬁrst-class connector element offered, leading com-

plex interaction patterns to be implicitly speciﬁed in

component speciﬁcations.

On the other hand, Rapide introduces architec-

tural constraints, through which global interaction

protocols for the interacting components can be spec-

iﬁed. But, unlike Wright, where connectors are inde-

pendent elements, Rapide constraints are embedded

within an architecture speciﬁcation, and thus cannot

be re-used in different architecture speciﬁcations.

MetaH. (Binns et al., 1996). Unlike other ADLs

introduced so far, MetaH does not allow designers to

specify their own component types. Instead, a set of

low-level pre-deﬁned types are offered. Software ar-

chitectures are speciﬁed with subprogram and pack-

ages component types, while hardware architectures

with monitor, memory, process, channel, and device

types. Designers can use the pre-deﬁned component

types and include interfaces inside their component

type speciﬁcations. Interfaces herein are ﬁrst-class

elements in MetaH that are speciﬁed externally and

then used in component speciﬁcations. Finally, the

computations of components are speciﬁed as a col-

lection of attributes, which are used to describe the

non-functional requirements, e.g., schedulability and

reliability details of components.

MetaH offers additional component types (i.e.,

modes and macros) for specifying the conﬁguration

of components.

MODELSWARD 2017 - 5th International Conference on Model-Driven Engineering and Software Development

384

Connector Support. MetaH does not offer ﬁrst-class

connectors. Connectors are viewed as connection

links, which are used in conﬁguration components to

connect the interfaces of their sub-components.

UniCon. (Shaw et al., 1995). Component types in

UniCon can be either primitive or composite. Ev-

ery component is speciﬁed with a type, which is cho-

sen among the pre-deﬁned types offered by UniCon.

(e.g., sharedData, process, and ﬁlter). These pre-

deﬁned types determine the interface of the compo-

nents, i.e., its actions (named as players in UniCon).

Note that UniCon also has a general component type,

allowing designers to specify generic types without

any restriction on interfaces. A primitive component

type can also include implementation details (e.g., lo-

cation of source code).

Connector Support. Connector types in UniCon are

introduced as ﬁrst-class elements. A connector type

is speciﬁed with an interaction protocol, acting as a

mediator of interaction among components. Protocols

herein, just like Wright connectors, consist essentially

of roles. However, unlike Wright, UniCon restricts

protocols to be of certain types, e.g., Pipe, DataAc-

cess, and ProcedureCall, thus preventing designers

from freely specifying their own (complex) types.

Koala. (van Ommering et al., 2000). As in Darwin,

system architectures in Koala are speciﬁed in terms of

components. However, unlike Darwin, Koala offers

ﬁrst-class interface elements, encapsulating methods.

So, interfaces are then employed within components,

which either require or provide their methods.

Component types in Koala can also be com-

posite by including a computation (i.e., a conﬁgu-

ration of components). Koala introduces contains

and connects constructs (corresponding to inst and

bindings in Darwin respectively) for specifying the

conﬁguration of components in composite types.

Connector Support. Like Darwin, Koala does not sup-

port connectors in system architectures either. Inter-

actions between components are merely speciﬁed by

connects in composite component types. Being sim-

ple links, these cannot be used to specify complex

interaction protocols independently of components.

Nevertheless, as aforementioned, Koala offers mod-

ule, which can be employed in a composite compo-

nent and connected with the interfaces of the interact-

ing sub components to order their the method-calls.

So, modules in Koala can be used to specify interac-

tion protocols for components.

COSA. (Oussalah et al., 2004). Component types

in COSA are speciﬁed with interfaces and a com-

putation. Furthermore, a component type can in-

clude properties for specifying non-functional prop-

erties and a constraint, which is again a property that

is used to specify certain policies to be met by the

components.

While components can be composite too, consist-

ing of component and connector instances, COSA

also offers ﬁrst-class instance elements for specifying

conﬁgurations of components and connectors.

Connector Support. COSA offers ﬁrst-class con-

nector types, which are speciﬁed with a collection

of roles for participating component interfaces and

a glue for representing a global interaction protocol.

Designers can also specify some other interaction de-

tails as part of connectors, such as the type of connec-

tions or the mode of connections. While the connec-

tion types can be either communication, conversion,

coordination, or facilitation, the connection-mode can

be synchronous or asynchronous connections.

COSA also introduces composite connector types.

A composite connector is speciﬁed via a glue element,

with which designers can specify a conﬁguration of

component and connector instances. So with COSA,

it is possible to specify complex connectors modu-

larly, by re-using the existing component and connec-

tor type instances.

XADL. (Dashofy et al., 2002). XADL provides the

very basic elements for an architecture description in

terms of XML schemas. These basic schemas can be

extended to new schemas by adding/removing new

features, which enables the creation of speciﬁc con-

structs ﬁtting better the designers own needs. XADL

offers a design-time schema, which can be used by

designers to specify their software architectures. The

design-time schema includes the commonly used ar-

chitectural constructs, e.g., component, connector, in-

terface, and link, and allows designers to specify basic

information about them, e.g., their id, description, and

type. So, designers can use the design-time schema

to specify their component types with their type, de-

scription, and interface(s). However, if the existing

features of the construct are not enough, designers

can extend the design-time schemas and add features

meeting their particular needs. Indeed, designers can

add features for specifying behaviours in some for-

malisms, e.g., Wright’s interface protocols.

Connector Support. Just like component types, con-

nector types are also supported by the design-time

schema, speciﬁed with type, description, and inter-

face(s). So, designers can either use its connector

construct as it is or extend it to add extra features,

e.g., Wright’s complex connector.

Architecture Descriptions of Software Systems: Complex Connectors vs Realisability

385

CONNECT. (Issarny et al., 2011). Components are

simply speciﬁed with interfaces representing the be-

haviours of the components in their interaction with

their environment.

Connector Support. Just like Wright connectors,

connectors in CONNECT are speciﬁed with roles and

a glue, where the roles represent the participating

components (namely their interfaces) and the glue

represents their coordination.

LEDA. (Canal et al., 1999). Component types in

LEDA are speciﬁed either as primitive or composite.

Regardless of being primitive or composite, a com-

ponent type is speciﬁed with interfaces and computa-

tion (i.e., optional). An interface is a ﬁrst-class ele-

ment, which, once speciﬁed, can then be used exter-

nally in component speciﬁcations to describe their in-

teraction points. Computation of components is spec-

iﬁed as a protocol, which coordinates the interface be-

haviours. Moreover, composite component types fur-

ther include composition and attachments, represent-

ing its computation as a conﬁguration of components.

Connector Support. Like Darwin, LEDA does not

support connectors either. Indeed, its only interac-

tion mechanism is the simple attachments, speciﬁed

within composite component types for linking the

component interfaces. Complex interaction mecha-

nisms (i.e., interaction protocols) can only be speci-

ﬁed as part of components, which makes components

less re-usable and protocol dependent.

SOFA. (Plasil and Visnovsky, 2002; Bures et al.,

2006). A component type in SOFA is speciﬁed with

component frame and a computation. A component

frame represents the external view of a component

type that consists of required (requires) or provided

(provides) interfaces. It should be noted that these

interfaces are essentially the instances of interface ab-

stractions that are speciﬁed externally as ﬁrst-class el-

ements. For component computations, they are speci-

ﬁed for composite components and consist of compo-

nent instances and connection links between required

and provided interfaces of these component instances.

Connector Support. SOFA offers pre-deﬁned basic

interaction mechanisms, i.e., procedure call, messag-

ing, streaming, and blackboard (Bures and Plasil,

2004). So, designers can specify their component

interactions using these basic interactions. More-

over, SOFA allows designers to specify their own

connectors too. It provides connector generation

tools, through which designers can choose any of the

pre-deﬁned interaction mechanisms and specify some

non-functional properties for these mechanisms (Ga-

lik and Bures, 2005; Bures, 2005). Nevertheless, it

is not possible to specify complex interaction mech-

anisms (i.e., interaction protocols) for the interact-

ing components via the connectors (and the tools) in

SOFA.

RADL. (Reussner et al., 2003). Component types

can be either basic or composite. Basic types are spec-

iﬁed with interfaces. An interface can be either pro-

vided, offering methods to their environment, or re-

quired, making method-calls. Note however that un-

like other ADLs, RADL constrains each basic type to

have at least one required and one provided interfaces.

Composite component types are speciﬁed with

interfaces and also a computation. A computation

herein describes a conﬁguration of sub component in-

stances whose interfaces are connected to each other

via bindings. Besides bindings, RADL offers map-

pings too, which allows an interface of a sub compo-

nent to be connected with an interface of the compos-

ite component (if both interfaces have the same type).

Connector Support. Like Darwin, RADL does not of-

fer ﬁrst-class connector elements. One can only spec-

ify simple communication links via bindings to con-

nect sub components of composite component types.

However, complex interaction protocols for their sub

components cannot be speciﬁed explicitly.

AADL. (Feiler et al., 2006). Just like MetaH,

AADL does not provide a generic type for specifying

component abstractions. Instead, component types

are categorised into three groups, each consisting of

a collection of component types which can be instan-

tiated by designers to specify their system architec-

tures. For specifying a software architecture, compo-

nent types can be either (i) thread, (ii) thread group,

(iii) process, (iv) data, or (v) subprogram. For spec-

ifying a hardware architecture, component types can

be (i) processor, (ii) memory, (iii) device, or (iv) bus.

Lastly, for specifying composite units of the above-

mentioned components, component type can then be

a system type only.

Component types under these categories are es-

sentially speciﬁed with interfaces. A component in-

terface has either ports or subprogram calls, where

ports serve for asynchronous events and data com-

munications, and, subprogram calls for two-way syn-

chronous method communications. A component

type in AADL can also include the (i) extends func-

tionality for inheriting from other types and (ii) prop-

erties functionality for specifying non-functional re-

quirements. Furthermore, component types can have

a computation that is speciﬁed with (i) subcompo-

nents, (ii) calls and connections to specify interac-

tions between subcomponents, (iii) extends to inherit

MODELSWARD 2017 - 5th International Conference on Model-Driven Engineering and Software Development

386

from another implementation, and (iv) properties to

specify non-functional requirements for the subcom-

ponents.

Connector Support. AADL does not offer ﬁrst-class

connector elements. However, it provides a pre-

deﬁned collection of interaction mechanisms: (i) port

connections, (ii) component access connections, (iii)

subprogram calls, and, (iv) parameter connections.

Port connections are concerned with the interac-

tions through component ports by sending or receiv-

ing data/events asynchronously. Component access

connections are employed when a shared data is to be

accessed by components. As to subprogram calls and

parameter connections, they relate to synchronous in-

teraction between components through subprogram

calls.

Archface. (Ubayashi et al., 2010). Archface is in-

spired from Aspect Oriented Programming (Kiczales

and Hilsdale, 2001), offering notations for e.g., point-

cut and advice. A component is speciﬁed with inter-

faces, each representing a single method of commu-

nication that is either required from the component

environment or provided to its environment. Further-

more, component speciﬁcations can include point-

cut declarations for the interface methods, such as

“call (method call), execution (method execution),

and cﬂow (control ﬂow)”.

Composite components are not supported by

Archface. Conﬁgurations of components are speci-

ﬁed via the architecture construct.

Connector support Connectors in Archface are

ﬁrst-class elements, which are speciﬁed as a collec-

tion of connections between the required and pro-

vided interfaces of some interacting components.

Each connection has an advice that is speciﬁed for

the provided method of the connection. The ad-

vice for the provided method describes that when-

ever the pointcut of the provided method is satis-

ﬁed, this is followed by the inter-connected required

method whose pointcut is expected to be satisﬁed sub-

sequently. Note however that complex interaction

protocols for components (i.e., the order of method-

calls or method executions) cannot be speciﬁed using

Archface connectors.

3 REALISABILITY

The issue of realisability essentially originates from

the work of Allen and Garlan on formalising connec-

tors (Allen and Garlan, 1997). They deﬁne the ar-

chitectural connectors in terms of (i) roles and (ii)

a glue. A role is deﬁned for each component that

P2UR NAP1

inc

double

MSC1 MSC2

P2UR NAP1

inc

double

Figure 1: A nuclear power plant’s (unrealisable) MSCs

(Alur et al., 2003).

P2UR NAP1

inc

double

inc

Figure 2: An unavoidable bad behaviour in the nuclear plant

(Alur et al., 2003).

the connector coordinates; and it describes the inter-

action behaviour of the component in terms of a se-

quence of messages sent/received. The glue of a con-

nector choreographs the component role behaviours

by describing a global sequence(s) of messages sen-

t/received by the components. However, software ar-

chitectures with global constraint speciﬁcations (i.e.,

the glue) may not always be realised in the same way

it is speciﬁed (i.e., with the same components, their

behaviours, and their conﬁguration). This is because

global constraints cannot be imposed on distributed

system components in reality as the distributed com-

ponents are autonomous entities and can only observe

their own local states - the global system state is un-

known to them. To realise the global constraint spec-

iﬁcations during implementation, one will possibly

need to use a controller that controls the distributed

component behaviours to ensure the global constraint.

This will however turn the distributed system into a

centralised one and violate the design decisions spec-

iﬁed for the distributed nature of the system and in-

validate any analyses made over the design decisions.

To illustrate realisability, consider the Nuclear

Power Plant system (Alur et al., 2003), which con-

sists of two clients (P1 and P2) whose goal is to ac-

cess and modify the Nitric Acid (NA) and Uranium

(UR) data controlled by the nuclear power plant. In

the plant, the quantities of UR and NA need to be the

same at all times. The clients P1 and P2 respectively

increase and double these quantities and to ensure the

plant’s safety they need to strictly follow the protocol

described by the message sequence charts of Figure 1.

However the protocol in Figure 1 was proved to be

Architecture Descriptions of Software Systems: Complex Connectors vs Realisability

387

Table 1: The ALs that

ignore complex connectors

(Note: * represents the lan-

guages that use some other

notations for specifying in-

teraction protocols).

Architectural

Languages

Darwin

Rapide*

MetaH

UniCon

Koala*

LEDA

SOFA*

RADL

AADL

Archface

Table 2: The ALs that sup-

port complex connectors.

Architectural

languages

Wright

COSA

XADL

CONNECT

unrealisable. It cannot be realised in a decentralised

manner so that bad behaviours like the one in Figure 2

are avoided (Alur et al., 2003).

Nevertheless, Allen and Garlan’s approach for ar-

chitectural connectors deﬁned in the nineties may

have inspired many other languages in their deﬁni-

tion of connectors, or more generally component in-

teractions. Table 1 and Table 2 show respectively the

analysed languages in Section 2 that have been ﬁnd

out to ignore complex connectors and support com-

plex connectors. Due to the space restriction again, I

focus on these ALs for realisability, especially those

that support the speciﬁcation of interaction protocol

constraints using complex connectors or another no-

tation.

Wright. Allen and Garlan has used their connector

deﬁnition in their Wright architecture description lan-

guage (Allen and Garlan, 1997). So, software archi-

tecture speciﬁcations in Wright may not be realisable

in distributed cases due to the allowance for the global

constraints via the connectors.

XADL. Realisability may be a concern for XADL

(Dashofy et al., 2002) when an extended schema

adopts the features of connector-centric ADLs such

as Wright. If an extended form of connector types al-

lows for a glue construct to coordinate the behaviours

of the components, this would naturally lead to poten-

tial unrealisability.

COSA. Like Wright, COSA (Oussalah et al., 2004)

enforces a glue in connector speciﬁcations, through

which protocols of interaction among components are

speciﬁed. Thus, COSA too allows potentially unreal-

isable speciﬁcations.

CONNECT. Just like Wright speciﬁcations, CON-

NECT (Issarny et al., 2011) speciﬁcations are poten-

tially unrealisable due to the requirement for a glue in

connector speciﬁcations.

Rapide. Rapide (Luckham, 1996) offers architec-

tural constraints, which are essentially global con-

straints imposed on the interaction of the components

within architecture speciﬁcations. These constraints

are intended to coordinate the actions taken by the

components, ensuring their compliance to particular

global ordering of actions. Therefore, Rapide archi-

tectural constraints serve just as Wright glues and al-

low potentially unrealisable speciﬁcations.

Koala. In Koala (van Ommering et al., 2000), the

modules speciﬁed within composite components act

as glues, coordinating the sub components of the com-

posite components. So, this can cause unrealisable

speciﬁcations if the sub components are distributed.

SOFA. In SOFA (Plasil and Visnovsky, 2002; Bu-

res et al., 2006), the protocol behaviour of a compo-

nent computation can essentially impose a global con-

straint on the conﬁguration of components. As afore-

mentioned, global constraints lead to system speciﬁ-

cations that cannot always be realised in a distributed

manner.

4 DISCUSSIONS & CONCLUSION

Software architectures have been so popular since the

nineties as a high-level design method for specifying

software systems in terms of components and their

relationships (i.e., connectors). Since then, there has

been an ever-increasing attempt towards developing

architectural languages. Today, there are more than

120 known architectural languages (ALs) for specify-

ing software architectures at varying levels of details

and then performing many useful operations such as

formal analysis and implementation code generation

(Ozkaya, 2016a). However, ALs did not gain the ex-

pected momentum unfortunately, and most of them

remain unused by the practitioners in industry (Mala-

volta et al., 2012; Ozkaya, 2016b).

To better understand the ALs and compare them

with each other, I analysed the existing 120 languages

for a set of language requirements determined by

Lago etal (Lago et al., 2015), which are grouped as

MODELSWARD 2017 - 5th International Conference on Model-Driven Engineering and Software Development

388

Figure 3: The ALs that support complex connectors.

language deﬁnition, language features, and tool sup-

port. The analysis results (Ozkaya, 2016a) showed

for each AL the level of support provided for the

language requirements in question and the relation-

ships between the requirements. In this paper, I fo-

cus on two of the requirements analysed, which are

(i) complex connector support (i.e., interaction pro-

tocols) and (ii) the realisability of software architec-

tures. By doing so, the goal is to determine whether

the existing ALs allow for the realisable speciﬁcation

of software architectures in terms of ﬁrst-class com-

ponents and complex connectors (i.e., interaction pro-

tocols).

Among the 120 ALs I analysed, only 37 of them

depicted in Figure 3 support complex connectors

through which interaction protocols can be separated

from components. The rest of the languages in

(Ozkaya, 2016a) either (i) ignore interaction proto-

cols or (ii) allow designers to inject interaction pro-

tocols within component speciﬁcations. However, ig-

noring interaction protocols can lead to architectural

mismatch (Garlan et al., 1995), i.e., the inability to

compose seemingly compatible components due to

wrong assumptions these make about their interac-

tion. If the interaction protocols can be injected in-

side components, components may not then be easily

re-used in different contexts - they become protocol

dependent. This will also hinder the understandability

of the system computations independently from the

system interactions. The analysis of system compo-

nents in isolation will be hindered too, and one may

not easily understand during the analysis whether a

design error is due to a wrong computation or wrong

interaction protocol.

While complex connectors aid in the modular sep-

aration of interaction protocols from components in

software architectures, the interaction protocol speci-

ﬁcations can sometimes be dangerous for practition-

ers. Languages with complex connector support allow

practitioners to specify interaction protocols that can

globally constrain the interacting components (via the

glue element of connectors)

. However, such global

constraints cannot be guaranteed for distributed com-

ponents, which are autonomous entities and can only

know their own local state - global state is not visible

to them. Therefore, software architecture speciﬁca-

tions with complex connectors cannot be realised for

distributed systems. To realise the global constraints,

practitioners will need to add a new controller com-

ponent which will make their system centralised how-

ever. In such a case, any analyses (e.g., performance)

that have been made on the unrealisable speciﬁcation

will all be invalid as the analysed software architec-

ture speciﬁcation can no longer be used as it is for the

implementation.

Note that a few languages (e.g., Rapide (Luckham,

1996), Koala (van Ommering et al., 2000), and SOFA

(Plasil and Visnovsky, 2002)) allow the speciﬁcation of

global constraints in different ways (using different nota-

tions).

Architecture Descriptions of Software Systems: Complex Connectors vs Realisability

389

None of the analysed languages addresses the

unrealisability of the connector-centric architectural

languages - except the XCD language (Ozkaya and

Kloukinas, 2014) that has been introduced very re-

cently. In XCD, while connectors are used for spec-

ifying interaction protocols, all protocol constraints

are locally imposed on the components - global con-

straints are not possible. An XCD connector con-

sists structurally of roles, where each role describe

the local interaction protocol for a participating com-

ponent. If a global constraint is required, this can

only be speciﬁed via a controller component that sits

among other components and coordinates their inter-

action according to a global constraint.

ACKNOWLEDGEMENTS

This work has been supported by the project of the

Scientiﬁc and Technological Research Council of

Turkey (TUBITAK), Grant No: 215E159.

REFERENCES

Allen, R. and Garlan, D. (1997). A formal basis for architec-

tural connection. ACM Trans. Softw. Eng. Methodol.,

6(3):213–249.

Alur, R., Etessami, K., and Yannakakis, M. (2003). Infer-

ence of message sequence charts. IEEE Trans. Soft-

ware Eng., 29(7):623–633.

Binns, P., Englehart, M., Jackson, M., and Vestal, S.

(1996). Domain-speciﬁc software architectures for

guidance, navigation and control. International Jour-

nal of Software Engineering and Knowledge Engi-

neering, 6(2):201–227.

Bures, T. (2005). Automated synthesis of connectors for

heterogeneous deployment. Tech. report no. 2005/4,

Dep. of SW Engineering, Charles University, Prague.

Bures, T., Hnetynka, P., and Plasil, F. (2006). Sofa 2.0: Bal-

ancing advanced features in a hierarchical component

model. In SERA, pages 40–48. IEEE Computer Soci-

ety.

Bures, T. and Plasil, F. (2004). Communication style

driven connector conﬁgurations. In Ramamoorthy, C.,

Lee, R., and Lee, K., editors, Software Engineering

Research and Applications, volume 3026 of Lecture

Notes in Computer Science, pages 102–116. Springer

Berlin Heidelberg.

Canal, C., Pimentel, E., and Troya, J. M. (1999). Speciﬁca-

tion and reﬁnement of dynamic software architectures.

In Donohoe, P., editor, WICSA, volume 140 of IFIP

Conference Proceedings, pages 107–126. Kluwer.

Clements, P. C., Garlan, D., Little, R., Nord, R. L., and

Stafford, J. A. (2003). Documenting software archi-

tectures: Views and beyond. In Clarke, L. A., Dillon,

L., and Tichy, W. F., editors, ICSE, pages 740–741.

IEEE Computer Society.

Dashofy, E. M., van der Hoek, A., and Taylor, R. N. (2002).

An infrastructure for the rapid development of xml-

based architecture description languages. In Tracz,

W., Young, M., and Magee, J., editors, ICSE, pages

266–276. ACM.

Feiler, P. H., Gluch, D. P., and Hudak, J. J. (2006). The Ar-

chitecture Analysis & Design Language (AADL): An

Introduction. Technical report, Software Engineering

Institute.

Galik, O. and Bures, T. (2005). Generating connectors for

heterogeneous deployment. In Nitto, E. D. and Mur-

phy, A. L., editors, SEM, pages 54–61. ACM.

Garlan, D., Allen, R., and Ockerbloom, J. (1995). Architec-

tural mismatch or why it’s hard to build systems out

of existing parts. In ICSE, pages 179–185.

Garlan, D. and Shaw, M. (1994). An introduction to soft-

ware architecture. Technical report, Pittsburgh, PA,

USA.

Holzmann, G. J. (2004). The SPIN Model Checker - primer

and reference manual. Addison-Wesley.

Issarny, V., Bennaceur, A., and Bromberg, Y.-D. (2011).

Middleware-layer connector synthesis: Beyond state

of the art in middleware interoperability. In Bernardo,

M. and Issarny, V., editors, SFM, volume 6659 of

Lecture Notes in Computer Science, pages 217–255.

Springer.

Kiczales, G. and Hilsdale, E. (2001). Aspect-oriented pro-

gramming. SIGSOFT Softw. Eng. Notes, 26(5):313–.

Kloukinas, C. and Ozkaya, M. (2012). Xcd - modular, re-

alizable software architectures. In Pasareanu, C. S.

and Salaün, G., editors, Formal Aspects of Component

Software, 9th International Symposium, FACS 2012,

Mountain View, CA, USA, September 12-14, 2012. Re-

vised Selected Papers, volume 7684 of Lecture Notes

in Computer Science, pages 152–169. Springer.

Lago, P., Malavolta, I., Muccini, H., Pelliccione, P., and

Tang, A. (2015). The road ahead for architectural lan-

guages. IEEE Software, 32(1):98–105.

Luckham, D. C. (1996). Rapide: A language and toolset

for simulation of distributed systems by partial order-

ings of events. Technical report, Stanford University,

Stanford, CA, USA.

Magee, J. and Kramer, J. (1996). Dynamic structure in soft-

ware architectures. In SIGSOFT FSE, pages 3–14.

Magee, J., Kramer, J., and Giannakopoulou, D. (1997).

Analysing the behaviour of distributed software archi-

tectures: a case study. In FTDCS, pages 240–247.

IEEE Computer Society.

Malavolta, I., Lago, P., Muccini, H., Pelliccione, P., and

Tang, A. (2012). What industry needs from architec-

tural languages: A survey. IEEE Transactions on Soft-

ware Engineering, 99.

Medvidovic, N., Oreizy, P., Robbins, J. E., and Taylor, R. N.

(1996). Using object-oriented typing to support archi-

tectural design in the c2 style. In SIGSOFT FSE, pages

24–32.

Medvidovic, N. and Taylor, R. N. (2000). A classiﬁcation

and comparison framework for software architecture

MODELSWARD 2017 - 5th International Conference on Model-Driven Engineering and Software Development

390

description languages. IEEE Trans. Software Eng.,

26(1):70–93.

Oussalah, M., Smeda, A., and Khammaci, T. (2004). An

explicit deﬁnition of connectors for component-based

software architecture. In ECBS, pages 44–51. IEEE

Computer Society.

Ozkaya, M. (2016a). Analysis of architectural languages.

https://sites.google.com/site/ozkayamert1/als. Online;

accessed: 2016-12-17.

Ozkaya, M. (2016b). What is software architecture to prac-

titioners: A survey. In Hammoudi, S., Pires, L. F.,

Selic, B., and Desfray, P., editors, MODELSWARD

2016 - Proceedings of the 4rd International Confer-

ence on Model-Driven Engineering and Software De-

velopment, Rome, Italy, 19-21 February, 2016., pages

677–686. SciTePress.

Ozkaya, M. and Kloukinas, C. (2014). Design-by-

contract for reusable components and realizable ar-

chitectures. In Seinturier, L., de Almeida, E. S.,

and Carlson, J., editors, CBSE’14, Proceedings of

the 17th International ACM SIGSOFT Symposium

on Component-Based Software Engineering (part of

CompArch 2014), Marcq-en-Baroeul, Lille, France,

June 30 - July 4, 2014, pages 129–138. ACM.

Perry, D. E. and Wolf, A. L. (1992). Foundations for the

study of software architecture. SIGSOFT Softw. Eng.

Notes, 17(4):40–52.

Plasil, F. and Visnovsky, S. (2002). Behavior protocols

for software components. IEEE Trans. Software Eng.,

28(11):1056–1076.

Reussner, R., Poernomo, I., and Schmidt, H. (2003). Rea-

soning about Software Architectures with Contrac-

tually Speciﬁed Components. In Cechich, A., Piat-

tini, M., and Vallecillo, A., editors, Component-Based

Software Quality, volume 2693 of Lecture Notes in

Computer Science, page 287–325. Springer Berlin

Heidelberg.

Rumbaugh, J. E., Jacobson, I., and Booch, G. (2005). The

uniﬁed modeling language reference manuel - covers

UML 2.0, Second Edition. Addison Wesley object

technology series. Addison-Wesley.

Shaw, M., DeLine, R., Klein, D. V., Ross, T. L., Young,

D. M., and Zelesnik, G. (1995). Abstractions for soft-

ware architecture and tools to support them. IEEE

Trans. Software Eng., 21(4):314–335.

Taylor, R. N., Medvidovic, N., Anderson, K. M., Jr., E.

J. W., Robbins, J. E., Nies, K. A., Oreizy, P., and

Dubrow, D. L. (1996). A component- and message-

based architectural style for gui software. IEEE Trans.

Software Eng., 22(6):390–406.

Ubayashi, N., Nomura, J., and Tamai, T. (2010). Archface:

A contract place where architectural design and code

meet together. In Kramer, J., Bishop, J., Devanbu,

P. T., and Uchitel, S., editors, ICSE, pages 75–84.

ACM.

van Ommering, R. C., van der Linden, F., Kramer, J.,

and Magee, J. (2000). The koala component model

for consumer electronics software. IEEE Computer,

33(3):78–85.

Architecture Descriptions of Software Systems: Complex Connectors vs Realisability

391