Domain Modelling

Presented ByDr. Shazzad Hosain

Domain ModelsA domain model is a visual representation of

conceptual classes or real-world objects in a domain of interest.

Identifying a rich set of objects or conceptual classes is at the heart of object-oriented analysis

In domain model no operations are defined. It may showDomain objects or conceptual classesAssociations between conceptual classesAttributes of conceptual classes

Domain Model, a Visual Dictionary of Abstractions

Domain Models are not Models of Software Components

Domain model shows conceptual class, not software class

Domain Models and DecompositionIn structured analysis the dimension of

decomposition is by processes or functions.In OO analysis the division is by conceptual classes

or objects.Example conceptual classes in the Sale Domain

Conceptual Classes1. A conceptual class is an idea, thing or object.2. It may be considered in terms of its symbol, intension and extension

Conceptual Class IdentificationIn incremental model iteratively identify

classes rather than identify all classes at the beginning.

For example, if the iteration is limited to cash-only ProcessSale scenario, then create domain model only for this one

It is better to overspecify a domain model with lots of fine-grained conceptual classes than to underspecify it.

Strategies to Identify Conceptual Classes

Use a conceptual class category listIdentify noun phrases, though need some art

Main Success Scenario (or Basic Flow):1.Customer arrives at the POS checkout with goods and/or services to purchase2.Cashier starts a new sale3.Cashier enters item identifier4.…………

Conceptual Class Category List

Conceptual Class Category

Examples

Physical or tangible objects

Register, Airplane

Places Store, Airport

Transactions Sale, Payment, Reservation

Organizations SalesDepartment, ObjectAirline

Rules and policies RefundPolicy, CancellationPolicy

Things in a container Item, Passenger

…… …….

Table 10.1 Conceptual Class Category List

Candidate Conceptual Classes for the Sales Domain, an Example

Register

Item

Store

Sale

Payment

ProductCatalog

ProductSpecification

Cashier

Customer

Manager

There is no such thing as a “correct” list. It is somewhat arbitrary collection of abstractions.

On Naming and Modeling Things: The MapmakerMake a domain model in the spirit of a

cartographer or mapmakerUser the existing names in the territoryExample, use “Borrower” or “Patron” for

customer in library domainExclude irrelevant features

Pen and PaperBag may be excluded from sales domain

Do not add things that are not there

A Common Mistake in Identifying Conceptual ClassesIf we do not think of some conceptual class X

as a number or text in the real world, X is probably a conceptual class, not an attribute.

Example: Should Store be an attribute of Sale, or a separate object

Should destination be an attribute of Flight, or Airport be a separate object

Resolving Similar Conceptual ClassesRegister vs. POST (point-of-sale terminal)

A domain model is not absolutely correct or wrong, but more or less useful; it is a tool of communication

Specification or Description Conceptual Classes

Assume that, Item instance represents a physical item in a store;

An item has a description, price, itemID which are not recorded any-where else.

Every time a real physical item is sold, the corresponding Item instance is deleted from “software land”

Worse Better

Another Specification ExampleLet an airline company suffers a fatal crash of one of its planesConsequently cancels all flights for investigation, delete Flight

instances, no longer a record of what flight routes the airline has

Descriptions of ServicesFlight example is about a service rather than a

good (such as a veggieburger item)Descriptions of services or service plans are

commonly neededAnother example: A mobile company sells

difference packages such as “bronze”, “gold”, “dijuce”, “nababi call rate” etc.

So you need a description class separate from an actual sold package.

Modeling the Unreal World Some software system has little analogy in real

world e.g. software for telecommunications.Still you can create a domain model.

Message

Connection

Route

Port

Protocol Dialog

UML Notations, Models and Methods: Multiple Perspectives

Software / design class

Domain concepts / conceptual class

class

Implementation classe.g. Java Class

Lowering the Representational Gap

Domain Modeling GuidelinesList the objects using category list and noun

phrase identification techniqueDraw them in a domain modelAdd associations necessary to record

relationshipsAdd attributes in necessary

Domain Model: Adding Associations

AssociationsAn association is a relationship between types (or

more specifically instances of those types) that indicated some meaningful and interesting connection.

Criteria for Useful AssociationsKnowledge of a relationship that needs to be

preserved for some duration – may milliseconds or years, depending on context. These are known as “need-to-know” associations.Example: Do we need to remember

SalesLineItem instances for Sale instance.Example: Relationship between Sale and

Manager?If n different objects then n*(n-1) associations. Be

parsimonious. Associations derived from the Common

Association List

UML Association Notation

Finding Associations – Common Association List

Category Examples

A is a physical part of B

Drawer – RegisterWing – Airplane

A is a logical part of B

SalesLineItem – Sale

A is a description for B

FlightDescription – Flight

A is a member of BCashier – StorePilot – Airline

A communicates with B

Customer – Cashier

A is owned by B Plane – Airline

…….. ………….

Table 11.1 Common Association List

RolesEach end of an association is called a role.

Roles may optionally have:Name (will discuss latter)Multiplicity ExpressionNavigability (will discuss latter)

Multiple AssociationsTwo types may have multiple associations

Naming AssociationsTypeName – VerbPhrase – TypeName format where the

verb phrase creates a sequence that is readable and meaningful in the model context

Should start with a capital letterTwo common and equally legal formats for a compound

association name are:Paid-byPaidBy

How Detail Should Association Be?Finding conceptual classes is more important

than finding association. The majority of time spent in domain model creation should be devoted to identifying conceptual classes, not associations.

NextGen POS Domain Model

SuggestionsFocus on need-to-know associationsAvoid redundant or derivable associations

Domain Model: Adding Attributes

AttributesAn attribute is a logical data value of an object

Keep attributes simpleE.g. Boolean, Date, Number, String, TimeOther examples are Address, Color, Universal

Product Code (UPC) etc.Relate conceptual classes with an association,

not with an attribute

Examples

Non-primitive Data Type Classes

Represent as non-primitive class if If composed of separate sections

Phone number, name of personThere are operations usually associated with it, such as

parsing / validationSocial security number

It has other attributesPromotional price could have start date and end date

It is a quantity with a unitPayment amount has a unit of currency

It is an abstraction of one or more types with some of these qualitiesItem identifier may be UPC or EAN (European Article Number)

Where to Illustrate Data Type Classes?

A domain model is a tool of communication; choices about what is shown should be made with that consideration in mind.

Design Creep: No Attributes as Foreign Keys

Relate objects with an association, not with an attribute

Modeling Attribute Quantities and UnitsMost numeric quantities should not be represented as

plain numbers. Consider price or velocity that are associated with units.

Multiplicity From SalesLineItem to Item

Derived attribute indicated with a “/” symbol

Domain Model Conclusion

NextGen POSSystem Model

ReferencesChapter 10, 11, 12 of “Applying UML and

Patterns – An Introduction to Object-Oriented Analysis and Design and the Unified Process” – by Craig Larman