A series of posts providing proven guidance for developing ASP.NET MVC applications from idea to well-designed implementation.
Day 2 – Define the Domain Conceptual Model
Objective of the Day
Transform the requirements from Day 1 into an appropriate domain conceptual model reflecting objects, attributes, and associations.
- Project Vision
- User Stories or Use Cases
- Data Dictionary
The domain conceptual model is a visual representation of conceptual or real-world objects in the domain of interest [Fowler, 1996]. (The domain design model, which will be discussed in Day 3, is a visual representation of the classes and behaviors which will be implemented in the software.)
The conceptual model is not a class diagram describing classes with methods. But in practice, the conceptual model will iteratively become the basis of the class diagram of the design model. Specifically, the conceptual model reflects the following information:
- Domain conceptual objects,
- Associations between conceptual objects, and
- Attributes of conceptual objects.
The important distinction between conceptual model and design model is that the conceptual model should represent a clear business-oriented abstraction of the domain; i.e., the client should be able to look at the conceptual model and understand it fully without difficulty. Compare this to the design model which will include method names, data types, polymorphic associations, and supporting classes, such as factories and services.
To illustrate, suppose your domain includes the concept of “Customer” and “Employee.” The conceptual model would reflect two separate objects, each having duplicate attributes such as first name and last name. The design model may instead reflect a parent “Person” class, inherited by both Customer and Employee, having duplicated fields moved up to the Person superclass. Applying UML and Patterns [Larman 2004] goes into great deal concerning this process and is highly recommended read.
We’ll get into more details of the design process when we see it in action, next.
Putting it Into Practice
For Acme Telecom’s CLogS, the business requirements have been established. It is now time to begin transforming the requirements into a domain model.
The first step along this path is to define the conceptual model. We’ll define the conceptual objects, define their relationships with other objects, and add attributes, describing the pertinent information associated with each. But how exactly do we go about naming the conceptual objects? [Larman 2004] suggests looking for objects which fall into a Conceptual Class Category, such as:
- Physical or tangible objects,
- Transactions and transaction line items,
- Roles of people,
- Physical container of other things,
- Things in a container,
- Rules and policies, or
For finding associations, Larman suggests looking for the following types of associations:
- A is a physical or logical part of B,
- A is physically or logically contained in/on B, or
- A is recorded in or is a line item of B.
Now that we know what to look for, what artifacts do we look at as potential sources for objects? The primary sources include the vision, data dictionary, and user stories; i.e., the artifacts from Day 1.
As a caveat, if you find conceptual objects in the vision or data dictionary that are not included in the user stories, you should double check to make sure that the user stories are adequately representative of the requirements. While you may find extra concepts in the data dictionary, since it provides explanatory details of terms, extra concepts in the vision – but not found in the user stories – likely indicates an inadequacy, accordingly.
Looking at the inputs from the previous day, potential conceptual objects include:
- Support Staff
- Support Call
- Support Ticket
- Ticket Resolution Report per Support Staff
- Ticket Resolution Report per Issue Type
Compiling the list of concept objects will likely incite useful discussion, much of which will help to ensure that the business has been adequately modeled, and how the concept model will be later transformed into the design model.
At right, review an example of how the conceptual model could be visually modeled, for the concepts discussed, with associations and attributes. As shown, all of the major elements of the conceptual model have been visualized. There are some interesting things to note concerning this model:
- There are many duplicated fields between Management and SupportStaff. When implemented, these will likely be combined into a single Employee class; but recall that this is the conceptual model and should include more, rather than less, detail to cover all of the unique concepts within the requirements.
- SupportTicket and SupportCall have a one-to-one relationship with each other. These may have instead been merged into a single concept (and will be done so in the design model), but splitting them into separate concepts at this stage emphasizes that there is a call from the customer which leads to a ticket being opened.
- TicketResolutionReport is a report concept which includes a listing of SupportTickets and a number of ResolutionMetrics. Note that there is not an explicit association between TicketResolutionReport and the SupportTicket object to emphasize that the report, rather than being a core element of the domain, is an auxiliary concept to the domain. This is a subtle and subjective point but can help to establish bounded contexts during the design of the implementation. While it would not have been wrong to have included an explicit association, doing so would not have added much useful meaning to the context of the requirements. Associations between objects in a conceptual model should indicate some degree of permanence.
- As an additional note, the ResolutionMetrics attribute of TicketResolutionReport may indeed be a separate concept object itself; but at this point, it’s added as a placeholder, to be expanded upon at a later time.
As may be inferred, there’s certainly a lot of subjectivity and brainstorming that goes into creating the domain conceptual model. As such, don’t try as much to get it "just right" as to ensure that it comprehensively captures all of the key concepts and associations within the requirements.
When creating the conceptual model and you are faced with the decision to split a concept (or merge separate concepts), err on the side of splitting the concept to provide more granularity than may be necessary for the actual implementation; i.e., it’s better for the conceptual model to be too expressive than too simplistic. Once the concepts are established, you can always combine and regroup as necessary for the design model, but you don’t want to miss anything along the way.
As a final note, defining conceptual objects is more important than identifying the associations among them, and more time should be spent on object identification, accordingly.
That wraps up Day 2 in this series. In Day 3, we'll Define the Domain Design Model...
10-12-2012 4:00 PM