Class 

Based Modeling
.
 Class Diagram
1. Noun-phrase approach
2. Common Class patterns
3. Class-Responsibility-Collaborator
4. Use-Case driven approach
 1. Noun-phrase approach

• Initial list of noun phrases

• Eliminate irrelevant classes
• Reviewing redundant classes
• Review adjective classes
• Review possible attributes
• Review the class purpose
 1.1 Initial list of Noun phrases
• Guidelines for identifying tentative classes
Look for nouns in the System Requirements
Specification (SRS)
Some classes are implicit or taken from general
knowledge
All classes are to be taken from problem domain
Carefully choose and define class names
 1.2 Eliminate Irrelevant classes
• Noun-phrase are put into 3 categories
Relevant classes
Fuzzy classes
Irrelevant classes - unnecessary, so omit
 1.3 Reviewing Redundant classes
• Redundant classes from Relevant and Fuzzy
classes
Do not keep two classes that express the same
information
In case of more than one to describe the same
idea, choose the word used by user of the system
 1.4 Review Adjective classes
• Adjectives are used in many ways
 Adjectives can suggest a different kind of object
 Different use of the same object

• Find whether the object represented by noun

behave differently when the adjective is applied to
it.

• Make a new class only if the behavior is different

 1.5 Review possible Attributes
• Attribute classes
Classes defined only as values should be restated
as attributes and not classes
 1.6 Review the class purpose
• Each class must have a purpose and every
class should be clearly defined.
• Formulate a statement of purpose for each
candidate class.
• Otherwise, eliminate the candidate class
Class Structure
Role Name, Relationship name, Multiplicity
 Multiplicity
• 1:1
• 1:N
• N:1
Click to add text
• N:M
• Meta character – “*” and “+”
Identifying Class Relationships, Attributes and
Methods
.
 Guidelines for Identifying Association

Class A and B are associated if

• An object of class A sends a message to an
object of class B
• An object of class A creates an object of class B
• An object of class A has an attribute whose
values are objects of class B
• An object of class A receives a message with an
object of class B as an argument

14
 Guidelines for Identifying a Super-sub
Relationship
• Top-down
Look for noun phrases composed of adjectives in a
class name.

• Bottom up
Look for classes with similar attributes or methods
 Identifying the Composition &
Aggregation/a-part-of Relationship
• Composition - a physical whole is constructed from physical parts
(Assembly)
 Eg1: Building constructed by bricks, stones
 Eg2: ATM with Card Reader, Console, Printer, Key Pad

• Aggregation - a physical whole encompasses but is not constructed from

physical parts (Container)
 Eg1: Building with Furniture, Appliances
 Eg2: Car with AC and Radio

• Collection-member – a conceptual whole encompasses parts that may

be physical or conceptual
 Eg: University and Institution
Examples on Relationships
Relationship Notation
 Association Class
.
Dependency Relationship
Ternary (n-ary) Association
 2. Common Class patterns approach

• Based on a knowledge base of the common

classes proposed by various researchers
Concept class
Event class
Organization class
People class
Place class
Tangible things and device class
Review the class purpose
 2.1 Concept Class
• Idea or understanding of the problem
• Principles that are not tangible, and used to
organize or keeping track of business activities
E.g.: Performance, reservation
 2.2 Event class
• Things happen at a given date and time
• Points in time that must be recorded
E.g.: Request, order
 2.3 Organization class
• A collection of people, resources, facilities, or
group to which the users belong
E.g.: Accounting department
 2.4 People class (roles class)
• Different roles users play in interacting with
application
• Guideline
Classes that represent users of the system
E.g.: Operator, clerk
Classes representing people who do not use the
system but about whom information is kept by the
system
E.g.: Employee, client, teacher, manager
 2.5 Places class
• Areas set aside for people or things
• Physical locations that the system must keep
information about
E.g.: Building, store, site, travel office
 2.6 Tangible things
• Physical objects or groups of objects that are
tangible and devices with which application
interacts
E.g.: Car, ATM
 4. Class-Responsibility-Collaborator (CRC)
approach
• They add useful insights throughout the
development including in the early stages of
identifying classes and associations.
• E.g.: “maintain data about the book’ is a
responsibility, but there might be many
associated operations for achieving it

29
 Creating CRC Cards
• The name of a class at the top
• The responsibilities of the class on the left
hand side
• The collaborators of the class on the right
hand side of the card

30
Creating CRC Cards

31
 Use-Case Driven Approach
• Identify the active entities in the system
(actor)
• Identify business domain (“passive”) entities
in the system (reflect business domain hence
potential class)
ATM Case Study –System Requirements
• The bank client must be able to deposit an amount to and withdraw
an amount from his or her accounts using the touch screen at the
ATM kiosk. Each transaction must be recorded, and the client must
be able to review all transactions performed against a given
account. Recorded transactions must include the date, time,
transaction type, amount and account balance after the transaction

• A bank client can have two types of accounts: a checking account

and savings account. For each checking account, one related savings
account can exist.

• Access to the bank accounts is provided by a PIN code consisting of

four integer digits between 0 and 9
ATM Case Study –System Requirements
• One PIN code allows access to all accounts held by a bank client

• No receipts will be provided for any account transactions

• The bank application operates for a single banking institution only

• Neither a checking nor a savings account can have a negative

balance. The system should automatically with draw money from
a related savings account if the requested withdrawal amount on
the checking account is more than its current balance. If the
balance on a savings account is less than the withdrawal amount
requested, the transaction will stop and the bank client will be
notified.
 Apply Common Class patterns to ATM Case
study
• Concept class - Availability
• Events class – Account, Checking account,
Savings account, Transaction class
• Organization class – Bank class
• People class – BankClient class
• Places class – Building
• Tangible things and devices class – ATM Kiosk
 Case Study – ATM
Identifying the Class & Relationship
 Case Study – ATM
Identifying the Class, Relationship & Attribute
 Case Study – ATM
Identifying the Class, Relationship, Attribute & Method
 Identifying a list of candidate classes:
Example 1
The library contains books and journals. It may have several
copies of a given book. Some of the books are for short
term loans only. All other books may be borrowed by any
library members for 3 weeks. Member of the library can
normally borrow up to 6 items at a time, but members of
staff may borrow up to 12 items at one time. Only
members of staff may borrow journals.
The system must keep track of when books and journals
are borrowed and returned by the user, enforcing the rules
described above.
Identified Classes for Library System
 Initial Class model for Library System
.

41
 Revised class model for Library System
.

42
 Design concepts
Functional Independence
Cohesion – is an indication of the relative functional
strength of a module
Coupling – is an indication of the relative
interdependence among modules