Introduction to design patterns, Part 3: Beyond software design patterns

Use patterns to improve interaction design, enterprise architecture, software methodology, and more

Whenever an activity occurs in repetition, such as programming, patterns emerge and can be documented. The benefits of documenting and using software design patterns are well established, as are some common pitfalls. In this final article in the Introduction to design patterns series, we'll move beyond the software design patterns that Java developers know so well to look at four other types of patterns that are relevant to software development. Read on to find out how design patterns are used to improve application usability, enterprise architecture, software development processes, workplace communication, and technical presentations.

Interaction design patterns

Christopher Alexander's A Pattern Language: Towns, Buildings, Construction could be considered the "big bang" that illuminated a universe of design patterns. If software design patterns comprise one of this universe's galaxies, interaction design patterns comprise another one.

An interaction design pattern is a design pattern that describes a solution to a common usability or accessibility problem in a specific context such as software development. Interaction design patterns are used in interaction design, where products are designed for human use. For example, consider how human beings might interact with a holographic display. Would we control the device through physical controls or via a virtual (shimmering) control panel?

Software developers typically engage in interaction design when we consider the usability of a user interface (UI), such as Microsoft's Metro UI for Windows 8. As you might recall, Metro was designed to be user-friendly on tablets, but proved less accommodating for desktops. The controversy surrounding Metro proves that interaction design is a challenging and important field.

Interaction design history

Interaction design pre-dates the digital era; for example, consider America's automotive industry in the early 1900s. The fact that an American automobile's steering wheel is on the left side of the vehicle, and not the right, is an example of interaction design. In the digital realm, Xerox's Palo Alto Research Center (PARC) invented the GUI and mouse, which have been enabling users to interact with their computers since the 1970s. (Both components were popularized by Apple via its early Macintosh computers.)

In the mid-1980s, human-computer interaction pioneers Bill Moggridge and Bill Verplank coined the term interaction design. Ten years later, other designers rediscovered this term and started to use it.

In 1999, Web consultant Jenifer Tidwell presented the first substantial set of interaction design patterns via her Common Ground collection. Since then, she has written Designing Interfaces, which presents new and revised patterns.

More interaction design pattern libraries have since emerged. The Yahoo! Design Pattern Library currently offers 59 user interface patterns. Android Patterns is a pattern repository for designing Android mobile apps.

Interaction design patterns in the real (and virtual) world

Tidwell presents an extensive catalog of interaction design patterns on her website. Most of her patterns are documented in terms of examples, context, problem, forces (tradeoffs being considered), solution, and (often) a resulting context. The Narrative pattern presented in Figure 1 is a good example (courtesy of Jenifer Tidwell).

The Narrative design pattern Courtesy of Jenifer Tidwell.

Figure 1. Diagram of the Narrative pattern

Patterns can be combined to solve particular design problems. Figure 2 shows an example where several interaction design patterns are combined in a traditional telephone interface, as shown in Figure 2 (courtesy of Jenifer Tidwell).

Diagram of the Telephone interface pattern Jenifer Tidwell

Figure 2. Applying patterns to a telephone interface 

Martijn van Welie has collected many examples of interaction design patterns used by web designers. You are likely familiar with the Breadcrumbs pattern, which helps website visitors know where they are in a site hierarchy, and also makes it easier for them to navigate back to higher levels.

Figure 3. The Breadcrumbs pattern on IBM developerWorks (click to enlarge)

The breadcrumb bar in the above design is typical. It presents a path that shows the location of the current page in the total page hierarchy. Each hierarchy level is labeled and behaves as a link to that level. The current page is marked in some way to give feedback about where the user is currently located and should not be presented as a link. Note that in Figure 3 the > symbol is used to separate breadcrumbs.

Microsoft's Windows 7 Explorer program presents another example of the Breadcrumbs pattern. While navigating the filesystem, the breadcrumbs control located at the top of the window presents the path to the current folder. Each folder in this chain is presented as a button that you can click in order to examine the folder's contents. You can also click on any of the parent folder buttons, as shown in Figure 4.

A second screenshot of the Breadcrumbs pattern. Screenshot by Jeff Friesen for JavaWorld

Figure 4. Breadcrumbs in Windows 7's Explorer program 

Architectural patterns

Architectural patterns have much in common with software design patterns but are broader in scope. Whereas software design patterns address issues at the source code level, architectural patterns address them at the higher level of software architecture. Issues addressed by architectural patterns include hardware performance limitations, high availability and scalability, and business risk minimization. Architectural patterns come in many flavors and are often best learned by studying an implementation example. The patterns below are further discussed in the linked JavaWorld articles and case studies:

  • An (extract, transform, load) architecture focuses on the extraction of data from outside sources, the transformation of this data to fit operational needs, and the loading of the transformed data into a data warehouse or other destination. Also see "ETL - Extract, Transform, Load" for a use case and a demonstration.
  • An promotes the production, detection, consumption of, and reaction to events (significant changes in state). For example, a vehicle's state changes from "for sale" to "sold" when it is purchased.
  • A architecture structures an application so that it can be decomposed into groups of subtasks. Each group of subtasks exists at a specific level of abstraction. The traditional three-tier client/server model is an example of this architectural pattern. Also see Design Pattern: Layers.
  • architecture is a client-server architectural pattern in which presentation, application processing, and data management functionality are separated into logical layers or tiers.
  • is a pattern that requires all business logic to be encapsulated by domain objects (that is, business objects); that the user interface be a direct representation of these domain objects, with all user actions focused on creating or retrieving domain objects and/or invoking methods on those objects; and that the user interface be automatically generated from the definition of the domain objects.
  • A pattern transforms data from one format into another by passing it through a series of filters (transformation processes) that are connected via pipes (data conduits). The ETL pattern typically leverages the pipe and filter architecture pattern to transform extracted data into a format that's capable of being stored in a data warehouse.
  • (SOA) provides a set of principles and methodologies for designing and developing software in the form of interoperable services, such as Web services. Various design patterns have been documented for solving problems related to SOA. For example, Version Identification addresses the problem in which a published service contract has changed and clients of this contract are unaware of the change, which results in clients missing an opportunity to utilize the change or being negatively impacted by the change.
  • is an architectural pattern that most Java developers are familiar with, for instance from using Struts or Spring. In MVC a model stores application data and business rules, the controller mediates input and converts it to commands for the model or view, and the view is any output representation of the model's data, such as a chart or a diagram.

    There is some confusion as to whether MVC is a software design pattern or an architectural pattern. In "

    Is MVC a design pattern or an architectural pattern?

    " blogger Kamal Wickramanayake makes the case for MVC being both a software design pattern and an architectural pattern.

See the end of this tutorial for more implementation examples for the above architectural patterns.

Organizational patterns

An organizational pattern documents the structure of relationships within a professional organization. Such patterns are discovered, documented, and used in order to help organizations achieve their goals. Although they're generally applicable throughout an organization, organizational patterns typically provide guidance for managing software development processes.

Organizational patterns apply to the structure of organizations rather than to the structure of source code and software architecture. Organizations have human-like characteristics (being comprised of humans); as such they can learn, and they can also be dysfunctional. By studying organizational behavior, lessons can be learned and documented as patterns that are shared with other organizations.

Organizational patterns aren't created or invented, but are discovered through empirical observation. This was demonstrated by early research at Bell Laboratories, in which patterns were discovered by analyzing social networks. This research used empirical role-playing techniques to gather information about the structure of relationships in the subject organization. These structures were analyzed for recurring patterns across organization and their contribution to achieving organizational goals. Successful structures were written up in pattern form to describe their tradeoffs and detailed design decisions (forces), the context in which they would apply, along with a generic description of the solution.

Organizational patterns provide an incremental path to improving an organization. The pattern style of building the organization works as follows:

  1. Find the weakest part of the organization.
  2. Find a pattern that is likely to strengthen the weakest part.
  3. Apply the pattern.
  4. Measure the results.
  5. If the pattern improved the situation, go back to Step 1 and find the next area for improvement. Otherwise, undo the pattern and try an alternative pattern.

Agile development as an organizational pattern

Organizational patterns are closely associated with the approach to software development. This approach focuses on iterative and incremental development where requirements and solutions evolve through collaboration between self-organizing and cross-functional teams. Agile is often with the more traditional waterfall method of software development.

Agile consultant James Coplien pioneered work on organizational design patterns and presented a paper on this topic at the Pattern Languages of Programs conference held in 1995. Together with Neil Harrison, Coplien subsequently collected organizational patterns and combined them into a collection of four pattern languages. This collection was then presented in Organizational Patterns of Agile Software Development, published in 2004.

In the book, Harrison and Coplien presented four inter-related pattern languages: Project Management, Piecemeal Growth, Organizational Style, and People and Code. Consider the following agile project management patterns:

  • Community of Trust: When assembling any project team, it's essential that team members trust each other so that work can get done. Interpersonal relationships have a positive or negative impact on the team's effectiveness.
  • Size the Schedule: A project must be understood and its size estimated before work begins. Developers become complacent when a project schedule is too long, and become overtaxed when the schedule is too short. Reward developers who meet the schedule.

Here are two Piecemeal Growth patterns:

  • Size the Organization: Large projects are rarely delivered on time and within budget when their development teams are too large or too small. Start projects with a critical mass of about 10 people to avoid having to add more people late in the project.
  • Phasing It In: Start a project by hiring people who possess a business's core competencies and then gradually add people as the project grows.
1 2 Page 1
Page 1 of 2
InfoWorld Technology of the Year Awards 2023. Now open for entries!