1. Object Oriented Analysis and Design Introduction

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

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

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

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

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

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

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

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

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

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 11

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 12

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 13

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 14

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

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

17. Waterfall Model 17 Requirements Analysis Design Implementation Testing Deployment

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

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

20. Rational Unified Process 20

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

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

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

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

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

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

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

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

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

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

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

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 32

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

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 34