Designing Software for Reuse
By admin In Tech Facts On December 10, 2014
FABNexus – The benefits of reusable software components have been understood by software development specialists for decades. An on-line search will locate numerous publications that elaborate on this topic (see Schmidt for example). The potential benefits of software reuse are similar to those realized by the electronics industry, where electronic component manufacturers design, build, and sale carefully documented standard electronic component devices. Off-the-shelf hardware components enable circuit designers to rapidly create new electronic systems in a highly predictable fashion. Electronic design would be more riskier and difficult without use of proven and precisely documented electronic components.
The hope is that software designers will someday construct new software systems by selecting and interconnecting an appropriate set of high-value meticulously crafted and precisely specified off-the-shelf software components, equivalent to how electronic PCB or chip designers operate. Use of existing software components will reduce effort and risk, permitting engineers to fabricate new software systems by ‘stitching together’ reliable high-density drop-in components. Each new software design will require creation of custom ‘glue’ code to interconnect and integrate the chosen collection of off-the-shelf software components, but will require significantly less new source code than is required for today’s software systems. Similar to electronics, constructing software from well specified components will lead to availability of computer aided software design and development tools. An early example is the National Instruments LabView programming environment.
In the 1980′s there was an intensive effort to improve software engineering practices and promote greater software reuse, led by the US and Western European academic and aerospace/defense communities. At that time legacy and in-development defense software systems were experiencing sky-rocketing procurement and maintenance costs. The objective was to improve matters by incorporating state-of-the-art advances in software engineering, including support of software reuse, while developing a standard programming language for future military procurement. This led to the development of the standard ISO/IEC 8652:2012 ADA programming language. This was the first and arguably remains the best and most advanced programming environment to support and promote software reuse across multiple platforms. Unfortunately due to its sophisticated compilers and up-front design orientation it’s gained little interest outside the aerospace, defense and a few other large mission, safety, and security critical industries.
In the mid and late 1980′s upstart software and hardware tools vendor Rational Software was an at the forefront of reusable software engineering design technology, initially with ADA and later with C++ and Java. One of their founding principals, Grady Booch, authored a book entitled Software Components with ADA which was accompanied by a library of reusable ADA software components, the first of its kind. Grady is most recognized as one of the creators of the Unified Modeling Language (aka UML) software design notation.
In the early 1990′s a group of four software researchers, Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, published what became a seminal book regarding modern software reuse entitled Design Patterns: Elements of Reusable Object-Oriented Software. Their book explored among other things how one identifies patterns of software that should be reused, which remains a very challenging skill to master. It also presented an elementary example of how one might categorize a collection of reusable components.
It’s commonplace for operating systems and programming language environments to be bundled with documented off-the-shelf libraries that offer a wide assortment of built-in reusable utility functions, classes, and stand-alone utility applications, but most businesses have shown little or no interest in developing nor in purchasing reusable software components. There are numerous factors contributing to this situation, including
- The advent and growth of open source software, and the transformation of the software industry away from a ‘for purchase’ software model has reduced commercial incentive.
- The explosion in the number of new programming languages being used, including web-programming technologies, creates significant technical barriers to reuse.
- A lack of standards for software component interfaces and component documentation.
- A lack of standards for rating a component’s reliability and performance efficiency.
- Concerns of copyright, licensing, or software patent litigation.
While a discernible marketplace of off-the-shelf software components hasn’t evolved, some industries have found in-house reuse to be attractive, especially those engaged in aerospace, defense, finance, and similar high-end industries. These industries recognize and capitalize on the clear technical and financial benefits in this approach.
Organizations outside those domains mentioned above typically don’t attempt reusable software designs, or else have limited success when attempting to do so. There are numerous reasons for this limited success, including:
- Pressures of delivery schedules and budgets related to the organization’s business,
- Lack of technical expertise in producing reusable software modules.
- Reuse limitations resulting from differences and incompatibilities among commonly used programming environments, and even differences in versions of the same programming environments over time.
- Neglect in performing upfront design analysis as it relates to reusable software interfaces, and failure to generate detailed software design documentation.
Unfortunately many organizations involved in serial software development projects don’t budget time or resources to this end, even though well designed domain-specific software components have been shown to provide trusted reliable software that reduces future project development time and cost.
To be continued.
Leave a comment