0% found this document useful (0 votes)
38 views

CSIT114-Week 6 - Domain Modelling

This document discusses domain modeling and class diagrams. It provides an overview of techniques for identifying domain classes, including brainstorming and identifying nouns. It describes the key components of domain classes, such as attributes and identifiers. It also discusses different types of associations that can exist between domain classes, including binary, unary, and ternary associations. Finally, it defines domain model class diagrams and their purpose in representing the relationships between domain classes in the problem domain.

Uploaded by

adam hope
Copyright
© © All Rights Reserved
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
38 views

CSIT114-Week 6 - Domain Modelling

This document discusses domain modeling and class diagrams. It provides an overview of techniques for identifying domain classes, including brainstorming and identifying nouns. It describes the key components of domain classes, such as attributes and identifiers. It also discusses different types of associations that can exist between domain classes, including binary, unary, and ternary associations. Finally, it defines domain model class diagrams and their purpose in representing the relationships between domain classes in the problem domain.

Uploaded by

adam hope
Copyright
© © All Rights Reserved
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 49

University of Wollongong in Dubai

CSIT114 – System Analysis


Domain Modeling

Dr. Haitham Yaish


Dr. Zeenath Reza Khan
Document Change Control

Version Author Date Change Description


1.0 Dr. Zeenath Reza Khan Autumn 2019 Defined the first version
2.0 Dr. Haitham Yaish Autumn 2023 Updated and created
new Lecture Content.

3
Agenda

• Techniques to identify things.


• Domain Classes
• Types of Associations
• Domain Model Class Diagram
• Class Diagrams Class Activities
• Case Study
• Entity Relationship Diagrams (ERD)
• ERD Class Activity

4
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 call them data entities
Source: https://flylib.com/books/en/2.623.1.30/1/

5
Techniques to identify things

Brainstorming
Technique

Noun
Technique

6
Techniques to identify things

• 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
Brainstorming

• Are there any tangible things?


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

8
Brainstorming Steps

Use the types of


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

9
The Noun Technique

• A technique to identify problem domain classes


(things) by finding, classifying, and refining a list of
nouns that come up 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.

• Good place to start when there are no users available


to help brainstorm.

10
The Noun Technique Steps

1. Using the use cases, actors, and other information about the
system— including inputs and outputs—identify all nouns.
– Example: 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.
– Example: these might include price, size, color, style,
season, inventory quantity, payment method, and
shipping address.

11
The Noun Technique Steps

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?

12
The Noun Technique Steps

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.

13
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.

14
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

15
Associations among things

 Association— a naturally occurring relationship between classes (UML


term)

16
Types of Associations

 Binary Association
 Associations between exactly two different classes
 Course Section includes Students
 Members join Club

 Unary Association (recursive)


 Associations between two instances
of the same class
 Person married to person
 Part is made using parts

 Ternary Association (three)


 N-ary Association (between n)

17
Associations among things

 Called association on class diagram in UML


 Multiplicity is term for the number of associations between classes: 1
to 1 or 1 to many
 We are emphasizing UML in this subject
 Called relationship on Entity Relationship Diagram in
database class
 Cardinality is term for number of relationships in entity relationship
diagrams: 1 to 1 or 1 to many
 Associations and Relationships apply in two directions
 Read them separately each way
 A customer places an order
 An order is placed by a customer

18
Domain Model Class Diagram

 Class
 A category of classification used to describe a collection of
objects (instances)
 Domain Class
 Classes that describe objects in the problem domain
 Class Diagram
 A UML diagram that shows classes with attributes and
associations
 Domain Model Class Diagram
 A class diagram that only includes classes from the problem
domain

19
Domain Model Class Diagram

Domain class diagrams Vs. design model class diagrams

• Both types of class diagrams used in system analysis and system design, but they serve different
purposes and are created at different stages of SDLC.

• Purpose Domain class diagrams: are used to model the fundamental concepts and entities in
the problem domain. They represent the real-world objects, their attributes, and relationships.

• Purpose Design class diagrams: are less abstract and may include implementation-specific
details. They capture the structure of software components, including methods (operations) and
attributes.
Attributes are usually listed in the form: ​Access_modifier attribute_Name : Type​

Public (+): visible to all classes​


Protected (#): visible from within the class and from the subclasses, but
not from outside.
Private (-): visible only from within the class. It cannot be accessed from
outside the class.

• Our Main focus in this subject will be on Domain class Diagrams.


20
Domain Class Notation

 Domain class has no methods


 Class name is always capitalized
 Attribute names are not capitalized and use camelback
(camelCase) notation (words run together and second word
is capitalized)

21
UML notation for Multiplicity

22
A Simple Domain Model Class Diagram

 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

has Relates to

23
Domain Model Class Diagram for a bank with many branches

24
Domain Model Class Diagram
for course enrollment at our university

 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
Domain Model Class Diagram
for course enrollment at our university

 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.

• Course Enrollment at a University


• A Course has many CourseSections
• A CourseSection has many
Students and a Student is registered
in many CourseSections
• Problem
– How/where to capture student
grades?

26
Domain Model Class Diagram
for course enrollment at our university

 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.

has belongs

enrolls

has

27
Association Class Properties

• The association class is the same “thing” as the association itself


• The unique identifier (key) for the association class is the series
of the keys of the attached classes
– In the previous example the key for CourseSection is
CourseNumber + SectionNumber
– Hence the key for CourseEnrollment is
CourseNumber + SectionNumber + StudentID
– Note: If more information is required to uniquely identify
instances of the association class, then the model is incorrect,
i.e., if the key cannot be formed by the series of the endpoint
keys, it is in error.

28
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 inherit characteristics of the more general
superclass

29
Generalization/Specialization Relationships

Triangle: Superclass (Generalization of a class)


Points to the
Superclass to The car has three subclasses
Gen/Spec (Specialization of a class)
Hierarchy

30
30
Whole Part Relationships

 Whole-part relationship— a relationship between classes


where one class is part of or a component portion of another
class.

1- Aggregation
2 – Composition

31
Whole Part Relationships

 Aggregation— A logical whole-part relationship between a whole


and a constituent part​.
 A whole part relationship where the component part exists separately
and can be removed and replaced.
 The part can exist independently from the whole-part.

 Aggregation associations are denoted by a hollow-diamond on the


association​linked to the whole-part.
Example:

32
Whole Part Relationships

 Note: this is
aggregation
 Whole part can have
multiplicity symbols,
too (not shown)

33
Whole Part Relationships

 Composition— A physical/strong whole-part relationship between a


whole and a constituent part​.
 A whole part relationship where the parts can no longer be
removed.
 The part cannot exist independently from the whole.

 Composition associations are denoted by a filled-diamond on the


association​linked to the whole-part.
Example:

34
UML Relationships

 There are actually three types of relationships in class


diagrams
 Association Relationships
 These are associations discussed previously.

 Whole Part Relationships


 One class is a component or part of another class (Aggregation
and Composition)
 Generalizations/Specialization Relationships
 Inheritance

 So, try not to confuse relationship with association

35
Class Activity 1

In your groups, draw the class relationship between Book and Chapter.

36
Class Activity 2

In your groups, draw the class relationship between Room and Wall.

37
Class Activity 3

In your groups, specify the association name and multiplicity to indicating how many
objects participate in the given relationship​.

38
Class Activity 4

In your groups, draw the class relationship between I/O Device, Scanner, Keyboard,
and Mouse.

39
Case Study

An organization has employees who are working for it. The


attributes of an Employee include employee ID, first name, last
name, gender, address, and birthdate. The organization has
several projects. The attributes of the Project, include project ID,
project name, start date, and end date. Each employee may be
assigned to zero or more projects. A project must have at least
one employee assigned to it. The billing rates of the project
employees may vary by project, and the organization wishes to
record the applicable billing rate for each employee when
assigned to a particular project, the start and the end dates of
assigning the employee to the project.
Case Study
Entity Relationship Diagrams (ERD)

 An ERD shows basically to an extent a similar


information as a domain model class diagram
 It is used by data analysts in database management.
 An ERD is not good for showing
generalization/specialization relationships and whole
part relationships
 There are several widely used styles of notations for
Entity-Relationship Diagrams (ERDs).
 In this lecture you will learn crows feet notation.

42
Entity Relationship Diagrams (ERD)

 A simple ERD without showing attributes

43
ERD Cardinality Symbols
often called the crows feet notation

44
Expanded ERD with attributes

 Note: This diagram matches the semantic net shown previously


 Also matches a domain model class diagram shown previously
45
ERD Class Activity

In your groups, try developing an ERD for a bank

46
References
• Satzinger, J., Jackson, R. & Burd, S. (2016) Systems Analysis And Design In A
Changing World. 7th Edition, Boston, Mass. Cengage Learning.
• OOAD - UML Basic Notations.
https://www.tutorialspoint.com/object_oriented_analysis_design/ooad_uml_basic
_notation.htm
. Last Accessed 14 October 2023.
• Camel case. https://en.wikipedia.org/wiki/Camel_case . Last Accessed 14 October
2023.

47
THANK YOU
Any Question ?

48

You might also like