Multiple concerns in aspect-oriented language design: a language engineering approach to balancing benefits, with examples

ABSTRACT

Some in the aspect-oriented community view a programming language as aspect-oriented only if it allows programmers to perfectly eliminate scattering and tangling. That is, languages that do not allow programmers to have maximal quantification and perfect obliviousness are not viewed as aspect-oriented. On the other hand, some detractors of aspect-oriented software development view maximal quantification and perfect obliviousness as causing problems, such as difficulties in reasoning or maintenance.

Both views ignore good language design and engineering practice, which suggests trying to simultaneously optimize for several goals. That is, designers of aspect-oriented languages that are intended for wide use should be prepared to compromise quantification and obliviousness to some (small) extent, if doing so helps programmers solve other problems. Indeed, balancing competing requirements is an essential part of engineering. Simultaneously optimizing for several language design goals becomes possible when one views these goals, such as minimizing scattering and tangling, not as all-or-nothing predicates, but as measures on a continuous scale. Since most language design goals will only be partially met, it seems best to call them "concerns."

REFERENCES

• 1: J. Aldrich. Open modules: Modular reasoning about advice. In A. P. Black, editor, ECOOP 2005 -- Object-Oriented Programming 19th European Conference, Glasgow, UK, volume 3586 of Lecture Notes in Computer Science, pages 144--168. Springer-Verlag, Berlin, July 2005.
• 2: AspectJ Team. The AspectJ programming guide. Version 1.5.3., Available from http://eclipse.org/aspectj, 2006.
• 3: Lodewijk Bergmans , Mehmet Aksit, Composing crosscutting concerns using composition filters, Communications of the ACM, v.44 n.10, p.51-57, Oct. 2001 [doi>10.1145/383845.383857]
• 4: L. Bergmans and M. Aksit. Principles and design rationale of Composition Filters. In R. Filman, T. Elrad, S. Clarke, and M. Aksit, editors, Aspect-Oriented Software Development. Addison-Wesley, 2004.
• 5: C. Clifton. A design discipline and language features for modular reasoning in aspect-oriented programs. Technical Report 05--15, Department of Computer Science, Iowa State University, 226 Atanasoff Hall, Ames, Iowa 50011, July 2005.
• 6: C. Clifton and G. T. Leavens. Observers and assistants: A proposal for modular aspect-oriented reasoning. In G. T. Leavens and R. Cytron, editors, FOAL 2002 Proceedings: Foundations of Aspect-Oriented Languages Workshop at AOSD 2002, number 02--06 in Technical Reports, pages 33--44. Department of Computer Science, Iowa State University, Apr. 2002.
• 7: C. Clifton and G. T. Leavens. Spectators and assistants: Enabling modular aspect-oriented reasoning. Technical Report 02--10, Iowa State University, Department of Computer Science, Oct. 2002.
• 8: C. Clifton and G. T. Leavens. A design discipline and language features for formal modular reasoning in aspect-oriented programs. Technical Report 05-23, Dept. of Computer Science, Iowa State University, Ames, IA, 50011, Jan. 2005.
• 9: C. Clifton, G. T. Leavens, and J. Noble. Ownership and effects for more effective reasoning about aspects. Technical Report 06--35, Dept. of Computer Science, Iowa State University, Ames, IA, 50011, Dec. 2006. To appear in ECOOP 2007.
• 10: Edsger W. Dijkstra, Letters to the editor: go to statement considered harmful, Communications of the ACM, v.11 n.3, p.147-148, March 1968 [doi>10.1145/362929.362947]
• 11: R. E. Filman and D. P. Friedman. Aspect-oriented programming is quantification and obliviousness. In OOPSLA 2000 Workshop on Advanced Separation of Concerns, Minneapolis, MN, Oct. 2000.
• 12: R. E. Filman and D. P. Friedman. Aspect-oriented programming is quantification and obliviousness. In M. Akşit, S. Clarke, T. Elrad, and R. E. Filman, editors, Aspect-Oriented Software Development. Addison-Wesley, Reading, MA, 2004.
• 13: R. E. Filman and K. Havelund. The effect of AOP on software engineering, with particular attention to OIF and event quantification. In SPLAT '03, Mar. 2003. http://tinyurl.com/2euk95.
• 14: Lawrence Flon, On research in structured programming, ACM SIGPLAN Notices, v.10 n.10, October 1975 [doi>10.1145/987253.987256]
• 15: John B. Goodenough, Exception handling: issues and a proposed notation, Communications of the ACM, v.18 n.12, p.683-696, Dec. 1975 [doi>10.1145/361227.361230]
• 16: William G. Griswold , Kevin Sullivan , Yuanyuan Song , Macneil Shonle , Nishit Tewari , Yuanfang Cai , Hridesh Rajan, Modular Software Design with Crosscutting Interfaces, IEEE Software, v.23 n.1, p.51-60, January 2006 [doi>10.1109/MS.2006.24]
• 17: S. Gudmundson and G. Kiczales. Addressing practical software development issues in AspectJ with a pointcut interface. In ECOOP 2001 Workshop on Advanced Separation of Concerns, 2001.
• 18: Gregor Kiczales , Erik Hilsdale , Jim Hugunin , Mik Kersten , Jeffrey Palm , William G. Griswold, An Overview of AspectJ, Proceedings of the 15th European Conference on Object-Oriented Programming, p.327-353, June 18-22, 2001
• 19: Gregor Kiczales , Mira Mezini, Aspect-oriented programming and modular reasoning, Proceedings of the 27th international conference on Software engineering, May 15-21, 2005, St. Louis, MO, USA [doi>10.1145/1062455.1062482]
• 20: Donald E. Knuth, Structured Programming with go to Statements, ACM Computing Surveys (CSUR), v.6 n.4, p.261-301, Dec. 1974 [doi>10.1145/356635.356640]
• 21: R. Laddad. AspectJ in Action. Manning Publications Co., Grennwich, Conn., 2003.
• 22: D. Larochelle, K. Scheidt, K. Sullivan, Y. Wei, J. Winstead, and A. Wood. Join point encapsulation. In SPLAT '03, Mar. 2003. http://tinyur1.com/26on14.
• 23: B. H. Liskov and A. Snyder. Exception handling in CLU. IEEE Transactions on Software Engineering, SE-5(6):546--558, Nov. 1979.
• 24: R. E. Lopez-Herrejon and D. Batory. Improving incremental development in AspectJ by bounding quantification. In SPLAT '05, Mar. 2005. http://tinyurl.com/25shp3.
• 25: R. Milner. A theory of type polymorphism in programming. J. Comput. Syst. Sci., 17(3):348--375, Dec. 1978.
• 26: H. Ossher. Confirmed join points. In SPLAT '05, Mar. 2005. http://tinyurl.com/2xzffu.
• 27: Guy L. Steele, Jr., Building interpreters by composing monads, Proceedings of the 21st ACM SIGPLAN-SIGACT symposium on Principles of programming languages, p.472-492, January 16-19, 1994, Portland, Oregon, United States [doi>10.1145/174675.178068]
• 28: Friedrich Steimann, The paradoxical success of aspect-oriented programming, Proceedings of the 21st annual ACM SIGPLAN conference on Object-oriented programming systems, languages, and applications, October 22-26, 2006, Portland, Oregon, USA
• 29: Kevin Sullivan , William G. Griswold , Yuanyuan Song , Yuanfang Cai , Macneil Shonle , Nishit Tewari , Hridesh Rajan, Information hiding interfaces for aspect-oriented design, Proceedings of the 10th European software engineering conference held jointly with 13th ACM SIGSOFT international symposium on Foundations of software engineering, September 05-09, 2005, Lisbon, Portugal
• 30: Peri Tarr , Harold Ossher , William Harrison , Stanley M. Sutton, Jr., N degrees of separation: multi-dimensional separation of concerns, Proceedings of the 21st international conference on Software engineering, p.107-119, May 16-22, 1999, Los Angeles, California, United States [doi>10.1145/302405.302457]

INDEX TERMS

Primary Classification:
  D. Software
  D.1 PROGRAMMING TECHNIQUES
      D.1.m Miscellaneous

Additional Classification:
  D. Software
  D.2 SOFTWARE ENGINEERING
      D.2.2 Design Tools and Techniques
  D.3 PROGRAMMING LANGUAGES
      D.3.3 Language Constructs and Features
          Subjects: Control structures; Modules, packages; Procedures, functions, and subroutines

General Terms:
Design, Languages

Keywords:
aspect-oriented programming language design, balance, compromise, concerns, ease of maintenance, ease of reasoning, goals, obliviousness, quantification, scattering, tangling, tradeoff