Recently, I have had conversations with a number of people who were attempting their first object-oriented project. Most of these people claimed to be using “use cases” in their object-oriented analysis and design approaches. However, listening to them describe their projects, it became quite apparent to me that there is a great deal of confusion regarding the definition, context, and use of use cases. This confusion can (and often does) lead to poorly-designed systems.
Walking on water and developing software from a specification are easy if both are frozen.
Object-oriented domain analysis seeks to identify reusable items localized around objects e.g., classes, instances, systems of interacting objects, and kits.
An action which is suffered by, or required of, an object. Operations may be selectors, constructors, or iterators. An operation is contained in an object's interface and has its details described in a corresponding method. Operations may be composite, i.e., composed of other operations. However, encapsulation of composite operations within the interface to an object is not encouraged.
Work on what was to become “structured design” began in the early 1960s. Structured design, as a well-defined and named concept, did not achieve appreciable visibility until the publication of an article in the IBM Systems Journal in 1974 (Stevens et al., 1974). There is more than one way to accomplish a “structured design.”
Like structured design, the term object-oriented design (OOD) means different things to different people. For example, OOD has been used to imply such things as