EDUCE:
A Pattern Language of Language Patterns

Nik Boyd

Abstract

Most software development projects fail, or fail to deliver their intended value, or fail to produce a net return on their (often substantial) investments. Software development is hard, not so much because the technologies are hard to use, but rather because we often don't clearly understand the problems we're trying to solve.

Most difficulties of understanding can be resolved by keeping problem statements simple, and then sharing problem descriptions widely to forge consensus understanding and foster the usage and codification of an ubiquitous language. Adherence to a few simple language patterns helps keep problem statements simple.

Background and Purposes

Software development is a knowledge intensive, knowledge driven activity. People are the reservoirs of the knowledge needed to develop software, both business knowledge and technical knowledge. In No Silver Bullet, Fred Brooks commented on the essential difficulties and challenges of software development and the need for incremental, convergent development. Brooks obvserved:

"The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is as difficult as establishing the detailed technical requirements, including all the interfaces to people, to machines, and to other systems. No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later."

Initial ideas for software solutions usually revolve around specific business problems or opportunities, but they will most often concentrate on some business vision or a mission-critical or mission-central theme, i.e., some specific problem domain which has attendant vocabulary, techniques, equipment, and quality concerns.

The earliest stages of software development usually include discussions about what a software product will do, whose needs it will serve, what problems it will solve, what business process improvements it will make, what opportunities it will address, and how it will support business decision making. All of these discussions require clear communication and (some level of) consensus among the various (and often diverse) solution stakeholders.

Several kinds of stakeholders serve as official information sources for software development, especially for software solution requirements. People who serve as information sources can be grouped broadly according to their collaborative roles, including corporate boards and officers (governors), those who manage business activities and request improvements therein (requestors), those who perform business activities and expect software solutions to improve those activities (expectors), and solution developers.

Successful software development requires effective collaboration between all interested stakeholders during software development projects that impact their interests. In order to communicate and collaborate effectively, stakeholders must share a common understanding of the problems they are trying to solve (or resolve). Without a common vocabulary and shared conceptual models of a business opportunity and its attendant problem(s), the effectiveness of a software development team and the likelihood that the developed solution will achieve its intended ends are substantially reduced (if not utterly doomed).

Software product managers, business analysts, and requirements engineers are typically responsible for eliciting, collecting, analyzing, and organizing software solution requirements, especially by translating the (often) relatively informal statements of stakeholders into more stylized and formalized statements of requirements. Software developers then translate these ideas into working code.

Many stakeholders only use natural language to describe their problems, concerns, and objectives. So, their knowledge and ideas take the form of natural language statements. EDUCE is a linguistic analytic process that simplifies natural language statements. EDUCE can help those crafting software solution requirements by guiding their efforts to analyze and organize those requirements. The EDUCE process applies several language patterns to complex statements of various kinds. The resulting statements have a consistent simplified grammar and style while retaining their original essential meaning.

While a few wordsmiths can be responsible for the proper crafting of simple problem statements, all software solution stakeholders must participate in the review and approval of the resulting terminology and definitions in order for a consensus language to emerge and become ubiquitous. Thus, the first purpose of EDUCE is to foster clarity and commonality throughout the various stakeholder communities, especially those tasked with establishing software solution requirements.

Useful (and even reusable) object discovery is at the heart of the object-oriented approach to software development. There are many opportunities for useful object discovery throughout the development of an object-oriented system. However, one of the greatest opportunities exists early in development during the elicitation and analysis of software solution requirements.

Finding good class candidates in software solution requirements can be challenging. Few software development methodologies offer guidance for finding good class candidates. Therefore, the second purpose of EDUCE is to guide the discovery of good class candidates that can be found in software solution requirements.

There are several pervasive metaphors used during software design that directly impact the naming of software elements and components. The metaphors used in object-oriented design center on the elements, techniques, and qualities found in the domain to be considered and modeled, and the attendant problems to be solved. Many of these software metaphors are derived from the language, vocabulary, and people (esp. roles) discovered in discussions about the problems to be solved.

Software elements and components need good names, including class names, instance names, method names, state names, value names, relationship names, role names, exception names, and responsibilities. Also, due to the structural constraints of object-oriented programming languages, object-oriented designs tend to be idiomatic: objects, classes, and their properties tend to be descriptive noun phrases, operations and relationships tend to be simple verb phrases. Therefore, the third purpose of EDUCE is to help software developers to make good software naming decisions, extending an ubiquitous language into the code based on the terminology discovered in the solution requirements.

EDUCE does not (nor intends to) replace other methodologies that serve the object-oriented approach to software development. EDUCE complements other methodologies and can help make them more effective. EDUCE is compatible with several other approaches to object discovery, including problem frames, user stories, use cases, feature driven development, and domain driven design. Also, EDUCE is oriented toward and intends to foster natural naming for software elements and components. Finally, because EDUCE focuses on statements, it can be applied incrementally. Therefore, EDUCE can be used in conjunction with agile requirements processes.

§ § §

Patterns Overview

Some of the EDUCE language patterns focus on business value, vision, and mission, while other patterns focus on conceptual models. The core EDUCE patterns focus on meaning preserving statement simplification and the organization of an emergent Domain Vocabulary. The following table provides quick links to each of these patterns.

§ § §