The Mysterious Case of The Missing Reusable Class Libraries

(File Last Modified Wed, May 29, 2002.)

• Review: The Mysterious Case of The Missing Reusable Class Libraries
• Problem Addressed
• Approach Proposed
• Analysis
• Conclusion
• Comments

Review: The Mysterious Case of The Missing Reusable Class Libraries

Problem Addressed

This paper observed the phenomena that reusable libraries as promised by the literature on Object-oriented mehtods are largely missing from the public domain and are often restricted to either use-interface or collection class libraries. Even in the restricted domains of specific corporations, reusable class libraries are the rare exception rather than the rule. The authors discussed the reasons of the missing case and proposed a solution.

Approach Proposed

Software engineers can educate themselves to create the libraires: ``reuse mind-set'' is possible to pervades the entire development process. Instead of generalising the goal after delivery of the first software, the first application could be a example(specification) of the goal after the generalization process of the development.

Analysis

Severl examples of the process of generalising some design for requirement into a reusable class libraires

• SMARTASK, where the generalized classes tend not to be specialisations or generalisations of the application object, but rather a horizontal collaboration of classes.
• DESCRIBE, where a mark-up language and an interpreter for that language were built, which allowed the alterations of requirements to be maintained by the business users. Again, reusable classes are horizontally associated classes.
• KNOWLEDGE BASES, knowledge base and a separate inference engine for the expert system. It demonstrates that useful support tools for a requirement may not involve generalisation-specialisation of application objects. Rather, they may require the development of elaborate architectures that are not in the original requirements documents.
• STRUCTURE CHARTS, suggests that a standard library for any OO language should be a node-link network editor.
• MODEL-VIEW-CONTROLLER, which implements the concept of dialogue independence, i.e. a clear separation of a program's computational component from its interface.

Organisational factors can encourage or discourage the generalization process. It is more likely to occure in small, skilled, experienced teams working with incremental development tools without serious time and cost constraints being a dominant factor.

Existing OO-methodologies

• lack of concern with reuse.
• concentrate on the notions of inheritance rather than the horizontal links of association and client-server.

Conclusion

Reasons for the missing case are:

• Developers have not structured themselves to create the libraries, they do not think general when they build systems
• Project plans defer object generalisation till after the delivery of the first product.
• The current OOA and OOD tools may not support the development of reusable components since they mostly do not support the discovery and specification of horizontal associations between classes and therefore, no reuse.

Solutions:

• Generalisation should not simply be regarded as an optional add-on, but should pervade the whole development process from the very begining.
• Considerable further research into OO methodologies is required for the development of class libraries to become a reality.

Comments

• This paper is Dr. Tim Menzies's theoretical defense of the DSL approach for better SE. It gives extensive discussion and analysis with examples.
• However, I am a little confused: what does ``horizontal association classes'' mean? Without generalization/specialization, how do we describe ``reuse''?
• DSL seems a ideal approach for the allowance of alteration without program-level maintenance. But, is it always possible to apply this approach in every domain?