In-Depth

Approaching the promised land of component reuse

• By Ivar Jacobson, Martin L. Griss
• June 1, 2001

The technology and standards are now largely in place to support the long-promised "golden age" of component-based development. The time has come to work together to take advantage of this situation. With more and more of the world's activities being carried on by software, we can no longer afford to build all critical applications totally from scratch. We must systematically reuse components.

In our opinion, economically significant reuse has three prerequisites:

1. A widely understandable modeling language to do for software what a standard format for engineering blueprints has done for the construction and mechanical disciplines,
2. A process for developing software, drawn from the example of the earlier engineering disciplines and
3. Software tools to support the entire development process, covering both the different detailed life cycle activities and key cross-life cycle activities.

The work products of software engineering will be described using the blueprinting language, they will use this standard process, and they will be managed and transformed by these tools. By building on the structure provided by language, process and tools, it is technically possible to make great strides toward component reuse.

We have been saying for years that if we want to become as industrial in software as we are in the older industries, we need to apply techniques similar to those of the other disciplines, but—and it is a big but—we must adapt them to our specific problem space.

This is a very different vision from what the proponents of programmer-empowered methods suggest. They are like the Luddites who worked against the industrial revolution, who felt that the rise of industry would dehumanize and exploit workers. They use a very similar language; they talk about the "rights of the programmer" and the social aspects of programming.

The other engineering disciplines have held out for us the vision of where the software industry should go. As inspiration, we first used the hardware industry. The vision was one of software components and interfaces comparable to the pluggable boards and boxes connected with the buses and cables of the hardware.

In each of these industries, engineers and architects know that they can reduce time and improve quality by employing standard components and proven best practices, often codified as processes. Early in their careers, engineers are trained in the selection of components and their assembly into larger systems using standard processes. They do not start each new project from scratch.

That metaphor has shaped our joint thinking. It has guided us in developing blueprinting languages and development processes. During the past few years, the languages have been standardized by the Object Management Group (OMG) as the Unified Modeling Language (UML) and the Rational Unified Process (RUP). Both have emerged as de facto standards for developing component-based systems.

Today we see substantial reuse of complete commercial applications and other packages (such as DBMSs, communications infrastructures, operating systems, accounting packages and GUI frameworks). Developers often focus on achieving the "best fit" by asking which commercial packages can be used as the base for the system and come as close to the requirements as possible. They then try to change their application requirements to be closer to what the commercial packages offer.

Individuals and organizations also practice some ad hoc reuse. Many development teams regularly create their own libraries of code, share designs, re-apply templates and frameworks and so on. But this tends to be uncontrolled, inspired by individuals, and it can be rather fragile.

Neither of these current reuse practices has significantly transformed the software industry. We envision and advocate a systematic engineering practice, a controlled, planned and architected reuse program based on large-scale managed components. The quality and productivity that reuse produces should be controlled, measurable and managed.

The three prerequisites are finally here
Achieving the long-promised benefits of large-scale component-based development has been hampered because the three essentials were missing until very recently. Their absence made it almost impossible to systematically create and find software pieces suitable for reuse. Because there was no effective, standard way of describing the pieces, finding what was available and deciding if each piece was suitable was difficult. We did not have a standard way of communicating about software, until UML.

To achieve reuse, we need to understand what we will reuse. Until a few years ago we had no standard for communicating what a component could do. The software industry has adopted UML as a blueprint. Nearly every university that teaches software engineering teaches UML. It is widely used in requirements engineering, architecture, analysis, design and implementation courses. It is used to define patterns, processes, protocols, workflows and organizations.

UML provides the means to communicate between people, both those doing the same kind of work (such as analysts communicating with other analysts) and those in different roles (such as analysts communicating with designers). It provides a means of communication both between people working on the same project and on different projects. Its capabilities extend to people working in different parts of the world and even in different companies. UML is used for the diagrams necessary to develop software. UML even extends upstream from software development to model the business processes that developers implement in software.

The function of this modeling language is to describe the many different views of components and complete applications at various stages of development. Different constructs are used in different models; for example, use cases are used in the analysis model and classes are used in the design model. Each of these models evolves as the system is refined. Some of the models can be used to describe what a component does, while others describe how it does it and how it interacts with other components while doing it. In addition to using some form of component catalog to search for components, these models allow designers to understand what a reusable component will do without looking at the design or implementation. The language is precise enough that the designer should not need to examine the source code to understand exactly what the component might be able to do.

In the past, we did not have an effective and standard process for developing software. Now we have RUP. For these past 30 years the software industry has employed a great variety of methods, languages and tools to develop software systems.

How do we get a whole team to develop software together? That is what we mean by process. They all need to know what to do, when to do it and how to do it. The process helps by defining which artifacts need to be produced, by whom and what activities need to be carried out at each step. By helping them to know what to do and when to do it, the process frees developers to focus on developing the right solution.

Given a useful set of high-quality components and UML to describe them precisely, the next step was a well-defined development process to create and reuse components. With contributions from thought-leaders all over the world, we agreed on a process to develop software systematically. That process became institutionalized as RUP, which answers the need for a systematic software development process. RUP can be applied both to developing complete applications and to developing reusable components. RUP satisfies this need because it enables people to work together effectively.

Because the needs of software development are as broad as the world itself, the process was designed to be specializable and scalable in many ways, based on skills, role, application areas and organizational constraints. For simpler developments in smaller organizations, a lightweight subset of RUP is used—RUP can be made as lightweight as necessary. As the scale of the work and the organization grows, RUP provides the basis for the processes followed by the whole organization.

RUP alone does not cover all of the processes needed to fully support reuse. Reuse requires a suite of distinct processes targeted to architecting families of systems, developing components and putting together application systems. We build on the RUP foundation to produce a scalable family of component reuse-oriented processes that cover system architecture, component construction and the reuse of components to build other systems.

We used to say that a process that is not tightly supported by an integrated set of tools is just an academic idea. Fortunately, both UML and RUP are supported by suites of tools. These tools support many aspects of both the specific software life cycle stages like requirements, analysis, design, implementation and test, and also the key cross-life cycle activities like change management, version control, configuration management, defect tracking, documentation, project management and process automation. Tools like Rational's RequisitePro, Rose, SoDA, ClearQuest, TestManager and so on are well integrated, customizable to different users of RUP and UML, and support all the important artifacts.

Toward a well-understood engineering discipline and industry
Ideally, the software industry should have many active players, each proficient in some aspect of the development, distribution or use of reusable components. No longer can a lone individual invent and develop from scratch all the pieces of software that a large-scale software system comprises.

There are useful parallels between the construction industry and software development. Building architects and engineers work with diagrams and computer models to produce detailed design blueprints and specifications. Later masons, carpenters, electricians and plumbers "install" these designs on-site by assembling prefabricated physical components.

Likewise, in software development we have a variety of analogous skills and specialties. Software architects, analysts and designers produce detailed designs in the form of a set of artifacts (such as specifications or models) utilizing UML. Later, other developers, such as programmers skilled in different languages, database experts, GUI specialists and testers complete the implementation. The architects, testers and others make use of large catalogs of components.

Large-scale reusable components
While class libraries and other forms of small-scale reuse have been useful, they have not transformed the software industry enough. Components must be worth the effort of being sold, bought and maintained. We will call large-scale reusable assets components in the broad sense of the word; they are substantial chunks of functionality designed for reuse. (In this sense, component is a much wider term than the component construct employed in UML. There it just refers to a software element that may be quite small.) The reusable assets we are talking about are the size of subsystems or frameworks.

These big components are represented by a standard set of artifacts—to use RUP's terminology. For instance, these components have a set of models: use case, analysis, design, implementation and test. In practice, one of these components may support several use cases. It may include many subsystems, each with a number of classes, and their implementation in terms of source code and executable code. These components have a strict configuration and version-control system in place. With each such component there are ready-made software models that can be incorporated in tools supporting UML and RUP. Each component also has guidelines for its reuse.

These components are used to build applications. Reusing a component means that each of its different models will be reused in the course of building the application. Thus, the use cases for the application reuse the use cases of the component; the design of the application reuses the design model of the component, and therefore reuses its code, its tests and so on. Such a component accelerates application development by lowering costs and speeding time to market. Both of these benefits are achieved not by starting from scratch, but by starting with quality components.

A software component is not usually as easy to use or to connect to other software components as building construction components are. Some construction components, such as doors, windows and cabinets, can just be connected to other things by means of a simple seam, such as a line of nails or screws. Other construction components are more complex and have to be consistent with many fine-grained and coarse-grained architectural constraints and standards. In some cases, different standards have been selected for different regions. Adherence to such standards and the use of compatible prefabricated components (such as doors, cabinets, windows, plumbing fixtures, roofing trusses, wall panels and so on) have greatly improved the efficiency of the construction industry.

Software is still more complex and, moreover, less tangible. Therefore, strong and effective architectural standards are absolutely essential for a viable software components industry. While some small software systems are simpler than some buildings, most large software systems are more complex than most large buildings. (One way to measure this is to compare the number of developers necessary to design the building and the number needed to develop the software.) Large software systems have many software components that must fit into the often very complex setting defined by the underlying architecture or system software, which includes the operating system, the database management system and the programming environment. The software must interface with other components through many complex interaction points.

This complexity makes it hard to produce software components that are usable in several architectures. We must usually be content for a component to be capable of playing a role only in the architecture for which it was designed. For example, a component in the middleware layer is dependent on the system software it runs on top of, as well as the other components it works with in the same layer. It is not easy to move a component to work in another architectural setting, such as from Microsoft .NET to J2EE. It is not easy to enable a component to work with components it was not designed to interface with. (Here you may have to put a wrapper around it or around the environment to get the interaction to work.)

A component in a higher layer is dependent on the middleware and the system software layers. It will not immediately work on top of other layers from a different architecture, although we may try to insulate the higher layer from the underlying layers by using a layering wrapper, which makes the top layers much more independent of the underlying platform.

Software components are understandable
Developers, that is, people, create the source code for the components and their interfaces, which will be translated mechanically into executing code intended for interpretation by a machine. We can, of course, reuse this code by shipping it to many places, installing it and letting it execute. However, developers trying to reuse a component need a lot more information than they will ever get from executing code or even from source code. They will need models and documentation that describe what a component does, how to use it, how it interacts with other components and by what architectural, standards and infrastructure constraints it must abide. Furthermore, they may need guidance on how to specialize or adapt the component if they will not use it "as is." Thus software components must be understandable.

Should the component documentation and released models include source code? Many software components are not, and will not be, sold with complete UML models and source code, just as detailed chip layout diagrams are not always included with hardware components. Often all the details used to implement and maintain the component are not needed to understand how to use or how to do the most important customizations with the component. So, just like a chip, in many cases components are sold with binary code and a partial UML model with some textual elaboration. In other cases, to make the explanation of how to reuse a component clearer, UML models focused on describing the facade of the component—all you need to know to reuse the component and some of the source code—is needed. When reusers expect to do significant modification, their own maintenance or possible recompilation of a component, even more of the detailed models will be needed, including a lot of source code and many of the models (from use cases to test models).

This reliance on UML will happen for a number of reasons, including: more people will be trained to read UML, UML will be extended with "profiles" to more effectively address specific problem areas, more components will be sold with effective UML descriptions, and new customization mechanisms will make it easier to extend code without modifying or recompiling the source code. We expect that developers will come to understand components modeled in UML. However, understanding UML and developing with RUP is not enough. We need more to create this industry—a standard that enables people to understand how to become producers and consumers of reusable components through a global marketplace.

For this to happen, a standard Reusable Asset Specification (RAS) is also necessary. We need consistent component specification standards if we want a much wider-spread component reuse market. Ad hoc component specifications will work only as long as components are produced and reused within a single company or small group of companies. But as soon as we want to scale up to a broadly distributed market, much stronger standards are needed. It will be very hard (if not impossible) to effectively reuse components produced by different companies if they are modeled, specified and documented poorly and inconsistently.

The players in the new industry
One of the requirements for a robust and efficient market is that it must include many participants with diverse viewpoints and objectives. To understand this emerging market, let us focus on the four most important players: the component factories, the application builders, the tool makers and the component brokers.

Component factories are the vendors that have developed components. Usually a component is targeted to a particular vertical niche, such as insurance or banking. However, there are components at all layers, including middleware and system software. With the prominence of the Internet, components are built specifically to accommodate the requirements of e-business.

Many of the companies that will become the component factories of the future have already developed components, or something that can be turned into components, for their own business needs. Of course, each of these companies has had to develop its own techniques, such as their own proprietary reuse-oriented processes, modeling languages, component specifications, frameworks and tools. These unique technologies make it very hard for anyone else to reuse these components; some will have to be replaced by widely used standards. In many cases, vendors have depended on these differences as barriers to competition. Such companies will need to adjust their business models and their approach to competition in a world of more open standards.

The component factories will come from five areas:

1. Service organizations such as TCS, Accenture or EDS;
2. IT departments in the larger companies particularly in insurance, banking or other specialized fields;
3. Package vendors such as SAP, although these vendors will have significant challenges in standardizing their proprietary solutions, adapting to new component standards and getting their established customers to change technology;
4. Infrastructure vendors, the developers of operating systems, networking and middleware products, such as Sun, Microsoft, HP, BEA and so on; and
5. Current and emerging vendors of small sets of components, like class libraries (RogueWave, for example) and brokers such as ComponentSource or Flashline.

The potential components that some of these companies have today cannot simply be factored out and sold. They are usually integrated within complete solutions and rely on a mixture of proprietary and standard technologies and ad hoc specifications. Today, the organization that developed the component usually is the only one that can reuse it. These companies will have to do substantial repackaging, and some significant re-engineering, before these components are ready for the open component market. They will also need to change some of their business models; service companies must turn the component/customizable solution part of their business into a component product business.

Given the state of today's marketplace, a potential component vendor has few effective ways to let potential buyers know what it has to sell. Then, even if it finds a purchaser, there is no agreed-upon methodology with which to instruct the buyer in the employment of the component. This is the infrastructure that the component factories of tomorrow will need to provide or help build for the industry.

In the future, component factories will take on the role of product companies delivering reusable assets to a world market. The difficulties they will face fall into several categories. They all need to move to a standard component specification and development process, such as those which UML, RUP and RAS provide. Also, they will need to become compatible with one of the major component architecture standards, such as COM, .NET, CORBA or J2EE. The package vendors will need to transition from their home-brewed technology to these standards.

Application builders will build applications or end-user products—what we usually call systems—by selecting and customizing components from vendors, and then adding their own components and additional software to integrate these components into complete solutions. In this way, they will add application-specific functions on top of more generic reusable components to form systems for their clients.

Several kinds of companies like this exist today, but their roles will become more specific as a real component market develops. In some cases they build applications for sale; in other cases they build applications for use by their own or customer organizations. They include:

• Solution builders or system integrators, such as EDS, CSC and others, that provide software to others;
• E-business service companies that build by reusing packages and dynamic e-services; and
• Large product-line builders that build a suite of applications around a common product-line architecture, for example, telecommunications systems, printers or instruments.

Potential application builders of the future are solutions-centric. They have a vertical organization—their customer relations or marketing organization is familiar with the business needs of the end users. We foresee a future in which these organizations take a stand and decide on their direction. Either they will become competitive application builders or they will become component factories.

Of course, a few companies will attempt to play both roles, although it will most likely be difficult to do both. Application builders and component factories have many differences, but the most significant is that application builders are solutions-oriented and their customers are other businesses, while component factories are technology-oriented and their customers are other software companies.

Putting components together will be the task of the application builders. They will need tools to do it. Without powerful tools, architects, designers and developers will find it very hard to effectively customize and assemble applications from large-scale components with their models and complex customization mechanisms. Those tools will allow them to incorporate components described by a set of models so that they can build new applications by reusing those models. The tools will come from still another group of companies, the tool builders.

Tools to support component reuse must be able to import a set of models and then allow the application builder to build on top of those models. Because we may reuse many underlying components, we need to be able to build on top of several such underlying sets of models coming from different component factories. The challenge to this is to ensure that the reusers (the developers from the application builder) do not actually change what is reused, but just specialize it. Because of this, if developers are given rich UML models and effective descriptions, they should not need source code.

In this way there will be clear responsibilities between component factories and application builders: component factories are responsible for components, and application builders are responsible for the way the components are interconnected and specialized. Companies will be identified as either component factories or application builders.

Given that we now have the technology to develop components and to use them, we need to make sure that component factories and application builders can find one another. This is a much simpler problem today than it was in the past. In the past is was difficult for many reasons. As we have already said, we did not know what a component should look like, we did not have standards like UML and RUP and we did not have supporting tools. This alone is sufficient to prevent any progress from being made. But if this were not enough, we did not have the Web and search engines; we did not have standard architectures and frameworks; and we did not have XML to transfer and interact about components. Until this point, the business of brokering components was not very interesting or feasible.

But now it is. There is a growing understanding of the economics of the "make vs. buy" dilemma, among both developers and managers. It is worthwhile to advertise and market components. It is worthwhile to create a marketplace for components. The operators of these component marketplaces will be the component brokers.

Standards underwrite the new industry
In the marketplaces of antiquity, the products were inconsistent from one unit to the next and their sizes were haphazard. Merchants had to weigh the gold or silver pieces offered in exchange to avoid being "cheated." Even the weights of the items they bought and sold were not enforced by an external authority superior to the players. These inconsistencies forced market players into time-consuming one-on-one bargaining and bartering.

In other words, nothing about these old marketplaces was standardized, which was inefficient. Now we have the experience of a long history of marketplaces, with standard sizes, defined measurement units and fixed prices. Our task is to transfer this experience to the component marketplace. In a similar way, we need a standard for the way some software vendors can create and sell reusable components and the way others can buy and reuse those components. The component factories and the application builders must know exactly how to play the game. Standards will tell them how.

Think about a modern game, such as soccer. It has a rule book that tells you how to play. It has what we might call a set of tools—a ball, a type of shoe, goal posts, even a marked-off field. It has a referee to help interpret and enforce the rules. Armed with these rules and tools, teams from the far ends of the earth can meet and play successfully. Without these "standard" rule books, strange teams could meet in a meadow, but they would be reduced to kicking at tufts of grass. To play a game, you must have standard rules, tools (such as a football, goals and a field ) and institutions (such as referees and associations).

The same prescription applies to the new game we are creating: the marketplace for software components. A key goal of this marketplace is to establish standards for quality and performance, as well as for functionality and interoperability. It is important to both sellers and buyers to ensure quality, to reduce costs and increase trust in the components.

We must have a rule book, the standard for what it means to play the game. It will be non-proprietary, of course. The rules will specify, for instance, what kinds of models need to be created for each component, and how to be sure that a component has been appropriately tested or certified to meet its specification, either by the seller or by an independent third-party testing laboratory.

We must have tools to play this new game. Tool vendors will design and produce the tools for building the models necessary to follow the standard.

We must have referees and associations that establish, enhance and validate the use of the standards. Some companies will set up their own standards organizations, acceptance testing and certification laboratories for their application builders, while others will participate in open standards organizations, use third-party testers or depend on the supplier to do a good job and market forces to weed out bad components.

The standard will specify, (as, in fact, RUP does now) what models component factories build and deliver for each component: use cases, analysis, design, implementation and test. It will specify the details about these models, including their contents and how to describe variation points. It will specify the models to deliver with the component, and provide extended models to be used by the developers only for evolution and maintenance. RUP and RAS specify what should be modeled and UML defines the legal syntax and semantics of the things being modeled.

For application builders to effectively reuse components, these components must be well-specified, well-documented and easy to reuse using widely accepted standards. By well-specified, we mean an appropriate set of UML artifacts must be provided to make it clear exactly what the component does and how it is intended to interact with other components. Its variability and its interfaces must be specified carefully. By well-documented, we mean that in addition to UML diagrams, there must be additional artifacts to provide rationale and notes about features, classification, testing status, relationship and comparison with other components, who to call for support, evolution plans and so on. To be easy to reuse, the set of artifacts provided must be amenable to importing directly into the models being built for the new application, supporting quick modeling and automation.

Creating marketplace standards
As RAS gains acceptance and as architected large-scale component reuse becomes more widespread, the next step will be to focus on the reuse process—how an application is best built from reusable components. This will determine which artifacts are needed and in what order. By also standardizing these key reuse-process steps and their related UML artifacts and associated documents, we ensure that component builders provide the right set of artifacts. We ensure clear relationships between them. We enable application builders to use each in a well-defined way at an appropriate step in the reuser-process.

The current RAS specification, and the later refinements that come from the reuser process-based approach will ultimately lead to a more coherent set of standard artifacts and, hence, to better results.

The component factory that delivers a component must take long-term responsibility for it. That factory should maintain and further develop the component according to the terms of a strict release plan.

For its part, the organization reusing a component should make a conscious decision—and promulgate it to its troops—not to change a component. In part, the reason for not providing all the source code, or all the internal design models, is to prevent reusers from changing the source code.

The possibility of unauthorized change is one of the key challenges facing the open source movement. While the appeal of "a thousand eyes" to catch defects is compelling, the ability of almost anyone to make changes at any time makes it hard to guarantee a stable version for reuse in other systems. The responsibility for making changes within such a component really belongs to the component factory producing it, and not arbitrary reusers.

Of course, there will always be component factories that go out of business. Ideally, support for their components will be assumed by other component factories. Inevitably, there will be instances where a reuser assumes responsibility for an "orphan" component. Alternatively, some reuser organizations require source code to be placed in escrow to insure against such problems.

To carry out this policy, tool builders need to devise ways to assure that developers in the reusing organization cannot easily make changes within the component. In the normal course of development, they should only be able to specialize what the component maker makes available to them, such as parameters, tables or other variation points. With good specialization techniques such as those provided with UML, a reuser can go far in making a component useful for his or her needs.

The point is: if any user can readily change the content of a component, the component maker cannot effectively discharge the responsibility it properly assumes for the future evolution of the component. That future evolution, of course, is kept under control by configuration control management, enabling all concerned to know what they are actually dealing with.

The standard will specify the rules for actual reuse. For instance, we think it is very important that the component factory delivering a component must take long-term responsibility for it. That factory should support, maintain and further develop the component in accordance with the terms of a strict release plan.

Thus far in the software half-century, we have achieved some reuse on a small scale. Some companies have reached a larger scale, achieving reuse across a line of related products. A few have reached a still larger scale reuse across different product lines. We are now ready to take the next step, which is to create a component market that will go still further.

In this marketplace there will be different kinds of participants:

• vendors developing reusable assets,
• system builders using these assets,
• tool vendors,
• component brokers and
• standards organizations.

With agreement on a standard set of component models and widely available processes and tools to construct and reuse components, the whole world can build teams. It can let these teams compete with one another—not only pairwise, but all at once. There will be no rest in such a marketplace. But in such turmoil the goals of the marketplace as a whole will advance.

The newly emerging e-services trend promises to lead to a new generation of large-grain "components" and expand market opportunities. Many companies are participating in the standardization of several XML and Web-based technologies for the next generation of flexible e-commerce applications. The emerging Internet (HTTP) and XML standards for e-commerce set by the W3C, CommerceOne, UDDI and others are beginning to stabilize enough to enable a vast array of "chapter one" Internet-based e-commerce systems. New standards and Web-based infrastructure established by Microsoft .NET (which includes SOAP and BizTalk), CommerceOne, Ariba, eCo, RosettaNet, IBM, HP e-speak, OBI and so on, have the potential to expand the definition of a component. This next generation of "components" will not be statically composed, traditional components. Instead, they will be Web-based e-service components, with well-defined interfaces described in XML, that can be dynamically found using registries and brokers and dynamically composed into complete applications using workflow-like glue languages. With the advent of these new standards, Internet middleware and e-commerce frameworks, we are on the verge of a much more dynamic "chapter two" Internet e-commerce world.

This marketplace will mean business at the level of tens or even hundreds of billions of dollars worldwide within a decade. It will provide developers with a means of reducing the cost of building software by a factor of 10. This cost reduction need never result in the unemployment of software people. Instead, as developers are liberated from their current tasks, they can use their freedom to develop new kinds of software and technologies that would not otherwise be possible. And we will see things that we did not even dream of in the past.

Suggested reading

1. Booch, G., J. Rumbaugh and I. Jacobson. The Unified Modeling Language User Guide. Reading, Mass.: Addison Wesley, 1998.
2. Jacobson, I., G. Booch and J. Rumbaugh. The Unified Software Development Process. Reading, Mass.: Addison Wesley, 1998.
3. Jacobson, I., M. Griss, and P. Jonsson. Software Reuse: Architecture, Process and Organization for Business Success. Reading, Mass: Addison Wesley, 1997.
4. Kruchten, P. The Rational Unified Process: An Introduction. Reading, Mass.: Addison Wesley, 1998.
5. Rumbaugh, J., I. Jacobson and G. Booch. The Unified Modeling Language Reference Manual. Reading, Mass.: Addison Wesley, 1998.

Defining our terms Component: A large-scale reusable asset in the broadest sense, a substantial chunk of functionality designed for reuse, such as a subsystem or framework. Facade: A model element that specifies the information application builders need to reuse a component. This element is a packaging of several public UML elements available for imported reuse. The facade effectively hides the inner details of a modeled system. A component can have multiple facades, each presenting a useful and coherent subset of public UML elements available to support some reusable functionality provided by the component. Rational Unified Process (RUP): A widely used de facto standard development process (framework) that defines artifacts, roles and process steps to be followed in architected, incremental-iterative development. Reusable Asset Specification (RAS): A proposed specification of the needed artifacts and their format which is currently under development by a consortium of vendors, sponsored by Rational. Unified Modeling Language (UML): A widely used software blueprinting language standardized under the auspices of the OMG. —Ivar Jacobson and Martin L. Griss