times as requirements change or more attractive technologies emerge. Properly designed components can be replaced with improved versions with minimal disruption to other modules.

Modularization thus enables considerable flexibility in evolving a system. For example:

  • Several prototypes can be built to explore alternative methods of accomplishing a particularly crucial goal.

  • Prototypes of individual modules can be discarded without jeopardizing investments made in the rest of the system.

  • A sequence of smaller, focused development projects can be used to add capability to the system.

  • The design and implementation of different system components can be divided among multiple vendors or research centers with specialized abilities. For example, a modular design should permit developing a new access technique for a particular kind of record without altering other parts of the system.

  • Commercial off-the-shelf (COTS) or other third-party packages—for, say, full-text indexing and search—can often be integrated individually into the system.

The hallmarks of modular design are the decomposition of the system into separate modules and the specification of the interfaces that surround each module, i.e., the details of the connections a module makes to other modules in the system. While it would be fairly easy to draw a high-level block diagram showing a modular system structure (such as was done in the OAIS framework2), more detailed evaluation of the required modules and interfaces is critical to obtaining the rewards of modular design. If modules are too big, they become hard to change or replace. If the interfaces become too complex or allow internal details of a module’s implementation to become known to other modules, the set of modules becomes “brittle,” and the ability to change one module independently of others may be lost. The details of modular structure and interface designs are critical.

Possible Modules and Interfaces for the ERA

This section briefly discusses some considerations for modular design of an archive system and outlines some of the possible modules and interfaces that would need to be specified for the ERA. In describing these, the committee intends only to provide some concrete illustrations of issues to be faced in the system design, not to do detailed design work.

To exploit modular structure for incremental evolution, it is necessary to define the software interfaces by which each module connects to other modules. These interfaces require defining subroutine calls and data types transferred between the modules. The data model used to store records in the file system serves in effect as an interface between ingest and access modules: Even though an ingest module does not directly invoke an access module, the

2  

ISO Consultative Committee for Space Data Systems (CCSDS). 2002. Reference Model for an Open Archival Information System (OAIS). CCSDS 650.0-B-1 (Blue Book). CCSDS Secretariat, National Aeronautics and Space Administration, Washington, D.C. January. Available online at <http://wwwclassic.ccsds.org/documents/pdf/CCSDS-650.0-B-1.pdf>.



The National Academies | 500 Fifth St. N.W. | Washington, D.C. 20001
Copyright © National Academy of Sciences. All rights reserved.
Terms of Use and Privacy Statement