Context: Architecture constraints are specifications of conditions to which an architecture model must adhere in order to satisfy an architecture decision imposed by a given design principle. These constraints can be specified with predicate languages like OCL at design time and checked on design artifacts. Objective: Many works in the literature studied the importance of checking these constraints to guarantee quality on design models, and to prevent technical debt and maintenance difficulties. In this paper, we propose a process whose ultimate goal is to enable the checking of these constraints in the implementation stage. Method: The proposed process takes as input a textual specification of an architecture constraint specified at design stage. It translates this specification into meta-programs and then it uses them with aspect-oriented programming to check constraints at the implementation stage and at run-time on object-oriented programs. Results: We experimented an implementation of this process on a set of 12 architecture constraints. The results of this experimentation showed that our process is able to statically and dynamically detect architecture constraint violations on toy object-oriented applications, but also on real-world ones. Conclusion: The automatic checking of architecture constraints is important at source code level and at runtime. It avoids the disappearance of architecture decision knowledge in implementation artifacts, and facilitates later their maintenance.

Currently, architecture constraints can be specified and checked in different paradigms of software development, the object-oriented, component-based and service-based one. But the current state of the art and practice do not consider their specification at a high level of abstraction, independently from any paradigm vocabulary. We propose in this paper a process combining graphs and feature modeling to specify multi-paradigm architecture constraints. These constraints are expressed with OCL on a particular meta-model of graphs. Then these constraints can be transformed to any chosen paradigm, after their configuration using a feature/variability model. This transformation allows later to handle these constraints in that (chosen) paradigm: to refine them, to generate source code from them, and to check them on models and on source code. A case study is presented in this paper; it concerns architecture constraint specification and configuration under software migration from the object-oriented to the component-based paradigm.

Architecture constraints are components of design documentation. They enable designers to enforce rules that architecture descriptions should respect. Many systems make it possible to associate constraints to models at design stage but very few enable their association to code at implementation stage. When possible, this is done manually, which is a tedious, error prone and time consuming task. Therefore, we propose in this work a process to automatically generate executable constraints associated to programs' code from model-based constraints. First, the process translates the constraints specified at design-time into constraint-components described with an ADL, called CLACS. Then, it creates constraint-services which can be registered and later invoked to check their embedded constraints on component- and service based applications. We chose to target components and services in order to make architecture constraints reusable, searchable in registries, customizable and checkable at the implementation stage. The generated constraint-services use the standard reflective (meta) layer provided by the programing language to introspect elements of the architecture. We experimented our work on a set of 15 architecture constraints and on a real-world system in order to evaluate the effectiveness of the process. (C) 2017 Elsevier Inc. All rights reserved.

In order to make explicit and tangible their design choices, software developers integrate, in their applications' models, constraints that their models and their implementations should satisfy. Various environments enable constraint checking during the modeling stage, but inmost 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.

Les contraintes d'architecture sont des specifications definies par les developpeurs dans la phase de conception, qui permettent de verifier, apres une evolution de l'architecture, si sa description est encore conforme aux conditions imposees par un patron ou un style architectural, ou bien une regle de conception generale. Ces specifications peuvent etre exprimees avec un langage standardise comme OCL. Elles sont la plupart du temps des specifications brutes sans aucune structure permettant leur parametrage et reutilisation. Afin de pouvoir les verifier dans la phase d'implementation nous proposons dans ce travail une methode pour traduire automatiquement ces specifications en composants executables. En plus de les rendre verifiables en phase d'implementation, nous avons choisi de cibler les composants logiciels afin de rendre ces contraintes d'architecture reutilisables, personnalisables et composables. Puisque les contraintes d'architecture doivent analyser les descriptions d'architecture, les composants generes utilisent le mecanisme de reflexivite standard fourni par le langage de programmation. Notre implementation prend en entree des contraintes OCL specifiees sur le metamodele UML. Elle produit en sortie des composants programmes en COMPO, un langage de programmation par composants reflexif developpe par notre equipe.

Architecture 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.

Les contraintes d'architecture sont des specifications definies par les developpeurs dans la phase de conception, qui permettent de verifier, apres une evolution de l'architecture, si sa description est encore conforme aux conditions imposees par un patron ou un style architectural. Ces specifications peuvent etre exprimees avec un langage standardise comme OCL (Object Constraint Language). Afin de verifier ces contraintes d'architecture dans la phase d' implementation nous devrions soit: i) reecrire entierement ces contraintes avec un langage qui est interpretable dans cette phase de developpement , ou ii) developper de nouveaux interpreteurs pour le langage de contrainte (OCL, par exemple) qui peuvent analyser le code des programmes sur lesquels les contraintes doivent etre verifiees. Ce dernier choix est difficile a mettre en œuvre et necessite beaucoup de travail. Cependant, meme en optant pour la premiere solution, la tâche de reecrire entierement les contraintes dans la phase d' implementation est fastidieuse et source d'erreurs. Nous proposons dans ce travail une methode pour traduire les specifications de contraintes d'architecture en composants executables. En plus de les rendre verifiables en phase d'implementation, nous avons choisi de cibler les composants logiciels afin de rendre ces contraintes d'architecture reutilisables et composables. Puisque les contraintes d'architecture doivent analyser les descriptions d'architecture, les composants generes utilisent le mecanisme de reflexivite standard fourni par le langage de programmation. Notre implementation prend en entree des contraintes OCL specifiees sur le meta-modele UML. Elle produit des composants programmes en COMPO, un langage de programmation par composants.

Afin de formaliser leurs choix de conception, les concepteurs des logiciels specifient des contraintes sur les modeles de leurs applications. Il s'avere important de specifier ces contraintes non seulement dans la phase de conception mais aussi dans la phase d'implementation en les rendant verifiables sur le code. La specification de ces contraintes peut se faire manuellement mais celles-ci peuvent etre obtenues automatiquement avec la generation de code de leurs modeles. Plusieurs travaux et outils existent permettant la generation automatique des differents modeles en code source. Cependant, la plupart de ces outils ne considerent pas la generation des contraintes textuelles associees a ces modeles en code. Pour ceux qui le font, la transformation est appliquee sur des contraintes fonctionnelles mais non architecturales. Dans ce contexte, nous avons developpe une methode qui permet d'ecrire des contraintes d’architecture d’un modele donne en se basant sur son meta-modele et ensuite generer du code a partir de ces contraintes sous la forme d’un meta-programme.