An object-oriented bridge among architectural styles, aspects and frameworks

Abstract

It is generally agreed that designing high-quality frameworks results a difficult task, mainly because this process often relies more on the designer's expertise than the technology used to implement such designs [4]. Besides, frameworks should also take into account several quality attributes. Therefore, framework development practices typically involve considerable efforts. This would indicate that some aspects of the domain could not be directly modeled in terms of object-oriented concepts. The problem is how to break the tradeoffs imposed by a pure functional decomposition versus a pure object-oriented decomposition of a system. In this context, a design approach driven primarily by architectural models focuses on the solution of design problems taking as main driver the organization of software components as a function of the quality attributes affecting the system. In this way, developers should be able to construct a given system by assembling and elaborating certain architectural fragments, as independently as possible of particular implementation technologies. Nonetheless, improved software quality cannot be achieved simply by focusing on isolated architectural styles and their associated quality attributes. In fact, as software complexity gets bigger, designers need to deal with a variety of special computing concerns or aspects [6] (e.g., synchronization, error-checking strategies, resource sharing or usage, distribution and performance, among others) in order to fulfill these quality factors. Particular styles may be able to address specific aspects, but the final system architecture needs to be built considering a number of relevant concerns, which usually present uneven organizations. Moreover, the intrinsic nature of concerns makes it difficult to cleanly segregate them [5]. Once the system architecture is given, the underlying organization of its concerns comes attached. The discussion is not just about new mechanisms or artifacts to handle software concerns, rather it involves how technologies can contribute to effectively reason about concerns by promoting good design practices.