Spring 2005 ECE450H1S Software Engineering IILecture 7 Aspect-orientation (AO*)A new paradigm in Software EngineeringCopyright © Yijun Yu, 2005Spring 2005 ECE450H1S Software Engineering IILast lecture and tutorial …Software Quality Measurements• We have shown the use of quality measurements to monitor the progress of software development• The development/restructuring (maintenance) activities (refactoring, tuning, adding features) can be guided by the metrics of softgoalsSpring 2005 ECE450H1S Software Engineering IIToday …On Aspect Orientation• Today we explain the paradigm of aspect-orientation1. Concepts: What are aspects?2. Practices: Aspect-orientation at large– AOP: Aspect-oriented programming– AOSD: Aspect-oriented software development– AORE: Aspect-oriented requirements engineering– AOSR: Aspect-oriented software reuse (probably next lecture)3. A case study of AORE4. SummarySpring 2005 ECE450H1S Software Engineering II1. What are aspects?1. Some design principles• Divide and conquer: problem solving/design principle• Modularization: high cohesion/low couplingSeparation of concerns• DRY: Don’t Repeat YourselfIncrease the fan-in2. Previous paradigms• 70s – 80s: Structured programming (Goto’s considered harmful) => Structured Analysis, Structured Design• 80s – 90s:Object-oriented programming (OOP) =>OOA/OOD => UML3. Why another paradigm ?• Since late 90s …Separation of the crosscutting concerns4. What are aspects?– Modularizing the crosscutting concernsSpring 2005 ECE450H1S Software Engineering II1.1 Some design principlesStructured programming• What is structured program?– A program has no more GOTO’s– Only three kinds of structure prevails• Sequential• If-then-else• Loops[Dijkstra: Goto considered harmful]– In other words, every statement block has single-entry, single-exit as Hammock Graph[Weiser: Program slicing]• “Whenever possible, we wish to maximize fan-in during the design process. Fan-in is the raison d’être of modularity. Each instance of multiple fan-in means that some duplicate code has been avoided.”raison d'être: grounds for existence (http://www.french-linguistics.co.uk/dictionary/)[Yourdon & Constantine79] Structured Design (pg. 172, see also http://wwwpa.win.tue.nl/wstomv/quotes/structured-design.html)[parnas: Modularization, information hiding]Spring 2005 ECE450H1S Software Engineering II(1) A decomposition hierarchy from abstract to concrete: Divide and Conquer, Structured Design; (2) Don’t Repeat Yourself, Factoring / Refactoring …CCCCCCCSpring 2005 ECE450H1S Software Engineering IIExampleSCANVALUEREMOVALLMOVE UNTILFINDSTRINGCOMPYourdon & Constantine, SD, pg.168Spring 2005 ECE450H1S Software Engineering II1.1 Some design principlesObject-oriented programming• Everything is an object (Smalltalk)• Information hiding / Encapsulation: object groups related data and the operations on the data into a module• Object has structural relationships:– inheritance: generalization / specialization: isA/instanceOf– aggregation : hasA / isPartOf– associations: 1-to-many, 1-to-1, many-to-many• In the end, the structurally-related objects are packaged into componentsSpring 2005 ECE450H1S Software Engineering II1.2 Aspect-orientation• Component language (any structured or OO language, even corresponding design and requirements specification)• What are crosscutting concerns?• An aspect language– What are joinpoints?– What are pointcuts?– What are advices?• A weaving mechanismSpring 2005 ECE450H1S Software Engineering IIAspect concepts• Concepts: cross-cutting, component, aspect, join points, weavingAOP hides the join pointsAspectCSpring 2005 ECE450H1S Software Engineering IIAOP (THE MAGIC)SCANVALUEREMOVALLMOVE UNTILFINDSTRINGCOMPSpring 2005 ECE450H1S Software Engineering IIAOP (NOT REALLY MAGIC)SCANVALUEMOVE UNTILFINDSTRINGCOMPREMOVALLFIND: AT LINE 5VALUE: AT LINE7SCAN: AT LINE 15MOVE UNTIL: AT LINE 8REMOVALL: AT LINE 2Spring 2005 ECE450H1S Software Engineering IIAOP example/** ==== ======== ====== =========== ======== ========== ======= ======= =======** The Apache S oftwar e License, Version 1.1** Copy right (c ) 1999 The Apache Softwar e Foundati on. Al l right s* rese rved.** Redi stributi on and use in sou rce and binary for ms, wit h or wi thout* modi fication , are permitted p rovided that the f ollowin g condi tions* are met:** 1. R edistrib utions of source code mus t retain t he abov e copyr ight* n otice, t his li st of condi tions an d the foll owing d isclaim er.** 2. R edistrib utions in binary form mus t reproduc e the a bove co pyright* n otice, t his li st of condi tions an d the foll owing d isclaim er in* t he docum entati on and/or o ther mat erials pro vided w ith the* d istribut ion.** 3. T he end-u ser do cumentation include d with the redist ributio n, if* a ny, must inclu de the foll owing ac knowlegeme nt:* "This produc t includes software developed by the* Apach e Soft ware Founda tion (ht tp://www.a pache.o rg/)."* A lternate ly, th is acknowle gement m ay appear in the softwar eitself,* i f and wh erever such third -party a cknowlegem ents no rmally appear.** 4. T he names "The Jakarta Pro ject", " Tomcat", a nd "Apa che Sof tware* F oundatio n" mus t not be us ed to en dorse or p romote product sderived* f rom this softw are without prior w ritten per mission . For w ritten* p ermissio n, ple ase contact apache@ apache.org .** 5. P roducts derive d from this softwar e may not be call ed "Apa che"* n or may " Apache " appear in their n ames witho ut prio r writt en* p ermissio n of t he Apache G roup.** THIS SOFTWAR E IS P ROVIDED ``A S IS'' A ND ANY EXP RESSED OR IMPL IED* WARR ANTIES, INCLUD ING, BUT NO T LIMITE D TO, THE IMPLIED WARRAN TIES* OF M ERCHANTA BILITY AND FITNES S FOR A PARTICULAR PURPOS E ARE* DISC LAIMED. IN NO EVENT SHAL L THE AP ACHE SOFTW ARE FOU NDATION OR* ITS CONTRIBU TORS B E LIABLE FO R ANY DI RECT, INDI RECT, I NCIDENT AL,* SPEC IAL, EXE MPLARY , OR CONSEQ UENTIAL DAMAGES (I NCLUDIN G, BUT NOT* LIMI TED TO, PROCUR EMENT OF SU BSTITUTE GOODS OR SERVICE S; LOSS OF* USE, DATA, O R PROF ITS; OR BUS INESS IN TERRUPTION ) HOWEV ER CAUS ED AND* ON A NY THEOR Y OF L IABILITY, W HETHER I N CONTRACT , STRIC T LIABI LITY,* OR T ORT (INC LUDING NEGLIGENCE OR OTHE RWISE) ARI SING IN ANY WA Y OUT* OF T HE USE O F THIS