TK2023 Object-Oriented Software Engineering

CHAPTER 12

Introduction to Responsibility-Driven Design

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.

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 casenames

systemoperations

Use Case Diagram

Process Sale

1 . Customer

arrives ...

2 . ...

3 . Cashier

enters item

identifier .

ideas for

the post -

conditions

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.

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

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

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

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.

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

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”

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.

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”

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.