OBJECT ORIENTED ANALYASIS AND DESIGN UNIT -I 1…anujsinha.weebly.com/uploads/3/7/2/7/37270669/11150h71_-_ooad.pdf · 1 OBJECT ORIENTED ANALYASIS AND DESIGN UNIT -I 1. INTRODUCTION

1

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.

2

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.

3

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,

4

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:

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.

Employee Class

Car

Cost

Color

Model

5

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:

Brake

*7

Computepayroll

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.

Car object

5 object

Employee

object

6

2.9 CLASS HIERARCHY:

Object oriented system organizes classes in to subclass-super class hierarchy.

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:

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

Motor Vehicle

Bus Truck Car

Vehicle

Car

Taurus Mustang Thunder bird

Ford

7

"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.

I know how to stop

Stop method is reusable

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.

Vehicle

Car

Taurus Mustang Thunder bird

Ford

8

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.

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.

Car Truck Bus

Motor Vehicle

Utility Vehicle

9

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”

Can fly flown by

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.

Request for Printing

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.

Pilot

c

Planes

Print Server Item

10

Example:

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.

Car

Engine Seat Wheel

11

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.

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

Car Instance (object)

Make: Saab

Color: red

Model:90os

Owner

Person Instance (object)

Name: Raj

Age: 30

Owns

Employee Name Address Salary

Office Worker

Data Entry Compute Payroll Print Report

Manager

Data Entry Compute Payroll Print Report

Production Worker

Data Entry Compute Payroll Print Report

12

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.

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

Shape

Draw ()

Circle Object

Draw (circle)

Box Object

Draw (box)

Triangle Object

Draw (Triangle)

13

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.

Transformation 1

Transformation 2

Transformation 3

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):

What are the uses

of the system?

Problem Statement Analysis

Design Implementation Detail

System Software Product

14

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:

(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.

How

What

Do It

Test

Use

15

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

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.

Requirements Needs Design Software

16

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.

Analysis

IIIiiiii

Fig 3.4: The OOSD Approach.

Analysis

Ana

Build a Use-Case

Model

Object

Analysis Validate

/Test

Implementation

Design

Using Tools CASE

&/ OO Programming

Languages

User Satisfaction

Usability & QA

Test

Design Classes,

Define Attributes

& Methods

Build Object

& Dynamic

Model

User Satisfaction

Test, Usability Test

& QA Test

Build User

Interface

&

Prototype

17

JACOBSON LIFE CYCLE MODEL:

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

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:

Use Case

Model

Object Interaction

Diagram, etc . Design

Classes

UI

18

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.

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. Create an Object Oriented Design.

4. Then do some more of each.

Tangible Object Intangible object

Pay Check Tables

Employee Data Entry

Worker Data Structures

Supervisor

Office administrator

Supervisor

19

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:

20

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.

Legacy Program Legacy Data

Open Connectivity

Legacy Screens Legacy software Package

Component Wrapper Component Wrapper

Component Wrapper

Component Wrapper

21

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.

22

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.

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

(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

First Name Account Account

Last Name Transaction

PinCode

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.

State Transition Diagram for the Bank Application user interface.

Client

First Name

Last Name

Pin Code

Account Number

Balance

Deposit

Withdraw Create Transaction

Transaction

Trans Date

Trans Time Trans Type Amount Post Balance

Checking Account

Withdraw

Saving Account

Account has been selected

Selected Checking

or savings account

Nothing is

selected

Select Checking

account

Select transaction

type (withdraw,

deposit, transfer)

Enter the

amount

Confirmation

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

Bank code

Account

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.

ATM Card

reader

User keyboard

entry

User screen selection

ATM DFD System architect Comment OMT data flow

Select bank

Select card

Verify password

Select account

Update account

User

Process Data store Data flow External entity

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

Super class

Inherits

Inherits

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

ortEscoEeE

E

Taurus

Mustang

Car Color

Manufacture cost

cost

Ford

Enable Disable

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.

Enabled

Sound Alarm

Silence Alarm

Silence d Soundin

g

Disabled

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

Member

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.

Checking out books

Getting an interlibrary loan

Reading books, newspapers

Purchasing supplies

Doing research

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

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.

OK

NOTOK

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

O-O Design

Continuous testing

Design Classes

their Attributes

Methods

Association

Structure

O-O Analysis

Develop use-case

Activity diagram

Prototyping

Develop

interaction

Diagram

Identify Classes

relationship

attributes

Refine

and

iterate

Continuous testing

Construction

Component Based Development

User satisfaction

usability tests, quality

Assurance test

Repository

Of use-case Design, UI and

past experiences

patter ns,

documentation

and traceability

Layered

Approach

UML Based

Modeling

Build UML class diagram

Apply design

Axiom

Design

view

And

access

layer and

prototypes

User

satisfaction

usability

tests based

on use case

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.

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.

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

OOA

OOA,OOD &

Prototyping Three Layered Approach

Data

Data

Access Layer

Business Layer

View Layer

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.

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.

Length: meter

Fuel capacity

:Gal

Door: int

Boeing 737

Boeing 737

Boeing 737

Length: meter

Fuelcapacity:Gal

Door: int

Lift()

Break()

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

employer employee

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

association relationship.

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

An association can show multiplicity:

• a fixed value (such as 1, 2, or 10) , *

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

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

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

multiplicity

OR Association

Company Person

Bank Account Person

Bank

Account#

Person

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

may instantiated at one time for any single object.

{or}

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.

N –ARY ASSOCIATION

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.

Semester *

* class student *

AGGREGATION AND COMPOSITION

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

to denote aggregation.

Car

Company

Company Person

Works for

Salary

Year

Class Student

Grade Book

Grade

Exam

lab

Person

1 consists of

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.

Separate target

CLASS DIAGRAM:

Team Player

Vehicle

Bus Truck

Car

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 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.

• 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

Analysis is the process of extracting the needs of a system and what the system must do to satisfy the

users’ requirements.

By constructing models of the system that concerntrate on describing WHAT the system does rather than HOW it does

• 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 ?

• 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

3 common sources of requirement difficulties [Norman] :fuzzy descriptionsincomplete requirementsunnecessary features

• To understand users’ requirements :

Find out how they “use” the system, by developing use

cases.

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

Use cases = scenarios for understanding system requirements

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

• 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

Develop use cases, activity diagrams

Develop interaction diagrams

Build prototype

Refine & iterate

Identify classes, relationships, attributes, & methods

Identify actors

Figure 1 : OOA process in the unifed approach

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

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

Go to counter and

return books

Go to counter and check out the books

Interlibrary loan

Search for book

Do research on

topics

Read news paper and magazine

yes

Return book?

yesyes

yes

yes

yesyes

no

no

no

no

borrow book?

Do search

Read newspaper?

Activty diagram –library system

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 :

• 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

ActorUse-case

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 :

10

Yati

Jamila

Salmi

USER

Borrow book

Check IDs

Order books

USE CASE

volunteer

employee

member

ACTORCan play the role of

performs

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

Check library card

Get an interlibrary loan

Return books

Do research

Read books and news paper

Purchase supplies

memberCirculation clerk

supplier

extends

uses

uses

uses

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

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

ATM system

Bank system

ATM maintenance

Bank teller

System boundary

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

• 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

Conduct bank transactions

Maintain ATM machine

Run reports

ATM Maintenance

Customer Bank

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

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

Who reads Use-Case documentation ?

customers

users

system developers

reviewers

system analysts / system

designer

system tester

project leader

technical writer

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 TERMSUse caseActorUse case modelKEY 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 cases2. Use cases are scenarios that describe how actors use the system. (a) Use case model (b) use cases3. 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 :

Noun Phrase Approach

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

Wiener

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

25

Noun phrase

Common class patterns Use-case

driven, sequence / collaboration modeling

Classes, Responsibilities, and Collaborators (CRC)

• Nouns are listed and divided into 3 categories :

• Guidelines for selecting classes in an application :

26

Nouns in textual description

Classes

Verbs in textual description

Methods of the classes

Considered to be

Considered to be

plurals singularChanged to

Relevant classes

Irrelevant classes

fuzzy classes

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

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.

27

Review redundant classes

Review irrelevant classes

Review attributes

Review adjectives

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

AccountAccount balanceAmountApproval processAtm cardAtm machineBankBank clientCardCashCheckCheckingChecking account

ClientClient’s accountCurrencyDollarEnvelopeFour digitsFundInvalid pinMessageMoneyPasswordPINPin code

RecordSavingsSavings accountStepSystemTransactiontransaction history

30

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

AccountAccount balanceAmountApproval processAtm cardAtm machineBankBank clientCardCashCheckCheckingChecking account

ClientClient’s accountCurrencyDollarEnvelopeFour digitsFundInvalid pinMessageMoneyPasswordPINPin code

RecordSavingsSavings accountStepSystemTransactiontransaction

history

Reviewing possible attributes

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

33

Then it must collaborate with those objects to fulfill its responsibility

• 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 )

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

Figure 3 : CRC process

34

Class name: Collaborators

Responsibilities

Identify classes & responsibility

Identify collaboration

Assign responsibility

• 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

• 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

What is use case analysis ?

• 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

Use case model Design model

Use case Use case realization

• 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

These 3 perspectives are :

• The boundary between the system and its actors

• The information the system uses

• The control logic of the system

38

System boundary

System information

Use-case behavior coordination

<<boundary>>

<<control>>

<<entity>>

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:

Entity Class :

39

Register for courses

RegisterForCoursesForm CourseCatalogSystem

Course Catalog System

Student

• 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 )

Control Class :

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

or more use-cases

40

CourseOfferring

Student

Schedule

• They represent the dynamics of the system, handling the

main tasks and control flows

• One control class per use case

• Example : finding control classes

• 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

Register for courses

RegistrationController

Course Catalog System

Student

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 : CourseWorking Definition : A class offered by the University

Name : ProfessorWorking 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

• 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

Use case Use-Case Realization

Sequence diagrams

Collaboration diagrams

• 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

44

Math 101 Math 101 :

CourseOffering

: CourseOffering

Object nameObject name and Class name

Class name

Object representation in UML

• Messages: communication between two objects that

triggers an event

• 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

• Collaboration Diagram

45

Message

:Prospective Buyer :PersonalPlannerForm

//maintain profile()

//prompt to create new profile()

:Prospective Buyer :PersonalPlannerForm

//maintain profile()

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

The guidelines for naming classes: ◊ The class name should be singular.

46

1:enter id

2:validate id

3:enter current semester

4:create new schedule

5:display

6:get courses

Ali:Student

:AvailableClasses:ScheduleForm

:RegistrationForm

◊ 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)ClassificationConcept classPlaces classOrganization classPerson class (or) people classTangible 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 recorded3. 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 class5. Places class is a physical locations that the system must keep information

about6. 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 class2. Events class is points in time that must be recorded (a) concept class (b) event class (c) organization class (d) people class3. 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 class4. People class is Known as person, roles, and roles played class (a) concept class (b) event class (c) organization class (d) people class5. Places class is a physical locations that the system must keep information

about (a)Places class (b) event class (c) organization class (d) people class6. 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 CRC8. 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)

53

1

Person CourseGive lecture

1..*

2)

• 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

• AGGREGATION (A-APRT-OF RELATIONSHIPS) :

54

StaffMemberStaffNameStaffNoCalculateBonusChachangeGradegetGrade

CreativeStaffAdminStaff

1

Person CourseLecturer

1..*

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

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

CAR

CARBURETOR

RADIOENGINE

• 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 :

• 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

AttributesNameStaffIdSubject Taught

Dr.Mohd.AzimA0123Software Quality

Pn.NorhayanaA0224Software Requirement

• 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 namedIt indicates the balance must be calculated this is an implementation decision

GetBalance ( ) Well namedIt 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 :

59

2. Add course

: RegistrationForm : RegistrationManager

RegistrationManager

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 :

60

1 1

0..4

1

1

1

1

1

<<boundary>>ScheduleForm

<<entity>>CourseCatalog

<<entity>>StudentRecord

<<entity>>Course

<<control>>RegistrationManager

Adds student to

accesses

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

AggregationAntisymmetryA part of relationshipAssociationTransitivity

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) Aggregation2. AGGREGATION (A-APRT-OF RELATIONSHIPS) represents the

situation where a class consists of several component classes (a) Association (b) Aggregation3. 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) Antisymmetry4. 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.

CommercialVehicle PrivateVehicle

Lisence

Lisencee

CommercialVehiclee PrivateVehiclee

FoodTruck

Restuarant

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 :

Macro-Level Proces : Identifying View Classes

The view layer macro process consists of 2 steps :

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

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.

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.

View objects

Business objects

Access objects

Relationship among view objects, business objects, access objects

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

Micro level design process

Apply micro level UI design rules and GUI

guidelines to each interface object identified

to develop the UI

Done

Next interface objects refine and iterate

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

Account

Relation between the view class

AccountTransactionUI

and its associated

business class (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

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.

OOA use case model

User satisfaction test cases

Quality assurance test cases

Usability test cases

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.

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

A Custom Form For User Satisfaction Test

10 9 8 7 6 5 4 3 2 1

Ease of use

Functionality

Cost

Intuitive UI

Reliability

Comments

10 9 8 7 6 5 4 3 2 1

10 9 8 7 6 5 4 3 2 1

10 9 8 7 6 5 4 3 2 1

10 9 8 7 6 5 4 3 2 1

Very Easy

Very Functional

Very Inexpensive

Very Intuitive

Very Reliable

Very Hard

Non Functional

Very Expensive

Very Hard to Follow

Not Reliable

I have more to say; I would like to see you

How do you rate the customer tracking project at this time?

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)