Object Oriented Analysis and Design

Introduction

Contents

2

Analysis & Design Software Life Cycle Iterative Development UML

Analysis and Design

3

Analysis and design is part of the software life cycle

It is the process by which the nature of the problem is understood and a solution is developed

In the early days of software, this part of the process was often ignored

Today, it is seen as a crucial part of the software development process

The Importance of Design

4

Software is one of the most complex creations of man

The complexity of software increases exponentially with its size

As the size of software increases, design becomes more important

Design lets you think of the best implementation technique before you build it

But, I Don’t Need to Design

5

Of course you don’t You have only been working on

small problems Design is not essential for

small problems Problems worked on by one person

Design is important for Larger problems Difficult problems Problems being worked on by

groups of programmers

The Benefits of Design

6

Well-selected classes Well designed methods Data structures which are consistent across

the project Proper class hierarchies A simple, logical architecture Appropriate use of design patterns Games which are

Simpler to understand Easier to extend and modify Less costly to build and maintain

Design Alternatives

7

We will look at several approaches to software design The Big Ball of Mud Spaghetti Code Spaghetti & Meat Balls Non-object-oriented design Object-oriented design

Big Ball of Mud

8

Code is in one big program Code is not broken into logical

sections Logic is distributed throughout

the code

Evaluation: Difficult to modify and maintain Logic is difficult to discover

Spaghetti Code

9

Code where Following the logic is like following

a piece of spaghetti through a bowl Little or no design Somehow it actually works

Evaluation Code cannot be understood Almost impossible to modify or

maintain Easier to re-write than understand

Spaghetti & Meat Balls

10

The object-oriented version of spaghetti code

Objects (meat balls) are connected by spaghetti code

Programmers claim benefits of object oriented code

Evaluation Just as bad as regular spaghetti

Non-Object Oriented Design Uses functional decomposition

Break problem into smaller problems Write a function for each smaller

problem Put them together to make a solution

Evaluation Design ignores data Functions are created based on

functionality and ignore data This results in poor

Low cohesion High coupling

11

The Cohesion Principle Software must have a good reason

to be together It should

Do few things, ideally just one Access few data structures, ideally

just one

Highly cohesive software is good software

12

The Coupling Principle Coupling refers to the connections

between functions A connection could be

Passing of data to a function A function accessing data outside its

scope Functions accessing global data Functions accessing data maintained

by other functions Accessing data without using functions

to do so Coupling is minimized in good

software13

Object-Oriented Design Is based on

Identification of objects Encapsulation of data so it cannot be

accessed outside the class Addition of methods to access and

manipulate data in the class

Evaluation High cohesion since methods deal with

one data structure Low coupling as all data is in classes

and can only be accessed via methods High-quality designs

14

Software Development Life Cycle (SDLC)

15

There is more to software than writing the code

Software has a long life cycle that extends past when it is shipped

There is a definite order in which the steps in the life cycle must occur

Understanding the life cycle is one of the keys to a good software process

Life Cycle Phases

16

Requirements Identifying what the software must do

Analysis Translating the requirements into software

Design Tailoring the software for the environment

Implementation Coding, testing, installation

Support

Waterfall Model

17

Requirements

Analysis

Design

Implementation

Testing

Deployment

Problems with the Waterfall Model

18

It proceeds only in the forward direction

If a mistake is found in a later step, there is no way to go back to a previous step

It assumes that each step is performed perfectly

It does not reflect how people think and work

Iterative Model

19

• project is split into smaller projects• each smaller project is like a big project• any step can be repeated until it is correct

Rational Unified Process

20

RUP

21

The Rational Unified Process is organized along two dimensions A horizontal time axis showing the major phases

of a project A vertical axis depicting the disciplines or major

activities of a project The graph shows the amount of activity in

each discipline in the different phases of the project

RUP Disciplines

22

Technical Disciplines Business modeling discipline Requirements discipline Analysis and design discipline Implementation discipline Test discipline Deployment discipline

Supporting Disciplines Project management discipline Configuration and change management discipline Environment discipline

RUP Phases

23

Inception State the project vision State the business case for the project

Elaboration Planning the project Designing the software

Construction Building the product Adapting the architecture to changing requirements

Transition Passing the product to the users Training the users Maintaining the product

Iterating

24

RUP assumes that you will not get things right the first time and that you will have to iterate the phases of the project

For example, a product might have three versions produced Create an initial version of the product -> V1 Add additional features to the product -> V2 Incorporate requirement changes -> V3

Each version is built by following all phases of the project

Iteration

25

Iteration allows the product to Be built in smaller parts Tested as each part is added Have flaws identified and corrected in the next iteration

Each iteration involves all phases

RUP In Practice

26

RUP Seeks to Build system is smaller parts Make frequent deliveries to the client Get rapid feedback from the client Each iteration provides a verifiable deliverable for

the client

RUP Strengths & Weaknesses

27

Strengths Well defined with tool support Combines many best practices Comprehensive

Weaknesses Large and difficult to manage Can get bogged down in process and forget you

are trying to write software Requires customization for each project Tools limited to Rational

The Problems with Non-Iterative Approaches

28

They assume that requirements do not change People change, environments change,

requirements change They assume that a correct design can be

created on paper before the software is built True if it is a simple project with well-known

technology and nothing novel The goal is to produce the next document

and freeze it so you can move on to the next phase of the project

How Iteration Helps

29

Changing requirements are dealt with in the next iteration

The design for the next phase is performed after evaluating the results of the previous phase

Nothing is frozen until, maybe, the end of the project

Documents do not rule the project

Benefits of Iteration

30

Highest risk is attacked early Change is properly managed More and consistent user feedback Proper prioritization Early detection of inconsistencies Continuous iterative testing Development team learns from mistakes and

improves Stakeholders and users involved throughout the

project Higher level of reuse Better project quality

Game Life Cycle

31

Requirements Game Design Document

Analysis and Design Recognition of objects Design of classes

Testing Unit testing Integration testing Testing gameplay

Delivery Packaging game for shipment

The Design Process Analyze the game design document Identify classes which need to be created Use a notation to represent the classes

which is less work than coding the classes Which can be changed easily as design ideas change Which allows the design of details to be delayed Which captures much less detail than actual coding

Create demos to show how to use the classes Create diagrams to show the high level

components Create diagrams to explain complex algorithms Create diagrams showing how to install software

32

The Unified Modeling Language

33

UML is a graphical and textual notation that is designed to Capture the design of the software Show how the software components interact with

one another Show how the software can be deployed

Benefits Lets the software be viewed in several ways Is fast to work out design ideas Takes much less time than writing code

One Game, Many Views Games are made from complex software You cannot see the whole thing with one picture UML Provides

Class diagrams – to show classes and relationships Object diagrams – to show how classes exist in actual

use Sequence diagrams – to show how classes are used to

solve a problem

34