Concern architectures an aspect oriented software architecture viewtype mika katara shmuel katz
1 / 56

Presented by: Gil Krumgant - PowerPoint PPT Presentation

  • Uploaded on

Concern Architectures: An Aspect-Oriented Software Architecture Viewtype Mika Katara . Shmuel Katz. Presented by: Gil Krumgant. Introduction. In recent years the importance of multiple, concurrent “views” of software architecture has been recognized.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Presented by: Gil Krumgant' - mira

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Concern architectures an aspect oriented software architecture viewtype mika katara shmuel katz

Concern Architectures:An Aspect-Oriented SoftwareArchitecture ViewtypeMika Katara.Shmuel Katz

Presented by: Gil Krumgant


  • In recent years the importance of multiple, concurrent “views” of software architecture has been recognized.

  • The use of aspect-oriented programming to modularizeconcerns of systems thatotherwisewould cut across usual class or process hierarchies is becoming popular.

  • Nevertheless, supportfor the independent description of aspect designs and for the incremental design of aspecs themselves has been neglected.


  • A conceptual model is presented called

    the concern architecture .

  • The term concernisused to mean any “conceptual matter of interest”.

  • We use the term aspectfor amodule that is potentially able to encapsulate software or design artifacts treating an otherwisecross-cutting concern.


  • Concerns can be treated by one or more aspects.

  • Anaspect provides augmentationsto existing designs by mapping an existing design artifact into anew one with more details or modifications.

Presented by gil krumgant


  • The relationships among aspects ofthe system need to be made explicit.

  • However, aspects themselves can be complex, and must be adapted over time to changing requirements, and thus need to be designed incrementally.

  • Cannot be assumed that aspects are always orthogonal.


  • In a concern architecture the aspects serve as building blocks.

  • In the case of more than one aspect corresponding to a concern, we call them sub-aspects.

  • Sub-aspects are usually shared by more than one concern but can be composed when needed to form a composite aspect matching a single concern.


  • Aspects can be seen as LEGO bricks that can be assembled incrementally to form more complex aspects from simpler sub-aspects.

  • Each concern is addressed in a modular way by a collection of aspects, which can be composedwhen needed.

  • The overlapping parts of the different concerns are given explicitly by the aspectscommon to them.


  • Ideally, each aspect describes only a small increment. This allows on-demand creation or remodularizationof aspects by composing different collections of aspects to match whatever concernis needed.

  • To deal with a concern, the aspects within it can either be applied to a given underlying systemone after the other in any order that satisfies the dependencies, or the aspects can be combined first among themselves into a complex aspect, that in turn is applied to an underlying system.


  • Overlap between different aspects.

  • Identification of join points in UML.


Two concerns:

1.providing security of key variables

2.preventing overflow of variables

Introduction example

  • An aspect for treating overflow of data values and anotherfor encoding values to increase security can both involve the same methods or fields of an underlyingobject-oriented design, and may even overlap in the modifications applied.

Modeling aspects required provided and hidden parts
Modeling AspectsRequired, Provided, and Hidden Parts

To support reuse, Aspect model splited into two disjoint parts.


required part

provided part

(The “join points”)

(The augmentations)

Modeling aspects required provided and hidden parts1
Modeling AspectsRequired, Provided, and Hidden Parts


  • A software artifact, consisting of classes C and D.

  • Asimple aspect A which adds classes E and F, subclasses of C, and introduces a method m to D,maps the artifact to an augmented one consisting of D including the method m, and C togetherwith its subclasses E and F.

  • The requiredpart couldconsist of classes C and D, and the providedpart of subclasses E and F, and method m.

Required provided and hidden parts
Required, Provided, and Hidden Parts

  • The requiredpart describes the “join points”, to which the aspect is to be applied as well astheir wider context and can be seen as parametric elements.

  • The providedpart introduces the augmentations.

  • Some elements provided by an aspect can be labeled as hiddenfrom other aspects. This means that other aspects cannot bind elements to the hidden ones.

  • Providedelements not hidden from other aspects define an interfaceof the aspect.

Presented by gil krumgant

Composition of Aspects

  • Composition of aspects is based on superimposition.

  • Superimposition is an asymmetric operation in which one aspect augments another one.

  • A superimposition where aspect B augments A is denoted by B/A.

  • By treating the overlapping parts of the different concerns explicitly in the aspects common to them, it becomes easier to reason about the effects on one aspect caused by the changes in some other aspect of the same system.

Composition of aspects example
Composition of AspectsExample

If an aspect for monitoring a system defines new counter variables to record how often a variable is referenced, and an aspect treating overflow needs to consider all numerical variables, clearly the overflow aspect augments the one for monitoring, even though this means that any additions in the aspect for treating overflow will not be monitored.

Composition of aspects
Composition of Aspects

  • Regular composition binding

  • Replacement composition binding

  • Unification composition binding

Regular binding
Regular Binding

  • Generally, when B augments A, the elements in the requiredpart of B can be bound to theelements in the required and providedparts of A.

  • Therequired part of the composite aspect consists of the requiredpart of A and unbound elements ofthe requiredpart of B.

Replacement binding
Replacement Binding

  • An element aprovided by A can be replaced by elements b1, .., bnprovided by B,if it is shown that the properties of A (presumably from its specification) that need to be preservedare indeed preserved.

  • This can also include replacing a single relation (e.g., an arrowrepresenting a transition) by a substructure.

Unification binding
Unification Binding

  • When an element name appears both in A and in B, or renaming is used to make previouslydistinct names identical, this means that they are unifiedby the replacement binding.

Instantiation composition.

  • Definition 1 (Well-formedness of an aspect) An aspect is well formed if and only if the corresponding artifact in language L obtained by ignoring the required/provided/hidden tags is well formed.

  • Definition 2 (Composability) A well-formed aspect B can augment another well-formed aspect A with given bindings if and only if the resulting composite aspect B/A is well formed.

Instantiation for uml
Instantiation for UML composition.

Views Consisting of Aspects and Concerns

  • Aspect as package

  • Concerns as irregularly shaped encircling lines surrounding the corresponding collections of aspects.

  • Elements requiredby an aspect are distinguished from provided ones by a tag “{required}”.

  • All elements not tagged as “{required}”, are assumed to be provided.

  • Additionally, a tag “{hidden}” is used for those provided elements that should not be included in the aspect’s interface.

Example composition.

Basic Features

Example basic features
Example composition.Basic Features

  • Simplified design of a digital sound recorder with a digital memory capable of recording, playing, and deleting messages. Thedevice can also be used as an alarm clock.

Example basic features1
Example composition.Basic Features

  • The hardware, described and encapsulated using wrapperclasses, consists of six standard components: microphone, speaker, display, simple keyboard, timerand battery.

  • Some fundamental classes can be identified describing thelow-level software, e.g., UserInterface and AudioController.

  • Each of these singleton classes is denotedas required and could be introduced in a separate aspect.

Example basic features2
Example composition.Basic Features

  • Turning to a top-down analysis, the concerns of the system can be divided into Recording,Playing, and Alarmclock functionality.

Gui aspect
GUI aspect composition.

  • The concerns are all overlapping becausethey all include the GUI aspect.

  • GUI defines the main functionality of the graphicaluser interface for three concerns.

Memory aspect
Memory aspect composition.

  • The Memory aspect requiresthe AudioController class, and introduces three classes and four relations.

Record aspect
Record aspect composition.

  • The Record aspectprovides the AudioInput class and adds new operations to theAudioController, Message, and AudioBlock classes which are needed to implement the recordingfeature.

  • The required association between the AudioController and Message classes serves as anabstraction of a more complex relationship provided in the Memory aspect.

Output aspect
Output aspect composition.

  • The Output aspect captures the common parts of playing and alarm clock features related to outputting sound. The aspect introduces the AudioOutput and Synthesizer classes.

Play aspect
Play aspect composition.

  • The Play aspect adds new operations to the AudioController, Message, and AudioBlockclasses which are needed to implement the feature.

  • It also provides a new state Play-onin the statechart of the AudioController class.

  • The aspect introduces a new sub-class PlayingUserMode for the class UserMode provided by the GUI aspect.

  • The sequencediagram illustrates playing a message.

Clock and alarm aspects
Clock and Alarm aspects composition.

  • The Clock aspect describes the clock using the hardware timer. It provides Time and Date classes to encapsulate therepresentation of time.

  • The Alarm aspect requires the Time and Date classes introduced in the Clockaspect. Among other things, it provides the AlarmClock class with operations to set the alarm andto query the time, date, and state of the alarm.

Feature interactions
Feature Interactions composition.

  • Concerns and aspects defining the interactions of the concerns.

  • Aspect in addition to the interacting concerns.

Play alarm aspect
Play&Alarm aspect composition.

  • In the case of playing and sounding the alarm, the alarm is given priority. This is indicated in thestatechart of the AudioController class by adding a transition from state Play-on to state Alarm-on,triggered by a playAlarm event.

Record alarm aspect
Record&Alarm aspect composition.

  • It might be feasible to just let the alarm soundwhilerecording. However, toensure that a recording is not ruined because of the alarm, decided only to display thealarm indicator on the display and not to output sound.

  • When the user stops recording, theAudioControllergoes to state Alarm-on and starts to play the alarm sound.

Composed audiocontroller statechart
Composed AudioController statechart composition.

It contains all the states,transitions, triggering events, and guard conditions added in various aspects. If some element hasbeen provided by more than one aspect, unification binding is used in their composition. This applies,for instance, to the stop operation, corresponding to the stop event, in class AudioController.

Related work
Related Work composition.

In the Hyperspace conceptual model (where aspects correspond to hyperslices), slicescan be composed (recursively) to hypermodules which contain composition rules for the componentslices. Hyper/J is an instantiation of the approach in the Java language. However, that work does not define an architecture diagram that clarifies relationshipsamong hyperslices in terms of the concerns treated, and does not clearly separate assumptionsfrom provided elements.

Conclusions composition.

  • Using the concern architecture views it is easy to trace requirements in the design, because the collection of aspects addressing each concern can be made visible, as was shown in the example. Moreover, to support reusability, the required part can express the context in which the aspect is applicable.

  • Overlapping parts of the different cross-cutting concerns

    are stated explicitly. Thus, if a cross-cutting concern needs to be changed, disjoint concerns shouldbe unaffected.

  • “Mix-and-match” of features to suit different members of a software family is achieved by composingdifferent collections of the aspects constituting the family.

  • A concern architecture viewtype enhances parallel development.

  • In summary, aspect-oriented design provides new possibilities for composing and decomposingsoftware artifacts.

View to the future
View to the future composition.

  • Future work includes investigation of different architectural styles that conform to the concernarchitecture viewtype.