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.