27. Aspect-Oriented Design (Aspektorientierte Decomposition)

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

Prof. Dr. Uwe Aßmann 1) Aspect-oriented Technische Universität Dresden decomposition Institut für Software- und 2) The Modularity Law of Multimediatechnik Aspect Separation http://st.inf.tu-dresden.de 3) Essential Decomposition /teaching/swt2 4) Aspect-oriented extension Version 15-0.8, 16.01.16

Prof. Aßmann - Model-Driven Software Development (MDSD) © Prof. U. Aßmann 2 Obligatory Literature ► ►

Model-DrivenSoftware inDevelopment Spaces(MOST) Technical Software, 12(6), Nov. 1995, S. IEEE, 42-50 [Kruchten] Kruchten, P., Vancouver, B., C.:View TheModelof 4+1 Architecture; IEEE View models (Wikipedia) – – – http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=469759 In this chapter, call we a view model a http://en.wikipedia.org/wiki/View_model specifc perspective models perspective model. Here, view modelsare © Prof. U. Aßmann 3 ► ► ► ►

OtherLiterature Model-DrivenSoftware inDevelopment Spaces(MOST) Technical 2004 Ada-Europe pp.Springer-Verlag LNCS3063, 35–51, 2004. Heidelberg 2004, Berlin ́ı and Strohmeier A. (Eds.): Steve Vinoski. Overview An of Middleware.In: A. Llamos (2.Auf.) München 1992) [Raasch] Raasch, J.: Systementwicklung Strukturierten mit Methoden; Hanser Verlag McMenamin, S.,Palmer, J.: Strukturierte Systemanalyse; Hanser Verlag 1988 Siehe “Action-Oriented auch Kapitel Design” De Marco, T.: Structured Analysis andSystem Specifcation; Yourdon Inc. 1978/1979. © Prof. U. Aßmann 4 ► ►

Goal Model-DrivenSoftware inDevelopment Spaces(MOST) Technical Understand the modularity lawaspect of separation oriented) Learn about acompletely different strategydecomposition for (crosscutting, aspect- Fakultät Informatik - Institut Software- und Multimediatechnik - Softwaretechnologie

27.1 Aspect-Oriented Decomposition

Prof. Aßmann - Model-Driven Software Development (MDSD) © Prof. U. Aßmann 6  ►

Developmentwith Different Decomposition Strategies Model-DrivenSoftware inDevelopment Spaces(MOST) Technical perspectives simultaneously Concern-oriented (Aspect-oriented)Development decomposition): decomposition criterion stepwise for refnement ( So far, had we – – – – – – – Component-oriented Decomposition Object-oriented Decomposition Data-oriented Decomposition ECA-based Decomposition Action-oriented Decomposition Function--oriented Decomposition Transformative Decomposition modular decomposition strategiesmodular decomposition divide&conquer-based , who decompose regard with to one decomposes into several

Perspective Models, Viewpointsand Views Model-DrivenSoftware inDevelopment Spaces(MOST) Technical formsthe backbone for systematic aspect-oriented development A A simplerviews on component the space. Theconcern space is usedas an index. ofa coupled componentconcern and space. Itserves constructionfor the of A concerns and algebraic an structure A A modeland programcomponents A  component space concern (Belang) – perspective (viewpoint model, viewmodel) model separation-of-concerns (SoC-Space, Sichtenbildungsraum) space concern(aspect space Belangraum,Aspektraum) space, perspective (viewpoint) perspective Examples: 4+1 views Kruchten, of RM-ODP, framework,Zachmann MDA With oneseveral or software systems forms a simpleviewpoint on spacethiscomponent ( system-,artefact- consists of a set of concerns relevant to an actor toan relevant concerns set aof of consists or solutionspace defnesa SoCspace anf ) consists a setof of consistsof a set of consists © Prof. U. Aßmann 8 Actors, Concerns, and Perspectives Actor ►

Model-DrivenSoftware inDevelopment Spaces(MOST) Technical A perspective groupsconcerns on behalf the of eyes an of actor. Actor Perspective Q Perspective P Concernraum Concern 3 Concern 2 Concern 1 © Prof. U. AßmPerspective Q ann 9 Perspective P ► (Sichtenbildungsraum) are Concerns

Concerns and Blood Groupsfor Software and Documents Model-DrivenSoftware inDevelopment Spaces(MOST) Technical – – – Concern mapping Component space Concern space (Belangraum concern or aperspective (viewpoints) colors or defning with bloodgroups (Solution space) with components the software of the system(s) (Aspektraum) Concern Space Concern 2 Concern 1 Aspekt 3 views ) with of components. Concerns group a software system(s) into a into system(s) software a group Concerns components. of (Sichten, slices, Scheiben, Schicht) in component the space, correlateda to concerns (Aspekt, Belang, Farbe, Bloodgroup), grouped into Perspectives (Sichtenabbildung) Concernmapping (SolutionSpace) Component Space SoC space SoC © Prof. U. AßmPerspective Q ann 10 Perspective P ► Concerns andviews together are thecalled

Concerns and Blood Groupsfor Software and Documents Model-DrivenSoftware inDevelopment Spaces(MOST) Technical ■ Example: layout aspect, structural aspect, behavioral aspect (Aspektraum) Concern Space Concern 2 Concern 1 Aspekt 3 aspects (Sichtenabbildung) Concernmapping of the softwareor document the (SolutionSpace) Component Space © Prof. U. Aßmann (staticaspects) (entirewebsite) 11 PerspectiveP PerspectiveQ ► Several technologies owe their success to

Well-known Examples for Aspect Separation Model-DrivenSoftware inDevelopment Spaces(MOST) Technical 1) Document Decomposition into Aspects Structure, Layout, Behavior    Behavior Layout Structure : specifed in CSS or FO : event-condition-action-based reaction: injavascripte.g. or PHP : described inhtml XML or Concern space Concern 3 Concern 2 Concern 1 Reaction Structure Layout aspect-oriented decomposition strategies: Concernmapping Component spaceComponent javascript html html css css (architecture) © Prof. U. Aßmann Perspective1 12 (bloodgroups) Perspective2 3) Bloodgroup Decomposition3) Bloodgroup Application 2) Architectural Decomposition

OtherAO-Decomposition Strategies are Aspect-Oriented Model-DrivenSoftware inDevelopment Spaces(MOST) Technical  Application (A), Technique (T), Algorithmic (0) (see ST-1 and CBSE) Concern space Technology Architecture Application Algorithms Concern 4 Concern 3 Concern 2 Concern 1 (A-T-0, Siedersleben) decomposes a system aspects into the Concernmapping workflow spec Component spaceComponent workflow spec Java Architecture C and Java Java © Prof. U. Aßmann 13 “MDA”): 5) Platform-oriented Decomposition distinguishesthe following aspects(viewpoints): 4) DecompositionEssential

OtherAO-Decomposition Strategies are Aspect-Oriented Model-DrivenSoftware inDevelopment Spaces(MOST) Technical   – – – Adaptation to Platform 1 .... Plattform n Essential activities I: Infrastructure A: Administrative E: Essential checking) dataactivities, structures andtheir stores activities (for communication andadaptation to plattform) activities (for checkthe data of consistency and contract (EAI-Decomposition)(from Structured Analysis) decomposes into a the spects chapter(see © Prof. U. Aßmann 14 ► ► ►

Perspectives (Viewpoints) Model-DrivenSoftware inDevelopment Spaces(MOST) Technical Perspective 2 Perspective 1 perspective A A A view simplePerspective perspective (viewpoint) perspectiveof a consists all of views relatedto concernsthe the of Concern 3 consistsof one concern Concern 2 Concern 1 Concerns consists a setof of concerns (aspects) Views © Prof. U. Aßmann 15 ► ► ►

Perspective Models (ViewpointModels) Model-DrivenSoftware inDevelopment Spaces(MOST) Technical Example: defnes5viewpoints RM-ODP aITon infrastructure Thus, it defnes the aspectseparation asystem of by concerns andviews the on system(s). A http://en.wikipedia.org/wiki/File:RM-ODP_viewpoints.jpg perspective model defnes astandard set of perspectives (viewpoints)with their http://en.wikipedia.org/wiki/View_model concerns of sets © Prof. U. Aßmann 16 ► Model-DrivenSoftware inDevelopment Spaces(MOST) Technical The Perspective modelof [Kruchten]„4+1 ViewModel of Architecture” Architectural Aspects Kruchtenof onthe functions and components Shows an archtiecturalview of a system(s), fordesign, program and runtime The 4+1 Perspective Modeldefnes 2 perspectives for allcomponents – – view Implementation Perspective 2:1 aspect: Szenarios Perspective 1:4 aspects: Concerns and views Process- Logic View View viewswork together Use cases show how Szenarios Development models,and code iles,structureof f the Shows thedevelopment Physical runtimecoordination Viewof distributionand View View © Prof. U. Aßmann 17 http://en.wikipedia.org/wiki/Zachman_Framework Perspective Model „Zachmann Framework“ ►

Model-DrivenSoftware inDevelopment Spaces(MOST) Technical all activities the of software cycle life into views Zachmann proposed amatrix aspectspace out of 5concerns and6questions group to 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

Prof. Aßmann - Model-Driven Software Development (MDSD) © Prof. U. Aßmann 19 ► ►

Corrolary: Concern can beused on any Level Abstractionof Model-DrivenSoftware inDevelopment Spaces(MOST) Technical Concerns (aspects) can be used modules for source or components code The question is „what isacomponent“? – – – For all model elements in amodel: relateaspect For elements andfragments models of andcomponents For models andcode Concern 3 Concern 2 Concern 1 Component Space © Prof. U. Aßmann 20 ► ►

Spaces ConcernSeparation and Concern-Separated Component Model-DrivenSoftware inDevelopment Spaces(MOST) Technical color Ina suchthat every componentis related important task in design:Transform the components of a solution space Concern separation(aspect separation, Aspekttrennung) – concern Ifnotaspect-separated, split components Concern 3 Concern 2 Concern 1 - separated component space toonly one everycomponent carries one Component Space c oncern (has isan one color ) © Prof. U. Aßmann 21 Concern-Separated Component Spaces are Modular ►

Model-DrivenSoftware inDevelopment Spaces(MOST) Technical Slice (Scheibe, view)Slice (Scheibe, In aConcern-Separated Space Component all of components specifc one color a form Concern 3 Concern 2 Concern 1 , akind of ( cross-cutting querschneidendes) module Component Space © Prof. U. Aßmann 22 Modularity Lawof ► ►

Model-DrivenSoftware inDevelopment Spaces(MOST) Technical If a system is concern-separated, the components beloning to one to beloning components the is If concern-separated, system a Exchange fragments of and modelelements Exchange implementation of modules, code compoennts If a system is concern-separated, the components beloning to one to beloning components the is If concern-separated, system a If a system is NOT concern-separated, some components some components concern-separated, is If NOT system a If a system is NOT concern-separated, some components some components concern-separated, is If NOT system a beloning to to beloning color can be exchanged easily exchanged be color can beloning to to beloning color can be exchanged easily exchanged be color can by changing the concern the concern changing by by changing the concern the concern changing by several concerns severalconcerns several concerns severalconcerns Concern-Separated Systems and cannot cannot and and cannot cannot and by changing the concern changing by by changing the concern changing by → split → them split → split → them split be exchanged exchanged be be exchanged exchanged be 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)

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

Prof. Aßmann - Model-Driven Software Development (MDSD) I/O, communication Implementation-dependent andPlatform- © Prof. U. Aßmann 24 The Perspective Model Essentialof Decomposition Error compensationError Contract checking, Consistency checking, Quality assurance, ► ►

Model-DrivenSoftware inDevelopment Spaces(MOST) Technical EAI was invented in SA, but can be used for all development methods Essential Decomposition – – – Infrastructure Administration (functional) Essence consistency checking) infnite memory, infnite bandwidth technology. captures the p Essence assumes ensures the quality the of system (contract checking, data Infrastructure /Middleware Spontaneous Event-Hull forms a SoC space with 3 aspects: are functionsthose independent of the underlying Administration Essence . latform-dependent details perfect technology perfect application Real functional core of [Raasch, McMenamen/Palmer] Events outofthe system , e.g., processes time, without Physical Physical Ring

Process “Cure Proposal/Kurantrag” Example:Aspect-Separated EAI-Decomposition of a Business Model-DrivenSoftware inDevelopment Spaces(MOST) Technical EAI was invented in SA, but can be used for all development methods Essence, Administration, Infrastructure/Middleware The EAI-Decomposition ofa business process (inDFD) can be indicated by different colors for Anfrage Anfrage prüfen_ annehmen _Wunsch Administration Kurwunsch Krankenkasse Patienten- daten Kurunter- ren_Patient suchung aktualisie- Essence Patient Kurvorschlag Verwaltungsaktivität Infrastuktur genehmi- gen_Kur Kurformular Formular

Kur Formular versenden _Formular zeichnen_ Formular _Formular schreiben unter- © Prof. U. Aßmann

26 Application ►

Management Sytem” Ex. EAI-Decomposition aofProcess of a Tool “Application Model-DrivenSoftware inDevelopment Spaces(MOST) Technical Desire for Essence, Administration, Infrastructure The EAI-Decomposition ofa business process (in DFD)can be indicated by different colors _Desire accept application Administration check_ application Administration investigate Infrastucture Essence update Customer Proposal approve permission

Application permission permission send [Raasch] permission _Form Form write sign © Prof. U. Aßmann Concern Space Administration Infrastructure 27 “Application Management” Example:EAI-Decomposition of the Business Process Essence ►

Model-DrivenSoftware inDevelopment Spaces(MOST) Technical The EAI-SoC-Space with SA-DFD application _Desire check_ accept Administration Component Space investigate update Patient approve permission permission _Form send sign write © Prof. U. Aßmann 28 ► ► ► ►

„Essential Structured Analysis (ESA)“ DevelopmentMethod Model-DrivenSoftware inDevelopment Spaces(MOST) Technical [Raasch] combines ZOPP, EAI ESA ECA, decomposition Essential Analysis Structured slicing). is simple: very aspects The decompose DFD into the a slicesof color specifc (graph With DFD, the decomposition bythe aspects (Essence, Administration, Infrastructure) method applications for The books [Raasch, of McMenamen/Palmer]as showacomplete ESAdevelopment – – Petri-nets, workfow activity nets, diagrams aresimilar Stream-based be sliced DFD easilycan isawith development combining process aspect ECA [Raasch, McMenamen/Palmer] © Prof. U. Aßmann 29 ► „Essential Structured Analysis (ESA)“ ECA-Based Development Method 2) ECA-Analysis Three steps: analysis, goal ECA analysis, activity development in EAI

Model-DrivenSoftware inDevelopment Spaces(MOST) Technical ecinietfication Reaction identif icationEvent identif Event TriggerEvent Reaction 1)Project-Goals Event-Analysis (fromZOPP) ECA-Rules 3) Activity Development3) Activity Dictionary Activities data - Essential View Data DFD Essential Reducible DFD Administrative View DFD Administrative Activities - data Reducible DFD [Raasch, McMenamen/Palmer] Infrastructure-View DFD Middleware Infrastructure/ Activities- data Reducible DFD © Prof. U. Aßmann 30 6) 5) 4) 3) 2) 1)

Essential Structured Analysis (ESA) DevelopmentProcess of Model-DrivenSoftware inDevelopment Spaces(MOST) Technical Repeat and refne Elaboration: exchangeand transformation) Analysis: data consistency checking Analysis: Elaboration: Essental Activities Elaboration: Goal 5) 4) 3) 2) 1) Refnement: refne diagram context Analysis: Elaboration: theessential context Specify diagram Elaboration: Elaboration: identify identify identify the integratethe integrated DFD m Identifyreactions ECArules and Identifyexternal events and triggers Infrastructure activities Administration activities identifcation(e.g., with EssentialDatastores identifcation ZOPP) by considering datathe fow (Communication,Data forcontract checking and odelfrom allviews

(with EAI)

Erweiterung von ESA auf das Reengineering von Altsystemen Model-DrivenSoftware inDevelopment Spaces(MOST) Technical Ohne Analyse desOhne AnalyseAltsystems MSpecs Elementar_(FürMSpecs Aktivit.) Datenkatalog 3...6 (2)Essence, Kontext Ereignistabelle ESA ess. Aktivitätenmodelle integrieren (5) neue Inkarnation neue konstruieren neue Essenceneue konzipieren Modellqualität optimieren Anwendergespräche Kontextabgrenzung Ziele essent. ableitenAktivitäten (2) izieren essentielle Fragmenteklassif reduzieren expandieren Ist-Zustand erheben Mit Analyse Mit Analyse des Altsystems Erw. ESA Fakultät Informatik - Institut Software- und Multimediatechnik - Softwaretechnologie

27.4. Extension by Aspect-Orientation

Aspect-Oriented Crosscutting Extensions Model-DrivenSoftware inDevelopment Spaces(MOST) Technical Perspective 1 Perspective possibly crosscutting other component nets andslices Extension works by aspectadding anew with anew extended alsoin With Aspect-Orientation and an appropriate extension mechanism, software can be Extending unforeseen ways Concern 3 Concern 2 Concern 1 crosscutting slice to the system, to the © Prof. U. Aßmann 34 ► ► ► ► ► ► ►

The End – What did welearn? Model-DrivenSoftware inDevelopment Spaces(MOST) Technical this mean software for architecture? How can aspects be to used a extend system workfow in unforeseen ways?does What system Explain andwhy the ESA aspectual decompositionsimplifes the development a of Explain following why the perspective models supportaspect decomposition Explain the law modularity of aspectorientation Which ingredients aperspective does model have? views? How do youAspect-Oriented use Decomposition to structure softwareinto several Why is aspect-oriented decomposition modular differentfrom decomposition? – – – – – Explain the concept a„SoC-space“ of Explain the concept a“Concernspace” of (Belang-Raum) Software Bloodgroups Siedersleben of (siehe ST-1) RM-ODP, Zachmann, 4+1 Kruchten EAI-Decomposition Fakultät Informatik - Institut Software- und Multimediatechnik - Softwaretechnologie

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

Prof. Aßmann - Model-Driven Software Development (MDSD) © Prof. U. Aßmann 36 ► Nets Workflow in JoinOperators and Copy-Split Open Model-DrivenSoftware inDevelopment Spaces(MOST) Technical outgoing edges Remember, open operators in nets,workfow which can be extendedbyincoming resp. without violating the operator contractwithout the of violating

XOR OR AND OR CP- CP- © Prof. U. Aßmann 37 Extending the open operators of a core workflow does not change its contracts. its change contracts. not does workflow of core operatorsa open Extending the Extending the open operators of a core workflow does not change its contracts. its change contracts. not does workflow of core operatorsa open Extending the ► ► Aspect-Oriented Workfows with Harmless Extensions Model-DrivenSoftware inDevelopment Spaces(MOST) Technical Adding an aspectual slice to the open operators of a workflow net of annet workflow a of of operators open to slicethe Adding an aspectual Adding an aspectual slice to the open operators of a workflow net of annet workflow a of of operators open to slicethe Adding an aspectual net. Therefore, adding an retains edge the contracts, i.e., assumptions,basic of aworkfow destroy change or it(monotonic extension) If edges areadded an operator,to open they applicationisa applicationisa harmlessextension. harmlessextension. enrich the semantics enrich semantics the of the net, donotbut