2.4.2 Design Principles

Portability.

Portability is a must for any rigorous technical, workstation-based software implementation. A thorough discussion of the advantages of portable implementations would exceed the scope of this text, but it may be said that the requirement for portability is widely acknowledged. Despite this knowledge, existing approaches always neglected this serious requirement for the benefit of faster (initial) implementations, which later turned out as strategic mistakes. S.M. RUBIN summarized this situation in [54]:

``An important aspect of CAD systems flexibility that is overlooked by many programs is machine independence. Most systems are integrally tied to a single computer and display.''

Portability is even more crucial for an application-framework, as it exploits an immense conceptual advantage - by properly integrating an application into the framework, the application automatically becomes available on all platforms supported by the framework. This is of special value in the Technology CAD field, where a broad spectrum of workstation and mainframe platforms are in use.

Comprehensibility.

The complexity to be expected for the framework suggests that comprehensibility will be an indispensable requirement in order to benefit from the introduction of an application-framework architecture. Thus, it is of vital importance that the structure and concepts of the framework can be learned and understood with a minimal expenditure of time and effort. Therefore, a major demand is that the design and implementation of all framework components adhere to a few, simple, and consistent basic concepts. We will see that this demand often provides the decisive argument in critical architectural choices.

Re-use.

Re-use decreases complexity and increases maintainability. One requirement for introducing re-use is a modular, layered, and comprehensible design. The re-use of framework functionality by applications is the most effective contribution.

Orthogonality.

Orthogonality has at least two implications. If a set of data, objects, constructs, procedures, or modules is orthogonal, it implies (in analogy to vector orthogonality)

1. that they are independent and do not share a common functionality, and
2. that they can be combined (superimposed) arbitrarily, without restrictions, to achieve a desired functionality.

Orthogonality counteracts code duplication and improves maintainability, but is typically only achievable for low-level parts of software (those with fairly problem-independent semantics).

Abstraction.

Conventional programming language features are often not suited to reduce the complexity which arises from the implementation of functionality which is derivable from a more general, abstract principle. Redundant and tedious coding work has to be done in most cases. One can, however, bypass this error-prone task by generating the source code automatically from a more abstract formal representation. Abstraction is the key to overcome insufficient programming language power and to manage implementation complexity.

Conceptual integrity [40], orthogonality, re-use, and abstraction all contribute to the comprehensibility of the framework. Conceptual integrity can be fostered by favoring the generalization of existing concepts and the extension of their scope and level of abstraction, over the introduction of new (albeit optimal and ready-to-use) solutions.

Much too often, purely functional requirements are overemphasized at the cost of these abstract demands for software quality. A typical consequence is that systems are built from many independently developed optimal components. Despite the optimality of the single constituent parts, the sum will suffer from the multitude of different concepts.

It should be said that none of the above demands can always be entirely fulfilled. It is sometimes not feasible to strictly adhere to these guidelines, but one should strive after them. In critical design situations, the decisive argument should always be conceptual integrity and orthogonality instead of implementation effort, robustness, and portability instead of efficiency.

Fortunately, there are also more seizable, less abstract requirements for a TCAD system.