1. OO Design Roshan Chitrakar

2. Analysis to Design Do the RIGHT thing Do the RIGHT thing Requirement Analysis Requirement Analysis Domain Modeling with addition of attributes and associations Domain Modeling with addition of attributes and associations Use Case Modeling (Behavioral modeling) Use Case Modeling (Behavioral modeling) Requisite Pro and Use case diagrams Requisite Pro and Use case diagrams Do the thing RIGHT Do the thing RIGHT Responsibility assignment Responsibility assignment Object Design Object Design Design Class diagrams Design Class diagrams Determining visibility Determining visibility Interaction diagrams (Sequence diagrams & Collaboration diagrams, Class diagram) Interaction diagrams (Sequence diagrams & Collaboration diagrams, Class diagram)

3. OO Design: Introduction A logical solution based on OO paradigm is developed A logical solution based on OO paradigm is developed Constitutes a design model Constitutes a design model Creation of Interaction diagrams (collaboration among objects and/or sequence of messages) Creation of Interaction diagrams (collaboration among objects and/or sequence of messages) Class diagrams are drawn in parallel with or after the interaction diagrams Class diagrams are drawn in parallel with or after the interaction diagrams

4. GRASP Fundamental principles of Object design are: - Fundamental principles of Object design are: - Responsibility assignment and Responsibility assignment and Design patterns Design patterns GRASP (General Responsibilities Assignment Software Patterns) describe the principles of object design and responsibility assignment, expressed as patterns. GRASP (General Responsibilities Assignment Software Patterns) describe the principles of object design and responsibility assignment, expressed as patterns.

5. Responsibility It is a contract or obligation of a classifier It is a contract or obligation of a classifier It is assigned to classes during object design It is assigned to classes during object design Type of Responsibilities Type of Responsibilities Knowing (e.g. “a Sale is responsible for knowing its total”) Knowing (e.g. “a Sale is responsible for knowing its total”) about private encapsulated data about private encapsulated data about related objects about related objects about things it can derive or calculate about things it can derive or calculate Doing (e.g. “a Sale is responsible for creating SalesLineItems”) Doing (e.g. “a Sale is responsible for creating SalesLineItems”) something itself something itself initiating action in other objects initiating action in other objects controlling and coordinating activities in other objects controlling and coordinating activities in other objects

6. Methods Responsibilities are translated into methods Responsibilities are translated into methods Depending upon the granularity, several methods are implemented to fulfill the responsibilities Depending upon the granularity, several methods are implemented to fulfill the responsibilities Methods either act alone or collaboratively Methods either act alone or collaboratively Both responsibilities and methods are reflected in interaction diagrams Both responsibilities and methods are reflected in interaction diagrams

7. Responsibility & Methods in Interaction Diagram makePayment(cashTendered) create(cashTendered) : Sale : Payment Responsibility: To create Payments

8. Patterns A pattern is a named problem/solution pair that can be applied in new context, with advice on how to apply it in novel situation and discussion of its trade-offs. e.g. Pattern Name: Information Expert Solution: Assign a responsibility to the class that has the information needed to fulfill it. Problem It Solves: What is a basic principle by which to assign responsibilities to objects. A pattern is a named problem/solution pair that can be applied in new context, with advice on how to apply it in novel situation and discussion of its trade-offs. e.g. Pattern Name: Information Expert Solution: Assign a responsibility to the class that has the information needed to fulfill it. Problem It Solves: What is a basic principle by which to assign responsibilities to objects.

9. The First Five GRAS Patterns They are: - They are: - 1. Information Expert (or Expert) 2. Creator 3. High Cohesion 4. Low Coupling 5. Controller They cover very basic, common and fundamental design issues They cover very basic, common and fundamental design issues

10. Information Expert It guides that objects do things related to the information they have. It guides that objects do things related to the information they have. It is a class that has information necessary to fulfill the responsibility It is a class that has information necessary to fulfill the responsibility There may have partial information experts who will collaborate for the responsibility There may have partial information experts who will collaborate for the responsibility Design Class Responsibility Sale Knows sale total SalesLineItem Knows line item subtotal ProductSpecification Knows product price

11. Expert Illustration : To find out the grand total Domain model showing association of Sale

12. Expert Illustration : To find out the grand total Knowing Line Item sub total and knowing product price in order to get the grand total. Responsibilities are being added to both interaction and Class diagrams also. More than one class can act as information expert. They collaborate by passing messages.

13. Expert: Pro and Cons Advantages: - Advantages: - Encapsulation is maintained Encapsulation is maintained Behavior is distributed across the classes Behavior is distributed across the classes Disadvantages: - Disadvantages: - Leads to problems of coupling, cohesion and duplication Leads to problems of coupling, cohesion and duplication

14. Creator It guides assigning responsibilities related to the creation of objects It guides assigning responsibilities related to the creation of objects The concept of aggregation is the basic guiding principle of the Creator. The concept of aggregation is the basic guiding principle of the Creator. It suggests that the enclosing container or recorder class is a good candidate for the responsibility It suggests that the enclosing container or recorder class is a good candidate for the responsibility

15. Creator Illustration : Creating a Sales Line Item Sale Domain

16. Creator Illustration : Creating a Sales Line Item

17. Creator: Pro and Cons Benefits: - Benefits: - Low coupling is supported i.e lower maintenance dependence and higher possibility of reuse. Low coupling is supported i.e lower maintenance dependence and higher possibility of reuse. Contraindications: - Contraindications: - In special cases, all creations are delegated to a helper class called Factory. (Which is against the principle of Creator) In special cases, all creations are delegated to a helper class called Factory. (Which is against the principle of Creator)

18. Low Coupling It suggests assigning a responsibilities to classes such that their placement does not produce negative results. It suggests assigning a responsibilities to classes such that their placement does not produce negative results. It recommends designs of classes to be more independent and hence reduce the impacts of change. It recommends designs of classes to be more independent and hence reduce the impacts of change. No absolute measure of low/high coupling, designer has to assess it so that negative results would not occur. No absolute measure of low/high coupling, designer has to assess it so that negative results would not occur.

19. Low Coupling Illustration : Creating a Payment PaymentRegisterSale Creator pattern suggests Register as a candidate for creating the Payment. Coupling of Register class to the knowledge of Payment class

20. Low Coupling Illustration : Creating a Payment An alternate solution: Coupling of Sale class with the Payment class Sale creates the Payment; does not increase the coupling

21. High Cohesion “High functional cohesion exists when the elements of a component (e.g. a class) all work together to provide some well-bounded behavior”- Booch “High functional cohesion exists when the elements of a component (e.g. a class) all work together to provide some well-bounded behavior”- Booch High Cohesion has fewer methods, with highly related functionality, collaborates with other objects to share the effort. High Cohesion has fewer methods, with highly related functionality, collaborates with other objects to share the effort. High Cohesion pattern has real world analogy or delegating the too much work. High Cohesion pattern has real world analogy or delegating the too much work.

22. High Cohesion Illustration : Creating a Payment Register creates the Payment by taking the work by itself: Low cohesion

23. High Cohesion Illustration : Creating a Payment Register delegates the work to Sale : Low cohesion

24. High Cohesion: Pro and Cons Advantages: - Advantages: - Maintenance and enhancement is simplified Maintenance and enhancement is simplified Low coupling is often supported Low coupling is often supported Reuse is increased. Reuse is increased. Disadvantages: - Disadvantages: - Distributed servers take more overhead and pay reduced performance Distributed servers take more overhead and pay reduced performance For only one person to maintain and support the component, it is difficult. For only one person to maintain and support the component, it is difficult.

25. Controller It provides guidance for handlers for external inputs / events messages or signals that system receives. It provides guidance for handlers for external inputs / events messages or signals that system receives. It delegates, coordinates and controls the work to other objects: does not do the actual work. It delegates, coordinates and controls the work to other objects: does not do the actual work. The System class made during the analysis phase, is now taken care of by Controller class. The System class made during the analysis phase, is now taken care of by Controller class.

26. System Class to Controller Class Register acts as the single Controller Class Two handlers act like Controllers

27. Controller Illustration : enterItem()

28. Possible handlers are: - : Register enterItem(id,quantity) : ProcessSaleHandler enterItem(id,quantity)

29. Controller: Pro and Cons Increased potential for reuse Increased potential for reuse Pluggable interface (i.e. application logic is not handled in the interface layer) Pluggable interface (i.e. application logic is not handled in the interface layer) It guarantees that system operations within a use case occur in a legal sequence (It is possible if the same controller is used throughout the use case) It guarantees that system operations within a use case occur in a legal sequence (It is possible if the same controller is used throughout the use case)