Protel(ID:4094/)Language with distributed modularityDeveloped by BNR for Nortel, and used to make switchboard and duplexing system. One of the first languages to introduce true modularity (after Mesa) Related languages
References: Modular programming techniques are a major tool in software evolution. Modularity emphasizes good design practices and raises design visibility. The distinction between interface and implementation sections isolates the implementation details of a module and leads to confidence that changing them should not affect overall system consistency. Use of interfaces allows mechanical determination of which system parts might be affected by a change to an interface. The benefits of modularity are difficult to quantify without performing controlled experiments in building and evolving the same large system using modularity and ad hoc techniques. However, practical experience -- at BNR and elsewhere -- has shown that system evolution is easier and more reliable in a modular environment. The major practical problem we observed in using modular programming support is that, to obtain its full advantages, there is a significant increase in the amount of compilation required. This is caused by the need to recompile all modules that use a changed interface directly or indirectly. We have built on our eight years of experience with Protel to develop the BNR Pascal programming system. In it, we have defined a set of recompilation rules and have ensured that the support tools maintain these rules: Interface additions require no recompilation. Changes to interface variables and procedures require only the recompilation of direct users. Changes to constants and types require the recompilation of all direct and indirect users. In addition, the checking mechanism that ensures no inconsistent systems are loaded is performed on a per-name basis rather than on the full-interface basis as is now the practice in Protel, Modula, and Ada. This reduces the number of modules that need recompiling to satisfy consistency checks. Another benefit of this technique is the ability to evaluate with the linker which modules are affected by a change. It is difficult to determine quantitatively the benefits of the BNR Pascal recompilation reduction aids. However, designers who have used both Protel and BNR Pascal feel that BNR Pascal features have helped apply changes more rapidly and more securely. More than 2000 BNR designers have used Protel or BNR Pascal. They strongly believe modularity is a valuable tool that has helped them significantly in building, maintaining, and evolving their software. Extract: Interface additions Interface additions In an evolving system, additions are probably the most common type of interface change. These changes should require recompilation of only the changed module. Unfortunately, in many systems, the support tools introduce unnecessary dependencies that require additional recompilation. If a designer adds an item called A to an interface, the system may not link because of an existing declaration of A in some other, unrelated part of the system. A time consuming inconvenience, the fix usually requires a change in name and a recompilation. The problem also occurs in a more serious form when two parts of the system are integrated, only to discover that both have used the name A to mean different things. In Protel, we suffered with this problem until we introduced module qualification. This language feature lets a name be qualified with the name of the module it is imported from. Other languages -- such as Modula, Ada, and BNR Pascal -- support module qualification. Providing qualified identifiers avoids the global naming problem at the compiler level. However, most system linkers -- including those on most IBM and Unix systems -- do not support module qualification and instead resolve names globally. In such systems, language-module qualification is implemented by the compiler translating the qualified identifier into a global name typically consisting of the module name followed by some encoding of the identifier (for example, its procedure number or variable offset). This approach creates some unnecessary mechanical dependencies that increase the need for recompilation. Mechanical dependencies have nothing to do with the semantics of the system being developed but are caused exclusively by how development tools are implemented. Examples of such dependencies are use of procedure numbers and variable offsets to resolve intermodule links. For example, consider a system where links are resolved with procedure numbers. Introducing a new procedure in the middle of the interface means that all subsequent procedure numbers change and thus requires all direct users of the enhanced interface to be recompiled. This is the case in Protel. In practice, such recompilation is tedious enough that designers tend to avoid it by placing interface additions at the end of the interface. Although this avoids recompilation, it leads to interfaces where, over time, closely related procedures are scattered. With proper tool design, it is easy to avoid mechanical dependencies. The BNR Pascal support tools were designed with this in mind. The results are systems whose interfaces can be extended with minimal recompilation effort: only the changed module need be recompiled. Extract: Experience Experience. BNR's experience with modularity shows that it assists many aspects of software structuring, project management, system documentation, and configuration managements However, we feel its major advantage is that it improves our systems' designs and lets us rapidly and reliably evolve them. Greater emphasis on design. Modularity provides and consolidates the design and programming practices described in detail in the box on p. 50: Duplication of declarations is avoided by declaring items in only one interface and importing them from there. User-defined type mechanisms are used to group related items and avoid inconsistencies between them. Dependency relationships are maintained explicitly through the Uses list. Information-hiding is encouraged by the separation of interface and implementation. In the past, design decisions might have been made subconsciously and buried in the code. Modularity emphasizes key structural decisions. The more obvious example is specifying the function of a module in the interface rather than in the implementation detail. This forces a designer to make explicit (and account for) design decisions. Modularity increases the visibility of design structure. This lets new designers learn the system more rapidly. It also focuses the design reviews on interfaces, deferring detailed discussions on implementation. Evolving a design requires a choice between a number of alternatives and their effects on the system. A designer wanting to make a change spends lots of time sifting through source code to obtain information (such as system connectivity) to help make the decision. Modularity increases the visibility of the design, so the designer can spend more time understanding and deciding -- rather than gathering the information on which to base the decision. Implementation changes. Modularity stresses an important distinction between interface changes and implementation changes. As long as they do not affect the semantics of the interface, changes to an implementation may take place with complete confidence that they cannot create inconsistencies with other parts of the system. Of course, it requires great care on the designer's part to ensure that the meaning of the interface is not changed. For example, a change in a sort routine to return a descending sequence in place of an ascending one may be totally an implementation change but is likely to have violent repercussions on the rest of the system. More realistically, a bug fix may subtly alter the meaning of an interface procedure and cause a failure for the user who depends on that subtlety. In our experience, neophyte designers and, occasionally, experienced designers are lulled into a false feeling of security when making implementation changes. However, after a couple of incidents, they rapidly become more careful in assessing the potential effects of their implementation changes on interlace semantics. Interface changes. Modularity makes _ interface changes easier and more reliable. Interface changes are easily propagated through the system and any inconsistencies are detected by recompiling all modules that use directly or indirectly a changed interface. (Indirect users are modules that use a direct user of the interface or that use another indirect user of the interface.) Published practical experience eloquently describes this. The Mesa group at Xerox found that "the experience of many projects in Mesa is that once a previously running system has been successfully recompiled and rebound following changes to its internal or external interfaces, it will immediately run with the same reliability as before. " BNR's experience with Protel echoes this, concluding that "the major benefits we have experienced were better control of project development and maintenance, improved capacity for change and system evolution, ease of configuring slightly different systems from common modules obtained from a system library, and, most importantly, the detection of errors by the compiler at an early stage of system construction". However, lest it be thought that modularity is a cure-all, note that applying modularity does have its costs (described in the box on p. 53). The major cost is the need to recompile module users when an interface change is made. Extract: Modular languages Modular languages Systems written in modular languages are built from modules (also called "packages" and "units"). A module contains an interface section and an implementation section. The interface of a module specifies types, data, and procedures exported by the module. The implementation contains the executable statements of the interface procedures, along with additional type, data, and procedure declarations private to the module. Names defined in a module's interface section are accessible from outside the module, while those in the implementation section are hidden. A module indicates that it wants to import the names declared in the interface of another module by including that other module's name in a list of used modules (called the Uses list). Figure l shows a subsystem containing three modules. In the figure, each box is a module. The top part of the box is the interface and the bottom part is the implementation. The module imports those items declared in the interfaces of modules in the Uses list. For example, items declared in the interface of modules A and B are visible throughout module X. However, the items of A are not seen by B and vice versa. When a module is compiled, the compiler produces information on all names declared in its interface. This information is read during the compilation of other modules to perform compile-time checking of intermodule references. Abstract: Modularity is invaluable, but changes in one module can have a domino effect on others, requiring significant extra compilation.. BNR Pascal reduces this extra compilation.. Large software systems are not static. Over their lifetime they evolve significantly to meet new and changing requirements. As much as 70 percent of the cost of large systems software has been attributed to this evolution. System evolution, which is sometimes inaccurately called maintenance, causes much change to the design and implementation of a system. System evolution requires much expertise about the structure and behavior of the whole system. It is probably the greatest contributor to software's overall cost and lack of quality. Over time, programming practices have evolved that improve ways to change a system. Many of these practices have come together under the heading of modularity. Modularity techniques have gained wide acceptance and have, been supported by development tools, primarily programming languages. The first languages to do this were the proprietary languages Mesa in 1974 and Protel in 1975. Languages such as Modula and Ada followed suit. At BNR (Bell-Northern Research), the first support for modularity occurred in 1975 with the Protel language, its support tools, and its PLS library system. Our parent company, Northern Telecom, uses Protel in its DMS digital multiplex systems family of digital switching systems. DMS switches are configured from a collection of software modules that provide local, toll, gateway, PABX, Centrex, and valuea-dded facilities. DMS software contains more than 4 million lines of source code and nearly 5000 modules. This software is not simply a library of application programs but a single system design with configuration options. We firmly believe that we could not have evolved a system as large as DMS without modularity features to control the evolution of the design and implementation and to permit fast and reliable change. Recently, we implemented a new language, BNR Pascal.6 In BNR Pascal, we maintained the successful modularity features of Protel but attacked Protel's bottleneck: the need for recompilation of all modules that use an interface when that interface changes. To do so, we have defined recompilation rules for different change classes of interface and ensured that the development tools support these rules. We also designed an improved checking technique to detect modules that should have been recompiled but were not. Experience with 3 million lines of BNR Pascal shows that these recompilation rules and checks can reduce recompilation during development by as much as a factor of three. Since the modularity features of Protel and BNR Pascal are functionally similar to those of Modula and Ada, our practical experience also applies to tools for and software designs in those languages. |