Reasoning about Software Architectures with Contractually Specified Components

Reussner, Ralf; Poernomo, Iman; Schmidt, Heinz

doi:10.1007/978-3-540-45064-1_14

Cited by 35 publications

(21 citation statements)

References 18 publications

Supporting

Mentioning

Contrasting

Unclassified

Order By: Relevance

“…Interface descriptions and dependencies between components are required. If possible, the analyzed architectural documentation should provide service effect specifications [56] for individual software components, which determine the control and data flow through components on an architectural level.…”

Section: Data Collectionmentioning

confidence: 99%

Sustainability evaluation of software architectures

Koziolek¹

2011

Proceedings of the Joint ACM SIGSOFT Conference -- QoSA and ACM SIGSOFT Symposium -- ISARCS on Quality of Software Architecture

109

View full text Add to dashboard Cite

Long-living software systems are sustainable if they can be cost-efficiently maintained and evolved over their entire lifecycle. The quality of software architectures determines sustainability to a large extent. Scenario-based software architecture evaluation methods can support sustainability analysis, but they are still reluctantly used in practice. They are also not integrated with architecture-level metrics when evaluating implemented systems, which limits their capabilities. Existing literature reviews for architecture evaluation focus on scenario-based methods, but do not provide a critical reflection of the applicability of such methods for sustainability evaluation. Our goal is to measure the sustainability of a software architecture both during early design using scenarios and during evolution using scenarios and metrics, which is highly relevant in practice. We thus provide a systematic literature review assessing scenario-based methods for sustainability support and categorize more than 40 architecture-level metrics according to several design principles. Our review identifies a need for further empirical research, for the integration of existing methods, and for the more efficient use of formal architectural models.

show abstract

Section: Data Collectionmentioning

confidence: 99%

Sustainability evaluation of software architectures

Koziolek¹

2011

Proceedings of the Joint ACM SIGSOFT Conference -- QoSA and ACM SIGSOFT Symposium -- ISARCS on Quality of Software Architecture

109

View full text Add to dashboard Cite

show abstract

“…• The third, more relaxed view of completeness, requires connecting only the interfaces that are strictly necessary [12,17,18] by exploiting the component behavior's description. This is typically done by analyzing protocols which makes completeness checking less immediate.…”

Section: Software Architecture Correctness and Completeness In Cbsementioning

confidence: 99%

“…This does not complicate completeness checking, yet increases the opportunities of building a complete architecture given a set of predefined components. However, associating the mandatory / optional property to an interface regardless of the assembly context does not increase the capability of individual components to be reused in various contexts.• The third, more relaxed view of completeness, requires connecting only the interfaces that are strictly necessary [12,17,18] by exploiting the component behavior's description. This is typically done by analyzing protocols which makes completeness checking less immediate.…”

mentioning

confidence: 99%

Search‐based many‐to‐one component substitution

Desnos

Huchard

Tremblay³

et al. 2008

J. Softw. Maint. Evol.: Res. Pract.

View full text Add to dashboard Cite

SUMMARYIn this paper, we present a search-based automatic many-to-one component substitution mechanism. When a component is removed from an assembly to overcome component obsolescence, failure or unavailability, most existing systems perform component-tocomponent (one-to-one) substitution. Thus, they only handle situations where a specific candidate component is available. As this is not the most frequent case, it would be more flexible to allow a single component to be replaced by a whole component assembly (many-to-one component substitution). We propose such an automatic substitution mechanism, which does not require the possible changes to be anticipated and which preserves the quality of the assembly. This mechanism requires components to be enhanced with ports, which provide synthetic information on components' assembling capabilities. Such port-enhanced components then constitute input data for a searchbased mechanism that looks for possible assemblies using various heuristics to tame complexity.key words: component substitution, component assembly evolution, search-based building process, many-to-one component replacement, heuristics, dead components Introduction Nowadays, software systems have to meet the needs of long life, autonomous and ubiquitous applications and must therefore be flexible, dynamic, and adaptable like never before. * Correspondence to: LGI2P, Ecole des Mines d'Alès, Parc scientifique Georges Besse, F30035 Nîmes cedex, France † E-mail: Nicolas.Desnos@ema.fr, huchard@lirmm.fr, tremblay.guy@uqam.ca, Christelle.Urtado@ema.fr, Sylvain.Vauttier@ema.fr Component-based software engineering (Cbse) [1] is a good solution to optimize software reuse and dynamic evolution while guaranteeing the quality of the software. Typically, a component is seen as a black box which provides and requires services through its interfaces. An architecture is built to fulfill a set of functional objectives (its functional requirements) while enforcing a set of properties (its non-functional requirements) and is described as a static interconnection of software component classes. A component assembly is a runtime instantiation of an architecture composed of linked component instances.In long life applications or evolving environments, component substitution is a necessary mechanism for software evolution: it is a response to such events as component obsolescence, failure or unavailability. Anticipating valid component substitutions while designing some software is not always possible as the various contexts in which that software may run are not known in advance. Repairing a component assembly after a component has been removed while still preserving its whole set of functionalities is thus difficult. When a component is removed from an assembly, most existing approaches perform component-to-component (oneto-one) substitution [2,3,4,5]. However, these approaches rely on the fact that an appropriate component, candidate for substitution, is available. This situation can hardly happen because it is difficult to fin...

show abstract

“…The functional properties consist of interface specifications (i.e., signatures and protocols) and descriptions of internal dependencies between provided and required interfaces. We use service effect specifications from [7] to describe such dependencies. They model how a provided services calls its required services and can be specified by state machines.…”

Section: Specification Workflowmentioning

confidence: 99%

“…In this workflow, interoperability problems are solved and the architecture is optimised. For example, parametrised contracts, which are modelled as service effect specifications, can be computed [7]. The outputs of the specification workflow are an optimised architecture and component specifications with refined interfaces.…”

Section: Specification Workflowmentioning

confidence: 99%

A QoS Driven Development Process Model for Component-Based Software Systems

Koziolek

Happe

2006

Component-Based Software Engineering

View full text Add to dashboard Cite

Abstract. Non-functional specifications of software components are considered an important asset in constructing dependable systems, since they enable early Quality of Service (QoS) evaluations. Several approaches for the QoS analysis of component-based software architectures have been introduced. However, most of these approaches do not consider the integration into the development process sufficiently. For example, they envision a pure bottom-up development or neglect that system architects do not have complete information for QoS analyses at their disposal. We extent an existing component-based development process model by Cheesman and Daniels to explicitly include early, model-based QoS analyses. Besides the system architect, we describe further involved roles. Exemplary for the performance domain, we analyse what information these roles can provide to construct a performance model of a software architecture.

show abstract

Reasoning about Software Architectures with Contractually Specified Components

Cited by 35 publications

References 18 publications

Sustainability evaluation of software architectures

Sustainability evaluation of software architectures

Search‐based many‐to‐one component substitution

A QoS Driven Development Process Model for Component-Based Software Systems

Contact Info

Product

Resources

About