1 / 29

Object Oriented Analysis and Design

Object Oriented Analysis and Design. Unified Modeling Language. Contents. Unified Modeling Language. A series of diagrams to capture software design Each diagram shows a different aspect of the design You cannot see an entire program In just one diagram In just one type of diagram

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

E N D

Presentation Transcript


  1. Object Oriented Analysis and Design Unified Modeling Language

  2. Contents

  3. Unified Modeling Language • A series of diagrams to capture software design • Each diagram shows a different aspect of the design • You cannot see an entire program • In just one diagram • In just one type of diagram • Each diagram provides a different view of the game • All of the diagrams show you how the game will work

  4. Multiple Views, Like Blueprints Each diagram shows the object from one perspective

  5. Multiple Views, Like Blueprints Another view lets you build a 3D image of the object

  6. Multiple Views, Like Blueprints A third view completes the 3D picture of the object

  7. Multiple Views, Like Blueprints Other diagrams can zoom in to show details

  8. Alternate Designs to One Problem Other studios might design different solutions to the same problem

  9. Nothing New Under the Sun • UML simplifies formalizes the diagrams used for years • We now • Have a standard set of symbols • Have a standard set of diagrams • Have tools to support diagram production • Allow the designs to be understood by everyone

  10. Class Diagram • Shows some or all of the classes in the program • Shows how the classes are related to one another via inheritance • Shows other relationships between classes

  11. Class Diagram

  12. Object Diagram • Shows the actual connection between objects • It is like a snapshot of the connection between objects in the running system • Used to illustrate how class instances are actually connected to each other

  13. Object Diagram

  14. Activity Diagram • An activity diagram shows the series of steps necessary to complete an operation • An activity diagram can include • Linear control flow • Decision points • Splitting of control for parallel execution • Joining of parallel threads of control

  15. Activity Diagram

  16. Sequence Diagram • A sequence diagram shows the method calls between objects • These are arranged along vertical time lines • Can include self-referential calls for methods performed by the same object

  17. Sequence Diagram

  18. Collaboration Diagram • The collaboration diagram shows how objects interact to perform a task • It is similar to a sequence diagram but does not use an explicit time line • As a result, messages between the objects are numbered to show their sequence

  19. Collaboration Diagram

  20. Statechart Diagram • Shows how the system moves between several states • Shows the events or inputs that cause the transition from one state to the next • Useful for formally specifying the behaviour of a system

  21. Statechart Diagram

  22. Package Diagrams • In large systems, it is helpful to group related classes together into packages • This helps to organize the classes into logical units • A package diagram shows the packages and what classes are within the package

  23. Package Diagrams

  24. Deployment Diagram • The deployment diagram shows how the software will be deployed on the hardware • It consists of hardware nodes that can run software and software nodes which are environments in which software can run

  25. Deployment Diagram

  26. Component Diagrams • Show interaction between the components of the system • Can be used to identify related components or reuseable components • Components can be objects or other entities, such as files, in the system

  27. Component Diagrams

  28. Views • A single picture does not convey all there is to know about a piece of software • Different diagrams show different aspects of the software, just like blueprints show different aspects of a house • Views provide a way to organize software diagrams into groups

  29. Views • We use three views • Functional view • Shows the functional behavior of the system from a requirements point of view • Static view • Shows a static snapshot of the components of the design of the final solution • Dynamic view • Shows how the design components interact to solve the problem

More Related