By: Phumlani Simelane

Mr PT Simelane
E-mail:
PhumlaniS1@[Link]
1. PLEASE ALL CELLPHONES OFF OR PUT THEM ON SILENT
DURING LECTURES
2. DON’T BE LATE FOR CLASS
4. DON’T MAKE NOISE IN CLASS
6. TAKE NOTES AND ASK QUESTIONS

2
Aim/Purpose:
➢To provide students with Business Analysis tools and
methodologies to solve business related problems

3
 “Things” in the Problem Domain
◦ Data entities
◦ Domain classes
 The Domain Model Class Diagram
 The Entity-Relationship Diagram

A domain model contains conceptual classes,

4
 Explain how the concept of “things” in the
problem domain also define requirements
 Identify and analyze data entities and
domain classes needed in the system
 Read, interpret, and create an entity-
relationship diagram
 Read, interpret, and create a domain model
class diagram
 Understand the domain model class diagram
for the RMO Consolidated Sales and
Marketing System

5
 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 call them
data entities

6
 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

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

8
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

9
 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

10
11
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.

12
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?

13
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

14
 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.

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

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

17
⚫ Associations have minimum and maximum constraints
⚫ minimum is zero, the association is optional
⚫ If minimum is at least one, the association is mandatory

18
⚫ Binary Association
⚫ Associations between exactly two different classes
⚫ Course Section includes Students

⚫ Members join Club

⚫ Unary Association (recursive)

⚫ Part is made using parts

⚫ Ternary Association (three)

19
⚫ Class
⚫ A category 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 20
⚫ Domain class has no methods
⚫ Class name is always capitalized
⚫ Attribute names are not capitalized and use
camelback notation (words run together and
second word is capitalized)

21
⚫ 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

22
23
24
⚫ Where is each student’s grade remembered in this model?
⚫ Each section has many grades and each grade is association
with a student
⚫ Each student has many grades and each grade is association
with a section 25
⚫ Association class— an association that is treated as a class
in a many to many association because it has attributes that
need to be remembered, such as grade

26
⚫ 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

27
28
⚫ Abstract class— a class that allow subclasses to inherit
characteristics but never gets instantiated. In Italics (Sale
above)
⚫ Concrete class— a class that can have instances
29
⚫ A
SavingsAccount
has 4 attributes
⚫ A
CheckingAccoun
t Has 5 attributes
⚫ Note: the
subclasses
inherit the
associations, too

30
⚫ Whole-part relationship— a relationship between
classes where one class is part of or a component
portion of another class
⚫ Aggregation— a whole part relationship where the
component part exists separately and can be
removed and replaced (UML diamond symbol, next
slide)
⚫ Computer has disk storage devices
⚫ Car has wheels
⚫ Composition— a whole part relationship where the
parts can no longer be removed (filled in diamond
symbol)
⚫ Hand has fingers
⚫ Chip has circuits
31
⚫ Note: this is
composition,
with diamond
symbol.
⚫ Whole part can
have multiplicity
symbols, too
(not shown)

32
⚫ There are actually three types of relationships
in class diagrams
⚫ Association Relationships
⚫ These are associations discussed previously, just
like ERD relationships
⚫ Whole Part Relationships
⚫ One class is a component or part of another class

⚫ Generalizations/Specialization Relationships
⚫ Inheritance

⚫ So, try not to confuse relationship with

33
⚫ There are several ways to create the domain
model class diagram for a project
⚫ RMO CSMS has 27 domain classes overall
⚫ Can create one domain model class diagram
per subsystem for those working on a
subsystem
⚫ Can create one overall domain model class
diagram to provide an overview of the whole
system
⚫ Usually in early iterations, an initial draft of the
domain model class diagram is completed to
guide development and kept up to date
34
⚫ There are several ways to create the domain
model class diagram for a project
⚫ RMO CSMS has 27 domain classes overall
⚫ Can create one domain model class diagram
per subsystem for those working on a
subsystem
⚫ Can create one overall domain model class
diagram to provide an overview of the whole
system
⚫ Usually in early iterations, an initial draft of the
domain model class diagram is completed to
guide development and kept up to date
35
36
37
38
⚫ Given the complete RMO CSMS Domain Model
Class Diagram and Sales and Customer Account
subsystem examples:
⚫ Try completing the Order Fulfilment Subsystem Domain
Model Class Diagram
⚫ Try Completing the Marketing Subsystem Domain Model
Class Diagram
⚫ Try Completing the Reporting Subsystem Domain Model
Class Diagram
⚫ Review the use cases from Chapter 3 and decide
what classes and associations from the complete
model are required for each subsystem
⚫ Classes and associations might be duplicated in more
than one subsystem model

39
⚫ An ERD shows basically the same information
as a domain model class diagram
⚫ It is not a UML diagram, but it is widely used by
data analysts in database management
⚫ There really is no standard notation, but most
developers use the entity and crows feet
notation shown in this text
⚫ An ERD is not good for showing
generalization/specialization relationships and
whole part relationships

40
⚫ A simple ERD without showing attributes

41
42
⚫ Note: This diagram matches the semantic net shown
previously
⚫ Also matches a domain model class diagram shown
previously

43
44
Thank you…!