180 likes | 272 Vues
Supporting Architectural Design by Early Aspects Identification. Thorsten Keuler. Outline. Motivation Problems Approach UC Indicators SD Indicators Architecture issues Example Evaluation Discussion points. 1/17. Definition. Software Architecture …
E N D
Supporting Architectural Design by Early Aspects Identification Thorsten Keuler
Outline • Motivation • Problems • Approach • UC Indicators • SD Indicators • Architecture issues • Example Evaluation • Discussion points 1/17
Definition Software Architecture … … describes the fundamental organization of a system embodied in its components, their relationships to each other and to the environment and the principles guiding its design and evolution … provides critical abstractions by which it is possible to reason about and describe the structure and behavior of a system 2/17
Motivation … • Changing the architecture potentially leads to high effort (deep impact changes) • Crosscutting concerns affect lots of components … Idea: Early identification of CCC enables special treatment of CCC 3/17
Problems • What is CCC on the architectural level? • Hard to identify due to implicit nature • How to deal with identified CCCs? • Is my architecture a good one? 4/17
Approach Requirements Requirements Analysis UC/SD CCC candidates CCC Analysis Architecture Construction (initial) Architecture : Artifact Recommendations Architecture Evaluation : Process 5/17
Example System 6/17
UC Indicators • A high number of outgoing “extends”-relations of a use case increases the likelihood that it represents a crosscutting concern. (#<<extends>>.out > 1) • A low number of external triggers of a use case increase the likelihood that it represents a crosscutting concern. (#(external triggers) == 0). 7/17
Example 1 8/17
Example 2 9/17
SD Indicators • If a component is always embedded in a similar control flow context in different scenarios the likelihood that it represents a crosscutting concern is increased. • If a component is called by a larger number of components than the average, the likelihood that it represents a crosscutting concern is increased. 10/17
Tangle & Scatter Definition: 12/17
Architectural Heuristics Minimization of tangle The minimization of tangle implies that responsibilities of a component are decreased. This decrease can be realized by the following tactics. Tactics: - Introduction of new components - Rearrangement of responsibilities among components Rationale: Improvement of traceability of that component to its requirements. Reason: pure reduction of responsibility relations simplifies the understandability of the remaining relations. 13/17
Architectural Heuristics Minimization of scatter The minimization of scatter implies that a set of components loses responsibility with respect to one or more requirements. Tactics: - Pattern/Aspect extraction Rationale: - Reduction of implementation complexity - Improvement of maintainability and understandability Is that enough? 14/17
Example Evaluation =(0.33+0+0.66+0.66+0.66) / 5 = 0.47 15/17
Example Evaluation Result: tangle & scatter decreased better architecture !? =(0.33+0+0.66+0+0) / 5 = 0.2 16/17
Discussion points • What is the impact of high-level concerns? • What are the benefits/risks if those are (not) identified? • Is tangle and/or scatter a good measure for architecture evaluations? • How to model concerns at an abstract level? 17/17