A system model is a disciplined view of some aspect of reality, such as the functioning or safety of a system in the world. As such it must have an appropriate structure that can correspond in a useful way with reality. Structure is therefore a key aspect of any model.
Models are extremely diverse; many types of model but by no means all involve graphics, with notations consisting of objects and connections between them, each with meanings established by a combination of the syntax of the chosen type of model, and designations relating individual items in the model to reality.
A modelling platform therefore needs to provide a range of features to be effective. It must permit a range of notations to be expressed, preferably with little or no programming effort. It must be expressive, ideally allowing designations to be written in English (or other natural languages). It must be stable so that modelling is reliable. And it must support the kinds of data structure that models typically contain, such as hierarchies and networks of objects.
DOORS is a database of a special kind. It is explicitly intended for 'requirements' but in fact supports objects of any type, organized into lists or hierarchies, connected into networks by links of any type. Both objects and links can be documented by any number of attributes of any type. This is evidently a powerful set of data structures ideally suited to the construction of business and system models. This core strength is reinforced by a well-designed user interface which gives engineers an intuitive way of accessing models and other data structures such as requirements and test cases.
In addition, DOORS provides the DXL extension language, which gives access to all the DOORS data structures with convenient access functions in a C-like programming language framework. It also allows for user and external interface construction with simple file and window handling.
I have over the years implemented a range of types of model for my own use in requirements engineering and for my clients. These models include use cases, information models, dataflows, object models, agent interactions, decision trees, product features, dictionaries and others. Most of these have benefited directly from the use of DOORS' hierarchical data structures, attributes, and links, applied in quite diverse ways. Since DOORS directly implements most of the structures that I need for these models, I have the freedom to think out what I need at a conveniently abstract level. Even quite complex architectures like use case models (multiple structured hierarchies of objects of different kinds, linked arbitrarily with several types of relationship) were implemented initially in a few days, and then allowed to evolve according to need.
Could all this have been accomplished with another platform? Possibly; there are powerful simulation and modelling platforms available to engineers, complete with sophisticated graphics, but these are tools as large as DOORS. Simpler tools such as standard programming languages (C, Pascal, etc) would have meant substantial effort designing and implementing data structures; standard relational databases (Oracle, Access, etc) would similarly have managed data as tables, demanding very considerable effort to construct and handle hierarchies of objects. Possibly some of the object-oriented databases used for handling commercial transactions could have served as well as DOORS, but these too are large, costly and complex tools.
To sum up, DOORS does the job of a modelling platform exceptionally well. It may be that some other tools could do the same, but whether any are as convenient is a question I cannot answer. Certainly I do not believe that any small and simple programming or database tool could rival it.
© Ian Alexander 2002