On-Demand Quality-Oriented Assistance in Component-Based Software Evolution

Studies in Computational Intelligence

Tramoni

et al. 2015

Self Cite

International audienceIn order to make explicit and tangible their design choices, software developers integrate, in their applications' models, constraints that their models and their implemetations should satisfy. Various environments enable constraint checking during the modeling stage, but in most cases they do not generate code that would enable the checking of these constraints during the implementation stage. It turns out that this is possible in a number of cases. Environments that provide this functionality only offer it for functional constraints (related to the states of objects in applications) and not for architectural ones (related to the structure of applications). Considering this limitation, we describe in this paper a system that generates metaprograms starting from architecture constraints, written in OCL at the metamodel level, and associated to a specific UML model of an application. These metaprograms enable the checking of these constraints at runtime

Section: Resultsmentioning

confidence: 99%

Automatic Translation of OCL Meta-Level Constraints into Java Meta-Programs

Kallel

Studies in Computational Intelligence

Tramoni

et al. 2015

Self Cite

“…This ensures easy and safe evolution (maintenance) activities on the software. Indeed, among the maintenance activities, understanding the software architecture before its evolution, and iterations between regression testing and applying concrete changes on the software, are by far the most expensive (52). By making the most important architectural choices explicit and formal, on the one hand, we facilitated the architecture comprehension (through knowledge documentation) and on the other, we automated some checking that allows an assistance to the evolution activity.…”

Section: Discussionmentioning

confidence: 99%

“…This assistance notifies developers on-the-fly, whenever an architectural change affects the documented architectural choices. This contributes in reducing the costs related to the software evolution activity by anticipating some regression tests, as detailed in (52).…”

Section: Discussionmentioning

confidence: 99%

See 1 more Smart Citation

A family of languages for architecture constraint specification

Journal of Systems and Software

Fleurquin

Sadou

2010

Self Cite

During software development, architecture decisions should be documented so that quality attributes guaranteed by these decisions and required in the software specification could be persisted. An important part of these architectural decisions is often formalized using constraint languages which differ from one stage to another in the development process. In this paper, we present a family of architectural constraint languages, called ACL. Each member of this family, called a profile, can be used to formalize architectural decisions at a given stage of the development process. An ACL profile is composed of a core constraint language, which is shared with the other profiles, and a MOF architecture metamodel. In addition to this family of languages, this paper introduces a transformation-based interpretation method of profiles and its associated tool.

“…Architecture constraints are used during the evolution of a software architecture for guaranteeing that changes do not have bad side effects on the applied architecture patterns or styles, and thus on the quality [28].…”

Section: Introduction: Context and Problem Statementmentioning

confidence: 99%

Automatic Translation of Architecture Constraint Specifications into Components

Kallel

Tramoni

et al. 2015

Software Architecture

Self Cite

International audienceArchitecture constraints are specifications defined by developers at design-time and checked on design artifacts (architecture descriptions , like UML models). They enable to check, after an evolution, whether an architecture description still conforms to the conditions imposed by an architecture pattern, style or any design principle. One possible language for specifying such constraints is the OMG's OCL. Most of these architecture constraints are formalized as " gross " specifications, without any structure or parameterization possibilities. This causes difficulties in their reuse. We propose in this work a process for translating architecture constraints into a special kind of components called constraint-components. This makes these specifications reusable (easily put and checked out in/from repositories), parametrizable (generic and applicable in different contexts) and composable with others. We implemented this process by considering the translation of OCL constraints into constraint-components described with an ADL called CLACS