Chapter 6. Elevate the Level of Abstraction

Benefits	Improved productivity. Reduced complexity.
Patterns	Reuse existing assets. Use higher-level tools and languages to reduce the amount of documentation produced. Focus on architecture.
Anti-Patterns	Go directly from vague, high-level requirements to custom-crafted code.

Complexity is a central issue in software development. Elevating the level of abstraction helps reduce complexity and the amount of documentation required by the project, while facilitating communication. You can achieve this elevation through reuse, the use of high-level modeling tools, refactoring, and stabilizing the architecture early.

One effective approach for reducing complexity is to reuse existing assets, such as reusable components, legacy systems, existing business processes, patterns, or open source software. Two great examples of reuse that have had a major impact on the software industry over the last decade are reuse of middlewaresuch as databases, Web servers, and portalsand, more recently, open source software, which provides many smaller and larger components that can be leveraged. Moving forward, Web services will likely have a major impact on reuse, since they provide simple ways of reusing major chunks of functionality across disparate platforms and with loose coupling between the consumer and provider of a service (see Figure 6.1). As a result, you can more easily leverage different combinations of services to address your business needs. Reuse is also facilitated by open standards, such as Simple Object Access Protocol (SOAP), Web Services Definition Language (WSDL), Reusable Asset Specification (RAS), Universal Description, Discovery, and Integration (UDDI), and eXtensible Markup Language (XML).

Figure 6.1. Reuse Existing Assets Through Service-Oriented Architectures.

One of the problems with reuse is that two components need to know about each other's existence at development time. Service-oriented architectures alleviate that problem by providing what is called loose coupling; a consumer of a service can dynamically find a provider of a service. You can hence wrap existing components or legacy systems into services, allowing other components or applications dynamic access to their capabilities through a standards-based interface, independent of the platform and implementation technology used to develop the various components.

Another approach to reducing complexity and improving communication consists of leveraging higher-level tools, frameworks, and languages. Standard languages such as Unified Modeling Language (UML) and rapid application languages such as Enterprise Generation Language (EGL) provide the ability to express high-level constructs, such as business processes and service components, to facilitate collaboration around high-level constructs while hiding unnecessary details. Design and construction tools can automate moving from high-level constructs to working code by providing wizards to automate design, construction, and test tasks; by applying patterns, generating code and enabling usage of code snippets; and by making integration and testing seamless development tasks through integrated development, build, and test environments. Another example is project and portfolio management tools, which allow you to manage financial and other aspects of multiple projects as one entity versus a set of separate entities.

A third approach to managing complexity is to focus on architecture, no matter whether you are trying to define a business or develop a system or application. In software development we aim to get the architecture designed, implemented, and tested early in the project. Consequently, early in the project we define the high-level building blocks and the most important components, their responsibilities, and their interfaces. We define and implement the architectural mechanisms, that is, ready-made solutions to common problems, such as how to deal with persistency or garbage collection. By getting the architecture right early on, we define a skeleton structure for our system, making it easier to manage complexity as we add more people, components, capabilities, and code to the project. We also understand what reusable assets we can leverage and what aspects of the system need to be custom-built.

The anti-pattern to following this principle would be to go directly from vague, high-level requirements to custom-crafted code. Since few abstractions are used, a lot of the discussions are made at the code level versus a more conceptual level, thus missing many opportunities for reuse, among other things. Informally captured requirements and other information require many decisions and specifications to be revisited over and over, and limited emphasis on architecture causes major rework late in the project.

This chapter covers a series of practices that will help you manage complexity by working at a higher level of abstraction:

• Practice 15: Leverage Patterns explains how patterns allow you to produce an application more effectively and shows how patterns can be used to help enforce the architecture.

• Practice 16: Architect with Components and Services describes the benefits of developing with components and demonstrates how to go about developing a component-based architecture.

• Practice 17: Actively Promote Reuse provides guidelines for how to enable and promote reuse of assets.

• Practice 18: Model Key Perspectives discusses how models can help you understand, communicate, and accelerate development.

Let's have a look at these practices in turn.