The Warpcity Project: What is it?
At the Warpicity Project's core lies the production of a single,
interactive, realtime, software development support tool. We refer to
this tool as the Developer's Assistant or DA for short. The support it
will offer covers the entire spectrum of software development activities
from input of requirements to production of executables. When available
it will come as a package including it as an executable as well as its
complete, detailed, component source code. Thus the procurer will have
all that it necessary to customize, modify, or extend in any desired
manner to meet any current or future need.
This occurs through the exclusive use of a specification language,
denoted as SL/I or Specification Language/I, based on a formal logic
known as predicate logic. Syntactically this language resembles PL/I.
In fact it is a superset of PL/I. This choice derives from PL/I's
unique position as the most powerful and functionally complete
programming language available today. No other programming language
without the use of an additional library or libraries comes close. Thus
it provides the highest starting scaffold from which to build an even
more powerful language.
Moreover the language, SL/I, is self-defining. Its syntax, semantics,
proof theory, and meta theory exist as specifications in SL/I. Thus
like the DA, which is based on SL/I use, the language is capable of
unlimited extensions to meet any current or future need.
Thus the package, which includes the DA and its source, includes SL/I
and its source as well.
As its name implies the DA acts as a clerical assistant to the developer
in every software development activity. It provides all the clerical
support necessary for all software development activities. To do so it
must understand every activity. That understanding exists as
specifications in SL/I. Those specifications derive from decomposing
the seamless, software development process of specification, analysis,
design, and construction in a stepwise manner until defined in terms of
atomic activities. Each of these atomic activities have an IPO
(Input-Process-Output) model expressed in SL/I terms. The seamless
character of the process is maintained throughout all levels of
decomposition down to and including the atomic activities.
Thus we have two types of specifications to incorporate with respect to
the IPO model, one type for the data (the I and the O) and the other for
the process (the P). As the DA assumes full responsibility for the
maintenance of the data specified, which must be as seamless as it is
the seams connecting the processes, it needs some formal means, some
tool for doing this. The means is a Data Repository. The tool is the
Universal Name Directory or UND for short.
As its name implies the UND concerns itself only with names and their
relationships with other names, i.e. their assembly into information
structures. In modeling a real world of homonyms (same name, different
referent) and synonyms (different name, same referent) we must have a
means of providing a unique name, an unambiguous reference to a
referent. In the UND we do this by assigning an index to every primary
(or proper) name. Thus a unique name has two parts, a primary name and
an index value.
If a name is a group (or container) name the UND stores it and what it
contains (the names associated with it) as a two-level hierarchy with
the contained names existing as an unordered set noted only by their
relative position. No requirement exists than any unique name may
appear only once in the set. It may appear more than once. If the
contained names have an internal ordering among them, representing one
or more networks, the UND will store and maintain this. Thus the UND is
capable of representing and maintaining any known information structure.
As the UND can always provide a unique name for any referent regardless
of type, each type may exist separately elsewhere within the data
repository using only the seamless connection between them provided
within the information structuring capability of the UND. The DA then
uses the UND to maintain the seamless character of the data in the Data
Respository.
IBM's AD/Cycle
The DA in combination with a Data Respository based on the UND
represents a realization of IBM's AD/Cycle. IBM presented AD/Cycle
visually in three layers. The topmost layer represented the software
development process (SDP)in the seamless sequence of its stages:
specification, analysis, design, construction, and testing. The middle
layer represented the various vendor tool offerings with horizontal line
segments showing the portion or portions of the SDP covered. The third
or bottom layer contained the Data Respository, a common storage for the
inputs and outputs to the various vendor tools.
In theory a customer could pick and select a contiguous set of tools
from the beginning to the end of the SDP. In practice no such
contiguous set, no seamless fit, existed. There were discontinuities
from where one tool ended and the next began or they overlapped without
providing any functional, modular means for the user's choosing where
his use of one tool ended and another began.
Consider the obstacles facing the vendors in AD/Cycle. They first would
have to decompose the SDP into a continguous (seamless) set of atomic
activities with an agreed-upon set of input and output data formats. No
such decomposition had ever occurred prior to AD/Cycle, none occurred
during its heyday, and none has occurred since. Thus the most
fundamental analysis that we routinely provide and feel necessary to
understand client processes we have never applied on our own SDP.
Without this analysis, without the modular granularity it would provide,
without agreed-upon, well-defined data interfaces AD/Cycle floundered
and failed.
Had the decomposition occurred resulting in a set of well-defined
set of data interfaces and atomic activities every vendor would now have
to modify his tools within their range of atomic activities covered.
Where discontinuities existed competing vendors would have to extend a
tool's range. Where overlaps existed competing vendors would have to
provide user options to determine the range of each tool. Clearly every
vendor had an exposure relative to the distance between his tool
offering and what it supported relative to the determination provided by
the agreed-upon composition.
Then finally the vendors would have to face up to the plug-and-play
options the user's would now have. All the proprietary, all the
incompatibilities would disappear. No vendor would have safe haven
regardless of what niche his tool served. For whatever advantages
AD/Cycle offered users, the primary group whose stated needs for such
support led IBM to propose it, established vendors understood its threat
to their protected niches. AD/Cycle was user-friendly, not
vendor-friendly.
The Warpicity Project as AD/Cycle
As stated earlier the Warpicity Project will offer a single tool, the
DA, that encompasses the entire SDP. Thus its niche is the SDP. As the
tool will provide all the necessary clerical support and therefore must
know all the data interfaces and processes, the SDP decompositon into
atomic activities, which has never occurred previously, must take place.
This detailed decomposition within the defined hierarchy descending from
the SDP to its stages (specification, analysis, design, construction) to
the atomic activities within them will replace the first or topmost
layer of AD/Cycle. The DA whose line segment (and thus range) extends
from the beginning atomic activities to the ending ones replaces the
middle or tool layer of AD/Cycle. Then the Data Repository, the bottom
layer of AD/Cycle, will contain the data supporting the data interfaces
of the atomic activities, all held together through the UND.
As the only connection between successive atomic activities lies in the
data interfaces the activities themselves are loosely coupled. This
supports the original plug-and-play intent of AD/Cycle.
The Specification Language, SL/I
Using a specification language based on an established formal logic
provides three advantages in software development/maintenance. One, it
is the first formal language necessary. Two, it is the last formal
language necessary. And three, it is the only formal language
necessary.
More to the point such a specification language suffers none of the
limits of a programming language. Such a specification language because
it allows any logical expression with any logically-define operator and
any logically-defined operand becomes as universal as the form of logic
on which it is based. As we use the same language to logically define
(specify) the operators and operands we can use it to permit extensions
of either in an unlimited manner as the need arises. In short we need
only a formal logic specification language to specify a
formal logic specfication language.
The formal logic on which we base the specification language, SL/I, is
the predicate logic. It is the formal logic introduced with the
DOS-based Trilogy product in the late 80's. It is the formal logic used
currently in the Z-specification language. A good reference text for
the Z-specification language (and thus predicate logic) is "Using Z:
Specification, Refinement, and Proof" by Woodcock and Davies published
by Prentice Hall.
We have chosen to implement SL/I as a superset of PL/I. For that
reason the syntax of SL/I is as simple as that of PL/I. Every predicate
(specification assembly) in SL/I is composed of two or more
specification statements. Every specification statement ends in a
semi-colon. The only two required specification statements are the
labeled predicate statement and the end statement. These provide the
name of the predicate as well as its beginning and ending boundaries.
An example of such a declaration is:
<![CDATA[
my_pred: predicate;
end;
]]>
Now a predicate may have a "head" and a "body", each of which may
contain one or more specification statements. The "head" contains only
object specifications, while the "body" contains only process
specifications. In logical reasoning the object specifications make up
the givens, the set of applicable rules and conditions. The process
specifications make up the unknowns, that which we want to prove from
the givens. In other specification languages, e.g. Prolog, we refer to
process statements as "assertions". Certain of these assertions in
Prolog are designated as "goals".
In SL/I every object specifcation begins with a "declare" or "dcl".
Every process specification does not, i.e. it begins with something
else. As SL/I is a superset of PL/I every "declare" statement ever
written in any PL/I program constitutes a valid object specification in
SL/I. As also with PL/I any SL/I "declare" (object specification) may
appear in any order anywhere within the boundaries of the predicate and
may be reordered at will without changing their logical consequence.
Process specification statements making up the body of a predicate form
in structured programming terms one or more control structures known as
"sequences". The order of the statements in any sequence control
structure is important and thus must be maintained.
In Prolog we connect the process statements of each sequence control
structure into a "logical and". Unfortunately in logic the "logical
and" is commutative which means their "truth value" (what results)
overall is independent of their order. To retain the full attributes of
a "logical and" in SL/I we do not connect the process statements in a
sequence control structure by any other means than their written order,
i.e. as occurs in any programming language.
SL/I differs from Prolog in another aspect: it supports imperatives. In
programming languages imperatives have the form of an "assignment"
statement or an i-o statment (read, write, writeln, etc.) just to give
two examples. Prolog allows only "assertions", i.e. logical
expressions. SL/I allows imperatives and assertions to be mixed in any
order in any sequence control structure.
This means that the logic engine which applies the proof mechanism in
SL/I makes a distinction between an assertion and an imperative in the
type of proof it applies. Thus there are two proof types within a
single proof mechanism of a logic engine.
The writing of an assignment statement in SL/I requires the substitution
of the dual symbol assignment operator ('<-') for use of the equal ('=')
symbol for that purpose in PL/I. This restricts then the equal symbol
to its use in logic. Thus 'a = b = c;' is a logical expression whose
truth value we want to determine and not an assignment statement of
assigning to a the truth value of b = c. We would express that instead
as 'a <- b = c;'.
With the substitution for the assignment operator and one replacing the
procedure statement with a predicate statement any PL/I program will
serve as an example of SL/I.
In addition SL/I supports aggregate expressions, the use of aggregate
operands (arrays, structures, and lists) with any operator as occurs in
APL and Prolog. This ability to include lists as aggregates means that
an invoked predicate (a subroutine call) may return a "result list"
to the invoking predicate and the invoking predicate may submit as input
to another invoked predicate. In general this means no need for the
"cursor logic" that occurs in programming languages, e.g. Cobol, to
process the results of an SQL query.
A more complete and detailed description with examples of SL/I will
appear in the language reference manual. The biggest obstacle initially
to overcome lies in realizing that it has none of the limits of any
programming language. It needs no more than itself to extend itself.
The Universal Name Directory (UND)
In discussions to date people have tended to focus on the specification
language, SL/I. When considering the claim of "50 times time reduction,
200 times cost reduction" they don't see how using a specification
language can achieve that. They are correct. It cannot. It does not.
SL/I, as does any similarly based specfication language, offers
productivity gains over any other programming language, especially when
in comes to softare maintenance on complex (many interconnections) and
complicated (many statements) applications.
The claimed productivity gains and cost reductions occur almost entirely
through shifting clerical support in software development and
maintenance from manual to machine labor. In effect it occurs by
applying our standard structured methods that we use in improving client
processes to our own process. It's that simple.
As occurs in improving a client process we must structure the data and
define an integrate set of data stores. As in AD/Cycle we design and
designate a common set of data stores in a data repository. We must
also design and designate a data store which allows us to store "things"
separately and yet retrieve them as "wholes". Within the Warpicity
Project this data store is the called the Universal Name Directory or
UND.
We call it a name directory because the only things (entities) stored in
it are names. We do so because the only attribute common to anything
that we can reference is its name. They all have names. Beyond that
they start to differ.
We can vigorously (and rigorously) state that the UND is "not" a data
dictionary. It does not tell you anything about what a name means, only
what it is called (used as reference). If you want a data dictionary,
then add it as another data store in the data respository which allows
it to be integrated with the other types of data.
In its relational implementation it consists of four tables. Two allow
for the definition of all possible names, including unlimited homonyms
(same name, different referents) and synonyms (different names, same
referent). Before we forget homonyms provide a means of version
control. Thus version control is a builtin facility of the UND and its
application to any name, thus any entity. To anything you can name you
can apply version control.
We now define these tables as object specfications in SL/I.
<![CDATA[
dcl 1 ega_table unaligned,
2 primary_name char(64) varying,
2 primary_index fixed bin (31) unsigned,
2 primary_type char (1)
range ('U', 'E', 'G', 'A', 'H', 'N')
default ('U');
dcl 1 alias_table unaligned,
2 alias_name char(64) varying,
2 alias_index fixed bin (31) unsigned,
2 primary_name char(64) varying,
2 primary_index fixed bin (31) unsigned;
dcl 1 group_table unaligned,
2 group_name char(64) varying,
2 group_index fixed bin (31) unsigned,
2 relative_position fixed bin (31) unsigned,
2 primary_name char(64) varying,
2 primary_index fixed bin (31) unsigned;
dcl 1 from_to_table unaligned,
2 group_name char (64) varying,
2 group_index fixed bin (31) unsigned,
2 from_position fixed bin (31) unsigned,
2 to_position fixed bin (31) unsigned;
]]>
The first table, the ega_table, is the "only" entry point into the
directory. The first two tables, the ega_table and the alias_table,
account for all possibilities of names including synomyms (alias_table)
and homonyms (the _index columns). The third table, the group-table,
allows a group name to be associated with the set of all its members.
This supports all two-level hierarchical relationships. The fourth
table, the from_to_table, supports an ordered relationship among the
members of a group as one or more networks.
Together the last two tables, the group_table and the from_to_table,
permit the representation of any known information structure. Any known
information structure. Even those unknown.
The first two tables, the ega_table and the alias_table, guarantee a
"unique name". The second two tables, the group_table and the
from_to_table will show all unique names in all relationships. These
table are utterly simple. And just as powerful. The next time someone
asks you, "What's in a name?", you can confidently reply, "More than you
might think."
Storing and Retrieving Source Documentation
The UND itself is part of a larger entity referred to as a "data
repository", a place where data is stored. Now that data exists as
source data. That source data is text-data either written in an
informal language (user documentation) or a formal one (source code
statements). The basic stored informational unit (IU), atomic unit or
raw material, of the informal language is a sentence (ending in a
period(.)), a question (ending in a question mark(?)), an exclamation
(ending in a exclamation mark (!)), and so on. The basic stored IU for
a formal language like SL/I is a specification statement, all of which
end or are terminated by a semi-colon(;).
In either case we have recognizable (and distinct) source statements.
We choose to store, maintain, and retrieve both informal and formal
language source in a single table with the following description:
<![CDATA[
dcl 1 source_table,
2 primary_name char(64) varying,
2 primary_index fixed bin (31),
2 non_name_source char(2048) varying;
]]>
What this means is that we use the text itself, its content, to
determine its primary name: up to 64 bytes of the input text. In short
every informal language sentence, every formal language statement is
stored separately within the same source table.
What it also means is that any assembly of these source IUs, e.g.
paragraph, section, chapter, etc., is stored and maintained within the
group and from_to tables of the UND.
Each of these source IUs can refer to one or more named objects, the
things of our universe to which we assign names. These objects, the
things referred to within the contexts of our source, we store
separately in an object table defined as follows:
<![CDATA[
dcl 1 object_table,
2 primary_name char(64) varying,
2 primary_index fixed bin (31),
2 attributes char(2048) varying,
2 description char(2048) varying;
]]>
The Data Repository
With these two tables (source_table and object_table) in addition to the
four tables of the UND we have all the tables necessary to support a
data repository of all source text used within an enterprise. This as
we have reported elsewhere in this document IBM tried to achieve and did
not. Perhaps one reason lies in its being too simple a solution to a
difficult problem.
The paradigm under direct attack here is the universal assumption made
by vendors of editors, compilers, linkers, debuggers, word processors,
and CASE tools that input to and output from their product is in the
form of a file, a source file. Warpicity considers source as source,
something held in common, not something stored, maintained, and
retrieved separately. There are no source files. The Warpicity
equivalent is an assembly of source, an information structure, all of
which are maintained within the UND. Thus programs and documentaion as
well as data are truly assembled from source.
This allows then from a single source the ability to create assemblies
which are user documentation only, source code only, or any combination
or internal ordering of the two. Note that this approach allows similar
storage of html and xml documents where the control codes exist as
separate IUs in the source. It could do the same for any proprietary
format used, for example, by a word processor. In effect this means
that the actual text source is now free of any proprietary constraints.
In the same way that the syntax of SL/I in conjunction with source only
invocation prevents anyone from adding incompatible source in the formal
language this method equally prevents any ability to add incompatible
source in the informal language. Thus one of the biggest buggaboos in
trying to keep various versions of vendors products and data formats in
synch is avoided altogether. The source is compatible. All source is
usable with any other.
This ability accounts for the bulk of the time and cost reductions
claimed for Warpicity, for automating clerical labor, for shifting it
from manual to machine labor. This same ability of single source for
all activities eliminates any need for status meetings: the system is
the status. You need only ask it to determine any status within it.
The Developer's Assistant (DA)
Now that we have have an introductory look at IBM's AD/Cycle; a brief
look at the specification language, SL/I, and the Universal Name
Directory; and a reference to a data repository it's time that we
introduce the tool, the Developer's Assistant or DA. It embodies what
IBM would have achieved with AD/Cycle had it succeeded. It is a single
interactive tool supporting the development process from input of
requirements through all the stages and ending with production of an
executable product.
The DA accounts for nearly all of the claimed productivity gains and
cost reductions: 50 times time reduction, 200 times cost reduction. It
does this because it assumes responsibility for all clerical support
occurring in the shift from manual to machine labor. The DA then
"knows" all the inputs, all the outputs, and all the activities
(processes) defined within the process.
For the DA to know this we must tell it. For us to tell it we must know
it. For us to know it we must analyze and design (define) a software
development process to the necessary detail level. This means also that
we must maintain the seamless (data) flow connecting every activity
(process). We can allow no discontinuities, no breaks, no intervening
manual-only methods. All data must reside at all times within the data
respository.
We are talking about a detail analysis and design of the software
development process, something which has never occurred in the entire
history of our profession. That which we insist upon performing on
client processes to achieve improvements therein we have never performed
on our own. As a result we have not offered vendors any means of
integrating their tools into a standard-defined process. Thus nowhere
from among the set of vendor tools offered does any client have the
ability to replicate the necessary seamless flow from input of
requirements to release of executable product.
IBM in remaining politically correct in its vendor partner dealings with
AD/Cycly found it politically impossible to achieve the necessary
agreement and cooperation to provide that seamless flow from the
available set of vendor tools. The DA steps aside from any political
issues, offering simply a competitive alternative to the use of all
vendor tools. Nevertheless it provides the means for any vendor to
enter to replace the DA in part or in whole in an open, competitive
manner.
You may find it difficult at first to grasp the significance of a
single, interactive interface that encompasses the entire software
development process. The DA through the UND supports defining a
hierarchical (taxonomic) information structure. This permits defining a
class structure leading from a general class of systems to one of
operating systems and another of application systems. From the
application systems' class to defining a set of applications. From
within the applications to defining the set of object and process
specifications and their class structure.
This means, for example, a seamless growth of an application system from
the simple entry of its name throughout its incremental development and
maintenance further on over its lifecycle. For any application within
the application system it means having predefined classes of element
objects (data) and their group classes of inputs, outputs, and data
stores. Thus every specification, object or process, used in an
application will appear within its class membership along with any
hierarchical structuring for either data or processes.
In short the DA continuously maintains the state of the system and every
sub-system within it down to the utmost detail. The DA can report the
state of the system at any level or from any view. For example, for any
change to a specification (amounting to a new version) it can report
every affected application (and thus application systems).
It can treat any prospective change as a "what if" situation by making
it in all affected applications and demonstrating the consequences
including full regression testing. Thus it provides an extremely
low-cost means in software development/maintenance of "trying before
buying". It does this with a single developer making a single request
with the DA assuming responsibility for all the rest, performing it at
machine speeds.
It is difficult for anyone with IT experience in software development
and maintenance to grasp the clerical pervasiveness within their work.
Thus they cannot easily grasp what it means to shift it from manual to
machine labor. They face the same credibility gap within themselves
that used to occur in client departments when IT ventured forth with its
promised gains from making that shift.
In Summary
In this we have tried to provide an overview of the components that make
up the system that is the Warpicity Project. The realization of IBM's
AD/Cycle. A specification language, the only language necessary. A
data repository integrated through a name directory. The shift of
clerical work from manual to machine labor. And a tool that does it
all.
In doing so the tool defies IT "common sense". It runs roughshod over
paradigms, of ways of doing things, over many, many years. Yet what it
does and how it does it is simpler than current practice. Getting from
current practice to that practice will require much effort and time as
we essentially must start over from scratch. We have just begun the
journey.
| 
