Aspect Oriented Programming Aspect Component Based Software Engineering

Aspect Oriented Programming Aspect Component Based Software Engineering (ACBSE) Razieh Asadi University of Science & Technology Mazandran Babol

programming languages and software design processes ØDesign processes : break a system down into smaller and smaller units ØProgramming languages : define abstractions of system sub-units, compose those abstractions to produce the overall system ØAbstraction and composition mechanisms is common key object-oriented languages, procedural languages and functional languages

Requirement ØFunctional : system must able to do it. e. g. registering in education system. ØNonfunctional : Issues in connection with the system and how to do tasks well. e. g. Performance, Quality of Service.

What is a Concern ? One or more requirement related to stakeholders and development, able to implement with a code structure ØCore Concerns : –Necessary for correct ? –Is part of program Logic –Encapsulate in module

What is a Concern ? (cont 1) ØCrosscutting Concerns: –Is not part of program Logic. e. g. Logging –Cannot be cleanly encapsulated in a module and affect on many module –Lack of clear separation in design and implementation –Tangling and Scattering

What are the Crosscutting Concerns ? ØTangling –Code separate in multiple module ØScattering –Code mixed with code of other concerns

Crosscutting Concerns ØInfrastructure Concern –Nonfunctional requirement. e. g. security, logging ØPeers Concern –Functional requirement –Overlap in implementation ØExtension Concern –Functional requirement –New concern over basic concerns

What Is an Aspect ? ØAspects are an program unit of modularity. ØAvoid of separation cross-cutting code ØImplement Crosscutting Concerns Without Aspect With Aspect

What Is an Aspect ? (cont. ) Aspect Consists of two sections : Ø Advice code Including piece of code that must be executed (After, Before, Around) Ø Pointcut Points that advice code must be executed in

Aspect Oriented programming ØCrosscutting concerns are implemented in aspects instead of fusing them into core modules. ØBy reducing code tangling it makes it easier to understand what the core functionality of a module is. ØNot replacement for OOP

Aspect Weaver ØIntegration takes the aspects and the core modules and composes the final system ØCan be implemented in various ways Compile-Time By the language compiler Loading-Time first compile source with original compiler, then weave aspects into class files Run-Time By a classloader

Aspect Weaver

Programming environment ØUse a Object Oriented language –E. g. Java, C++ ØAspect. J Weaving in loading and compiling time ØJava Aspect Component (JAC) Weaving in run time ØJBoss AOP Weaving in run time And open source

Example public class Example { public static void deliver. Message(String essage) { println ("The message is: " + message); } public static void main(String [] args) { deliver. Message("I'm here"); … deliver. Message("Aspect. J rocks"); } }

Example public aspect Example. Aspect { pointcut hello. PC() : call(void Example. deliver. Message(. . )); before() : hello. PC() { System. out. print("Hello! "); } after() : hello. PC() { System. out. println("The message has been delivered. "); } }

Current CBSE problems ØLack of reusability and adaptability in CBSE ØCode-tangling is inherent to CBSE program (crosscutting concern) ØUses statement (like CCM statement) during component specification may be considered harmful

Current CBSE problems (cont. ) ØCBS adaptability and reusability ØUpdating Non-functional properties in CCM each component can be configured in Package Phase. ØUpdating functional properties Container can not be used, business rules change for system , specify in Design Phase

Current CBSE problems (cont. ) ØAspect Component Based Software Engineering (ACBSE) solved this problem ØNew requirements involve change in all of the component life cycle ØAOP create changes in each component based system development phase

Dependency in Specification Phase ØBelong to the component ØMust be maintained by all implementations ØUse of component is quite limited ØNew dependencies becomes difficult task ØSolution : Specify dependencies avoiding crosscutting at the Implementation Phase

Dependency in Implementation Phase ØDependency 1. Intrinsic 2. Non-intrinsic ØSolution : Each component only implements the basic business functionality (intrinsic)

Dependency in Package Phase 1. Define during system design phase (UML) 2. Dependencies in UML translated to XML Descriptor Specification 3. XML descriptor describes the on-intrinsic for each component 4. Recompile the component code, add restriction and dependencies that specified in XML descriptor 5. These dependencies are expressed as aspect

Dependency in Package Phase ØXML descriptors use to describe the component properties ØAllows us to apply the non-intrinsic dependencies ØDependencies with other component are not expressed in the implementation

Dependency in Assembly and Deployment Phase ØDefine non-intrinsic and intrinsic dependencies ØDependencies in UML translated to XML Assembly Descriptor ØPermit us to connect the component implementation

ACBSE advantages ØReusability Component is not recoded, implementation adapted to new business rules by changing nonintrinsic dependencies ØAdaptability Modifying the component descriptor by altering the final component functionality ØScalability New components with their intrinsic and nonintrinsic dependencies can be used to compose new system

References [1] Pedro J. Clemente and Juan Hernández, Aspect Component Based Software Engineering, University of Extremadura. Spain [2] Gregor Kiczales, et al. , Aspect-Oriented Programming, proceedings of the European Conference on Object-Oriented Programming (ECOOP), Finland. Springer-Verlag LNCS 1241. June 1997.

Aspect Oriented Programming Aspect Component Based Software Engineering (ACBSE) The end 07. 01. 2010