Towards Multi Dimensional Methods1 A position paper for OOPSLA2000 Workshop on Advanced Separation of Concerns in Object-oriented Systems.
Juha Savolainen Helsinki University of Technology P.O. Box 9700, FIN-02015 HUT Finland
[email protected] ABSTRACT Recently, new paradigms have emerged to improved standard object-oriented methods. However, most of these lack guidelines for developers on how to design complex real-life systems using these techniques. In this position paper, we investigate proposed methods and reason why they still fail to meet key requirements of the standard design methodology. We also present a few key requirements for such methodology and show potential pitfalls along the way. Keywords Software Architecture, Product Line, Product Family, Subject-oriented Programming, Aspect-oriented Programming, Multidimensional Separation of Concerns
1
INTRODUCTION
Recently new multidimensional paradigms of software development have been proposed by multiple researches.[1,2,3] They are all based on different implementation techniques that allow separating different concerns into more manageable parts than the original system if built using traditional object-oriented methods. Naturally, this technology is needed to being able to derive the actual instances of the system under considerations. However, this implementation focus does not offer enough tools for real-world software developers to cope with the new challenges that emerge with these tools. Especially, there is no generally accepted development methodology for multidimensional software.
2
KEY REQUIREMENTS ON THE METHODOLOGY
For any technique to be truly successful - is has to support development of large software systems that have a large number of developers, often in geographically distributed locations. Systems can be typically very large in size, having millions of lines of code. In this context, any method should provide tools for feature-based development as well as efficient support for creating the family architecture. Also it should allow traceability from the requirements to the different dimensions and also to the code level when appropriate. In the following, we have listed the main requirements on the development methodology as well as the implementation techniques and tools that support them.
1
This paper has been partially done in ESAPS project. ESAPS is project 99005 in ITEA organization a part of Eureka Σ! 2023 program. This work is supported by the Technology Development Fund of Finland. (TEKES)
Thus, following key requirements must be met: • • • • • • • • • •
Allow efficient distribution of total development effor Support work division among different organizational structures Help managing inherent complexity Support communicating the main design decisions to the all developers Allow encapsulations and information hiding Directly use feature modelling Be compatible to the main domain analysis methods Help designing software architectures Allow specifying quality attributes and key architectural drivers Provide full traceability support
There are current methods that focus on the system development with aspect-oriented techniques. FeatureRSEB for aspect-oriented product line development proposes a simple method for developing systems with different concerns in mind.[4] This simply suggest using results from the traditional feature-based domain analysis as a basis on which aspect-oriented techniques are used. Unfortunately, the method does not provide any guidance for creating the product line architecture. In this context, we need clear definitions of main quality attributes, which drive the architecture – feature variations and their mappings to the aspect implementations are not enough. Another functionality-oriented product line development technique – the building block method has also adopted aspect design practises. [5,6] Building block method identifies three different design dimensions – these object, process and aspect dimensions form the whole design space. Here the main idea is to assign different aspects to different components, for example an aspect of an access control protocols. Then identifying these aspects explicitly helps designing and maintaining evolving systems. However, most non trivial applications have very complex feature interactions and may have variations also in the aspects they need or provide, therefore making this kind of approach difficult to use. Another closely related approach for relating components and the aspect on which they contribute is presented by John Grundy.[7] He presents a simple method to identify requirements on the system, finding out main aspects and then relating these aspects to different components that are used to implement the system. The method provides and easy way to maintain traces and it may be also used during design to take care that all important aspects are taken care of. This method is mostly limited to just relating aspects and components and therefore suffers from the same drawbacks as the building block method. We have also earlier proposed simple techniques to experiment with aspect-oriented techniques using currently available tools.[8] In addition our method for product line requirements engineering [9] has been extended to better support multidimensional development efforts. Unfortunately none of these methods can fulfil all the main requirements of an effective multidimensional, aspect-oriented, product line development method.
3
CONCLUSIONS
Recently there have been increasing interest to aspect-oriented techniques, methods and process that support them. Unfortunately, none of current methods provide enough support for real-life development projects. In this paper, we presented a very limited survey of a few methods, listed some requirements on the development methodology that could be used with the new techniques such as multidimensional separation of concerns. Much more research is needed to fully understand forces that affect this kind of development process.
6
REFERENCES
[1] W. Harrison, H. Ossher, Subject-Oriented Programming (A Critique of Pure Objects). Proceedings of the Conference on Object-Oriented Programming: Systems, Languages, and Applications (OOPSLA’93), ACM Press, 1993, pp.411-428. [2] G. Kiczales, J. Lamping, A. Mendhekar, C. Maeda, C. Lopes, J. Irwin, Aspect-oriented programming. Proceedings of 11th European Conference of Object-Oriented Programming (ECOOP’97), Lecture Notes in Computer Science, Springer-Verlag,1997, pp.220-242. [3] P. Tarr, H. Ossher, W. Harrision, S. Sutton, N Degrees of Separation: MultiDimensional Separation of Concerns, Proceedings of the Conference on Object-Oriented Programming: Systems, Languages, and Applications (OOPSLA’99), ACM Press, 1999, pp.235-250. [4] M. Griss, Implementing Product-Line Features by Composing Aspects, In Software Product Lines, P. Donohoe (Ed.), Kluwer Academic Publishers, 2000, pp. 271-288. [5] F. van der Linden, J. Muller, Creating Architectures with Building Blocks, IEEE Software, November, 1995. [6] J. Muller, Aspect Design with the Building Block Method, In Software Architecture, P. Donohoe (Ed.), Kluwer Academic Publishers, 1999, pp. 585-601. [7] J. Grundy, Aspect-oriented Requirements Engineering for Component-based Software Systems, Proceedings of the Conference on Requirements Engineering (RE’99), IEEE, 1999. [8] J. Savolainen, J. Kuusela, Managing Variance in Product Lines, in OOPSLA98 Workshop on Object technology and Product Lines [9] J. Kuusela, J. Savolainen, Requirements Engineering for Product Lines, in proceedings of ICSE 2000, IEEE, 2000.
