1 / 27

Object oriented analysis and design

Object oriented analysis and design. Kan Qi, Bo Wang. Adapted from Alexey Tregubov’s Slides. Outline. Purpose and motivation The history The methodology UML diagrams: Use case diagrams Robustness analysis diagrams. Motivation. Motivation. How to solve the problem?

glaser
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 Kan Qi, Bo Wang Adapted from Alexey Tregubov’s Slides

  2. Outline • Purpose and motivation • The history • The methodology • UML diagrams: • Use case diagrams • Robustness analysis diagrams

  3. Motivation

  4. Motivation • How to solve the problem? • standard notations • communication tool • Why object-oriented? • Conceptual diagrams use “objects” • Inspired by OO paradigm (programming and languages) “The "software crises" came about when people realized the major problems in software development were … caused by communication difficulties and the management of complexity” [Budd]

  5. OOD history • OO in the `60s & `70s – Informal notions • Simula, Smalltalk • In `82, Grady Booch coined the term Object Oriented Design • The idea was to combine a design methodology with language constructs that implement design concepts • Objects in design space are classes in implementation space

  6. Pros and cons of OOA&D * https://www.tutorialspoint.com/object_oriented_analysis_design/ooad_object_oriented_analysis.htm

  7. Definitions • Analysis — understanding, finding and describing concepts in the problem domain. • Grady Booch has defined OOA as, “Object-oriented analysis is a method of analysis that examines requirements from the perspective of the classes and objects found in the vocabulary of the problem domain”. • Design — understanding and defining software solution/objects that represent the analysis concepts and will eventually be implemented in code. • OOAD — a software development approach that emphasizes a logical solution based on objects.

  8. OOA&D Principles • Major principles: • Abstraction • Encapsulation • Modularity • Hierarchy • Minor principles: • Typing • Concurrency • Persistence

  9. Design Goals for OOD • Booch defined three goals • Identify the objects/classes • Identify the functionality of these objects/classes • Identify the relationship between these objects/classes • This is an iterative process • Decisions in design space are complex • Identification and specification of one aspect of a class might force changes in other aspects

  10. UML supported diagrams • class • object • component • package • deployment • use case • interaction • communication • sequence • collaboration • timing • activity • robustness

  11. Overview • use case - description of functionality provided by system along with actors and their connection to the use case • object- set of objects and their relationships • class - set of classes, interfaces, collaboration, relationships • interaction - set of objects and their relationships including messages • state/statechart - a state machine showing states, transitions and events. • activity- states sequential flow of activities • component - physical structure of code in terms of code components

  12. Overview (cont-d) • deployment - physical architecture of hardware and software in the system • package - shows packages of classes and dependencies among them • grouping mechanism • form of class diagram • also called subsystem

  13. Organization of Diagrams Behavior diagrams • use case • robustness • sequence Structure diagrams • class • component • deployment • package

  14. Use case diagrams

  15. Use case diagrams (cont-d) A use case is a relatively large end-to-end process description that typically includes many steps or transactions; it is not normally an individual step or activity in a process. • Larman [1998] Applying UML and Patterns

  16. Use case diagrams – steps • capture normal (‘sunny-day scenarios’) use flow • for every step, ask yourself: “What can go wrong (rainy-day scenarios)?” • each variation of a use case is shown as an extension • after creating the diagram, write a generic scenario (called a use case description) – part of SSAD document. • Each step in a use case is an element of the interaction between an actor and the system.

  17. Examples: WinBook Use Case diagram (all use cases)

  18. Examples: WinBook Use Case diagram (all use cases) • Common mistakes: • Too many details • Functionality expressed in an implementation specific way • Functions of the system are not viewed from the perspective of the actors.

  19. Use case diagram (workshop I) • Pick 5 use cases from your project that are most important. • Develop a use case diagram for the five use cases. • Do it in groups (3-5 people) - 10 minutes.

  20. Domain Modeling • Necessary to ground both requirements and design (and hopefully implementation) in terminology shared by all stakeholders • A methodology for building terminology, as well as discovering and refining use-cases and requirements

  21. Domain Modeling Guidelines (cont-d) • Focus on real-world (problem domain) objects. • Use generalization (is-a) and aggregation (has-a) relationships to show how the objects relate to each other. • Limit your initial domain modeling efforts to a couple of hours. • Organize your classes around key abstractions in the problem domain. • Don’t mistake your domain model for your data model.

  22. Introduction to robustness analysis “The basic idea is that you can analyze the steps of a use case to validate the business logic within it and to ensure that the terminology is consistent with other use cases that you have previously analyzed.”* * from http://www.agilemodeling.com/artifacts/robustnessDiagram.htm

  23. Robustness analysis: vending machine example Make Payment Make Selection of Drink

  24. Introduction to robustness analysis: common mistakes

  25. PC-2 workshop • Group discussion and presentation: • Sit in teams • Pick one use case that has highest business value (section 2), and the objects identified (section 3) to create a robustness diagram (5 mins). • Choose a presenter and show your team’s (3 mins): • Quickly present the use case diagram you crated in workshop I. • Describe the chosen use case and why it are important. • Present the robustness diagram and explain how it realizes the use case.

  26. References • https://en.wikipedia.org/wiki/Artifact_%28UML%29 • https://www.tutorialspoint.com/object_oriented_analysis_design/index.htm • www.utdallas.edu/~chung/OOAD/M01_OO_Intro.ppt

  27. Please sit in teams.

More Related