p. 253 · PDF 257

1-2-3 Software Detailed Design Process

The software detailed design process provides a design for the software that implements and can be verified against the software requirements and software architecture and is sufficiently detailed to permit coding and testing.

(1) Software detailed design

Six tasks are executed in software detailed design.

p. 254 · PDF 258

In software detailed design, software components (i.e., programs) are partitioned into the units of coding called software units.

Task (i) described above is also called module design, because software component is partitioned into modules, which are the units of development (i.e., coding). In the module partitioning that is conducted during module design, structured design using the concept of structuring is used. For the module partitioning that is used in structured design, there are methods that focus on the flow of processing (or data). In general procedures, higher-level module partitioning is first performed by using STS partitioning, after which lower-level modules are partitioned by using transaction partitioning. After this, the modules are verified, and common functional partitioning is performed.

[Module partitioning techniques focused on the flow of processing (or data)]

• • STS partitioning
  This is a technique that partitions program flow into three parts: input (i.e., Source), processing (i.e., Transform), and output (i.e., Sink). Each part becomes a module. Partitioning in this case is carried out at the maximum abstract input point where input data has been abstracted, and the maximum abstract output point where the models for output data have been collected. · 1 question

Enlarge original visual

Source visual description

Program flow (bubble chart): A points to B, B to C, C to D, D to E, and E to F. Source contains A and B; Transform contains C and D; Sink contains E and F. Dashed vertical boundaries mark the maximum abstract input point between B and C and the maximum abstract output point between D and E. Beneath, the Module structural diagram (functional hierarchy diagram) has Program above Source, Transform and Sink; Source has children A and B, Transform C and D, and Sink E and F.

Original STS partitioning diagrams · 1 practice questions

• • TR partitioning (Transaction partitioning)
  This is a technique that partitions each process as a module when processing differs according to type of data. As an example, when processing procedures differ for males and females in file updating, partitioning can be performed as follows:

p. 255 · PDF 259

Enlarge original visual

Source visual description

Update processing has two child boxes: Processing for males and Processing for females.

• • Common functional partitioning
  When there are functions that are common to multiple partitioned modules, this technique partitions these functions into a single independent module.

Enlarge original visual

Source visual description

The left hierarchy has M1 above M2 and M3; each lower module contains Function A. A rightward arrow leads to a hierarchy with M1 above M2 and M3 and one shared Function A box beneath them. Both lower modules connect to the common Function A; the source shows its folded-corner mark.

In addition to methods focused on the flow of processing (or data), there are also methods of module partitioning that focus on data structure.

Modules partitioned in this way must be evaluated for independence. Module strength and module coupling are used as metrics for evaluation.

p. 256 · PDF 260

• • Module strength
  This metric represents the associations of functions within the module. A better module has a higher strength. When modules are arranged in order of higher module strength, the result is as follows:

Functional strength	A collection of only functions that execute one certain process
Informational strength	A collection of multiple independent functions that process specific data
Communicational strength	A collection of multiple sequential functions, with internal passing of data
Procedural strength	A collection of multiple sequential functions, without internal passing of data
Temporal strength	A collection of multiple functions executed at a specific timing
Logical strength	A collection of multiple functions selected by parameters
Coincidental strength	A collection of meaningless functions partitioned by size and others

View original table · p. 256

Enlarge original table

• • Module coupling
  This metric represents associations with other modules. A better module has a weaker coupling. When modules are arranged in order of weaker module coupling, the result is as follows: · 1 question

Data coupling	Passes only parameters that do not affect control
Stamp coupling	Passes the data structure itself
Control coupling	Passes parameters that affect control
External coupling	Externally declares and shares only necessary data
Common coupling	Externally declares and shares data including unnecessary data
Content coupling	Directly looks up data in other modules

View original table · p. 256

Enlarge original table

Module coupling order · 1 practice questions

Partitioned modules are to be evaluated according to evaluation criteria, such as scope of control and scope of effect of the module, amount of partitioning of the module (the number of steps), partitioning into components, and reuse. After that, they are to be repartitioned as necessary.

p. 257 · PDF 261

Module specification design (or program design) is to be performed to clarify the functions of the partitioned modules. At this time, methods for representing module specifications include flowcharts, decision tables, and NS (Nassi-Shneiderman) charts. (Details are described in “2-2-1 Structured Design.”) In “(ii) Detailed design of software interfaces” (interface design), physical design is to be performed, which includes responsiveness, hardware functions, and others along with what have been considered in architectural design. In input/output detailed design, as input media, input design to determine input data checking methods (e.g., numeric checks, limit checks, format checks, duplication checks, matching checks, balance checks, logical checks (validity checks)), output objectives, and others are considered, output media (e.g., display screens, printer forms) is determined. In addition, output design is performed to design layouts based on the limitations of paper (specialized paper, general paper), displays, printers, and others. In physical data design for files and others, data property analysis, file organization methods (e.g., sequential organization, relative organization, indexed sequential organization, partitioned organization, direct organization), recording media, the layout of records (generally with key items positioned to the front, and reserved items added with expansion taken into account), and others are determined. This way of thinking is that same as that in “(iii) Detailed design for the databases,” and a physical data model is created with an awareness of the DBMS product to be implemented. With regard to interfaces between software components and interfaces between software units, appropriate interfaces (e.g., parameters and return values) are to be defined on the basis of the relationships between modules (i.e., main routines) that perform calls and modules (i.e., subroutines) that are called. At this time, call by value and call by reference are to be used appropriately as methods for calling subroutines (i.e., methods for passing parameters). In “(v) Definition of test requirements for software units,” in the same manner as test requirements for software integration, checklists, and others are to be used. In addition, criteria are to be created for test requirements for not only black box tests but also white box tests that verify whether the internal structure (i.e., algorithm) of the software is correct. (Details of black box tests and white box tests are described in “1-2-4 Software Construction Process.”)

p. 258 · PDF 262

(2) Evaluation and review of software detailed design

The following tasks are to be executed in evaluation and review of software detailed design.