Lecture 4: Design Concepts of Responsibility-Driven Design1 of 25© University of Colorado, 2005January 20, 2005Lecture 4: Design Concepts For Responsibility-Driven DesignKenneth M. AndersonJanuary 20, 2005Lecture 4: Design Concepts of Responsibility-Driven Design2 of 25© University of Colorado, 2005January 20, 2005Lecture 4: Design Concepts For Responsibility-Driven DesignIntroductionChapter 1 of Object Design covers topics that aid understanding of Responsibility-Driven DesignObject MachineryRolesRole StereotypesResponsibilities and CollaborationsObject ContractsPre- and Post- ConditionsDomain ObjectsApplication-Specific ObjectsDesign PatternsFrameworksArchitectureLecture 4: Design Concepts of Responsibility-Driven Design3 of 25© University of Colorado, 2005January 20, 2005IntroductionChapter 1 of Object Design covers topics that aid understanding of Responsibility-Driven DesignArchitectureArchitectural StylesControl StylesExample: Layered ArchitectureLecture 4: Design Concepts of Responsibility-Driven Design4 of 25© University of Colorado, 2005January 20, 2005IntroductionObject MachinerySoftware as a biological systemLike cells, software objects don't know what goes on inside one another (encapsulation) but they communicate (message passing) and work together to perform complex tasks (delegation and collaboration)A software system's dynamic behavior emerges from the interactions of many objectsObject ResponsibilitiesLecture 4: Design Concepts of Responsibility-Driven Design5 of 25© University of Colorado, 2005January 20, 2005Object MachineryObject Responsibilitiesan objectknowsinformationmaintainsconnectionsperformsservicesmakesdecisionsCommon Object Design TermsAn application is a set of interacting objectsAn object is an implementation of one or more rolesA role is a set of related responsibilitiesA responsibility is an obligation to perform a task or know informationA collaboration is an interaction of objects or roles (or both)A contract is an agreement outlining the terms of a collaborationLecture 4: Design Concepts of Responsibility-Driven Design6 of 25© University of Colorado, 2005January 20, 2005Object MachineryRolesObjects should have a specific purpose to play within a software system, i.e., a roleRoles are powerful because they allow objects that implement a role to be used interchangeablyRoles can be implemented using interfaces and compositionRole StereotypesStereotypes are "purposeful oversimplifications" to give designers a target for defining rolesThe following stereotypes have proven useful over timeInformation Holder: knows and provides informationStructurer: maintains relationships between objects and information about those relationshipsService Provider: performs workCoordinator: reacts to events by delegating tasks to othersController: makes decisions and closely directs the actions of other objectsLecture 4: Design Concepts of Responsibility-Driven Design7 of 25© University of Colorado, 2005January 20, 2005RolesRole StereotypesThe following stereotypes have proven useful over timeCoordinator: reacts to events by delegating tasks to othersController: makes decisions and closely directs the actions of other objectsInterfacer: transforms information and requests between distinct parts of a software systemObjects will often fit more than one stereotype, e.g., information holders will often provide servicesA designers goal will be to decide what to emphasize and to strive to provide a clear cut role for each objectResponsibilities and CollaborationsResponsibilities are assigned to rolesRoles are implemented by objectsIf an object implements a role, it decides to accept the role's responsibilitiesObjects work together to fulfill responsibilitiesThese object networks are called collaborationsA designer's task is to distribute responsibilities (roles) across a set of "intelligent" objects that can collaborate with each other such that all responsibilities are fulfilledLecture 4: Design Concepts of Responsibility-Driven Design8 of 25© University of Colorado, 2005January 20, 2005RolesResponsibilities and CollaborationsA designer's task is to distribute responsibilities (roles) across a set of "intelligent" objects that can collaborate with each other such that all responsibilities are fulfilledAn "intelligent" object is one that has the right blend of information that it know about and services it can provide because of that informationyou don't want to make any one object too powerful or too weak; the former tend to dominate designs in a bad way, reducing the use of encapsulation, inheritance, polymorphism, etc.; the latter tend not to provide much utility to the system overallWe will see specific examples of roles, responsibilities, and collaborations as we delve into responsibility-driven design over the next few weeksObject ContractsObjects exist within an environment consisting of other objectsIt is often helpful to specify during analysis and design the "contract" an object has with this environmentLecture 4: Design Concepts of Responsibility-Driven Design9 of 25© University of Colorado, 2005January 20, 2005RolesObject ContractsIt is often helpful to specify during analysis and design the "contract" an object has with this environmentHere, a contract refers to specifying the conditions under which an object guarantees its work (pre-conditions) and the effects it leaves behind when its work is complete (post-conditions)There are a number of ways this type of information can be documented; A particularly useful method is the use of "assert()" mechanisms in programming languagesAt the start of each method, you place assert statements that specify the method's per-conditions; At the end of the method, you place assert statements that specify the post-conditions. At run-time, if an assert fails (evaluates to false), an exception is thrownLecture 4: Design Concepts of Responsibility-Driven Design10 of 25© University of Colorado, 2005January 20, 2005RolesDomain ObjectsDesigners and Users need a common vocabularyThis vocabulary allows designers to learn about the user's domain and to understand the requirements being provided by the userThis vocabulary often takes the form of a glossary but it can be much more useful if its incorporated into the object model of the system under designThis "vocabulary term as object" is considered a domain objectProblem ContextIn the analysis and design of software systems, we face the following situationProblem
View Full Document
Unlocking...