Chapter 3. Case Study Introduction

In Chapters 3 through 7 we will follow an extended case study that illustrates how to apply PBE. The goal of these chapters is to bring together the PBE Core Values, Patterns, Guidelines, and Practice in an example of how they can be applied. This chapter sets the stage by introducing the case study’s project team and the application that they will be building. In subsequent chapters we will examine the team’s efforts across multiple iterations.

Both the company, Oslec Software, and the application discussed are fictional, but the case study reflects an amalgamation of real-world PBE experiences. The goal in presenting this case study is to provide a balance between real-world applicability and abstracting away details that unnecessarily complicate the scenario. As part of that balance, the case study focuses on the elements that are most important in helping software engineers learn how to adopt and use PBE.

Overview

We’ll follow a fictional company, Oslec Software, through the creation of a new software solution. Oslec Software had developed an auction application to allow its employees to purchase corporate logo merchandise. Purchasing via an auction makes everything more exciting, even corporate logo merchandise.

After observing high employee participation and interest in corporate logo merchandise auctions, the company decided to productize the auction application. The application will be sold under the name LogoAuction and will enable other companies to create the same kind of social dynamics achieved within Oslec. We will follow the story of how the company rebuilds the application so that it can be sold as a commercial application. The original application works fine for internal use, but there are numerous issues that prevent an as-is repackaging. We will be exploring some of these issues as we drill down into the architecture of the application.

Because a version of the application already exists, the project team can leverage a number of artifacts in building the commercial version. For instance, there is already a use case model, a domain model, and a code base that they can consult.

The team will be leveraging PBE on the project. This will be a challenge, because the organization is new to PBE and in the past has not excelled in its use of patterns. Any pattern use that has occurred to date has essentially been ad hoc—not systematic, not disciplined—and the company has not quantified the results of any pattern efforts. The team is essentially working from a blank sheet of paper in regard to patterns. Oslec Software has its own methodology and many other tools and assets to support that methodology. An important goal for the organization is to have a successful project while also building out its patterns capability, accelerating this project and future projects.

Meet the Team

Now that we have a better idea of the application scope, let’s take a look at the development organization at Oslec Software. The skills, experience, and culture of the organization will play a big role in how successful it is in adopting PBE.

Figure 3.1 depicts a simplified organization chart for the project team and summarizes the names and roles for the team members. Alex, the architect for this effort, has significant experience with the Java EE platform, and he has been a strong proponent of bringing patterns and PBE into the company. Working hand-in-hand with him are Gwen, the requirements analyst, and Michael, the project manager. They are both skilled in their respective domains but are unfamiliar with patterns and PBE. Eight developers are based in three different sites (four in Toronto, two in Boston, and two in Bangalore). Each developer group is led by a team leader: Duncan in Toronto, John in Boston, and Rajesh in Bangalore. The team leaders are familiar with the use of some patterns, but not with PBE. Jade from the testing group has been assigned to the project to assist with the quality assurance effort. Others who will interact with the team include Sam, the asset manager, and Jordan, from the tools group.

Figure 3.1. Organization chart for the development team

As the development team is globally distributed, Michael faces challenges such as differences in language, culture, and time zone that in the past have been difficult for the organization. Designs that have been created in one location are often implemented in another location, based on availability and skills. In many cases the implementations have not stayed true to the design, which has led to rework and missed deadlines.

Because of other project commitments, John’s and Rajesh’s teams will join the project later. This will give Duncan’s team time to define and build the infrastructure that the others will be leveraging.

Oslec Development Process

Oslec uses an Agile development approach in the majority of its projects. Teams have built out a custom process that brings together a number of Agile practices. Of particular interest is the use of practices such as test-driven development, iterative and incremental development, Agile modeling, and continuous integration.

In terms of planning, they follow iterative and incremental development, with two to three weeks per iteration. The goal is to provide enough time to deliver valuable increments, without going too long between deliveries. They have also adopted Agile modeling¹ for their architecture and design activities. They use UML and have standardized on a modeling platform. Their projects start with Iteration 0: Envisioning, when the teams flesh out the high-level architecture of the application to develop. The purpose is not to determine all the details but to get a shared vision of the architecture. This architecture will be validated and refined as the application is developed. They have also adopted the practice of recording and specifying requirements with use cases. However, their use cases tend to be high-level; details are fleshed out through discussions and tests. They have adopted a test-driven development approach where they write their tests and test artifacts before developing features. They then work to build a solution that will pass the tests; once the solution passes the tests, they refactor it as necessary. To further support their iterative and incremental approach along with their quest for quality, Oslec uses continuous integration. Each night the application under development is built and tested.

Alex and Michael have worked together, filling the role of process engineer to further customize the Oslec development process to include PBE. They have customized the process and published a configuration that the team will use. The published configuration has been posted to a server that is accessible by all team members so they can refer to it in their day-to-day work.

Overview of the Plan

Up until now, Oslec Software has used patterns in only an ad hoc and isolated manner; for instance, they have previously used Model-View-Controller (MVC) when building their applications. There has also been some use of some of the GoF design patterns. However, this usage has not been systematic or disciplined. When patterns are used, it is an uncoordinated, individual decision, and no rigor is applied to determining the impact of using the patterns. In addition, because of varied skill levels across the team, they’ve seen inconsistent results related to the application of patterns. Automation has not yet played any role in their pattern efforts, and culturally patterns are not promoted.

As this is the first PBE-based project, the team does not yet have a repository of patterns that they can consult and leverage. The project itself will follow an Agile iterative and incremental approach, and one of the priorities is to build out their PBE capabilities in each iteration; that is, they will not be taking a big-bang approach to the adoption. Instead, within each iteration they will adopt as much as is realistic and worthwhile. By the end of the project, the goal is that they will have substantially increased their capabilities to use patterns. Then, on further projects, they can continue to build on this base and incrementally build out additional capabilities.

In ramping up for the project, the team has taken the following initial steps:

• Tool selection. The first step is to determine which tools will be used to help with the creation and management of patterns. For management of patterns, including storage of pattern specifications and implementations, they will use their existing asset repository. A new asset will be created for each pattern they use. If the pattern is not specific to the company (i.e., the source is external to the company) and the specification is already available through the Internet, the entry will contain a brief description of the pattern as well as a reference to the pattern source. Pattern specifications specific to the company will be specified in HTML, to make them easier to consult. The team has also decided to use the pattern specification template as described in the Pattern Specification guidelines (Chapter 13) as their standard with a goal of supporting pattern sharing and comprehension. For pattern implementations, a download link will be provided with the pattern asset page so that people interested in automating the use of the pattern can easily download the implementation. Their standard architecture and design tool is IBM Rational Software Architect as it provides mechanisms to develop model-to-model and model-to-text pattern implementations. The existing configuration management tool will be used to manage the source artifacts related to the development of pattern implementations as for any other development artifact.

• Collaboration. On past projects the team extensively used wikis to capture information and collaborate; they want to leverage this positive experience by using wikis to store and discuss candidate pattern specifications. Once the pattern specification has stabilized, it will be moved to the asset repository. However, the wiki entry will be maintained to encourage discussion and feedback on the pattern specification as new versions are pursued. The asset repository will be used for managing feedback on deployed patterns.

• Enablement. Alex, Michael, Jordan, and the development team leads have been taking training on PBE, including coverage of concepts, tooling, and implementation skills. This group has learned about the theory behind PBE and the associated patterns, guidelines, core values, and practice. In these efforts they have learned how to identify candidate patterns, how to write pattern specifications, and how to create pattern implementations. In addition, they’ve been asked to focus on building a culture that will embrace and work with the PBE approach.

Case Study Roadmap

As we move forward with the case study, it is important to remember that PBE is not a one-size-fits-all approach. As we look to apply the lessons from the case study to our own projects, we will need to be pragmatic and pick the aspects that will help us succeed within the specifics of our projects. We will use the PBE Patterns and Guidelines as well as the PBE Practice highlighted in Chapter 8 as a guide on our journey.

The case study uses a subset of the available PBE guidance. In addition, only a fraction of the thousands of currently available patterns are touched upon. As we embark on our projects, we will need to pick out a subset from this pool of available guidance, a subset that provides value and helps us to get our job done.

The content of the case study is focused in one domain and an application that is limited in applicability. However, the steps taken, the ideas leveraged, and the core values and patterns used can be mapped to many situations.

In the case study we will be following the Oslec team during the first four iterations of their project. As we accompany them, we will see how they perform their tasks leveraging PBE practices, patterns, and guidelines. Figure 3.2 summarizes the PBE focus of each iteration of the case study as well as some of the main aspects that will be covered in each iteration.

Figure 3.2. Overview of the case study iterations

As the team starts envisioning the requirements and architecture of the application, they will use existing patterns and also identify and evaluate new patterns to build. In the second iteration they will work on building the application, while Jordan and Alex design and build a pattern. In the third iteration they will package and deploy the newly built pattern to make it available to others. The last iteration of the case study focuses on how the pattern is used to create a new subsystem as well as to refactor an existing one.

Summary

In this chapter we familiarized ourselves with Oslec, a fictional company. We will follow the project team in the next four chapters as they develop an auction-based application for selling corporate logo merchandise using PBE Core Values, Patterns, Guidelines, and Practice.