Concern Architecture View and Aspect-Oriented Design

Mika Katara and Shmuel KatzTampere 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