Features

It sounds easy enough--understand a system before you develop it and make sure it has the same meaning after it is developed. But, this is near to impossible, if not impossible, with a traditional approach.

001 is based on the Development Before the Fact (DBTF) preventative approach. With 001, such goals are able to be realized because it has the aspects, such as the following, as part of its environment (see Comparison figure):

With the use of 001's formal, but friendly systems language, USL, all models are defined and developed as system oriented objects (SOOs). Every system is an object. Every object is a system.

With the use of this language, models (including requirements, tests, targets) are evolvable systems. By their very nature systems defined with this language have built-in quality, built-in productivity and built-in control.

Whereas 75% or more errors in a traditional system are interface errors, what would have been interface errors no longer exist in a 001 system. In a traditional system, most errors are found after implementation, either manually or by dynamic test runs; some of these errors are never found. In a 001 system, all interface errors are "found"; either inherently or by static and automatic means (with the Analyzer) before implementation. All objects are under control and traceable.

The same language is used for defining any part of a system at any phase of development, whether it be requirements, testing or design.

With 001 AXES, everything is a system. The same language can be used to define a software system, hardware system, enterprise model, testing system, or any other system.

The same language can be used to define all model types within a system's environment be they requirements, process models, test cases, test scenarios including use cases, design and detailed design.

The means for capturing inherent and recursive reuse is provided by the formal definition mechanisms within USL. Not only does 001 have properties in its definitions to find, create and use commonality from the very beginning of the life cycle, it also has the ability to ensure commonality just by using its language. This means that 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.

001's preventative philosophy, to solve a given problem as early as possible, means finding a problem statically is better than finding it dynamically. Preventing it by the way a system is defined is even better. Better, faster, cheaper, yet, is not having to define (and build) it at all.

001 is an integrated, design and development environment; a system design can be seamlessly integrated to software. Requirements can be traced to design, code, test cases, or to other requirements and back again using RT(x), the requirements traceability component. Since all systems are SOOs, all parts of a 001 system are inherently integrated.

The interface between all of 001's components is seamless since they are all part of one DBTF system which is 001, itself.

USL can serve as an executable specification language. A definition has information in it for its simulator, the Xecutor, to understand its behavior and dynamically analyze it for things such as risk, timing and cost; and a higher layer operating system to execute it. For software that same definition can be used as input to 001's automatic code generator. The result is a rapid prototype for a system designer or a production ready system for a software developer. That which is simulated by 001's simulator can be integrated with that which is automatically generated by 001's generator to a very fine or loosely grained level.

A definition can have additional information about it and its relationships provided by the user. This information, together with its formal definition, is used for gathering metrics about the system and its development, providing a mechanism to trace from requirements to code and back again, ensuring that the implemented system meets the requirements. The 001 generator can use this information to generate reports on the progress or state of the development of the current target system and its relation to the original requirements.

001's Resource Allocation Tool (RAT) automatically generates complete, integrated, fully production ready code for any kind of software system whether it be GUI, database, communications, real time, distributed, client server, multi-user or mathematical algorithms. Instead of automatically supporting the user to do the work manually as is the case with traditional environments, 001 does the real work and generates a complete software solution. And even when a more traditional tool automatically does some real work, it needs to be finished and/or integrated with other code, manually. With the use of 001's RAT, no manual work is required to finish the coding.

Once 001's code is generated, it is automatically compiled and linked and executed.

001 can be configured to interface to a system at all levels, e.g., to a language, communications package, to the internet, database package or operating system of choice. Once 001's generator is configured for a new environment, 001 will automatically regenerate the new system to reside on that environment. This open architecture approach provides more flexibility to the user when changing requirements or architectures; or moving from an older technology to a newer one.

SOOs are defined to handle changes both during development and operation. There is more flexibility; yet less unpredictability than with traditional systems. All maintenance changes are made at the specification level, whether it be for simulation or for software code. Unlike before, a change in the application is made to the model or specification, not to the code; a change is made to the architecture configuration of the component which generates one of a possible set of implementations from the model, not to the code.

With traditional products, after the shell code or partial code has been generated, it is necessary for programmers to add or change code manually; as more code is written, it becomes less possible to regenerate the shell or partial code from changes in the requirements, because the manual code would be destroyed or made obsolete; the maintenance process using traditional products becomes increasingly manual as the software evolves. With 001, the user doesn't ever need to change the code, only the specification, and then regenerates (automatically) only that part of the system that has changed. Once again the system is automatically compiled, linked and executed without manual intervention.

001's GUI environment is tightly integrated with the development of any of its applications. 001 provides GUI support while preserving traceability, interface integrity and control seamlessly between the GUI part of the application and the other parts of the application. Its automatic data driven interface generator supports rapid program evolution.

Runtime constraint tests that validate correct object manipulation and construction as well as unit test harnesses for testing each object and its relationships are automatically generated by 001. An automatic user interface is provided with 001's object editor for populating and manipulating complex objects, including storage and retrieval for persistent objects. This provides the ability to test the target system at any input output interface with predefined object test data sets. Unlike with 001, this part of the process is a manual one for traditional environments.

001's documentation environment is tightly integrated with the definition of the system. In fact documentation can be automatically generated from a 001 definition by 001's RAT, wrapping in the user's own comments should it be desirable to do so; that same definition can itself become part of that same generated document. Documentation from the various model viewpoints of a system can be collected and integrated into the documentation of the system. This means for example that a resulting document could also include descriptions of the requirements, the testing, developer's issues and developer's decisions made about a system.

001 can be used to present a system before the fact to end users as a rapid and evolving prototype starting with a skeleton show and tell or mock up of what is to come. 001 enables design and modeling of any concept that humans can envision. It could be for example the target system, the testing system (including the operational model), a model of the development process for building target systems, a model of the end user's enterprise or the enterprise of the developer organization itself.

This means that one of the systems developed with 001 is 001 itself. Over 8 million lines of code have been generated by the tool suite to generate its 4 major versions. This means, that "001 is not just a product at HTI to sell, but one we use ourselves in exactly every way we have our customers use it".

Whenever 001 has been entered into a competition (including those sponsored by Carnegie Mellon, IBM, Digital, MIT, NASA, the Navy, Mitre, DoD, Lockheed Martin, McDonnell Douglas and Citibank) with the task of designing and developing a real application from the beginning to the end, 001 has always been the only one to finish the job within the required time. The productivity in getting the job done, both in time to market and cost to deliver, as well as the quality of the generated system is always much higher with 001 than with traditional methods of development.