Identification of Classes

Object Oriented Analysis (OOA) OOA is process by which we identify classes that play role in achieving system goals & requirements. Classification is the process of checking to see if an object belongs to a category or a class which guides us in making decisions about modularization.

Approaches for identifying classes & their behaviours in problem domain Noun phrase approach Common class patterns Use–case driven approach Classes, Responsibilities and Collaboration (CRC) approach

Noun Phrase Approach Read through the requirements or use cases looking for noun phrases. Nouns in textual description are considered to be classes & verbs to be methods of classes. As a whole, classes are grouped in to three categories: Relevant classes, Fuzzy classes and Irrelevant classes.

The series of steps in this approach are as follows: 1.Identifying Tentative Classes: Following are guidelines for selecting classes in an application Look for nouns, and noun phrases in use cases Some classes are implicit or taken from general knowledge All classes must make sense in application domain Avoid computer implementation classes – defer them to the design stage

2. Selecting Classes form Relevant & Fuzzy Categories: Following guidelines help in selecting candidate classes from relevant & fuzzy categories of classes in problem domain Redundant classes: If more than one word is being used to describe same idea, select one that is most meaningful in the context of system. This part of building a common vocabulary for the system as a whole. Adjectives classes: Adjectives can be in many ways. An adjective can suggest a different kind of object, different use of the same object or it could be utterly irrelevant Attribute classes: Tentative objects that are used only as values should be defined or restated as attributes and not as a class Irrelevant classes: Each class must have a purpose and every class should be clearly defined and necessary. Classes which cannot be given statement of purpose are eliminated

3. Elimination & Refining: The process of eliminating redundant classes & refining remaining classes is not sequential. It can be done forth & back among steps as of wish.

Example Case study ( ATM) The following section provides a description of the ATM 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 bank atm. Each transaction must be recorded and the client must be able to review all transactions performed against a given account.  In this bank client can have two types of accounts: a checking account and savings account.  The bank client will interact with the bank system by going through the approval process. After the approval process, the client can perform the transaction. The steps involved in transaction are: a)Insert ATM card b)Perform approval process c)Ask type of transaction d)Enter type e)Perform transaction f)Eject card g)Take card

Contd..  Initially the client enters the PIN code that consists of 4 digits. If PIN is valid the clients account will be available. Else an appropriate message is displayed on the screen.  Neither a checking nor savings account can have a negative balance. If the balance in saving account is less than the withdrawal amount requested, the transaction will stop and the client will be notified.

Solution: List of nouns identified are: Account Account balance Amount Atm card Bank Bank client Card Checking account Client Clients account Four digits Invalid PIN Message PIN PIN code Savings Savings account Transaction Transaction history Touch Screen

Eliminate irrelevant classes Account Account balance Amount Atm card Bank Bank client Card Checking account Client Clients account Four digits Invalid PIN Message PIN PIN code Savings Savings account Transaction Transaction history Touch Screen

Reviewing the redundant classes and building a common vocabulary Client, Bank client = Bank client Account, Client’s Account = Account PIN, PIN code = PIN Checking, Checking Account= Checking Account Savings, Savings Account =Savings Account

Here is the revised list of classes Account Account balance Amount Atm card Bank Bank client Card Checking account Client Clients account Four digits Invalid PIN Message PIN PIN code Savings Savings account Transaction Transaction history

Reviewing the classes containing adjectives In this example, we have no classes containing adjectives that we can eliminate.

Reviewing the Possible Attribute Amount -A value not a class Account Balance -An attribute of the Account class. Invalid PIN -only a value, not class Transaction history - attribute of transaction class PIN -attribute of Bank client class Password: An attribute of Bank Client class

Revised list after eliminating the attributes Account Account balance Amount Atm card Bank Bank client Card Checking account Client Clients account Four digits Invalid PIN Message PIN PIN code Savings Savings account Transaction Transaction history

Review the class purpose: ATM card class Bank client class: Details about client Account class: abstract class Savings and checking account: inherits account class. Transaction class: keeps track of the records.

Common Class Patterns Approach It is based on a knowledge base of common classes that have been proposed by various researchers. They have compiled & listed the following patterns for finding the candidate class & object Concept class: It encompasses principles that are not tangible but used to organize or keep track of business activities or communications. Eg: Performance is an concept class object Events class: These are points in time that must be recorded. Associated with things remembered are attributes such as who, what, when, where, how or why. Eg: Landing Organization class: It is collection of people, resources, facilities or groups to which users belong; their capabilities have a defined mission, whose existence is independent of individuals People class: It represent different roles users play in interacting with application. It is also known as person, roles and roles played class divided into 2 – users & non-users information Places class: Places are physical locations that system must keep information about. Eg: Stores Tangible things & devices class: This class includes physical objects or groups of objects that are tangible & devices with which application interacts. Eg: cars, pressure sensors

CRC Approach The Classes, Responsibilities and Collaborators process consists of three steps 1. Identify classes’ responsibilities (and identify classes) 2. Assign responsibilities 3. Identify collaborators Classes are identified & grouped by common attributes, which also provides candidates for super classes. Responsibilities are distributed; they should be as general as possible & placed as high as possible in inheritance hierarchy. The idea in locating collaborators is to identify how classes interact. Classes (cards) that have a close collaboration are grouped together physically.