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.

Key-Words: Domain oriented reuse, object orientation, classification, Draco paradigm, Draco-PUC, SAP/R3, patterns, frameworks

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's 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 content 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.

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.

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 few 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 encapsulated 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.
 
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.