Trends in Reuse

When you build a model of some aspect of a system, you immediately make those aspects visible; as soon as you make them visible, they become potentially reusable. Research and experience have provided many models for defining various aspects of requirements. For example, at the beginning of a project you can make a system visible by drawing a context diagram to model the intended context of the work. You can partition the subject matter into business events, use cases, and classes, each of which you can model. The choice of which models you use is not important; what is important is that you and your colleagues all work with the same models so that you have a communication medium for making your work visible and hence potentially reusable.

Reuse and Objects

Using the principles of object orientation, we partition and implement system knowledge so that everything relating to one class of subject matter is packaged together.

For a thorough discussion of the wide implications of reuse, refer to Jacobson, Ivar, Martin Griss, and Patrik Jonsson. Software Reuse: Architecture Process and Organization for Business Success. Addison-Wesley, 1997.

For instance, the IceBreaker system includes a class called Truck. This class contains all the attributes of a truck, such as its tonnage, registration number, and model description. It also contains all the operations that are unique to a truck, such as Maintain Truck and Show Truck Capacity. The definition of the class called Truck is probably reusable, as a starting point, in any system that deals with trucks or similar vehicles.

The use of objects has encouraged greater formality and consistency in the way people define and talk about system knowledge. This consistency has helped to raise consciousness about the possibilities of reuse. If we express our knowledge in a more consistent way, then it is more widely communicable and there is every chance that we can use it more than once. Another reason that object orientation contributes to reuse is that it has led to convergence toward a common notation. The Unified Modeling Language (UML) is becoming a standard notation for building object-oriented models.

For an overview of the Unified Modeling Language, refer to Fowler, Martin. UML Distilled: A Brief Guide to the Standard Object Modeling Language. Addison-Wesley, 2003.

Reuse Is Now a Job?

Back in 1993, the Second International Workshop on Software Reusability was held in Lucca, Italy. Most of the papers presented at the conference focused on the subjects of reusing code, design, or architecture. In other words, the thinking was that only the hard artifactscode, objects, and so oncould be reused. Very few papers at the conference looked at the idea of reuse earlier in the development cyclenamely, the requirements themselves.

If you reuse a requirement, you probably get the design and the code and objects for free. By reusing knowledge gleaned from earlier stages in the development cycle, you get the advantage of the downstream products.

Things have changed a lot since then. The practice of reuse is moving upstream, so that today we are seeing reuse of the more abstract artifacts. Requirements are commonly recycled; patterns are exchanged on the Internet. Working conferences on patterns are held regularly and result in the sharing of knowledge and publication of new patterns. This change in emphasis brings with it greater rewards. For instance, if a requirement has already been implemented, then it has a design and some code or objects associated with it. If you reuse this requirement, providing your implementation environment is similar, you probably get the design and the code and objects for free. By reusing knowledge gleaned from earlier stages in the development cycle, you get the advantage of the downstream products. But reusing material taken from later in the cycle does not bring the same advantages as mining the upstream products.

When we saw this advertisement in April 1998, it was very unusual:

"We invite applications to investigate Software Reengineering Patterns as an approach to the problem of reengineering legacy systems. This project, funded under the EPSRC Managed Programme "Systems Engineering for Business Process Change," is jointly run by the Computer Science Department and the Management School of the University. Candidates should have excellent communication skills, and either a PhD in a related area or relevant industrial or commercial experience."

For more on thinking behind the reuse of analysis models, refer to Robertson, Suzanne, and Kenneth Strunch. Reusing the Products of Analysis. Second International Workshop on Software Reusability, Position Paper. Lucca, Italy, March 2426, 1993.

Today it is no longer uncommon to see job advertisements that ask for people who have pattern-related skills. This trend indicates that we are starting to think of the discovery and management of reusable patterns as a real job. If we are prepared to invest in knowledge as a tangible asset, then we can reap the benefits of requirements reuse.