AOSD - Enhancing SoC :: INF5120 :: Mansur Ali Abbasi. AOSD :: Aspect Oriented Software Development SoC :: Separation of Concerns

Transcription

1 :: INF5120 :: Mansur Ali Abbasi AOSD - Enhancing SoC AOSD :: Aspect Oriented Software Development SoC :: Separation of Concerns 1

2 NB! This lecture leans on conciseness rather than completeness (in contrast to F01-F13) ( That means you should read at least some of the articles referenced by this presentation). 2

3 Learning goals 1. Students must a. have an introductory knowledge of AOSD as an emerging development paradigm (including background/rationale) b. acquire basic understanding of main concepts and terminology of AOP. c. acquire basic understanding of main concepts and terminology of AOM. d. recognize and understand the necessity and applicability for AO analysis and design. 2. Students should a. be able to understand the contents of the articles associated with this lecture. b. be able to connect AO-principles to other parts of the curriculum of INF5120 (especially requirements engineering and architecture). c. be able to outline and describe the essential concepts of mainstream state-of-the-art SoC-mechanisms. 3. Students are NOT expected to a. be able to produce or reverse-engineer system designs utilizing AOP/AOM. b. know historical facts or subtile details of AOSD / AOAD. 3

4 Agenda 1. SoC mechanisms in software development a. SoC a definition b. OO technology / Object thinking c. Enhancements to OO-technology d. Agents and Services e. Model-centric thinking 2. AOSD Aspect-Oriented Software Development a. Motivation b. Introduction c. Aspects d. Benefits 3. AOP - Example a. AspectJ 4. AOM Aspect Oriented Modeling a. AOM in general b. AOMDF Overview c. AOMDF - Interactions d. The Theme Approach 5. Summarizing thoughts a. Summarizing thoughts b. Future 6. References 4

5 Part 1 Separation of Concerns 5

6 1a. Separation of Concerns (SoC) Only available way of effectively structuring one s thoughts. Scientific thinking = apply SoC Apply SoC = to consider in depth only a single aspect of a subject matter in isolation for the sake of the aspect s own consistency, while knowing that one is occupying one s mind with only one among all the aspects of the subject matter, and hence being single- and multi-track- minded at the same time. - Edsger W. Dijkstra Divide and conquer break up into sub-problems, solve them individually and then combine their solutions to form the solution to the larger problem. Core intellectual meta-activity during system analysis and design. SoC-effectiveness is a measure of how good a development paradigm is. (OO-techniques provide better SoC than pre-oo techniques). 6

7 1b. OO technology / Object thinking Recall from lecture F01: A paradigm shift in software development Encapsulation everything to do with a thing in one place! Reuse, polymorphism, interfaces, etc Easier to map real world phenomena to software elements Modularity comprehension complex software systems Only a small step w.r.t. SoC Perfectly possible to design spaghetti -systems using OO Decomposition along a single dimension 7

8 1c. Enhancements to OO (1) OORAM Object Oriented Role Analysis Model Address the shortcomings of Object Orientation Most common OOP languages are actually Class Oriented Role models and model synthesis capture phenomena as descriptions of object collaboration patterns Small per-concern metamodels / recipes for implementing specific concerns Abstractions above object models Derive a system through a synthesis of several role models A precursor for UML (Collaboration diagrams) Core ideas present in most modern software development paradgims 8

9 1c. Enhancements to OO (2) OORAM: 9

10 1c. Enhancements to OO (3) UML and OCL UML: De-facto standard modeling language OCL: Express contraints and rules over object models Enabling technologies for MDE / MDA. Design Patterns / Analysis Patterns Repeatable general solutions for common analysis and design problems Visitor, Observer, Abstract Factory, etc. SoC-guidelines, reduce risk of ending up with intangible systems Collected over time experience Anti-patterns 10

11 1d. Agents and Services (1) Goal-orientation / Capability-Orientation Explosion of network- and Internet-based computing interconnected systems with individual agendas and priorities emergence of need to represent systems in terms of business-goals and services Natural evolution from OO thinking Agent-Based Software Development Agent-based system: System of multiple interacting agents that autonomously pursue individual or common interests based on inherent knowledge and continuous environment sensing. Agents: Smart objects / autonomous entities with beliefs, goals, responsibilities and plans. 11

12 1d. Agents and Services (2) Agent-oriented architecture: 12

13 1d. Agents and Services (3) Agent coordination example Contract Net: 13

14 1d. Agents and Services (4) Services and SOA: Recall F09 and F10! Independent services with well-defined interfaces Loosely coupled, black-box software elements Distributed capabilities and ownership Better SoC with Agents and/or Services Higher abstraction Modularization beyond the object-concept (complementary) More natural translation of requirements into software design Easier to reason about distributed systems Interoperability 14

15 1e. Model-centric thinking (1) Model Driven Engineering / MDA Further mechanization in terms of SoC Shift from code-centric to model-centric development Graphical modeling tools (often domain specific) (Semi-)automation of translation from design to implementation CIM, PIM, PSM, mappings / transformations, and all that J2EE.NET 15

16 1e. Model-centric thinking (2) Automation in software development: Requirements Requirements Requirements Manually implement Manually implement Manually implement High-level spec (functional and nonfunctional) Source in a general-purpose language, e.g., Java or C++ Source in domain-specific language (DSL) Compile (may generate code in Java or C++) Source in domain-specific language (DSL) (may generate code in Java or C++) Compile Compile Compile Compile Implementation Implementation Implementation 16

17 1e. Model-centric thinking (3) Contribution in terms of SoC Higher abstraction Multiple views of a system during design Easier to perform round-trip engineering Models are not just additional documentation artifacts, but they are the actual source Instant feedback through simulation / rapid code generation Metamodelling, domain specific languages Narrowing of the path between requirements and implementation! Better SoC? Yes, clearly! BUT some problems remain unsolved / unaddressed 17

18 Part 2 Aspect-Oriented Software Development 18

19 2a. Motivation (1) Good system architecture Must consider both current and future requirements in order to avoid patchy-looking implementations Problem Requirements have become increasingly complex Pervasive, competing concerns (security, logging, fault tolerance, QoS ) Conventional design and implementation techniques are not enough Only allow SoC along a small / fixed set of dimensions Tyranny of the dominant decomposition Crosscutting concerns Code tangling Code scattering Multidimensional concerns / requirements, but only one-dimensional modularization available in implementation platforms Inevitable tangling and scattering 19

20 2a. Motivation (2) Scattering: Design element to support R1 in many places of OO design Tangling: Single OO design unit has elements for many requirements 20

21 2a. Motivation (3) The pain of crosscutting concerns / features Understanding, analyzing and changing them! Information is distributed Maintaining consistency in the presence of changes is difficult Difficult to consider alternative treatments Lack of attention to crosscutting concerns early in the development cycle can lead to major redesign in later stages of development. 21

22 2a. Motivation (4) The solution Need tools for simultaneous separation of overlapping concerns in multiple dimensions Some temporary solutions to this have been around for a while: Design patterns, mix-in classes, domain-specific solution (EJB frameworks) None address the problem at its roots, still tangling and scattering of crosscutting concerns (tyranny of the dominant decomposition prevails) The real solution breaking the tyranny: Aspect Orientation Aspect: modular unit designed to implement a concern. With respect to a primary / dominant decomposition an aspect is a concern that crosscuts that decomposition. 22

23 2b. Introduction (1) Aspect oriented development 3 main steps Aspectual decomposition: Decompose the requirements, identify crosscutting and common concerns. Separate module-level concerns from crosscutting system-level concerns. Example: core credit card processing, logging, and authentication. Concerns implementation: Implement each concern separately. Example: core credit card processing unit, logging unit, and authentication unit. Aspectual recomposition: Specify recomposition rules by creating modularization units -- aspects. Example: must log each operation's start and completion, each operation must clear authentication before executing business logic. The recomposition process, also known as weaving or integrating, uses this information to compose the final system. 23

24 2c. Aspects (1) System-level crosscutting concerns: Logging Authentication Fault-tolerance Domain-specific crosscutting concerns: Billing Timing Monitoring 24

25 2c. Aspects (2) Implementation level: AOP languages, multidimensional separation of concerns in the implementation platform easier translation from requirements to implementation Analysis and design level: Need to identify aspect early in the development phase AOAD techniques / Aspect Oriented Modeling 25

26 2d. Benefits of AOSD Benefits: Modularized implementation of crosscutting concerns Easier-to-evolve systems Since the aspected modules can be unaware of crosscutting concerns, it's easy to add newer functionality by creating new aspects. Further, when you add new modules to a system, the existing aspects crosscut them, helping create a coherent evolution. Late binding of design decisions An architect can delay making design decisions for future requirements, since (s)he can implement those as separate aspects More reuse of components: Aspects are more loosely-coupled components than objects (no tangling of concerns) 26

27 Part 3 AOP through example 27

28 3a. AspectJ (1) Introduction Most popular AOP implementation, extends Java Compiler (or weaver-compiler ) produces standard Java class files AspectJ program == Java program Supplied with aspect-aware debugger, visualization tools, etc. 28

29 3a. AspectJ (2) 1 overlay onto Java Joinpoint: well-defined point in a program's flow. For example, joinpoints could define calls to specific methods in a class 4 small additions to Java Pointcut: Construct to pick out joinpoints and collect context (values) at those points Advice: Code (additional action) that executes upon meeting certain conditions. For example, an advice could log a message before executing a joinpoint Inter-type declarations ( aka open classes ) Aspect: unit of modularity for behavior that crosscuts. Comprised of advice, inter-type, pointcut, field, constructor and method declarations. 29

30 3a. AspectJ (3) Hello world (base code) Plain old java //HelloWorld.java public class HelloWorld { public static void say(string message){ System.out.println(message); } } public static void saytoperson(string message, String name){ System.out.println(name + ", " + message); } 30

31 3a. AspectJ (4) Manners (aspect code) Aspect Pointcut //MannersAspect.java public aspect MannersAspect { pointcut callsaymessage() : call( public static void HelloWorld.say*(..) ); before() : callsaymessage() { System.out.println("Good day!"); } Joinpoint designation Advice } after() : callsaymessage() { System.out.println("Thank you!"); } 31

32 3a. AspectJ (5) Compiled (woven) program: Good day! will be printed before each message and Thank you! after each message. If we add another method in class HelloWorld that fits the joinpoint designation of the callsaymessage pointcut, the aspect advice will apply there as well: public class HelloWorld { public static void saytogroup(string message, List names){ //call saytoperson for each name in the names-list. } } Note how the base code is totally unaware of being aspected by the manners concern. 32

33 3a. AspectJ (6) Pseudo-example: Telecom setting Base: Call routing and setup logic Aspects: Timing, Logging, Billing, QoS, public class Customer{ } public class Call{ } public abstract class Connection{ } public class Local extends Connection{ } public class LongDistance extends Connection{ } public aspect TimerLog{ } public aspect Timing{ } public aspect Billing{ precedence: Billing, Timing; } Aspect precedency in situations where advice from several aspects affect same joinpoints These are trivial examples, AspectJ can do a lot of neat things More AspectJ-examples at: 33

34 Part 4 Aspect-Oriented Modeling 34

35 4a. AOM in general Fusing AO-concepts and Model Driven Engineering Leveraging the strengths of two great advancements in software development The Theme Approach Theme/Doc (analysis) Theme/UML (design) Partial tool support AOMDF (Aspect Oriented Model Driven Framework) Structural and behavioural AOM, extends UML Automated model compositions of Class diagrams and Sequence diagrams Tools support in near future Design only Many other approaches, but the one s mentioned above are the most mature / complete. The Theme approach is the most known of them all. 35

36 4a. AOM in general (2) Reference Architecture for AOM: 36

37 4b. AOMDF Overview (1) 37

38 4b. AOMDF Overview (2) aspect class model 1 instantiate context-specific aspect class models values used in bindings application domain namespace model element names primary class model values used in bindings aspect class model 1 instantiate context-specific aspect class models composition directives compose composed class model 38

39 4c. AOMDF - Interactions (1) sd AspectModelTest (x:string) : C :D :E ma(x) mb(x) 39

40 4c. AOMDF - Interactions (2) sd ComposedSimpleTagEx :A :D :E :B m1(p,q,r) ma(p) mb(p) m2(q) ma(r) mb(r) 40

41 4c. AOMDF - Interactions (3) sd primmodelint :A :B :C m1() <<compositeaspect>> comptest(xtype) m2() <<exclude>> m3() m4() m5() 41

42 4c. AOMDF - Interactions (4) sd comptest(t:type) X Y <<begin>> op1() <<before>> op2() <<body>> op3() <<after>> op4() <<end>> op5() 42

43 4c. AOMDF - Interactions (5) sd composedint :A :X :Y m1() op1() op2() m2op3() op4() m3() op2() m4op3() op4() op5() m5() 43

44 4d. The Theme Approach 44

45 Part 5 Summarizing thoughts 45

46 5a. Summarizing thoughts Contribution to SoC Better separation of crosscutting concerns with AOSD AOP vs. AOM Common theme: Improved support for SoC Code vs. models Code provides a single view of behaviour AOP aspects crosscut source code modules Models provide multiple overlapping views of a systems Views support separation of concerns AOM aspects crosscut views in a model AOM design models are not necessarily descriptions of aspect-oriented programs AOM design models CAN be transformed to non-aop languages. 46

47 5b. Future Much happening in the AOSD-field Several AOP languages and tools have emerged Many variants / frameworks for AOM, standardization? Tool support for AOM Further research on multidimensional SoC AOSD is the next (or actually the current) big thing Thesis suggestions available (AOM-related) Contact: mansuraa@ifi.uio.no, arnor.solberg@sintef.no 47

48 Part 6 References 48

49 6. References Articles: Solberg, A. et al, Developing Service Oriented Systems Using An Aspect Oriented Model Driven Framework, International Journal of Cooperative Information Systems (IJCIS), 2006 Clarke, S. and Baniassad, E., Theme: An Approach for Aspect-Oriented Analysis and Design, Proceedings of the International Conference on Software Engineering (ICSE), 2004 IBM Research, Multi-Dimensional Separation of Concerns: An Overview, Laddad, R., I want my AOP! (Part 1), Laddad, R., I want my AOP! (Part 2), Laddad, R., I want my AOP! (Part 3), Dijkstra, E. W., Selected Writings on Computing: A Personal Perspective, New York: Springer-Verlag, ISBN:

50 6. References (2) Books: Filman, R. E. et al., Aspect-Oriented Software Development: Addison-Wesley Professional, ISBN: Clarke, S. and Baniassad, E., Aspect-Oriented Analysis and Design The Theme Approach: Addison- Wesley Professional, ISBN: Jacobson, I. and Ng, P-W., Aspect-Oriented Software Development With Use Cases: Addison-Wesley Professional, ISBN: Luck, M. et al., Agent-Based Software Development: Artech House Publishers, ISBN: Websites: (now an Eclipse project: (Also check Wikipedia for other AOP-languages and more AOSD-links) 50