Explicit Architectural Policies to Satisfy NFRs Using COTS

Abstract

Abstract. Software architecture decisions hinge more on non-functional requirements (NFRs) than on functional ones, since the architecture stipulates which software to build. Model-Driven Architecture (MDA) aims to automate the derivation/generation of software from high level architectural specifications, but most current MDA implementations start from software design (i.e. how to build a software piece) rather than software architecture. This article presents an approach to extend MDA through the concepts of architectural policies and mechanisms. The key ideas are representation of NFRs through architectural concerns using architectural policies, systematic reification of policies into mechanisms, and multi-dimensional description of components as implementators of mechanisms. A detailed illustrative example is provided. Azimut framework realizes these ideas, supports larger-scale work through catalogs of policies and components, and allows traceability and reuse of architecture by enabling enabling these architecture-level descriptions and reasoning.

Weak Constraint Programming to Identify Alternative Composite COTS-Based Software Systems from Imperfect Information

“…Since components information is generally incomplete, imprecise and unreliable, Azimut propose forms to work with this incomplete information [14,15,6]. This paper proposes certain criteria of confidence associated to the components information, this could be applied in the models of constraint programming, allows generating alternatives solutions (CCSS), and, evaluating and selecting the solution which best meets the requirements.…”

“…This article describes the use of constraint programming to automate the process of generation, evaluation and selection of CCSS in the early development activities of a project, based on the Azimut approach [14,15,6].…”

“…As a brief example (taken from [14]), consider intercommunication among applications. One architectural concern is the communication type, which might have the dimensions of sessions, topology, sender, and integrity v/s timeliness; to this we add synchrony.…”

Multidimensional Catalogs for Systematic Exploration of Component-Based Design Spaces

“…As a brief example (taken from [24]), consider inter-communication among applications. One architectural concern is the communication type, which might have the dimensions of sessions, topology, sender, and integrity v/s timeliness [18]; to this we add synchrony.…”

“…We have deployed the described approach and techniques in the Azimut framework [24], which extends MDA to automate architectural decisions from NFRs through components. The prototype is described in [26].…”