1. TK2023 Object-Oriented Software Engineering CHAPTER 12 Introduction to Responsibility-Driven Design

2. INTRODUCTION UML is only a visual modelling language. Knowing UML doesn’t teach you how to think in objects. The critical design tool for software development is a mind well educated in design principles.

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. ACTIVITIES OF OBJECT DESIGN The artifacts created during analysis become inputs to object design.  Use case text During OO design, use case realizations are designed to realize use cases.  Supplementary specification This defines the non-functional goals that need to be satisfied by objects.  System sequence diagrams The system operation messages in the SSDs become the starting messages in the interaction diagrams.

5.  Glossary 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.  Operation contracts Operation contracts may complement the use case text to clarify what the software objects must achieve in a system operation.  Domain model The domain model suggests some names and attributes of software domain objects in the domain layer of the software architecture

6. The overall approach to doing the OO design modelling will be based on the metaphor of responsibility-driven design (RDD).  In RDD, we think about how to assign responsibilities to collaborating objects. During OO design, various OO design principles are applied through design patterns such as GRASP and the Gang-of-Four (GoF).

7. OUTPUTS OF OBJECT DESIGN The main outputs of object design are the interaction and class diagrams. Other outputs:  Package diagrams  UI sketches and prototypes  Database models  Report sketches and prototypes

8. RESPONSIBILITIES AND RESPONSIBILITY-DRIVEN DESIGN One way of thinking about the design of software objects is in terms of responsibilities, roles and collaborations. In RDD, we think of software objects as having responsibilities. The responsibilities of an object refer to its obligations or behaviour in terms of its role. Responsibilities are assigned to classes of objects during object design.

9. Basically, an object has two types of responsibilities:  “Doing” responsibilities such as doing something itself, such as creating an object or doing a calculation initiating action in other objects controlling and coordinating activities in other objects  “Knowing” responsibilities such as knowing about private encapsulated data knowing about related objects knowing about things it can derive or calculate

10. Examples (POS):  responsibility to “calculate the total of a sale”  responsibility to “know the line items of a sale”  responsibility to “generate a receipt for a sale”  responsibility to “handle a new sale”

11. Guideline: The domain model often inspires “knowing” responsibilities for software domain objects.  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.

12. Responsibilities and methods are not the same. Methods fulfill responsibilities. The translation of responsibilities into classes and methods is influenced by the granularity of the responsibility.  Big responsibilities may translate to hundreds of classes and methods. Example: responsibility to “provide access to relational databases”  Small responsibilities might take just one method. Example: responsibility to “create a Sale”

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