Model-driven development: assets and reuse.

INTRODUCTION

There are many challenges in software development, but in this paper, we focus on mitigating complexity, improving consumability (the ease of use by which a model can be approached, its organization understood, and a determination made concerning how to apply it to one's needs), and reducing time to market.

Background

Several years ago, a consortium of software industry leaders--including IBM, Rational * Software (before its acquisition by IBM), and Microsoft--began exploring ways to help organizations repurpose software investments. In this exploration, it was determined that software entities need to be named, organized, reviewed, and reused to improve the return on the investment in them.

The consortium began to describe these software investments as software assets. This led us ultimately to create standards for asset packaging formats and then to develop tools and processes to work with assets throughout their life cycle. Although we found that assets take on many shapes and sizes and are used in multiple roles throughout the development life cycle, we found similarities among asset types. This made it possible to consider using automation with reusable assets.

Models, a reusable asset, provide a unique opportunity to mitigate complexity, improve consumability, and reduce time to market. We proceed by addressing each of these areas.

Complexity

The demand for more sophisticated solutions is one impetus to the increase in complexity of our software development projects. Increasing complexity is also driven by the pervasive nature of software in today's business and government processes. With software reaching into all aspects of business and government, software design and testing have become two of the critical factors to address the inherent complexity.

Some see complexity in software stemming from the variety that software organizations face--the variety of methods and tools available, the variety of software and hardware, and the variety in skill sets and organizational structures. The value of decomposing the technology stack that organizations use to deliver solutions can be argued, but with that comes an increasing number of elements and combinations. All of these factors--methods, tools, software, hardware, and organizational structures--add to the increasing complexity of software.

In The Economist, (1) n article on managing complexity outlined some of the well-known software project failures and posited that a fundamental reason for such failures is the lack of tools for developers and management that scale to the level of complexity required by today's solutions. Specifically, poor software design was identified as a fundamental element of this failure: As software has become more and more pervasive in business and government, and more complicated, the impact of poor software design has been steadily growing.

Consumability

From experience we learn that the longer it takes to locate, evaluate, use, and extend an asset the more difficult it is to preserve its value. Many of us have experienced the frustration of trying to find and understand work someone else performed. If it takes us longer than what seems reasonable, then we often look elsewhere or stop looking and re-create the content ourselves.

There are no hard-and-fast rules about how long that time is, but some common sense prevails. If we are looking for a model that describes the architecture for a system that our team will build for the organization, it is reasonable that we may take several days or more to find and evaluate it. Conversely, if we are looking for a sort routine, then we are less inclined to spend such a lengthy time. Finding the asset is only part of the problem. Understanding its purported solution and its relevance to the context at hand is another challenge to reusing it. The ability to comprehend what has been created and shared is the next major hurdle. There is a balance between complexity and comprehension, and often solutions are provided that are complex and difficult to understand. In the end, this can be summarized as consumability and ease of use.

Poulin points out that one aid to achieving consumability is to organize the assets in a consistent manner. (2) He notes from a study on the topic that using a standard layout lets a potential reuser quickly scan the important aspects of a component, such as text descriptions, pseudo-code, illustrations, and implementation information. More is said on this topic later in the paper.

Time to market

The notion of time to market is comprised of the individual daily wins an organization makes in its software development process. This includes the notion of time to value, a test that reusable assets must pass constantly to ensure their investment. Time to value means discovering and understanding the right model for the relevant context in a timely manner to achieve productivity improvements. It is directly impacted by the amount of time required to find the right model, but even more so by its reusability. Two factors that make an asset reusable, impacting its time to value and thereby affecting the organization's time to market, are its complexity and its comprehensibility.

There are few metrics dealing with either of these two factors. Quantitative metrics include the MacCabe Cyclomatic Complexity metric (3) and the Halstead Software Science metrics. (4) These metrics focus on program logic, structure, and lines of code, but they do not directly translate to the complexity of a model asset. Several studies that focused on comprehension concluded that if users were presented with consistently structured information and artifacts regarding assets, the comprehensibility of those assets improved. (5,6) We can conclude that if an asset is truly comprehensible, offers minimal complexity, and solves a recurring problem, and if the consumer of the asset can discover it quickly, then that asset has its best chance at providing value in a timely manner. It is the aggregation of many time-to-value wins that can ultimately affect time to market.

Show me the money

Walker Royce describes the context within which asset reuse flourishes (7): In general, things get reused for economic reasons. Therefore, the key metric in identifying whether a component is truly reusable is to see whether some organization is making money on it.

In our corporate zeal to develop technologies and solutions, we often become enamored by technical brilliance. The cycle for innovation should always be tempered by value to the customer and to the business. In Model Driven Development ** (MDD **) work, the same holds true for the use and reuse of assets. We use models as the basis for creating reusable assets; these models should provide value to the customer. The model used in this paper is introduced later.

ASSET-BASED DEVELOPMENT

Several years ago, we at Rational Software began an effort to describe how to leverage software investments for future use. Asset-based development (ABD) organizes the software-related investments, requirements, models, code, tests, and deployment scripts to be used for future software project activities. The four major areas of ABD are the following:

[] Process--Describes the life cycle of assets, both assets relevant to a project and across projects

[] Standards--Describes the standards to be used for assets, such as standard asset packaging, and for specific asset types like services

[] Tooling--Describes the tools necessary to work with assets throughout their life cycles

[] Assets--Describes the kinds of assets that are relevant to a particular organization

What is the relationship of ABD and component-based development? Component-based development focuses on the specification and implementation of software bits that can be reused. ABD broadens this to include a set of asset types that are useful to personnel in roles other than the developer role and to include other points in the development life cycle, such as during the inception and elaboration phases.

Some of the high-value assets we deal with are in the early stages of a project or application design. For example, a powerful mechanism to bridge the business and information technology (IT) gap and provide flexibility and productivity to an organization would be the ability to reuse a business process model as a template, customize it for a specific project or customer need, and then realize that business process with a set of reusable IT assets, such as use-case documents, services, and models.

Nature of assets

When we formally started working on ABD several years ago, we first sought agreement with several organizations on the definition of an asset. This is the result:

An asset is a collection of artifacts that provides a

solution to a problem. The asset has instructions

on how it should be used and is reusable in one

or more contexts, such as a development or a

runtime context. The asset may also be extended

and customized through variability points.

There are three key dimensions that describe reusable assets: granularity, variability, and articulation.

Granularity is the spectrum of asset size and shape. Assets may range from fine-grained, meaning they are small in size and purpose, to coarse-grained, providing larger size and purpose and often containing or referring to fine-grained assets.

Variability refers to the asset's degree of customization. This, too, is a spectrum. On one end, the asset is fixed, and on the other, it is widely visible and changeable.