THE REUSABLE ASSET SPECIFICATION

12 February 2002

by Paul Allen

The IT marketing machine often invites the assumption that components somehow magically come with clear specification and high quality by default. Components however are not a panacea. In one sense, they raise a whole new set of issues. For example, how does a supplier accurately describe a component? Where are the techniques to enable suppliers in the component market to collaborate? Does this particular technology lock a consumer to the vendor, or is it really as open as claimed? How does a consumer know that a component is the right one for the organization's business needs? How does a consumer know that a component will adapt easily to shifts in operating systems and programming languages? How can a consumer trust that a component will perform adequately in his or her runtime environment? These are issues that I come across repeatedly in many organizations today.

The software industry must solve two chronic problems before the promise of component reuse can be fully realized. First, standards for specification of components must be agreed upon at all levels. This means at the business level as well as implementation and deployment levels. This in turn requires consensus on the various dimensions that make up a component. Second, a high degree of software quality, particularly in terms of factors like reliability and maintainability, must be achieved in order to ensure consumer confidence. Ultimately, both problems center on the question of trust: trust that the component is the right one and trust that the component comes up to scratch.

How can I trust a component to do what I want and how I want it? Rigor of specification is necessary to ensure that the developer of the component has a clear and unambiguous contract to work toward. Equally important, rigor is needed so that the component can be rationally assessed for its compliance to requirements. At the same time, less formal and easily understood specifications are necessary for customers to choose components without getting a diploma in linguistics. A certain pragmatic formalism is required.

The Reusable Asset Specification

Rational Software's Reusable Asset Specification (RAS) centers on the classification, content, and usage of software assets (see http://www.rational.com/eda/ras/preview/index.htm). It first came to my attention in the latter half of 2000, and it is clearly a major initiative, which continues to unfold. Rational is working with the Reusable Asset Specification Consortium to put forward a set of guidelines for the specification, development, and application of reusable software assets. This initiative recognizes that a fundamental prerequisite for reuse is an industry agreement on a common way of describing reusable software assets. RAS is aimed at reaching such agreement; the third version of a preview of the specification was published on 9 April 2001.

The scope of RAS stretches beyond components to all development artifacts that are essential to the delivery of an application. This ranges from simple assets, like the company's logo that must appear on every Web page, to complex assets, like a component framework designed for a particular business domain. There are potentially many categories and profiles of reusable software assets. The specification identifies some profiles/categories and describes what should be packaged for each given profile.

RAS does not address how the assets are mapped into specific tools. It is intentionally tool-neutral and employs the Object Management Group's (OMG) Unified Modeling Language (UML) to map out a tool-neutral metamodel. RAS applies UML in the following three ways:

1. To describe itself (to describe asset description structure and semantics)
   
   
2. To specify the asset content
   
   
3. To identify a small set of UML extensions to precisely define properties of different asset categories and their variability
   
   

RAS describes three dimensions of software assets -- variability, granularity, and articulation -- and uses these to position different types of assets. It provides a coarse interpretation and relative positioning of three of these types of assets -- design pattern, framework, and component.

The following is worth noting:

• Variability -- this dimension defines how customizable an asset is. Along this dimension, assets range from templates (zero or few concrete elements, only placeholders) to components (concrete elements with extension points).
  
  
• Granularity -- this dimension captures the size and complexity of an asset. Although size and complexity are relative, we can identify assets that are single-purpose, small collections of elements as well as assets that are large, complex collections (or collaborations) of smaller assets. Along this dimension, we can have small, simple mechanisms on one hand and complex architectural frameworks on the other.
  
  
• Articulation -- this dimension follows the natural progression from requirements to designs to implementation.
  
  

The intention is that the asset profiles will be defined in RAS (though they are still under construction at the time of writing). So what do assets look like? RAS defines an asset as a collection of related artifacts that provide a solution to a problem. The asset may be a logical packaging or a physical packaging.

Throughout RAS the term "asset" is used interchangeably with "asset package." The Overview part contains a collection of human-readable artifacts such as documents describing the problem that the asset solves as well as the intent and motivation. The Classification part contains metatags (or descriptors, or qualifiers) that describe the assets as a unit. They are used to group, store, search, and retrieve assets as units. This section also has a description of the Context(s) in which, or for which, the asset may be applied. The Usage part contains key information about how to apply the asset such as the problem context (the reuse intention) for which the asset was created and the variability points through which the asset can be customized for a particular reuse situation. The Solution part contains the artifacts that make up the solution; these artifacts include requirements, designs, models, code, tests, deployment scripts, and so on. Note that the structure of the asset is defined using UML within a separate UML Description section.

Just from this quick overview we can see that RAS is a significant standardization initiative that shows that our industry is taking the issue of reuse seriously. At the same time, reuse is one -- albeit important -- element in the specification equation. For example, serious attention must be given to defining characteristics such as reliability and adaptability. As I've said before, my feeling is that perhaps the time is right for the OMG to take the helm in much the way it did with UML back in 1997.

-- Paul Allen, Editor, Component Development Strategies

[For more information on component specification and assessment, see the October 2001 issue of Component Development Strategies, available from Cutter Information Corp. at +1 800 492 1650 or +1 781 641 9876, fax +1 800 888 1816 or +1 781 648 1950, or e-mail service@cutter.com.]