Sommerville-Software-Engineering-10ed

180 Chapter 6 ■ Architectural design
UML
editors
Code
generators
Design
translator
Project
repository
Java
editor
Python
editor
Figure 6.11 A repository
architecture for an IDE
Design
analyzer
Report
generator
The majority of systems that use large amounts of data are organized around a shared
database or repository. This model is therefore suited to applications in which data is
generated by one component and used by another. Examples of this type of system
include command and control systems, management information systems, Computer-
Aided Design (CAD) systems, and interactive development environments for software.
Figure 6.11 illustrates a situation in which a repository might be used. This diagram
shows an IDE that includes different tools to support model-driven development. The
repository in this case might be a version-controlled environment (as discussed in
Chapter 25) that keeps track of changes to software and allows rollback to earlier versions.
Organizing tools around a repository is an efficient way of sharing large amounts
of data. There is no need to transmit data explicitly from one component to another.
However, components must operate around an agreed repository data model.
Inevitably, this is a compromise between the specific needs of each tool, and it may
be difficult or impossible to integrate new components if their data models do not fit
the agreed schema. In practice, it may be difficult to distribute the repository over a
number of machines. Although it is possible to distribute a logically centralized
repository, this involves maintaining multiple copies of data. Keeping these consistent
and up to date adds more overhead to the system.
In the repository architecture shown in Figure 6.11, the repository is passive and
control is the responsibility of the components using the repository. An alternative
approach, which has been derived for artificial intelligence (AI) systems, uses a
“blackboard” model that triggers components when particular data become available.
This is appropriate when the data in the repository is unstructured. Decisions
about which tool is to be activated can only be made when the data has been analyzed.
This model was introduced by Nii (Nii 1986), and Bosch (Bosch 2000)
includes a good discussion of how this style relates to system quality attributes.
6.3.3 Client–server architecture
The Repository pattern is concerned with the static structure of a system and does
not show its runtime organization. My next example, the Client–Server pattern
(Figure 6.12), illustrates a commonly used runtime organization for distributed