Aspect-oriented Software DevelopmentObjectivesTopics coveredAspect-oriented software developmentThe separation of concernsConcernsStakeholder concernsCross-cutting concernsSlide 9TanglingScatteringAspects, join points and pointcutsAspect terminologyAn authentication aspectAspectJ - join point modelPointcutsAspect weavingSlide 18Software engineering with aspectsCore system + extensionsTypes of extensionConcern-oriented requirements engineeringViewpoints and ConcernsViewpoints on an inventory systemAvailability requirementsInventory system - core requirementsInventory system - extension requirementsAspect-oriented design/programmingUse-casesAn extension use caseInventory use casesInventory extension use-caseAn AOSD processUML extensionsAn aspect-oriented design modelA partial model of an aspectVerification and validationTesting problems with aspectsProgram inspection problemsWhite box testingAspect problemsKey pointsSlide 43©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 32 Slide 1Aspect-oriented Software Development©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 32 Slide 2ObjectivesTo explain the principle of separation of concerns in software developmentTo introduce the fundamental ideas underlying aspect-oriented developmentTo show how an aspect-oriented approach can be used at all stages of developmentTo discuss problems of testing aspect-oriented systems©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 32 Slide 3Topics coveredThe separation of concernsAspects, join points and pointcutsSoftware engineering with aspects©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 32 Slide 4Aspect-oriented software developmentAn approach to software development based around a new type of abstraction - an aspect.Used in conjunction with other approaches - normally object-oriented software engineering.Aspects encapsulate functionality that cross-cuts and co-exists with other functionality.Aspects include a definition of where they should be included in a program as well as code implementing the cross-cutting concern.©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 32 Slide 5The separation of concernsThe principle of separation of concerns states that software should be organised so that each program element does one thing and one thing only.Each program element should therefore be understandable without reference to other elements.Program abstractions (subroutines, procedures, objects, etc.) support the separation of concerns.©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 32 Slide 6ConcernsConcerns are not program issues but reflect the system requirements and the priorities of the system stakeholders. •Examples of concerns are performance, security, specific functionality, etc.By reflecting the separation of concerns in a program, there is clear traceability from requirements to implementation.Core concerns are the functional concerns that relate to the primary purpose of a system; secondary concerns are functional concerns that reflect non-functional and QoS requirements.©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 32 Slide 7Stakeholder concernsFunctional concerns which are related to specific functionality to be included in a system.Quality of service concerns which are related to the non-functional behaviour of a system. Policy concerns which are related to the overall policies that govern the use of the system. System concerns which are related to attributes of the system as a whole such as its maintainability or its configurability.Organisational concerns which are related to organisational goals and priorities such as producing a system within budget, making use of existing software assets or maintaining the reputation of an organisation.©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 32 Slide 8Cross-cutting concernsCross-cutting concerns are concerns whose implementation cuts across a number of program components.This results in problems when changes to the concern have to be made - the code to be changed is not localised but is in different places across the system.Cross cutting concerns lead to tangling and scattering.©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 32 Slide 9Cross-cutting concernsSecurity req.Recovery req.Core concernsNew customerreq.Customermanagement req.Accountreq.Cross-cuttingconcerns©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 32 Slide 10Tanglingsynchronized void put (SensorR ecord rec ) throws Interrupte dException { if ( numberOfEntries == bufsize) wait () ; store [back] = ne w SensorRecord (rec.sensorId, rec.sensor Val) ; back = back + 1 ; if (back == bufsize) back = 0 ; numberOfEntries = numberOfEntries + 1 ; notify () ; } // put©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 32 Slide 11ScatteringPatientgetName ()editName ()getAddress ()editAddress ()...anonymise ()...<attribute decls>ImagegetModality ()archive ()getDate ()editDate ()...saveDiagnosis ()saveType ()...<attribute decls>ConsultationmakeAppoint ()cancelAppoint ()assignNurse ()bookEquip ()...anonymise ()saveConsult ()...<attribute decls>©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 32 Slide 12Aspects, join points and pointcutsAn aspect is an abstraction which implements a concern. It includes information where it should be included in a program.A join point is a place in a program where an aspect may be included (woven).A pointcut defines where (at which join points) the aspect will be included in the program.©Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 32 Slide 13Aspect terminologyTerm Definition advice The code implementing a concern. aspect A program abstr action that defines a cross-cutting concern. It includes the definition of a pointcut and the advice associated with that concern. join point An event in an executing program where the advice associated with an aspect may be executed. join point model The set of events that may be referenced in a pointcut. pointcut A statement, included in an aspect, that defines the join points where the associated aspect advice should be executed. weaving The incorporation of