Introduction to the 001 Tool Suite

The 001 Tool Suite; also referred to as 001: Digital Gold, or simply 001, and pronounced "double-oh-one" was created to automate the mathematically based paradigm, Development Before the Fact (DBTF). Along with its automation, DBTF has been used in research and "trail blazer" organizations; and is now being adopted for commercial use.

In addition to its roots in real world system design and software development, DBTF has roots in other worlds including systems theory, formal methods, formal linguistics and object technology. Although it is new, it would be natural to make assumptions about what is possible and impossible based on its superficial resemblance to other technologies such as object technology. It helps, however, to suspend any and all preconceived notions when first introduced to DBTF, because DBTF is a world unto itself-a completely new way to think about systems and software.

What makes DBTF different is it is a preventative paradigm instead of a curative one. Problems associated with traditional methods of design and development are prevented "before the fact" just by the way a system is defined. That is, DBTF concentrates on preventing problems of development from even happening; rather than letting them happen "after the fact", and fixing them after they've surfaced at the most inopportune and expensive point in time.

A formal systems language based on DBTF's foundations, USL, is used to define a DBTF system. With this language, a system has properties that come along "for the ride" that in essence control its own destiny; because of these properties, many things heretofore not believed possible with traditional methods are now possible with DBTF [Table 1]. DBTF's automation, 001, is used to ensure that these properties are captured throughout a system's design and development.

Although a total system engineering and software development environment, 001 can be used to coexist and interface with other tools. It can be used to design a system, prototype a system or develop a software system fully. 001 breaks the development life cycle into a sequence of stages, including: requirements and design modeling by formal specification and analysis; automatic code generation based on consistent and logically complete models; test and execution; and simulation.

001's motivation is to facilitate the "doing things right in the first place" development style, avoiding the "fixing wrong things up" traditional approach. To automate the theory, 001 is developed with the following considerations: error prevention from the early stage of system definition, life cycle control of the system under development, and inherent reuse of highly reliable systems.

001 provides traceability from requirements to design to implementation; the system under development is manageable and maintainable. Systems being managed are objects from the viewpoint of 001. Objects in one phase-say, requirements-are traceable to objects in the next phase of development, the specification phase. This feature is helpful for large, complex software systems, for which maintenance in traditional environments is even more time and effort consuming than development.

USL lies in the heart of 001. Although formal, this language is practical and friendly. It can be used to define any kind of system the human mind can envision and develop any software application that has the potential to be implemented. Based on a theory that extends traditional mathematics of systems with a unique concept of real time distributed control, USL has embodied within it a natural representation of structured relationships of objects and their interactions as events.

All USL models are defined and developed as system oriented objects (SOOs). A SOO is understood the same way without ambiguity by all other objects within its environment-including all users, models and automated tools. Each SOO is made up of other SOOs. Every aspect of a SOO is integrated not the least of which is the integration of its object oriented parts with its function oriented and its timing oriented parts. The philosophy which supports the theory that to integrate all the objects in a system you need be able to integrate all aspects of each object in the system is strongly adhered to.

Instead of systems being object-oriented, objects are systems-oriented. The means for capturing inherent and recursive reuse is provided by the formal definition mechanisms within 001/USL. Not only does it have properties in its definitions to support the designer in finding, creating and using commonality from the very beginning of a system's life cycle; commonality is ensured simply by using this language. This means the modeler does not have to work at making something become object oriented. Rather he models the objects and their relationships, and the functions and their relationships; and the language inherently integrates these aspects as well as takes care of making those things that should become objects become objects.

Every SOO is a candidate to be a reusable-and it is inherently integratable-within the same system, within other systems and within all of these systems as they evolve. This is because every object is a system and every system is an object.

USL provides the necessary information in its definitions for an automated environment to know whether a system should be allocated to distributed, asynchronous or synchronous processors; or whether two processors or ten processors should selected. With traditional methods, it is up to the developer to incorporate such detail into his application. For any change in the architecture, it is necessary for the developer to then redesign and redevelop his applications that are impacted by that change. With DBTF, this is not necessary, since this process is inherent and automated.

DBTF users are not tied to any particular process model for development when building an application (eXtreme Programming, spiral development, waterfall development, etc.) other than that which is implied by the USL language.

With DBTF the same language semantics is used throughout a life cycle to define all aspects of a system including its requirements, system design and software design models; enterprise, hardware and software models; functional, timing (e.g., scheduling) and object oriented parts of each model. Models are defined and designed with USL; and simulated (to understand a system's real time distributed behavior), developed (to show a generated software implementation), tested and maintained with 001.

Once USL is used to capture the essence of DBTF in defining a system, complete software implementations (100% of the code) are automatically generated by 001 in a developer's language of choice (such as Java, C or C++). Although the current commercial versions of 001 are hosted on UNIX and Linux, other environments can be cross targeted with 001 from the host to the target architecture (for example, web applications developed using 001 on Linux but generated by 001 to reside under NT).

Because it is based on DBTF, 001 is able to automatically generate all of (and any kind of) software system from a set of USL defined requirements, specifications or design--for any configured architecture. This is in fact how the 001 Tool Suite itself was developed. That is, it is defined with itself and it automatically (re)generates itself as an ongoing evolving system on many diverse architectures.

Since all the components within 001 are inherently integrated as part of the same DBTF system (Figure 1 contains a simplified USL object type definition of the tool suite's architecture), no additional time and effort is needed for integrating diverse products for developing different parts of a system, phases of the system, or for integrating the modules or views (e.g., use cases, data flow, timing, state transition and object types) of a module created with or resulting from these disparate products. If one component is used for, say, definition and another for analysis and still another for generating code, there will not be interface mismatches between these components of the tool suite. Similarly, there are no interface mismatches between the components of the applications developed with the tool suite-and, no interface mismatches between each component's states of development.

Although a total system engineering and software development environment, 001 can be used to coexist and interface with other tools. It can be used to design a system, prototype a system or develop a software system fully. 001 breaks the development life cycle into a sequence of stages, including: requirements and design modeling by formal specification and analysis; automatic code generation based on consistent and logically complete models; test and execution; and simulation.

001's motivation is to facilitate the "doing things right in the first place" development style, avoiding the "fixing wrong things up" traditional approach. To automate the theory, 001 is developed with the following considerations: error prevention from the early stage of system definition, life cycle control of the system under development, and inherent reuse of highly reliable systems.

001 provides traceability from requirements to design to implementation; the system under development is manageable and maintainable. Systems being managed are objects from the viewpoint of 001. Objects in one phase-say, requirements-are traceable to objects in the next phase of development, the specification phase. This feature is helpful for large, complex software systems, for which maintenance in traditional environments is even more time and effort consuming than development.

USL lies in the heart of 001. Although formal, this language is practical and friendly. It can be used to define any kind of system the human mind can envision and develop any software application that has the potential to be implemented. Based on a theory that extends traditional mathematics of systems with a unique concept of real time distributed control, USL has embodied within it a natural representation of structured relationships of objects and their interactions as events.

All USL models are defined and developed as system oriented objects (SOOs). A SOO is understood the same way without ambiguity by all other objects within its environment-including all users, models and automated tools. Each SOO is made up of other SOOs. Every aspect of a SOO is integrated not the least of which is the integration of its object oriented parts with its function oriented and its timing oriented parts. The philosophy which supports the theory that to integrate all the objects in a system you need be able to integrate all aspects of each object in the system is strongly adhered to.

Instead of systems being object-oriented, objects are systems-oriented. The means for capturing inherent and recursive reuse is provided by the formal definition mechanisms within 001/USL. Not only does it have properties in its definitions to support the designer in finding, creating and using commonality from the very beginning of a system's life cycle; commonality is ensured simply by using this language. This means the modeler does not have to work at making something become object oriented. Rather he models the objects and their relationships, and the functions and their relationships; and the language inherently integrates these aspects as well as takes care of making those things that should become objects become objects.

Every SOO is a candidate to be a reusable-and it is inherently integratable-within the same system, within other systems and within all of these systems as they evolve. This is because every object is a system and every system is an object.

USL provides the necessary information in its definitions for an automated environment to know whether a system should be allocated to distributed, asynchronous or synchronous processors; or whether two processors or ten processors should selected. With traditional methods, it is up to the developer to incorporate such detail into his application. For any change in the architecture, it is necessary for the developer to then redesign and redevelop his applications that are impacted by that change. With DBTF, this is not necessary, since this process is inherent and automated.

DBTF users are not tied to any particular process model for development when building an application (eXtreme Programming, spiral development, waterfall development, etc.) other than that which is implied by the USL language.

With DBTF the same language semantics is used throughout a life cycle to define all aspects of a system including its requirements, system design and software design models; enterprise, hardware and software models; functional, timing (e.g., scheduling) and object oriented parts of each model. Models are defined and designed with USL; and simulated (to understand a system's real time distributed behavior), developed (to show a generated software implementation), tested and maintained with 001.

Once USL is used to capture the essence of DBTF in defining a system, complete software implementations (100% of the code) are automatically generated by 001 in a developer's language of choice (such as Java, C or C++). Although the current commercial versions of 001 are hosted on UNIX and Linux, other environments can be cross targeted with 001 from the host to the target architecture (for example, web applications developed using 001 on Linux but generated by 001 to reside under NT).

Because it is based on DBTF, 001 is able to automatically generate all of (and any kind of) software system from a set of USL defined requirements, specifications or design--for any configured architecture. This is in fact how the 001 Tool Suite itself was developed. That is, it is defined with itself and it automatically (re)generates itself as an ongoing evolving system on many diverse architectures.

Since all the components within 001 are inherently integrated as part of the same DBTF system (Figure 1 contains a simplified USL object type definition of the tool suite's architecture), no additional time and effort is needed for integrating diverse products for developing different parts of a system, phases of the system, or for integrating the modules or views (e.g., use cases, data flow, timing, state transition and object types) of a module created with or resulting from these disparate products. If one component is used for, say, definition and another for analysis and still another for generating code, there will not be interface mismatches between these components of the tool suite. Similarly, there are no interface mismatches between the components of the applications developed with the tool suite-and, no interface mismatches between each component's states of development.

Figure 1: The 001 Tool Suite Architecture Defined with 001

Vertically, there are two model spaces in 001:

Definition space: the static specification of the system under development. Every model is defined in terms of Function Maps (FMaps) to capture time characteristics and Type Maps (TMaps) to capture space characteristics, which guide a designer in thinking through his concepts at all levels of system design (Figure 2). TMaps are used for defining types of objects and the relationships between those objects, FMaps are used for defining things done with the objects, in the TMap (i.e., for defining functions and state transitions; including timing, ordering and priorities). FMaps and TMaps are inherently integrated. In 001, FMaps exist either as FMap operations or as FMap structures (user configurable FMaps); TMaps exist simply as TMaps or TMap structures (user configurable TMaps, called parameterized types).

Figure 2: Definition/Execution Space of USL Defined Systems

Execution space: the realization of the definition space, reflecting the run-time performance of the system. This space is realized in terms of Execution Maps (EMaps, instantiations of FMaps) and Object Maps (OMaps, instantiations of TMaps, see Figure 2).

All USL maps (sometimes referred to as control maps) are defined in terms of formal structures of control (control of input access, output access, input values, output values, error detection, invocation, timing and priorities). Features such as polymorphism, encapsulation, inheritance, and persistence formally reside both on the function side as well as the object side of a system; where the functional side is defined in terms of the object side and vice versa, providing the ability to automatically trace within and between levels and layers of a system.

Components within 001

One set of components within the tool suite, 001Developer, is used by a developer or designer to work with the definition space of a system; another set, 001Engineer, is used by the system designer to understand a system's execution space.

USL can be thought of as operating in two distinct modes within the 001 environment:

Executable specification: USL can serve as an executable specification language. In this mode, a USL definition can serve as input to 001's simulator component (the Xecutor configured for simulation) for dynamic analysis during the design phase; or it can be layered onto 001's DXecutor (when the Xecutor is configured as a stand-alone distributed object manager) for distributed system development.

Automatic code generation: a 001/USL definition serves as input to the code generator for purposes of prototyping or production software development. This feature facilitates the automatic programming of language independent, platform independent software development.

001Engineer contains components for systems design (system engineering, process modeling, enterprise modeling). It consists primarily of the requirements traceability component, RT(x), for analyzing and tracing requirements, and a simulator component (Xecutor in simulation mode) that simulates a USL model.

001Developer contains components used by both system designers and software developers. It consists primarily of graphical editing capabilities for defining models (Definition Editors), an Analyzer component that checks models for consistency and logical completeness, a generator component (RAT) that automatically generates executable code or documentation from USL models, the OMap Editor for viewing and testing objects and a set of reusable building blocks.

In addition to other reusables supplied by 001Developer, the designer starts with a tool kit or foundation of primitive types and a set of existing types in the form of universal and core types. The designer also has the option of defining and building his own types as well as other types of reusables with 001.

In addition to the components within the 001 Tool Suite, other 001 developed components are available to support 001 users. An example of such a component is a product called WebJumpStarter, a "middleware" reusable for jump starting 001 developed web based applications. The example in this paper uses 001 along with the WebJumpStarter in its development process.

With 001, the developer doesn't ever need to change the code. SOOs are defined to handle changes both during development and operation, providing for more flexibility, yet less unpredictability than with traditional systems. Application changes are made to the specification-not to the code (whether it be for simulation or for software). Changes to the architecture of the application are made to the configuration of the generator environment (which generates one of a possible set of implementations from the model)-not to the code. Once a change has been made to either the specification or the architecture configuration only that part of the system that has been changed is regenerated and integrated with the rest of the application (again, automatically). The system is then automatically generated, compiled, linked and executed without manual intervention.

DBTF's preventative philosophy, to solve a problem as early as possible, means finding that problem, statically (before implementing it) is better than finding it dynamically at testing time. Preventing it by the way that system is defined is even better. Better, faster, cheaper; better yet, is not having to define the system (and build and test) it at all. This is the philosophy adhered to in designing systems and developing software with 001.