For those who are just joining us, welcome! We are exploring common and useful object-oriented analysis and design modeling activities that ultimately lead to the creation of a system implemented in Java.

By definition, because analysis focuses on investigation of the problem space, the analysis models do not directly relate to Java. However, as we move on to design, we will explore more Java-related issues that impact the design of the architecture and software classes. When diagrams are used, we illustrate them in the Unified Modeling Language (UML) notation. However, this is not a column about the UML (which is “simply” a useful, standard diagramming notation—no small feat), rather it is a column about skills and heuristics in analysis and design, which is a more critical concern than notation. My usual disclaimer applies: modeling and diagramming should practically aid the development of “better” software—better in meeting the desires of the client or in being easier to change and extend. If it doesn't, question its value.

In our last column on conceptual (or domain object) models (see “The Conceptual Model—What's the Object?,” Java Report, Vol. 3, No. 10) we focused on the fundamentals of this classic object-oriented analysis model: identifying concepts, attributes, and associations. It is not a picture of software components or classes; it is an analysis-oriented set of diagrams that depict abstractions of things of interest in the problem domain.