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 Must understand potential interactions For correctness For reuse in building blocks For evolution and maintenance As an aspect-oriented view of system architecture

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

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

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

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

Preview: Record Aspect

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

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

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

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

Instantiation for UML Describe an aspect as a stereotype of a package where any element can be denoted required or 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

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

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)

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

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

Concern Diagram

Record Aspect

State machines and sequence diagrams in aspects

GUI Aspect

Recording slice (combined aspect, with no requires part)

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