SCOUG Logo


Next Meeting: Sat, Oct 19, 2019
Meeting Directions


Be a Member
Join SCOUG

Navigation:


Help with Searching

20 Most Recent Documents
Search Archives
Index by date, title, author, category.


Features:

Mr. Know-It-All
Ink
Download!




SCOUG:

Home

Email Lists

SIGs (Internet, General Interest, Programming, Network, more..)

Online Chats

Business

Past Presentations

Credits

Submissions

Contact SCOUG

Copyright SCOUG



warp expowest
Pictures from Sept. 1999


The views expressed in articles on this site are those of their authors.

warptech
SCOUG was there!


Copyright 2019, Southern California OS/2 User Group. ALL RIGHTS RESERVED.

SCOUG, Warp Expo West, and Warpfest are trademarks of the Southern California OS/2 User Group. OS/2, Workplace Shell, and IBM are registered trademarks of International Business Machines Corporation. All other trademarks remain the property of their respective owners.

The Southern California OS/2 User Group
P.O. Box 26904
Santa Ana, CA 92799-6904, USA
The Warpicity Project
Lynn Maxson, Warpicity Founder and SCOUG Member

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:

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.

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:

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:

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.