Responsibility-driven design

Composition

The SDD usually contains the following information: The data design describes structures that reside within the software. Attributes and relationships between data objects dictate the choice of data structures. The architecture design uses information flowing characteristics, and maps them into the program structure. The transformation mapping method is applied to exhibit distinct boundaries between incoming and outgoing data. The data flow diagrams allocate control input, processing and output along three separate modules. The interface design describes internal and external program interfaces, as well as the design of human interface. Internal and external interface designs are based on the information obtained from the analysis model. The procedural design describes structured programming concepts using graphical, tabular and textual notations. These design mediums enable the designer to represent procedural detail, that facilitates translation to code. This blueprint for implementation forms the basis for all subsequent software engineering work.

Responsibility-driven design

Responsibility-driven design is a design technique in object-oriented programming, which improves encapsulation by using the client–server model. It focuses on the contract by considering the actions that the object is responsible for and the information that the object shares. It was proposed by Rebecca Wirfs-Brock and Brian Wilkerson. Responsibility-driven design is in direct contrast with data-driven design, which promotes defining the behavior of a class along with the data that it holds. Data-driven design is not the same as data-driven programming, which is concerned with using data to determine the control flow, not class design. In the client–server model they refer to, both the client and the server are classes or instances of classes. At any particular time, either the client or the server represents an object. Both the parties commit to a contract and exchange information by adhering to it. The client can only make the requests specified in the contract and the server must answer these requests.[1] Thus, responsibility-driven design tries to avoid dealing with details, such as the way in which requests are carried out, by instead only specifying the intent of a certain request. The benefit is increased encapsulation, since the specification of the exact way in which a request is carried out is private to the server. Overview Responsibility-driven design focuses on the objects as behavioral abstractions which are characterized by their responsibilities. The CRC-card modelling technique is used to generate these behavioral abstractions. The rest of the object structure including data attributes are assigned later, as and when required.[2] This makes the design follow type hierarchy for inheritance which improves encapsulation and makes it easier to identify abstract classes. It can also group the classes together based on their clients which is considered a unique ability. A good object-oriented design involves an early focus on behaviors to realize the capabilities meeting the stated requirements and a late binding of implementation details to the requirements. This approach especially helps to decentralize control and distribute system behavior which can help manage the complexities of high-functionality large or distributed systems. Similarly, it can help to design and maintain explanation facilities for cognitive models, intelligent agents, and other knowledge-based systems. Building blocks Application: A software application is referred to as a set of interacting objects. Candidates: Candidates or candidate objects are key concepts in the form of objects described on CRC cards. They serve as initial inventions in the process of object design. Collaborations: A collaboration is defined as an interaction of objects or roles (or both). CRC Cards: CRC stands for Candidates, Responsibilities, Collaborators. They are index cards used in early design for recording candidates. These cards are split up into an unlined and a lined side. Content of lined side: On this side the candidate's name, its responsibilities and its collaborators are recorded. Content of unlined side: On this side the candidate's name, its purpose in the application, stereotype roles and anything worthwhile such as the names of roles in patterns it participates in are recorded. Hot Spots: Hot Spots are points in the application where variations occur. They are recorded using Hot Spot Cards. Hot Spot Cards: Hot Spot Cards are used for recording variations with just enough detail so you can discriminate important difference. Similar to CRC cards, these are also created from index cards. These cards consist of: Hot Spot Name General description of the variation At least two specific examples where the variation occurs Objects   Objects are described as things that have machine-like behaviors that...