Introduction

This discipline in the software development life cycle is also termed as “Domain Modeling”,
which is the main artifact of the Elaboration phase of the Unified Process. It represents the
real world conceptual classes not the software classes. And, therefore, it is different from
object modeling that is more design and implementation oriented. Domain modeling help us to
identify to the relevant concept and ideas of the domain.

Domain Models:
 The domain objects required for the modeling are obtained from decomposition of the
 domain of interest (division by conceptual classes).
 It is a visual representation of real world objects in the domain, hence sometimes called
 domain objects model
 The UML notation illustrates a set of class diagrams without operations, but showing
domain
 objects, their associations and attributes.
· Key ideas of domain model are
 Domain model is a visual dictionary of abstractions
 Domain models are not models of software components
Before you ever create any tables of fields in a database, you should create a domain model of
the organization first. Think of a domain model as a type of flowchart that shows the activities
and concepts of a given topic. In this case, it is Wizard Accounting and its various departments
that we've been asked to convert into a system.
A domain model is NOT a listing of software specifics or database relationships. It is a model
that shows the real-world flow, relationships between entities, and concepts. We can't do any
of that until we have a solid understanding of the business reality.
Therefore, the following graphic shows the three main areas of Wizard Accounting that we'll
focus on.

s1
Relationships & Attributes:
A domain model can tell us the relationships between entities. In the Accounting entity, we
might have an employee and a job title. A domain model can show the relationship between
the two and define that relationship. A job is 'held by' an employee. One job can actually be
held by more than one employee.
Take note of the number 1 and the asterisk on the line. This means that for one job, there can
be any number of employees holding that job. You will see the term one-to-many to indicate
this relationship. For the database-minded, you will see this term in database design.
Remember, domain models are NOT database design documents! The graphic below shows
that in the Accounting Department of Wizard Accounting, the CPA-Tax job can be held by more
than one employee.

s2