Adding CBD to OPEN

• By Brian Henderson-Sellers
• April 1, 2001

When using the OPEN approach to system development, we start with the metamodel—known as the M2 level in the terminology of the Object Management Group (see Figure 1). The metamodel presents the entities we can instantiate into our process (as shown in Figure 2), a process usually described at the organizational level (M1 level in Figure 1). The instances we create may be our own, or may be selected from a predefined set: predefined Activities and Tasks for OPEN are defined in The Open Process Specification,¹ while predefined Techniques are outlined in The OPEN Toolbox of Techniques.² These predefined Activities can be thought of as belonging to a process component repository (see Figure 3). All these instances are then configured together using the rules of the metamodel, thus creating a personalized sequencing, according to a chosen life-cycle model such as contract-driven, spiral, fountain, waterfall, etc. The configured process instances together form an organizational-level (or M1 level) process. When you ask a company, "What process are you using?," the given relates to this M1 level. Finally, whenever that process is effected on a particular project, with actual individuals filling the roles, real calendar deliverables, and so on, then we have an M0-level process instance (see Figure 1).

Figure 1. Three levels in the metalevel hierarchy for process.

The process component instances (M1) that have been identified in the literature were published as part of the OPEN book series^1,2 as noted above. However, technology is always changing and there were a number of gaps in these books that have been filled in over the last few years. In this and my next few columns, I address some of these gaps. In particular, I address work that has recently been done to add to OPEN (at the M1 level) Activities, Tasks, and Techniques relevant to:

• components
• web development
• usability and usage-centered design
• risk assessment
• personnel and team issues

Figure 2. A process is instantiated from a process metamodel and the instantiated components are then assembled into an organization-specific process.

In addition, a version of the OPEN process framework has been created to address not software or software-intensive system development, but the process by which an industry actually introduces object and/or component technology into their organization. This is called a transition process,³ and I will outline this in a later column.

Figure 3. Process components are stored and selected in a repository using a set of construction guidelines. The result is a personalized OO/CBD process instance highly suitable for the current project.

COMPONENT-BASED DEVELOPMENT
Component-based development (CBD) is no different from traditional or object-oriented development in that it too needs a process—a process by which the particular characteristics of components can be fully exploited. That process is the framework that the creation of the software solution occurs, taking into account a wide variety of issues, including (but not exclusively) project management, organizational culture, individuals' skills, tool availability, quality criteria imposed by the end user/client of the software, and, of course, reuse strategies.

In CBD, we typically focus on the use of encapsulated and plugable components as units of deployable code,⁴ although this definition is extended in Objects, Components, and Frameworks with UML: The Catalysis Approach (Chapter 10)⁵ to include designs, specifications, text documents, etc.—in fact anything that can be described by a UML package. Since components are known almost exclusively by their interfaces,^{4, 6} these must therefore be trusted, clearly specified, and useful. Hence, both unit and integration testing are clearly very important.⁷ Components also need to be "composable," i.e., there must be an easy way of "gluing" them together, requiring minor enhancements or variations in use with current OO modeling languages and processes.

From this 50,000-foot view, the issues of CBD are not that dissimilar from those in object-oriented development, except that there is a greater focus on integration rather than synthesis,⁸ on creating reusable assets, and on obtaining and using previously created components. In comparison with an object-oriented approach, a component package includes definitions of the interfaces it requires, as well as what it provides; components tend to have more complex actions at their interfaces, not just individual messages, and are coarser grained⁵—indeed, a component may contain several objects inside it. Components are also more static than objects, although both work through polymorphic interfaces.⁵ We can then use existing development processes, such as the ones described here in OPEN, and ask what modifications need to be made in order for them to be equally suitable for CBD.

EXISTING OPEN SUPPORT FOR CBD
The extent to which OPEN may or may not already support CBD can be examined in terms of how many CBD-related issues are covered in its Activities, Tasks, and Techniques. Here we identify the extent of pre-existing support for components, and, in particular, reuse; and then suggest new process element instances to fill in the gaps.⁹

Three of the existing OPEN Tasks¹ focus on reuse. These are immediately applicable to CBD, although they require additional comment and discussion focused on components, as well as objects.

1. Create and/or identify reusable components ("for reuse").
2. Optimize reuse ("with reuse").
3. Manage library of reusable components.

"For reuse" focuses on the creation of reusable assets. Domain-wide thinking is needed, together with additional effort that must be expended to bulletproof the components. "With reuse," on the other hand, takes those existing, well-crafted components and advises how they can be used in the present project.

Barriers to successful reuse of components are partly sociological because developers are often reticent in considering the use of someone else's code, and partly based on the widespread belief in the myth that reuse occurs for free simply by using inheritance. At a technical level, reuse is just as likely (probably more likely) to result from the use of some form of composition or "aggregation"—this is particularly true for components. Therefore, we should note in passing that there are difficulties in using or adopting UML's notions of aggregation and composition to components.¹⁰ Thus, fixing UML's composition support is more crucial in CBD than in OO software development. Proposals are already scheduled for the UML Version 2.0 committees.

Lastly, component repository management is a little different from managing a library of classes for OO development. There is, however, another Task in OPEN: "Develop software development context plans and strategies" that has existing subtasks to establish plans and strategies. None of these address the organization's (or team's) policy on components—clearly an extension will be needed.

In addition to the three pre-existing OPEN Tasks discussed above, there are also a significant number of Techniques in OPEN relevant to component usage. The most relevant are those that focus on reuse, and they include:

• library management
• library class incorporation
• reuse measurement

together with a number of more technical techniques not solely focused on components or reuse. These include (in alphabetical order) application scavenging, CIRT indexing, completion of abstractions, domain analysis, framework creation, genericity specification, idioms, mechanisms, pattern recognition, and revision of inheritance hierarchies (generalization for reuse).²

EXTENDING THE SUPPORT
In this section, we focus primarily on the "with reuse" aspects of component-based development, deferring the issues of how to build these components until later. Some good advice on component creation as well as component utilization can be found in Objects, Components, and Frameworks with UML: The Catalysis Approach.⁵

It is clear that OPEN needs to augment existing Tasks and/or to include new Tasks and Subtasks that are specifically focused on component selection and use. Creating applications from preexisting components is a prime example of "with reuse." Currently in OPEN, this focus area is described by a Task that relates to activities such as domain analysis and application build. For OO application development, this has been adequate. However, for CBD, the whole focus of acquisition and integration of components (including Commercial Off the Shelf [COTS]) is really a parallel for (at least part of) the Build Activity of software applications development. OPEN's support for "with reuse" has thus been elevated⁹ to the level of an Activity rather than a Task. In so doing, it was renamed "Component Selection." This new OPEN activity has three associated tasks. These are based on the work of Kuruganti.¹¹

1. "Screen the candidate list of components."
2. "Evaluate the potential components."
3. "Choose appropriate components."

It then remains for appropriate Techniques to be identified to fulfill these tasks and, if necessary, to identify and add any such missing techniques to OPEN's "Toolbox."² Secondly, outsourcing is increasing, resulting in companies having to evaluate the utility of COTS packages. It is thus opportune to include in OPEN a discussion of COTS Selection under this same "with reuse" Activity (Component Selection). This is especially useful because the three Tasks identified for components are equally viable for COTS selection—we just need to consider COTS software as being analogous to a large component.

Lastly, we note the need for a new Task: "Integrate Components" that describes how the selected components and/or COTS are synthesized into the application. This may be a substitute or a complement to the existing OPEN Task: "Code."

ACTIVITY: COMPONENT SELECTION
Component selection is described as finding pieces to fit into an underlying jigsaw puzzle, identifying not only the required component(s) but also the necessary granularity.¹²

For OPEN's Component Selection Activity, we utilize ideas of Kuruganti.¹¹ Her methodology for component selection stresses the need to evaluate various vendor offerings of components in identifying the best-fit solution for your particular problem, noting that this may be difficult because of a lack of understanding of components, framework, and architecture issues; incomplete understanding of functional requirements and deployment constraints that must be met; and inhomogenously packaged offerings from different vendors.

Each of the three new tasks identified as being supportive of this new Component Selection Activity has pre-specified inputs and outputs,¹¹ as well as roles, primarily of the people involved. Each is also said to operate across three dimensions: functional specifications, operational/performance attributes, and deployment factors.

TASKS TO SUPPORT COMPONENT SELECTION ACTIVITY
Task: "Screen the candidate list of components"
The goal of this Task is to identify vendors and available components. These are then screened against a list of requirements (which also may simultaneously evolve). The pre-conditions relate to the draft specification for required features (services) of the components, performance constraints, target platforms, and expectations from vendors regarding business alignment. The post-conditions are a ranked list of screened components, possible revisions to requirements, and refined component specifications. Producers involved with this task include system designers, system architects, and product managers.

There are also a number of subtasks:

• Gather information on candidate components (which selects OPEN Techniques from those already found useful in requirements engineering).
• Select candidate components.
• Gather preliminary cost information on selected candidates.
• Product first (rough) assessment (which uses the new OPEN Technique: "Checklist").

Task: "Evaluate the potential components"
The goal of this Task is to undertake a full evaluation of the candidates identified in Task: "Screen the candidate list of components." The pre-conditions are thus equivalent to the post-conditions of that Task. The post-conditions include evaluation results from each candidate component, revisions to software architecture and component specifications, and finally, a ranked list of vendors and their components. The producers involved are software developers, designers, and systems engineers.

Appropriate subtasks are:

• Generate a compliance matrix (which uses a new OPEN Technique: "Compliance Matrix Template").
• Execute vendor-supplied examples in test mode.
• Obtain independent benchmark data (optional).
• Develop and test context-specific examples.
• Document results of component evaluation.
• Document interactions with vendor.
• Rank the candidate components (which uses the OPEN Technique: "Checklist").

Kuruganti¹¹ notes that this task is crucial for CBD and should be conducted extremely diligently. She also notes that if one component (and vendor) clearly stands out from the rest, then the decision-making process Task: "Choose appropriate components") is obviated.

Task: "Choose appropriate components"
For this, a decision-making task, we need to choose the most appropriate component(s). This task is only needed if there is no clear winner already. The pre-condition is equivalent to the post-condition of Task: "Evaluate the potential components." The post-conditions include a decision on the "make or buy" question and, in the latter case, the recommended vendor. Additionally, risk assessments should be attached to any decision. A mitigation plan is optional (see OPEN Subtask: "Develop contingency plan"¹). Producers involved are technical and product managers, as well as system architects.

There are a number of appropriate subtasks:

• Compile a list of critical components.
• Compile list of individuals' assessments of the candidate components.
• Arrive at overall score and ranked list (probably using a normalization/weighted aggregate approach).

Subtask: "Establish policy on components, COTS, and outsourcing"
In the documentation on OPEN,¹ one of the major project management (PM) Tasks is "Develop software development context plans and strategies." Existing subtasks focus on various plans (e.g., contingency, security) and strategies (e.g., change management). One additional subtask focusing on CBD is needed: Subtask "Establish policy on components, COTS, and outsourcing."

The use of software elements from elsewhere is often influenced by both individual and corporate mindsets. There is too often a wariness about using other people's work—although thankfully this is beginning to change. As a supply of high-quality components continues to become available in the marketplace, so the trend toward COTS software and/or components will likely increase. At the same time, an increasing number of organizations are now outsourcing their IT. This means that by downsizing the in-house IT skillset, more emphasis must be placed on developing skills related to testing and evaluation of third-party software. Policies need to be developed regarding evaluating the quality levels of suppliers. This has been one of the elements in a Total Quality Management (TQM) approach in manufacturing for many years, but often requires a time interval in which to build up mutual trust. In other words, "buy or build" decisions need to be made, either on a high level (as a departmental policy) or on a per-project basis.

SUPPORTING TECHNIQUES FOR COMPONENT SELECTION TASKS
The introduction of these new OPEN Tasks and subtasks requires three new, compatible techniques. These are QESTA,¹³ checklists, and compliance matrix templates.

New OPEN Technique: QESTA
QESTA stands for:
Quantification—define the metric for each characteristic to be evaluated.
Examination—values for each metric are found for each product under examination.
Specification—values are interpreted as "good" or "bad."
Transformation—values are normalized.
Aggregation—an algorithm is used to create a single number from the set of values from the Transformation step.

QESTA¹³ seems an excellent candidate to be an OPEN Technique. It is useful not only for evaluating COTS (as originally proposed in "A Generic Process and Terminology for COTS Software"¹³), but also for evaluating components, as required here. Indeed, both COTS and component apps are discussed in the new OPEN Task: "Evaluate the potential components."

New OPEN Technique: Checklist
The idea of using a checklist of criteria is straightforward. A list of appropriate criteria is compiled and importance levels are assigned: e.g., critical (must have), preferable (nice to have), and optional. The actual criteria used depends on the Task to which this Technique is applied. For example, Kuruganti,¹¹ provides specific checklist criteria useful for the three tasks described earlier.

New OPEN Technique: Compliance Matrix Template
In a compliance matrix, the features of interest are listed in a column on the left-hand side, and the performance criteria is listed along the top (typically). Then for each feature, each of the performance criteria is evaluated as met or not met. Ticks or crosses are put in the matrix elements and an overall visualization is constructed to evaluate whether or not (or to what extent) the proposed component complies with the requirements.

New OPEN Task: "Integrate Components"
Since components already exist, they do not need to be coded. In other words, the OPEN Task: "Code" is redundant. Rather, components need to be integrated together or composed. In essence, this is coding at a coarser granularity. The interfaces of the components would ideally be immediately plugable, but in many cases, "glue" will need to be written, perhaps using a scripting language or creating some other form of inter-component "adapter."⁵ Existing OPEN Subtask: "Integrate with existing, non-OO systems" is also clearly relevant here.

SUMMARY
Although originally formulated for OO software development, the OPEN approach has shown to be useful for CBD. However, to provide adequate support for CBD, additional Activities, Tasks, and Techniques have required formulation, while older ones have required some minor enhancements. The modular and metalevel definition of OPEN facilitates making such extensions.

ACKNOWLEDGEMENTS
This is Contribution #00/13 of The Centre for Object Technology Applications and Research (COTAR).

REFERENCES

1. Graham, I., B. Henderson-Sellers, and H. Younessi. The OPEN Process Specification, Addison–Wesley, Harlow, UK, 1997.
2. Henderson-Sellers, B., A.J.H. Simons, and H. Younessi. The OPEN Toolbox of Techniques, Addison–Wesley, Harlow, UK, 1998.
3. Henderson-Sellers, B., and M. Serour. "Creating a Process for Transitioning to Object Technology," Proceedings Seventh Asia-Pacific Software Engineering Conference (APSEC) 2000, IEEE Computer Society Press, Los Alamitos, CA, 2000. p. 436–440.
4. Szyperski, C. Component Software, Beyond Object-Oriented Programming, Addison–Wesley, Harlow, UK, 1998.
5. D'Souza, D.F. and A.C. Wills. Objects, Components, and Frameworks with UML: The Catalysis Approach, Addison–Wesley, Reading, MA, 1999.
6. Digre, T. "Business Object Component Architecture," IEEE Software, 15(5): 60–69, 1998.
7. Weyuker, E. "Testing Component-Based Software: A Cautionary Tale," IEEE Software, 15(5): 55–59, 1998.
8. Seacord, R.C. and K.C. Nwosu. "Life Cycle Activity Areas for Component-Based Software Engineering Processes," TOOLS 30 (eds. D. Firesmith, R. Riehle, G. Pour, and B. Meyer), IEEE Computer Society, Los Alamitos, CA, 1999, p. 537–541.
9. Henderson-Sellers, B. "An OPEN Process for Component-Based Development," Chapter 23, Component-Based Software Engineering: Putting the Pieces Together (eds. G.T. Heineman and W. Councill), Addison–Wesley, Reading, MA, 2001.
10. Henderson-Sellers, B. and F. Barbier. "Black and white diamonds," >'99—The Unified Modeling Language, Beyond the Standard (eds. R. France and B. Rumpe), Lecture Notes in Computer Science 1723, Springer–Verlag, Berlin, 1999, p. 550–565.
11. Kuruganti, I. "A Component Selection Methodology with Application to the Internet Telephony Domain," TOOLS 30 (eds. D. Firesmith, R. Riehle, G. Pour, and B. Meyer), IEEE Computer Society, Los Alamitos, CA, 1999, p. 552–556.
12. Unhelkar, B. "Effect of Granularity of Object-Oriented design on Modeling an Enterprise and Its Application to Financial Risk Management," Ph.D. thesis, University of Technology, Sydney, Australia, 1997.
13. Hansen, W.J. "A Generic Process and Terminology for Evaluating COTS Software," TOOLS 30 (eds. D. Firesmith, R. Riehle, G. Pour, and B. Meyer), IEEE Computer Society, Los Alamitos, CA, 1999, p. 547–551.