Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.



Published on

feedback me for document

Published in: Technology
  • Be the first to comment

  • Be the first to like this


  1. 1. UNF Digital CommonsUNF Theses and Dissertations Student Scholarship2002Incorporating Aspects into the SoftwareDevelopment Process in Context of Aspect-Oriented ProgrammingMark Alan BaschUniversity of North FloridaRecommended CitationBasch, Mark Alan, "Incorporating Aspects into the Software Development Process in Context of Aspect-Oriented Programming"(2002). UNF Theses and Dissertations. Paper 112. Masters Thesis is brought to you for free and open access by theStudent Scholarship at UNF Digital Commons. It has been accepted forinclusion in UNF Theses and Dissertations by an authorized administratorof UNF Digital Commons. For more information, please
  2. 2. INCORPORATING ASPECTS INTO THE SOFTWARE DEVELOPMENT PROCESS IN THE CONTEXT OF ASPECT -ORIENTED PROGRAMMING by Mark Alan Basch A thesis submitted to the Department of Computer and Information Sciences in partial fulfillment of the requirements for the degree of Master of Science in Computer and Information Sciences UNIVERSITY OF NORTH FLORIDADEPARTMENT OF COMPUTER AND INFORMATION SCIENCES December 2002
  3. 3. ACKNOWLEDGEMENTI wish to thank my thesis adviser, Dr. Arturo 1. Sanchez, for his assistance andpatience in guiding me through the thesis process. 11
  4. 4. The thesis "Incorporating Aspects into the Software Development Process in theContext of Aspect-Oriented Programming" submitted by Mark Alan Basch in partialfulfillment of the requirements for the degree of Master of Science in Computer andInformation Science has beenAppro d b the ¥eSiS mmittee Date Signature Deleted c ezThesis Adviser and Committee Chairperson Signature DeletedRobert F. Roggio Signature DeletedNeal S. CoulterAccepted for the Department of Computer and Information Sciences Signature Deleted 1~/{( {2>LAccepted for the College of Computing Sciences and Engineering Signature Deleted nilLl ~ ~Neal S. CoulterDean of the CollegeAccepted for the Unive~ Signature Deleted /.).:1 1 r(c 2..-Thomas S. SerwatkaDean of Graduate Studies 111
  5. 5. CONTENTSL1St 0 fFIgures ................................................................................ Vll1 · ...Abstract ........................................................................................ .ixChapter 1: Introduction ....................................................................... 1Chapter 2: Aspect-Oriented Programming ................................................ .4 2.1 History of AOP Research ...................................................... .4 2.2 Description of AOP ............................................................. 7 2.2.1 AspectJ ............................................................... 10 2.2.2 Other Aspect-Oriented Languages ............................... 14Chapter 3: The Software Development Process .......................................... 17 3.1 The Unified Process ............................................................. 18 3.1.1 History of the Unified Process .................................... 18 3.1.2 Description of the UP ......................... " .................... 19 3.2 Agile Processes ................................................................... 22 3.2.1 Extreme Programming .............................................. 24 3.3 The Unified Process and Extreme Programming ............................ 25Chapter 4: The Unified Modeling Language ................................................ 27 4.1 History ofUML .................................................................. 28 IV
  6. 6. CONTENTS (continued) 4.2 UML Basic Concepts .......................................................... 29 4.2.1 Static View .......................................................... 30 4.2.2 Use Case View ..................................................... 31 4.2.3 Interaction View ................................................... 32 4.2.4 State Machine View .............................................. .32 4.2.5 Other Views ........................................................ 33 4.2.6 Extensibility ........................................................ 33Chapter 5: Aspects in the Software Development Process .............................. 35 5.1 Aspects Created in the Unified Process ..................................... 36 5.1.1 Aspects in the Inception Phase ................................... 36 5.1.2 Aspects in the Elaboration Phase ................................ 39 5.1.3 Aspects in the Construction Phase ............................. .43 5.1.4 Aspects in the Transition Phase ................................ .46 5.2 Aspects Created in Extreme Programming ................................ .47 5.3 Chapter Summary ............................................................... 52Chapter 6: Modeling Aspects in the Unified Modeling Language ..................... 54 6.1 Aspects and UML Proposals from the Netherlands Conference ......... 55 6.1.1 Aspects as Packages ............................................... 55 6.1.2 Using Extensibility Mechanisms ................................. 56 v
  7. 7. CONTENTS (continued) 6.1.3 Extensions for AspectJ .......................................... 57 6.1.4 Making Aspects First-Class Citizens ......................... .58 6.1.5 Aspects and Statecharts ......................................... 60 6.2 Aspects and UML Proposals from the Germany Conference .......... 60 6.2.1 Aspects in Activity Diagrams .................................. 61 6.2.2 Modeling Aspects at the Requirements Level. .............. 61 6.2.3 Creating New UML Icons for Aspects ........................ 62 6.2.4 Principles of Aspect-Oriented UML Modeling .............. 63 6.3 Proposal for Modeling Aspects in the Unified Modeling Language ... 64 6.3.1 Aspect Packages in the UML .................................. 66 6.3.2 Aspects and Use Case Diagrams .............................. 69 6.3.3 Class Diagrams for Aspects .................................... 70 6.3.4 Interaction Diagrams for Aspects .............................. 72 6.3.5 Aspects and State chart Diagrams .............................. 81 6.3.6 Aspects and Other UML Diagrams ............................ 83 6.4 Chapter Summary ............................................................. 84Chapter 7: Conclusions and Future Work ............................................... 86References .................................................................................... 89Appendix A: Use Cases and Supporting Documents .................................. 96 VI
  8. 8. CONTENTS (continued)Appendix B: UML Specifications of Join Points .................................... 113Appendix C: UML Specifications of Aspects ....................................... .l16Vita .......................................................................................... 119 vii
  9. 9. LIST OF FIGURESFigure 2.1: Cross-cutting aspect. ........................................................... 7Figure 2.2: Output of Hello World AspectJ program .................................... 12Figure 3.1: The Unified Process ............................................................ 21Figure 4.1: Class diagram ................................................................... 30Figure 4.2: Use case diagram ............................................................... 31Figure 4.3: Collaboration diagram ......................................................... 31Figure 4.4: Sequence diagram ............................................................... 32Figure 4.5: Statechart diagram .............................................................. 33Figure 6.1: Aspect packages ................................................................ 67Figure 6.2: Aspect class diagram .................................................. , ........ 71Figure 6.3: Sequence diagram with notes indicating aspects ........................... 74Figure 6.4: Sequence diagram with aspect objects ....................................... 75Figure 6.5: Collaboration diagram with aspect objects .................................. 76Figure 6.6: Sequence diagram with Before and After aspect advice ................... 77Figure 6.7: Sequence diagram with aspect and join point elements .................... 79Figure 6.8: Aspect sequence diagram ...................................................... 80Figure 6.9: Statechart diagram with links to aspects ..................................... 83 Vl11
  10. 10. ABSTRACTAspect-oriented programming is a relatively new approach to programming that isdesign to resolve issues of separation of concerns. Rather than focusing oncommonality 0 f 0 bjects, as in object-oriented programming, aspect -orientedprogramming focuses on commonality of concerns, or more precisely as described byexperts in the field, of "cross-cutting concerns." These are aspects that cut acrossdifferent modules of a program, such as security and authentication issues.While much research in the area has focused on developing programming languages,little attention has been given to dealing with aspects in the software developmentprocess and the Unified Modeling Language. This thesis will examine how aspectsare created during the software development process and how they can be modeled inthe UML. ix
  11. 11. Chapter 1 INTRODUCTIONMuch attention in computer programming techniques these days focuses on object-oriented programming, the practice of creating a program by identifying objects anddeveloping classes related to the objects. But very recently, some programmingexperts have suggested a supplementary approach called aspect-orientedprogramming. Rather than focusing on commonality of objects, aspect-orientedprogramming focuses on commonality of concerns, or more precisely as described byexperts in the field, on "cross-cutting concerns." These are aspects that cut acrossdifferent modules of a program, such as security and authentication issues.Proponents of aspect-oriented programming, or AOP, argue that it improvesefficiency of coding by making the program more modular [ElradOlB].Since this is a relatively new field, much of the AOP research to date has beenfocused on developing programming languages that can accommodate aspect-oriented techniques, but attention toward incorporating AOP into the softwaredevelopment process is just beginning. For instance, there are no standards forrepresenting aspects in the Unified Modeling Language, or UML [Rumbaugh 99].Within the past year, there have been workshops on aspect-oriented modeling at the1sl International Conference on Aspect-Oriented Software Development in April and - 1-
  12. 12. at the Fifth International Conference on the Unified Modeling Language inSeptember. With research in the early stages, there is no consensus on how aspectsshould be modeled in the UML.While aspect-oriented programming is a new and even unknown concept to manyprofessional software developers, its adoption into the mainstream is already beingtouted by some observers. It was identified by the MIT Technology Review as one of"ten emerging areas of techno logy that will soon have a profound impact on theeconomy and how we live and work [Demeter02]," stating that widespread adoptionof aspects holds out the promise of less buggy upgrades, shorter product cycles and,ultimately, better and less expensive software [TristramOl]."While AOPs impact on the world is still debatable, it is worthwhile to developstandards for developing aspects and modeling them in the UML.This thesis examines how software developers can express aspects in the softwaredevelopment process and how aspects should be modeled in the UML. It will includea proposal to incorporate aspects in the next revision ofthe UML standards. Thethesis focuses on the well-known Unified Process [Arlow02], but it also addressesother development processes such as Extreme Programming [Wake02] and otherAgile Software Development processes [Cockbum02]. -2-
  13. 13. The thesis will trace the textbook example of a real estate system [KulakOO] as it goesthrough the software development process and demonstrate how the AOP-relatedelements of the system are modeled in the UML. -3-
  14. 14. Chapter 2 ASPECT-ORIENTED PROGRAMMINGAspect-oriented programming, or AOP, is a programming technique that has beendeveloped over the past decade. It aims to increase efficiency in coding by offering amethod of dealing with concerns that are scattered repeatedly throughout a systemacross different modules, resulting in "tangled" code [Kiczales97]. Examples of theseconcerns include areas such as security, logging, error handling or synchronizationthat are re-used at various points in the program. These concerns are said to be "cross-cutting" because they cut into various modules of a system, such as classes andobjects of an object-oriented program.In the field of aspect-oriented programming, these cross-cutting concerns are knownas "aspects." The aspects are separated from the main program, thus untangling thecode and providing better modularity and an enhanced ability to reuse the aspects[ElradOlB].2.1 History of AOP ResearchIn the late 1980s and early 1990s, several research groups were studyingprogramming approaches to solve the problems of separation of concerns. Those -4-
  15. 15. groups included the Trese Group at the University of Twente in the Netherlands,which developed an approach called Composition Filters; a team at the IBM ThomasJ. Watson Research Center that developed an approach called MultidimensionalSeparation of Concerns; and the Demeter research team at Northeastern Universitythat developed Adaptive Programming.The Demeter group did much early research on the problem of separation of concernsand in 1987 proposed the "Law of Demeter," which states "each unit should haveonly limited knowledge about other units: only units closely related to the currentunit." The laws motto is "only talk to your immediate friends" [Demeter02].The group introduced Adaptive Programming in 1991 [Connections02], a techniquein which programs are decomposed into cross-cutting building blocks.The Demeter group published a 1995 paper [Hursch95] that identified "a newparadigm in software engineering called separation of concerns." Although the paperdoes not use the term "aspect-oriented," Karl Lieberherr, the leader of the Demeterteam, refers to this paper as one of the early works on aspect-oriented programming[LieberherrOO] .The Trese Group began working on its Composition Filters approach to handlingcross-cutting concerns in the late 1980s. The group described its approach as early as1992 [Aksit92]. - 5-
  16. 16. The term "aspect-oriented programming" and much of the development of AOP iscredited to Xeroxs Palo Alto Research Center, or PARC, which began working onthe discipline in 1992 [Morales02]. Much of the current research in the field pointsback to a seminal paper [Kiczales97] presented by the PARC group in 1997 to theEuropean Conference on Object-Oriented Programming, or ECOOP. The paperdescribes aspects as issues that address "design decisions" that are difficult to capturewith traditional object-oriented programming techniques. And it says the aspects aredifficult to capture because "they cross-cut the systems basic functionality."The paper breaks down elements of a program into two terms: components, which areelements that "can be cleanly encapsulated in a generalized procedure" and aspects,which cannot be cleanly encapsulated. In simplified terms, the component can bethought of as a module of the main program, while the aspect is a separate modulethat interacts with components repeatedly throughout the main program.The goal of AOP, according to the PARC team [Kiczales97], is "to support theprogrammer in cleanly separating components and aspects from each other."Research in AOP increased considerably after publication ofPARCs 1997 paper.IBMs approach to aspect-oriented issues, called Multidimensional Separation ofConcerns, was introduced in 1999. -6-
  17. 17. Research in the field has advanced further in the past two years, with the 1stInternational Conference on Aspect-Oriented Software Development held in theNetherlands in April 2002. The second annual AOP conference is scheduled to beheld in Boston in March 2003. Additionally, major software development-relatedconferences such as ECOOP, Object-Oriented Programming, Systems, Language andApplications (OOPSLA) and the International Conference on Software Engineeringregularly feature AOP-related papers in their proceedings.2.2 Description of AOPA further illustration of aspects as cross-cutting concerns can be found in adescription offered by PARC team leader Gregor Kiczales in [ElradOIB]. It isillustrated in the simple diagram of a figure editor depicted in Figure 2.1. Figure 2.1: Cross-cutting aspect -7-
  18. 18. The illustration shows a figure editor that is used to draw points and lines. Thedrawing of a point or a line is contained in separate classes, called Point and Line.The program includes a concern that every time a new point or line is drawn, the userwill be notified. This is the concern called DisplayUpdating. Since this concern isinvoked if either a point or line is drawn, the DisplayUpdating concern cross-cuts thepoint and line classes. This becomes an aspect.In most research about AOP, examples of aspects include concerns such as errorhandling functions, synchronization, logging or security, such as authenticating a userwhen a database is accessed. But aspects are not limited to those concerns. Accordingto PARes defmition of aspects in its 1997 paper [Kiczales97], any concern thatcross-cuts a component and "can not be cleanly encapsulated in a generalizedprocedure" can be programmed as an aspect.In a traditional program, there are at least two ways the DisplayUpdating concern (orany other aspect) can be handled. In one way, the DisplayUpdating code can berewritten in every class in which it cross-cuts. In the above example, it would bewritten once for the line class and repeated in the point class.This creates the problem referred to as "tangling" [Miller01]. Simply put, the codebecomes a tangled mess with too many concerns running together in one module,making it difficult to trace and understand. -8-
  19. 19. Related to tangling is the concept of "scattering," [AspectJ02] which refers to thesame code being scattered throughout different modules ofthe program. Problemsarise when the scattered code needs to be changed, and the programmer has to fmdevery instance of the code and ensure that the changes made are identical.The other way the cross-cutting concern can be handled is to create a separatefunction for the concern. The main program can then use the concern with a simplefunction call. But a function call can be complicated because of the parameters thatare passed between the main program and the function. The programmer has toensure that the correct form and number are passed to the function and if theparameters of the function are altered, the programmer must find every function calland re-check the parameters.By separating the cross-cutting concern into an aspect, the code is simplified andmodularity of the program is improved. The component (the main program module)makes no reference to the aspect being called, so the main functions of the programcan be traced without interference from the aspects. However, at certain points in thecomponent, an aspect will be invoked, although it is invisible to the main program.These points where the aspects are instantiated are referred to as "join points"[ElradOlB]. They are simply a designation of where the aspects cross cut thecomponents. The complication in aspect-oriented programming is developing - 9-
  20. 20. techniques in which the aspects and components can properly refer to the join points,so that the aspects are invoked at the proper times.The aspects and components are joined together in a software system through the useof an "aspect weaver" [Kiczales97]. The aspect weaver is basically a compiler thatweaves aspects and components together into a single, executable program.There are several AOP languages under development that include a compiler that willperform the aspect weaving. The most well-known language and probably the mostadvanced is being developed by the PARC researchers, and it is known as AspectJ[AspectJ02].2.2.1 AspectJAspectJ is an extension of Java that is intended to be easily learned and used by Javaprogrammers. As Kiczales said in an interview: "Normally when people have a new programming paradigm, they make a whole new language. But by putting it in Java, a Java programmer can become an aspect-oriented programmer in 15 minutes" [Morales02].Any Java program can be cleanly compiled by the AspectJ compiler, but an AspectJprogram containing aspects can not be compiled by a Java compiler. - 10-
  21. 21. AspectJ consists of three main elements: [AspectJ02] • Join points are the points in the Java program where an aspect is called and executed. • Pointcuts are references in the aspect to the join points. Basically, while the joint point is the point in the program where the aspect and component cross- cut from the components (or main programs) view, the pointcut is the cross- cutting point from the aspects view. • Advice is the code in the aspect that is executed when the main program reaches a join point.Here is a simple AspectJ example based on a similar example from a recent researchpaper [Laddad02B]. It is based on the traditional "Hello World" program and beginswith a Hello World Java class that has two methods that print messages: public class HelloWorld { public static void sayHello(} Systern.out.println("Hello World"}; public static void sayltAgain(} { Systern.out.println("Hi again"};The program is complicated by an aspect in AspectJ that incorporates tasks to print"Begin message" before any message is printed and "End message" when themessage is completed. The following coding represents the aspect. - 11 -
  22. 22. public aspect PerformTask{ pointcut callPerformTask () : call(public static void say* ()); before() : callPerformTask() { System.out.println("Begin message"); } after() : callPerformTask() { System.out.println("End message");The ftrst line of the code above declares an aspect called PerformTask, similar tothe way a Java class is declared. The second line declares the pointcut. Theinformation on the left side of the colon deftnes a pointcut namedcallPerformTask. The information on the right side of the colon tells us thisaspect will be invoked every time a public static method beginning with say iscalled.The rest of the aspect consists ofthe advice. The before code indicates code thatwill be executed as soon as the joint point is reached, before the code in the main Begin message Hello World End message Begin message Hi again End message Figure 2.2: Output of Hello World AspectJ program - 12 -
  23. 23. program is executed. The after code is executed once the code in the main programis executed. Figure 2.2 shows what the output ofthis AspectJ program would be.While AspectJ is often demonstrated with before and after advice, there is nomandate that an aspect have either or both. There is also a third type of advice,around [AspectJ02], which basically executes around the component, and there arevariations on both before and after. There are no required types of advice thatmust be used in AspectJ.The AspectJ joint points are most commonly found at method calls in the main Javaprogram, but joint points can also be found at constructor calls, read/write access to afield, exception handler execution and object and class initialization [Laddad02B].The PARe group is continuing to develop AspectJ. The latest version as of thiswriting is release 1.0.6 and is available for free download from the groups web site at is also getting support from other developers. For example, the Eclipsedevelopment environment [Eclipse02] is now including AspectJ as one of itssupported languages. - 13 -
  24. 24. 2.2.2 Other Aspect-Oriented LanguagesAspectJ is the most widely-used aspect-oriented language, and much ofthe researchconcerning AOP in the software development process and the Unified ModelingLanguage is based on programming with AspectJ. However, there are other aspect-oriented languages and techniques in various stages of development.AspectJ was designed as a compatible extension to Java [AspectJ02], and some ofthedevelopers of that language have naturally extended their work to other languages.For example, AspectC was designed from the non-object-oriented areas of AspectJ[AspectC02] and is being developed from there. It is not publicly available as of thiswriting.That group also has used the AspectJ design to develop AspectC++. A prototype ofAspectC++ is available [AspectC++02] but is not ready for use in softwaredevelopment.Outside of the work ofthe PARC group, the most well-known aspect-oriented tool isHyperJ, which is being developed by the aforementioned IBM researchers. HyperJ isa tool that addresses "Multidimensional Separation of Concerns," or MDSOC. HyperJdecomposes a program into separate concerns [HyperJOl]. It makes no distinctionbetween classes and aspects [OssherOl]. The separate concerns are known as"hyperslices. " - 14-
  25. 25. Each hyperslice can be implemented as a stand-alone software module. This is adifference between HyperJ and AspectJ. In AspectJ, the aspects only function as add-on modules that are weaved into an application [MillerOl].For example, the IBM developers describe a corporate organization system in whichinformation about employees, such as job titles (personnel feature) and salaries(payroll feature) are kept [OssherOl]. While the personnel and payroll features couldbe described as cutting across a class called "employee," in HyperJ each feature-employee, personnel and payroll- is modeled as a separate hyperslice that mayormay not overlap with other hyperslices.HyperJ was designed not as an extension to Java but as a tool that can be used toadapt any off-the-shelf Java component [OssherOl]. It is written in standard Java andis also available for free download [HyperJOl].The Demeter groups Adaptive Programming technique is, in the groups own words,a "special case of Aspect-Oriented Programming" [Connections02]. In this technique,an adaptive method (its version of an aspect) contains definitions of join points andinstructions that will be performed at those join points [LieberherrO 1]. The techniqueuses a traversal strategy to weave the join points in the program. - 15 -
  26. 26. Like HyperJ, Adaptive Programming is not an extension of Java but offers a Javapackage called the Demeter/Java, or DJ, library that, the group says, "covers a largeportion of real-world programming tasks" [LiberherrOl].The Trese groups Composition Filters approach provides filters as an enhancementto objects. Each filter represents an aspect [TreseOl]. The filters are described asmodular, in that they are independent of the implementation ofthe objects they areattached to, and orthogonal, in that they are independent of other filters. The groupsays those two properties increase adaptability and reuse of the aspects, as filters[BergmansO 1].A comprehensive list of AOP languages and techniques can be found at the Aspect-Oriented Software Development web site at the research groups listed here have been studying AOP-related issues for atleast a decade and there are a number of language projects underway, the AspectJlanguage developed by the P ARC team is the most advanced and the most widelyused. So AspectJ will be referred to often in this thesis to illustrate aspects in thesoftware development process. - 16 -
  27. 27. Chapter 3 THE SOFTWARE DEVELOPMENT PROCESSA software development process uses the best practices in the industry, combiningtechnology, tools, people and organizational patterns, to efficiently develop qualitysoftware [Rumbaugh99].At the current time, aspect-oriented programming is generally not part ofthemainstream software development process, because the programming techniques itadvocates are not in mainstream use yet. But if one is to assume that aspect-orientedprogramming will be incorporated into the programming world as a standard practice,it stands to reason that modeling and developing aspects will become a standardpractice in software development processes.In order to incorporate AOP into software development, it is necessary to look atsoftware development processes in use today. One widely-known process is theUnified Process, but other so-called Agile Processes such as Extreme Programmingare also gaining popularity. This thesis will examine aspects in both the UnifiedProcess and Extreme Programming development processes. - 17 -
  28. 28. 3.1 The Unified ProcessThe Unified Process, or UP, is a development process that describes a set of activitiesneeded to develop a users requirements into a software system. The UP is use-casedriven, architecture-centric and iterative and incremental. It uses the UnifiedModeling Language (which will be described in Chapter 4) to model the system[Rumbaugh99]3.1.1 History of the Unified ProcessThe roots of the UP trace back to work fIrst unveiled at Ericsson in 1967 [Arlow02],which used a set of interconnected blocks to diagram software systems. The blockswere created from so-called traffic cases" (which evolved into what are now knownas use cases"), which described how the system would be used.In 1976, the Specification and Description Language, or SDL, was issued by theCCITT, the international body for standardization in the telecommunications field[Rumbaugh99]. The SDL, which was influenced by the Ericsson design system, useda set of components that communicated with each other by sending signals.In 1987, Ivar Jacobson left Ericsson and founded a new company called ObjectoryAB, which developed a software development process called "Objectory" (short forObject Factory) [Rumbaugh99]. - 18 -
  29. 29. Objectory was acquired in 1995 by Rational Software Corp. This softwaredevelopment process, as it evolved, was known as the Rational Objectory Processfrom 1995 through 1997. In 1998, the name was changed to Rational Unified Process,reflecting the fact that Rational had acquired a number of different companies andincorporated their work into its own unified software development process[Rumbaugh99] .The Rational Unified Process, or RUP, is commonly used and referred to in softwaredevelopment studies. But the RUP refers to a proprietary software developmentprocess owned by Rational. This thesis will use the Unified Process, or UP, which isclosely related to RUP but is a separate, generic process.3.1.2 Description of the UPAccording to the three Rational developers who are credited as the primary inventorsof the UP (Jacobson, James Rumbaugh and Grady Booch), there are threecharacteristics ofthe UP that set it apart from other processes: it is use-case driven,architecture-centric and iterative and incremental [Rumbaugh99]Use cases constitute an analysis tool that can be used to elicit software requirementsfrom user expectations by showing what a software system is expected to do throughuse scenarios. It should describe what a user puts into the system and what comes outwhen the user does something [KulakOO]. In other words, it captures the requirements - 19-
  30. 30. of a system by describing the users interactions with the system. By saying theUnified Process is use-case driven, that means the ultimate deployment ofthe systemis driven by what is specified in the use cases.The UP is architecture-centric because the systems architecture is a fundamentalelement that is taken into consideration for all development decisions as the systemevolves.The UP is iterative and incremental in that it repeatedly goes through a series ofcomplete "mini-projects" [Rumbaugh99] as the system evolves through a series ofcycles that culminate with a new release of the software.Each cycle is divided into four phases and each phase is divided into iterations[Rumbaugh99]. The phases are: • Inception, where an idea is developed into a business case; • Elaboration, where the use cases are specified and the system architecture is designed; • Construction, where the system is built; and • Transition, where the system moves into release. - 20-
  31. 31. Requirements Amount of workAnalysisDesignImplementation Figure 3.1: The Unified ProcessEach phase can have one or more iterations (mini-projects), and the iterations includefive so-called core workflows: requirements, analysis, design, implementation andtest [Arlow02].Figure 3.l is an oft-repeated illustration of the Unified Process. For example, it showsthat there is more emphasis on requirements and analysis in the elaboration phasethan in other phases. And most of the implementation occurs in the constructionphase.This thesis will examine a project as it goes through the phases and iterations anddemonstrate how aspects are unveiled during the projects life cycle. - 21 -
  32. 32. 3.2 Agile ProcessesAn agile software development process is one that can be described as "both light andsufficient" [Cockburn02]. A description of agile processes can be best explained bylooking at a manifesto issued by the Agile Alliance, a group of 17 developers ofvarious agile processes who met in February 2001 and agreed, in the manifesto, onfour core values of agile development [Agile02]: • "Individuals and interactions over processes and tools;" • "Working software over comprehensive documentation;" • "Customer collaboration over contract negotiation;" and • "Responding to change over following a plan."Beyond the four core values, the alliance also agreed on 12 principles: [Agile02] 1. "Our highest priority is to satisfy the customer through early and continuous delivery of valuable software." 2. "Welcome changing requirements, even late in development. Agile processes harness change for the customers competitive advantage." 3. "Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale." 4. "Business people and developers must work together daily throughout the project." - 22-
  33. 33. 5. "Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done." 6. "The most efficient and effective method of conveying information to and within a development team is face-to-face conversation." 7. "Working software is the primary measure of progress." 8. "Agile processes promote sustainable development. The sponsors, developers and users should be able to maintain a constant pace indefmitely." 9. "Continuous attention to technical excellence and good design enhances agility." 10. "Simplicity - the art of maximizing the amount of work not done - is essential. " 11. "The best architectures, requirements and designs emerge from self- organizing teams." 12. "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly."In short, agile development emphasizes development teams working together inconstant communication, including communication with the users, and turning outnew software releases as quickly as possible.There are various agile methods in use, with names such as Adaptive SoftwareDevelopment, Scrum, Crystal, Feature-Driven Development and Dynamic System - 23 -
  34. 34. Development Method [Cockburn02]. This thesis will look at one of thesemethodologies, known as Extreme Programming.3.2.1 Extreme ProgrammingExtreme Programming is a relatively new software development process thatemphasizes a repeated cycle of coding and testing to incrementally build a system.Once the code is working, a process called refactoring is used to attempt to improvethe code design. No one developer "owns" the code, so any member of theprogramming team is free to change code when he or she feels it is necessary[Wake02].The programming team, working in pairs, is put together in an open workspace tofoster communication between team members. The customer is on site to interactwith the programming team as much as possible. Extreme Programming also calls fora 40-hour work week to avoid burnout [Wake02].The core values of Extreme Programming are simplicity, testing, communication andcourage - that is, the courage to go ahead and make whatever improvements aredeemed necessary [Cockburn02].The Extreme Programming process begins with a "Release Planning Game"[Wake02], in which the customer writes "stories" on cards describing features ofthe - 24-
  35. 35. system. The customer and the programmers then work together to decompose andprioritize the stories and decide what is needed to implement them.After the stories are written, the development team divides them into tasks, which arealso written on cards, for the purpose of planning iterations. The individualprogrammers then estimate the tasks and decide which tasks they will implement inthe iteration.Although the term "Extreme" is used in today s popular culture to describe somethingthat is new and youth-oriented, proponents emphasize that Extreme Programming isderived from development practices that have been around for a long time[HighsmithOO]. The difference, they say, is Extreme Programming is more flexibleand more responsive to customers changing needs.3.3 The Unified Process and Extreme ProgrammingRational has produced a white paper [Smith02] to compare the Unified Process, asconceived in its Rational Unified Process, and Extreme Programming to "dispel thenotion that XP is a lightweight, and therefore desirable, alternative to heavyweightRUP."The paper compares Extreme Programmings story-writing phase to the inceptionphase of the Unified Process, with the stories substituting for use cases. It contrasts - 25 -
  36. 36. the two processes by saying that Extreme Programming moves straight fromrequirements gathering into planning for the first release, while the Unified Processgoes into the elaboration phase after inception in which the architecture is stabilized.It says the UPs construction phase is equivalent to Extreme Programmings series ofproduct releases, although each iteration in the construction phase does not result in arelease to the customer. And Extreme Programming does not have a transition phase,since the customer is constantly receiving new releases.A major difference between the Unified Process and Extreme Programming is thatthere are a far greater number of artifacts produced in the UP. Extreme Programmingde-emphasizes documentation.The Unified Process is tied in with the Unified Modeling Language, while ExtremeProgramming appears to have no modeling standards, or perhaps no need for them.This thesis is intended to demonstrate how aspects are uncovered in the softwaredevelopment purpose and then modeled in the UML, so much of the thesis willconcentrate on a project developed in the UP and modeled in the UML. But while itwill not offer modeling examples for Extreme Programming, it does consider aproject developed through Extreme Programming and how aspects would be unveiledand developed in that process. - 26-
  37. 37. Chapter 4 THE UNIFIED MODELING LANGUAGEThe Unified Modeling Language, or UML, is a general-purpose visual modelinglanguage that is used to document the design and analysis activities of a softwaresystem [Rumbaugh99]. While it is closely tied with object-oriented programming andwith the Unified Process and some people consider the UP the preferred developmentprocess for use with UML, the UML is not tied to any particular softwaredevelopment process or paradigm [Arlow02].The word "Unified" is used to denote that UML: • Brings together historical methods and notations; • Is used seamlessly through each phase of the development cycle; • Is used across application domains; • Is used across programming languages and platforms; • Is used across software development processes; and • Attempts to be consistent with its internal concepts [Rumbaugh99]. - 27-
  38. 38. 4.1 History ofUMLThe Unified Modeling Language was adopted as an industry standard relativelyrecently. A number of researchers were working on modeling languages for object-oriented development when, in 1994, James Rumbaugh, who had developed alanguage called Object Modeling Technique, or OMT, joined Rational SoftwareCorp., There he worked with Grady Booch, who had developed a technique called theBooch method [Arlow02]. In 1995, Ivar Jacobson brought his Objectory softwaredevelopment process to Rational, and he joined with Rumbaugh and Booch indeveloping UML [Rumbaugh99]. These three were also the main developers of theUnified Process at Rational, which is why UML is so closely associated with UP.In 1996, the Object Management Group requested proposals for a standard approachfor object-oriented modeling. The three Rational developers, with input from otherdevelopers at other companies, refmed the UML and submitted it to the OMG forapproval in September 1997. It was adopted by the OMG as the standard modelinglanguage in November 1997 [Rumbaugh99]. - 28 -
  39. 39. 4.2 UML Basic ConceptsThe UML is comprised of three building blocks [Arlow02]: • Things, which are the modeling elements; • Relationships, which specify how things are tied together; • Diagrams, which are views that show collections of things.The modeling constructs of the UML are classified into "views." The classificationsare listed in various ways, depending on the researcher. Once concept is known as the4+ 1 architecture because it consists of four views, all integrated by a fifth view,which is the use case view [Arlow02]. That view consists of use case diagrams andinteraction diagrams.The other four views are the logical view, which consists of class diagrams,statecharts and object diagrams; the process view, which has class diagrams andobject diagrams; the implementation view, which has component diagrams; and thedeployment view, which has deployment diagrams.The three Rational developers, in their UML reference manual [Rumbaugh99], give adifferent description of the views. They divide them into four main areas: - 29-
  40. 40. • Structural area, which describes things in the system and their relationship with other things. This area includes the static view, use case view, implementation view and deployment view; • Dynamic area, which describes the system behavior. It includes the state machine view, the activity view and interaction view; • Model management area, which organizes the models and crosses the other views; and • Extensibility area, which gives developers the ability to extend the UML.4.2.1 Static ViewThe static view models classes and their relationships through a class diagram. Theclasses are drawn as rectangles, as shown in Figure 4.1. 1 Figure 4.1: Class diagram1 All UML diagrams in this chapter represent screen shots taken from a sample project in TogetherControl Center, a CASE tool for modeling a system with the UML. - 30-
  41. 41. Figure 4.2: Use case diagram4.2.2 Use Case ViewThe use case view, as shown in Figure 4.2, models the system as outside usersinteracting with the system. The users are called actors. Figure 4.3: Collaboration Diagram - 31 -
  42. 42. Figur 4.4: qu nc Diagram4.2.3 Int raction VieTh int racti n ho th flow of contr I a ro many bj ct through a qu nc of me age exchang . It can be mod I d a a collaboration diagram a in igur 4.3, which mod 1 th object and links of an interacti n. Or it can m deleda a qu ne diagram a in igur 4.4. which ho a tom ag in qu nee.4.2.4 tat n1achin wTh tat machin vie model a t ofobj ct at a p riod tim i which a c rtai ent occur . It can 10 19ur 4.5. - 32-
  43. 43. Figure 4.5: Statechart diagram4.2.5 Other ViewsOther views include the activity view, which uses an activity diagram to describe anoperation; the implementation view, which uses a component diagram to display thesoftware units of an application; the deployment view, which uses a deploymentdiagram to show the nodes of a system; and the model management view, whichmodels the system as a set of packages.4.2.6 ExtensibilityThe UML has three extensibility mechanisms [Arlow02]: • Constraints, which use a text string to specify rules about a modeling element; - 33 -
  44. 44. • Stereotypes, which allow developers to defme a new modeling element as a variant of an existing element. The stereotype is indicated with a «stereotype> designation; and • Tagged values, which allow developers to add properties to a modeling element.The extensibility mechanisms give developers flexibility to tailor a model for theirown needs. - 34-
  45. 45. Chapter 5 ASPECTS IN THE SOFTWARE DEVELOPMENT PROCESSIn order to determine how aspects arise in the software life cycle, this thesis will gothrough the steps ofthe Unified and Extreme Programming processes and indicatepoints along the path of a project where a developer would determine aspects arerelevant in connection with the solution domain.In addition to generically describing the process, in this chapter we will use aclassroom project that was studied in a two-semester Engineering of Software class atthe University of North Floridas CIS Department in the fall semester of2001 andspring semester of 2002. The project is based on a textbook case described in[KulakOO, pp. 175-250].The case is an application for a real estate agency that wants a system that can listproperties for sale and let buyers and sellers, as well as real estate agents working forthe company, list properties up for sale, peruse the list, and work through the processof selling a property. The case study, much of which was outlined in the textbook butwas also expanded by the students, includes a number of use cases, a list of businessrules and a list of nonfunctional requirements. The full set of these documents can befound in Appendix A. - 35 -
  46. 46. Developing use cases from meetings between developers and users is the first step increating an application in the Unified Process, so the use cases already developed inthis case study are a good starting point for unveiling aspects in the softwaredevelopment process through the Unified Process.Although Extreme Programming uses "stories" instead of use cases for requirementsgathering, the information in the use cases will also be the basis for examiningaspects in the Extreme Programming process.5.1 Aspects Created in the Unified ProcessAs discussed in Section 3.1, the Unified Process consists of four phases. Each of thephases includes one or more iterations through the five main workflows. This thesiswill go through the four phases in order to see where aspects would be created duringthe software development process.5.1.1 Aspects in the Inception PhaseThe goal of the Inception phase of the Unified Process is to develop a business casethat justifies moving forward with the project [Jacobson99]. Much ofthe activitycenters on initial requirements gathering, and while some decisions may be madeabout architecture, there is relatively detail of the functional requirements consideredin this phase. So only a small number of aspects will be identified in this phase. - 36 -
  47. 47. There would likely be one iteration through the five workflows in the Inceptionphase. Most ofthe work, as illustrated in Figure 3.1 in Chapter 3, would come in thefrrst workflow, which is the gathering of requirements. This workflow consists ofidentifying actors who interact with the system and use cases that illustrate thefunctional requirements of the system. This workflow will also create the list ofnonfunctional requirements. While the use cases are not completed in the Inceptionphase, making it difficult to make determinations about functional requirements, adeveloper may make the decision early on that a nonfunctional requirement will bedesigned as an aspect.The analysis workflow in this iteration is where a developer may begin to consideraspects from the list of nonfunctional requirements. Although very few details aboutthe system implementation are considered at this point in the process, the developermay make a "frrst rough cut" [Rumbaugh99] at an analysis model by identifyingclasses and packages. Therefore, potential aspect packages could be identified at thispoint. As will be discussed in Chapter 6, aspects should be modeled as independentpackages for the purposes of the Unified Modeling Language.In examining the list of nonfunctional requirements for the real estate agency(Appendix A), two aspect candidates emerge. Requirement 12 sets certainperformance levels for online response time that must be maintained by the system. Ifthe developers decide that response time should be monitored from within the system,this could be modeled as an aspect. - 37 -
  48. 48. The requirement mandates that agents should get a response within 10 seconds 90percent ofthe time. At this point in the process, there may not be enough detail in theuse cases to pinpoint every instance where an agent will need a system response. Butthe agent will be interacting with the system in several use cases, such as Close onProperty, Offer Price on Property and Agree to Terms. Since response time will haveto be monitored during each of these use cases, an aspect to monitor the time willcross-cut these concerns many times throughout the system.Likewise, other users will interact with the system in several use cases, includingSelect Agent, Agree to Terms and Process Loan. The nonfunctional requirementmandates that external users receive a response from the system within seven seconds95 percent ofthe time. An aspect to monitor response to external users will alsocross-cut many concerns of the system.The second aspect found in the list of nonfunctional requirements would come fromrequirement 15, which considers recoverability from a server crash. There will bemany instances in the system where information is stored in a database, such as whena user lists a property, makes an offer on a property or closes a property. An aspect tocreate an audit trail that tracks database transactions will also cross-cut with thosesystem functions.It should be noted that we consider these as "candidates" for aspects at this stage ofthe process, because it may be determined later during design, implementation or test - 38 -
  49. 49. workflows in this phase or later phases that these features are better handled withoutaspects.Moving on with the single iteration of the Inception phase, the design workflow isconcerned with determining the architectural design of the system. So there would beno consideration of possible aspects in this workflow.The implementation and test workflows are generally not used in this phase, unless aminimal prototype must be built to confIrm the viability of the architecture.5.1.2 Aspects in the Elaboration PhaseWhile developers in the elaboration phase continue to capture requirements for thesystem, the principal objective of this phase is to form the architecture baseline forthe project [Rumbaugh99]. Most of the analysis and design decisions made duringthis phase are made to the extent that they are necessary to establish that architecturebaseline, not in the interest of effIciency of coding. So searching for aspects in thisphase is not a primary concern. Yet, some aspects can potentially be unveiled here.By the end of the elaboration phase, about 80 percent of use cases should beidentifIed but as little as half of those will be described in detail and even fewer thanthat may be fully analyzed [Rumbaugh99]. However some steps will be taken in thisphase toward separation of concerns. - 39 -
  50. 50. In the requirements workflow, as use cases are identified, the developer will look forcertain redundancies. These redundancies could be modeled as "include"associations, in which the redundant procedure becomes a separate use case that isincluded by association with other use cases. At this point in the process, thedeveloper may not have enough detail about the use cases to determine whether thesetypes of relationships exist. So in the elaboration phase, the developer is looking forobvious redundant features.These features may be candidates for aspects, but they are more likely to be complexprocedures that are a central feature of the software system, so they are very likely tobe modeled as functions or methods in the main program.An example of this may be a retail establishment that makes several types oftransactions with its customers. Regardless of the type of transaction, theestablishment would go through the same type of procedure to process the customerspayment, so "Process Payment" would become a use case that is included in all of thetransaction use cases. That would be obvious even if the use cases, as written at thispoint in the elaboration phase, did not detail the payment process. So the processwould be separated from the transaction use cases. However, the complexity of"Process Payment" would make it an unlikely candidate for an aspect. - 40-
  51. 51. In looking at the use cases for the real estate agency in Appendix A, no obviouscandidates for "include" associations emerge and no new candidates for aspectsemerge at this point.In the elaboration phase, the analysis workflow is the likely point where aspectswould be identified. As part of the architectural analysis, the developer in this phasewill identify "generic analysis mechanisms." These mechanisms include[Rumbaugh99] : • Persistence; • Distribution and concurrency; • Security features; • Fault tolerance; and • Transaction management.These are the concerns that are typically associated by researchers with aspects. Evenwithout detailed procedures outlined in use cases, which have not yet been completedat this stage, the developer can reasonably assume that some of these genericmechanisms will be needed and that they will be modeled as aspects.In the case of the real estate agency, we have already determined some ofthesemechanisms in Section 5.1.1 from the list of non-functional requirements. Theseaspects were for performance time and fault tolerance. - 41 -
  52. 52. While it was not on the list of non-functional requirements, at this point we will addanother mechanism that should be modeled as an aspect - a security function. Thereis a separate use case to authenticate users when they enter the system. However,once users are in the system, there should be another concern that ensures that theyonly have authorized access to certain features. For example, a potential homepurchaser should not have access to personal records of the seller that may be in thedatabase, and vice versa. A security concern, modeled as an aspect, would ensure thatthe user has the proper clearance to view certain records or make certain transactions.This will cross-cut many concerns in the system.In the design workflow of the elaboration phase, while developers may not havemuch detail to work with from the use cases, they do have enough information tocontinue identifying classes and potential packages and relationships between thoseclasses and packages. Again, most ofthe work in this phase is concerned withestablishing the architecture, so there is no mandate to create detailed designs of theaspects at this point. But at least some aspects can be identified and separated.The generalized information in the real estate agency use cases that the developerwould have at this point produces no additional candidates for aspects.Just as in the inception phase, the implementation and test workflows are minimal inthe elaboration phase. Some significant use cases may be implemented, but the - 42-
  53. 53. aspects would not be considered significant to the business case, which is still beingestablished at this point, to make further work on aspects worthwhile in this phase.It should be noted that the elaboration phase may contain two or more iterationsthrough the five workflows. As the developers go through the iterations, they mayidentify more aspects on follow-up passes through the analysis phase.5.1.3 Aspects in the Construction PhaseThe purpose of the construction phase is to produce a "beta release" version of thesoftware system [Jacobson99]. In the first two phases, much of the groundwork waslaid for the project but much of the detail was skipped. In the construction phase,most of the remaining details of the use cases are fleshed out, which gives thedeveloper an opportunity to examine detailed procedures of the system and determinewhere the use of aspects would be appropriate.In this phase, there are likely to be several iterations through the five workflows asthe beta version of the system is built in small increments. So there may be severalpoints in the phase where aspects are discovered and created. But for the purposes ofour example, we will go through each workflow once.In the construction phase, the requirements gathering and analysis, which were themajor workflows of the first two phases, are minimized, as indicated in Figure 3.1. - 43 -
  54. 54. Early in the construction phase, the design workflow is featured but toward the end ofthe phase, the emphasis is on implementation.Since the requirements and analysis workflows are largely complete by this phase, itis unlikely that new aspects will be found during those workflows in the constructionphase iterations. Most ofthe use cases have already been identified (in requirements)and the architecture of the system (in analysis) is basically already determined.In the design workflow of the construction phase, the developer will be studying thedetails of the use cases that have been overlooked, to an extent, in previous phases. Sothis is an opportunity to uncover aspects.In looking through the details of the use cases for the real estate agencies, threecandidates for aspects emerge.The fITst aspect here would be a "no agent" warning. One of the use cases is a "SelectAgent" case in which a buyer or seller of property chooses a real estate agent, whoworks for the agency, to be his or her representative. However, the system also allowsbuyers and sellers to act without an agent, with acknowledgement that the use of anagent can be advantageous in working out a transaction.At various points in the system, a buyer or seller may attempt to negotiate a contractor close a deal without an agent. That may be an oversight on their part. The party - 44-
  55. 55. may want to bring in an agent for help at that point. The system could send the user awarning message that he or she can still select an agent at this point. In fact, such awarning is indicated in the procedures of the "Offer Price for Property" use case. Thatwould be modeled as an aspect that cross-cuts the system at many points.As a buyer or seller goes through the transaction process through several use cases,including making an offer, negotiating a contract, inspecting the property and closingthe deal, the details ofthe transaction (whether referred to as an offer or contract) gothrough many changes. It may be worthwhile to log the changes by date and time andwho made the changes. The logging concern would ideally be modeled as an aspectthat is outside the flow of the systems main procedures but cross-cuts many of theprocedures.Another logging concern regards user access to the system. From a marketingperspective, it would be worthwhile to log access to the system, so the agency knowswhat outside users have entered the system and where and when. And from a "bigbrother" perspective, the agencys management might want to know how often theagents, who are employees ofthe company, are accessing the system. This would alsobe modeled as an aspect.Following design, there will be much implementation and testing ofthe software inthis phase. As the developer attempts to implement and then test certain features, heor she may fmd some concerns have been modeled inefficiently and may be better - 45 -
  56. 56. designed as aspects. Conversely, the developer may fmd that an aspect that wasmodeled in the design workflow or in the earlier phases does not work well in thesystem. At this point, candidate aspects identified earlier would be created ordropped, and new aspects may emerge.Since the real estate agency modeled in this thesis will not be implemented, we willhave to assume that no aspects were found or deleted in the implementation and testworkflows.5.1.4 Aspects in the Transition PhaseThe basic purpose of the transition phase is to get the software into the hands of theend-users and ensure the system works to their liking, and that the bugs are workedout. There is very little new analysis and design. However, users may belatedlydecide there are new features they need after they get their hands on the beta release[Jacobson99]. For example, the logging aspects designed in the construction phase, ifthey were not in the beta release, are something users might decide they want,because they want to keep track of changes in contracts or the number of timescustomers access the system.In the transition phase, these additional features, if they cross-cut many other featuresof the system, would ideally be modeled as aspects, because the aspects could be - 46-
  57. 57. added without disturbing the basic functionality of the main program. This is one ofthe big advantages of using aspects.In the transition phase, the five workflows are given minimal, if any attention. Mostof the work done by the developer would be in response to user needs. So aspects canbe added at any point in this phase.Since the real estate agency in this example is hypothetical, we have no userfeedback. So no new aspects are added in this phase for that project.5.2 Aspects created in Extreme ProgrammingExtreme Programming appears, at first glance, to be an unstructured approach todeveloping software. But there are procedures that are followed and if theprogramming team follows standard practices, the creation of aspects can still be anorderly process.Extreme Programming builds a system incrementally through a constant process ofimplementing and testing, so aspects can be unveiled anywhere from the initialplanning to the [mal build. The process goes roughly like this: - 47-
  58. 58. • The customer writes a "story" describing a feature of the system. • The programmers determine if the story is doable, or if it has to be split into smaller tasks. • After a number of stories are gathered, the customer sorts the stories in terms of their value. • The programmers select the tasks determined by the stories and begin the iterations to implement them. • Once a section of code is successfully implemented and tested, the refactoring process begins in which programmers look for ways to improve the code.Through this process, there are two points where aspects will emerge. The fIrst iswhen the programmers take the stories and decide on their feasibility. The second,which is very obvious, is the refactoring process, which is designed to clean up codeand solve the problems of code tangling and code scattering addressed by aspect-oriented programming.As the development process begins and the customer hands stories to theprogrammers, the fIrst thing the programmers do is "estimate" the stories - that is,determine how long it will take to implement them [Wake02]. Ifthey dont knowhow to implement them, they "do a spike," which is quick throwaway solution to theproblem that is used to make the estimate [Wake02]. - 48 -
  59. 59. At this point, an aspect-oriented developer should be looking for aspects and willlikely find them.In order to examine how aspects will be found for the real estate agency example inan Extreme Programming development environment, we make the assumption thatthe customers stories would all be contained within the use cases in Appendix A.For example, the two aspects created in the Inception phase of the UP, which all camefrom the list of non-functional requirements, would likely be created from the storiesin the Extreme process. The non-functional requirements would probably besubmitted as simple stories by the customer, as follows: • Online response time for agents should be 10 seconds 90 percent of the time; Online response for external users should be within seven seconds 95 percent of the time. • The system should be able to handle customers with poor Internet connections and recover from a server crash.One difference in extreme programming is that the first aspect might be divided intotwo stories and eventually be programmed as two aspects. - 49-
  60. 60. Moving on to the one aspect created in the UPs Elaboration phase, that securityaspect would also emerge from the stories of the Extreme process. The security aspectensured that once a user entered the system, that user only had access to data andfeatures that were authorized for that type of user (an agent or a customer).That system requirement was not included in the UP use cases. It was an aspect thatthe developer determined would be a necessary feature. So we might assume that thecustomer for the Extreme programmers did not write a story for it. However, whileonly customers write stories for the system, these stories can be derived fromsuggestions by the programmers. And the customer would probably decide that thissecurity feature is a good idea.The logging aspects that were created in the UPs Construction phase might emergein the same way in Extreme Programming. Although those aspects were not specifiedin the use cases (or in the original stories), the programmers might suggest them tothe customer as good ideas that would make good stories.The agent warning aspect from the Construction phase did emerge from the detailedlook at the use cases, and we can assume it would be included in the customer storiesand would be created as an aspect.In the UP example, all aspects emerged as the developers examined the customersrequirements for the system. However, in Extreme Programming, after the - 50-
  61. 61. requirements are implemented, the developers will have a second chance to hunt for aspects during refactoring.Refactoring is a process of re-examining code, after it has been successfullyimplemented and tested, to determine if the code can be streamlined. There areseveral "danger signs" that the programmer might find in finished code, including[Wake02]: • Classes that are too long; • Methods that are too long; • Duplicate code.These danger signs, particularly the duplicate code, can indicate the presence of thecode tangling or code scattering problems which aspect-oriented programming seeksto improve.This is a significant advantage for Extreme Programming as a development process,in terms of aspect-oriented programming. In following the Unified Process, youwould have fewer opportunities to uncover aspects by examining code. Most of theaspects will be created by modeling, rather than in the coding process. Refactoring isa major part of the Extreme process, which ensures that an aspect-orientedprogrammer will have plenty of opportunities to examine code for possiblerestructuring into aspects. - 51 -
  62. 62. However, Extreme Programming has its drawbacks. A major problem could be itslack of documentation. In aspect-oriented programming, the UML models thatdemonstrate relationships between concerns are a very important tool to helpdevelopers use aspects consistently. Extreme Programmers are unlikely to formallyuse the UML to model their system, so it would be difficult for developers tovisualize the concerns and their relationships.5.3 Chapter SummaryIn this chapter, we examined a software application that was developed for a realestate agency as part of a classroom exercise, looking for opportunities to createaspects that cross-cut other features of the system. We identified six aspects: • A performance aspect that monitors system response time; • A recoverability aspect that creates an audit trail to recover transactions in case of a system crash; • A security aspect to ensure that only authorized users have access to certain features; • An agent warning aspect that ensures users have an opportunity to use a real estate agent to assist in their transactions; • A transaction logging aspect that tracks changes in real estate sales deals in progress; and • A user logging aspect that keeps track of users accessing the system. - 52 -
  63. 63. The identification of these aspects demonstrates that aspects can be found at severaldifferent stages of the software development process, in both the Unified Process andExtreme Programming. - 53 -
  64. 64. Chapter 6 MODELING ASPECTS IN THE UNIFIED MODELING LANGUAGEOver the past decade, most of the research into aspect-oriented programming hasbeen focused on developing programming techniques to incorporate aspect-orientedprinciples into the fmal realization of software systems. However, until very recently,little attention was given to how to model aspects in the software developmentprocess. After all, without programming languages that support aspects, there was noreason to consider aspect-oriented development.However, with the advancement of AspectJ and other aspect-oriented programminglanguages, we may be reaching the point where aspects will be incorporated intomajor software projects. The analysis and design of those projects will requiremodeling standards for aspects in the Unified Modeling Language. So within the pastyear, researchers have begun offering proposals for how to model aspects in theUML. As the Object Management Group considers a new release of the UMLstandards, from current version 1.4 to version 2.0, it is also appropriate to proposenew modeling elements that accommodate aspects.This chapter begins by reviewing the proposals that have been made to date. Theproposals are compiled from the proceedings of two workshops that have been held - 54-
  65. 65. this year on the UML for aspects, at the 1st International Conference on Aspect-Oriented Software Development in the Netherlands in April and at the FifthInternational Conference on the Unified Modeling Language in Germany inSeptember.After reviewing and critiquing proposals from those two workshops, this chapter willconclude with a new proposal for modeling aspects in the UML, based on researchabout aspects and the UML.6.1 Aspects and UML Proposals from the Netherlands ConferenceThe Netherlands conference was the first major conference devoted solely to aspect-oriented programming, and it included a workshop dedicated to aspects and the UML.The proposals showed no clear consensus on standards for modeling aspects, butoffered a number of ideas.6.1.1 Aspects as PackagesStephan Herrmann of Technical University of Berlin offered a proposal in whichpackages, rather than classes would be the main design entity [Hermann02]. Usingpackages, with relationships drawn between them to show the relationships betweenaspects and other concerns, allows for separation of concerns and re-usability ofaspects. - 55 -
  66. 66. Hermann also argued that design notations should be language-specific to allowdevelopers "to smoothly move from analysis to implementation." But at this time, noaspect -oriented language has been widely adopted, not even AspectJ. With AspectJbeing the most advanced aspect-oriented language, it is useful to use it as a guide inspecifying UML elements for aspects. However, the UML should also be able toaccommodate other aspect -oriented languages, if needed.6.1.2 Using Extensibility MechanismsA group of French researchers [Ho02] said existing UML mechanisms can be used tomodel separation of concerns, namely through the use of extensibility mechanisms.Stereotypes can be used to label a class as an aspect or with the name of the aspectbeing modeled. Also, constraints and tag values can be used in a non-aspect class todenote join points in the class, where an aspect would be invoked.Obviously, extensions will have to be used when using existing CASE tools to modelaspects in the UML. The extensibility mechanisms are there to allow developers to gobeyond standard designs and model new types of elements. However, thecharacteristics of aspects do not fit neatly into UML stereotypes. For example, someproposals may model an aspect as a stereotype of a UML class, but an aspect does notreally have the characteristics of a class. So ultimately, extensions may not be able toproperly model aspects. - 56 -
  67. 67. Another paper stated that the use of extensibility mechanisms is only a "compromisesolution" in the transition from pure object-oriented development to aspect-orienteddevelopment [Chavez02]. It proposes that AOP should have its own set of modelingelements. Again, it seems reasonable to assume that UML 2.0 should accommodateaspects.6.1.3 Extensions for AspectJThe French group was not the only group to propose the use of extensions.Researchers at the University of Essen, Germany [Stein02A], proposed a system ofusing existing extensibility mechanisms to model the concepts of AspectJ, namelyjoin points, pointcuts and advice.The join points, which are the points in a Java program where aspects are invoked,are modeled using links that can be added to a UML sequence diagramPointcuts, which are specifications in the aspect that indicate where the join points arefrom the aspects view, are represented within the aspect by a stereotype. The aspectsthemselves are modeled as classes with a stereotype indicating that they are aspects.The aspect classes include "crosscut" stereotypes which indicate the Java classes thatare cross-cut by the aspect. The crosscut stereotypes are contained in the operationssection of the aspect classes. - 57 -
  68. 68. The advice, which is the code of the aspect that is executed when a join point isreached, is also indicated by a stereotype within the aspect.The German researchers also propose modeling the aspect weaver through use casemodels, which indicate the order in which java classes and aspects are reached.Some of the other researchers would likely consider this proposal to be too specificto AspectJ. As another paper presented at the workshop [Clarke02] pointed out, "anydesign language that simply mimics the constructs of a particular AOP language islikely to fail to achieve implementation language independence." As previouslystated, since AspectJ, or any other aspect-oriented language, has not been adopted asa standard, the UML notation for aspects should be adaptable for use with otherlanguages, even it is closely modeled after AspectJ.6.1.4 Making Aspects First-Class CitizensResearchers at the Swiss Federal Institute of Technology Lausanne recognized amajor problem of using existing UML elements [Kande02]; the parts of an aspects(such as advice and pointcuts in an AspectJ program) can be spread out amongdifferent diagrams in the model, making it difficult, if not impossible, to distinguishthe aspects from normal Java classes. - 58 -
  69. 69. They proposed treating the aspects as "frrst-class citizens" to clearly distinguish them,which is a sound idea. Unfortunately, their solution makes it somewhat difficult todistinguish aspects from classes. The aspects are modeled in a class diagram usingstereotypes to indicate the aspect is not a Java class. But it looks like a standard Javaclass diagram.Their solution also inserts the aspect as an object in a collaboration diagram, with aspecial "CP" notation to indicate connection points where the join points between theaspects and classes would be. Again, it is difficult to make the distinction betweenthis and a standard collaboration.Another paper [Jezeque102] raised the point that the aspects pointcuts (to use theAspectJ terminology) should have their own separate designation. lfthe pointcuts areincluded with the aspect, it may make it difficult to reuse the aspect.The CEDRIC group in France [Pawlak02C] proposed a simple "pointcut" stereotypeto associate an aspect with a class. Other notations along the association line link theaspect with a particular method in the class. - 59-
  70. 70. 6.1.5 Aspects and StatechartsAnother UML modeling element that could be used for aspects is the statechart, asproposed by researchers at Lucent Technologies. [Aldawud02]. The statechartprovides a view of an object over time as it goes through different states.This proposal has some merit, as the state ofthe object in some cases will trigger theexecution of an aspect. However, the focus of a statechart diagram is on the object,not the aspect, so it may not be the best model for the use of an aspect. As stated in[FowlerOO], "state diagrams are not very good at describing behavior that involves anumber of objects collaborating."6.2 Aspects and UML Proposals from the Germany ConferenceThe papers presented at the AOP conference in the Netherlands revealed a wide rangeof ideas but no consensus on how aspects should be modeled in the UML. The secondmajor workshop on the issue was held on Sept. 30 at the UML conference inGermany. Some of the researchers who submitted papers to the Netherlandsconference also submitted papers at the Sept. 30 workshop, but there were also somenew proposals presented. - 60-
  71. 71. 6.2.1 Aspects in Activity DiagramsTwo Portuguese researchers [Barros02] proposed using activity diagrams as the mainmodeling diagram for aspects. Their model was based on a new type of activitydiagram, which is part of a proposal for new standards for UML 2.0. These activitydiagrams use Petri net-based semantics, which allow activities to have "multipletoken flows" at the same time. The aspects would be modeled as activities, withcertain nodes along the activity path indicating where the aspects merge with the restof the modeLThe drawback to this proposal is that it puts the focus of the interaction betweenaspects and other concerns on the aspect. In other UML schemes, the concerns of thesystem as a whole are the focus of the modeling elements, with aspects added atpoints in diagrams that describe the systems behavior. After all, the aspects areinvoked by the systems components, not the other way around.6.2.2 Modeling Aspects at the Requirements LevelOne determination of how aspects should be modeled is derived from where theaspects are created in the software development process. Developers will have toconsider including aspects in use case diagrams if those aspects are found during therequirements gathering process. - 61 -
  72. 72. One proposal [Araujo02] models aspects found at the requirements level as a specialstereotype use case that is linked to a main use case using a "wrapped-by" stereotype,similar to the way a use case diagram is modeled with "include" or "extend"stereotypes to account for repeatable activities.Unfortunately, the addition of the aspect stereotype to diagrams showing other systemuse cases suggests that the aspect is an extension, or somehow a part of the use case.The main goal of aspect-oriented programming is separation of concerns, so theaspect should be separate.Another proposal in [Araujo02] models aspects in sequence diagrams by simplyadding special identifiers at points in the sequence to reference an event. This is asound proposal on how to model the interaction between aspects and other concerns,while still indicating their separation.6.2.3 Creating New UML Icons for AspectsResearchers at The American University in Cairo [Zakaria02] proposed a very simpleclass diagram to represent the relationship between aspects and other classes. Theycreated a new icon to represent the aspect and another icon for what they referred toas a pointcut, although other researchers would refer to it as a join point (In much ofthe research, in which AspectJ terminology is not used, the terms "pointcuts" and - 62-
  73. 73. "join points" are used interchangeably to indicate the points where aspects cross-cutother concerns).In the class diagram, the aspect and the class are both linked with associations to thepointcut. It is a very simple, yet effective representation.6.2.4 Principles of Aspect-Oriented UML ModelingTwo papers from the Germany conference raised important points that form the basisfor sound principles on how aspects should be modeled in the UML.Researchers from Tel-Aviv University [Sapir02] emphasized the separation of theaspect from other modules of the application under development, or AUD. They statethat: "An aspect is considered to be a separate encapsulated and modular application that crosscuts the AUD. It does not merge into the AUD, nor changes its logic and static structure. The AUD is kept modular, untouched and consistent."The key principle here is that the aspects are completely separated from systemconcerns, other than at the points where the aspects cross-cut them.That leads to the second principle, which was raised by the University of Essenresearchers who had originally presented their proposal on using extensibilitymechanisms to model the concepts of Aspect] at the Netherlands conference. In a - 63 -
  74. 74. follow-up paper presented at the Germany workshop [Stein02C], they emphasized theimportance of identifying join points in an aspect-oriented system. They stated: "It is a primary task for an aspect -oriented modeling language to provide suitable representations for join points."These two principles, separation of concerns and identification of join points (or pointcuts, according to the semantics of the development paradigm) should be the guidingprinciples of aspect-oriented modeling in the Unified Modeling Language.6.3 Proposal for Modeling Aspects in the Unified Modeling LanguageThis proposal for standards for incorporating the modeling of aspects in the UnifiedModeling Language is based on several areas: previous research on aspect-orientedprogramming, previous research on incorporating aspects into the UML, currentUML specifications and the creation of aspects in the software development lifecycle. The proposal assumes that as the Object Management Group considersrevisions to UML specifications as it moves from version 1.4 to version 2.0[OMG02], the updated version will be able to accommodate new elements that maybe needed to properly model aspects.We begin by re-introducing the terminology used in previous research on thestructure of aspect-oriented programming, chiefly the pioneering work of XeroxsPARe group and the standards it set in its 1997 paper [Kiczales97]. - 64-
  75. 75. P ARC broke down elements of a system into two terms: components, whichessentially are system modules, and aspects, which cross-cut the componentsrepeatedly through the system. We will use that terminology in describing theproposal for incorporation of aspects into the UML.The term "join points" is used repeatedly in discussions about AOP, although it canhave different meanings in different contexts. For the purposes of this proposal, joinpoints will refer to connection points where aspects cross-cut components.The proposal will incorporate some of the ideas presented in previous research, asdescribed earlier in this chapter. Most notably, we will use the two guiding principlesoutlined in Section 6.2.4: • Each aspect will be considered as its own encapsulated module separated from the system as a who Ie, and also separated from other aspects; • A key objective in modeling the system will be to detail the join points where aspects cross-cut the components.The use ofUML elements in this proposal will be based on procedures outlined in theObject Management Groups specifications for the current version ofUML, version1.4 [OMG01], and on several UML manuals, including the reference manualpublished by the three UML pioneers, Rumbaugh, Jacobson and Booch[Rumbaugh99] . - 65 -
  76. 76. Finally, the lessons learned in Chapter 5 as we traced the creation of aspects throughthe software development process will be incorporated into this proposal. Some UMLartifacts are closely tied to the stage in the process where the artifacts are created, soit is important to note the stages at which aspects were revealed. That influences theinclusion or exclusion of certain UML elements to the proposal for modeling aspects.6.3.1 Aspect Packages in the UMLIn order to accommodate the separation of aspects and components, we use UMLpackages. Each aspect is encapsulated within its own package, and all thefunctionality of the aspect can be modeled within the package. This should includeclass diagrams and interaction diagrams at a minimum, as well as anything elseneeded to specify the aspects functionality.According to UML specifications [OMG01], the purpose ofa package is to provide agrouping mechanism. It further states that "the package construct can be used fororganizing elements for any purpose; the criteria to use for grouping elementstogether into one package are not defmed within UML."In this case, the purpose of using packages is to separate and encapsulate the aspects. - 66-