Aspect Oriented Programming - AOP/AOSD
- 1. ASPECT-ORIENTED SOFTWARE DEVELOPMENT CONTENTS 21.1 The separation of concerns 21.2 Aspects, join points, and pointcuts 21.3 Software engineering with aspects Prepared by Razık Can PAHALI, 15002697
- 2. OBJECTIVES Understand why the separation of concerns is a good guiding principle for software development; Have been introduced to the fundamental ideas underlying aspects and aspect-oriented software development;
- 3. THE SEPARATION OF CONCERNS Organize your software so that each element in the program does one thing and one thing only. Class, method, procedure, etc.)
- 4. AOSD uses a concept of horizontal slices through vertically-decomposed software components.
- 6. THERE ARE SEVERAL DIFFERENT TYPES OF STAKEHOLDER CONCERN: Functional concerns, Quality of service concerns, Policy concerns System concerns, Organizational concerns.
- 7. 1.The Separation of Concerns
- 8. • The separation of concerns is a key principle of software design and implementation. • It means that you should organize your software so that each element in the program (class, method, procedure, etc.) does one thing and one thing only. • With all this taken into account, maintenance and updating will be easier. • When changes are required, they are localized to a small number of elements
- 9. • Although it is generally agreed that separating concerns is good software engineering practice, it is harder to pin down what is actually meant by a concern. • Sometimes it is defined as a functional notion (i.e., a concern is some element of functionality in a system). • Alternatively it may be defined as any piece of interest or focus in a program. • According to Jacobson and Ng (2004), concerns are really reflections of the system requirements and priorities of stakeholders in the system. • System requirements may be a concern ranging from users wanting a faster response time from the system to stakeholders feeling inclusion of a particular functionality is needed.
- 10. • According to Jacobson and Ng (2004), concerns are really reflections of the system requirements and priorities of stakeholders in the system. • System requirements may be a concern ranging from users wanting a faster response time from the system to stakeholders feeling inclusion of a particular functionality is needed. • A concern can therefore be defined as something that is of interest or significance to a stakeholder or a group of stakeholders.
- 11. • The core concerns of a system are those functional concerns that relate to its primarypurpose. • Therefore, for a hospital patient information system, the core functionalconcerns are the creation, editing, retrieval, and management of patient records. • In addition to core concerns, large systems also have secondary functional concerns. • These may involve functionality that shares information with the core concerns, or which is required so that the system can satisfy its non- functional requirements.
- 12. New Customer Requirements Account Requirements Customer Management Requirements Security Requirements Recovery Requirements Core Concerns Cross-cutting Concerns
- 13. • The cross cutting example in Figure 1 is based on an internet banking system. • This system has requirements relating to new users, management of existing users and management of customers. • All of these core concerns are associated with the systems primary functions- the internet baking service • However the system also has security requirements and recovery requirements. • These are cross-cutting concerns as they may influence the implementation of all of the other system requirements.
- 14. Programming language abstractions, such as procedures and classes, are the mechanism that you normally use to organize and structure the core concerns of a system. However, the implementation of the core concerns in conventional programming languages usually includes additional code to implement the cross-cutting, functional, quality of service, and policy concerns. This leads to two undesirable phenomena: tangling and scattering.
- 15. • Tangling occurs when a module in a system includes code that implements different system requirements. • The related phenomenon of scattering occurs when the implementation of a single concern (a logical requirement or set of requirements) is scattered across several components in a program. • This is likely to occur when requirements related to secondary functional concerns or policy concerns are implemented.
- 16. • Problems with scattering and tangling occur when the initial system requirements change. For example, say new statistical data had to be collected in the patient record system. • The changes to the system are not all located in one place and so you have to spend time looking for the components in the system that have to be changed. You then have to change each of these components to incorporate the required changes. • This may be expensive because of the time required to analyze the components and then make and test the changes. • There is always the possibility that you will miss some code that should be changed and so the statistics will be incorrect. • Furthermore, as several changes have to be made, this increases the chances that you will make a mistake and introduce errors into the software.
- 17. 2.Aspects, join points, and pointcuts
- 18. TERMINOLOGY USED IN ASPECT-ORIENTED SOFTWARE ENGINEERING Term Definition advice The code implementing a concern. aspect A program abstraction 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 advice code at the specified join points by an aspect weaver.
- 19. AN AUTHENTICATION ASPECT aspect authentication { before: call (public void update*(..)) // this is a pointcut { // this is the advice that should be executed when woven into // the executing system int tries = 0 ; string userPassword = Password.Get ( tries ); while (tries <3 && userPassword != thisUser.password ( ) ) { // allow 3 tries to get the password right tries = tries + 1 ; userPassword = Password.Get ( tries ) ; } if (userPassword != thisUser.password ( )) then //if password wrong, assume user has forgotten to logout System.Logout (thisUser.uid) ; } } // authentication
- 20. ASPECTJ - JOIN POINT MODEL Call events Calls to a method or constructor Execution events Execution of a method or constructor Initialisation events Class or object initialisation Data events Accessing or updating a field Exception events The handling of an exception
- 21. POINTCUTS Identifies the specific events with which advice should be associated. Examples of contexts where advice can be woven into a program Before the execution of a specific method After the normal or exceptional return from a method When a field in an object is modified
- 22. ASPECT WEAVING Aspect weavers process source code and weave the aspects into the program at the specified pointcuts. Three approaches to aspect weaving Source code pre-processing Link-time weaving Dynamic, execution-time weaving
- 25. TYPES OF EXTENSION o Secondary functional extensions o Policy extensions o Quality of service extensions o Infrastructure extensions
- 26. CONCERN-ORIENTED REQUIREMENTS ENGINEERING It’s important to separate concerns while determining the requirements engineering. Requirements for the core system as well as requirements for the system extensions should be identified.
- 28. Apart from secondary functional requirements, there are cross- cutting concerns which reflect policy and quality of service non-functional requirements that apply to the system as a whole. Having too many concerns or extensions to the system is not recommended as it might lead to a system design that does not conform to its quality of service requirements.
- 29. ASPECT-ORIENTED DESIGN/PROGRAMMING Aspect-oriented design The process of designing a system that makes use of aspects to implement the cross-cutting concerns and extensions that are identified during the requirements engineering process. Aspect-oriented programming The implementation of an aspect-oriented design using an aspect-oriented programming language such as AspectJ.
- 30. USE CASES FROM THE INVENTORY MANAGEMENT SYSTEM
- 31. A GENERIC ASPECT-ORIENTED DESIGN PROCESS
- 32. DESIGN ACTIVITIES Core system design where you design the system architecture to support the core functionality of the system. Aspect identification and design Starting with the extensions identified in the system requirements, you should analyze these to see if they are aspects in themselves or if they should be broken down into several aspects. Composition design At this stage, you analyze the core system and aspect designs to discover where the aspects should be composed with the core system. Essentially, you are identifying the join points in a program at which aspects will be woven.
- 33. AN ASPECT-ORIENTED DESIGN MODEL
- 34. PART OF A MODEL OF AN ASPECT
- 35. PROGRAM INSPECTION PROBLEMS To inspect a program (in a conventional language) effectively, you should be able to read it from right to left and top to bottom. Aspects make this impossible as the program is a web rather than a sequential document. You can’t tell from the source code where an aspect will be woven and executed. Flattening an aspect-oriented program for reading is practically impossible.
- 36. TESTING PROBLEMS WITH ASPECTS How should aspects be specified so that tests can be derived? How can aspects be tested independently of the base system? How can aspect interference be tested? How can tests be designed so that all join points are executed and appropriate aspect tests applied?