27. Aspect-Oriented Design (Aspektorientierte...

Prof. Aßmann - Softwaretechnik II

Fakultät Informatik - Institut Software- und Multimediatechnik - Softwaretechnologie

27. Aspect-Oriented Design(Aspektorientierte Decomposition)

Prof. Dr. Uwe Aßmann

Technische Universität Dresden

Institut für Software- undMultimediatechnik

http://st.inf.tu-dresden.de/teaching/swt2

Version 16-0.3, 14.01.17

1) Aspect-orienteddecomposition

2) The Modularity Law of AspectSeparation

3) Essential Decomposition

4) Aspect-oriented extension

http://st.inf.tu-dresden.de/

© P

rof.

U. A

ßm

ann

2 Softwaretechnik II (ST2)

Obligatory Literature

► View models (Wikipedia)

– http://en.wikipedia.org/wiki/View_model

– In this chapter, we call a view model a perspective model. Here, view models arespecifc perspective models

► [Kruchten] Kruchten, P., Vancouver, B., C.: The 4+1 View Model of Architecture; IEEESoftware, 12 (6), Nov. 1995, IEEE, S. 42-50

– http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=469759

http://en.wikipedia.org/wiki/View_model

© P

rof.

U. A

ßm

ann


Other Literature

► De Marco, T.: Structured Analysis and System Specifcation; Yourdon Inc. 1978/1979.Siehe auch Kapitel “Action-Oriented Design”

► McMenamin, S., Palmer, J.: Strukturierte Systemanalyse; Hanser Verlag 1988

► [Raasch] Raasch, J.: Systementwicklung mit Strukturierten Methoden; Hanser Verlag(2.Auf.) München 1992)

► Steve Vinoski. An Overview of Middleware. In: A. Llamos ı́ and A. Strohmeier (Eds.):Ada-Europe 2004, LNCS 3063, pp. 35–51, 2004. Springer-Verlag Berlin Heidelberg2004

© P

rof.

U. A

ßm

ann


Goal

► Learn about a completely different strategy for decomposition (crosscutting, aspect-oriented)

► Understand the modularity law of aspect separation



27.1 Aspect-Oriented Decomposition

© P

rof.

U. A

ßm

ann


Development with Different Decomposition Strategies

► So far, we had modular decomposition strategies, who decompose with regard to onedecomposition criterion for stepwise refnement (divide&conquer-baseddecomposition, refnement):

– Function--oriented Decomposition

– Action-oriented Decomposition

– ECA-based Decomposition

– Data-oriented Decomposition

– Object-oriented Decomposition

– Component-oriented Decomposition

– Transformative Decomposition

Concern-oriented (Aspect-oriented) Development decomposes into several perspectives simultaneously

Design Question:What are the concerns and how are they related to the components?

Design Question:What are the concerns and how are they related to the components?

© P

rof.

U. A

ßm

ann


Perspective Models, Viewpoints and Views

► A component space (system-, artefact- or solution space, Lösungsraum)consists of a set of model and program components

– With one or several software systems

► A concern (Belang) forms a simple viewpoint on this component space■ Imagine a concern as a color for coloring code and model fragments

► A concern space (aspect space, Belangraum, Aspektraum) consists of a set ofconcerns and an algebraic structure

■ Imagine a concern space as a color system

► A separation-of-concerns space (SoC-Space, Sichtenbildungsraum) consistsof a coupled concern and component space. It serves for the construction ofsimpler views on the component space. The concern space is used as an index.

► A perspective (viewpoint) consists of a set of concerns relevant to an actor (the set ofrelevant colors)

► A perspective model (viewpoint model, view model) defnes a SoC space anfforms the backbone for systematic aspect-oriented development

Examples: 4+1 views of Kruchten, RM-ODP, Zachmann framework, MDA

© P

rof.

U. A

ßm

ann


Actors, Concerns, and Perspectives

► A perspective groups concerns on behalf of the eyes of an actor.

Concern Space

Concern 1

Concern 2

Concern 3

Actor

Actor

Perspective P

Perspective Q

© P

rof.

U. A

ßm

ann


Concern Space(Aspektraum)

Concerns and Blood Groups for Software and Documents

► Concerns are colors or bloodgroups of components. Concerns group a software system(s) into a SoC space(Sichtenbildungsraum) with

– Concern space (Belangraum) with concerns (Aspekt, Belang, Farbe, Bloodgroup), grouped into Perspectives(viewpoints)

– Component space (Solution space) with the components of the software system(s)

– Concern mapping defning views (Sichten, slices, Scheiben, Schicht) in the component space, correlated to aconcern or a perspective

Concern 1

Concern 2

Aspekt 3

Component Space(Solution Space)

Concern mapping(Sichtenabbildung)

Perspective P

Perspective Q

© P

rof.

U. A

ßm

ann


Concern Space(Aspektraum)

Concerns and Blood Groups for Software and Documents

► Concerns and views together are called the aspects of the software or the document■ Example: layout aspect, structural aspect, behavioral aspect

Concern 1

Concern 2

Aspekt 3

Component Space(Solution Space)

Concern mapping(Sichtenabbildung)

Perspective P

Perspective Q

© P

rof.

U. A

ßm

ann


Well-known Examples for Aspect Separation

Several technologies owe their success to aspect-oriented decomposition strategies:

► 1) Document Decomposition into Aspects Structure, Layout, Behavior Structure: described in html or XML Layout: specifed in CSS or FO Behavior: event-condition-action-based reaction: e.g. in javascript or PHP

Concern space

html

css

html

javascript

Concern 1Structure

Concern 2Layout

Concern 3Reaction

Component space

css

Concern mapping

Perspective P(static aspects)

Perspective Q(entire web site)

© P

rof.

U. A

ßm

ann


Other AO-Decomposition Strategies are Aspect-Oriented

2) Architectural Decomposition decomposes a system into the aspects Architecture andApplication (see ST-1 and CBSE)

3) Bloodgroup Decomposition (A-T-0, Siedersleben) Application (A), Technique (T), Algorithmic (0)

Concern space

workflow specJava

C

Concern 1Architecture

Concern 2Application

Concern 3Technology

Component space

Java

workflow spec

JavaConcern 4Algorithms

Concern mapping

Perspective 1(architecture)

Perspective 2(blood groups)

© P

rof.

U. A

ßm

ann


Other AO-Decomposition Strategies are Aspect-Oriented

4) Essential Decomposition (EAI-Decomposition) (from Structured Analysis)distinguishes the following aspects (viewpoints):

– E: Essential activities, data structures and their stores

– A: Administrative activities (for the check of data consistency and contractchecking)

– I: Infrastructure activities (for communication and adaptation to plattform)

5) Platform-oriented Decomposition decomposes into the aspects (see chapter“MDA”):

Essential activities Adaptation to Platform 1 .... Platform n

© P

rof.

U. A

ßm

ann


Perspectives (Viewpoints)

► A perspective (viewpoint) consists of a set of concerns (aspects)

► A simple Perspective consists of one concern

► A view of a perspective consists of all views related to the concerns of theperspective

Concern 1

Concern 2

Concern 3

Perspective 1

Perspective 2

ViewsConcerns

© P

rof.

U. A

ßm

ann


Perspective Models (Viewpoint Models)

► A perspective model defnes a standard set of perspectives (viewpoints) with theirconcerns and views on the system(s).

► Thus, it defnes the aspect separation of a system by sets of concerns► Example: RM-ODP defnes 5 viewpoints on a IT infrastructure

http://en.wikipedia.org/wiki/File:RM-ODP_viewpoints.jpg

http://en.wikipedia.org/wiki/View_model

© P

rof.

U. A

ßm

ann


Architectural Aspects of KruchtenThe Perspective model of [Kruchten] „4+1 View Model of Architecture”

LogicView

Process-View

PhysicalView

DevelopmentView

Szenarios

Shows an archtiectural view on the functions and components

Shows the development structure of the f iles, models, and code

Implementationview

View of distribution andruntime coordination

Use cases show howviews work together

► The 4+1 Perspective Model defnes 2 perspectives for all components of asystem(s), for design, program and runtime

– Perspective 1: 4 aspects: Concerns and views– Perspective 2: 1 aspect: Szenarios

© P

rof.

U. A

ßm

ann


Perspective Model „Zachmann Framework“

► Zachmann proposed a matrix aspect space out of 5 concerns and 6 questions to groupall activities of the software life cycle into views

http://en.wikipedia.org/wiki/Zachman_Framework



27.2. The Modularity Law of Aspect Separation

► Concerns can be used for better extension, exchange, and variation

© P

rof.

U. A

ßm

ann


Component Space

Corollary: Concern can be used on any Level of Abstraction

► The question is „what is a component“?

► Concerns (aspects) can be used for modules or source code components

– For models and code

– For elements and fragments of models and components

– For all model elements in a model: relate aspect

Concern 1

Concern 2

Concern 3

© P

rof.

U. A

ßm

ann


Component Space

Concern Separation and Concern-Separated ComponentSpaces

► Concern separation (aspect separation, Aspekttrennung) is an important task indesign: Transform the components of a solution space such that every component isrelated to only one concern (has one color)

– If not aspect-separated, split components

► In a concern-separated component space every component carries one color

Concern 1

Concern 2

Concern 3

© P

rof.

U. A

ßm

ann


Component Space

Example: Concern Separation with Architecture

► Software architecture separates the concerns of architecture, and application. ► Software architecture insists on a concern-separated component space, because then

■ Application components can be exchanged independently of the architecture■ The architecture can be reused for several applications■ The application components can be integrated into different architectures

Architecture

Application

© P

rof.

U. A

ßm

ann


Component Space

Example: Concern Separation with Architecture and Testing

► In a software architecture, often more concerns are separated:■ Contracts ensure the correct usage of components■ Code instrumentation for testing and inspection

. Debugging outputs prints information about the program state

. Logging dumps information

Architecture

Application

Contracts

Logging

Debugging

Perspective „Software“

Perspective „Testing“

© P

rof.

U. A

ßm

ann


Component Space

Concern-Separated Component Spaces are Modular

► In a Concern-Separated Component Space all components of one specifc color form aSlice (Scheibe, view), a kind of cross-cutting (querschneidendes) module

Concern 1

Concern 2

Concern 3

© P

rof.

U. A

ßm

ann


Modularity Law of Concern-Separated Systems

If a system is concern-separated, the components beloning to onecolor can be exchanged easily by changing the concern

If a system is concern-separated, the components beloning to onecolor can be exchanged easily by changing the concern

► Exchange of implementation modules, code compoennts

► Exchange of fragments and model elements

If a system is NOT concern-separated, some components beloning to several concerns and cannot be exchanged

by changing the concern → split them

If a system is NOT concern-separated, some components beloning to several concerns and cannot be exchanged

by changing the concern → split them

© P

rof.

U. A

ßm

ann


Component Space

Example: Concern Separation with Quasar Blood Groups

► Quasar Blood Groups defne a structured concern space of■ Representation Change (R); Application (A); Algorithmic (0); Technical (T)■ AT-Software mixes A and T. Therefore, it is hard to reuse■ AT-components are not concern-separated and hard to reuse, because they are

related to two concerns A and T

0-Software

T-Software

AT-Software

A-Software

R-Software

<<A>>

<<T>>

<<0>>

<<AT>> <<R>>

© P

rof.

U. A

ßm

ann


Quasars a view model highlighting the advantages of aspect separation.

Avoid AT components, i.e., the mix of aspects on one component.

Quasars a view model highlighting the advantages of aspect separation.

Avoid AT components, i.e., the mix of aspects on one component.



27.3 Essential Decomposition in the Structured Analysis

Perspective model with 3 Aspects Essence, Administration, Infrastructure (EAI)

EAI supports aspect separation, because all activities should related only to one concern,E xor A xor I.

“The general role of middleware is to abstract away the details of underlying facilitiesand platforms, thereby isolating applications from them.” [Vinoski]

© P

rof.

U. A

ßm

ann


The Perspective Model of Essential Decomposition

Essence

Administration

Infrastructure / Middleware

Spontaneous Event-Hull

Real functional core ofapplication

Events out of the system

Quality assurance,Consistency checking,Contract checking,Error compensation

Platform- andImplementation-dependentI/O, communication

Physical Ring

► Essential Decomposition forms a SoC space with 3 aspects:

– (functional) Essence are those functions independent of the underlyingtechnology. Essence assumes perfect technology, e.g., processes without time,infnite memory, infnite bandwidth

– Administration ensures the quality of the system (contract checking, dataconsistency checking).

– Infrastructure captures the platform-dependent details

► EAI was invented in SA, but can be used for all development methods

[Raasch, McMenamen/Palmer]

© P

rof.

U. A

ßm

ann


Ex. EAI-Decomposition of a Process of a Tool “ApplicationManagement Sytem”

Essence

Administration Customer

Administration

Infrastucture<completed>permission

<signed>permission

<written> Form

<approved> ApplicationProposal<checked>

application

<unchecked> Application

<raw>Desire

► The EAI-Decomposition of a business process (in DFD) can be indicated by different colorsfor Essence, Administration, Infrastructure

accept_Desire

sendpermission

signpermission

check_application

approve

investigate

update

write_Form

[Raasch]

© P

rof.

U. A

ßm

ann


Example: EAI-Decomposition of the Business Process“Application Management”

► The EAI-SoC-Space with SA-DFD

Essence

Infrastructure

Administration

accept_Desire

check_application investigate

approve

write_Form

signpermission

sendpermission

Administration Patient

update

Concern Space Component Space

© P

rof.

U. A

ßm

ann


Development Method„Essential Structured Analysis (ESA)“

► The books of [Raasch, McMenamen/Palmer] show ESA as a complete developmentmethod for applications

► With DFD, the decomposition by the aspects (Essence, Administration, Infrastructure)is very simple: The aspects decompose the DFD into slices of a specifc color (graphslicing).

– Stream-based DFD can be sliced easily

– Petri-nets, workfow nets, activity diagrams are similar

► Essential Structured Analysis is a development process combining ECA with aspectdecomposition

► [Raasch] ESA combines ZOPP, ECA, EAI

[Raasch, McMenamen/Palmer][Raasch, McMenamen/Palmer][Raasch, McMenamen/Palmer]

© P

rof.

U. A

ßm

ann


ReducibleDFD

ECA-Based Development Method„Essential Structured Analysis (ESA)“

1) Project-Goals(from ZOPP)

Event-Analysis

Event identif icationReaction identif ication

ECA-Rules

Event Trigger Reaction

Essential DFD

Essential View

Activities - data

Administrative View

Activities - data

Administrative DFD

Infrastructure-View

Activities - data

Infrastructure/Middleware DFD

ReducibleDFD

ReducibleDFD

DataDictionary

3) Activity Development

2) ECA-Analysis

► Three steps: goal analysis, ECA analysis, activity development in EAI

[Raasch, McMenamen/Palmer]

© P

rof.

U. A

ßm

ann


Development Process of Essential Structured Analysis (ESA)

1) Elaboration: Goal identifcation (e.g., with ZOPP)

2) Elaboration: Essental Activities identifcation (with EAI)

1) Elaboration: Identify external events and triggers

2) Elaboration: Identify reactions and ECA rules

3) Elaboration: Specify the essential context diagram

4) Analysis: identify the Essential Datastores by considering the data fow

5) Refnement: refne context diagram

3) Analysis: identify Administration activities for contract checking anddata consistency checking

4) Analysis: identify Infrastructure activities (Communication, Dataexchange and transformation)

5) Consolidate: split an activity, if it relates to several concerns: separateconcerns into E, A and I

6) Elaboration: integrate the integrated DFD model from all views

7) Repeat and refne

© P

rof.

U. A

ßm

ann


Erweiterung von ESA auf das Reengineering von Altsystemen

ZieleAnwendergesprächeKontextabgrenzung

neue Essence konzipierenneue Inkarnation konstruieren

Modellqualität optimiereness. Aktivitätenmodelle integrieren (5)

Ist-Zustand erhebenexpandierenreduzierenessentielle Fragmente klassif izierenessent. Aktivitäten ableiten (2)

EreignistabelleEssence, Kontext (2)Datenkatalog 3...6MSpecs (Für Elementar_ Aktivit.)

Ohne Analyse des Altsystems Mit Analyse des Altsystems

ESA Erw. ESA



27.4. Extension by Aspect-Orientation

Extensibility Question:What are further concerns and how are they related to further

components?

Extensibility Question:What are further concerns and how are they related to further

components?

© P

rof.

U. A

ßm

ann


Aspect-Oriented Crosscutting Extensions

► With Aspect-Orientation and an appropriate extension mechanism, software can beextended also in unforeseen ways

► Extension works by adding a new aspect with a new crosscutting slice to the system,possibly crosscutting other component nets and slices

Concern 1

Concern 2

Concern 3

Perspective 1

ExtendingPerspective

© P

rof.

U. A

ßm

ann


The End – What did we learn?

► Why is aspect-oriented decomposition different from modular decomposition?

► How do you use aspect-oriented decomposition to structure software into severalviews?

– Explain the concept of a “Concern space” (Belang-Raum)

– Explain the concept of a „SoC-space“

► Which ingredients does a perspective model have?

► Explain the modularity law of aspect orientation

► Explain why the following perspective models support aspect decomposition

– EAI-Decomposition

– RM-ODP, Zachmann, Kruchten 4+1

– Software Bloodgroups of Siedersleben (siehe ST-1)

► Explain ESA and why the aspectual decomposition simplifes the development of asystem

► How can aspects be used to extend a workfow system in unforeseen ways? What doesthis mean for software architecture?



27.A.1 Aspect-Oriented Extensibility of Workfow Nets

© P

rof.

U. A

ßm

ann


Open Copy-Split and Join Operators in WorkflowNets

OR

XORCP-

AND

CP-OR

► Remember, open operators in workfow nets, which can be extended by incoming resp.outgoing edges without violating the contract of the operator

© P

rof.

U. A

ßm

ann


Aspect-Oriented Workfows with Harmless Extensions

► If edges are added to an open operator, they enrich the semantics of the net, but do notdestroy or change it (monotonic extension)

► Therefore, adding an edge retains the contracts, i.e., basic assumptions, of a workfownet.

Extending the open operators of a core workflow does not change its contracts. Extending the open operators of a core workflow does not change its contracts.

Adding an aspectual slice to the open operators of a workflow net of anapplication is a harmless extension.

Adding an aspectual slice to the open operators of a workflow net of anapplication is a harmless extension.

27. Aspect-Oriented Design (Aspektorientierte...

Documents

Transcript of 27. Aspect-Oriented Design (Aspektorientierte...