D.OOAD

• 1. What is OOAD

     1. OOAD is a process of identifying relevant details of system and system and organizing them in such a way that reusable software constrict can be discovered.

  2. OOAD Vs Design Patterns

• • 1. OOAD is approach to analysis and find solution to real world software implementation problem.

    2. Design patterns are collection of proven software design artifacts each of which best suited to a fundamental type of problem.

    3. Fundamental origin of most of design patterns is some where in the root of OOPS and OOAD.

• 3. OOAD Life cycle

• • 1. Requirements gathering

       1. Customer Statement

       2. Feature List

          1. Talk to customer and all stack holders and collect high level statement of what software is suppose to do.

          2. This process may take several iterations

       3. Use Case Diagram

• • • • 1. Use case diagram represent how system will interact with it`s surrounding

        2. It is actually visual representation of what your system is supposed to do.

        3. It also list down the external forces that may affect system behavior

• • 1. 4. Problem Break Down

• • • • 1. Break your application in to smallest possible modules of similar functionality

        2. Then identify most important features

        3. Oder the modules in order to priority

• • 1. 5. Requirement List

• • • • 1. Figure out low level individual requirements of each identified module

        2. Always start with core module

        3. Keep iterating your requirement list through your development cycle and keep fine tuning them

        4. Iteration do not mean that you need develop new features but to keep list up to date for future releases.

        5. Make sure they fits in one big picture.

• • 2. Analysis

• • • 1. Application Architecture

         1. Finalize Application Patterns

         2. Finalize application technology stack

      2. Domain Analysis

• • • • 1. Domain analysis is a an approach to study any such existing system , stories and lesson learned , collection and origination of any meaningful information.

        2. Convert Use cases to classes and objects

        3. Use Textual analysis for identify domain objects.

• • • 3. Thumb Rules

• • • • 1. Never try to solve big problem

        2. Split large problem into smallest possible problem

        3. Start working with small problem set one at a time and start design to delivery iteration.

        4. Always prefer to start with the feature (Problem Set) that is architecturally most significant

        5. Always Defer Details (such as cosmetic issues) as long as you can

        6. In early development cycle never pickup the feature does not contribute to reduce risk.

        7. Hold on writing code as long as you can.

        8. Avoid writing custom code as long as you can

• • 3. Design

• • • 1. Defines classes and Behavior and interrelationship

      2. Object Object Oriented Concepts

         1. Abstraction

         2. Encapsulation

         3. Polymorphism

         4. Inheritance

      3. Defines Objects and interrelation ships

      4. Apply Object Oriented Principles

• • • • 1. Open Close Principle (OCP)

           1. Classes should be closed for modification and open for extension.

           2. It recommend to program to interface (or abstract abstract version).

        2. Single Responsibility Principle (SRP)

• • • • • 1. There should be only one reason to change

          2. Encapsulate what varies.

          3. Prefer High Cohesion (single responsibility) and low coupling

          4. Always do a Commonality Vs Variability analysis while identifying Classes in your system

• • • • 3. Don`t Repeat yourself

• • • • • 1. Never write even single line of duplicate code , make them a shared code

• • • • 4. Liskov substitution principle (LSP)

• • • • • 1. Subclass(derived class) must be behaviorally equal to their base types.

          2. Any overriding violates this principle to avoid overriding as long as you can.

          3. It recommend to prefer Delegation over Inheritance if you do not need to modify the behavior of other class.

          4. It recommend to prefer Composition over Aggregation

          5. Prefer Property Map instead of inheritance

          6. Inheritance should be last option for extension

          7. This is very important principle that if applied correctly then eliminate lot of problems so apply it very carefully.

• • • 5. Apply patterns

      6. Finalize Development Pattern

• • • • 1. Use Case driven

        2. Feature Driven Development

        3. Test Driven Development

• • • 7. Programming Pattern

• • • • 1. Contractual Programming

           1. It assumes other developer and third parties will obey the contract that may not always true.

        2. Defensive Programming

• • • • • 1. it never believe in other code and protect it self as much as it can.

          2. However it cause overhead so a right balance need to be find between contractual and defensive programming

• • • 8. Finalize Programming Model

• • • • 1. Procedural , APM, CEP, EPM

• • • 9. Note: Most of the time programming patterns are driven by underlying development technology, for example Silverlight only supports APM.

• • 4. Implementation

• • • 1. Do coding and development

      2. Develop and execute Unit Testing

      3. Initial Delivery and end used feedback

      4. With user feedback go back to requirement phase if you feel so

• • 5. It is not required to accommodate all the end user feedback immediately but to keep adding analysing them in back log list keep the door open.

    6. Change Analysis

• • • 1. Expose your software/developed features to possible changes

      2. Collate result of impact analysis.

      3. Revisit your design and go back to design phase.

      4. Keep repeating till it looks good.

• • 7. Final Integration and testing

    8. Final Delivery

Notes