The Booch Method is a well-documented, proven method for object-oriented analysis and design. It has gone through two major revisions, and is currently being updated a third time to reflect the experience gained with the method over the last five years. [6]. In this paper, we will cover only the Booch method notation and how we can automate the construction, maintainence and validation of these models using a popular CASE tool -- Rational Rose.
The Booch method notation differs from other OO methodologies because it centers on the development of four fundamental models of the system in the problem domain that will be implemented primarily in software. These models are:
These models document components: classes, class categories, objects, operations, subsystems, modules, processes, processors, devices and the relationships between them. Just as an architect has multiple views of a skyscraper under construction, so the software engineer has multiple view of the software system undergoing design.
The Booch method recognizes that an engineer can view the four models from several different perspectives. In the Booch method, an engineer can document the models with several different diagrams:
The engineer augments these diagrams with specifications that textually complement the icons in the diagrams. It's important to realize that there is not a one-to-one mapping between a model and a particular view. Some diagrams and/or specifications can contain information from several models, and some models can include information that ends up in several diagrams. Each model component and their relationships can appear in none, one, or several of a models diagrams.
In this paper, we will only discuss the first four diagrams. A process diagram would involve discussing multithreaded programming, which may not be a worthwhile way to program [7]. The interaction diagram shows information that overlaps significantly with the Object diagram, so most projects use one or the other.