Object-oriented programming increases the value of these metrics by ma — Rebecca Wirfs-Brock

"A subsystem is a set of classes (and possibly other subsystems) collaborating to fulfill a set of responsibilities. Although subsystems do not exist as the software executes, they are useful conceptual entities."

"Responsibility-driven design specifies object behavior before object structure and other implementation considerations are determined. We have found that it minimizes the rework required for major design changes."

"Encapsulation is the key to increasing the value of such software metrics as reusability, refinability, testability, maintainability, and extensibility. Object-oriented languages provide a number of mechanisms for improving encapsulation, but it is during the design phase that the greatest leverage can be realized. The data-driven approach to object-oriented design focuses on the structure of the data in a system. This results in the incorporation of structural information in the definitions of classes. Doing so violates encapsulation. The responsibility-driven approach emphasizes the encapsulation of both the structure and behavior of objects. By focusing on the contractual responsibilities of a class, the designer is able to postpone implementation considerations until the implementation phase. While responsibility-driven design is not the only technique addressing this problem, most other techniques attempt to enforce encapsulation during the implementation phase. This is too late in the software life-cycle to achieve maximum benefits."

"Users can work with analysts and object designers to formulate and tune system requirements. People from business, analytical and object design disciplines can come together, learn from each other and generate meaningful descriptions of systems that are to be built. Each participant and each project has slightly different concerns and needs. Practical application of use cases can go a long way to improve our ability to deliver just what the customer ordered."

"Experienced object designers explore the design space from many different angles. They refine ideas of how their system should respond while they are in the middle of building and discarding ideas about how their design should work. Getting a design to gel involves making assumptions, seeing how they play out, changing one’s mind or perspective slightly and re-iterating. Design is a difficult, involved task. It inherently is a non-linear process. Yet, we are asked to trace our design results back to system requirements. And, if we uncover some implications during design, we’d like to tune our system requirements to reflect necessary design compromises."

"Use cases, scenarios or scripts are roughly synonymous terms for important ways to focus our design activities. I prefer the term use case (although quickly saying it three times can leave your tongue tied) because it emphasizes usage. A use case is a textual description of a sequence of interactions between an actor (roughly corresponding to an external agent or class of users) and the system we are designing. Use cases were first described by Ivar Jacobson in his book “Object Oriented Software Engineering A Use Case Driven Approach.” Use cases have been around in various forms for quite some time. Jacobson, however, made the keen observation that use cases can be treated as refineable, extensible and even reusable specifications of system requirements. We’ve had these same goals for object designs. We know that it is harder to actually accomplish them than it is to talk about them."