Relating architectural views with architectural concerns

Abstract

Architectural views are at the foundation of software architecture and are used to describe the system from different perspectives. However, some architectural concerns crosscut the decomposition of the architecture in views. The drawbacks of crosscutting with respect to architectural views is similar to the drawbacks with respect to code, i.e. hampering reuse, maintenance and evolution. This paper investigates the relations between architectural concerns and views to identify why concerns tend to crosscut. We propose to extend the architectural description with slices and composition mechanisms to prevent this crosscutting and perform an initial exploration of these concepts in an Online Auction system. Within this limited setting the first results look promising to better separate concerns that otherwise would crosscut the views.

Dynamics of task allocation in global software development

“…To determine the exact relationships considered for the task allocation decision, the practitioners were asked to select the architectural relationships they look into before allocating tasks to distributed sites. The architectural relationships presented are categorized into 3 main categories of module view type, component and connector view type, and allocation view type . The pie chart in Figure highlights the importance of architectural views by GSD practitioners for task allocation.…”

“…The architectural relationships presented are categorized into 3 main categories of module view type, component and connector view type, and allocation view type. 58 The pie chart in Figure 3 highlights the importance of architectural views by GSD practitioners for task allocation. The module view type has the greatest percentage, highlighting the significance of static relationships between modules as being important for task allocation.…”

TMiner aspects: Crosscutting concerns in the TMiner component-based data mining framework

“…For instance, Ivar Jacobson believes that use-case driven development and AOP complement each other very well: as early aspects, use cases are key to effectively separate concerns (Jacobson & Ng, 2004 Other researchers advocate for using aspects in the architectural description of software systems (Boucké & Holvoet, 2006;Shomrat & Yehudai, 2002). In fact, architectural viewpoints and perspectives lend themselves to be interpreted as crosscutting concerns, albeit at a higher abstraction level than traditional AOP aspects: ''An architectural perspective is a collection of activities, tactics, and guidelines that are used to ensure that a system exhibits a particular set of related quality properties that require consideration across a number of the systems architectural views" (Rozanski, 2005).…”

Using Aspects in Architectural Description

“…Boucké and Holvoet (B&H) propose extending architectural descriptions with architectural slices: "since the architectural elements in a slice are meant to cover a specific driver, there is a direct traceability between drivers and the views describing them (and thus no tangling)" [27]. However, part of the problem B&H set out to solve is self-inflicted -they do not adopt a rigorous notion of view (cf.…”