Accelerating J2EE Development with Rational XDE

by Khawar Z. Ahmed

Rational XDE Technical Marketing

Rational®XDETM provides a truly seamless integrated visual modeling environment within the most popular Integrated Development Environments (IDEs). But there is a lot more to Rational XDE's capabilities than just automated code generation and effortless model/code synchronization. To get full benefit from Rational XDE, you need to understand its powerful internal J2EE design patterns and code templates, which you can either use as is or customize. This article illustrates how to use these Rational XDE capabilities by walking you through a simple J2EE project.

Sample Application Overview

To illustrate how to use Rational XDE's unique capabilities, we will implement portions of a simple Web-based loan management application that allows loan owners and loan administrators to perform a few simple tasks:

Loan Owners

● Make payments online.

● View amortization schedules via the Web.

Loan Administrators

● Set up one or more loans for a client.

● Obtain information about upcoming loan payments due.

We'll assume that we must leverage the existing infrastructure: an IBM WebSphere application server and several databases.

First, we can use Rational XDE's free-form modeling capabilities to communicate broad ideas about the direction of our solution, as shown in Figure 1. Such free-form diagrams offer a distinct advantage: They allow you to continue working within one toolset and to easily integrate planning documents into the project.

Copyright Rational Software 2002 http://www.therationaledge.com/content/nov_02/t_J2EEWithXDE_ka.jsp

Figure 1: Free-Form Diagram Illustrating Broad Outlines of the Solution

Automating Analysis and Design Activities

Once the preliminary planning is done, we can move into analysis and design. Although Rational XDE runs within a software development IDE, it provides all capabilities needed to accomplish traditional analysis and design activities -- use-case modeling, sequence diagrams, and so forth -- right inside the IDE. In fact, Rational XDE comes with the Rational Unified Process® Configuration for Java Developers (RCJD), which provides proven guidelines for Java software development.

Figure 2 shows the initial use-case model of the simple loan management system, arrived at via further elaboration and discussion with the customer.

Figure 2: Use-Case Model for the Simple Loan Management System

For the sake of brevity, we'll follow the progress of just one use case -- Show Amortization -- to illustrate how Rational XDE capabilities come into play during development. The initial sequence diagram, elaborating the basic use-case scenario, is shown in Figure 3.

Figure 3: Sequence Diagram to Elaborate Show Amortization Use Case Basic Flow

Obviously, this is a very high-level view of the interaction, covering none of the system's internal workings. The Rational Unified Process suggests using analysis level classes to provide further detail, as shown in Figure 4.

Figure 4: Refined Main Flow for the Show Amortization Use Case

The exact details of how to arrive at this diagram are beyond the scope of this document, but you can consult the first three References listed below for further information. Note that in this case, we've chosen to split the boundary into two pages. A simpler approach might depict all boundary interactions via a single element.

Creating Models with a Custom Pattern

You are probably familiar with design patterns such as Gang of Four patterns and Core J2EE Patterns. These pre-defined patterns are supported by Rational XDE, and we will explore usage of some of the Core J2EE patterns later on in this article. Rational XDE also goes a step farther, however, by providing the capability to define your own custom patterns easily via the UML. Rational XDE's custom patterns capability allows you not only to implement custom designs, but also to automate some tedious aspects of creating models, such as generating multiple use-case flow diagrams. Use cases typically have more than a single flow of events. For example, the Show Amortization use case has at least two flows of events: one for the successful scenario documented above and another for failures that might occur while trying to obtain loan details. Figure 5 shows a custom pattern (UCArtifacts) for generating diagrams for the main (successful) flow of events and two failure flows.

Figure 5: Custom Pattern (UCArtifacts) that Automates the Creation of Use-Case Flow Diagrams

This simple pattern consists of two input parameters; ausecase takes a use-case model element as input, and anactor takes an actor model element as input. The pattern uses the names of these input parameters to create objects by appending the word Boundary, Control, or Entity to the use-case name. These objects are then used to define a skeleton sequence diagram for the main flow diagram and two alternate flow diagrams, based on standard UML diagrams supplied in XDE. It is as simple as creating sequence diagrams for the use case and dragging/dropping the associated objects on to the diagram from the Model Explorer. Each of the two alternate flow diagrams the pattern creates has the supplied Actor, and one each of the boundary, control, and entity objects. We can complete the diagram simply by drawing the required messages between the different objects and deleting any analysis objects that do not participate in the flow.

Arriving at the Design

The initial class diagram for the Show Amortization sequence diagram is shown in Figure 6.

Figure 6: Initial Class Diagram for the Show Amortization Use Case

This diagram shows the basic roles needed to fulfill key requirements but does not consider classes that participate in implementing other use cases. To arrive at a unified analysis model, we would need to analyze those other use cases in a similar manner and then combine the results. At this stage, however, our primary goal is to identify and eliminate duplicate classes and merge the ones with similar or overlapping functionality. For instance, we could merge the Amortization Control object with the MakePaymentControlobject to arrive at a single Controller object that can handle multiple use cases. As we are focusing on the Show Amortization use case, we will not

show all of these operations here, but you can consult the first three References listed below to learn more.

Implementing the Solution in J2EE

So far this discussion has been mostly implementation-technology independent. Now, let's see how the capabilities described above relate to J2EE development. In general, the analysis classes we discussed above map to J2EE technology as follows:

Boundary

● HTML

● JavaServer Page (JSP)

Control

● Servlets

● Session Beans

● Message Driven Beans

Entity

● Entity Beans

● JavaBean

This is a starting point for identifying the right J2EE technology to use in developing your application. Because different technologies can be used to implement similar solutions, the best choice will depend on your implementation details and requirements.

Core J2EE Patterns

Regardless of the problem you are facing, if you are implementing a J2EE solution, I strongly encourage you to learn and use the core J2EE patterns as part of your everyday development efforts. And of course, you can create your own custom patterns that either utilize the core J2EE patterns or customize them to make them more suitable to your needs. A collection of best practices and design strategies assembled by the Sun Java Center, these patterns are based on proven techniques identified in real-world J2EE projects. Rational XDE provides a robust implementation of all fifteen patterns (see Figure 7). 1

Figure 7: Core J2EE Patterns

Now, let's see how you can leverage two of these core J2EE patterns -- Service Locator and Front Controller -- in Rational XDE.

Leveraging the Service Locator Pattern

J2EE Components use the JNDI (Java Naming and Directory Interface) to look up and create EJB and JMS components. A problem arises when many types of clients repeatedly use the JNDI service, and the JNDI code unnecessarily appears multiple times across these clients.

To address this problem, you can use the Service Locator pattern, which uses the Service Locator object to abstract all JNDI usage, thereby hiding all the complexities of initial context creation, EJB home object lookup, and EJB object re-creation. Clients simply reuse the Service Locator object to reduce code complexity and provide a single point of control.

Figure 8 shows how the Service Locator pattern is used in the context of a client (e.g., a servlet or JavaBean) and a service provider (e.g., an EJB).

Figure 8: Service Locator Pattern Usage

Below is the simplified code for locating an EJB when using the Service Locator pattern instead of directly looking up the EJB via JNDI lookup.

// locate the amortization EJBAmortizationHome theHome;try {

theHome =(AmortizationHome)sl.getEJBHome("Amort/AmortizationHome"); Amortization theRemote = theHome.create(); // call the remote method on the session bean float totalInterest = theRemote.amortize(……….);

Leveraging the Front Controller Pattern

In a multi-tier system, if a user accesses the Presentation View directly without going through a centralized mechanism, several problems might occur:

● There is often duplicate code because the same resources are accessed by multiple clients.

● Content and view navigation might become intermingled.

● Distributed control might be more difficult to maintain because changes need to be made in numerous places.

For example, as shown in Figure 9, you could use an implementation approach that uses a servlet to process incoming requests, obtain the necessary data from EJBs or databases, and then build the appropriate dynamic response pages. Although this approach is simple, it does present the challenge of coupling between business logic, formatting, and control. It also becomes harder to understand and maintain such an implementation, as each iteration introduces more changes and greater complexity to support the increased functionality.

Figure 9: An Implementation Without the Front Controller Pattern

The Front Controller pattern addresses these issues by managing the request handling, including:

● Invoking security services (such as authentication and authorization).

● Delegating business processing.

● Managing the choice of an appropriate view, handling errors, and managing the selection of contact creation strategies.

The pattern introduces a few additional classes but makes the system easier to manage and evolve over the long term. In the Rational XDE implementation of the Front Controller pattern, a servlet that acts as the controller is responsible for receiving and initial processing of all incoming requests. As it receives the requests, the controller determines what use case the request corresponds to. Then, based on that information, it requests the HelperFactory to instantiate the helper bean associated with that use case and passes on the request to that bean.

Each helper bean is responsible for handling all aspects of a specific use case. The loan management application, for example, has helper beans for the ShowAmortization use

case, MakePayment use case, and so on.

Each helper bean implements the IHelper interface and also the processRequest() method, which forwards requests to the helper beans. When the processRequest() method is invoked on a helper bean, it can work with other entities in the system, such as EJBs, to collect the required data and then initiate the appropriate view handler (e.g., JSP) to format and present the results to the user.

Figure 10 shows a static view of the Front Controller pattern implementation. Note the different helper beans instantiated by the HelperFactory.

Figure 10: Front Controller Pattern Applied to the Loan Management Application

Implementation Details

Of course, the coolest part about the Rational XDE J2EE patterns is that the implementation for each pattern is quite complete; all you need to provide is the business logic specific to your application. In this section, we will look at the specifics you would need for the Rational XDE Front Controller Pattern.

Establish the Relationship Between an Incoming Request and a Use Case. An incoming request (e.g., a form submission) must be easily identified with a specific use case. In the Front Controller pattern implementation we have been discussing, this information would be communicated via a hidden field in the form that is filled with the use-case name at form construction time. When the form is submitted, the controller simply parses the parameters to determine which use case is involved. A default use case function is usually set up to handle requests that do not explicitly identify a use case (see below).

<FORM Name="Form" METHOD="GET" ACTION="Controller"> <p align="left"> <b><i><u>Show Amortization</u></i></b> </p> <p> Enter the following information about the loan: </p> <p> Principal <input type="text" name="principal" size="8" value="250000"> dollars </p> <p> Rate <input type="text" name="rate" size="8" value="10.0"> % </p>

<p> Duration <input type="text" name="termInYears" size="3" value="30"> years </p> <input type="hidden" name="UseCase" value="ShowAmortization"> <p> <input ID="IDCancel" Name="Cancel" Type="reset" Value="Cancel"> <input ID="IDOK" Name="OK" Type="submit" Value="OK"> </p></FORM>

Request Handling by the Controller. There is no implementation work for the controller, as the pattern implementation creates the logic required for extracting the hidden parameter, requesting the appropriate associated helper bean and delegating the processing to the helper bean. Figure 11 shows the static relationship between the pages and the controller. The complete, auto-generated request handling code is shown below Figure 11.

Figure 11: Relationship Between a Form and the Controller

// Check if we have a use case name passed on the URL. String useCase = httpRequest.getParameter("UseCase"); IHelper ihelper = null; if (useCase != null) { // Dynamically instantiate a helper and call it. ihelper = (IHelper)theHelperFactory.create(useCase); if (ihelper == null) ihelper = (IHelper)theHelperFactory.createDefaultHelper(); } else { ihelper = (IHelper)theHelperFactory.createDefaultHelper(); } ihelper.processRequest(httpRequest, httpResponse);

Establishing Use-Case-to-Helper-Bean Mapping. You can establish use-case-to-helper-bean mapping by adding mapping information to the HelperFactory constructor at design time. Sample mapping for the ShowAmortization use case and the SetupLoan

use case is shown in the text box below. This code just needs to be placed in appropriate, pre-defined locations in the HelperFactory constructor at design time.

// establish ShowAmortization use case mapping to its helper classusecasename = "ShowAmortization";classname = "ShowAmortizationHelper";addMap(usecasename, classname);

// establish SetupLoan use case mapping to its respective helper classusecasename = "SetupLoan";classname = "SetupLoanHelper";addMap(usecasename, classname);

Helper Bean Implementation. Clearly, helper bean implementation will vary from one use case to another in this scenario. Generally speaking, however, a helper bean usually needs to extract the appropriate form parameters from the incoming request, coordinate additional information gathering or processing with other participants (e.g. session or entity beans), and then, finally, make the results of the processing available to others (e.g., a JSP) for display. A partial example of this process is shown below. Note that the XDE patterns engine eliminates the need to manually create each helper class. Simply select the "Generated Value" option in the wizard and enter the helper class names in the list. Figure 12 shows a snapshot of this wizard screen.

// extract the info from the request parameter String sPrincipal = httpRequest.getParameter("principal");…..// locate the amortization EJB using the service locator…...// call the remote method on the session beanfloat totalInterest = theRemote.amortize(principal, rate, termInYears); // put data in the AmortValueBean AmortValueBean avb = new AmortValueBean();avb.setPrincipal(principal);…..// set the session attributehttpRequest.getSession().setAttribute("avb", avb);

Figure 12: Automatically Creating the Basic Helper Beans

Displaying the Results. Again, various approaches will work for this. Typically, the data is made available to a JSP that is then responsible for formatting and presenting the information. Figure 13 shows the static relationships involved in one such setup. JSP source code for such an approach is shown below Figure 13.

Figure 13: JSP Relationship with Participants Involved in Format/Display of Data

extracts data from the 'avb' bean instance and formats/displays it<jsp:useBean class="AmortValueBean" id="avb" scope="session"/><b>Results of your loan amortization request: <br>Pricipal entered: <%= avb.getPrincipal() %><br>ýý.Total Payments: <%= avb.getTotalPayments() %><br></b> <p><a HREF="MainLoan.html">Back to Main Page</a>

Code Templates

Code templates are another Rational XDE capability that developers can leverage to greatly simplify their lives. They provide an efficient mechanism for:

● Reusing code snippets and algorithms.

● Sharing code-based solutions to specific problems to achieve uniformity.

● Creating standard headers/comments.

Rational XDE provides substantial support for code templates. In addition to an extensive, built-in infrastructure, it provides the ability to:

● Bind one or more code templates to a method.

● Unbind a code template as needed.

● Reorder the binding order to affect the code generated.

● Parameterize the code template.

In the context of our example, you could create a code template to establish the use-case-to-helper-class mapping. You could then bind the code template multiple times to the constructor and simply provide a different default value for the code template binding to customize the code generation. An example of this is shown in Figure 14.

Figure 14: Code Template for Establishing Use-Case-to-Helper-Bean Mapping

Code templates can be used as part of a custom pattern, so you can create extensive application frameworks with Rational XDE. In fact, Rational XDE internally uses the code templates and patterns capabilities to deliver numerous product capabilities. For example, the code generation associated with getters and setters, design pattern implementations, and so on, all use the code templates capability!

End-to-End Scenario

Now that we have covered the design and implementation details for our sample application, let's recap how all the different pieces fit together. The next two sequence diagrams capture the end-to-end interaction between the different objects, including participants from the two pattern implementations.

Figure 15 illustrates the front end activities: The form is submitted to the controller, which then obtains the helper bean and requests it to handle the incoming request.

Figure 15: Form Submission and Handling by the Controller

Figure 16 is a continuation of the previous sequence diagram (with some overlap). It shows the various actions initiated by the helper bean, culminating in the forwarding of the request to the JSP responsible for formatting and presenting the computation results to the user. Note the use of the Service Locator pattern in obtaining the reference to the EJB required for processing.

Figure 16: The Helper Bean Performs Processing and Presents Results

Patterns and Templates Simplify and Speed J2EE Development

I hope this discussion has conveyed some of the benefits Rational XDE's advanced capabilities offer to J2EE projects. The core J2EE patterns and code templates within Rational XDE provide an easy way to leverage proven design solutions while speeding up product development. Additional Rational XDE capabilities -- such as auto synchronization and the ability to create custom patterns and code templates -- liberate developers from tedious, repetitive tasks and further accelerate development.

References

Khawar Ahmed and Cary Umrysh, Developing Enterprise Java Applications With J2EE and UML. Addison-Wesley, 2001.

Ivar Jacobson, Magnus Christerson, Patrik Jonsson, and Gunnar Overgaard, Object-Oriented Software Engineering. Addison-Wesley, 1992.

The Rational Unified Process, Guidelines: Analysis Class section.

Deepak Alur, John Crupi, and Dan Malks, Core J2EE Patterns. Prentice-Hall, 2001.

Grady Booch, James Rumbaugh, and Ivar Jacobson, The Unified Modeling Language User Guide. Addison-Wesley, 1999.

Notes

1 For more information about these patterns, see Deepak Alur, John Crupi, and Dan Malks, Core J2EE Patterns. Prentice-Hall, 2001.

For more information on the products or services discussed in this article, please click here and follow the instructions provided. Thank you!

Copyright Rational Software 2002 | Privacy/Legal Information

Effective Business Modeling with UML: Describing Business Use Cases and Realizations

by Pan-Wei Ng

Software Engineering SpecialistRational Software Singapore

As most software development practitioners know, the Unified Modeling Language (UML) excels at representing "real world" phenomena. This capability led to development of the UML Business Modeling Profile, which provides extensions and stereotypes to facilitate communication between users and analysts.

Organizations that are thinking about applying the UML Business Modeling Profile often have practical questions, such as:

● When do I really need a business model? When are use-case models alone sufficient?

● Which UML diagrams should I use for particular business modeling situations? How do I know whether to use a sequence diagram or a collaboration diagram, for example?

● How does the UML business model relate to other UML models (domain model, use-case model, etc.)? How should I organize these models?

Unfortunately, the literature that addresses these questions, as well as best practices for applying the UML Business Modeling Profile, is relatively sparse compared to that for system modeling. This frustrates users and analysts who recognize the benefits of using the UML for business modeling but are forced to struggle with the notation.

This article addresses their concerns by walking through an example case that models

http://www.therationaledge.com/content/nov_02/t_businessModelingUML_pn.jspCopyright Rational Software 2002

the acquisition process within an IT department responsible for managing outsourced development. Comprised of legal advisors, enterprise architects, and project managers, the department is responsible for contractual, system architecture, and project management issues. Its mission is to free end-user departments from IT-related issues so they can concentrate on business operations. When these departments need to acquire new systems or enhance existing ones, they get the IT department to prepare tender specifications, and IT then selects suitable vendors to deliver the required system.

The discussion assumes a basic knowledge of the Business Modeling Profile described in the Rational Unified Process® (RUP®). If you're not familiar with this Profile, see the Appendix below.

Doing a Business Use-Case Model Survey

The first step in our simple example is to complete a business use-case model survey. As Figure 1 shows, there are two actors and two business use cases. The End User Manager wants a vendor to automate some processes, so the IT department assists by preparing tender documents and short-listing vendor candidates. Once a contract has been awarded, the procurement department assists the End User Manager by managing delivery of the systems in accordance with the contract's milestones.

Figure 1: Business Use-Case Model

We can summarize the business use cases as follows:

● Prepare Tender: Describes the process for preparing the system

Identifying Business Actors

It is easy to identify Actors for system modeling -- anything outside the system is an Actor, and the boundaries are very clear, so people are always Actors. For business modeling it is not so simple, however, because a person could be either a Business Actor (i.e., someone external to the business who interacts with it) or a Business Worker (i.e., someone internal to the business). A way around this issue is to identify all people involved with the business case before classifying them as either Business Actors or Workers. This means you have to define Business Actors and Workers at the same level of abstraction: They are all either people, or groups of people.

Try not to define any system as a Business Actor, although some systems will become Actors when you derive the system use cases. In business modeling, you want to focus on business processes, so postpone dealing with system issues to avoid cluttering up the business use-case model.

specifications.

● Select Vendor: Describes the selection process, from approval of tender to award of contract award to a vendor that can meet the specifications at a reasonable cost and deliver on a reasonable schedule.

We can summarize the Business Actors as follows:

● End User Manager: The contact person in the end user department that requested the automation.

● Vendor Manager: The vendor's representative who bids for the contract and oversees system implementation from the vendor end.

In our business use-case model survey, the Business Actors are people as opposed to groups of people; that is, we have an End-User Manager as opposed to an End-User Department, and a Vendor Manager as opposed to a Vendor. This is so that the Actors will be at the same level of abstraction as the Business Workers when we later realize the business use cases.

Scoping Business Use Cases

To determine scope of a business use case, I usually trace a core business goal in a single workflow like the one in Table 1. If the use case gets too long, I refine the core business goals into subgoals, segment the workflow accordingly, and divide the long workflow horizontally into several business use cases.

Table 1: Very Long Workflow

The business use case begins when an End User Department requires additional automation to improve operations. The goal of this use case is to select a vendor that can deliver the desired system.

1. Designation of End-User Manager. The procurement department designates an End-User Manager for the entire acquisition process.

2. Prepare System Specifications. The End User Manager prepares and submits specifications to the IT department.

3. Prepare Tender Document. The IT department reviews submitted specifications and prepares a tender document, augmenting the specifications with contractual requirements.

4. Approval of Tender Document. The End User Manager reviews and approves the tender document.

5. Open Tender. Once the tender document is approved, the IT department sends it to a list of vendors for the system category specified.

6. Prepare Bid. Each vendor prepares a bid indicating estimated cost and projected delivery plan, and submits it to the IT department.

7. Short-list Bids. At the end of the tender period, the IT department short-lists candidate bids (vendors) according to the estimated cost and feasibility of the delivery plan.

8. Select Vendor. From the short-list of vendors, the End-User Manager selects the most suitable one.

9. Prepare Contract. The IT department prepares a contract with the selected vendor.

10. Award Contract. Both the End-User Manager and the selected Vendor sign the contract, and more detailed system planning and design begin.

In our example, the core business goal of acquiring a new system is refined into two subgoals

● Specifying the system to be acquired.

● Selecting and evaluating a candidate vendor.

Consequently, the Prepare Tender business use case covers Steps 1 to 4 in Table 1, and the Select Vendor business use case covers Steps 5 to 10 in Table 1. There are many ways to segment the workflow, and it is important to discuss options with the customer. Nevertheless, it is important to recognize that the true value in business modeling lies in understanding how seemingly piecemeal workflows relate to each other.

Doing a Business Use-Case Specification

In this section, we look at how to describe business use cases. The business use-case template in the RUP has a number of sections, but we will focus only on the basic and alternate flows. I will discuss the other sections -- which include goals, risks, possibilities, and so on -- in a future article. Table 2 shows basic and alternate flows for the Prepare Tender business use case.

Table 2: Business Use-Case Specification

Basic Flow for Prepare Tender

This business use case begins when the End User Department requires additional automation to improve operations. The goal is to finalize a tender document that can be issued to candidate vendors.

1. Designation of End User Manager. The procurement department designates an End-User Manager for the entire acquisition process.

2. Prepare System Specifications. The End-User Manager prepares and submits specifications to the IT department.

3. Prepare Tender Document. The IT department reviews submitted specifications and prepares a tender document, augmenting the submitted specifications with contractual requirements.

4. Approval of Tender Document. The End-User Manager reviews and approves the tender document. The use case then terminates.

Alternate Flows

1. System Specifications Invalid. In Step 3, if the IT department finds the system specifications are too vague or unfeasible, the End-User Manager needs to rework the specifications. The business use case then either resumes at Step 2 or terminates if the End-User Manager does not wish to continue.

2. System Already Exists. In Step 3, if the IT department finds that the desired system is very similar to an existing system in another department, then the IT department refers the End-User Manager to that department. If the End-User Manager wishes to proceed with acquiring the "new" system, he or she must put the differentiating features in the system specifications, resubmit the specifications, and continue at Step 2. The business use case terminates if the End-User Manager does not wish to continue.

3. Tender Document Discrepancies. In Step 4, if the End-User Manager notices discrepancies in the Tender Document, it is rejected, and the IT department must rework it. The business use case continues at Step 3.

Business Use-Case Realizations

In this section, we discuss several approaches to realizing business use cases:

● Focus on work processes.

● Focus on process automation.

● Focus on information processes.

The following subsections describe the benefits of each approach, and how the approaches complement each other.

Focusing on Work Processes

We will look at business use-case realizations that focus on work processes involving Business Workers and their responsibilities. As Figure 2 shows, the Prepare Tender business use case has three Business Workers.

● IT Project Manager: The main point of contact with the End-User Manager.

● Enterprise Architect: Assists the IT Project Manager by ensuring that the acquired system will meet organization standards to reduce the complexities of system integrations.

● Legal Officer: Assists the IT Project Manager by supplementing and reviewing contractual terms within the tender.

Figure 2: Business Workers - Prepare Tender

A sequence diagram describing the realization of the basic flow for the Prepare Tender business use case is

Basic and Alternate Flows

A business use case describes a sequence of actions a business performs to produce an observable result of value to a particular Business Actor. It is important to identify the initial condition before initiation of the use case -- as well as the goal of the use case. The basic flow should then document the steps from the initial condition directly to the goal. From the basic flow, brainstorm the different situations that might arise at each step and document them as alternate flows.

During interviews, customers frequently describe many possible situations, which can clutter the analyst's mind and distract him from documenting the main work processes. To avoid this situation, the analyst can document these alternate scenarios in a "parking lot," (i.e., a temporary but visible place for future reference and discussion, such as the corner of a whiteboard) and work singlemindedly on the basic flow. Then, when it is time to identify alternate flows, he can simply pick from these documents in the "parking lot."

Specifications as

depicted in Figure 3.

Figure 3: Business Use-Case Realization for Prepare Tender (Focus on Work Processes)

The messages in Figure 3 can be mapped to the responsibilities of each Business Worker, as shown in Figure 4. This technique is very similar to the technique for conducting use-case analysis, which is precisely why the RUP business modeling technique is so powerful: The same technique can be applied for both business modeling and system modeling.

Process Invariants

Business use-case specifications describe the external perspective, whereas business use-case realizations describe the business's internal perspective. But it is typically not easy for business process analysts to define what is "in" and what is "out." Do you always describe only the interactions between the Business Actors and the business, or do you go into details of the internal operations of the business itself? This is the classical debate on "design requirements" in the use-case community: When are requirements actually requirements, and when do requirements become design?

What I say is, if it is difficult to distinguish between what is in and what is out, why not use business use-case specifications to distinguish process invariants (fixed elements) from what can be reengineered (redesigned)? Then, you can document a selected process variation in your business use-case realization and list other options in the "possibilities" section of the business use-case specification.

Figure 4: View of Participating Business Actors and Workers

Distinguishing Between Events/Actions and Responsibilities/Activities

In business use-case realizations, it is best to use verbs such "prepare" and "review" in the messages and operations, and avoid verbs such as "submit," "approve," "reject," and so on. This is so we can distinguish between events/actions versus responsibilities/activities. Otherwise, we get errors like the one shown in Figure 5.

Figure 5: Error: Events and Responsibilities Have the Same Name

Suppose the End User Manager sends a message -- "submit system specifications" -- to the IT Project Manager, as shown on the left in Figure 5. This implies that the IT Project Manager has the responsibility to "submit system specifications," but that is clearly wrong. The End-User Manager must do this. If we use a reflexive message from the End-User Manager to himself to "submit system specifications" as illustrated in Figure 6, the situation is still awkward. Figure 6 does not show to whom the End User Manager must "submit system specifications."

Focus on Business Actor and Worker Responsibilities

Understanding Business Actor and Worker responsibilities is a very important aspect of requirements elicitation, because we want to build the right system to address their needs and operate effectively within their business context. Often analysts jump straight to system specifications without considering the real

Figure 6: Error: Reflexive Message Does Not Specify Who Receives System Specifications

The recommended solution is to follow message 2 in Figure 3. The submission signifies the completion of system specification preparation. Furthermore, the direction of message 2 also indicates that the system specification is submitted by the End-User Manager to the IT Project Manager.

Figure 7 shows a similar mistake for an explicit "Submit System Specifications" activity. The recommended solution is shown in Figure 8; submission is an event or action that causes a transition from the "Prepare System Specifications" to the "Prepare Tender Document" activity. This is more concise; note that Figure 8 has only two activities instead of three, as in Figure 7.

Figure 7: Error: End-User Manager Owns Both Activity and Action

problem, with a poor understanding of real needs, or without putting needs within some business context. This normally results in changing requirements. Hence, it is crucial that first attempts at realizing business use cases deliberately focus on Business Actor/ Worker responsibilities. I strongly advise that the very first attempt not include any consideration of what the systems do, especially if legacy systems are involved, because there is a tendency to "forget" the responsibilities that those systems have in the business. When this happens, people also forget to question critical business procedures and rules hidden in the old system, and to scrutinize them in light of the new business context.

Note also that both the Business Vision Document and the Vision Document require descriptions of customer, user, and stakeholder responsibilities. By using business use-case realizations focused on work processes, you can verify that the list of responsibilities elicited is complete.

Once you understand responsibilities, it is then possible to identify which of them are time consuming, resource intensive, or error prone -- and, consequently, where automation can produce the greatest benefits. My

previous Rational Edge article, "Business Process Simulation with UML" describes how to use simulation to quantitatively evaluate different automation options.

Figure 8: Solution: Make Submission an Action that Causes a Transition

Focusing on Process Automation

Now we are ready to explore the automation of Business Actor or Worker responsibilities -- specifically when and how they use business systems. In our example, we have two business systems, as depicted in Figure 9:

● Tender Management System (TMS): A new system to be developed for preparing tenders and selecting vendors.

● Contract Management System (CMS): An existing system that tracks existing contracts.

Figure 9: Business Systems for the Prepare Tender Use Case

The Guidelines for the Business Object Model in the RUP (business modeling discipline) suggest the possibility of defining a new stereotype icon. In this article we will use the "Business Worker" icon for business systems, but they will have a new icon in the new UML Business Modeling Profile. Note, however, that our concept of a business system is exactly the same as that in the new Profile.

Figure 10 shows a sequence diagram describing the realization of the basic flow for the Prepare Tender business use case, including required business systems.

Figure 10: Business Use Case Realizations -- Automation for the Prepare Tender Use Case

The messages in Figure 10 can be mapped according to the responsibilities of each Business Worker, as shown in Figure 11.

Figure 11: View of Participating Business Actor, Workers, and Systems

The class diagram in Figure 11 shows the context of the Tender Management System (TMS). By context, we mean the clients who need the services of the TMS, and the suppliers that the TMS requires for operation. This context can be represented in another form in a use-case diagram, as depicted in Figure 12.

Figure 12: Use Cases for Tender Management System Derived from Business Use-Case

Realization

The use-case names in Figure 12 correspond exactly to the operation names in the TMS in Figure 11. The Actor names in Figure 12 correspond exactly with the Business Actors and Business Workers in Figure 11. Using the same naming convention facilitates traceability from the business object model (of which the business use-case realization is a part) to the system use-case model.

Exploring Automation Options. The sequence diagram in Figure 10 illustrates how the Tender Management System (TMS) hides the Contract Management System (CMS) from the Legal Officer. This is one of the possible system development scenarios, which include:

Scenario 1: disparate systems with no integrationScenario 2: providing a new front-end onlyScenario 3: integration

How Many Business Use Cases?

In general, the number of business use cases should be few compared to the number of system use cases. The realization of business use cases involves the participation of both Business Actors and Business Workers, both of which will potentially need to interact with the system and consequently have their own set of use cases. Typically, the ratio of business to system use cases should be between 1:5 and 1:10. In our example, the "Prepare Tender" business use case is expressed in five system use cases, as depicted in Figure 12. The value of business use cases is to put use cases in context -- to show how a group of them can be implemented to deliver business value.

If the numbers of business use cases and system use cases are comparable (i.e., a 1:1 to 1:3 ratio), I would question the need for business modeling. If the granularity of the business use case and the system use cases are similar, then one type is redundant.

In Scenario 1, there is no integration between the TMS and the CMS, and both are treated as separate and independent systems. The sequence diagram for the activities of the Legal Officer is represented as shown in Figure 13; note that the Legal Officer accesses the CMS directly.

Figure 13: Sequence Diagram -- Scenario 1: Disparate Systems with No Integration

The use-case diagram for the TMS derived from Figure 13 is depicted in Figure 14. Note that the CMS does not appear in Figure 14 because it does not interact with the TMS.

Figure 14: Use-Case Diagram -- Scenario 1: Disparate Systems with No Integration

In Scenario 2, the TMS provides a front end that wraps up the functionality of the CMS. The sequence diagram for the activities of the Legal Officer is shown in Figure 15. The goal of this approach is to provide a consistent look and feel for the front end. However, there is no additional functionality to support the Legal Officer in reviewing and supplementing the tender with legal terms.

Figure 15: Sequence Diagram -- Scenario 2: Providing New Front End

The use-case diagram for the TMS derived from Figure 15 is depicted in Figure 16. Note that Figure 16 includes a new use case, "Search

Contracts," which interacts with the CMS.

Figure 16: Use-Case Diagram -- Scenario 2: Providing New Front End

Scenario 3 is shown in message 4 of Figure 10. The TMS provides a front end to the CMS, and at the same time provides additional functionality to facilitate the Legal Officer in reviewing and supplementing the tender with legal terms.

Messages Can Map to Use Cases or Flows. In the discussion above, each message in the sequence diagram is mapped to a use case. This implies that the business object model and the use-case model must be consistent -- that is, that use-case names correspond to operation names in the business systems. This may be too restrictive, because in many cases we want to restructure the use-case model or the business object model independently of each other. However, restructuring either model will invalidate the mappings between the two models, and we want to maintain consistency or some form of traceability. We can achieve this by permitting a message to be mapped to either an entire use case or part of a use case, as a flow or event with corresponding message semantics that support such a mapping. This is illustrated in Figures 17 and 18.

Figure 17: Message-to-Use-Case Mapping

Figure 18: Operation-to-Use-Case Mapping

Focusing on Information Processes

Now let's look at business use-case realizations that focus on information processes -- that is, how business entities are manipulated. Our example has several business entities, as depicted in Figure 19:

● The System Specifications document, which describes the system requirements. It is initially developed by the End-User Manager and supplemented by the Enterprise Architect through the IT Project Manager.

● The Tender document, which will be given to candidate vendors as a basis for preparing a bid. It comprises the system specifications and legal terms.

● The Legal Terms, an important section within the tender that defines legal terms and conditions with which candidate vendors have to comply.

● The Contract, which can refer to existing related contracts so that the Legal Officer does not have to write legal terms from scratch every time.

Figure 19: Business Entities -- Prepare Tender Use Case

A sequence diagram describing the realization (information processes) of the basic flow for the Prepare Tender business use case is depicted in Figure 20.

Figure 20: Business Use-Case Realization -- Information Processes (Sequence) for the Prepare Tender Use Case

The corresponding collaboration diagram describing the realization (information processes) is depicted in Figure 21.

Figure 21: Business Use Case Realization -- Information (Collaboration) for the Prepare Tender Use Case

The messages in Figures 20 and 21 can be mapped into the responsibilities of each of the business entities, as shown in Figure 22.

Figure 22: View of Participating Business Actors, Workers, and Entities

Note that business entities are passive and do not initiate interactions on their own. Hence, the messages in Figures 20 and 21 represent how Business Actors or Workers manipulate these entities, either manually or through the use of automated tools (e.g., Tender Management System or Contract Management System). In most cases, organizations will have more than one system, so a single business entity responsibility may be mapped to multiple system responsibilities. Describing which business system is used to manipulate which business entity within Figure 20 would complicate Figure 20 as well as Figures 21 and 22. Hence, I frequently use separate diagrams for process automation and information processes. When you are performing use-case analysis, you can postpone depicting the manipulation of entities by systems until later. Alternatively, you can have a class diagram mapping business systems and business entities.

Figure 22 can be simplified by showing only the participating business entities, as in Figure 23.

Figure 23: View of Participating Business Entities -- Prepare Tender Use Case

Figure 23 is also referred to as the domain view, and the set of all business entities constitutes the domain model. The domain model also describes dynamic behavior, usually through state transition diagrams. In addition to showing the relationships between different business entities, it is important to show the states of individual business entities. The state diagram shows the operations that can be performed on each business entity. Figure 24 is the state diagram for the Tender Document.

Figure 24: State Diagram for Tender Document

In Figure 24, the events have the same name as the operations within the Tender Document. Guard conditions (i.e., Boolean expressions delimited by "[" and "]" in UML) signify different termination conditions for the operation. For example, the Review Tender Document operation has three possible terminating conditions, namely:

● Acceptable

● Legal Terms Unacceptable

● System Specifications Unacceptable

These terminating conditions must be handled by the "Review Tender Document" use case identified in Figure 12. The Tender Document being accepted can be the basic flow of the use case, whereas the other two conditions can be the alternate flows. A mapping from the state transition to the use case can be derived as shown in Figure 25. An event is mapped to a use case, the guard condition is mapped to a flow with that use

Business Rules

One of the challenges in requirements elicitation is how to organize business rules and ensure their completeness. I often identify and categorize groups of business rules, because missing a group is more devastating than missing a rule within a group. Some possible sources of business rule groups are:

● Alternate flows in business use-case specifications/realizations.

● Events in domain models.

For example, in the Business Use Case Specification for Prepare Tender (see Table 2), we have an alternate flow -- A1: System Specifications Invalid. This indicates that a checklist is needed to determine whether the system specifications are indeed invalid. This checklist can be documented as a group of business rules.

State charts in domain models highlight the different events that

case, and the action represents the step following the detection of the guard condition.

Figure 25: Mapping from State Transition to Use Case

Thus, the state Tender Document Prepared in Figure 24 is handled by a use case: Review Tender Document, as shown in Table 3. The state Tender Document Prepared has three outgoing transitions that are mapped to Step 4 of the basic flow, alternative flows A1 and A2.

may occur (e.g., Figure 24), which can be triggered or guarded by different conditions. Hence, it is natural to group such business rules according to the events.

"Maintain" Use Cases

Use-case practitioners who come across "maintain"-type use cases often ask: Where do these "maintain" use cases come from, and what are their business goals? Each step in the business use-case realization has prerequisites, which can be fulfilled either by preceding steps or by "maintain" use cases. For example, the "Search Contract" requires the existence of some contracts as a precondition. As none of the preceding steps in the Prepare Tender business use case creates a contract, a "Maintain Contract" use case is required. There is no need for a "Maintain Legal Terms" use case, however, because the legal terms are created and updated as part of the "Supplement Tender with Legal Terms" Step.

Table 3: Review Tender Document Use Case

Basic Flow

This use case begins when the End-User Manager wants to review a tender document after being notified by the IT Project Manager that the document has been completed.

1. List Tender Documents. The system retrieves and displays a summary list of Tender Documents for the End-User Department, showing their status.

2. Open Tender Document. The End-User Manager selects a Tender Document. The system retrieves and displays it.

3. Review Tender Document. The End-User Manager reviews the system specifications and legal terms.

4. Tender Document Acceptable. If the End-User Manager accepts the contents, she or he approves the document. The system notes the decision, and the IT department can now open

the tender for bidding. The use case terminates.

Alternate Flows

1. Legal Terms Unacceptable. If in Step 3 of the Basic Flow the End-User Manager finds the Legal Terms unacceptable, the reasons for rejecting them is noted. The system notifies both the IT Project Manager and the Legal Officer of the rejection. The use case terminates.

2. System Specifications Unacceptable. If in Step 3 of the Basic Flow the End-User Manager finds the System Specifications unacceptable, the reasons for rejecting it are noted. The system notifies both the IT Project Manager and the Enterprise Architect of the rejection. The use case terminates.

The alternate flows in Table 3 handle the rejection of the Tender Document. In Step 1 of the Basic Flow in Table 3, the system displays a summary list of Tender Documents and their status, which is one of the states in Figure 24. Thus, the state diagrams in the business model provide a means of detailing use cases in the following aspects:

● Identifying alternate flows.

● Enumerating status of entities to be displayed.

Conclusion

Software systems are developed to achieve business objectives. However, users, analysts, and developers often live in different worlds; they have different perspectives and use different jargon. The communication barriers between these groups result in many heated discussions on the interpretation of various system requirements as well as changing requirements. Typically, these changes occur not because the end users change their minds, but rather because the original requirements need clarification.

It is therefore highly beneficial to use a common notation system (such as the UML) and common techniques (UML and RUP Business Modeling Profiles) that can describe both business processes and system usage in a way that is understandable to all users, analysts, and developers. Such improved communication will certainly make software engineering projects more successful.

In this article, we have walked through the steps of identifying Business Actors and business use cases and describing their realizations using three approaches, each with a different focus (see Table 4).

Table 4: Approaches to Describing Business Use-Case Realizations

Focus Purpose Benefits

Work Processes

Identify responsibilities of Business Actors and Workers.

● Understand business process without being distracted by system or information details.

● Identify which Business Actor and Worker and responsibilities are time consuming, resource intensive, or error prone to prioritize automation needs.

Process Automation

Identify the responsibilities of business systems in support of Business Actor or Worker responsibilities.

● Understand how business systems are used by Business Actors and Workers as part of their work process.

● Facilitate the derivation of system use cases.

Information Process

Identify the manipulation of business entities by Business Actors and Workers.

● Understand the relationship between business entities.

● Facilitate the refinement and verification of system use cases.

Appendix: Business Modeling Overview

This article assumes that the reader is fairly familiar with the UML and has some basic understanding of the UML profile for business modeling.

An overview of the current UML profile for business modeling is summarized in Table A-1.

Table A-1. Overview of Current UML Profile for Business Modeling

Stereotype Description UML Representation

Business Use-Case Model

● A model of the intended business functions.

● Used as essential input to identify roles and deliverables in the organization.

Model, stereotyped as "business use-case model"

Business Object Model

● An object model describing the realization of business use cases.

Model, stereotyped as "business object model"

Business Use Case

● A class that defines a set of business use-case instances; each instance is a sequence of actions a business performs that yields an observable result of value to a particular Business Actor.

Use case, stereotyped as "business use case"

Business Use-Case Realization

● Describes how a particular business use case is realized within the business object model, in terms of collaborating objects (instances of Business Workers and business entities).

Collaboration, stereotyped as "business use-case realization"

Business Actor

● Represents a role played in relation to the business by someone or something in the business environment.

Actor, stereotyped as "business actor"

Business Worker

● A class that represents an abstraction of a human that acts within the system.

● Interacts with other Business Workers and manipulates business entities while participating in business use-case realizations.

Class, stereotyped as "Business Worker"

Business Entity

● A passive class that does not initiate interactions on its own.

● May participate in many different business use-case realizations and usually outlives any single interaction.

● In business modeling, represents objects that Business Workers access, inspect, manipulate, produce, and so on.

● Provides the basis for sharing information among Business Workers participating in

Class, stereotyped as "business entity"

different business use-case realizations.

®Organization Unit

● A collection of Business Workers, business entities, relationships, business use-case realizations, diagrams, and other organization units.

● Used to structure the business object model by dividing it into smaller parts.

Package in the business object model, stereotyped as "organization unit"

For more information on the products or services discussed in this article, please click here and follow the instructions provided. Thank you!

Copyright Rational Software 2002 | Privacy/Legal Information

The Cone of Correct Compensation

by Joe Marasco

Senior Vice President and General ManagerRational Software

Compensation of software professionals is always controversial. Often there are tenfold differences in productivity between the best and worst performers on a development team, yet no conventional salary structure provides for this kind of dynamic range. In this article, we examine some new ways of looking at compensation and performance in software organizations. Although we provide no "silver bullet" for resolving the problem, we do provide a framework for thinking about it in a non-traditional way. One important conclusion: Many problems that we seek to solve with compensation are really job assignment or skills development issues that need to be attacked with tools appropriate to those domains.1 We attempt to tie together three variables: compensation, skill level, and job difficulty. As compensation is linked to performance, the challenge is to correlate performance with skill level and job difficulty.2

Going for the Flow

Let's begin by looking at the work of Mihaly Csikszentmihalyi,3 who posits that humans have a "flow channel," which roughly translates to the intense focus and sense of satisfaction we feel when our skill level is well matched to the challenges of our job.

If the task is too easy, boredom sets in, and people are unhappy (see Figure 1). If the task is -- relatively speaking -- very challenging compared to competence, then people become tense and anxious. When there is a reasonable match -- not too easy, not too hard -- then we are in the flow channel, which actually spans a broad range of competency and task

Copyright Rational Software 2002 http://www.therationaledge.com/content/nov_02/k_correctComp_jm.jsp

difficulty. In this state of grace, achievement is high, and we experience a feeling of incredible well-being; athletes describe it as "being in the zone." 4

Figure 1: The Flow Model

Note that, starting from position 1 in Figure 1, one can move into an anxiety zone if the job difficulty increases without a corresponding increase in skills (position 2). To get back into the flow channel, any combination of skills improvement and decrease in difficulty will suffice, but the best move is a horizontal one, toward position 3. In a like manner, one can improve skills while job difficulty holds constant and move position 1 to position 2', where boredom sets in. Achieving flow then requires a move toward position 3 -- by seeking a more challenging job. Of course, then position 3 becomes the new position 1, and the cycle starts all over again. At position 3, however, there is a greater contribution to the organization than at position 1, even though they are both flow states. Clearly, moving up and to the right is a good result for both the team member and the organization. We believe the flow channel "opens up," as skill level and job difficulty increase, so individuals theoretically have more opportunities for job satisfaction.5

We should also state that being in the flow channel leads to optimal performance. One can be outside the flow channel and still perform at a level good enough to earn a "satisfactory" rating in many organizations. However, the farther from the flow channel one gets, the more performance degrades. And we should ask ourselves: Why not set the goal of achieving optimal performance from everyone in the organization? Would this not lead to the best possible "win-win" for both the organization and the individual?

There is obviously much, much more to Csikszentmihalyi's work, and this brief description does not do him justice. However, it does provide a basic understanding of the conceptual model we will use to frame our discussion of compensation.

Flow and Software Development Performance

Before we get deeply into that discussion, however, let's look at how this idea of flow relates to productivity/performance in the software development environment. One of the most intriguing and confounding phenomena for development managers is the wide variability in productivity among team members. How do we account for these variations?

In our experience with a large number of projects and an even larger number of team members, we've seen that the productivity of architects, designers, programmers, and testers who find their flow channel vastly outstrips that of their peers.6

Lower-productivity individuals typically exhibit one of the two characteristics Csikszentmihalyi identified: anxiety from being in over their heads (task difficulty >> skill level) or boredom because of insufficient challenge (skill level >> task difficulty). The results? Poor code -- either because of inexperience and wheel reinvention in the first instance, or from laziness and procrastination in the second.

Of course, another major factor in productivity is whether the company culture "pays" for performance rather than how a job or a person looks on paper. There is some confusion about what this means. In my simple view, job skills represent the potential to perform. Through training and experience, we attain skill levels that should enable high performance but do not ensure it.

In a like manner, job difficulty represents the opportunity to perform. That is, a particularly challenging job provides an arena in which a combination of effort and skills can produce a great result. For a highly motivated and skilled individual, the lack of a sufficient outlet is frustrating, as there is no opportunity to shine. But just as with skills, simply having the challenge by no means guarantees high performance.

So ideally, we want to pay for performance, meaning results, or total contribution to the organization. And that means we need to understand all the factors that affect performance. These include more than simply the balances and imbalances in skill and job difficulty. For example, motivation is a powerful factor. Also, people perform much better when they are engaged in activities they just enjoy doing. Yet another factor is confidence in one's abilities; good performance can generate a positive feedback loop that leads to even greater confidence and higher performance.

When one is in the "flow channel," motivation and enjoyment of the job are at their highest, and confidence soars. So the concept of flow is consistent with these other factors that affect productivity/performance.

However, we should be careful not to neglect motivational factors that are independent of flow. In particular, we should not underestimate the motivational effects that come from commitment to a mission and feeling part of a great team. And, of course, individuals go through cycles of increased or decreased motivation because of other things that are occurring in their lives.

Finally, perceived compensation can be either a motivator or a demotivator. People who feel they are being unfairly compensated, either absolutely or relative to others, can become demotivated to the point that their performance suffers. (The problem here, of course, is that these are perceived inequities; employees may overestimate their contribution and/or peer compensation.) So there is yet another feedback loop that needs to be considered.

Although all these factors affect performance, and hence compensation, in the rest of this article we will stick to Csikszentmihalyi's flow model, with the understanding that this is oversimplifying a very complex affair. We choose to do this because we believe we can directly affect three factors -- skill levels, job difficulty, and compensation -- whereas some of the other factors are much more difficult for us to influence.

Applying the Flow Model to Compensation

In the discussion below, we will assume three zones of compensation: correct, underpaid, and overpaid. Overpaid means the team member in question is compensated at a level greater than the level at which he or she contributes to the organization. Underpaid means the team member's compensation level is lower than his level of contribution to the organization.7 We achieve correct compensation when there is a balance between contribution and compensation for the team member in this job, and within this organization; all bets are off relative to other contexts.8 And clearly, a team member who is not doing a good job is always, by definition, being overpaid.

Skills-Based Model

Some organizations compensate by skill level, without considering job difficulty as a dominant factor. This is more common in government organizations and those that focus on seniority, where the assumption is that skills increase with time. Based on the model in Flow, Figure 2 depicts this approach.

Figure 2: Model for Skills-Based Compensation

As we see, there is a zone of "correct compensation," where the compensation level is appropriate for the skill set of the team member in the job. Positions 1 and 3 are in this zone, although position 3 is clearly compensated more than position 1.

In position 2, the team member is earning more than is appropriate for his or her skill level. This may or may not be dysfunctional; for example, the team member may be doing a difficult job, one that requires more skills than the team member currently has, and is being compensated accordingly. Or, it may just be an error.

In position 2', the team member is being underpaid for his or her skill level. Once again, there may be different reasons for this. The team member may be truly underemployed, or the job may not leverage his or her full skill set.

Job-Based Model

Some organizations worry less about skill levels and compensate according to the difficulty of the job (or, as a surrogate, responsibility). This model is more typical of entrepreneurial, start-up ventures (see Figure 3).9

Figure 3: Job-Based Compensation Model

Once again, positions 1 and 3 represent correct compensation, and 3 is more highly compensated than 1.

In position 2, the team member is being overpaid relative to the difficulty of the job. This can occur for a variety of reasons. It may be an error, or it may be that the jobholder possesses high-level skills or credentials, but the current job assignment does not make use of those skills.

In position 2', the team member is underpaid. This is typical of a person promoted to a new and difficult job who has not yet received a corresponding compensation bump.

Note that in this model and the previous one, when someone is at 2, the remedies are to increase either skill level or job difficulty at the current compensation level. When team members are at 2', the appropriate response is to increase compensation.

No matter what the model, it is always difficult to move into the "zone" by decreasing job difficulty, skill level, or compensation. Organizations do not usually support downward changes. We will discuss this in more detail later.

Introducing the Cone of Correct Compensation

We now combine these models into a three-dimensional graph, introducing a "Cone of Correct Compensation" (Figure 4).

Figure 4: The Cone of Correct Compensation

This cone represents the state in which skill levels, job difficulty, and compensation are all in balance. The region inside this cone, indicated by the "C" at the center of the projection, above, represents the classic "win - win" situation. The team member is neither bored nor anxious -- he or she is in the flow channel. Compensation is also correct -- the team member is neither underpaid nor overpaid. He or she operates at peak productivity, and the organization is paying a fair price for this. Note that the cone opens up because, as all variables increase, there is more latitude for getting the compensation right.10

The other eight zones represent "out of cone" scenarios. We have labeled them with compass directions to help navigate through the rest of the discussion.

It is possible, although sometimes challenging, to correct the problems in directions E and W. Here, team members are correctly compensated but are either bored or anxious. In these regions, productivity is suboptimal, but the issues involve a skills/difficulty mismatch, so fiddling with compensation doesn't help.

The issues in the N and S directions are relatively simple to deal with. In this case, the team member is in the flow channel but is either underpaid or overpaid. An adjustment needs to be made to bring the equation back into balance, so that neither the team member nor the organization profits

excessively from the team member being in the flow channel.

We will discuss the other four directions, which are somewhat more pathological, in the next section. After that, we will consider in greater detail the E,W and N,S scenarios we just described. In both sections, we take the projection of the cone and depict it as a two-dimensional plot. The four diagonal cases become a two-by-two plot in the next section; after that, the center and eight compass directions become a three-by-three plot.

Diagonal Cases

This section focuses on the four extreme cases that involve team members who are in the wrong jobs and incorrectly compensated. These fall at the four diagonal corners of the cone - NE, NW, SE, and SW, respectively, as represented in Figure 5.

Please note that team members may be "incorrectly compensated" for many reasons, including historical errors, temporary disequilibria in the marketplace between supply and demand of specialized skill sets, and so on.

Figure 5: Team Members Who Are in the Wrong Jobs and Incorrectly Compensated

The upper left box (NW) contains team members who are being paid for their skill level but are doing relatively easy jobs that could be filled at lower cost to the organization by less skilled team members. This is a bad box: productivity is intrinsically low relative to pay, and there is an opportunity cost to the organization because it does not exploit these

team members' full potential.

The lower left box (SW) represents the bored, underpaid team members of the world. They are at least marginally qualified, have relatively easy jobs, and are not paid a lot. Sometimes the combination of boredom and lack of compensation spurs them to seek other opportunities; often they vegetate. This class represents a waste of human capital. Although they are not overpaid, they add to headcount.

The lower right box (SE) contains the strivers in the organization, those who are doing hard jobs with relatively inadequate skills, and being underpaid in the bargain. This combination is untenable in the long term, as these team members will burn out sooner or later.

Finally, the upper right (NE) represents team members who are being overpaid for being overextended. They may do well temporarily but ultimately will fail unless they get some skills development. As there is a strong monetary incentive for them to continue to "get in over their heads," they are great candidates for proving the Peter Principle.11

The Nine Possibilities

In Figure 6 we consider all nine possible cases for our cone model, not just the four most pathological cases we showed in Figure 5.

Here the cone of correct compensation is depicted by the center bullseye, where flow has been achieved and the compensation level is just right. In this case, the team member is happy and productive, and the organization is getting the best productivity at a fair price.

Figure 6: Nine Possibilities in and Around the Cone of Correct Compensation

In the middle row left and right (E and W), compensation is "fair," but both the team member and the organization lose, because productivity is suboptimal. In this case, tinkering with compensation does nothing to address the problems that cause team member unhappiness and organizational loss of productivity. This is a pure difficulty/skills mismatch and needs to be addressed along those axes.

In the middle column, top and bottom (N and S), the team member is in flow, and productivity is maximized. Compensation should be adjusted to ensure that neither the team member nor the organization profits excessively from that situation. Clearly, this is easy to do for the underpaid case; for the overpaid case, we usually hold compensation constant while increasing both of the other variables (job difficulty and skill level) in balance.

The four extreme corner cases were discussed above.

In the next section, we will discuss the stability of these various states, along with actions managers can take to get team members and the organization to a win-win state.

Instability of North, South, East, and West

We know that the center in the previous figure represents an optimal condition, and once a team member is there, we need to continue to move him or her along the "body diagonal" to keep him or her in the cone of correct compensation.

We also know that the four corners are potential sink states, or places where things either degenerate rapidly or are long-term costly to the team member and/or organization.

Are the four middle states stable? Although they are not as dangerous as the corner states, the problem is that they tend not to be stable over the long term if left unattended (see Figure 7).

Figure 7: Unattended Middle States Move Toward Corners

In both cases in the middle row (E and W), the correctly paid team member who is not in a state of flow will become less and less productive because of either anxiety or boredom. At some point, he or she will migrate upward on the chart, as indicated by the arrows labeled "A," moving into the overpaid category. This will happen without any nominal rise in compensation; it is strictly the effect of becoming less productive at constant compensation.

We have observed that in-flow team members who are overpaid (N) tend to get bored. This makes them less productive and moves them into the NW corner, as indicated by the arrow labeled "B." We have also observed that in-flow team members who are underpaid (S) tend to become anxious as a result of the inequity they see in their compensation. This has a tendency to throw them out of flow and into the SE corner, as indicated by the arrow labeled "C." (As they become less productive, they also become less underpaid.)

Getting to Win-Win

A good management objective is to get all team members to the win-win area inside the cone and to keep them there. Most organizations do not have the flexibility to easily reduce team members' job difficulty, nor are they likely to want (or be able) to reduce compensation. It is also meaningless to talk about reducing skill levels as a way to achieve equilibrium,12 although sometimes a lateral move may have that effect -- in other words, some of the team member's current skill set may be inapplicable in the new position, and new skills will have to be developed. But usually the only way to address an imbalance is by moving other variables in a positive direction, as opposed to a negative one.

Most of the recommended remedies shown in Figure 8 are self-explanatory, but we'll examine a few special cases.

Figure 8: Getting to Win-Win

In the NW corner, the only remedy is to dramatically increase either job difficulty or responsibility. The team member has the skills and is already being paid for a more difficult challenge.

In the N box, care must be taken to increase skill level and job difficulty in proportion, so as to not violently throw the team member out of flow. In the NE box, skills must be increased more than the increase in job difficulty, else disaster looms.

Increasing skill level is tricky. It usually cannot be done overnight and may involve training, coaching, mentoring, and other methods that require time. Team members who have potential but need skills improvement need to be identified early, so that remedial action can be taken before the situation becomes so acute that the improvement cannot take place within a reasonable time frame.

Note that of the eight suboptimal cases, only one can be addressed by solely increasing compensation. Five cases require no compensation action but do require adjustment of skill levels and job difficulty to get back into the cone. The remaining two cases require adjusting either skill levels or job difficulty in combination with compensation. So, remarkably, compensation is a partial remedy in only three out of the eight dysfunctional situations.

Mapping Current Team Members

If you are managing a team, do the following experiment. Lay out the three-by-three grid with "Win-Win" in the middle, and then assign each

team member to one of the nine boxes. You will find yourself thinking about people in ways you have not previously considered.

Once you have done the allocation, you will have some idea of both the development plan and the compensation strategy for each class. The exercise forces you to look at both aspects at the same time, something we sometimes forget to do. This methodology also makes discussions with team members more constructive, as you can show them that you have considered all the variables as you figure out their path forward.

Mapping New Team Members

When recruiting in a tight labor market, we sometimes have to pay somewhat more for a new hire than we would like. Equity vis à vis current team members becomes an issue. And sometimes making an attractive offer involves improving the prospective team member's situation relative to the one he already has, which may be the result of an aberration in his current organization.

One way to approach such situations is to lay out your current roster on the grid and see where the new player will fit. If it becomes clear that the salary inequity will cause not only an immediate problem, but also long-term development problems, then perhaps you need to reconsider your offer.

Money Isn't Always the Answer

We might have titled this article, "When Is a Compensation Problem Not a Compensation Problem?" Often, managers have a knee-jerk response that leads them to focus on compensation when problems arise. But often the problem is dysfunctional behavior that might be caused in part by a compensation problem but has other root causes as well. Simply changing compensation (which always means raising it), may not achieve the desired result. Using the cone analysis method gives you a way to look at all the variables simultaneously. If you think a team member is out of the cone, the first thing to do is determine which of the eight boxes he or she is in. Then, and only then, can you proceed with a solution.

Doing this kind of analysis is also a reminder that we need to better understand the coupling between development plans for individuals and their compensation trajectories. Dealing with either of these without careful consideration of the other is worse than just solving "half the problem" at a time. Unless you take a gestalt view of the situation and formulate a plan that considers skills progression, job difficulty, and compensation together at one time, both parts of the equation will probably come up short. The cone methodology provides a coherent way of looking at the whole picture and helps us do a better job of retaining and developing team members, and improving their productivity.

A very senior manager read a draft of this article and remarked: "I think it's a great point that needs to be made, but I'm terribly afraid that managers will misunderstand the importance of matching assignment, skills, and motivation to optimize results. If assignments are made on the

basis of compensation, it's a disaster. In fact, compensation is irrelevant to making the right assignment; optimal compensation should result from optimal assignment, and not the other way around."

So, with this order of priorities in mind, one answer to the koan13 of correct compensation is the cone of correct compensation. Use this technique to get people in the right jobs with the right skill levels, and motivate them for optimal performance. Once you do that, it is easier to get their compensation right.

Appendix: Predicting Total Contribution

Some people have asked the following logical question:

"If we go back to Csikszentmihalyi's two-dimensional plot of job difficulty versus skill level, we can infer that the team member is more productive when in the flow channel and less productive when outside it. Can we use this information to predict total contribution to the organization as a function of job difficulty and skill level?"

The answer is that we can try to model this information. The model would be very useful, because if we knew the contribution, we could try to make the compensation relate more closely to it.

Recall that in our basic flow channel model (Figure 1), the channel consists of two lines that go upward and to the right. So let us make a few simplifying assumptions. In our simplified model, the flow channel does not "open up." We assume that factors affecting productivity outside the flow model are small compared to those implicit in the flow model. As we have clearly stated elsewhere, this is a big assumption, and should cause us to not attach more to these predictions than the model itself justifies. Productivity affects contribution, which in turn should affect compensation, so we need to understand the factors we exclude from the model that can materially affect productivity.

Next, we'll assume that contribution -- the "performance" we are paying for -- is the product of job difficulty and productivity. That is, for equally productive people, those doing harder jobs are contributing more.

We'll also assume that, at a given level of job difficulty, all skill levels within the flow channel have equal productivity, arbitrarily set to 1. This seems reasonable, as team members can be optimally productive anywhere within the flow channel. In the example we will see below, the flow channel is fairly wide; this is part of the model. Setting the breadth of the channel relative to other factors is one way to "tune" the model.

Then, we will assume that, at the same level of job difficulty (a horizontal line on the plot), productivity tails off as we move farther and farther away from the flow channel, both in the anxiety region and the boredom region. In our example, we have made this productivity degradation fairly rapid once outside the channel. At one skill level outside the channel, productivity drops to 0.75; at the second, to 0.50; at the third, to 0.25; and at the fourth to zero. If we choose a different rate at which

productivity decreases, we will get a different profile. This is another way to "tune" the model.

The plot in Figure A-1 shows the contribution measured in arbitrary units; we center the plot on 100 units of contribution. The level of difficulty of the job changes by ten units in the flow channel for each step up or down. Please remember that this is a very simple model. Yet it may capture the effective contribution to first order, if Csikszentmihalyi's theory is valid. If we agree on the model, then we also have a notion for how compensation should go as a function of skill level and job difficulty.

Figure A-1: Effective Contribution Using Csikszentmihalyi's Flow Model

As an example, consider the person with a task difficulty and contribution level of 100 who falls within the flow channel, and the person outside the channel at the same task level with a contribution equal to 75. If that person's compensation is greater than 75, we would consider him overpaid according to this model, as his pay is greater than his contribution. Or, to put it another way, if the person in the channel and the person outside the channel are both being paid 85 units, then one is underpaid and the other is overpaid.

This is an interesting way to make comparisons, and one that we have not seen elsewhere.

Notes

1 Disclaimer: The ideas presented here are those of the author. They do not represent the philosophy, policy, or practice of Rational Software Corporation. The author has benefited from extensive and penetrating discussions with his son Marc, who is the compensation specialist in the family.

2 Our exploration examines only one aspect of compensation: financial rewards such as salary, bonus, stock options, and so on. We will not consider intrinsic rewards and privileges, which might encompass "perks" -- the large corner office with the window, for example -- as well as visibility, power, and influence. However, we do want to emphasize that compensation does include more than just salary; management has at its disposal a wide variety of mechanisms for compensating team members, and can adjust the compensation

mix to fit the specific employee and organizational profile.

3 Pronounced "chick-sent-me-high-ee." See Mihaly Csikszentmihalyi, Flow: The Psychology of Optimal Experience. HarperCollins, 1991.

4 On the software development front, the person who epitomizes this state of being would have to be the legendary Howard Larsen, an early pioneer at Rational Software. Anyone who has worked with Howard will be nodding his head at this juncture; Howard is probably as far "up and to the right" as you can get in the programming flow channel. I'm sure that you either have a Howard in your organization or wish you did. And the real question is: Why are "Howards" so rare?

5 I don't think this is part of Csikszentmihalyi's theory, but it seems like a reasonable extension to me. It is this "opening up" of the channel that leads to the three-dimensional cone we will introduce later in this article.

6 In assessing productivity, we look at both quantity and quality of the software artifacts produced.

7 We assume that the contribution to the organization can be objectively and consistently measured.

8 We should note the nagging problem of "scarcity premiums" paid for certain skills when and where there is a temporary imbalance between supply and demand in the marketplace. We abstract this from the current discussion but come back to it later in the article.

9 It is also generally true of executive compensation; jobs are often benchmarked by similar positions at similarly sized firms.

10 This appears to be true in actual practice; the margin for error seems to be tighter at lower levels.

11 The Peter Principle asserts that people rise to their level of incompetence in any organization. One reason for this is that there is an economic benefit (better compensation) to taking on harder jobs or more responsibility. As long as they can "hang in there," the team members reason, it is better to be stressed for more compensation rather than for less. And, as most organizations do not move people backwards, there is a tendency for people to rise until it is obvious that no more upward movement is possible. This generally results in people stalling out and stagnating at least one level over their heads. This phenomenon is used to explain the perceived widespread incompetence in the management ranks of many organizations.

12 Lobotomies are typically frowned upon.

13 The Concise Oxford Dictionary defines a koan as follows: "Riddle used in Zen to teach inadequacy of logical reasoning. [Jap., = public plan]." The atrocious pun notwithstanding, I hope we have shown that correct compensation does not have to be a riddle immune to logical reasoning.

For more information on the products or services discussed in this article, please click here and follow the instructions provided. Thank you!

Copyright Rational Software 2002 | Privacy/Legal Information

Ingredients for Building EffectiveEnterprise Architectures

by Dave West, Kurt Bittner, and Eddie Glenn Rational Software

In 1996, the U.S. Congress passed the Clinger-Cohen Act,1 which, among other things, mandated that federal agencies develop and maintain an integrated enterprise information technology (IT) architecture. This act brought focus to a growing concern that the applications previously developed by government organizations -- although partially successful in meeting a narrow set of needs -- could not be tied together to meet the greater needs of a broader set of constituencies. Subsequently, agencies launched a series of Enterprise Architecture (EA) efforts to address this challenge, focusing on ways to ensure mission-driven development. In order to create applications that would support the interoperability of a broad range of systems to accomplish expanding missions, these agencies first had to define those missions clearly, and describe how the set of interoperating systems would fulfill them.2

This article offers an overview of what such EA efforts can accomplish. It briefly describes several federal EA frameworks and examines why the UML (the Unified Modeling Language) is particularly well-suited to describe an EA. It also notes ways organizations can build an EA that can effectively drive software and systems development projects that further their mission.

What Is an Enterprise?

An enterprise is a set of resources applied toward a business purpose or mission. It may be a business or government agency, part of a business or agency, or, in some cases, several businesses or agencies (e.g., the intelligence community or a bank participating in a broad credit card enterprise). When government agencies and other enterprises began to recognize the importance of understanding their IT infrastructure in a

Copyright Rational Software 2002 http://www.therationaledge.com/content/nov_02/f_enterpriseArchitecture_dw.jsp

much more precise manner than they have done in the past. this gave rise to a number of different techniques for capturing and modeling enterprises as well as the lines of communication between various enterprise entities. This trend has also led to the definition of new tasks, activities, and functions these entities must perform to understand and manage relationships with other enterprise entities.

What Is an Enterprise Architecture and Why Is It Valuable?

An EA is a "blueprint" that documents all the information systems within the enterprise, their relationships, and how they interact to fulfill the enterprise's mission. This documentation gives organizations the ability to understand and analyze their business operations, allowing managers to identify and address shortcomings or inconsistencies, and to eliminate costly errors, redundancies, and inefficiencies.

Even people who have worked in an enterprise for many years may not understand its underlying mission. And even more probably have no idea how the enterprise's systems infrastructure actually works, let alone how it is supposed to work. Naturally, if the people within an organization do not understand its mission, they will never be successful in achieving that mission. An EA offers a remedy by documenting the organization's mission, and then looking at what the organization does and who benefits from the activity in order to determine whether these things are aligned with the mission.

An EA is especially important for understanding those information systems that should directly support the organization's mission. Insurance companies, for example, have a mission to serve customers and process their claims. Companies store

Enterprise Architecture in the United States Federal Government

Although federal EA efforts certainly do not encompass all the industry efforts to standardize and benefit from EA, federal EA efforts are important because of the large scope of the targeted enterprises.

DoDAF

The Department of Defense Architectural Framework (DoDAF) is focused on enabling the interoperation of disparate systems used to support military missions. Its purpose is to clearly relate the objectives of the DoD's information technology with the performance of its core mission. One aim of the DoD enterprise architecture is to correlate information technology objectives with business cases for IT investments.

DoDAF, and in particular C4ISR -- which provides specific support for DoDAF with respect to command, control, communications, computers, intelligence, surveillance, and reconnaissance -- gives the DoD a number of important capabilities:

● Allows the DoD to create systems that work effectively together.

● Enables owners and

descriptions of their customers throughout the enterprise in many forms, including various claims and renewal systems. If the company is considering the addition of a new customer system, then in order to make the right decisions, management must understand the dependencies and data sharing structures within the current systems.

Without an EA, it is difficult or impossible to tie systems together in a meaningful way. Often, instead of getting properly integrated into the whole systems architecture, newly developed systems begin forming "stovepipes," and the organization winds up with a large number of different systems with overlapping functions. Eventually, these become impossibly expensive to maintain and test, and the complexity of the systems structure exceeds staffing capabilities. Without an EA, there is no way to understand how to integrate the data and business logic from these disparate systems into an intelligent body of information on which to base corporate decisions. Moreover, integration attempts almost invariably uncover not only data duplication, but also subtle inconsistencies in the duplicate data from system to system.

These problems are exacerbated by mergers. Any organization that merges with another typically must integrate a number of similar but incompatible systems, ranging from accounting to payroll to customer relationship management. Our federal and state governments, currently challenged to streamline the communication of intelligence

investors to make intelligent buy, build, and reuse decisions.

● Helps system architects make good design decisions about where functionality should reside within the systems architecture.

● Provides a common language to describe an integrated system that spans missions.

● Allows large groups of stakeholders to work cooperatively and effectively on large, complex systems.

FEAF

The Federal Enterprise Architecture Framework (FEAF) was established in 1999 by the Chief Information Officers (CIO) for each federal agency in response to the Clinger-Cohen legislation. The purpose of the FEAF is to facilitate shared development of common processes and information among federal agencies and other government organizations.

According to FEAF, it allows the federal government to:

● Organize federal information on a federal-wide scale.

● Promote information sharing among federal organizations.

● Help federal organizations develop their architectures.

● Help federal organizations quickly develop their IT investment processes.

● Serve customer needs better, faster, and more cost effectively.

The FEAF, like other frameworks, is essentially a guide for collecting

information across agencies, face integration problems of unprecedented complexity. And in private enterprises such as healthcare, the need to share information among all stakeholders -- insurers, patients, employers, and healthcare providers, for example -- drives up costs even as all parties try to tie their incompatible systems together to bring costs down.

An EA can alleviate these problems. It provides a mechanism that enables communication about the essential elements and functioning of the enterprise. It yields centralized, stable, and consistent information about the enterprise environment. In an insurance agency, for example, an EA would help executives pinpoint the agency's more lucrative markets, understand how well the company's current resources are meeting customer needs in those locations, and determine what kind of system might be needed to improve services. The precise, high-quality information an EA provides also make it much easier for the organization to respond to the forces of change and make better decisions. And finally, because an EA enables organizations to reduce duplication and inconsistencies in information, they can dramatically improve ROI for future IT implementations.

common architecture information and building a repository to store it.

TEAF

The Treasury Enterprise Architecture Framework (TEAF) was developed by the Department of the Treasury and its agencies (e.g. IRS, Customs, etc). Its goals are similar to those of FEAF, but it is specialized for the Department of the Treasury's domain.3

Enterprise Architectures in Other Contexts

Largely because of the Clinger-Cohen Act, EA is emerging as a significant IT trend in the government sector, including federal, state, and local governments. In addition, a similar trend is emerging in industry, as companies recognize that the IT spending of the past was not well-aligned with organizational objectives, creating islands of information and systems that failed to meet their intended objectives.

Representing Enterprise Architectures

Once you decide that an EA is necessary, how do you go about creating and maintaining one? To date, EA has usually been represented using an odd assemblage of inconsistent techniques. Typically, an organization will begin by preparing slide presentations, and this approach is certainly better than nothing. However, such presentations are surprisingly difficult

to maintain: There is no easy way to keep them up to date as the organization, and its business objectives, change.

Moreover, most organizations that set out to document their systems find no standard methodologies to help them form a consistent and understandable notation. They might use pictorial descriptions to communicate concepts, but the pictures they develop are typically imprecise and vague. Fortunately, there is a better way.

The Unified Modeling Language (UML)

The UML is a visual modeling language developed to combat these kinds of difficulties in the general arena of software development. Soon after its initial release, the software development community realized its potential for much more than visual descriptions of software. In fact, its applicability and ease of use extends to many domains: business modeling, data modeling, and system modeling. It is ideal for developing precise and complete visual descriptions of the elements of an EA, largely because of the availability of good graphical modeling tools based on the UML that teams can use to create and maintain the architecture and its semantics in a central, browsable framework.

Key Benefits of the UML. Today, UML is a standard specification language maintained by the Object Management Group. A principal strength of the UML is that it defines a single meta model. Models developed using the UML are consistent in their definition, and thus support standard traceability and linking. This enables an almost instant understanding of the relationships between elements created in different contexts.

UML-based tools also present the user with another key capability: formal traceability, or linking, of various artifacts to one another. This is perhaps these tools' most important feature, as it lets you develop a formal process for maintaining the various documents describing the EA and the business requirements that EA realizes. The same modeling technique can be used throughout the enterprise to link process, data, and control model elements together. When external factors demand changes to a business level requirement, you can trace the change through the interlinked system of models, starting with the EA, to learn 1) what needs to be modified in individual organizations or systems; 2) how much these changes will cost; and 3) what the impact of this change will be on other systems, markets, and customers. This traceability brings a level of predictability to enterprise development that was not possible before. Stockholders and other stakeholders who are used to seeing vague business predictions change every quarter can begin to hold the company to a higher standard as its ability to maintain a high-quality EA model matures. Also, once you link the EA to actual software systems development projects, it is possible to keep the EA up to date and to measure organizational progress against this "yard stick."

As a language designed for visual representation of models, the UML offers business an excellent means to assess, build, and deploy IT systems that support the organization's core mission in the most cost effective and accurate way possible. Consider the following strengths:

● UML is an industry standard notation for developing and documenting systems of all kinds.

● It can help all the way from capturing the business or operational process to defining the EA and specifying systems that support it.

● By providing a single, rigorous notation for documenting all the disparate views of the EA, UML enables relationships to be more easily represented, communicated, and understood. This facilitates communication and uncovers errors in understanding more easily than other approaches.

● As UML can be used to define the EA as well as the supporting system, it can also be used to assess compliance of a system with the defined EA.

Rational's UML-Based Lifecycle Approach to Enterprise Architecture

As the originator and chief advocate of the UML, and as a pioneer in applying the UML to business process modeling and systems engineering, Rational Software is well positioned to provide a better solution for representing enterprise architectures. The following techniques and tools are particularly well-suited for EA design and implementation in today's businesses.

Use Cases. Use cases provide a proven technique for representing the structure of interaction and results within a software system. They help all stakeholders understand both the organization's mission and what the organization does to achieve it.

As use cases are themselves mission-based, they can help the organization understand how best to allocate resources toward fulfilling that mission. This provides a consistent thread throughout the organization, a way of tying actions to the value they provide. This use-case driven approach breaks through the barriers created by a typical functional decomposition approach, in which actions can become ends unto themselves, disconnected from the mission, and typically result in a collection of flawed processes.

Iterative Development. Rational's solution is also centered on an incremental, iterative approach to developing the EA. Often, EA efforts fail to achieve their objectives because organizations try to define everything, all at once. Many organizations in both government and civilian sectors have discovered that an iterative, incremental approach that is driven by risk mitigation achieves better results because it is more adaptive to inevitable change. The Rational Unified Process® (RUP®) platform codifies best practices for such an iterative approach, allowing the whole development team to work within a single development framework with a single set of artifacts encompassing the entire development lifecycle.

Automated Tools. Rational's tools are designed to automate the RUP, and they are ideally suited to EA development. Teams can use Rational®

RequisitePro® to manage EA requirements and Rational Rose® to visually represent elements in the EA. In addition, Rational ClearCase®and Rational ClearQuest® provide configuration management and change management capabilities that help teams manage the EA as it evolves throughout the project. Rational's toolset also functions across geographically dispersed worksites, enabling multi-site collaboration among colleagues in a controlled and consistent way.

In addition, Rational®ProjectConsole can help managers measure progress as team members collaborate on developing the EA. It collects both standard and custom metrics from Rational Suite® development platform and third-party products, and presents the results graphically so that you can easily assess project progress and quality. This allows you to better predict which areas will require special attention, and where to focus scarce resources that will enable the project to stay on schedule and within budget.

Rational Supports EA-Driven Results

An Enterprise Architecture serves a far greater purpose than simply providing architecture documentation. As companies continue to seek creative methods for "doing more with less," a properly implemented EA can help by driving prudent investments in information systems and technology. If they use Rational Software to construct an EA, teams can then make a smooth transition from the EA to the definition and development of systems that support the organizational mission the EA describes.

The Rational Software Corporation has more than twenty years of experience helping customers deliver complex, enterprise-class applications, using an iterative, risk-mitigating approach that improves the ability to predict and resolve project bottlenecks and deliver on time. Rational's development tools provide support for this approach with capabilities for requirements capture and management, visual modeling, change management, project and program status assessment and control, and automated testing. Integration between tools and process enables greater predictability in delivering EA-driven results at lower cost.

For more information on how Rational Software can help you develop and implement your EA visit www.rational.com or contact Dave West: dwest@rational.com

Notes

1 See http://www.cio.noaa.gov/itmanagement/cohenact.htm

2 General Accounting Office, "Enterprise Architecture Use Across the Federal Government Can Be Improved." February 2002, GAO-02-6.

3 For more information, see http://www.omb.gov

For more information on the products or services discussed in this article, please click here and follow the instructions provided. Thank you!

Copyright Rational Software 2002 | Privacy/Legal Information

Book Review

E-Support: How Cisco Systems Saves Millions While Improving Customer Support by Andrew Connan and Vincent Russell

Cisco Press, 2002

ISBN: 1-58720-052-XCover Price: $24.95204 Pages

E-support is looming as a great challenge for companies seeking to both maximize customer satisfaction and remain financially viable in this troubled economy. What internal organizational structure do you need to implement an e-support site? How did Cisco Systems get 80 percent of its customers to use e-support mechanisms? And how is Cisco managing to save millions while continuing to improve its support offerings?

This book addresses all of these questions. It is both a valuable look inside a company that has been overwhelmingly successful in providing e-support and an insider tour of how the Cisco Systems TAC (Technical Assistance Center) Web site works.

Structured as a series of interviews with the key players behind TAC Web -- the senior director, project managers, technical writers, and site manager -- the book is laced with e-support terminology as well as high-tech colloquialisms (e.g., bleeding edge appears frequently). The interviews themselves convey a sense of intimacy; you feel as if you're sitting in a meeting with all of Cisco's e-Support teams, getting an interior view of how their organization is structured and what methods they use. For example, you learn that Cisco has dedicated technical writers within the teams to transform customer issues into meaningful support content. Also, a bonus of the interview format is that it allowed the book's designer to leverage white space effectively, alleviating the feeling of density that sometimes characterizes a text-heavy book.

The target audience for this book is CEOs and Senior VPs seeking to either implement an e-support solution or improve an existing one. Of particular interest to these execs is the chapter on metrics, which provides graphics and sample charts showing the kinds of metrics Cisco relies on. (Walker Information regularly surveys Cisco customers regarding the TAC Web site content.) The chapter examines the greatest challenges involved in acting on these metrics, as well as what metrics are meaningful and where they

http://www.therationaledge.com/content/nov_02/r_esupportCisco_cb.jspCopyright Rational Software 2002

come from. For example, Cisco measures what technical articles customers access most frequently so that their tech support team can proactively get that information to customers in a more direct form -- either via e-mail messages or by making the content more visible on the TAC Web. Cisco also measures customer satisfaction with the technical content on the Web site, so that they can improve its effectiveness and accessibility.

The guidance this book offers could not come at a better time, as technology companies seek to maximize customer retention through outstanding, and technically efficient, customer support. As a Cisco Certified Network Associate (CCNA), I've found that the TAC Web site can help solve most of the problems I've run into with my home system's Cisco routers and switch. When I have an IOS or configuration problem, it's really wonderful to have help available 24X7 through the site. Cisco proactively helps customers deal with product defects, and actually provides its defect database for online searching through the TAC Web. That means customers can save themselves from falling prey to painful defects by doing some studious searching and taking preventive measures: You don't have to wait until you wind up in a down situation to know what defects can cause serious trouble.

As for the book itself, it has one big weakness: It is not a blueprint. Although it provides a useful peek inside a successful e-support implementation, it does not offer a step-by-step method for creating a comparable system for your company or for "saving millions" with your own e-support solution. The authors could have done a better job of setting appropriate expectations in an Introduction explaining the book's scope and goals or by writing a Conclusion that summed up the interviews. Also, they really don't talk about how the Cisco e-support model might translate to other companies. Will it scale down for companies that don't have the resources to assemble a marketing team devoted exclusively to e-support or a team of writers and editors to gather and shape content from support engineers?

Still, the meeting-style conversations make this book captivating, and anyone involved in creating or maintaining an e-support solution -- from CEOs to technical writers -- could profit from reading it. It does contain a treasure trove of ideas (e.g., incorporating dedicated technical writers into support teams), and it places a bandage on the bleeding edge of e-support by modeling a successful e-support content team. Assembling and maintaining effective content for a support Web sites involves interaction among many business units in an organization, from sales to tech support to engineering. The authors emphasize that the organization as a whole must communicate effectively to get the right information to customers in a way that will provide effective self-service. Overall, the book does a good job of describing the basic vision, scope, and perspective you need to be successful in e-support.

-Carem Bennett, CCNA, MCSE, NT-CIPSenior Content DeveloperRational Customer Service

For more information on the products or services discussed in this article, please click here and follow the instructions provided. Thank you!

Copyright Rational Software 2002 | Privacy/Legal Information

The Future of Software Technology

Interview with Grady BoochChief Scientist for Rational Software

Published with permission of CHIPS Magazine, Fall 2002 (Volume XX, Issue IV).

CHIPS' editors had the pleasure of meeting Grady Booch, recognized pioneer in software development, and hearing him speak at the Software Technology Conference (STC) in April 2002. He had the STC mesmerized with his analysis on current and future technology developments. CHIPS asked Grady to share some thoughts with readers.

CHIPS: Rational products are designed following the Capability Maturity Model for Software Development. Why do you think this is important?

Grady Booch: Over the years, Rational has been involved with customers from around the world in literally tens of thousands of software projects for every imaginable problem domain. From that experience, we've observed what has worked and what has not, then codified those best practices in the form of the Rational Unified Process® (RUP®) as well as made them manifest in and encouraged by our tools. Most significantly, we apply those same practices and tools to our own development: architecture [design] first, develop iteratively, test continuously, model visually, manage requirements, and manage change.

The Capability Maturity Model (CMM), also based upon years of experience with real projects, provides a useful means of comparing the maturity of an organization's process. Among other things, the CMM has given the industry a vocabulary with which to name and characterize the various stages of process maturity.

To say that Rational's products are designed following the CMM is therefore not exactly a meaningful statement: the CMM provides a reasonable measure of process maturity, but it does not prescribe a particular process. That being said, the experience of organizations using Rational's process -- and that includes Rational itself -- has demonstrated that they can achieve higher levels in the CMM by applying the best practices that we have collected over the years.

http://www.therationaledge.com/content/nov_02/f_boochInterview.jspCopyright Rational Software 2002

It is also important to note that while the CMM offers a measure of process maturity, that measure is not necessarily related to the measure of project success. We measure success entirely in economic terms: Does the project provide a good return on investment? In other words, is the amount we're spending, in terms of human and capital expenses, giving back tangible value that forwards the mission of its organization? Functionality, quality, and schedule play a seminal role in this equation; missing functionality, poor quality, and missed schedules represent failures in delivering tangible value. Similarly, opportunity cost plays a role: Are these scarce human and capital resources being spent wisely and intentionally on the most important thing to my organization?

These economic measures are of primary importance, because they relate directly to the primary product of any development team, namely, the executable software itself. The CMM is relevant insofar as it relates to the predictability and repeatability of these economic measures: A chaotic process will be neither predictable nor repeatable, but a mature process will be both -- and an exceptional process will predictably achieve better results over time.

Running somewhat counter to the goals of predictability and repeatability is the need for agility: For all kinds of software-intensive systems, the development team must cope with changing technology, changing context, and changing user needs. Among other things, the dot bomb era demonstrated quite soundly that agility and speed without a predictable and repeatable economic model is doomed to failure. Technology does change, the business and environment do change, and user needs do change -- but these forces must be balanced with repeatable and predictable processes that yield a good return on investment both in the short and long term.

The best practices I spoke of earlier -- architecture [design] first, develop iteratively, test continuously, model visually, manage requirements, manage change -- exist because they are proven to help an organization make the proper engineering and business decisions that balance the forces upon the software development organization. By focusing on architecture first, one intentionally attacks the highest technical risks in the system; by developing iteratively, one has the opportunity to reach closure on a regular rhythm and then make intelligent midcourse corrections relative to the current business and technical risks. Testing can then happen continuously with each new release representing a baseline against which the emerging product can be measured relative to the current (and more deeply understood) requirements of the system. Modeling permits the team to visualize, specify, construct, and document the artifacts of a software-intensive system so as to control its architecture and reason about elements that cannot be known at the level of pure code. The management of requirements and the management of change refer to the intentional consideration of changing user needs (for the mere presence of a release will tell the user things they could not have known or asked about initially) and of the artifacts that constitute the developing product itself.

Relative to the CMM, the RUP -- which codifies these best practices -- defines a mature process that is predictable and repeatable as well as

agile. We use these practices ourselves because they work and because, as a user of our own products, we too seek a good economic return on the investment we place in building software. Rational produces a new release of all of its products twice a year, with many more releases made internally. We simply could not develop that much quality software without following our own process and using our own tools. Furthermore, we are getting better and better each year -- the sign of a mature process -- and since those practices are embodied in the RUP and in our tools, the same benefit is made possible to the users of the RUP.

CHIPS: With so many challenges to security and a standard architecture for mobile devices, what do you think the design plan should be to overcome these problems?

Booch: Building secure systems is not a core competency of the average code warrior, who already has a multitude of skills to balance. Furthermore, individual developers have a difficult enough time making reasonably optimal local decisions, but building secure systems requires making a long series of local design decisions that are globally optimal as well; in short, the problem of security is a classic one of aspect-oriented programming, that of crosscutting concerns. At

Rational, for example, in addition to our chief architect (who oversees significant design decisions across all of our products), we also have a security architect. Security is a systemic issue: It must be defended logically in the design of the software itself, physically in the design of the network, and physically in the human processes that interact with a secure software-intensive system.

The presence of wireless connections to a network introduces a completely new set of security issues that further complicate the problems of building secure captive wired systems. First, without an intentional effort to manage the system's topology, adding wireless connections can inadvertently open wide holes in an otherwise secure network. Second, the current standards for secure wireless transmission are still immature.

Architecturally, if you have to have wireless connection to a system, the one thing you can do is to form an air gap between the wireless elements of your network and the wired elements. In this manner, you can apply all the usual techniques to make your wired network impenetrable, but defend it from unexpected intrusions via the unwired side by either totally eliminating communication, making communication unidirectional, or vigorously guarding communication between the two elements. It goes without saying (but I'll say it anyway) that active intrusion detection and response is a must in systems with unwired elements.

CHIPS: What do you think the next breakthrough will be in software development?

Booch: Your question assumes that there have been previous breakthroughs; in my experience, there have been none, nor do I expect any in the immediate future. Now, that may sound terribly pessimistic, but

it's not really that bad.

The history of software engineering has been one of growing levels of abstraction -- we see this in our languages (assembly to FORTRAN to Ada to Java), our methods (structured analysis and design to object-oriented design), and our platforms (programming running on raw iron to basic operating systems to platforms such as .NET and J2EE). This growth has occurred simply as a meaningful engineering response to the growth in complexity in the kinds of software systems we as an industry are asked to create. If you examine every one of these advances, there are no breakthroughs that I can identify (although historians in retrospect may label what they call major events -- but you must remember that history is written by the winners…). Rather, every advance is built upon the experiences of the previous technology. Such is the nature of scientific and engineering progress: We try something, we learn from experience what works and what does not, and we progress by claiming what works and improving upon what does not. Thus, you might say that the UML was a breakthrough. Well, its presence is certainly important, for it has become a part of the mainstream of software development. However, the UML has its roots in developments that began over a decade ago, and it's that decade of use and experimentation that has made it what it is today -- a technology of value that helps organization build better software faster.

Ours is a ruthless industry: It has its fads, but ultimately, those things that do not add value are quickly discarded. Building quality software --intensive systems that matter -- is fundamentally hard, and just as Fred Brooks observes, I don't see any development in the near future that will change that.

Now, that being said, as Chief Scientist at Rational, my role is to worry about software engineering as it might be three to five years from now. Where possible, we try to invent that future (inventing the future is the best way to predict it, as Alan Kay has observed); otherwise, I stay close to a diverse community of software engineers around the world to track and, where I can, contribute, to their thrusts in this space. A few years ago, this is why I injected myself into the patterns movement. Today, there are a handful of technologies on my radar screen: aspect-oriented programming, model-driven development, collaborative development environments, architectural patterns, and the semantic Web are the ones I'm spending most of my energy on. Will any of these represent breakthroughs? No, I don't think so, although I do think that any one of these elements can nibble away at current points of friction in the way we build software today.

What holds us back the most in building better software faster is not a problem of technology. Computer science tells us some things about the limits of software and how we might best lay down code or design our systems, but ultimately, software development is a human problem. As such, the problems of organization and process (and politics) weigh most heavily upon success in delivering quality software-intensive systems. The cost of software-intensive systems is thus no longer dictated by the cost of

hardware or tools but by each individual's and collectively the team's ability to deliver; improving the productivity of the code warrior and of the team thus can have a large economic impact. The Unified Modeling Language (UML) has gained broad industry acceptance as the industry-standard language for specifying, visualizing, constructing, and documenting the artifacts of software systems.

CHIPS: Why is UML important and how does it fit in the Object Management Architecture?

Booch: I have been pleasantly surprised at the breadth and depth to which the UML has entered the mainstream of software development. We see its use in virtually very kind of problem domain, all around the world. As I said earlier, ours is a ruthless industry, and the UML would not have the degree of penetration it does today if it did not add value.

The UML is all the things you describe, but from that I'd observe that the UML is important because it addresses several points of pain in building software-intensive systems. First, again as I mentioned earlier, software development is fundamentally hard, and the way we counter that complexity is by abstraction. The UML permits a

team to visualize and construct abstractions that transcend the underlying implementation language. As even James Gosling has observed, there are some things you can reason about when staring at raw Java, but many things you cannot (but which you can do in the UML). For example, extracting and/or imposing patterns for security or messaging is far more easily done at the level of models than at the level of code (although those patterns in models most certainly end up being manifest in code). Thus, the UML is important for architectural control.

Second, the UML is important for the individual code warrior for the same reasons, although at a different level of abstraction. In developer's use of Rational's eXtended Development Environment (XDE) for Visual Studio .NET and Eclipse, for example, we see code warriors using UML models extracted from code to better understand and navigate their implementation, and then to use these models or build new ones to push their abstractions into code.

Third, the UML addresses the problem of coordinating the disparate viewpoints of the many stakeholders who contribute to the creation of any nontrivial system. The great thing about the UML is that it provides a single, unambiguous language of blueprints that a system's domain experts and developers can use to communicate with one another. Thus, we see business experts, domain experts, and end users expressing their desired behavior for their system in the UML, with the code warriors, analysts, testers, and even network engineering using the same language to construct the system. Having this common language facilitates the bandwidth as well as the quality of communication among those who must collaborate to build and deploy a software-intensive system.

CHIPS: What is the benefit of UML for users? How will using the OO/UML model benefit the Navy's C4ISR enterprise architecture and joint fighting

capability?

Booch: The benefit to users is what I express in the third element above: Through the UML's language for use cases (and associated behavioral elements), users have a language whereby they can assert their desired behavior for a system and then effectively collaborate with those who must turn those desires into reality.

This is especially true for frameworks such as C4ISR (and I'd add to that .NET, J2EE, and emerging standards for homeland defense and other government enterprise architectures). The value of an architecture such as C4ISR is that it provides a higher level of abstraction upon which one may build systems. None of these platforms I've mentioned is trivial, and by expressing them in the UML (as has been done for C4ISR) across all the various views different stakeholders may see of the platform, one makes possible both the architectural as well as the implementation benefits of applying the UML. In this way we finally have a relatively seamless and smooth mapping from the highest level enterprise architecture abstraction to the software system abstraction to the implementation in code, and thus a single communication tool from inception to implementation. Ultimately, this translates into helping teams build quality software faster.

CHIPS: Some experts say that the full potential of the Internet for e-business processes has not been realized yet. What important trends in e-business do you forecast? How can the Navy cash in on this still emerging technology?

Booch: The most important trends I see in e-business derive from what we've learned in the dot bomb era: first, we've learned that raw technology without a proper mapping to the human and financial needs of the enterprise is doomed to failure and second, we've learned some canonical architectures for e-business systems that do work.

In the first case, the essence of this lesson is a human one: I think that we as an industry better understand the need to develop any kind of e-business technology with the particular needs of its various human users and financial stakeholders. In the second case, this is a simple matter of having experimented with various Web-centric enterprise architectures and discovering what works well and what does not. For example, throwing together a system with Perl duct tape may be expedient, but results in a brittle system; for this reason, platforms such as .NET and J2EE have emerged, and there exist patterns of use that we better understand (for example, where to build the business rules in a system, how to manage communication among loosely-coupled systems, how to architect the illusion of a session).

As for trends, the rise of the use of XML is certainly a good thing; work on standardizing XML schemas for various domains is also a welcome trend. I'm encouraged by emerging standards for security and agent computing as well.

As for the Navy cashing in on these technologies (can I really comment on that that? I'm a USAFA graduate, you know, and there's this Air Force/Navy game coming up soon, and we know who's going to win…), I

can only advise that first, there must be a good economic model for any investment in this space. Consider the points of pain in your existing human processes, and then and only then consider what technology might do to eliminate that pain. The best way to reduce the risk of software development is to not write any software at all, and thus, rushing in to cash in on a technology is the wrong order of priorities: identify what hurts first, and then build or buy the right technology to cure that pain. Don't underestimate the capacity the Navy and the DoD has in general to influence the commercial marketplace -- helping to direct this emerging technology while learning from the commercial space is far more cost-efficient than trying to invent this stuff by yourself in a cave.

CHIPS: When asked at the STC, What scares you the most? You said, the fragility of network security. With so many security risks in the form of information terrorism to the nation's information infrastructure, what steps should be taken to ensure protection?

Booch: As I mentioned in an earlier answer, building secure systems is a systemic issue that requires a long series of local design decisions at both the conceptual and physical levels. Unfortunately, the sad reality is that too many platforms are inherently insecure, and even the best laid plans can go astray on top of a wobbly, porous platform. To quote a line from the movie Network, I'd say "I'm mad as hell and I'm not going to take it anymore." We individually can respond to the presence of lousy software, simply by not buying it. Unfortunately, we often still do because we don't think we have any control or any other options. Well, as I suggested earlier, the Navy in specific and the DoD in general is not a tiny market, and collectively, a common voice from this community saying that you won't stand for insecure platforms will indeed speak volumes to those who produce those platforms.

I'm currently working with a group responsible for the electric power grids in the Northeast. It's truly humbling and frightening at the same time to gaze at the architecture of the system that will keep the lights on in Manhattan -- it's humbling because what we do here will be invisible to the end user, but ultimately must not fail; it's frightening because I see all sorts of risks (which we know we can mitigate); but I worry about those that we do not see. Every kind of software-intensive system of this size embodies similar risks. Mitigating those risks requires intentional emphasis in understanding the ways in which that system might be breached (and it will be breached) and how it therefore might be defended against.

CHIPS: I heard you say that you are a voracious reader; what types of books do you read?

Booch: OK, now that you've put security in the front of my mind, I just checked the locks on my doors and engaged the alarm system as well; let me take a deep breath and proceed… I recently finished cataloging the books in my collection; I've close to 2,000 books on software in my

professional library, and my wife and I have over 4,000 books in our private library. I read a lot of software books every year simply to stay up with contemporary and emerging technology; on my desk at this moment are several books I'm reading dealing with business rule modeling as well as a few others -- in a totally different space -- concerning current research in quantum computing and cognitive science. I subscribe to about twenty trade magazines and ACM/IEEE journals as well (my mail carrier hates me, I think, but on the other hand, Amazon loves me). On the personal side, I primarily read a lot of history and biographies (I'm slogging through Gotham, a detailed history of New York City, plus I am up to volume two of Churchill's memoirs of World War II, The Grand Alliance, and I am halfway through Margaret Thatcher's Statecraft), especially those centered around the Middle Ages and the Renaissance (which complements my passion for music -- I play the Celtic harp). I read deeply in the areas of philosophy and spirituality (I just finished How We Believe by Michael Shermer). When I need a break from reality, I'll read science fiction (Terry Pratchett and Neal Stephenson are my favorite authors in the genre) or works such as Interpreter of Maladies by Jhumpa Lahiri and Ex Libris by Ross King. For a typical day on holiday, my wife and I will both consume one or two books per day.

For more information on the products or services discussed in this article, please click here and follow the instructions provided. Thank you!

Copyright Rational Software 2002 | Privacy/Legal Information

Book Review

Hacker's Delight by Henry S. Warren, Jr.

Addison Wesley, 2002

ISBN: 0-201-91465-4Cover Price: US$39.99306 Pages

Hacker's Delight by Henry S. Warren Jr. is a delight indeed. Despite its title, this volume of mathematical programming tricks has nothing to do with breaking into other people's computers. Warren is a hacker in the original sense of the word: someone who enjoys writing clever code and finding elegant solutions to computing problems. He discovered many of the tricks and methods he presents in the book during a forty-year career working on compilers and computer architecture with IBM's Research Division. His collection of code snippets and equations range from basic arithmetic operations to sophisticated mathematics.

Computer math may not be a subject that appeals to a broad range of readers, but this book is a gold mine of useful methods and information for those who are interested. The engineer writing a compiler, a math library, or any highly optimized code will find the book indispensable. Anyone familiar with assembly language will find the book accessible and interesting. It can be read from front to back, used as a reference, or enjoyed in the manner Guy Steele describes in his foreword to the book: "Devouring these little programming nuggets was like eating peanuts, or rather bonbons -- I just couldn't stop -- and there was a certain richness to them, a certain intellectual depth, elegance, even poetry."

The book begins by giving a set of formulas for simple operations that one might encounter in the course of writing assembly-level programs. For example, the fastest way to determine whether an unsigned integer is a power of 2 is:

x & (x-1)

If x is a power of two, the expression evaluates to zero; for other numbers it is nonzero. This section of the book can take days to finish because, for the reader who enjoys recreational bit-wrangling, it is tempting to take a pencil and test each of Warren's assertions. Like many of Warren's formulas, x & (x-1) is not an obvious solution at first glance, but once you

Copyright Rational Software 2002 http://www.therationaledge.com/content/nov_02/r_hackersDelight_sm.jsp

work through it and look at the bits, you can see that it works. In this instance, I tried 8 (a power of 2) and 6 (not a power of 2):

x = 8 6x = 0000 1000 or 0000 0110x-1 = 0000 0111 0000 0101x & (x-1) = 0000 0000 0000 0100 zero nonzero

The book goes on to give formulas for counting the 1-bits in a word, isolating the rightmost 1-bit, flipping the rightmost contiguous string of 1-bits, shifting and propagating bits, reversing the order of bits and bytes, transposing a matrix, and so on. More than half the book is a collection of methods for doing basic calculations efficiently. Code examples are given either in C or in a simplified assembly language the book defines for 32-bit RISC machines.

Code for Simple to Complex Mathematical Operations

In the course of everyday software engineering, most of us just link our programs with a standard math library and take it for granted that the machine knows how to perform multiplication, division, and other operations on unsigned and signed integers, long integers, floating-point numbers, and so on. This book goes into greater detail, explaining exactly how to do each of these calculations.

After disposing of basic arithmetic operations, Warren turns his attention to more complex math problems -- calculating square roots, for example. His discussion of the subject is both complex and simple. First, he explains Newton's method of computing square roots through a page full of equations that require some effort to follow -- but then he gives an implementation that requires fewer than twenty lines of C code. This is followed by another method that is longer and more cryptic but executes faster, by using a binary search algorithm. Whether you are interested in the equations or merely need the C code to do your job, Warren's solutions are efficient and elegant. Here is his code for computing an integer square root using Newton's method:

int isqrt (unsigned x) { unsigned x1; int s, g0, g1;

if (x <= 1) return x; s = 1; x1 = x - 1; if (x1 > 65535) {s = s + 8; x1 = x1 >> 16; } if (x1 > 255) {s = s + 4; x1 = x1 >> 8; } if (x1 > 15) {s = s + 2; x1 = x1 >> 4; } if (x1 > 3) {s = s + 1;} g0 = 1 << s; // g0 = 2**s. g1 = (g0 + ( x >> s)) >> 1; //g1 = (g0 + x/g0)/2.

while (g1 < g0) { g0 = g1; g1 = (g0 + (x/g0)) >> 1; } return g0;}

The book also offers similar solutions for computing cube roots, exponents, and logarithms.

Pursuit of Fascinating Problems

The last few chapters of the book discuss topics chosen seemingly at random from a range of mathematical subjects the author has found interesting. One of the more fascinating chapters, which is far "outside the box" in relation to today's computers, discusses unusual bases for number systems and considers their possible use in computing. Base -2, for example, is a system in which both positive and negative numbers can be represented without using an explicit sign bit. As in the more familiar binary system, negabinary numbers are represented by 0/1 bits -- but the sign flips in every other digit. So instead of the digits being valued (1, 2, 4, 8, 16…), they are valued (0, 1, -2, 4, -8, 16…). The advantage of negabinary numbers is their simplicity in representing negative numbers, but their downside is that negabinary arithmetic operations such as division are quite complicated. Warren also discusses positive and negative complex base systems. In bases in which digits are valued based on powers of the numbers (-1 + i) or (-1 - i), all numbers both real and imaginary can be represented by 0/1 bits. He briefly touches on base e numbers, and finally considers the question of which base is the most efficient one for computing.

Other topics Warren addresses include Gray codes, the Hilbert curve, and prime numbers. Gray codes are a method of arranging the integers from 1 to N in a list so that each number can be visited exactly once by flipping only one bit at a time. The Hilbert curve is a similar idea expressed geometrically: a single continuous curve which, given a space divided into a grid of squares, touches every square exactly once and does not cross itself. In each case, Warren provides both the mathematical discussion and the code to solve the problem.

The chapter on prime numbers is the most challenging mathematically but also one of the most interesting. It starts with a concise overview of various mathematicians' efforts to devise ways of finding prime numbers. "Like many young students, I once became fascinated with prime numbers, and tried to find a formula for them," explains Warren. Actually, this statement is the key to the whole book. The author is one of those people who periodically become fascinated by some problem and devote themselves to learning more about it and searching for a solution.

The chapter ends not with Warren's usual code sample, but instead with an invitation to continue the search for interesting solutions to the problem. Clearly, the author views this book not as a finished collection, but rather as a snapshot of work in progress. After decades of interest-

driven research, Henry Warren has amassed a collection of studies big enough to fill a book. It is fortunate for the rest of us that he has written one, and I look forward to the next installment.

-Susan McVeySoftware Quality EngineerRational Software

For more information on the products or services discussed in this article, please click here and follow the instructions provided. Thank you!

Copyright Rational Software 2002 | Privacy/Legal Information

Modeling Software with Rational XDE and Visual Basic .NET: An Introduction to Class Diagrams

by Dan Petit

Editor's Note: Each month, we will feature one or two articles from the Rational Developer Network, just to give you a sense of the content you can find there. If you have a current Rational Support contract, you should join the Rational Developer Network now!

Experienced coders who are new to modeling sometimes find it peculiar. Perhaps to them modeling seems too difficult, with all its strange symbols and diagrams. Maybe modeling seems like extra work or a waste of time, since many coders can code most small applications without significant formal design or modeling. Or perhaps they simply don't see the need, no matter what the size of the application.

Visual Basic programmers are especially prone to thinking modeling isn't needed. Visual Basic is arguably the most immediately satisfying language there is (and has been for years): developers can very quickly draw a working user interface, click Run, and immediately see the fruits of their labor. It's as close to instant gratification as you can get in software development, and the language itself is deceptively simple. When creating the application seems so easy, why bother with modeling?

There are also other reasons for this reluctance to model. Traditional software modeling ý from, say, a whopping five to ten years ago - was usually awkward, like a forced afterthought (or more often, pre-thought) to coding. It was difficult to establish a flow between the modeling and coding because you had to first do some modeling, then switch gears to write some code, then switch gears again to update the model, then switch again, and so on. Since the code and models had to be synchronized by hand, the process was discouragingly complex.

As we'll see shortly, the .NET Edition of Rational® XDETM Professional v2002 helps resolve this problem by combining a simple modeling language (the Unified Modeling Language, or UML) with an integrated coding/modeling environment as part of Microsoft Visual Studio .NET. So, if you're a Visual Basic .NET programmer who has been puzzled by modeling, or you're just waiting for the right time to take the plunge, Rational XDE and this article are for you.

This article will explore the basics of modeling simple Visual Basic .NET classes. After taking a look at why the UML and modeling are important, we'll walk through a simple

Copyright Rational Software 2002 http://www.therationaledge.com/content/nov_02/rdn.jsp

example of how to model and code with Rational XDE Professional v2002 Release 2.1 ý .NET Edition and Visual Studio .NET. We'll see how XDE integrates modeling with coding and turns their historically hard-to-manage relationship on its head with code-model synchronization.

Note: C# developers should refer to the article "Modeling Software with Rational XDE and Visual C#, Part 1: An Introduction to Class Diagrams" [available on RDN; registration required], which is similar to this article except that it focuses on Visual C# rather than Visual Basic .NET.

This article is not intended to be a detailed tutorial on the art of modeling; rather, it will discuss the mechanics of the technique. Modeling is like painting, and we're going to cover only the basics of mixing paint and a few simple brush strokes, not how to have artistic vision. Also, the article won't discuss all the details of using Rational XDE, so it will help if you have some previous familiarity with this environment from Rational. To try out the steps in the article, you'll need to have XDE up and running. Additional sources of information about both modeling and XDE are listed on RDN [registration required] under "References and Other Resources," and an evaluation copy of XDE is available on Rational.com.

The UML - Consolidated Theories of Modeling

So, what is the Unified Modeling Language? To paraphrase its oft-quoted definition (from Booch et al., The Unified Modeling Language User Guide), the UML is a language for visualizing, specifying, constructing, and documenting software systems. Although it's a thorough language, it's not complicated. Nor is it intended strictly for tech-heads; it's accessible by a wide audience, helping to bridge the semantic gap between product definition teams (who are usually not technology-savvy) and developers.

Like any language, the UML provides a syntax and grammar for its use ý in this case to facilitate the creation of models. It represents a reasonable consolidation of numerous modeling theories that emerged in the late 1980s and early 1990s, when object-oriented analysis and design was just becoming a mainstream phenomenon. Many of the theories and techniques behind the UML are drawn from three sources. From Grady Booch's "Booch Method," the UML gains a practical perspective for object design and code construction. Ivar Jacobson's work with use-case-driven software creation figures prominently, and James Rumbaugh's Object Modeling Technique (OMT) brings its data-centric approach to analysis. After joining forces, Booch, Rumbaugh, and Jacobson (affectionately known as the "three amigos") went on to author the aforementioned UML user guide.

Modeling in the UML takes place through diagrams, and the UML offers numerous kinds of diagrams to describe just about anything you'd want to talk about related to software. In this article, we'll focus on a type of diagram known as class diagrams, for two reasons: they're among the easiest of diagrams to understand and create and they're also among the most practically useful.

Why Model?

The UML is important in much the same way modeling itself is important. A model is simply a representation of your software system. Modeling makes it possible for you to plan your software development, prove your concept, explore seemingly fanciful ideas, test the validity and completeness of your system's requirements, and document your software, all without going through the trouble of coding it. Even in Visual Basic, programming can be difficult and time-intensive, especially compared to modeling. Modeling is far faster, simpler, and cheaper than the code-first-ask-

questions-later approach. Furthermore, with the new features of Visual Basic .NET (inheritance being among the most significant), it's now even more important to plan and design through modeling before beginning to code. Continuing to model while you code helps keep things clear; the model of your code and the diagrams based on that code can provide constant visual clarity to your code. The moral of the story is simple: combining modeling and coding makes it possible to create better software, faster.

But the best way to see the benefits of the UML and modeling is to see them in action. For the remainder of this article, we'll look at a very simple sample application (which you can download from RDN; regisration required). Although simple, this application is meant to fulfill part of a realistic requirement that's commonplace in businesses today: payroll computation. It will compute part of the paycheck amount for the various employees of a company. To keep things easy, we won't bother with deductions or taxes or any of that mess; we'll only compute the gross pay for each employee. We'll also simplify the data access typically associated with payroll systems by gathering the data from the user through prompts. (A full-blown application would presumably gather this information from a database.) Finally, the emphasis here will be on modeling rather than coding. The completed system will have very few handwritten lines of code.

Getting Started

You'll usually begin the design and modeling process by identifying the participants in your system ý that is, the entities, or nouns, in your business domain. This enables you to size up the problem and gain a better understanding of what you're up against. The source of this information can be your use cases, requirements documents, user interface specifications, prototypes, common sense, or (usually) some combination of these.

When it comes to computing paychecks, the entity that springs to mind immediately is "employee." An employee is someone who gets paid. All employees have some basic attributes, such as first name, last name, employee ID number, and social security number, which help to identify them. (Admittedly, there are many other potential attributes, but we'll omit them here for simplicity.) There are also some behaviors associated with an employee. Of importance to us is the "get paid" behavior, which we'll reduce to computing the gross pay amount ý that is, an employee will know how to compute its own gross pay.

This overview gives us a good starting point. However, as we look a little more deeply into this, it becomes clear that the term "employee" is too broad. Companies typically have many kinds of employees. For example, in addition to hourly workers, there may be salaried employees, managers with potential bonuses, and salespeople with sales commissions, to mention but a few. Table 1 summarizes some standard kinds of employee. In our application, each type of employee will be able to compute the gross amount of its own paycheck.

Type of employee Method used to compute paycheck

Hourly Hourly Number of hours worked * hourly rate

Hourly with overtime Number of regular hours worked * regular hourly rate + number of overtime hours worked * overtime hourly rate

Salaried Yearly salary * part of year represented by pay period

ManagerYearly salary * part of year represented by pay period +bonus amount if pay period falls when bonuses are to be paid

Comissioned Base yearly salary * part of year represented by pay period +sales * commission rate

Table 1: Employee Types and Paycheck Calculations

In working through this example, we'll encounter the concept of code-model synchronization, whereby XDE will generate code from your model, modify your model based on changes to the code, or a combination of both (depending on how you configure it, as discussed under "Configuring Synchronization"). The complexities of synchronization with XDE can be a bit tricky to understand at first, but this simple example should serve as a good introduction.

Configuring Synchronization

Exactly what Rational XDE does, or not, along the lines of code-model synchronization is configurable at many levels. You can view and set general synchronization policies by choosing Tools > Options and then, on the left in the Options dialog, selecting Rational XDE > Round-Trip Engineering > General (see Figure 1).

Figure 1: Rational XDE Synchronization Options

In addition, you can set the synchronization policy for just about any UML element, by changing the element's SynchronizationPolicy property in the Properties

window to one of the four values shown in Figure 2.

Figure 2: Synchronization Policy Options

The options you can set in the Options dialog include the following:

● You can adjust when XDE should perform code-model synchronization. It can happen either when you manually request it, as done in this article, or automatically when you switch windows or save your project. Until you've become accustomed to its behavior, I recommend leaving Automatic Synchronization off to maintain better control over when XDE changes your code or model. Also, slower systems may experience a significant lag if it's left on.

● You can define how XDE should behave when there's a conflict between the code and the model during synchronization. (When there's no conflict, XDE simply merges the two representations of your system.)

● You can control how synchronization behaves when applied to items referenced beyond those selected.

Creating the Initial Model

Although at this point our basic entities aren't very well defined, we can still begin modeling. In fact, the process of modeling will help us define our entities more fully. To get started:

1. Create a new, blank Visual Basic .NET Windows Application Project called GrossPay.

2. Rename Form1 to frmMain and rename the file Form1.vb to Main.vb. The sample application provides a simple user interface with this form. Although the creation of the interface itself won't be described in this article, the empty form will be left in the model for reference (with the completed example showing the code residing in this form).

3. Save everything. (It's a good idea to save frequently while learning how to model.)

4. Right-click the project in the Solution Explorer and choose Synchronize, which will direct XDE to synchronize your model and your code. Since there's no existing model, XDE will create one corresponding to the project. It will then open the Model Explorer and list the new model there (similar to what's shown in Figure 3).

Figure 3: GrossPay Project in the Model Explorer

Note that instead of Synchronize you could have chosen Reverse Engineer, which causes XDE to generate a model from your code. Since there was not yet a model, both commands would have had the same effect.

When creating the empty model, XDE also configures itself so that its code generation and reverse engineering capabilities understand Visual Basic ý after all, it wouldn't do us much good if XDE worked in C# while we worked in Visual Basic.

As can be seen in Figure 3, XDE creates a default diagram called Main. But since by default this diagram is not under the GrossPay namespace (indicated in the Model Explorer by curly braces, {}), generating code from classes created on the diagram (as we'll do in a moment) won't work correctly. We'll fix this in the next step.

5. In the Model Explorer, drag the Main diagram from its current location to under the GrossPay namespace.

Adding a Class

Since (following the concept at the heart of object-oriented analysis and design) our entities will map to classes, we'll add our first class to the model, the Employee class:

1. Double-click the Main diagram in the Model Explorer to open its window.

2. Select the Class tool from the Toolbox (see Figure 4).

Figure 4: Rational XDE Toolbox with Class Tool Highlighted

1. Drag from the Class tool onto the empty diagram. When you release the mouse button, you'll have a blank class.

2. Name the new class Employee. It should look like the empty Employee class in Figure 5. Note that the class will also appear in the Model Explorer.

Figure 5: Empty Employee Class

Figure 5 shows the Employee class in standard UML notation, as a box containing three sections. The top section holds the name of the class; the middle section holds the attributes of the class (of which there are none yet); and the bottom section holds the operations (methods) on the class (of which, likewise, there are none yet).

Adding Attributes

Now let's add the attributes FirstName, LastName, EmployeeID, and SSN to our class. There are four common ways of doing this, and we'll look at each in turn.

Adding an Attribute Through the Diagram

Let's start by adding the FirstName attribute:

1. In the diagram, right-click the Employee class and choose Add UML > Attribute.

2. Enter FirstName, a colon, and then the type, String. The class should now look like the one in Figure 6.

Figure 6: Employee Class with FirstName Attribute

In the UML, an attribute usually appears with its visibility, its name, and its type. The visibility is indicated by one of the symbols listed in Table 2 and is followed by the name and then the type. Figure 6 shows that the class Employee has a public attribute named FirstName of type String.

Symbol Visibility Visual Basic .NET keyword

+ Public Public

- Private Private

# Protected Protected

~ Package Friend

Table 2: Attribute Visibility Symbols Mapped to Visual Basic .NET Keywords

Adding an Attribute Through the Model Explorer

Another way to add an attribute is through the Model Explorer. Let's add the LastName attribute that way:

1. Switch to the Model Explorer.

2. In the Model Explorer, right-click the Employee class and choose Add UML > Attribute.

3. Enter the name of the attribute, as LastName. Notice that the model is updated automatically.

4. To give the new attribute a type, expand the Employee class in the Model Explorer, right-click the LastName attribute you just added, and choose View > Properties Window (or press F4).

5. Under TypeExpression, enter String (see Figure 7).

Figure 7: LastName in the Properties Window

Note that XDE also provides a more code-specific counterpart to the Properties window, called the XDE Code Properties window (which you can access through View > Other Windows > Code Properties, or the shortcut Shift+Alt+P); see Figure 8. Because this window lets you configure which keywords XDE will apply during code generation, it provides an even simpler mechanism for fine-tuning XDE's behavior.

Figure 8: LastName Attribute in XDE Code Properties Window

Adding an Attribute Directly to the Code

Now let's add the EmployeeID attribute. This time, however, we'll add the attribute directly to the code.

1. In the class diagram or the Model Explorer, right-click the Employee class and choose Synchronize.

2. Switch to the Solution Explorer and notice that XDE has generated a new class. At the moment, this class features only the attributes we've just created.

3. Double-click the class in the Solution Explorer to open its code editing window.

4. Edit the code to create a public Integer value named EmployeeID after the LastName attribute. Your class should now look like Listing 1.

Public Class Employee Public FirstName As String Public LastName As String Public EmployeeID As IntegerEnd Class

Listing 1: Employee Class

At this point, if you switch back to the model you'll notice that the EmployeeID attribute doesn't appear there. Unless you have automatic synchronization enabled ("Configuring Synchronization"), you'll have to force the synchronization of the model and code by hand, which is simple to do: switch back to the class diagram or the Model Explorer, right-click the Employee class, and choose Synchronize. The Employee class in the model should now look like Figure 9.

Adding an Attribute Through a Property

You can see that adding attributes to classes is very straightforward. Generally, though, rather than add public attributes as we've done so far (to keep things simple), you'll want to add private attributes with public property Get/Set accessors. Using property accessors helps control access to class data and makes for better encapsulation. XDE presents a detailed dialog box that simplifies the process of creating the attribute and its corresponding property accessors. Let's add an attribute for the employee's social security number (SSN):

1. In the Model Explorer, right-click the Employee class and choose Add Visual Basic > Property.

2. Fill in the dialog box as shown in Figure 10 to add the SSN attribute as a property with Get and Set accessors.

Figure 10: XDE Add Visual Basic Property Dialog for the SSN Property

3. Click OK. The Employee class now should look something like Figure 11.

Figure 11: Employee Class with SSN Property/Attribute

You can see that XDE generated the following:

● a public attribute named SSN, labeled with the <> stereotype

● a private attribute named msSSN

● two methods named SSN, labeled with <> and <> stereotypes

A stereotype is simply a labeled classification of UML elements that's used to create other UML elements. In this example, the <> stereotype is applied to an attribute to make a more specialized kind of attribute (a property), and the <> and <> stereotypes are applied to methods to create specialized methods (property accessors). In the next section, we'll look at adding another kind of method (a simple method to perform a basic class behavior). For now, remember when adding UML attributes that XDE doesn't automatically create corresponding Visual Basic properties; you must explicitly choose Add Visual Basic > Property. Also note that although the property we created here was very simple, the XDE Add Visual Basic Property dialog lets you control every aspect of the property you're adding, including its modifiers (Shared, MustOverride, and so on) and its parameters.

With a property modeled, we can right-click the Employee class in the Model Explorer and choose Generate Code, which causes XDE to generate the code shown in Listing 2. (The Region comments are added by default and can be removed with no impact on round-trip engineering capabilities; unfortunately, there's no way to prevent XDE from adding them in the first place.)

Public Class Employee

Public FirstName As String Public LastName As String Public EmployeeID As Integer Public Property SSN() As String Get ' #Region "XDEOperation" ' Begin Template Expansion{05DB3E79-8D05-42A3-AE85-7BAF0003D0C1}

Return msSSN ' #End Region ' XDEOperation End Template Expansion{05DB3E79-8D05-42A3-AE85-7BAF0003D0C1} End Get Set(ByVal Value As String) ' #Region "XDEOperation" ' Begin Template Expansion{9F7A6EF3-CD51-4B5E-A4AE-14FF8340474A}

msSSN = Value ' #End Region ' XDEOperation End Template Expansion{9F7A6EF3-CD51-4B5E-A4AE-14FF8340474A} End Set End Property Private msSSN As StringEnd Class

Listing 2: Employee Class with SSN Property Generated by XDE

The fact that Rational XDE allows code to be generated from a model or vice versa from within the Visual Studio .NET IDE is a significant advantage for developers. It's arguably the most important innovation since a compiler and linker were added to an editor to create the first IDE. This code-model synchronization capability is further strengthened by the fact the even comments in the code and documentation in the model have direct links to one another. In XDE, you can add documentation to any model element (simply by selecting the element and entering its documentation into the Model Documentation window). When the code is generated from the model, the documentation is automatically embedded into comments, XDE can also do the reverse, transforming comments into model documentation.

Adding a Method

We've seen how to add a property accessor type of method to a class as the result of creating a Visual Basic property, but now let's look at how to add a simple method to perform a basic class behavior - specifically, the ComputeGrossPay method. It will be responsible for computing the gross pay amount for our employees. However, note that a generic "employee" doesn't really exist. All employees are already one of the kinds of employee listed in Table 1. Therefore, the Employee class's ComputeGrossPay method should be implemented by other classes, and we'll indicate this by flagging it MustOverride. In addition, we'll mark the Employee class itself with MustInherit.

Adding a method to the model is similar to adding an attribute:

1. In the class diagram or Model Explorer, right-click the Employee class and choose Add UML > Operation.

2. Enter the name ComputeGrossPay.

Notice that the operation appears under the Employee class in the Model Explorer. Further examination shows that the method should return a money amount (for which we'll use Decimal in Visual Basic .NET) and should take two parameters, PayPeriodStart (a DateTime value) and DaysInPayPeriod (Integer). Adding these three features is simple:

1. In the Model Explorer, right-click the ComputeGrossPay method and choose Add UML > Parameter to add the return parameter.

2. Delete the parameter name, open the Properties window, change the Kind property to return, and change the TypeExpression property to Decimal. This is the return value "parameter." (Note that you can also set the return type on the method itself using the XDE Code Properties window.)

3. To create the next parameter, right-click the ComputeGrossPay method and again choose Add UML > Parameter. Using the XDE Code Properties window, name this parameter PayPeriodStart and change its Type property to DateTime.

4. Repeat step 3 to add the DaysInPayPeriod parameter, making its type Integer.

The Model Explorer should now look something like Figure 12.

Figure 12: Employee Class with ComputeGrossPay and its Parameters

Finally, wrap up as follows:

● To make the ComputeGrossPay method virtual, toggle the MustOverride property from false to true in the XDE Code Properties window.

● Set the class itself to MustInherit by selecting it and setting its MustInherit property to true in the XDE Code Properties window.

● To see the code corresponding to the Employee class, right-click the class and choose Generate Code. XDE generates the method and parameters as shown in Listing 3.

Public MustInherit Class Employee Public FirstName As String Public LastName As String Public EmployeeID As Integer Public Property SSN() As String Get ' #Region "XDEOperation" ' Begin Template Expansion{087407FD-7BD6-45CF-9508-A216B779CECB}

Return msSSN ' #End Region ' XDEOperation End Template Expansion{087407FD-7BD6-45CF-9508-A216B779CECB} End Get Set(ByVal Value As String) ' #Region "XDEOperation" ' Begin Template Expansion{50DC14A8-A1FD-4B88-8E58-F7365456636F} msSSN = Value ' #End Region ' XDEOperation End Template Expansion{50DC14A8-A1FD-4B88-8E58-F7365456636F} End Set End Property Private msSSN As String Public MustOverride Function ComputeGrossPay(ByVal PayPeriodStart As DateTime, ByVal DaysInPayPeriod As Integer) As System.Decimal

End Class

Listing 3: Employee Class with ComputeGrossPay Method

Adding Relationships

Viewing a single class in a diagram is helpful, but the real strength of a class diagram is that it can show the relationship between classes. Let's continue the model by creating an inherited class.

First, remember that how we compute a particular paycheck depends on which kind of employee we're dealing with. For example, as Table 1 shows, for an employee who is an hourly employee, the paycheck is computed by multiplying the hourly rate by the number of hours worked. The phrases "kind of" and "is a" are indicative of a relationship between two things. In this case, an hourly employee "is an" employee, and this relationship is known as a generalization, represented in code through inheritance. XDE allows you to model the generalization relationship and then can generate the corresponding class (complete with inheritance) for you.

To demonstrate this, switch back to the Main diagram and draw another class, naming it HourlyEmployee. To show that an hourly employee is an employee, choose the Generalization tool from the Toolbox (see Figure 13) and drag a connection from the HourlyEmployee class to the Employee class. In the UML, inheritance is shown by means of an arrow, with a hollow arrowhead pointing from the inherited class to the class from which it inherits.

Figure 13: Rational XDE Toolbox with Generalization Tool Highlighted

Your class diagram should now look something like Figure 14.

Figure 14: HourlyEmployee Class Inheriting from Employee Class

When you generate the code for the model, you'll notice that XDE has produced a new class and class file, HourlyEmployee.vb, and that the new class inherits from the Employee class, as shown in Listing 4.

Public Class HourlyEmployee Inherits EmployeeEnd Class

Listing 4: HourlyEmployee class

Continue with the modeling by drawing the classes for the other types of employees listed in Table 1 and the remaining relationships, using the following descriptions as a guide:

An HourlyEmployeeis an Employee. An HourlyEmployeeWithOvertimeis an HourlyEmployee. A SalariedEmployeeis an Employee. A Manageris a SalariedEmployee. A CommissionedEmployeeis a SalariedEmployee.

When you're finished adding your classes and relationships, your class diagram should look similar to Figure 15.

Figure 15: Employee Types with Generalizations

Filling Out the Model

Now that we have a completed inheritance tree, we can go through each of the new classes to flesh them out more fully. Notice that the workflow of the modeling is very flexible. You can start with some details about the class and model all of them at once, or you can stub several classes along with their relationships to one another. You can add as much (or as little) detail to your classes as you like at any time.

In practice, having the relationships modeled helps us to define the classes better. For example, we know that the HourlyEmployee class already has the FirstName, LastName, EmployeeID, and SSN attributes, since they're inherited from the Employee class. Looking a little more closely at Table 1, we can see that we'll need to add HourlyRate and HoursWorked properties to compute the gross pay. Table 3 summarizes the additional attributes needed for each of our classes, along with the corresponding Visual Basic .NET type. Attributes in italic are inherited from a base class.

Class Additional attributes Additional type

HourlyEmployeeHourlyRate

HoursWorked

Decimal

Integer

HourlyEmployeeWithOvertime

HourlyRate

HoursWorked

OvertimeRate

OvertimeHoursWorked

Decimal

Integer

Decimal

Integer

SalariedEmployee YearlySalary Decimal

Manager

YearlySalary

BonusPayDate

AnnualBonus

Decimal

DateTime

Decimal

CommissionedEmployee

YearlySalary

BonusPayDate

AnnualBonus

Decimal

Decimal

Decimal

Table 3: Additional Attributes Needed (italic = inherited)

After these attributes are added to the classes, the class diagram will look something like Figure 16. Generating the code from the model at this point causes XDE to produce all the new classes with the appropriate attributes.

Figure 16: Classes with Added Attributes

With just a few minutes spent on modeling, we already have a meaningful framework representing our system. XDE has automatically generated a good deal of the code we'll need to build the application, and we've got an outstanding visual representation of this system. The best part is that we're almost done; we just need to add a bit of inline code to round out the functionality.

Listings 5 through 9 show the code to implement each of the gross pay computation methods we've discussed. The code here is not of great importance to the model, but it's obviously needed to make the application work. Each of these functions has the same basic structure: prompt the user for the missing information and return the results of the computation. Using the model as a foundation for the classes, we need fewer than 25 lines of inline code to implement the functionality.

Public Overrides Function ComputeGrossPay(ByVal PayPeriodStart As Date, ByVal DaysInPayPeriod As Integer) As Decimal HoursWorked = Convert.ToInt32(InputBox("Enter regular hours worked:")) HourlyRate = Convert.ToDecimal(InputBox("Enter hourly rate:")) ComputeGrossPay = HoursWorked * HourlyRateEnd Function

Listing 5: Compute GrossPay for HourlyEmployee Class

Public Overrides Function ComputeGrossPay(ByVal PayPeriodStart As Date, ByVal DaysInPayPeriod As Integer) As Decimal Dim RegularPay As Decimal RegularPay = MyBase.ComputeGrossPay(PayPeriodStart, DaysInPayPeriod) OvertimeHoursWorked = Convert.ToInt32(InputBox("Enter overtime hours worked:")) OvertimeRate = Convert.ToDecimal(InputBox("Enter overtime hourly rate:")) ComputeGrossPay = RegularPay + (OvertimeHoursWorked * OvertimeRate)End Function

Listing 6: ComputeGrossPay for HourlyEmployeeWithOvertime class

Public Overrides Function ComputeGrossPay(ByVal PayPeriodStart As Date, ByVal DaysInPayPeriod As Integer) As Decimal Const DaysInAYear As Integer = 365 YearlySalary = Convert.ToDecimal(InputBox("Enter Yearly Salary:")) ComputeGrossPay = Convert.ToDecimal(DaysInPayPeriod) / Convert.ToDecimal(DaysInAYear) * YearlySalaryEnd Function

Listing 7: ComputeGrossPay for SalariedEmployee class

Public Overrides Function ComputeGrossPay(ByVal PayPeriodStart As Date, ByVal DaysInPayPeriod As Integer) As Decimal Dim Salary As Decimal = 0

BonusPayDate = Convert.ToDateTime(InputBox("Enter date bonus is payable:")) If ((PayPeriodStart <= BonusPayDate) And (BonusPayDate <=

PayPeriodStart.AddDays(DaysInPayPeriod))) Then AnnualBonus = Convert.ToDecimal(InputBox("Enter Bonus Amount:")) End If Salary = MyBase.ComputeGrossPay(PayPeriodStart, DaysInPayPeriod) ComputeGrossPay = Salary + AnnualBonusEnd Function

Listing 8: ComputeGrossPay for Manager class

Public Overrides Function ComputeGrossPay(ByVal PayPeriodStart As Date, ByVal DaysInPayPeriod As Integer) As Decimal Dim Salary As Decimal = 0 CommissionPercent = Convert.ToDecimal(InputBox("Enter commission rate:")) / 100 Sales = Convert.ToDecimal(InputBox("Enter Commissionable Sales:")) Salary = MyBase.ComputeGrossPay(PayPeriodStart, DaysInPayPeriod) ComputeGrossPay = Salary + (CommissionPercent * Sales)End Function

Listing 9: ComputeGrossPay for CommissionedEmployee class

Test-Driving the Sample Application

The complete sample application uses the various classes to compute the gross pay of an employee. It does so through a simple user interface form, the one we left in the model for reference. The main form (Figure 17) allows the user to enter the first and last name of an employee, the employee's ID and SSN, the start of the pay period, the number of days in the pay period, and the type of the employee. The user can then calculate the gross pay for the employee by clicking the Compute Gross Pay button. It's the responsibility of the individual classes to prompt the user for any additional information required to complete the computations. Once the calculation is complete, the application presents the results in a standard Windows message box.

Figure 17: Gross Pay Computer Form

Just the Beginning

This article has provided a glimpse at modeling with the UML. We've seen the basics of working with Rational XDE and Visual Studio .NET, and we've looked at class diagrams to introduce modeling classes and generalization relationships. Although the diagram we created was simple, it's a good example of how powerful the code-model combination is in Rational XDE. In a matter of a few minutes, we were able to model

the high-level structure of the application and generate the code for the classes needed to implement it. And none of this was difficult or tedious; creating the application from the model was easy, fast, and efficient.

Basic class diagrams and generalization relationships are just the beginning. We could have explored a lot of other relationships; for example, a manager presumably manages employees, so the Manager class should have some kind of direct association to the Employee class. There are relationship types that show when one peer accesses another, when a parent class possesses multiple child classes, and when a whole is made up of various parts, to name a few. Each of these relationships is available in the UML and Rational XDE and is well worth your continued exploration.

References and Other Resources

Books about modeling:

● The Unified Modeling Language User Guide by Grady Booch, James Rumbaugh, and Ivar Jacobson (Addison-Wesley, 1998). This is probably the most comprehensive look at the UML available, drawing heavily from the UML specification itself.

● Real Visual Basic: A Practical Approach to Enterprise Development in the Corporate World by Dan Petit (Addison-Wesley, 1999). While this book was published before both Rational XDE and Visual Studio .NET, it nevertheless contains an introduction to the UML and modeling that remains useful.

Rational Developer Network articles [available at http://www.rational.net; requires registration]:

● "Introducing the Rational XDE Professional v2002 Release 2 --.NET Edition Kit" by Rational Software

● "Getting Started with Rational XDE Professional: A Guide for Visual Studio .NET Developers" by JJ Kuslich

● "Modeling Software with Rational XDE and Visual C#" ("Part 1: An Introduction to Class Diagrams" and "Part 2: Beyond Simple Class Diagrams") by Dan Petit

Acknowledgments

Many thanks to Robert A. Maksimchuk and Powell F. Quiring for their review of this article.

For more information on the products or services discussed in this article, please click here and follow the instructions provided. Thank you!

Copyright Rational Software 2002 | Privacy/Legal Information

Design for Testability, Agile Testing, and Testing Processes: An Interview with Testing Expert Bret Pettichord

by Sam Guckenheimer

Senior Director of Technology for Automated TestRational Software

Bret Pettichord is an independent consultant in software testing and test automation as well as a co-author, with Cem Kaner and James Bach, of Lessons Learned in Software Testing. For the past year, he has championed principles of Agile Testing with Brian Marick. His software testing philosophy is context-driven, focusing on good relations with developers and agile methods that get results with a minimum of documentation. I recently asked Bret to share with us his insights about Design for Testability, Agile Testing, and Testing Processes.

Sam Guckenheimer: You just returned from the Pacific Northwest Software Quality Conference (PNSQC), where you gave a talk on your "Design for Testability" paper. What do you see as the main idea behind that concept?

Bret Pettichord: As you know, I've been talking about design for testability for a while, and I finally decided to write down my thoughts in that paper, which started as a catalogue of different things people have done in order to make testability work. I was motivated by the big disconnect I've often found between testers and developers on this issue. Although I've usually been able to bridge the gap in my consulting work and as an employee with different companies, I wasn't really sure I could train other people in how to do that.

I realized that developers and testers had different perspectives. The testers were saying, "I want testability in the code," and the developers

Copyright Rational Software 2002 http://www.therationaledge.com/content/nov_02/f_pettichordInterview_sg.jsp

were saying, "Well, that's too hard." I think the developers didn't realize they could meet the testers' requirements easily, and the testers often didn't recognize that some of the simpler things the developers could do would be sufficient. So there was a feeling on both sides that more movement was needed than was really necessary. What I did was scour the literature, look back on my own experience and that of others, and put together a long list, case by case, of what people had done to make products more testable, what had worked for various teams. I found that holding concrete discussions between testing and development teams was the best way to help them come together. The testers said, "This isn't exactly the information we need," and the developers said, "Well, we can add some more information to the logs then." So then the testers started describing the specific features they really needed instead of making nebulous requests like, "You have to make this product testable."

SG: What's your favorite example?

BP: I was working with the testing team for an embedded system with communications technology, and we were trying to figure out how to test to make sure that all the stuff would communicate. What we needed, essentially, was to simulate a request coming from one part of the system after being triggered from another part of the system. I suggested that we talk to the developers, but the test team didn't want to. So I said, "Okay, I'll go talk to them." The half dozen people on the testing team all followed me to the lead developer's cube, and I told her, "This is what we'd like to do." And she replied, "Oh, you know, we were going to do something like that, and we've done 90 percent of the work already. So we'll just finish up that work and put it in." This was a classic case; the testers were so fearful that their request would be considered difficult, but with the right kind of communication the developers said, "This isn't so hard."

SG: What's behind the test team's reluctance to ask for something that is often really easy to do?

BP: A lot of people don't have enough experience to know that it's easy to do. I also think that, frankly, testers have a bad reputation working with development teams. A lot of testing teams believe it's their job to scold development rather than support them, and the developers often expect it. So there is this kind of built-in animosity that gets in the way.

A lot of times you have testers who aren't technical enough to actually describe what they want and to be able to review design documents. I think these capabilities are critical for testers. At least some testers need to understand the system design and architecture so they can talk meaningfully with the developers about the testability hooks in the system and where they can access them.

Here's another thing that gets in the way of a lot of testers: They feel like they've been put in a position to judge the software, and therefore they have to seem authoritative, which gets in the way of collaborating with developers on things like testability. They can't come in and say, "Well, we'd like something like this, but we're not exactly sure. What are your thoughts?" That just doesn't reinforce that presumed air of authority.

You get this a lot with people who wear the "quality assurance" label. They feel like the final inspectors, the ones who judge whether the software is good or bad, and the more seriously they take that mission, the more it hurts their ability to be helpful to the team.

SG: You just presented your paper at the conference. How did people take it? What kind of reaction did you get?

BP: I'm happy that it received a lot of interest. The best reaction I got was from someone I talked to afterward; he started brainstorming with a co-worker about adding testability into their product before the talk was even over. And that's what I was hoping to do, to provide a catalyst to make these kinds of things happen.

SG: Let's drill into the content a little bit. In the paper and in the book you co-wrote with Cem Kaner and James Bach, Lessons Learned in Software Testing, you talk about design for testability as a matter of visibility and control. What do you mean by those things?

BP: I think there are two difficult things about software. One is that software is practically invisible. When it operates, we see very little sign of what is actually happening, how it got there, what went on. In classic black box testing, all we see are the inputs and the outputs, and from that data we have to somehow derive correctness. Essentially, testability isn't compatible with a black-box way of thinking. It asks, how do we get into the system and see what's happening inside? And, given the nature of software, the only way that you can see the inside is by having some kind of facility that lets you do that.

The second part is control. With the standard inputs you have to the system, it's difficult to exercise all the different code portions, especially if you are looking at things like exception paths and opportunities for test automation. Testers need different ways to operate the system, to be able to send it inputs and put it into different states to test how it handles all of the software's possible states.

SG: Does that apply to GUI testing, or is it better applied at the API level?

BP: Several years ago, I found that in order to make GUI test automation work, you need some testability in the GUI layer itself. And as I developed techniques for GUI testing, I began to realize that if we're going to modify the system to improve testability, it might be more efficacious to do that at some level other than the GUI. So the question has become, when do we modify the GUI to make it more testable? When do we find other ways to test the product besides using the GUI?

I think that one of the biggest problems with test automation is that people automate through GUI interfaces, which are fundamentally unstable. They have a design flexibility that is somewhat necessary to the success of the software. So you have this classic maintenance problem of how to update the test and how to keep things going. I think the right solution is to do more API-based testing with system interfaces at an API level that allows you to get into the core product. This has to happen before we're really going to make big progress on the test automation

front.

SG: Do you find that most testers you speak with understand the value of API over GUI testing?

BP: It varies quite a bit. A large section of the testing community is focused on the GUI testing approach. Many people have invested a lot in learning the tools and techniques for making that work, so they're reluctant to adopt a totally different view. In other cases, especially if the testers have tried API testing, they see the advantages.

SG: Last month we talked to Brian Marick about test-first design. He remarked that if you practice test-first design, then the need to design for testability is obvious, and there's no contention -- it just happens. Do you agree with that? Do you see test-first design as necessary for achieving design-for-testability?

BP: I don't think it's absolutely necessary, although I do agree with Brian that it helps a lot when you have people doing test-first design. Many development organizations tell me that because they're using test-first design, they often design products differently. They divide up the functionality in different ways to make each piece more similar and more testable in isolation. So I think that it does a lot to help testability on the small scale.

But Brian and I have different perspectives from the standpoint of scale. Brian looks at testing from the developer's perspective, which considers smaller scale testing. I work a lot more with systems and larger scale testing problems, so I think it's important to consider not only design for testability, but also an architecture for testability. So my questions are: How do we conduct end-to-end testing on the system? What kind of testability hooks do we have in place, and what are we missing?

Of course, we have less experience doing test-first development from a system perspective, so whatever we say about that is going to be a little bit more speculative.

SG: You described how the concept of testability can open that up for better coverage of error paths and so forth. Have you tracked this with code coverage as well?

BP: I don't focus a lot on measuring the code coverage. Most of the teams I work with really aren't at a point where they can appreciate these distinctions, because they are just trying to get the basic things tested, get their routines automated. But yes, there are times when error handling is not just a unit level issue. Certain types of errors are really systems errors, and they are often handled in a complicated way between different components. For instance, consider how a system handles running out of system memory. If you actually try testing these things, and you find your exception handlers themselves start allocating memory, then you can't test because you're out of memory. So you can run into pretty serious problems. In these cases, you could test the individual components, and they would look as if they're okay -- until you realized

that your assumptions don't quite hold when you chain all the components together.

SG: I'm interested in the key role you played at another conference, ChiliPLoP 2001, which was held last February in Arizona, where you were one of the organizers of the workshop on patterns for GUI test automation. Can you fill us in on what happened there?

BP: I had been thinking about patterns as ways of describing solutions or common techniques, and I had put together a set of patterns for test automation. At the conference, Brian Marick, Bob Hamner, Nancy Landau, and I spent a couple of days going over some of the notes I'd been making. Brian's perspective was grounded in the work of Richard Gabriel, who views patterns as more than simply a grab bag of solutions but rather as a set of interlocking solutions with a common set of values. Looking at my work, Brian suggested that we explore the underlying values and principles at stake in the patterns I had defined. We basically were able to divide them into two categories. Some were based on what I call the "silo principle" -- testing works in a separate space from development, and there are a number of solutions for making test automation work. Other patterns were derived from a collaborative relationship where there is no silo, where you have a lot of crossing over between development and testing. Basically, we agreed that the silo patterns revealed limitations, whereas the collaborative patterns were where we wanted to focus. We needed to pay less attention to automating the software as it's given to us, and instead to take advantage of whatever interfaces we have and build up whatever apparatus is necessary to make that kind of testing effective.

In the traditional silo approach to GUI test automation, you try to figure out how to test through the GUI. Typically, you build up several abstraction layers to insulate your tests from expected changes in the user interface. But that takes extra engineering time, and as the software changes, you have to maintain your separate automation system in parallel with the software test. So we pushed our discussion in this other, collaborative direction -- not only collaborating with the developers, but also more specifically working with the Agile development community on ways to adapt testing. Essentially, our Agile testing project got started at that workshop.

SG: Now you've worked with Brian to articulate principles for Agile testing.

BP: Right. For a while the two of us were working with a few people, trying to define an intersection between our school of software testing and the Agile development community. It was largely speculative, and it's an ongoing project. Right now, we've boiled the principles down to four key ideas. One is conversational test creation, which I think is a powerful idea, because defining the test includes lots of people. I've done test-first stuff where the testers went off by themselves in a separate environment and defined tons of tests. They waited for the software to come through the gate and then start executing the tests. What was missing was conversation -- sharing tests with other people and discussing tests early in the project. Conversational test creation gives the test visibility, and there are some interesting implications. For instance, it means you can't

have all of your tests coded up in a scripted fashion, because you want them to be written in a form that lots of people can examine and use as a basis for conversation.

Another idea is what I call coaching tests, and what Brian calls rapid feedback guidance tests. These tests can direct the project and set goals. This is a form of test-first development, but it also illustrates that tests can be a form of requirements instead of a form of finding mistakes. That is a big shift in thinking: How do we encapsulate requirements within tests, instead of looking at testing as a bug finding activity?

SG: One of the phrases starting to appear more frequently -- I think Martin Fowler coined it, and Brian used it in last month's Edge interview -- is specification-by-example.

BP: Yes, that's a great term. It means doing requirements by example on the system level. For many, many years, we've had difficulty doing good requirements analysis and finding a way of specifying requirements clearly. I think it's actually harder to specify requirements than it is to design a system. The problem is, we're actually working at a higher level of generality -- the design we use is just one possible solution that meets the problems essentially defined by the requirement space. So doing requirements well requires this very complicated definition that could have multiple implementations and multiple solutions.

We're asking, what are the things that the system has to do? There has been a lot of talk about requirements having to be testable. We're trying to go one step further by saying that requirements have to be the tests. I think this is really a powerful notion, because requirements had been the hardest part of the Agile testing agenda for me to embrace, and I now think it's one of the strongest parts.

Here's what we're saying: Let's just use an example of something the system has to do. Let's not focus on defining the whole space, but rather on points in that requirements space. And that's what these coaching tests are -- they focus on one activity the test has to support.

SG: RUP expresses basically the same idea with the term use-case realization. It doesn't quite have the same ring as specification by example.

BP: Yes. I think "coaching tests" is more mnemonic, but it's the same idea. Whatever process you use to get there, you need to make sure you get specific. As I mentioned before, testers and developers have difficulty communicating. And it's worse trying to communicate at an abstract level, since different groups have different definitions for abstract terms. When we get specific -- for example, so and so must buy this product for this much money and it's going to be debited to their credit card -- then we know how the system is going to support that activity, what the results are supposed to be, and how the whole thing is going to come together.

SG: So that describes conversational test creation and coaching tests. What are the other ideas?

BP: Providing test interfaces and exploratory learning. Coaching tests are written first, as commands in a scripting language or data in a spreadsheet. They need to be executed, so some facility for executing has to be provided. Typically this is done with test interfaces and fixtures. It's a consequence of making testability a requirement.

Reading the XP literature made us think that there was something missing, that unit testing and acceptance testing wasn't enough. So we defined the idea of exploratory learning. This is basically exploratory testing, but the focus is as much on finding out new ideas for how you want to evolve the system as it is on uncovering hidden defects. And you can't really automate it. At XP Universe, we learned that most XP groups were actually doing this, but they called it "playing around." It was something that usually happened at the end of an iteration, when the developers naturally wanted to show off their baby, and people from outside the development team would play with the software and see what it could do. All we are doing is giving this activity a little more focus. We think there are ways to structure this activity to ensure that you get the most from it.

SG: How do you find the reception to these ideas among testers and developers? Or requirements analysts for that matter?

BP: It depends on what communities you're talking to. I recently gave a talk based on these ideas at the SoftPro bookstore near Boston, which is run by an old colleague of mine. At the end of my talk, he shook his head and said to his brother, "We've been doing this stuff for twenty years." So, to a certain degree, none of this is new. What is groundbreaking, though, is that people are talking about it and writing about it and treating it as good methodology. Before, although people were doing the same things, they were so busy creating products that they weren't writing or talking publicly about them.

I have been quite surprised at the welcome reception we've had from developers regarding many of these ideas, especially those in the Agile and Extreme Programming communities. We've been coming in not only with these ideas, but also with some sharp criticisms of what XP theory misses regarding testing. We expected resistance, but instead, this community has embraced what we're saying and encouraged us to talk more about these things.

SG: Why did you expect resistance on these points from XP developers?

BP: Some of the elements of XP methodology contradict our views, and we had met people who regarded most aspects of XP as dogma --for example, the principle that you have to have 100 percent test automation. Martin Fowler had said that the use of manual testing on a team indicated a problem. But we've found great value in manual testing and exploratory testing; you just need to understand how to use it and when to use it effectively. And after we talked to Martin about how manual testing fits into the whole project, he completely rethought that position.

SG: I recall a workshop at the Software Test Automation Conference in

which some people with testing backgrounds seemed quite threatened by the idea of Agile Testing. I'm wondering whether that has to do with differences among industries, whether they were used to a highly regulated environment, or whether that comes from an innate resistance to change.

BP: Well, regarding agility, some testers look at what's going on and say, this is cowboy programming; we've seen this all before. It's just going to get us into trouble, and there is no reason we should be corroborating it. In fact, because of these objections, I've recently put together a list of four schools of software testing.

First school is the "comprehensive" school, which promotes a set of techniques for thoroughly testing software. I think most techniques for coverage measurement have come from this school, and I think of Boris Beizer as one of the leaders. Academia embraces this school, because mathematical techniques can be employed in comprehensive testing. And the telecommunications industry often needs it because they have some of the highest software reliability requirements.

People in this community look at Agile Development and test-first development and say, "You call that testing? That's not testing." It doesn't match their quantification requirements, and it doesn't use any of the techniques developed in schools for comprehensive testing coverage.

The second school I call the "factory" school. These are the people who believe testing is an item on a checklist that needs to get done. They view their teams as groups with limited skill and ability, working hard to check off all the tasks on the list. The factory school is very management focused and centered on logistics: "Have we checked off every requirement? Have we done the minimum necessary in order to say that we've performed a complete testing job?"

The ways in which we encourage collaboration, and the extent to which the boundaries of trust between testers and developers are open to negotiation is very worrisome to people of this community, because they want, more than anything else, to have a manageable activity.

SG: Would you say the BCS (British Computing Society) material is an example of that?

BP: Yes. I think that the BCS or the ISEB (Information Systems Examinations Board) curriculum fits into that type of approach. It is focused on contract software development and IT software development, and it's often appropriate for certain types of developers who simply don't want to re-think the testing agenda.

So the third school I call the "QA police." These are the process-focused people, who look at testing as a cudgel to beat developers into following some proper process.

When I put together my ideas on the four schools of software testing, I tried to find a way to give each of them their share of credit, but I had a hard time finding much credit to give this school of thinking. The QA police

work in organizations that believe it's important for testers and QA people to scold the programmers for not having done things right. For them, agile development is just making it up as you go along -- a form of general madness -- and they have no tolerance whatsoever for the ideas we've been discussing.

The last school of software testing is the "context-driven" school of testing, which, as you know, I belong to, along with Brian Marick, Cem Kaner, James Bach, and many others. We're the people trying to figure out how to pull this all together and how we can get testers to work effectively with Agile Development.1

SG: Several times during this interview you've referred to a distrust or other forms of boundaries between testers and developers. What is your view of the project manager's role in assessing and understanding the place of testing, and in bridging some of those cultural gaps, especially from the context-driven point of view?

BP: I think testing brings essential information to the project manager. If he or she is not getting useful information from the testing team about the project -- how things are progressing, what's working and what's not -- then the testing team is failing. The other schools of testing focus on the testing group's quality assurance role, but this concern really properly belong to the project manager. That's the person who has to make trade-offs between various activities and considerations for the project: Do you want to spend more time fixing bugs or more time doing design? Where do you put project resources in order to get a successful result? The testing team should play a central role in helping the project manager make those calls.

Now, if testing team members refuse to cooperate with developers, or say, "We won't do any testing until we get a complete specification," they simply should be fired. That's an unacceptable attitude for a tester. One reason we wrote Lessons Learned in Software Testing was to get that message to project managers -- to let them know that there were some reasonable expectations they could have of testing teams -- expectations that, unfortunately, a lot of testing teams hadn't been meeting.

Although the book presents itself as a work for software testers and tells the reader how to do a better job of software testing, we did specifically intend that it be used by project managers as well. There are a lot of lessons there that we want project managers to overhear us telling the tester, so if the tester doesn't get the message, then the project manager will.

SG: If you roll the calendar forward ten years, what will be different about software testing practice?

BP: I think a large part of the community will not have changed at all; I expect to see a lot of inertia. But I do think the trend toward outsourcing is going to affect the way testing is conducted. A lot of development projects are being moved overseas, and companies are having trouble outsourcing the testing. I was just talking to someone recently about a

project that sent the development work to India; when the issue of testing arose, there was uncertainty about what needed to be done and how to get it done. It's hard to talk realistically about improving collaboration between testers and developers if the developers are half a world away and the testers are still here.

So much of the communication required isn't simply between people who call themselves developers and people who call themselves testers; we need communication between people who are in a position to understand the customer's perspective and the people who are building the system. If the systems are going to be used here but are being built in other areas of the world -- whether that's Russia, China, or India -- I think we're going to have a bigger gap in customer understanding.

SG: Do you see that context-driven testing will still be as controversial, or do you think acceptance for it will grow as time goes on?

BP: As acceptance grows for the principles of test-first design, I think really good developers will be thinking more about testing ten years from now than they are right now. They're going to be building testability into the product; they're going to be thinking about how to automate tests; they're going to understand that key testing problems are in fact key design problems, and that there's not a clear barrier between the two things.

One of the reasons developers are getting more interested in testing is that they can no longer pretend to understand how an entire system works, and they can't model the whole thing in their own heads. As they use more and more third-party components, as they use more tools to build the components that they're creating themselves, they need to understand the software that they're using -- and that means testing it.

Sometimes when I talk to testers, I mention that we do not need to know the correct result before we run a test. And yet, I've found that testers can be very interested in test results. Developers, too, are often very curious to know the actual performance characteristics and what limits there are. When this information is presented factually and not under the guise of blame, developers have a lot of interest in it. And that is really what software testing is: a process of experimenting with software and finding out what it does. I think that it is going to become more and more interesting to developers; as systems get larger and more complex, they need ways to figure out what is it they're actually dealing with.

Notes

1 For more on context-driven testing, see the interview with Cem Kaner in the July issue of The Rational Edge.

For more information on the products or services discussed in this article, please click here and follow the instructions provided. Thank you!

Copyright Rational Software 2002 | Privacy/Legal Information

Requirements Archaeology

by Benjamin A. Lieberman, Ph.D.

Senior Software ArchitectTrip Network, Inc.

"You call this Archaeology?"

- Dr. Henry Jones, Sr.from Indiana Jones and the Last Crusade,

Lucas Films, Ltd. (1989)

System requirements are at the heart of every meaningful software system. They not only explain the behavior of the system, but also provide context into the minds of the software users who will ultimately benefit. Often times, however, these requirements are either a) partially captured in an informal or locally developed mechanism, or b) captured in the heads of the developers and the mystery that is code. Unfortunately, for most software development organizations, both approaches lead to mistakes and added costs.

Costly Legacies

Many, if not most, companies have a significant investment in one or more legacy software systems that were developed over a number of years and are critical to the continued survival of the company. However, as most of these systems have missing, incomplete, or inaccurate requirement sets, there is a very high likelihood that they are fragile and expensive to maintain. Moreover, because the behavior of the software is not well defined, it is almost impossible to replace the system with a modern equivalent. This leads to systems that are "dated" and too inflexible to meet modern business demands.

Adding new functionality or behavior to the existing system typically complicates the issue further, as the effect on the existing system's stability is unpredictable. This is very much like adding a second story to a house with an unknown foundation: There is no documentation about how the system was built, and therefore no way to know if the structure will hold until it is too late to do anything about it. If you want to replace, re-

Copyright Rational Software 2002 http://www.therationaledge.com/content/nov_02/m_reqArchaeology_bl.jsp

develop or continue to maintain a legacy system, you need a more complete understanding of the original driving forces of the system: the behavior, states, data elements, and business rules. That requires discovery of the system's business requirements.

The more obvious sources for this information -- those who developed the system -- probably have left the company by now. But the information also lies buried within the single reliable artifact remaining to the investigator: The Code. In other words, there is a way to rediscover "lost" requirement "artifacts." The discovery process is akin to an archaeological expedition: You must determine areas of investigation, interview and study information sources, carefully catalog the available artifacts, interpret cryptic comments, and, finally, present the software's "story" to system stakeholders.

All of this, of course, comes at a cost. Any "expedition" incurs significant risk and expense. Depending on the size of the system to be captured and the current state of the requirements base, this effort may require as many as three to four people working full time for several months. The expense might seem justifiable only when you consider the cost of not having a stable and complete requirements base. Without well-understood requirements, businesses can lose opportunities and experience increases in maintenance expenses, difficulties in integrating systems to realize economies of scale, and decreased employee job satisfaction (an expert who understands part of the system is unlikely to be allowed to work on anything else), and significant decreases in their strategic planning capability. Only by reestablishing a solid understanding of "what is" can an organization prepare to realize "what can be." In other words, although a company can survive without a solid requirements base, it will have a very limited ability to grow and thrive.

In this article I will discuss the process by which a legacy system's requirements can be captured and used to rebuild a complete requirement base. I will present some techniques for "excavating" requirements from existing artifacts and other information sources. Finally, I will discuss how to present the newly discovered artifacts so as to improve the probability of long-term maintenance.

If you have a stout heart and keen mind, read on. For mystery and adventure await the intrepid requirements explorer.

Preparation

The prudent Requirements Archaeologist recognizes the need to acquire a few skills and supplies before embarking on an expedition into the Software Wilderness, including:

1. A firm grounding in the theory and practice of both Structured Requirements1 and use-case-based requirements analysis.

2. Experience with researching and cataloging information.

3. Experience leading small teams of engineer-investigators.

4. Practice with presenting to, and facilitating for, small groups of business subject matter experts.

5. Strong familiarity with UML modeling (at a minimum, use-case and activity diagrams).

6. Experience with the system programming language (optional, but it's always useful to speak the language of the "locals").

It is also very helpful to have the right equipment at your disposal when facing the unknown. So it is a good idea to acquire the following tools before setting out:

1. A requirements management tool (e.g., Rational®RequisitePro®2), to hold and organize your findings.

2. A Unified Modeling Language (UML) diagramming tool (e.g., Rational Rose®3) for use cases, activity diagrams, and state charts to express the system information graphically.

3. A good code editor/profiler for the particular system language (e.g., TextPad4) to review the code artifacts.

Once you have collected your equipment and honed your skills, you will be ready to head out on your adventure.

Site Investigation

Surprisingly enough, requirements that require discovery are seldom left just lying about waiting to be picked up and used. Typically, they are deeply buried in guarded legacy systems, mysterious legacy documentation, and even "legacy personnel." I have found that there are four primary sources of information about an existing software system:

● People

● Documentation

● Software Code

● Software Issue Tracking Reports

Each of these sources requires different techniques to sift through and recover meaningful descriptions of the software system. If a company has a defined requirements management team, then this is the best place to start investigations. Typically, these people will be referred to as "Business Analysts" or "Requirements Engineers," but they may also be members of product or project management, marketing, or even sales. In fact, anyone in the organization who has a hand in determining the functionality and performance of the system will serve as a good source of information to discover and document the driving forces that created the original need for the software system. (Within the Rational Unified Process®(RUP®), the needs of a well-architected system are first identified in "Stakeholder Requests"5.)

Written documentation is a useful, but often misleading, source of information. This is because most documentation is not maintained and so tends to become obsolete rather quickly. In addition, this resource is typically the most difficult to locate, because a company that doesn't organize its requirements is unlikely to organize its documentation; usually, critical system documents exist only on local hard drives or difficult-to-access shared drives. Once collected, however, these historical records can provide a good starting point for discussions and further investigation.

The most accurate source of information on the system's behavior is, of course, the software code itself. But it takes special skills to make use of this resource. In particular, as I mentioned earlier, the investigator should be familiar with the specific programming language(s) used by the development team. This can range from assembly language used for mainframes, to C++, Java, and VisualBasic™ used for PC applications, to more specialized languages like Perl and Fortran. Although proficiency in the specific programming language is very helpful for discovering embedded requirements6, running the application and observing its behavior will provide nearly as much information about the system's functional characteristics.

Another excellent resource is the company's issue tracking system (automated or not), which often becomes the de facto repository of system requirements as enhancements are logged as system "fixes." If the investigative team is fortunate, they can run reports on issues logged as ENH or Enhance or some other identifier that indicates the "fix" was actually a new piece of functionality. If they are unlucky, then an extended excavation may be in order (see tips on excavating legacy documentation below).

In addition to identifying sources of information, you should also consider the conditions of the "dig-site" for your system requirements investigation. Based on what you know about the organization's culture, pressures, needs, and so forth, is the company environment favorable or neutral? The environment is favorable if the organization recognizes the need to reform the requirements capture process and welcomes the investigator and his/her team. A neutral environment is one in which the local requirements team is "too busy" to be bothered with what the investigator is doing, but offers to help "when they get the time." A neutral environment will require a heavy reliance on independent study, as defined below in the section on Excavation and Cataloging.

The Curse

What good archaeology story would be complete without a curse? Here, the curse is the likelihood that existing requirement artifacts will be misleading or false; people with the knowledge will have left the company; the code is obscure and filled with dead-ends and traps for the unwary. Woe to those who would seek to disturb the resting-place of this most sacred software design!

Needless to say, caution must be exercised when unearthing system

requirements. It is best to validate the discovered functionality with the requirement stakeholders, system users, and other knowledgeable individuals. In particular, the successful requirements Archaeologist will befriend the testing team; they can be the best allies of those seeking to discover the "true" system function.

Sometimes the gaps in a requirements base are more telling then the requirements themselves. For example, if a piece of functionality was "rushed" into production, often there are few or no supporting requirements. Moreover, if something was important enough to the business to be rushed into production, then it is likely a critical part of the software functionality.7 In this case the investigator should look to the software issue management system and personal interviews for clues as to what's missing.

It's also important to be careful with sections of the code that are not executed, otherwise known as "dead code." As it is very difficult to determine which code blocks are "live" and which are "dead," a good debugging or profiling tool will be useful in determining areas of code that are no longer functional.

Excavating and Cataloging

What about the actual mechanics of retrieving and organizing the requirement "artifacts"? Let's consider the techniques of interviewing, diagramming, investigating, and capturing requirements from existing sources.

Often times the principal investigator will work alone, sifting through the available materials to locate information of interest. Although this style of investigation may be the only one available in neutral or hostile site environments, it carries a high probability of making an incorrect hypothesis -- that is, you might easily capture a requirement that was never actually implemented or was later modified. It is therefore best that the investigation team work as collaboratively as possible with the "natives." Most of the activities detailed in Table 1 assume system experts are available, but a great deal of groundbreaking work can be performed prior to meeting with system stakeholders and experts. The resourceful investigator can gain a good understanding of the existing system through all of these activities. Even a poorly documented legacy system will begin to divulge its secrets when you use systematic investigative techniques. Although you might not need to undertake these activities in a particular order, the order presented is the one I've found most effective.

Table 1: Techniques for Investigating Requirements

Method Activity Description

Independent Study

Documentation Review

Most organizations will have some documentation, even if it is not very accurate or complete. Read and review as much of this information as possible, identifying "candidate" requirements and recording them in a requirements management tool. Make particular note of exception handling (i.e., errors). Developers usually start with the desired functionality first and worry about error conditions later, if at all. Consequently, system exceptional conditions and handling is usually the last area for development and often the most poorly documented.

Independent Study

System Functional Modeling

Next, excavate the application itself. Use activity diagrams8 ("flow charts on steroids") to quickly capture most of the existing system functionality. Create them by using the application as if you were an end user (e.g., entering data via the user interface, creating accounts with a command line, performing searches, etc.). Do this alone or in conjunction with a system expert (e.g., a member of the testing team). The expert can use the application while you record and/or diagram the user activity steps using a separate laptop computer. It is likely that much of the functionality will not have a corresponding requirement in the available documentation.

Independent Study

Defect Tracking Review

Review issue tracking reports, which might be organized by functional area via a tracking tool such as Rational ClearQuest.9 Run a report on bugs matching a particular functional area. System enhancements often masquerade as "fixes" and are therefore not captured within the legacy requirement documentation. Correct identification of these requirements requires cross-referencing against documented feature requirements, so review documents first. If the development staff uses a "trial-and-error" approach, there will likely be a chain of issue reports that chronicle changes to a piece of functionality.

Independent Study

Code Tracing Even if you are not familiar with the coding language, often programmer comments will be embedded in the code base with references to issues (e.g., "Fixed BUG1403 - 01/03/2001"). Asking a programmer to review that section of code and report on the expected behavior may be the only way to find exceptional conditions that are difficult to simulate and reproduce during the functional activity-modeling task described above.

Interviewing Individual Interviews

Conduct interviews one-on-one, reviewing system documentation beforehand to provide a familiar starting point for system experts to begin discussions.

● Ask subject matter experts (SMEs) to validate the documentation and

facilitate closure of gaps or update incorrect information. Use activity diagrams created for system functional flows, which highlight areas of the system that are not well defined -- particularly exception handling aspects of the system.

● Alternatively, ask SMEs to walk through the application and comment on how and when each section of the system was established. Multiple interviews with SMEs are usually required to cover a reasonably complex software system.10

Interviewing Group Sessions An extension of the individual interviews, these are best used to review updated documentation and findings. Investigators present their work and facilitate constructive review of the information, perhaps using a projector attached to a laptop computer to display and capture comments in the documentation. Save this approach until a sizeable portion of the system requirements have been rediscovered and documented.

Multi-Day Workshops (Facilitated Re-Discovery)

Small Group Sessions

Rediscovery workshops serve a dual purpose:

● To capture and document requirements into use cases directly from people closest to the system behavior.

● To begin teaching the team a good technique for capture, presentation, and maintenance of system requirements as a set of well-formed use cases and supplemental specifications.

Deciphering and Translating

After the capture of requirements come the tasks of deciphering and translating. Many requirements are captured using some form of functional decomposition technique. Although this common technique is useful for breaking a problem domain into manageable sections, it is often misused to indicate implementation details, and is very difficult to interpret because the standalone statements don't form a cohesive "story" about the system functionality. Even more common is capturing requirements as highly abstract business statements (e.g., "the system shall be intuitive and user-friendly"). As a result, a common viewpoint must be found that can be used to translate these into a more understandable "story-telling" format (e.g., use cases). Needless to say, performing this task will require diligent attention to detail and some form of Rosetta Stone (such as a business vision document) that will provide guidance in piecing together the elements of system history.

Capturing Functional Requirements. Functional requirements represent the bulk of requirements for a user-intensive system. When translating these requirements, it is usually advisable to take a top-down approach. As the traditional structured decomposition approach is still very popular, I will use this form in the example (see Appendix for a complete translation example, from structured declarations to use-case flows and supplemental specifications). When translating structured declarative statements, look for phrases such as "the system shall present" or "the system shall display" to indicate requirements for user interaction. When a requirement begins with "The system shall perform," this is a good indication that the requirement is for a system-processing step. Any requirements that contain restrictions, such as "the system must respond within 60 seconds," are good candidates for supplemental specifications. A

decomposition, by its very nature, is hierarchical, so this structure can be used to indicate an initial separation of functionality. For example, if a requirement hierarchy is called "Stock Purchase and Reconciliation," this may represent a set of use cases around "Purchase Stock" and "Reconcile Accounts." Thus, you can rapidly construct an initial use case survey from a primary grouping of similar functionality, or from the structure of the statement hierarchy itself. This will provide a framework for tracing statements into functional flows.

Detailing Data Descriptions. Data descriptions are often scattered about the documentation and code, and may contain more implementation detail than is appropriate for a requirement statement. This typically happens when data dictionaries created from database tables are placed in requirements documentation. The details of primary/foreign key implementation and data types do not belong in a requirement description. Instead, requirements should describe the relationships between data elements and the restrictions on values that these elements can contain. For example, taking a section on user activity audit trails from the Appendix use case:

Audit TrailDate of ChangeChange Event (Refund, Pre-Paid Minutes, Customer Data, Payment)Original InformationAltered InformationUser Identifier (Lastname + Firstname + UserID)Supervisor Approval Indicator (Yes/No)

This approach describes the data elements at a level of abstraction that is more readily apparent to business subject matter experts. They can see data relationships without being confused by implementation details that are better suited to a design document.

Deciphering Business Rules. System business rules relate to usability, reliability, performance, and scalability (URPS). These types of requirements are typically scattered throughout the documentation and should be re-organized into a set of nonfunctional requirements, including:

● Data Validation Rules

● Processing and Performance Restrictions

● Exception Handling

● External Systems Interfaces

● Security

The most logical place for these requirements is in system supplemental specifications. These can be either directly associated with a particular use case, or created as global requirements for the full system.

Public Display

Once the original requirements base has been discovered and recreated, you need some method for the preservation and presentation of that knowledge. The role of the software archaeologist doesn't stop once a system has been unearthed; it is also his or her responsibility to teach the teams involved how to care for the system artifacts. To be of continued value, requirements must be accurate, current, and presentable.

A requirements base is best maintained with the use of a suitable organizational tool, and there are a number of excellent candidates, some relatively inexpensive. At a minimum, the tool should have the ability to record requested features, requirements (including use-case scenarios), and supplementary documentation (e.g., a glossary11). There are a number of good papers and books on the topic of requirements management.12. All of the discovered and created artifacts, including use-case models, activity diagrams, and data dictionary information, should be controlled and maintained through such a documentation management system.

To ensure the continued maintenance of the requirement artifacts, you should establish a process of continuous training and development for the requirements management team. This could include attending industry conferences, bringing in consultants/trainers to instruct new and existing personnel, and rewarding employees who seek out additional training and experience. As of this writing, there are no universally accepted certifications for requirement engineers, but many in the industry are attempting to build a body of knowledge that can be used for this purpose.13

One of the greatest dangers for the requirements archaeologist is the possibility of backsliding into the same problems that necessitated the reconstruction effort in the first place. Things to watch out for include inappropriate schedule pressures, changeovers from experienced to inexperienced personnel, funding cuts, rapid expansion of the business (and consequently the software functionality), and a drop in visibility (e.g., "Hey it's working; let's forget about it!"). Constant vigilance is the price you must pay to prevent these pitfalls from destroying all of your hard-won work.

The End?

I consider the process for capturing requirements no different from the process for maintaining software code: Periodic refactoring and reorganization are required for a healthy system, and system requirements must be continuously revisited and revised to ensure that they meet the real needs of customers and end users. The requirements base represents a key company asset, one that is often overlooked. Another way to put it is: Requirements are money. There is a direct relationship between correct system requirements and final acceptance of the software product, which usually means payment. The relationships are rather straightforward:

Correct Requirements -> Correct System Correct System -> Customer Acceptance

Customer Acceptance -> Money

Unfortunately, if you're working with a legacy system that's new to your team, most likely you will have to re-capture the system's business requirements before you can move forward with a system upgrade or integration. Although it's entertaining to think of system requirements rediscovery as a form of archaeology, the sad truth is that we must do this only because companies so often fail to understand the simple relationships described above. Although the rediscovery process is difficult and sometimes expensive, however, it always pays off in the end. Once a team understands the system's driving forces - its behavior, states, data elements, and business rules - they will understand how to make the system more successful as well as how to leverage it in more challenging and difficult projects.

References

Alistair Cockburn, "Goals and Use Cases." Journal of Object-Oriented Design. September 1997, pp. 35-40.

E.F.J. Ecklund, L.M.L. Delcambre, and M.J. Freiling, "Change Cases: Use Cases that Identify Future Requirements." OOPSLA, 1996.

Ivar Jacobson, Grady Booch, and Jim Rumbaugh, The Unified Software Development Process. Addison-Wesley, 1999.

Philippe Kruchten, The Rational Unified Process: An Introduction, 2nd ed. Addison-Wesley, 2000.

Ben Lieberman, "UML Activity Diagrams: Versatile Roadmaps for Understanding System Behavior." The Rational Edge, April 2001.

Tom Rowlett, "Building an Object Process Around Use Cases." Journal of Object-Oriented Design. March/April 1998, pp. 53-58.

Appendix: Structured Requirements to Use-Case Translation

The following statements are excerpts from a larger requirements definition for a customer care and automated service-provisioning system requested by a fictitious telecommunications firm. These requirements can be used to identify Actors, create initial use cases, and extract the beginnings of a data dictionary for the system.

System Requirements

CUSTOMERProTM Customer Care System

Service Provisioning

1. Customer shall be able to call a specific 888 number to automatically provision the telephony service after headset purchase via the PHONEMasterTM provisioning system.

2. Customer shall be able to call a specific 888 number or use a Web site to suspend telephony service for a period of up to six months. The Web interface will be easy to use and intuitive to the user.

3. Customer shall be able to have service disconnected by calling a specific 888 number or using a Web site.

Customer Service

4. System shall support Internet capabilities for customers to access and check their account(s), service status, and remaining pre-paid minutes.

5. System will permit the Call Center to accept payments into the CUSTOMERProTM system via check, cash, credit card, or electronic fund transfer. Payments that are overdue will be noted and charged a 2 percent late fee, which will be waived if the customer has premier service account status.

6. Call Center personnel will be limited to making refunds of $50 or less without supervisor approval.

7. All Call Center or customer actions will be logged and tracked for audit purposes.

8. The Web interface will be easy to use and intuitive to the user.

9. All Call Center personnel shall be able to access the same information as well as issue refunds and add pre-paid minutes to customer accounts (within specified limits, unless approved by the supervisor).

Translating Requirements into Use Cases

The "requirements" presented above are a collection of statements intended to describe the desired system (CUSTOMERPro). However, there is no clear theme or story. At first glance, there seem to be two clearly defined systems: one for Service Provisioning and a second for Customer Care. In reading the Service Provisioning section, it is clear that the term customer is used frequently to describe the functionality; this suggests that the functionality can actually be considered part of Customer Care. So we begin by defining a system boundary, as shown in Figure A-1.

Figure A-1: Defining a System Boundary

Next we look for Actors to the system. A "customer" is mentioned in statements 1, 2, 3, and 4. Call Center personnel are noted in statements 5, 6, 7, and 9. A system called "PHONEMaster" is noted in statement 1. So we amend our diagram as shown in Figure A-2:

Figure A-2: Adding Actors

Now we can begin to look for use cases and assign an Actor for each. Requirement 1 suggests some form of ability for the customer to activate phone service, while statement 2 suggests the ability to suspend said service, and statement 3 provides for disconnection of service. In addition, we find that there is some interaction with a separate system ("PHONEMaster"), although it is unclear whether this interaction is only for "activation," or also for the "suspend" and "disconnect." The implied supplemental requirement is that we will be developing a system that can be accessed via a regular telephone (see statements 1, 2, and 3). I usually capture such information directly into the documentation for a use-case diagram element, as shown in Figure A-3.

Figure A-3: Capturing a Supplemental Requirement

Then we can capture the use cases for this requirement, as shown in Figure A-4.

Figure A-4: Use-Cases for Supplemental Requirement

Statement 4 is a combined requirement statement, providing for both account management services and something called "pre-paid minutes." Note that this statement also contains a non-functional requirement for Internet-based access. Statement 5 is another compound requirement that combines information on acceptable payment types (check, cash, credit card, and EFT) with requirements about handling overdue payments. The astute investigator will note that statement 5 mentions something about "premier service account status." This suggests that the account management functionality noted in statement 4 will have some kind of information about the customer's role with the company (we can also capture this information into the use-case documentation section of the diagram). Our use case model is now shown in Figure A-5.

Figure A-5: Use-Case Model

Statement 6 suggests that the Accept Payments use case will also have a scenario for refunding customer accounts, with value limitations on the amount and approval requirements.

Statement 7 introduces a new functionality: logging. Also implied is some form of security (it would be hard to log a Call Center individual without unique identification). So we have an additional use case, as shown in Figure A-6.

Figure A-6: Model with Additional Use Case

Note that statement 8 is not really a requirement, but rather a generic statement about usability that cannot be measured or tested.

Statement 9 suggests that Call Center personnel can "access the same information," but is unclear about what information is referenced (Customer Account?). Also, it reiterates refund capability as well as the ability to add "pre-paid" minutes to a customer account (with undefined limitations and, again, supervisor approval).

We can now trace all of these statements to the use-case model, capturing non-functional requirements that are directly associated with specific use cases. We can also refactor the Telephone Service use cases to take advantage of the similarity between activation, suspension, and deactiviation (Figure A-7).

Figure A-7: Use-Case Model Capturing Non-Functional Requirements

We can also capture the scenarios captured in the documentation, as shown in Figure A-8.

Figure A-8: Capturing Use-Case Scenarios in Documentation

Clearly, this analysis has led to more questions than answers. Some additional follow-up activities can include: definition of the "pre-paid' minutes functionality; clarification of the 888 number interface; a definition of "head-set" (statement 1); and inquiry on the logging needs and data elements:

Audit Trail

● Date of Change

● Change Event (Refund, Pre-Paid Minutes, Customer Data, Payment)

● Original Information

● Altered Information

● User Identifier

● Approval Indicator

The next steps also include the creation of user flows to describe each of these system interactions (e.g., activity diagrams), and a further description of alternate and exceptional scenarios for each use case.

As shown in this example, even starting with a minimal description of the system, it is possible to create a reasonable model to capture and organize information as an investigation proceeds. I used Rational Rose to create and capture the information; this is my usual approach because Rose permits me to capture and organize my models in one step. Alternatively, you could use a less complex approach with a simple drawing tool and

skeleton use-case documents. The key is to take an analytical approach and maintain traceability to the original requirement statements.

Notes

1The term structured requirement refers to the classic declarative form, "The system shall ý"

2See http://www.rational.com/reqpro

3See http://www.rational.com/

4See http://www.textpad.com

5See Philippe Kruchten, The Rational Unified Process: An Introduction, 2nd ed. (Addison-Wesley, 2000) and Ivar Jacobson, Grady Booch, and Jim Rumbaugh, The Unified Software Development Process (Addision-Wesley, 1999).

6I use the term embedded to refer to requirements that exist in no other location than the code base. This is often a result of direct communications between a specific developer and the client, and the functionality is folded directly into the code base without review.

7It has been pointed out to me that using "lack" of documentation as an indicator of potentially critical requirement(s) is similar to the classic method of detecting pneumonia with a stethoscope -- it's where you don't hear any breath that a serious problem is likely to exist.

8See Ben Lieberman, "UML Activity Diagrams: Versatile Roadmaps for Understanding System Behavior." The Rational Edge, April 2001.

9http://www.rational.com/products/clearquest/index.jsp

10For additional information on soliciting requirements using interviews, see Dean Leffingwell and Don Widrig, Managing Software Requirements, A Unified Approach. Addison-Wesley, 2000, p. 491.

11Requested features are based on customer requests for functionality; requirements can be captured as use-case scenarios to represent the bulk of the functional requirements; supplementary documentation is useful for defining terms, nonfunctional requirements, examples, and implementation restrictions (e.g. third party interfaces).

12See the References listed below and the following Rational Edge articles:"Ending Requirements Chaos" http://www.therationaledge.com/content/aug_02/m_endingChaos_sa.jsp"Features, Use Cases, Requirements, Oh my!" http://www.therationaledge.com/content/dec_00/t_usecase.html"Iteration-Specific Requirements" http://www.therationaledge.com/content/mar_01/t_iteration_mt.html

13Software Engineering Body of Knowledge (SWEBOK): http://www.swebok.org/

For more information on the products or services discussed in this article, please click here and follow the instructions provided.

Thank you!

Copyright Rational Software 2002 | Privacy/Legal Information

Simplifying Product Line Development Using UCM Streams

by Jason Leonard

Principal ConsultantRational Software Australia

Many organizations struggle with the complexity inherent in developing a product family. This complexity can be partially managed by maintaining a strong focus on system architecture and program management techniques. Concentrating on the configuration management discipline, this article explains how the Unified Change Management (UCM) concept of

streams can help organizations support multiple product family projects by reducing start-up timeframes, tracking changes, managing dependencies between product variants, and propagating changes between product variants.

In typical product line development, several variants of a product are under development simultaneously. This can happen for any -- or sometimes all -- of the following reasons:

● Products with the same basic architecture are needed to provide different end-user services/functionality.

● The same product needs to be deployed on different target platforms (hardware or software).

● Older versions of the system need maintenance support.

● Development timeframes for multiple versions overlap; for example, Version 2 might still be under development when development of Version 3 is slated to begin.

The simultaneous development of multiple variants presents a significant challenge to the configuration manager: There is a delicate balancing act between the need to share desirable changes across all variants and the

http://www.therationaledge.com/content/nov_02/m_UCMStreams_jl.jspCopyright Rational Software 2002

need to keep firm control over the configuration of a given product.

In the modern software development environment, the scope, frequency, and volume of change, coupled with continually increasing system size and complexity, makes change tracking extremely difficult, even for a single project. With variants, this task becomes even more difficult. One way to tackle it is by adopting the advanced configuration management practices detailed in Rational's Unified Change Management (UCM)1 approach.

Based on studies of software development projects in a range of highly effective organizations, UCM was developed to help codify and automate change and configuration management best practices. It is implemented with the Rational® ClearCase® software configuration management tool. By applying the UCM concept of streams, organizations can efficiently develop variants, even in large-scale systems. Streams allow different project teams to work on a common set of artifacts independently, sharing changes only when it is desirable to do so.

Managing Change

In a software development environment, we can classify changes according to two levels of granularity:

● Microlevel, day-to-day changes that individual developers make to a component or set of components (e.g., bug fixes or small enhancement requests).

● Macrolevel changes that add significant new product capabilities to the system.

When planning development of a new product variant, it is convenient to think in terms of extending capabilities. We would specify a variant in terms of adding a new set of capabilities to the existing set of capabilities provided by a product framework. We may distinguish between the macrolevel and microlevel in a number of ways, but it is perhaps easiest to categorize macrolevel changes as those that are visible from a project management or end-user viewpoint: key features, performance improvements, and so on.

That said, management of microlevel changes is still very important. Customers hate nothing more than to see old defects find their way back into a release. You also want to be efficient about ensuring that bug fixes and small enhancements are propagated across all product variants. A common practice within more advanced software development environments is to create and maintain an architecture with a set of components that do not need modification from one product variant to another. This is usually realized by a layered architecture: Perhaps a "business" layer provides components that automate business logic common across each variant. Similarly, a "system" layer might provide a set of components that perform lower-level functionality (e.g., operating system interfaces, hardware interfaces, middleware interfaces, etc.) that is invariant from one project to another. Unfortunately, it is still possible -- and even likely -- that a component might need to be modified for some,

or even every, variant in any of the layers. For instance, there might be subtle modifications in the business logic between projects, or a requirement to support new computing hardware. In this situation, it is much better to automate (or at least partially automate) the propagation of required changes to the relevant variant, than to have to make these changes manually.

So, in summary, the goals of change management for developing product variants are:

● Specify variants in terms of adding new capabilities to an existing set of selected capabilities.

● Manage change at the microlevel and macrolevel ("product capability").

● Streamline the management of microlevel changes.

Let's explore how to use UCM (see definitions in the sidebar) by working through some scenarios.

Setup for Variant Development

Imagine that a development organization wants to port a system from a UNIX platform to MS-Windows, while continuing to support their UNIX-based customers. This is an example of a variant.

Project setup for variant development is a major hurdle for many software organizations. The first issue is often that they do not understand the need for robust configuration management practices to support variants. The organization might maintain multiple repositories (one per variant), each with slight differences -- and no one really understands what these differences are. Under these circumstances, the only way to propagate changes across variants is through "Copy and Paste." Changes to copied data then need to be maintained in each repository. But no one knows which repositories already have the change and which do not. Ensuring a high-quality product release will require a large amount of tedious and time-

UCM Definitions2

● Activity: A unit of work performed by an individual. In UCM. an activity tracks a change set, that is, a list of versions of files created to perform the work.

● Stream: A UCM construct that tracks activities. Work within a stream is always performed one activity at a time. Because streams track activities, and activities track file versions, at any given point in time a stream selects a single version of each file that corresponds to all work undertaken for the activities within that stream.

● Baseline: Data that identifies the versions of the components, files, and directories worked on. Baselines provide a consistent foundation for a team to

consuming inspection and adjustments.

A second issue is that, to start development of a variant with an existing set of artifacts, the team leader and/or architect must define a starting point for the development team and in many instances they choose component versions, rather than versions of individual files. This complicates project setup: It is not sufficient to track only component versions, because each variant might modify the same component. For example, specifying Version 5 of a file management component is meaningless if there is a Version 5 for the UNIX platform variant and a different Version 5 for the Windows platform variant.

Before starting work, development teams need to consider the following:

● What is the quality of the initial component versions? Preferably, only well-tested and approved changes should be included in the foundation for the new project, so that the project team can avoid spending time on resolving broken builds. So, the team needs a way to quickly select just those component versions that have undergone appropriate levels of quality assurance.

● What are the relationships between component versions? A component often has dependency relationships with several other components, so an incorrect set of component versions could cause integration problems. This means that a configuration management approach that focuses exclusively on components while neglecting their relationships is sub-

work from, including the versions of components, files, and directories that constitute a previous release. Baselines can be applied to streams to identify their configuration at a point in time.

● Project: A UCM construct that groups configuration management information, such as which components will be worked on during the project. A project contains at least one stream.

● View: A virtual working area showing artifacts (documents, code, directories, etc.). A view is associated with a stream, and the stream specifies the configuration of the view; that is, the stream selects the version of the artifacts the user will see.

● Component: A nontrivial, nearly independent, and replaceable part of a system that fulfills a clear function in the context of a well-defined architecture3. In the context of configuration management, a component groups a set of related directory and file elements. Typically, elements that make up a component are developed, integrated, and released together.

optimal.

Large projects can spend an enormous amount of time determining the answers to these questions, so what is needed is a streamlined approach.

Using UCM streams represents a very efficient approach. Each stream specifies the right version of every file. This greatly reduces the need to track file or component versions, and the dependencies between these versions, because the stream represents the foundation for a project in terms of a single entity.

Of course, a developer might not want the latest changes made in the stream if they have not have been tested. UCM streams have a baseline to record their configuration at a point in time, so the team lead can select not only a stream, but also a baseline within that stream, to provide a stable foundation for team members to work from. The stream concept represents a change in mindset for many experienced software configuration managers, most of whom are used to thinking of baselines as versions of components. But UCM extends the concept to improve efficiency: It defines a baseline for a stream, which in turn defines baselines for the components in that stream.

With this stream-based approach, larger projects can use UCM components -- rather than a myriad of small logical components -- to represent large subsystems.

Controlling Changes Across Multiple Variants

Now, let's imagine that we have a microlevel change (e.g., a bug fix or small enhancement) to make. If we are developing variants, there are three possibilities:

Case 1: The change is required by just one variant of our product; for example, the change might be specific to software running on the MS-Windows platform.

Case 2: The change is required by all variants; for example, the change might relate to how a calculation is performed, which should be platform independent.

Case 3: The change is required by selected variants; for example, a change might be required only for the variants created for Japanese and Chinese customers.

Case 1 is relatively easy to deal with. So is Case 2, provided that the project team has a good architect; the calculation could be compartmentalized into a single component that is shared among all variants. Case 3 requires selectively propagating the change to multiple variants, which is where UCM can really help out.

Let's review in detail how UCM assists teams in each of these situations.

Under the UCM model, the team would walk through the following steps:

Step 1: When starting on a project, each team member "joins" the project. This creates a view for the person to work in. The configuration of that view is based on a new stream that tracks the changes made by the team member.

Step 2: An activity is created (perhaps by the team leader) and assigned to the team member.

Step 3: This team member accepts the activity within the context of the stream and commences work. As the stream has preconfigured the working area (view), development can start immediately.

Step 4: Eventually, the change is completed. At this point, the team member could either take on other related work or baseline the stream to capture the state of the artifacts at that point in time.

Step 4a: In Case 1 (change required by just one variant), there might be integration required with others working on the project, but the work is otherwise finished.

Step 4b: In Case 2 or Case 3 (change required by some or all variants), we would also need to go through integration. This time, we could make use of the automation provided by the tool (Rational ClearCase) to deliver changes to multiple destinations (product variants).

Example: Developing a GPS Tracking System

Step 4b clearly needs additional explanation; let's do this by walking through another example: the development of a GPS tracking system originally created for in-car use. Let's suppose that, although the original system is successful, it has not been widely adopted in the prestige car market. To break into this market, a number of new features are required (i.e., a variant), which in turn require changes to existing software components. In addition, we want to create variants for trucks and hand-held devices.

The Problem

For the hand-held device, the graphics software for the GPS tracking system needs to be modified to deal with the screens used in these devices. The team working on the prestige car project also needs these changes, as they want to adopt similar hardware to reduce sun glare.

The UCM Solution

The UCM solution to this problem is sketched out in Figure 1. To solve this problem, the team used multiple streams:

● A stream for each variant.

● A stream to group activities common to multiple variants.

If the team had made modifications required to support the screens directly within the hand-held variant stream (by checking out files from a workspace [view] associated with that stream), it would have been difficult to share these modification without also sharing the activities specific to the hand-held variant. So instead, the team used a "Graphics Changes" stream to capture all the development changes and then "deliver"4 (to use more UCM terminology) these changes to each variant that needed them -- in this case, the hand-held and prestige car streams.

Figure 1: Using Streams to Manage Variants

Let's get down to the "nuts and bolts" of setting up this mechanism. First, the developer creates a new view to provide a workspace to modify files and directories, and to build and test the changes. He can either select the Graphics Changes stream or request that another stream be created. For the moment, let's assume he uses the Graphics Changes stream.

To modify a file (e.g., graphicsdriver.cpp), the developer must check it out from the workspace. Of course, he needs to check out the correct version. If he is using UCM, he knows it is the correct version because the developer is working in a ClearCase view (i.e., a workspace), and ClearCase view is associated with a stream, which automatically configures the view with the latest set of file and directory versions. In response to a check out request, the stream selects a file that reflects the baseline (tested and reviewed component versions) the stream is founded upon, plus changes to this baseline.

When the developer checks out a file, UCM forces him to specify the context for his modifications -- that is, the activity to which he has been assigned. Checking in a file creates a new version for that file, and the activity's change set is updated to record this new version. ClearCase also automatically updates the configuration of versions in the developer's view so that he will select this new version. In our example, the developer modifies graphicsdriver.cpp to support new graphics hardware, so the activity might be called "Activity 263: Support New Graphics Hardware model 654 from VeryGoodGraphicsHardware Corporation."

Once the developer makes all the changes, he (or the integrator, depending on the organization's size and preferences) can perform delivery as follows:

1. The developer) selects the view with the changes, clicks a "Deliver" button, and selects the destination -- in this case the hand-held variant stream.

2. ClearCase finds the activities that have not been previously delivered5 . Then, using the change set for each of these activities, it determines the changes, at a file and directory level, that should be incorporated into the destination stream.

3. The developer/integrator may review the activities (e.g., Activity 263) and changes (e.g., versions 1, 2, and 3 created on the Graphics Changes stream of graphicsdriver.cpp) to be delivered, and then either proceed or perform further quality assurance procedures, such as peer reviews of these versions.

4. When the developer/integrator decides to proceed, the destination (hand-held) stream is updated to include all activities created or modified (such as Activity 263) within the Graphics Changes stream since the last delivery. At a file level, this means:

EITHER: ClearCase will update the hand-held variant stream so that a different version of graphicsdriver.cpp will be selected in views that are configured by this stream,

OR: If graphicsdriver.cpp has already been modified in the hand-held variant stream, ClearCase will merge the modifications made by the Graphics Changes stream with the modifications already present. Note that this merging procedure is quite robust for many file types (text, HTML, XML, etc.) but is problematic for binary files. In either case, the user may choose to be informed of the changes made and review the automated modifications before committing to them.

Tracking the Work of Multiple Developers

If the graphics changes required are quite significant, several developers might be assigned to the task. If all of these developers work on the same Graphics Changes stream, even with separate workspaces, issues can arise that impact productivity.

Let's suppose that Bob and Wendy are both assigned to the graphics work and have split the work between them: Bob does Activity 263, and Wendy does Activity 264: Improve Graphics Rendering Performance (Figure 2). Wendy determines that Activity 264 requires modifications to the graphicsrendering.cpp file, so she checks it out and makes modifications. Wendy, being the conscientious developer she is, decides to test these changes. To perform the test, she tries to build the software. Sadly for Wendy, Bob previously checked in his changes (to graphicsdriver.cpp) without testing or even compiling them. As Bob's and Wendy's views share the same configuration, when Bob checks in his changes to graphicsdriver.cpp, Wendy's view may be updated to select the new version. Because Wendy can test her system only if she compiles both graphicsrendering.cpp and graphicsdriver.cpp, her work could be halted by Bob's lack of attention to quality: graphicsdriver.cpp might not compile, or it might cause the system to fail immediately upon execution (Figure 3).

Figure 2: Initial Configuration Before Two Developers Commence Their Separate Activities

Figure 3: Configuration After Two Developers Check in Their Changes

To address this situation, Wendy and Bob could create individual streams, based on the same foundation as the Graphics Changes stream. Their individual changes would then be entirely isolated from each other, and Wendy's productivity would not be hampered by Bob's lack of attention to detail (Figure 4).

Figure 4: Two Developers Using Separate Streams

This is detail; let's take a quick step back and look again at the big picture. We have seen that the big advantages to using streams and UCM are that you can:

● Quickly propagate a bug fix or enhancement to all product variants that need it.

● Improve the productivity of individual developers.

However, we have been using simplified examples that don't touch upon some of the complexities of larger software projects. We'll discuss scaling up in the next section.

Scaling Up

If the projects working to create the product variants are large both in duration and staff size, the variants are likely to move farther and farther from one another and from their common base. This makes it more difficult to craft modifications that can be delivered to multiple variants automatically.

A solution for scaling up is to use streams in an additional role: to manage capabilities. You can control divergence between variants by building them out of more fundamental building blocks. Note that this is different from conventional configuration management practices, which build systems from baselined configuration items; streams use baselines to group activities. The UCM approach provides the rigor of component centric baselines, but more readily provides for development of variants.

In larger projects, streams can be useful on three levels:

1. Capturing microlevel changes. Once they are reviewed and tested, these changes can be baselined.6

2. Capturing macrolevel functionality (i.e., capabilities). The microlevel streams start from a baseline within these capability streams and are delivered back to them. Again, after QA, the capability would be baselined.

3. Building up product variants via deliveries from capability streams. After QA, baselines of these variants would be delivered to the customer.

Example: GPS Tracking System with New Capability

Let's continue to follow the GPS Tracking System example, this time assuming that we need to add an entirely new capability (macrolevel change) requirement for the prestige car market: giving verbal directions to the user.

The new capability is developed within the confines of a stream. This means that even though it was originally developed with only prestige cars in mind, it was developed in isolation; so it can be delivered to another stream -- say the stream used for the truck variant -- or another project.

Some questions arise when implementing such a macrolevel change:

● What if this shared software component depends on other components? How can we make sure that these are also included?

ClearCase does not need to read or understand the contents of the files it stores to understand dependencies between the files. Recall that activities record change sets; that is, an activity remembers the name and version of each file created as a result of that activity.

Therefore, when the development activities that were carried out within the (prestige car) stream are delivered to the truck project, we get not only the verbal directions component, but also the correct configuration of all other required files. This greatly simplifies reuse compared with the alternative: tracking the correct baseline of each and every required file or component.

● How do we know that the versions of these files are ready for use, and have been approved according to our quality procedures?

Activities do not just track modified files; they may also have associated workflow and data that will help ensure that quality procedures are met. For example, if the activity should be signed off before it is delivered to other streams, this can be enforced. This is where Rational ClearQuest comes in; basically, ClearQuest is a configurable workflow engine.

● OK, but what if the truck project wanted to "tweak" this software component to fit their specific needs?

That would be a microlevel change. Again, the developers could create a stream to capture the changes in isolation so that they could be integrated with other changes for the truck project, and perhaps also delivered back to the prestige car project if the changes were useful to that team.

● What if the verbal directions component(s) depended on other components already in use by the truck project?

We have four possibilities:

1. The truck project uses the same version of these components. No problem.

2. The truck project uses a more recent version of these components. The shared component (verbal directions) would have to be retested to ensure it is not broken by the more recent components it depends upon.

3. The truck project uses an older version of the components. The components in use by the truck project would be updated (automatically) to match those required by the verbal directions component. Retesting the truck project might be required, because other parts of the truck system might be affected adversely by these new component versions.

4. The truck project uses a different version of the components (i.e., it has also modified the components). This might result in automated file merges if the same files or directories were modified. If this happens, ClearCase will attempt to retain the modifications made by both projects. Human intervention is required and prompted for if conflicts occur, such as when both projects change exactly the same line of a text file.

Reuse clearly remains a non-trivial task, but this scenario demonstrates that UCM streams make this goal achieveable by allowing teams to focus on capabilities, not individual files or components.

Quality Assurance

All this talk of streams and automated deliveries from one stream to another is well and good, but it doesn't stop problems from creeping in through various sources, including:

● A change that is delivered to integration before unit testing or other quality assurance procedures are completed.

● A change that depends on other changes is delivered out of sequence and stalls integration.

● A change that is delivered to the wrong stream; for example, the verbal directions capability might be delivered to the hand-held variant by mistake.

Another challenge that arises in larger projects is simply tracking all the changes that have been delivered and integrated. For example, how can we easily generate release notes detailing bugs fixed and added enhancements? UCM provides options to help out. For example, the deliver function can be scripted to enforce any given process, as in the following cases:

● The project manager might need to move change requests into an "approved" state before the delivery can take place.

● Change requests might have links to other dependent change requests; the deliver script could check that all dependencies have been delivered first.

Because UCM is activity focused, it automatically provides a list of change requests completed between baselines, so generation of release notes and baseline auditing can be partially automated. This automation can then, in turn, provide a project manager or release engineer with sufficient data to decide whether a given baseline should be approved for release.

Streams for Phased Integration

Some organizations use streams to implement phased integration, even if they are not developing variants. For example, a project might be divided into teams focusing on particular system areas, such as capabilities or logical subsystems. Individuals within a team deliver to a stream for "local" integration. When the team has integrated successfully, there is a second delivery to a system integration stream. This allows the project to employ different levels of formality: Small teams can have a low-ceremony configuration management process, promoting collaboration wherever possible but employing more rigor where it matters -- at a system integration level.

Streams for Efficiency

Using UCM streams to capture product capabilities is a logical and efficient way to manage the complexities inherent in developing product variants in both large- and small-scale projects. Using streams, the configuration manager can minimize project startup and integration time by automating delivery of a correct and consistent configuration of the versions of components that provide these product capabilities. This alleviates the need to manually track the dependencies of individual components and keeps the project running smoothly and efficiently.

References

Brian White and Geoffrey Clemm, Software Configuration Management Strategies and Rational ClearCase: A Practical Introduction. Addison Wesley, 2000.

Notes

1 As implemented in Rational ClearCase v2002.

2 I've simplified definitions to fit the context of this article. The Glossary for Rational ClearCase provides more formal definitions.

3 RUP v2002 definition.

4 "Deliver" is an automated function in the ClearCase implementation of UCM.

5 The Deliver operation may also redeliver activities. An activity might be delivered more than once if work continues on the activity after the initial delivery. At a lower level, this means that extra file or directory versions have been created since the initial delivery.

6 This is true in UCM as implemented in ClearCase v2002. Previous versions of UCM were more restrictive with respect to where baselines could be applied.

For more information on the products or services discussed in this article, please click here and follow the instructions provided. Thank you!

Copyright Rational Software 2002 | Privacy/Legal Information