8.2 Responsibility-Driven Development

The design process requires special discussion to promote responsibility-driven design and development. Responsibility-driven design requires that subsystems and components are identified and designed based on their functional responsibilities. Each subsystem or component has a set of responsibilities that is orthogonal to every other subsystem or component in the system. If a particular responsibility that already exists is required by a new subsystem or component, the new component delegates the task to an existing instance of the component or subsystem. This technique maximizes reuse and redundancy at the expense of the typically small performance overhead of delegation. While responsibility-driven development is already popular in many object-oriented software development organizations, it will likely grow even further in popularity with the advent of components and component-oriented development, which already rely upon delegation for composing new components from existing components.

One of the design deliverables in a software development effort is the creation of a software specification for one or more subsystems. In specification writing, it is important to differentiate between the documentation of an interface and the documentation of the implementation. Since other subsystems may rely upon the interface, it is expected that the specification for the interface will be less likely to change than classes utilized completely within an encapsulated subsystem.

For software development where developers are not able to remain in constant close contact, design documents should be more akin to a specification, a more rigorous description of a software design, than those provided by some methodologies. A design specification should clearly differentiate between the interface between subsystems and components and the parts that make up the internal implementation of one or more subsystems. The purpose of a specification is to reduce, if not completely eliminate, the effect of multiple interpretations of a design. If every design consistently defined every subsystem to a sufficiently low level of detail, documenting each subsystem by describing the semantics of every class, method, parameter, and data structure, then there would be no need to have a specification because such a design would be sufficient to resolve any ambiguity. However, in practice, designs often vary in their quality, and the introduction of a specification makes explicit the areas where detail is absolutely essential-the interfaces exposed to other subsystems. Generally, it is exceptionally beneficial to describe these interfaces in an interface specification language, such as OMG IDL.

Having a design specification makes it easier for the architect because several heuristics can be applied to assess whether certain tradeoffs are made appropriately. For example, the introduction of several user-defined data types indicates a tighter coupling between the subsystem and its clients than if more simple or system-wide data types were used. Frequently, an architect will need to communicate ideas to parts of a development team, and a presentation is deemed to be better suited to the time constraints than conveying the same information through individual mentoring. While a presentation is useful for disseminating quick and dirty guidance, it tends to be rather useless if not supplemented with more substantial material over time. Specifically, guidance given in presentation form without being tied to hands-on mentoring can do more harm than good because developers gain no additional skills and are demoralized at not meeting a higher level of productivity. Software architects should always make clear to project stakeholders what presentations are not effective at conveying and should emphasize the need to support in-depth studying from academic texts. Even more important are industry white papers, which are frequently an excellent means of learning lower level architectural details of emerging technologies.