1 / 22

Concern Architecture View and Aspect-Oriented Design

Concern Architecture View and Aspect-Oriented Design. Mika Katara and Shmuel Katz Tampere U. T. Technion, Haifa. Designing Aspects and Describing Connections among Aspects. Not supported on architecture/design level Need incremental design of aspects

willasmith
Download Presentation

Concern Architecture View and Aspect-Oriented Design

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. Concern Architecture View and Aspect-Oriented Design Mika Katara and Shmuel Katz Tampere U. T. Technion, Haifa

  2. Designing Aspects and Describing Connections among Aspects • Not supported on architecture/design level • Need incremental design of aspects • Must understand potential interactions • For correctness • For reuse in building blocks • For evolution and maintenance • As an aspect-oriented view of system architecture

  3. One Context: Viewtypes • A perspective on software architecture • Defined using elements and relationships • Can have several styles that define recurring forms • Client-server • Pipeline • Reference: Clements, et.al, Documenting Software Architectures: Views and Beyond

  4. Here: a software architecture viewpoint • The organization of the aspects themselves • Only one way to view

  5. Abstract definitions • Concern: conceptual matter of interest (security, performance monitoring,…) • A name “inherited” from a group of requirements • Aspect: software design treating part of a concern, usually cross-cutting • Combined aspect: Cluster of related aspects that treat a concern • Remodularization/refactoring to isolate common denominators in separate aspects

  6. What is an aspect? • A Mapping: Design  Design • Two parts: • Required: the part of the `source’ design giving join points and needed assumptions used • Provided/Defines: the augmentations that give the result of applying the aspect • Example: Aspect A uses (formal) class C, and defines a subclass D with new method m • Parametric in C; bind C to actual required class

  7. Preview: Record Aspect

  8. Composing aspects • For A and B, if there is no binding among their required parts (directly or indirectly), either order is OK; they are independent • BUT, if the required part of B is bound to part of A, then B is applied later, and B depends on A • Uses Superimposition concepts and mechanisms (see references and explanation in paper) • A collection of aspects and dependencies ordering their composition treat each concern

  9. Two types of dependency • Between aspects that together treat the same concern • Order, compose, and modularize • Between unrelated aspects…identify potential conflicts and “stress points” • Can identify relations among concerns

  10. Example: monitoring execution and preventing overflow • If monitoring adds integer counters, and overflow must treat every integer, monitoring must be done first, even though they treat different concerns. • If different variables are treated, or monitoring doesn’t affect integers, they may be independent. • If monitoring must treat everything else, overflow should be applied first • Can also have mutual application • Policy: identify overlapping subaspects: when (treatment of) one concern is modified, the other may be influenced

  11. Concern Diagram: a new view • Contain aspects, dependencies among them, groupings into concerns • Concerns have overlapping, contain common aspects • Architectural viewpoint that identifies potential conflicts, concentrates effort when changes are made

  12. Instantiation for UML • Describe an aspect as a stereotype of a package where any element can be denoted requiredor provided • Elements includes class, method, state, transition, link, use case, actor, etc. • Add new UML diagram type to treat concern diagram for selected subsets of aspects, concerns, and elements

  13. Symmetric or Asymmetric View? • Could have everything be a concern, each realized by aspects that are then ordered by dependencies and bound • Could have an underlying object system that treats some concerns, others in an aspect layer that uses this notation

  14. Extended example: digital sound recorder • Slices that correspond to • Playing a message, • Recording a new message, • Activating an alarm clock • are complex and hide any overlap • Instead: describe aspects separately, use concern diagram to show overlap • Slices are results of combinations of simpler aspects (themselves aspects or superimpositions)

  15. Basic Classes and Aspects • Classes: hardware wrappers and low level software • Microphone, Speaker, Display, Timer, Battery,.. • UserInterface, AudioController, AudioBlock • Here, these are all required in the descriptions of the aspects • Here, all high-level functionality is in aspects • Other divisions are possible

  16. Sound Recorder (cont.) • Typical aspects • GUI • Memory management • Record (Added parts over GUI and Memory) • Output creation • Typical concerns • Playing, Recording, Activating alarm

  17. Concern Diagram

  18. Record Aspect

  19. State machines and sequence diagrams in aspects

  20. GUI Aspect

  21. Recording slice (combined aspect, with no requires part)

  22. Conclusions • Combinations of collections of aspects are needed to treat concerns • Parametric UML aspects with requires and provides • Concern diagrams identify common denominators and stress points • One (valuable) view in a multiview approach • Still needed: clear development path, correctness criteria, semantics

More Related