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
|
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.
|