12 Intro To Rdd


Published on

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

12 Intro To Rdd

  1. 1. TK2023 Object-Oriented Software Engineering CHAPTER 12 Introduction to Responsibility-Driven Design
  2. 2. INTRODUCTION <ul><li>UML is only a visual modelling language. Knowing UML doesn’t teach you how to think in objects. </li></ul>The critical design tool for software development is a mind well educated in design principles.
  3. 3. REVIEW OF ANALYSIS ARTIFACTS Operation : enterItem ( … ) Post - conditions : - . . . Operation Contracts Sale date . . . Sales LineItem quantity 1 .. * 1 . . . . . . Domain Model Use-Case Model : System enterItem ( id , quantity ) Use Case Text System Sequence Diagrams make NewSale () system events Cashier Process Sale : Cashier use case names system operations Use Case Diagram Process Sale 1 . Customer arrives ... 2 . ... 3 . Cashier enters item identifier . ideas for the post - conditions
  4. 4. ACTIVITIES OF OBJECT DESIGN <ul><li>The artifacts created during analysis become inputs to object design. </li></ul><ul><ul><li>Use case text </li></ul></ul><ul><ul><ul><li>During OO design, use case realizations are designed to realize use cases. </li></ul></ul></ul><ul><ul><li>Supplementary specification </li></ul></ul><ul><ul><ul><li>This defines the non-functional goals that need to be satisfied by objects. </li></ul></ul></ul><ul><ul><li>System sequence diagrams </li></ul></ul><ul><ul><ul><li>The system operation messages in the SSDs become the starting messages in the interaction diagrams. </li></ul></ul></ul>
  5. 5. <ul><ul><li>Glossary </li></ul></ul><ul><ul><ul><li>The Glossary clarifies details of parameters or data coming in from the UI layer, data being passed to the database, and detailed item-specific logic or validation requirements. </li></ul></ul></ul><ul><ul><li>Operation contracts </li></ul></ul><ul><ul><ul><li>Operation contracts may complement the use case text to clarify what the software objects must achieve in a system operation. </li></ul></ul></ul><ul><ul><li>Domain model </li></ul></ul><ul><ul><ul><li>The domain model suggests some names and attributes of software domain objects in the domain layer of the software architecture </li></ul></ul></ul>
  6. 6. <ul><li>The overall approach to doing the OO design modelling will be based on the metaphor of responsibility-driven design (RDD). </li></ul><ul><ul><li>In RDD, we think about how to assign responsibilities to collaborating objects. </li></ul></ul><ul><li>During OO design, various OO design principles are applied through design patterns such as GRASP and the Gang-of-Four (GoF). </li></ul>
  7. 7. OUTPUTS OF OBJECT DESIGN <ul><li>The main outputs of object design are the interaction and class diagrams. </li></ul><ul><li>Other outputs: </li></ul><ul><ul><li>Package diagrams </li></ul></ul><ul><ul><li>UI sketches and prototypes </li></ul></ul><ul><ul><li>Database models </li></ul></ul><ul><ul><li>Report sketches and prototypes </li></ul></ul>
  8. 8. RESPONSIBILITIES AND RESPONSIBILITY-DRIVEN DESIGN <ul><li>One way of thinking about the design of software objects is in terms of responsibilities, roles and collaborations. </li></ul><ul><li>In RDD, we think of software objects as having responsibilities. </li></ul><ul><li>The responsibilities of an object refer to its obligations or behaviour in terms of its role. </li></ul><ul><li>Responsibilities are assigned to classes of objects during object design. </li></ul>
  9. 9. <ul><li>Basically, an object has two types of responsibilities: </li></ul><ul><ul><li>“ Doing” responsibilities such as </li></ul></ul><ul><ul><ul><li>doing something itself, such as creating an object or doing a calculation </li></ul></ul></ul><ul><ul><ul><li>initiating action in other objects </li></ul></ul></ul><ul><ul><ul><li>controlling and coordinating activities in other objects </li></ul></ul></ul><ul><ul><li>“ Knowing” responsibilities such as </li></ul></ul><ul><ul><ul><li>knowing about private encapsulated data </li></ul></ul></ul><ul><ul><ul><li>knowing about related objects </li></ul></ul></ul><ul><ul><ul><li>knowing about things it can derive or calculate </li></ul></ul></ul>
  10. 10. <ul><li>Examples (POS): </li></ul><ul><ul><li>responsibility to “calculate the total of a sale” </li></ul></ul><ul><ul><li>responsibility to “know the line items of a sale” </li></ul></ul><ul><ul><li>responsibility to “generate a receipt for a sale” </li></ul></ul><ul><ul><li>responsibility to “handle a new sale” </li></ul></ul>
  11. 11. <ul><li>Guideline: The domain model often inspires “knowing” responsibilities for software domain objects. </li></ul><ul><ul><li>For example, suppose the Sale class has a time attribute in the domain model. We then might assign to the software Sale class a responsibility for knowing the time of sale. </li></ul></ul>
  12. 12. <ul><li>Responsibilities and methods are not the same. Methods fulfill responsibilities. </li></ul><ul><li>The translation of responsibilities into classes and methods is influenced by the granularity of the responsibility. </li></ul><ul><ul><li>Big responsibilities may translate to hundreds of classes and methods. </li></ul></ul><ul><ul><ul><li>Example: responsibility to “provide access to relational databases” </li></ul></ul></ul><ul><ul><li>Small responsibilities might take just one method. </li></ul></ul><ul><ul><ul><li>Example: responsibility to “create a Sale” </li></ul></ul></ul>
  13. 13. <ul><li>RDD also includes the idea of collaboration. Responsibilities are implemented by means of methods that either act alone or collaborate with other methods and objects. </li></ul><ul><li>RDD is a general metaphor for thinking about OO software design. It leads to viewing an OO design as a community of collaborating responsible objects. </li></ul>