6.1 The

6.1 The "M" in MVC

The model components of an application arguably are the most valuable software artifacts to an organization. The model includes the business entities and the rules that govern access to and modification of the data. It's vital that this be kept in a single location in order to maintain valid data integrity, reduce redundancy, and increase reusability.

The model should remain independent of the type of client that's being used to access the business objects and their associated rules. In fact, the components within the model should not be aware of what type of client or framework is using it. There's an axiom that goes, "Dependencies go down, data goes up." The idea is that when using a layered architecture, the upper layer may have dependencies on lower layers, but the lower layers should not depend on the layers above them. Figure 6-1 illustrates how this principle is applied to a typical Struts architecture.

Figure 6-1. Application layers should depend only on lower layers

If you find yourself importing packages or classes from the Struts framework into your model, you are violating this principle. Coupling a lower layer to an upper one will make maintenance, reuse, and future enhancements more difficult.

Before we get into the details of designing and building a model for a Struts application, let's look at the different types of models and how each one is relevant to a project.

6.1.1 Types of Models

The term "model" has many different meanings. In very general terms, a model is a representation of some aspect of reality, such as a shop where products are bought and sold, an auction house where bids are placed, or a way to predict how a weather storm will move. All of these examples are based on real concepts. The main purpose of creating a model is to help understand, describe, or simulate how things work in the real world.

In software development, the term "model" is used to indicate both the logical representation of real-world entities and the physical creation of classes and interfaces that programs can use. The first step, however, always should be to perform a thorough analysis of the problem domain. Once use-cases are complete, the next step should be to develop a conceptual model.

6.1.1.1 The conceptual model

During analysis of the problem domain, a conceptual model should be developed based on the real-life entities within the problem space. The entities in a conceptual model have less to do with the software components of the system and more to do with the physical entities that are fundamental to the business. The conceptual model usually illustrates the concepts, the relationships between them, and the attributes that belong to each concept. The behavior usually is not represented in this type of model.

The conceptual model is developed from a set of use-cases for the system. The purpose of building the model is to help identify the entities that most likely will become classes in the design stage and to better understand the problem domain. Figure 6-2 illustrates a conceptual model for the Storefront application. Notice that only relationships and the attributes for the entities are shown; no methods are specified.

Figure 6-2. The Storefront conceptual model

If you are familiar with Entity-Relationship (E-R) diagrams, you shouldn't be too confused by the conceptual model. They are very similar.

The value of a conceptual model is that it clearly shows the entities that are used by the problem domain. Everyone involved in the business, technical or not, should be able to look at the conceptual model and make sense of it. They also should be able to quickly point out problems with the model. For example, maybe an item can't belong to more than one catalog at a time. By examining the conceptual model, someone would be able to point this out, and the analysts could make the change early. The later in the design and development cycle that a change is required, the more costly that change becomes.

6.1.1.2 The design model

The conceptual model is just one artifact of the analysis stage; there can be many others. In smaller development groups or on smaller projects, the conceptual model may be skipped in favor of moving to the design stage sooner. The risk of doing this, however, is that you might leave the analysis stage without a clear and concise understanding of the requirements.

Even if you build a conceptual model, you still will need to create the appropriate design documents. This usually includes class diagrams, interaction diagrams, and possibly other artifacts such as state diagrams. At a minimum, your design-stage artifacts should include one or more class diagrams. Figure 6-3 illustrates a class diagram based on the conceptual model for the Storefront application illustrated in Figure 6-2.

Figure 6-3. The class diagram for the Storefront business objects

The class diagram in Figure 6-3 shows the business objects used within the Storefront application. For brevity, only the attributes and relationships are shown here.

The way you arrive at the proper design for your application is definitely beyond the scope of this book. There are a multitude of excellent analysis and design books available. One of the more popular references is Applying UML and Patterns by Craig Larman (Prentice Hall).

The exact type and structure of business objects and processing rules obviously are dependent on the domain of your application, and no two applications are exactly the same. Even within a single application, it's understood that requirements change. However, conducting a thorough analysis of the problem domain and constructing a resilient design goes a long way toward protecting your application from unexpected change.