HNDIT2032

System Analysis
and Design

Advanced Technological Institute

Galle
 “Things” in the Problem Domain
• Domain classes or data entities are what end
users deal with when they do their work
– for example, products, sales, shippers, shipments,
and customers.
• These are often referred to as “things” in the
context of a system’s problem domain.
 problem domain
• The problem domain is the specific area of the
user’s business that is included within the scope
of the new system.
• The new system involves working with and
remembering these “things.”
– For example: customers and products
– a customer is a person who places an order, but the
system needs to store information about that
customer, so a customer is also a thing in the problem
domain
Techniques for identifying the things in
the problem domain.
• The brainstorming technique
• Noun technique.
 1. 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
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
• Nouns used to describe events, use cases, and the
actors are potential things.
• listing all the nouns that users mention when talking
about the system.
• Refine the list. 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?
• Create a master list of all nouns identified.
 Attributes
• many of these nouns are actually attributes.
• The analyst needs to identify the attributes of
each thing that the system needs to store.

Relationship
• a term that describes a naturally occurring
association between specific things.
 The Domain Model Class Diagram
• A class is a category or classification used to
describe a collection of objects. Each object
belongs to a class.
– Eg: students Mary, Joe, and Maria belong to the
class Student.
• Classes that describe things in the problem
domain are called domain classes
 class diagram
• Class diagrams are drawn by showing classes
and associations among classes.
• Class names and attribute names use
camelback notation, in which the words run
together without a space or underscore.
• Class names begin with a capital letter;
attribute names begin with a lowercase letter .
Class diagram
 Class
Collection of group of things that have the same
attributes and the same behaviors

13
 Class Diagram
• Class diagram describes the types of objects in
the system and the various kinds of static
relationships that exist among them.
• It also shows the attributes and services of a
class and the constraints that apply to the way
objects are connected.

14
 Class Stereotype:
Type of the Class;
entity for Analysis.

<<entity>>
Name of the Class
Patient
Attributes of the -name : CHAR
Class
-dateOfBirth: DATE
Operations of the
Class +getName ()

15
<<entity>>
Major Components
<<entity>>
Patient Doctor
Class: Class
With 3 -
-DoctorID Description
Compartments : Qual [0..N] Contains
Attributes
+ getDoctorDtls ()
&
Operations

Inheritance

Association Multiplicity
At each end
1..N 0 N
Of Association

Notes

16
 Class Diagram
• Name
– All words start in capital
– No spaces
• List of attributes
– No capitals in first word
– All other words only start with capital
– No space
• List of methods
– No capitals in first word
– All other words only start with capital
– No space
– Parentheses at the end
 Class Diagram
• Indicating data type and default value
 Class Diagram
• Function signature
– acceptCloths(c:String)int
• Function name acceptCloths
• Parameter : String type c
• Return value :type is int
 Class Diagram
• Including constraints
 Visibility
• + Public
• ‐ Private
• # Protected
• ~ Package

21
 Stereotypes and Classes
A Stereotype is a mechanism use to categorize
classes.

• Primary class stereotypes in UML

22
 Boundary Classes
• Provide the interface to a user or another
system.
• Handles communication between system
surroundings and the inside of the system
– User interface classes
– System interface classes
– Device interface classes

23
 Entity Classes
• Fundamental building block which perform
internal tasks
• Represent real world entity
• They correspond to database table

24
 Control Classes
• Objects that mediate between boundaries and
entities.
• Typically one control class per use case

25
 Relationships
• Association
• Aggregation/Composition
• Generalization/Inheritance
• Dependency

26
 Associations

• Link between classes

 Multiplicity
• Type of relationship
• The number of objects from one class that
relate with a single object in an associated
class
1 Exactly one
0..* Zero or more
1..* One or more
0..1 Zero or one
5..8 Specific Range (5,6,7 or 8)
Class Diagram
• Multiplicity
 Aggregation (Shared Association)
• Relationship between whole and it’ part
• Containing class with a diamonded single line
and contained class
Composition(Not-Shared Association)
• Stronger type aggregation
• Each component in a composite can belong to
just only one whole
• Child class's instance lifecycle is dependent on
the parent class's instance lifecycle.

31
Aggregation Vs. Composition
 Inheritance
• Base class or root class.
– No parents
• leaf class
– No children
• Single inheritance
– Single parent
• Multiple inheritance
– More than one parent
 Inheritance
• Create hierarchy of classes
• Classes at the top of hierarchy known as super
class
• Super classes holding the common
information
• Sub classes inherit all the features of super
classes

34
 Generalization/ Specialization
• Generalization
– Create super class encapsulate structure and
behavior common to number of classes
• Specialization
– Create sub class that represent refinement to
super class.
– Specific structure and behavior are added to sub
classes

35
 Generalization/ Specialization
Finding Super classes Generalization
Needs abstract thinking
Domain knowledge helpful
Helps in creating reusable Classes

Finding Subclasses
Concrete lower level
implementation thinking
Helps in using reusable Classes

Specialization

36
Example
 Reflexive Relations
Relationship of a class to itself

• Possible when a class has objects that can play

a variety of roles

38
Example

39
END