Defining Patterns-Based Engineering
This chapter is from the book
This chapter is from the book
This chapter is from the book
Beginnings are tough. Where to start? Is the necessary expertise available? Will we finish on time? Will the quality be there? Will everyone on the project follow best practices? Will the team get a chance to be creative while using and improving their skills? Are the requirements really known and understood?
As software engineers, we find ourselves asking such questions whether we are working on a greenfield project or maintaining a legacy application. Often the answers are not to our liking. As we start the project, we often joke about missing deadlines and are anxious about whether we will get the job done. Experience has taught us that the road ahead is going to be difficult and frustrating. To quote Grady Booch: "Software development has been, is, and will remain fundamentally hard."1
We know that we are not alone. We need to improve how we deliver our software projects. We need to improve productivity, enhance quality, hasten time to market, have better governance, and do all of this while dealing with a challenging set of constraints,2 such as not enough expertise, daunting timelines, ambiguous and changing requirements, and ever-increasing solution scope and complexity.
Over the years we have tried to take steps to address these issues. We've adopted Agile processes, as who wouldn't want their projects to be more agile? We've tried model-driven development (MDD); as they say, "A picture is worth a thousand words." We've incorporated the leading industry frameworks, including .NET and Java EE, as well as the frameworks within these domains that further support our efforts, including Spring, Hibernate, and JavaServer Faces (JSF). We've adopted the best approaches to development as they've emerged, such as object-oriented (OO), component-based development (CBD), and service-oriented architecture (SOA). We've outsourced and off-shored, looking outside our organization for support, skills, and cost management. However, we continue to come up short—all while the complexity of what we are asked to build continues to advance.
This book discusses Patterns-Based Engineering (PBE), an approach to software development. It is not the silver bullet; it is not the magic elixir that will cure all that ails our projects. However, PBE, as demonstrated in real-world projects, takes a systematic and disciplined approach to using patterns—proven, best-practice solutions—to deliver software. A key and unique aspect of this approach is that in addition to using existing patterns from the community, we identify and create patterns within the organization, codifying, automating, and leveraging our own best practices. Organizations that have adopted this practice have seen improved productivity, increased quality, better utilization of expertise, and improved governance.
Asset-Based Development
A good place to start in gaining an understanding of PBE is to look at asset-based development (ABD). There is a strong connection between PBE and ABD. ABD is focused on how to leverage investments made in software artifacts in future projects. However, the guidance related to ABD is typically focused on assets in general, which is useful when the focus is on promoting reuse across many types of artifacts. PBE builds on the foundation provided by ABD and provides guidance for how we can succeed with a specific type of asset—specifically, patterns. With this relationship in mind, let's take a more detailed look at ABD.
ABD includes four major areas—process, standards, tooling, and assets—all of which are focused on how to successfully reuse and benefit from assets. An asset is "a collection of artifacts that provides a solution to a problem. The asset has instructions on how it should be used and is reusable in one or more contexts, such as a development or a runtime context. The asset may also be extended and customized through variability points."3 A variability point is a part of the asset that is purposely provided by the creator of the asset and allows for later configuration or extension of the asset. Variability points are key to success with ABD, and in turn PBE, as they allow us to take a proven solution and easily tailor, customize, and adapt it to the specifics of our situation.
Generally a team produces numerous different types of artifacts as they look to deliver software solutions, ranging from requirements, to models, code, tests, and even deployment scripts. Each of these investments could potentially become a reusable asset. We need to evaluate specific instantiations of these artifacts to determine which would warrant an investment.
As shown in Figure 1.1,4 when following an ABD approach, we look at four areas of effort related to the assets, including
- Asset identification. We need to identify potential assets and determine which are suitable for investment.
- Asset production. After we have identified candidate assets, we need to produce those assets.
- Asset management. As assets are produced, we take appropriate steps to manage them and make them available for others to reuse. This includes support for searching, reviewing, and providing feedback. An asset repository is typically used to assist with this effort.
- Asset consumption. Once a set of assets is made available, the team accesses the asset repository and reuses the assets in their projects. Users of the assets are expected to provide feedback to the asset producers. This feedback is used to improve the assets and increase their value to the organization.
)
Figure 1.1 Overview of major areas of effort related to asset-based development
Typically, we consider ABD from two perspectives. In one perspective we are concerned with the available tools, processes, standards, and assets. In the other perspective we focus on the efforts that we put into the identification, production, management, and consumption of assets.
If an organization already has an ABD program in place, PBE is a quick addition to the effort. If an organization has not yet adopted ABD, PBE is a very good place to start learning, adopting, and succeeding with assets.