Home > Articles > Software Development & Management

  • Print
  • + Share This
This chapter is from the book

1.5 SPE for Object-Oriented Systems

The bad news is that object-oriented (OO) systems present special problems for SPE. The functionality of object-oriented systems is decentralized. Performing a given function is likely to require collaboration among many different objects from several classes. These interactions can be numerous and complex and are often obscured by polymorphism, making them difficult to trace. Distributing objects over a network compounds the problem.

The good news is that object-oriented modeling notations (such as the Unified Modeling Language [UML]) and methods actually help to reduce the impact of these problems. Much of the information needed to perform SPE can be captured as part of the object-oriented analysis and design process with a minimum of disruption. Use cases, which are identified as part of the requirements definition, are a natural link between software development activities and SPE. The scenarios that describe the use cases provide a starting point for constructing the performance models.

Our approach to SPE is tightly integrated with object-oriented notations, such as the UML. It does not require that you become an expert in performance modeling. To do SPE, you construct analysis and design models as you have always done. When you want to evaluate the emerging software's performance, you use your object-oriented analysis or design models to derive a performance model. Solving the model gives you feedback on the performance and suggests ways of revising the design.

SPE is also language independent. The models are constructed from architectural and design-level information. Thus, SPE works with C++ and Java as well as with other object-oriented and non-object-oriented languages. The execution behavior of the software will be different with different languages. Nevertheless, this is reflected in the resource requirement specifications, not the model structure.

This integration is addressed in Chapter 15.

SPE can be easily integrated into the software development process. It has been used with traditional process models, such as the waterfall model. It works especially well with iterative, incremental processes such as the Spiral Model [Boehm 1988] or the Unified Process [Kruchten 1999], [Jacobson et al. 1999]. With an iterative, incremental process, you can use SPE techniques to assess and reduce the risk of performance failure at the project outset, and at each subsequent iteration.

1.5.1 What Does It Cost?

The cost of SPE is usually a minor component of the overall project cost. Lucent Technologies has reported that the cost of SPE for performance-critical projects is about two to three percent of the total project budget. For other, less critical, projects, SPE typically costs less than one percent of the total project budget. For projects where the performance risk is very high, the SPE expenditure may be as much as ten percent of the project budget.

SPE efforts can save far more than they cost by detecting and preventing performance problems. Bank One reported that, on one project, SPE costs over a five-month period were $147,000. During this time, the team analyzed three applications and identified modifications that resulted in a projected annual savings of $1,300,000 [Manhardt 1998]. Similarly, the performance engineering group at MCI reported a $20,000,000 savings in one year with SPE due to reduced resource requirements that resulted in deferred configuration upgrades [CMG 1991].

1.5.2 What Do You Need?

To perform SPE studies, you need two essential skills:

  • Estimation techniques for specifying best- and worst-case resource requirements

  • Enough modeling background to understand the translation of OO models into performance models, and to understand the results

This book provides the information you need to develop these skills.

Other factors will make your SPE efforts easier. The following list starts with factors that are easy to find and progresses to those that require more effort but provide substantial benefits.

  1. Performance specialists in your computer systems department (capacity planners, system programmers, and so on.) can assist with measurement studies and modeling techniques.

  2. SPE tools make it easier for you to create and evaluate the models.

  3. Management commitment provides sufficient time and resources to evaluate the risk of performance failures early in the project, and take appropriate steps based on the results. Management commitment provides the incentive and the ability to conduct SPE tasks.

  4. Formal integration of SPE into the software development process with specific SPE milestones and deliverables makes SPE less people-dependent and ensures that it will be uniformly applied across projects.

  5. An official SPE organization can provide a team of specialists to assist many projects with the SPE modeling and analysis steps. This organization is not the same as the computer system performance specialists in item 1. This team is more closely allied with the development organization, and provides software-specific performance engineering support.

These topics and others are also addressed in this book.


SPE is not a silver bullet—you cannot buy one book or one tool and expect that it alone will resolve performance problems.

SPE takes thought, effort, and analysis to produce the desired results. However, the return on investment for SPE more than justifies its use.

  • + Share This
  • 🔖 Save To Your Account