The line between analysis and design in an object-oriented system is not a fine one. If such a line existed, analysis would emphasize the conceptual model and design, the specification model. However, it's not recommended that we create separate analysis and design models because they involve too much overhead. Instead, we recommend that the analysis model grow into the design model. In fact, due to the nature of object-oriented design and encapsulation, we'll find it's common for a portion of the system to be designed in detail, whereas another portion of the system is barely designed at all. This is the power of abstraction and is manifest in the various
interfaces that exist across the seams in our system.
• Interaction diagrams: As mentioned in Chapter 3, interaction diagrams illustrate the behavior of a portion of the system via a set of collaborating objects.
• Class diagrams: Also mentioned in Chapter 3, a class diagram illustrates the structural relationships among classes. Class diagrams are useful for showing the coupling that exists between classes, including relationships involving usage, inheritance, and interface realization.
• Package diagrams: While not a formal diagram in the UML, a package diagram is one of the most useful. Package diagrams enable us to represent our system's high-level dependency structure. In this sense, a package diagram is the specification of our software system at a much higher level of abstraction.
The importance of package diagrams, and how to use them effectively, is discussed in Chapter 10, when we discuss architectural modeling.
• Packages: The design model contains two types of packages. First are those packages that enable us to differentiate various views of the design model, such as use case realizations, process models, and implementation models.
Second are those packages that map directly to our Java source code and application package structure. They are represented in code during construction.
• Data models: Business applications take a data-centric view of the world.
Therefore, most business applications focus on supplying data to a user and applying various behavioral business rules to that data. In this regard,
generating a data model is critical. The creation of a data model is performed during analysis and design based on the requirements set forth during
requirements gathering.
• Process models: A process model illustrates the processes and threads that compose an application. Similar to how we trace use cases to the classes that realize these use cases, we trace these classes to the processes and threads in which they run. The process model and process view discussed in Chapter 3 are synonymous. We do not discuss process models in this book.
• Implementation models: An implementation model shows the components that compose our application. In Java, a component may consist of multiple classes. For example, an Enterprise JavaBeans (EJB) component may be composed of many different classes that provide the EJB with its functionality.
The implementation model traces the components to the classes that provide the components with their functionality. The implementation model and development view discussed in Chapter 3 are synonymous. Components are briefly discussed in Section 10.5.
Again, the intent of the analysis and design stage is to produce a set of artifacts that serve as useful inputs into the construction stage. Our system is fully and exactly realized at the construction stage. We should produce analysis and design artifacts only if they serve as useful inputs to construction. Needlessly producing artifacts that serve only as documentation and provide no value during construction should be seriously questioned.
In Figure 4.3, we again see our View Account use case, though in a somewhat different context. In this figure, our use case is attached via a generalization
relationship to a collaboration element. In Chapter 3, we introduced the collaboration element and stated that while a use case represents requirements from a customer's vantage point in the use case view, a collaboration models these same set of requirements from a developer's perspective. The primary benefit of using a
collaboration is to achieve traceability. Traceability is the ability to trace elements in one view into elements in another view. In Figure 4.3, our collaboration is named
"View Account Realization" because it's going to serve as the set of elements that are responsible for representing the View Account use case from a developer's
perspective.
Figure 4.3. Analysis and Design Artifacts and Model Structure
Similar in nature to how a use case has an associated use case specification, a
collaboration has an associated set of interaction and class diagrams, called a use case realization. For each flow of events associated with a use case, an asso ciated
interaction diagram is created, specifying the objects working together to realize that use case. Because a message can be sent to an object only if the two classes have a structural relationship, upon identifying the set of behaviors realizing a use case, we can analyze our interaction diagrams, identifying the structural relationships. This results in a class diagram, which we'll call the "View of Participating Classes (VOPC)" because it is the set of classes that participate in the realization of the use case to which they are attached.