1. 1 What is OO Design? OO Design is a process of invention, where developers create the abstractions necessary to meet the system’s requirements OO Design is independent of the programming language used to implement the design. However, using OO Language helps Objects are independent and encapsulate state and representation information System functionality is expressed in terms of object services Shared data areas are eliminated. Objects communicate via message passing

2. 2 Why OOD? OOD does not reduce development time. In fact it may increase it! However, there is empirical evidence that OOD facilitates the following activities: Reuse Maintenance Verification

3. 3 What is Object Oriented Design? OOD is a set of principles and methods for designing systems based on combining data and function into entities called objects OOD Principles include Encapsulation Decomposition Design Patterns Hierarchical Relationships Defined decision making

4. 4 OO Design OO systems are designed using a three phase iterative process - Analysis - Design - Implementation Successful software systems evolve over time, leading to iterative process, by evolving and refining each time through the process.

5. 5 OO Analysis Definition ( Booch ): OOA is a method of analysis that examines the requirements of the system from the perspective of classes and objects that are found in the vocabulary of the problem domain Transform programming problem into a precise description of the tasks to be performed. Prior to analysis problem is usually vaguely understood. OOA focuses on What needs to be done, not How it needs to be done.

6. 6 OO Analysis OOA is the input to Object Oriented Design (OOD) Quality of OOD is based on quality of OOA When defining OOA need to work with problem domain expert. OOA provides a description of the problem The description must be complete, consistent, readable, reviewable by diverse parties, and testable against the reality. You should not pursue issues of class design or representation in the analysis phase

7. 7 OO Analysis Identify functional and non-functional points of the system Identify classes and objects( their roles and responsibilities) from the vocabulary of problem domain Functional points are observable and testable behaviors of a system End use perspective: function points represent the activity of the system in response to an event Analyst perspective: function points represent a behavior. The more function points, the greater system’s complexity

8. 8 When OO Analysis is finished? When you have formal requirements analysis document describing behavioral requirements Described non-functional requirements: reliability, security, portability, and performance Capture descriptions of behavior by using scenarios Risk assessment: Identify known risks that may impact the design process. Better to document risks early than discover them latter.

9. 9 Domain Analysis Identify objects that are common to a particular system Study similar existing systems (REUSE), benefiting from other projects that had to make similar design decisions. Do not reinvent the wheels!

10. 10 OO Analysis: Scenario Planning Identify the function points of the system and cluster them by the related behaviors. If an object life cycle is essential to a scenario document using a finite state machine Look for patterns in among developed scenarios

11. 11 OO Analysis: Approaches Primary goal of OOA is to discover the objects in the system specification How do we discover objects and classes that form the vocabulary of system domain? Classical Behavior Analysis Domain Analysis Use case Analysis CRC cards Informal English description

12. 12 Classical Analysis Derive classes from the requirements of problem domain Derive candidate classes and objects from the following sources: Tangible things Roles Events Interactions Structure Devices/Locations Organizational Units / Grouping

13. 13 Behavioral Analysis Focus on dynamic behavior as the primary source of classes and objects Emphasize responsibilities: Actions object can perform Group things that have common responsibilities Create hierarchies that embody general responsibilities and subclasses that specialize their behavior

14. 14 Domain Analysis Focuses on single specific application Seeks to identify the classes and objects that are common to all applications within a specific domain Examples: Patient record tracking, stock and bond trading, Compilers and etc. Addresses the fact that there are very few unique kinds of software systems

15. 15 Use Case Analysis Goal: Derive process of analysis in a meaningful way Develop series of important scenarios and identify objects, their responsibilities and how objects collaborate with other objects

16. 16 CRC Cards Help to analyze scenarios CRC cards are 3x5 cards capturing: Name of the class Class responsibilities Collaboration with other classes Software team walks through scenarios and and assigns new responsibilities, updates existing, discovers new classes and etc

17. 17 English description Radical alternative analysis method developed by Abbott Process: Write a detailed English description of the problem Underline nouns and verbs in the detailed English description Nouns become candidate objects Verbs represent candidate operations upon the objects Benefits: Simple and forces analysis to work in the vocabulary of problem space Problem: Does not scale well to handle large problems

18. 18 OO Design A lot of gray areas between analysis phase and design OOD emphasizes the proper and effective structuring of a complex system: the system architecture. Design process begins as soon as we have developed a reasonably complete model of the behavior of the system Don’t design before analysis reaches closure Don’t delay the design trying to achieve perfect analysis. When working in gray areas, both activities are done in parallel

19. 19 OO products Tactical Policies Error detection Memory management Exception Handling Data store managment System Architecture Class and object structure Clustering of classes into class categories

20. 20 Object oriented programming Method of implementation in which programs are organized as cooperative collections of objects, each of which represents an instance of some class. Uses objects, not algorithms as its fundamental blocks Each object is an instance of some class Classes are related to each other