On the Interactions of Component Interfaces

Graduate Student Research Forum

Department of Computer Science

March 16, 2004

Donald Craig

Ph.D. Candidate

What is a Component?

“A software component is a unit of composition with contractually specified interfaces and explicit dependencies only. A software component can be deployed independently and is subject to composition by third parties.”

– Clemens Szyperski (1999)

Component Software : Beyond Object-Oriented Programming

“An independently deliverable piece of functionality provide access to its services through interfaces.”

– Alan W. Brown (2001)

“An Overview of Components and Component-Based Development.”

“Reusable software components are self-contained, clearly identifiable artefacts that describe and/or perform specific functions and have clear interfaces, appropriate documentation and a defined reuse status.”

– Johannes Sametinger (1997)

Softare Engineering with Reusable Components

Component Interfaces

Most definitions in the literature are imprecise, ambiguous and sometimes even contradictory.

One notion most definitions have in common is the concept of an “interface” through which a component communicates.

Some of the challenges in the development of large software architectures include the issues of “reuse” and “substitutability.”

Central to these issues is the concept of “component compatibility.”

How can we tell when two components are compatible?

Component Descriptions

We need formalisms to describe components (particularly, their interfaces), the component's environment and their communication protocols.

Observations:

No component exists as a separate entity. A software architecture can be composed of many interconnected components organized hierarchically.

Components use services of other components (requester) or they can provide services to other components (provider). A component can simulateously be a requester and provider.

We can treat component interaction as a form of synchronization via “token passing.”.

We can use petri-nets to formally model the interacations of the interfaces of a component

Component Abstraction

Requester behaviour is the set of sequences of service operations that are performed at the component’s interface.

Provider behaviour is a set of all sequences of service operations that it supports.

We can think of a component’s behaviour in terms of languages.

Requester Component

Provider Component

a

(bc)*

d

Component Languages

Requester

a

b

c

d

Provider

a

b

c

d

(a(bc)*d)*

(a(b|c)*d)*

Petri-net Interfaces

Provider

Requester

Interface

a

b

c

d

a

b

c

d

Petri-net Interfaces

Provider

Requester

Interface

a

b

c

d

a

b

c

d

Petri-net Interfaces

Provider

Requester

Interface

a

b

c

d

a

b

c

d

Petri-net Interfaces

Provider

Requester

Interface

a

b

c

d

a

b

c

d

Petri-net Interfaces

Provider

Requester

Interface

a

b

c

d

a

b

c

d

Petri-net Interfaces

Provider

Requester

Interface

a

b

c

d

a

b

c

d

Petri-net Interfaces

Provider

Requester

Interface

a

b

c

d

a

b

c

d

Petri-net Interfaces

Provider

Requester

Interface

a

b

c

d

a

b

c

d

Petri-net Interfaces

Provider

Requester

Interface

a

b

c

d

a

b

c

d

Petri-net Interfaces

Provider

Requester

Interface

a

b

c

d

a

b

c

d

Petri-net Interfaces

Provider

Requester

Interface

a

b

c

d

a

b

c

d

Petri-net Interfaces

Provider

Requester

Interface

a

b

c

d

a

b

c

d

Petri-net Interfaces

Provider

Requester

Interface

a

b

c

d

a

b

c

d

Petri-net Interfaces

Provider

Requester

Interface

a

b

c

d

a

b

c

d

Component Compatibility

Definition: If two components can be connected using this construction technique and the resulting net is deadlock free, then the components are compatible.

Deadlock detection algorithms exist for simple petri-nets.

Compatibility can also be established using languages generated by the components’ interface (as we will see later).

Note that in the previous example, if we swap the provider and requester, the net will deadlock.

Incompatible Interfaces

Requester

Interface

Provider

(a(bc)*d)*

(a(b|c)*d)*

a

b

c

d

a

b

c

d

Component Compatibility

By examining the languages that denote the behaviour of the provider and requester, we can also determine their compatibility.

L(R) ⊆ L(P) ⇔ CR is compatible with CP

Timing issues associated with component compatibility can be addressed by assigning appropriate timings to the transitions of the provider and requestor.

L(P)

L(R)

Work to be Done

Formalization of the approach:

Consistency as the property of net models and its verification.

Hierarchical Interfaces:

This would more accurately model how software is composed in a large-scale software architecture.

XML Representation:

Representation would have to consider the services as well as their respective ordering.

Autonomous Software Assembly:

Given appropriate representations of software components, can they assemble themselves into usable architectures that satisify system requirements?

Conclusions

Using petri-nets to model the structural and dynamic nature of component interactions offers a uniform and systematic approach to the analysis of component-based systems.

We can use deadlock analysis or language analysis to determine component compatibility. Indeed, there may be a theoretical connection between these two approaches.

What about a metric that measures the degree to which components are compatible?

Although complete automatic assembly may not be achievable, this work may increase the amount of automation involved in software development.

2004-03-11T19:25:36