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

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

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