To offset IBM's withdrawal from the SOHO desktop marketplace with regards to OS/2, the OS/2 community must become self-sufficient with respect to an operating system that's vendor independent and more responsive to user needs.
1. Overview
1. The following outline represents a work-in-process of
a complete proposal of an organization, its staffing, and its means to
provide an alternative and independent means of software users to have
investment protection in terms of post-sales support and enhancements.
Though initially directly at providing such for OS/2 users through a fully
compatible and extensible operating system tentatively dubbed "Warpicity",
the means support all forms of software development. Warpicity represents
a generic model of an operating system intended to support the APIs and
thus the applications available on Intel (and non-Intel) processors, specifically
Linux and MS Windows-based OSes.
2. The proposal uses the "classical waterfall" method
of the software development process: specification, analysis, design, construction,
and testing. It uses a single interactive tool, the Developer's Assistant
(DA), which provides the developer with all the necessary clerical assistance
supporting a "true" integrated development environment (IDE), making the
system the only source of documentation and thus the only source for system
status as well.
3. The Developer's Assistant as an application derives
from using standard structured analysis and design methods on the software
development process in the same way we would use them on any client process
and for the same reasons: increased throughput, leading to reduced costs
and higher productivity. The analysis resulted in the proposed specification-centric
(and -only) approach: no use of any programming language, only a specification
language based on established logic programming methods.
4. The specification language must lead to an "executable"
in some "target" machine language. We achieve this by incorporating
the specification of each target machine architecture within our common
specification pool or library. We then use logic programming instead
of programming logic to translate the components of any higher level specification
in terms of those of a lowest level target machine architecture.
5. This translation of any component follows the logic
programming habit of providing "all" possible results. Thus we can
select from them those which give the best performance or those which minimize
memory space. We can also choose in any instance of a component occurring
within another component to execute it inline or as a called subroutine.
This leads to achieving performance levels not possible with any programming
language like C or C++ and at minimum equal to the best assemby language.
6. The last question which remains lies in maintenance.
The specification-centric approach offers the lowest cost and the fastest
means of performing maintenance than any programming-centric alternative,
including all forms of OO. In fact it has the ability to
respond to a change request in less than the average interval between requests.
2. Proposal
1. Independent OS/2 user community
1. Investment protection
1 Unlimited scalability
1. Platform independence
2 Unlimited extensibility
1. Function
2. Vendor independence
1 User determines
post-sales support (who)
2 Unaffected by vendor
status
1. Out of business
2. Product withdrawal
3. Support withdrawal
4. Market segment
3 Non-proprietary
choice
1. No copyright
2. No intellectual property
3. User owns "source code".
3. Buyer independence
1 "Full" product ownership
4. Operating Systems
1 Target system
1. "Warpicity": The Essence of Warp
1. A single "generic" operating system incorporating "all" the
functions and features of existing operating systems with
support for "all" applications (past, present, and future).
2. Platform independent
2 Source systems
1. OS/2
2. Windows 3.xx, Windows 9x, Windows NT
3. UNIX, including LINUX, HP UX, Sun Solaris, IBM AIX, SCO UNIX
4. IBM, including VM, MVS, VSE, and OS/400
2. Presenter
1. Lynn H. Maxson
1 lmaxson@ibm.net
2 71233,1254 CompuServe
3 OS2FORUM, S14/For
What It's Worth
3. Organization
1. Member-based
1. Direct democracy
1 One member, one
vote
1. Every vote counts
2. Board as a whole
3. Member "rights"
1 Unlimited Usage
1. No copy limits
2 Unrestricted usage
1. Including ability to compete
1. Note: Allows any dissenting minority interest to pursue
alternate course, preventing tyranny of majority
3 Full ownership
1. Source
1. Specification pool/library
2. Tools
1. Developer's Assistant (DA)
2. Subscription-based
1. Annual
2. Minimal fee
(suggested $20/yr)
4. Staffing
1. Performance-based contract
1. Permanent staff positions determined
by "board"
2. Chief Librarian
1. Communication
1 Internal/External
2. Administration
1 Fincance
3. Chief Developer
1. Responsible for all development
5. Means
1. Specification-centric development
1. Premise
1 Hardware, software:
100% logic-based
2. Recognises "specification" step as
"central transform"
1 Application of SAD
to SDP
1. Physician, heal thyself.
2 Write specifications
only: no writing of programs
1. Prolog is a programming language. Any use instance is capable
of producing only a "single" program, i.e. incapable of
producing an application system of any combination of batch,
interactive, and distributed.
2. Prolog uses the same "rule-based" approach to generating
machine language executable code as do non-logic programming
languages, each use instance of which also only capable of
producing a single executable.
3 Specification process
1. Specification pool/library
1. The set of "all" specifications.
2. Development stages
1. Specification
1. Formal translation of "requirements" into specifications
for addition to specification pool.
1 Includes machine architectures
2. Analysis
1. Selection of an "(named) instance" set of specifications
from the specification pool.
2. Ambiguity resolution
3. Design
1. Specification of "desired" forms: hierarchical setting
of subassemblies: the "design" specification
4. Construction
1. The translation of a specification from "analytical
(logical)" to "executable (physical)" format.
5. Test
1. As the specification must be "logically correct" only an
error in the "external" requirements can occur. This
results in "adding" a "new" requirement, resulting in
turn in a "new" specification. No "modification" of an
"existing" specification occurs. Thus only a new
"version" with corresponding "replacements" occurs: no
rewrite (copy with replacements)
3. Advantages
1. Respond to change requests faster than they arrive:
response time < change rate interval
4 Specification
1. Inherently reusable
2. Intrinsic patterns
3. Note: Requires no "outside" (user) intervention
3. Supports integrated development of
application systems
1 <application
system> ::== <application>...
2 All options/combinations
1. Batch
2. Interactive
3. Distributed
1. Peer-Peer
2. Client-Server
3 Unlimited scalability
1. Number of applications per system
2. Size of application
4 Eliminates need
for "freezing"
4. Provides "true" Integrated Development
Environment (IDE)
1 Only the system
can provide its status: completely internal, no
external components
1. Eliminates "need" for "status meetings": no one knows more
than what system can provide
2 Has never occurred
previously in history
3 Uses only a "single"
tool: Developer's Assistant
1. Connects requirements to specifications
2. Supports all operations on specifications
3. Translates a specification into an executable
5. IPO format
1 Input...........Process.........Output
2 <requirement>
[specification] <specification>
3 <specification>
[analysis] <specification>
4 <specification>
[design] <specification>
5 <specification>
[construction] <executable>*
6 <executable>*
[testing] <requirement>
7 Note: <executable>*
::== <executable specification>
8 Note: Flawless "internal"
logic within stepwise refinement of
specification. Thus no internal logic errors: produces logically
consistent specification. Only "external" errors possible:
requirement. Correction: add new requirement, repeating process.
6. <specification><op><specification>
-> <specification>
1 Conforms to set
theory as implemented in relational database
managers: <set> <op> <set> -> <set>
7. <requirement> -> <specification>
-> <executable>* -> <requirement>
1 <executable>*
::== <executable specification>
8. "Universal" Modelling Language (UML)
1 As opposed to OO
"Unified"
9. Level of Abstraction
1 Manufacturing levels
1. Final Assembly: Highest (relative to this construction) Level
of Abstraction
1. Bill of Material
1. Provides stepwise refinement through all lower levels in
which all subassemblies resolve into the raw materials
2. Sub-assembly
1. <sub-assembly> ::== <raw material>...|
[<raw material>][<sub-assembly>]
3. Raw Material
1. Machine Archectecture
4. Low-level code (LLC)
2 Predicate levels
1. Zero level predicate
1. Machine architecture (RISC)
2. First level predicate
1. Machine architecture (CISC)
3. Second level predicate
1. Control structures
1. Sequence
2. Decision
3. Iteration (recursion)
4. Third level predicate
1. First level function (atomic)
5. Fourth and higher
1. Higher-level functions (non-atomic)
6. Low-level code (LLC)
1. Exception: recursion
2. Current thinking
1. Specification language based on predicate
logic
1 Predicate
1. Name
2. Head
1. Variables
3. Body
1. Assertions on variables
1. Including "control logic"
4. Sample: Taken from Trilogy User's Guide
1.
2. Language choices
1 PL/I data types
2 APL2
1. Operators
2. Symbol Set
3. Strict left to right/right to left evaluation
1. No operator precedence
2. Force use of parenthesis
3 Predicate logic
3. References
1 Logic Programming
1. Visual Prolog--Causal Logic
2. "Simple Logical: Intelligent Reasoning by Example"--Flach
1. Language specification
1. Syntax
2. Semantics
3. Proof-theory
1 Note "proof" difference between logic programming
(Prolog and Trilogy) and programming logic (C, C++,
JAVA, COBOL, PL/I, etc.).
4. Meta-theory
1 Note: If capable of expression within the same
language, it becomes "self-reflexive", "closed
(logically complete in terms of necessary and
sufficient), and "extensible" (unlimited).
3. Trilogy--Predicate Logic
4. Trilogy User Guide--Paul Voda
5. "Programs for Fast, Flawless Logical Reasoning"--Wos
(CACM,June 1998)
2 Set Theory
1. "Sets, Relations, Functions: An Introduction"--Selby, Sweet
3 Functional Programming
1. "Functional Programming: Application and Implementation"--
Henderson
2. "Principles of Functional Programming"--Glaser, Hanikin, Till
3. "Recursive Programming Techniques"--Burge
4 Z-specification
Language
1. Predicate logic
2. "Software Development with Z"--Wordsworth
3. "Z in Practice"--Barden, Stepney, Cooper
4. "Z: An Introduction to Formal Methods"--Diller
5. "Using Z: Specification, Refinement, and Proof"--Woodcock,
Davies
5 Artificial Intelligence
1. Purpose
1. Pattern recognition/mapping
2. Experiential system: Developer's Assistant
2. "Artificial Intelligence: A New Synthesis"--Nilsson
3. "Fundamentals of the New Artificial Intelligence"--Munakata
6 Lambda calculus
1. "Machine Organization,..."--Wegner
3. Universal Name Directory (UND)
1. Relational Form
1 EGA_TABLE
1. PRIMARY_NAME
2. PRIMARY_INDEX /* homonym and version control */
3. PRIMARY_TYPE
'E' -- element name
'G' -- group name
'A' -- alias name
2 ALIAS_TABLE (Synonym)
1. ALIAS_NAME
2. ALIAS_INDEX
3. PRIMARY_NAME
4. PRIMARY_INDEX
3 GROUP_TABLE
1. GROUP_NAME
2. GROUP_INDEX
3. RELATIVE_POSITION
4. REFERENCE_NAME
5. REFERENCE_INDEX
4 FROM_TO_TABLE
1. GROUP_NAME
2. GROUP_INDEX
3. FROM_REL_POSITION
4. TO_REL_POSITION
4. AD/CYCLE
1. Software Development Cycle (SDP)
1 specification|analysis|design|construction|test
2. Product
1 Currently
1. Bachmann
2. CASE tools
3. Compilers
4. Editors
5. ICE (Integrated Construction Environment): not IDE
2 Proposed
1. Developer's Assistant
3. Data Respository
1 UND-based