Preface

Increasing and unending pressure exists in software development to finish more quickly, to produce higher-quality solutions, and to do so with fewer resources. We can use patterns, proven best-practice solutions to known problems, as a powerful tool to help address these challenges. However, if the answer were as simple as “Just use patterns,” we would already have dealt with these challenges.

There is complexity, depth, and nuance to using patterns, and succeeding with them requires knowledge, expertise, and guidance. And not only do we want to succeed with patterns, we want to do so in a fashion that is scalable, repeatable, and predictable. This book introduces an approach known as Patterns-Based Engineering (PBE) that provides guidance on how to successfully incorporate and leverage patterns in software development. We don’t just use patterns; we think, evaluate, create, innovate, collaborate, abstract, simplify, justify, automate, and reuse.

Patterns-Based Engineering

PBE is a specialized approach to asset-based development that focuses on patterns, a specific type of reusable asset. PBE provides guidance and support for using patterns in a systematic, disciplined, and quantifiable way. With PBE an organization uses patterns in multiple forms, for numerous purposes, and in a number of ways. More specifically, we look at two specific types of patterns: pattern specifications and pattern implementations. We use these types of patterns to support design, testing, deployment, and other aspects of the software development lifecycle. In performing these tasks, we use patterns in many ways such as documenting, generating, refactoring, and harvesting. As a result, we are able to use patterns to boost productivity, improve quality, leverage expertise, simplify, and improve communication within an organization. The goal is to ensure that as we use and create patterns, we are doing so in a way that adds value and boosts the agility of our projects and organization.

An important aspect of PBE is that it goes beyond just the technology. Success on a project has never been and will never be just about the technology. We need to ensure that the team is able to work together; that we all know the roles we are to play, the tasks to be done, the work products to create along the way; and that we can communicate with one another.

How to Read This Book

This section starts with an overview of the book’s structure. We then provide a guide to reading the book based on role, and we finish with suggestions for the background needed to get the most out of the book and a list of learning objectives.

Book Structure

This book is divided into four parts. Part I provides an introduction to PBE. Within this part, Chapter 1 starts by defining PBE and Chapter 2 follows by providing some examples of pattern implementations, as this is a new concept for most and is an important aspect of PBE. Chapters 3 through 7 then show an example of PBE in action through a case study. Chapter 8 concludes Part I with a discussion of the process aspects of PBE and how it could fit into existing software development processes, including coverage of Extreme Programming, Scrum, and OpenUP.

Part II describes some of the best practices related to PBE in the form of patterns and guidelines. Chapter 9 explains the organization and summarizes each of the patterns and guidelines. Chapters 10 through 16 detail the patterns and guidelines, each chapter focusing on a specific category.

Part III covers additional topics that provide a deeper examination of PBE, particularly the nontechnical aspects. We detail some of the PBE benefits in Chapter 17, move to the economic aspects of PBE in Chapter 18, and finish Part III with Chapter 19, which takes a look at some of the PBE misconceptions that may be faced in rolling out PBE within an organization.

Part IV wraps up the book with a set of appendices that provide supporting materials and references. Appendix A summarizes the main PBE definitions to provide quick access to some of the terms and concepts used throughout the book. Appendix B takes a look at PBE in comparison to other software development approaches. Appendix C provides a nonexhaustive list of tools available to help in applying PBE within an organization. Appendix D provides a set of PBE Patterns and Guidelines overview diagrams. Appendix E provides the pattern specification for the Subsystem Façade pattern created and used in the case study. Appendix F serves as a companion to Chapter 8, adding more details to support our understanding of the PBE Practice.

To get a high-level understanding of PBE, read all of Part I and Chapter 9 from Part II, which provides a high-level summary of the PBE Patterns and Guidelines.

For a deeper understanding of PBE you should go at least once through the PBE Patterns and Guidelines to get a better idea of what problems they address and the associated solutions. And if you are interested in some of the nontechnical aspects of PBE, Part III is a must read.

Who Should Read This Book

Patterns surface and are applicable throughout the development lifecycle and for multiple purposes. Thus, there is a wide audience for this book, including

• Software architects, designers, and developers: Read all parts.

• Project managers: Read Part I, at least Chapter 1, and Part III.

• Process engineers: Read all parts with a focus on Chapter 8 and Appendix F.

• Analysts, including those responsible for testing, requirements, and business: Read Part I, at least Chapter 1.

Suggested Background

To get the most from this book, we suggest that you have basic familiarity with the following topics:

• Object-oriented programming with a language such as Java or C#

• Patterns

• Unified Modeling Language (UML)

• XML

Learning Objectives

Upon completion of the book, you will be able to

• Describe ways in which patterns can be leveraged in delivering software

• Describe the roles, tasks, work products, and best practices defined within PBE

• Describe the factors that help decision making about investments driven by PBE as well as the expected implications of such decisions

• Describe the value and purpose of using patterns (implementations and specifications)

• Successfully identify, specify, and implement patterns

• Understand that patterns are for all roles and projects

Why This Book?

So, why this book? Why does the world need another patterns book? Aren’t there enough already? One way to answer these questions is to say that we do not like solving the same problems over and over again. As a matter of fact, we struggle a bit dealing with the mechanical and mundane aspects of writing software. We are big fans of trying to be creative and solving new and unique problems. And we like to leverage automation to help us minimize and avoid having to work on those mechanical and mundane tasks.

Another way to answer these questions is that it’s not enough to be passionate. It’s not enough to be creative. It’s not enough to use tooling and automation. There’s already content in many forms—books, courses, and articles—that touches upon these topics. However, we were not able to find content that brings these ideas together. A holistic approach is needed to discuss how we can use patterns more strategically, more systematically. We need to be able to scale the use of patterns across the organization and ensure predictability and repeatability in our pattern-infused projects.

Downloadable Content

There are three downloads associated with this book, available from www.PatternsBasedEngineering.net. These downloads include

• Source artifacts for the pattern implementation that is discussed in the case study

• The source plug-in for a PBE Practice to be used with Eclipse Process Framework Composer

• A published configuration of the PBE Practice composed of a set of HTML pages that can be viewed with a standard web browser

Writing Style

Software development is a team sport; we present the rest of the book as a team effort. We are in this together, having a chat about how we can better leverage patterns in our projects.