1 / 34

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

Download Presentation

Object Oriented Analysis and Design

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.


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

More Related