Data-Oriented Design
This text uses the Martin (1990) version of Information Engineering to illustrate data-oriented design. The result of data-oriented analysis – entity-relationship diagrams, data flow diagrams, CRUD matrices, and so on – is translated into screen designs, production database designs, action diagrams, procedural structures, and security plans. Compared to other approaches, data-oriented design strongly emphasizes security, recovery, and audit controls, relating each to data and processes in the application.
In this chapter, you will learn about the concepts and terminologies for data-oriented design, analyzing data and defining system controls, and the action diagram. The action diagram shows the processing details for an application in a structured format, which can be translated into programs and modules. You will also learn about menu structure, dialogue flow, and hardware and software installation and testing.
Summary
Data-oriented methods assume that, since data are stable and processes are not, data should be the main focus of activities. First, design focuses on the usage of data to develop a strategy for distributing or centralizing applications. Several matrices summarize process responsibility, data usage, type of data used, transaction volumes, and subjective reasons for centralizing or distributing data.
Next, processes from a process hierarchy diagram are restructured into action diagrams in design. The details of process interrelationships are identified from the PDFD and placed on the action diagram. Each process is fully defined either in a diagram or in the data dictionary. Process details are grouped into modules and compared to existing modules to determine module reusability. Modules are analyzed from a different perspective to reflect concurrency opportunities or requirements on the action diagram. Entities are added to the diagram and related to processes. Lines connect individual processes to attributes to complete the action diagram specification of each application module. For manually drawn diagrams, an optional activity is to identify screens and link them to attributes and processes, to give a complete pictorial representation of the on-line portion of the application.
Data-oriented design focuses on the needs for security, recovery, and audit controls, relating each topic to the data and processes in the application.
The menu structure and dialogue flow for the application are defined next. The menu structure is constructed from the process hierarchy diagram to link activities, processes, and subprocesses for menu design. The structure can be used to facilitate interface designers' application understanding. The dialogue flow documents the flexibility or restrictiveness of the interface by defining the allowable movements from each menu level (from the menu structure) to other levels of menus and processing.
Finally, installation plans for all hardware and software are developed. A list of tasks is defined, responsibilities are assigned, and due dates are allocated to the tasks.
There are two fully functional CASE tools that support data-oriented methodology as discussed in this chapter, lEW and IEF. They are popular in companies that use data-oriented methods.