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's 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 inmost 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 customer from scratch and it ends up with the developers bringing out a system inisolation. Such systems assume the so-called 'Greenfield' development where the systemwill 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, Internet Component Management Group, Bangalore and can be contacted at: r.srinivasan@iCMGworld.com)