Frantisek Plasil

SOFA 2.0: Balancing Advanced Features in a Hierarchical Component Model

Component-based software engineering is a powerful paradigm for building large applications. However, our experience with building application of components is that the existing advanced component models (such as those offering component nesting, behavior specification and checking, dynamic reconfiguration to some extent, etc.) are subject to a lot of limitations and issues which prevent them from being accepted more widely (by industry in particular). We claim that these issues are specifically related to (a) the lack of support for dynamic reconfigurations of hierarchical architectures, (b) poor support for modeling and extendibility of the control part of a component, and (c) the lack of support for different communication styles applied in inter-component communication. In this paper, we show how these problems can be addressed and present an advanced component system SOFA 2.0 as a proof of the concept. This system is based on its predecessor SOFA, but it incorporates a number of enhancements and improvements

The Common Component Modeling Example: Comparing Software Component Models

This volume defines a common example for modelling approaches of component based systems. It is based on the Dagstuhl research seminar CoCoME (Common Component Modelling Example), which was held from August 1-3, 2007, at Schloss Dagstuhl, Germany. The Common Component Modelling Example makes it possible to compare different approaches and to validate existing models. It serves as a platform for the classification of existing models and approaches and the interchange of research ideas, enabling researchers to focus and to tackle aspects less frequently dealt with. The CoCoME project is an ongoing venture, one of the aims of which is the adoption of the Common Component Modelling Example by the entire component community as a means of comparing and validating their approaches.

DEECO: an ensemble-based component system

The recent increase in the ubiquity and connectivity of computing devices allows forming large-scale distributed systems that respond to and influence activities in their environment. Engineering of such systems is very complex because of their inherent dynamicity, open-endedness, and autonomicity. In this paper we propose a new class of component systems (Ensemble-Based Component Systems - EBCS) which bind autonomic components with cyclic execution via dynamic component ensembles controlling data exchange. EBCS combine the key ideas of agents, ensemble-oriented systems, and control systems into software engineering concepts based on autonomic components. In particular, we present an instantiation of EBCS - the DEECo component model. In addition to DEECo main concepts, we also describe its computation model and mapping to Java. Lastly, we outline the basic principles of the EBCS/DEECo development process.

What characterizes a (software) component

The definitions and discussions below were contributed via e-mail. They are arranged by date. The experts, listed alphabetically above, participated in this virtual round table during the first quarter of 1998.

An architectural view of distributed objects and components in CORBA, Java RMI and COM/DCOM

The goal of this paper is to provide an architectural analysis of the existing distributed objectoriented platforms. Based on a relatively small number of design patterns, our analysis aims at a unified view of the platforms. We achieve this by articulating a series of key issues to be addressed in analyzing a particular platform. This approach is applied systematically to the CORBA, Java RMI and COM/DCOM platforms.

Dynamic reconfiguration and access to services in hierarchical component models

This paper addresses the unavoidable problem of dynamic reconfig-uration in component-based system with a hierarchical component model. The presented solution is based on (1) allowing several well defined patterns of dynamic reconfiguration and on (2) introducing a utility interface concept, which allows using a service provided under the SOA paradigm from a component-based system. The paper is based on our experience with non-trivial case studies written for component-based systems SOFA and Fractal.

Component composition errors and update atomicity: static analysis

Dynamic evolution inherently involves dynamic update and the issue of its atomicity. We show how this issue can be addressed in a similar manner to a communication failure via an extension to behavior protocols. First, we discuss the problem of defining a composition operator for behavior protocols so as to be able to reflect communication failures. Classical architecture description languages (ADLs) supporting behavior description, such as Wright and TRACTA, use a CSP-like parallel composition, which inherently yields only ‘successful traces’ ignoring non-accepted communication attempts. We show that component composition can produce several different types of behavior errors: bad activity, no activity, and divergence. The key idea behind bad activity is that real programs typically have an asymmetry of roles during event exchange: the caller is considered to be the initiator of the call while the callee has only a passive role. This contrasts with most formal systems, which treat communication symmetrically. We propose a new composition operator, ‘consent’, which reflects these types of errors by producing erroneous traces. By using the consent operator it can be statically determined whether the atomicity of a dynamic update of a component is implicitly guaranteed by the behavior of its current environment. Copyright

Software Connectors and their Role in Component Deployment

To support rapid software evolution, it is desirable to construct software systems from reusable components. In this approach, the architecture of a system is described as a collection of components along with the interactions among these components. Whereas the main system functional blocks are components, the properties of the system also strongly depend on the character of the component interactions. This fact gave birth to the “connector” concept which is an abstraction capturing the nature of these interactions. The problem tackled in this paper is that even though the notion of connectors originates in the earliest papers on software architectures [20, 15], connectors are currently far from being a typical first class entity in the contemporary component-based systems. By articulating the “deployment anomaly”, the paper identifies the role connectors should play when the distribution and deployment of a component-based application is considered. Further, we introduce a connector model reflected at all the key stages of an application’s development: ADL specification, deployment, and implementation.

Bounding component behavior via protocols

We enhance the SOFA Component Description Language with a semantic description of a components functionality. There are two key requirements this description aims to address: first, it should ensure correct composition of the nested architectural abstractions (for design purposes); second, it should be easy-to-read so that an average user can identify a component with the correct semantics for the purposes of component trading. The semantic description in SOFA expresses the behavior of the component in terms of behavior protocols using a notation similar to regular expressions which is easy to read and comprehend. The behavior protocols are used on three levels: interface, frame, and architecture. The key achievements of the paper include the definition of the protocol conformance relation. Using this relation, the designer can in most cases statically verify that the frame protocol adheres to the requirements of the interface protocols, and that the architecture protocol adheres to the requirements of the frame and interface protocols.

Model Checking of Software Components: Combining Java PathFinder and Behavior Protocol Model Checker

Although there exist several software model checkers that check the code against properties specified e.g. via a temporal logic and assertions, or just verifying low-level properties (like unhandled exceptions), none of them supports checking of software components against a high-level behavior specification. We present our approach to model checking of software components implemented in Java against a high-level specification of their behavior defined via behavior protocols, which employs the Java PathFinder model checker and the protocol checker. The property checked by the Java PathFinder (JPF) tool (correctness of particular method call sequences) is validated via its cooperation with the protocol checker. We show that just the publisher/listener pattern claimed to be the key flexibility support of JPF (even though proved very useful for our purpose) was not enough to achieve this kind of checking