Martin L. Griss, Senior Scientist, Hewlett-Packard Laboratories, Palo Alto, CA.

[Version of column to appear in Object Magazine, Feb 1996]

In this column, I reflect on some progress in systematic OO reuse since I first started writing for Object Magazine last year. I began the year concerned that too many people simply equate reuse with objects, expecting OT to ``automatically'' ensure reuse. Few people from the OO community attended reuse conferences, and vice-a-versa. While this schism remains, I have recently participated in meetings and customer visits at which OO reuse was discussed far more realistically.

In August, I participated in Object World San Francisco, and in the 7th Annual Workshop on Software Reuse (WISR7). In October, I was at OOPSLA'95 in Austin, Texas. I was encouraged that some (but not yet all) presenters discussed the real issues of OO reuse. Several panels, tutorials and keynotes highlighted the key software engineering issues of OT and reuse. Some stressed reuse process and organization; others stressed well-known software engineering principles needed to scale small-team OT to industrial use. While writing this column, I also completed my reviews of several OO reuse papers for the 4th International Conference on Software Reuse (ICSR4).


WISR7 was a 3 day workshop attended by 55 reuse researchers and practitioners. Companies included Andersen Consulting, AT&T, Applied Expertise, Boeing, CSC, CTA Inc., DEC, Ellemtel, HP, IBM, Loral, MITRE, MountainNet, Motorola, Microsoft, Nokia, Swiss Telecom, and USAF CARDS. Most of the work was conducted in 7 working groups, several with significant OO-reuse content. Position papers, detailed working group reports, and information on the upcoming Apr'96 ICSR4, can be found on the WWW at


Mark Simos (Organon Motives) led the ``Comparative analysis of various domain-analysis methods'' group. Domain-analysis is the starting point for the systematic design of a reuse architecture and reusable assets for a family of related applications or subsystems. (This space of related systems is called a domain). Example systems, user needs, domain expertise and technology trends are analyzed to identify and characterize common and variable features of the domain. The group contrasted the techniques used to represent commonality and variability in ODM, FODA, OOA/D, OO frameworks, configuration management systems and some AI representation languages. Systems representation methods, such as OOA/D, can sometimes be used to express commonality and variability for reuse. Since OOA/D supports only specialization (inheritance) directly, it is hard to explicitly and consistently represent asset alternatives. Extra annotations and conventions can help, but without explicit mechanisms, it is difficult to systematically maintain and exploit commonality and variability decisions in later component and framework engineering. Furthermore, using only inheritance biases implementors to also use only inheritance to implement related reusable assets, encouraging naive ``reuse means inheritance.'' This discourages more powerful parametrization and generative techniques. Similar observations led to Basset's richer NETRON/CAP frame representation[1], to domain-specific kits described in my previous column, and to Objectory extensions in my reuse work with Ivar Jacobson, described below. Differences in culture and goals impede transfer of systematic reuse I led a group on ``OO Reuse - A tale of two cultures,'' exploring why potential contributions from the systematic reuse community seem not to impact the OO community. Factors such as too little communication, few joint meetings, different culture, immaturity of methods, and problem and team scale issues all play a role. The reuse and the OO communities have historically different foci - software engineering in the large vs. rapid development in the small. Education is a problem. Many CS programs do (try) to teach OO methods and programming, but there is too little software engineering content, and even less systematic reuse in most college courses.

Different people in the OO community have different concerns. I particularly valued the insights of Ralph Johnson (U of Illinois). Managers are concerned with $, time to market, concrete evidence, management models, etc. Methodologists are concerned with scaling, principles, ``meta issues". However, the bulk of the OO community are technologists and application programmers, who work in small teams, with an oral culture and ``just build it'' approach. While people interested in patterns and frameworks are usually application programmers, the reverse is not true. Some methodologists are also interested in patterns and frameworks, but most of this work has come from technologists who build systems. Pattern writers describe informal reusable models and documents, while framework builders abstract designs as concrete systems via evolutionary prototyping. Application programmers (using Smalltalk, C++, Eiffel or even Visual Basic) are most concerned with concrete code artifacts, using a quick learning and prototyping approach. The OO practitioner can today apparently manage without much systematic reuse community advice and knowledge, until larger scale problems, systems, libraries or teams will demand a more structured and systematic approach. We identified several potential systematic reuse contributions (e.g., coding and micro-architecture guidelines, process and organization guidelines, concrete domain-analysis checklists and models, modifications to OO methods, OO reuse metrics, criteria to evaluate class libraries, library tool guidance). But systematic reuse methods are perceived as not sufficiently operational, mechanical or concrete. Crisper, more compelling and immediate evidence of reuse success is needed to motivate adoption by the OO community. We must package concrete pieces of systematic reuse ``wisdom'' in an easy to use way, directly related to ``reuse problems'' in the OO community (e.g. use of domain analysis to help classify patterns). Finally, the reuse community should make a conscious effort to mix more with the OO community, arrange joint meetings and workshops, and should develop and publish reuse-oriented case analyses of OO situations.


Ivar Jacobson and I delivered a half-day tutorial, ``The Reuse-Driven Software Engineering Business - Architecture and Process for Systematic OO Reuse'' at OOPSLA'95. This was the first public report on a research collaboration between Ivar Jacobson, myself, and colleagues. Our work explores how systematic reuse processes (see my May'95 column) can augment traditional OO methods. Based on our experience with reuse at HP, Objectory, and customers, we are convinced that today's OT will not succeed in giving users much reuse.

We are addressing these architecture, process and organization questions systematically. We are combining reuse process, organization and kit concepts with the use-case driven OO modeling and methods of Objectory's OO System Engineering [2] and OO Business Engineering [3].

To develop reusable architectures, frameworks and components, we have augmented Objectory with the concept of component systems. Component systems are sets of use-case and object models related to each other by refinement and tracebility links. These include abstract and concrete components, which subsume the concept of frameworks. Our approach is centered on the production and use of layered, modular architectures, based on concepts from systems of interacting systems and domain-specific kits. Notation and methods provide encapsulating interface objects (which we call ``facade'' in the style of the pattern community[4]). Additional representation of commonality and variability, and extended Objectory robustness analysis (component factoring and clustering steps) support systematic domain engineering. Richer parameterization mechanisms augment the familiar ``uses'', ``extends,'' subclassing and aggregation. Component system engineering includes explicit design and implementation guidelines to enhance reusability. Component systems can also include (domain-specific) processes and tools, such as for (problem-oriented) scripting languages, builders, and generators, thus subsuming the concept of kit, described in my Nov'95 column.

We apply OO Business Engineering[3] to describe and then restructure the software engineering processes, tools and structure of a software development organization to support large scale reuse. Use-cases are used to model the interaction of actors (person or external organization) with the development organization. Use-case and object models identify core reuse-oriented software development processes. When these models are further refined to produce the Objectory robustness model (with interface, control and entity objects), we are able to map these onto detailed software engineering processes (SEP), reuse workers, and software engineering process support environments (SEPSE), consisting of information systems and tools. This use is related to Objectory's notion of ``development cases'' and helps define the reuse roles such as reuse process owner, reuse process leader, reuse engineer, reuse librarian, domain architect or resource manager.

At OOPSLA, I also moderated a well-attended panel entitled ``Systematic Software Reuse - Objects and frameworks are not enough,'' with participants: Ted Biggerstaff (Microsoft Corp), Ivar Jacobson (Rational Software Corp), Sallie Henry (Virginia Tech), Doug Lea (SUNY Oswego), and Will Tracz (Loral Federal Systems). We and the audience discussed experiments and measures of OO and reuse, changes needed to OT to support scaleable libraries, layered component architectures, reuse process and organization, and the use of Visual Basic and Java as reusable scripting languages.


There is a growing understanding of how software engineering, reuse processes and organization need to be integrated with OO methods and technology. This is clear from the many discussions at numerous meetings and workshops. More reuse people are attending OO meetings. New books by Tracz, by Goldberg and Rubin, and by Karlsson (described in previous columns) pay significant attention to OO reuse, reuse teams, and software engineering issues pertinent to effective software reuse. Several several interesting reuse tools support the reuse process in various ways, and are more than ``object browsers.'' More about these matters in future columns.


  1. [1] PG Bassett, Software Engineering for Softness, American Programmer, 4(3) pp. 24-38, March 1991.
  2. [2] I Jacobson, M Christerson, P Jonsson and G Overgaard, Object- Oriented Systems Engineering: A Use-case Driven Approach, Addison- Wesley, 1992.
  3. [3] I Jacobson, M Ericsson & A Jacobson, The Object Advantage - Business Process Reengineering with Object Technology, Addison-Wesley, 1994.
  4. [4] E Gamma, R Helm, R Johnson & J Vlissides, Design Patterns - Elements of Reusable Object-Oriented Software, Addison-Wesley, 1994.


Martin L. Griss is a senior Laboratory Scientist in Hewlett-Packard Laboratories, Palo Alto. He leads the Reuse Engineering project, researching object-oriented reuse and distributed instrumentation kits. Known as HP's "reuse rabbi", he previously managed the Software Reuse Department, was Director of the Software Technology Laboratory, and led a HP Corporate Engineering project to introduce software reuse into HP's software development processes. Before coming to HP, he was an Associate Professor of Computer Science at the University of Utah. He received a Ph.D. in Physics from the University of Illinois in 1971, and a B.Sc from the Technion, Israel in 1967. He may be reached by email at, by FAX at +1 415-857-8526, or by mail at HP Laboratories, 1501 Page Mill Road, Palo Alto, CA 94303-1126, USA.

Last modified: Thursday, 06-Feb-1997 16:21:14 PST
This document is: