p. 250 · PDF 254

1-2-2 Software Architectural Design Process

In the software architectural design process, software requirements are implemented, and software design able to verify these is provided.

(1) Software architectural design

Five tasks are executed in software architectural design.

p. 251 · PDF 255

In software architectural design, software is partitioned into functional-level software components (hereinafter called components), and functional specifications of each component, and the processing procedures and relationships among components are made clear. · 1 question

Enlarge original visual

Source visual description

Fig. 4-2. One Software box connects down to three separate Component boxes.

In (i) described above, when software is partitioned into components, the concept of structuring is often used to design functions in step-by-step detail and create a hierarchical structure. At this time, the criteria used for partitioning components include processing patterns for uniform records, differences in processing timing (i.e., processing cycle), differences in processing efficiency, simultaneously usable resources, characteristics of input devices, and such other factors. (As an example, the update processing for the same file is partitioned as one component.) Moreover, from the perspective of component partitioning, file integration or file partitioning may be used. (For example, when there are different functions for male and female customers, customer files may be partitioned into male customer files and female customer files, and the software is partitioned into components that process each file.) Functional specifications are determined for each partitioned component. Components become programs that provide functions collected into a single function. Since

p. 252 · PDF 256

programs can be reused by other software as components, partitioning is considered on the basis of criteria for ease of understanding, development productivity, operability, processing capability, maintainability, reusability, and such other factor. (This way of thinking is called “partitioning into components.”) Furthermore, it is also important to consider the use of existing programs. In “(ii) Architectural design of interfaces” (interface design) described above, top-level interfaces are to be made clear on the basis of the software requirements definition document, in consideration of operability, visibility, software functions, and processing method, according to interface design standards. Since screens, forms/slips, files, and others correspond to external interfaces, GUI-based screen design, form/slip design, and other input/output design (i.e., input/output conceptual design), along with logical data design, are to be performed. In top-level design, logical definitions such as items, layouts and screen transitions are created. Physical definitions that rely on hardware or specific methods are not created. This way of thinking is that same as that in “(iii) Top-level design for the database,” and design that relies on specific DBMS products and others are not performed at the software architectural design stage. In “(v) Definition of test requirements for software integration,” checklists and others are to be used to verify that there are no oversights in test requirements. In addition, test requirements are to be created on the basis of criteria for black box tests. These tests verify that the relationships between input and output are correct. (Details of black box tests are described in “1-2-4 Software Construction Process.”)

(2) Evaluation and review of software architectural design

Two tasks are executed in evaluation and review of software architectural design.