What is OO Design?

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