Figure 2.46. Software design visualization. From Brown(1985)
The term programming in the large refers to the high-level design of subsystems and modules. Techniques and concerns of high-level design are different from the concerns of algorithm design, and it has been argued that high-level design should be done in a language distinct from that used to create data structures and algorithms. In most real-world environments, the high-level design is done ad hoc or on paper. The following systems not only provide computer-assisted ways of doing high-level design, but also provide formal output from the process.
G. P. Brown (1985) describes a system called PV built to visualize the software design process.
Figure 2.46. Software design visualization. From Brown(1985)
The system calls for linking together a whole range of diagram types:
system requirements documents
program function diagrams
program structure diagrams
communication protocol diagrams
program text
program commentary
flow control
structured data
persistent data
program in relationship to host environment
Graphic conventions are used to situate the programmer in the hierarchy
of diagrams being edited. A smaller overall diagram is always shown; this
diagram has a region highlighted that corresponds to the detail diagram
being edited. The system seeks to handle everything from data flow diagrams
to algorithm animation. The approach is more encompassing and less rigorous
than the Pegasys system described below.
Pegasys (Moriconi 1985) links design diagram to underlying logic. The
system uses a form calculus. As an example, when a network diagram is created,
and an arrow is drawn between a shape labeled host and a shape labeled
line, predicates such as the following would be generated:
process(Host)
module(Line)
type(Packet)
write(Host, Line, Packet)
Active entities in this system are:
subprogram
process
module
Pictures are drawn through an interactive editor that enforces the form calculus. The drawing can be refined at different levels, meaning that a program is defined through a hierarchy of pictures.
Figure 2.47. Pegasys network diagram. From Moriconi (1985)
Every atomic entity, that is, one that is not refined, must be associated
with program units. Passive entities are associated with data objects.
The system is built to be tied to Ada, so the active entities are associated
with subprograms, packages, tasks and generics. The diagrams produced using
the system correspond to a set of predicates, and since the editor enforces
a set of rules the predicates are internally consistent. Pegasys can then,
in an automated way, prove that the design hierarchy is consistent with
the code it describes.
Goguen (1985) suggests that semantics be used on large systems by attaching theories to program units. He suggests that this process is a visual, diagrammatic one, and should be made explicit.
Figure 2.48. Mapping graphs with meta-edges. From Goguen (1985)
The diagrams he uses are of two sorts. Above, a graph with meta edges
shows the mapping between graphs. Below, a puzzle-piece convention, an
instance of the adjoinment convention, is used to illustrate how software
modules can be fit together.
Figure 2.49. Puzzle piece convention. From Goguen (1985)