OBJECT ORIENTED ANALYASIS AND DESIGN

UNIT -I

1. INTRODUCTION

1. AN OVERVIEW: OBJECT ORIENTED SYSTEM DEVELOPMENT

1.1 What is Object Oriented System Development?

 It refers to all activities that go into producing an information system solution.
 It consists of system analysis, modeling, design, implementation, testing and
maintenance.
1.2 What is software development methodology?
 It is a series of process that, if followed, can lead to the development of an
application.
 The process describes how the work is carried out.
 Each process consists of a number of steps and rules.

1.3 VIEW OF SOFTWARE:

Algorithms +Data structures=Programs.
 A software system is a set of mechanisms for certain action on certain
data.
 Object Oriented System Development centers on the object, which
combine data
 and functionality.
1.4 OBJECT ORIENTED SYSTEM DEVELOPMENT METHODOLOGY:
 This development offers a different model from the traditional software which is
based on Functions and Procedures.
 Simply it is a way to develop software by building self contained modules or objects.
 Object has attributes (data) and methods (functions).
For example, Window object is responsible for things like opening, sizing and closing
itself.
1.5 Why an Object Orientation? –Advantages:
The systems are easier to adapt to changing requirements, easier to maintain, more robust

and promote greater design and code reuse.

An object orientation
 Allows working at a higher level of abstraction.
 Provides a seamless transition among different phases of software development.
 Encourages good development practices.
 Promotes reusability.

1
1.6 OVERVIEW OF THE UNIFIED APPROACH: 8m
The unified approach (UA) is methodology for software development that is proposed
by the author, UA based on methodologies by Booch, Rumbaugh, Jacobson to combine the
best practice, process and guidelines along with object.
UML: (Unified Modeling Language)

 It is a set of notations and conventions used to describe and model an application.

 The heart of unified approach is Jacobson‘s use case. The use case represents a
typical interaction between a user and a computer system to capture the user’s goals
and needs.

 UA consists of following concepts:

o Use-case driven development.

o Object Oriented Development.
o Object Oriented Design.
o Repository of reusable classes and maximum reuse.
o The layered approach.
o Incremental development and prototyping.
o Continuous testing.

 The unified approach road map contains

o Analysis
 Identify the users/actors
 Develop a simple business model process model
 Develop the use case
 Interaction diagrams
 Classification
o Design
 Apply design axioms to design classes, their attributes, methods,
associations, structures and protocols.
 Design the access layer
 Designing the view layer classes
 Iterate and refine the design/ analysis.
o Prototyping and Testing
 Prototype user interface
 Usability and user satisfaction testing.

2. INTRODUCTION – OBJECT BASICS

2.1 OBJECT BASICS: 16m

 A car is an object. It is real world entity.

 Identifiably separated from its surroundings. A car has well defined set of attributes or
properties (color, manufacture, cost, and owner) and well defined set of thing you
normally do with it (drive it, lock it, tow it, and carry passengers in it). It is also called
a procedures or methods.

2
2.2 AN OBJECT ORIENTED PHILOSOPHY:
 A fundamental characteristic of object oriented program is that it allows the base
concepts of the language to be extended to include ideas and terms closer to those of
its application.
 The fundamental difference between object oriented system and their traditional
counter parts is the way in which you approach problems.
 Traditional development methods are either Algorithm centric or Data centric.

1. Algorithm-Centric Methodology:
Think of an algorithm that can accomplish the task, and then build data structure
for that algorithm to use.
2. Data -centric Methodology:
 Think how to structure the data, and then build the algorithm around the data.
 In the object-oriented system, however the algorithm and data structures are
packed together as an object.
 The attributes and methods are equal and inseparable parts of the object.
2.3 OBJECTS:
The term Object means a combination of data and logic represents some real world
entity.
For ex, Saab automobile

o Saab represents object.

o The data part is car’s name, color, number of doors, price etc.
o The logic part is the collection of programs such that show mileage, stop, go.
In an object oriented system every thing is an object.
When developing an Object Oriented Application two basics question arise.
1. What Objects does the application need?
2. What functionality should those objects have?
For ex, every Window application needs window object. Each object is responsible for

itself such that opening, sizing, closing itself.

2.4 OBJECTS ARE GROUPED IN CLASSES:

 A Class is a set of object s that shares a common structure and common behavior.
 A single object is simply an instance of a class.
 In an object –oriented system a method or behavior of an object is defined by its class.
 Each object is an instance of a class.
 Each employee object is responsible for its own data such as number, address, salary,
etc,

3
 Employee Class

Sue
Objects Bill

of class Ali
Employee Hal
David
FIGURE 2.1 Sue, Bill, Ali are instances or Objects of class Employee
2.5 ATTRIBUTES: OBJECT STATE AND PROPERTIES:
 Properties represent the state of an object.

Fig2.2 The attributes of a car object:

Car
Cost
Color
Model

 We could represent each property in several ways.

 Cost-dollar ,rupees
 Color –red ,Number of red paint
 Make-manufacture name, model number
2.6 OBJECT BEHAVIOR AND METHODS:
 In the object model, object behavior is described in methods or procedures.
 Car-> We normally do with it (drive it, lock it…)
 Elephant -> It can do on its own (eat a banana, etc…..)
 Behavior-> collection of methods.

2.7 OBJECT RESPOND TO MESSAGES:

o However, to do an operation, a message is sent to an object.
o Object performs operations in response to messages.
o For example, when you press on the break pedal of a car, you send a
stop message to the car object.
o The car object knows how to respond to the stop message.
o Breaks have been designed with specialized parts.

MESSAGES:
 It’s essentially a nonspecific function calls.
 A message is a different from of subroutine call, since different object
can respond to the same message in different ways.

4
  For example, car , motorcycle, bicycle all are respond to stop message,
but actual operations performed are object specific.

Fig 2.3 Object responsible to messages:

Car object Brake

5 object *7

Employee Computepayroll
object

 Methods are similar to functions, procedures or subroutines.

 To draw chart
 Draw -> message
 Draw chart or draw line or draw circle -> chart, line, and circle is
different object.
 Each object could act differently
 It is important to understand the difference between methods and messages.
 For example, you want to tell to make you tomato soup.
 Instruction is message.
 Way of preparation is method.
 Tomato soup is an object
 In other words, message is the instruction and method is the implementation.
2.8 ENCAPSULATION AND INFORMATION HIDING: 4m
 The wrapping up of data and functions in to a single unit is known as
encapsulation.
 Encapsulation protection mechanism, with public, private and protected
members.
 Public members accessed from anywhere.
 Private members access within a class.
 Protected members can be accessed only from subclass.
 An object is said to encapsulate the data and program.
 This means the user cannot see the inside of the object ‘capsule’, but can use
the object by calling the objects methods.
 An important factor in achieving encapsulation, using common protocol.
Example: A car engine.
 Although engines may differ in implementation.
 The interface between the driver and the car is through common protocol.
 Step on the gas to increase power or star the car.
 Let up on the gas to decrease power.
 Since all drivers know this protocol.
 All drivers can use this method in all cars, no matter what engine is in the car.

5
2.9 CLASS HIERARCHY:
Object oriented system organizes classes in to subclass-super class hierarchy.

Motor Vehicle

Bus Truck Car

Bus Air bus Omni 8 wheeler car sports car

Fig: 2.4 Class Hierarchy
A subclass inherits all the properties and methods defined in its super class.

 Motor vehicle-> super class

 Bus, Truck, Car-> subclass
 Consider the Bus. Bus is- super class. Air bus, passenger bus –Sub class.
 Sub class modifies the attributes of its super class car.
Fig: 2.5 Class hierarchy for ford class:
Vehicle

Car

Ford

Mustang Taurus Thunder bird

 The Mustang class defines the behaviors of mustang.

 The Ford class defines the behaviors of Ford.
The term Super class-> base class. The term sub class-> derived class.

2.9.1 INHERITANCE
Inheritance is a relationship between different classes which share common characteristics.
“If class B inherits class A, then both the operations and information structure in class A
will become part of class B”
Major benefits are simpler, clearer classes, at higher levels of abstraction
Employee, Managing, Director, Truck, Driver

6
"is an", "inherits from"
Generalization means extracting common properties from a collection of classes and
placing them higher in the inheritance hierarchy, in a ‘super class’.
Much care has to be taken when generalizing (as in the real world) that the property makes
sense for every single subclass of the super class. If this is not the case the property must
not be generalized.
Inheritance:
 It allows objects to be built from other objects. (Objects of one class acquire the
properties of object of another class).
 Inheritance is a relationship between classes where one class is the parent class or
super class or base class. Another one is the derived class.
 Inheritance allows classes to share and reuse behaviors and attributes.
 It allows reusability. For ex, The car class defines the general behavior of the car.
 The ford class inherits the general behavior and adds specific behaviors.

Vehicle

Car

I know how to stop

Ford
Stop method is reusable

Mustang Taurus Thunder bird

I don’t know how to stop

Stop (my Mustang)
Fig: 2.6 Inheritance allows Reusability

 Assume, all ford use same breaking system, behaviors share.

 However the stop method is not defined in the Mustang class, it’s invoked from ford

Class.

 But, Thunder bird has its own antilock breaking system. This class would redefine the

stop method so, the stop method of the ford class never be invoked.

7
Types of Inheritance:
1. Dynamic Inheritance.
2. Multiple Inheritance.

2.9.1 Dynamic Inheritance:

 It allows objects to change and evolve over time.
 Since base classes provide properties and attributes for objects, changing base
classes changes the properties and attributes of a class.
 It refers to the ability to add, delete or change parents from objects at run time.
2.9.2 Multiple Inheritance: 4m

 It permits a class to inherit its state and behaviors from more than one super class.
This kind of inheritance is referred to as multiple inheritance.

 For example, a utility vehicle inherits attributes from both the car and Truck
classes.

 The benefits of multiple inheritance in a language with single inheritance is to

inherit from the most appropriate class and then add an object of another class as
an attribute.

 It is more difficult to understand programs written in multiple inheritance systems.

Motor Vehicle

Truck Car Bus

Utility Vehicle

Fig: 2.7 Utility vehicles inherit attributes from both the car and truck classes.

2.10 POLYMORPHISM: 4m
 Poly means “many”. Morph means “Form”. In the OO- System, it means objects that
can take on or assume many different forms.

 It means that the same operation may behave differently on different classes.

 For ex, The driving is a behavior perform with all cars, the specific behavior can
be different, depending on the kind of car we are driving.

8
  Polymorphism allows writing generic, reusable code more easily, because can specify
general instructions and delegate the implementation details to the object involved.

 For ex, In a payroll system, Manager, production worker, office worker objects
all will respond to compute payroll message, but the actual operation performed
are object specific.

2.11OBJECT RELATIONSHIPS AND ASSOCIATION:

o Associations represent the relationship between objects and classes.
For ex, “A pilot can fly planes”

Pilot Can fly flown by Planes

c

o Associations are bidirectional. It can traverse in both directions.

o An important issue in association is cardinality. This specifies how many instances
of one class may relate to a single instance of an associated class.
Ex: client-Account relationship where one client can have one or more accounts.

2.11.1 CONSUMER-PRODUCER ASSOCIATION:

 It’s a special form of association.
 Also known as a client –server association or a use relationship.
 It can be viewed as one way interaction.
 One object requests the service of another object.
 The object makes the request is the customer (or) Client, and object receives the
request and provides the service is the producer or server.

Print Server Request for Printing Item

Fig: 2.9 The Consumer-Producer Association

2.12 AGGREGATION AND OBJECT CONTAINMENT 4m

 All objects are composed of and may contain other objects.
 For ex, (i) Spread sheet is an object composed of cells.
(ii) Cells are objects that may contain text, mathematical Formulas, video, etc.,
 Breaking down objects into the objects from which they are composed is
called Decomposed.
 Object attributes need not be simple data fields.
 Attributes can reference other objects. This is known as Aggregation, Where an
attribute can be an object itself.

9
 Example: Car

Engine Seat Wheel

Fig: 2.10 A car is an aggregation of other objects such as engine, seat and wheel objects.

2.13 CASE STUDY- PAYROLL PROGRAM 16m

It process employee’s records. It consists of several classes of employees with particular
payroll requirements and rules for processing each. This company has three types of
employees:

1. Managers receive a regular salary.

2. Office workers receive an hourly wage and are eligible for overtime after 40 hours.
3. Production Workers are paid according to apiece rate.
2.13.1 Structured Approach:
(Refer Book)
2.13.2 The Object Oriented Approach:
The Object Oriented System development consists of
 Object Oriented Analysis
 Object Oriented Information Modeling
 Object Oriented Design
 Implementation
 Testing, Iteration, Documentation

Each object is entirely responsible for itself. For ex., Employee object is responsible
for things like, computing payroll, printing paychecks, storing data.
 First task in the Object Oriented –analysis to find the class of objects.
 To identify the attributes of objects.
 To identify the behavior.

10
 Employee
Name
Address
Salary

Office Worker Manager Production Worker

Data Entry Data Entry Data Entry

Compute Payroll Compute Payroll Compute Payroll
Print Report Print Report Print Report

Fig 2.11 Class Hierarchy:

2.14 ADVANCED TOPICS:

2.14.1 Object and Identity:

 It is a special feature.
 Every object it’s own unique identity.
 This identity is never confused with another object.
 This identity name never change even if all the properties of the object change
 Object identity is implemented through some kind of object identifier (OID)
or Unique identifier(UID)
 OID’s never reused.

Car Instance (object) Person Instance (object)

Make: Saab Name: Raj

Color: red
Age: 30
Model:90os
Owner Owns

Fig 2.12 The owner property of a car contains a reference to the person instance named Raj.

11
  In the object system, the relationship between the car and Raj can be implemented
and maintained by references. A reference is similar to the Pointer in other
programming languages.
 Object references directly denote the object to which they refer.
 Owner is the property of car Instance, referred to the person instance.
 Owns is the property of person instance, referred to a car instance.

2.14.2 STATIC AND DYNAMIC BINDING:

 Binding refers to the linking of a procedure call to the code to be executed in response
to the call.
 The process of determining at run time which function to invoke is termed Dynamic
binding.
 It occurs when polymorphic call issued.
 Making this determination earlier, at compile time is called static binding. It optimizes
the calls.

Shape

Draw ()

Circle Object Box Object Triangle Object

Draw (circle) Draw (box) Draw (Triangle)

Draw ( ) ->Procedure Call

2.14.3 Object Persistence:

 Objects have a life time.

 A file or database can provide support for objects having a longer life time
longer than a duration of the process for which they were created.
 This Characteristic is called Object persistence.

2.14.4 Meta Classes:

 In the O-O-System everything is an object. Numbers ,array, records, fields, file,
form etc.
 A class belongs to a class called meta class (or) Class of Classes.
 All objects are instances of a class and all classes are instances of Meta class.

OBJECT ORIENTED SYSTEM DEVELOPMENT LIFE CYCLE: 16m

12
3.1 INTRODUCTION:
 Software development process consists of analysis, design, implementation, testing
and refinement is to transform user needs in to software solution.
 The emphasis is intended to promote the building of high quality software.
3.2 SOFTWARE DEVELOPMENT PROCESS:
 System development can be viewed as a process.
 The development itself, is a process of change, refinement, transformation or addition
to the existing product.
 With in the process, it’s possible to replace one sub process with in a new one.
 With this method of change, it’s possible to adapt a new process. The process can
be divide in to small,
 Interacting phases called Sub process.
 The sub process must be clear and defined.
 Sub process must have the following:
 A description in term of how it works.
 Specification of the input required for the process.
 Specification of the output to be produced.
 The software development process also can be divided in to smaller, interacting sub
process.
 The software development process can be viewed as a series of transformation.
 The output of the transformation becomes the input of the subsequent transformation.

What are the uses Transformation 1 Problem

of the system? Statement
Analysis

Transformation 2
Design
System
Implementation
Software
Detail
Transformation 3 Product

TRANSFORMATION 1(ANALYSIS):
 It translates the user needs into system requirements and responsibilities.
 They use the system can provide insight into user’s requirements.
TRANSFORMATION 2(DESIGN):
 Begins with a problem statement and ends with a detailed design.
 This transformation includes bulk of the software development activity ,how to build
the software, It’s development and its testing.
 Also include design description, program, testing materials.
TRANSFORMATION 3(IMPLEMENTATION):

13
  It refines the detailed design into the system development that will satisfy the user’s
needs.
 This takes in to account the equipment, procedure and people.
 For ex, the new compensation method is programmed, new forms are put to use and
new reports can be printed.
 An example of the Software development process is the Water fall approach.

THE WATER FALL SOFTWARE DEVELOPMENT PROCESS:

What

How

Do It

Test

Use

(i) What is to be done? (What is the problem)

(ii) How to accomplish them?
(iii) Which we do it?
(iv) Must test the result?
(v) Finally we use.
 The Water fall model is the best way to manage a project with a well
understood product.
 It’s based on well established engineering principles.
DISADVANTAGES:
 In the real world, the problems are not always well defined.
 For example, if a company has experience in building accounting systems, then
building accounting systems, then building another such product based on the
existing design is the best managed with water fall model, as it has been
described.
 Where there is uncertainty regarding, what is required or how it can be built, the
water fall model fails.
ADVANTAGES:
 It is a best way to manage a project with a well understood product.
 It’s based on well established engineering principles.
 However ,it’s failure can be traced it’s inability to accommodate
 Software’s special properties, and it’s inappropriateness for resolving partially
understood issues.
 In neither emphasis nor encourage software reusability.

14
3.3 BUILDING HIGH QUALITY SOFTWARE:
 The software process transforms the user needs via application domain to a software
solution that satisfies those needs.
 Once the system exists, we must test it’s a free of bugs.
 High quality products must meet users and expectations.
 The ultimate goal of building high quality software is user satisfaction.
To achieve high quality in software we need to answer the following.

 How do we determine when the system is ready for delivery?

 Is it an operation system that satisfies user’s need?
 Does it pass an evaluation process?
There are 2 basic approaches to system testing.

1. How it has been built.

2. What it should do.
In Blum describes system evaluation in terms of four quality Measures
1. Correspondence
2. Correctness
3. Verification
4. Validation
Fig: 3.3 Quality Measures: Validation
Verification

Needs Requirements Design Software

Correctness

Correspondence
CORRESPONDENCE:
Measure how well the delivered system matches the needs of the operational environment
as described in original requirement statement.

VALIDATION:
It is the task of predicting correspondence. It begins as soon as project starts.
CORRECTNESS:
Measures the consistency of the product requirements with respect to the design
specifications.

15
VERIFICATION:
It is the exercise of determining the correctness.
Verification & Validation answer to the following questions:
Verification: Am I building the product right?

Validation: Am I building the right product?

 Validation begins as soon as the project starts.

 But verification can begin only after a specification has been accepted.
 Both are independent of each other.

3.4 OBJECT ORIENTED SYSTEM DEVELOPMENT:

A USE-CASE DRIVEN APPROACH: 8m
The object oriented software development life cycle (SDLC) consists of three macro
process.
1. Object Oriented Analysis
2. Object Oriented Design
3. Object Oriented Implementation
The use case model can be employed throughout most activities of software development.

Build a Use-Case
Model

Object
Analysis Validate
Analysis /Test
Analysis
Ana

Using Tools CASE User Satisfaction Design Classes, Build Object Build User
&/ OO Programming Usability & QA Define Attributes & Dynamic Interface
Languages Test & Methods Model &
Prototype

IIIiiiii Implementation User Satisfaction

Test, Usability Test
Design & QA Test

Fig 3.4: The OOSD Approach.

16
JACOBSON LIFE CYCLE MODEL:

Use Case
Model

OOA: Identify Actors OOA: Use Case Model OOA: Course of Action

Object Interaction
Design
Diagram, etc .
Classes

UI
Dynamic Model OOA: Object Model OOD: Dynamic Model Testing: Usage Scenarios

 In the lifecycle model of Jacobson , one can produce design that are traceable across
requirements, Analysis , design, and implementation and testing.
 The main advantage is that , all design decisions can be traced back directly to user
requirements.
 Usage scenarios can be come test scenarios.
 In the Object Oriented System development includes these activities.
1. Object Oriented Analysis- Use Case Driven
2. Object Oriented Design
3. Prototyping.

4. Component Based Development

5. Incremental Testing.
3.4.1 OBJECT ORIENTED ANALYSIS- USE-CASE DRIVEN: 8m
Use Case:

A description of the set of sequences of actions, including variants, that a system

performs that yield an observable result of value to an actor.

Use Case Driven:

17
 In the Software development life cycle a process, in which use cases are used and
establish desired behavior of the system, for verify, validate the system architecture for
testing and for communicating among the stakeholders of the project.

 It is concerned with determining the system requirements and their relationships to

other classes in problem domain.
 To understand the system requirements, we need to identify the users or the actors.
 Who are the actors and how do they use the system?
 In the object oriented analysis, scenarios are used to help analysts to understand the
requirements.
 In the Jacobson concept of the use case, his name for a scenario to describe the user
computer system interaction.

Eg: Application domain might be a payroll system.

Tangible Object Intangible object

Pay Check Tables

Employee Data Entry
Worker Data Structures
Supervisor
Office administrator

 Documentation is another activity.

 80-20 rule generally applies for the documentation.
 Documentation and modeling are not separate activities.
 Good modeling implies good documentation.

3.4.2 OBJECT ORIENTED DESIGN: 8m

 The goal is to design the classes identified during the analysis phase and the user
interface.
 During this phase, we identify and define additional objects and classes that support
the implementation of the requirements.
 Eg: During the design phase, need to add objects for the user interface (E.G data
entry windows & Browse windows).
 Object Oriented Design & Object Oriented Analysis is distinct disciplines. But they
can intertwine.
 Activities are also intertwined.
 In the Object Oriented Development
1. You start with Object Oriented Analysis.
2. Model it.
3. CreateSupervisor
an Object Oriented Design.
4. Then do some more of each.

18
 5. Refining? & completing the models of the system.

First build the object model based on objects, then iterate and refine the model.

 Design & Refine classes.

 Design & Refine attributes
 Design & Refine methods.
 Design & Refine structures.
 Design & Refine associations.

Four guidelines to use Object Oriented Design:

1. Reuse- Rather than build a new class.

2. Design a large number of simple classes rather than a small number of complex
classes.
3. Design methods.
4. Critique what you have proposed. If possible go back & refine the classes.

3.4.3 PROTOTYPING: 8m

 It is a version of the software product development in early stage of the product life
cycle.
 It provides the developer to test and refine the user interface.
 Increases the usability of the system.

1. Horizontal Prototyping:
 Prototyping provides the developer a means to test and refine the user
interface and increase the usability of the system.
 It is a simulation of the interface.
 Contains no functionality.
 Very quick to implement.
2. vertical Prototype:
 It is a subset of system features with complete functionality.
 Advantage: Implemented function can be tested in great depth.
3. Analysis Prototype:
 It is an aid for exploring the problem domain.
 It is used to inform the user and demonstrate the proof of a concept.

4. Domain Prototype:

 It is an aid for the incremental development of the ultimate software solution.

 Prototyping is a useful exercise at almost any stage of the development.
 Prototyping should be done in parallel with preparation of functional
specification.

3.4.4 IMPLEMENTATION:

19
 Component Based Development:

 The s/w components are built and tested, using a wide range of
techniques.
 For Eg: Computer Aided Software Engineering (CASE) tools allow
their users to rapidly develop the information system goal of CASE.
 CASE : Develop the system development life cycle using a set of
interrelated s/w tools (such as modeling ,methodology, automatic code
generation)
 CASE tools give the skeleton of applications.
 New generations of CASE tools support Component Based
Development (CBD)
CBD:
 It is an industrial approach to the s/w development process.
 Application development moves from custom development to assembly
of prebuilt, pretested reusable s/w components that operate with each
other.

Two basic ideas underlie CBD:

1. The application development can be improved significantly; applications can be

assembled quickly from prefabricated s/w components.
2. Increasingly large collection of s/w components made available to the developer in
both general and specialized catalogs.
o A CBD Developer can assemble components to construct a complete s/w
system.
o Component themselves may be constructed from other components.
o The CBS is more efficient and less development effort.
o Most Legacy-complex.
o The CBD approach to legacy integration involves application wrapping, in
particular wrapping technology.
Component Wrapper
Component Wrapper

Legacy Program Legacy Data

Open Connectivity

Component Wrapper
Component Wrapper

Legacy Screens Legacy software Package

20
 Fig : 3.6 Reusing legacy system via component wrapping technology.

Software Components:

 Software components are the functional units of a program, building blocks.

 A software component can request a service from another component or deliver its
own service.
 In short the object oriented concept addresses analysis, design, and programming.
 The component based development (CBD) is concerned with implementation and
system integration.

Rapid Application Development (RAD): 8m

 It is a set of tools and technology that can be used to build an application faster than
traditional methods.
 It is often used in conjunction with software prototyping.
 RAD ->quick delivery. But quality is good.
 RAD -> does not replace the system development life cycle, but complements it.

Task of RAD:

1. Build application quickly.

2. Incrementally implement the design and user requirements, through tools (VB).

Main objectives:

 To build a version of an application rapidly.

 It involves a number of iteration.
 Each iteration we might understand the problem, a little better.
 RAD encourages the incremental development approach of “grow, do not build”
software.
 Prototyping and RAD do not replace the object oriented software development model.
 Instead in a RAD, you go through in rapid in the next iteration of prototype.

3.4.5 INCREMENTAL TESTING:

 The developer would turn over applications to a quality assurance (QA) group

for testing only after development was completed.

 QA group not included in the initial plan.

3.5 REUSABILITY: 8m

 The major benefit in object oriented system is reusability.

 The potential benefits of reuse are,

1. Increased Reliability.

21
 2. Reduce Time.
3. Reduce cost for development.
4. Improved Consistency.
You must effectively evaluate existing software components for reuse by ask questions,

1. Has my problem already been solved?

2. Has my problem been partially solved?
3. What has been done before to solve a problem similar to this one?

So we need detailed summary information about existing software components.

The reuse strategy can be based on following:

1. Information Hiding

2. Performance to naming standards.

3. Creation and administration of an object repository.

4. Establishing targets for a percentage of the objects, in the project to be reused.

--------------------------------------------------------------------------------------------------------------

22
(OBJECT ORIENTED ANALYSIS AND DESIGN)

UNIT-II

RUMBAUGH ET AL.’S OBJECT MODELING TECHNIQUE

 The object modeling technique (OMT)) by Jim Rumbaugh describes a method for analysis,
design and implementation of a system using oriented technique.
 OMT identifies and models all the objects faster
 Details such as class, attributes, methods, inheritance and association can be expressed easily.
 Dynamic behavior of object within a system can be described by OMT dynamic model.
 Process description and consumer - producer relationship can be expressed using OMT’s
functional model.

OMT consists four phases, which can be performed iteratively:

1. Analysis
The results are objects, dynamic and functional models.
2. System design
The results are a structure of the basic architecture of the system along with high level
strategy decisions.
3. Object design
Produces design document containing detailed objects static dynamic and functional
models.
4. Implementation
This activity produces reusable, extendible, and robust code.
1.1 THE OBJECT MODEL
The object model describes the structure of objects in the system: their identity, relationship to
other objects, attributes, and operations.
It is represented by object diagram.
 Client Client Transaction
Client Account Number
First Name Account Balance Account
First Name Trans Date
Last Name Deposit Transaction Trans Time
Last Name Withdraw Trans Type
Pin Code Create Transaction Amount
PinCode Post Balance

Checking Account Saving Account

Withdraw

It is represented graphically with an object diagram. In object diagram classes are

interconnected by association lines.
Each class represents a set of individual objects classes. The association lines establish
relationships among the classes. Each association line represents a set of links from the objects
of one class to the objects of another class.
1.2THE OMT DYNAMIC MODEL
Dynamic Model is detailed consisting of states transitions, actions and events.

Nothing is Account has

selected been selected

Selected Checking Select Checking

or savings account account

Select transaction Enter the

type (withdraw, amount
deposit, transfer)

Confirmation

State Transition Diagram for the Bank Application user interface.

The OMT state transition diagram is a network of states and events.
Each state receives one or more events, at which time it makes the transition to the next state.
The next state depends on current state as well as events.
1.3 THE OMT FUNCTIONAL MODEL
The OMT data flow diagram (DFD) shows the flow of data between different processes in a business.
An OMT DFD provides a simple and intuitive method for describing business processes.
Carsatium

ATM Card Bank code Select bank

reader
Select card

User keyboard
entry Verify password

Select account
User screen
selection
Account

Update account
ATM DFD
System architect
Comment
OMT data flow User

Process Data store Data flow External entity

DFD of the ATM System.

Data flow diagrams use four primary symbols

1. The Process is any function being performed; for example, verify password or PIN in the ATM
systems.
2. The Data Flow shows the direction of data element movement; for example: PIN code.
3. The Data Store is a location where data are stored; for example, account is a data store in the
ATM.
4. An External Entity is a source or destination of a data element; for example: the ATM card
reader.
 Thus, Rumbaugh OMT methodology provides one of strongest tool sets for the analysis and
design of object oriented systems.

THE BOOCH METHODOLOGY

 It is usually used object oriented method for designing the system using object
paradigm.
 It covers the analysis and design phases of an object oriented system.
 Booch defines a lot of symbols to document. Booch starts with class and object
diagrams in the analysis phase and refines these diagrams in various steps . While
generating code we design the symbols .
Booch method consists of the following diagrams.
o Class diagrams
o Object diagrams
o State transition diagrams
o Module diagrams
o Process diagrams
o Interaction diagrams
The Booch methodology prescribes a
o Macro development process and
o Micro development process.

THE MACRO DEVELOPMENT PROCESS

It serves as controlling framework for the micro process and can take weeks or even months.
It primarily concerns with technical management of the system .In macro process, the traditional
phases
of analysis and design are preserved to a large extents.

The steps in the macro development process are,

1. Conceptualization.
During conceptualization, you establish the core requirements of the system. You establish
asset of goals and develop a prototype to prove the concept.
 OBJECT MODELING USING BOOCH NOTATION

Car Color
Manufacture cost
Super class
cost

Inherits
Ford
Inherits

ortEscoEeE
Mustang Taurus E
Escort
2. Analysis and development of the model.
Class diagrams are used to describe the roles and responsibilities the objects are to carry
out in performing the desired behavior of the system . Then , you use the object diagram is
used to describe the behavior of the system in terms of scenarios or, alternatively, use the

interaction diagram to describe behavior of the system as scenarios.

3. Design or create the system architecture.
In the design phase, you use the class diagram to decide what classes exist and how they
relate to each other.
The object diagrams to decide what mechanisms are used to regulate how objects
collaborate.
Then the module diagram is used to map out where each class and object should be
declared.
The process diagram to determine to which processor to allocate a process. We also
determine the schedules for multiple processes on each relevant processor.
4. Evolution or Implementation.
Refine the system through many iteration. Produce a stream of software implementations
each of which is a refinement of the prior one.
5. Maintenance.
Make localized changes to the system to add new requirements and eliminate bugs.

Operator::Turn Off Alarm

 Enabled

Sound Alarm
Silence d Soundin
Silence Alarm g

Enable Disable

Disabled
Alarm Fixed

An alarm class state transition diagram with Booch notation.

THE MICRO DEVELOPMENT PROCESS

Each macro development process has its own micro development processes.
The micro is a description of day to day activities by a single or small group of software
developers.
The micro Development process consists of the following steps:
o Identify classes and objects.
o Identify class and object semantics.
o Identify class and object relationship.
o Identify class and object interfaces and implementation.

THE JACOBSON ET AL. METHODOLOGIES

The Jacobson et al. methodologies (e.g., OOBE,OOSE,and Objectory) cover the entire life
cycle and stress traceability between the different phases, both forward and backward.
This traceability enables reuse of analysis and design work, thus reducing development time.
Then reuse of code we have the use case concept, which evolved with objectory.
USE CASES
Use cases are scenarios for understanding system requirements.
A use case is an interaction between user and a system.
The use case model captures the goal of the user and responsibility of the system to its users.
In the requirement analysis, the use cases are described as one of the following:
 Non formal text with no clear flow of events.
 Text, easy to read but with a clear flow of events.
 Formal style using pseudo code.
The use case description must contain
o How and when the use case begins and ends.
o The interaction between the use case and its actors, including when the interaction
occurs and what is exchanged.
o How and when the use case will need data stored in the system or will store data in the
system.
o Exceptions to the flow of events.
o How and when concepts of the problem domain are handled.
Every single use case should describe one main flow of events.
An Exceptional or additional flow of events could be added.
The Exceptional use case extends another use case to include additional one.
Some Use Case of a Library.
Library

Checking out books

Getting an interlibrary loan

Doing research

Member Reading books, newspapers

Purchasing supplies
Supplier

o The use case model employs extends and uses relationships.

o The extends relationship is used when you have one use case that is similar to another
use case but does a bit more.
o It extends the functionality of the original use case.
o The uses relationships reuse the common behavior in different use cases.
o Use cases could be viewed as concrete or abstract.
o An abstract use case is incomplete and has no actors that initiate it but is used
by another usecase.
o This inheritance could be used in several levels.
o Abstract use cases also are the ones that have uses or extend relationships.
OBJECT ORIENTED SOFTWARE ENGINEERING :OBJECTORY
Object Oriented Software Engineering also called objectory. Objectory is a method of object
oriented development with the specific aim to fit the development of large real time systems.
The use case driven development says use case are used in several phases of development
including Analysis, design, validation and testing.
This is a process for industrialized development of software.
This method produces usable and robust system,adapting more easily to changing usage.
This objector is built on several different models.
Use Case Model
The use case model defines the outside actors and inside use case of the systems behavior.

Use Case Model

Express in Testing in

Structured by Realize by Implemented by

OK

NOTOK

Domain Object Model Analysis Model Design Model Implementation Model Testing Model

Domain Object Model

The objects of the real world are mapped in to the domain object model.
Analysis Object Model
The analysis object model present how the source code should be carried out and written.
Implementation Model
It represents the implementation of the system.

Test Model
It constitutes the test plans, specification and reports.

A Process is created when first development project starts and is stopped when the developed
system is taken out of service.
OBJECT ORIENTED BUSINESS ENGINEERING (OOBE)
It is the object modeling at enterprise level.
Use cases are the central vehicle for modeling, providing traceability throughout software
engineering Processes.
Analysis Phase
It defines the system to be built in terms of problem domain object model, requirement
and analysis model.
It reduces complexity and promotes maintainability over the life of the system.
It forms a base for requirements model. This process is iterative.
Jacobson suggests that prototyping with a tool might be useful during this phase to help
specify user interfaces.
Design and Implementation Phase
The implementation environment must be identified for the design model
o DBMS, Distribution of process, Constraints due to programming language.
o Component libraries and Incorporating GUI tools.
It may be possible to identify implementation can be concurrently identified with analysis.
The analysis objects are translated in to design objects for current implementation environments.
Testing Phase
Finally Jacobson describes several testing levels and techniques.
The level include
 Unit testing, Integration testing and System testing.
PATTERNS
 Any science or engineering discipline must have a vocabulary for expressing its concepts and a
language for relating them to each other.
 The concepts of patterns serve for this purpose.
 Design patterns was first introduced by a building architect called Christopher Alexander.
 The main idea of using patterns is to provide documentation.
Definition
A pattern is instructive information that captures the essential structure and insight of a
successful family of proven solutions to a recurring problem that arises within a certain
context and system of forces.
A good pattern will do the following:
o It solves a problem. Pattern captures solution, not just abstract principles or strategies.
 o It is a proven concept. Patterns capture solutions with a track record, not theories or
speculation.
o The solution is not obvious. The best patterns generate a solution to a problem
indirectly -a necessary approach for the most difficult problem of design.
o It describes a relationship. Patterns do not just describe modules, but describe deeper
system structures and mechanisms.
o The pattern has a significant human component. All software serves human comfort
or quality of life; the best patterns explicitly appeal to aesthetics and utility.
Mostly patterns focus on design problems.
Recent patterns encompass all aspects of software engineering including:
 Development organization,
 Software development process,
 Project planning,
 Requirements engineering and
 Software management
GENERATIVE AND NON GENERATIVE PATTERNS
Generative patterns describe a recurring problem, tell how to generate something and can be
observed in the resulting system architecture they helped shape.
Non generative patterns are static and passive, they describe the recurring phenomena without
saying how to reproduce them.

PATTERN TEMPLATE
Every pattern is expressed as a rule (template) which establishes a relationship between a
context, a System of forces which arises in that context and a configuration which allows
forces to resolve themselves in the context.
Many pattern templates have been defined that represents a pattern.

A pattern should contain certain essential components. They are

1. Name
A meaningful name. A single word or a short phrase to refers to the pattern and the
Knowledge and structure it describes.
Good pattern name form vocabulary for conceptual abstractions.
When the pattern has more than one name it is practice to document these nicknames as
aliases. Some pattern forms also provide a classification of the pattern in addition to its name.
2. Problem
A statement of the problem that describes the goals and objective it wants to reach within the
given context and forces.
3. Context
The preconditions under which the problem are called context. It is the initial configuration of
the system before applying pattern.
4. Forces
A description of relevant forces and constraints and how they interact or conflict with
one another and with the goals we wish to achieve.
5. Solution
Static relationships and dynamic rules describing how to realize the desired outcome.
The static structure tells the form and organization of the pattern, but often the behavioral
dynamics is what makes the patterns “come alive”.
6. Examples
Examples help the reader understand the patterns use and applicability.
Visual examples and analogies are used.
Easy to comprehend examples are highly preferred.
7. Resulting Context
The state configuration of the system after pattern has been applied.
It describes the post condition and side effect of the pattern.
It is called resolution of forces because it describes which forces have been resolved and
which Unresolved and which patterns are applicable.
Documenting resulting context correlates initial context of other patterns.
8. Rationale
A justifying explanation of steps or rules in the pattern.
It explains how forces and constraints are orchestrated.
It tells how pattern works, why it works and why it is “good”.
Rationale provides insight into deep structures and key mechanism on the surface of the
system.
9. Related Patterns
The static and dynamic relationship between this pattern and other within the same
pattern language or system.
Related pattern share common forces.
 They also frequently have an initial or resulting context that is compatible with the
resulting or initial context of another pattern.
10. Known Users
The Known occurrences of pattern and its application within existing systems.
It is a proven solution to a recurring problem.
Good pattern begin with an abstract.
This gives a clear picture of pattern and informs of any problems they wish to solve.
A pattern has to identify the target audience.

ANTI PATTERNS
A pattern represents a “best practice” but anti pattern represents “worst practice”.
Anti patterns come in two varieties:
o Those describing a bad solution to a problem that resulted in a bad situation.
o Those describing how to get out of a bad solution and how to proceed from there
to a good solution.
CAPTURING PATTERNS
The process of looking for patterns to document is called pattern mining. (Reverse architecting).
Some guidelines for capturing patterns are
o Focus on practicability.
o Aggressive disregard of originality.
o Non anonymous Review.
o Writes workshop instead of presentations.
o Careful editing.
FRAMEWORKS
Frameworks are a way of delivering application patterns to support best practice.
An experienced programmer almost never codes a program from scratch.
A seasoned business consultant who has worked on many consulting projects performing
data modeling almost never builds a new model from scratch.
A framework is a way of presenting a generic solution to a problem that can be applied to all
levels in a development.
A framework is viewed as the implementation of a system of design patterns.
Difference between framework and design pattern.
FRAMEWORK
o Framework is executable software.
o Frameworks are of physical nature.
o They are physical realization of one or more software pattern solution.
o They are not abstract.
o It contains several design patterns
o They are highly specialized.
PATTERN
 Patterns represent knowledge and experience about software
 Patterns are of logical nature.
 Patterns are the instructions for how to implement those solution
 Design patterns are more abstract than frameworks.
 Design pattern are smaller architectural elements than framework.
 Design patterns are less specialized.

THE UNIFIED APPROACH

The unified approach establishes a unifying and unitary framework but utilizing
the unified Modeling Language (UML) to describe the model and document the software
development process.
The main idea is to combine the best practices, notation and diagrams for understanding object
oriented concepts and system development.
The unified approach to software development revolves around the following processes and concepts.

The Processes are,

 Use case driven development,

 Object Oriented Analysis,
 Object Oriented Design,
 Incremental development and prototyping,
 Continuous testing
 Develop use-case Develop Identify
Refine
interaction Classes
Activity diagram and
Diagram relationship
attributes iterate
Prototyping

O-O Analysis

Construction Repository
Component Based Layered
Of use-case
Development Design, UI and Approach
Continuous testing past experiences
patter ns,
User satisfaction documentation UML Based
usability tests, quality and traceability Modeling
Assurance test

O-O Design
Design Classes Design User
their Attributes Apply design view satisfaction
Methods Axiom And usability
Association access
Build UML class diagram tests based
Structure layer and
prototype on use case
s
Continuous testing
The methods and technology used include

 UML for modeling

 Layered approach
 Repository for object oriented system development patterns and frameworks.
 Components based development.
OBJECT ORIENTED ANALYSIS

Analysis is the process of extracting the needs of a system. The goal is to understand problem
domain and system responsibilities.

So we construct several models which concentrate on describing what the system does rather than how
it does it.

OOA process consists of the following steps:

1. Identify the actors.

2. Develop a simple business process model using UML activity diagrams.
3. Develop the use case.
4. Develop interaction diagrams.
5. Identify classes.
OBJECT ORIENTED DESIGN

Unified approach utilizes Jacobson et al’s analysis and interaction diagrams, Booch object diagrams
and Rum Baugh’s domain models.

OOD Process consists of

 Designing classes, their attributes, methods, associations, structure and protocols, apply,
design, axioms.
 Design the access layer.
 Design and prototype UI.
 User satisfaction and usability tests based on the Usage/Use Case.
 Iterate and refine the design.

ITERATIVE DEVELOPMENT AND CONTINUOUS TESTING

We must iterate and reiterate till we are satisfied with the system.

After testing we repeat the process by reworking, re-prototyping and retesting.

 Refining is continued until satisfied results.

 During iterative Process, the prototypes will be incrementally transformed into
the actual application.

 UA starts testing phase from day one of the project.

  Usage scenarios become testing scenarios
 Usability testing is the process in which the functionality of the software is
measured.

MODELING BASED ON UML

UML was developed by joint efforts of leading object technologists Grady Booch, Ivar

Jacobson and James Rumbaugh.

UML uses the best of notations used by Booch, Jacobson and Rumbaugh.

UML become universal language for modeling system.

UML expresses model of many different kinds and purposes.

UML has become standard notation for object oriented modeling systems.

The UA utilizes UML to describe and model the analysis and design phase of system

development.

The UA PROPOSED REPOSITORY

In modern business best practice sharing is a way to ensure that solutions to the process and

organization problems.

 It eliminates duplicates of problem solving.

 It is a constant goal of quality improvement.
 It is applied for quality and productivity.
We have to create a repository for maximum reuse of previous experience and

previously defined objects, patterns, frameworks and user interfaces.

The advantages of repository we can select from a repository –data element, diagram,

Symbols, definitions for reuse.

THE LAYERED TO SOFTWARE DEVELOPMENT

System developed with today CASE tools or client- server application development tends to follow
“two layered Architecture”: interface and data.

In a two layered system, user interface screens are tied to data through routines that sit directly behind
the screens.
 Data

Work Station

With every interface , we re create the business logic needed to run the screen.

This approach results in objects that are very specialized and cannot be reused in other projects.

Another approach is one that isolates the functions of the interfaces from the functions of the business.

It also isolate business from the details of the data access.

Data

Work Station

We have the three layered approach, where we create objects that represent elements of business and
completely independent of how they are represented to the user (through interface) or how there are
physically stored in a database.

The three layered approach consists of

 A view or user interface layer

 A business layer
 An access layer

OOD and
Prototyping Access Layer

OOA Business Layer

View Layer
OOA,OOD &
Prototyping
Three Layered Approach
THE BUSINESS LAYER

The Business layer contains all the objects represent the business.

The responsibilities of the layer are

Model the objects of business and how they interact to accomplish the business Processes.

When creating the business layer, however, it is important to keep in mind a couple of things.

These objects should not be responsible for the following:.

 Display details.
 Display data access details.

Displaying Details

Business object should have no special knowledge of how they are being displayed and by whom.

The details of how to display an object should exist in the interface layer of the object displaying it.

Data Access Details

 Business object also should have no special knowledge of” where they come from”.

 We don’t bother whether the data are stored and retrieved via SQL or file I/O.

 The business objects need to know only whom to talk about being stored or retrieved.

The User interface (view) Layer

This layer consists of objects with which the user interacts as well as the objects needed to

manage or control the interface. The UI layer also is called the view layer.

The applications of view layer are

 Responding to user interaction.

 Displaying business objects.

Responding to user interaction:

The UI objects must be designed to translate actions by user, such as clicking on a button or
selecting

from a menu, in to an appropriate response.

The response may be to open or close another interface.

 Displaying business objects:
This layer must paint the best possible picture of the business objects for the user.

Example: Entry fields, list Boxes or Graphs

The UI layer’s objects are identified during object-Oriented design phase.

The requirement for a UI or how a user will use the system is the responsibility of object-oriented
analysis.

Use cases can provide a very useful tool for understanding UI requirements.

THE ACCESS LAYER

 It contains objects that know how to communicate with the place where the data actually
reside,
 Whether it be a relational database, mainframe, internet or file)
 The responsibilities of access layer are:
TRANSLATE REQUEST
 The access layer must be able to translate any data- related requests from business layer in to
the appropriate protocol for data access.
 (Eg. If customer needs 55552 to be retrieved, the access layer must be able to create the correct
SQL statement and execute it)
TRANSLATE RESULTS
 The access layer also must be able to translate the data retrieved back into the appropriate
business objects and pass those objects back up in to the business layer.
 Access objects are identified during object- oriented design.

UNIFIED MODELING LANGUAGE

 A model is an abstract representation of a system, constructed to understand the system prior to
building or modifying it.
 A model provides a means for conceptualization and communication of ideas in a precise form.
 Modeling enables us to cope with the complexity of a system.
 Modeling frequently is used during many of the phase of the software life cycle, such as
analysis,
design and implementation.
 Some of the existing models are
1. Use Case Model:
It define outside (actor) and inside (use case) of the system’s behavior.
2. Domain Object Model:
Objects of the real world are mapped in to the domain object model.
3. Analysis Object Model:
It deals with how source code should be carried out and written.
4. Implementation Model:
It represents implementation of system.
5. Test Model:
It constitutes test plan, specification and reports.
We look at Unified Modeling Language (UML) notations and diagrams. The main idea is to get
exposed to UML Syntax, semantics and modeling constructs.

STATIC AND DYNAMIC MODELS

Models can represent static or dynamic situations.

STATIC MODEL
A static model is a snapshot of systems parameters at rest or at a specific point in time.
They represent the structural or static aspect of a system.
DYNAMIC MODEL
Dynamic model is a collection of procedures or behaviors that reflect the behavior of a system
over time.
Why Modeling?
Good models are essential for communication among project teams. A modeling language must
include.
Model element- Fundamental Modeling concepts and semantics.
Notation- Visual rendering of model elements.
Guidelines –Expression of usage within trade.
The benefits of models are
Clarity –errors are picked easily due to visual examination
Familiarity- used by the people currently works in problem domain.
Maintenance-Visual notation can improve the maintainability of system.
 Simplification-It is simple and easily understandable.
Advantages of Modeling are
1. Models are easier to express complex ideas.
2. Easy to understand.
3. Enhance learning and training.
4. Low cost.
5. Manipulation is easier than real time system.

INTRODUCTION TO UML
UML is a graphical language with a set of rules and semantics.
It is a language for specifying, constructing, visualizing and documenting the software
system and its components.
The rules and semantics of a model are expressed in English, in a form known as object
constraint
language (OCL).
The Unified Modeling Language (UML) is a modeling language for specifying,
visualizing, constructing , and documenting the artifacts of a system-intensive process.
The design goals of UML are,
1. Provides user a ready to use so that they can develop and exchange meaningful models.
2. Provide extensibility and specialization.
3. Independent of programming language.
4. Formal basis for understanding modeling language.
5. Encourage the growth of the OO tools markets.
6. Support higher level development concepts.
7. Integrate best practices and methodologies.

UML DIAGRAMS
Every complex system is given by a set of independent views of a model.
Every model may be expressed at different levels.
The UML defines nine graphical diagrams.
 Use-Case Diagrams
 Class and Object Diagrams
 Behavior Diagrams
  State chart Diagrams
 Activity Diagrams
 Interaction Diagrams
 Sequence Diagram
 Collaboration Diagram
 Implementation Diagrams
 Component Diagram
 Deployment Diagram

UML CLASS DIAGRAM

The UML class diagram referred to as object modeling is the main static analysis diagram.
Class Notation
A class is drawn as a rectangular with three compartment,
 Top holds class name.
 Middle holds general properties like attributes.
 Bottom holds list of operations.
Italics font is used for abstract classes.
Normal (roman) font for concrete classes.
A static diagram is an instance of class diagram.

Boeing 737 Boeing 737

Length: meter

Boeing 737 Fuelcapacity:Gal

Door: int
Length: meter
Fuel capacity Lift()
:Gal
Break()
Door: int CLASS NOTATION
Class Interface Notation
Class interface notation is used to describe the externally visible behavior of a class.
Example: A person object may need to interact with bank account to get balance.
Notation is a small circle with name of the interface connected to class.

Person Bank Account

 Interface Notation of a class
Binary Association notation
Binary association is a solid line connecting two class symbols.
Each association has two or more roles to which it is connected.

Works For
Company Person
employer employee

UML uses association navigation or navigability to specify a role affiliated with each end of an
association relationship.

Bank Account Person

Association Notation.

Here association is navigate in only one direction, from Bank Account to person but not reverse.

Qualifier and Multiplicity

A qualifier is association attribute.

Example: A person is associated to Bank Object through the attribute account.

Qualifier is denoted by small rectangular attached to the end of an association path.

Multiplicity is the range of allowable associated classes .It is given by a range of integers of

the format.

Lower bound....Upper bound

Bank
An association can show multiplicity:
Account#
• a fixed value (such as 1, 2, or 10) , *

• an asterisk (*) which means many 0...1

• a range of values (for instance 0..3) Person

• a set of values like 1,3,5,7,11.....* Asociaction Qualifier and

multiplicity

OR Association
 An OR Association indicates a situation in which one of the several potential association

may instantiated at one time for any single object.

{or}
Car

Company

Association class

An association having class properties is an association class. It is known by a class symbol attached
by a dashed line to an associate path.

Company Person

Works for
Salary

N –ARY ASSOCIATION
Person
It is an association among more than two classes. It is shown as a large diamond with a path

from the diamond to each participant class.

Year

Semester *

Class * class student * Student

Grade Book

Grade
Exam
lab

AGGREGATION AND COMPOSITION

Aggregation is a form of association. A hollow diamond is attached to one of end of the path

to denote aggregation.
 1 consists of
Team Player
class

Composition, known as a part of is a form of aggregation with strong ownership to represent

the

component of a complex object. It is referred as part whole relationship.

GENERALIZATION

It is the relationship between more general class and more specific class. It is displayed as a

directed line with a closed, hollow arrow head at the super class end.

Vehicle Separate target

Bus Car
Truck

CLASS DIAGRAM:
USE CASE DIAGRAM

 The Use case concept was introduced by Ivar Jacobson in object oriented software
engineering (OOSE).
 Use case represent specific flow of events in the system.
 Usecase define the outside (actor) and inside (usecase) of the system’s behavior.
 A use case diagram is a graph of actors, a set of usecases enclosed by a system
boundary, communication (participation) association between the actors and the
use case, and generalization among the use case.

Use-Case Diagrams (Jacobson)

 Interaction of Users with System Components
 Actors
 External Entity that Interacts with Software
 Promote Simulation of Events
 Can be People, Classes, Software Tools, etc.
 Use-Case Diagram
 Graph of Actors and Set of Use Cases Enclosed by System (High-Level) or Class
Boundary
 Focus on What Actions, Methods, Functions, etc. are Utilized by Which Actors
 Black Box View of System Components
 Derived via User Interviews
 A use-case diagram shows the relationship among the actors and use case within a

system. A client makes a call that is taken by an operator, who determine s the nature

of the problem. Some calls can be answered immediately; other calls require research

and a return call.

 A use case is shown as an ellipse containing use case name. Use case nme can be

placed below or inside the ellipse.

 An actor is shown as class rectangle with the level <<actor>> or the label and a stick

figure or just the stick figure with the name of the actor below the figure.
The three representations of an actor are equivalent.

The relationship show in use case diagram are:

1. Communication. The communication relationship of an actor in a use case is shown

by connecting the actor symbol to the usecase symbol with a solid path.

2. Uses. A uses relationship between use case is shown by a generalization arrow from
the use case.

3. Extends. The extends relationship is used when you have one use case that is similar
to.
 .

UML INTERACTION DIAGRAM

 The main idea in developing interaction diagram is simplicity.

 But interaction diagram lose clarity with conditional behavior.

 To capture complex behavior in a single diagram, we can go for activity diagrams.

 Interaction diagrams are models that describe how groups of objects collaborate to get the
job done.

 Interaction diagrams capture the behavior of a single use case, showing the pattern of
interaction among objects.

 The diagram shows a number of example objects and the messages passed between
those objects within the use case.

There are two kinds of interaction models:

o Sequence Diagrams.

o Collaboration Diagrams.

UML SEQUENCE DIAGRAM

 Sequence diagrams are easy and intuitive way of describing the behavior of a system by
viewing the interaction between the system and its environment.

 A sequence diagram shown an interaction arranged in a time sequence.It shows the

objects participating in the interaction by their life lines and the messages they
exchange, arranged in a time sequence.

A sequence diagram has two dimensions:

1. The vertical dimension represents time.

2. The horizontal dimension represents different object.

 An object is shown as a box at the top of a dashed vertical line.

 The vertical line is called the object’s life line. The life line represents the object’s
existence during the interaction.

 Each message is represented by an arrow between the life lines of two objects.
  The order in which these messages occur is shown top to bottom of the page.

 Message contains message name, arguments and some control information.

 A sequence diagram is an alternative way to understand the overall flow of the control

 of a program

UML COLLABORATION DIAGRAM

Another type of interaction diagram is the collaboration diagram. A collaboration diagram

represents collaboration, which is a set of messages exchanged among the objects within the
collaboration to achieve a desired outcome.
COMPARING SEQUENCE AND COLLABORATION DIAGRAM

 The principal feature of the interaction diagram is their simplicity.

Sequence diagram puts emphasis on sequence. It is easy to see the order in which the

things occur.

 Collaboration diagram uses the layout to indicate how objects are statically connected.
UML STATECHART DIAGRAM

 A state chart diagram(also called a state diagram) shows the sequence of states that an

object goes through during its life in response to outside stimuli and massages.

 The state is the set of values that describes an object at a specific point in time and is

represented by state symbols and the transitions are represented by arrows connecting the

state symbols.

 A state chart diagram may contain sub diagrams. A state diagram represents the state of

the method execution and the activities in the diagram represent the activities of the object

that performs that method.

 UML ACTIVITY DIAGRAM

 An activity diagram is a variation or special case of a state machine, in which the states
are
activities representing the performance of operations and the transitions are triggered by the
completion of the operations.

 Activity diagram are useful in connection with workflow and in describing behavior that
has a
lot parallel processing.

 The core symbol is “Activity state” or “Activity ”.

 Activity is a state of doing something

Either real world process (Example: type a letter)

Or execution of software runtime (Example: method on a class)

 Activity diagram describes sequencing of activities, with support for conditional and parallel
behavior.

 Activity diagram is a variant of state diagram in which states are activity states.

STATIC: COMPONENT DIAGRAM

 Component Diagram: High-Level Interaction and Dependencies Among Software Components

 Captures the Physical Structure of the Implementation

 Built As Part of Architectural Specification

 Purposes:
  Organize Source Code

 Construct an Executable Release

 Specify a Physical Database

 Main Concepts: Component, Interface, Dependency, Realization

 Developed by Architects and Programmers

 Captures the Physical Structure of the Implementation

STATIC: DEPLOYMENT DIAGRAM

 Deployment Diagram: Focus on the Placement and Configuration of Components at Runtime

 Purposes:

 Specify the Distribution of Components

 Identify Performance Bottlenecks

 Main Concepts: Node, Component, Dependency, Location

 Developed by Architects, Networking Engineers, and System Engineers

PACKAGES IN CLASS DIAGRAMS

 Complex Class Diagrams are Abstracted

 Packages Contain Multiple Classes and are Associated and Linked to One Another

 Dependency Arrow is Dashed

 Indicates that One Package Depends on Another

 Means that Changes in Destination (Dependee - Arrow Head) Can Possible Force
Changes in the Source (Dependent – Arrow Tail)\

 Supports Rudimentary SW Architecture Concepts

 However, no Checking/Enforcement of Dependencies in Subsequent Diagrams

Example Package
 UNIT-III

CHAPTER 6:
OBJECT ORIENTED ANALYSIS: Identifying Use Cases

OBJECTIVES :

At the end of this chapter, students should be able to

• Define and understand the object-oriented analysis process

• Explain the use case modeling process

• Identify actors

• Identify use cases

• Developing use case flow of event

1
 Introduction to Object-Oriented Analysis

Analysis is the process of extracting the needs of a

system and what the system must do to satisfy the
users’ requirements.

• Analysis  focus on understanding the problem and its domain

• Main objective of analysis  capture a complete, unambiguous, and
consistent picture of the requirements of the system and what the
system must do to satisfy the users’ requirements and needs.

By constructing models of the system that

concerntrate on describing WHAT the
system does rather than HOW it does
• Analysis = process of transforming a problem definition from a fuzzy
set of facts  a coherent statement of a system’s requirements.

• Analysis involves a great deal of interaction with the people who will
be affected by the system

2
• Analyst has 4 major tools for extracting information about a system :
o Examination of existing system documentation
o Interviews
o Questionnaire
o Observation
• Why analysis is a difficult activity ?

3 common sources of requirement

difficulties [Norman] :
fuzzy descriptions
incomplete requirements
unnecessary features

• Business object analysis is a process of understanding the system’s

requirements and establishing the goals of an application

• The outcome of the business object analysis is to  identify classes

that make up the business layer and the relationships that play a role
in achieving system goals

3
 • To understand users’ requirements :
 Find out how they “use” the system,  by developing use
cases.

Use cases = scenarios for

understanding system
requirements
Where Should We Start?ANALYSIS-4 tools for extracting information about

system

• 1. Examination (checking, testing) of existing system documentation.

• 2. Interviews (meeting, discussion).

• 3. Questionnaire (feedback form).

• 4. Observation (inspection, study).

Requirements Difficulties

(WHY ANALYSIS IS A DIFFICULT PROCESS?)

 Analysis is a creative activity that involves understanding the problem, its

associated constraints and methods of overcoming those constraints.

Three most common sources of requirements difficulties are:

1. Incomplete requirements.

2. Fuzzy descriptions.

3. Unneeded features

4
Incomplete requirements

• Certain requirements necessary for successful system development are not

included for variety of reasons

• This could include the users forgetting to identify them high cost, politics

within the business, or oversight (error, mistake, failure to notice) by the

system developer

Unneeded features

 keep on mind every additional features could affect the performance,

complexity, maintenance, stability (strength) and support costs of an

application

 a number of other factors also may affect the design of an application.

Note: Additional features and shortcuts can affect the product

 USE-Case Driven OO Analysis (OOA): Unified Approach

• OOA phase of the unified approach uses actors and use cases to
describe the system from users’ perspective.
• OOA process in the unified approach : refer figure 1.

5
Figure 1 : OOA process in the unifed approach

Develop use Develop

cases, activity interaction
diagrams diagrams

Build prototype
Identify classes,
Identify relationships,
actors attributes, &
methods

Refine & iterate

• OOA process consists of the following steps :

1. identify the actors :
a. who is using the system ?
b. who will be using the system ? ( in case of a new system )
2. develop a simple business process model using UML activity
diagram
3. develop the use case :
a. what are the users doing with the system ?
b. what will users be doing with the new system? (in case of
a new system )
c. use cases provide comprehensive documentation of the
system under study

6
 4. prepare interaction diagrams
a. determine the sequence
b. develop collavboration diagrams
5. classification – develop a static UML class diagram :
a. identify classes
b. identify relationships
c. identify attributes
d. identify methods
6. iterate and refine : if needed, repeat the preceding steps

Business process modelling

• Not necessary for all project
• When required business process and requirements can be modelled to any
level of detail
• Activity diagram support this modelling
• disadvantages
– Time consuming process
• Advantages
– familiarity

7
 yes yes Go to
yes Go to counter and
counter and check out
return the books
books
Return
book?
yes yes
Interlibrary
loan
borrow no
book?
no Search for
book

yes Do
Do search research on
topics
no

yes Read news

Read news paper and
paper? magazine
no

Activty diagram –library system

Use case model

• Senarios for understanding the system
• Interaction bw user and system
• Captures users goal and systems responsibility
• Used to discover classes and relationship
• Developed by talking to users
• Use case model
– Provides external view of the system
• Object model (UML class diagram)
– Provides internal view
Use cases and microscope
• A use case is a sequence of transaction in a system whose task is to yield
results of measurable value to an individual actor of the system
• Actor

8
 – Role played by the user with respect to the system
– Single actor may perform many use cases
– Can be external system
– Can be one get value from the system, or just participate in the use
case

Use-Case Model
• major concepts in Use-Case modeling :

Use-case
Actor

• an actor represents anything that interacts with the

system
• a use case is a sequence of actions a system performs
that yields an observable result of value to a particular
actor

• A use-case model is a model of the system’s intended functions (use

cases) and its surroundings (actors)
• The same use-case model is used in requirement analysis, design, &
test
• Primary purpose  is to communicate the system’s functionality and
behavior to the customer or end user
• Benefits of a use-case model :
 To communicate with the end users and domain experts

9
  To identify :
• who will interact with the system and what the system
should do
• what interfaces the system should have
 to verify :
• all requirements are captured
• that the developers have understood the requirements

 Identifying Actors

• Actors are not part of the system, they represent roles a user of the
system can play (user may play more than one role )
• Actor may actively interchange information with the system
• Actor may be a passive recipient of information
• Actor can represent a human, machine or another system
• The difference between users and actors :

USER Can play the role ACTOR performs USE CASE

of
Yati member Borrow book

Salmi employee
Order books

Jamila
volunteer Check IDs

10
 Uses and extends association

• Uses
– common sub flows are extracted and separate use case is created
– Relationship bw usecase and extracted one is called uses relationships
• Extends
– Used when use case is similar to other, but do bit more or more
speciliazed

Borrow books uses

Check library card

extends

Get an uses
interlibrary loan

uses
Return books
member
Circulation clerk

Do research

Read books and news paper

Purchase supplies
supplier

11
• Abstract use case

– No initiating actor

– Used by concrete use cases

• concrete use cases

– Interacts with actors

• Candidates for actors can be found through the answers to the

following questions :

 Who is interested in a certain requirement?

 Where in the organization is the system used?
 Who will supply the system with this information, use this
information, remove this information?
 Who will use this function?
 Who will support and maintain the system?
 Does the system use an external resource?
 What actors do the use cases needed?
 Does one actor play several different roles? Do several actors
play the same role?

12
• Actors and system boundaries

ATM system
ATM
maintenance

Bank teller Bank system

System boundary

Identifying Use-Cases

• A use case models a dialogue between actors and the system

• A use case is initiated by an actor to invoke a certain functionality in
the system
• A use case is a complete and meaningful flow of events
• All use-cases constitute all possible ways of using the system
• Steps for finding use-cases :

13
  For each actor, find the tasks and functions that the actor
should be able to perform or that the system needs the actor to
perform. The use case should represent a course of events that
leads to a clear goal

 Name the use-cases

• Provide a general description of the use-case function
• The name should express what happens when an
instance of the use-case is performed
• Often expressed in the form of a verb (borrow) or verb
and noun (Borrow books)

 Describe the use-cases briefly by applying terms with which the

user is familiar

• Sources of information for use-cases

 System specification /problem statement
 Domain relevant literature
 Interviews with domain experts
 Personal knowledge of the domain
 Legacy systems

14
 • Use-Case diagram is drawn to illustrate that use-cases and actors
interact by sending stimuli to one another

Conduct bank transactions

Customer Bank

Run reports
ATM Maintenance

Maintain ATM machine

• Use-cases are connected to actors through association relationships.

• A line drawn from an actor to a use-case depicts an association
• At times a use-case includes the functionality, extends the
functionality, or generalizes the functionality of another use-case on
the diagram. This is shown using include(or uses), extend, and
generalization relationships.
• Includes association :
 occurs when you are describing your use-cases and notice that
some of them have subflows in common
 to avoid describing a subflow more than once in several use-
cases, you can extract the common subflow and make it a use-
case of its own

15
  represents the inclusion of the functionality of one use-case
within another
 the arrow is drawn from the base use-case to the used use-case
• Extends association :
 Used when you have one use-case that is similar to another use-
case BUT does a bit more, or is more specialized (like a
subclass)
 Put the base or normal behavior in one use-case and the unusual
behaviors somewhere else
 Represents the extension of the use-case to include optional
behavior
 The arrow is drawn from the extension use-case to the base use-
case
• Generalization association :
 Represents a specialized use-case to a more generalized one
 More general use-case being higher than the lower use-cases
 The arrow is drawn from the specialized use-case to the base
use-case

Refer to diagram, distribute in the class.

• Each use-case has to be described in a flow of events document. This

textual document defines what the system has to do when actor
activates a use-case.
• The structure of a use-case document can vary.
• Use-cases are documented in

16
 • A brief description
o The purpose of the use-case in a few lines
• Detailed flow of events
o Description of the primary and alternate flow of
events that occur when the use-case is initiated
• Documentation should read like a dialogue between the
actor and the use-case

• Use-Case Flow of Events :

 Each use-case :
• Has one normal, basic, sequence of transactions
• May have several alternative sequences of transactions
• Usually has several exceptional sequences of transactions
handling erroneous situations
• May also have well defined pre-and post-conditions

 Describe only the events that belong to the use-case, and not
what happens in other use-cases
 Avoid terminology such as “for example”, “etc.”, and “
information”

 The flow of events should describe :

• How and when the use-case starts and ends
• When the use-case interacts with the actors
• What information is excahnged between an actor and the
use-case ( do not describe the details of the user interface
)
• The basic flow of events

17
 • Any alternate flow of events

How detailed must a use case be? When to stop decomposing it and when

to continue

• Develop system use case diagram

• Draw package

– to represent business domains of the system . for each package

create child use case diagram

• Prepare at lest one scenario for each use case

– Each scenario shows different sequence of interaction , with all

decisions definite

• When the lowest use case level is arrived, which can’t be broken further,

sequence and collaboration diagram is drawn

Dividing use case into package

• Whole system is divided into many packages

• Each package encompasses multiple use cases

Refer to Use-Case Documentation example.

• Each use-case represent a scenario in the system

• a design can be broken down into packages, and each of packages
consists multiple use-cases (refer to diagram , distribute in the class )

18
 Who reads Use-Case
documentation ?

customers
users
system developers
reviewers
system analysts / system
designer
system tester
project leader
technical writer

Developing effective documentation

• An effective document can serve as a communication vehicle among the
project's team members, or it can serve as initial understanding of the
requirements.
• Important factor in making a decision about committing (assigning,
handover, giving) resources
• Mainly depends on rules and regulation

19
Guidelines for developing effective documentation:
According to Bell and Evans:
• Common cover
• 80-20 rule
• Familiar vocabulary
• Make the document as short as possible
• Organize the document

1.Common Cover
• All documents should share a common cover sheet that identifies the
document, the current version, and the individual responsible for the
content.
2)80–20 Rule
• 80 percent of the work can be done with 20 percent of the documentation.
• The trick is to make sure that the 20 percent is easily accessible and the rest
(80 percent) is available to those (few) who need to know.
3)Familiar Vocabulary
• Use a vocabulary (word, language, expression) that your readers understand
and are comfortable with.
• The main objective here is to communicate with readers and not impress
them with buzz words.
4)Make the Document as Short as Possible
• Eliminate all repetition;
• Present summaries, reviews, organization chapters in less than three pages;

20
 • Make chapter headings task (mission) oriented so that the table of
contents also could serve as an index (catalogue, guide,key).
•
5)Organize the Document
Use the rules of good organization (such as the organization's standards,
college handbooks, Strunk and White's Elements of Style, or the University
of Chicago Manual of Style) within each section.
SUMMARY
Analysis is the process of extracting the needs of a system and what
the system must do to satisfy the users’ requirements.OOA phase of the
unified approach uses actors and use cases to describe the system from
users’ perspective.A use-case model is a model of the system’s intended
functions (use cases) and its surroundings (actors).A use case models a
dialogue between actors and the system.
KEY TERMS
Use case
Actor
Use case model
KEY TERM QUIZ
1. A use-case model is a model of the system’s intended functions (use cases) and
its surroundings (actors).
2. Use cases are scenarios that describe how actors use the system.
3. An actor represents anything that interacts with the system

MULTIPLE CHOICE
1. A use-case model is a model of the system’s intended functions (use cases) and
its surroundings (actors).
(a) Use case model (b) use cases
2. Use cases are scenarios that describe how actors use the system.
(a) Use case model (b) use cases
3. An actor represents anything that interacts with the system
(a) use case model (b) usecases (c) actor

21
REVIEW QUESTIONS
1. What is a use case model?
2. Describe the basic activities in OO analysis?
3. Who are actors?
4. Why are uses and extends associations useful in use case modeling?
5. How do you identify actors?
6. What is 80-20 rule?
References :
 Bahrami, A.(1999). Object Oriented Systems Development,

using the unified modeling language, McGraw-Hill

 Object Oriented Analysis and Design using UML, by Rational

Software Corporation

 Dennis,A., Wixon,B.H., and Tegarden,D.(2002). Systems Analysis and

Design : An Object Oriented Approach with UML

22
 CHAPTER 5:
OBJECT ANALYSIS – CLASSIFICATION

OBJECTIVES :

At the end of this chapter, students should be able to

• Identify classes using the noun phrase strategy

• Identify classes using the common class pattern strategy
• Identify classes using the CRC strategy
• Identify classes using the use case analysis strategy
• Identify attributes and methods for classes
• Identify relationships between classes
• Develop the interaction diagrams (sequence and collaboration diagrams)
• Develop the class diagram

23
INTRODUCTION:

 Object Analysis : Classification

• Identification of classes is the hardest part of part of OOAnalysis

• Object analysis  a process by which we can identify the classes that

play role a role in achieving the system goals & requirements

• Booch states that “ There is no such a thing as the perfect class

structure, nor the right set of objects”

• Classification  the categorization of input data (things) into

identifiable classes through the extraction of significant features of
attributes of the data from a background of irrelevant detail

• Classes are an important mechanism for classifying objects

• The main role of a class is to define the attributes, methods, and

applicability of its instances

24
 Approaches for identifying classes

• There are 4 alternative approaches for identifying classes :

Classes,
Noun Responsibilities,
phrase and
Collaborators
Commo (CRC)
n class
patterns
Use-case
driven,
sequence /
collaboration
modeling

 Noun Phrase Approach

• Proposed by Rebecca Wirfs-Brock, Brian Wilkerson, & Lauren

Wiener

• Read through the requirements or use-cases looking for noun phrases

25
 Considered to
be
Nouns in
textual Classes
description
Considered to
Verbs in be
Methods of
textual
the classes
description
Changed to
plurals singular

• Nouns are listed and divided into 3 categories :

Relevant fuzzy
classes classes
Irrelevant
classes
Scrap this classes,
which either have
no purpose or will
be unnecessary

• Guidelines for selecting classes in an application :

26
  Look for nouns and noun phrases in the use-cases

 Some classes are implicit or taken from general knowledge

 All classes must make sense in the application domain; avoid

computer implementation classes – defer them to the design
stage

 Carefully choose and define class names

• Guidelines in selecting candidate classes from the relevant and fuzzy

categories of classes in the problem domain :
 Redundant classes ==> do not keep two classes that express the
same information
 Adjectives classes ==> an adjective can suggest a different kind
of object, different use of the same object, or it could be utterly
irrelevant. If the use of the adjective signals that the behavior of
the object is different, then make a new class
 Attribute classes ==> objects that are used only as values
should be defined or restates as attributes and not as a class
 Irrelevant classes ==> each class must have a purpose and
should be clearly defined and necessary. Formulate a statement
of purpose for each candidate class

Refer figure 1.

Review redundant
classes

Review irrelevant
Review adjectives
classes

Review attributes

27
 Figure 1 : the process of eliminating the redundant classes and
refining the remaining classes is not sequential. You can move
back and forth among these steps as often as you like

Initial list of noun classes : in vianet bank

• Account
• Account balance
• Amount
• Approval process
• Atm card
• Atm machine
• Bank
• Bank client
• Card
• Cash
• Check
• Checking
• Checking account
• Client
• Client’s account
• Currency
• Dollar
• Envelope
• Four digits
• Fund
• Invalid pin
• Message
• Money
• Password
• PIN
• Pin code
• Record
• Savings
• Savings account
• Step
• System
• Transaction
• transaction history

28
 Removing irrelevant classes
• Account
• Account balance
• Amount
• Approval process
• Atm card
• Atm machine
• Bank
• Bank client
• Card
• Cash
• Check
• Checking
• Checking account
• Client
• Client’s account
• Currency
• Dollar
• Envelope
• Four digits
• Fund
• Invalid pin
• Message
• Money
• Password
• PIN
• Pin code
• Record
• Savings
• Savings account
• Step
• System
• Transaction
• transaction history

29
 Removing redundant classes and building common vocabulary

Account Client
Account balance Client’s account
Amount Currency
Approval process Dollar Record
Atm card Envelope Savings
Atm machine Four digits Savings account
Bank Fund Step
Bank client Invalid pin System
Card Message Transaction
Cash Money transaction history
Check Password
Checking PIN
Checking account Pin code

30
Reviewing possible attributes

Account Client
Account balance Client’s account
Amount Currency
Record
Approval process Dollar
Savings
Atm card Envelope
Savings account
Atm machine Four digits
Step
Bank Fund
System
Bank client Invalid pin
Transaction
Card Message
transaction
Cash Money
history
Check Password
Checking PIN
Checking account Pin code

Reviewing the class purpose

 Include classes with

• Purpose
• Clear definition
• Necessary in achieving system goal
 Eliminate classes with no purpose
 Ex: Candidate class with purpose are
• ATM machine class
• ATM card class
• Bankclient class
• Bank class
• Account class
• Checking account class

31
 • Saving account class
• Transaction class

 Common Class Patterns

• proposed by shalaer &Mellor, Ross, and Coad & Yourdon
• patterns for finding the candidate class and object :
 Concept class :
• A concept is a particular idea or understanding that we
have of our world
• Consists principles that are not tangible but used to
organize or keep track business activities or
communications
• Ex: performance
 Events class :
• Are points in time that must be recorded
• Associated with things remembered are attributes such as
who, what, when, where, how, or why.
• Ex : landing, order, request
 Organization class :
• A collection of people, resources, facilities, or groups to
which users belong, and their capabilities have a defined
mission, whose existence is largely independent of
individuals.
• Ex : human resources department
 People class :
• Known as person, roles, and roles played class
• Represents the different roles users play in interacting
with the application

32
 • What role does a person play in the system ?
• Ex : employee, student, lecturer

 Places class :
• Physical locations that the system must keep information
about
• Ex : buildings, stores, offices

 Tangible things and devices class :

• Includes physical objects or groups of objects that are
tangible and devices with which the application interacts
• Ex : car (tangible ), pressure sensors (devices)

 Classes, Responsibilities, and Collaborators (CRC)

• Developed by Cunningham, Wilkerson, and Beck  presented as a

way of teaching the basic concepts of OO development

• CRC  a technique used for identifying classes’ responsibilities and

therefore their attributes and methods
• Assists in identifying classes
• Based on the idea that an object either can accomplish a certain
responsibility itself or it may require the assistance of other objects

Then it must
collaborate with those
objects to fulfill its
responsibility
33
 • By identifying an object’s responsibilities and collaborators, you can
identify its attributes and methods

• CRC cards are 4” x 6” index cards  all information for an object is

written on a card (refer figure 2 )

Class name: Collaborators

Responsibilities

Figure 2 : CRC index card

• The CRC process are as follows (refer figure 3 ):
 1. identify classes’ responsibilities (and identify classes )
 2. assign responsibilities
 3. identify collaborators

Identify classes
&
responsibility

Identify Assign
collaboration responsibility

Figure 3 : CRC process

34
 • classes are identified & grouped by common attributes, which also
provides candidate for superclasses
• the card also notes sub-and superclasses to show the class structure
• next, the responsibilities are distributed  should be general as
possible and placed as high as possible in the inheritance hierarchy
• idea in locating collaborators  is to identify how classes interact

 Use-Case Driven Approach : Identifying Classes and their behaviors

thru Sequence/ Collaboration Modeling
• modeling with use-cases is recommended aid in finding the objects of
a system
• technique used by the unified approach
• use-cases are employed to model the scenarios in the system and
specify what external actors interact with the scenarios
• once the system has been described in terms of its scenarios, then
examine the textual description or steps of each scenario to determine
what objects are needed for the scenario to occur
• the process of creating sequence or collaboration diagram is a
systematic way to think about how a use case(scenario) can take
place; and by doing so, it forces you to think about objects involved in
your application

35
 What is use
case analysis ?

• Use Case analysis  the process of examining use cases to discover

objects and classes for the system being developed
 Scenarios are detailed and shown graphically in interaction
diagrams
 Classes are grouped into packages
 Class diagrams are created

• Purpose 
 identify the classes which perform a use case’s flow of events
 distribute the use case behavior to those classes, using a use-
case realizations
 identify the responsibilities, attributes, and associations of the
classes

36
• Use-Case Realization :

Use case model Design model

Use case Use case realization

 A use case realization desribes how a particular use case is

realized within the Design Model in terms of collaborating
objects
 A use case realization in the Design model can be traced to a
use case in the Use Case model.
 A realization realtionship is drawn from the use case
realization to the use-case it realizes

• A use-case realization can be presented using a set of diagrams :

 Interaction diagrams (sequence and/or collaboration
diagrams) can be used to describe how the use case is realized
in terms of collaborating objects. These diagrams model the
detailed collaborations of the use-case realization.
 Class diagrams can be used to describe the classes that
participate in the realization of the use-case, as well as their
supporting relationships. These diagrams model the context of
the use-case realization

37
 • For each use case realization :
 Find classes from use-case behavior
 Distribute use-case behavior to classes

• Find Classes from Use-Case Behavior

 Technique for finding analysis classes uses 3 different
perspectives of the system to drive the identification of
candidate classes

<<boundary>>

<<control>>
System
boundary Use-case
behavior
coordination
<<entity>>

System
information

 These 3 perspectives are :

• The boundary between the system and its actors
• The information the system uses
• The control logic of the system

38
  Identification of classes means just that : they should be
identified, named, and described briefly in a few sentences

 Boundary Class :

• Intermediates between the interface & something outside

the system
• Types of boundary classes :
o User interface classes
o System interface classes
o Device interface classes
• One boundary class per actor/use-case pair

• Example : finding boundary classes:

Course
Student Register for courses Catalog
System

RegisterForCoursesForm CourseCatalogSystem

 Entity Class :

39
 • Represent stores of information in the system
• Used to represent the key concepts that the system
manages
• Entity objects (instances of entity classes) are used to
hold and update information about some phenomenon,
such as an event, a person, or some real-life object
• Main responsibilities of entity classes are to store and
manage information in the system
• Entity objects are identified by applying the nouns
approach
• Example : candidate entity classes : Register for Courses
(Create Schedule )

CourseOfferring Schedule

Student

 Control Class :

• Is a class used to model control behavior specific to one

or more use-cases

40
 • They represent the dynamics of the system, handling the
main tasks and control flows
• One control class per use case

• Example : finding control classes

Course
Student Register for courses Catalog
System

RegistrationController

• Each control class is responsible for controlling the

processing that implements the functionality described in
the associated use case.

• Naming Classes
 A class name should be a singular noun
 Class names start with an upper case letter
 Underscores are not used
• Names composed of multiple words are pushed together
and the first letter of each additional word is capitalized

41
  Example : Student, BillingSystem, CourseRoaster

 After naming a class, a brief concise description of the class

should be made
• Focus on the purpose of the class, NOT on the
implementation
 The class name and description form the basis for a model
dictionary
 Example :

Name : Course
Working Definition : A class offered by the University

Name : Professor
Working Definition : A person teaching classes at the
university

• Distribute Use-Case Behavior to Classes

 For each use-case flow of events :

• Identify analysis classes
• Allocate use-case responsibilities to analysis classes
• Model analysis class interactions in interaction
diagrams

42
 Use case Use-Case
Realization

Sequence Collaboration
diagrams diagrams

• Interaction Diagrams :
 A graphical representation of interactions between objects
 2 kinds of interaction diagrams : Sequence diagrams(time
ordered) and Collaboration diagrams (data flow)

• Sequence Diagram
 Shows object interactions arranged in time sequence
 The diagram shows
• The objects participating in the interaction
• The sequence of messages exchanged

 Basic elements :

43
 • Actors : someone/something outside the system that
interacts with the system, either by giving or receiving
information, or both

• Objects: an entity with a well-defined boundary and

identity that encapsulates state and behavior

Object Math 101 Math 101 : : CourseOffering

representation in
UML CourseOffering

Class name
Object name
Object name and
Class name

44
 • Messages: communication between two objects that
triggers an event

:Prospective Buyer :PersonalPlannerForm

//maintain profile()
Message

• Lifelines :represents the existence of the object at a

particular time
• Focus of control :shows the period of time during which
an object is performing an action, either directly or
through a subordinate procedure

:Prospective Buyer :PersonalPlannerForm

//maintain profile()
//prompt to create
new profile()

• Collaboration Diagram

45
  Alternate way to represent the messages exchanged by a set of
objects
 The diagram shows object interactions organized around the
objects and their links to each other

 Basic elements :
• Actors
• Objects
• Links : a pathway for communication between objects on
a collaboration diagram
• Messages

Example : Collaboration Diagram

2:validate id

3:enter current
1:enter id semester

4:create new
Ali:Student schedule :RegistrationForm

5:display

6:get courses
:AvailableClasses
:ScheduleForm

The guidelines for naming classes:

◊ The class name should be singular.

46
 ◊ One general rule for naming classes is that you should use names with
which the users or clients are comfortable.
◊ The name of a class should reflect its intrinsic nature.
◊ Use readable name. Capitalize class names.

SUMMARY:
Identification of classes is the hardest part of part of
OOAnalysis.Classification is the categorization of input data (things) into
identifiable classes through the extraction of significant features of attributes of the
data from a background of irrelevant detail. The guidelines for naming classes-
The class name should be singular, One general rule for naming classes is that you
should use names with which the users or clients are comfortable, the name of a
class should reflect its intrinsic nature., Use readable name, Capitalize class names.

KEYTERMS
Classes ,Responsibilities, and Collaborators (CRC)
Classification
Concept class
Places class
Organization class
Person class (or) people class
Tangible things and devices class

KEY TERM QUIZ

1. Concept class concept is a particular idea or understanding that we have of
our world
2. Events class is points in time that must be recorded
3. Organization class is a collection of people, resources, facilities, or groups
to which users belong, and their capabilities have a defined mission, whose
existence is largely independent of individuals.
4. People class is Known as person, roles, and roles played class
5. Places class is a physical locations that the system must keep information
about
6. Tangible things and devices class which includes physical objects or
groups of objects that are tangible and devices with which the application
interacts

47
 7. Classes ,Responsibilities, and Collaborators (CRC) is a technique used
for identifying classes’ responsibilities and therefore their attributes and
methods
8. Classification is the categorization of input data (things) into identifiable
classes through the extraction of significant features of attributes of the data
from a background of irrelevant detail.

MULTIPLE CHOICE

1. Concept class concept is a particular idea or understanding that we have of

our world
(a) concept class (b) event class (c) organization class (d) people class
2. Events class is points in time that must be recorded
(a) concept class (b) event class (c) organization class (d) people class
3. Organization class is a collection of people, resources, facilities, or groups
to which users belong, and their capabilities have a defined mission, whose
existence is largely independent of individuals.
(a) concept class (b) event class (c) organization class (d) people class
4. People class is Known as person, roles, and roles played class
(a) concept class (b) event class (c) organization class (d) people class
5. Places class is a physical locations that the system must keep information
about
(a)Places class (b) event class (c) organization class (d) people class
6. Tangible things and devices class which includes physical objects or
groups of objects that are tangible and devices with which the application
interacts
(a) concept class (b) event class (c) organization class (d) Tangible things and
devices class
7. Classes ,Responsibilities, and Collaborators (CRC) is a technique used
for identifying classes’ responsibilities and therefore their attributes and
methods
(a) CRC (B) classification
8. Classification is the categorization of input data (things) into identifiable
classes through the extraction of significant features of attributes of the data
from a background of irrelevant detail.
(a) CRC (B) classification

REVIEW QUESTIONS

48
1. What are the approaches to identify classes?
2. Describe the noun phrase strategy for identifying tentative classes in the
problem
domain?
3. Describe relevant, fuzzy, irrelevant classes.
4. How do you select candidate classes from the list of relevant and fuzzy classes?
5. Why is identifying classes an incremental process?
6. Why is developing a sequence / collaboration diagram a useful activity in
identifying classes?
7. Mention the uses of CRC
8. Why is identifying class hierarchy important in OO analysis?

49
 CHAPTER-8
Identify Objects, Relationships, Attributes, Methods

OBJECTIVES:
At the end of this chapter, students should be able to define and understand:

• Analyzing relationship among classes

• Identifying association
• Association patterns
• Class responsibilities

INTRODUCTION

The three types of relationships among objects are Association, Super-Sub

structure (also known as generalization hierarchy), Aggregation and a-part-of
structure. Association represents a physical or conceptual connection between two
or more objects. Binary associations are shown as lines connecting two class
symbols. Ternary and higher-order associations are shown as diamonds connecting
to a class symbol by lines, and the association name is written above or below the
line. We need to identify the system’s responsibilities because responsibilities
identify problems that are to be solved. A responsibility serves as a handle for
discussing potential solutions. Once the system’s responsibilities are understood,
we can start identifying the attributes of the system’s classes.

50
 Relationships
• All objects stand in relationship to others on whom they rely for
services and control
• The relationship among objects is based on the assumptions each
makes about the other objects, including what operations can be
performed and what behavior results
• 3 types of relationships among objects :
 Association
 Super-Sub structure (also known as generalization hierarchy)
 Aggregation and a-part-of structure

• ASSOCIATION:
 Represents a physical or conceptual connection between two or
more objects
 The most general relationship and indicate communication only
 Ex : if an object has the responsibility for telling another object
that a credit card number is valid or invalid, the two classes
have an association
 Identifying associations begins by analyzing the interactions
between classes
 Any dependency relationship between two or more classes is an
association
 Examine the responsibilities to determine dependencies

51
 The following questions can assists in identifying associations
[Wirfs-Brock, Wilkerson, &Wiener ]:

• Is the class capable of fulfilling the required task by

itself?
• If Not, what does it need ?
• From what other class can it acquire what it needs ?

 Association Specifiers
• association names  a label that clarifies the meaning of
the association
o usually verbs or verb phrase
o use either an association or a role name, NOT
both
o used during analysis, before sufficient information
exists to use role names

• role names  a label that specifies the ‘face’ the class

plays in an association
o usually noun or noun phrase
o use either a role name , or an association name,
NOT both
o roles name are preferable, when information is
available
o always be used during design

52
 • multiplicity  the number of instances a class relates to
an instance of another class
o defined at both ends of the association line

o multiplicity Indicators :

Many *

Exactly one 1

Zero or More 0..*

One or More 1..*

Zero or One 0..1

Specified range 2..4

Example :

1) Give lecture
Person Course
1 1..*

53
2)
Lecturer
Person Course
1 1..*

• SUPER-SUB CLASS RELATIONSHIPS (GENERALIZATION)

 A class is part of hierarchy of classes, where the top class is the
most general one and from it descend all other, more
specialized classes
 Represents the inheritance relationships between related classes
 Also known as generalization hierarchy
 Advantage  can build on what already have and more
important, reuse what already have
 Inheritance allows classes to share and reuse behaviors and
attributes
Example : Generalization hierarchy

StaffMember
StaffName
StaffNo
CalculateBonus
Chachange
GradegetGrade

AdminStaff
CreativeStaff

• AGGREGATION (A-APRT-OF RELATIONSHIPS) :

54
 Represents the situation where a class consists of several
component classes

 A class that is composed of other classes does not behave like

its part; actually ,it behaves very differently

Example : Aggregation

CAR

ENGINE RADIO

CARBURETOR

 2 major properties of an aggregation are :

• Transitivity : the property where, if A is part of B and
part B is part of C, then A is part of C.
o Ex : a carburetor is part of an engine, and engine
is aprt of a car, Therefore a carburetor is aprt of a
car

55
 • Antisymmetry : the property where, if A is part of B, then
B is not part of A.
o Ex : An engine is aprt of car, BUT car is not part
of an engine

 Identifying Attributes
• attributes are things an object must remember
• an attribute is a data definition held by instances of a class (object)
• attributes do not have behavior  they are NOT objects
• attribute are simple nouns or noun phrases
 names must be unique within a class
• each attribute should have a clear, concise definition
• Example :

• Good attributes for the STUDENT class :

o Name : first and last name
o Major : major field of study
• Bad attribute for the STUDENT class :
o SelectedCourses
[ This is a relationship NOT an attribute ]

• An attribute value is the value of an attribute for a particular object

• Each object has a value for every attribute defined for its class

56
• Example : object of the “LECTURER “ class : Attributes
Name
StaffId
Pn.Norhayana Subject Taught
A0224
Software Requirement

Dr.Mohd.Azim
A0123
Software Quality

• identifying attributes of a system’s classes starts with understanding

the system’s responsibilities
• system’s responsibilities can be identified byd eveloping use cases
and the desired charactersitics of the applications, such as determining
what information users need from the system
• The following questions help in identifying the responsibilities of
classes and deciding what data elements to keep track of :
 What information about an object should we keep track of ? 
to identify attributes of a class
 What services must a class provide ?  to identify a class’s
methods

• Many attributes are discovered in the flow of events for the use cases

57
 • Look for nouns that were not considered good candidate
classes
• Others are discovered when the class definition is created

 Identifying Methods/operation
• Objects not only describe abstract data but also must provide some
services

• In an object-oriented environment, every piece of data, or object is

surrounded by a rich set of rountines called methods. ( These methods
do everything from printing the object to initializing its variables )

• Operations (methods or behavior) in the object-oriented system

usually correspond to queries about attributes (and sometimes
association) of the objects

• An operation is a service that can be requested from an object to

effect behavior

• Methods are responsible for managing the value of attributes such as

query, updating, reading, and writing;
Example : operation  GetBalance, return the value of an account’s
balance

58
 • Operation should be name to indicate their outcome NOT the steps
behind the operation

Example :
calculateBalance ( )  poorly named
It indicates the balance must be calculated  this is an
implementation decision

GetBalance ( )  Well named

It indicates the outcome only

• Discovering operations from interaction diagrams

 The messages displayed in sequence and/or collaboration
diagrams are usually oeprations of the receiving class
 Messages are translated into operations and added to class
diagram
Example :

: RegistrationForm : RegistrationManager

2. Add course

RegistrationManager

59
AddCourse( )
  Class Diagram
• A class diagram shows a set of classes, interfaces, and their
relationships
• Model the static view of the system, which supports the functional
requirements of the system
• Made up of the following basic elements :
 Classes
 Relationships
• Associations
• Aggregations
• Generalizations
• Example :

<<entity>>
<<boundary>> Course
ScheduleForm 0..4

1 1
Adds student to
1 1 1

<<entity>>
<<control>> 1
CourseCatalog
RegistrationManager 1
<<entity>>
accesses StudentRecord
60
SUMMARY
The three types of relationships among objects are Association, Super-Sub
structure (also known as generalization hierarchy), Aggregation and a-part-of
structure. Association represents a physical or conceptual connection between two
or more objects. Binary associations are shown as lines connecting two class
symbols. Ternary and higher-order associations are shown as diamonds connecting
to a class symbol by lines, and the association name is written above or below the
line. We need to identify the system’s responsibilities because responsibilities
identify problems that are to be solved. A responsibility serves as a handle for
discussing potential solutions. Once the system’s responsibilities are understood,
we can start identifying the attributes of the system’s classes. A-part-of
relationship, also called aggregation, represents the situation where a class consists
of several component classes. A class that is composed of other classes does not
behave like its parts; actually, it behaves very differently.

KEY TERMS

Aggregation
Antisymmetry
A part of relationship
Association
Transitivity

KEY TEM QUIZ

1. ASSOCIATION represents a physical or conceptual connection between

two or more objects
2. AGGREGATION (A-APRT-OF RELATIONSHIPS) represents the
situation where a class consists of several component classes

61
 3. Transitivity is the property where, if A is part of B and part B is part of C,
then A is part of C.
4. Antisymmetry is the property where, if A is part of B, then B is not part of
A.

MULTIPLE CHOICE

1. ASSOCIATION represents a physical or conceptual connection between

two or more objects
(a) Association (b) Aggregation
2. AGGREGATION (A-APRT-OF RELATIONSHIPS) represents the
situation where a class consists of several component classes
(a) Association (b) Aggregation
3. Transitivity is the property where, if A is part of B and part B is part of C,
then A is part of C.
(a)Transitivity (b) Antisymmetry
4. Antisymmetry is the property where, if A is part of B, then B is not part of
A.
(a)Transitivity (b) Antisymmetry

REVIEW QUESTIONS

1. What is association?
2. What is generalization?
3. How would you identify a super- subclass structure?
4. What is an a-part-of structure? Write their properties.
5. What guidelines would you use to identify a-part-of structure?
6. Is association different from an a-part-of relation?
7. What are unnecessary associations? How would you know?
8. How do you identify attributes?
9. How do you identify methods?
10. What are the unnecessary attributes?
11. Why do we need to justify classes with one attribute?
12. State why documentation is important part of analysis.

62
13. What are the similarities between classes and Use Cases?
14. State the difference between the classes and Use Cases.

 References :
 Bahrami, A.(1999). Object Oriented Systems Development,
using the unified modeling language, McGraw-Hill
 Object Oriented Analysis and Design using UML, by Rational
Software Corporation (2002)

63
 UNIT-IV

OBJECT ORIENTED DESIGN

CHAPTER 9

OO Design Process and Design Axioms

OBJECTIVES:

At the end of this chapter, students should be able to

Define and understand the object-oriented design process

Explain the object-oriented design rules
INTRODUCTION

Main focus of the analysis phase of SW development  “what needs

to be done”
Objects discovered during analysis serve as the framework for design
Class’s attributes, methods, and associations identified during analysis
must be designed for implementation as a data type expressed in the
implementation language
During the design phase, we elevate the model into logical entities,
some of which might relate more to the computer domain (such as
user interface, or the access layer) than the real world or the physical
domain (such as people or employees). Start thinking how to actually
implement the problem in a program.
The goal  to design the classes that we need to implement the
system.
Design is about producing a solution that meets the requirements that
have been specified during analysis.
Object-Oriented Design Process and Design Axioms
• Analysis Phase
– Class’s attributes, methods and associations are identified
– Physical entities, players and their cooperation are identified
– Objects can be individuals, organizations or machines
• Design Phase
– Using Implementation language appropriate data types are assigned
– Elevate the model into logical entities (user interfaces)
– Focus is on the view and access classes (How to maintain information
or best way to interact with a user)

Importance of Good Design

• Time spent on design decides the success of the software developed.
• Good design simplifies implementation and maintenance of a project.
• To formalize (celebrate, honor) design process, axiomatic (clear) approach is
to be followed

OO design process
 Activities of OOD Process

1.Apply design axioms to design classes, their attributes, methods, associations,

structure and protocols.
• 1.1 Refine and complete the static UML class diagram by
adding details to the UML class diagram. This steps
consists of the following activities:
1.1.1 Refine attributes
1.1.2 Design methods and protocols by utilizing
a UML activity diagram to represent the
methods algorithm.
1.1.3 Refine association between classes (if
required)
1.1.4 Refine class hierarchy and design with
inheritance (if required).
1.2 Iterate and refine again.

(2) Design the access layer

• Create mirror classes: For every business class identified and
created, create one access layer
• . Eg , if there are 3 business classes (class1, class2 and class3),
create 3 access layer classes (class1DB, class2DB and
class3DB)
• Identify access layer class relationships
Simplify classes and their relationships – main goal is to eliminate redundant
classes and structures
– Redundant classes: Do not keep 2 classes that perform
similar translate request and translate results activities.
Select one and eliminate the other.
– Method classes: Revisit the classes that consist of only
one or two methods to see if they can be eliminated or
combined with existing classes.
• Iterate and refine again.

(3) Design the view layer classes

– Design the macro level user interface, identifying view layer objects
– Design the micro level user interface, which includes these activities:
(a) Design the view layer objects by applying
 the design axioms and corollaries.
(b) Build a prototype of the view layer
interface
– Test usability and user satisfaction
– Iterate and refine

(4) Iterate and refine the whole design. Reapply the design axioms and if needed ,
repeat the preceding steps.

• An axiom is a fundamental truth that always is observed to be valid and for

which there is no counterexample or exception.
• They can not be proven or derived but they can be invalidated by
counterexamples or exceptions.
• A theorem is a proposition that may not be self-evident (clear) but can be
proved from accepted axioms.
• A corollary is a proposition that follows from an axiom or another
proposition that has been proven.

Types of Axioms
• AXIOM-1 (Independence axiom): deals with relationships between system
components such as classes, requirements, software components.

• AXIOM-2 (Information axiom): deals with the complexity of design

Axioms of OOD
• The axiom 1 of object-oriented design deals with relationships between
system components (such as classes, requirements and software
components) and axiom 2 deals with the complexity of design.
• Axiom 1. The independence axiom. Maintain the independence of
components. According to axiom 1, each component must satisfy its
requirements without affecting other requirements. Eg. Let us design a
refrigerator door which can provide access to food and the energy lost
should be minimized when the door is opened and closed. Opening the door
should be independent of losing energy.
• Axiom 2. The information axiom. Minimize the information content of the
design. It is concerned with simplicity. In object-oriented system, to
minimize complexity use inheritance and the system’s built in classes and
add as little as possible to what already is there.
 Origin of corollaries.

Types of corollaries
The design rules or corollaries derived from
design axioms are stated below.

• Corollary 1: Uncoupled design with less

information content.
• Corollary 2: Single purpose.
• Corollary 3: Large number of simple classes.
• Corollary 4: Strong mapping.
• Corollary 5: Standardization.
• Corollary 6: Design with inheritance.

Corollary 1: Uncoupled design with less information content.

Coupling
• Coupling is a measure of the strength of association established by a
connection from one object or software component to another.
• Coupling is a binary relationship.
• For example A is coupled with B.
• Coupling is important when evaluating a design because it helps us focus on
 an important issue in design.
The degree of coupling
• How complicated the connection is ?
• Whether the connection refers to the object itself or something inside it.
• What is being sent or received?
Cohesion
• Cohesion can be defined as the interactions within a single object or
software component.
Corollaries
• Corollary 1: Uncoupled design with less information content. Highly
cohesive (interconnected) objects can improve coupling because only a
minimal amount of essential information need be passed between objects.
• Corollary 2: Single purpose. Each class must have a single, clearly defined
purpose. While documenting, one should be able to describe the purpose of
a class in few sentences.
• Corollary 3: Large number of simple classes. Keeping the classes simple
allows reusability.
• Corollary 4: Strong mapping. There must be a strong association between
the physical system (analysis’s objects) and logical design (design’s object).
• Corollary 5: Standardization. Promote standardization by designing inter
changeable components and reusing existing classes or components.
• Corollary 6: Design with inheritance. Common behavior (methods) must be
moved to super classes. The superclass-subclass structure must make logical
sense.

Corollary 1: Uncoupled Design with Less Information Content

• Coupling is a measure of the strength of association established by a
connection from one object or software component to another. Coupling is a
binary relationship. It is important for design because a change in one
component should have a minimal impact on the other components.
• The degree or strength of coupling between 2 components is measured by
the amount and complexity of information transmitted between them.
• Object oriented design has 2 types of coupling: interaction coupling and
inheritance coupling.
• Interaction coupling involves the amount and complexity of messages
between components. It is good to have little interaction. The general
guideline is to keep the message as simple and infrequent as possible.
• Objects connected to many complex messages are tightly coupled, meaning
any change to one invariably leads to a ripple (current, flow) effect of
changes in others.
 • Inheritance is a form of coupling between super and sub classes.
• A subclass is coupled to its superclass in terms of attributes and methods.
We need high inheritance coupling. For this each specialization class should
not inherit lot of unrelated and unneeded methods and attributes.
• If the superclass is overwriting most of the methods or not using them, then
it is an indication that the inheritance coupling is low.
Types of coupling among objects or components (highest to lowest)
Name Degree of coupling
• Content coupling Very high
• Common coupling High
• Control coupling Medium
• Stamp coupling Low
• Data coupling Very low

• Cohesion: The interactions within a single object or software component is

called cohesion.
• Cohesion reflects the “single-purposeness” of an object.
• Highly cohesive components can lower coupling because only a minimum
of essential information need be passed between components.
• Method cohesion, means that a method should carry one function.
• A method that carries multiple functions is undesirable.
• Class cohesion means that all the class’s methods and attributes must be
highly cohesive, meaning to be used by internal methods or derived classes’
methods.

Corollary 2: Single Purpose

• Every class should be clearly defined and necessary in the context of
achieving the system’s goals.
• When we document a class, we should be able to explain its purpose in a
sentence or two.
• If we cannot, then the class should be subdivided into independent pieces.
• Each method must provide only one service.
• Each method should be of moderate size, no more than a page; half a page is
better.

Corollary 3: Large number of simpler classes, Reusability

• There are benefits in having a large number of simpler classes because the
chances of reusing smaller classes in other projects is high.
• Large and complex classes are too specialized to be reused.
• Object-oriented design offers a path for producing libraries of reusable parts.
Why reusability is not used? Coad and Yourdan
Software engineering textbooks teach new practitioners to build systems from
“first principles”; reusability is not promoted or even discussed
• The “not invented here” syndrome(condition,pattern) and the
intellectual(logical) challenge of solving an interesting software problem in
one’s own unique way mitigates against reusing someone else’s software
component.
• Unsuccessful experiences with software reusability in the past have
convinced many practitioners and development managers that the concept is
not practical.
• Most organizations provide no reward for reusability; sometimes
productivity (output, efficiecy) is measured in terms of new lines of code
written plus a discounted credit

Corollary 4: Strong mapping

• A strong mapping links classes identified during analysis and classes
designed during the design phase eg view and access classes.
• The analyst identifies objects’ types and inheritance, and thinks about events
that change the state of objects.
• The designer adds detail to this model perhaps designing screens, user
interaction, and client-server interaction.

Corollary 5: Standardization
• To reuse classes, we must have a good understanding of the classes.
• Most object-oriented systems come with several built-in class libraries.
• But these class libraries are not always well documented.
• Sometimes they are documented, but not updated.
• They must be easily searched, based on users’ criteria.

Corollary 6: Designing with inheritance

• When we implement a class, we have to determine its ancestor, what
attributes it will have, and what messages it will understand.
• Then we have to construct its methods and protocols.
• Ideally, one has to choose inheritance to minimize the amount of program
instructions.
• The primitive form of reuse is cut-and-paste reusability.

Achieving Multiple Inheritance in a Singe Inheritance System

• Single inheritance means that each class has only a single super class.
• The result of using a single inheritance hierarchy is the absence of
ambiguity as to how an object will respond in a given method;
• We simply trace up the class tree beginning with the object’s class, looking
for a method of the same name.
• But languages like LISP or C++ have a multiple inheritance scheme
whereby objects can inherit behavior from unrelated areas of the class tree.
• The complication here is how to determine which behavior to get from
which class, particularly when several ancestors define the same method.
• One way of resolving this is to inherit from the most appropriate class and
add an object of mother class as an attribute or aggregation. The other is to
use the instance of the class (object) as an attribute.

Lisence

CommercialVehicle PrivateVehicle
 Lisencee

Restuarant
CommercialVehiclee PrivateVehiclee

FoodTruck
 Lisencee

CommercialVehiclee PrivateVehiclee

FoodTruck

Restuarant

Design Patterns
• A design pattern provides a scheme for refining the subsystem or
components of a software system or the relationships among them.
• They allow systems to share knowledge about their design, by describing
commonly recurring structures of communicating components that solve a
general design problem within a particular context
SUMMARY

The basic goal of the axiomatic approach is to formalize the design process
and assist in establishing a scientific foundation for the object-oriented design
process, so as to provide a fundamental basis for the creation of systems. Without
scientific principles, the design field never will be systematized and so will be

difficult to comprehend, codify, teach and practice. The main activities in design
process are

◊ Designing classes (their attributes, methods, associations, structures, and

protocols) and applying design axioms. If needed, this step is repeated.

◊ Designing the access layer.

◊ Designing the user interface (view layer classes).

◊ Testing user satisfaction and usability, based on the usage and use cases.

◊ Iterating and refining the design.

An axiom is a fundamental truth that always is observed to be valid and for

which there is no counterexample or exception. The axioms cannot be proven or
derived but they cannot be invalidated by counterexamples or exceptions. There
are two design axioms applied to object-oriented design. Axiom 1 deals with
relationships between system components and Axiom 2 deals with the complexity
of design.

Axiom 1: The independence axiom. Maintain the independence of components.

Axiom 2: The information axiom. Minimize the information content of the

design.

A corollary is a proposition that follows from an axiom or another

proposition that has been proven. A corollary is shown to be valid if its referent
axioms and deductive steps are valid. The design rules or corollaries derived from
design axioms are stated below.

Corollary 1: Uncoupled design with less information content.

 Corollary 2: Single purpose.

Corollary 3: Large number of simple classes.

Corollary 4: Strong mapping.

Corollary 5: Standardization.

Corollary 6: Design with inheritance.

KEY TERMS

Axioms

Cohesion

Corollary

Coupling

Design pattern

Theorem

KEY TERM QUIZ

1. An axiom is a fundamental truth that always is observed to be valid and for

which there is no counterexample or exception.
2. A corollary is a proposition that follows from an axiom or another
proposition that has been proven.
3. Design Patterns provides a scheme for refining the subsystems or
components of a software system or the relationships among them
4. A theorem is a proposition that may not be self-evident but can be proven
from accepted axioms. Therefore, is equivalent to a law or principle.
5. Cohesion can be defined as the interactions within a single object or
software component.
6. Coupling deals with interactions between objects or software components.
MULTIPLE CHOICE

1. An axiom is a fundamental truth that always is observed to be valid and for

which there is no counterexample or exception.
(a) Axiom (b) corollary

2. A corollary is a proposition that follows from an axiom or another

proposition that has been proven.
(a) Axiom (b) corollary

3. Design Patterns provides a scheme for refining the subsystems or

components of a sw system or the relationships among them
(a) Design pattern (b) Theorem

4. A theorem is a proposition that may not be self-evident but can be proven

from accepted axioms. Therefore, is equivalent to a law or principle.
(a) Design pattern (b) Theorem

5. Cohesion can be defined as the interactions within a single object or

software component.
(a) Cohesion (b) Coupling

6. Coupling deals with interactions between objects or software components.

(a) Cohesion (b) Coupling

REVIEW QUESTIONS

1.What is the task of design?

2. What is the significance of Occam’s razor?
3. Define axiom.
4. Define theorem and corollary.
5. What is coupling?
6. State the different type of coupling.
7. Define cohesion.
8. What is basic activity in designing an application?
9. List the Object Oriented design axioms and corollaries.
10. What is the relationship between coupling and cohesion?
 References :
 Bahrami, A.(1999). Object Oriented Systems Development,

using the unified modeling language, McGraw-Hill

 Object Oriented Analysis and Design using UML, by Rational

Software Corporation (2002)

 CHAPTER 10

Designing Classes

OBJECTIVES :

At the end of this chapter, students should be able to

Designing classes

Designing protocols and class visibility

Designing methods

Develop statechart diagrams

Develop packages

 INTRODUCTION

Most important activity in designing an application is coming up with

a set of classes that work together to provide the needed functionality
Underlying the functionality of any application is the quality of its
design
This chapter focus on guidelines & approaches in designing classes
and their methods
Use the OCL (Object Constraint Language- a specification language,
provided by UML ) to specify the properties of a system
Designing Classes
• Object-oriented design requires taking the object identified during object-
oriented analysis and designing classes to represent them.
• As a class designer, we have to know the specifics of the class we are
designing and also we should be aware of how that class interacts with other
classes.

Object oriented design philosophy

• Here one has to think in terms of classes. As new facts are acquired, we
relate them to existing structures in our environment (model).
• After enough new facts are acquired about a certain area, we create new
structures to accommodate the greater level of detail in our knowledge.
• The important activity in designing an application is coming up with a set of
classes that work together to provide the functionality we desire.
• If we design the classes with reusability in mind, we will gain a lot of
productivity and reduce the time for developing new applications.

Designing Classes : the process

Class visibility: Designing well-defined public, private and protected protocols
• In designing methods or attributes for classes, we are confronted (dealed)
with two problems.
• One is the protocol or interface to the class operations and its visibility and
the other is how it is implemented.
• The class’s protocol or the messages that a class understands, can be hidden
from other objects (private protocol) or made available to other objects
(public protocol).
• Public protocols define the functionality and external messages of an object.
• Private protocols define the implementation of an object.

Visibility
• A class might have a set of methods that it uses only internally, messages to
itself. This private protocol of the class, includes messages that normally
should not be sent from other objects. Here only the class itself can use the
methods.
• The public protocol defines the stated behavior of the class as a citizen in a
population and is important information for users as well as future
descendants, so it is accessible to all classes. If the methods or attributes can
be used by the class itself (or its subclasses) a protected protocol can be
used. Here subclasses can used the method in addition to the class itself.
• The lack of well-designed protocol can manifest itself as encapsulation
leakage. It happens when details about a class’s internal implementation are
disclosed through the interface.

Encapsulation leakage
• Encapsulation leakage is lack of a well-designed protocol
• The problem of encapsulation leakage occurs when details about a class’s
internal implementation are disclosed through the interface.
• As more internal details become visible, the flexibility to make changes in
the future decreases.
Visibility types

Attribute representations :
• During design, OCL ( Object Constraint Language) can be used to define the
class attributes

OCL
• The rules and semantics of the UML are expressed in English, in a form
known as object constraint language.
• Object constraint language (OCL) is a specification language that uses
simple logic for specifying the properties of a system.

Attribute presentation suggested by UML :

Designing classes: Refining attributes
• Attributes identified in object-oriented analysis must be refined with an eye
on implementation during this phase.
• In the analysis phase, the name of the attribute is enough.
• But in the design phase, detailed information must be added to the model.
• The 3 basic types of attributes are:
(1) Single-value attributes
(2) Multiplicity or multivalue attributes
(3) Reference to another object or instance connection

Attributes
• Attributes represent the state of an object.
• When the state of the object changes, these changes are reflected in the value
of attributes.
• Single value attribute has only one value or state. (Eg). Name, address,
salary
• Multiplicity or multivalue attribute can have a collection of many values at
any time.
• (Eg) If we want to keep tact of the names of people who have called a
customer support line for help.

Multi value attribute

• Instance connection attributes are required to provide the mapping needed
by an object to fulfill its responsibilities.
 • (E.g.) A person may have one or more bank accounts.
• A person has zero to many instance connections to Account(s).
• Similarly, an Account can be assigned to one or more person(s) (joint
account).
• So an Account has zero to many instance connection to Person(s).

Designing methods and protocols

• A class can provide several types of methods:
• Constructor: Method that creates instances (objects) of the class
• Destructor: The method that destroys instances
• Conversion Method: The method that converts a value from one unit of
measure to another.
• Copy Method: The method that copies the contents of one instance to
another instance
• Attribute set: The method that sets the values of one or more attributes
• Attribute get: The method that returns the values of one or more attributes
• I/O methods: The methods that provide or receive data to or from a device
• Domain specific: The method specific to the application.

Design goals
• To maximize cohesiveness (interconnection) among objects and software
components to improve coupling (combination, pairing), because only a
minimal amount of essential information should be passed between
components.
• Abstraction leads to simplicity and straight- forwardness and, at the same
time, increases class versatility (flexibility, resourcefulness, usefulness).

Five rules/ characteristics of bad design

• If it looks messy (confused, disorder), then it’s probably a bad design.
• If it is too complex, then it’s probably a bad design.
• If it is too big, then it’s probably a bad design.
• If people don’t like it, then it’s probably a bad design.
• If it doesn’t work, then it’s probably a bad design.

Design issues- avoiding design pitfall (drawbacks, difficulty)

• Apply design axioms to avoid common design problems and pitfalls.
• Much better to have a large set of simple classes than a few large, complex
classes.
Possible actions to solve design problems
• Keep a careful eye on the class design and make sure that an object’s role
remains well defined. If an object loses focus, you need to modify the
design.Apply corollary -2
• Move some functions into new classes that the object would use, Apply
corollary 1.
• Break up the class into two or more classes. Apply corollary 3.
• Rethink the class definition based on experience gained.

Packages and Managing Classes

• A package groups and manages the modeling elements, such as classes, their
associations and their structures.
• Packages themselves may be nested within other packages.
• A package may contain both other packages and ordinary model elements.
• A package provides a hierarchy of different system components and can
reference other packages.
• Classes can be packaged based on the services they provide or grouped into
the business classes, access classes and view classes.

SUMMARY

Expressions are stated as strings in object constraint language. The syntax

for some common expressions is given here. The leftmost element must be an
expression for an object or a set of objects. The expressions are meant to work on
sets of values when applicable.

◊ Item. Selector: (e.g.) John. age

◊ Item. Selector [qualifier-value]: (e.g.) John. Phone[2]

◊ Set->select(Boolean-expression): (e.g.) company.employee-salary->30000

Private protocol of the class includes messages that normally should not be
sent from other objects. The messages are accessible only to operations of that
class. Only the class itself can use the method.

◊ The public protocol defines the stated behavior of the class so that it is
 accessible to all classes.

◊ If the methods or attributes have to be used by the class itself or its

subclasses, a protected protocol can be used. In a protected protocol,

subclasses can use the method in addition to the class itself.

Encapsulation leakage is lack of a well-designed protocol. The problem of

encapsulation leakage occurs when details about a class’s internal implementation
are disclosed through the interface. As more internal details become visible, the
flexibility to make changes in the future decreases.

A class can provide several types of methods:

◊ Constructor: Method that creates instances (objects) of the class.

◊ Destructor: The method that destroys instances.

◊ Conversion method: The method that converts a value from one unit f
measure to another.

◊ Copy method: The method that copies the contents of one instance to

another instance.

◊ Attribute set: The method that sets the values of one or more attributes.

◊ Attribute get: The method that returns the values of one or more

attributes.

◊ I/O methods: The methods that provide or receive data to or from a

device.

◊ Domain specific: The method specific to the application.

KEY TERMS:

Object constraint language (OCL)

Private protocol
Protected protocol

Public protocol

KEY TERM QUIZ

1. Private protocol of the class, includes messages that normally should not be
sent from other objects
2. Public protocol defines the stated behavior of the class as a citizen in a
population and is important information for users as well as future
descendants
3. Protected protocol is nothing but Methods or attributes can be used by the
class itself or its subclasses
4. Use the Object Constraint Language- a specification language, provided
by UML to specify the properties of a system
MULTIPLE CHOICE

1. Private protocol of the class, includes messages that normally should not be
sent from other objects
a) Object constraint language (OCL)
b) Private protocol
c) Protected protocol
d) Public protocol
2. Public protocol defines the stated behavior of the class as a citizen in a
population and is important information for users as well as future
descendants
a) Object constraint language (OCL)
b) Private protocol
c) Protected protocol
d) Public protocol
3. Protected protocol is nothing but Methods or attributes can be used by the
class itself or its subclasses
a) Object constraint language (OCL)
 b) Private protocol
c) Protected protocol
d) Public protocol
4. Use the Object Constraint Language- a specification language, provided
by UML to specify the properties of a system
a) Object constraint language (OCL)
b) Private protocol
c) Protected protocol
d) Public protocol
REVIEW QUESTIONS

1. What are public and private protocols? What is the significance of separating
these two protocols? (Pg 220)
2. What are some characteristics of a bad design? (Pg 226)
3. How do design axioms help avoid design pitfalls? (Pg 226)
4. List out the type of attributes. Explain them (Pg 222)
5. How is an attribute represented in the UML? (Pg 222)
6. How is an operation represented in the UML? (Pg 227)
7. Define Encapsulation Leakage (Pg 220)
8. What is OCL? (Pg 218)
9. What is the use of protected protocol? (Pg 220)

 References :
 Bahrami, A.(1999). Object Oriented Systems Development,
using the unified modeling language, McGraw-Hill
 Object Oriented Analysis and Design using UML, by Rational
Software Corporation (2002)
 Leszek A. Maciaszek (2001). Requirements Analysis and System
Design, Developing Information Systems with UML, Addison-
Wesley.
 CHAPTER-11
Access Layer - Object Storage – Object Interoperability

OBJECTIVES:

At the end of this chapter, students should be able to

Define and understand the persistent objects and transient objects

Define and understand the object-relational systems
 INTRODUCTION
DBMS = is a set of programs that enables the creation and
maintenance of a collection of related data
Fundamental purpose of a DBMS  provide a reliable, persistent
data storage facility and the mechanisms for efficient, convenient data
access and retrieval
In an OO system, it concerned with both persistent objects and
transient objects
Transient data  data that will be erased from memory after they
have been used
Persistent data  data that must be stored in a secondary data storage
system, not just in computer memory, that must be stored after the
program that creates or amends it stops running, and that usually must
be available to other users
Access Layer: Object storage and object interoperability

• A Date Base Management System (DBMS) is a set of programs that enables

the creation and maintenance (access, manipulate, protect and manage) of a
collection of related data.
• The purpose of DBMS is to provide reliable, persistent data storage and
mechanisms for efficient, convenient data access and retrieval.
• Persistence refers to the ability of some objects to outlive the programs that
created them.
• Object lifetimes can be short for local objects (called transient objects) or
long for objects stored indefinitely in a database (called persistent objects).

Persistent stores
• Most object-oriented languages do not support serialization or object
persistence, which is the process of writing or reading an object to and from
a persistence storage medium, such as disk file.
• Unlike object oriented DBMS systems, the persistent object stores do not
support query or interactive user interface facilities.
• Controlling concurrent access by users, providing ad-hoc query capability
and allowing independent control over the physical location of data are not
possible with persistent objects.

Object Store and Persistence

Each item of data will have a different lifetime. These lifetimes are categories
into six, namely

1. Transient results to the evaluation of expressions.

2. Variable involved in procedure activation (parameters and variables
with a localized scope)
3. Global variable and variables that are dynamically allocated
4. Data that exist between the executions of a program
5. Data that exist between the versions of a program.
6. Data that outlive a program.
Typically, programming languages provide excellent, integrated support for the
first three categories of transient data. The other three categories can be supported
by a DBMS, or a file system. A file or a database can provide a longer life for
objects – longer than the duration of the process in which they were created. From
a language perspective, this characteristic is called persistence.
Essential elements in providing a persistent store are:
Identification of persistent objects or reachability (Object ID)
Properties of objects and their interconnections. The store must be able to
coherently manage nonpointer and pointer data. (i.e interobject references)
Scale of the object store. The object store should provide a conceptually infinite
store.
The system should be able to recover from unexpected failures and return the
system to a recent self-consistent state.
Database Models
• A database model is a collection of logical constructs used to represent the
data structure and data relationships within the database. The conceptual
model focuses on the logical nature of that data presentation. It is concerned
with what is represented in the database and the implementation model is
concerned with how it is represented.
• Hierarchical model
• This model represents data as a single rooted tree. Each node in the tree
represents a data object and the connection represents a parent-child
relationship.
• Network Model
• This is similar to a hierarchical database, with one difference. Here record
can have more than one parent.
Network Model
• A network database model is similar to hierarchical model. Here in this
model each parent can have any number of child nodes and each child node
can have any number of parent nodes.

Relational Model
• It is simple and widespread. Here the relation can be thought of as a
table.
• The columns of each table are attributes that define the data or value
domain for entries in that column.
• The rows of each table are tuples representing individual data objects
being stored.
• A relational table should have only one primary key.
• A primary key is a combination of one or more attributes whose value
unambiguously (clearly) locates each row in the table.
• A foreign key is a primary key of one table that is embedded in another
table to link the tables.

Database Interface

• The interface on a database must include a data definition language

(DDL), a query and data manipulation language (DML). These
languages must be designed to reflect the flexibility and constraints
inherent in the data model. Databases have adopted 2 approaches for
interfaces with the system.
• One is to embed a database language such as structured query language
(SQL), in the host programming language. The problem here is that
application programmers have to learn and use two different languages.
The application programmers have to negotiate the differences in the
data models and data structures allowed in both languages.
 • Another approach is to extend the host programming language with
database related constructs. Here application programmers need to
learn only a new construct of the same language rather than a
completely new language. Eg. GemStone from Servio Logic has
extended the Smalltalk object-oriented programming.

Database Schema and Data Definition Language

• DDL is the language used to describe the structure of and relationships
between objects stored in a database. This structure of information is
termed the database schema. In traditional databases, the schema is the
collection of record types and set types or the collection of relationships
and table records to store information about entities of interest to the
application.
• E.g.. CREATE TABLE inventory (Inventory_Number CHAR(10)
NOT NULL Description CHAR(25) NOT NULL Price DECIMAL
(9,2));

Data Manipulation Language and Query Capabilities

• Asking Questions, formally making queries of the data – is a typical and
common use of a database. A query is expressed through a query
language. A Data Manipulation Language (DML) is the language that
allows users to access and manipulate (such as create, save or destroy)
data organizations. The SQL is the standard DML for relational
DBMSs. The query usually specifies
• The domain of the discourse over which to ask the query
• The elements of general interest
• The conditions or constraints that apply
• The ordering, sorting or grouping of elements and the constraints that
apply to the ordering or grouping

DML
• Query processes have sophisticated “engines” that determine the best
way to approach the database and execute the query over it. The may
use the information in the database or knowledge of the whereabouts of
particular data in the network to optimize the retrieval of a query.
• DML are either procedural or nonprocedural. A Procedural DML
requires users to specify what data are desired and how to get the data.
• A non-procedural DML requires users to specify what data are needed
but not how to get the data. Object-oriented query and data
manipulation languages, such as Object SQL, provide object
 management capabilities to the data manipulation language.
• In a relational DBMS, the DML is independent of the host
programming language.
• A host language such as C or COBOL would be used to write the body
of the application. SQL statements then are embedded in C or COBOL
applications to manipulate data.
• Once SQL is used to request and retrieve database data, the results of
the SQL retrieval must be transformed into the data structures of the
programming language.
• The drawback here is that the programmers code here in two
languages, SQL and the host language.

Logical and Physical Database Organization and Access Control

• Logical database organization refers to the conceptual view of database
structure and the relationships within the database. Physical database
organization refers to how the logical components are represented in a
physical form by operating system constructs eg objects may be
represented as files.

Shareability and Transactions

• Data and objects in the database need to be accessed and shared by
different applications. With multiple applications having access to the
object concurrently, it is likely that conflicts over object access will
arise. The database must detect and mediate these conflicts and
promote maximum amount of sharing without any data integrity
problem. This mediation process is managed through concurrency
control policies, implemented, by transactions.

Transactions
• Transaction is a unit of change in which many individual modifications
are aggregated into a single modification that occurs in its entirety or
not at all. Thus either all changes to objects within a given transaction
are applied to the database or none of the changes. A transaction is said
to commit if all changes can be made successfully to the database and to
abort if canceled because all change to the database cannot be made
successfully. This ability of transactions ensures atomicity of change
that maintains the database in a consistent state.
• Many transaction systems are designed for short transactions (lasting
for minutes). They are less suitable for long transactions, lasting hours.
Object databases are designed to support both short and long
 transactions. A concurrent control policy dictates what happens when
conflicts arise between transactions that attempt to access to the same
object and how these conflicts are to be resolved.

Concurrency Policy
• When several users attempt to read and write the same object
simultaneously, they create a contention (conflict) for object. Then
concurrency control mechanism is established to mediate such conflicts
by making policies that dictate how they will be handled.
• To provide consistent view, the transactions must occur in serial order.
A user must see the database as it exists before a given transaction
occurs or after the transaction.

Concurrency issues
• The conservative way of enforcing serialization is to allow a user to lock
all objects or records when they are accessed and to release the locks
only after a transaction commits. This is called conservative or
pessimistic policy. It provides exclusive access to the object, despite
what is done to it. The policy is conservative because no other user can
view the data until the object is released.
• By distinguishing between querying (reading) the object and writing to
it, greater concurrency can be achieved. This policy allows many
readers of an object but only one writer.
• Under an optimistic policy, two conflicting transactions are compared in
their entirety and then their serial ordering is determined.
• A process can be allowed to obtain a read lock on an object already
write locked if its entire transaction can be serialized as if it occurred
either entirely before or entirely after the conflicting transaction.
• The reverse also is true. A process may be allowed to obtain a write
lock on an object that has a read lock if its entire transaction can be
serialized as if it occurred after the conflicting transaction. Now the
optimistic policy allows more processes to operate concurrently than the
conservative policy.]

Distributed Databases and Client-Server Computing

• In distributed databases, portions of the database reside on different
nodes and disk drives in the network.
• Each portion of the database is managed by a server.
• The server sends information to client applications and makes queries
or data requests to these client applications or other servers.
Client-Server Computing
• It is the logical extension of modular programming. In modular
programming we separate a large piece of software into its constituent
parts (modules). This makes development easier and gives better
maintainability.
• In client-server computing all those modules are not executed within the
same memory space or even on the same machine. Here the calling
method becomes “client” and the called module becomes the “server”.
• The important component of client-server computing is connectivity,
which allows applications to communicate transparently with other
programs or processes, regardless of their locations. The key element of
connectivity is the network operating system (NOS), known as
middleware. The NOS provides services such as routing, distribution,
messages, filing, printing and network management.
• Client programs manage user interface portion of the application,
validate data entered by the user, dispatch requests to server program
and executes business logic. The business layer contains all the objects
that represent the business.
• The client-based process is the front-end of the application, which the
user sees and interacts with. It manages the local resource with which
the user interacts, such as the monitor, keyboard, workstation, CPU and
peripherals.
• A key component of a client workstation is the graphical user interface
(GUI). It is responsible for detecting user actions, managing the
Windows on the display and displaying the data in the Windows.
• The server process performs back-end tasks.
• Client – Node that request for a service
• Server – Node that services the request.
• Client Server computing is the logical extension of modular
programming.
• The fundamental concept behind the modular programming is
decomposing the larger software in to smaller modules for easier
development and maintainability.
• Client Server computing is developed by extending this concept i.e,
modules are allowed to execute in different nodes with different
memory spaces.
• The module that needs and request the service is called a client and the
module that gives the service is called a server.
• The network operating system is the back bones of this client sever
 computing.
• It provides services such as routing, distribution, messages, filing and
printing and network management. This Network Operating System
(NOS) is called middleware.

Client Program:
• It sends a message to the server requesting a service (task done by
server).
• Manages User Interface portion of the application.
• Performs validation of data input by the user.
• Performs business logic execution (in case of 2 tier).
• Manages local resources.
• Mostly client programs are GUI.
Server Program:
• Fulfills the task requested by the client.
• Executes database retrieval and updation as requested by the client.
• Manages data integrity and dispatches results to the client.
• Some cases a server performs file sharing as well as application services.
• Uses power full processors and huge storage devices.

• File Server – Manages sharing of files or file records. Client sends a

message to the file server requesting a file or file record. The File Server
checks the integrity and availability of file/record.
• Data Base Servers – Client pass the SQL query in the form of messages
to the server in turn server performs the query and dispatches the
result.
• Transaction Servers – Client sends message to the server for a
transaction (set of SQLstatements) where the transaction succeeds or
fails entirely.
• Application Servers – Application servers need not to be database
centric. They may Serve any of user needs such as sending mails,
regulating download.

Characteristics of Client Server Computing

1. A combination of client/ front end process that interacts with the user
and server/ backend process that interacts with the shared resources.
2. The front end and back end task have different computing resource
requirements.
3. The hardware platform and operating system need not be the same.
4. Client and Server communicate through standard well defined Application
Program Interface(API).
5. They are scalable.

File server Vs Database server

• The server can take different forms. The simplest form of server is a file
server. With a file server, the client passes requests for files or file records
over a network to the file server. This needs a large bandwidth and can slow
down a network with many users. Traditional LAN computing allows users
to share resources such as data files and peripheral devices.
• Advanced forms of servers are database servers, transaction servers, and
application servers and object servers. With database servers, clients pass
SQL requests as messages to the server and the results of the query are
returned over the network. Both the code that processes the SQL request
and the data reside on the server, allowing it to sue its own processing power
to find the requested data. This is in contrast to the file server, which
requires passing all the records back to the client and then letting the client
find its own data.

Transaction Servers
• With transaction servers, clients invoke remote procedures that reside
on servers, which also contain an SQL database engine. The server has
procedural statements to execute a group of SQL statements
(transactions), which either all succeed or fail as a unit.
• Applications based on transaction servers, handled by on-line
transaction processing (OLTP), tend to be mission-critical applications
that always require a 1-3 second response time and tight control over
the security and integrity of the database. The communication
overhead in this approach is kept to a minimum, since the exchange
consists of a single request and reply (as opposed to multiple SQL
statements in database servers).

N-tier architecutre

• In a two-tier architecture, a client talks directly to a server, with no

intervening server. This type of architecture is used in small environments
with less than 50 users. To scale up to hundreds or thousands of users, it is
necessary to move to a 3-tier architecture.
• Three-tier architecture introduces a server between the client and the server.
The role of the application or Web server is manifold. It can provide
translation services, metering services (transaction monitor to limit the
 number of simultaneous requests to a given server) or intelligent agent
services (mapping a request to a number of different servers, collating the
results, and returning a single response to the client).

Basic characteristics of client-server architectures

• The client process contains solution-specific logic and provides the interface
between the user and the rest of the application system. The server process
acts as a software engine that manages shared resources such as databases,
printers, modems or processors.
• The front end task and back-end task have fundamentally different
requirements for computing resources such as processor speeds, memory,
disk speeds and capacities and i/o devices.
• The environment is heterogeneous and multivendor. The h/w platform and
o/s of client and server are not the same.
• They can be scaled horizontally and vertically. Horizontal scaling means
adding or removing client workstations with only a slight performance
impact. Vertical scaling means migrating to a larger and faster server
machine.

Distributed and Cooperative Processing

• Distributed processing means distribution of applications and business logic

across multiple processing platforms. It implies that processing will occur
on more than one processor to complete a transaction. The processing is
distributed across 2 or more machines, where each process performs part of
an application in a sequence. These processes may not run at the same time.
• Cooperative processing is computing that requires two or more distinct
processors to complete a single transaction. Here programs interact and
execute concurrently on different processors

Common Object Request Broker Architecture

• It is used to integrate distributed, heterogeneous business applications
and data. The CORBA interface definition language (IDL) allows
developers to specify language-neutral, object-oriented interfaces for
application and system components. IDL definitions are stored in an
interface repository that offers object interfaces and services. For
distributed enterprise computing, the interface repository is central to
communication among objects located on different systems.
• CORBA implements a communication channel through which
applications can access object interfaces and request data and services.
 • The CORBA common object environment (COE) provides system level
services such as life cycle management for objects accessed through
CORBA, event notification between objects and transaction and
concurrency control.

Microsoft’s ActiveX/DCOM
• Microsoft’s Component Object Model (COM) and its successor, the
distributed component object model (DCOM) are alternative to COR
BA. DCOM was bundled with Windows NT 4.0. DCOM is an Internet
and component strategy where ActiveX (formerly known as object
linking and embedding or OLE) plays the role of DCOM object.
DCOM is backed by web browser (Internet Explorer).

DISTRIBUTED DATABASES

Many modern databases are distributed databases, which implies that portions of
the database reside on different nodes (computers) and disk drives in the network.
Usually, each portion of the database is managed by a server, a process responsible
for controlling access and retrieval of data from the database portion.

What is Client-server Computing

Client-server computing is the logical extension of modular programming.
The modular programming is hat separation of a large piece of software into its
constitute parts (“modules”) creates the possibility for easier development and
better maintainability.

Client-server computing extends this theory a step further by recognizing that all
those modules need not be executed within the same memory space or even on the
same machine. With this architecture, the calling module becomes the “client”
(that which requests a service) and the called module becomes the “server” (that
which provides the service)
Another important component of client-server computing is connectivity, which
allows applications to communicate transparently with other programs or
processes, regardless of their locations. The key element of connectivity is the
network operating system (NOS), also known as middleware . The NOS provides
services such as routing, distribution, messages, filing and printing, and network
management.

Client Process
The client is a process (program) that sends a message to a server process
(program) requesting that the server perform a task (service).

Client programs usually manage the user interface portion of the application,
validate data entered by the user, dispatch requests to server programs, and
sometimes execute business logic.

The business layer contains all the objects that represent the business (real objects)
such as Order, Customer, Inventory. The client-based processes is the front-end of
the application, which the user sees and interacts with. The client process contains
solution-specific logic and provides the interface between the user and the rest of
the application system.

A key component of a client workstation is the graphical user interface (GUI),

which normally is a part of the operating system (i.e. the Windows manager). It is
responsible for detecting user actions, managing the Windows on the display, and
displaying the data in the Windows.
Server Process
A server process (program)fulfills the client request by performing the task
requested. Server programs generally receive requests from client programs,
execute database retrieval and updates, manage data integrity, and dispatch
response to client requests. Sometimes, server programs execute common or
complex business logic. The server-based process “may” run on another machine
on the network. This server could be the host operating system or network file
server; the server then is provided both file system services and application
services. The server process acts as a software engine that manages shared
resources such as databases, printers, communication links or high-powered
processors. The server process performs the back-end task that are common to
similar applications.

More advanced forms of servers are database servers, transaction servers,

application servers, and more recently object servers. With database servers, clients
pass SQL requests as messages to the server and the results of the query are
returned over the network. Both the code that processes the SQL requests and the
data reside on the server,allowing it to use its own processing power to find the
requested data. This is in contrast to the file server, which requires passing all the
records back to the client and then letting the client find its own data.

With transaction servers, clients invoke remote procedures that reside on servers,
which also contain an SQL database engine. The server has procedural statements
to execute a group of SQL statements (transactions), which either all succeed or
fail as a unit.The server has procedural statements to execute a group of SQL
statements (transactions), which either all succeed or fail as a unit.
The application based on transaction servers, handled by on-line transaction
processing (OLTP), tend to be mission-critical applications that always require a 1-
3 seconds response time and tight control over the security and the integrity of the
database.

Interaction Between the client-server

A typical client-server application consists of the following components:
1. User interface. This major component of the client-server application interacts
with users, screens, windows, windows management, keyboard and mouse
handling.
2. Business Processing. This part of the application uses the user interface data to
perform business tasks.
3. Database Processing. This part of the application code manipulates data within
the application. The data are managed by a database management system, object
oriented or not. Data manipulation is done using a data manipulation language,
such as SQL.

Distributed and Cooperative Processing

Distributed Processing means distribution of applications and business logic
across multiple processing platforms. Distributed processing implies that
processing will occur on more than one processor in order for a transaction to
be completed. In other words, processing is distributed across two or more
machines, where each process performs part of an application in a sequence.

Example, in processing an order from a client, the client information may

process at one machine and the account information then may process on a
different machine.
Cooperative processing is computing that requires two or more distinct
processors to complete a single transaction. Cooperative processing is related
to both distributed and client-server processing. Cooperative processing is a
form of distributed computing in which two or more distinct processes are
required to complete a single business transaction. Usually, these programs
interact and execute concurrently on different processors.

Cooperative processing also can be considered to be a style of distributed

processing, if communication between processors is performed through a message-
passing architecture.

Distributed Object Computing

Distributed object Computing(DOC) promises the most flexible client-server
system, because it utilizes reusable software components that can roam anywhere
on networks, run on different platforms, communicate with legacy applications by
means of object wrappers.

Distributed objects are reusable software components that can be distributed and
accessed by users across the network. These objects can be assembled into
distributed applications. Distributed object computing introduces a higher level of
abstraction into the world of distributed applications. Applications no longer
consists of clients and servers but users, objects and methods. The user no longer
needs to know which server process performs a given function. All information
about the function is hidden inside the encapsulated object. A message requesting
an operation is sent to the object, and the appropriate method is invoked.
Distributed object computing resulted form the need to integrated mission-critical
applications and data residing on systems that are geographically remote,
sometimes from users and often from each other, and running on many different
hardware platforms. The business have had to integrate applications and data by
writing custom interfaces between systems, forcing develops to spend their time
building and maintaining an infrastructure rather than adding new business
functionality.
Object-relational systems
The object-oriented development creates a fundamental mismatch between the
programming model (objects) and the way in which existing data are stored
(relational tables).

To resolve the mismatch, a mapping tool between the application objects and the
relational data must be established. Creating an object model from an existing
relational database layout (schema) often is referred to as reverse engineering.
Conversely, creating a relational schema from an existing object model often is
referred to as forward engineering.

Tools that can be used to establish the object-relational mapping processes have
begun to emerge. The main process in relational and object integration is
defining the relationships between the table structures (represented as schemata)
in the relational database with classes (representing classes) in the object model.
Example Sun Java Blend allows the developer access to relational data as java
objects, thus avoiding the mismatch between the relational and object data
model.
 Object- Relation Mapping
In a relational database, the schema is made up of tables, consisting of rows and
columns, where each column has a name and a simple data type. In an object
model, a table is a class, which has a set of attributes (properties or data
members). Object classes describe behavior with methods.

A tuple (row) of a table contains data for a single entity that correlates to an
object (instance of a class) in an object –oriented system. In addition, a stored
procedure in a relation database may correlate to a method in an object-oriented
architecture. A stored procedure is a module of precompiled SQL code
maintained within the database that executes on the server to enforce rules the
business has set about the data.

Therefore, the mapping essential to object and relational integration are between
a table and a class, between columns and attributes, between a row and an
object, and between a stored procedure and a method.

The relational data maps to and from application objects, it must have at least
the following mapping capabilities.

Table-class mapping
Table-multiple classes mapping
Table-inherited classes mapping
Tables- inherited classes mapping.

The tool must describe both how the foreign key can be used to navigate among
classes and instances in the mapped object model and how referential integrity is
maintained. Referential integrity means making sure that a dependent table’s
foreign key contains a value that refers to an existing valid tuple in another
relation.

Table-Class Mapping
Table-Class mapping is a simple one-to-one mapping of a table to a class and the
mapping of columns in a table to properties in a class. In this mapping, a single
table is mapped to a single class.

Table-multiple classes mapping

In the table-multiple classes mapping, a single table maps to multiple noninheriting
classes. Two or more distinct, noninheriting classes have properties that are
mapped to columns in a single table. At run time, a mapped table row is accessed
as an instance of one of the classes, based on a column value in the table.
Table – Inherited Classes Mapping
In table-inherited classes mapping, a single table maps to many classes that have a
common superclass. This mapping allows the user to specify the columns to be
shared among the related classes. The superclass may be either abstract or
instantiated.
Tables – Inherited classes Mapping
Another approach here is table-inherited classes mapping, which allows the
translation of is a relationships that exist among tables in the relational schema into
class inheritance relationships in the object model. In a relational database, an is-a
relationship often is modeled by a primary key that acts as a foreign key to another
table. In the object-model, is a is another term for an inheritance relationship.

OODBMS
 • It is marriage of object oriented programming and database technology.
The defined operations apply universally and are not dependent on the
particular database application running at the moment.

• The data types can be extended to support complex data such as multimedia
by defining new object classes that have operations to support new kinds of
information.

• It should have object-oriented language properties and database

requirements.

Rules to make object-oriented system

• The system must support complex objects.

• Object identity must be supported

• Objects must be encapsulated

• System must support types or classes

• System must support inheritance

• System must avoid premature binding

• System must be computationally complete

• System must be extensible

• It must be persistent, able to remember an object state

• It must be able to manage large databases

• It must accept concurrent users

• Data query must be simple

• The system must support complex objects. System must provide simple
atomic types of objects (integers, characters, etc) from which complex
objects can be built by applying constructors to atomic objects.
• Object identity must be supported: A data object must have an identity and
existence independent of its values.

• Objects must be encapsulated: An object must encapsulate both a program

and its data.

• System must support types or classes: The system must support either the
type concept or class concept

• System must support inheritance: Classes and types can participate in a

class hierarchy. Inheritance factors out shared code and interfaces.

• System must avoid premature binding: This is also known as late binding or
dynamic binding. It shows that the same method name can be used in
different classes. The system must resolve conflicts in operation names at
run time.

• System must be computationally complete: Any computable function should

be expressible in DML of the system, allowing expression of any type of
operation.

• System must be extensible: The user of the system should be able to create
new types that have equal status to the system’s predefined types.

• It must be persistent, able to remember an object state: System must allow

the programmer to have data survive beyond the execution of the creating
process for it to be reused in another process.

• It must be able to manage large databases: System must manage access to

the secondary storage and provide performance features such as indexing,
clustering, buffering and query optimization.

• It must accept concurrent users: System must allow multiple concurrent

users and support notions of atomic, serializable transactions ,must be able
to recover from hardware and software failures

• Data query must be simple: System must provide some high-level

mechanism for ad-hoc browsing of the contents of the database.
Object oriented databases versus Traditional Databases

The responsibility of an OODBMS includes definition of the object

structures, object manipulation and recovery, which is the ability to maintain
data integrity regardless of system, network or media failure.

The OODBMs like DBMSs must allow for sharing; secure, concurrent
multiuser access; and efficient, reliable system performance.

The objects are an “active” component in an object-oriented database, in

contrast to conventional database systems, where records play a passive role.
Another feature of object-oriented database is inheritance. Relational
databases do not explicitly provide inheritance of attributes and methods.

The objects are an active component in an object-oriented database, in

contrast to conventional database systems, where records play a passive role.

The relational database systems do not explicitly provide inheritance of

attributes and methods while object-oriented databases represent
relationships explicitly (openly, clearly). (improvement in data access
performance )

Object oriented databases also differ from the traditional relational databases
in that they allow representation and storage of data in the form of objects.
(each object has its own identity or object-ID

Object Identity

Object oriented databases allow representation and storage of data in the form
of objects.

Each object has its own identity or object-ID (as opposed to the purely value-
oriented approach of traditional databases).

The object identity is independent of the state of the object.

Multidatabase Systems

• A different approach for integration object-oriented applications with

relational data environments is multidatabase systems or heterogeneous
database systems, which facilitate the integration of heterogeneous
databases and other information sources.

• Heterogeneous information systems facilitate the integration of

heterogeneous information sources, where they can be structured
(having regular schema), semi-structured and sometimes even
unstructured. Some heterogeneous information systems are constructed
on a global schema over several databases. So users can have the
benefits of a database with a schema to access data stored in different
databases and cross database functionality. Such heterogeneous
information systems are referred to as federated multidatabase systems.

• Federated multidatabase systems provide uniform access to data stored

in multiple databases that involve several different data models.

• A multidatabase system (MDBS) is a database system that resides

unobtrusively on top of, existing relational and object databases and file
systems (local database systems) and presents a single database illusion
to its users.
• The MDBS maintains a single global database schema and local
database systems maintain all user data.

• The schematic differences among local databases are handled by

neutralization (homogenization), the process of consolidating the local
schemata.

• The MDBS translates the global queries and updates for dispatch to the
appropriate local database system for actual processing, merges the
results from them and generates the final result for the user.

• MDBS coordinates the committing and aborting of global transactions

by the local database systems that processed them to maintain the
consistency of the data within the local databases.

• An MDBS controls multiple gateways (or drivers). It manages local

databases through gateways, one gateway for each local database.

• Open Data Base Connective (ODBC) is an application programming

interface that provides solutions to the multidatabase programming
problem. It provides a vendor-neutral mechanism for independently
accessing multiple database hosts.

• ODBC and other APIs provide standard database access through a

common client-side interface. It avoids the burden of learning multiple
database APIs. Here one can store data for various applications or data
from different sources in any database and transparently access or
combing the data on an as needed basis. Details of back-end data
structure are hidden from the user.
ODBC

• ODBC is similar to Windows print model, where the application

developer writes to a generic printer interface and a loadable driver
maps that logic to hardware-specific commands.

• This approach virtualizes the target printer or DBMS because the

person with the specialized knowledge to make the application logic
work with the printer or database is the driver developer and not the
application programmer.

• The application interacts with the ODBC driver manager, which sends
the application calls (such as SQL statements) to the database.

• The driver manager loads and unloads drivers, perform status checks
and manages multiple connections between applications and data
sources.

Designing Access Layer Classes

• The main idea behind creating an access layer is to create a set of classes
that know how to communicate with the place(s) where the data
actually reside. Regardless of where the data reside, whether it be a file,
relational database, mainframe, Internet, DCOM or via ORB, the access
classes must be able to translate any data-related requests from the
business layer into the appropriate protocol for data access.
 • These classes also must be able to translate the data retrieved back into
the appropriate business objects.

• The access layer’s main responsibility is to provide a link between

business or view objects and data storage.

• Three-layer architecture is similar to 3-tier architecture. The view layer

corresponds to the client tier, the business layer to the application
server tier and the access layer performs two major tasks:

Access Layer tasks

• Translate the request: The access layer must be able to translate any
data related requests from the business layer into the appropriate
protocol for data access.

• Translate the results: The access layer also must be able to translate the
data retrieved back into the appropriate business objects and pass those
objects back into the business layer.

Advantage of this approach

• Here design is tied to any base engine or distributed object technology

such as CORBA or DCOM. Here we can switch easily from one
database to another with no major changes to the user interface or
business layer objects. All we need to change are the access classes’
methods.

• The access layer design process consists of the following activities:

• If a class interacts with nonhuman actor such as another system,

database or the web , then the class automatically should become an
access class.

Design the access layer (approach-1)

(1) For every business class identified ,mirror the business class package.: For
every business class identified and created, create one access class in the
access layer package.
 Eg , if there are 3 business classes (class1, class2 and class3), create 3
access layer classes (class1DB, class2DB and class3DB)

(2) Identify access layer class relationships (or) define the relationships.

Simplify classes and their relationships – main goal is to eliminate redundant

classes and structures

– Redundant classes: Do not keep 2 classes that perform

similar translate request and translate results
activities. Select one and eliminate the other.

– Method classes: Revisit the classes that consist of only

one or two methods to see if they can be eliminated or
combined with existing classes.

• Iterate and refine again.

(3)Simplify classes and their relationships – main goal is to eliminate

redundant classes and structures.Inmost cases , combine simple access
class and simplify the super and subclass structures

– Redundant classes: Do not keep 2 classes that perform

similar translate request and translate results
activities. Select one and eliminate the other.

– Method classes: Revisit the classes that consist of only

one or two methods to see if they can be eliminated or
combined with existing classes.

(4) Iterate and refine again.

In this process, the access layer classes are assumed to store not only the
attributes but also the methods.This can be done by utilizing an OODBMS
OR Relational data base
Design the access layer process (approach-2)

• Let methods to be stored in a program (eg: a compiled c++ program

stored on a file) and store not only the persistent attributes

• (1) For every business class identified determine if class has persistent
data.An attribute can be either transient or persistent (non transient )

(2) For every business class identified ,mirror the business class package.: For
every business class identified and created, create one access class in the
access layer package.

Eg , if there are 3 business classes (class1, class2 and class3), create 3

access layer classes (class1DB, class2DB and class3DB)

(3) Identify access layer class relationships (or) define the relationships.

(4)Simplify classes and their relationships – main goal is to eliminate

redundant classes and structures.Inmost cases , combine simple access class
and simplify the super and subclass structures

– Redundant classes: Do not keep 2 classes that perform

similar translate request and translate results
activities. Select one and eliminate the other.

– Method classes: Revisit the classes that consist of only

one or two methods to see if they can be eliminated or
combined with existing classes.

(5) Iterate and refine again.

APPROACH(1)
SUMMARY

A package groups and manages the modeling elements, such as classes,

their associations, and their structures. Packages themselves may be nested within
other packages. A package may contain both other packages and ordinary model
elements. The entire system description can be thought of as a single high-level
sub-system package with everything else init. All kinds of UML model elements
and diagrams can be organized into packages. Persistence refers to the ability of
some objects to outlive the programs that created them. The persistent data are
those data that exist beyond the lifetime of the creating process. Some categories of
persistent data are:

◊ Data that exist between the executions of a program.

◊ Data that exist between the versions of a program.

◊ Data that outlive a program.

Essential elements in providing a persistent store are:

◊ Identification of persistent objects or reachability

◊ Properties of objects and their interconnections.

◊ Scale of the object store.

◊ Stability.

Schema or meta-data contains a complete definition of the data formats,

such as the data structures, types and constraints. The meta-data are usually
encapsulated in the application programs themselves. In DBMS, the format of the
meta-data is independent of any particular application data structure; therefore it
will provide a generic storage management mechanism. A concurrency control
policy dictates what happens when conflicts arise between transactions that attempt
access to the same object and how these conflicts are to be resolved. There are two
policies,

◊ Conservative or pessimistic policy

Allows a user to lock all objects or records when they are accessed
 and to release the locks only after a transaction commits.

◊ Optimistic policy

Two conflicting transactions are compared in their entirety and

then their serial ordering is determined.

A database model is a collection of logical constructs used to represent the

data structure and data relationships within the database. The different database
models are,

Hierarchical model
Network model
Relational model
KEY TERMS

Data definition language(DDL)

Data base management system (DBMS)

ODBC

Multi database system (MDBS)

Homogenization

Common object request broker architecture (CORBA)

Distributed object computing (DOC)

Cooperative processing

KEY TERM QUIZ

1. Open database connectivity (ODBC) is an application programming

interface that provides solutions to the multidatabase programming problem.
2. A multi database system (MDBS) is database systems that resides
unobtrusively on top of existing relational and object databases, and file
systems and presents a single database illusion to its users.
3. Neutralization also called homogenization is the process of consolidating
the local schemata.
4. Common object request broker architecture (CORBA) is a standard
 proposed as a means to integrate distributed heterogeneous business
applications and data.
5. Distributed object computing (DOC) utilizes reusable software
components that can roam anywhere on networks, run on different
platforms, communicate with legacy applications by means of object
wrappers, and manage themselves and the resources thy control.
6. Cooperative processing is computing that requires two or more distinct
processors to complete a single transaction.
7. Data definition language (DDL) is the language used to describe the
structure of and relationships between objects stored in a database.
8. DBMS is a set of programs that enables the creation and maintenance of a
collection of related data
9. Open database connectivity (ODBC) is an application programming
interface that provides solutions to the multidatabase programming problem.
10. A multi database system (MDBS) is database systems that resides
unobtrusively on top of existing relational and object databases, and file
systems and presents a single database illusion to its users.
11. Neutralization also called homogenization is the process of consolidating
the local schemata.
12. Common object request broker architecture (CORBA) is a standard
proposed as a means to integrate distributed heterogeneous business
applications and data.
13. Distributed object computing (DOC) utilizes reusable software
components that can roam anywhere on networks, run on different
platforms, communicate with legacy applications by means of object
wrappers, and manage themselves and the resources thy control.
14. Cooperative processing is computing that requires two or more distinct
processors to complete a single transaction.
15. Data definition language (DDL) is the language used to describe the
structure of and relationships between objects stored in a database.
16. DBMS is a set of programs that enables the creation and maintenance of a
collection of related data

MULTIPLE CHOICE

1. Open database connectivity (ODBC) is an application programming

interface that provides solutions to the multidatabase programming problem.
a. Open database connectivity (b) multi database system
 2. A multi database system (MDBS) is database systems that resides
unobtrusively on top of existing relational and object databases, and file
systems and presents a single database illusion to its users.
a. Open database connectivity (b) multi database system

3. Neutralization also called homogenization is the process of consolidating

the local schemata.
(a) Open database connectivity (b) multi database system (c) homogenization

4. Common object request broker architecture (CORBA) is a standard

proposed as a means to integrate distributed heterogeneous business
applications and data.
(a) Common object request broker architecture (b) multi database system

(c) homogenization

5. Distributed object computing (DOC) utilizes reusable software

components that can roam anywhere on networks, run on different
platforms, communicate with legacy applications by means of object
wrappers, and manage themselves and the resources thy control.
(a) Common object request broker architecture (b) Distributed object

computing (DOC) (c) homogenization

6. Cooperative processing is computing that requires two or more distinct

processors to complete a single transaction.
a. Cooperative processing (b) Data definition language
7. Data definition language (DDL) is the language used to describe the
structure of and relationships between objects stored in a database.
a. Cooperative processing (b) Data definition language
8. DBMS is a set of programs that enables the creation and maintenance of a
collection of related data
(a) Cooperative processing (b) Data definition language (c) DBMS

REVIEW QUESTIONS

1. Differentiate between transient data and persistent data? (Pg 238)

2. What is a DBMS? (Pg 239)
3. What is a relational database? Explain tuple, primary key and foreign key
(Pg 241)
4. What is a database schema? Differentiate between schema and meta-data
(Pg 242)
5. What is a DDL? (Pg 242)
6. What is a distributed database? (Pg 245)
7. What is concurrency control? (Pg 244)
8. Define shareability (Pg 243)
9. What is a transaction? (Pg 244)
10. What is concurrency policy? (Pg 244)
11. What is a query? (Pg 242)
12. Define client-server computing (Pg 245)
13. Name the different types of servers. Briefly describe each (Pg 246)
14. Why is DOC so important in the computing world? (Pg 250)
15. Describe CORBA, ORB and DCOM (Pg 251, 252)
16. What is an OODBMS? Differentiate between an OODBMS and object-
oriented programming (Pg 252, 254)
17. Differentiate between forward and reverse engineering (Pg 255)
18. Describe a federated multidatabase system (Pg 261)
19. Describe the process of creating the access layer classes (Pg 264)
20. Define object store and persistence (Pg 238)

 References :
 Object Oriented Analysis and Design using UML, by Rational

Software Corporation (2002)

 Bahrami, A.(1999). Object Oriented Systems Development,

using the unified modeling language, McGraw-Hill

 UNIT-V

SOFTWARE QUALITY AND USABILITY

CHAPTER 12

VIEW LAYER: Designing Interface Objects

OBJECTIVES :

At the end of this chapter, students should be able to

Identifying View (or User interface ) classes

Designing Interface objects

Prototyping the interface objects

INTRODUCTION

o Main goal of a user interface (UI) is to display & obtain needed

information in an accessible, efficient manner.
o A well-designed UI has visual appeal that motivates users to use yr
application.
o A graphical user interface (GUI) uses icons to represent objects, a
pointing device to select operations, and graphic imagery to
represent relationships

 Designing View Layer Classes

View layer objects or interface objects  the only exposed objects of

an application with which users can interact
They are objects that represent the set of operations in the business
that users must perform to complete their tasks
 View layer objects responsible for 2 major aspects of the application :
 1. Input  responding to user interaction. The UI must be
designed to translate an action by the user
 2. Output  displaying or printing business objects. This layer
must paint the best picture possible of the business objects for
the user

The process of designing view layer :

1. The macro level UI design process – identifying

view layer objects ( identify classes that interact
with human actors by analyzing the use-cases,
sequence/collaboration diagram )
2. Micro level UI design activities :
2.1 Designing the view layer objects by
applying design axioms and corollaries
2.2 Prototyping the view layer interface
3. Testing usability and user satisfaction
4. Refining and iterating the design

 Macro-Level Proces : Identifying View Classes

The view layer macro process consists of 2 steps :

  1. for every class identified, determine if the class interacts with

a human actor. If so, perform the following ; otherwise, move

to the next class

1.1 identify the view(interface) objects for the class.

Zoom in on the view objects by utilizing

sequence/collaboration diagrams to identify the interface

objects, their responsibilities, and the requirements for

this class

1.2 define the relationships among the view (interface)

objects.

 2. Iterate and refine

Designing View Layer Classes

Three Layer architecture used for software development, namely Access

layer, view layer and user-interface / business layer.

The separation of the view layer from the business and access layers is that,
when you design of UI objects, you have to think more explicitly about
distinctions between objects that are useful to users.

View layer classes or interface objects are objects that represent the set of
operations in the business that users must perform to complete their tasks, ideally
in a way they find natural, easy to remember, and useful.

Any objects that have direct contact with the outside world are visible in
interface objects.
The view layer objects are responsible for two major aspects of applications:

1. Input-responding to user interaction: The user interface must be designed

to translate an action by the user, such as clicking on a button or selecting
from a menu, into an appropriate response.
2. Output-displaying or printing business objects. This layer must paint the
best picture possible of the business objects for the user. In one interface,
this may mean entry fields and list boxes to display an order and its items. In
another, it may be a graph of the total price of a customer‟s orders.

The view layder classes is divided into four activities:

1. The macro level UI design process – identifying view layer objects. The
main objective of the macro process is to identify classes that interact with
human actors by analyzing the use cases developed in the analysis phase.

The each use case involves actors and the task they want the system to
do. These use cases should capture a complete, unambiguous, and consistent
picture of the interface requirements of the system.
In this phase, it is also need to address the issue of how the interface
must be implemented.
Sequence or collaboration diagrams can help by allowing us to zoom
in on the actor-system interaction and extrapolate interface classes that
interact with human actors; thus assisting us in identifying and gathering the
requirements for the view layer objects and designing them.

2 Micro level VI design activities:

2.1Designing the view layer objects by applying design axioms and
corollaries.
In designing view layer objects, decide how to use and extend the
components to support application-specific functions and provide the most
 usable interface.

2.2 Prototyping the view layer interface. After defining a design model,
prepare a prototype of some of the basic aspects of the design. Prototyping
is particularly useful early in the design process.

3. Testing usability and user satisfaction. "We must test the application to
make sure it meets the audience requirements. To ensure user satisfaction,
measure user satisfaction and its usability along the way as the UI design
takes form. Usability experts agree that usability evaluation should be part of
the development process rather than a post-mortem or forensic activity.

4. Refining and iterating the design

Macro-level process: identifying view classes by analyzing use cases

The interface object handles all communication with the actor but processes
no business rules or object storage activities. The interface object will operate as a
buffer between the user and the rest of the business objects.

For example, computing employee overtime is an example of a business

object service. However, the data entry for the employee overtime is an interface
object.
The interface object has a coordinating responsibility in the process, at least
responsibility for those tasks that come into direct contact with the use.
The view layer macro process consists of two steps:
1. For every class identified, determine if the class interacts with a human
actor.
1.1 identify the view (interface) objects for the class
1.2 Define the relationships among the view (interface) objects.
2. Iterate and refine
 The advantage of utilizing use cases in identifying and designing view layer
objects is that the focus centers on the user, and including users as part of the
planning and design is the best way to ensure accommodating them.

Once the interface objects have been identified, we must identify the basic
components or objects used in the user tasks and the behavior and the
characteristics that differentiate each kind of object, including the relationships of
interface objects to each other and to the user.

The interface object handles all communication with the user but does not
process any business rules; that will do by the business objects.

Effective interface design is more than just following a set of rules. It also
involves early planning of the interface and continued work through the software
development process. The process of designing the user interface involves
clarifying the specific needs of the application, identifying the use cases and
interface object and then devising a design that best meets users' needs.
 Relationship among view objects,
business objects, access objects

View objects

Business objects

Access objects

Micro-Level Process
The design of the view layer objects must be user driven or user centered.
A user-centered interface replicates the user‟s view of doing thins by
providing the outcomes users expect for any action.
The following is the process of designing view (interface) objects:
1. For every interface object identified in the macro UI design process, apply
micro-level UI design rules and corollaries to develop the UI.
2. Iterate and refine.
 Micro level design process

Apply micro level UI

design rules and GUI
guidelines to each
interface object identified
to develop the UI

Next interface
objects refine
and iterate

Done

UI design Rule 1. Making the interface simple

(Application of Corollary 2)
The user interface should be so simple that users are unaware of the tools and
mechanism that make the application work. As applications become more
complicated, user must have an even simpler interface, so they can learn new
applications more easily.
This rule is an application of Corollary 2 (Single purpose) in UI deign.
It means that each UI class must have a single, clearly defined purpose. Similarly,
when you document, you should be able easily to describe the purpose of the UI
class with a few sentences.

UI Design Rule 2. Making the Interface Transparent and Natural

(Application of Corollary 4)
The user interface should be so intuitive and natural that users can anticipate
what to do next by applying their previous knowledge of doing tasks without a
computer. An application, therefore, should reflect a real-world model of the user‟s
goals and the tasks necessary to reach those goals.

The second UI rule is an application of Corollary 4 (Strong Mapping) in UI

design. Here, this corollary implies that there should be strong mapping between
the user‟s view of doing things and UI classes.

A metaphor, or analogy, relates two otherwise unrelated things by using one

to denote the other, such as question Mark (?) to label a help button.

This principle also applies to UI design. Using metapors is a way to develop

the user‟s conceptual model of an application. Familiar metaphors can assist the
users to transfer their previous knowledge from their work environment to the
application interface and create a strong mapping between the user‟s view and the
UI objects.

Of ten an application design is based on a single metaphor. For example,

billing, insurance, inventory and banking applications can represent forms that are
visually equivalent to the paper forms users are familiar to seeing.

A goal of user interface design is to make the user interaction with the
computer as simple and natural as possible.

UI design Rule 3. Allowing Users to be in Control of the software

(Application of Corollary 1)
The users always should feel in control of the software, rather than felling
controlled by the software.

The second implication is that users, because of their widely varying skills
and preferences, must be able to customize aspects of the interface. The software
should reflect user settings for different system properties such as color, fonts or
other options.

The final implication is that the software should be as interactive and

responsive as possible. Avoid modes whenever possible.

A mode is a state that limits the user to specific interactions. There are
situations in which modes are useful; for example, selecting a file name before
opening it. The main idea here is to avoid creating a single UI class for several
business objects, since it makes the UI less flexible and forces the user to perform
tasks in a massive way.

Some of the ways to put users in control are:

Make the interface forgiving
Make the interface visual
Provide immediate feedback
Avoid modes
Make the interface consistent.

Make the Interface Forgiving:

The user‟s actions should be easily reversed. They should be able to back up
or undo previous actions. An effective interface allows for interactive discovery.
Actions that are destructive and may cause the unexpected loss of data should
require a confirmation or better should be reversible or recoverable.

Even within the best designed interface, users can make mistakes. These
mistakes can be both physical (accidentally pointing to the wrong command or
data) and mental (making a wrong decision about which command or data to
select).
An effective design avoids situations that are likely to result in errors.

Users feel more comfortable with a system when their mistakes do not cause
serious or irreversible results.

Make the interface Visual. Deign the interface so users can see, rather than recall,
how to proceed.
Provide Immediate Feedback. Users should never press a key or select an action
without receiving immediate visual or audible feedback or both.
For example, the color, emphasis, and selection indicators show users they can
select that choice.

Avoid Modes. Modes force users to focus on the way an application works,
instead of on the task they want to complete. Modes, therefore, interfere with
user‟s ability to use their conceptual model of how the application should work. It
is not always possible to design a modeless application.

The method for ending the mode should be easy to learn and remember.

There are some of the modes that can be used in the user interface:

Modal dialog: Sometimes an application needs information to continue, such as

the name of a file into which users want to save something. When an error occurs,
users may be required to perform an action before they continue their task.

Spring-loaded modes: Users are in a spring-loaded mode when they continually

must take some action to remain in that mode; for example, dragging the mouse
with a mouse button pressed to highlighted a portion of text. In this case, the visual
cue for the mode is the highlighting. For example Cut and paste text

Tool-driven modes: If you are in a drawing application, you may be able to choose
a tool, such as a pencil or a paintbrush for drawing. After you select the tool, the
mouse pointer shape changes to match the selected tool.

Make the Interface Consistent Consistency is one way to develop and reinforce
the user‟s conceptual model of applications and give the user the feeling that he or
she is in control, since the user can predict the behavior of the system. User
interface should be consistent throughout the applications.

The purpose of a View Layer Interface

Each window should serve a clear, specific purpose. Windows commonly used
for:
Forms and data entry windows
It provide access to data that user can retrieve, display and change in
application.
Application windows (main windows)
It is container of application object or icons. It contains an entire
 application with which users can interact.

Guidelines for Designing Forms and Data Entry Windows

What kind of information will users work with and why? For example, a user
might want to change inventory information, enter orders, or maintain prices for
stock items.

Do users need access to all the information in a table or just some information? –
use a query that selects the rows and columns users want.

In what order do users want rows to appear? For example, users might want to
change inventory information stored alphabetically, chronologically or by
inventory number.

Typical data entry tasks include the following:

Navigating rows in a table, such as moving forward and backward and moving
first and last record
Adding and deleting rows
Changing data in rows
Saving and abandoning changes.

Guidelines for Designing Dialog boxes and Error Messages

A dialog box provides an dialog between the user and the application.
Because dialog boxes generally appear after a particular menu item or a command
button.

If the dialog box is for an error message, use the following guidelines:
Your error message should be positive. For example instead of displaying “you
have typed an illegal data format” display the message “Enter date format
mm/dd/yy”.

The error message should be constructive. For example, avoid messages

such as “You should know better! Use the OK button”; instead display “Press the
Undo button and try again”.

Guidelines for Designing Application Windows

A typical application window consists of a frame (or border) that defines its
extent and a title bar that identifies what is being viewed in the window. If the
viewable content of the window exceeds the current size of the window, scroll bars
are used. The windows also can include other components like menu bars, toolbars
and status bars. An application window usually contains common drop-down
menus.

The File menu: It provides an interface for the primary operations that apply a file
such as open, Save, Save As… and Print.

The Edit Menu : Include general purpose editing commands on the Edit menu.
These commands include the Cut, Copy and Paste commands and also includes
Undo, Find, Delete command.

The View Menu and other command Menus: Commands on the View menu should
change the user‟s view of data in the Window. For example Zoom or Outline,
Show Ruler.

The Window Menu: use the window menu in multiple document, interface style
applications for managing the windows within the main workspace.

The Help menu: It contains commands that provide access to Help information.
Such as Help Topic command – Contents, Index and Find Topic.

Toolbars and Status Bars : It is special interface constructs for managing sets of
controls. A toolbar is a panel that contains a set of controls.

A status bar is a special area within a window, typically at the bottom, that displays
information such as current state such as keyboard state.

Guidelines for Using colors

For all objects on a window, use colors to add visual appeal to the form. Text
must be readable at all times: black is the standard color. Associate meanings to the
colors of your interface. For example, use blue for all the uneditable fields, green
to indicate fields that will update dynamically, and red to indicate error conditions.
Ensure color consistency from screen to screen and make sure the users know what
these various colors indicate.

 Use identical or similar colors to indicate related information. For example,

savings account fields might appear in one color.
 • For an object background, use a contrasting but complementary color. Make
sure that the background color contrasts with the date color so that the user
can easily read data in the field.
• Use bright colors to call attention to certain elements on the screen.
• Use colors consistently within each window and among all windows in the
application. For example, the colors for push buttons should be the same
throughout.
• Don‟t use too many colors, it will be visually distract the application and
make less interesting
• Allow the user to modify the color configuration of the application.

Guidelines for Using Fonts

Most commercial applications use 12-point System font for menus and 10-point
System font in dialog boxes. The most preferable font is Times New Roman.
• Use commonly installed fonts, not specialized fonts that users might not
have on their machines.
• Use Bold for control labels, so they will remain legible when the object is
dimmed.
• Use fonts consistently within each from and among all forms in the
application
• Using too many font styles, sizes and colors can be visually distracting and
should be avoided.
• To emphasize text, increase its font size relative to other words on the form
or use a contrasting color.
 EXAMPLE : CASE STUDY  DESIGNING USER INTERFACE FOR THE
VIANET BANK ATM
VIEW LAYER MACRO PROCESS
 Determine if the class interacts with a human actor
 ATMMachine
 Identify the interface objects for the class(go thru the
sequence/collaboration diagram). Review the use cases that interact
directly with actors :
 Bank transaction, Checking transaction history, Deposit checking,
Deposit savings, Savings transaction history, Withdraw checking,
Withdraw savings, Valid/invalid PIN
based on these use-cases,  identified 8 view /interface objects.
 Define relationships among the view (interface objects)
8 view /interface objects are :
AccountTransactionUI, CeckingTransactionHistoryUI,
SavingsTransactionHistoryUI, BankClientAccessUI(for
validating a PIN code), DepositCheckingUI, DepositSavingsUI,
WithdrawCheckingUI, WithdrawSavingsUI
AccountTransactionUI

AccountTransactionUI

Relation between the

view class
AccountTransactionUI
and its associated
business class (account) Account
VIEW LAYER MICRO PROCESS
 Based on the outcome of macro process :
BankClientAccessUI
MainUI
AccountTransactionUI
CheckingAccountUI
SavingsAccountUI

 Apply micro-level UI design rules and collaries to develop UI

The AccountTransactionUI
 Iterate and refine
KEY TERMS

UI (USER INTERFACE)
Graphical user interface (GUI)

KEY TERM QUIZ

1. User interface (UI) is to display & obtain needed information in an
accessible, efficient manner.
2. A graphical user interface (GUI) uses icons to represent objects, a pointing
device to select operations, and graphic imagery to represent relationships
MULTIPLE CHOICE
1. User interface (UI) is to display & obtain needed information in an
accessible, efficient manner.
(a) User interface (UI) (b) graphical user interface (GUI)
2. A graphical user interface (GUI) uses icons to represent objects, a pointing
device to select operations, and graphic imagery to represent relationships
(a) User interface (UI) (b) graphical user interface (GUI)

REVIEW QUESTIONS:

1. Why is User interface one of the most important components of any

software? (Pg 281)
2. Compare GUI with OOUI (Pg 281-283)
3. Why is OOUI easier to use? (Pg 282)
4. How can use cases help us design the view layer objects? (Pg 284)
5. Describe the macro and micro processes of view layer design
(Pg 285;287)
6. How can metaphors be used in the design of a user interface?
(Pg 290)
7. Describe the UI design rules (Pg 288;290;292)
 CHAPTER-13

SOFTWARE QUALITY ASSURANCE

INTRODUCTION

Debugging is the process of finding out where something went wrong in the

application, what we develop and correcting the code to eliminate the errors or

bugs that cause unexpected results.

Error-based testing: This technique search a given class‟s method for

particular clues of interests, then describe how these clues should be tested.

Scenario-based testing/usage-based testing: It concentrates on what the

user does, not what the product does. This means capturing use cases and the tasks

users perform, then performing them and their variants as tests. They often are

more complex and realistic than error-based tests.

Scenario-based tests tend to exercise multiple subsystems in a single test,

because that is what users do.

Introduction
Testing is very important for developing and delivering robust system. It is also
important to examine collective behaviors to ensure maximum operational
reliability. Verify each component will behave correctly.

Debugging is the process of finding out where something went wrong and
correcting the code to eliminate the errors.

Kind of Errors
Language Error / Syntax error: Due to incorrectly constructed code, such as
incorrectly typed keyword or some necessary punctuation omitted.

Run-time errors occur and are detected as the program is running, when a
statement attempts an operation that is impossible to carry out. Ex: nonexistent
object, a file.

Logic errors occur when code might be syntactically valid and run without
performing any invalid operations and yet produce incorrect results. Logic errors
also can produce run-time errors.

Quality Assurance Testing

The elimination of the syntactical bug is the process of debugging, whereas the
detection and elimination of the logical bug is the process of testing.
Testing vs. Quality Assurance
• Quality Assurance
– Responsible for test plans and system testing
– Monitor testing during development
– Keep statistics
 • Testing is a necessary but insufficient part of a QA process
• QA addresses activities designed to
– prevent defects
– remove defects
• Testing helps in identifying problems and failures
• Testing helps QA by identifying them early.

Quality assurance testing can be divided into two major categories: error-based
testing and scenario-based testing

Error Based Testing

These techniques search a given class‟s method for particular clues of interests,
then describe how these clues should be tested
Ex: Payroll computation method of an Employee class:
anEmployee.computePayroll(hours). To test this method try different values for
hours (say, 40,0,100 and -10) and also test the boundary conditions.

Scenario based Testing

Scenario-based testing, also called usage-based testing., concentrates on what the
user does, not what the product does. This means capturing use cases and the tasks
users perform, then performing them and their variants as tests. These scenarios
also can identify interaction bugs.
Disadvantages : The tests will not find everything but they will cover at least the
higher visibility system interaction bugs.
Adv: This testing identifies the following:
An incorrect specification, the product doesn‟t do what the customer wants.
Interactions among subsystems, these are bugs where some action over there
sets up some state that crashes this subsystem over here.
TESTING STRATEGIES
The extent of testing a system is controlled by many factors, such as the risks
involved, limitations on resources and deadlines. There are many testing strategies
such as block box testing, white box testing, top down testing and bottom up
testing.
Black Box testing
In black box, the test item is treated as “black”, since its logic is unknown; all that
is known is what goes in and what comes out or the input and output. In black box
testing, you try various inputs and examine the resulting output; you can learn what
the box does but nothing about how this conversion is implemented.
White Box testing
The main use of the white box is in error-based testing, assumes that the specific
logic is important and must be tested to guarantee the system‟s proper functioning.
It is also called path testing, makes certain that each path in a object‟s method is
executed at least once during testing. Two types of path testing are
Statement testing coverage is to test every statement in the object‟s method by
executing it at least once. It is unfeasible to test a program on every single
input, so you never can be sure that a program will not fail on some input.
Branch testing coverage is to perform enough tests to ensure that every branch
alternative has been executed at least once under some test.
Top-Down testing
Top-Down testing assumes that the object interaction and systems messes of the
application need more testing than an individual object‟s methods.
Top-down testing should find critical design errors early in the testing process
and significantly improve the quality of the delivered software because of the
iterative nature of the test.
A top-down strategy supports testing the user interface and event-driven
systems
 This serves two purposes, First, top-down approach can test the navigation
through screens and verify that it matches the requirements.

Second, users can see, at an early stage, how the final application will look and
feel. This approach also is useful for scenario-based testing.
Top-down testing is useful to test subsystem and system integration.
Bottom-Up testing
Bottom-up testing starts with the details of the system and proceeds to higher
levels by a progressive aggregation of details until they collectively fit the
requirements for the system.
This approach is more appropriate for testing the individual objects in a system.
This strategy makes sense because you are checking the behavior of a piece of
code before it is used by another.
Bottom-up testing leads to integration testing, which leads to systems testing.

Impact of Inheritance in Testing

The base class contains methods inherited() and
redefined(). The derived class redefines the redefined()
method.
The derived::redefined has to be tested afresh since it is a new code.
If the base::inherited has been changed, the derived::inherited() may not have to be
completely tested.
Where it does depend on the base methods: otherwise it must be tested again.

Reusability of Tests
If base ::redefined() and two different methods with different protocols and
implementations, each needs a different set of test requirements derived from the
use cases, analysis, design or implementation.
You need to write new tests only for those derived::redefined requirements not
satisfied by the base::redefined tests.
The models developed for analysis and design should be used for testing as well.
For example, the class diagram describes relationships between objects; that is an
object of one class may user or contain an object of another class, which is useful
information for testing.
Furthermore, the use-case diagram and the highest level class diagrams can benefit
the scenario-based testing.
Since a class diagram shows the inheritance structure, which is important
information for error-based testing.
TEST PLAN
A test plan is developed to detect and identify potential problems before delivering
the software to its users.
A test plan offers a road map for testing activities, whether usability, user
satisfaction, or quality assurance tests. It should state the test objectives and how to
meet them.
1. Objectives of the test: create the objectives and describe how to achieve
them and if the objective is usability of the system.
2. Development of a test case: develop test data, both input and excepted
output, based on the domain of the data and the excepted behaviors that must
be tested
3. Test analysis involves the examination of the test output and the
documentation of
the test results. If bugs are detected, then this is reported and the activity
centers on debugging. After debugging, steps 1 through 3 must be repeated
until no bugs can be detected.
All passed tests should be repeated with the revised program, called regression
testing, which can discover errors introduced during the debugging process. When
sufficient
testing is believed to have been conducted, this fact should be reported, and testing
for this specific product is complete.
Most software companies also use beta testing, a popular in expensive, and
effective way to test software on a select group of the actual users of the system.
This is in contrast to alpha testing, where testing is done by inhouse testers, such as
programmers, software engineers, and internal users.

Guidelines for Developing Test plans

Thomas developed the guidelines for writing test plans:
• specify the format of your test plan
• try to include as much as detail as possible about the tests.
• The test plan should contain a schedule and a list of required
resources.
• Identify what types of testing are necessary such as black box testing,
white box testing
The level of test plan required

CONTINUOUS TESTING
A common practice among developers is to turn over applications to a quality
assurance (QA) group for testing only after development is completed. Testing the
whole system and detecting bugs is more difficult than testing smaller pieces of the
application as it is being developed. Testing must take place on a continuous basis,
and this refining cycle must continue throughout the development process until
satisfied with the results.

During this iterative process, prototypes will be transformed incrementally

into the actual application. The use cases and usage scenarios can become test
scenarios and therefore will drive the test plans.
SUMMARY

Debugging is the process of finding out where something went wrong in the
application, what we develop and correcting the code to eliminate the errors or
bugs that cause unexpected results. Error-based testing: This technique search a
given class‟s method for particular clues of interests, then describe how these clues
should be tested. Scenario-based testing/usage-based testing: It concentrates on
what the user does, not what the product does. This means capturing use cases and
the tasks users perform, then performing them and their variants as tests. They
often are more complex and realistic than error-based tests. Scenario-based tests
tend to exercise multiple subsystems in a single test, because that is what users do.
Testing becomes successful when the steps below are followed;
◊ Understand and communicate the business case for improved testing.
◊ Develop an internal infrastructure to support continuous testing.
◊ Look for leaders who will commit to and own the process.
◊ Measure and document your findings in a defect recording system.
◊ Publicize improvements as they are made and let people know what
they are doing better.

KEY TERMS
Black box testing
White- Box testing
Top- down Testing
Statement testing coverage
Branch testing coverage
White box testing
Path testing
Bottom - up Testing

KEY TERM QUIZ

1. In a Black box testing, the test item is treated as “black,” since its logic is
unknown; all that is known is what goes in and what comes out or input and
output. It may be used for Scenario- based testing.
2. White- Box testing assumes that the specific logic is important and must be
tested to guarantee the system‟s proper functioning. It is used mainly in the
error based testing.
3. Top- down Testing assumes that the main logic or object interactions and
systems messages of the application need more testing than an individual
object‟s methods or supporting logic. It can detect the serious design flaws
 early in the implementation.
4. The main idea of statement testing coverage is to test every statement in
the object„s method by executing it at least once.
5. The main idea behind branch testing coverage is to perform enough tests to
ensure that every branch alternative has been executed at least once under
some test.
6. Path testing is one form of white box testing.
7. Two types of Path testing are Statement testing coverage and Branch testing
coverage
8. Bottom - up Testing starts with the details of the system and proceeds to
higher levels by a progressive aggregation of details until they collectively
fit the requirements for the system.

MULTIPLE CHOICE
1. In a Black box testing, the test item is treated as “black,” since its logic is
unknown; all that is known is what goes in and what comes out or input and
output. It may be used for Scenario- based testing.
(a)Black box testing (b) White- Box testing (c) Top- down Testing

2. White- Box testing assumes that the specific logic is important and must be
tested to guarantee the system‟s proper functioning. It is used mainly in the
error based testing.
(a)Black box testing (b) White- Box testing (c) Top- down Testing

3. Top- down Testing assumes that the main logic or object interactions and
systems messages of the application need more testing than an individual
object‟s methods or supporting logic. It can detect the serious design flaws
early in the implementation.
(a)Black box testing (b) White- Box testing (c) Top- down Testing

4. The main idea of statement testing coverage is to test every statement in

the object„s method by executing it at least once.
(a)Statement testing coverage (b) Branch testing coverage(c) White box
Testing

5. The main idea behind branch testing coverage is to perform enough tests to
ensure that every branch alternative has been executed at least once under
some test.
(a)Statement testing coverage (b) Branch testing coverage(c) White box
 Testing

6. Path testing is one form of white box testing.

(a)Statement testing coverage (b) Branch testing coverage(c) White box
Testing

7. Two types of Path testing are Statement testing coverage and Branch testing
coverage
(a) Path testing (b) Bottom - up Testing

8. Bottom - up Testing starts with the details of the system and proceeds to
higher levels by a progressive aggregation of details until they collectively
fit the requirements for the system.

a) Path testing (b)Bottom - up Testing

REVIEW QUESTIONS
1. Describe the different testing strategies (Pg 328)
2. What is black box testing? (Pg 328)
3. When is white box testing used? (Pg 329)
4. If you do not know what is inside the box, how would you test it?
a. (Pg 328)
5. What is the importance of developing a test case? (Pg 332)
6. What is white box testing? (Pg 329)
7. What is path testing? (Pg 329)
8. What is statement testing coverage? (Pg 329)
9. What is branch testing coverage? (Pg 329)
10. Describe top-down and bottom-up strategies. Which do you prefer and why?
(Pg 329-330)
11. What is regression testing? (Pg 334)
12. What is a test plan? What steps are followed in developing a test plan? (Pg
333)
13. Define continuous testing (Pg 335)
14. State Myers‟s debugging principles (Pg 337)
a. (Bug locating principles and Debugging principles)
15. What are QA tests? (Pg 326)
16. What is an error? Name and explain the types of errors (Pg 327)
17. Differentiate between error-based and scenario-based testing
a. (Pg 327-328)
 CHAPTER-14

System Usability -Measuring User Satisfaction

INTRODUCTION:

Usability
ISO defines Usability as the effectiveness, efficiency, and satisfaction with
which a specified set of users can achieve a specified set of tasks in particular
environments. It requires,
◊ Defining tasks.
◊ Defining users
◊ A means for measuring effectiveness, efficiency, and satisfaction.

The issues in software quality

◊ Validation – user satisfaction
◊ Verification – Quality assurance

Usability testing
It measures the ease of use as well as the degree of comfort and satisfaction
users have with the software.

User satisfaction testing

It is the process of quantifying the usability test with some measurable
attributes of the test, such as functionality, cost, or ease of use.

Usability testing
• ISO defines usability as
– Effectiveness
– Efficiency
– Satisfaction
With which a specified set of users can achieve a set of tasks in
particular environments
• ISO requires
– Defining tasks
– Defining users
– A mean for measuring effectiveness, efficiency, satisfaction
Usability testing
• Definition
– Measures the ease of use as well as the degree of comfort and
satisfaction users have with the software
– Testing begins in the early stages of product development

OOA use case model

Quality User
Usability
assurance satisfaction
test cases
test cases test cases

Guidelines for Usability testing

• The usability testing should involve all software components
• Usability need not be more expensive or elaborate
• All tests need not involve many subjects
• Consider user’s experience as a part of your software usability
• Apply usability testing early and often.
Recording the usability test
• Provide comfortable location for participants
• Don’t interrupt participants
• Record the techniques and search patterns users employ when
attempting to work through a difficulty
• Record the time taken to perform a task, and problems faced by them
• Record the results using portable tape recorder or camera
• This is followed by user satisfaction test and questionnaire (feedback
form)

User satisfaction test

• Process of quantifying (calculate, measure) usability test with
measurable attributes of the test such as functionality , cost or ease of
use
– Ex: 90.5 of the people should know to withdraw money from
ATM without training or error

Objectives of User satisfaction test

• Used as communication vehicle between designers, and also between
users and designers
• To detect and evaluate changes during the design process
• To provide a periodic indication of divergence of opinion about current
design

Guidelines for developing user satisfaction test

• Must work with users or clients to find out what attributes should be
included in the test
• Limit the number of attributes
• some attributes are
– ease of use
– functionality
– Cost
– reliability

Tool for user satisfaction test

• Commercial Off the Shelf (COTS)
• User Satisfaction Test Spreadsheet (USTS)
GUIDELINES FOR DEVELOPING USER SATISFACTI0N TEST
The format of every user satisfaction test is basically the same, but its
content is different for each project.

A Custom Form For User Satisfaction

Test
How do you rate the customer tracking project at this time?
10 9 8 7 6 5 4 3 2 1
Ease of use Very Easy Very Hard
10 9 8 7 6 5 4 3 2 1
Very Functional Non Functional
Functionality
10 9 8 7 6 5 4 3 2 1
Cost Very Inexpensive Very Expensive

10 9 8 7 6 5 4 3 2 1
Intuitive UI Very Intuitive Very Hard to Follow
10 9 8 7 6 5 4 3 2 1
Reliability Very Reliable Not Reliable

Comments

I have more to say; I would like to see you

SUMMARY

Usability
ISO defines Usability as the effectiveness, efficiency, and satisfaction with
which a specified set of users can achieve a specified set of tasks in particular
environments. It requires,
◊ Defining tasks.
◊ Defining users
◊ A means for measuring effectiveness, efficiency, and satisfaction.

The issues in software quality

◊ Validation – user satisfaction
◊ Verification – Quality assurance
Usability testing
It measures the ease of use as well as the degree of comfort and satisfaction
users have with the software.

User satisfaction testing

It is the process of quantifying the usability test with some measurable
attributes of the test, such as functionality, cost, or ease of use.

KEY TERMS

Usability
Usability testing
User satisfaction testing

KEY TERMS QUIZ

1. ISO defines Usability as the effectiveness, efficiency, and satisfaction with

which a specified set of users can achieve a specified set of tasks in
particular environments.
2. Usability testing measures the ease of use as well as the degree of comfort
and satisfaction users have with the software.
3. User satisfaction testing is the process of quantifying the usability test with
some measurable attributes of the test, such as functionality, cost, or ease of
use.

MULTIPLE CHOICE
1. ISO defines Usability as the effectiveness, efficiency, and satisfaction with
which a specified set of users can achieve a specified set of tasks in
particular environments.
(a)Usability (b)Usability testing(c)User satisfaction testing

2. Usability testing measures the ease of use as well as the degree of comfort
and satisfaction users have with the software.
(a)Usability (b)Usability testing(c)User satisfaction testing

3. User satisfaction testing is the process of quantifying the usability test with
some measurable attributes of the test, such as functionality, cost, or ease of
use.
 (a)Usability (b)Usability testing(c)User satisfaction testing

REVIEW QUESTIONS

1. Differentiate between validation and verification

a. (Pg 341) (Chapter 3 – Pg 43)
2. What is quality? (Pg 341)
3. What is the need for usability testing? When do we use that?
a. (Pg 343)
4. Why do we need to apply usability testing early on? Why should we apply it
often? (Pg 343)
5. Name some of the techniques used in gathering usability information? (Pg
344)
6. Describe the ”Wizard of Oz” technique (Pg 344)
7. What is a user satisfaction test? (Pg 345)
8. Why do we need to measure user satisfaction? (Pg 346)
9. How do you develop a custom form for a user satisfaction test?
a. (Pg 347)
10. Give the significance of comments in a user satisfaction form?
a. (Pg 349)
11. List out steps in a user satisfaction test cycle (Pg 349)