Lecture 5 Responsibility-Driven Design

1. Lecture 5Responsibility-Driven Design Object Oriented Analysis and Design K268 SENG2100 Pat Browne Patrick.Browne@comp.dit.ie http://www.comp.dit.ie/pbrowne/ Lecture 2

2. Object Analysis • This lecture is based on “A Brief Tour of Responsibility –Driven Design” by Rebecca J. Wirfs-Brock and Alan McKean, which was resented at OOPSLA 2002: The ACM SIGPLAN Conference on Object-Oriented Programming, Systems, Languages, and Applications • http://www.wirfs-brock.com/pages/resources.html • Last accessed 29-9-2004

3. Object Analysis • Candidate Objects • Information • Essential Behavior • Associations (not strictly part of RDD) • Responsibilities • Collaborations

4. Object Design • Roles, Responsibilities and Collaborations • State Models • Control Architecture • Candidate Classes • Class Inheritance Hierarchies • Design Level Conversations

5. What Is Responsibility-DrivenDesign? • A way to design emphasizing behavioral modeling using objects, responsibilities and collaborations employing informal tools and techniques that enhances development processes from XP (eXtreme Programming) to RUP (Rational Unified Process) with responsibility concepts and thinking • Described in the book Design of Object Oriented Software (DOOS) by Wirfs-Brock, Wilkerson and Wiener.

6. R-DD Principles • Maximize Abstraction: Hide the distinction between data and behavior. We think of responsibilities for “knowing,” “doing,” and “deciding” • Distribute Behavior: Make objects smart— have them behave intelligently, not just hold bundles of data. Objects should not be too lean or too fat • Preserve Flexibility: Design objects and collaborations so they can be readily changed

7. R-DD Constructs • an application = a set of interacting objects • an object = an implementation of one or more roles • a role = a set of related responsibilities • a responsibility = an obligation to perform a task or know information • a collaboration = an interaction of objects or roles (or both)

8. Responsibility-Driven DesignProcess

9. RDD Summary • Responsibility-Driven Design is a set of tools for thinking, not for documenting (that’s for the UML) • Objects behave by knowing, doing and deciding. Behavior first. Data second • Responsibility-Driven Design can be used in every development project • Responsibility-Driven Design is compatible with all development methods, from the lightest (XP) to the heaviest (RUP)

10. Identifying Objects/classes • In the initial stages of analysis there are various approaches for identifying objects: • Data driven methods focus on the data encapsulated by the object and the operations performed on them. • Process driven methods concentrate on the process encapsulated by an object.

11. Identifying Objects/classes • Event driven methods focus on states encapsulated by the object and the definitions of the events causing state transitions. • An object driven approach focuses on the extraction of the objects existing in the problem domain.

12. Identifying Objects/classes • Responsibility driven methods start with identifying the responsibilities the object determined by the role of the object in carrying out the overall purpose of the system. • RDD enables us to characterize the objects in ways that help you reason about them and their relationships

13. A Software ‘Story’ • Talk about important ideas: • What is your application supposed to do? • How will it support its users? • Is it connected to a real world example that you can study or emulate? • Is it similar to what you have done before? What will make your application a success? • What are the most challenging things to design?

14. Identifying Objects/Classes • Look for inventions that represent: • The work your software performs • The things your software affects or is connected to • The information that flows through your software • Your software’s decision-making, control and coordination activities • Ways to structure and manage groups of objects Representations of real world things your software needs to know something about

15. Look for Objects First, ThenShared Roles • Candidates represent important, vivid abstractions: • concepts, machinery and mechanisms • Initially we think very concretely: We identify candidate objects that represent things that know and do and perform some work in our application • Once we have a few candidates, we can think more abstractly. Looking at candidates, we identify the roles that these objects play and which can be shared by different kinds of objects

16. Identifying Objects/Classes • Candidate classes: • tangible objects; • roles; • events; • organisational units.

17. Identifying Objects/Classes • When looking a system analysts can ask some initial questions • "What processing must this system do?" • "What are the objects and classes involved in this system?" • "Which objects initiate or are acted upon by operations or actions?"

18. Naming Candidates • Fit a name into some naming scheme • Give service providers “worker” names. • Choose a name that suits a role. • Choose names that expand an object’s behavior • Choose a name that lasts a lifetime • Include facts most relevant to its users • Eliminate naming conflicts by adding description

19. Is Requirement Document Enough? • 1. Object oriented systems are modeled using the objects and their relationships. The end user functionality is realized by the interaction of these objects. The objects interact by sending messages to each other. Therefore, objects, relationships and messages are important notions which characterize the object oriented systems. It is difficult to directly identify objects from the requirement documents. Objects fall in multiple categories like physical objects, roles, incidents, interactions and specifications. All this may not be easily visible in the requirement document.

20. Is Requirement Document Enough? • 2. Object oriented systems manage complexity through abstraction and encapsulation. Objects encapsulate a definite behavior. The requirement documents do not correctly indicate the amount of behavior encapsulated in each objects. • 3. Object Oriented systems tend to encourage reuse by factoring out common responsibilities into independent classes. The requirements documents fail to indicate how much factoring is possible.

21. Is Requirement Document Enough? • 4. Requirements set in the beginning of the software tend to change. Therefore, the causal analysis based on systems characteristics extracted from initial requirement specification needs to be corrected. For efficient feedback we require characterizations which can be re­evaluated consistently throughout the various phases of the software development cycle.

22. Classes in Specification • The main technique for indentifying classes from a statement of requirement is noun analysis. Appropriate classes are frequently suggested by the nouns or noun phrases that occur within the text of a statement of requirements.

23. Associations • An association is a connection between two objects that is significant for the application area. • The relationships between objects are represented as associations between the classes of which the objects are instances.

24. Associations in Specification • Verbs connect nouns and noun phrases in a statement of requirements. Verbs or verb phrases can be used to suggest likely associations(or links) between classes. • For example: • The department is staffed by accountants and auditors. • Each auditor is assigned one job at a time.

25. class-association matrix • For many object models of moderate size, a useful approach is to take the classes that have been identified and pair them together and consider whether an association between the two classes is of significance to the application area – does the application area need to record how instances of the two classes are connected. A thorough, but laborious, way of doing this is via a class-association matrix, where classes are paired, one with another.

26. Responsibilities • State responsibilities at a high level:They are for knowing, doing, deciding, calculating… • Use strong descriptions:The more explicit the action, the stronger the statement. • – Stronger verbs: remove, merge, calculate,credit, activate • – Weaker verbs: organize, record, process, maintain, accept

27. Responsibilities • Behavior for • knowing • Doing e.g. calculating • deciding • Stated at a high level • Assigned to appropriate objects

28. How Do You State Responsibilities? • Don’t express responsibilities as too fine-grained. • They are larger than individual attributes or operations. A single responsibility is often realized by several methods. Example: A Customer object has a name which may be comprised of a first name, surname, middle name, maiden name, and there may be aliases or nicknames. The software Customer “knows its name and preferred ways of being addressed.”

29. Where Do We Find Responsibilities? • Responsibilities come from looking at many different descriptions of system behaviour and then modeling how a community of objects work • Use cases (covered in UML) • Other requirements • Themes and software stories (slide 13) • Gaps in these system descriptions • Role stereotypes • Relationships and dependencies between candidates • Candidates’ “life events” • Technical aspects of a specific software environment • A design perspective on how things should work

30. Stereotypes in RDD • Stereotypes are simplified views that help us characterize object essentials. Use them to characterize the roles objects play in an application • Service providers do things: a Mailer • Interfacers translate requests and convert from one level of abstraction to another: Presenter and Selector • Information holders know things: Letters, Words, Sentences • Controllers direct activities: the Guesser • Coordinators delegate work: the MessageBuilder • Structurers manage object relations: Objects that manage Letters, Words, Sentences and Commands

31. Assigning Responsibilities • Responsibilities should generally match a role’s stereotype. This makes roles cohesive. • Is the responsibility one for “bridging” between neighborhoods or layers? – Use a controller or interfacer • Is it an extremely complex behavior? Or is it prone to change? – Use a service-provider that does little else • Does it involve complex decision-making? – Use a controller • Does it involve many objects of the same type? – Use a structurer

32. Assigning Responsibilities • Keep behaviour with related information. This makes roles efficient • Don’t make any one role too big. This makes roles simple • Distribute intelligence. This makes roles smart • Keep information about one thing in one place. This makes roles safe

33. Make Objects Cohesive • An object should be the sum of its responsibilities. • Everything an object knows or does should contribute directly to its purpose • Avoid “doing favours” that unnecessarily tie objects from different areas of the application to each other. Common favours: conversion from one object type to another, formatting, translation • If you can imagine one object existing without another, don’t give it any responsibilities that require it to know about the other

34. SummaryFinding and Assigning Responsibilities • Object responsibilities are derived from the application responsibilities expressed in many different requirements documents • Responsibilities are distributed among the candidate objects according to the objects’ roles • Responsibilities enable you to think about object behaviours without concern for how the objects perform them • Responsibilities are higher lever abstractions than object methods.

35. Collaboration • Collaborators • A collaborator is is a class whose services are needed to fulfil a responsibility. • Collaborations only exist to fulfil responsibilities.

36. What Drives the Collaborations? • Behaviours described in use cases require object actions and collaborations • The steps of a complex algorithms may be performed by different objects, each responsible for a given step • Internal Events, such as a timer’s timeout, can start a collaboration • External Events from outside devices and programs can set a group of objects into motion

37. Why Does an Object Collaborate? • That’s not my role! • I don’t know enough! • It’s my job to direct others! • I need help! • Why should I do it, too?

38. Early Collaboration Modeling • Concentrate on control, coordination, and important services • Don’t over specify a collaboration • Stop designing collaborations when you can show that your small set of roles fulfils its purpose • Ignore UI details – Treat the UI as a source of events • Decide what the scope of your thinking should be • When working at a high level, think about how subsystems collaborate • When studying details, limit your thinking to a small group of objects

39. Lecture 2

40. Characteristics of CentralizedControl • Generally, one object (the controller) makes most of the important decisions. Decisions may be delegated, but most often the controller figures out what to do next. • Tendencies with this strategy: • Control logic can get overly complex • Controllers can become dependent upon information holders’ contents • Objects can become coupled indirectly through the actions of their controller • The only interesting work is done in the controller

41. Characteristics of DelegatedControl • A delegated control style passes some of the decision making and much of the action off to objects surrounding a control center. Each neighboring object has a significant role to play: • Coordinators tend to know about fewer objects than dominating controllers • Dialogs are higher-level • Changes typically affect a fewer number of objects • It is easier to divide design work among team members

42. Guidelines for Collaborating • Delegate control if possible. Let collaborators be responsible • Look for opportunities to ask for services or direct others’ actions more intelligently • Develop control centers and collaboration patterns. • Look for ways to make similar things work consistently • Exploit polymorphism! It eliminates complexity • Determine regions where trusted collaborations can occur and where extra precautions must be taken to ensure reliable collaborations

43. SummaryDesigning Collaborations • Objects get things done by collaborating • A collaborator is a “helper” object • Collaborations have identifiable styles • Centralized … one controller • Delegated … a few coordinators • Dispersed … no centers of control • Centers of control should be easy to locate • Collaborations should follow a consistent style

44. DOOS • Rebecca Wirfs-brock contributed much to Responsibility-driven design approach. It is a simple idea, and it facilitates the transition from design to programming. It predates the Unified Modelling Language (UML). • DOOS is a responsibility driven design method for OO development. See DOOS.doc for more detail. Lecture 2

45. DOOS Lecture 2

46. DOOS Lecture 2

47. Special Keypad Normal Pad 1 2 3 Display Screen 4 5 6 7 8 9 Cancel Key 0 . Cash Dispenser Deposit Drawer Bank Card Reader Printer Lecture 2

48. ATM in DOOS • An automated teller machine (ATM) is a machine through which bank customers can perform a number of financial transactions. The machine consists of a display screen, a bank card reader, input keys, a money dispenser slot, a deposit slot and a receipt printer. The main menu contains a list of the transactions that can be performed. These transactions include: • deposit funds to an account • withdraw funds from an account • transfer funds from one account to the other • query the balance of an account. Lecture 2

49. ATM class • The ATM class represents the teller machine. Its main operations are to create and initiate transactions. This class acts as a client of both the Financial Subsystem and the User Interface Subsystem. Lecture 2

50. A DOOS ATM collaboration graph Lecture 2