Concept: Reusable Asset
This concept describes Reusable Assets in detail.
Relationships
Main Description

Introduction

As shown in the following figure, an asset is a collection of related artifacts that provides a solution to a problem. The asset is customizable through its variability points, meaning those locations within the asset (or more specifically, within the asset's artifacts) that can be customized. Asset consumers may need to supply, for example, their own model extension and integration, or a JDBC driver, or perhaps some IP addresses.

An asset as a collection of artifacts
An asset as a collection of artifacts

The asset may also be relevant to one or more contexts, such as a development context, a deployment context, or a business context. The asset is accompanied by rules and instructions for its usage.

An asset may be fully articulated and include requirements and use cases, design models, component specifications, components, test cases, test drivers, and test data, or it may be just a set of use cases and their models and the rules for extending the use cases. In any case, however, it should have the following qualities to be a good asset:

  • The asset should be easy to use, customize, and apply to another context.
  • It should possess the characteristics of sound engineering: tight cohesion, loose coupling, and sufficient capabilities.
  • Its purpose and intent should be easy to understand.
  • It should be easy to conduct fit analysis to determine the asset's match to a particular context.

To achieve these goals, an asset needs to be more than just a collection of runtime artifacts (code and components); it should also include artifacts that explain its goals, purpose, and motivations. In many cases these are best captured as subsets of the original requirements and the vision-related artifacts used in creating the asset's runtime elements. In addition, modified versions of the build files should be packaged with the asset to help make it easy to use, and test beds should be provided to aid in evaluating the asset.

For more information on the Reusable Asset Specification, which is used to specify assets, see Concept: Reusable Asset Specification.

There are many types of reusable assets, as described in Specify Asset Types.

Assets also vary in the way that the Asset Consumer interacts with them, as described in Styles of Reuse.

Making Assets Reusable

The RAS (Reusable Asset Specification) describes a consistent way to organize and package artifacts, thus providing an infrastructure in which to reuse them. This article discusses the nature of the content itself (that is, the material that is inside the asset).

Both the content and the packaging of the asset need to be useful. For example, if you receive a beautifully wrapped package from your Auntie for your birthday, and it has uncle Joe's dirty socks inside, then regardless of the wrapping it is unlikely that you will use the gift. In this case, it sounds more like a liability than an asset.

Packaging must enable capturing, browsing, and reuse. But it is the usability and relevance of the content that truly allows the asset to be reused.

"One possible measure of a component's reusability comes from its successful use." [Source: Measuring Software Reuse, Jeffrey S. Paulin, Addison-Wesley, pg. 110]

To improve the likelihood of an asset being successfully used, you should consider some characteristics of reusable assets.

Characteristics of Reusable Assets

You can consider an asset to be a candidate for reuse when it fits a cross section of:

  • Providing a solution to your problem
  • Fitting your technical context
  • Meeting your business objectives
  • Fitting within your delivery process
  • Integrating within your organizational structure

One goal of an asset packager should be to make these cross sections easy to understand for the asset consumer, and to simplify fit analysis whereby the consumer evaluates the asset's potential fit in their context.

The degree to which you conduct such an analysis is proportional to the size, complexity, and value proposition of the asset. For instance, you will likely spend more effort on evaluating an application framework than you will on a component that formats addresses.

These guidelines focus on the technical aspects of making an asset reusable, and will not discuss the issues surrounding meeting the business/organizational/process needs.

There are technical things you can do to your assets and their artifacts to make them more reusable. The goal and purpose of this is to lower the relative costs of reuse. This is a sound value proposition for both corporate/internal asset producers (i.e., asset artifact developer or asset packager) as well as producers that operate on a public exchange. The bottom line is that the asset consumer is better served by addressing these issues which lowers the cost of reuse thereby decreasing the number of times the asset must be used in order to get payback on their investment.

So the question remains: What can you do to make my asset reusable? What, in fact, makes an asset reusable?

There are many studies and papers written that claim a variety of elements for answering this question. The suggestions range from creating good documentation, to defining well-formed interfaces, to controlling the size and complexity of the asset itself.

The sum of it all is that the use of sound software engineering principles is the key item that makes an asset reusable. This should not be a surprise. These principles represent elements of the foundation on which Rational has been preaching and practicing. These principles are summarized below:

A challenge with determining an asset's reusability is the lack of standard quantitative metrics in this area. It would be useful if we could say that the asset X reusability metric score is 9 out of a possible 10. Some projects have produced such metrics, but since these are not well established, the principles for determining reusability are used with a combination of quantitative and subjective techniques. Each of these is discussed in further detail below.

Comprehension

This principle is critical to the proper selection and usage of the asset. The reason for this being a key principle is that an asset's relevance to your context is critical in determining its reusability. Said another way, reusability of an asset is largely a function of how well the asset fits our context.

To make such judgments, you must first be able to understand what problem the asset proposes to solve, the nature of the asset's solution, and the context (e.g., business, technical, and other) for which it is intended.

Two key elements of this principle follow.

Documentation quality

Documentation is often viewed as a final step to getting the software out the door. If an asset consumer can find what they need to know to conduct both fit analysis and asset usage, then the documentation can be viewed more as a strategic tool than as an afterthought.

Time to Understandability and Use

If the asset consumer can attain comprehension in a relatively short period of time, then the asset is evaluated with more correct information. How many times have you looked at a component or a class library and, after a period of time, determined that it might be easier just to built the thing yourself?

The asset must be discoverable at multiple levels to conduct a fit analysis. This means that you need to be able to understand where the asset fits within your process, who will use it, what are the steps and costs of using it, and whether you have the skills to use it.

Complexity

Complexity is manifested in several ways, perhaps best described as internal complexity and external complexity. External complexity is about the complexity of working with, customizing, and applying the asset. This could be termed "ease of use." Internal complexity is about the structure, organization, and architecture of the content itself. Metrics such as Halstead and MacCabe can be used to get a sense of the internal complexity.

The measurements of some of these items can be automated whereas other items must be measured manually.

  • If the asset is difficult to use and to customize, then this increases complexity.
  • If the asset has many parameters and points of customization, then this increases complexity.
  • If the asset has many external dependencies, said another way is tightly coupled, then this increases complexity.

The complexity of an asset partially determines its ease of usability. There are no agreed upon metrics that quantify the complexity of an asset. However, the following can be used as indicators of an assets complexity:

  • The McCabe Cyclomatic Complexity metric
  • The number of dependencies the asset has on external elements
  • The number of steps the user must follow in order to install and customize the asset
  • The number of variability points
  • The number of lines of code (if applicable)
  • The quality of the documentation
  • Feedback received from users that have applied (or attempted to apply) the asset

An asset can have many artifacts in it. These artifacts can be requirements documents, models, source code, binaries, tests, and so on. The complexity of these artifacts greatly affects the reusability of the asset.

For assets of any significant size and complexity there may be an architect and designer and developer who are creating the initial artifacts. There is also an asset packager. This person (or people) focus on making the asset consumable. Cooperating with each other, these roles address the issue of making the artifacts consumable.

Some of the elements affecting complexity are listed in the following sections. This initial list identifies some items to consider in mitigating complexity in your asset.

Complexity Item Value
Degree of Customization How many locations for customization?
Degree of Coupling How many occurrences and of what type?
Level of Complexity What are the Halstead and MacCabe numbers?
Asset Size How many (classes, interfaces, services,and so) must the user interact with?

Degree of Customization

An asset may be customized in many places, such as in the use case document, the model, or in the code itself. Obviously, the more places where customization is required, the more difficult the asset is to reuse. These points of customization are called variability points.

Identify the locations where the asset consumer must customize the artifacts. It is helpful to build a table like the one below for capturing these variability points or to create a package and diagrams with variability points as well.

Variability Point Location Type Variability Point Binding
Design Model::User Account Java Interface Create implementation class
DB2 Control Center Relational DBMS Create database
WebSphere Advanced Server Application Server Configure Container Managed Persistence

The purpose of the table is not to replace installation and customization instructions. Rather, the table should provide a summary of the numbers and types of customization that the asset consumer must perform in order to use the asset. If the number of customizations becomes too large, at times you may decide to create multiple implementation strategies of the same asset. This may decrease the number of variability points; however, this decision must be balanced with support and maintenance capabilities as well.

Degree of Coupling

There are several forms of coupling, and they can be viewed as a spectrum. Using the following table evaluate the boundary of your asset and determine how many occurrences there are for each type of coupling.

Forms/Types of Coupling Definition
Best Form Data coupling This is where the proper data elements are passed to another asset or component.
Relevant Structure Coupling This is where more data than is necessary, such as in a data structure, is passed to another asset or component.
Control Coupling This is where an object or function passes an element of control to another asset or component.
Shared Element Coupling This is where multiple assets or components access the same data storage location.
Worst Form Internal Reference Coupling This is where an asset or component has knowledge of something internal to another asset or component, such as a local variable.

Note that for this evaluation you do not need to consider the coupling that may exist within the boundaries of the asset. However, this evaluation should consider the coupling that the asset has with other assets.

If you have mostly data coupling and relevant structure coupling, then your asset's reusability is greatly improved. If your asset has control coupling or any that are worse, then the asset's reusability is in jeopardy and needs re-architecting.

As has already been stated, the fewer occurrences of any kind of coupling the more reusable is the asset. This table illustrates a coupling spectrum to consider when evaluating the complexity of your asset.

Coupling is expressed as a dependency on another asset or component. Poulin quotes a study by Torres and Samadzadeh regarding the impact of coupling on reuse. The result of their studies using Ada and C found that high coupling "had a negative affect on reuse", while low complexity "had a positive effect".

There are various forms of coupling; some have a more negative impact on reuse than others. The spectrum of coupling spans from an asset knowing about the internals of another asset to an asset passing a simple argument or a fully-used data structure to another asset.

To make an asset reusable all instances of coupling must be addressed. The number of coupling instances that an asset has directly affects its reusability for several reasons. It affects comprehension, maintenance, and usability. If the coupling can be removed then it should be. If it cannot be removed then it should be made the "best form" of coupling, as mentioned previously.

Level of Complexity

Halstead and MacCabe metrics focus on program structure complexity. This is useful for assets providing source code that the asset consumer must use. These metrics reflect the effort to comprehend, use, and maintain the asset.

Another element affecting complexity is the number of parameters that the asset consumer must use. This may range from a few simple parameters on a component to many parameters for a framework, plus all of the relevant parameters for deploying the asset. Presenting the asset consumer with these parameters at the right point in time minimizes the complexity and information overload.

Asset Size

Another element affecting complexity is size. The size of the asset tends to affect comprehension and usability, which in turn affect reusability. Finding the balance of the right-sized thing is important. As some have pointed out, "we don't package up the letter 'e' and pass it around to everybody because it is so reusable". Therefore finding the right-sized set of artifacts, and solving the right, repeatable problem, is critical to making assets reusable.

An asset with several classes and interfaces, a few source files, and a few use cases, and test data is certainly approachable compared with 50 classes, 10 interfaces, 60 source files, 10 use cases, and several test beds. The point here is that as we create assets we should consider size as one factor in mitigating complexity.

Reliability

Few things are more aggravating than using an asset from another source and continually facing reliability issues. In addition to the productivity losses for the asset consumer, there is the sense of a loss of control when waiting upon another party to rectify the situation. This issue can have a more negative impact on reuse than any amount of good documentation and well-architected solutions can overcome.

Therefore, when creating and packaging an asset there must be a commitment to verifying the asset in targeted contexts. This speaks to the need for well-formed, mature processes in an organization. It is no surprise that opportunities for sustained reuse and the resulting benefits are generally reserved for mature software development organizations.

Mitigating the asset's complexity and providing avenues for comprehension are key to making the asset reusable. If you add to these factors the notion of reliability, you begin to experience reusable assets within an infrastructure that behaves seamlessly for retaining and leveraging your corporate investments.

The Lifecycle of an Asset

The lifecycle of a reusable asset can be described as a series of states. These states are customizable and should reflect the needs of your organization. Some states of an asset may be:

Asset Production

  • In Progress: The asset is being created
  • Harvested: The asset is gleaned from existing artifacts and is ready to go through packaging
  • Developed: The asset is produced from new artifacts and is ready to go through packaging
  • Packaged: The Harvested or Developed asset is packaged but has not yet been submitted
  • Submitted: The Packaged asset is submitted for review and inclusion in the reusable library

Asset Management

  • Under Review: The Submitted is currently being reviewed
  • Rejected: The Submitted has been reviewed but not accepted
  • Approved: The Submitted asset has been reviewed and accepted by the Asset Administrator
  • Published: The Accepted asset is available for consumption from the Asset Repository

Asset Consumption

  • Reused: The asset has been used on a particular project

Considerations When Developing Reusable Assets

Creating and reusing assets certainly doesn't come for free, as such there are some costs to consider.

Cost of Creating Reusable Assets

There are generally some additional costs when making artifacts reusable, preparing the documentation, and other supporting material for Asset Consumers. Poulin refers to this as the Relative Cost of Writing for Reuse, and uses an average number of an additional 50% cost to do this. [Source: Measuring Software Reuse, Jeffrey S. Poulin, Addison Wesley, p. 31.]

Cost of Reusing Assets

The cost of reusing an asset includes searching and browsing assets, conducting fit analysis, acquiring, applying and customizing the asset. Lowering the costs of reusing assets strengthens the business case for conducting reuse activities and is driven by several factors, including the following:

  • The organization and packaging of the asset and its documentation
  • The complexity of the asset, such as the number of variability points
  • The degree to which the asset fits within your context

According to Poulin's research [Source: Measuring Software Reuse, Jeffrey S. Poulin, Addison-Wesley, pp. 24-25], if 25% or more of an asset must be changed to make it fit your needs, then the cost of reuse jumps to over 80%. Modification in this sense is not the use of a variability point but rather a functional, structural or architectural change to the asset. In other words, if more than 25% of the asset needs to be modified for your use, then the cost of reuse tends to go upwards of 80% of what it would have cost to develop the asset. Thus, if such a degree of change is required, you may decide not to reuse the asset, and instead just build it yourself.

When and What to Count as Reuse

A key part of measuring your reuse activities is to arrive at a definition of reuse transaction occurrences and content. This means that for the reuse measurements to be accurate, there must be agreement on when to count a reuse transaction and what is in the reuse transaction. For example, if your team develops a component on a project and uses it themselves, is that considered a reuse instance? Or if another team builds a component and your team uses that, is that considered a reuse instance?

Therefore, a policy needs to be determined describing when to count instances of reuse. The other part of this policy needs to describe what to count. For example, if your team purchases a COTS product that is an application, does that count as reuse? Or, should the middleware layer of a system be counted as reuse? Or should only those assets that are developed by the organization be counted?

The goal here is to arrive at some clarity of what is being counted and when it is being counted.