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? 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]

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

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: Minor 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) 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

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

27. Please sit in teams.