Architectural design of the Health Watch system with an integrated aspect-oriented modeling approach

Abstract

Crosscutting behaviors and features of architectural units have always been a tricky issue in software architecture design. If not well treated, they may lead to a number of architectural breakdowns, such as increased maintenance overhead, reduced reuse capability, and architectural erosion over the lifetime of a system. Unfortunately, traditional software modeling approaches lack abstraction to support the modular representation of crosscutting concerns. This paper employs a special kind of architectural component called Aspectual Component to encapsulate crosscutting behaviors and features to improve modularization, and extends the semantic of conventional connectors to represent the crosscutting effect of aspectual components. Moreover, we present a general-purpose aspect-oriented architecture description language AC-ADL for formal specification of the software architecture of systems. The whole designing process of the approach is illustrated systematically through a case study of Health Watcher system.

Uncovering quality-attribute concerns in use case specifications via early aspect mining

“…Specific to our work, the HWS provides a requirements specification with 9 use cases (around 19 textual pages). Second, other researchers have used HWS as a model problem and analyzed its quality-attribute properties [40,42]. After running SAET [34,35] on the use cases of HWS, we detected the early aspects listed in Table 6.…”

“…To answer this question, we cross-checked the QAMiner outputs against documentation already provided by the case studies. In HWS, the analysis of the ''actual'' quality attributes was based on existing architectural sources [40,42], while in CRS, the actual quality attributes were gleaned from the documented business goals for the system [7]. Since QAMiner performs better when using only early aspects as input, we used the results of that configuration to perform the cross-checking analysis.…”

“…This judgment was performed based on the descriptors (i.e., verb-object pairs) and intent of each early aspect. At last, the rightmost column contains the system quality attributes, that is, the actual quality attributes as interpreted from the case-study documentation [18,24,42]. The lines between identified and actual quality attributes highlight the correspondences between them.…”

“…The question to answer here was whether the candidate quality attributes have correspondences with the quality attributes considered in solutions to the case studies. In practice, several authors have proposed architectures for the HWS problem [24,42], so we directly took the quality attributes stated and addressed by those architectures. For the CRS case-study, unfortunately, there is no published architectures, and we had to infer the relevant quality attributes from the problem context.…”