ABSTRACT
Evidence is mounting that aspect-oriented programming is useful for (re-)structuring the many concerns that software is designed to address. Many of these concerns often arise in the problem domain, and, therefore, there is a growing effort to examine 'early aspects' - to identify and represent concerns that arise during software requirements engineering and design, and to determine how these concerns interact. But can one seek to identify aspects too early? While identifying concerns during requirements elicitation may indeed be profitable, the notion of crosscutting concerns, indeed of crosscutting requirements, may only make sense when elements of a solution also begin to be explored. There are two consequences of this: a case for more interleaving of the processes of requirements engineering and design, and a case for the explicit development of specifications that map the problem and solution structures. We elaborate and discuss this thesis, and offer an alternative research agenda for aspect-oriented requirements engineering.
- Finkelstein, A. and Sommerville, I., "The Viewpoints FAQ", BCS/IEE Software Engineering Journal, 11 (1): 2-4, January 1996.Google ScholarCross Ref
- Kiczales, G., Lamping, J., Mendhekar, A., Maeda, C., Lopes, C., Loingtier, J-M., and Irwin, J., "aspect-Oriented Programming", In Proceedings of European Conference Object-Oriented Programming, LNCS 1241, Springer, 220--242, 1997. Google ScholarDigital Library
- Nuseibeh, B., Kramer, J., and Finkelstein, A., "A Framework for Expressing the Relationships Between Multiple Views in Requirements Specification", IEEE Transactions on Software Engineering, 20(10): 760--773, October 1994. Google ScholarDigital Library
- Nuseibeh, B., "Weaving Together Requirements and Architectures", IEEE Computer, 34(3):115--117, March 2001. Google ScholarDigital Library
- Parnas, D. L., "On the Criteria to be Used in Decomposing Systems into Modules", Communications of the ACM, 15(12), December 1972. Google ScholarDigital Library
- Polya, G., How to Solve It, Princeton University Press, 1945.Google Scholar
- Tarr, P., Ossher, H., Harrison, W., and Sutton, S., "N Degrees of Separation: Multi-Dimensional Separation of Concerns", In Proceedings of 21st International Conference on Software Engineering (ICSE-99), Los Angeles, USA, May 1999, 107--119, IEEE CS Press. Google ScholarDigital Library
- Tarr, P., Harrison, W., Ossher, H., Finkelstein, A., Nuseibeh, B., and Perry, D.,"Workshop on multi-dimensional separation of concerns in software engineering", In Proceedings of the International Conference on Software Engineering (ICSE-2000), 4-11 June 2000, 809--810, IEEE CS Press. Google ScholarDigital Library
- Rashid, A., Sawyer, P., Moreira, A., and Araujo, J., "Modularisation and Composition of Aspectual Requirements Engineering", In Proceedings of International Conference on Aspect-Oriented Software Development (AOSD '03), Boston, USA, March 2003, 11--20, ACM Press. Google ScholarDigital Library
Recommendations
Revealing Crosscutting Concerns in Textual Requirements Documents: An Exploratory Study with Industry Systems
SBES '12: Proceedings of the 2012 26th Brazilian Symposium on Software EngineeringIt is well-known that effective requirements analysis plays a crucial role in the quality of software systems. However, the scattered and tangled nature of certain system's concerns can hinder the proper understanding and treatment of import ...
Isolating and relating concerns in requirements using latent semantic analysis
Proceedings of the 2006 OOPSLA ConferenceAspect-oriented requirements analysis involves the identification of concerns that behaviorally influence other concerns. Such concerns are described in requirements called emphaspectual requirements: requirements that detail the influence of one ...
An evolutionary model of requirements correctness with early aspects
IWPSE '07: Ninth international workshop on Principles of software evolution: in conjunction with the 6th ESEC/FSE joint meetingThe achievement of building evolvable systems depends on how efficiently the changeable requirements are elicited and structured by software engineers. In current requirements approaches changing requirements are not dealt with satisfactorily. Partially,...
Comments