|
 Design
and software reuse leads to an effective approach through which
a large segment of a software system can be leveraged from reusable
components, writes Dr R Srinivasan
One
of the important requisites being advocated today in software development
organisations is to adopt the principle of software ‘reuse’.
The methodology of object-oriented programming was brought in with
the very idea of implementing object reuse in future developments.
However, due to certain deficiencies, it could not materialise until
the basic idea of component-based development sprung up. In principle,
software reuse demands the idea of bringing out a library or repository
of reusable components so that anybody needing the same components
need not spend his/her time in developing the codes and thereby
improving the productivity in software development.
In
a similar manner, it is also possible to implement a well-documented
design reuse. It is well known that design segment of any typical
software development life-cycle will include the architecture (discussed
in an earlier article), and also the design and integration of different
applications to realise the ultimate system. In today’s parlance
transactions through Internet involves integration of multiple applications
across the network on a horizontal platform employing the middleware
architecture. It is in this scenario that the concept of component
reuse is very important in the sense that both the horizontal system
and the vertical applications can deploy reusable components. By
this method, design reuse will also support software reuse of the
horizontal components without additional development for integration.
The motto is: design reuse and software reuse will lead to an effective
approach in that a larger segment of a software system can be leveraged
from reusable components.
Of
course, it is very convincing to read about the concept of reuse:
however the question is whether it is really happening and if so
to what extent? Reuse is very rare in most organisations. Goldberg,
et al in their book on, Succeeding with Objects: Decision Frameworks
for Project Management, claim that out of 32 projects studied by
them none had an evidence of deploying successful reuse. Unfortunately
even the people at the top managerial level in certain organisations
advocate building a custom software system for a customer from scratch
and it ends up with the developers bringing out a system in isolation.
Such systems assume the so-called ‘Greenfield’ development
where the system will have stove pipe architecture having all the
associate problems of interoperability, future expansion and reuse.
Such systems will have more problems when they need to be integrated
with legacy systems whereas good developments employing design reuse
and software reuse easily adapt to the situation in integration
with such systems. As mentioned by William Brown, ‘Greenfield
Assumptions’ also ignore significant reusable software assets
in the form of Internet freeware.
As
mentioned, many organisations do not follow design reuse and software
reuse and end up with the antipattern called ‘Reinvent the
Wheel’. Typical causes of these are: the process assumes Greenfield
development, lack of management in enterprise wide application integration
(EAI), leading to unique and isolated design of application interfaces,
inadequate experience in architecture-based development involving
architecture mining and domain knowledge of the applications and
lack of proper project management leading to insufficient communication
at time of design and development. The refactored solution for this
antipattern is to follow ‘architecture farming’ which
depicts requirements-driven architecture. The design team should
take cognisance of precursor design, which is normally available
for many applications and problems in the form of legacy systems,
standards, design patterns, etc. Lot of man-hours have already been
spent in the design aspects of many applications.
Many
design experts mention that very valuable information is buried
in these designs, the benefits of which have already been made use
of by earlier architects, through architecture mining, to build
useful and challenging systems. In order to achieve architecture
mining, it is absolutely essential to determine the methods and
appropriate technology, which are relevant to the design problem.
Quite naturally mining means literature survey, discussions with
experts and consultants and search through the Internet.
(To
be continued) (The author is Chief Technology Officer, iCMG, Bangalore.
He can be contacted at r.srinivasan@icmg.nu)
|
