State of the art

In principle the work on early aspects and aspect-oriented software architecture design  in particular is in the pioneering stage. The ultimate goal of this research is to come up with techniques to cope with the architectural crosscutting concerns. The current literature on software architecture design provide some related issues that somehow try to cope with crosscutting architectural concerns, albeit not in an "aspect-oriented" manner. In this context we can basically identify architectural styles, architectural views and Model-Driven Architecture.

Architectural Styles

Architectural styles or patterns provide a generic configuration of architectural components and implicit guidelines to meet various quality factors, which are in essence crosscutting. In these conventional architectural styles, the reasoning on these quality concerns remains implicit and quality is considered to be in the configuration of components. An example of an implicit guideline is, for example, “Use the pipe and filter style when reuse is desired and performance is not a top priority”.

Attribute-based architectural styles (ABASs) as defined by SEI-CMU and applied in the Architecture Trade-Off Analysis Method (ATAM), which build on these former architectural styles aim to provide a more precise and explicit reasoning on architecture design by integrating architectural styles with so-called reasoning frameworks. The reasoning framework is based on quality attributes, which exist in the various quality attribute communities such as the performance, reuse and reliability communities. The explicit reasoning framework approach has the benefit of improving and guiding design decisions around quality concerns.

Architectural Views

There is now a broad consensus that software architecture design should include multiple and various types of concerns. These concerns are usually called views or viewpoints. A widely recognized model in this context is the 4+1 model, which distinguishes between five concurrent views of software architecture design each with a different notation and addressing a specific set of concerns. Hereby, the logical view and the development view primarily aims to support the functional requirements by describing the object model and the static organization in the development environment., respectively. The process view and the physical view take into account the non-functional requirements and address concerns such as concurrency, distribution and fault tolerance. Finally, the use case view includes the scenarios and use cases for illustrating and validating the architecture design. Although, non-functional concerns are taken into account in basically the process and physical view, this model is restricted in providing an explicit and integral solution to cope with crosscutting quality concerns. This is because the set of concerns that are taken into account are only restricted to specific concerns such as concurrency, fault-tolerance and synchronization. Moreover, the non-functional concerns that are addressed are not explicitly addressed but remain implicit in the design decisions.  

Model-Driven Architecture

Model-Driven Architecture (MDA) as proposed by OMG is a relatively new approach for implementing systems that need to be mapped and/or integrated to different platforms.  MDA applies the basic principle of separation of concerns by separating the specification of the system functionality from its implementation on a specific platform. The former is defined as a Platform Independent Architecture (PIM), the latter as Platform Specific Architecture (PSA). The mapping from PIM to PSM is performed using transformation rules.

For more information we refer to MDA Guide Version 1.0.1