Object Oriented Analysis and

Design

Object Oriented Analysis :

Object oriented analysis is a method that examines requirements from the perspective of the classes and objects found in the vocabulary of the problem domain.

Abstraction :

An abstraction denotes the essential characteristics of an object that distinguishes it from all other kinds of objects and thus provide crisply defined conceptual boundaries, relative to the perspective of the viewer.

Object Oriented Design :

Object Oriented Design is a methods of design encompassing the process of object - oriented decomposition and a notation for depicting both logical and physical as well as static and dynamic models of the system under design.

Two important parts to this definition :

1.Leads to an object oriented decomposition and

2.Uses different models of the logical(Class and Object Structure) and physical (module and process architecture ) design of a system , in addition to the static and dynamic aspects of the system.

Object Oriented Programming :

It is a method of implementation in which programs are organized as cooperative collections of objects , each of which represents an instance of some class , & whose classes are members of hierarchy of classes united via inheritance relationships.

Object Oriented Language :

A language is Object - Oriented if and only if it satisfied the following requirements :

•It supports objects that are data abstractions with an interface of named operations and a hidden local state.

•Objects have an associated type [Class].

•Types [Classes] may inherit attributes from super types[Super classes]

Project Life Cycles :

Testing Requirementspecification

Design

Implementation

Traditional SW life cycles : Major portion of the project life time is spent on implementing design .

Requirementspecification

Implementation

Design

Testing

Object oriented design aims for robust software that can be easily reused , refined , tested , maintained and extended , thereby ensuring it a productive maturity.

Software is Reused when it is used as a part of software other than that for which it is initially designed .

Software is Refined when it is used as the basis for the definition of other software.

Software is Tested when its behavior is determined .

Software id Maintained when errors are found and corrected.

Software is Extended when new functionality is added to an already existing program.

Software that can be Reused :

Components

Frameworks

Applications

Project Life Cycle :

1. Requirements Specification.

2. Design.

3. Implementation

4. Testing.

==> Maintenance

Refinement and Extension

Requirements Capture :

Current System

New Requirements

Investigating Current System :

•Some of the functionality of the existing system will be required in the new system.

•Some of the data in the existing system is of value and must be migrated into the new system.

•Technical Documentation of the existing computer systems may provide details of processing that will be needed in the new system.

•The existing system may have defects which we should avoid in the new system.

•Studying the existing system will help us understand the organization in genera

•Parts of existing system may be retained.

• To Understand how people do their jobs at present in order to characterize people who will be the users of the new system.

• To gather baseline information against which we can set and measure performance targets for the new system.

New Requirements :

•Functional Requirements

•Non Functional Requirements

•Usability Requirements

Functional Requirements :

Functional requirements describe what a system does or expected to do , often referred to as functionality .

Functional Requirements include the following :

•Descriptions of processing which the system will be required to carry out.

•Details of inputs into the system from paper forms and documents , from interactions between people ,such as telephone calls , and from other systems.

•Details of outputs that are expected from the system in the form of printed documents and reports , screen displays and transfers to other systems.

•Details of data that must be held.

Non Functional Requirements :

Non Functional requirements are those which describe aspects of the system that are concerned with how well it provides the functional requirements . These include the following :

•Performance criteria such as desired response times for updating data in the system or relative data from the system.

•Anticipated volumes of data , either in terms of throughput or of what must be stored .

•Security considerations.

Usability Requirements :

Usability requirements are those enable us to ensure that there is a good match between the system that is developed and both the users of the system and the tasks that they will undertake when using it.

•Characteristics of the users who will use the system.

•The tasks which the users undertake , including the goals they are trying to achieve.

•Situational factors which describe the situations which could arise during system use.

•Acceptance criteria by which the user will judge the delivered system.

Fact finding techniques :

•Sampling

•Questionnaires

•Interviewing

•Reading

•Observation

Analysis

What to do

Design

Exactly how to do

Other Activities in Analysis

•Project Management

•Staff Skills and Experience

•Client Decisions

•Choice of Development Environment

Project Management (Task by Project Manager)

- Budget in terms of Money and Staff.

Staff Skills and Experience

- Business Analyst

- Systems Analyst

- Systems Architects

.

Client Decisions

- The clients want to know what they are paying for.

(Decision point)

- Specification of system in terms of requirements.

-Selection of Alternatives from number of Specifications.

Choice of Development Environment

-Hardware / Software Environment.(Dynamic)

Design

Design

Logical

(Implementation

Independent)

Physical

(Implementation

Dependent)

In Object -Oriented methodology, the development of a system is viewed from three perspectives

1. The Essential Model : Equivalent to Analysis Model.

2. The Specification Model : Logical Design.

3. Implementation Model : Physical Design Model.

Design

System Design Detail Design

System Design

•Overall System Architecture of the system.(e.g.Client Server(Unix,Windows NT).

•Distribution of Processes and Objects on Different Machines.(done by systems designer or architect).

•Decomposing the system into different Subsystems and allocation of processors to different Subsystems.

•Communication between processors and mechanism for communication between processors..

•Concurrency Needs

•Decisions about the standards to be applied across the whole system.(e.g. Screen Layouts , Report Layouts, On-line help. Etc.)

Detail Design

Traditional Approach

•Designing Inputs

•Designing Outputs

•Designing Processes and

•Designing Files

Object - Oriented Detailed Design

•Concepts of Business (Analysis Phase)

•Classes

•Use Cases

•User Interfaces and Interfaces with other Systems Classes (Depending on Hardware and Software Platform)

Identifying Classes :

Classes often represent the more permanent aspects of an application domain.

A class is an abstract descriptor for a set of instances with certain logical similarities to each other.

The class Diagram is a fundamental to object oriented analysis . Through successive iterations , it provides both a high level basis for system architecture , and a low level basis for the allocation of data and behavior to individual classes and object instances and ultimately for the design of the program code that implements the system. It is important to identify the classes correctly.

Object :(Definition by Coad and Yourdan)

An abstraction of something in a problem domain , reflecting the capabilities of the system to keep information about it , interact with or both.

Abstraction: A form of representation that includes only what is important or interesting from a particular viewpoint.

Objects serve two purposes :

1. The promote understanding of the real world and

2. Provide a practical basis for computer implementation.

All objects have certain similarities :

Every object has

•State - Represents the particular condition that an object is in at a given time.

•Behavior - Things the object can do.

•Identity - Every object is unique.

UML

UML Diagrams :•Use Case Diagrams

•Sequence Diagrams

•Collaboration Diagrams

•Class Diagrams

•State Transition Diagrams

•Component Diagrams

•Deployment Diagrams

Use Case Diagrams :

These diagrams show interaction between use cases , which represent system functionality, and actors , which represent the people or systems that provide or receive information from the system .

Use Case Diagram for an Automatic Teller Machine :

Transfer Funds

Change Pin

Make Payment

View Balance

Withdraw Money

Deposit Funds

Customer

Manager

Credit

System

Sequence Diagrams :

Sequence diagrams are used to show the flow of functionality through a use case.

Card Reader ATM Screen Customer Account

Cash DispenserCustomer

1:Accept Card 2:Read Card No.

3:Initialize Screen

4:Open Account5:Prompt for pin no

6:Enter Pin no 7:Verify Pin no

8:Prompt for Transaction

9:Select Transaction(Withdraw)

10:Prompt for Amount

11:Enter Amount12:Withdraw Funds

13:Verify Funds

14:Deduct Funds

15:Provide Cash

16:Provide Receipt17:Eject Card

Collaboration Diagrams :

Collaboration Diagrams show exactly the same information as the Sequence Diagrams . However collaboration diagrams show this information in a different way (I.e. Object actor information without reference to time) and with a different purpose(I.e Distribution of processes between objects) .

ATM

Screen

Customer Account

Cash Dispenser

Card Reader

10:Prompt for Amount

1:Accept Card

2:Read Card No

3:Initialize Screen

4:Open Account

5:Prompt for Pin

6:Accept Pin

7:Verify Pin

8:Prompt for Transaction

9:Select Transaction(withdraw)

Customer 11:Enter Amount

12:Withdraw Funds

13:Verify Funds

14:Deduct Funds

15:Provide Cash

16:Provide Receipt17:Eject Card

Class Diagrams :

Class Diagrams show interaction between classes in the system .Classes can be seen as a blueprint for objects. Classes contain information and behavior that acts on that information.

Some ClassSome Class Some Class

Attributes

Operations

Abbreviated Form Full Form

Card Reader

- Card Number

+Accept Card()

+Eject Card()

+Read Card()

ATM Screen

+ Prompt ()+Accepting()

Cash Dispenser

-Cash Balance

+Provide Cash()

+Provide Receipt()

Account

-Account Number

-Pin

-Balance

+Open()

+Withdraw Funds()

-Deduct Funds()

-Verify Funds()

State Transition Diagrams :

State Transition Diagrams provide a way to model the various states in which an object can exist . State Transition Diagrams are used to model the more dynamic behavior of a system.

Open

Closed

Overdrawn

Do:Send notice to Customer

Customer Request Closure

Withdrawal [Balance < 0]

Deposit [Balance < 0]

Check Balance [Balance<0 for > 30 days]

Component Diagrams :

Component Diagrams show a physical view of the model .It shows the software components in the system and the relationships between them . There are two types of components on the diagram :

1.Executable Components.

2.Code Libraries.

Component diagrams are used by an individual who is responsible for compiling the system , so as to know in what order the components need to be compiled.The diagrams also show runtime components created as a result of compilation .Component diagrams show mapping of classes to implementation components . This is a point where code generation is initiated.

ATM.exe

Cash Dispenser

Cash Dispenser

ATM Screen

Card Reader

ATM Screen

Card Reader

Shaded Component : Package Specification

I.e. program file(.cpp, .java)

Unshaded Component : Package Specification

I.e. .h files in c++

Task Specification ,represents thread of processing

Deployment Diagrams :

The deployment diagram shows the physical layout of the network and where the various components will reside .

The deployment diagram tells much about the layout of the system. These diagrams are used by project manager , users , architects and deployment staff to understand the physical layout of the system and where the various systems will reside.This diagram helps the Project Manager to communicate to the users , what the system will be like.

Oracle Server Banking Database

Server

Regional ATM ServerATM Server.exe Printer

ATM Client.exe ATM Client.exe

Street 1 ATM Street 2 ATM

<<Private Network>><<Private Network>>

<<LAN>>

Object Oriented Development

Most of the methods remain tied to a waterfall model.

Unified Software Development Process.

(Booch , Jacobson , Rambaugh)

Object Modeling Technique (OMT) Developed by Rambaugh

Three Phases:

•Analysis

•System Design

•Object Design

(Implementation is regarded out of scope)

Methodology Step Comment1. Write or obtain an initialdescription of theproblem(Problem Statement)

A major task

2.Build an Object Model : Identify Object Classes. Begin an data dictionary

containing descriptions ofclasses and associations.

Add associations betweenclasses .

Add attributes for objects andlinks.

Organize and simplify objectclasses using inheritance.

Test access paths usingscenarios and iterate theabove steps as necessary.

Group classes into modules ,based on close coupling andrelated function.

A major taskbroken downinto severalmore detailedtasks.

=>Object Model Object modeldiagram + data dictionary

An end-of-phase product

OPEN :(Object - oriented Process, Environment and Notation)

(Tailorable life cycle model)

Components

•Activities : Collection of tasks seen from a project manager’s perspective .

E.g. project initiation , requirements engineering , analysis and model refinement , project planning and build.

•Tasks : Developers View

e.g. analyze user requirements, choose project team, design UI ,perform class testing.

•Techniques : Describe how to carry out one or more tasks

e.g. CRC technique , class internal design

•Deliverables : Post conditions for activities and also preconditions for other activities

e.g. User requirements statement,requirements specifications, diagrams such as inheritance diagrams,deployment diagrams.

•Notation :COMN(Common object modeling notation written in Object modeling language)

Objectory :

Analysis Construction Testing

Requirements model

Analysis model

Design model

Implementation model

Test model

More Case Studies