Are Domains Really Cost Effective?
Julio Cesar Sampaio do Prado Leite
Departamento de Informática , PUC- Rio
R. Marquês de São Vincente 225
22453-900 - Rio de Janeiro, Brasil
julio@inf.puc-rio.br
http://www.inf.puc-rio.br/~julio
Abstract
The idea of domain oriented reuse is quite old by now, but nonetheless it seems to be rediscovered again and again. Why is it still being rediscovered by many reuse initiatives? I will argue that most of the problem is really a lack of real understanding of where to focus the attention allied with a naive view of modeling. Reuse is a discipline that is orthogonal to software engineering and has received different treatments from practitioners as well as from software scientists. Based on the very nature of the predominant technical perspective, in general, the reuse solutions are driven by a major focus on product representation. I will argue that this bias is the major roadblock to really advance the use of domain orientation. On the other hand, I will argue that despite all the positive evidence, it is not possible to answer the question suggested by the title.
Keywords: Domain oriented reuse, object orientation, classification, Draco paradigm, Draco-PUC, SAP/R3, patterns, frameworks
1 Background
My work on software reuse has been framed by previous work developed in the early 80's at UC, Irvine under the direction of Peter A. Freeman and based on the Draco paradigm idea proposed by Jim Neighbors [Neighbors 84]. Neighbors' idea is that to be effective, reuse has to be performed at a high level of abstraction, that is, at the domain level. Domain is understood as a general theory for a class of problems for which a domain language has to be built. Neighbors invented a software machine, Draco, that made possible the automatic generation of systems once the syntax and semantics of a domain language was described. At PUC-Rio I have been directing a research project [Leite 94] geared at the construction of an infrastructure for making possible the usage of the Draco paradigm. On the other hand, I also have been involved in software engineering in general and in particular in reverse engineering and requirements engineering. My contention is that although several do agree that domain orientation is key to the reuse problem there is a bias on the community that upholds the general usage of this belief.
2 Position
Reuse solutions are driven by a major focus on product representation. I argue that this bias is the major roadblock to really advance the use of domain orientation. On the other hand, I will argue that despite all the positive evidence, it is not possible to answer the question suggested by the title.
3 Argument
Software reuse occurs if certain pre-conditions [Kruger, 92] are fulfilled. These pre-conditions are: the reuser has to have defined what is to be reused, the object of reuse has to be stored in a proper place, the object of reuse has to be built for reuse, the actors in the development process are aware of the advantage of reuse and there should have mechanisms for finding the object to be reused. This general view of reuse is well accepted by the community. As such, several problems do appear related to each of these pre-conditions. Even though several have already seem that reuse is not just a technical problem [Griss 94] [Hollenbach 96], most of the work performed on software reuse has been geared towards representation aspects, and most of them dealing with specifications or their implementation. So, lots have been written on how to store components, how to represent them and how to modify them. Although we had important progress, it seems that little effort was performed at the heart of the matter. Let me address this by posing the following questions.
What is the reason for the success of such products like Visual Basic, Power Builder, and Access?
Why is R3 from SAP a tremendous success in the information technology industry?
Why Visual Basic made object-oriented gurus rethink the major argument for using OO languages?
Why are patterns and frameworks such a success in the object-oriented arena?
I content that products like Access and Visual Basic are typical examples of infrastructures that successfully embodied the concept of domain reuse. Access does a reasonable job regarding simple database management and Visual Basic did embody the basic knowledge of screen oriented human-computer interaction. I believe that the popularity of these infrastructures is exactly because they successfully embodied knowledge that the market was willing to reuse.
Why is SAP listed as one of the major players of the IT business if ten years ago very few people knew about them? I content that domain reuse is the key aspect in SAP's success. They managed to encapsulate business knowledge in a parameterized software framework.
On the other hand, in the mid 90's [Griss 94] [Udell 94] software engineers discover, that despite the fact that object-oriented languages did provide class abstraction mechanisms, they were not as much successful as the component based model such as Visual Basic VBX in achieving reuse. Component oriented reuse is linear, it does not have to deal with aspects of classification and generalization, so it is easy to build and latter to reuse. Projects that tried to use a class oriented reuse were always discovering new possible sub-classes or discovering that the class was not really the best abstraction, so lots of rework have to be performed. The conclusion in these cases always point to the fact that the domain was not well understood beforehand. As we argued before, there is a continuous rediscovery of the necessity of domain oriented reuse.
Nowadays the trend is frameworks, patterns and architectures [Gamma 95] [Shaw 96]. Lots of people talk about it, some are using and others are finding difficult to understand what is it. No doubt that these concepts do help reuse and provide some basic principles to design, but they are still focusing on the representation aspect, that is they are still oriented towards the software engineering domain. By the same token the efforts on interoperable objects do also contribute to the infrastructure for making reuse possible, but, again, the effort is at the implementation level.
Despite the success of SAP and of specific software products, like the ones mentioned above, it is clear to me that yet most of software reuse research and practice is still geared to aspects of specification/implementation and very few are effectively using the idea of domain oriented reuse. There is also a little bit of confusion of what really is a domain and what exactly is to reuse a domain. Domain reuse is not the reuse of informal diagrams or the reuse of a general taxonomy. Effective domain reuse implies the reuse of executable components that implement the concepts of the domain [Neighbors 94]. So, we must be aware that the use of domain analysis methods [Arango 94] not necessarily implies domain-oriented reuse. In reality, several projects have used domain analysis methods as a replacement for traditional systems analysis specification methods. Building domains, requires a large body of knowledge gathered through years of experience and backed by a well defined process, where the focal point is classification [Prieto-Diaz 87] and has an enormous cost. I argue that the efforts in research, with few exceptions [Arango 89], [Sutcliffe 94], are not addressing the heart of the problem, which is building taxonomies.
4 Conclusion
Although it seems that building domains will pay on the longer term, as per SAP, we, from the viewpoint of software reuse research, are not able to answer if domains are cost effective. We are not able to answer return on investment questions regarding domains, despite the several existing proposals [Lim 96] [Favaro 96], which in most cases address mainly the component part and not the taxonomy part. I understand that these ROI models do not address the heart of the problem because, as said before, we do not know much about the processes of building domains, we do not have data about these processes and we do not know how to integrate these processes with the infrastructure that is available.
As such, I believe that software reuse research has to invest on processes for building domains using the new type of infrastructure that is coming out of the laboratories [Aitken 98] [Batory 96] [Sant'Anna 98]. We need to research on process description languages a là Plop, to invest on process description and to conduct experiments to tie these processes with recent technology, in order to reduce the time to build domains. There is a long way to go and lots of work to be done until we reach a point where we could say more about domain reuse.
References
[Aitken 98] Aitken, W, Dickens, B., Kwiatkowski, P., Moor, O., Ricther, D., Simonyi, C. Transformation in Intentional Programming In Proceedings of the Fifth International Conference on Software Reuse, IEEE Computer Society Press, Los Alamitos, CA, 1998.
[Arango 89] Arango, G. Domain Analysis: From Art Form to Engineering Discipline. In Proc. 5th International Workshop on Software Specification and Design, IEEE Computer Society Press, pp. 152-159, 1989.
[Arango 94] Arango, G. Domain analysis methods. In Software Reusability, Schafer, Prieto-Diaz and Matsumoto (ed.), Ellis Horwood Workshops, UK., pp. 17-49, 1994.
[Batory 96] Batory, D. Subjectivity and GenVoca Generators. In Proceedings of the Fourth International Conference on Software Reuse, IEEE Computer Society Press, Los Alamitos, CA, 1998, pp. 166-175.
[Favaro 96] Favaro, J. A Comparison of Approaches to Reuse Investment Analysis. In Proceedings of the Fourth International Conference on Software Reuse, IEEE Computer Society Press, Los Alamitos, CA, 1996, pp. 136-145.
[Gamma 95] Gamma, E., Helm, R., Johnson, e Vlissides, J. Design Patterns: Elements of Reusable Object-Oriented Design, Addison-Wesley, 1995.
[Gries 94] Gries, M.L., Favaro, J. and Walton, P. Managerial and organizational issues - starting and running a software reuse program. In Software Reusability, Schafer, Prieto-Diaz and Matsumoto (ed.), Ellis Horwood Workshops, UK., pp. 51-78, 1994.
[Gries 94] Gries, M.L., Kozaczynski, W., Wasserman, A.I., Jette, C. and Troy, R. Panel: Object-Oriented Reuseand organizational issues - starting and running a software reuse program. In Proceedings of the Third International Conference on Software Reuse, IEEE Computer Society Press, Los Alamitos, CA, 1994, pp. 209-213
[Hollenbach 96] Hollenback,C. and Frakes, W. Software Process Reuse in an Industrial Setting. In Proceedings of the Fourth International Conference on Software Reuse, IEEE Computer Society Press, Los Alamitos, CA, 1996, pp. 22-30.
[Kruger 92] Krueger, C. W., Software Reuse, ACM Computing Surveys, Vol. 24, N. 2, Jun. 1992, pp. 131-184.
[Leite 94] Leite, J.C.S.P., SantíAnna M., Freitas, F.G. Draco-PUC: a Technology Assembly for Domain Oriented Software Development, In Proceedings of the Third International Conference on Software Reuse, IEEE Computer Society Press, Los Alamitos, CA, 1994, pp. 94-100.
[Lim 96] Lim, W.C. Reuse Economics: A Comparison of Seventeen Models and Directions for Future Research. In Proceedings of the Fourth International Conference on Software Reuse, IEEE Computer Society Press, Los Alamitos, CA, 1996, pp. 41-51.
[Neighbors 84] Jim Neighbors, The Draco Approach to Constructing Software form Reusable Components, IEEE Trans. on Soft. Eng., SE-10, Sep. 1984, pp. 564-573.
[Prieto-Diaz 87] Prieto-Diaz, R. e Freeman, P.. Classifying software for reusability, IEEE Software, 4, 1, Jan. 1987, pp. 6-16.
[San'Anna 98] Sant'Anna, M., Leite, J.C.S.P., Prado, A.F. A Generative Approach to Componetware. International Workshop on Component-Based Software Engineering, 1998.
[Shaw 96] Shaw,M. e Garlan, D. Software Architecture: Perspectives of an Emerging Discipline, Prentice Hall, Upper Saddle, New Jersey, 1996.
[Sutcliffe 94] Sutcliffe,A.G. and Maiden N.A.M. Domain Modeling for Reuse. In Proceedings of the Third International Conference on Software Reuse, IEEE Computer Society Press, Los Alamitos, CA, 1994, pp. 169-177.
[Udell 94] Udell, J. "Component Software". Byte, Vol. 19. N. 5, pp. 46-55, 1994.