1 / 18

Supporting Architectural Design by Early Aspects Identification

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 …

ilana
Download Presentation

Supporting Architectural Design by Early Aspects Identification

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Supporting Architectural Design by Early Aspects Identification Thorsten Keuler

  2. Outline • Motivation • Problems • Approach • UC Indicators • SD Indicators • Architecture issues • Example Evaluation • Discussion points 1/17

  3. 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

  4. 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

  5. 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

  6. Approach Requirements Requirements Analysis UC/SD CCC candidates CCC Analysis Architecture Construction (initial) Architecture : Artifact Recommendations Architecture Evaluation : Process 5/17

  7. Example System 6/17

  8. UC Indicators • A high number of outgoing “extends”-relations of a use case increases the likelihood that it represents a cross­cutting 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

  9. Example 1 8/17

  10. Example 2 9/17

  11. 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

  12. How to use CCC information? 11/17

  13. Tangle & Scatter Definition: 12/17

  14. 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

  15. 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

  16. Example Evaluation =(0.33+0+0.66+0.66+0.66) / 5 = 0.47 15/17

  17. Example Evaluation Result: tangle & scatter decreased better architecture !? =(0.33+0+0.66+0+0) / 5 = 0.2 16/17

  18. 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

More Related