Shubhanan Bakre
ABSTRACT
Introduction of aspects into the system raises the level of separation of concerns within the system. At the same time it also raises the level of interactions among the various components and features within the system. Current modeling techniques(sequence diagrams, live sequence charts) are inadequate in handling this added level of interaction. A higher level of abstraction is needed in order to capture the interactions among aspects/features/core and provides two immediate benefits - better modularization of the requirements, and better adaptability for the resulting model. We propose the Aspect Interaction Charts (AIC) that build on top of the Live Sequence Charts (LSC) [3] in order to capture the interactions among various aspects at joinpoints. With the AIC we foresee the ability to capture aspect interactions at a joinpoint in a common specification in the form of use-case scenarios, and the ability to execute these scenarios while non-invasively manipulating the interactions among the various aspects. In addition to the aforementioned benefits, we plan on leveraging the tools that come with the LSC language, i.e. the Play Engine. The AIC would provide us with the ability to model, view and manipulate aspect interactions at joinpoints.
- Aspect J. http://www.eclipse.org/aspectj, 2002.Google Scholar
- Remi Douence, Pascal Fradet, and Mario Sudholt. A framework for the detection and resolution of aspect interactions. In Proceedings of the ACM SIGPLAN/SIGSOFT Conference on Generative Programming and Component Engineering. Springer-Verlag, Lecture Notes in Computer Science 2487, 2002. Google ScholarDigital Library
- D. Harel and R. Marelly. Come, Let's Play: Scenario-Based Programming Using LSC's and the Play-Engine. Springer-Verlag, 2003. Google ScholarDigital Library
- David Harel and Rami Marelly. Specifying and executing behavioral requirements: the play-in/play-out approach. Software and System Modeling, 2(2):82--107, 2003.Google ScholarDigital Library
- Shmuel Katz and Joseph Gil. Aspects and superimpositions. In ECOOP Workshops, pages 308--309, 1999. Google ScholarDigital Library
- G. Kiczales, J. Lamping, A. Mendhekar, C. Maeda, C. V. Lopes, J. Loingtier, and J. Irwin. Aspect-oriented programming. In proceedings of the European Conference on Object-Oriented Programming (ECOOP), Finland., Springer-Verlag LNCS 1241, June 1997.Google ScholarCross Ref
- M. Monga, F. Beltagui, and L. Blair. Investigating feature interactions by exploiting aspect oriented programming, 2002.Google Scholar
- Y. R. Reddy, Sudipto Ghosh, Robert B. France, Greg Straw, James M. Bieman, N. McEachen, Eunjee Song, and Geri Georg. Directives for composing aspect-oriented design class models. pages 75--105, 2006. Google ScholarDigital Library
- M. Sihman and S. Katz. Superimpositions and aspect-oriented programming. The Computer Journal, 46(5):529-541, September 2003.Google ScholarCross Ref
- SpringAOP. http://www.springframework.org, 2007.Google Scholar
Index Terms
- Scenario based resolution of aspect interactions with aspect interaction charts
Recommendations
Aspect interaction chart - a UML approach for modularizing aspect interaction conflicts
SAC '13: Proceedings of the 28th Annual ACM Symposium on Applied ComputingCrosscutting concerns exist well before the implementation phase of software development life cycle (SDLC). Aspects modularize these crosscutting concerns. However, introduction of aspects within a system may bring along issues related to unanticipated ...
Interaction awareness for aspect refactoring
AOAsia '13: Proceedings of the 8th international workshop on Advanced modularization techniquesAspect Refactoring includes two phases: aspect mining and aspect extraction. Aspect mining is used to identify crosscutting concerns from the OO program. Aspect extraction extracts the identified crosscutting concerns from the OO program and refactors ...
Verifying scenario-based aspect specifications
FM'05: Proceedings of the 2005 international conference on Formal MethodsSoftware systems specifications are often described as a set of typical scenarios. Some of the desired scenarios are crosscut by other requirements, called aspects, also naturally described as scenarios. Aspect descriptions are independent of the ...
Comments