Component-based specification of software architecture constraints

Tibermacine, Chouki; Sadou, Salah; Dony, Christophe; Fabresse, Luc

doi:10.1145/2000229.2000235

Cited by 17 publications

(13 citation statements)

References 11 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Such kind of specifications is subject to reuse. They are frequently assembled together to build more complex architecture constraints [30]. We have presented in this paper a process for translating architecture constraints into components.…”

Section: Discussionmentioning

confidence: 99%

“…r e a l i z i n g C l a s s i f i e r When applying our proposed approach, we change the format of the constraint (Listing 1.1) from a textual "gross" specification into an architecture description made of "constraint-components" and "query-components". These components are described with an ADL named CLACS [30] (pronounced Klax).…”

Section: Illustrative Examplementioning

confidence: 99%

“…We propose a two-step process which takes as input a gross OCL architecture constraint specification expressed in the UML metamodel, and which provides as output constraintscomponents expressed with CLACS ADL. We propose to generate architecture constraints as "constraint-components" [30] so that we can put them on "shelves" and thereafter make them reusable, customizable and composable with others to produce more complex constraints.…”

Section: Introduction: Context and Problem Statementmentioning

confidence: 99%

See 2 more Smart Citations

Automatic Translation of Architecture Constraint Specifications into Components

Kallel

Tramoni

Tibermacine

et al. 2015

Software Architecture

Self Cite

View full text Add to dashboard 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

show abstract

Section: Discussionmentioning

confidence: 99%

Section: Illustrative Examplementioning

confidence: 99%

Section: Introduction: Context and Problem Statementmentioning

confidence: 99%

See 1 more Smart Citation

Automatic Translation of Architecture Constraint Specifications into Components

Kallel

Tramoni

Tibermacine

et al. 2015

Software Architecture

Self Cite

View full text Add to dashboard Cite

show abstract

“…The results of the transformation are checked using architecture constraints also implemented as Compo components [18].…”

Section: Advanced Examplementioning

confidence: 99%

Wringing out objects for programming and modeling component-based systems

Špaček

Dony

Tibermacine

et al. 2013

Proceedings of the Second International Workshop on Combined Object-Oriented Modelling and Programming Languages

Self Cite

View full text Add to dashboard Cite

Languages and technologies used to implement componentbased software are not component-based, i.e. while the design phase happens in the component world, the programming phase occurs in the object-oriented world. When an object-oriented language is used for the programming stage, then the original component-based design vanish, because component concepts like requirements and architectures are not treated explicitly. This makes it difficult to keep model and its implementation causally connected. We present a new pure reflective component-based programming and modeling language where all core component concepts are treated explicitly and therefore keeping original componentdesign alive. The language makes it possible to model and program component-based software using the same language plus its uniform component-based meta-model and integrated reflection capabilities make the language and its applications open and flexible.

show abstract

“…The first trend such as [38,39] focuses on the respect of the applied pattern in the architecture model. StADs take the form of architectural constraints describing the organisation imposed by the pattern.…”

Section: Introductionmentioning

confidence: 99%

Preserving architectural decisions through architectural patterns

et al. 2014

Self Cite

View full text Add to dashboard Cite

Architectural decisions have emerged as a means to maintain the quality of the architecture during its evolution. One of the most important decisions made by architects are those about the design approach such as the use of patterns or styles in the architecture. The structural nature of this type of decisions give them the potential to be controlled systematically. In the literature, there are some works on the automation of architectural decision violation checking. In this paper we show that these works do not allow to detect all possible architectural decision violations. To solve this problem we propose an approach which: i) describes architectural patterns that hold the architectural decision definition, ii) integrates architectural decisions into an architectural model and, iii) automates the architectural decision conformance checking. The approach is implemented using Eclipse Modeling Framework and its accompanying technologies. Starting from well-known architectural patterns, we show that we can formalize all those related to the structural aspect. Through two evaluations, we show that our approach can be adapted to different architecture paradigms and allows to detect more violations comparing to the existing approaches.

show abstract

Component-based specification of software architecture constraints

Cited by 17 publications

References 11 publications

Automatic Translation of Architecture Constraint Specifications into Components

Automatic Translation of Architecture Constraint Specifications into Components

Wringing out objects for programming and modeling component-based systems

Preserving architectural decisions through architectural patterns

Contact Info

Product

Resources

About