Practice 8. Understand the Domain


Per Kroll

A concise and shared understanding of the problem domain enhances communication and project effectiveness.

Problem

To 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.

Background

For 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:

  • Checking accounts. Yield no interest, but provide a broad set of services at a low fee.

  • Money market deposit accounts. Typically pay interest, but require a minimum balance, with fees charged for more than six withdrawals per month.

  • Savings accounts. Reasonable interest, some fees.

  • Time deposits or CDs. Often pay higher, fixed interest, but lock funds in for a predetermined period.

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.

In our daily life we present information through graphic depictions.


Applying the Practice

To 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 Concepts

To 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

A domain model shows graphically how various concepts are related.


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).

[1] See Jacobson 1992 for more information on domain models.

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.

Use UML to express the domain model.


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:

[2] Many people also use data modeling notations to capture domain models.

  • Association. Associations show how instances of one concept (for example, a specific employee in Figure 4.4) relate to instances of another concept (for example, a specific expense report). An association may have a multiplicity. The multiplicity can, for example, specify that a specific employee can have any number of expense reports (denoted with a "*") but only one credit card (denoted with a "1").

    Figure 4.4. Sample Association.

    An employee can file any number of expense reports (indicated by the "*" next to the expense report) but can have only one credit card on file in the system (indicated by the "1" next to the credit card) and only one manager. In reality, there may be many different managers (functional, administrative, and so on), but we can see from the role descriptor "Administrative Manager" that this system cares only about the administrative manager who has responsibility for approving expense reports.

  • Generalization. Generalizations show a general concept and specializations of that concept, as shown in Figure 4.5.

    Figure 4.5. Sample Generalization.

    There are three types of expense items: hotel, car rental, and airfare. These are all specializations of the general concept of expense items and thus share a number of common characteristics.

  • Aggregation. This relationship shows that one concept consists of, or is built up from, several other concepts (see Figure 4.6).

    Figure 4.6. Sample Aggregation.[3]

    This figure details some of the general information presented in Figure 4.3 by showing that an expense report is built up from header information specifying items such as purpose of trip and destination, along with a list of expense items. There is one set of header information, but there can be any number of expense items.

    [3] UML allows you to show different types of aggregations, such as composition. It is outside the scope of this book to discuss these finer details, and you must always ask yourself whether additional specificity is required to explain the domain, or whether you are better off keeping things simple.

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 Required

You 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.

[4] Ambler 2002.

Using Key Concepts in the Development Effort

When 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]

[5] Ambler 2003.

Domain objects are a great starting point for your design.


Document Business Rules

A 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:

[6] See the Glossary for the IBM Rational Unified Process.

  • If an order is canceled, and not yet shipped, the order should be closed.

    Business rules can be laws, regulations, or guidelines for running the business.


  • A team must not have more than eight members.

  • A rented car can be returned to a subsidiary company in another state. The renting subsidiary must ensure that the car has been returned by the end of the rental period. Ownership of the car will be transferred to the new subsidiary. Transfer of ownership must be initiated by the subsidiary that rented the car. The transfer value of the car should be decided according to fair estimate, as determined by corporate standard E-153.

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 Modeling

As 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]

[7] Within the IBM Rational Method Compose product, see RUP Plug-Ins for Business Modeling, as well as SOA for the RUP approach to business-driven software development.

It is key to link the business process to existing or new software capabilities.


Other Methods

All 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.

[8] Beck 2000.

XP relies heavily on verbally communicating domain information.


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.


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]

[9] See www.ibm.com/developer

[10] Ambler 2005.

Levels of Adoption

This practice can be adopted at three levels:

  • Basic. Include somebody in the project team who understands the domain well, and also the customer if possible. Capture key concepts in a glossary.

    The basic practice of capturing key concepts keeps the process light, while making it easier to communicate what needs to be done within the team.

  • Intermediate. Capture relevant concepts and their relationships as a set of class diagrams in a visual modeling tool. Reference glossary items as you document the system.

    The intermediate practice of capturing your domain model in visual modeling tools introduces some additional discipline, with an associated learning curve, but can also allow you to run the project more effectively, especially if it is a larger project. Changes can more rapidly and easily be communicated to the extended team, making it easier to support shorter iterations.

  • Advanced. Leverage business rules and business process modeling. This helps you to identify good components and services that map to how the business works. These components can be developed relatively independently, increasing your ability to deliver iteratively and improve the overall business over time.

    The advanced practice of leveraging business rules and business process modeling adds additional discipline and an associated learning curve. It is a practice appropriate for more complex projects. Because you are now adding more documentation, it typically becomes more cumbersome to keep all the information consistent and up-to-date, all of which tends to drive you toward longer iterations.

Related Practices

  • Practice 9: Describe Requirements from the User Perspective outlines how to document requirements in the form of use cases and support your requirements with storyboards and user-interface prototypes. It is desirable to model the domain in parallel with describing requirements.

  • Practice 10: Prioritize Requirements for Implementation shows how to determine which requirements to address in early iterations to drive the architecture and to mitigate key risks. Proper prioritization requires a good understanding of the domain.

Additional Information

Information in the Unified Process

OpenUP/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 Reading

The following books provide good insights into domain modeling and agile development:

Scott Ambler. Agile Modeling: Effective Practices for Extreme Programming and the Unified Process. John Wiley & Sons, 2002.

Eric Evans. Domain-Driven Design: Tackling Complexity in the Heart of Software. Addison-Wesley, 2004.

The following books provide a good insight into business rules and business modeling:

Ronald G. Ross. Principles of the Business Rule Approach. Addison-Wesley, 2003.

Ivar Jacobson, Maria Ericsson, and Agneta Jacobson. The Object Advantage: Business Process Reengineering with Object Technology. Addison-Wesley, 1997.



Agility and Discipline Made Easy(c) Practices from OpenUP and RUP
Agility and Discipline Made Easy: Practices from OpenUP and RUP
ISBN: 0321321308
EAN: 2147483647
Year: 2006
Pages: 98

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net