Scribd
Upload
18 views2 pages

Week8 Unit4 Notes KFL

The lecture notes focus on domain modeling, emphasizing the identification and analysis of data entities and domain classes essential for system requirements. It introduces techniques such as brainstorming and the noun technique to systematically identify 'things' in the problem domain, which can be modeled using Entity-Relationship Diagrams and UML class diagrams. Key concepts such as attributes, associations, and cardinality are also discussed to aid in understanding the relationships between these entities.

Uploaded by

thembi malinga
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
18 views2 pages

Week8 Unit4 Notes KFL

The lecture notes focus on domain modeling, emphasizing the identification and analysis of data entities and domain classes essential for system requirements. It introduces techniques such as brainstorming and the noun technique to systematically identify 'things' in the problem domain, which can be modeled using Entity-Relationship Diagrams and UML class diagrams. Key concepts such as attributes, associations, and cardinality are also discussed to aid in understanding the relationships between these entities.

Uploaded by

thembi malinga
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 2

Lecture notes

DOMAIN MODELING
Week 8
Learning outcome
 Explain how the concept of “things” in the problem domain also defines requirements
 Identify and analyse 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

Introduction
The focus of this study guide is to identify and define the entities or problem domain classes. Traditional
system development methodologies called these “things” data entities and used Entity-Relationship
Diagrams to model the data structure. Object-oriented techniques call these “things” problem domain
classes, or just classes for short. A UML class diagram is used to model the data structure. Students should be
familiar with both Entity-Relationship diagrams and Class diagrams.
The first part of the chapter is a discussion to help students find, identify, and classify these “things.”
The second part of the study unit instructs how to build an entity-relationship diagram, and the final topic in
the chapter is how to build a class diagram domain model.

Important notes
 attributes – descriptive pieces of information about things or objects

 identifier or key – an attribute the value of which uniquely identifies an individual thing or object 
compound attribute – an attribute that consists of multiple pieces of information but is best treated in the
aggregate  association – a term, in UML, that describes a naturally occurring relationship between specific
things, sometimes called a relationship

 relationship – a term that describes a naturally occurring association between specific things, sometimes
called an association

 cardinality – a measure of the number of links between one object and another object in a relationship

 multiplicity – a measure, in UML, of the number of links between one object and another object in an
association

 multiplicity constraints – the actual numeric count of the constraints on objects allowed in an association

 binary associations – associations between exactly two distinct types of things

 unary association – an association between two instances of the same type of thing

 ternary association – an association between exactly three distinct types of things

 n-ary association – an association between n distinct types of things


The Brainstorming Technique
This technique is a joint effort between the analyst and the users.. “Things” ranges from very
tangible things such as books and vehicles to roles such as employees and customers to quite
abstract things such as flights and orders. (You cannot observe a flight or an order with any of your
five senses.) Here are the steps to follow when using the brainstorming technique:
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


The noun technique is a more mechanical approach to identifying classes, but it is also a powerful
technique. The basic idea is to identify all the nouns, which are always some type of “thing,” and build the
list of all these nouns. Then refine the list to remove duplicates and identify which are classes and which are
attributes of classes. Here are the steps to follow when using the noun technique:

1. Using the use cases, actors, and other information about the system—including inputs and outputs—
identify all nouns.

2. Using other information from existing systems, current procedures, and current reports or forms, add
items or categories of information needed.

3. As this list of nouns builds, you will need to refine it. Ask these questions about each noun to help you
decide whether you should include it: ◦ Ask questions, such as is it important and inside the scope, to see if it
should be included. ◦ Ask questions to see if it really should be excluded, such as is it only a report or an input
or is it an attribute. ◦ Ask questions to see if it needs further research. In other words that you cannot answer
whether it needs to be included or excluded.

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 refine the list of things in the
problem domain.

You might also like