object oriented analysis and design n.
Skip this Video
Loading SlideShow in 5 Seconds..
Object Oriented Analysis and Design PowerPoint Presentation
Download Presentation
Object Oriented Analysis and Design

Object Oriented Analysis and Design

116 Views Download Presentation
Download Presentation

Object Oriented Analysis and Design

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. Object Oriented Analysis and Design Introduction

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  17. Waterfall Model Requirements Analysis Design Implementation Testing Deployment

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

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

  20. Rational Unified Process

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

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

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

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

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

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

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

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

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

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

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

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

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

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