Structure Of The Universe and
Programming
(Evolution Of
Programming Methodology, Part II, Page 4)
By Bill Nicholls
March 27,
2000
Objects
were the darlings of the 1990s. Objects introduced the
concept of data capsules, that information relating to a
single thing should be kept together and isolated from
outside access except through well-defined interfaces.
Objects take the MVC paradigm and implement it in smaller
logical or functional units.
Patterns reflect the discovery of how many parts of
different programs went through the same sequence of steps,
even though the details and the data were different. A
pattern is an abstraction of the larger scale structure of a
program or group of programs. These patterns were seen as a
structure that could be reused as a guide to building other
programs that used similar steps.
MVC made a comeback in this decade. As objects became a
mainstream idea, the value of MVC as a concept was
rediscovered. Objects put a fine-grained structure around
the smallest elements of a program, while MVC created a
structure around the functional aspects of the program.
Patterns identified a structure in applications.
The conceptual set of objects, MVC and Patterns is a set
of nesting concepts. Each element is made up from a
collection of smaller elements, starting with objects. There
is an amazing analogy to the physical structure of the
universe that starts, we think, with elementals like quarks
and leptons, making particles that make atoms, molecules,
planets, solar systems, galaxies, and universes.
In an analogous fashion, I see that programs are built
from bits, bytes, data elements, objects, MVC, and patterns,
each structure built upon the prior structure. This
hierarchy of structures is a concept that can be used to
facilitate the creation of programs by automating the
building of a program by assembly of building blocks
Building A Program
How would this concept work?
Think of objects as the Leggo building blocks of a program,
and MVC as the walls, floors, and ceilings, using Patterns
as the design of the buildings. Then consider C/S as the way
buildings are connected into a factory. Two new tools are
needed to make this possible. One is a way to specify the
interfaces, the way the blocks, walls, and buildings can be
connected. The second is a tool analogous to a crane that
can stack and assemble the pieces to build the complete
structure.
This first tool is a Meta Interface Language (MIL) that
describes the component interfaces in a way that lets
components be automatically found and assembled,
either by a person or program. If such an MIL is created and
the required components for a program described, then
programming would lose much of the detail dogwork that is
involved, along with the human errors that are made in the
process.
The second tool is one that programmers would use to
describe the function and structure of the desired program.
This tool would inspect its database of objects, MVC
functions, patterns, and the MIL that describes how these
can be connected together. It's a software version of the
VLSI electronic building blocks, and the MIL is analogous to
the VLSI design languages. The building tool is analogous to
VLSI design tools. I call this the Program Structure Builder
(PSB).
The PSB follows the operator's directions in selecting
and assembling the necessary components to create the
program. It takes components with their MIL descriptions and
assembles them into functions. All details will be hidden
unless conflicts arise or components have to be created or
modified to meet special needs. The operator (programmer)
may use block-function diagrams, finite state machines, or
other descriptive technique to specify the sequence and the
results, but not the details of the process. This will
finally raise the programmer from a piece worker to assembly
line manager, with the PSB carrying out the commands.
<<<Previous
Page >>>Next
Page
