1 / 55

Responsibility Driven Design

Responsibility Driven Design. Overview. Use Cases Responsibility-driven design CRC Cards. Use Cases. Use Case : a collection of related success and failure scenarios that describe an actor using a system to support a goal Note: use cases are text stories

dara-craft
Download Presentation

Responsibility Driven Design

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Responsibility Driven Design

  2. Overview • Use Cases • Responsibility-driven design • CRC Cards

  3. Use Cases • Use Case: a collection of related success and failure scenarios that describe an actor using a system to support a goal • Note: use cases are text stories • Actor: something with behavior (e.g. person, another system, an organization) • Scenario: a specific sequence of (inter)actions between actors and a system • One particular story of using a system

  4. Why Use Cases? • A good way to ‘keep it simple’ for both domain experts and requirements providers • User-centric emphasis: emphasize user goals and perspective • Can scale in terms of sophistication and formality • Typically serve as the means of capturing functional/behavioral requirements in context

  5. Common Use Case Formats • Brief: Terse, one-paragraph summary, usually of the main success scenario • Casual: Information paragraph format; multiple paragraphs covering various scenarios • Fully Dressed: All steps and variations written in detail

  6. Use Case Guidelines • Focus on intent; keep the user-interface out (an essential style) • Focus on responsibility; avoid describing internal workings • Write terse use cases • ‘Drill down’ on goals (e.g. prefer ‘identify user’ as opposed to ‘login’) • Take an actor and actor-goal perspective • Focus on understanding what the actor considers a valuable result

  7. Finding Use Cases • Determine the system boundary • Software application? +hardware? +person using system? +organization? • Identify the primary actors • Identify the goals for the primary actors • Define use cases that satisfy the primary goals • Name them according to their goal

  8. Finding Use Cases… • Questions to help find actors/goals • Who starts and stops the system? • Who does user and security management? • Who does system administration? • Does the system respond to “timed” event(s) • Are there external software systems that call upon services of the system?

  9. Evaluating Use Cases • Tests to evaluate whether a use case is properly scoped • The ‘boss’ test: would a boss be happy to hear that you’ve been working all day on that use case • The Elementary Business Process (EBP) test:‘A task performed by one person in one place at one time, in response to a business event, which adds measurable business value’ • The size test: use cases typically contain many steps, and require 3-10 pages of text in ‘fully dressed’ form

  10. Evaluating Use Cases… • What do you think about the following use cases: • Negotiate a Contract • Handle Returns • Log In • Move piece on Gameboard • Caveat: subfunction-level use cases (e.g. Pay by credit) may not meet the evaluation requirements, but are still useful for composition

  11. Goals of OO Analysis • Encourage early exploration, yet provide structure for improving upon initial decisions • Provide simple, conceptual and physical tools to reason about analysis • It should be easy to record and modify decisions • Develop language-independent methods and guidelines

  12. Exploration • The start, analysis is exploratory • Looking for classes of object • Trying out schemes to discover the most natural and reasonable way to abstract a system • What behavior is the application responsible for? • What classes are required to model the application?

  13. Object Analysis • Constructing and understanding a model of key objects and how they cooperate to achieve the system’s goals • Abstracting essential entities and inventing mechanisms

  14. Finding Objects From Use Cases • Attempt to separate the system context from • Devices • Human roles outside the system • Other systems • Within the system context, look for • Things or events remembered (nouns) • Human roles that will be replaced by the system • Information about people, other systems or devices outside the system

  15. Modeling • Idealized • Helps me elaborate object roles, interactions and responses • Fits my style of thinking • Transparently supports and promotes the good things about object technology • Encapsulation (information hiding) • Abstraction • Re-use • Results are easily traceable to system requirements

  16. Modeling Approaches • Data-driven: first find the data, then package it into objects with associated operations • Procedural: start with the computations encapsulated by the object • Event-driven: describe objects in terms of stimuli they handle • Responsibility-driven: define objects in terms of the roles they play

  17. Modeling: Data-Driven • A data-driven horse: a horse in terms of its parts • Head • Tail • Body • Leg (4) • …

  18. Modeling: Data-Driven • Problems: • Internal details of object structure can easily become part of the public definition • Internal details may be spread across collaborators • Classes are likely to be less reusable because their definition reflects their structure

  19. Modeling: Procedural • A procedural horse: a horse in terms of the operations it can perform • Walk • Trot • Canter • Gallop • Bite • Eat • Neigh

  20. Modeling: Event-Driven • An event-driven horse: a horse in terms of the external events it processes • Mount rider • Dismount rider • Start • Stop • Change direction • Change speed • …

  21. Modeling: Responsibility-Driven • A responsibility-driven horse: a horse in terms of its responsibilities • Carry a rider • Run a race • Process hay intomanure • …

  22. Modeling: Responsibility-Driven • Initially focus on what, not how • Define the public interface to an object in terms of the role(s) it will play in the problem domain • The interface should answer: • What actions is this object responsible for performing? • What information is the object responsible for providing?

  23. Modeling: Responsibility-Driven • Strengths: • Improves encapsulation by initially modeling behavior, not structure • Avoids ‘data leaks’ • Object interactions are in terms of services (‘would you do this for me…’) • Helps identify patterns of communication between objects • Stating general responsibilities rather than specific operations/structures helps to identify common abstractions

  24. Modeling: Responsibility-Driven • Responsibility • A related subset of the behavior defined by an object • Initially identify the overall purpose, not the individual operations • Each responsibility may be transformed into one or more messages Horse Responsibility: Carry a rider mountRider goToDestination dismountRiderResponsibility: Process food processFood Responsibilities organize what an object does or reveals

  25. Modeling: Responsibility-Driven • Determining collaborations • Who needs the result of the knowledge? • If the object capable of fulfilling the responsibility itself? If not, what is needed? • From what other object can it acquire what it needs?

  26. Modeling: Responsibility-Driven • Collaboration • When instances of one class make use of some or all of the functionality defined by another class • A request made by one object to another • Collaborations between objects define a contract between these objects • ‘Client’ can ask for results, but not specify how it gets done • ‘Server’ is obligated to do what was requested

  27. Class/Responsibility/Collaborator • Is a technique used to discover classes, their responsibilities and collaborations required to fulfill those responsibilities • Is done for each use case - which is reviewed for references to nouns and verbs • Is usually done by using index cards (CRC Cards)

  28. CRC Cards • Identify the object and its purpose at the top of the card • Underneath, identify its responsibilities and the collaborators required for that responsibility (if any) Person Represents an individual within the scheduling system

  29. Creating CRC Cards • Review the use case for nouns - people, places and things that will be the domain classes • Create an index card for each class • Determine the responsibilities that need to be defined on the classes by reviewing the use case for verbs or actions • Assign responsibilities to the appropriate class • Examine the responsibilities for those that cannot be accomplished solely by the assigned class • Determine the necessary collaborators for such responsibilities

  30. Activity: CRC Cards • Generate CRC cards from the use cases for a scheduling system

  31. Example CRC Cards - Room Room

  32. Example CRC Cards - Person Person

  33. Example CRC Cards - Appt. Appointment

  34. Example CRC Cards - Meeting Meeting (a type of Appointment)

  35. Example CRC Cards - Schedule Schedule

  36. Domain Modeling

  37. Domain Model • A domain model is a visual representation of conceptual classes in a domain • Typically expressed using UML class diagrams at a conceptual perspective • It is not a visualization of software objects (e.g. Window, database, etc.) • It is not the same as a data model

  38. Creating a Domain Model • Find the conceptual classes (using CRC, etc.) • Draw them as classes in a UML class diagram • Add associations & attributes (within the bounds of the current iteration…)

  39. Finding Conceptual Classes • Reuse or modify existing models • There are published & well-crafted domain & data models for many common domains • Use a category list • Identify noun-phrases

  40. Conceptual Class Categories

  41. Conceptual Class Categories…

  42. Creating a Domain Model • Find the conceptual classes (using CRC, etc.) • Draw them as classes in a UML class diagram (more on this momentarily) • Add associations & attributes

  43. Creating a Domain Model • Find the conceptual classes (using CRC, etc.) • Draw them as classes in a UML class diagram • Add associations & attributes

  44. Associations • An association is a relationship between classes that indicates some meaningful and interesting connection • Usually imply knowledge of a relationship that needs to be preserved for some duration • i.e. what objects do we need some memory of a relationship • Associations in domain modeling are not statements about the software solution (e.g. data flows, foreign key relationships, instance variables, object connections, etc.)

  45. Finding Associations

  46. Attributes • An attribute is a logical data value of an object • Include attributes that the requirements imply a need to remember • Note: attributes in the domain model should preferably be data types • Values for which unique identity is not meaningful (i.e. value objects) • Typically immutable • Note: do not represent foreign-key attributes

  47. Common Data Types When to define new data types? If it is composed of separate sections (e.g. phone number, name of person) There are operations associated with it (e.g. social security number) It has other attributes (e.g. promotional price) It is a quantity with a unit (e.g. currency) Data Types

  48. Results of the Analysis • The result of the responsibility-driven analysis process is a description of • The domain model of objects within the system • The responsibilities of those objects • The collaborations between those objects • A rough idea of the object roles

  49. Analysis Guidelines • Make object behavior cohesive • Don’t assign too many disparate responsibilities to one object • Group related knowledge and behavior • Keep knowledge about one thing in one place • Distribute system intelligence • State responsibilities generally

  50. Analysis Guidelines… • Distribute system intelligence • Avoid single ‘controller’ classes • Reduces most other classes to the level of data structures • Pros/Cons of distributed intelligence • - More study is required to understand control and flow of information • + Any single object will know about relatively fewer objects (less coupling) • + Changes are typically localized • + Relatively fewer classes needed

More Related