Lecture - 8 - Software Engineering - II Fall 2009 Click to...

Info iconThis preview shows pages 1–8. Sign up to view the full content.

View Full Document Right Arrow Icon
Click to edit Master subtitle style Software Engineering - II Fall 2009
Background image of page 1

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
Responsibilities and Responsibility-Driven Design A popular way of thinking about the design of software objects and also larger-scale components is in terms of responsibilities, roles, and collaborations Software objects as having responsibilities – an abstraction of what they do UML defines the responsibilities as “a contact or obligation of a classifier” Related to the obligations or behavior of an object in terms of its role
Background image of page 2
Responsibilities and Responsibility-Driven Design Doing responsibilities of an object include: Doing something itself, such creating an object or doing a calculation Initiating action in other objects Controlling and coordinating activities in other objects Knowing responsibilities of an object include: Knowing about private encapsulated data Knowing about related objects Knowing about things it can drive or calculate
Background image of page 3

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
Responsibilities and Responsibility-Driven Design Responsibilities are assigned to classes of objects during object design. For example: I may declare that “a sale is responsible for creating SalesLineItems” (a doing), or “a sale is responsible for knowing its total: (a knowing)
Background image of page 4
Responsibilities and Responsibility-Driven Design Software Domain Objects, the domain model, because of the attributes and associations it illustrates, often inspires the relevant responsibilities related to “knowing”. For example: If the domain model Sale class has a time attribute, it’s natural by the goal of low representational gap that the Software Sale class knows its time
Background image of page 5

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
Responsibilities and Responsibility-Driven Design Responsibility is not the same thing as a method It’s an abstraction Methods fulfill responsibilities RDD also includes the idea of collaboration Implemented by means of methods that either act alone or collaborate with other methods and objects Sale class might define one or more methods to know its total; say a method named getTotal. To fulfill that responsibility, the sale may collaborate with other objects, such as sending a getSubTotal message to each SalesLineItem object asking for its subtotal
Background image of page 6
GRASP: A Methodical Approach to Basic OO Design GRASP names and describes some basic principles to assign responsibilities, so it’s useful to know A Learning Aid for Object-Oriented Design with
Background image of page 7

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
Image of page 8
This is the end of the preview. Sign up to access the rest of the document.

This note was uploaded on 03/28/2011 for the course CS 643 taught by Professor Naumanriazchaudhry during the Spring '11 term at École Normale Supérieure.

Page1 / 25

Lecture - 8 - Software Engineering - II Fall 2009 Click to...

This preview shows document pages 1 - 8. Sign up to view the full document.

View Full Document Right Arrow Icon
Ask a homework question - tutors are online