The Rational Edge: e-zine for the Rational Community · The Rational Edge: e-zine for the Rational...

Search help

© Copyright IBM Corporation 2004. All rights reserved. http://www-136.ibm.com/developerworks/rational/rationaledge

Search help

Issue contents

Editor's notes

Welcome toThe Rational Edge ezine —and to our new home in the Rational portion of IBM developerWorks. For those of you already familiar with this publication, you’ll notice a few changes: The “Franklin’s Kite”section has been renamed “Theory &Practice,”the “Management”section is now called “Teams &Projects,”and you should look for articles that used to appear in our “Technical”section throughout the Rational portion of developerWorks (http://www-136.ibm.com/developerworks/rational). If you’re not familiar with The Rational Edge, we think you’ll find it a rich resource for explanations and general guidance to IBM Rational methods, technologies, and thought leadership regarding software development.

This month’s cover storyby Alan Brown, who was recently named an IBM Distinguished Engineer, offers an introduction to model driven architecture, or MDA. And you’ll find lots more in the table of contents below.

Happy iterations, Mike PerrowEditor-in-Chief

Features

● An introduction to Model Driven ArchitecturePart I: MDA and today’s systemsby Alan W. BrownIn this first part of a three-part series, Brown examines the importance of models and modeling, introduces four key principles of MDA, and looks at the leadership role that IBM has played in defining the approach and its supporting standards.

● Ensuring success with IBM Rational's system integrator partnersby Thomas G. McBrideAn introduction to a new series of articles contributed by IBM Rational systems integrator partners. These articles illustrate successful, working models of systems integrator and client

Teams and projects

● UML's Sequence Diagramby Donald BellPart of a series of articles, "UML basics," on the essential diagrams in the Unified Modeling Language, this article offers a detailed introduction to the sequence diagram. It also introduces several new notation elements in the recent UML 2.0 specification.

● Performance testing Java servlet-based Web applications: A guide for software test engineersby Len DiMaggioAs testing expert DiMaggio walks readers through the ins and outs of performance testing for applications built with Java servlets, he makes special note of ways

issue contents

archives

subscribe

submit an article

contact us

Entire issue in .pdf

Downloadthe entire issue in .pdf (9.8 MB)

© Copyright IBM Corporation 2004. All rights reserved. http://www-136.ibm.com/developerworks/rational/rationaledge

The Rational Edge: e-zine for the Rational Community

interaction, and they are designed to spark imagination regarding the use of systems integrators in a variety of software development projects.

● CSC and IBM Rational join to deliver C-RUP and support rapid business changeby David J. Jones and Stosh MisiaszekThe first in a series of articles contributed by IBM Rational systems integrator partners, this article examines an integration of two methodolgoies: CSC's Catalyst and IBM Rational's Rational Unified Process, or RUP. The result? C-RUP.

● Model Driven Development for J2EE with IBM Rational Rapid Developer (RRD)by The Middleware Company Case Study Team

Rational reader

● Practical Software Engineeringby Enricos ManassisReviewed by Parshu AnantharamThis review describes a book on how to integrate three aspects of software development: the process of engineering software-intensive systems, object-oriented analysis and design methodology, and technology.

● Radical Project Managementby Rob ThomsettReviewed by Tanuj VohraVohra reviews a book that explains the complexities of managing time-sensitive projects in rapidly changing environments, and suggests tools project managers should use to manage those complexities.

that servlets’distinctive characteristics can affect overall application performance.

● Using IBM Rational RequisitePro to evaluate competing bidsby Fredrik FermUsing IBM Rational RequisitePro to manage the bid selection process bypasses the problem of having to synchronize a specialized bid analysis tool with your requirements tool, Ferm explains. This article describes how to automate the selection process with Rational RequisitePro support.

Theory and practice

● A look at aspect-oriented programmingby Gary PollicePollice provides an overview of AOP and offers some observations on its promise, what we need to do to realize that promise, and some issues and obstacles along the way.

About IBM | Privacy | Terms of use | Contact

An introduction to Model Driven Architecture Part I: MDA and today’s systems

Contents:Effective enterprise software development

The rationale for modeling

MDA in theory

IBM and MDA

Summary

Acknowledgments

Further reading

References

Notes

About the author

Rate this article

Subscriptions:dW newsletters

dW Subscription(CDs and downloads)

Alan BrownIBM12 January 2004

from The Rational Edge: In this first part of a three-part series, Brown examines the importance of models and modeling, introduces four key principles of MDA, and looks at the leadership role that IBM has played in defining the approach and its supporting standards.

In recent months many organizations have begun to focus attention on Model Driven Architecture (MDA)1 as an approach to application design and implementation. This is a very positive development for several reasons. MDA encourages efficient use of system models in the software development process, and it supports reuse of best practices when creating families of systems. As defined by the Object Management Group (OMG), MDA is a way to organize and manage enterprise architectures supported by automated tools and services for both defining the models and facilitating transformations between different model types.

While the OMG-defined MDA standards and terminology for creating and evolving enterprise-scale software systems are becoming widely referenced in the industry, only recently has the OMG and its members, including IBM Rational, been able to offer clear guidance on what MDA means, where we are in its evolution, what aspects of MDA are possible with today’s technology, and how to take advantage of MDA in practice.

© Copyright IBM Corporation 2004. All rights reserved. http://www-106.ibm.com/developerworks/rational/library/3100.html© Copyright IBM Corporation 2004. All rights reserved. http://www-106.ibm.com/developerworks/rational/library/3015.html


This article is Part I of a three-part series that will cover: how modeling is used in industry today and the relevance of MDA to today’s systems (Part I); a classification of MDA tooling support (Part II); and examples of MDA's use in the context of IBM’s model-driven development technology (Part III).

In this first part we examine the importance of models and modeling, and introduce the four key principles of MDA. We then look at IBM’s support for MDA and the leadership role that IBM has played in defining the MDA approach and its supporting standards.2

Effective enterprise software developmentDeveloping enterprise-scale applications today requires an approach to software architecture that helps architects evolve their solutions in flexible ways. This approach should permit reuse of existing efforts in the context of new capabilities that implement business functionality in a timely fashion, even as the target infrastructure itself is evolving. Two important ideas are now considered central to addressing this challenge:

● Service-Oriented Architectures (SOA). Enterprise solutions can be viewed as federations of services connected via well-specified contracts that define their service interfaces. The resulting system designs are frequently called Service Oriented Architectures (SOAs).3 Flexibility can be enhanced in a system’s architecture by organizing a system as a collection of encapsulated services making calls on operations defined through their service interfaces. Many organizations now express their solutions in terms of services and their interconnections.

● Software Product Lines. Frequently, there is a great deal of commonality among the systems an organization develops and maintains. We see recurring approaches at every level of an enterprise software project, from having standard domain models that capture core business processes and domain concepts, to the way in which developers implement specific solutions to realize designs in code. Organizations gain a great deal of efficiency when patterns can be defined by skilled practitioners and propagated across the IT organization. This represents a move toward a software product-line view of development that promotes planned reuse of assets, along with an increasing level of automation, to realize solutions for large parts of the systems being developed.4 More generally, we can understand the application of well-defined patterns in a product-line view of development as a way to transform descriptions of a solution from one level of abstraction to a lower level of abstraction.

These two ideas have had significant influence on the thinking of the Object Management Group (OMG), a consortium of software organizations that develops and supports specifications to improve the practice of enterprise software development and deployment. (There will be more on the important role the OMG plays in the next section.) The OMG has created a conceptual framework5 that separates business-oriented decisions from platform decisions to allow greater flexibility when architecting and evolving these systems. This conceptual framework and the standards that help realize it is what the OMG calls “Model Driven Architecture (MDA).”6 Application architects use the MDA framework as a blueprint for expressing their enterprise architectures, and employ the open standards inherent in MDA as their “future proofing” against vendor lock-in and technology churn.

The OMG’s MDA concept provides an open, vendor-neutral approach to system interoperability via OMG's established modeling standards: Unified Modeling Language (UML), Meta-Object Facility (MOF), XML Metadata Interchange (XMI), and Common Warehouse Meta-model (CWM). Descriptions of enterprise solutions can be built using these modeling standards and transformed into a major open or proprietary platform, including


CORBA, J2EE, .NET, and Web-based platforms.

Before we delve further into MDA, let’s consider the fundamental concepts and benefits of modeling in software development.

The rationale for modeling Models provide abstractions of a physical system that allow engineers to reason about that system by ignoring extraneous details while focusing on relevant ones. All forms of engineering rely on models to understand complex, real-world systems. Models are used in many ways: to predict system qualities, reason about specific properties when aspects of the system are changed, and communicate key system characteristics to various stakeholders. The models may be developed as a precursor to implementing the physical system, or they may be derived from an existing system or a system in development as an aid to understanding its behavior.

Views and model transformationBecause many aspects of a system might be of interest, you can use various modeling concepts and notations to highlight one or more particular perspectives, or views, of that system, depending on what is relevant at any point in time. Furthermore, in some instances you can augment the models with hints, or rules, that assist in transforming them from one representation to another. It is often necessary to convert to different views of the system at an equivalent level of abstraction (e.g., from a structural view to a behavioral view), and a model transformation facilitates this. In other cases, a transformation converts models offering a particular perspective from one level of abstraction to another, usually from a more abstract to less abstract view, by adding more detail supplied by the transformation rules.

Models, modeling, and MDAModels and model driven software development are at the heart of the MDA approach. So to better understand MDA, it is appropriate to first look at how enterprise application developers take advantage of modeling.

In the software engineering world, modeling has a rich tradition, dating back to the earliest days of programming. The most recent innovations have focused on notations and tools that allow users to express system perspectives of value to software architects and developers in ways that are readily mapped into the programming language code that can be compiled for a particular operating system platform. The current state of this practice employs the Unified Modeling Language (UML) as the primary modeling notation. The UML allows development teams to capture a variety of important characteristics of a system in corresponding models. Transformations among these models are primarily manual. UML modeling tools typically support requirements traceability and dependency relationships among modeling elements, with supporting documents and complementary consulting offerings providing best practice guidance on how to maintain synchronized models as part of a large-scale development effort.

One useful way to characterize current practice is to look at the different ways in which the models are synchronized with the source code they help describe. This is illustrated in Figure 1,7 which shows the spectrum of modeling approaches in use by software practitioners today. Each category identifies a particular use of models in assisting software practitioners to create running applications (code) for a specific runtime platform, and the relationship between the models and the code.8


Figure 1: The modeling spectrum

Today, a majority of software developers still take a code-only approach (left end of the modeling spectrum, Figure 1) and do not use separately defined models at all. They rely almost entirely on the code they write, and they express their model of the system they are building directly in a third-generation programming language such as Java, C++, or C# within an Integrated Development Environment (IDE) such as IBM WebSphere Studio, Eclipse, or Microsoft VisualStudio.9 Any “modeling” they do is in the form of programming abstractions embedded in the code (e.g., packages, modules, interfaces, etc.), which are managed through mechanisms such as program libraries and object hierarchies. Any separate modeling of architectural designs is informal and intuitive, and lives on whiteboards, in PowerPoint slides, or in the developers’ heads. While this approach may be adequate for individuals and very small teams, it makes it difficult to understand key characteristics of the system among the details of the implementation of the business logic. Furthermore, it becomes much more difficult to manage the evolution of these solutions as their scale and complexity increases, as the system evolves over time, or when the original members of the design team are not directly accessible to the team maintaining the system.

An improvement is to provide code visualizations in some appropriate modeling notation. As developers create or analyze an application, they often want to visualize the code through some graphical notation that aids their understanding of the code’s structure or behavior. It may also be possible to manipulate the graphical notation as an alternative to editing the text-based code, so that the visual rendering becomes a direct representation of the code. Such rendering is sometimes called a code model, or an implementation model (although many feel it is appropriate to call these artifacts “diagrams” and reserve the use of “model” for higher levels of abstraction). In tools that allow such diagrams (e.g., IBM WebSphere Studio and Borland Together/J), the code view and the model view can be displayed simultaneously; as the developer manipulates either view, the other is immediately synchronized with it. In this approach, the diagrams are tightly coupled representations of the code and provide an alternative way to view and possibly edit at the code level.

Further modeling advantages are available through roundtrip engineering (RTE), which offers a bi-directional exchange between an abstract model describing the system architecture or design, and the code. The developer typically elaborates the system design to some level of detail, then creates a first-pass implementation by applying model-to-code transformations, usually manually. For instance, one team working on the high-level design might provide design models to the team working on the implementation (perhaps simply by printing out model diagrams or providing the implementation team with files containing the models). The implementation team


converts this abstract, high-level design into a detailed set of design models and the programming language implementation. Iterations of these representations will occur as errors that might be corrected in either the design or the code. Consequently, without considerable discipline, the abstract models and the implementation models usually—and quickly—end up out of step.

Tools can automate the initial transformation and also help to keep the design and implementation models in step as they evolve. Typically, the tools generate code stubs from the design models that the user has to further refine.10 Changes to the code must at some point be reconciled with the original model (hence the term “roundtrip engineering,” or RTE). To achieve this, you need a way to recognize generated versus user-defined code; placing markers in the code is one approach. Tools that implement this approach, such as IBM Rational Rose, can offer multiple transformation services supporting RTE between models and different implementation languages.

In a model-centric approach, the system models have sufficient detail to enable the generation of a full system implementation from the models themselves. To achieve this, the models may include, for example, representations of the persistent and non-persistent data, business logic, and presentation elements. If there is any integration with legacy data and services, the interfaces to those elements may also need to be modeled. The code generation process may then apply a series of patterns to transform the models to code, frequently allowing the developer some choice in the patterns that are applied (e.g., among various deployment topologies). This approach frequently makes use of standard or proprietary application frameworks and runtime services that ease the code generation task by constraining the styles of applications that can be generated. Hence, tools using this approach typically specialize in the generation of particular styles of applications (e.g., IBM Rational Rose Technical Developer for real-time embedded systems and IBM Rational Rapid developer for enterprise IT systems). However, in all cases the models are the primary artifact created and manipulated by developers.

A model-only approach is at the far-right end of the coding/modeling spectrum shown in Figure 1. In this approach developers use models purely as aids to understanding the business or solution domain, or for analyzing the architecture of a proposed solution. Models are frequently used as the basis for discussion, communication, and analysis among teams within a single organization, or across multi-organizational projects. These models frequently appear in proposals for new work, or adorn the walls of offices and cubes in software labs as a way to promote understanding of some complex domain of interest, and to establish a shared vocabulary and set of concepts among disparate teams. In practice, the implementation of a system, whether from scratch or as an update to an existing solution, may be disconnected from the models. An interesting example of this is the growing number of organizations that outsource implementation and maintenance of their systems while maintaining control of the overall enterprise architecture.

MDA: A growing consensusModeling has had a major impact on software engineering, and it is critical to the success of every enterprise-scale solution. However, there is great variety in what the models represent and how they are used. An interesting question is: which of these approaches can we describe as “model-driven”? If I create a visualization of some part of a system, does that mean I am practicing MDA? Unfortunately, there is no definitive answer. Rather, there is a growing consensus that MDA is more closely associated with approaches in which code is (semi-) automatically generated from more abstract models, and that employ standard specification languages for describing those models. We will explore this concept in the next section.

MDA in theoryThere are many views and opinions about what MDA is and is not. However, the most authoritative view is


provided by the Object Management Group (OMG), an industry consortium of more than 800 companies, organizations, and individuals. Why does the OMG’s view of MDA matter so greatly? As an emerging architectural standard, MDA falls into a long tradition of OMG support and codification of numerous computing standards over the past two decades. The OMG has been responsible for the development of some of the industry's best-known and most influential standards for system specification and interoperation, including the Common Object Request Broker Architecture (CORBA), OMG Interface Definition Language (IDL), Internet Inter-ORB Protocol (IIOP), Unified Modeling Language (UML), Meta Object Facility (MOF), XML Metadata Interchange (XMI), Common Warehouse Model (CWM), and Object Management Architecture (OMA). In addition, OMG has enhanced these specifications to support specific industries such as healthcare, manufacturing, telecommunications, and others.

The OMG has refocused its strategy, standards, and positioning to support the MDA approach. It is promoting MDA as a way to develop systems that more accurately satisfy customers’ needs, and that offer more flexibility in system evolution. The MDA approach builds on earlier system specification standards work, and it provides a comprehensive interoperability framework for defining interconnected systems.

The principles of MDAFour principles underlie the OMG’s view of MDA:

● Models expressed in a well-defined notation are a cornerstone to understanding systems for enterprise-scale solutions.

● The building of systems can be organized around a set of models by imposing a series of transformations between models, organized into an architectural framework of layers and transformations.

● A formal underpinning for describing models in a set of metamodels facilitates meaningful integration and transformation among models, and is the basis for automation through tools.

● Acceptance and broad adoption of this model-based approach requires industry standards to provide openness to consumers, and foster competition among vendors.

To support these principles, the OMG has defined a specific set of layers and transformations that provide a conceptual framework and vocabulary for MDA. Notably, OMG identifies four types of models: Computation Independent Model (CIM), Platform Independent Model (PIM), Platform Specific Model (PSM) described by a Platform Model (PM), and an Implementation Specific Model (ISM).

For MDA, a "platform" is meaningful only relative to a particular point of view – in other words, one person's PIM is another person's PSM. For example, a model may be a PIM with respect to choice of communication middleware if that model does not prescribe a particular choice of middleware technology. However, when a decision is made to use particular middleware such as CORBA, the model is transformed to a CORBA-specific PSM. The new model may still be a PIM with respect to choice of ORB – and certainly with respect to target operating system and hardware. This is illustrated in Figure 2.


Figure 2: An example of PIM to PSM transformations

As a result, an MDA tool may support transforming a model in several steps, from initial analysis model to executable code. For instance, the pattern facility of IBM Rational XDE supports this type of multi-transformation development. Alternatively, a tool (such as IBM Rational Rose Technical Developer) may transform a model from UML to executable code in a single step.

MDA practitioners recognize that transformations can be applied to abstract descriptions of aspects of a system to add detail, make the description more concrete, or convert between representations. Distinguishing among different kinds of models allows us to think of software and system development as a series of refinements between different model representations. These models and their refinements are a critical part of the development methodology for situations that include refinements between models representing different aspects of the system, addition of further details to a model, or conversion between different kinds of models.

Three ideas are important here with regard to the abstract nature of a model and the detailed implementation it represents:

● Model classification. We can classify software and system models in terms of how explicitly they represent aspects of the platforms being targeted. In all software and system development there are important constraints implied by the choice of languages, hardware, network topology, communications protocols and infrastructure, and so on. Each of these can be considered elements of a solution “platform.” An MDA approach helps us to focus on what is essential to the business aspects of a solution being designed, separate from the details of that “platform.”

● Platform independence. The notion of a “platform” is rather complex and highly context dependent. For example, in some situations the platform may be the operating system and associated utilities; in some situations it may be a technology infrastructure represented by a well-defined programming model such as J2EE or .Net; in other situations it is a particular instance of a hardware topology. In any case, it is more


important to think in terms of what models at different levels of abstraction are used for what different purposes, rather than to be distracted with defining the “platform.”

● Model transformation and refinement. By thinking of software and system development as a set of model refinements, the transformations between models become first class elements of the development process. This is important because a great deal of work takes places in defining these transformations, often requiring specialized knowledge of the business domain, the technologies being used for implementation, or both. We can improve the efficiency and quality of systems by capturing these transformations explicitly and reusing them consistently across solutions. If the different abstract models are well-defined, we can use standard transformations. For example, between design models expressed in UML and implementations in J2EE, we can, in many cases, use well-understood UML-to-J2EE transformation patterns that can be consistently applied, validated, and automated.

Underlying these model representations, and supporting the transformations, is a set of metamodels. The ability to analyze, automate, and transform models requires a clear, unambiguous way to describe the semantics of the models. Hence, the models intrinsic to a modeling approach must themselves be described in a model, which we call a metamodel. For example, the standard semantics and notation of the UML are described in metamodels that tool vendors use for implementing the UML in a standard way. The UML metamodel describes in precise detail the meaning of a class, an attribute, and the relationships between these two concepts.

The OMG recognizes the importance of metamodels and formal semantics for modeling, and it has defined a set of metamodeling levels as well as a standard language for expressing metamodels: the Meta Object Facility (MOF). A metamodel uses MOF to formally define the abstract syntax of a set of modeling constructs.

The models and the transformations between them will be specified using open standards. As an industry consortium, the OMG has championed a number of important industry standards for specifying systems and their interconnections. Through standards such as CORBA, IIOP, UML, and CWM, the software industry can achieve a level of system interoperability that was previously impossible, Furthermore, tool interchange standards such as MOF and XMI foster tool interoperation as well.

A simple exampleFigure 3 shows a simplified example of a platform independent model (PIM) and its transformation into three different platform-specific models (PSM).


Figure 3: A simplified example of PIM to PSM transformation

The simple PIM in Figure 3 represents a Customer and Account. At this level of abstraction, the model describes important characteristics of the domain in terms of classes and their attributes, but does not describe any platform-specific choices about which technologies will be used to represent them. Figure 3 illustrates three specific mappings, or transformations, defined to create the PSMs, together with the standards used to express these mappings. For example, one approach is to export the PSM expressed in UML into XMI format, using standard definitions expressed as either XML Schema Definitions (XSD) or Document Type Definitions (DTD). This can then be used as input to a code generation tool that produces interface definitions in Java for each of the classes defined in the UML.

Usually, a set of rules is built into the code generation tool to perform the transformation. However, the code generation tool often allows those rules to be specifically defined as templates in a scripting language.11

MDA theory in a nutshellFollowing a long history of the use of models to represent key ideas in both problem and solution domains, MDA provides a conceptual framework for using models and applying transformations between them as part of a controlled, efficient software development process. Here are the basic assumptions and parameters governing MDA usage today:

● Models help people understand and communicate complex ideas.● Many different kinds of elements can be modeled, depending on the context. These offer different views of

the world that must ultimately be reconciled. ● We see commonality at all levels of these models – in both the problems being analyzed and the proposed


solutions. ● Applying the ideas of different kinds of models and transforming them between representations provides a

well-defined style of development, enabling the identification and reuse of common approaches. ● In what it calls “model driven architecture,” the OMG has provided a conceptual framework and a set of

standards to express models, model relationships, and model-to-model transformations. ● Tools and technologies can help to realize this approach, and make it practical and efficient to apply.

IBM and MDAThat IBM has a long heritage of support for modeling, model driven development, and MDA is evident in many areas across IBM technologies and services (e.g., in business modeling, data modeling, deployment modeling, and so on). Here we will concentrate on the IBM Rational solutions in which modeling is used primarily to drive the design and implementation of enterprise-scale, software-intensive systems.

For more than a decade, IBM Rational tools have emphasized the importance of models as a way of raising the level of abstraction at which software practitioners understand and build software solutions. Over the past few years, the software development industry has increasingly realized the value of ever-higher levels of abstraction—from code descriptions at the level of machine language to the emergence of MDA itself—as shown in Figure 4.

Figure 4: The increasing levels of abstraction for software practitioners

We have seen a number of fundamental shifts in the way software practitioners perceive software-intensive solutions. These moves have changed the mindset of the vast majority of software engineers. Formerly, they concerned themselves with the low-level details of manipulating bits of data and moving bytes between registers in the CPU; now, increasingly they spend a majority of their time understanding the users’ problem domain in terms of use cases to be supported, and designing solutions that they conceptualize as collaborations of services offering behavior to realize those use cases. This profound shift in thinking has only been possible because it has been supported by effective tools that allow the new concepts to be clearly expressed and shared.

Essential to this change, of course, was the UML. It provided a single set of common concepts that became widely used across the software industry, which soon ended the lengthy debate over which set of concepts to use when designing software systems. IBM Rational’s leading role in defining the UML is widely acknowledged, as is the pre-eminence of the IBM Rational Rose product in implementing UML to support the architecting of large-


scale software systems. The same principles have been applied in IBM Rational Rose XDE, which combines a rich modeling environment with a code-oriented tool set to create a comprehensive practitioner desktop for creating solutions in a variety of architectural styles, and targeted at specific runtime infrastructures.

This rich heritage of modeling support has continued at IBM, which, through its visual modeling and development tools, supports MDA as defined by the OMG today, and is committed to supporting MDA as it evolves over time.

An IBM view of MDAIBM strongly believes that organizations are well-served by creating models of the problem domain and solution domain, and by coordinating these models throughout the life of a software project. Because IBM has been a strong proponent of such model-driven approaches to software development, and model-driven development forms a key component of the best practices and tools available from IBM, today a wide range of IBM customers employ these technologies to great effect.12

IBM recognizes MDA as an emerging set of standards and technologies focused on a particular style of software development—one that prescribes certain kinds of models to be used, how these models may be prepared, and the relationships among the different kinds of models. MDA provides an approach for, and enables tools to be provided for:

● Specifying a system independently of the platform that supports it.● Specifying platforms.● Choosing a particular platform for the system being developed.● Transforming the system specification into one for a particular platform.

In general, IBM believes that two categories of software development tools provide strong support for MDA:

● Tools that offer a high degree of automation in model definitions and transformations, typically targeted to specific application domains for which complex transformation rules appropriate to that domain can be pre-defined.

● Tools designed for a more general purpose, but which can be configured to support MDA via end-user and third-party tool vendor extensions and customizations, typically targeted to a broader range of application domains.

IBM Rational offers products in both of these categories.13 In the first category, IBM Rational Rose Technical Developer provides highly automated model transformation and robust code generation capabilities—capabilities particularly important to developers of embedded systems and other technical software products. Similarly, IBM Rational Rapid Developer provides a highly automated implementation of MDA targeted to J2EE applications that integrate and extend existing legacy systems. In the second category, IBM Rational Rose XDE Developer offers a combination of patterns capabilities, code templates, and application

8 Many other important lifecycle artifacts also benefit from a model driven approach (e.g., requirements lists, test cases, and build scripts). For simplicity we concentrate on the primary development artifact – the code.

program interfaces that allow developers and third-party tool vendors to custom-develop their implementation of MDA for more general domain applicability.


IBM leadership for MDAAnother important aspect of IBM’s support for MDA can be seen in the leadership position that IBM plays in many of the key MDA standards. IBM has consistently provided strong support for the OMG in terms of:

● Specific standards largely derived from IBM technologies. The key example, of course, is UML, as it was based on the work of IBM Rational—formerly Rational Software—which was acquired by IBM in 2003. However, IBM Rational has also had a major influence on other standards such as the Meta Object Facility (MOF), the Query, View, and Transformation (QVT) standards, and the emerging Reusable Asset Specification (RAS) work.

● Personal commitments from IBM Rational to drive MDA standards. IBM Rational personnel occupy key positions on the OMG Architecture Board, on standards task forces, and in the teams developing solutions. IBM Rational is committed to continuing this deep involvement in MDA standards, and to ensuring that those standards are practical and effectively implemented in IBM Rational tools.

SummaryMDA is a work in progress; the very definition of MDA is evolving. In the narrowest sense, it is about different abstract models of a system, and well-defined model transformations among them. In a more general sense, it is about models at varying levels of abstraction that serve as the basis for software architectures that are ultimately realized through various implementation technologies. At this time, MDA is interpreted very broadly, and many organizations (some of whose tools have been mentioned in this article) claim "support for,” or “conformance to,” MDA in their diverse solutions.

We have taken this opportunity to characterize the IBM Rational view of MDA and how our tools support MDA as it is defined today by the OMG. Fundamentally, our visual modeling and development tools support MDA today in two key ways: 1) by offering a high degree of automation in specific solution domains, and 2) by providing general-purpose capabilities that allow organizations readily to construct customized, model driven approaches for their own specific domain. We are also firmly committed to supporting MDA as it evolves over time.

IBM recognizes MDA as an emerging set of standards and technologies focused on a particular style of software development – one that emphasizes the advantages of modeling at various levels of abstraction and, most important, the integration and flow of information through these models. This approach allows software developers to contribute to a project through the types of models that best match the kinds of information and decisions they make. It also allows senior project members to maximize their effectiveness through their definition and implementations of model-to-model transformations. System analysts, testers, and quality assurance staff can leverage models to analyze the system and its performance before the system is complete.

IBM is actively working with select clients today to improve MDA practice. Those experiences will drive the way we support MDA as it evolves over time.

AcknowledgmentsThe ideas discussed in this article reflect the thinking of a broad team at IBM, including Jim Amsden, Grady Booch, Gary Cernosek, Magnus Christerson, Jim Conallen, Luan Doan-Minh, Pete Eeles, John Hogg, Sridhar Iyengar, Simon Johnston, Grant Larsen, Martin Nally, Jim Rumbaugh, Bran Selic, and Dave Tropeano.


Further readingFor those interested in learning more about applying MDA in practice, there are three primary sources:

● OMG materials. The OMG is the primary source for learning about many MDA ideas (see http://www.omg.org/mda). Currently, its offerings tend to be either detailed specifications aimed at technologists implementing those specifications or high-level whitepapers and presentations that position the MDA approach for non-practitioners and provide overviews of concepts and standards. Unfortunately, there is little material to fill the space between these two extremes for those who want to understand more about MDA in the context of current development approaches, and how MDA can be applied in practice. Also see "References" below.

● Books and papers. Recognizing the gaps in OMG materials, a number of experts have written books and papers on MDA that are now appearing in print. The two primary texts are: Kleppe et al., MDA Explained: The Model Driven Architecture Practice and Promise (Addison Wesley, 2003) and D. Frankel, Model Driven Architecture: Applying MDA to Enterprise Computing (Wiley Press, 2003). At this writing, a third book is on the way: S. Mellor et al., MDA Distilled (to be published by Addison Wesley, 2004). Another group of books offers useful perspectives on key MDA technologies, such as executable UML and the Object Constraint Language (OCL). These works include S. Mellor et al., Executable UML: A Foundation for MDA (Addison Wesley, 2003) and J. Warmer and A. Kleppe, The Object Constraint Language: Getting Your Models Ready for MDA, second edition (Addison Wesley, 2003). Both classes of books offer perspectives on the key OMG standards and their relationships, supported with limited insights into MDA in practice. Also see "References" below.

● Broader industry and academic materials. As the MDA approach gains support, a number of materials are becoming available that address its practical application, strengths, and limitations. Currently, this material is very variable in focus, depth, and quality. The OMG maintains a small library of MDA papers (www.omg.org/mda/presentations.htm) that offers a good starting point. A wider search with a Web search engine will provide many more pointers.

ReferencesT. Sloan, “Business Model Collaborations: Pushing Software Revolution.” Software Magazine, September 2003: www.softwaremag.com

A. Kleppe, J. Warmer, and W. Bast, MDA Explained: The Model Driven Architecture Practice and Promise. Addison Wesley, 2003.

D. Frankel, Model Driven Architecture: Applying MDA to Enterprise Computing. Wiley Press, 2003.

Richard Soley and OMG Staff Strategy Group, “Model Driven Architecture.” November 2000.

P. Harman, “MDA: An Idea Whose Time Has Come.” Cutter Consortium, 2003.

B. Selic, “The Pragmatics of Model-Driven Development,” IEEE Software, Vol. 20, #5, September 2003.

T. Gardner, C. Griffin, J. Koehler, and R. Hauser, “A review of OMG MOF 2.0 Query/View/Transformation Submissions and Recommendations Towards the Final Standard.“ IBM Whitepaper submitted to the OMG, September 17, 2003.


D.K. Barry, Web Services and Service Oriented Architectures. Morgan Kaufman, 2003.

P. Clements and L. Northrop, Software Product Lines: Practices and Patterns. Addison Wesley, 2001.

A. Thomas Manes, Web Services: A Manager’s Guide. Addison Wesley, 2003.

S. Mellor et al., MDA Distilled. Forthcoming from Addison Wesley, 2004.

S. Mellor et al., Executable UML: A Foundation for MDA. Addison Wesley, 2003.

J. Warmer and A. Kleppe, The Object Constraint Language: Getting Your Models Ready for MDA, second edition. Addison Wesley, 2003.

J. Daniels, “Modeling with a Sense of Purpose.” IEEE Software, pp8-10, Jan/Feb 2002.

Notes1 Model Driven Architecture (MDA) is a Registered Trade Mark of the Object Management Group.

2 There are a number of sources of help for those interested in learning more about applying MDA in practice. The “Further reading” section at the end of this article offers a useful starting point.

3 D.K. Barry, Web Services and Service Oriented Architectures. Morgan Kaufman, 2003.

4 P. Clements and L. Northrop, Software Product Lines: Practices and Patterns. Addison Wesley, 2001.

5 In this context a conceptual framework is a set of key concepts and structures that guides the planning, understanding, and realization of an enterprise solution.

6 Richard Soley and OMG Staff Strategy Group, “Model Driven Architecture,” November 2000.

7 Figure 1 is based on a diagram originally used by John Daniels.

8 Many other important lifecycle artifacts also benefit from a model driven approach (e.g., requirements lists, test cases, and build scripts). For simplicity we concentrate on the primary development artifact – the code.

9 For this discussion we shall ignore the fact that the code is itself a realization of a programming model that abstracts the developer from the underlying machine code for manipulating individual bits in memory, registers, etc.

10 In some cases much more than code stubs can be generated, depending on the fidelity of the models.

11 More detailed examples of this will be described in subsequent parts of this series. However, you may wish to take a look at examples of MDA in action in commercial tools such as IBM Rational Rose Technical Developer and Rapid Developer products (http://www.ibm.com/rational), or open source MDA tools applying this approach (e.g., AndroMDA (http://www.andromda.org) and Jamda (http://jamda.sourceforge.net)).


12 See, for example, http://www.rational.com/success and do a search using the keywords “model driven.”

13 Detailed examples of the use of IBM Rational tools to create MDA solutions will be provided in subsequent parts of this series. Here we offer a broad overview of IBM Rational tool support for MDA.

What do you think of this document?

Killer! (5) Good stuff (4) So-so; not bad (3) Needs work (2) Lame! (1)

Comments?


Search help

Ensuring success with IBM Rational’s system integrator partners

Contents:

About the author

Rate this article



Tom McBrideIBM30 0 2004

Imagine you’re an insurance company looking to provide a new Internet service to your clients. Where do you start? How do you ensure that your business requirements drive the software and technology needed to build the right system? Does your IT staff have the right skills to do the software development work? How do you minimize costs yet maximum results? These are among the issues that clients typically face when considering a new business system.

If you are reluctant to build such a system yourself, then you should consider getting help from an IBM Rational partner who is in the business of building new business systems — that is, a system integrator, or SI. These partners of ours have the proven people, industry knowledge, and skills to build business systems. In fact, they may already have built a system similar to the one you need, which can put you months ahead when you begin your project.

What role does IBM Rational play when you work with one of our system integrators? From beginning to end, we’re a full partner in the project. For more than twenty years, Rational Software, now part of IBM Software Group, has been committed to ensuring the success of clients (including many system integrators!) who depend on developing and deploying software. We have done this by providing a software development platform, an iterative process, and a variety of services that reduce project risk, help manage the impact of change, and improve application quality. Together, our software and services have helped us build strong relationships with a wide spectrum of clients in many industries. To complete the picture, we work closely with IBM Rational system integrator partners who can add the following strategic capabilities:

● Offer a complete business solution, from consulting to deployment.● Leverage years of proven performance in software development methodology, development, and

deployment.● Provide specific industry expertise.● Provide technology built with open standards, deep technical and deployment experience, and skills

transfer and training to IBM clients.● Provide low-cost development options, including onsite, offsite, and offshore development. ● Maintain a staff of IBM Rational skilled and certified consultants.

© Copyright IBM Corporation 2004. All rights reserved. http://www-106.ibm.com/developerworks/rational/library/2825.html

Ensuring success with IBM Rational’s system integrator partners

In coming months, The Rational Edge will feature articles contributed by IBM Rational system integrator partners. Presenting successful, working models of the three-way interaction among IBM Rational, SI partners, and clients these articles will help you imagine new, effective ways to use IBM Rational and SIs in your software development projects. Some will demonstrate how a system integrator used IBM Rational tools or methodologies to successfully solve complex business problems for a client. Others, like this month’s introductory article, will show how IBM Rational and an SI partner collaborated to create a new system, product, or service.

If you have questions about our IBM Rational system integrator partner program in general, or about a particular partner, please contact me at: [email protected] or 936-273-6822.

I promise to help you get the skills, products, and expertise you need, at any level, to make your next software development project a success.

About the authorTom McBride joined IBM in 2003 with the merger of Rational Software into the IBM Software Group. For the Rational Brand, his current role is to lead the Rational team responsible for managing the Strategic Alliances with Global and Major Systems Integrators worldwide with the primary focus being software engineering and development, which manifests itself in software development best practices, the Rational Unified Process (RUP), and a Software Development Platform (SDP) product

set. With Rational Software, Mr. McBride held a number of management positions focused on developing the Rational Field organization and working with Customers. Starting in April, 2001 and leading up to the merger, he was responsible for managing the Strategic Alliance with IBM, including IBM Global Services. Prior to joining Rational Software in 1991, he had a long career with Control Data Corporation. He now resides with his family in The Woodlands Texas and enjoys travel and photography.



Comments?


Search help

CSC and IBM Rational join to deliver C-RUP and support rapid business change

Contents:Structural similarities, complementary content

Overview of CSC Catalyst

Overview of RUP

C-RUP: Integrating two methodologies into one

Blueprint for success: A collaborative roadmap for integrating and deploying business change and IT methodology

Summary: Business change and methodology integration

Notes

About the authors

Rate this article



David Jones, CSCStosh Misiaszek, IBM

5 January 2004

from The Rational Edge: The first in a series of articles contributed by IBM Rational systems integrator partners, this article examines an integration of two methodolgoies: CSC’s Catalyst and IBM Rational’s Rational Unified Process, or RUP. The result? C-RUP.

As business change accelerates at an unprecedented pace, globalization, coupled with a hyper-competitive business climate in industrialized nations, has intensified the dependency between business success and information technology. Companies and institutions typically look to their IT organizations to deliver solutions more quickly and efficiently to customers and stakeholders. Yet most IT organizations continue to deploy software development methods and approaches suitable for smaller, specialized IT solutions, perhaps prefaced by a few business analysis activities.

IT organizations often have a multitude of technologies and software development methods available from software vendors, service providers, or internal sources. However, they seldom unite these resources effectively to pursue concurrent IT and business changes. For example, a large, traditional enterprise may think that creating an online ordering system is critical to satisfying customer demands for a constantly evolving product line and sustaining competitive market advantage. But establishing a blueprint for both business change and system development



requires a single, overarching methodology — not several. And, unfortunately, most IT organizations have neither the time nor the expertise to integrate multiple methodology frameworks.

To help these organizations, CSC (Computer Sciences Corporation) teamed up with IBM Rational to combine their two well-known process frameworks into a single methodology called "C-RUP." C-RUP is based on CSC Catalyst and IBM Rational Unified Process,® both of which are well-suited for integration projects. Both are mature, field tested, and self-contained methodologies. Each addresses particular aspects of large-scale projects encompassing both business change and IT development. And both have the flexibility, modifiability, and agility to accommodate the inevitable additions and changes that result from evolving business and IT requirements.

In this article, we will outline the purpose and architecture of C-RUP, describe the collaborative effort that produced this hybrid methodology, and provide a roadmap for others who might want to pursue a similar path.

Structural similarities, complementary contentBoth CSC Catalyst and RUP are based on well-defined foundational principles, industry best practices, and the extensive experience of their respective consulting organizations. Both are engineered and continually enhanced by harvesting best practices from field experts and artifacts, and then fusing these with industry knowledge.

The CSC Catalyst and RUP frameworks have a natural synergy because of their structural similarities and complementary content. Their similar foundational object-model structures — encompassing lifecycle phases, artifacts (work products), processes, and roles — enables them to be joined together. However, the scope, perspective, and content of the two methodologies are different. Catalyst takes a broad, high-level view of business change that ultimately drives the system solution; it provides a holistic framework for the change initiative. In contrast, RUP focuses mainly on the immediate business context for the solution to be developed.

CSC's corporate methodology team and IBM Rational collaborated to build and deploy a methodology framework that unified these two approaches, within an accelerated timeframe. Before we describe the principles and processes that guided this effort, let's take a brief look at each of the methodologies.

Overview of CSC Catalyst CSC Catalyst is a global methodology for delivering business and IT services and solutions. It provides the common framework, language, and processes through which CSC practitioners in various disciplines, industries, and geographies help clients realize business change via integrated solutions and services. Originally, the methodology focused on system integration projects within the systems development lifecycle; then it evolved to address business process reengineering and larger scale, business-driven initiatives. The CSC Catalyst lifecycle provided processes in all domains involved in business change: process, organization, location, data, application, and technology.

Over time, however, CSC Catalyst began to incorporate best practices gleaned from CSC divisions serving clients in large government sectors: civil, defense, and aerospace. This brought enterprise architecture, solution engineering, and program-level governance capabilities to CSC Catalyst. At the same time, the increasingly global nature of CSC clients and the trend toward outsourcing of business, application, and technology services generated greater capability for process repeatability, standardization, and integration — in both industry clients' operating environments and CSC's own delivery capability. With its integration into CSC's global knowledge environment, CSC Catalyst became the unifying, global language for delivering both client and internal initiatives.

The scope of the CSC Catalyst methodology encompasses both lifecycle and management concerns, as illustrated


in Figure 1.

Figure 1: Scope of CSC Catalyst.

CSC Catalyst1 reflects and guides how CSC professionals deliver services and solutions. They combine processes within the lifecycle framework to form client engagement initiatives, as depicted in Figure 2.


Figure 2: CSC Catalyst-based initiatives

Overview of RUP IBM Rational Unified Process, or RUP, is a Web-enabled software engineering process that enhances team productivity and delivers software best practices to all team members. These best practices have been culled from over twenty years of collaboration between IBM Rational and its customers, and they represent a mature approach to software engineering:

● Develop software iteratively ● Manage requirements ● Use component-based architectures ● Model visually ● Continuously verify software quality ● Manage changes to software

Organized into a series of four project phases — Inception, Elaboration, Construction, and Transition — RUP2 guides project teams through an iterative approach to software development. Based on the six best practices listed above, the iterative approach allows development teams to add functionality to working software in increments. They tackle the most difficult, high-risk aspects of the project first, and trace essential system requirements through each iteration of the software. The four RUP phases and their associated workflows are illustrated in Figure 3.


Figure 3: RUP phases, with associated workflows and example iterations

C-RUP: Integrating two methodologies into oneC-RUP, a framework for integrating CSC Catalyst and RUP, is available to CSC practitioners via a CSC Catalyst Plug-In to the RUP environment, with hyperlinks to CSC Catalyst's Toolkit environment. Conceptually, C-RUP extends RUP's object-oriented custom development capabilities into a larger business process framework, through which CSC professionals drive service and solution engagements.

Although CSC Catalyst includes a variety of paths for process enablement and development, Rational Unified Process upgrades Catalyst's object-oriented development space with its industry-recognized best practices. Furthermore, IBM Rational products are popular in many of CSC's largest accounts, which use CSC Catalyst as their overarching, business change methodology. In the past, CSC engagement teams often looked for ways to bring Catalyst and RUP together on a project level, but they could never justify the considerable engineering effort required.

Now, with the collaboration of IBM Rational, CSC has brought these technologies together in C-RUP. With C-RUP, RUP can integrate smoothly as a development path within the CSC Catalyst framework. Starting with CSC Catalyst's Architecture phase, as shown in Figure 4, RUP is positioned as a development path for OO custom application development; it includes "touch points" to various CSC Catalyst lifecycle specialty area processes (e.g., Organizational Change) and management area processes (e.g., Project Management).


Figure 4: C-RUP incorporates RUP as a development path within CSC Catalyst, including methodology process interfaces

However, integrating methodologies for successful field use is not as simple as putting some experts in a room for a few months and telling them to combine a prevailing base methodology with RUP software. In fact, combining these two methodologies effectively required a well-planned, disciplined, and coordinated series of workstreams, frequently operating in parallel. The following story of how we produced the C-RUP methodology highlights the essential activities in this effort.

Stage one: Establishing the concept and collaboration

The opportunity to create C-RUP emerged as the result of several business drivers. First, during its planning, the CSC Catalyst Group launched an internal initiative to engineer a knowledge-based asset that would complement and augment CSC Catalyst in areas of significant benefit to field engagement teams.

Although the group maintained relationships with multiple vendors who support elements of CSC Catalyst, such as its process design tools, IBM Rational quickly emerged as the ideal candidate for supporting a methodology augmentation. RUP methodology had principles and a structure similar to those of CSC Catalyst, excellent industry penetration, an object-oriented platform, and complementary capabilities for OO-based work.

The CSC Catalyst team then conducted an internal inquiry to assess how CSC was using IBM Rational products around the globe as well as IBM Rational's capabilities. This confirmed the team's choice for several reasons:

● Many large CSC accounts were already using IBM Rational tools successfully, and CSC practitioners


wanted to understand how to use them with CSC Catalyst's strengths in business change and project governance.

● IBM Rational could help upgrade the development portions of CSC Catalyst by incorporating RUP's leading-edge, object-oriented best practices for custom applications.

● IBM Rational could augment CSC Catalyst's capabilities with automated tools and reusable templates. ● RUP supported the UML standard for modeling, as did CSC Catalyst.

When the CSC Catalyst Group contacted IBM Rational, the collaborative relationship developed quickly, and the team soon realized that any methodology implementation, whether customized or not, involves much more than purchasing copies of the product and providing a list of recommended training courses. Especially in globally distributed organizations, a successful implementation requires careful management of the customizations (if any), as well as a comprehensive rollout program to educate end-users and project managers about how to use and benefit from the unified methodology. Rolling out even a simple change within an integrated methodology is not trivial on a global scale. The integration effort needs to be carefully planned and coordinated so that changes can be kept to a minimum. The implementation should also be designed for easy maintenance and upgrades when there are new releases of either methodology.

Originally, the CSC Catalyst/IBM Rational knowledge asset was conceived as an online manual explaining the relationships among CSC Catalyst, IBM Rational tools, and RUP, and how to leverage them all on a CSC engagement. Soon, however, this concept evolved into the notion of an "integrated methodology product" that would allow CSC practitioners to navigate electronically through a single object-oriented methodology environment. Envisioning an integrated product that CSC professionals could easily apply to the planning and execution of client engagements, the team focused on a set of known business and technical priorities to effectively evolve C-RUP. As shown in Table 1, they analyzed these high-level requirements across the CSC Catalyst Domains of Change to identify areas where C-RUP would have an important impact.

Table 1: Analysis of high-level requirements and impact of C-RUP on CSC Catalyst Domains of Change


Stage two: Knowledge transfer

After open discussions between CSC and IBM Rational about deployment and support issues, the IBM Rational team proposed an accelerated six-month certification and qualification program in Rational products and disciplines. This would be delivered to a specified number of CSC practitioners through both online and instructor-led courses. CSC initiated a global query and evaluation of more than 100 interested CSC practitioners across all major continents, and selected fifty of them to undertake the pilot program.

An internal workshop provided initial knowledge on how RUP Organizer, RUP Builder, IBM Rational Rose XDE Developer, and other tools could be used to develop the C-RUP Plug-in and Practice Guide. The latter would explain the use of C-RUP, the integration between CSC Catalyst and RUP, and the requirements for setting up a C-RUP project.

Phase three: Architecture and development

Based on their experience with the IBM Rational tools in the workshop, the team agreed that a "thin plug-in" approach using RUP Organizer and RUP Builder would be the most advantageous. The thin plug-in's modifiability would position the CSC Catalyst Group staff to provide timely and efficient maintenance and updates of C-RUP in the future.


Creating the C-RUP solution began in earnest with mapping the CSC Catalyst architecture to the RUP architecture — identifying all the touch points, overlaps, and gaps in hundreds of objects: artifacts, activities, and processes. A team of CSC subject matter experts (SMEs) helped analyze the methodology bridging requirements, then designed and developed the solution elements of the C-RUP Plug-In and an accompanying Practice Guide. The team then began to identify and build the Plug-In's "guidance components," which would advise C-RUP practitioners on how to link and apply CSC Catalyst elements to particular components in RUP, and to transition from CSC Catalyst to RUP and vice-versa.

Using the virtual environment of IBM Lotus Notes SameTime, the C-RUP development team showcased a prototype of the C-RUP Plug-In design to a group of practitioners experienced in both CSC Catalyst and RUP. This led to refinements of the solution architecture, including the format and navigation for the guidance component, and sharing of successive prototypes with other internal CSC experts.

Figure 5 depicts the global, virtual approach the C-RUP Team used to create C-RUP:

Figure 5: The C-RUP virtual operating model: coordinated workstreams

As Figure 5 shows, the C-RUP initiative was planned and coordinated from a CSC office near Philadelphia, PA. With input from CSC Subject Matter Experts (SMEs) from Sydney, Australia, who helped to define the architecture and develop content, the C-RUP Plug-In software was engineered at a CSC office in Waltham, MA. Other CSC SME's and reviewers participated remotely from a variety of time zones and locations.

IBM Rational experts provided key RUP knowledge and technical support from a variety of international locations. In addition, the CSC IBM Rational SME program leveraged a Rational licensing arrangement with CSC's Consulting division to create a global support network for C-RUP.

Knowledge management also played an important role in the globally distributed model. CSC's knowledge portal served as a centralized repository for sharing C-RUP knowledge and evolving the solution, providing configuration


management and deployment support as well. The portal was also used to collect CSC-produced field collateral early on, and then best practices and lessons learned from using RUP with CSC Catalyst.

At the time of this publication, the C-RUP team is finalizing the solution design and development activities, with feedback from user testing and reviews.

Critical success factors: Deployment, training, and user support

As the CSC and IBM Rational members of the C-RUP team realized, creating and adapting a business change methodology for an organization can be a purely academic exercise if the methodology is not implemented effectively. To be successful, a rollout must be accompanied by an educational program that reaches a high percentage of the target end users and provides sufficient background for people to understand the methodology and its components.

The IBM/CSC collaboration uncovered some significant challenges that a training program would have to address:

● The trainees are globally distributed and billable. A multi-day training event in one location was not feasible.

● The training program would have to be flexible, and self-paced, which meant that achieving full participation and follow-through from students would be more challenging than in a traditional classroom setting. We would have to devise some incentive to ensure successful completion by all.

● The program required active participation and management by both IBM Rational and CSC, so it had to be structured to make co-management possible.

● Since RUP addresses everything from requirements definition to design, coding, and quality assurance, and since each of these areas is supported by a specific IBM Rational tool or toolset, the CSC/IBM team was concerned that field support staff might become too specialized in narrow areas of concern (e.g., a OO/UML expert might not learn about change management).

This last consideration gave rise to the Subject Matter Expert (SME) program, which combines the use of Web Based Training (WBT) with courses at IBM education facilities worldwide for maximum flexibility. Participants were presented with two options for each subject track: one led to "qualification" in the chosen subject area, a designation meaningful only within the CSC organization; the other option led to "certification" in the subject area, which is an industry-wide designation.

IBM Rational provided the training resources and materials to complete the course. CSC provided a pool of candidates from which the company chose carefully to achieve its objectives of global distribution and full representation across all subject areas. CSC also took responsibility to manage training licenses and other assets related to the program, while IBM provided the assets themselves and the back office infrastructure.

Finally, a feedback loop was incorporated into the training program. This has been essential for fine-tuning the program as well as for developing new versions of it that will serve CSC's needs as C-RUP is rolled out to an even wider community.

Participation in the program has been excellent. Clearly, the benefits of training and certification for each program participant, tailored to their work needs, and the cooperative approach to managing the program, were key factors in determining the high level of acceptance and participation in this program.


Blueprint for success: A collaborative roadmap for integrating and deploying business change and IT methodologyBased on the C-RUP lessons learned, the best approach to methodology integration combines the planning and execution of workstreams to meet key milestones.

Workstreams

Workstreams employed in the C-RUP initiative are represented in Figure 6. Note that the times shown in this chart are based on empirical data derived from the collaborative effort described above. Times for other projects may vary considerably.

Figure 6: C-RUP initiative project workstreams

Project management

The project management workstream results in a high-level project plan with milestones, deliverables, roles, and timeframes for the key workstreams represented in Figure 6. It encompasses securing sponsorship and stakeholder buy-in and any funding necessary to complete the project. The foundation for the alignment should be established within the first month, although it may take another month to achieve full alignment as key stakeholders are brought on board.

The project manager creates a first iteration project plan and arranges the resources for the methodology integration project, reporting on progress regularly to all stakeholders. The project management discipline is essential for managing and integrating the multiple workstreams, including asset engineering, configuration management, development tool acquisition, implementation, and training.

Envision and evolve concept


This workstream results in an agreement among the methodology initiative planners and architects about which aspects of the methodologies will be integrated to meet the needs of field practitioners on client engagements. The business change methodology should provide a foundation into which the IT methodology will fit, and a vision document should describe how these methods will be integrated. In addition, field practitioner input should be used to define requirements for both the integrated methodology and supporting services that will ensure its effective use. The process — from formulating the concept to establishing a high-level design — should take one or two months near the outset of the initiative.

Establish technical infrastructure and development processes

This workstream results in an updated, detailed project plan that reflects acquisition of the technology development environment, installation, development, and the education requirements by development team role and effort required. Additional effort may include migrating content from one format to the desired end format, adding new process content and documentation, and manipulating the underlying technology of the methodologies themselves. The process — from specifying technology requirements to team process and tool training — should take from two to three months early in the initiative.

Define methodology architecture

This workstream results in analysis of the gaps between two methodologies, generating content requirements practitioners will use to apply the integrated methodology. These requirements will cover the conceptual framework from which the end user will understand and apply the integrated methodology, and the type, source, focus, and organization of the knowledge needed to address gaps at each of the methodology touchpoints, or interfaces. Cross-mapping the methodologies will play a vital role here, and that work can be extensive, depending on the breadth and depth of the methodologies you're combining. Subject matter experts with in-depth knowledge in both methodologies must be involved. The complete analysis may take from three to four months, and should evolve in parallel with the "develop solution components and content" workstream.

Design solution

This workstream results in a "meta-architecture" — a blueprint of the components and interfaces to drive their development. This includes the format for the components inserted in the methodology environment, as well as the hyperlinks within the base methodology environment and between both methodologies if they are in electronic form. It is helpful to review the data/object architectures of the methodologies.

This activity may take from three to four months, and will evolve in parallel with the "define methodology architecture" workstream.

Develop solution components and content

This workstream results in a completed set of content components embedded within (and across) the methodology environments, with hyperlinks in place. Components are developed iteratively by the SMEs in the designated component template formats, and a technical editor reviews them. Development includes providing user instructions for launching and using the integrated methodology environment. Components and links must be tested in a non-production environment. This activity may take from four to five months, and will evolve in parallel with the "design solution" workstream.


Conduct user reviews

This workstream results in a series of iterative prototypes for each major component of the integrated methodology solution that has been deployed and field tested. SMEs, who represent the users of the combined methodology, provide critical feedback about the integrated methodology framework, navigation, knowledge organization, and content. The process — from establishing a proof-of-concept prototype to realizing a fully functional solution — may take three to four months.

Communications, deployment, and user support

This workstream results in a deployment strategy, course content, delivery mechanism, and schedule, including identifying and training key participants. This process should start early in the initiative and be launched simultaneously with the integration methodology solution. It should span the lifecycle of the project and then continue after deployment, to provide support.

Content management and release management

This workstream results in a set of procedures for managing the iterative development of content and changes to future releases of the integrated methodology. It begins after the set-up of the technical environment that houses the evolving asset configuration components, as well as the methodology architecture definition. This definition specifies how the data for the solution will be defined, controlled, and evolved as data objects. This activity should begin and evolve in parallel with the "design solution" workstream. It should continue indefinitely beyond the initial release to sustain and refresh the integrated methodology product.

Summary: Business change and methodology integration Accelerating business change is a fact of life for today's global commercial and institutional entities. Many larger organizations have made considerable investments in both business and software development methodologies, but few have integrated them successfully. Often, attempts at doing so amount to "bolting on" a few process design techniques to an IT methodology, or vice versa. Unfortunately, this creates more extra work than value.

To support business change, what is needed is a comprehensive business change methodology that incorporates leading IT solution development methods. Integrating two richly featured methodologies is not easy to do, but CSC and IBM Rational have proved that it can be done. Following the processes presented in this article, they took the best of CSC Catalyst and IBM Rational Unified Process to create C-RUP. This integrated methodology has already been tested and used successfully by field professionals at CSC.

Notes 1 For more information on CSC Catalyst, see http://www.csc.com/solutions/knowledgemanagement/mds/mds122/index.shtml

2 For more information on IBM Rational Unified Process, see the resources available at http://www-306.ibm.com/software/awdtools/rup/.


About the authorsDavid J. Jones is a senior methodology and business architect in CSC’s Corporate Knowledge Program. With nineteen years of experience in the IT industry and thirteen years with CSC, he leads initiatives in the design and development of CSC Catalyst — the company’s global methodology for delivering business and IT services and products to clients and internally. As co-leader of the Catalyst Methodology Community, he facilitates the application of company best practices and knowledge management to support business change initiatives in the field. He also provides field support through methodology panels, virtual conferences, and business architecture consulting engagements. Frequently, he publishes articles on company methodology and its role in supporting strategic business objectives at CSC.

Stanley (Stosh) Misiaszek is the alliance manager representing the IBM Rational brand. In his seventh year at IBM, he leads the alliance effort between IBM Rational and CSC. After beginning his career as an assembly language programmer twenty years ago, he spent time developing methodology and delivering training for large corporations, as well as designing and delivering training material for software developers. He holds an MS in computer engineering from Syracuse University.



Comments?


RRD Productivity Case Study [email protected] Copyright © 2003 The Middleware Company Page 1 Of 22

Model Driven Development for J2EE with IBM Rational Rapid Developer (RRD) Productivity Analysis

Based on The Middleware Company Application Server Baseline Specification http://www.middleware-company.com/casestudy/ The Middleware Company Case Study Team November 2003

www.middleware-company.com

The Middleware Company RRD Productivity Case Study [email protected]


Table of Contents

TABLE OF CONTENTS.............................................................................................................................................2 1 EXECUTIVE SUMMARY.................................................................................................................................4 2 INTRODUCTION................................................................................................................................................4

2.1 WHAT IS MODEL-DRIVEN DEVELOPMENT? ..................................................................................................4 2.1.1 What is ARAD?......................................................................................................................................5

2.2 WHAT ARE THE SUPPOSED BENEFITS OF MDD?...........................................................................................5 2.3 RATIONAL RAPID DEVELOPER (RRD) AND ARAD......................................................................................6

2.3.1 Modeling and Code Generation ...........................................................................................................6 2.3.2 Using the Class Model ..........................................................................................................................7 2.3.3 Building the Site Model and Style Models............................................................................................7 2.3.4 Creating Web Pages..............................................................................................................................7 2.3.5 Adding Application Logic .....................................................................................................................8 2.3.6 Setting the Application’s Architecture..................................................................................................8

3 STUDY DESCRIPTION.....................................................................................................................................8 3.1 ABOUT THE SPECIFICATION............................................................................................................................9 3.2 CHOICE OF APPLICATION................................................................................................................................9 3.3 OVERVIEW OF THE RULES ............................................................................................................................10 3.4 OVERVIEW OF TESTING PROCESS.................................................................................................................11 3.5 OVERVIEW OF THE TEAMS............................................................................................................................11 3.6 OVERVIEW OF PROJECT SCHEDULE AND PROJECT MANAGEMENT APPROACH.........................................12

4 STUDY RESULTS .............................................................................................................................................12 4.1 ARCHITECTURAL ANALYSIS .........................................................................................................................12

4.1.1 UML and Code Generation ................................................................................................................12 4.1.2 Overall Shape of the Code ..................................................................................................................13

4.1.2.1 Traditional Team.............................................................................................................................13 4.1.2.2 RRD Team.......................................................................................................................................13

4.1.3 Security.................................................................................................................................................14 4.2 QUALITATIVE RESULTS.................................................................................................................................14

4.2.1 Traditional Team.................................................................................................................................14 4.2.1.1 Traditional Team - Week 1.............................................................................................................14 4.2.1.2 Traditional Team - Week 2.............................................................................................................15 4.2.1.3 Traditional Team - Week 3.............................................................................................................15 4.2.1.4 Traditional Team - Weeks 4 and 5 .................................................................................................15

4.2.2 RRD Team............................................................................................................................................16 4.2.2.1 RRD Team – Early Stages..............................................................................................................16 4.2.2.2 RRD Team – Late Stages ...............................................................................................................16

4.3 QUANTITATIVE RESULTS..............................................................................................................................17 4.4 FACTORS THAT AFFECTED PRODUCTIVITY..................................................................................................17

4.4.1 WYSIWYG Page Design......................................................................................................................17 4.4.2 Binding Pages to Data ........................................................................................................................18

4.4.2.1 Lists in Pages...................................................................................................................................18 4.4.2.2 Passing Objects Between Pages .....................................................................................................18

4.4.3 Default Error Pages ............................................................................................................................18 4.4.4 Source Control.....................................................................................................................................19 4.4.5 Team Organization..............................................................................................................................19

4.5 ADDITIONAL TASKS......................................................................................................................................19 4.5.1 Internationalize a Page .......................................................................................................................20


4.5.2 Add and Use a New Table...................................................................................................................20 4.5.3 Partition the Application.....................................................................................................................20

5 CONCLUSION...................................................................................................................................................21 6 DISCLOSURES..................................................................................................................................................21

6.1 WHY ARE WE DOING THIS STUDY? WHAT IS OUR “AGENDA”?....................................................................22 6.2 DOES A “SPONSORED STUDY” ALWAYS PRODUCE RESULTS FAVORABLE TO THE SPONSOR?.....................22


1 Executive Summary

With the relentless drive toward ever faster creation of J2EE applications, model-driven development has drawn increasing interest. An emerging segment of model-driven tools is a class of tools known as “architected rapid application development” or ARAD.1 These tools are associated with higher abstraction, greater productivity over traditional development and less required J2EE knowledge. Among the various products taking this model-driven, ARAD approach is IBM’s Rational Rapid Developer (RRD). It promises enormous productivity gains for J2EE developers, slashing the time it takes to build server-side applications

In this case study, we test the RRD productivity claims. Two teams developed an identical application – one using RRD, the other a traditional code-centric IDE.

The result of this study is dramatic: The RRD team developed their application 10.7 times faster than the traditional team. The RRD team finished in 47.5 hours, compared to 507.5 hours for the traditional IDE team. In addition, the RRD team completed some typical enhancements to the application with comparable speed.

As a result of this case study, The Middleware Company recommends that development shops interested in increasing their productivity evaluate RRD for use in their projects.

2 Introduction

This whitepaper compares the productivity of two development teams building an identical application, which was tightly specified by a functional specification reviewed by industry experts. The specification is The Middleware Company Application Server Platform Baseline Specification, which is a rigorously specified version of the familiar J2EE PetStore application. One team used IBM’s Rational Rapid Developer (RRD), a tool that takes a model-driven approach to J2EE development. The other team used a traditional, code-centric development approach.

We begin with an overview of model-driven development and the benefits it promises. Next we look at how RRD implements model-driven development, focusing on the key features of RRD that differ from a code-centric IDE. Then we examine the results of our study – the structure and quality of the code produced by both teams, the qualitative experience of the developers, and of course the quantitative results. Finally, we drill deeper to explain how so dramatic a difference could occur.

2.1 What is Model-Driven Development?

A model is simply an abstract representation of some part of an application or system. We may model something as specific as the classes that make up the user interface, something as broad as the distribution of data and functionality across the entire network, or anything in between. And we can build models with any degree of sophistication we choose: from hand-drawn boxes on a whiteboard to complex UML diagrams produced by a modeling tool. 1 For a consise, high-level discussion of ARAD, see Architected RAD Tools Are Delivering Major Benefits, Gartner Research Note T-19-0792, Jan 29, 2003. This note is available at this URL: http://www.viewpointpartners.com/0pdf/Gartner%20Researc%C9e%20ARAD%20-%20IO.pdf


While models have long figured into J2EE development, too often they remain strangely disconnected from the implementation. The model serves as a guide or blueprint, but developers still have to write all the implementation code by hand. As the application evolves, developers often find adherence to the model confining rather than useful. Maintaining the model becomes a chore rather than a help.

Model-driven development (MDD) is a paradigm that connects the model more closely to the implementation. With MDD, the model not only encapsulates the application design, but is used to generate the implementation code. MDD typically consists of four steps:

1. Create a class model. This includes defining data entities and business operations.

2. Generate Java code from the model. The tool produces code for any J2EE constructs – servlets, JSPs, EJBs, SOAP objects – that you specify.

3. Supply implementation code for the defined operations. Typically the tool knows how to implement CRUD operations. But custom operations such as placeOrder( ) or validateCreditCard( ) would require custom code from the developer. (Note that this step may come before step 2, depending on the tool and the modeling approach.)

4. Package the application for deployment to a particular platform.

2.1.1 What is ARAD?

Despite generating code from the model, basic model-driven tools may still require developers to manually write a great deal of infrastructure code to complete the application. Architected rapid application development (ARAD) takes model-driven development a step further by addressing the high-level structure (architecture) of the application. In doing so, ARAD tools speed the development process significantly.

Several characteristics of ARAD tools make this possible:

• First, they raise the model’s abstraction to a higher level. A class in the top level model simply represents a domain entity, abstracted from how that entity will be used in the application. The entity might be implemented as a business object, a message, a web service, a JSP or all of these, but those choices are made independent of the basic model.

• Second, they generate infrastructure code, including non-Java artifacts such as deployment descriptors. As a result they produce a much higher portion of the application’s total code than do basic model-driven tools, allowing the developer to focus on defining the application components.

• Finally, the code they generate is “architected” based on best practices. The architect or developer can typically choose among alternative pre-built architectures, as well as customize them or define new ones.

2.2 What are the Supposed Benefits of MDD?

Model-driven development claims to offer the following benefits:

Faster development time. Code generation can save you the “grunt work” required to hand-write the same files over and over again. With the traditional approach, an entity bean, for example, requires 3 or 4 Java classes and one or more XML files. A clever MDD tool can automate most of this.

Architectural advantages. Modeling at the domain level can force you to actually think about the architecture and object model behind your system, rather than letting you simply dive into coding (which


many developers still do). It’s well accepted that greater attention to modeling up front reduces architectural flaws down the line.

Improved code consistency and maintainability. Most organizations have problems keeping code consistent in their projects. Some developers use well-accepted design patterns, while others do not. Using an MDD tool to generate your code with a consistent algorithm, rather than writing it by hand, can force all developers to use the same underlying design patterns, since the code is generated in the same way each time. This can become a huge advantage from the maintenance perspective. Furthermore, developers may be more likely to understand each other’s code more easily, given that they’re all speaking the same design language.

Increased portability across architectures, middleware vendors and platforms. Models, by definition, abstract to one degree or another from the code they generate. An MDD tool could be configured to produce a body of code with a particular configuration and characteristics. For example:

• Data entities in the model could generate entity beans, JDO classes, or plain old Java objects (POJOs) with JDBC.

• Screen designs in the model could generate JSPs, explicit servlets, or a Swing GUI.

• Deployment settings in the model could generate descriptors for any specified application server, be it WebLogic, WebSphere, JBoss or another.

Additionally, a model could even abstract beyond J2EE itself, giving you the ability to generate J2EE, .NET, or CORBA code from the same model.

This whitepaper focuses on evaluating the benefit of faster development time. It does not address the other potential advantages of MDD.

2.3 Rational Rapid Developer (RRD) and ARAD

Rational Rapid Developer is an ARAD tool for creating server-side Java applications. RRD covers the important aspects of J2EE development: the UI, business logic, persistence, messaging, as well as integration with legacy systems and web services.

2.3.1 Modeling and Code Generation

Developing with RRD starts with a class model. The class model contains entities with attributes and methods. Classes within the model have relationships to one another. Typically the class model will resemble the database schema, at least initially; in fact RRD can easily generate a class model from a database schema or vice versa.

One interesting aspect of any model-driven approach is how it integrates developer-supplied implementation logic into the model. Most models cannot completely describe an application. For example, when you define an operation in a class model, the tool could generate a Java class with a stub for the corresponding method. But except for standard CRUD operations, the tool would not know how to generate the code for the method body. You would have to supply the method’s implementation logic yourself.

RRD handles this issue by including the method code in the class model itself. In other words, when you define a method for a model class, you code the method within the model rather than as part of the generated Java class. RRD stores the method code as metadata in the model, then later incorporates it into the Java classes it generates.


This approach has two important consequences for the developer:

• Methods are coded “in isolation” rather than as part of a complete Java source file. The developer accustomed to scrolling through a source code file to examine other members of the same class may find this approach challenging at first.

• Ordinarily there is no reason to touch the generated Java code. In fact, from RRD’s perspective the generated code is “irrelevant”. This is not as radical an idea as it may sound; JSP developers rarely look at the Java servlets generated from their JSPs.

2.3.2 Using the Class Model

Once the class model is built, RRD application development centers on building constructs that interact with the classes in the model. RRD can produce many such constructs, among them web pages, messages, or generic components. Each construct has its own ObjectSpace (its own subset or view of the class model) that includes only the classes, attributes and methods needed by that construct. For example, to create a web page displaying the details of a single customer and related orders, we would include in the ObjectSpace for that page the Customer and Order classes, but omit the Product and Vendor classes. Drawing an analogy to database schemas: if the class model is the entire schema, the ObjectSpace is a subset of tables and fields made visible to a particular database user.

Extending the analogy, just as a database schema can include calculated fields and virtual tables, so too you can define variables and methods within an ObjectSpace; they belong only to the parent J2EE construct.

The result of this approach is that certain Java classes that derive from the class model are generated for every construct that uses those classes in its ObjectSpace. For example, if you build five different web pages that include the model Customer class in their ObjectSpaces, RRD generates a separate Java Customer class for each page. And each generated Java class includes only those Customer attributes and methods actually used in that ObjectSpace.

This approach has important consequences for the shape of the resulting Java code. We will discuss them further at various points below.

2.3.3 Building the Site Model and Style Models

If the application includes a web front end, you create a site model. This is a flowchart-like diagram showing the pages of the site and how a user would navigate among them. You can use this facility to initially define all the pages of the site for completion later.

The site model acts as a storyboard for the site. While it does not generate actual navigation code among pages, it does does the actual page linkages that you have coded.

You also create style models for the GUI. These are akin to style sheets for a text document. They contain predefined page layouts and page controls, as well as color and font schemes. Style models insure that pages in the site have a consistent look and feel. They also speed page development by taking care of most formatting choices in advance.

2.3.4 Creating Web Pages

RRD has a WYSIWYG design tool for creating web pages and other screen constructs. You build a page by placing Visual Basic-like controls in the design space, then binding the controls to objects in the ObjectSpace. For example, the data entry fields in a Customer detail page would map to the attributes of the Customer object in the ObjectSpace. RRD generates the code connecting the objects to the page. When the page is loaded at runtime, the fields are automatically populated.


RRD also simplifies the process of linking pages together. For example, if the customer detail page includes a table of the customer’s orders, each line in the table could provide a link to an order detail page for that order. RRD would compose a URL for the link that includes the order ID.

RRD’s approach to page design frees the developer from two tedious tasks:

• Writing explicit HTML script or JSP logic.

• Writing framework code (e.g. Struts) behind the page.

2.3.5 Adding Application Logic

Once the class and site models have been defined, you will add application logic. This takes the form of custom methods that you define and implement. These methods can belong to model classes, to individual pages or to other constructs.

2.3.6 Setting the Application’s Architecture

At some point along the way you set up the application’s overall architecture. This process consists of several steps:

• Choosing the deployment technology. You first choose the technology platform – J2EE or Microsoft DNA/COM – then the application server.

• Choosing the construction patterns, i.e. high-level patterns that will govern how the code is generated. For example, you can choose to implement persistence via EJBs or POJOs containing JDBC. Similarly you could choose to implement web pages via JSPs or explicit servlets.

• Partitioning the application for deployment. You can package the entire application in a single archive or partition it into multiple archives.

Note that these steps can take place at any point in the development process. Note, too, that you can change these choices without affecting the various models that comprise the application.

3 Study Description

This case study compares the productivity of two different approaches to developing a J2EE application: the model-driven, ARAD approach embodied by IBM’s Rational Rapid Developer product and a traditional, code-centric approach. The study centers on two competing teams developing the same Java application: The Middleware Company Application Server Platform Baseline Specification (henceforth, “the specification”)

It is important to note that we did not create two new teams for this study. Instead we formed one team to implement the specification using RRD. For comparison we used the results and experiences of a “traditional” team from a previous productivity study conducted earlier this year.2 That team used a market-leading, full-featured IDE typical of the code-centric approach. We refrain from naming the IDE to focus the study on the productivity of MDD and RRD rather than make this a “vendor shoot out”.

2 Model Driven Development for J2EE Utilizing a Model Driven Architecture (MDA) Approach -- Productivity Analysis, The Middleware Company Case Study Team (June 2003)


Additional details about the setup and conduct of the study:

• Both teams were given files containing the static HTML for the required web pages, so they could incorporate it into the JSPs they created. In this way they could focus on J2EE development and not be sidetracked writing HTML. While the traditional used these HTML files, the RRD team chose to ignore them. Because of RRD’s page design features, the team found it more productive to create the pages from scratch, guided by screenshots in the spec.

• After they finished implementing the specification, the RRD team was given a short list of enhancements to implement, “typical” of evolving application requirements. Since these additional requirements were not part of the traditional team’s mandate, the RRD team’s experience here stands alone as anecdotal evidence, and is not part of a quantitative comparison.

3.1 About the Specification

The functional specification used by both teams for this productivity study is The Middleware Company Application Server Platform Baseline Specification. It is a 46-page spec for an enterprise application that describes its requirements in detail, from database schema to web user interface. Using this specification insures that participants in this study would build comparable applications.

The Middleware Company created the specification with the help of a distinguished panel of experts, including book authors, open source contributors, CTOs and VPs of Engineering, representatives from two of the top three IT research firms in the United States, and interested critics of prior case studies conducted by The Middleware Company. The expert group members include:

Assaf Arkin (Chief Architect, Intalio), Clinton Begin (Author, Open Source JPetStore), Rob Castaneda (Author, CEO, CustomWare Asia Pacific), Salil Deshpande (The Middleware Company), William Edwards (The Middleware Company), Marc-Antoine Garrigue (OCTO, lecturer ENSTA), John Goodson (VP, DataDirect), Erik Hatcher (Author, Java Development with Ant), Rod Johnson (Author, Expert 1-on-1: J2EE Design & Development), Anne Thomas Manes (Analyst, CEO, Bowlight), Vince Massol (Author, JUnit in Action), John Meyer (J2EE/.NET Analyst, Giga Information Group, now Forrester Research), Tom Murphy (J2EE/.NET Analyst, META Group), Cameron Purdy (CEO, Tangosol), Roger Sessions (.NET Guru, Founder, ObjectWatch), Vivek Singhal (CTO & VP Engr, Persistence Software), Bruce Tate (Author, Bitter Java), Bruno Vincent (OCTO), Andrew Watson (Vice President & Technical Director, Object Management Group), Wayne Williams (CTO, Embarcadero Software), Joe Zuffoletto (Author, BEA WebLogic Server Bible)

You can download the specification from our web site, http://www.middleware-company.com/casestudy.

3.2 Choice of Application

As is well known by now, PetStore, the basis for the specification, is a simple web-based J2EE e-commerce application with the following functionality:

• User management and security. Users can sign into the system and manage their account.

• A Product catalog. Users can browse a catalog of pets on the web site (such as birds, fish or reptiles).

• Shopping cart functionality. Users can add pets to their shopping cart and manage their shopping cart in the usual ways.

• Order functionality. Users can place an order for the contents of their shopping carts.

• Web services. Users can query orders via a web service. We extended the PetStore to include this, since web services are an emerging area of interest.


From a technology perspective, the PetStore includes the following:

• A thin client HTML UI layer • JSPs to generate HTML on the server • JDBC SQL-based data access • EJB middle tier components • Ad-hoc database searching • Database transactions • Data caching • User/Web session management • Web Services • Forms-based authentication

It should be noted that “PetStore” evokes mixed emotions in some, because Sun Microsystems never intended the original PetStore sample application to be used as the basis of a case study. After all, PetStore was originally merely a sample application for J2EE, not a fully blown specification. Furthermore, the original PetStore did not represent a well-architected application.

We believe we have addressed these challenges in the following ways:

• We have a specification for the PetStore, rather than merely an implementation.

• The “modern” PetStore implementations, which conform to our specification, have departed substantially from Sun’s original implementation. Practically, what the specification has most in common with Sun’s original PetStore is that the application domain involves purchasing pets.

• The specification does not mandate any particular architectural approach to designing the PetStore, giving teams the freedom to architect their applications as they see fit.

3.3 Overview of the Rules

The specification describes in detail the rules for building the application. It describes, for example, what data can be cached, database exclusivity rules, requirements for forms-based authentication and session state rules. It also describes in great detail the required experience of using the application.

The rules for this study are designed to factor out extraneous aspects of the comparison and focus it on the productivity of J2EE coding. In brief:

• Each team was required to use the same database schema, as spelled out in the spec.

• Each team received the same static HTML and images. The traditional team used the provided HTML in constructing their JSPs; the RRD team did not, because RRD made it easier to design the pages from scratch. They did, however, use the provided images.

• The spec did not mandate the implementation details of the J2EE code, including choice of J2EE implementation patterns – those decisions were left up to each team. What mattered was that the two resulting applications behave similarly.

• Each team was given their choice of J2EE-compliant application server, so that forcing the use of an unfamiliar one would not hinder their productivity. (As before, we refrain from mentioning the specific application servers used.)

• Each team chose their own tools for source control, logging and the like. Here are their choices: [


Traditional Team Tool Purpose Comments Unnamed Version control A full-featured version control system, used internally at The

Middleware Company for many purposes. Apache Axis Web services Apache Axis is compliant with Sun’s Java API for XML

Parsing (JAXP) standard. Apache Log4J

Logging and auditing

Apache Log4J is quickly becoming a standard logging package for use in J2EE projects.

RRD Team Tool Purpose Comments Unnamed Version control RRD integrates well with version control, letting you check

files in/out from within RRD. Apache Axis Web services Apache Axis is compliant with Sun’s Java API for XML

Parsing (JAXP) standard. RRD’s native logger

Logging and auditing

RRD has integrated debugging and logging capabilities.

3.4 Overview of Testing Process

To ensure that the two final applications behaved similarly, we ran both through a rigorous testing process. Described in a 29-page document, this process comprised 37 testing scenarios that we performed manually on each application. The test measured whether the applications performed as described in the original specification.

The test scenarios are functional in nature, in that they do not perform unit testing of code, but rather describe a process for a tester to interact with the application using the web interface. For example, one scenario was to sign into the system and edit account information. We intentionally did not perform code-level unit testing because the two teams’ implementations were different, and what really mattered was that the end applications behaved similarly, so that the results of the productivity case study would be useful. That is also why the testing was manual in nature.

Both teams’ applications passed the tests.

3.5 Overview of the Teams

The team using the traditional, code-centric approach consisted of three members: one senior J2EE architect from The Middleware Company (who served as team leader) and two experienced J2EE programmers. Each team member had significant experience with J2EE development on a variety of application servers.

The RRD team consisted of two members, one each provided by IBM and The Middleware Company (TMC). The IBM-provided team member is an experienced server-side developer from Technology Solution Partners LLC, a Shelton, CT based services provider that has used RRD for several years, He served as team leader. The TMC team member is an experienced J2EE developer with a solid foundation in architecture as well as development. Before this study he had experience with many development tools, including model-driven, but none with RRD.

Despite a difference in team size, we went to great lengths to ensure that the teams had roughly similar skill-sets regarding J2EE development experience generally and the specific development tool they would


use. On the traditional side, the team members came in with experience in the chosen IDE. Still, they spent time reinforcing their knowledge of it and other tools they would use. On the RRD side, to get up to speed, the TMC member received three days of one-on-one RRD training before beginning the project. None of the time spent on training counted toward the total.

3.6 Overview of Project Schedule and Project Management Approach

To keep an accurate log of the experiences of each team, we held periodic conference calls separately with each team. With the traditional team we held these conferences weekly. With the RRD team, because development proceeded so much faster, we did so near the beginning of their development work and again toward the end. We took copious notes about the teams’ experiences in these calls. The teams would answer the following questions:

• What did your team work on?

• What was good from the productivity perspective?

• What was challenging from the productivity perspective?

Summaries of these notes are presented in the next section of this whitepaper.

4 Study Results

In this section, we discuss the results of the case study. The results are organized into the following upcoming sections:

In the Architectural Analysis section you will learn about the architecture and J2EE patterns used by each team.

The Qualitative Results section summarizes each team’s qualitative thoughts on the development approach they chose – the issues each team encountered and how they resolved those issues.

In the Quantitative Results section you will see the final productivity result numbers of each team.

The section Factors that Affected Productivity gives a detailed breakdown of the reasons for the difference in productivity.

Finally, Additional Tasks describes the RRD team’s experience in performing enhancements to the application.

4.1 Architectural analysis

4.1.1 UML and Code Generation

Both teams created UML diagrams for their object models. In fact, they each created very similar object models. They each had abstractions for:

• User Accounts • User Profile Information • Products • Product Categories


• Suppliers • Shopping Carts • Orders • Line Items

The teams differed, however, in how they created these models and diagrams.

The traditional team created UML diagrams for their object model using a product named Visual Thought. They made their UML strictly for design and communication purposes – they did not auto-generate J2EE code from the UML. They did, however, use their IDE's wizards to generate JavaBean accessor/mutator methods, EJB components, struts code, exception handling code, and stub-code that sped the implementation of interfaces.

The RRD team used RRD to create a class model from the database schema, then enhanced the model directly in RRD via the UML diagram it displays. They auto-generated much more of their code than the traditional team due to RRD’s generation capabilities.

4.1.2 Overall Shape of the Code

The two teams produced bodies of code that are similar in many ways. For example, both applications use JSPs and EJBs. Still, the two bodies of code are different in other, important ways. How the code was produced markedly affected the shape of the result.

4.1.2.1 TRADITIONAL TEAM

For the web tier, the traditional team used a combination of servlets, JavaServer Pages (JSPs), and JSP tag libraries (taglibs). They used Apache Jakarta Struts as the framework for navigation within the web tier. (Struts is a popular open source framework for building J2EE-based web applications. It encourages use of the well-accepted Model-View-Controller (MVC) design paradigm.)

In the business tier the traditional team used EJBs, both session and entity. Session beans represented business logic while entity beans handled persistence. In addition, the team consciously used many standard J2EE design patterns:

• Session façade • Primary Key generation in EJB components • Business delegate • Business interface • Data Transfer Objects (DTOs) • Custom DTOs • DTO Factory • Service locator • JDBC for Reading via Data Access Objects (DAOs)

4.1.2.2 RRD TEAM

The RRD team’s approach was different. RRD abstracts from the J2EE platform and from low-level choices about the shape of the code produced. Instead, you first choose the target platform, then make high-level choices about how the code is built. The RRD team chose one platform and set of construction patterns for development, and another for the production version.


For development, the team initially chose Apache Tomcat (which comes with RRD) as the target platform. With this platform choice, RRD produced servlets for presentation and an MVC structure of POJOs for business logic and persistence. The reason for these choices was speed and lighter weight during development.

After finishing development, the team switched to a full-featured J2EE application server. This target platform let them choose JSPs for presentation, stateless session beans for business logic and entity beans for persistence. Regenerating the code with the new settings took only minutes.

Noteworthy is how RRD replicates certain classes for each page. If five pages require the Account class from the model, each page gets its own Account.java, but one tailored to its needs. When you choose to construct EJBs, you get a separate stateless session bean for each page. The argument behind this architecture is that the page-specific classes are lighter in weight because each contains only the logic necessary for the page it serves.

As for design patterns, the RRD-constructed code used some but far fewer than the other team. More to the point, in abstracting from the J2EE platform, RRD took those decisions out of the developer’s hands.

4.1.3 Security

The two teams took very different approaches in the area of security.

The traditional team used an authentication filter. This filter checks if the currently requested page is restricted and, if so, checks if the user is signed in (sign-in information is stored in the HTTP Session). The team wrote this filter from scratch. The filter implements the javax.servlet.Filter interface, supplied by Sun.

By way of comparison, the RRD team used a more distributed approach. It too used a session attribute containing login identity to indicate whether login had occurred. But each authenticated page contained its own logic to check the attribute and, if necessary, invoke the login procedure. All security-related logic was written by hand.

4.2 Qualitative results

In this section, we’ll review qualitative thoughts from both teams, summarized directly from their periodic status updates.

4.2.1 Traditional Team

4.2.1.1 TRADITIONAL TEAM - WEEK 1

The traditional team adopted an iterative prototyping style development process. In the first week, they built a simple prototype that allowed them to architect their design patterns basis for their project. It was a fairly involved process for them to establish a comfortable development environment, and they ran into a few challenges getting their version control to collaborate effectively with their IDE. They used workarounds to sidestep this issue, which was largely resolved by week 2. They also spent a good amount of time during week 1 architecting the object model for their system, deciding on a package structure, and other environment-related issues.

From the productivity perspective, they were happily impressed by the capabilities of their IDE that first week. They found the IDE to integrate well with their chosen application server, as well as have good code generation capabilities. It helped that each of the team members had experience with the IDE in the past.


Their productivity challenges this week related to sharing files, communication issues, performing code reviews, and maintaining a consistent package structure.


In week two, the traditional development team began to specialize in their various development roles. One team member owned the model (EJB) layer, another team member owned the view (web) layer, while a third team member added value through providing helper classes and interfaces between layers to keep the team members productive.

The team decided to build their system in a use-case fashion, by focusing on each use-case in turn. This week they worked on user account maintenance use-cases, such as sign-in, sign-out, user creation, and user preference maintenance.

From the productivity perspective, what they found good this week was leveraging the Struts framework. They found Struts coding to be very efficient. Furthermore, they decided to use a strategy of decoupling their web tier and business tier by allowing “stub” implementation code to be plugged in for code that was not fully built yet. They switched between “stub” and “real” code through properties files and the business delegate design pattern described in the appendix.

The productivity challenges this week were the typical ones a development team first encounters, such as consistent use of source control. They also had some challenges with their IDE, in that if they tried to generate J2EE components from their IDE, and needed to modify them later, the components did not round-trip back into the IDE very easily.


This week, the traditional team continued their development by working on product catalog browsing, as well as some shopping cart functionality.

From the productivity perspective, what they found good this week was that they had resolved their version control collaboration issues. They also reduced build-time dependencies by building libraries of interfaces that team members could use. At this stage in development, each team member was very productive and the project was well partitioned so that each team member had his own area of development. Furthermore, their IDE had been providing them value in code generation capabilities.

The only challenges this week were clarifications required for the PetStore specification, and some minor refactoring they needed to perform on their shopping cart.

4.2.1.4 TRADITIONAL TEAM - WEEKS 4 AND 5

In their final weeks, the traditional development team wrapped up their application by coding the final use cases, performing testing, and debugging. Also, they integrated their team members’ code together, abandoning the stub implementations that had served their purpose.

Productivity gains these weeks included several items. They received a continual benefit from the stub implementation architecture they chose. Very little team communication was required given the interfaces they had authored that allowed them to collaborate efficiently. Also, their web service implementation was built very quickly, as their IDE provided capabilities enabling them to do this.

The challenges this week include some re-factoring and re-analysis of code, such as in their data access layer, which had several flaws. The fact that their application has many layers also caused challenges when things break, since it was not always clear where the issue was until they delved into the layers. They also had some other minor issues related to Struts and property files.


4.2.2 RRD Team

Again, impressions from the RRD team were taken more frequently because the team progressed so quickly.

4.2.2.1 RRD TEAM – EARLY STAGES

The team had made a very quick start. On Day One the team accomplished an enormous amount of work:

• Loaded the database

• Set up the application environment, including source control

• Created the class model from the database schema. This involved importing the schema to create the classes, then filling in relationships that didn't exist in the DB.

• Set up a style repository to facilitate style consistency while building the application.

• Built the “site model” (the site storyboard) by creating all the empty pages and linking them together.

• Created the login pages and logic.

• Created the shopping cart and logic.

Several things in particular contributed to productivity immediately. First, importing the initial class model from the database schema saved much time. All that remained was to specify class relationships that didn’t have corresponding foreign key relationships in the schema. Second, building the site model quickly created all the blank pages and established the overall flow, or user navigation, among pages. Third, the WYSIWYG page designer proved much more efficient than direct JSP editing. And binding page controls to data objects in the class model proved a very efficient way of connecting pages to application logic.

One issue that, from the TMC member’s perspective, reduced the productivity gain had to do with the style repository. RRD’s GUI style handling is sophisticated and multi-layered. It lets you set up a repository, independent of the application, containing page styles and common controls. These styles and controls then become available when you build PetStore. Additionally, when you place a control in a page you can override its inherited settings in a number of ways.

The TMC member found that default settings didn’t always behave as expected. For example, although he gave the default grid control the color scheme shown in the specification, when he used the control in a page it took on different colors. He had to spend additional time reformatting the control.

Additionally, the TMC member was initially concerned about the degree of abstraction RRD inserts between the developer and the J2EE platform. This concern did not hinder his productivity.

4.2.2.2 RRD TEAM – LATE STAGES

As the project progressed, the rapid development of pages continued to prove productive.

Three issues hindered productivity in the final days. The first concerned drop-down lists of states, countries, etc. RRD’s native handling of such lists proved problematic, given the specification requirements. These problems forced some awkward programming. See section 4.4.2.1 below for more details.

The second concerned the default error page described in the specification. RRD placed certain obstacles in the way of using JSP’s innate error trapping capabilities, forcing the team to explicitly trap application


errors and pass them to the error page. This approach was cumbersome compared to how it would be done with pure JSP programming. See section 4.4.3 below for more details.

Finally, the TMC member found it challenging to find the best way to organize code in RRD. In particular, when he wanted to write some global utility functions, it was not immediately obvious where he should put them. This problem would likely disappear with experience in RRD.

4.3 Quantitative Results

Here is the final tally of development hours spent by each team to develop PetStore to spec:

Team Original Estimated Hours Actual Number of Hours

Traditional team 499 507.5

RRD team 40-50 47.5

As you can see, the RRD team was the clear winner from the productivity perspective in this case study. They built the PetStore application dramatically faster than the traditional team, in less than 10% of the time.

4.4 Factors that Affected Productivity

Clearly RRD’s ability to generate application code from a model accounts for most, if not all, of the productivity gain. But with such a dramatic improvement it is worth digging deeper and examining the differences in detail. There were a number of significant factors contributing to RRD’s greater productivity, as well as a few that detracted. While we can’t quantify each one individually, we can indicate the approximate importance of each to the outcome.

4.4.1 WYSIWYG Page Design

One huge factor in RRD’s favor is that it completely shielded the developers from the need to edit servlets or JSPs. Again, the traditional team used the supplied HTML. And while their IDE offered a JSP editor, they were still forced to edit JSP syntax directly. They had to convert the supplied HTML into JSPs. This can be extremely tedious, time-consuming work, even with templates and custom tag libraries. RRD’s page designer, linking Visual Basic-like controls to model classes, proved a much cleaner and more productive way to build pages.

A smaller, related gain came in debugging pages. In traditional JSP development, to test the correctness of your JSP syntax you must run the application and invoke the JSP. In RRD you can choose to translate your page designs directly to servlets rather than to JSPs. When you do, the build process compiles the servlet and thus detects JSP syntax errors before you even run the application. This process is much faster. The RRD team chose this approach.

Two additional notes on RRD & page construction:

• RRD still requires or allows you to use JSP logic in specific places. For example, the text you place in a label control may include JSP expressions as well as literal strings. Still, these uses are isolated and constituted a tiny fraction of the team’s time spent on page construction.

• RRD lets you view and edit the HTML/JSP logic it produces from your page design. The RRD team found a couple of places where viewing or even overriding the HTML was necessary to achieve a desired result.


4.4.2 Binding Pages to Data

RRD’s paradigm of binding page controls to objects in the class model via the ObjectSpace also contributed enormously to productivity. The RRD team did not have to program to Struts or any similar low-level framework. For the typical data page, it sufficed to place labels or text fields in the page and map them to attributes of some object in the ObjectSpace. In special cases a page or an individual control required some explicit pre-load logic; RRD provides places for that logic.

There were two factors that reduced this productivity gain somewhat.

4.4.2.1 LISTS IN PAGES

The first had to do with using a list (such as a drop-down list of US states) in a page. RRD maps the user’s selection from the list to an integer, even if the data to be stored is a string. In the list of US states, for example, when the user chooses Alabama, RRD considers the “value” of the list to be 1 rather than “Alabama”. To bind the list to a string attribute of an Account object in the ObjectSpace required some additional programming.

Note: If the data to populate lists resides in database tables, this problem goes away. But the specification’s schema did not include such tables, and the RRD team refrained from creating them because the spec barred changes to the schema.

4.4.2.2 PASSING OBJECTS BETWEEN PAGES

A second complicating factor had to do with passing data objects from one page to another via the HTTP session. Ordinarily the source page simply places the object in the session as a named attribute, and the target page retrieves the same object in similar fashion. In RRD, however, a model class translates to a separate Java class for each page that uses it. For example, if the model has a ShoppingCart class and three pages use it in their ObjectSpaces, each page gets its own generated ShoppingCart.java. The three generated classes are different because each lives in a page-specific Java package. This means the pages cannot pass actual ShoppingCart objects via the HTTP session.

RRD’s preferred solution is to convert the objects to/from XML and pass the XML strings via the session. RRD does make it relatively easy to create a DTD from a model class and convert between object and XML. Nevertheless, this process does require additional programming in pages that use it. The RRD team used this technique.

4.4.3 Default Error Pages

The specification requires all application exceptions to be captured in a default error page. In the screenshot in the specification document, the error page includes the stack trace for the exception, although the spec leaves the actual content of the page to the implementer’s discretion.

The JSP API makes it easy to implement the error page shown in the spec:

1. Use a page directive in each source page to point to the error page.

2. Use a page directive in the error page to mark it as such.

3. In the error page, refer to the exception via the predefined variable exception.

RRD, in abstracting page design from the JSP API, obscures and complicates this process, which cost the RRD team time. RRD makes it easy to designate an error page for a given source page. What’s difficult is capturing and passing the exception. The team was forced to wrap every method body in a try block with a


corresponding catch that place the captured exception in the session. The default error page then must retrieve the exception and display it.

4.4.4 Source Control

The use of source control probably gave the RRD team a modest advantage. In the case of the traditional team, the team leader knew the chosen product well and trained and guided the other team members in its use, but the product did not integrate with the IDE. Consequently, source control procedures always required team members to take deliberate actions outside the IDE. Also, the team had to figure out which files generated by the IDE to keep in the source control tool and which to ignore.

The RRD team chose one of several popular source control software tools that are supported in RRD. Apart from initially logging into the source control server, the team members could do all source control actions easily from within RRD. Moreover, RRD automatically knew which files to place in source control.

Offsetting this advantage to a small degree was the issue of how RRD organizes its artifacts. While the RRD team leader understood this organization very well, the RRD novice on the team faced a learning curve. Where this mattered was in choosing what items to check out for a given development task. For example, class and method definitions for the entire class model are stored in a single file, while the body of each method is stored in its own individual file. This meant, paradoxically, that two team members could simultaneously edit different methods of the same class in the model, but could not simultaneously define new methods of different classes in the model. The TMC team member had to adjust to this unusual (for him) organization of source files.

4.4.5 Team Organization

Finally, the RRD team may have gained some productivity simply by having a smaller team. Fewer team members meant less difficulty dividing up the work, fewer source control conflicts and fewer miscommunications. It also meant that tasks performed together (such as design discussions) took fewer total man-hours. The TMC team member felt that, with a moderately-sized application such as this, having a third team member with comparable skills to his own might have actually slowed development rather than accelerated it.

4.5 Additional Tasks

After completing the development of the application to specification, the RRD team received a list of enhancement / maintenance tasks to perform. These tasks were intended to represent typical follow-on tasks developers might be asked to perform on existing applications.

As noted earlier, since the traditional team did not perform these tasks, we cannot compare the two teams’ experience to measure productivity gains. Still, the RRD team’s experience is interesting on its own.

Here are the additional tasks performed:

• Internationalize the account edit page. Set up a framework for multiple locales / languages. Translate one page into a foreign language based on the choice of locale.

• Add a new table to the database and use it. Add a table of customer reviews that has a N:1 relationship with items. Update the class model to match the database schema. Display a list of reviews on the item detail page.

• Partition the application. Divide the application into separate deployment archives for presentation (WAR) and business logic (JAR).


The time spent completing these tasks was short:

Task Time Spent

Internationalize the account edit page 1.1 hours

Add a new table to the database and use it 1.5 hours

Partition the application 0.3 hours

Details on these tasks follow.

4.5.1 Internationalize a Page

RRD's i18n capabilities are sophisticated. You can import locale-specific resource bundles from Excel, a database or elsewhere. Individual label controls and messages on pages are keyed to specific resources in the chosen bundle. The process is fairly straightforward; the most tedious part is translating the various pieces of text into foreign languages.

The specification added a wrinkle that complicated the task slightly: The user can choose a preferred language. So the locale must be chosen programmatically when the user logs in.

Still, it only took the RRD team a bit over one hour to generally set up internationalization for the application, translate the messages for one page into Spanish, apply the resources to the page and modify the login code to choose a locale.

4.5.2 Add and Use a New Table

The team was given SQL to create and populate a reviews table with a 1:N relationship between items and reviews. The team executed the SQL, imported the new table into the class model, set up the relationship to the items table, then modified the item detail page to list the reviews in a separate grid below the other item data. The team implemented the reviews grid to behave like others in the application, using Previous and Next buttons to handle displays beyond a certain length.

The whole process took less than 1.5 hours.

4.5.3 Partition the Application

RRD includes a "Partition Architect" that lets you partition the app. It presents a list of all constructed artifacts, along with separate lists for the different app tiers (presentation, business logic, persistence). You move individual artifacts from the first list into one of the others. You then tell RRD to build the requisite archive files. The process is comparatively simple and allows for creation of multiple partition models, with different deployment technologies and different architectures, e.g. development partition deploys locally to Tomcat as one file , production partition.deploys to WebSphere and has separate files for presentation and business logic/persistence.

The team partitioned the application into two parts: presentation and business/persistence. It took 20 minutes.


5 Conclusion

Based on the results of this case study, the productivity gains experienced using Rational Rapid Developer are impossible to ignore. The Middleware Company is impressed by the dramatic difference over the traditional approach.

Organizations wishing to improve their developer productivity should evaluate RRD for their projects. In doing so, we suggest considering these factors:

• RRD’s strong emphasis on modeling and therefore on architecture. We at The Middleware Company consider modeling and architecture good things, but they do require a change in thinking for traditional, code-centric developers. Additionally one might consider how RRD and its models would interact with other model-based tools already in use. RRD provides class model import and synchronization with IBM’s UML modeling tools Rational Rose and Rational XDE, as well as XMI import.

• RRD’s abstraction from the J2EE platform. Again, RRD shifts your development activities almost completely away from infrastructure code and towards modeling and business logic. Certain low-level platform issues such as package structure and use of code patterns are taken from the developer’s hands. This may be a challenge to experienced J2EE developers, just as some C++ programmers find the absence of pointers and direct memory management in Java a challenge. However, it is the primary reason why developers less experienced in J2EE can quickly become productive in RRD without understanding the platform complexities.

• The developer’s background. The TMC member of the RRD team felt that RRD is particularly well suited for developers just coming to J2EE from elsewhere, that it hides the complexities of J2EE development much like PowerBuilder and Visual Basic hide the complexities of OO development.

• RRD’s ability to handle existing applications. In this study the two teams built a new application from scratch. They did not evaluate the ease of pulling an existing application into the tool. Shops that have more maintenance than new development should do so when considering RRD. Additionally, RRD claims broad legacy integration functionality, although these capabilities were outside the scope of this case study.

Please write us at [email protected] to share your impressions and experiences with us.

6 Disclosures

This study was commissioned by IBM.

The Middleware Company has in the past done other business with IBM.

Moreover, The Middleware Company is an independently operating but wholly owned subsidiary of Veritas Software (www.veritas.com, NASDAQ:VRTS). Veritas and IBM have a number of business relationships in certain technology areas, and compete directly against each other in other technology areas.

IBM commissioned The Middleware Company to perform this study on the expectation that we would remain vendor-neutral and therefore unbiased in the outcome. The Middleware Company stands behind the results of this study and pledges its impartiality in conducting this study.


6.1 Why are we doing this study? What is our “agenda”?

We are compelled to answer questions such as this one, due to controversy that sponsored case studies occasionally create.

First, what our agenda is not: It is not to demonstrate that a particular company, product, technology, or approach is “better” than others.

Simple words such as “better” or “faster” are gross and ultimately useless generalizations. Life, especially when it involves critical enterprise applications, is more complicated. We do our best to openly discuss the meaning (or lack of meaning) of our results and go to great lengths to point out the several cases in which the result cannot and should not be generalized.

Our agenda is to provide useful, reliable and profitable research and consulting services to our clients and to the community at large.

To help our clients in the future, we believe we need to be experienced in and be proficient in a number of platforms, tools, and technologies. We conduct serious experiments such as this one because they are great learning experiences, and because we feel that every technology consulting firm should conduct some learning experiments to provide their clients with the best value.

If we go one step further and ask technology vendors to sponsor the studies (with both expertise and expenses), if we involve the community and known experts, and if we document and disclose what we’re doing, then we can:

� Lower our cost of doing these studies � Do bigger studies � Do more studies � Make sure we don’t do anything silly in these studies and reach the wrong conclusions � Make the studies learning experiences for the entire community (not just us)

6.2 Does a “sponsored study” always produce results favorable to the sponsor?

No.

Our arrangement with sponsors is that we will write only what we believe, and only what we can stand behind, but we allow them the option to prevent us from publishing the study if they feel it would be harmful publicity. We refuse to be influenced by the sponsor in the writing of this report. Sponsorship fees are not contingent upon the results. We make these constraints clear to sponsors up front and urge them to consider the constraints carefully before they commission us to perform a study.

Search help

Book review — Practical Software Engineering

Contents:Organization and key features

Emphasizes the importance of traceability

About the author

Rate this article



Parshu AnantharamSenior Software Engineer27 0 2004

from The Rational Edge: This review describes a book on how to integrate three aspects of software development: the process of engineering software-intensive systems, object-oriented analysis and design methodology, and technology.

by Enricos ManassisAddison-Wesley, 2004ISBN: 0-321-13619-5 Cover Price:US$39.99275 Pages

This book focuses on how to integrate three aspects of software development: the process of engineering software-intensive systems, object-oriented analysis and design (OOAD) methodology , and technology. It contains many practical insights, methods and guidelines on how the three aspects should interact and be applied to a software development project. Accordingly, each chapter explores development issues from the standpoint of:

● IBM Rational Unified Process,® or RUP®

● Object Oriented Analysis and Design● The Microsoft .NET platform

The book’s objective is to provide the reader with a holistic view of software development for distributed e-commerce systems. It assumes a basic knowledge of software development, object-oriented design principles, use-case analysis, and UML notation. It also assumes basic knowledge of the .NET framework, specifically an understanding of design and implementation models, and the ability to understand and review the companion code.

Manassis walks readers through a full software development lifecycle — from business modeling to analysis, security, and testing — showing how to integrate tools such as Visual Studio .NET and IBM Rational Rose XDE® Developer. With its complete explanations of UML diagrams, plus code samples, document templates, and checklists, this book constitutes a practical field guide and reference for development professionals working on .NET projects.



Organization and key features The book is divided into two parts. Part I, System Specification, discusses the UML business model, user experience model, and system requirements. Part II, System Analysis and Design, covers the UML analysis model, design model, implementation model, role-based security, and testing.

Key features in the book include:

● An iterative development case study.1 Manassis follows the development of a single sample Web application throughout the book to demonstrate all activities defined in the iterative IBM Rational Unified Process.

● A concise, holistic vision of process, design, and technology (.NET). This book presents a hands-on view of object-oriented analysis and design and describes the thought processes behind everything from requirements capture to class model and code generation. The well-focused approach helps readers gain insight into software development concepts, without overwhelming them with too many details.

● Excellent references: For every concept he introduces, Manassis provides references to pursue for more in-depth exploration.

Emphasizes the importance of traceabilityThroughout the book, Manassis discusses the importance of requirements traceability. The last chapter, “Traceability at Work,” demonstrates how traceability helps to keep projects on track and on schedule. The greatest practical function of traceability, he claims, is that it facilitates impact analysis. It allows you to predict and identify what will change if you modify the system at any level.

For example, with traceability you can:

● Identify the source of inputs for each artifact.● Include traceability information as part of an artifact where appropriate (e.g., in many UML model

diagrams).● Use techniques that help you link two artifacts to each other. For example, you can see how to link the

.NET role-based security attributes in code with the UML use-case model, actor diagram, and sequence diagrams, through the role-based security matrix.

● Whenever you make a code change, identify all artifacts you need to change, and understand how to make those changes.

In addition, the author describes the contribution of modeling tools such as IBM Rational Rose XDE Developer and Microsoft Visual Studio .NET with respect to traceability.

In summary, the book would be useful for any developer using software engineering principles and OOAD. In particular, it would be invaluable to anyone using RUP, OOAD, and .NET.

-Parshu Anantharam Senior software engineer

1 The complete case study can be found on a companion Web site:


http://www.booksreasy.com.

Editor’s note: You can read an excerpt from Practical Software Engineering in the October 2003 issue of The Rational Edge

About the authorParshu Anantharam is currently a senior software engineer at a company in Clayton, MO. He develops and builds test environments consisting of IBM midrange systems and middleware, as well as applications being developed using Java, XML, and Oracle. In addition, he works with IBM Rational Robot to develop and support test automation efforts. He holds a bachelor's degree in computer engineering from an institution in Mumbai, India, and has worked in the software field for the past twelve years.



Comments?


Search help

Book review—Radical Project Management

Contents:

About the author

Rate this article



Tanuj VohraIBM22 0 2004

from the Rational Edge: Vohra reviews a book that explains the complexities of managing time-sensitive projects in rapidly changing environments, and suggests tools project managers should use to manage those complexities.

by Rob ThomsettPrentice Hall, 2002ISBN: 0-13-009486-2Cover Price: US$39.99348 Pages

What do project managers really do? Most team members don’t know. A developer friend of mine used to describe her project manager as “unnecessary overhead ”— a person who did nothing constructive except schedule meetings, nag people to get their work done and keep up the quality, and caution them of the risks involved in delivering a feature. In her view, the project manager was just one more impediment to getting the product ready for release on time.

However, her perspective quickly began to change when she found herself leading a new, strategic project for her company that had engineering teams spread across three continents and rapidly changing requirements. During the first three months her team prototyped a set of features that no one would sign off on. Six months later, new requirements were still coming in, and there was a new set of stakeholders, each with different notions about the delivery schedule and feature list. Everywhere she turned, there were chaos, confusion, failed expectations, unhappy managers, and — most important — low employee morale. She tried using traditional project management techniques, such as detailed project and resource allocation plans, but they didn’t help much. Clearly, she needed something more radical. And then she found this book.

In this book Rob Thomsett crystallizes his group’s more than twenty-five years of experience working with more than 20,000 project managers into a new approach to project management that he calls “eXtreme Project Management (XPM).” XPM defines a new approach to measuring project success and progress that encompasses scope and objectives, project risks, team satisfaction, stakeholders, sponsors, managers, and more.

The book is structured into three distinct parts. The first part, on basic concepts, discusses the evolution of project



management and the need for XPM. According to Thomsett, traditional project management (TPM) focuses on content — the ultimate product that the team expects to create through their development effort. This focus is ill-suited for today’s development environment, in which the only real constant is change. In contrast, XPM focuses on the context (the managerial, political, and social environment of the project). The context includes several stages: project planning, implementation, post-implementation review, project support, and benefits realization. According to XPM, the effective management of a project requires a balance between, and integration of, the content and the context.

A focus on Rapid Application Development (RAD)

The second part of the book details the XPM process and discusses complementary tools. Beyond the traditional project management processes — project justification, approval and review, project planning, project tracking and reporting — Thomsett introduces additional XPM processes. The most important of these is Rapid Planning (RAP) sessions. Thomsett dedicates much of the book to discussing these sessions, including a chapter on each of their structural components.

According to Thomsett, a successful application of RAP requires completing the following activities:

● Define what “success” means for the project.● Determine the project scope and objectives.● Analyze potential benefits and define how to achieve them.● Define quality requirements.● Select a project development strategy.● Analyze project risks.● Develop a project task list.● Estimate the effort and costs associated with tasks/projects.● Develop a project schedule.● Allocate people to each task.● Estimate total costs and return on investment.● Create a project business case.

He discusses each of these process activities in detail, using actual cases as examples, and provides tools to assist with the activities. These include “success sliders” (used to gain consensus among stakeholders regarding project success), risk analysis spreadsheets, and process checklists.

He also lays out XPM rules throughout the book — simple, common sense principles that project managers often tend to ignore. Here are a few of my favorites:

● The less the project manager knows about the technical details, the better (I’ve taken this one to heart; my standard reply when my boss asks me anything is that I don’t have an answer!).

● No sponsor, no project.● If your project hasn’t changed, be afraid — very afraid.

Part three provides advanced tips and tools for project management, as well as discussions of issues such as ethics, project sponsorship, negotiation, and communication.


A reference for all project players

My friend benefited greatly from applying the concepts in this book. She found herself a sponsor for the project who was clearly able to define success, rein in requirements, help estimate costs, and create a business case. She then followed the RAP process, getting the team to help her identify risks, formulate a development strategy, and estimate costs. Finally, she got the team’s buy-in on quality and the project schedule. She then adjusted the project schedule with management approval, and the team was able to meet deadlines while maintaining product quality.

This is a great book not just for project managers, but also for everyone else associated with a project: sponsors, business analysts, stakeholders, IT professionals, developers, and even customers. It can provide them with an excellent understanding of the complexities involved in managing time-sensitive projects in today’s rapidly-changing environments, and of the tools project managers should use to anticipate and manage these complexities. Although most of the examples focus on the high-tech industry, they are applicable to other industry sectors as well.

A serious shortcoming of the book is that it mentions good points about the waterfall model, along with fast track prototyping and agile methods. But there’s no mention of the highly effective iterative approach inherent in the industry-leading IBM Rational Unified Process® (RUP®). Nevertheless, this book can serve as an excellent reference and provide instant value to project managers.

About the authorSoftware engineering manager Tanuj Vohra manages IBM Rational's PurifyPlus family of runtime-analysis tools. He is also keenly interested in management and leadership development practices. Before joining Rational as a software engineer in 1997, he held positions at Citibank, N.A., and Computer Maintenance Corporation, India. He earned a bachelors degree in computer science and engineering before leaving India, and then a masters degree in computer science from Michigan

Technological University.



Comments?


Search help

UML’s Sequence Diagram

Contents:The diagram’s purpose

The notation

The basics

Beyond the basics

Conclusion

References

Notes

About the author

Rate this article



Donald BellIBM12 January 2004

It’s February, and by now you’ve probably read about, or heard people talk about, making the change to UML 2.0—the new specification for UML that contains a number of improvements. Given the importance of the new spec, we are changing the basis of this article series, too, shifting our attention from OMG’s UML 1.4 Specification to OMG’s Adopted 2.0 Draft Specification of UML (a.k.a. UML 2). I hate to change emphasis from 1.4 to 2.0 in the middle of a series of articles, but the UML 2.0 Draft Specification is an important step forward, and I feel the need to spread the word.

There were a couple of reasons that the OMG improved UML. The main reason was that they wanted UML models to be capable of delivering Model Driven Architecture (MDA), which meant that the UML had to function as a more model driven notation. Also, the UML 1.x notation set was at times difficult to apply to larger applications. Furthermore, the notation elements needed to be improved in order to make diagrams more readable. (For example, modeling logical flow in UML 1.x was complicated and at times impossible. Changes to the sequence diagram’s notation set in UML 2 have made vast improvements in modeling logic in sequences.)

Notice the wording in my statement above: “Adopted 2.0 Draft Specification of UML.” It is true that the specification is still in draft status, but the key is that the Draft Specification has been adopted by OMG, a



consortium that does not adopt new standards until they become pretty solid. There will be some changes to the specification before UML 2 is completely adopted, but these changes should be minimal. The main changes will be in the internals of UML—involving features typically used by software companies who implement UML tools.

The main purpose of this article is to continue our focus on the essential UML diagrams; this month, we take a close look at the sequence diagram. Please note, again, that the examples provided below are based on the new UML 2 specification.

The diagram’s purposeThe sequence diagram is used primarily to show the interactions between objects in the sequential order that those interactions occur. Much like the class diagram, developers typically think sequence diagrams were meant exclusively for them. However, an organization’s business staff can find sequence diagrams useful to communicate how the business currently works by showing how various business objects interact. Besides documenting an organization’s current affairs, a business-level sequence diagram can be used as a requirements document to communicate requirements for a future system implementation. During the requirements phase of a project, analysts can take use cases to the next level by providing a more formal level of refinement. When that occurs, use cases are often refined into one or more sequence diagrams.

An organization’s technical staff can find sequence diagrams useful in documenting how a future system should behave. During the design phase, architects and developers can use the diagram to force out the system’s object interactions, thus fleshing out overall system design.

One of the primary uses of sequence diagrams is in the transition from requirements expressed as use cases to the next and more formal level of refinement. Use cases are often refined into one or more sequence diagrams. In addition to their use in designing new systems, sequence diagrams can be used to document how objects in an existing (call it “legacy”) system currently interact. This documentation is very useful when transitioning a system to another person or organization.

The notationSince this is the first article in my UML diagram series that is based on UML 2, we need to first discuss an addition to the notation in UML 2 diagrams, namely a notation element called a frame. The frame element is used as a basis for many other diagram elements in UML 2, but the first place most people will encounter a frame element is as the graphical boundary of a diagram. A frame element provides a consistent place for a diagram’s label, while providing a graphical boundary for the diagram. The frame element is optional in UML diagrams; as you can see in Figures 1 and 2, the diagram’s label is placed in the top left corner in what I’ll call the frame’s “namebox,” a sort of dog-eared rectangle, and the actual UML diagram is defined within the body of the larger enclosing rectangle.


Figure 1: An empty UML 2 frame element

In addition to providing a visual border, the frame element also has an important functional use in diagrams depicting interactions, such as the sequence diagram. On sequence diagrams incoming and outgoing messages (a.k.a. interactions) for a sequence can be modeled by connecting the messages to the border of the frame element (as seen in Figure 2). This will be covered in more detail in the “Beyond the basics” section below.

Figure 2: A sequence diagram that has incoming and outgoing messages


Notice that in Figure 2 the diagram’s label begins with the letters “sd,” for Sequence Diagram. When using a frame element to enclose a diagram, the diagram’s label needs to follow the format of:

Diagram Type Diagram Name

The UML specification provides specific text values for diagram types (e.g., sd = Sequence Diagram, activity = Activity Diagram, and use case = Use Case Diagram).

The basicsThe main purpose of a sequence diagram is to define event sequences that result in some desired outcome. The focus is less on messages themselves and more on the order in which messages occur; nevertheless, most sequence diagrams will communicate what messages are sent between a system’s objects as well as the order in which they occur. The diagram conveys this information along the horizontal and vertical dimensions: the vertical dimension shows, top down, the time sequence of messages/calls as they occur, and the horizontal dimension shows, left to right, the object instances that the messages are sent to.

LifelinesWhen drawing a sequence diagram, lifeline notation elements are placed across the top of the diagram. Lifelines represent either roles or object instances that participate in the sequence being modeled.1 Lifelines are drawn as a box with a dashed line descending from the center of the bottom edge (Figure 3). The lifeline’s name is placed inside the box.

Figure 3: An example of the Student class used in a lifeline whose instance name is freshman

The UML standard for naming a lifeline follows the format of:

Instance Name : Class Name

In the example shown in Figure 3, the lifeline represents an instance of the class Student, whose instance name is freshman. Note that, here, the lifeline name is underlined. When an underline is used, it means that the lifeline represents a specific instance of a class in a sequence diagram, and not a particular kind of instance (i.e., a role). In a future article we’ll look at structure modeling. For now, just observe that sequence diagrams may include roles (such as buyer and seller) without specifying who plays those roles (such as Bill and Fred). This allows diagram


reuse in different contexts. Simply put, instance names in sequence diagrams are underlined; roles names are not.

Our example lifeline in Figure 3 is a named object, but not all lifelines represent named objects. Instead a lifeline can be used to represent an anonymous or unnamed instance. When modeling an unnamed instance on a sequence diagram, the lifeline’s name follows the same pattern as a named instance; but instead of providing an instance name, that portion of the lifeline’s name is left blank. Again referring to Figure 3, if the lifeline is representing an anonymous instance of the Student class, the lifeline would be: “ Student.” Also, because sequence diagrams are used during the design phase of projects, it is completely legitimate to have an object whose type is unspecified: for example, “freshman.”

MessagesThe first message of a sequence diagram always starts at the top and is typically located on the left side of the diagram for readability. Subsequent messages are then added to the diagram slightly lower then the previous message.

To show an object (i.e., lifeline) sending a message to another object, you draw a line to the receiving object with a solid arrowhead (if a synchronous call operation) or with a stick arrowhead (if an asynchronous signal). The message/method name is placed above the arrowed line. The message that is being sent to the receiving object represents an operation/method that the receiving object’s class implements. In the example in Figure 4, the analyst object makes a call to the system object which is an instance of the ReportingSystem class. The analyst object is calling the system object’s getAvailableReports method. The system object then calls the getSecurityClearance method with the argument of userId on the secSystem object, which is of the class type SecuritySystem.2

Figure 4: An example of messages being sent between objects

Besides just showing message calls on the sequence diagram, the Figure 4 diagram includes return messages. These return messages are optional; a return message is drawn as a dotted line with an open arrowhead back to the originating lifeline, and above this dotted line you place the return value from the operation. In Figure 4 the secSystem object returns userClearance to the system object when the getSecurityClearance method is called. The system object returns availableReports when the getAvailableReports method is called.

Again, the return messages are an optional part of a sequence diagram. The use of return messages depends on the level of detail/abstraction that is being modeled. Return messages are useful if finer detail is required; otherwise,


the invocation message is sufficient. I personally like to include return messages whenever a value will be returned, because I find the extra details make a sequence diagram easier to read.

When modeling a sequence diagram, there will be times that an object will need to send a message to itself. When does an object call itself? A purist would argue that an object should never send a message to itself. However, modeling an object sending a message to itself can be useful in some cases. For example, Figure 5 is an improved version of Figure 4. The Figure 5 version shows the system object calling its determineAvailableReports method. By showing the system sending itself the message “determineAvailableReports,” the model draws attention to the fact that this processing takes place in the system object.

To draw an object calling itself, you draw a message as you would normally, but instead of connecting it to another object, you connect the message back to the object itself.

Figure 5: The system object calling its determineAvailableReports method

The example messages in Figure 5 show synchronous messages; however, in sequence diagrams you can model asynchronous messages, too. An asynchronous message is drawn similar to a synchronous one, but the message’s line is drawn with a stick arrowhead, as shown in Figure 6.


Figure 6: A sequence diagram fragment showing an asynchronous message being sent to instance2

GuardsWhen modeling object interactions, there will be times when a condition must be met for a message to be sent to the object. Guards are used throughout UML diagrams to control flow. Here, I will discuss guards in both UML 1.x as well as UML 2.0. In UML 1.x, a guard could only be assigned to a single message. To draw a guard on a sequence diagram in UML 1.x, you placed the guard element above the message line being guarded and in front of the message name. Figure 7 shows a fragment of a sequence diagram with a guard on the message addStudent method.

Figure 7: A segment of a UML 1.x sequence diagram in which the addStudent message has a guard

In Figure 7, the guard is the text “[pastDueBalance = 0].” By having the guard on this message, the addStudent message will only be sent if the accounts receivable system returns a past due balance of zero. The notation of a guard is very simple; the format is:

[Boolean Test]


For example,

[pastDueBalance = 0]

Combined fragments (alternatives, options, and loops)In most sequence diagrams, however, the UML 1.x “in-line” guard is not sufficient to handle the logic required for a sequence being modeled. This lack of functionality was a problem in UML 1.x. UML 2 has addressed this problem by removing the “in-line” guard and adding a notation element called a Combined Fragment. A combined fragment is used to group sets of messages together to show conditional flow in a sequence diagram. The UML 2 specification identifies 11 interaction types for combined fragments. Three of the eleven will be covered here in “The Basics” section, two more types will be covered in the “Beyond The Basics” section, and the remaining six I will leave to be covered in another article. (Hey, this is an article, not a book. I want you to finish this piece in one day!)

AlternativesAlternatives are used to designate a mutually exclusive choice between two or more message sequences.3 Alternatives allow the modeling of the classic “if then else” logic (e.g., if I buy three items, then I get 20% off my purchase; else I get 10% off my purchase).

As you will notice in Figure 8, an alternative combination fragment element is drawn using a frame. The word “alt” is placed inside the frame’s namebox. The larger rectangle is then divided into what UML 2 calls operands.4 Operands are separated by a dashed line. Each operand is given a guard to test against, and this guard is placed towards the top left section of the operand on top of a lifeline.5 If an operand’s guard equates to “true,” then that operand is the operand to follow.


Figure 8: A sequence diagram fragment that contains an alternative combination fragment


As an example to show how an alternative combination fragment is read, Figure 8 shows the sequence starting at the top, with the bank object getting the check’s amount and the account’s balance. At this point in the sequence the alternative combination fragment takes over. Because of the guard “[balance >= amount],” if the account’s balance is greater than or equal to the amount, then the sequence continues with the bank object sending the addDebitTransaction and storePhotoOfCheck messages to the account object. However, if the balance is not greater than or equal to the amount, then the sequence proceeds with the bank object sending the addInsuffientFundFee and noteReturnedCheck message to the account object and the returnCheck message to itself. The second sequence is called when the balance is not greater than or equal to the amount because of the “[else]” guard. In alternative combination fragments, the “[else]” guard is not required; and if an operand does not have an explicit guard on it, then the “[else]” guard is to be assumed.

Alternative combination fragments are not limited to simple “if then else” tests. There can be as many alternative paths as are needed. If more alternatives are needed, all you must do is add an operand to the rectangle with that sequence’s guard and messages.

OptionThe option combination fragment is used to model a sequence that, given a certain condition, will occur; otherwise, the sequence does not occur. An option is used to model a simple “if then” statement (i.e., if there are fewer than five donuts on the shelf, then make two dozen more donuts).

The option combination fragment notation is similar to the alternation combination fragment, except that it only has one operand and there never can be an “else” guard (it just does not make sense here). To draw an option combination you draw a frame. The text “opt” is placed inside the frame’s namebox, and in the frame’s content area the option’s guard is placed towards the top left corner on top of a lifeline. Then the option’s sequence of messages is placed in the remainder of the frame’s content area. These elements are illustrated in Figure 9.


Figure 9: A sequence diagram fragment that includes an option combination fragment

Reading an option combination fragment is easy. Figure 9 is a reworking of the sequence diagram fragment in Figure 7, but this time it uses an option combination fragment because more messages need to be sent if the student’s past due balance is equal to zero. According to the sequence diagram in Figure 9, if a student’s past due balance equals zero, then the addStudent, getCostOfClass, and chargeForClass messages are sent. If the student’s past due balance does not equal zero, then the sequence skips sending any of the messages in the option combination fragment.

The example Figure 9 sequence diagram fragment includes a guard for the option; however, the guard is not a required element. In high-level, abstract sequence diagrams you might not want to specify the condition of the option. You may simply want to indicate that the fragment is optional.

LoopsOccasionally you will need to model a repetitive sequence. In UML 2, modeling a repeating sequence has been


improved with the addition of the loop combination fragment.

The loop combination fragment is very similar in appearance to the option combination fragment. You draw a frame, and in the frame’s namebox the text “loop” is placed. Inside the frame’s content area the loop’s guard6 is placed towards the top left corner, on top of a lifeline. Then the loop’s sequence of messages is placed in the remainder of the frame’s content area. In a loop, a guard can have two special conditions tested against in addition to the standard Boolean test. The special guard conditions are minimum iterations written as “minint = [the number]” (e.g., “minint = 1”) and maximum iterations written as “maxint = [the number]” (e.g., “maxint = 5”). With a minimum iterations guard, the loop must execute at least the number of times indicated, whereas with a maximum iterations guard the number of loop executions cannot exceed the number.

Figure 10: An example sequence diagram with a loop combination fragment (click to enlarge)

The loop shown in Figure 10 executes until the reportsEnu object’s hasAnotherReport message returns false. The loop in this sequence diagram uses a Boolean test to verify if the loop sequence should be run. To read this diagram, you start at the top, as normal. When you get to the loop combination fragment a test is done to see if the value hasAnotherReport equals true. If the hasAnotherReport value equals true, then the sequence goes into the loop fragment. You can then follow the messages in the loop as you would normally in a sequence diagram


Beyond the basics

I’ve covered the basics of the sequence diagram, which should allow you to model most of the interactions that will take place in a common system. The following section will cover more advanced notation elements that can be used in a sequence diagram.

Referencing another sequence diagramWhen doing sequence diagrams, developers love to reuse existing sequence diagrams in their diagram’s sequences.7 Starting in UML 2, the ”Interaction Occurrence” element was introduced. The addition of interaction occurrences is arguably the most important innovation in UML 2 interactions modeling. Interaction occurrences add the ability to compose primitive sequence diagrams into complex sequence diagrams. With these you can combine (reuse) the simpler sequences to produce more complex sequences. This means that you can abstract out a complete, and possibly complex, sequence as a single conceptual unit.

An interaction occurrence element is drawn using a frame. The text “ref” is placed inside the frame’s namebox, and the name of the sequence diagram being referenced is placed inside the frame’s content area along with any parameters to the sequence diagram. The notation of the referenced sequence diagram’s name follows the pattern of:

sequence diagram name[(arguments)] [: return value]

Two examples:

1. Retrieve Borrower Credit Report(ssn) : borrowerCreditReport

or

2. Process Credit Card(name, number, expirationDate, amount : 100)

In example 1, the syntax calls the sequence diagram called Retrieve Borrower Credit Report and passes it the parameter ssn. The Retreive Borrower Credit Report sequence returns the variable borrowerCreditReport.

In example 2, the syntax calls the sequence diagram called Process Credit Card and passes it the parameters of name, number, expiration date, and amount. However, in example 2 the amount parameter will be a value of 100. And since example 2 does not have a return value labeled, the sequence does not return a value (presumably, the sequence being modeled does not need the return value).


Figure 11: A sequence diagram that references two different sequence diagrams

Figure 11 shows a sequence diagram that references the sequence diagrams “Balance Lookup” and “Debit Account.” The sequence starts at the top left, with the customer sending a message to the teller object. The teller object sends a message to the theirBank object. At that point, the Balance Lookup sequence diagram is called, with the accountNumber passed as a parameter. The Balance Lookup sequence diagram returns the balance variable. Then the option combination fragment’s guard condition is checked to verify the balance is greater then the amount variable. In cases where the balance is greater than the amount, the Debit Account sequence diagram is called, passing it the accountNumber and the amount as parameters. After that sequence is complete, the withdrawCash message returns cash to the customer.

It is important to notice in Figure 11 that the lifeline of theirBank is hidden by the interaction occurrence Balance Lookup. Because the interaction occurrence hides the lifeline, that means that the theirBank lifeline is referenced in the “Balance Lookup” sequence diagram. In addition to hiding the lifeline in the interaction occurrence, UML 2 also specifies that the lifeline must have the same theirBank in its own “Balance Lookup” sequence.

There will be times when you model sequence diagrams that an interaction occurrence will overlap lifelines that are not referenced in the interaction occurrence. In such cases the lifeline is shown as a normal lifeline and is not hidden by the overlapping interaction occurrence.


In Figure 11, the sequence references the “Balance Lookup” sequence diagram. The “Balance Lookup” sequence diagram is shown in Figure 12. Because the example sequence has parameters and a return value, its label —located in the diagram’s namebox—follows a specific pattern:

Diagram Type Diagram Name [(Parameter Type : Parameter Name)] :

[: Return Value Type]

Two examples:

1. SD Balance Lookup(Integer : accountNumber) : Real

or

2. SD Available Reports(Financial Analyst : analyst) : Reports

Figure 12 illustrates example 1, in which the Balance Lookup sequence uses parameter accountNumber as a variable in the sequence, and the sequence diagram shows a Real object being returned. In cases such as this, where the sequence returns an object, the object being returned is given the instance name of the sequence diagram.

Figure 12: A sequence diagram that takes the parameter of accountNumber and returns a Real object

Figure 13 illustrates example 2, in which a sequence takes a parameter and returns an object. However, in Figure 13 the parameter is used in the sequence’s interaction.


Figure 13: A sequence diagram that uses its parameter in its interaction and returns a Reports object

GatesThe previous section showed how to reference another sequence diagram by passing information through parameters and return values. However, there is another way to pass information between sequence diagrams. Gates can be an easy way to model the passing of information between a sequence diagram and its context. A gate is merely a message that is illustrated with one end connected to the sequence diagram’s frame’s edge and the other end connected to a lifeline. A reworking of Figures 11 and 12 using gates can be seen in Figures 14 and 15. The example diagram in Figure 15 has an entry gate called getBalance that takes the parameter of accountNumber. The getBalance message is an entry gate, because it is the arrowed line that is connected to the diagram’s frame with the arrowhead connected to a lifeline. The sequence diagram also has an exit gate that returns the balance variable. The exit gate is known, because it’s a return message that is connected from a lifeline to the diagram’s frame with the arrowhead connected to the frame.


Figure 14: A reworking of Figure 11, using gates this time

Figure 15: A reworking of Figure 12, using gates this time


Combined fragments (break and parallel)In the “basics” section presented earlier in this paper, I covered the combined fragments known as “alternative,” “option,” and “loop.” These three combined fragments are the ones most people will use the most. However, there are two other combined fragments that a large share of people will find useful – break and parallel.

BreakThe break combined fragment is almost identical in every way to the option combined fragment, with two exceptions. First, a break’s frame has a namebox with the text “break” instead of “option.” Second, when a break combined fragment’s message is to be executed, the enclosing interaction’s remainder messages will not be executed because the sequence breaks out of the enclosing interaction. In this way the break combined fragment is much like the break keyword in a programming language like C++ or Java.


Figure 16: A reworking of the sequence diagram fragment from Figure 8, with the fragment using a break instead of an alternative

Breaks are most commonly used to model exception handling. Figure 16 is a reworking of Figure 8, but this time Figure 16 uses a break combination fragment because it treats the balance < amount condition as an exception instead of as an alternative flow. To read Figure 16, you start at the top left corner of the sequence and read down. When the sequence gets to the return value “balance,” it checks to see if the balance is less than the amount. If the balance is not less than the amount, the next message sent is the addDebitTransaction message, and the sequence continues as normal. However, in cases where the balance is less than the amount, then the sequence enters the break combination fragment and its messages are sent. Once all the messages in the break combination have been sent, the sequence exits without sending any of the remaining messages (e.g., addDebitTransaction).

An important thing to note about breaks is that they only cause the exiting of an enclosing interaction’s sequence and not necessarily the complete sequence depicted in the diagram. In cases where a break combination is part of an alternative or a loop, then only the alternative or loop is exited.

ParallelToday’s modern computer systems are advancing in complexity and at times perform concurrent tasks. When the processing time required to complete portions of a complex task is longer than desired, some systems handle parts of the processing in parallel. The parallel combination fragment element needs to be used when creating a sequence diagram that shows parallel processing activities.

The parallel combination fragment is drawn using a frame, and you place the text “par” in the frame’s namebox. You then break up the frame’s content section into horizontal operands separated by a dashed line. Each operand in the frame represents a thread of execution done in parallel.


Figure 17: A microwave is an example of an object that does two tasks in parallel

While Figure 17 may not illustrate the best computer system example of an object doing activities in parallel, it offers an easy-to-understand example of a sequence with parallel activities. The sequence goes like this: A hungryPerson sends the cookFood message to the oven object. When the oven object receives that message, it sends two messages to itself at the same time (nukeFood and rotateFood). After both of these messages are done, the hungryPerson object is returned yummyFood from the oven object.

ConclusionThe sequence diagram is a good diagram to use to document a system’s requirements and to flush out a system’s design. The reason the sequence diagram is so useful is because it shows the interaction logic between the objects in the system in the time order that the interactions take place.

References

● UML 2.0 Superstructure Final Adopted Specification (Chapter 8 in particular) http://www.omg.org/cgi-bin/doc?ptc/2003-08-02

● UML 2 Sequence Diagram Overview http://www.agilemodeling.com/artifacts/sequenceDiagram.htm ● UML 2 Tutorial http://www.omg.org/news/meetings/workshops/UML%202003%20Manual/Tutorial7-


Hogg.pdf

Notes 1 In fully modeled systems the objects (instances of classes) will also be modeled on a system’s class diagram.

2 When reading this sequence diagram, assume that the analyst has already logged into the system.

3 Please note that it is indeed possible for two or more guard conditions attached to different alternative operands to be true at the same time, but at most only one operand will actually occur at run time (which alternative “wins” in such cases is not defined by the UML standard).

4 Although operands look a lot like lanes on a highway, I specifically did not call them lanes. Swim lanes are a UML notation used on activity diagrams. Please refer to The Rational Edge’s earlier article about Activity Diagrams.

5 Usually, the lifeline to which the guard is attached is the lifeline that owns the variable that is included in the guard expression.

6 As with the option combination fragment, the loop combination fragment does not require that a guard condition be placed on it.

7 It’s possible to reuse a sequence diagram of any type (e.g. programming or business). I just find that developers like to functionally break down their diagrams more.

About the authorDonald Bell is an IT Specialist in IBM Global Services, where he works with IBM's customers to design and develop J2EE based software solutions.



Comments?


Search help

Performance testing Java servlet-based Web applications: A guide for software test engineers

Contents:Step 1: Understand what’s special about servlet performance

Step 2: Consider performance test factors before testing the servlet

Step 3: Planning the tests

Step 4: Executing the Tests

Closing thoughts

References

Notes

About the author

Rate this article



Len DiMaggioSoftware QE Engineer and Manager, IBM30 0 2004

From The Rational Edge: As testing expert DiMaggio walks readers through the ins and outs of performance testing for applications built with Java servlets, he makes special note of ways that servlets’ distinctive characteristics can affect overall application performance.

This article is one in an ongoing series of “recipes” for testing various types of software. The goals of each article are to help testers understand issues that affect assessment of the target software and to provide specific, step-by-step instructions for thorough testing. In other words, my purpose is to describe the “whats, whys, and hows” of testing.

People use the phrase “speed kills” to warn drivers about the dangers of excess speed. When it comes to Web applications, however, it’s a lack of speed that can be fatal.

A few years ago, when using the ’Net or Web was still a novelty, people were often willing to tolerate slow response times when viewing static text or playing with cute applets. Today, however, we all rely on rapid responses from Web applications for business, scientific, research, and, of course, entertainment purposes. And, we’re not just viewing static text anymore. Now, we’re accessing application servers and databases and moving


large quantities of data over the ’Net.

Now, another popular expression applies to the performance of Web applications: “People vote with their feet.” Traditionally, this has meant that people will physically walk away from an unsatisfactory situation; in the Web applications world, it means that if you make clients wait, they’ll take their business elsewhere. Accordingly, performance testing1 should be a significant piece of your Web application testing. You won’t be successful if you try to do it as an afterthought or last-minute fire drill. Your Web application’s ability to respond quickly to clients—and handle ever-increasing numbers of them—will play a major role in the success of both your application and your business overall.

This article describes a step-by-step approach for testing a Java servlet-based Web application’s performance. The first step is to understand performance-related issues that affect Java servlets.

Step 1: Understand what’s special about servlet performance

Let’s begin by examining some basic information about servlets. The Java Servlet Specification2 defines a servlet as a:

…Java technology based Web component, managed by a container, that generates dynamic content. Like other Java-based components, servlets are platform independent Java classes that are compiled to platform neutral bytecode that can be loaded dynamically into and run by a Java enabled Web server. Containers, sometimes called “servlet engines,” are Web server extensions that provide servlet functionality. Servlets interact with Web clients via a request/response paradigm implemented by the servlet container…

There’s quite a bit of information in this paragraph. Let’s take a look at the key points from a performance testing perspective. Servlets have characteristics that are different from those of other types of programs (such as standalone Java applications), and these characteristics have implications for performance testing:

● Servlets are managed by a container. This is a major difference between servlets and standalone Java applications, because the performance of any servlet is directly affected by the performance of its container. To do performance testing on servlets, you have to understand servlets’ container configuration and operation, including how (and how well) the container integrates with other software, such as databases.

● Servlets are run by a Java-enabled Web server. This is another major difference between servlets and standalone Java applications. For performance testing, you must take into account the performance and configuration of the Web server, and also deal with applications whose configurations are distributed across multiple servlets and multiple servers.

● Servlets are in the Middle Tier of multi-tier J2EE applications. The Java 2 platform, Enterprise Edition (J2EE) supports the creation of multi-tier, distributed applications written via Java extension APIs (e.g., the servlet API) and executed within a runtime infrastructure implemented via containers. Such applications are divided into “components” that run on different physical systems, based on the functions they perform. The J2EE application model is typically represented with three or four tiers, with servlets in the Web Tier portion of the Middle Tier:

❍ Client Tier. These components are the Web clients (applets or other pages accessed via a browser) or Java applications running on client systems. The clients are typically “thin” in design; most data


processing tasks are performed by the servers.❍ Middle Tier. This tier is sometimes divided into two other tiers:

■ Web Tier. These components are the servlet and Java Server Pages (JSP) containers3 that run on the J2EE server systems.

■ Application (or Business Logic) Tier. These components are used to access (e.g., via Enterprise Java Beans [EJBs]) databases and other Enterprise Information Systems (EISs).

❍ Back-End (Data or EIS) Tier. The EISs in this tier may be database servers or other legacy systems.

Figure 1 shows how these tiers are configured in the J2EE platform.

Figure 1: Simplified view of tiers in the J2EE platform

(Based on graphics in the Sun Java Spec (Java) Servlet Specification http://java.sun.com/products/servlet)

● Servlets generate dynamic content. One constant in the ever-changing world of Internet software is the need to supply more and more dynamic content. You can still display static text content on Web sites, but increasingly, most Web content is generated dynamically, based on user/customer-specific profiles, requests, and so on. This data is likely stored in databases, so performance testing should verify how efficiently a servlet under test can access its databases.

● Servlets implement a request/response model. Unlike other protocols, HTTP does not maintain a single live virtual circuit’s “state” between clients and servers. Instead, it’s a stateless protocol that establishes and tears down connections as needed and implements reliable communications via a request/response4 mechanism. Because the protocol doesn’t maintain a state, the servlet itself must maintain user session information. The mechanisms used to store this information (e.g., in a remote database) may affect the servlet’s performance and have to be considered in planning performance tests.

● Servlets are meant to run unattended for extended periods. Unlike programs designed to run for brief periods and then close, servlets are designed to run unattended and stay running. For performance testing, this means that your tests should verify the servlet’s longevity—in other words, its performance over time.


And these tests should not only verify the functional operation of the servlet, but also determine how it makes use of available system resources, such as system memory.

Before we consider specific performance tests for servlets, our next step is to examine how some basic software performance test set-up issues apply to servlets.

Step 2: Consider performance test factors before testing the servlet

In planning performance tests for any type of software, you should consider factors such as the testing environment and the optimum testing sequence. The following subsections describe how these factors affect servlets and include checklists highlighting issues of particular importance.

Vetting the test environment

An integral part of performance testing for any networked software is measuring the speed with which data is transmitted between clients and servers, between two or more servers, and so on. This is especially true for servlet testing, as J2EE supports the creation of multitier, distributed applications whose servlets may have to access multiple remote servers (e.g., database servers).

Your goal, in short, is to ensure that the operational characteristics of your test network provide a controlled environment that will not skew your test results or become a gating factor in test execution. In other words, you want the test network to function as the platform for running the tests; and you don’t want to use the tests to debug your network.

The best test networks are physically separate from all other network traffic. You can construct such a network with dedicated routers, cables, DNS servers, PC domain controllers, and so on. You should also verify that the media you use can physically support the level of traffic you want to test for.

However, if you have limited networking (and financial) resources, you may not be able to execute all of your performance tests on a dedicated and physically separate network. The next-best alternative is to create a virtually separate test network by subnetting the physical network. First, verify that this virtual network is free of any traffic not generated by your tests; use the Unix “snoop” utility to listen in on traffic going “over the wire” before you start to run your tests.

Also, do not limit your vetting of the test environment to network hardware. Certain software-related factors can adversely affect performance tests. Here are some things to watch for:

● Virus scanning. The servlet under test, or any of its supporting software, may create files as it runs. If the scanning function for new files is enabled, then each of these newly created files will be scanned. If large numbers of files (e.g., temporary journal files to track individual transactions) are created, then such scanning can have a significant impact on performance. Should you therefore run performance tests with virus scanning disabled? It depends on the configurations your clients will use. Some servers (e.g., a servlet container server) will always run with virus scanning enabled, whereas others (e.g., Web servers to which content is deployed on a real-time basis) will run with it disabled.

● Shared directories/file systems. Remember how the space creatures in the movie “Alien” used human bodies as hosts? You should verify that your test servers aren’t hosting shared directories or networked file


systems. If your servers are storing/updating large chunks of data, that may affect your performance tests.● Default configurations: One size does not fit all. When you’re working with a system composed of

multiple integrated subsystems, it can be very tempting to try using standard, default configuration settings for the software with which your servlet must integrate. Unfortunately, this can have an adverse impact on the servlet’s performance. Earlier I pointed out that overly detailed logging level settings can negatively affect performance. Often, relying on the default logging setting for a servlet’s or container’s database will result in too much information being written to disk files; also, the default security level may require that every HTTP request be reauthenticated. Either of these situations can cause performance problems. Setting up a complex, integrated system can be a difficult task: You must wade through configuration data for each subsystem and determine which combinations of values will result in the best end-to-end performance for the system as a whole. However, this is the only way to ensure that the system is really performing according to requirements.

Checking for problems and making corrections in the test environment

Here’s a brief description of aspects of the test environment that you’ll want to check.

● Routing. Remember: A distinguishing characteristic of servlets is that they generate dynamic content. So the speed with which the servlet under test is able to access its database is important to its overall performance. Another distinguishing characteristic is that servlets are run by Java-enabled Web servers and can be configured into a distributed architecture. So inefficient routing can also affect servlet performance. Before you run any tests, you’ll want to verify that the network configuration is not routing traffic through convoluted paths and extraneous “hops” that cause communication delays between clients and servers, or servlets and their supporting database servers. To do this, use the Unix “traceroute” or Windows “tracert” utility, and trace through the routes in both directions.

● Logging. Set logging at a high level, because servers, servlet containers, Web servers, and other system components can negatively impact servlet performance by either slowing down the servlet itself or tying up system resources. However, remember that servlets are managed by a container, and excessively high logging configuration settings for the container can adversely affect the servlet’s performance. But don’t turn off the container’s logging. That might boost performance but also create an unsupportable configuration: If something goes wrong, you won’t be able to find and debug the cause of the problem. Instead, set the logging at the level that your customers will likely use in their production environments.

● Automatic software updates. As we noted above, servlets are designed to run unattended for extended periods, so your tests will have to run for extended periods as well. However, do not run these tests unattended. In some instances, test servers may perform scheduled automatic software updates (e.g., for OS updates or antivirus) during the extended tests. Some of these will likely be very large and may slow down the servers by tying up system resources. If you see this happening, you might want to intervene manually and de-configure the updates until the test run is complete.

● Configuring memory. When you run a Java program, unless you specify how much memory the Java Virtual Machine (JVM) should make available for it, then the JVM will use its default value. This value will vary according to the version of the JVM: For JDK 1.2, the default was 16 MB; for JDK 1.4, the value is 64 MB. What value should you use for performance testing? Allocating additional memory will probably improve the servlet’s performance, but you do not want to run tests in a larger configuration than your customers will use. It is safest not to depend on the default value—which may be different on different systems—and instead to explicitly set the memory limit in the servlet’s Web server and container configuration files. You can do this with the “-mxNNNm” option. For example, the syntax


java –mx128m <program name>

will set the upper limit at 128MB.

If you want to find the default memory heap value for your servlet’s test systems, the program5 shown in Figure 2 can help.

Figure 2: Program to help discover the default heap value for a servlet’s test systems

The program displays total and free memory and creates a byte array as large as the total amount of free memory. Each time this buffer is created, it gets added to a vector, so the space it uses cannot be reclaimed by the garbage collector. As a result, the program eventually encounters an out-of-memory exception and exits.

Figure 3 shows sample output from the program shown in Figure 2.


Figure 3: Sample output from program in Figure 2

Why you must understand the “hows”

It’s possible to execute some types of functional software testing by only mapping inputs to outputs, without any real understanding of the software’s internal workings. It’s tougher to tie inputs to outputs for performance testing, as you’re not looking merely to verify that a function returns a specific value; you’re also looking to quantify how fast the function can do that.

For example, let’s say you observe that the servlet under test seems to process XML input much more slowly than it processes plain text. You can confirm this to some extent by running tests with various types of inputs and timing the results, but unless you know exactly how the servlet is processing its inputs, you won’t be able to know why you’re seeing that slower throughput. Maybe it’s because both the client and the servlet are conversions between XML documents and data objects. Maybe it’s because inefficient XML parsers are being used. Or maybe the servlet’s logic is just plain convoluted when it comes to dealing with XML. All of these are valid hypotheses, but you won’t be able to prove any of them unless you understand what’s really going on “under the hood” of the servlet.

Looking at performance tests as complex equations

Executing software tests that exercise an entire system, including performance tests, can be a bit like solving a complex algebraic equation. Components of the equation are the servlet under test and its associated servers, databases, and so on. First, define the variables and constants that make up the test network and the tests, then establish a repeatable pattern of test results by using one set of values for the variables and constants, and finally,


change one value and measure differences in the test results. For example, after you’ve determined that the servlet is able to support a level of throughput, increase the logging level on its database server and measure to what extent that affects throughput.

Avoid the temptation to change multiple test characteristics (i.e., equation variables) in a single run, which would make it much harder to identify cause and effect relationships between test inputs and results.

When to start performance testing

A common practice is to start performance testing only after functional, integration, and system testing are complete; that way, you know that the target software is “sufficiently sound and stable” to ensure valid performance test results.

However, the problem with this approach is that it delays performance testing until the latter part of the development lifecycle. Then, if the tests uncover performance-related problems, you’ll have to resolve problems with potentially serious design implications at a time when the corrections you make might invalidate earlier test results. In addition, your changes might destabilize the code just when you want to freeze it, prior to beta testing or the final release.

A better approach is to begin performance testing as early as you can, just as soon as any of your application components can support the tests. This will enable you to establish some early benchmarks against which you can measure performance as the components are developed. It is an especially apt way to begin testing a servlet; the multitier J2EE architecture may allow you to execute performance tests for all components in a single tier. Remember, however, that these tier-specific tests will not satisfy the need for end-to-end testing once the entire application is testable.

When to stop performance testing

The short answer is: maybe never.

The conventional approach is to stop testing once you have executed all planned tests and can see a consistent, reliable pattern of performance. This approach gives you accurate performance information at that instant in time. However, you can quickly fall behind by just standing still.6 The environment in which clients will run your servlet will always be changing, so it’s a good idea to run ongoing performance tests.

Undoubtedly, you’ll run performance tests whenever you create new versions of the servlet. However, your clients, will likely install new versions of software in their environment (e.g., patches or other updates to their operating system, databases, Java JREs, and servlet container software) on schedules that are not in sync with your own servlet release schedule. It makes sense to monitor these changes and periodically revisit—and reexecute—your servlet performance tests.

Another alternative is to set up a continual performance test and periodically examine the results. You can “overload” these tests by making use of real world conditions. Of course, regardless of how well you plan, construct, and vet your “clean” in-house test network, you’ll never be able to reproduce all the conditions that your servlet will have to contend with in the real-world Internet environment: intermittent delays between servlets and their supporting database when misconfigured routers make dynamic routing changes; spikes in network


traffic when news sites are bombarded by users during international incidents; and so forth. However, you can configure a reasonable test by dispersing the various components in your application across multiple, physically separate servers, establishing and maintaining a constant but low level of traffic, and monitoring the results over time.

Step 3: Planning the tests

So much for how to start and end the testing; now it’s time to talk about what tests to run. The following sections describe various types of servlet performance tests.

A common thread: Measure servlet longevity

Although each type of performance test is different, they share a common thread: They measure specific aspects of how well the servlet under test can perform if it runs unattended for an extended period. As we noted at the beginning of this article, running unattended is a factor that distinguishes servlets from other types of programs. Once a servlet is instantiated and loaded by its container, it remains available to service requests until it is either made unavailable or until the servlet container is stopped. The application supported by the servlet should always be “on”— that is, it should be capable of running unattended 24/7.

One measure of longevity is whether performance is consistent over time. Does throughput start off at one level but then degrade over time? If so, the servlet may be experiencing a memory leak, or the servlet (or other application components) may be consuming excessive system resources, which adversely affects performance. We’ll discuss more about servlet longevity as we describe various performance tests below, and we’ll return to the issue of measuring system resource consumption in a later section.

Measure the data movement rate

The primary measurement you’ll likely look for from performance or throughput tests is the rate at which the servlet can accept, process, and serve data. I mentioned earlier how the overall performance of the servlet will be affected by the configuration and performance of its container and Web server(s). You’ll want to run capacity tests, applying increasing levels of usage/traffic and measuring the servlet’s throughput. But what else should you do?

See how variations in test data affect performance. I described earlier the importance of understanding how the servlet under test processes data, as opposed to treating it as a black box into which you can “pour” input, extract output, and measure the results. When you execute throughput tests, you build on this understanding with varying sets of concrete data. For example:

● Data sizes. Are bottlenecks based on the number of bits being moved? On the number of discrete transactions (e.g., requests made to the servlet) that are performed? Which takes longer to process—a single 100-MB transaction, or one hundred 1-MB transactions?

● Data formats. Do different types of input files/data take more or less time to process? Are the bottlenecks caused by processing/converting some types of data? Earlier I referred to a hypothetical situation involving the processing of XML data. Do other types of supported input (e.g., HTML, comma separated values) result in greater or lesser delays? What about data types that may be unexpected, such as XML tags embedded in HTML files?


Find out where the servlet is really spending its time. It used to be that shipping was a large part of the cost of producing and delivering a product to market. Today, however, personnel costs are the biggest expense. (That’s why US and European manufactured goods are often assembled in cheaper labor markets, from domestically created components.) There’s a parallel situation when it comes to testing servlets: Throughput bottlenecks may not relate to the actual movement of data over a network, but rather to preparing and processing that data. When you build and run performance tests you will want to identify these bottlenecks by checking the following.

● Data collection. Is user input converted into a different form before it’s processed? For example, does the servlet’s client send requests to the servlet that include data in the form of serialized objects that the servlet converts to XML? Or does the client send the servlet a large STRING object that contains XML tags that must be parsed into objects by the servlet?

● Data aggregation and calculation. When the servlet responds to a request from a client, does it “fire off” a large number of requests to database or application servers? Remember: A distinguishing characteristic of servlets is that they generate dynamic content, so they will be accessing databases or other servers. Does the servlet under test have to wait for responses from slow servers? And once it receives those responses, is its logic so convoluted that it wastes time performing unnecessary calculations? Does it take a long time to determine whether it has received invalid input?

● Data reporting. In a Java-based model-view-control application architecture, JSPs are often the most efficient way to display output for users. Does the servlet make use of JSPs for output, or does it painstakingly generate its own output? Does the servlet have to perform all the data conversions that the client performed, but in reverse?

● Caching. Is the servlet caching commonly requested information, or is it recalculating everything, every time? Earlier, I described a scenario in which a test designer didn’t understand that his automated test was invalidated by caching, which the software under test was taking advantage of. In performance testing, you determine whether the servlet IS taking advantage of caching.

Measure system resource consumption

When you measure the level at which the servlet under test consumes system resources such as memory, you’d like to see that level remain constant when the traffic level remains constant, and rise or fall in relationship to changes in the traffic level, over time. You don’t want to see that resource usage level either increase in response to consistent traffic or consistently rise over time, regardless of the traffic level.

Which system resources should you be concerned with? Let’s carry forward the assumption that network capacity— the rate at which you can push bits “over the wire”—will not be in short supply. This is a fairly safe assumption, given the high physical capacity of most internal and Internet networks. What does this leave us to worry about? Memory quickly comes to mind (pardon my word play), but you should also think about disk capacity and I/O rates.

Memory: Make sure the “garbage collector” is working for your servlet. One of the JVM’s most useful features is its “garbage collector,” which analyzes memory to find objects that are no longer in use and deletes them to free up memory. In spite of the garbage collector’s best efforts, however, you can still have memory leaks in Java programs.

Let’s look at a little background information on garbage collection. The garbage collector works by looking for objects in memory that are no longer referenced. A running Java program contains threads, and each thread


executes methods. Each method, in turn, references objects via arguments or local variables. We refer to these references collectively as a “root” set of nodes. The garbage collector works through the objects in each node, the objects referenced in each node, the objects referenced by those nodes, and so on. All other objects on the “heap” (memory used by all JVM threads7) are tagged as unreachable and are therefore eligible for garbage collection. Memory leaks occur when objects are reachable but no longer in use.8

So far so good, but nothing here is unique to servlets. Any Java program can hit a memory leak, can’t it? Yes, in practice, a Java program that is invoked, runs for a short time, and exits, may include a memory leak. However, the program does not run long enough for that leak to grow very large, so even if the garbage collector does not run before the program exits, that is no great problem. In contrast, recall one of the distinguishing characteristics of servlets: They are meant to run unattended for extended periods. Accordingly, even a small memory leak can become a big problem for a servlet if the leak is allowed to grow over time.

When you do your testing, you’ll want to simulate real-world conditions in which the servlet under test will have to function 24/7. So you’ll have to establish a level of traffic between test clients and the servlet. Several tools (such as IBM Rational Robot) on the market can help you simulate user sessions. However, the client is not your main concern. What matters most is how the servlet reacts to a regular, sustained level of incoming requests.

To examine this, you can monitor memory usage in several ways. The easiest way is simply to use utilities supplied by the operating system. On Microsoft Windows, the Task Manager enables you to view total system memory in use as well as the memory being used by any single process. On Unix systems, similar tools such as “sar” (on Solaris), or “vmstat” (on BSD-based Unix flavors) or “top” will provide you with some basic measurements of memory usage. What you should check for is increases in memory usage by the servlet’s container to handle the client traffic—and instances in which the memory is never released by the container when the traffic stops. If you do locate a pattern or memory loss with these basic tools, then you can investigate further with more specialized tools such as IBM Rational Purify to identify the offending classes/methods.

Disk capacity and I/O rates. My in-laws are really wonderful folks but a bit quirky (who isn’t?): They never throw anything away. Some applications are like that, too. Unfortunately, this “pack rat” mentality can have an adverse effect on performance if it is unchecked. I’ve already mentioned that logging at too high a level can be a drain on performance. What else might cause problems for a servlet with “pack rat” tendencies?

Temporary files can cause problems. When you’re dealing with large amounts of data, it’s often a good idea to break it into more manageable pieces for processing or transmission, and then to reassemble it into a single (and large) mass only when necessary. Your servlet might work this way—that is, working with data in pieces and writing intermediate data to temporary work files to avoid saving it in memory. Building an application in this way provides an extra measure of auditing in the event that one or more servers used by the application fails while processing a transaction. If the intermediate data is made persistent, then the transactions can be reconstructed.

There are some potential problems with this approach, however. First, disk I/O operations take a toll on system performance; they can affect performance of the servlet simply because, even with today’s high-speed hard disks, accessing data on a disk is always slower than accessing data in memory. And sooner or later, those temporary files will have to be cleaned out. Having the servlet “clean up” after itself by deleting these files can further affect its performance.

Verify the efficiency of software integrations


Integration testing is becoming a more and more important class of testing, as companies increasingly make use of software components (commercial or open source) supplied by third parties. In planning performance tests for your servlet, you have to consider not only whether integrations function successfully (between the servlet and its container and/or Web server; between the container or Web server and other software; and between the servlet itself and supporting software such as databases), but also the efficiency with which they function.

Dealing with the databases. As I mentioned earlier, for a servlet to generate dynamic content, using flexible selection criteria to customize (or “personalize”) data for a specific user, the servlet must extract data from a persistent data store, most likely a database. The servlet’s throughput is naturally dependent on the efficiency with which the servlet works with the database. In planning and executing performance tests for the servlet, here are some problems to watch for.

● Permitting global queries. What type of SQL query do you run if you’re not exactly sure what you’re looking for? Something like “select * from tableName,” right? The database responds by sending you the entire contents of the table, and you can manually search through a huge amount of data for the piece of information you need. What happens if your servlet runs a query like this? Its performance will be degraded, as it has to process potentially very large amounts of data. What sorts of tests should you run to detect this problem? Actually, you may need to test the servlet’s client more than the servlet itself; you’ll want to verify that it is not easy for the servlet to request huge queries from the database. But what if you can’t prevent this from happening?

● Receiving too much data, even with a narrowly focused query. What if the servlet makes queries that, even though narrowly focused, still return too much data? Some time ago, I worked on a project with a servlet that controlled user creation of data objects and “tasks” that acted upon those objects. The data objects, task definitions, and task results, including logging information, were all made persistent in a database. After running tests for a while, we found a performance problem: When more than a few dozen tasks had been executed, the client seemed to hang when it displayed a summary table for all tasks. As it turned out, the problem was simply that when the user selected the program option to display the task information, the servlet responded by performing multiple queries to the database. Some of these queries—for example, queries for task execution logs—resulted in large amounts of data from the database. This was a serious scalability problem, as these tasks could be scheduled to run automatically (similar to a Unix system “cron job”). The solution was to modify the servlet to query the database only for subsets of the task-related data—just enough to fill one screen at a time. When the user traversed the task data by moving from screen to screen, new queries would be run. Modifying the servlet to take many small “bites” instead of a few big ones improved performance dramatically.

● Failing to reuse or close connections. Another potential database-related bottleneck that can adversely affect servlet performance is the time it takes for the servlet to actually log into the database. There may be no way to alter the actual speed with which the database will accept new connections, but the servlet can be modified to create and use those connections more efficiently. The servlet can pool and reuse the connections so that it isn’t constantly opening new connections every time it has to access the database. Also, the servlet can be written to ensure that connections are properly closed when they are no longer needed. Connections left open can tie up system and database resources and can be a drain on system performance (and therefore servlet performance). Figure 4 shows an example of a coding error (in pseudocode) that can result in connections being left open unnecessarily.


Figure 4: Faulty code that leaves connections open unnecessarily

If the SQL query on line 10 fails and the code exits, the database connection that was opened on line 2 will remain open until it times out or is closed by some database housekeeping routine.

Step 4: Executing the Tests

Now that we’ve discussed the “whats” and “whys” of performance testing servlet-based applications, it’s time to discuss the “hows.” An approach that I’ve found successful is to divide the execution of the tests into four stages:

● Stage 1: Verify the subsystems and perform low-impact aerobics.● Stage 2: Vary the equation #1: Load testing.● Stage 3: Vary the equation #2: Performance testing.● Stage 4: Conduct ongoing “health checks.”

Stage 1: Verify the subsystems and perform low-impact aerobics

How to begin? There’s a great temptation to approach performance testing in the same way that some people approach rental cars: “Let’s hit the gas and see how fast it can go!” This approach may sound like fun, but it will probably be unproductive. You may have a hard time reproducing the exact input conditions that result in failures and an even harder time determining the cause and effect relationships that affect end-to-end operation of the software under test. Instead of that approach, I recommend the following measures.

● Reexamine functional tests. Start by reexamining functional tests you run to verify the operation of the application’s individual subsystems. This approach involves looking at those subsystems in isolation to the greatest extent possible, and tracing through how the subsystems execute discrete transactions.


Functional tests are concerned with verifying that function X returns value Y. When you look at these tests in the context of performance tests, your concern is how (i.e., how efficiently) function X returns value Y. For example, if the function in question retrieves data from a database, and you run a test to return (three) records, the functional test will succeed. However, if retrieving the three records requires three separate queries to the database, and each query returns excess data, (recall the dangers of global database queries we discussed earlier), then the test will either fail or at least be marked as an area for further investigation.9 To identify potential program inefficiencies, you will want to trace individual transactions, initially through each of the application’s subsystems, including the servlet’s methods, and ultimately through the entire set of subsystems. This can be difficult detective work, especially if you don’t have access to the servlet’s or application’s source code or designers, or if the design is extremely complicated. Certain tools can help, such as IBM Rational Quantify, a tool that lets you profile the performance of your entire application, including subsystems for which you don’t have source code. Although it’s not platform independent, IBM Rational Quantify10 offers versions that run on both Windows and Unix systems, respectively.

● To stub or not to stub? As you reexamine subsystem functional tests, you’ll have to decide whether to replace some subsystems with stub routines. This allows you to verify those subsystems’ operation and performance in isolation, but it involves constructing test versions of the actual product’s subsystems. For example, the Web application that you’re testing may consist of a Java client and a Java servlet that connect to a database via EJBs. If you can stub out a test client that runs on the same server as the servlet, and also stub out the database access by accessing static test data stored in files, then you can concentrate on verifying how (and how well) the servlet processes data. So, should you do this? If you’re sure that the test subsystems that you construct can run cleanly, without introducing spurious bugs, then give it a try. If you’re successful, you’ll effectively resolve at least some of the variables in the performance testing equation.

● Perform low impact aerobics/verify longevity. What next? After you’ve traced though discrete transactions and verified the operation of the application’s subsystems in isolation, then it’s time to attack the application end-to-end and look at its longevity. As you recall, servlets are intended to run unattended for extended periods, so your goal is to verify that the application and its servlet(s) can sustain a low level of traffic over an extended time. You will assess how the application consumes system resources and otherwise operates during this time. Why should you start with a low level of traffic? To reduce the number of variables. If you start with a “big bang” of traffic, the servlet may fail, but it may be hard to determine the exact cause (e.g., it could be a memory leak,11 problems with multiple thread coordination, database record locking, etc.) and therefore hard to debug. With a “single thread” of traffic, you’ll be better able to connect causes and effects. What types of problems, other than memory leaks, disk usage, and database connections should you look for? It all depends on the design of the software under test, but you may find some silly things, such as counters that either never get reset or that fail when the transaction count gets too high.

Stage 2: Vary the Equation #1: Load Testing

What’s next? Once you’ve confirmed that the application can walk, it’s time to make it run.12 What you’ll do now is keep some elements (the test configuration) in the testing equation constant while you change other variables (the test data and number of simulated users).

Here’s the sequence of actions.


● First, define a test configuration and establish a baseline. The testing you’ve performed so far will have involved relatively low levels of traffic and users for extended time periods. To some extent, this testing will have verified that the application and servlets can run independently for a long time, but it will not provide a real basis/baseline against which to measure the application’s performance. Your first action should be to establish that baseline.

The inputs for doing this are the hardware and software test configuration, the test data, the traffic or usage level, and the time period for which you want to run the test. How do you decide on the “shape” of the data and the number of users for this baseline? You may be fortunate enough to be working on a project for which the operational load parameters, including the hardware configuration, are exactly defined and specific configurations are “recommended.” If this is the case, then the decisions are made for you. However, it’s more likely that the load test parameters will be less precisely defined; you’ll have to deal with “grey” areas and complete the definition yourself. Don’t try this on your own. Instead, make use of other resources; marketing personnel, for example, will understand the configurations the application should support, and pre-sales and post-sales support personnel will understand the configurations that clients actually use.

Be forewarned, though, that defining performance test configurations is sometimes an inexact science. Temptation can be strong to make decisions based on “gut” feel or a need to control configuration costs. Instead, you should gather information from multiple sources, make a decision based on the sum of that information, and then obtain “buy in” from all concerned parties. If this sounds difficult, well, it can be. But remember that a Java-servlet based application often encompasses multiple software components in addition to the servlet (the servlet container, databases, etc.) as well as multiple, potentially geographically separated, hardware servers.

● Vary the data and number of users, and compare results to your baseline. Once you’ve established a baseline, it’s time to alter the test conditions by varying the test data and the number and characteristics of your simulated users.

❍ Varying the test data. Part of the configuration you use to establish the test baseline consists of data that you pass to the target application. The “mix” you select for this data should be the best approximation possible of commonly used customer data. Most likely, your target clients will not use simply a single, static set of data; instead, their data will cover a whole ranges of values, sizes, formats, and so on.

Varying the test data will help you look for throughput problems if the application under test (and its servlets) cannot handle these ranges of data. As we discussed earlier, you may find that the gating factor in the application’s throughput is not the number of bits moved through the system, but the number of transactions. For example, a single transaction that moves 100 MB of data may run much faster than ten transactions moving 10 MB each. Likewise, the speed of data handling may depend on format. For example, plain text might be handled much faster that XML because the application is using inefficient parsers.

❍ Varying the number/characteristics of test users. When you ran the “low impact aerobics” tests, your goal was to verify how well the application and its servlets were able to handle a single user’s actions. Now, you want to start increasing the number of users. But wait! You can’t simply assume that all users will perform the same tasks. The Web application under test probably supports


multiple user actions. You’ll have to create classes of test users, distinguishing each class by the actions it performs.

In order to support these classes of tests, you’ll need corresponding classes of data. One approach to defining these classes of tests and test data is software test design methodology that involves dividing inputs and outputs into groups or “classes”; tests involving individual members of each group yield results within the same group. This methodology is known as “equivalence class partitioning.”13 For example, one class of users may perform complex queries, while another writes new records/data, and still another deletes existing records, and so on. You’ll have to perform tests with each class of users to establish baselines and then perform tests with multiple classes of users.

● Should you vary both data and users in the same test? Again, you should resist the temptation to make multiple, simultateous changes to variables in the performance test equation. It may seem like a good way to combine multiple actions into a single test, but you may then not be able to map the results to a single data or user change. If this happens, you’ll have to take a step back, reset the variables, and then change only one at a time.

Stage 3: Vary the equation #2: Performance testing

In executing load tests, you work with a single “recommended” configuration. Since it’s likely that the application under test supports multiple configurations, it’s important to execute tests at those configurations’ boundaries.

● Testing at the boundaries — minimal and maximal hardware. An obvious approach is to run tests on “minimal” and “maximal” configurations; the differentiating hardware characteristics are memory and CPU speed, and the differentiating software characteristrics are the versions of supporting utilities (e.g., databases).You’ll want to verify that the smallest (and cheapest!) configuration the application officially supports is actually usable. You’ll also want to quantify the application’s performance on an optimal configuration. Some customers are willing to pay for high-end hardware if their return on investment is superior performance. What other configurations should you verify?

● Testing at the boundaries — distributed subsystems. Remember: Java servlets are managed by a container and run via a Web server. Also, the application may comprise multiple servlets and Web servers, as well as other supporting software subsystems such as databases. All of this means that you have to consider the extent to which the application’s configuration is distributed across discrete servers in your performance testing. In this distributed context, a minimal configuration may mean using a smaller number of servers, and a maximal configuration may mean that the application’s subsystems are distributed across a large number of discrete, and potentially geographically separated, servers.

❍ Multiple subsystems sharing servers. If the application under test is aimed at target customers with a wide range of usage/capacity needs, then it will likely also support a wide range of configurations. At the low end, the application may support a configuration that allows many or all of its subsystems to be run on a single physical server. This trades off higher performance and capacity against lower cost and simplicity of installation, configuration, and maintenance. When you execute performance tests on this type of all-in-one configuration, you have to pay special attention to how the subsystems will share and compete for potentially scarce system resources, such as memory.


At one client site, we were running tests on a servlet that accessed a database, when we noticed that the size of the database process continued to grow in memory. This seemed strange, as the database was a well-known, off-the-shelf program. What we thought was a memory leak actually turned out to be a knowledge leak. We had overlooked the fact that the database could be configured to use either all the memory available or memory only up to a configured amount.

❍ One server per subsystem. When you execute tests on this type of “high-end” configuration, your focus shifts from assessing how well how the application’s subsystems compete for resources on any one server to assessing how well those subsytems can handle interserver communications. As we discussed earlier, before you begin testing with this type of configuration, it’s important to confirm that your test network isn’t the gating factor in limiting the application’s performance.

What types of tests should you execute after you verify that the network is a suitable base? Well, as is often the case in testing software, your first step is to tear apart what you just created. You may want to run tests that simulate server outages (simply power down a server or two), so that you can observe how well the application’s remaining subsystems react. Such outages will probably be more rare than instances in which a server is briefly unavailable because of network “glitches,” or when a server is so heavily loaded that it becomes an application bottleneck. In such conditions, you’ll want to “bounce” (i.e., restart) key subsystems (e.g., the servlet container’s Web server) or tie up system resources by running multiple copies of memory-intensive programs to starve other key subsystems. By performing such tests, you’ll assess how well the the application as a whole implements “retry” actions, as well as its ability to cope with real-world network conditions.

Stage 4: Ongoing “health checks”

Now you’re all done, right? Well, maybe not.

To ensure that the application can continue executing in an evolving environment with constant updates to operating systems, databases, Java JREs, and servlet container software, you might have to run periodic tests.

This is the final stage of the testing. As we noted earlier, these tests will verify that changes in software components on which the application relies don’t result in a general application failure. Remember, it’s easy to fall behind by just standing still!

Closing thoughts

Java servlets represent a significant milestone in the evolution of Internet-based software. Their use is widespread today and will continue to grow. Odds are that if you’re working with Internet software, then you’re working with servlets. And, if you’re testing servlets, the odds are very good that you’ll be verifying their ability to support high-performance and high-capacity Web applications.

When you plan and execute performance tests for a Java servlet-based application, you should take into account more than just the “generic” factors that impact performance testing for any type of software (e.g., spurious traffic). Also consider servlet-specific factors that will affect the application. Although these factors enable the application to perform specific tasks, such as generating dynamic output, they may also constrain the servlet’s performance (e.g., the container’s performance will affect the servlet’s performance).


References

Online resources

● Sun Java Servlet Web site: http://java.sun.com/products/servlet● Sun Java J2EE Web site: http://java.sun.com/j2ee● Sun Java JVM Specification: http://java.sun.com/docs/books/vmspec● Tomcat Servlet Container: http://jakarta.apache.org/tomcat, http://java.sun.com/products/jsp/tomcat● JUnit Test Framework Web site: http://www.junit.org● “Does Java Technology Have Memory Leaks?” 1999 Java One Presentation, Ed Lycklama:

http://industry.java.sun.com/javaone/99/pdfs/e618.pdf● “An Introduction to Java Servlets," Hans Bergsten:

http://www.Webdevelopersjournal.com/articles/intro_to_servlets.html● “Learning Servlets”: http://www.javaskyline.com/learnservlets.html ● "FindTutorials.com”: http://tutorials.findtutorials.com/

Books

● Subrahmanyam Allamaraju, et al., Java Server Programming, J2EE Edition. Wrox Press Ltd., 2002.● Philippe Kruchten, The Rational Unified Process: An Introduction, 2nd edition. Addison-Wesley, 2000.● Glenford J. Myers, The Art of Software Testing. Wiley, 1979.● Larne Pekowsky, Java Servlet Pages. Addison-Wesley, 2000.● George Baklarz, and Bill Wong, DB2 Universal Database v8 Database Administration Certification

Guide. IBM Press, 2003.

Journal articles

● Michael S. Dougherty, “Optimizing for Top Performance.” DB2 Magazine, Oct. 2002. http://www.db2mag.com/db_area/archives/2002/q4/Webdev.shtml

● Len DiMaggio, “Testing at the Boundaries Between Integrated Software Systems - Part I: Where to Begin.” The Rational Edge, April 2003.

● Len DiMaggio, “Testing at the Boundaries Between Integrated Software Systems - Part II: A Roadmap for Testing.” The Rational Edge, May 2003.

Notes

1 The blanket term “performance testing” is used in this article to describe a wide variety of software tests. IBM Rational Unified Process,® or RUP,® differentiates among types of performance testing such as “load” testing (in which the test configuration remains constant while operational conditions such as the test usage level varies), “performance” testing (in which the configuration varies but the operational conditions remain constant) and “stress” testing (which places the software under test under extreme conditions). The majority of tests described in this article fall into the “load” and “performance” types. Details on the specific tests and the sequence in which they should be run are in the Executing the tests section of the article. Details on RUP are available at http://www.rational.com/products/rup/index.jsp and in The Rational Unified Process: An Introduction, second


edition, by Philippe Kruchten (Addison-Wesley, 2000).

2 Java(TM) Servlet Specification (http://java.sun.com/products/servlet)

3 Several servlet containers are in widespread use these days. The easiest (and cheapest) way to begin is with Tomcat, a free, open-source implementation of Java Servlet and JSP technologies built by the “Jakarta” project at the Apache Software Foundation. Start at http://jakarta.apache.org/tomcat. You’ll find user documentation, sample servlets, and links to other Jakarta projects. Tomcat is also bundled into the J2EE reference implementation from Sun and can be accessed at: http://java.sun.com/products/jsp/tomcat.

4 The HttpServlet class implements methods (which can be overridden) for each of the request types supported by the HTTP protocol: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE. The RFC (#2068) for the protocol is available at many Web sites, for example: http://www.rfc-editor.org/rfc/rfc2068.txt

5 This program, and other useful JVM memory usage related topics, can be found at: http://tutorials.findtutorials.com/read/id/216 (This is a really useful Web site—you’ll find many great tutorials here.)

6 I’d like to take credit for this line, but I can’t. It’s my favorite line from the play “Inherit the Wind” by Jerome Lawrence and Robert E. Lee (later made in to a great movie staring Spencer Tracy).

7 As defined in the JVM Specification. You can actually print a free copy (only once!) from: http://java.sun.com/docs/books/vmspec

8 In a 1999 Java One presentation, Ed Lycklama coined the phrase “loiterer” to describe these objects. His presentation (http://industry.java.sun.com/javaone/99/pdfs/e618.pdf) is a great place to start if you want to learn more about Java memory leaks. Also, if you do a Web search for “Java memory leak” you’ll find many references to subsequent journal articles by Lycklama as well.

9 An example of a useful tool for tracking open database connections is a DB2 “Event Monitor.” These monitors are created using the SQL Data Definition Language. For details (and lots of other good DB2 information) see : DB2 Universal Database v8 Database Administration Certification Guide by George Baklarz and Bill Wong (IBM Press, 2003, p. 689-702).

10 http://www.rational.com/products/quantify_nt/index.jsp

11 If you’re looking for memory leaks, then a tool you should consider is IBM/Rational Purify (http://www.rational.com/products/pqc/index.jsp). This multiplatform runtime analysis tool can be a big help in tracking down the locations of memory leaks.

12 I really have to give credit where credit is due on this statement. When my wife and I bought our house, the inspector remarked to us that we shouldn’t worry about the age of the house (built in 1918), as “it never ran; it only walked.” In other words, the house was always well cared for by its owners (who luckily avoided the 1970s rage for pastel-colored bathtubs)!


13 Glenford J. Myers, The Art of Software Testing (Wiley, 1979).

About the authorLen DiMaggio is a software quality engineer and manager at IBM Rational. Prior to joining Rational, he led software testing teams at BBN, GTE, and Genuity. Len has published articles on software testing in STQE, Software Development, Dr. Dobbs Journal, and the QAI Journal.



Comments?


Search help

Using IBM Rational RequisitePro to evaluate competing bids

Contents:The complexities of a competitive acquisition

A solution for the evaluation process

Using IBM Rational RequisitePro

Benefits

Progressive acquisition or waterfall?

Acknowledgments

Notes

About the author

Rate this article



Fredrik FermIBM6 January 2004

from The Rational Edge: Using IBM Rational RequisitePro to manage the bid selection process bypasses the problem of having to synchronize a specialized bid analysis tool with your requirements tool, Ferm explains. This article describes how to automate the selection process with Rational RequisitePro support.

I was recently involved in a project for a Swedish government agency that wanted to develop a new weapons system for a warship. The agency's job was to specify the system requirements, select a contractor for the development, and then verify and validate the completed system against the original requirements.

We spent quite some time specifying requirements so we could send out a good RFP (Request For Proposal). While doing this, we started to think about how we would select the winning bid and award the contract. IBM Rational RequisitePro,® we realized, could help us in the selection process. This article explains the process we used and how we applied Rational RequisitePro to support it.

The complexities of a competitive acquisitionWhen you send out an RFP for a competitive acquisition, you expect to get more than one bid back from separate contractors or groups of contractors. Once all bids are in, you have the problem of selecting one winning bid. If the



project is large, you might also be held responsible for the selection decision; in fact, one of the "losing" contractors might try to take you to court. If this happens, it is a good idea to have your decision well-documented and based on objective principles that the contractors knew about before they entered their bids. In other words, you should use an objective evaluation process that you describe in the original RFP.

Before we get to the particulars of such an evaluation process, let's discuss what factors and forces should shape this process.

Trading off requirements

Different contractors will describe how they plan to meet your set of requirements in different fashions; also, they will probably differ as to what specific requirements they will actually try to meet and how well they can do it.

You have to be able to make decisions based on tradeoffs: If contractor A can meet requirement X very well but not requirement Y, whereas contractor B cannot meet requirement X but can meet requirement Y very well, you must decide which requirements are most important so that you can objectively evaluate the contractors' bids.

If you have made decisions about some of these tradeoffs beforehand, you may want to include this information in your RFP. This might enable contractors to create bids that better suit your needs, but keep in mind that it will also limit your freedom during the evaluation process.

Managing lots of data

If your requirement set for the future system is large, you'll have to consider a lot of information during the evaluation process, possibly against a large set of criteria. This means the evaluation process will produce a lot of data. This data should be kept in a well-structured form, so that you can easily answer specific questions about the evaluation at a later stage. Remember: You might have to defend your decision in court.

Input from a team of people

Modern acquisitions usually involve not only technical aspects of the future system, but also considerations such as legal matters, payments and contracts, support agreements, provisioning, maintenance, training, and so forth. Typically, no one person inside an organization will have the expertise to cover all of these fields, so evaluating a set of bids will require the collective effort of a team of specialists.

A solution for the evaluation processSo how should you go about performing the evaluation, given the complexities described above? To be sound and successful, the evaluation for a competitive acquisition requires more than just a tool. We must also think about how the work should be performed — in other words, what process to use.

Therefore, below we will outline a two-part solution: One part deals with the evaluation process itself and the other with the tool support necessary to implement that process.

Designating evaluators and an evaluation manager

Basically, there are two major roles involved in the evaluation process: a set of evaluators and an evaluation


manager.

An evaluator is responsible for evaluating the bids from a specific perspective, such as contracting and legal matters, technical fit, fit into maintenance organization, and so forth. Since there is typically no one person in an organization with expertise in all of these fields, you will probably want to choose a group of evaluators whose combined competence covers all the areas. You may even use more than one evaluator for a specific competence area.

In addition, you will need to choose an evaluation manager to be responsible for executing the evaluation project. He or she will coordinate the efforts of all evaluators and also combine all evaluations to calculate a total score for each bid.

Disqualifying bids

Most RFPs contain certain requirements that every contractor must meet in order to be considered at all — requirements imposed by laws and regulations or safety standards, for example. You will want to disqualify any bid that does not meet these requirements; early in the process you should check each bid against the set of disqualifying requirements ("shall" requirements). That way you can eliminate any bid that does not meet all of these requirements early on. Please note that it is wise to have as few disqualifying requirements as possible. You want to avoid dismissing bids if you do not really need to do so.

Creating a criteria tree

After checking the bids against the disqualifying requirements, presumably you will have more than one remaining bid. Now you need a way to prioritize these bids. I propose a hierarchical criteria tree. An example of the top levels of such a tree is shown in Figure 1. In a real-life project the tree would be much deeper and wider, but this shows enough to get the idea across.

Structuring the issues that need to be evaluated for each bid as a tree diagram makes it quite easy to designate specific experts to do evaluations for specific branches. Every criterion in the tree should also have a number indicating its relative importance, or weight, compared to other criteria, as shown in Figure 1. Since the weight is a relative number, we can decide on the scale to use, as long as we use the same scale for every "family1" of criteria. Figure 1 uses a percentage scale (the total weight of all families add up to 100), but could have used another type of scale.


Figure 1: Criteria tree showing relative weights

As we already noted, it may be a good idea to inform potential contractors of your priorities (i.e., provide some of the information in your criteria tree2, including weights) when you send out an RFP.

Criteria vs. requirements

Your criteria tree should be detailed enough so that each leaf can focus on the evaluation of one thing. Does this mean that you should have one criterion for every requirement in your requirement set? In most cases the answer is "no," although in certain instances it may make sense for a criterion to represent a single requirement. If your requirement set is complex, asking evaluators to assess a cluster of related requirements can save you time and effort. In other words, it might be more efficient if a single leaf criterion relates to many requirements.

Furthermore, in certain situations a leaf criterion might not relate to any requirements at all. For example, you might want to solicit a subjective judgment from an expert, who might consider factors other than hard requirements.

In both of these situations, your criteria set will not map exactly to your requirement set; nevertheless, you will want to track the relationships between these sets.

Evaluating the bids

Now it is time to do the actual evaluations for all of the leaf criteria in your tree. Skilled evaluators should go through the bids and assign scores to every leaf criterion for which they are responsible. As we noted above, it is important to have good documentation on why you chose a specific bid over another. Evaluators must not only provide written evaluations, but also document their rationale for the evaluation.

The evaluation manager should keep two things in mind as the evaluation work is done. First, the evaluators should not know the relative weight assigned to each criterion, because an awareness of the weighting might influence their evaluations. Instead, they should be provided only with the list of criteria against which to evaluate the bids,


and any necessary information on how to apply those criteria.3 Ideally, they should simply assess how well each bid meets each criterion, no matter how important that criterion is to the project overall.

Second, the evaluation manager must think about the scale for the evaluation scores, which should be consistent for the whole tree. The type of scale you choose is not important, just as long as you apply it for every criterion. For example, we could use either a scale of scores from 1 to 10 or percentages, just as long as we are consistent.

If more than one evaluator is assigned to a specific criterion, you need a system for combining their individual evaluations into a single combined score. In the government agency project I mentioned earlier, we decided to use an average of the evaluations, but also to let the system warn us if the evaluations were too far apart. When this occurred, we applied overrides, which I will describe a little later on.

Figure 2 shows an example of how to use a criteria tree to evaluate two competing bids4. Evaluation scores for the two bids are assigned to each leaf node. Also note that two people evaluated the criterion Req 1. To derive a single evaluation for Req 1, we used the averaging technique I mentioned above (results are in the top box of each three-box cluster below Req 1 in the tree). If the system had warned us that the scores for Req 1 on Bid 2 were very far apart, we would have investigated to find out why the two evaluators had such different views.

Figure 2: Criteria tree with evaluation scores

Aggregating the evaluation scores


Once you have evaluations of each leaf criterion, you need a way to total the scores for each bid and compare them to totals for the other bids. Since we have a numbered score for each leaf criterion, and also a number telling us how important each criterion is, we can simply postulate the following rule:

For a specific bid, the score for a specific parent criterion is the weighted average of the scores for all of its children. The average should be weighted by the relative weight of those children.

By using this rule recursively, from the bottom of the tree up to the top, we eventually come up with a total score for the bid by looking at the calculated score for the root node.

For example, if we follow this rule for the evaluation scores for Bid 1 in Figure 2, we find that the score of the "Price" criterion is 6, and the score of the "Delivery date" criterion is 8. Then we can calculate a score for the criterion "Commercial issues" as follows:

Following the same pattern, we could calculate the score of "Adherence to specific reqs" for Bid 1 as 5.4, of "Technical solution" as 6.04, and of "Business commitment" as 5.8. Finally, the calculated score of the root criterion would be 6.172

Now, if we were to do the same calculations for Bid 2, we could easily compare the total calculated score with the total for Bid 1 to see which bid had the highest total score.

Overrides

Once you have a total score for each bid, should you automatically choose the bid with the highest score? I would say "no, not necessarily."

First, go back and take a careful look at the calculations and evaluations. Does anything seem wrong to you? Perhaps you don't agree with a score (calculated or evaluated) somewhere in the tree and feel inclined to change it. In the government agency project, we made it possible to override calculated values. Of course, we had to document a rationale for the override that was just as complete as the written rationale for the original evaluation.

For aggregation purposes, the evaluation manager assigned his/her override to a specific criterion in the tree. In the automated aggregation process, the system will search for scores in the uppermost boxes of every criterion cluster and disregard those in the lower boxes of the cluster.

In Figure 3, we can see how the evaluation manager changed the score of the criterion "Business commitment" for the first bid to 4, instead of 5.8, as we calculated above. The system will disregard any scores for the first bid below this point, and use the value of 4 instead.


Figure 3: Criteria tree with scores and overrides

Figure 3 also shows another example of an override. As you may recall, the combined evaluations for Req 1 in Bid 2 were very far apart. After consulting with the evaluators, the evaluation manager did not agree with the averaged number, and simply changed the calculated average from 5.5 to 7.5 The system will pick up this value of 7 when it runs the aggregation.

When the evaluation manager has changed the scores and documented the rationales behind these changes, the aggregation can simply be performed again, which will result in a slightly modified total score. You can repeat this process (change evaluations, recalculate) as many times as you like, until you are comfortable with the total score. At this point, but not before, you should select the bid with the highest total score and conclude your evaluation.

My advice is to not use the overrides too much. They provide a good way to change results that are obviously wrong, but you should not use them to steer the evaluation results in the direction of a specific bid. That would defeat the whole purpose of using an objective way to evaluate bids.

Using IBM Rational RequisitePro The market offers some specialized tools to support a bid evaluation process like the one described above. On the government agency project, however, we took an alternative approach. We already had a requirements database in IBM Rational RequisitePro and did not want to introduce another database because of all the synchronization problems that would cause. Also, we felt that that the price of the specialized tools was too high. Instead, we decided to extend our Rational RequisitePro database to fit the project's needs.

IBM Rational RequisitePro structure


We used the IBM Rational RequisitePro database to keep track of all the information about the evaluation. Figure 46 shows how we structured the Rational RequisitePro requirement types, attributes, and traceabilities that we used.

Figure 4: IBM Rational RequisitePro project structure

Table 1 explains the requirement types shown in Figure 4.

Table 1: IBM Rational RequisitePro requirement types


Table 2 explains the attributes shown in Figure 4.

Table 2: Attributes for requirement types


IBM Rational RequisitePro functionality

IBM Rational RequisitePro contains most of the functionality needed for the process described above. However, we needed to add some extensions, which I will describe below.

Aggregation extension

The functionality to perform the aggregation calculations explained above is not available in IBM Rational RequisitePro, so we developed an extension that uses that tool's COM API to perform these calculations.

When using this extension, the evaluation manager first selects which criterion to treat as the root criterion in the calculation; then, the manager specifies the bid on which to perform the calculation. Beginning at the selected criterion, the system performs the aggregation calculation for the portion of the criteria tree below the selected criterion. The results of the calculation are stored in a new tree of "Calculation Score"7 requirements. The hierarchy of this tree mirrors the hierarchy of the criteria used in the calculation, so the evaluation manager can easily locate


the calculated score for each criterion.

Importing and exporting evaluations

The aggregation extension gave us all the essential functionality necessary to do the evaluation, but we developed additional extensions to facilitate communication between the evaluation manager and evaluators. Evaluators did not have access to IBM Rational RequisitePro, and even if they did, they would not have been given permission to enter their evaluations in the database.

Therefore, we created spreadsheets in Microsoft Excel to import and export evaluations. Evaluators entered their scores and rationales in a spreadsheet that contained rows for all criteria assigned to them. These spreadsheets were created automatically through VBA (Visual Basic for Applications) macros that interfaced to the IBM Rational RequisitePro database. After the evaluations were filled out, the data in the populated spreadsheets was automatically imported into the Rational RequisitePro database by means of other VBA macros in the spreadsheet. In this way, the macros automatically created the "Evaluation Score"8 requirements and attributes in the Rational RequisitePro database.

BenefitsSo, what are the benefits of doing an evaluation using the approach we have described in this article?

First, many benefits accrue from not introducing another information database into the project. The evaluation information is tightly connected to the requirements; and you should maintain relationships between these two sets of information. If you use an additional tool rather than IBM Rational RequisitePro for the evaluation effort, you will have synchronization issues between the two tools.

Second, since there is a high probability that you will have to publicly defend your bidder selection, it is a very good idea to keep track of all the information related to the evaluation. The process described above forces evaluators to document rationales for their evaluations and, as all of this information is stored in one place in the database, you don't run any risk of losing information.

Furthermore, the objective method for combining subjective evaluations to produce a total score supports the bidder selection in a "scientific" way, making it easier to defend. Finally, as noted above, you can provide key criteria to competitive bidders in the RFP.

Progressive acquisition or waterfall?For years, the acquisition process has been linear, involving only a single, up-front evaluation to select a contractor. In recent years, a group of experts has been working to transform this traditional — or waterfall — approach to acquisition into an iterative one called Progressive Acquisition, or PA.9 The process we've described in this article will support acquisition projects that use either of these approaches.

Both approaches involve evaluating bids from contractors. If you were using the waterfall approach, you would do your single evaluation early on in the project; if you were using the Progressive Acquisition approach, you would do an evaluation before selecting a bidder, and then continue to evaluate how well the contractor is meeting requirements as you reach contract milestones and renegotiate terms. You could easily perform the first evaluation as well as these subsequent evaluations using the method described in this article.


AcknowledgmentsFor helping to develop the ideas in this article, I must give a lot of credit to Dean Fowler and Erik Djerf at the Defence Material Administration in Sweden. Furthermore, I'd like to thank Mats Rahm and Jim Heumann for reviewing the article and also Marlene Ellin for her excellent editing.

Notes1 By family I mean the set of child criteria for a specific parent criterion.

2 You may also choose to inform potential contractors about what you consider to be the most important evaluation information — that is, to provide them with the upper levels of your criteria tree.

3 Of course, they should also be provided with the RFP and the bids they should evaluate.

4 This example is based on an evaluation scale of 1-10.

5 There could be many reasons for doing this. Perhaps the first evaluator misunderstood something, or the evaluation manager might trust the second evaluator a lot more than the first one.

6 Figure 4 uses UML classes to represent IBM Rational RequisitePro requirement types, UML Attributes to represent Rational RequisitePro attributes, and UML dependencies to represent possible Rational RequisitePro traceabilities. Furthermore, for attributes stereotyped <<name>> the information is stored not as a Rational RequisitePro attribute, but rather in the name field of the requirement(s) of the specific type.

7 See Figure 4.

8 See Figure 4 and Table 2.

9 You can find more information about Progressive Acquisition in the following references:

● WEAG TA-13 Acquisition Programme. "Guidance on the Use of Progressive Acquisition", Version 2. November 2000.

● "Progressive Acquisition and the RUP: Comparing and Combining Iterative Processes for Acquisition and Software Development." Giles Pitette, The Rational Edge, November 2001.

● Max Wideman's five-part series on Progressive Acquisition and the RUP in The Rational Edge: ❍ December 2002❍ January 2003❍ February 2003 ❍ March 2003 ❍ April 2003

Search help

A look at aspect-oriented programming

Contents:What is AOP?

The logging example in AspectJ

What does this all mean to you?

Resources

Notes

About the author

Rate this article



Gary PolliceWorcester Polytechnic Institute27 0 2004

from The Rational Edge: Pollice provides an overview of AOP and offers some observations on its promise, what we need to do to realize that promise, and some issues and obstacles along the way.

In a perfect world, there would be no such thing as software rework. We would get the object model right the first time. The waterfall approach to development would work just fine. But alas, we don’t live in a perfect world. That’s why we continue to seek better ways to build our software systems.

As realists, we acknowledge that no one process, technique, language, or platform is good for all situations. We increase the number of tools in our repertoire so that when we need that special tool or technique, we are well-prepared to use it. The history of our industry is rife with examples of improvements in our approach to building software, from the introduction of high-level languages, structured programming, and the object-oriented approach, to the development of spiral and iterative methods, and so on. One of the latest entrants in this lineup is aspect-oriented programming (AOP), which represents one facet of aspect-oriented software development (AOSD). In this month’s column, I’ll provide an overview of AOP and offer some observations on its promise, what we need to do to realize that promise, and some issues and obstacles along the way. We’ll learn a little bit about AOSD, too.

What is AOP?Aspect-oriented programming is one of those ideas that seems new but has actually been around for quite a while. Many people contributed to the body of knowledge available today, and many can lay claim to being a founder. The person most commonly associated with AOP is Gregor Kiczales, currently at the University of British Columbia, where he works on software modularity research. From 1984 to 1999, Kiczales worked on AOP at the Xerox Palo Alto Research Center (PARC) and was a leader in developing implementations of it.

The best way to describe AOP is by example. Suppose you were responsible for maintaining a large software system that



managed the payroll and personnel functions for your organization. What if management issued a new requirement that you create a log of all changes to an employee’s data? This would include payroll changes, such as a change in the number of deductions, raises, overtime, and so on. It would also include any changes to the employee’s title, personal data, and any other information associated with an employee. How would you go about meeting this requirement?

Most people, in the absence of a better way, would search through the code and insert calls to a logging method in appropriate places. If the system were well-designed and constructed, the code might require changes in only a few places. For most systems, though, insertions would be necessary in many places. If the system were object-oriented, we might build a logging class and then use an instance of it to handle the logging. We might need a hierarchy of classes to handle different files and databases. Attempting to fulfill the requirement in this way would not be a trivial job, and it would not be easy to ensure that we’d made all of the necessary insertions, either.

Even if we had a superior, object-oriented system implementation, we would encounter some problems. In their book, Mastering AspectJ,™ Joseph Gradecki and Nicholas Lesiecki note that OO systems often produce classes that are difficult to change, and code that can’t be reused and is difficult to trace through (i.e., numerous inter-object messages make it difficult to follow a logical thread for the code).1

Cross-cutting concernsThe type of logging required in our example is a cross-cutting concern. It cannot be isolated or encapsulated in one or two specific classes; the logging involves changes in many places across the system. Our desire is to keep the system maintainable, and therefore we want our logging approach to keep the code as clean and simple as possible. We would also like to avoid significant structural changes to the system’s architecture. So how do we implement a cross-cutting concern such as logging? We could refactor all of the code by creating a logging class and performing the appropriate insertions. However, in a large system, this would be a time-consuming, error-prone job.

AOP is designed to handle cross-cutting concerns by providing a mechanism, the aspect, for expressing these concerns and automatically incorporating them into a system. AOP does not replace existing programming paradigms and languages; instead, it works with them to improve their expressiveness and utility. It enhances our ability to express the separation of concerns necessary for a well-designed, maintainable software system. Some concerns are appropriately expressed as encapsulated objects, or components. Others are best expressed as cross-cutting concerns.

The logging example in AspectJLet’s continue looking at the logging problem and see how it might be solved using AspectJ, an AOP implementation that extends the Java language. AspectJ is perhaps the best known and most widely used AOP implementation. Even if you are not familiar with Java, you should be able to understand the major ideas I will present below.

Figure 1 depicts one way we might structure our modification of the system. The Finance system has an interface and several methods for updating an employee’s financial data. The names of the methods all begin with the word update (e.g., updateFederalTaxInfo), and each financial update takes an Employee object as an argument. Employees’ personnel information is also updated through an Employee object, using the methods shown in Figure 1.


Figure 1: Classes involved in updating employee information

We can describe, in prose, what we need to do. Every time we call any of the updating functions and the update succeeds, we write a logging message. For simplicity, we will say that we print a logging message to the standard output. In the real system we would write to a log file. We would take three steps to implement our solution in AspectJ:

1. Identify places in the code where we want to insert the logging code. This is called defining join points in AspectJ.2. Write the logging code.3. Compile the new code and integrate it into the system.

I will describe each of these steps in the next three sections.

Define the join pointsA join point is a well-defined point in the code at which our concerns crosscut the application. Typically, there are many join points for each concern. If there were just one or two, we could manually change the code with little effort.

In AspectJ, we define join points by grouping them into pointcuts. (The AspectJ syntax is rich, and we will not attempt to describe it completely here.) To start, we define two pointcuts, one each for grouping the join points in the Employee class and the IEmployeeFinance component. The following code defines the two pointcuts:

pointcut employeeUpdates(Employee e): call(public void Employee.update*Info()) && target(e);

pointcut employeeFinanceUpdates(Employee e) : call (public void update*Info(Employee)) && args(e);

The first pointcut, named employeeUpdates, describes all join points where we call an Employee object’s method that begins with the string update and ends with the string Info, and has no arguments. It also specifically identifies the method as defined in the Employee class through the target designator. The second pointcut, employeeFinanceUpdates, describes all join points where there is a call to any method that begins with update, ends with Info, and has one argument of type Employee. Together, these two pointcuts define all of the join points with which we are concerned. If we add more updating methods to the Employee class or the IEmployeeFinance component, calls to them will automatically be included in the pointcuts, as long as we maintain the same naming conventions. This means that we do not have to deliberately include logging code every time we add an updating method.

Write the logging codeThe code that implements logging is similar to any method in Java, but it is placed in a new type, called an aspect. The aspect is


the mechanism we use to encapsulate code related to a specific concern. The implementation of the aspect for logging employee changes might look like the following:

public aspect EmployeeChangeLogger { pointcut employeeUpdates(Employee e) : call( public void Employee.update*Info()) && target(e);

pointcut employeeFinanceUpdates(Employee e) : call( public void update*Info(Employee)) && args(e);

after(Employee e) returning : employeeUpdates(e) || employeeFinanceUpdates(e) { System.out.println("\t>Employee : " +e.getName() + " has had a change "); System.out.println("\t>Changed by " + thisJoinPoint.getSignature()); } }

First, notice that the aspect structure is similar to a class in Java. The aspect is typically placed in its own file, just like a Java class. Although the usual method is to include the previously defined pointcuts here in the aspect code, as we have done, we could instead include them closer to code containing the join points.

Following the pointcuts, we have a section of code that is similar to a method in regular Java code. This is called advice in AspectJ. There are three different types of advice: before, after, and around. They execute before the join point, after the join point, and instead of the join point, respectively. There are many variations you can use to customize your advice. In our example, we choose to perform the logging immediately after the updating method in the join point returns. Notice also that we combined the two pointcuts by naming each of them immediately after the colon in the advice header and connecting them with a logical “or.” We were able to do this easily because both pointcuts have an Employee parameter.

Two statements in the advice print out the fact that the employee’s information was changed, along with the name of the employee. This is easy to arrange, since the affected employee object is passed in as an argument to the advice. The second statement identifies the exact join point where the advice is executed and makes use of the AspectJ JoinPoint class. Whenever advice executes, it has an associated join point referenced by thisJoinPoint.

Compile and testNow that we have written the code for logging, we need to compile it and integrate it into the existing system. For our example, we have implemented two classes: Employee and EmployeeFinance. We also have a simple test class with a main method, as shown below:

public static void main(String[] args) { Employee e = new Employee("Chris Smith"); // Do something to change some of the employee's // information here. e.updateJobInfo(); e.updateOfficeInfo(); EmployeeFinance.updateFederalTaxInfo(e); EmployeeFinance.updateStateTaxInfo(e); }


This code runs just fine without any AOP implementation. For our example, the bodies of all the update methods just contain a print statement. When we run this example we get the following output:

Updating job informationUpdating office informationUpdating federal tax informationUpdating state tax information

In order to incorporate our aspect into the system, we add the aspect source code to the project and build with the AspectJ compiler, ajc. The compiler takes each aspect and creates class files that contain the advice code. Then, calls to the appropriate methods in these class files are woven into the original application code. With the current release of AspectJ, this weaving takes place at the Java bytecode level, so there are no intermediate source files you can look at to see the final code. However, you can decompile the Java bytecode if you are curious.

I use the Eclipse environment for development, and the AspectJ plug-in takes care of invoking the compiler with the proper arguments. Once we have compiled the project with the AspectJ compiler, we get the following output:

Updating job information >Employee : Chris Smith has had a change >Changed by void employee.Employee.updateJobInfo() Updating office information >Employee : Chris Smith has had a change >Changed by void employee.Employee.updateOfficeInfo() Updating federal tax information >Employee : Chris Smith has had a change >Changed by void employee.EmployeeFinance.updateFederalTaxInfo(Employee) Updating state tax information >Employee : Chris Smith has had a change >Changed by void employee.EmployeeFinance.updateStateTaxInfo(Employee)

Now we know which employee had information changed, and where the changes were made. The logging could certainly be much more elaborate, but the basic technique would not change.

What does this all mean to you?Aspect-oriented technology has many potential benefits. It provides a way of specifying and encapsulating cross-cutting concerns in a system. This might, in turn, allow us to do a better job of maintaining systems as they evolve — and we do know that they will evolve. AOP would let us add new features, in the form of concerns, to existing systems in an organized manner. The improvements in expressiveness and structure might allow us to keep systems running longer, and to incrementally improve them without incurring the expense of a complete rewrite.

AOP may also be a great addition to quality professionals’ toolboxes. Using an AOP language, we might be able to test application code automatically without disturbing the code. This would eliminate a possible source of error.

We are in the early stages of understanding the full potential of AOSD. It seems clear that the technology offers enough benefits to warrant further exploration and experimentation. How far are we from everyday usage of AOP languages for application development? It depends on whom you ask.

Now that we’ve seen some benefits, let’s look at some of the risks concerning AOSD as well as what is needed to bring it into the software development mainstream. The next sections discuss these issues.

Quality and risksHaving looked at AOSD from a quality viewpoint and done a little exploring with AspectJ, I’ve seen potential risks along with


the benefits. I will discuss three issues that illustrate some of the challenges we may face with respect to quality as AOSD becomes more popular.

The first issue is how we will need to modify our process to accommodate AOP. One of the most effective techniques for detecting software defects is through code inspections and reviews. During a review, a team of programmers critiques code to determine if it meets its requirements. With object-oriented programs, we can review classes, or sets of related classes, and reason about them. We can look at the code and determine if it handles unexpected events properly, has logical flaws, and so on. In an OO system, each class completely encapsulates the data and behavior of a specific concept.

With AOP, however, we can no longer reason about a class just by looking at the code for it. We do not know whether the code might be either augmented by advice from some aspect or completely replaced by such advice. To be able to reason about an application’s code, we must be able to look at the code from each class as well as the code for any aspects that might affect the class’s behavior. However, it is possible that the aspects have not been written yet. If that is so, then how much can we truly understand about the behavior of the application class’s code when we consider it in isolation?

In fact, the way to think about correctness in AOP code is the inverse of how we consider it for object-oriented programming (OOP) code. With OOP, we go from inside out: We consider a class, make assumptions about its context, and then reason about its correctness, both in isolation, and in terms of how it will interact with other classes. With AOP, we need to look from the outside in, and determine the effects of each aspect on every possible join point. Determining how to reason correctly about AOP, and developing the appropriate techniques and tools to help us, is a rich research area.

A second, more practical issue regarding the potential widespread adoption of AOP is the development of tools and techniques for testing, especially unit testing. Because code may be changed by an aspect, unit tests that run perfectly on a class may behave quite differently when the class is integrated into an AOP system. The following example illustrates this point.

As you probably know, a stack is a data structure that is used to add and remove items in a last-in, first-out manner. If you push the numbers 2, 4, and 6 onto a stack and then pop the stack twice, you will get 6 and 4, in that order. Writing a unit test for a Stack class is straightforward. We can read the requirements specification and the code and do a very good job of ensuring that the implementation is correct. One of the first things I did when I began to look at AspectJ was to implement a stack and see what I could do with aspects to change the behavior. I implemented a simple change: Increment each item by 1. This is very easy to do. Now, my unit test — which pushes 2, 4, and 6 onto the stack and pops the top two elements off to verify that they are 6 and 4 — fails. The code that the unit test is testing did not change, yet the behavior changed. Instead of 6 and 4, the results are now 7 and 5.

This is a trivial example, and one that probably would not occur in a real-life situation. But it shows that a malicious programmer can cause a lot of harm quite easily. Even if we ignore malicious programmers, many defects occur because there are unwanted side effects of changes we make. It might be very difficult to ensure that an aspect implemented for very valid reasons does not have unwanted effects on existing program functionality.

The third issue is the testing process itself. Once we have a set of tools and techniques, how do we modify our testing process to use these effectively and support our overall development goals? Although this issue may not be a major one, I believe it will need to be addressed before we can really do a good job of testing software built with aspects.

Other barriers to AOSD adoptionQuality issues may be the biggest deterrents to adopting AOSD methods, but they are not the only ones. AOSD is a new paradigm. As did other paradigms when they were new (e.g., object-oriented software development), this one will take time to be adopted widely because it involves a learning curve. First we must learn basic techniques and mechanics, then advanced techniques, and then how to best apply the techniques and when they are most appropriate.

Tools will play a major part in industry adoption of AOP. In addition to compilers and editors, we need tools to help us reason about systems, identify potential cross-cutting concerns, and help us test in the presence of aspects. As we find methods to help us represent the systems better, such as representing aspects in UML, our tools must evolve to support these methods.


Although I discussed AspectJ in this article, it is neither the only AOP implementation nor the only one for Java. Furthermore, other paradigms similar to AOP are also emerging. The multi-dimensional separation of concerns paradigm, for example, has been under development at IBM Research, and an implementation is available in the HyperJ tool (http://www.alphaworks.ibm.com/tech/hyperj). Using any new paradigm is risky until standard implementations are established for the languages you work with. AspectJ, for instance, is a still-evolving AOP implementation. The danger is that you may develop software that incorporates cross-cutting concerns, and your implementation approach will either cease to be supported or will change significantly.

Moving toward a better way to build softwareClearly, we have a way to go in developing tools and processes to make AOP viable for everyday use. However, I do not believe that any of the issues I have discussed in this article represent insurmountable problems. I do believe that when we have developed a proven set of tools and processes for AOP, we will have a better way to build software than we do today.

As Barry Boehm said about agile processes,2 we must approach AOP with care. Whether we are early adopters or we wait for this technology to become more mainstream, we need to ensure that our software investment will provide acceptable returns today and in the future. That’s just good business sense.

ResourcesIf you are interested in AOSD and AOP, here are some places to start your investigation.

Communications of the ACM, October 2001, has many articles on AOSD.

“Improve Modularity with Aspect-oriented Programming,” by Nicholas Lesiecki provides a good overview: http://www-106.ibm.com/developerworks/java/library/j-aspectj/.

“Test Flexibility with AspectJ and Mock Objects,” by Nicholas Lesiecki shows how AOP can be used to help with unit testing: http://www-106.ibm.com/developerworks/java/library/j-aspectj2/?open&l=007,t=gr

Mastering AspectJ, by Joseph D. Gradecki and Nicholas Lesiecki, is a book published by John Wiley, 2003.

For a more detailed list of resources, visit my Web page at WPI: http://www.cs.wpi.edu/~gpollice/Interests/AOSD.html

Notes 1 Mastering AspectJ,™ by Joseph D. Gradecki and Nicholas Lesiecki, John Wiley, 2003, p. 8.

2 "Get Ready for Agile Methods, with Care", Barry Boehm, IEEE Computer, January, 2002.

About the authorGary Pollice is a Professor of Practice at Worcester Polytechnic Institute, in Worcester, MA. He teaches software engineering, design, testing, and other computer science courses, and also directs student projects. Before entering the academic world, he spent more than thirty-five years developing various kinds of software, from business applications to compilers and tools. His last industry job was with IBM Rational Software, where he was known as "the RUP Curmudgeon" and was also a member of the original Rational Suite team. He is the primary author of

Software Development for Small Teams: a RUP-Centric Approach, published by Addison-Wesley in 2004. He holds a B.A. in mathematics and M.S. in computer science.

The Rational Edge: e-zine for the Rational Community · The Rational Edge: e-zine for the Rational...

Documents

Transcript of The Rational Edge: e-zine for the Rational Community · The Rational Edge: e-zine for the Rational...