Software

Engineering
(CSE 327)
Lecture 5
(Domain Modeling)
 Problem Domain
• The specific area (or domain) of the user’s
business need (or problem) that is within the
scope of the new system.
• In other words, system developers are
developing a solution for a business need or
business problem. Hence the term problem
domain, or the context and arena in which the
business problem exists.
 Problem domain (from lecture 2)
• Identify actors
• Understand the need/impact of each actor
• Write down the goals of each actor
• What are the constraints that we have to work
with?
• What is the domain vocabulary?

Analysing the problem to figure out a direction

of solving this problem (“solution direction”)
 Solution domain (from lecture 2)
• Initially, we may just have a solution
direction
• Throughout the software development
process, we keep refining the solutions
based on:
– Our understanding of the problem domain
– Previous decisions made for the solution
• Note: Some of the decisions we made in the
past will restrict what we do next
 Model
• A model is a simplification of reality.
• The model captures the important aspects of
the thing being modeled and leaves out the
rest of the details.
 Why do we model?
• We build models so that we can better
understand the system we are developing.
• Through modeling, we achieve four aims:
– 1. Models help us to visualize a system as it is or
as we want it to be.
– 2. Models permit us to specify the structure or
behavior of a system.
– 3. Models give us a template that guides us in
constructing a system.
– 4. Models document the decisions we have made.
 Domain Modelling
• Using UML diagram to construct a model of
the real-world system:
– Understand the problem domain.
• Model recorded as a simplified class diagram.
• Seamless development:
– The same notation is used for analysis and design.
– The design can evolve from the initial domain
model.
 Domain Model Notation
• A subset of class diagram model elements are
used.
 Domain Model Notation
• Classes represent real-world entities.
• Attributes represent the data held about
entities.
• Associations represent relationships between
the entities.
• Generalization can be used to simplify the
structure of the model.
• Constraints can be used to indicate conditions.
 Case Study: Customers and Reservations

• Basic business fact: customers make reservations.

 Defining a Relationship
• Give a name to the relationship:
– use a verb so that the relationship can be read as
a sentence:
• A customer can make many reservations.
 Defining a Relationship
• Give a name to the relationship:
– use a verb so that the relationship can be read as
a sentence:
• A customer can make many reservations.

• How many people make a reservation?

– one principal contact whose details are held;
– that principal contact can make more than one
reservation (e.g., by postponing the time);
– the expected number of diners can be modelled
as an attribute of the reservation.
 Case Study: Tables and Reservation
• Is table an attribute of ‘Reservation’?
• Better modelled as a separate class:
– tables exist even if there are no reservations;
– other attributes of tables, e.g., size, can be stored.
 Use of Constraints
• Not all domain properties can be shown
graphically:
– e.g., it should be impossible to double-book a
table.
• Constraints add information to models:
– written in a note connected to the model element
being constrained.
Use of Constraints
 Use of Generalization
• A superclass can be used to show the properties
shared by different types of booking.
 Correctness
• How do we know when a domain model is
complete?
– we don't: there are lots of plausible models in
most cases.
• Domain modelling is not an end in itself, but a
guide to further development.
• Realizing use cases tests the domain model,
and will usually lead to refinements.
 Modelling structure
• The class diagram technique is central within
the Object Oriented paradigm when it comes
to capturing structure.
• The structure of a system can be captured
from different perspectives:
– Conceptual (E.g. A vehicle to transport the family)
– Specification
• High level (E.g. Car, Max speed, Fuel efficiency, …)
• Low level ( e.g. V6 engine, ABS, …)
– Implementation (E.g. Car engineering design …)
 Modelling perspectives
• Conceptual perspective
– Structure and model the concepts in the business
domain under study
• Specification perspective
– Focus on the interface of the software only
(consciously ignore the implementation detail)
• Implementation perspective
– Modelling at this level is for developers familiar
with the implementation framework and language
Modelling perspectives
 Conceptual Perspective
• At this level we are looking at the business
domain and all concepts within scope
• We structure and model the concepts in the
domain under study
• Natural relationships are captured, but these
A may
conceptual classrealised
not be diagram inmay
theinclude a few key
implemented
attributes,
system capture key associations, and may use
generalization relationships, may include cardinality but
must omit operations
 Specification perspective
• At this level, we are looking at software
– Interface of the software only
– We consciously ignore the implementation detail
• Object oriented methods put a great deal of
emphasis on the difference between the
interface and implementation
A specification level based
– Many industry class diagram shouldthat
studies show specify
teamallthat
key
attributes
have and some
kept operations,
this all associations
distinction have builtshould
more
indicate the cardinality
maintainable, flexible systems
 Implementation perspective
• By the time we get to this view,
– We understand the concepts in the domain and
how they are related
– We have modelled the interfaces (also known as
Types)
• This is pretty much reflective of the
implementation language and its features
Implementation level class diagram should include all
•operations
Modelling at this level
implementing thereally is for developers
responsibilities assigned to
thefamiliar
object with the implementation framework
and language
(UML) Class Diagrams
 Domain Modeling
• Domain modeling is known as conceptual
modeling.
• A Domain Model illustrates meaningful
concepts in a problem domain.
• It is a representation of real-world things, not
software components.
 Domain Modeling
• Representation of real-world conceptual
classes in the problem domain
– What’s a conceptual class?
– What are its attributes?
– What are description classes? Representation of
relationships between conceptual classes
– Associations between classes
– Generalization relationships
• Represented by a UML class diagram
– But it could also be described in text
 When to create Domain Model
• domain modelling is usually carried out in
parallel with use case modelling.
• the domain model represents a structural /
static view whereas use case modelling
focuses on behaviour.
• The domain model is viewed through a class
diagram.
 Why do we need a domain model?
• Gives a conceptual framework of the things in
the problem space.
• Helps us think – focus on semantics.
 Models of Domain Concepts

• Of course, it is not always this simple … !

 (good news)
Quiz-2 on Mid on
28/08/2023 04/09/2023
Project Progress on
23/08/2023