is inspired by the client/server model. It focuses on the contract by asking: - Rebecca Wirfs-Brock

The goal of is to improve encapsulation. It does so by viewing a program in terms of the client/server model.

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.

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.