Object oriented analysis and design

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.