Domain Model Analysis and Design

What is a Domain Model?

       A domain model is a visual representation of conceptual classes or real-situation objects in adomain [MO95, Fowler96]. Domain models have also been calledconceptual models(the term used in the first edition of this book),domain object models, and analysis object models.

Definition

     In the UP, the term "Domain Model" means a representation of real-situation conceptual classes, not of software objects. The term does not mean a set of diagrams describing software classes, the domain layer of a software architecture, or software objects with responsibilities.

What are Conceptual Classes?

       The domain model illustrates conceptual classes or vocabulary in the domain. Informally, a conceptua lclass is an idea, thing, or object. More formally, a conceptual classmay be considered in terms of its symbol, intension,and extension [MO95] (see Figure 9.5).

1. ·        Symbol words or imagesrepresenting a conceptual class.
2. ·        Intension the definition of aconceptual class.
3. ·        Extension the set of examplesto which the conceptual class applies.

Are Domain and Data Models the Same Thing?

       A domain model is not a data model (which by definition shows persistent data to be stored somewhere), so do not exclude a class simply because the requirements don't indicate any obvious need to remember information about it (a criterion common in data modeling for relationaldatabase design, but not relevant to domain modeling) or because the conceptua lclass has no attributes. For example, it's valid to have attributeless conceptual classes, or conceptual classes that have a purely behavioral role in the domain instead of an information role.

Why Create a Domain Model?

       Now, I knew almost nothing about this business, so one reason to create a domain model was so that I could start to understand their key concepts and vocabulary.

How to Find Conceptual Classes?

What are Three Strategies to Find Conceptual Classes?

1.     Reuse or modify existing models. This is the first, best, and usually easiest approach, and where I will start if I can. There are published, well-crafted domain models and data models (which can be modified into domain models) for many common domains, such as inventory, finance, health, and so forth. Example books that I'll turn to include Analysis Patternsby Martin Fowler, Data Model Patterns by DavidHay, and the Data Model Resource Book (volumes 1and 2) by Len Silverston.

2.      Use acategory list.

3.      Identifynoun phrases.

Method2: Use a Category List

 

Conceptual Class Category

Examples

business transactions

Guideline: These are critical (they involve money), so start with transactions.

Sale, Payment

Reservation

transaction line items

Guideline: Transactions often come with related line items, so consider these next.

SalesLineItem

product or service related to a transaction or transaction line item

Guideline: Transactions are for something (a product or service). Consider these next.

Item

Flight, Seat, Meal

where is the transaction recorded?

Guideline: Important.

Register, Ledger

FlightManifest

roles of people or organizations related to the transaction; actors in the use case

Guideline: We usually need to know about the parties involved in a transaction.

Cashier, Customer, Store MonopolyPlayer Passenger, Airline

place of transaction; place of service

Store

Airport, Plane, Seat

noteworthy events, often with a time or place we need to remember

Sale, Payment MonopolyGame Flight

physical objects

Guideline: This is especially relevant when creating device-control software, or simulations.

Item, Register Board, Piece, Die Airplane

descriptions of things

Guideline: See p. 147 for discussion.

ProductDescription

FlightDescription

catalogs

Guideline: Descriptions are often in a catalog.

ProductCatalog

FlightCatalog

containers of things (physical or information)

Store, Bin Board Airplane

things in a container

Item Square (in a Board) Passenger

other collaborating systems

CreditAuthorizationSystem

AirTrafficControl

records of finance, work, contracts, legal matters

Receipt, Ledger

MaintenanceLog

financial instruments

Cash, Check, LineOfCredit

TicketCredit

schedules, manuals, documents that are regularly referred to in order to perform work

DailyPriceChangeList

RepairSchedule

 

Method 3:Finding Conceptual Classes with Noun Phrase Identification

 

Guideline

Care must be applied with this method; a mechanical noun-to-class mapping isn't possible, and words in natural languages are ambiguous.

Example

Main Success Scenario (or Basic Flow):

1.  Customer arrives at a POS checkout with goods and/or services to purchase.

2.  Cashier starts a new sale.

3.  Cashier enters item identifier.

4.  System records sale line item and presents item description,price, and runningtotal. Price calculated from a set of price rules.

Cashier repeats steps 2-3 until indicates done.

5.  System presents total with taxes calculated.

6.  Cashier tells Customer the total, and asks forpayment.

7.  Customer pays and System handles payment.

8.  System logs the completed sale and sends sale and payment information to the external Accounting (for accounting andcommissions) and Inventory systems (to update inventory).

9.  System presents receipt.

10.  Customer leaves with receipt and goods (if any).

      

       Linguistic analysis is another source of inspiration. The fully dressed use cases are an excellent description to draw from for this analysis.

       A weakness of this approach is the imprecision of natural language; different noun phrases may represent the same conceptual class or attribute, among other ambiguities. Nevertheless,it is recommended in combination with the Conceptual Class Category List technique.

 

Associations

       An association is a relationship between classes (more precisely, instances of those classes)that indicates some meaningful and interesting connection (see Figure 9.11).

Guideline: Howto Find Associations with a Common Associations List

Category

Examples

A is a transaction related to another transaction B

CashPaymentSale

CancellationReservation

A is a line item of a transaction B

SalesLineItemSale

A is a product or service for a transaction (or line item) B

ItemSalesLineItem (or Sale)

FlightReservation

A is a role related to a transaction B

CustomerPayment

PassengerTicket

A is a physical or logical part of B

DrawerRegister

SquareBoard

SeatAirplane

A is physically or logically contained in/on B

RegisterStore, ItemShelf

SquareBoard

PassengerAirplane

A is a description for B

ProductDescriptionItem

FlightDescriptionFlight

A is known/logged/recorded/reported/captured in B

SaleRegister

PieceSquare

ReservationFlightManifest

A is a member of B

CashierStore

PlayerMonopolyGame

PilotAirline

A is an organizational subunit of B

DepartmentStore

MaintenanceAirline

A uses or manages or owns B

CashierRegister

PlayerPiece

PilotAirplane

A is next to B

SalesLineItemSalesLineItem

SquareSquare

CityCity

 

Attributes

 

       It is useful to identify those attributes of conceptual classes that are needed to satisfy the information requirements of the current scenarios under development. An attribute is a logical data value of an object.

 

Guideline:When to Show Attributes?

 

       Include attributes that the requirements(for example, use cases) suggest or imply a need to remember information.

       For example, a receipt (which reports theinformation of a sale) in the Process Sale usecase normally includes a date and time, the store name and address, and the cashier ID, among many other things.

Therefore,

·        Sale needs a dateTime attribute.

·        Store needs a name and address.

·        Cashier needs an ID.

 

Guideline:Where to Record Attribute Requirements?

       Instead, Isuggest placing all such attribute requirements in the UP Glossary,which serves as a data dictionary. Perhaps I've spent an hour sketching adomain model with a domain expert; afterwards, I can spend 15 minutes looking through it and transferring implied attribute requirements into the Glossary.

       Another alternative is to use a tool that integrates UML models with a data dictionary; then all attributes will automatically show up as dictionary elements.

Guideline

The attributes in a domain model should preferably be data types. Very common data types include: Boolean, Date (or DateTime), Number, Character, String (Text), Time.

Other common types include: Address, Color, Geometrics (Point, Rectangle), Phone Number, Social Security Number, Universal Product Code (UPC), SKU, ZIP or postal codes, enumerated types

 

Example

DomainModels Within the UP

 

Discipline

Artifact

Incep.

Elab.

Const.

Trans.

Iteration

I1

E1..En

C1..Cn

T1..T2

Business Modeling

Domain Model

s

Requirements

Use-Case Model (SSDs)

s

r

Vision

s

r

Supplementary Specification

s

r

Glossary

s

r

Design

Design Model

s

r

SW Architecture Document

s

Data Model

s

r

 

 

Conclusion:Is the Domain Model Correct?

       There is no such thing as a single correct domain model.All models are approximations of the domain we are attempting to understand; the domain model is primarily a tool of understanding and communication among a particular group.A useful domain model captures the essential abstractions and information required tounderstand the domain in the context of the current requirements, and aids people in understanding the domain its concepts, terminology, and relationships.