Programming Jakarta Struts, 2nd Edition [Electronic resources] نسخه متنی

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.