Object Oriented Analysis and Design

Object Oriented Analysis and Design Introduction

Contents • Analysis & Design • Software Life Cycle • Iterative Development • UML

Analysis and Design • 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 • 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 • 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 • 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 • 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 • 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 • 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 • 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

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

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 software

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

Software Development Life Cycle (SDLC) • 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 • 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 Requirements Analysis Design Implementation Testing Deployment

Problems with the Waterfall Model • 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 • 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

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

The Unified Modeling Language • 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

Object Oriented Analysis and Design

Object Oriented Analysis and Design

Presentation Transcript