Page 172 -

6.3 Architectural patterns 155

Name MVC (Model-View-Controller)

Description Separates presentation and interaction from the system data. The system is structured into
three logical components that interact with each other. The Model component manages
the system data and associated operations on that data. The View component defines and
manages how the data is presented to the user. The Controller component manages user
interaction (e.g., key presses, mouse clicks, etc.) and passes these interactions to the View
and the Model. See Figure 6.3.

Example Figure 6.4 shows the architecture of a web-based application system organized using the
MVC pattern.

When used Used when there are multiple ways to view and interact with data. Also used when the
future requirements for interaction and presentation of data are unknown.

Advantages Allows the data to change independently of its representation and vice versa. Supports
presentation of the same data in different ways with changes made in one representation
shown in all of them.

Disadvantages Can involve additional code and code complexity when the data model and interactions
are simple.

basis for model-driven development. However, I believe that informal models and
Figure 6.2 The model-
view-controller (MVC) notations, such as the UML, will remain the most commonly used ways of docu-
pattern menting system architectures.
Users of agile methods claim that detailed design documentation is mostly
unused. It is, therefore, a waste of time and money to develop it. I largely agree with
this view and I think that, for most systems, it is not worth developing a detailed
architectural description from these four perspectives. You should develop the views
that are useful for communication and not worry about whether or not your architec-
tural documentation is complete. However, an exception to this is when you are
developing critical systems, when you need to make a detailed dependability analy-
sis of the system. You may need to convince external regulators that your system
conforms to their regulations and so complete architectural documentation may be
required.

6.3 Architectural patterns

The idea of patterns as a way of presenting, sharing, and reusing knowledge about
software systems is now widely used. The trigger for this was the publication of a
book on object-oriented design patterns (Gamma et al., 1995), which prompted the
development of other types of pattern, such as patterns for organizational design
(Coplien and Harrison, 2004), usability patterns (Usability Group, 1998), interaction
(Martin and Sommerville, 2004), configuration management (Berczuk and