Lecture 4 – Domain Modeling

Subject: Modern System Analysis and Design

Objectives:
At the end of the lesson, students should be able to:
1. Explain how the concept of “things” in the problem domain also defines requirements.
2. Identify and analyze data entities and domain classes needed in the system.
3. Read, interpret, and create an entity-relationship diagram.
4. Read, interpret, and create a domain model class diagram.
5. Understand the domain model class diagram for the case study presented.
6. Read, interpret, and create a state machine diagram that models object behavior.

Overview
This chapter focuses on another key concept for defining requirements— data entities or
domain classes. In the RMO Tradeshow System from Chapter 1, some domain classes are
Supplier, Product, and Contact.
In this chapter’s opening case Waiters on Call, examples of domain classes are
Restaurants, Menu Items, Customers, Orders, Drivers, Routes, and Payments.

Things in the Problem Domain

• Problem domain—the specific area (or domain) of the users’ business need that is within
the scope of the new system.

• “Things” are those items users work with when accomplishing tasks that need to be
remembered

• Examples of “Things” are products, sales, shippers, customers, invoices, payments, etc.

• These “Things” are modeled as domain classes or data entities

• In this course, we will call them domain classes. In database class you may call them data
entities

Things in the Problem Domain

Two Techniques for Identifying Them

• Brainstorming Technique

• Use a checklist of all of the usual types of things typically found and brainstorm to
identify domain classes of each type
 • Noun Technique

• Identify all of the nouns that come up when the system is described and determine
if each is a domain class, an attribute, or not something we need to remember

Brainstorming Technique

• Are there any tangible things? Are there any organizational units? Sites/locations? Are
there incidents or events that need to be recorded?

Fig. 1. Types of things to use for the brainstorming technique.

Brainstorming Technique: Steps

1. Identify a user and a set of use cases
2. Brainstorm with the user to identify things involved when carrying out the use case—that
is, things about which information should be captured by the system.
3. Use the types of things (categories) to systematically ask questions about potential things,
such as the following: Are there any tangible things you store information about? Are there
any locations involved? Are there roles played by people that you need to remember?
4. Continue to work with all types of users and stakeholders to expand the brainstorming list
5. Merge the results, eliminate any duplicates, and compile an initial list
The Noun Technique

• A technique to identify problem domain classes (things) by finding, classifying, and refining
a list of nouns that come up in in discussions or documents
• Popular technique. Systematic.
• Does end up with long lists and many nouns that are not things that need to be stored by
the system
• Difficulty identifying synonyms and things that are really attributes
• Good place to start when there are no users available to help brainstorm

The Noun Technique: Steps

1. Using the use cases, actors, and other information about the system— including inputs
and outputs—identify all nouns.
• For the RMO CSMS, the nouns might include customer, product item, sale,
confirmation, transaction, shipping, bank, change request, summary report,
management, transaction report, accounting, back order, back order notification,
return, return confirmation…
2. Using other information from existing systems, current procedures, and current reports or
forms, add items or categories of information needed.
• For the RMO CSMS, these might include price, size, color, style, season, inventory
quantity, payment method, and shipping address.
3. As this list of nouns builds, refine it. Ask these questions about each noun to help you
decide whether you should include it:
• Is it a unique thing the system needs to know about?
• Is it inside the scope of the system I am working on?
• Does the system need to remember more than one of these items?
Ask these questions to decide to exclude it:
• Is it really a synonym for some other thing I have identified?
• Is it really just an output of the system produced from other information I have
identified?
• Is it really just an input that results in recording some other information I have
identified?
Ask these questions to research it:
• Is it likely to be a specific piece of information (attribute) about some other thing I
have identified?
• Is it something I might need if assumptions change?
4. Create a master list of all nouns identified and then note whether each one should be
included, excluded, or researched further.
5. Review the list with users, stakeholders, and team members and then define the list of
things in the problem domain.
 Partial List of Nouns for RMO

Details about Domain Classes

• Attribute— describes one piece of information about each instance of the class

• Customer has first name, last name, phone number

• Identifier or key

• One attribute uniquely identifies an instance of the class. Required for data entities,
optional for domain classes. Customer ID identifies a customer

• Compound attribute
 • Two or more attributes combined into one structure to simplify the model. (E.g.,
address rather than including number, street, city, state, zip separately).
Sometimes an identifier or key is a compound attribute.

Attributes and Values

• Class is a type of thing. Object is a specific instance of the class. Each instance has its
own values for an attribute

Associations Among Things

• Association— a naturally occurring relationship between classes (UML term)

- a relationship among instances of object classes (Valacich)

Fig. 2. Association among things.

Just to clarify…

• Called association on class diagram in UML

• Multiplicity is term for the number of associations between classes: 1 to 1 or 1 to

many (synonym to cardinality)

• UML is the primary emphasis of this text

• Called relationship on ERD in database class

• Cardinality is term for number of relationships in entity relationship diagrams: 1 to

1 or 1 to many (synonym to multiplicity)

• Associations and Relationships apply in two directions

• Read them separately each way

• A customer places an order

• An order is placed by a customer

Minimum and Maximum Multiplicity

• Associations have minimum and maximum constraints

• minimum is zero, the association is optional

• If minimum is at least one, the association is mandatory

Fig. 3. Multiplicity/cardinality of associations.

Types of Associations
1. Binary Association
• Associations between exactly two different classes
• Course Section includes Students
• Members join Club

Examples:

Fig. 4. Example of binary associations

The diagram above shows that a student may have an adviser, while a faculty member
may advise up to a maximum of 10 students. Also, while a course may have multiple offerings, a
given course offering is scheduled for exactly one course. A course may be taught by one or two
instructors.

Fig. 5. Class diagram showing associative classes

In Fig. 5, the attributes term and grade really belong to the many-to-many association
between Student and Course. The grade of a student for a course cannot be determined unless
both the student and the course are known. Similarly, to find the term(s) in which the student took
the course, both student and course must be known. The check Eligibility operation, which
determines if a student is eligible to register for a given course, also belongs to the association,
rather than to any of the two participating classes. We have also captured the fact that, for some
course registrations, a computer account is issued to a student. For these reasons, we model
Registration as an association class, with its own set of features and an association with another
class (Computer Account). Similarly, for the unary Tutors association, beginDate and
numberOfHrs (number of hours tutored) really belong to the association, and therefore they
appear in a separate association class.

Fig. 6. Example of generalizations, inheritance, and constrainnts

In Fig. 6, there are two types of patients: outpatients and resident patients. The features that
are shared by all patients—patientId, patientName, and admitDate—are stored in the Patient
superclass, whereas the features that are peculiar to a particular patient type are stored in the
corresponding subclass (e.g., checkbackDate of Outpatient). A generalization path is shown as a
solid line from the subclass to the superclass, with an arrow at the end, and pointing toward the
superclass. We also specify that this generalization is dynamic, meaning that an object may
change subtypes. This generalization is also complete (there are no other subclasses) and disjoint
(subclasses are not overlapping). Although not using exactly the same terminology, the same
generalization business rules that we saw with E-R diagramming can be represented.

2. Unary Association (recursive)

• Associations between two instances of the same class
• Person married to person
• Part is made using parts
 3. Ternary Association (three)

Fig. 7. Ternary relationship with association classes

Fig. 7 shows a ternary relationship among the Student, Software, and Course classes. It
captures the fact that students use various software tools for different courses. For example, we
could store the information that Mary Jones used Microsoft Access and Oracle for the Database
Management course, Rational Rose and Visual C++ for the Object-Oriented Modeling course,
and Jess for the Expert Systems Course. Now suppose we want to estimate the number of hours
per week Mary will spend using Oracle for the Database Management course. This process really
belongs to the ternary association, and not to any of the individual classes. Hence, we have
created an associative class called Log, within which we have declared an operation called
estimate Usage. In addition to this operation, we have specified three attributes that belong to the
association: beginDate, expiryDate, and hoursLogged.

4. N-ary Association (between n)

Representing Aggregation

An aggregation expresses a part-of relationship between a component object and an

aggregate object. It is a stronger form of association relationship (with the added “part-of”
semantics) and is represented with a hollow diamond at the aggregate end.

A solid diamond represents a stronger form of aggregation known as composition. In

composition, a part object belongs to only one whole object; for example, in Fig. 8, a room is part
of only one building. Therefore, the multiplicity on the aggregate end may not exceed one. Parts
may be created after the creation of the whole object; for example, rooms may be added to an
existing building. However, once part of a composition is created, it lives and dies with the whole,
deletion of the aggregate object cascades to its components. If a building is demolished, for
example, so are all its rooms. However, it is possible to delete a part before its aggregate dies,
just as it is possible to demolish a room without bringing down a building.

Fig. 8. Aggregation and composition

Entity-Relationship Diagrams (ERD)

• ERDs have been used for many years to develop data models that are used in database
development
• The term for “things” in ERD models is data entities
• ERD models are not UML models and do not use standard UML notation
• ERD models are not as expressive as UML models
• They do not model generalization/specialization well
• They do not model whole/part well
Example of ERD Notation

• ERD Models normally use “crows feet” notation to show cardinality

Fig. 9. A simple entity-relationship diagram.

ERD Cardinality Symbols

• Examples of crows feet notation for various cardinalities

Fig. 10. Cardinality symbols of ERD relationships.

Examples of cardinality constraints:
a. Mandatory cardinality

Fig. 11. Mandatory cardinalities

In Fig. 11, PATIENT Has_recorded PATIENT_HISTORY. Each patient has recorded one or
more patient histories (we assume that the initial patient visit is always recorded as an instance
of PATIENT HISTORY). Each instance of PATIENT HISTORY is a record for exactly one PATIENT

b. One optional, one mandatory cardinality

Fig. 12. One optional, one mandatory cardinality.

 In Fig. 12, EMPLOYEE Is_assigned_to PROJECT. Each PROJECT has at least one assigned
EMPLOYEE (some projects have more than one). Each EMPLOYEE may or (optionally) may not
be assigned to any existing PROJECT, or may be assigned to several PROJECTs.

c. optional cardinality

Fig. 13. Optional cardinalities.

In Fig. 13, PERSON Is_married_to PERSON. This is an optional zero or one cardinality in
both directions because a person may or may not be married.
It is possible for the maximum cardinality to be a fixed number, not an arbitrary “many”
value. For example, suppose corporate policy states that an employee may work on at most five
projects at the same time.
Expanded ERD with Attributes

• ERD with cardinalities and attributes

• There are several different notation methods for attributes in ERD models

• This notation places attributes within data entities

Fig. 14. An expanded ERD with attributes shown.

Degree of a Relationship
The degree of a relationship is the number of entity types that participate in that
relationship.

Fig. 15. Relationship type (completes).

Fig. 15 represents a training department in a company that is interested in tracking which
training courses each of its employees has completed. This leads to a relationship called
Completes between the EMPLOYEE and COURSE entity types. As indicated by the arrows, this
is a many-to-many relationship: each employee may complete more than one course, and each
course may be completed by more than one employee.
Thus, the relationship Completes illustrated in Fig. 15 is of degree two because there are
two entity types: EMPLOYEE and COURSE.
Types of Relationship
1. Unary or Recursive Relationship
- A relationship between instances of one entity type.

Fig. 16. Examples of unary or recursive relationships

2. Binary Relationships
- A relationship between instances of two entity types.

Fig. 17. Examples of binary relationships

 3. Ternary Relationship
- A simultaneous relationship among instances of three entity types.

Fig. 18. Example of a ternary relationship

Semantic Net

• A semantic net is a graphical representation of an individual data entity and its

relationship with other individual entities

• It is often used to help understand and then develop an ERD model

Fig. 19. Semantic net of customers, orders, and order items consistent with the expanded ERD.

The Domain Model Class Diagram

• Class

• A type of classification used to describe a collection of objects

• Domain Class

• Classes that describe objects in the problem domain

 • Class Diagram
• A UML diagram that shows classes with attributes and associations (plus methods
if it models software classes)
• Domain Model Class Diagram
• A class diagram that only includes classes from the problem domain, not software
classes so no methods

UML Domain Class Notation

• Domain class a name and attributes (no methods)

• Class name is always capitalized

• Attribute names are not capitalized and use camelback notation (words run together and
second word is capitalized)

• Compound class names also use camelback notation

Fig. 20. The UML domain class symbol with name and attributes.
A Simple Domain Model Class Diagram

Fig. 21. A simple domain model class diagram.

• Note: This diagram matches the semantic net shown previously

 • A customer places zero or more orders
• An order is placed by exactly one customer
• An order consists of one or more order items
• An order item is part of exactly one order

UML Notation for Multiplicity

Fig. 22. UML notation for multiplicity of associations

Domain Model Class Diagram

• Bank with many branches as show previously in ERD

• Note notation for the key

• Note the precise notation for the attributes (camelback)

• Note the multiplicity notation

Fig. 23. A domain model class diagram for a bank.

More Complex Issues about Classes: Generalization/Specialization Relationships

• Generalization/Specialization
• A hierarchical relationship where subordinate classes are special types of the
superior classes. Often called an Inheritance Hierarchy
• Superclass
• the superior or more general class in a generalization/specialization hierarchy
• Subclass
• the subordinate or more specialized class in a generalization/specialization
hierarchy
• Inheritance
• the concept that subclasses classes inherit characteristics of the more general
superclass

Generalization/Specialization

Fig. 24. Generalization/specialization relationships for motor vehicles.

Generalization/Specialization: Inheritance for RMO Three Types of Sales

• Abstract class— a class that allow subclasses to inherit characteristics but never gets
instantiated. In Italics (Sale)

• Concrete class— a class that can have instances

• Inheritance – Attributes of OnlineSale are:

• timeOnSite, chatUse, saleDateTime, priorityCode, S&H, tax, totalAmt…

 Fig. 25. Generalization/specialization relationships {inheritance} for sales.

RMO CSMS Project: Complete Domain Model Class Diagram

Fig. 26. Complete RMO CSMS domain model class diagram.

Object Behavior – State Machine Diagram

• Each class has objects that may have status conditions or “states”

• Object behavior consists of the various states and the movement between these states

• State – a condition during an object’s life when it satisfies some criterion, performs an
action, or waits for an event

• Transition – the movement of an object from one state to another

State Machine Diagram

• State Machine Diagram – a diagram which shows the life of an object in states and
transitions

• Origin state – the original state of an object before it begins a transition

• Destination state – the state to which an object moves after completing a transition

• pseudostate – the starting point in a state machine diagram. Noted by a black circle.

• action-expression – some activity that must be completed as part of a transition

• guard-condition – a true/false test to see whether a transition can fire

\State Machine for a Printer

Fig. 27. Simple state machine diagram for a printer.

Concurrency in a State Machine Diagram

• Concurrent states – when an object is in one or more states at the same time

• Path – a sequential set of connected states and transitions

• Concurrent paths – when multiple paths are being followed concurrently, i.e. when one
or more states in one path are parallel to states in another path
Printer with Concurrent Paths

Fig. 28. State machine diagram with concurrent paths

• Concurrent paths often shown by synchronization bars (same as Activity Diagram)

• Multiple exits from a state is an “OR” condition.

• Multiple exits from a synchronization bar is an “AND” condition.

Steps in Creating a State Machine Diagram

1. Review the class diagram and select classes that might require state machine diagrams
2. For each class, make a list of status conditions (states) you can identify
3. Begin building diagram fragments by identifying transitions that cause an object to leave
the identified state
4. Sequence these states in the correct order and aggregate combinations into larger
fragments
5. Review paths and look for independent, concurrent paths
6. Look for additional transitions and test both directions
7. Expand each transition with appropriate message event, guard condition, and action
expression
8. Review and test the state machine diagram for the class
 • Make sure state are really state for the object in the class

• Follow the life cycle of an object coming into existence and being deleted

• Be sure the diagram covers all exception condition

• Look again for concurrent paths and composite states

RMO – Creating a State Machine Diagram of SaleItem

1. Choose SaleItem. It has status conditions that need to be tracked
2. List the states and exit transitions

3. Build fragments – see figure below

4. Sequence in correct order – see figure below
5. Look for concurrent paths – none

Fig. 29. Partial state machine diagram for SaleItem object.

6. Add other required transitions
7. Expand with guard, action-expressions etc.
8. Review and test

Final State Machine Diagram

Fig. 30. Final state machine diagram for SaleItem object

RMO – Creating a State Machine Diagram of InventoryItem

1. Choose InventoryItem. It has status conditions that need to be tracked
2. List the states and exit transitions

Fig. 31. First-cut state machine diagram for InventoryItem object.

3. Build fragments – see figure below

4. Sequence in correct order – see figure below
5. Look for concurrent paths – see figure below

6. Add other required transitions

7. Expand with guard, action-expressions etc.
8. Review and test
 9. Below is the final State Machine Diagram

Fig. 32. Final state machine diagram for InventoryItem object.

Summary

• This chapter focuses on modeling functional requirements as a part of systems analysis

• “Things” in the problem domain are identified and modeled, called domain classes or data
entities

• Two techniques for identifying domain classes/data entities are the brainstorming
technique and the noun technique

• Domain classes have attributes and associations

• Associations are naturally occurring relationships among classes, and associations have
minimum and maximum multiplicity

• Entity-relationship diagrams (ERDs) show the information about data entities

• ERDs are often preferred by database analysts and are widely used

• ERDs are not UML diagrams, and an association is called a relationship, multiplicity is
called cardinality, and generalization/specialization (inheritance) and whole part
relationships are usually not shown

• Entity-relationship diagrams (ERDs) show the information about data entities

• ERDs are often preferred by database analysts and are widely used

• The UML class diagram notation is used to create a domain model class diagram for a
system. The domain model classes do not have methods because they are not yet
software classes.

• There are actually three UML class diagram relationships: association relationships,
generalization/specialization (inheritance) relationships, and whole part relationships

• Other class diagram concepts are abstract versus concrete classes, compound attributes,
composition and aggregation, association classes, super classes and subclasses

• Some objects have a life cycle with status conditions that change and should be tracked
• A State Machine Diagram tracks the behavior of these objects with states and transitions

• To develop a State Machine Diagram

• Choose a single object class.

• Identify the states and exit transitions

• Identify concurrent paths

• Identify additional paths

• Build the State Machine Diagram