Martin L. Griss, Laboratory Scientist
Software Technology Laboratory, HP Laboratories
Tel: (415) 857-8715
Email: griss@hpl.hp.com

(Draft of column to appear in Fusion Newsletter, Feb 1997)

In my second column, I continue the discussion of systematic software reuse by describing a collaboration with Ivar Jacobson to develop a coherent approach to structuring architecture, process and organization for effective object-oriented reuse. Ivar and I have worked together since 1994 [Griss95,Griss96] to integrate techniques of systematic software reuse into his Object-oriented Software Engineering process (OOSE)[Jacobson92], to make large-scale systematic reuse a practical reality. We call our approach the "Reuse-Driven Software Engineering Business" (RSEB). An RSEB is a software development organization structured to employ systematic reuse as a key business strategy. Details are in our forthcoming book, co-authored with Patrik Jonsson, "Software Reuse: Architecture, Process and Organization for Business Success" due to be published by Addison-Wesley in April 1997.

In this and future columns, we will describe the essential parts of the RSEB, and how some of these ideas might find their expression in the framework of Team Fusion[TF96].

In my previous column[Griss96a], I described the 10 rules of successful reuse. These success factors can be rephrased and regrouped to high-light a more systematic framework for successful, large-scale reuse effort:

Reflecting upon these factors as I came to understand the magnitude of the changes needed to install systematic reuse, it became clear that we should adopt a business reengineering approach to restructuring a software engineering organization for large-scale reuse[Griss95]. This in turn encouraged me to build upon an OO method that could deal not only with architecture, but also with process and organization design – and this is how I came to work with OOSE and Ivar Jacobson[Griss96]. We base our collaborative work on Jacobson’s use case driven architecture and process modeling frameworks — Object-Oriented System Engineering (OOSE)[Jacobson92] and Object-Oriented Business Engineering, described in "The Object Advantage"[Jacobson94].

By so doing, we have integrated the key aspects of successful reuse programs into a coherent model. This approach relates all processes (activities and supporting infrastructure) and products (architecture and components) to the business goals of a reuse driven software engineering business.

Our systematic approach has the following elements:

The RSEB is run as a software engineering business. This means that the information technology and software engineering goals are key to accomplishing the enterprise business goals, and that as a consequence, the software organization itself is operated as a business, with well defined customer and financial objectives. As a reuse-driven software organization, this organization is engaged in producing multiple, related applications, centered and optimized on the production and reuse of components. These applications commonly form a product-line or product family. As a business, this organization must understand its customers, and serve their needs, while at the same time effectively achieving its profit and expense objectives. Such business tradeoffs are managed using economic, product and process measures.

Figure 1 summarizes the key elements of the RSEB, using an informal OO business engineering notation. The ellipses are business use cases, representing software engineering processes, while the rectangles represent systems or models. The stick figures are actors, representing people or organizations the RSEB interacts with.

Figure 2 The basic architecture on which a Reuse Business rests is three layers of components that go into the application systems at the top of the diagram.

The Reuse Business uses an extended OOSE modelling notation and process to provide support for architecting reuse-oriented applications and components. New constructs support layered, modular architectures, in which application systems are built from a combination of concrete and abstract components. Related components are grouped into component systems, which are essentially frameworks or collections of related components such as use cases or Java classes. New mechanisms make explicit the commonality and variability crucial to effective engineering of components for families of systems. These variability mechanisms facilitate the a form of domain-engineering. Object-Oriented Business Engineering techniques are applied to the target organization to identify business objects and application families that support customer business processes.

Utilizers construct an application by selecting component systems and integrating them together into an application system. They may specialize or augment the component systems to adapt them to the new application. Thus, an application system is a set of customizable and configurable software elements. In some cases utilizers may have to supplement the reusable components with newly developed software.

As we have described before, the key to effective reuse is a family of related applications. Such families typically possess a commonality that is exploitable by reusable components. They can be implemented from a set of lower level components. At the same time, the applications, while related, also have differences. These differences mean that the components have to have the capability of being varied to accommodate the differences.

The three lower layers of the architecture Figure 2 are each composed of components, grouped into sets called component systems. Utilizers employ components to put together application systems. When we look at this operation more closely, we see that it makes sense to have something larger than a small component to work with. We need a larger aggregation of components that can be more easily handled by utilizers. That something larger is a component system. Also, looking closely, we see that utilizers don't need complete information about a component system. Complete information might be overwhelming. Utilizers need only a subset of the information, necessary to assemble the component systems into an application system.

We use the term component to refer to an element of a development model that meets two criteria: It is loosely coupled to other elements; it promises to be reusable. All software life cycle workproducts are potentially components or sources of components. These workproducts include, not only any of the models we use, but also interfaces, tests, and the source code itself. In our conception, a component is very general, and include OCXs, Ada packages, C++ components, and use cases. Some components are fairly formal and structured; some are operational code or tools; others are process descriptions or even less formal documents.

We use the term component system to refer to a set of related components that accomplishes some function larger than a single component does. Instead of tracking thousands of elements, a utilizer can restrict his scope to a few hundred components, packaged into a relatively small number of component systems.

In order to manage the interfaces between component systems, we only export a subset of the information for use by utilizers. This is done by publicizing subsets of components through one or more facades. Each facade exports to a utilizer only those aspects of the entire component system that she needs to reuse it. We think of it as a simplified model of the component system, revealing only those parts that need to be directly visible or need to be understood by the utilizer.

Some components or component system are used "as is." They do not need to be specialized and are consequently, when they matches the problem, are easy to reuse. More abstract components or component systems contains at least one of a variety of specialization mechanisms. A utilizer exploits this mechanism to adapt the component to the particular application. This adaptation effort imposes a little work on the utilizer, but it greatly expands the number of applications to which he or she can apply the component system. If we made no provision for variance, we would have to resign ourselves to the burden of the very large number of "concrete" component systems.

In general, we build the larger applications as layered systems with a modular, layered architecture. Each layer in the system is constructed from an appropriate (set of) components drawn from several component systems in lower layers. An application explicitly imports components from the component-system facade. Exports, imports, and facades work together to support both layering and modular pluggability.

We implement traditional object-oriented frameworks as component systems. These systems have "slots" into which a utilizer may plug components to augment their abilities. Or, they may be specialized by using inheritance or several other mechanisms.

In this layered architecture, each application is represented as a separate system. Each is constructed from components organized as component systems. Each component system, in turn, may be constructed from other, lower level component systems, as illustrated in Figure 2. The utilizer constructs each application, which is distinct, but related, from a set of application domain, business-specific components or component systems in the top layer. They can also directly reuse some components from lower layers, such as utility classes defined in middleware or system software layer. The business-specific components, in turn, use components from lower layers.

This layered architecture is a mental model that enables each person in the reuse business to understand the practice of engineering application systems from component systems. By having distinct layers, and clear interfaces between them, this architecture allows platform-independent interfaces to distribution and interoperability mechanisms in the middleware layer. Well defined, stable interlayer interfaces provide openness and flexibility. Finally, the architecture allows component systems to evolve independently, as new technologies and opportunities arise.

The Reuse Business model applies business engineering to the software engineering organization itself. The Object-Oriented Business Engineering framework [Jacobson94] provides a consistent, systematic approach to the organizational and process issues. Business use cases model the key software development processes, component engineering and application engineering. Business use cases model the interaction of persons with the software organization. These models then define the roles of reuse workers, to produce a reuse-oriented software organization structure that meets the needs of specific software development organizations. A business reengineering transition framework and change management techniques are used to systematically restructure a software development organization into a reuse business.

Use-cases are used to model the interaction of an actor (person or external organization) with the subject organization. Use-case and object models help identify core processes within the organization. When these models are further refined to produce a robustness model (with boundary, control and entity objects), we are able to map these onto processes (control objects), workers (interface objects) and information systems (entity objects). Factoring and subsystem packaging techniques at the OOBE model level allow us to introduce and model organizational grouping.

The Reuse Business links previously independent projects, introduces new architectures, changes the development processes, requires reusable component management and funding activities, and changes the roles of architects, process engineers, development engineers, and managers. Thus significant organizational change is involved.

The RSEB also defines several incremental, iterative reuse-driven software engineering processes, corresponding to the asset creation, utilization, management and support processes described in the previous column[Griss96a]. The most important of these RSEB processes are Application Family Engineering, Component System Engineering, and Application System Engineering. Application family engineering starts from a set of use cases defining services provided by a set of related applications. These lead to an overall layered architecture, a set of component systems, and the interfaces and relationships between them. Component system engineering designs and implements each component system, and application system engineering builds applications from these component systems.

The essence of systematic software reuse is the creation of component systems by one or more teams, and their reuse by other teams. Instead of building each related applications independently, from scratch, the organization purposely and proactively creates reusable assets, which are then utilized to build these applications more rapidly and cost effectively.

Developers employ a number of software engineering processes and support environments (tools) to create application systems and families from component systems.. We group these processes into three categories: Component Systems Engineering, Application Systems Engineering, and Application FamilyEngineering, each shown as an ellipse in Figure 1. The engineering of component systems and application systems consists largely of traditional software engineering processes, augmented as appropriate for reuse. The overall system architecture is created by the application family engineering process. A key goal of this process is to identify the architecture and a set of component systems that will support the suite of applications to be built. The overall management of the reuse business is also shown as a process Managing the Reuse Business, not described further in this column.

Object-oriented business engineering is used to model these software development processes. Business use cases model the interaction of persons with the software organization. These models are then refined to define the roles of reuse workers, and customized to produce a reuse-oriented software organization structure that meets the needs of specific software development organizations. A business reengineering transition framework and change management techniques are used to systematically restructure a software development organization into a reuse business.

The Application family engineering process determines how to decompose the overall set of applications into a suite of application systems and supporting component systems. The process architects the layers, facades and interfaces of the subsystems and component systems that support the complete family of related applications.

We call the designer of a family of application systems an architect. The architect faces a larger task of understanding requirements than the designer of a single system. He or she has to find out, not only what current users of similar systems now know they need, but also what potential users and customers now think they might want in the not entirely known future.

The architect then develops the layered architecture, introducing structure to make the architecture robust enough to survive the inevitable changes systems such as these undergo. Individual application and component systems become visible.

Existing software, such as large legacy systems, often millions of lines of code, and vendor systems must be considered. The architect has to include these existing elements within his plans. Developers incorporate legacy systems and purchased systems with the components and component systems that all together make up the sources from which application engineers can put together a family of application systems.

In other approaches to reuse, effective component system engineering relies on an activity historically called "domain engineering"[Arango94] described below to determine an architecture and set of components. The RSEB does not have an explicit domain engineering process, but distributes key domain engineering-like activities between the Application Family Engineering and Component System Engineering processes.

The Application system engineering process selects, specializes, and assembles components from one or more component systems into complete application systems. It uses appropriate tools, methods, processes, and instructions provided explicitly with the component system

Application systems engineering begins when an customer requests a new version of an application system. Developers first elicit and capture the requirements from a few sources, primarily the customers and the end-users. Then the developers try to express the requirements in terms of available architecture and component models. Certain requirements are met by directly reusing some components or specializing others. If the overall systems architecture is well designed, and if a comprehensive set of component systems has been made available, developers should usually be able to find an appropriate component to reuse. In the (hopefully less common) case where no appropriate component is available, they may have to seek a new component or even develop a model and software to meet the requirement themselves.

The next step is to implement an increment of the eventual application system. The increment should be large enough to be workable. In the case of models early in the development stages, "workable" may be a matter of judgment. In the case of code, "workable" means a portion of the eventual system that developers can run and test.

The final step comes, in some cases, during the life of the application system. User complaints or infrastructure changes may send the system back for improvement.

The Component system engineering process designs, constructs, and packages components into component systems. The process will use appropriate code, templates, models, dictionary, documents, and perhaps custom tools. In many respects the actual process of component systems engineering is similar to that of application systems engineering. The process begins when a reuse business needs to create a new component system. The first step is to collect and analyze the requirements about both needs and trends from a wide range of sources. The sources include business models, architects, domain experts, and application users. The goal is a consistent model that explicitly expresses commonality and variability across the suite of applications that will reuse these components. Using techniques for cost/benefit estimation, developers decide what functionality should be incorporated in the component system.

In addition to concrete components that will be reused as is, many components must be designed to be specialized. In addition to inheritance, other mechanisms based on problem-oriented languages, parameterized templates and generators[Bassett96] can be used.. Components can range from a very simple set of code elements and interface models to a very complex set of code elements, templates, tests, and scripts.

Next, the component systems engineers architect, and incrementally design, implement, and test the component system. The process concludes with the certification and packaging of the component system for. retrieval by utilizers.

The systematic transition of a existing software organization into an RSEB is based on the OO Business Engineering BPR framework[jacobson94]. This has several stages that prepare, define and execute a transition:

• Management directive to reengineer
• Envisioning the new organization
• Reverse engineering the existing organization
• Forward engineering to develop the detailed model
• Installing the new processes and organization

Into each of the steps, we have added several organizational change management guidelines, such as the role of stakeholder identification, champions and pilots, and some of the reuse pragmatics, such as incremental, pilot driven reuse adoption, and distinct reuse-maturity stages, as discussed in the previous column[Griss96a]. To develop the appropriate roadmap, it is important to assess both the clarity and urgency of the business and domain drivers, as well as the organization and process maturity.

Component system creation is based on an activity called domain engineering in the software reuse community[Arango94]. This involves the identification and development of reusable assets within an application or subsystem "domain." A domain is the space in which a family of related systems can be effectively built using some form of reuse.

In the RSEB, a form of domain engineering is distributed between the Application Family Engineering and Component System Engineering processes.

As summarized in Figure 3, domain engineering is concerned with identifying the commonality and variability in the chosen problem and solution spaces, and expressing the domain structure in terms of a system and component architecture, and a set of appropriately generalized components.

Applications are then built by taking advantage of the reusable assets, but are constrained to stay largely within the architecture and domain models covered by the asset base. A typical application usually consists of components drawn from several different domains.

Since the creation of reusable components is more expensive than "ordinary" system development, we only should develop components when an economic or business reason for reuse can be seen, and when we are sure that the resulting component systems will be reused multiple times. We should not simply guess at supposedly reusable components, nor should we simply extract and reengineer them from existing applications. The guesses are usually quite poor, and the components will not work well together, nor support effective applications development. The goal of the RSEB is to identify the domains and high-payoff components in a systematic way.

Several different styles of domain engineering have been developed[Arango94]. Each style depends on the nature of the domain, and the software processes and technology to be used. Some methods focus on how to identify the domain effectively, using available domain, architecture and systems expertise. Others focus on how to select existing examples for detailed analysis, or on how to collect, represent and cluster feature sets.

The RSEB uses a systematic process to design an architecture and reusable component systems. We use OO business engineering to analyze business needs and processes, which then leads to the design of a coherent suite of applications to implement the information systems needed to support the business[Jacobson94]. Business use cases define the processes, and provide a unifying framework to integrate the various applications into a coherent business system. We analyze the business criteria, and capture supporting rationale, models and architectures to enable better decisions to be made, recorded and revisited for future improvement. Example systems, user needs, domain expertise and technology trends are analyzed to identify and characterize features that are common to all family members, and other features that vary between family members.

Application systems engineering is then driven by the resulting components, and by the overall architecture, models and documentation that describe the domain.

In the RSEB we use OOSE as the basic model-driven OO software development process. We have extended OOSE with several constructs and activities. These extra activities involve iterative cycles over steps found in all domain engineering methods, such as:

The goal of application systems engineering is then to rapidly and/or cost effectively develop conforming applications, constrained to the domain architecture and taking maximum advantage of the available component systems. The steps are summarized in Figure 3.

In addition to component systems and facades mentioned above, the RSEB extends OOSE with a richer set of mechanisms to express variability. Sub-classing (inheritance) is simply not powerful enough to produce compact and flexible components.

In the implementation languages chosen, such as C++, JAVA or Visual Basic, inheritance can be augmented or replaced by combinations of parameters, aggregation, delegation, structured exception trapping, macros, generators and templates to express the needed variability. For example, Microsoft Wizards are simple template-driven generators, while NETRON/CAP[Bassett96] provides a powerful frame editing language which executes editing commands in hierarchically linked templates.

We have added analogous variability constructs to our RSEB modeling language. In the Unified Modeling Language (UML) terminology, we have extended the set of «generalization» stereotypes available[Booch97] in OOSE. We have defined the a Variation Point construct, as a place within a model element at which a specializing Variant can be applied using some mechanism. Classes containing variation points are usually incomplete and require an attached variant before being usable. Variants are usually fragments of classes, text strings or parameters, used to complete the class containing the variation point.

In diagrams, such as the use case and analysis models shown in Figure 4, we indicate the variation point by a solid dot, labeling it by {Variation point description}. These notational markers can appear in any class, such as use cases, actors, analysis objects and design objects.

In general, it is useful to imagine that a copy is made of the class body containing the variation point, and then the variation point definition text or structure is the replaced by some other text or structure. The replacement is obtained either by directly inserting a parameter or reference to the variant, or by computing some transformation using the variation point definition body and the supplied variant. For example, inheritance behaves as if the subclass was a complete copy of the superclass, but with the virtual operations replaced or overridden by the supplied operations.

Figure 4 shows a use case component for part of a simple banking example with three variation points, and two specific variants associated with the{Account overdrawn} variation point. Corresponding to this use case component and variants we also show several analysis components with related variation points and variants.

We have identified several useful ways to represent variability, and have been able to express each of those as particular stereotype of generalization. Each mechanism has its own way of applying or attaching the associated variant. These mechanisms include inheritance, parameters, uses, extends, templates and generation. For example, in a use case description corresponding to the diagram in Figure 4, the variation point might be a distinguished location, such as {Account overdrawn}. A variant using an «inherits», «extends», «uses», «parameterizes» or other generalization or association will replace this text of the variation point.

This is more than a just a generic name for all of the aforementioned mechanisms. The key is that each variation point is explicitly defined, and carefully documented with constraints on the specific variants that can be attached, how these are to be used, and how to write new variants. Also, variation points and variants in one model will possibly be related to other variation points and variants in this model, as well as having a defined mapping to corresponding variation points in other models. Tools will use hypertext-like links to connect these together in a useful way.

Because Team Fusion is to be based on a core subset of UML 1.0[Booch97], it should be relatively easy to adopt the same architectural constructs, with the same meaning: components, component systems, facades, patterns and layered architectures. We should be able to use essentially the same way of representing variability, described in this column.

Instead of using the OO business engineering framework to do our business-driven domain engineering, we can use a light-weight synthesis of the current HP domain engineering process [Cornwell96], the feature oriented FODA[Kang90] and ODM[Simos95]. In the same way the domain-engineering steps have become part of the RSEB processes of AFE and CSE, these steps will become an extension to the Team Fusion process - in fact, we will have a version of the (early phase) EVO Fusion process for architecting systems and developing components to create reusable assets, and a version of the (later phase) EVO Fusion, for application construction from reusable assets.

In our next column, we will continue with a discussion of the mechanisms and processes that support systematic reuse in the RSEB and Fusion. We will see how reusable components and variability in one model are traceable to others, and how frameworks and patterns are related to abstract subsystems and use cases.