Per Kroll A concise and shared understanding of the problem domain enhances communication and project effectiveness. ProblemTo develop an application, you often need to bring together people with very different backgrounds. You may have domain experts with limited technical expertise; developers, architects, and testers with limited domain expertise; and reviewers and other stakeholders with limited time to commit to the project and learn about the problem domain. These people often have an inconsistent or poor understanding of the problem domain in which you are building your software, such as how Company X signs up new insurance policies, or how Company Y deals with expense reports. This lack of understanding causes communication problems and increases the likelihood that they will build the wrong application. This practice shows you how to provide a concise and shared understanding of the problem domain. BackgroundFor convenience, when communicating with each other we often leave out a lot of information, making assumptions about what should be evident to the recipient of the information. For example, if I tell you, "I want a house with one bedroom, one bathroom, and a large kitchen. And I want both a shower and a bathtub," you would most likely understand that I want the shower and bathtub in the bathroom, not in the kitchen or bedroom. However, if you had never been in a house, that information would not be obvious. You have probably been in a meeting or discussion where everybody appears to be in agreement, only to discover later that each person came out of the meeting with a different understanding of what was agreed on. This is a common problem in software projects, where we are dealing with a lot of conceptual ideas and a problem domain that may be unfamiliar. Often, analysts write down requirements that are based on a misconceived notion of the problem domain; customers and other stakeholders do not understand what software requirements will address their business needs; and developers and testers do not sufficiently understand what problem the application is to address to build the right application. Obviously, such communication failures cause a lot of difficulties in software development. So how do we deal with these problems in other areas of life? Let's say that you work in a bank and want to explain what account types are available to a potential customer. Pretty soon the multitude of options in terms of account types can become overwhelming. To make it easier to explain the various loan types, you present the customer with a list, such as the following:
As you continue adding more details regarding which account types can be associated with an ATM card, credit cards, and direct deposit of paychecks, as well as which account types bear interest, you may find it easier to use graphics in addition to purely textual information to represent the many complex concepts and show how they are related (see Figure 4.2). We actually created this model when we first created a glossary and saw a need to model more complex relationships graphically through what we call a domain model. Domain models should be evolved as your understanding of the problem domain evolves. This means that you should expect the domain model to evolve along with your requirements, design, implementation, and test assets. Figure 4.2. Simple Domain Model.A domain model represents key concepts and their relationship to one another. This one shows different types of accounts and indicates which account type carries features, such as interest, ATM card, and credit card. This example provides you with a quick overview of the problem domain. It is important to include just the information required to explain the domain. Too much information clutters understanding and is too time-consuming for both the producer and consumer of information.
In our daily life we present information through clear definitions and graphic depictions to offset some of the difficulties in communication caused by differences in perspectives and experiences. The practice described here extends these ideas even further in an organized and structured fashion.
Applying the PracticeTo model the domain effectively, you first need to define key concepts within the domain, specify the key relationships between those concepts, and in some cases also detail the concepts in some depth. We will have a look at each of these activities and also provide some guidance on how to leverage key concepts most effectively in your development effort. Finally, we will discuss how you can capture business rules and use advanced practices such as business process modeling. Define Key ConceptsTo make sure that you share a common understanding of the problem domain, first identify the key "items" the application deals with. For example, for a travel expense application, define what expense types you can submit, what type of approvers you may have, and so on. Also add a glossary of common terminology used in the domain that the team or stakeholders may not be familiar with. This glossary is often owned by the analyst but updated by all team members as appropriate. To avoid miscommunication and misunderstanding, participants should agree on a common terminology. Hopefully, some of your team members are knowledgeable about the domain and can use this opportunity to share that knowledge effectively with other team members. If all team members already have an excellent knowledge of the domain, you may not need to define many or any concepts. In many situations, however, although team members think that they all agree on key concepts, as you start to discuss and detail them, you notice discrepancies in different team members' views; you may want to sort these discrepancies out. Specify Relationships Between Key Concepts
Many of the items in the glossary are related to each other, and to understand the problem domain, you need to understand these relationships. For example, for a travel expense application you want to know the answers to questions such as the following: What types of expense items are there? Who needs to approve an expense report? Can you automatically link an expense item to a transaction on your corporate credit card? What types of employee reimbursements are supported (direct deposit, checks)? This type of information can be captured in a glossary or domain model[1] One of the benefits of a domain model is that it shows graphically how various concepts are related (see Figure 4.3).
Figure 4.3. Domain Model for a Travel Expense Application.A domain model represents key concepts and their relationship to one another. In this travel expense reporting system, each employee needs to have a manager and only one credit card recognized by the system. The model also shows that there seems to be a way to couple credit card transactions to expense items on an expense report.
It is often a good idea to start by capturing a concept as a glossary item and then using the glossary as a source for identifying domain objects. If you know that a concept would be conveyed better graphically, you can capture it as a domain model directly. Another good starting point for the domain model is to ask a domain expert to use a pen and paper to draw you a picture showing an overview of the problem domain. As the expert graphically outlines the structure of key concepts, you often identify new concepts. Since many glossary items may have a corresponding domain object, information about the same concept may be stored in two places, which is undesirable. Instead, the glossary items should reference the domain object for a definition.
One of the purposes of the domain model is to provide an easily understood overview of the problem domain. We therefore use the standard language for software engineering, Unified Modeling Language (UML), to express the domain model.[2] To ensure that non-software experts understand your domain model, limit the number of different types of relationship you show between your domain objects. The most essential relationships to use include the following:
For domain models you should mostly use associations, and you may or may not use generalization or aggregations based on your needs and the audience. Role names are sometimes useful to clarify how one domain object relates to another. Detail Key Concepts as RequiredYou can also use a domain model to help everybody understand what critical information is typically captured for a domain object by capturing attributes. For example, a domain object Credit Card Transaction may have the attributes Transaction Amount, Transaction Date, and Transaction Establishment. As you detail key concepts with additional attributes or associations, remember that one of the key principles in software development is to travel light. As Scott Ambler writes in Agile Modeling,[4] do "just enough modeling and documentation to get by." It is a common mistake to put too much information into your domain model. If you are not sure you need it, don't include it.
Using Key Concepts in the Development EffortWhen you describe requirements, for example in the form of use cases, reference domain objects and glossary items to make sure that your requirements specification uses clearly defined terminology. This step will, among other things, allow reviewers, stakeholders, testers, and others to understand the requirements and the problem domain. Domain objects are also a great starting point for your design and will save you time later in the development effort. You will find that many domain objects map directly to a component, a set of components, an attribute within a component, and sometimes even a subsystem. In other cases you will find that a domain object has no corresponding representation in the design, since it captures a concept not managed by your application. Domain objects also provide you with a starting point for your data modeling effort, where many entities can be derived from your domain objects.[5]
Document Business RulesA business rule is a declaration of policy, heuristic, algorithm, or a condition that must be satisfied[6]; it is a requirement concerning how the business must operate. Business rules can be laws and regulations imposed on the business or guidelines for running the business effectively. Here are some examples of business rules:
Business rules are often captured in a separate document so that they can be referenced many times from different use cases, scenarios, or other requirements or design documentation but described only once. When writing use-case specifications or doing class designs, refer to applicable business rules in the same way that you would use glossary items. A document-based approach is useful when large numbers of business rules apply (for example, for financial products), or when there are lengthy textual descriptions for business rules (for example, for legislation). A disadvantage of this approach is that it captures business rules in a different artifact from the source where they apply. Business rules can also be captured in models (see Figure 4.7), as code in business rule engines, or as tests. The advantage of this technique is that it captures and displays business rules at the source where they apply. The main disadvantage is that because business rules are scattered throughout the model, it is difficult to view related rules. Reports can be generated to provide an overview of all business rules in the model. Figure 4.7. A UML Activity Diagram Showing a Business Rule.This figure shows a UML activity diagram that represents the following business rule: "If an order is canceled, and not yet shipped, the order should be closed. If the order has been shipped, the Manage Order Return procedure should first be followed and the order then closed." (Adapted from "RUP Business Modeling Discipline," produced by Empulsys BV.) Business Process ModelingAs software is increasingly crucial to how businesses are run, models of the business and of the software that supports it need to be closely coupled. To understand a particular business better, you can model "as is" or future business processes as a black box using business use cases, with textual description or activity diagrams providing detailed descriptions. A variety of diagrams, including interaction diagrams and process models (see Figure 4.8), can also be used to produce white-box descriptions, or so-called business use-case realizations, so that you can understand how various people, organizations, or systems are collaborating to run the business process. Especially if you are modeling future business processes, you should simulate them using process models to understand whether the business process will work as planned. Figure 4.8. A Process Model Using BPMN.This figure shows a process model that represents a business process. It uses an emerging OMG standard called Business Process Modeling Notation (BPMN), a language that allows you to graphically depict flows and decision nodes. The model can be used to simulate business processes. (Adapted from White 2005.) A key aspect of business process modeling is to link the business process to existing or new software capabilities to ensure that the software you develop will enable you to run the business as expected. RUP refers to this approach as business-driven software development.[7]
Other MethodsAll agile methods put a great deal of emphasis on understanding the domain, and a key aspect they all share is to involve the customer in the project team to ensure easy access to domain expertise. XP relies heavily on verbally communicating domain information by encouraging continuous communication within your team, thus creating and maintaining a minimum of requirements documentation and domain models. XP also leverages metaphors to aid communication. "A metaphor is a story that everyonecustomers, developers, and managerscan tell about how the system works."[8] The metaphor concept has been criticized as insufficient and vague. If there is a need to clarify a certain aspect of the domain, you may capture some aspects of it as a model, preferably on a whiteboard. If this model needs to be communicated more broadly, you may take a photo of the whiteboard and place it on a Wiki Web site.
Scrum focuses primarily on management activities and does not provide specific guidance on domain modeling. Agile modeling is, as the name indicates, more prone to do modeling and articulates the value of modeling the domain. A key principle is to create only the models you really need and not do too much modeling up front as you speculate about what functionality may be built. Agile modeling guides you in leveraging domain models to aid in your design and data modeling efforts.
RUP puts greater value on documenting key aspects of your domain than do many other agile processes, such as XP. The increased clarity of having a formal model can often save a lot of time by reducing the number of misunderstandings. RUP emphasizes only modeling the aspects of the domain that are relevant for the current project and developing a domain model iteratively, in conjunction with evolving the requirements, design, implementation, and testing. RUP does recognize that for certain projects, such as reengineering projects for which you have a very vague understanding of what type of system you are dealing with, you first need to understand the domain enough to determine the correct next step. That analysis will help you understand what parts of a system you need to reengineer and whether you can leverage existing legacy systems, acquire packaged applications, or need to develop custom software to address your needs. It is, however, important to move as rapidly as possible toward partial implementations of the system in order to validate assumptions that you have made. RUP also emphasizes using tools built to allow you to collaborate easily on representations of your domain, versus, for example, using only whiteboards. The agile community is increasingly focusing on how to couple the needs of the business closely with the software development effort by tightly integrating software development with business process design, and we should expect more guidance in this area over the next couple of years. Documentation on these topics can be found in RUP's Plug-In for Business Modeling[9] and Scott Ambler's Enterprise Unified Process.[10]
Levels of AdoptionThis practice can be adopted at three levels:
Related Practices
Additional InformationInformation in the Unified ProcessOpenUP/Basic describes how to capture a glossary and how to depict key concepts graphically. RUP also provides guidelines and artifacts for domain object modeling and expands on that content to cover complete business modeling, including how to leverage business rules and how to simulate business processes. Additional ReadingThe following books provide good insights into domain modeling and agile development:
The following books provide a good insight into business rules and business modeling:
|