Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
SlideShare a Scribd company logo

Software Design Trilogy Part I - Responsibility Driven Design for Rubyists

•Download as PPTX, PDF•
•
Andy Maleh
Andy Maleh

The document discusses responsibility driven design, an object oriented design approach that focuses on identifying the responsibilities needed to perform required actions and assigning those responsibilities to appropriate objects. It outlines the responsibility driven design process, provides an example, and discusses related concepts like responsibility based modeling, GRASP patterns, and a consolidated design process. An exercise walks through identifying responsibilities and objects for a sample requirement to search for deals near a user's location.

1 of 32
Responsibility Driven Design for Rubyists An Outside-In OO Design Approach Software Design Trilogy – Part I Prepared and Presented by: Andy Maleh / Software Engineer / Groupon
Outline Pop Quiz Responsibility Driven Design Responsibility Based Modeling GRASP Consolidated OO Design Process Exercise
Pop Quiz What was the first object oriented language? Simula 67 - developed in the 1960s at the Norwegian Computing Center in Oslo
Pop Quiz What are the key features/traits of Object Oriented Programming? Data Abstraction Encapsulation Messaging Modularity Inheritance Polymorphism
Responsibility Driven Design Object oriented design technique that came from Rebecca Wirfs-Brock Reaction to Data-Driven Design’s lack of encapsulation for object data Focuses on object responsibilities and collaborations Object interaction follows a client/server model
Responsibility Driven Design Process 1. Identify actions that must be taken to accomplish user goals in a software system 2. Identify responsibilities needed to perform these actions including information sharing responsibilities 3. Identify objects most suitable for responsibilities 4. Identify object collaborations needed to fulfill responsibilities, discovering new objects in the process 5. Iterate
Responsibility Driven Design Example Action: Add new address for user, validating address, and filling in zip code automatically. Responsibilities: User information storage Address information storage Validate address Retrieve zip code for address
Responsibility Driven Design Example Objects: User (stores user info) Address (stores address info, validates address) AddressFactory (creates new address, validates address, fills in zip code) ZipCodeService (retrieves zip code for address)
Responsibility Based Modeling Responsibility Driven Design inspired technique by Alistair Cockburn that helps developers start design from the business domain model and use cases Often begins with higher-level component design and then delves down into object design Use case scenario steps act as the actions for which responsibilities must be identified (alternatively Given/When/Then scenarios in Rubyland) Objects can be identified using CRC cards or object interaction diagramming
CRC Cards CRC stands for Class Responsibilities Collaborations Interactive paper exercise for discovering objects and collaborations Can be done collaboratively by multiple developers
CRC Cards CRC stands for Class Responsibilities Collaborations Interactive paper technique for discovering object and collaborations based on identified high level responsibilities http://www.madsen.us/uop/BSA375/handouts.htm
CRD Cards http://www.item.ntnu.no/people/personalpages/others/kraemer/phd/background
Object Interaction Diagramming Documents collaborations needed between objects to accomplish a user goal Helps developers discover objects and responsibilities The two most commonly used object interaction diagrams are: UML 2 Sequence Diagram UML 2 Communication Diagram
Sequence Diagram
Communication Diagram
GRASP GRASP: General Responsibility Assignment Software Patterns They help developers figure out how to assign object responsibilities and evaluate design decisions Contemplated collectively instead of one at a time Provide the underpinnings for object oriented design Help explain how design patterns are arrived to
GRASP 1. Creator: isolates object creation responsibilities 2. Information Expert: the object that holds the data performs the modification on the data 3. Controller: orchestrates multiple objects in accomplishing an action 4. Low Coupling: minimize coupling to other objects 5. High Cohesion: increase focus of object responsibilities
GRASP 6. Polymorphism: assign responsibilities based on types to objects of these types 7. Pure Fabrication: fabricate an object to take on a responsibility that needs to be offloaded of another object to improve coupling/cohesion 8. Indirection: decouple two objects by introducing an intermediary to decrease coupling and increase reuse and interchangeability 9. Protected Variations: protect an object from variations of interactions with other objects by substituting the variations with one interaction with a super interface for the other objects and relying on polymorhpism
Consolidated OO Design Process 1. Write functional requirements as use cases 2. Pick one use case and identify use case scenarios (or Given/When/Then) 3. Pick one use case scenario and identify actions 4. For each action, identify responsibilities needed to perform it
Consolidated OO Design Process 5. For each responsibility, identify an object most suitable to fulfill it using GRASP as guidance 6. Review the responsibility assignments done for the picked use case scenario, possibly altering your decisions based on GRASP 7. Repeat until done with all use cases. This is done for one use case at a time and one iteration’s length of requirements at a time in an Agile process (thin slice approach as per Alistair Cockburn)
Exercise Requirement: Ability to navigate deals Use Case: Search for deals near my location Scenario: Given I live in Chicago at 60622 When I sign into the system And I request a search for deals near my location And I specify keywords for finding deals Then I am presented with a collection of deals that match the specified keywords and are ordered by distance in ascending order
Exercise – Responsibilities 1. User lookup 2. User authentication 3. User information (including address) 4. User interaction request handling 5. Presentation of search input form 6. Search Form input handling
Exercise – Responsibilities 6. Searching for deals 7. Ordering of search results 8. Retrieval of deal information 9. Presentation of deal information
Exercise – Objects 1. User lookup: UserRepository (High Cohesion) 2. User authentication: AuthenticationService (Pure Fabrication, High Cohesion) 3. User Information: User (Information Expert) 4. User interaction request handling: DealSearchController (Controller) 5. Presentation of search form: SearchInputForm (Information Expert) 6. Search form input handling: DealSearchController (Controller)
Exercise – Objects 6. Searching for deals: DealSearchService (Pure Fabrication, High Cohesion) 7. Ordering of search results: DealSearchService (Pure Fabrication, High Cohesion) 8. Retrieval of deal information: DealRepository (High Cohesion) 9. Presentation of deal information: DealView (Pure Fabrication, High Cohesion, Indirection)
Exercise – Notes • Objects can have methods that represent responsibilities they do not directly perform, yet delegate to collaboration objects • Example: User has a sign_in method, but the work is performed behind the scenes with the AuthenticationService
Exercise – Notes on Ruby on Rails • Repositories and the objects they retrieve live in the same object with ActiveRecord. Think of the repository as the “Ruby class object” and the object it retrieves as the “Ruby class instance object” • Views are split into a template file (e.g. ERB or HAML) and a presenter object if needed to handle the presentation logic of the view. Rails Helpers often act as presenters though since they already have access to the view data context (Information Expert)
Personal Exercise Create CRC Cards for the responsibilities we identified Diagram the object interaction for the responsibilities we identified (Sequence or Communication)
Review Pop Quiz Responsibility Driven Design Responsibility Based Modeling GRASP Consolidated OO Design Process Exercise
Stay Tuned for More Stay tuned for more in the Software Design Trilogy: Part II: Design Patterns for Rubyists – Who Said Dynamic Languages Can't Have Patterns? Part III: Domain Driven Design in RoR Apps – When Controllers and ActiveRecords Won't Cut It Anymore
Contact Info Andy Maleh / Software Engineer / Groupon Blog: http://andymaleh.blogspot.com Twitter: @AndyMaleh
References Responsibility Driven Design:http://wirfs- brock.com/PDFs/Responsibility- Driven.pdf Responsibility Based Modeling: http://alistair.cockburn.us/Responsibility- based+modeling GRASP: http://www.amazon.com/Applying-UML- Patterns-Introduction-Object-Oriented/dp/0131489062

More Related Content

Software Design Trilogy Part I - Responsibility Driven Design for Rubyists

  • 1. Responsibility Driven Design for Rubyists An Outside-In OO Design Approach Software Design Trilogy – Part I Prepared and Presented by: Andy Maleh / Software Engineer / Groupon
  • 2. Outline Pop Quiz Responsibility Driven Design Responsibility Based Modeling GRASP Consolidated OO Design Process Exercise
  • 3. Pop Quiz What was the first object oriented language? Simula 67 - developed in the 1960s at the Norwegian Computing Center in Oslo
  • 4. Pop Quiz What are the key features/traits of Object Oriented Programming? Data Abstraction Encapsulation Messaging Modularity Inheritance Polymorphism
  • 5. Responsibility Driven Design Object oriented design technique that came from Rebecca Wirfs-Brock Reaction to Data-Driven Design’s lack of encapsulation for object data Focuses on object responsibilities and collaborations Object interaction follows a client/server model
  • 6. Responsibility Driven Design Process 1. Identify actions that must be taken to accomplish user goals in a software system 2. Identify responsibilities needed to perform these actions including information sharing responsibilities 3. Identify objects most suitable for responsibilities 4. Identify object collaborations needed to fulfill responsibilities, discovering new objects in the process 5. Iterate
  • 7. Responsibility Driven Design Example Action: Add new address for user, validating address, and filling in zip code automatically. Responsibilities: User information storage Address information storage Validate address Retrieve zip code for address
  • 8. Responsibility Driven Design Example Objects: User (stores user info) Address (stores address info, validates address) AddressFactory (creates new address, validates address, fills in zip code) ZipCodeService (retrieves zip code for address)
  • 9. Responsibility Based Modeling Responsibility Driven Design inspired technique by Alistair Cockburn that helps developers start design from the business domain model and use cases Often begins with higher-level component design and then delves down into object design Use case scenario steps act as the actions for which responsibilities must be identified (alternatively Given/When/Then scenarios in Rubyland) Objects can be identified using CRC cards or object interaction diagramming
  • 10. CRC Cards CRC stands for Class Responsibilities Collaborations Interactive paper exercise for discovering objects and collaborations Can be done collaboratively by multiple developers
  • 11. CRC Cards CRC stands for Class Responsibilities Collaborations Interactive paper technique for discovering object and collaborations based on identified high level responsibilities http://www.madsen.us/uop/BSA375/handouts.htm
  • 13. Object Interaction Diagramming Documents collaborations needed between objects to accomplish a user goal Helps developers discover objects and responsibilities The two most commonly used object interaction diagrams are: UML 2 Sequence Diagram UML 2 Communication Diagram
  • 15. Communication Diagram
  • 16. GRASP GRASP: General Responsibility Assignment Software Patterns They help developers figure out how to assign object responsibilities and evaluate design decisions Contemplated collectively instead of one at a time Provide the underpinnings for object oriented design Help explain how design patterns are arrived to
  • 17. GRASP 1. Creator: isolates object creation responsibilities 2. Information Expert: the object that holds the data performs the modification on the data 3. Controller: orchestrates multiple objects in accomplishing an action 4. Low Coupling: minimize coupling to other objects 5. High Cohesion: increase focus of object responsibilities
  • 18. GRASP 6. Polymorphism: assign responsibilities based on types to objects of these types 7. Pure Fabrication: fabricate an object to take on a responsibility that needs to be offloaded of another object to improve coupling/cohesion 8. Indirection: decouple two objects by introducing an intermediary to decrease coupling and increase reuse and interchangeability 9. Protected Variations: protect an object from variations of interactions with other objects by substituting the variations with one interaction with a super interface for the other objects and relying on polymorhpism
  • 19. Consolidated OO Design Process 1. Write functional requirements as use cases 2. Pick one use case and identify use case scenarios (or Given/When/Then) 3. Pick one use case scenario and identify actions 4. For each action, identify responsibilities needed to perform it
  • 20. Consolidated OO Design Process 5. For each responsibility, identify an object most suitable to fulfill it using GRASP as guidance 6. Review the responsibility assignments done for the picked use case scenario, possibly altering your decisions based on GRASP 7. Repeat until done with all use cases. This is done for one use case at a time and one iteration’s length of requirements at a time in an Agile process (thin slice approach as per Alistair Cockburn)
  • 21. Exercise Requirement: Ability to navigate deals Use Case: Search for deals near my location Scenario: Given I live in Chicago at 60622 When I sign into the system And I request a search for deals near my location And I specify keywords for finding deals Then I am presented with a collection of deals that match the specified keywords and are ordered by distance in ascending order
  • 22. Exercise – Responsibilities 1. User lookup 2. User authentication 3. User information (including address) 4. User interaction request handling 5. Presentation of search input form 6. Search Form input handling
  • 23. Exercise – Responsibilities 6. Searching for deals 7. Ordering of search results 8. Retrieval of deal information 9. Presentation of deal information
  • 24. Exercise – Objects 1. User lookup: UserRepository (High Cohesion) 2. User authentication: AuthenticationService (Pure Fabrication, High Cohesion) 3. User Information: User (Information Expert) 4. User interaction request handling: DealSearchController (Controller) 5. Presentation of search form: SearchInputForm (Information Expert) 6. Search form input handling: DealSearchController (Controller)
  • 25. Exercise – Objects 6. Searching for deals: DealSearchService (Pure Fabrication, High Cohesion) 7. Ordering of search results: DealSearchService (Pure Fabrication, High Cohesion) 8. Retrieval of deal information: DealRepository (High Cohesion) 9. Presentation of deal information: DealView (Pure Fabrication, High Cohesion, Indirection)
  • 26. Exercise – Notes • Objects can have methods that represent responsibilities they do not directly perform, yet delegate to collaboration objects • Example: User has a sign_in method, but the work is performed behind the scenes with the AuthenticationService
  • 27. Exercise – Notes on Ruby on Rails • Repositories and the objects they retrieve live in the same object with ActiveRecord. Think of the repository as the “Ruby class object” and the object it retrieves as the “Ruby class instance object” • Views are split into a template file (e.g. ERB or HAML) and a presenter object if needed to handle the presentation logic of the view. Rails Helpers often act as presenters though since they already have access to the view data context (Information Expert)
  • 28. Personal Exercise Create CRC Cards for the responsibilities we identified Diagram the object interaction for the responsibilities we identified (Sequence or Communication)
  • 29. Review Pop Quiz Responsibility Driven Design Responsibility Based Modeling GRASP Consolidated OO Design Process Exercise
  • 30. Stay Tuned for More Stay tuned for more in the Software Design Trilogy: Part II: Design Patterns for Rubyists – Who Said Dynamic Languages Can't Have Patterns? Part III: Domain Driven Design in RoR Apps – When Controllers and ActiveRecords Won't Cut It Anymore
  • 31. Contact Info Andy Maleh / Software Engineer / Groupon Blog: http://andymaleh.blogspot.com Twitter: @AndyMaleh
  • 32. References Responsibility Driven Design:http://wirfs- brock.com/PDFs/Responsibility- Driven.pdf Responsibility Based Modeling: http://alistair.cockburn.us/Responsibility- based+modeling GRASP: http://www.amazon.com/Applying-UML- Patterns-Introduction-Object-Oriented/dp/0131489062