Walking on water and developing software from a specification are easy if both are frozen. - Edward V. Berard

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.

Object-oriented domain analysis seeks to identify reusable items localized around objects e.g., classes, instances, systems of interacting objects, and kits.

In order to better understand object-oriented methodologies in general, it helps to understand the people who make up the "object-oriented community" itself. Far from being monolithic, there is a great deal of diversity within this community. Many object-oriented people, for example, seem to focus almost entirely on programming language issues. They tend to cast all discussions in terms of the syntax and semantics of their chosen object-oriented programming language. These people find it impossible (for all intents and purposes) to discuss any software engineering activity (e.g., analysis, design, and testing) without direct mention of some specific implementation language. Outside of producing executable "prototypes", people who emphasize programming languages seldom have well-defined techniques for analyzing their clients' problems or describing the overall architecture of the software product. A great deal of what they do is intuitive. If they happen to have a natural instinct/intuition for good analysis or good design, their efforts on small-to-medium, non-critical projects can result in respectable software solutions.