In this section, we will review the procedure of analyzing the form of a simple system by looking at a software system, bubblesort. Like the pump, this is a far more simple system than the tools of architecture are intended for, but it will bring out some important observations.

Figure 4.19 shows pseudocode for the standard bubblesort algorithm that sorts an array from its smallest to its largest entry by successively switching the location of adjacent entries if they are not in ascending order.

We will analyze the architecture guided by the six questions presented in Table 4.1. Question 4a is “What is the system?” In this case, it is obvious that the system is the pseudocode listed in Figure 4.19. But what is the object of form that represents this system? This requires us to think about what a software object is. Note that this is not the “software object” found in object-­oriented programming, even though they share the same nomenclature.

Box 4.1 defined form as “the physical or informational embodiment of a system that ­exists . . . and is instrumental in the execution of function . . . [and that] exists prior to the ­execution of function.” Therefore, in software, the code (or pseudocode) is the form: It exists, it exists prior to the execution of function, and it is instrumental of function. It is implemented (written). When it is operated, this form is interpreted as an instruction that, when executed, leads to function. The passenger emergency instruction card (Figure 4.2) is a metaphor for software code. It had a set of objects (pictures, etc.) that exist, that have been implemented, and that, when operated, are interpreted by humans as instructions and lead to function.

There is a subtle difference between defining abstractions of software and information systems and defining those of a physical system, in that information itself is an abstraction. Informational form must always be stored or encoded in some physical form, and the two are a duality. As suggested in Box 4.7 on the Principle of Dualism, informational form must always be represented by physical form. Poems are in print; thoughts are encoded in neural patterns; DVD movies are optical markings encoded on a surface; and images are composed of pixels. In all cases, information is encoded in some physical form. When we speak about information, it is patterns in physical form that can be encoded and decoded by the user.

Continuing in Table 4.1, Question 4b is “What are the principal elements of form?” Now that we understand that the code is form, the likely elements are obvious: the lines of pseudocode. Alternatively, we could abstract together the “procedure/end procedure,” the “if/end if,” the “for j/end of j loop,” and the “for i/end of i loop” and identify eight important elements.

Decomposing the lines of code further does not provide additional useful information about the system. There are certainly details that are important, such as command semantics, order of variables, and naming conventions. This information is best treated as a detail of an object, much as the details of the impeller of the pump were important to its performance, but not to its architecture.

Question 4c of Table 4.2 is “What is the formal structure?” The procedure for determining formal relationships that is recommended in Section 4.3 is to examine each pairwise set of objects and determine whether there is a spatial/topological or a connectivity relationship between them.

For software, we need to consider the idea of spatial/topological relationships more generally. The structure of objects in software code is implicit and is suggested by (optional) indentations, code conventions, and language syntax. The most important element of spatial/topological structure in imperative languages is sequence—what lines of code are executed before what other lines of code. For example in Figure 4.19 it is apparent that lines 5–7 are in a sequence. Also, they are within the conditional “if statement,” which is within the j loop, and so forth. Figure 4.20 shows the structural relationships for lines 4–8 explicitly.

The “precedes” or “follows” sequential spatial/topological relationship informs the transfer of control during execution. Likewise, the “contains” or “within” relationship informs the execution of all the lines that are “contained” within the section of code, if the conditional test is met. In such imperative pseudocode, the spatial/topological structure informs the eventual flow of control, or at least the part that is strictly associated with structure.

The DSM tabular view of the spatial/topological structure of the bubblesort code is shown in Table 4.8. The grey section indicates the lines that were shown in Figure 4.20. This matrix makes explicit what lines are preceded by what other lines of code, as well as lines that are ­contained within the paired lines such as “if/end if.” The DSM indicates that there are no ­spatial/topological relationships with the two objects outside of the procedure—that is, the compiler and calling routine.

The connectivity structural relationships for software are associated with the connections that will carry the functional interaction: the exchange of data or variables. As an example, the connectivity DSM for bubblesort is shown in Table 4.9. Here the entries are used to indicate the variable shared: the array, length of the array, temporary, and the indices for the i and j loops.

Comparing Tables 4.8 and 4.9 for the spatial/topological and connectivity structural ­relationships of the bubblesort procedure, we see less similarity between the two than in the corresponding ­arrays for the pump in Tables 4.5 and 4.6. In general, it is possible to make spatial/topological and connectivity structure more distinct in information systems than in physical systems.

Table 4.1 next suggests Question 4d: “What are the accompanying systems?” and “What is the whole product system?” Recall that the whole product system contains the accompanying systems that are essential to deliver the product/system value. In the case of the bubblesort, value is delivered as a sorted array.

The additional accompanying systems in the whole product system therefore are at least the calling routine and the compiler that compiles the source code into executable instructions. Following on from there, the accompanying systems would be the processor that executes the instructions, and the input and output devices to enter the arrays. Ultimately, there are also the power supply, network, operator, and so forth. For simplicity, we will limit our discussion of the accompanying systems to the compiler and calling routine, as shown by the objects listed beyond the dashed line (system boundary, Question 4e) in Tables 4.8 and 4.9.

Examining these tables reveals the interfaces in the off-diagonal blocks. Although there are no important spatial/topological interfaces, there are important connectivity interfaces. There must be a connection that allows the array and array length to be shared between the calling routine and bubblesort. In addition, there must be a connection that enables the compiler to view the code and create the appropriate machine-level instructions.

Finally, Question 4f of Table 4.1 is “What is the use context?” From the information we have, this would be difficult to say. It could be an instructional module for students, a library application, or a piece of embedded system-critical software. The requirements for quality assurance, reliability, and maintainability would be different in these cases.

In summary:

• The objects of form for a software system are the code, which (when operated) will be interpreted as instructions.

• The software form can be decomposed into modules, procedures, and eventually (if desired) lines of code.

• The structure of software consists of spatial/topological structural relationships that inform control flow during execution, and connectivity structure, which is the instrumental connection that allows data and variable flow during execution.

• The whole product system for software includes the software code, the accompanying system (compiler, calling routine, processor, system software, input and output, and so on) and the use context systems that inform requirements and operations.