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? Why object-oriented? 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]

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

Pros and cons of OOA&D Advantages Disadvantages Focuses on objects rather than the procedures as in Structured Analysis. Functionality is restricted within objects. This may pose a problem for systems which are intrinsically procedural or computational in nature. The principles of encapsulation and data hiding help the developer to develop systems that cannot be tampered by other parts of the system. It cannot identify which objects would generate an optimal system design. It allows effective management of software complexity by the virtue of modularity. The object-oriented models do not easily show the communications between the objects in the system. It can be upgraded from small to large systems at a greater ease than in systems following structured analysis. All the interfaces between the objects cannot be represented in a single diagram. * https://www.tutorialspoint.com/object_oriented_analysis_design/ooad_object_oriented_analysis.htm

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.

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

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

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

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

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

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

Use case diagrams

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

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.

Examples: WinBook Use Case diagram (all use cases)

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.

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.

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

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.

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

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

Introduction to robustness analysis: common mistakes

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.

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

Please sit in teams.