27. Aspect-Oriented Design (Aspektorientierte...
Transcript of 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
© 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
© P
rof.
U. A
ßm
ann
3 Softwaretechnik II (ST2)
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
4 Softwaretechnik II (ST2)
Goal
► Learn about a completely different strategy for decomposition (crosscutting, aspect-oriented)
► Understand the modularity law of aspect separation
Prof. Aßmann - Softwaretechnik II
Fakultät Informatik - Institut Software- und Multimediatechnik - Softwaretechnologie
27.1 Aspect-Oriented Decomposition
© P
rof.
U. A
ßm
ann
6 Softwaretechnik II (ST2)
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
7 Softwaretechnik II (ST2)
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
8 Softwaretechnik II (ST2)
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
9 Softwaretechnik II (ST2)
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
10 Softwaretechnik II (ST2)
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
11 Softwaretechnik II (ST2)
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
12 Softwaretechnik II (ST2)
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
13 Softwaretechnik II (ST2)
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
14 Softwaretechnik II (ST2)
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
15 Softwaretechnik II (ST2)
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
16 Softwaretechnik II (ST2)
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
17 Softwaretechnik II (ST2)
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
Prof. Aßmann - Softwaretechnik II
Fakultät Informatik - Institut Software- und Multimediatechnik - Softwaretechnologie
27.2. The Modularity Law of Aspect Separation
► Concerns can be used for better extension, exchange, and variation
© P
rof.
U. A
ßm
ann
19 Softwaretechnik II (ST2)
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
20 Softwaretechnik II (ST2)
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
21 Softwaretechnik II (ST2)
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
22 Softwaretechnik II (ST2)
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
23 Softwaretechnik II (ST2)
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
24 Softwaretechnik II (ST2)
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
25 Softwaretechnik II (ST2)
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
26 Softwaretechnik II (ST2)
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.
Prof. Aßmann - Softwaretechnik II
Fakultät Informatik - Institut Software- und Multimediatechnik - Softwaretechnologie
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
28 Softwaretechnik II (ST2)
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
29 Softwaretechnik II (ST2)
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
30 Softwaretechnik II (ST2)
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
31 Softwaretechnik II (ST2)
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
32 Softwaretechnik II (ST2)
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
33 Softwaretechnik II (ST2)
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
34 Softwaretechnik II (ST2)
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
Prof. Aßmann - Softwaretechnik II
Fakultät Informatik - Institut Software- und Multimediatechnik - Softwaretechnologie
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
36 Softwaretechnik II (ST2)
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
37 Softwaretechnik II (ST2)
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?
Prof. Aßmann - Softwaretechnik II
Fakultät Informatik - Institut Software- und Multimediatechnik - Softwaretechnologie
27.A.1 Aspect-Oriented Extensibility of Workfow Nets
© P
rof.
U. A
ßm
ann
39 Softwaretechnik II (ST2)
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
40 Softwaretechnik II (ST2)
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.