Results 1 - 10
of
212
SOFA 2.0: Balancing Advanced Features in a Hierarchical Component Model
- PROC. OF SERA 2006
, 2006
"... 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 reconfig ..."
Abstract
-
Cited by 86 (6 self)
- Add to MetaCart
(Show Context)
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. 1
Component Composition Errors and Update Atomicity: Static Analysis
- JOURNAL OF SOFTWARE MAINTENANCE AND EVOLUTION: RESEARCH AND PRACTICE
, 2005
"... We discuss the problem of defining a composition operator in behavior protocols in a way which would reflect false communication of the software components being composed. Here the issue is that the classical way in the ADLs supporting behavior description, such as Wright and TRACTA, is to emplo ..."
Abstract
-
Cited by 48 (15 self)
- Add to MetaCart
We discuss the problem of defining a composition operator in behavior protocols in a way which would reflect false communication of the software components being composed. Here the issue is that the classical way in the ADLs supporting behavior description, such as Wright and TRACTA, is to employ a CSP-like parallel composition which inherently yields only "successful traces", ignoring non-accepted attempts for communication. We show that
Adaptation of Service Protocols using Process Algebra and On-the-Fly Reduction Techniques
- In Proc. of ICSOC’08
, 2008
"... Abstract. Software Adaptation is a hot topic in Software Engineering since it is the only way to compose non-intrusively black-box components or services with mismatching interfaces. However, adaptation is a complex issue especially when behavioral descriptions of services are considered. This paper ..."
Abstract
-
Cited by 29 (6 self)
- Add to MetaCart
Abstract. Software Adaptation is a hot topic in Software Engineering since it is the only way to compose non-intrusively black-box components or services with mismatching interfaces. However, adaptation is a complex issue especially when behavioral descriptions of services are considered. This paper presents optimised techniques to generate adaptor protocols, being given a set of service interfaces involved in a composition and an adaptation contract. In this work, interfaces are described using a signature, and a protocol that takes value passing into account. Our proposal is completely supported by tools that automate the generation and the verification of the adaptor protocols. Last, we show how our adaptation techniques are implemented into BPEL. 1
Component Reliability Extensions for Fractal Component Model
, 2008
"... � Component Reliability Extensions for Fractal component model: Architecture/Design manual and User manual ..."
Abstract
-
Cited by 28 (11 self)
- Add to MetaCart
(Show Context)
� Component Reliability Extensions for Fractal component model: Architecture/Design manual and User manual
Model checking of Software Components: Combining Java PathFinder and Behavior Protocol Model Checker
- PathFinder and Behavior Protocol Model Checker, Proceedings of SEW’06, IEEE CS
, 2007
"... 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 highlevel behavior speci ..."
Abstract
-
Cited by 26 (9 self)
- Add to MetaCart
(Show Context)
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 highlevel 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 [1], 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.
Behavioural Models for Hierarchical Components
- In Proceedings of the International SPIN Workshop on Model Checking of Software. Spinger
, 2005
"... Abstract. We describe a method for the specification and verification of the dynamic behaviour of component systems. Building applications using a component framework allows the developers to specify the architecture, the deployment, the life-cycle of the system with well-defined formalisms, and to ..."
Abstract
-
Cited by 24 (7 self)
- Add to MetaCart
(Show Context)
Abstract. We describe a method for the specification and verification of the dynamic behaviour of component systems. Building applications using a component framework allows the developers to specify the architecture, the deployment, the life-cycle of the system with well-defined formalisms, and to gain productivity by reusing existing components. But then one wants to make sure that the application built from existing components is safe, in the sense that its parts fit together appropriately and behave together smoothly. Each component must be adequate to its assigned role within the system, and the update or replacement of a component should not cause deadlock or failure of the rest of the system. The usual notion of type compatibility of interfaces is not sufficient; we need to capture the dynamic interaction between components, and typically to avoid deadlocks or unexpected behaviours in the system. In this work, we focus on hierarchical component systems. We describe both the functional behaviour and the non-functional features (life-cycle management) of components in terms of synchronised transition systems; we define a notion of correct component composition; then we show how we can prove, using (compositional) model-checking techniques, temporal properties of a component system. Transformations of a system, for example replacement of a sub-component, are expressed as transformations of its behavioural semantics, allowing to prove preservation of some properties, or the validity of new properties after transformation. 1
Specification and Generation of Environment for Model Checking of Software Components
, 2007
"... Model checking of isolated software components is inherently not possible because a component does not form a complete program with an explicit starting point. To overcome this obstacle, it is typically necessary to create an environment of the component which is the intended subject to model checki ..."
Abstract
-
Cited by 21 (9 self)
- Add to MetaCart
Model checking of isolated software components is inherently not possible because a component does not form a complete program with an explicit starting point. To overcome this obstacle, it is typically necessary to create an environment of the component which is the intended subject to model checking. We present our approach to automated environment generation that is based on behavior protocols [9]; to our knowledge, this is the only environment generator designed for model checking of software components. We compare it with the approach taken in the Bandera Environment Generator tool [12], designed for model checking of sets of Java classes.
Behavior Protocols Capturing Errors and Updates
- Proceedings of the 2 nd International Workshop on Unanticipated Software Evolution
, 2003
"... We discuss the problem of defining a composition operator in behavior protocols in a way which would reflect false communication of the software components being composed. Here the issue is that the classical way in the ADLs supporting behavior description, such as Wright and TRACTA, is to employ a ..."
Abstract
-
Cited by 20 (4 self)
- Add to MetaCart
(Show Context)
We discuss the problem of defining a composition operator in behavior protocols in a way which would reflect false communication of the software components being composed. Here the issue is that the classical way in the ADLs supporting behavior description, such as Wright and TRACTA, is to employ a CSP-like parallel composition which inherently yields only "successful traces", ignoring non-accepted attempts for communication. We show that resulting from component composition, several types of behavior errors can occur: bad activity, no activity, and divergence. The key idea behind bad activity is that the asymmetry of roles during event exchange typical for real programs should be honored: the caller is considered to be the initiator of the call (callee has only a passive role). In most formal systems, this is not the case. We propose a new composition operator,"consent", reflecting these types of errors by producing an erroneous trace. In addition, by using the consent operator, it can be statically determined, whether the atomicity of a dynamic update of a component is implicitly guarantied thanks to the behavior of its current environment.
Model-Checking Distributed Components: The Vercors Platform
- In Proceedings of the 3rd International Workshop on Formal Aspects of Component Software FACS’2006
, 2006
"... This article presents a component verification platform called Vercors providing means to analyse the behaviour properties of applications built from distributed components. From the behavioural specification of primitive components, and from the architectural description of the composite components ..."
Abstract
-
Cited by 19 (4 self)
- Add to MetaCart
(Show Context)
This article presents a component verification platform called Vercors providing means to analyse the behaviour properties of applications built from distributed components. From the behavioural specification of primitive components, and from the architectural description of the composite components, our tools build models encoding the interactions between the components, suitable for analysis by model-checking tools. The models are hierarchical and parameterized, expressing in a compact way the system behaviour. Then we have tools for instantiating those parameterized models using finite abstractions, and producing input for state-of-the-art verification tools. Our current work also targets the generation of models that include controllers modelling the dynamic management of architectural transformation of an application, such as changes in bindings or replacement of sub-components. We describe the existing tools, give tracks for further developments and show how realistic case-studies can be model-checked using our platform.
Deriving Behavior Specifications from Textual Use Cases
- Oesterreichische Computer Gesellschaft
, 2004
"... The design of a software system or component starts with specifying its requirements; traditionally, use cases written in natural language are used for this task. While this makes use cases easily readable, it neither permits reasoning on requirement specifications (written as use cases), nor employ ..."
Abstract
-
Cited by 19 (1 self)
- Add to MetaCart
(Show Context)
The design of a software system or component starts with specifying its requirements; traditionally, use cases written in natural language are used for this task. While this makes use cases easily readable, it neither permits reasoning on requirement specifications (written as use cases), nor employing the use cases in deriving an initial design in an automated way. While employing linguistic tools to analyze use cases has already been considered, such efforts usually attempted to utilize all the information possibly contained in a use case specification, thus facing the complexity of a natural language. Yet, in a use case, the sentence describing a use case step adheres to a simple prescribed structure, and describes an action, which is either a communication action (among entities involved in the use case), or an internal action.
