Local inconsistency and deviations from overall conceptual integrity in applications must be allowed and our experience shows that this is indeed sometimes unavoidable. As applications are created in a very short time to solve highly specialized and complex problems and as the inconsistency is confined to a local area, they are excused. One must, however, strictly insist on conceptual integrity for all framework parts, as the framework must be transparent to applications and comprehensible for the application programmers. Applications are intrinsically opaque from the framework point of view (this not entirely true for the task level which controls the application), and hence, inconsistency in applications is not fatal for the integrated system. For the framework, consistency and software quality are essential. An incomprehensible or under-documented feature will not be used, leading to shallower integration (and lack of synergetic effects) of the applications.
To build the framework, it would often have been easier and faster to glue together well-established and near-optimal partial solutions. One could, e.g., use GNU Make [67] as configuration management utility and Tcl [48] for the task level. One could even, motivated by programming power, add C++ as implementation basis to that.
Instead, by only relying on ``Standard C'' as the target programming environment (as opposed to C, C++, Tcl, and make) and by implementing several components from scratch, one suffices with a minimum of different concepts, and by re-using and generalizing these concepts as far as possible, an unsurpassed (among existing TCAD systems) conceptual integrity is reached.
The aspect of conceptual integrity shall be explained using XLISP as example: Most importantly, LISP is a superset of PIF, so that architectural homogeneity of the TCAD system is strengthened by this choice. The conceptual common denominator between LISP, the PIF (both binary and ASCII), and the PAI is so significant that the net effort for the programmer to comprehend the entire system is clearly decreased. Additional synergetic features are the potential to store task-level LISP expressions on the data level (by using the PAI basic layer) and the ability to manipulate PIF information (as LISP expressions) directly on the task level.
The re-use of the task level interpreter as a key element for the integrated CASE system is another step towards conceptual integrity and comprehensibility. The re-use of a concept has been the most important reason for this architectural choice, the advantages of LISP like that it makes no distinction between program and data and that it offers powerful symbolic manipulation features are merely welcome side effects. The complexity of the overall system is in fact decreased by the choice of a full-fledged programming language interpreter, as the generality and scope of XLISP allows far more re-use than a specialized interpreter like, e.g., Tcl/Tk would have permitted.