Plug and Play/Pull and Pray

A Question of "un-" Reuse

Will Tracz

Lockheed Martin Federal Systems

Owego, NY 13827

Tel: (607)751-2169, fax: (607)751-6025

Email: Will.Tracz@LMCO.com

URL: http://www.owego.com/~tracz

1 Background

Reusable software components need to be easily composed. Oftentimes system designers provide reusable software designs, architectures, frameworks or patterns, in which developers can "plug" other components into. Furthermore, it is often the case, for reasons of performance, or lack of foresight, that certain features, functionality, capabilities (or whatever one chooses to call it) are "built-in" to the system. The problem becomes how to "not" reuse this functionality when future versions of these components are reused.

2 Position

3 Approach

I think that it is time to re-visit the 3-C Model: Concept, Content, and Context [Tracz90]. To digress then to 1989, when I proposed the 2-C Model (Concept and Content) at the SEI workshop on Software Reuse, and at which time John Goodenaugh was good enough (pun intended) to point out that context played a role in determining the reusability of software. This led the refinement of the ideas through many email discussions with Larry Latour, Steve Edwards, and Doug Lea, to name a few (and I expect additional side discussions within their reuse circles). The rest is history, as they say, though not as popular a history as some good ideas that have been more successfully promoted. The rest of this position paper revisits the 3-C's and reflects on some of the key points that have been associated with them.

4 Analysis

The 3-C Model focuses on three aspects of a software component that lend to its reusability:

• "the concept or abstraction the component represents,
• the content of the component, or its implementation, and
• the context that component is defined under, or what is needed to complete the definition of a concept or content within a certain environment."

While the separation of interface from implementation was not, is not and should not be considered revolutionary to anyone, it has obviously stood the test of time as all good Ada and Java programmers know, The least appreciated, yet most significant "C" is Context.

One can observe that one of the difficulties of trying to reuse software occurs when the contextual assumptions under which the component was designed and implemented do not meet the current context (i.e., trying to put a round peg into a square hole). I initially speculated that "by explicitly defining the context of a reusable software component at the concept and content level, and formally defining its domain of applicability, the user can better select and adapt the component for reuse."

I maintain the belief that this is an accurate assumption and would hypothesize that we have not done a good job understand the different kinds of context, or creating mechanisms to manipulate the concepts and contents of reusable software components under different contexts. This is not to detract from the fine work done but the folks at Ohio State (and beyond) on Refine.

As initially proposed, the context of a reusable software component takes on three dimensions: "The conceptual context of a reusable software component. How the interface and semantics of the module relate to the interface and semantics of other modules. The operational context of a reusable software component. What the characteristics of the data being manipulated are. the implementation context of a reusable software component. How the module depends on other modules for its implementation."

Parameterization, inheritance and importation of scope through the use of abstract machine interfaces were thought sufficient language mechanisms to support these forms of context separation.

I now believe that this may have been too simplistic and poorly explained.

I envisioned conceptual context as a way of declaring a component's inheritance relationships at a conceptual level. While this is important, it seems that in lieu of today's fascination with patterns, it is clear that the clustering of objects into a pattern reflects a certain type of conceptual context.

While the operational context was a thinly masked attempt to justify parameterized and generic types, this concept pales in comparison to what it could be if one considers how one associates certain non-functional contextual requirements on software components. That is, one would like a "secure, or fault tolerant component, which adhered to the same concept, and maybe had the same content, but was transformed according the selected operational context.

Finally, the implementation context provided a way of separating implementation dependencies with the direct goal of increasing portability. I believe that this still is a valid use of the concept. One could argue that this is also where the non-functional contextual requirements could and should be addressed. Maybe this is true.

In conclusion, I would like to come back to the "plug/pull" and play hypothesis. Clearly, components that are designed to be plugged in, need to be designed to understand the context that they are being plugged into. Similarly, components that are being pulled, need to have been inserted (integrated, incorporated, or what ever the right word is) in a manner that the context itself is flexible (adaptable, knowledgeable, or what ever the right word is) to facilitate such activities. I would observe, from practice that de-coupling context from implementation, is a technique similar to designing with certain non-functional requirement driven design policies and protocols. For example, error handling is an orthogonal issue. "Pull-ability" and "Plug-abililty" could be viewed as non-functional requirements also.

References

Biography

Dr. Will Tracz is a senior software engineer for Lockheed Martin Federal Systems (formerly Loral Federal Systems Owego, and before that, IBM Federal Systems Company Owego Laboratory). Currently, he is lead architect for several COTS and Reuse Repository Projects as well as the PI (Principle Investigator) on an internal IR&D project focussed on investigating non-intrusive integration mechanisms. Dr. Tracz is also serves at the chair of the Lockheed Martin Software Subcouncil Working Group on COTS Software and Reuse. Prior to this he was a PI (Principle Investigator) on the DARPA DSSA-ADAGE (Domain-Specific Software Architecture - Avionics Domain Application Generation Environment) Project. While with IBM, he was a member of IBM Corporate Reuse Council, IBM FSC Reuse Steering Committee, and editor of the IBM Corporate Programming Reuse Newsletter. Currently he is a member of the IEEE Computer Society Subcommittee on Software Reuse advisory board, editor of the ACM SIGSOFT Software Engineering Notes, and column editor for IEEE Computer. He also served as newsletter editor and chairman of ACM SIGMicro and been chairman of several reuse conferences, symposiums, and workshops.

Tracz has over 85 publications on software engineering, microprogramming, and software reuse. His current book, "Confessions of a Used Program Salesman: Institutionalizing Software Reuse," published (1995) by Addison-Wesley, provides a road map for introducing reuse into an organization by first using anecdotes and analogies to illustrate the non-technical inhibitors to software reuse, then providing a detailed process for identifying and creating reusable software assets.