Comparison Intro To OO1 Glossary

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):

Formal but friendly language

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.

A SOO is a formal model that is understood the same way without ambiguity by all other objects within its environment--including all users, other models and automated tools.   Each SOO can be 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 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.

The language ensures that all systems defined with it will have all of its objects under control. This means for example, that an object (which could itself be a set of objects) by its very existence maximizes the potential for its own inherent and recursive reuse, traceability, reliability (errors not allowed in before the fact), architecture independence, capitalizing on parallelism, flexibility to change (models can be "un-plug-in-able" and "plug-in-able"), inherent integration, automation and evolution. These and other properties that support a system's development inherently "come along for the ride" with every SOO.

With such a language there is no need to distinguish between types of applications; we can therefore naturally integrate all aspects of a model or system throughout all of its phases of development: function oriented with object oriented, GUI with application, software to hardware to peopleware, target application to testing, phase to phase, and change to change.

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.

No interface errors

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.

Same language for all phases and all viewpoints

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

Same language for all systems

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.

Inherently reusable

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.

Object oriented-like features such as polymorphism, encapsulation, inheritance 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 trace within and between levels and layers of a system.

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.

Integrated seamless design and development environment

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.

There is no longer an additional expense 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.

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

Executable specifications

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.

Integrated metrics for predictive systems

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.

100% automatic code generation

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.

The generator is accessible to a 001 user to tailor it for his own brand of generated code, if needed. This generator can be used to provide output information that can be used as input by other tools or as output for testing (such as showing all of the decision points in the system). This feature can also be used as another means of rapid prototyping for systems design studies.

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

Open architecture

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.

Maintenance performed at the blueprint level

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.

GUI environment tightly integrated with the development of an application

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.

Automated testing

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.

Automatic documentation

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.

User's mock up environment

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.

001 was completely defined and generated with 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".

Always number one when put to the test

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.

HTITable2.gif (898 bytes)
HTITable.gif (901 bytes)

001, 001:Digital Gold, Digital Gold, 001 Tool Suite, USL, Universal Systems Language, 001AXES, Function Map, FMap, Type Map, TMap, Object Map, OMap, Execution Map, EMap, Road Map, RMap, Xecutor, OMap Editor, 001 Analyzer, SOO, System Oriented Object, Resource Allocation Tool, RAT, AntiRAT, Object Editor, Primitive Control Structures, Development Before the Fact (DBTF), RT(x), VSphere, escherTMap, agent 001db are all trademarks of Hamilton Technologies, Inc.

© 1986-2017, Hamilton Technologies, Inc.