Motivations
Up to the present day, many languages for specifying and analyzing software architectures have been proposed. A "first generation" of Architecture Description Languages (ADLs) going from 1990 to 2000, had the main purpose to design an ideal ADL whose chief aim was to enable support of components and connectors specification and their overall interconnection as well as composition, abstraction, reusability, configuration, heterogeneity, and analysis.
Later on, during the "second generation", going from 2000 up to today, new requirements emerged, and new ADLs have been proposed to deal with more specific features such as configuration management, distribution, and product line modeling support.
As a result, a proliferation of architectural languages can be noticed today, each characterized by slightly different conceptual architectural elements, different syntax or semantics, focussing on a specific operational domain, or only suitable for different analysis techniques. One of the main reasons for such a long list of architectural languages is related to stakeholder concerns: a notation has to adequately capture design decisions judged fundamental by the system's stakeholders, thus the notion of software architecture has been expanded and notations as well as approaches for modeling software architectures have themselves continued to evolve. Stakeholder concerns are various, ever evolving, and adapting to new environment requirements; hence it is impossible to capture all such concerns with a single, narrowly focused notation. Instead of a unique language for specifying software architectures, we must therefore accept the existence of domain specific languages for Software Architecture (SA) modeling, therefore considering each ADL aimed at solving specific stakeholder concerns (e.g., architectural styles, real-time constraints, data-flow-architectures, code generation, etc.). Even the adoption of UML for modeling architectures is biased by different concerns: a number of UML profiles and extensions have been proposed for modeling different concerns, thus increasing even more the proliferation of architectural languages. These extensions cannot fully represent all aspects/features of every ADL and on the other side is impractical to have a "universal" notation.
Furthermore, when architecting a software system several significant decisions must be taken. Some of them cannot be taken at the beginning of the architecting phase and are made iteratively by analyzing and studying an architectural prototype often sketched by the architect starting from the nebulous dark set of constraints, requirements and ideas. Moreover, typically it is not immediately evident what kind of nonfunctional aspect must be considered in a system. This implies that the choice of the best ADL (as required by the considered nonfunctional aspect) may change during the architecting phase. Whether the architecture has been already modeled in a specific ADL, an interchange language is required or the architecture must be rewritten in the most suitable ADL.
These considerations led us to propose DUALLy.