36 An object-oriented environment ate into Beethoven'sChoral Symphony,a baritone breaks the stream of astounding but until then purely instrumental sounds to awake us to something even grander: O my friends!No more of these tunes! Let us strike up instead Some more pleasant and friendly songs. After reviewing in the preceding chapters some of the common approaches to O-O development,we should similarly end with a perhaps more modern and comprehensive approach(with no intended disparagement of the others;after all the Ninth's first three movements,before it goes vocal,already were pretty decent stuff.) The diagram is on This chapter presents an environment(ISE's)that relies on the principles developed page 1149. in the rest of this book,and makes them available concretely to O-O software developers. A complete diagram ofthe environment appears later in this chapter;some of the principal components are included for trial purposes in the CD-ROM attached to this book The purpose of this presentation is to put the final touch to our study of object technology by showing how environment support can make the concepts convenient to use in practice.A caveat:nothing in this discussion suggests that the environment discussed below is perfect (in fact,it is still evolving).It is only one example of a modem O-O environment;others-such as Borland's Delphi to name just one-have met wide and deserved success.But we need to explore one environment in some depth to understand the connection between the method's principles and their day-to-day application by a developer sitting at a terminal.Many of the concepts will,I hope,be useful to readers using other tools. 36.1 COMPONENTS The environment combines the following elements: An underlying method:the object-oriented method,as described in this book A language,the notation presented in this book,for analysis,design and implementation. A set of tools for exploiting the method and the language:compiling,browsing, documenting,designing. Libraries of reusable software components. The next sections sketch these various elements,except for the first which,of course, has been the subject of the rest of this book
36 An object-oriented environment Late into Beethoven’s Choral Symphony, a baritone breaks the stream of astounding but until then purely instrumental sounds to awake us to something even grander: O my friends! No more of these tunes! Let us strike up instead Some more pleasant and friendly songs. After reviewing in the preceding chapters some of the common approaches to O-O development, we should similarly end with a perhaps more modern and comprehensive approach (with no intended disparagement of the others; after all the Ninth’s first three movements, before it goes vocal, already were pretty decent stuff.) This chapter presents an environment (ISE’s) that relies on the principles developed in the rest of this book, and makes them available concretely to O-O software developers. A complete diagram of the environment appears later in this chapter; some of the principal components are included for trial purposes in the CD-ROM attached to this book. The purpose of this presentation is to put the final touch to our study of object technology by showing how environment support can make the concepts convenient to use in practice. A caveat: nothing in this discussion suggests that the environment discussed below is perfect (in fact, it is still evolving). It is only one example of a modern O-O environment; others — such as Borland’s Delphi to name just one — have met wide and deserved success. But we need to explore one environment in some depth to understand the connection between the method’s principles and their day-to-day application by a developer sitting at a terminal. Many of the concepts will, I hope, be useful to readers using other tools. 36.1 COMPONENTS The environment combines the following elements: • An underlying method: the object-oriented method, as described in this book. • A language, the notation presented in this book, for analysis, design and implementation. • A set of tools for exploiting the method and the language: compiling, browsing, documenting, designing. • Libraries of reusable software components. The next sections sketch these various elements, except for the first which, of course, has been the subject of the rest of this book. The diagram is on page 1149
1144 AN OBJECT-ORIENTED ENVIRONMENT $36.2 36.2 THE LANGUAGE The language is the notation that we have devised in part C and applied throughout the book.We have essentially seen all of it;the only exceptions are a few technical details such as how to represent special characters. Evolution The first implementation of the language dates back to late 1986.Only one significant revision has occurred since then(in 1990);it did not change any fundamental concepts but simplified the expression of some of them.Since then there has been a continuous attempt at clarification,simplification and cleanup,affecting only details,and bringing two recent extensions:the concurrency mechanism of chapter 30(concretely,the addition of a single keyword,separate)and the Precursor construct to facilitate redefinition.The stability of the language,a rare phenomenon in this field,has been a major benefit to users. Openness Although a full-fledged programming language,the notation is also designed to serve as a wrapping mechanism for components that may be written in other languages.The mechanism for including external elements-the external clause-was described in an earlier chapter.It is also possible,through the Cecil library,for external software to use the O-O mechanisms:create instances of classes,and call features on these objects, through dynamic binding(but of course with only limited static type checking). Of particular interest are the C and C++interfaces.For C++,a tool called Legacy++ is available to produce,out of an existing C++class,a "wrapper"class that will automatically include the encapsulation of all the exported features of the original.This is particularly useful to developers whose organizations may have used C++as their first stop on the road to object orientation in the late eighties or early nineties,and now want to move on to a more complete and systematic form of the technology-without sacrificing their investment.Legacy++smoothes the transition. 36.3 THE COMPILATION TECHNOLOGY The first task of the environment is,of course,to let us execute our software. Compilation challenges Developed over many years and bootstrapped through several iterations,the compilation technology is an answer to a set of challenges: C1.The efficiency of the generated code must be excellent,comparable to what developers could obtain by using a classical language suchas C.There is no reason to pay a significant performance price for O-O techniques. C2.The recompilation time after a change must be short.More precisely,it should be proportional to the size of the change,not to the size of the entire system.The crucial compilation concern,for developers working on a possibly large system,is the need to perform changes and see the results immediately
1144 AN OBJECT-ORIENTED ENVIRONMENT §36.2 36.2 THE LANGUAGE The language is the notation that we have devised in part C and applied throughout the book. We have essentially seen all of it; the only exceptions are a few technical details such as how to represent special characters. Evolution The first implementation of the language dates back to late 1986. Only one significant revision has occurred since then (in 1990); it did not change any fundamental concepts but simplified the expression of some of them. Since then there has been a continuous attempt at clarification, simplification and cleanup, affecting only details, and bringing two recent extensions: the concurrency mechanism of chapter 30 (concretely, the addition of a single keyword, separate) and the Precursor construct to facilitate redefinition. The stability of the language, a rare phenomenon in this field, has been a major benefit to users. Openness Although a full-fledged programming language, the notation is also designed to serve as a wrapping mechanism for components that may be written in other languages. The mechanism for including external elements — the external clause — was described in an earlier chapter. It is also possible, through the Cecil library, for external software to use the O-O mechanisms: create instances of classes, and call features on these objects, through dynamic binding (but of course with only limited static type checking). Of particular interest are the C and C++ interfaces. For C++, a tool called Legacy++ is available to produce, out of an existing C++ class, a “wrapper” class that will automatically include the encapsulation of all the exported features of the original. This is particularly useful to developers whose organizations may have used C++ as their first stop on the road to object orientation in the late eighties or early nineties, and now want to move on to a more complete and systematic form of the technology — without sacrificing their investment. Legacy++ smoothes the transition. 36.3 THE COMPILATION TECHNOLOGY The first task of the environment is, of course, to let us execute our software. Compilation challenges Developed over many years and bootstrapped through several iterations, the compilation technology is an answer to a set of challenges: C1 • The efficiency of the generated code must be excellent, comparable to what developers could obtain by using a classical language such as C. There is no reason to pay a significant performance price for O-O techniques. C2 • The recompilation time after a change must be short. More precisely, it should be proportional to the size of the change, not to the size of the entire system. The crucial compilation concern, for developers working on a possibly large system, is the need to perform changes and see the results immediately
$36.3 THE COMPILATION TECHNOLOGY 1145 C3.A third requirement,which appeared more recently,is quickly becoming important:the need to support the fast delivery of applications through the Internet to users or potential users,for immediate execution. The first two requirements,in particular,are hard to reconcile.CI is usually addressed through extensive compiler optimizations that make the recompilation and linking process prohibitively long.C2 is well served by interpretive environments,which execute software on-the-fly with little or no processing,but to obtain this result they must sacrifice execution-time performance(C1)and static type checking. The Melting Ice Technology The compilation technology that deals with the preceding issues,known as the Melting Ice Technology,uses a mix of complementary techniques.Once you have compiled a system, it is said to be frozen,like a block of ice stored in the freezer.As you take out the system to start working on it (so the metaphor goes),you produce some heat;the melted elements represent the changes.Those elements will not cause a compile-link cycle,which would defeat the goal of fast recompilation(C2);the melted code is,instead,directly executable by the environment's execution engine. YOUR SYSTEM THE ENVIRONMENT The Frozen and the Melted FREEZING Machine code FROZEN (from C code) Execution, browsing, symbolic debugging. BENCH documentation... MELTING “Bytecode” MELTED The tricky part(for the compiler implementers)is of course to make sure that the various components can work together,in particular that frozen code can call melted elements-even though it was not known,at freezing time,that they would later be melted!But the result is definitely worthwhile: Recompilation is fast.The waiting time is typically a few seconds. This is still a compilation approach:any recompilation will perform full type checking(without undue penalty on recompilation time because the checking,like the recompilation in general,is incremental:only the changed parts are rechecked)
§36.3 THE COMPILATION TECHNOLOGY 1145 C3 • A third requirement, which appeared more recently, is quickly becoming important: the need to support the fast delivery of applications through the Internet to users or potential users, for immediate execution. The first two requirements, in particular, are hard to reconcile. C1 is usually addressed through extensive compiler optimizations that make the recompilation and linking process prohibitively long. C2 is well served by interpretive environments, which execute software on-the-fly with little or no processing, but to obtain this result they must sacrifice execution-time performance (C1) and static type checking. The Melting Ice Technology The compilation technology that deals with the preceding issues, known as the Melting Ice Technology, uses a mix of complementary techniques. Once you have compiled a system, it is said to be frozen, like a block of ice stored in the freezer. As you take out the system to start working on it (so the metaphor goes), you produce some heat; the melted elements represent the changes. Those elements will not cause a compile-link cycle, which would defeat the goal of fast recompilation (C2); the melted code is, instead, directly executable by the environment’s execution engine. The tricky part (for the compiler implementers) is of course to make sure that the various components can work together, in particular that frozen code can call melted elements — even though it was not known, at freezing time, that they would later be melted! But the result is definitely worthwhile: • Recompilation is fast. The waiting time is typically a few seconds. • This is still a compilation approach: any recompilation will perform full type checking (without undue penalty on recompilation time because the checking, like the recompilation in general, is incremental: only the changed parts are rechecked). The Frozen and the Melted YOUR SYSTEM Execution, browsing, symbolic debugging, documentation… MELTING FREEZING Machine code (from C code) FROZEN MELTED BENCH “Bytecode” THE ENVIRONMENT
1146 AN OBJECT-ORIENTED ENVIRONMENT $36.3 Run-time performance remains acceptable because for a non-trivial system a typical modification will only affect a small percentage of the code;everything else will be executed in its compiled form.(For maximum efficiency,you will use the finalization form of compilation,as explained below.) As you perform more and more changes,the proportion of melted code will grow; after a while the effect on performance,time and space,may become perceptible.So it is wise to re-freeze every few days.Because freezing implies a C-compilation and linking, the time it takes is typically more on the order of minutes(or even an hour after several days of extensive changes).You can start this task in the background,or at night. Dependency analysis As should be the case in any modern development environment,the recompilation process is automatic;you will simply click on the Melt button of the Project Tool,in the interface described below,and the compiling mechanisms will silently determine the smallest set of elements that need to be recompiled;there is no need for "Make files"and the notation has no notion of“include file”. To compute what needs to be recompiled,the environment's tools first find out what you have changed,either from within the environment,using its own class editor,or through outside tools such as text editors (each class text being stored in a file,the time stamps provide the basic information).Then they use the two dependency relations,client and inheritance,to determine what else may have been affected and needs recompilation. In the client case,information hiding is an important help to minimize propagation:if a change to a class only affects secret features,its clients do not need recompilation To reduce melting time further,the grain of recompilation is not the class but the individual routine. Note that if you add an external element,for example a C function,a freeze will be required.Again this will be determined automatically. Precompilation In accordance with the method's emphasis on reusability,it is essential to allow software developers to put together carefully crafted sets of components-libraries-,compile them once and for all,and distribute them to other developers who will simply include them in their systems without having to know anything about their internal organization. The precompilation mechanism achieves this goal.A special compilation option On Ace files see generates a compiled form of a set of classes;then it is possible (through the Ace file)to “Assembling a sys- include a precompiled library in a new system. tem",page 198. There is no limit to the number of precompiled libraries that you may include in a new system.The mechanism that combines precompiled libraries supports sharing:if two precompiled libraries B and C both rely on a third one A (as with the Vision graphical library and the Net client-server library,discussed later,which both rely on the Base libraries for data structures and fundamental algorithms),only one copy of A will be included provided both B and C use the same version of A
1146 AN OBJECT-ORIENTED ENVIRONMENT §36.3 • Run-time performance remains acceptable because for a non-trivial system a typical modification will only affect a small percentage of the code; everything else will be executed in its compiled form. (For maximum efficiency, you will use the finalization form of compilation, as explained below.) As you perform more and more changes, the proportion of melted code will grow; after a while the effect on performance, time and space, may become perceptible. So it is wise to re-freeze every few days. Because freezing implies a C-compilation and linking, the time it takes is typically more on the order of minutes (or even an hour after several days of extensive changes). You can start this task in the background, or at night. Dependency analysis As should be the case in any modern development environment, the recompilation process is automatic; you will simply click on the Melt button of the Project Tool, in the interface described below, and the compiling mechanisms will silently determine the smallest set of elements that need to be recompiled; there is no need for “Make files” and the notation has no notion of “include file”. To compute what needs to be recompiled, the environment’s tools first find out what you have changed, either from within the environment, using its own class editor, or through outside tools such as text editors (each class text being stored in a file, the time stamps provide the basic information). Then they use the two dependency relations, client and inheritance, to determine what else may have been affected and needs recompilation. In the client case, information hiding is an important help to minimize propagation: if a change to a class only affects secret features, its clients do not need recompilation. To reduce melting time further, the grain of recompilation is not the class but the individual routine. Note that if you add an external element, for example a C function, a freeze will be required. Again this will be determined automatically. Precompilation In accordance with the method’s emphasis on reusability, it is essential to allow software developers to put together carefully crafted sets of components — libraries —, compile them once and for all, and distribute them to other developers who will simply include them in their systems without having to know anything about their internal organization. The precompilation mechanism achieves this goal. A special compilation option generates a compiled form of a set of classes; then it is possible (through the Ace file) to include a precompiled library in a new system. There is no limit to the number of precompiled libraries that you may include in a new system. The mechanism that combines precompiled libraries supports sharing: if two precompiled libraries B and C both rely on a third one A (as with the Vision graphical library and the Net client-server library, discussed later, which both rely on the Base libraries for data structures and fundamental algorithms), only one copy of A will be included provided both B and C use the same version of A. On Ace files see “Assembling a system”, page 198
$36.3 THE COMPILATION TECHNOLOGY 1147 “Formats for reus-. The author of a precompiled library may want to prevent his customers from having able component dis- access to the source code of the library (an early chapter discussed the pros and cons of tribution",page 79. this policy).It is indeed possible,when precompiling,to make the source code inaccessible.In that case users of the environment will be able,through the visual tools described later in this chapter,to browse the short form and the flat-short form of the library's classes,that is to say their interface (public)properties;but they will not be able to see their full text,let alone their flat form. Remote execution At the time ofwriting The interpretive code generated by melting-conventionally known as bytecode and the plug-in mecha- identified as such on the preceding figure-is platform-independent.To execute nism has not yet been released. bytecode,it suffices to have a copy of the environment's Execution Engine,known as 3E and freely downloadable through the Internet. By adding 3E as a plug-in to a Web browser,it will be possible to make code directly executable:if a browser's user clicks on a hyperlink corresponding to bytecode,3E will automatically execute the corresponding code.This is the remote execution mechanism first popularized by Java. 3E actually comes in two flavors,distinguished by the accompanying precompiled libraries.The first,secure,is meant for Internet usage;to avoid security risks it only allows input and output to the terminal.The second,meant for Intranet(corporate network) usage,supports general I/O and other precompiled libraries. An effort is also in progress to translate the bytecode into Java bytecode,to offer the supplementary possibility of executing the result of a development using a Java virtual machine. Optimization To generate the best possible code-goal CI of the earlier discussion-frozen mode is not sufficient.Some crucial optimizations require having a complete,stable system: Dead code removal removes any routines that can never be called,directly or indirectly,from the system's root creation procedure.This is particularly important if you rely on many precompiled libraries,of which your system may only need a subset;a space gain of 50%is not uncommon. "Static binding as Static binding which,as we studied in detail in the discussion of inheritance,should be an optimization”, applied by the compiler for features that are not redefined,or non-polymorphic entities. page 511 (also dis- cusses inlining). Routine inlining,also subject to compiler algorithms. When you are still changing your system,these optimizations are not applicable, since your next editing move could invalidate the compiler's work.For example by adding just one call you may resuscitate a supposedly dead routine;by adding a routine redefinition,you cause a statically bound routine to require dynamic binding.Besides, such optimizations may require a complete pass through a system,for example to determine that no class redefines a certain routine;this makes them incompatible with incremental development
§36.3 THE COMPILATION TECHNOLOGY 1147 The author of a precompiled library may want to prevent his customers from having access to the source code of the library (an early chapter discussed the pros and cons of this policy). It is indeed possible, when precompiling, to make the source code inaccessible. In that case users of the environment will be able, through the visual tools described later in this chapter, to browse the short form and the flat-short form of the library’s classes, that is to say their interface (public) properties; but they will not be able to see their full text, let alone their flat form. Remote execution The interpretive code generated by melting — conventionally known as bytecode and identified as such on the preceding figure — is platform-independent. To execute bytecode, it suffices to have a copy of the environment’s Execution Engine, known as 3E and freely downloadable through the Internet. By adding 3E as a plug-in to a Web browser, it will be possible to make code directly executable: if a browser’s user clicks on a hyperlink corresponding to bytecode, 3E will automatically execute the corresponding code. This is the remote execution mechanism first popularized by Java. 3E actually comes in two flavors, distinguished by the accompanying precompiled libraries. The first, secure, is meant for Internet usage; to avoid security risks it only allows input and output to the terminal. The second, meant for Intranet (corporate network) usage, supports general I/O and other precompiled libraries. An effort is also in progress to translate the bytecode into Java bytecode, to offer the supplementary possibility of executing the result of a development using a Java virtual machine. Optimization To generate the best possible code — goal C1 of the earlier discussion — frozen mode is not sufficient. Some crucial optimizations require having a complete, stable system: • Dead code removal removes any routines that can never be called, directly or indirectly, from the system’s root creation procedure. This is particularly important if you rely on many precompiled libraries, of which your system may only need a subset; a space gain of 50% is not uncommon. • Static binding which, as we studied in detail in the discussion of inheritance, should be applied by the compiler for features that are not redefined, or non-polymorphic entities. • Routine inlining, also subject to compiler algorithms. When you are still changing your system, these optimizations are not applicable, since your next editing move could invalidate the compiler’s work. For example by adding just one call you may resuscitate a supposedly dead routine; by adding a routine redefinition, you cause a statically bound routine to require dynamic binding. Besides, such optimizations may require a complete pass through a system, for example to determine that no class redefines a certain routine; this makes them incompatible with incremental development. “Formats for reusable component distribution”, page 79. At the time of writing the plug-in mechanism has not yet been released. “Static binding as an optimization”, page 511 (also discusses inlining)
1148 AN OBJECT-ORIENTED ENVIRONMENT $36.4 As a result,these optimizations are part of a third form of compilation,finalization, complementing the other two(melting and freezing).For a large system finalization can take a few hours;but it leaves no stone unturned in removing anything that will not be needed and speeding up everything that is not optimal.The result is the most efficient executable form of the system. The obvious opportunity for finalization is the delivery of a system,for a final or intermediate release.But many project leaders like to finalize once a week,at the time of the latest integration. 36.4T00LS The figure on the facing page shows the general organization of the environment.The environment is of course used to bootstrap itself,and is written in the O-O notation(except for some elements of the runtime system,discussed next);this makes it an excellent testbed of the technology,and a living proof that it does scale up to large,ambitious systems (which,of course,we would not want to develop in any other way!). Bench and the development process The centerpiece is Bench,the graphical workbench for compilation,browsing (exploring classes and features),documentation,execution,debugging.When developing a system you will constantly interact with Bench.For example you can melt the latest version by clicking on the Melt button of the Bench's Project Tool,shown below. As long as you are melting and freezing you can stay within Bench.When you finalize a system-also by clicking on a button,although for this operation and many others non-graphical commands are also available-the outcome will be a C program, which the environment will compile to machine code for your platform by calling the appropriate C compiler.Freezing too relies on C as intermediate code.The use of C has several benefits:C is available on just about every platform;the language is sufficiently low level to provide a good target format for a compiler;C compilers perform their own extensive optimizations.Two further advantages deserve emphasis: Thanks to C generation you can use the environment as a cross-development platform,by compiling the generated C on another platform.This is particularly useful for the production of embedded systems development,which typically uses a different platform for development and for final execution. The use of C as compilation technology helps implement the openness mechanisms discussed earlier,in particular the interfaces to and from existing software written in C and C++. Finalized C code,once compiled,must be linked;at this stage it uses the runtime system,a set of routines providing the interface with the operating system:file access, signal handling,basic memory allocation. In the case of cross development of embedded systems,it is possible to provide a minimum form of the runtime,which,for example,does not include any 1/O
1148 AN OBJECT-ORIENTED ENVIRONMENT §36.4 As a result, these optimizations are part of a third form of compilation, finalization, complementing the other two (melting and freezing). For a large system finalization can take a few hours; but it leaves no stone unturned in removing anything that will not be needed and speeding up everything that is not optimal. The result is the most efficient executable form of the system. The obvious opportunity for finalization is the delivery of a system, for a final or intermediate release. But many project leaders like to finalize once a week, at the time of the latest integration. 36.4 TOOLS The figure on the facing page shows the general organization of the environment. The environment is of course used to bootstrap itself, and is written in the O-O notation (except for some elements of the runtime system, discussed next); this makes it an excellent testbed of the technology, and a living proof that it does scale up to large, ambitious systems (which, of course, we would not want to develop in any other way!). Bench and the development process The centerpiece is Bench, the graphical workbench for compilation, browsing (exploring classes and features), documentation, execution, debugging. When developing a system you will constantly interact with Bench. For example you can melt the latest version by clicking on the Melt button of the Bench’s Project Tool, shown below. As long as you are melting and freezing you can stay within Bench. When you finalize a system — also by clicking on a button, although for this operation and many others non-graphical commands are also available — the outcome will be a C program, which the environment will compile to machine code for your platform by calling the appropriate C compiler. Freezing too relies on C as intermediate code. The use of C has several benefits: C is available on just about every platform; the language is sufficiently low level to provide a good target format for a compiler; C compilers perform their own extensive optimizations. Two further advantages deserve emphasis: • Thanks to C generation you can use the environment as a cross-development platform, by compiling the generated C on another platform. This is particularly useful for the production of embedded systems development, which typically uses a different platform for development and for final execution. • The use of C as compilation technology helps implement the openness mechanisms discussed earlier, in particular the interfaces to and from existing software written in C and C++. Finalized C code, once compiled, must be linked; at this stage it uses the runtime system, a set of routines providing the interface with the operating system: file access, signal handling, basic memory allocation. In the case of cross development of embedded systems, it is possible to provide a minimum form of the runtime, which, for example, does not include any I/O
§36.4T00LS 1149 Case Build Analysis,design and Graphicalapplication builder reverse engineering Developer-defined Classes Base (incl.Kernel) General libraries EXTERNAL CODE (C,C++,...) Vision,WEL,MEL... GUI libraries Existing software, Net libraries, utility packages, Client-server library,object exchange low-level access routines... Lex,Parse also Cecil library (calls to O-O Lexical and parsing libraries facilities from C and other languages) Math Numerical and statistical library FAST RECOMPILATION (MELTING ICE), ObjEdit EXECUTION, Run-time object editing Bench BRO WSING, AUTOMATIC Web DOCUMENTATION. Web form processing library DEBUGGING Shelf Finalization (OPTIMIZED COMPILATION) User-contributed reusable components PORTABLE PORTABLE. ANSI-C CODE INTERNET- DOWNLOADABLE C Compilation BYTECODE Runtime system Linking Downloadable Execution Engine Executable System STORABLE Store Persistent Databases Objects (Relational, 0-0) APPLICATION RESULTS
§36.4 TOOLS 1149 APPLICATION RESULTS Numerical and statistical library EXTERNAL CODE (C, C++, …) Base (incl. Kernel) Vision, WEL, MEL… Net Lex, Parse Math Web GUI libraries Client-server library, object exchange Lexical and parsing libraries Web form processing library Run-time object editing ObjEdit Build Build STORABLE Store Bench C Compilation Linking Runtime system PORTABLE ANSI-C CODE Developer-defined Classes Persistent Objects Databases Executable System Graphical application builder Existing software, libraries, utility packages, low-level access routines… also Cecil library (calls to O-O facilities from C and other languages) Shelf User-contributed reusable components Case reverse engineering Analysis, design and FAST RECOMPILATION (MELTING ICE), EXECUTION, BROWSING, AUTOMATIC DOCUMENTATION, DEBUGGING PORTABLE, BYTECODE INTERNETDOWNLOADABLE Finali zation Downloadable Execution Engine (Relational, O-O) (OPTIMIZED COMPILATION) General libraries
1150 AN OBJECT-ORIENTED ENVIRONMENT $36.5 High-level tools At the top of the figure on the preceding page,two high-level generation tools appear. Build is an interactive application generator based on the Context-Event-Command-Chapter 32. State model developed in an earlier chapter.You can use it to develop GUI(Graphical User Interface)applications graphically and interactively. Case is an analysis and design workbench which provides the ability to reason on Chapter 28. systems at a high level of abstraction,and through graphical representations.In accordance with the principles of seamlessness and reversibility introduced in the discussion of the software process,Case allows you both to: Devise system structures through graphical interaction -to produce visual representations of classes ("bubbles"),specify their relations through client and inheritance arrows,and group them into clusters-,relying on Case to generate the corresponding software texts in the end(forward engineering) Process existing class texts to produce the corresponding graphical representations, to facilitate exploring and restructuring(reverse engineering). Particular attention has been devoted to making sure that developers can freely alternate between forward and reverse engineering.In particular,you can make changes on either the graphical or the textual form;Case provides a reconciliation mechanism which will merge the two sets of changes and,in case of conflicts,take you through a step- by-step decision process in which you will see the conflicting versions of a feature and choose,in each case,the version to be retained.This part of the tool is key to ensuring true reversibility,letting developers decide at each stage the level of abstraction and the notation,graphical or textual,that they find most appropriate. The conventions of Case are drawn from the Business Object Notation described in “THE BUSINESS an earlier chapter.BON supports in particular the tools'facilities for abstraction and ORJECT NOTA- zooming:it is essential,for large systems,to enable developers to work on an entire system, TION",27.7,page 919. on a subsystem,on just a small cluster,choosing the exact level of abstraction they desire. An example Case screen appears at the top of the facing page,showing a cluster from a chemical plant description,the properties ofone of its classes(),and the properties of one of the features of that class (fill) 36.5 LIBRARIES A number of libraries appear on the general environment diagram of the preceding page. They play a considerable role in the software development process,providing developers with a rich set(several thousand classes)of reusable components.They include: The Base libraries,about 200 classes covering the fundamental data structures(lists, tables,trees,stacks,queues,files and so on).The most fundamental classes make up the Kernel library,governed by an international standard(ELKS) The graphical libraries:Vision for platform-independent GUI development;WEL for Windows,MEL for Motif,PEL for OS/2-Presentation Manager
1150 AN OBJECT-ORIENTED ENVIRONMENT §36.5 High-level tools At the top of the figure on the preceding page, two high-level generation tools appear. Build is an interactive application generator based on the Context-Event-CommandState model developed in an earlier chapter. You can use it to develop GUI (Graphical User Interface) applications graphically and interactively. Case is an analysis and design workbench which provides the ability to reason on systems at a high level of abstraction, and through graphical representations. In accordance with the principles of seamlessness and reversibility introduced in the discussion of the software process, Case allows you both to: • Devise system structures through graphical interaction — to produce visual representations of classes (“bubbles”), specify their relations through client and inheritance arrows, and group them into clusters —, relying on Case to generate the corresponding software texts in the end (forward engineering). • Process existing class texts to produce the corresponding graphical representations, to facilitate exploring and restructuring (reverse engineering). Particular attention has been devoted to making sure that developers can freely alternate between forward and reverse engineering. In particular, you can make changes on either the graphical or the textual form; Case provides a reconciliation mechanism which will merge the two sets of changes and, in case of conflicts, take you through a stepby-step decision process in which you will see the conflicting versions of a feature and choose, in each case, the version to be retained. This part of the tool is key to ensuring true reversibility, letting developers decide at each stage the level of abstraction and the notation, graphical or textual, that they find most appropriate. The conventions of Case are drawn from the Business Object Notation described in an earlier chapter. BON supports in particular the tools’ facilities for abstraction and zooming: it is essential, for large systems, to enable developers to work on an entire system, on a subsystem, on just a small cluster, choosing the exact level of abstraction they desire. An example Case screen appears at the top of the facing page, showing a cluster from a chemical plant description, the properties of one of its classes (VAT), and the properties of one of the features of that class (fill). 36.5 LIBRARIES A number of libraries appear on the general environment diagram of the preceding page. They play a considerable role in the software development process, providing developers with a rich set (several thousand classes) of reusable components. They include: • The Base libraries, about 200 classes covering the fundamental data structures (lists, tables, trees, stacks, queues, files and so on). The most fundamental classes make up the Kernel library, governed by an international standard (ELKS). • The graphical libraries: Vision for platform-independent GUI development; WEL for Windows, MEL for Motif, PEL for OS/2-Presentation Manager. Chapter 32. Chapter 28. “THE BUSINESS OBJECT NOTATION”, 27.7, page 919
$36.5 LIBRARIES 1151 SYSTEM A cluster,class 巴可☑图☒图酚 SYSTEM 氢网团 and feature 0可可可 -可 under Case CHEMICAL PLANT CLISTER (Here on a Sparc- station with Motif. TANK PIPE but versions exist for Windows and other look-and-feel 1 ariants.） : PLANT ◆CONTROL ROOM VAT 、VALVE 寸☒团勾目 Class:VAT Cluster:CHEMICAL_PLANT_CLUSTER Feature:fill Class:VAT 可田圆 VAT 中可嗣 仙 from VAT Annotation 四 创 --Fill the vat. ■Reused Z require a:in-valveis open ■Persistent 四 b:out-valve.closed deferred ■Deferred ■Comments ensure a:in-valve.closed 口Effective ▣Result b:out-valve.closed c:is-full ▣Root ☐Rename ▣Interfaced Deferred 图VAT 口Etective ☐Redefined Flename:vate ☐Private ☑圆熟好刀 同A "Storable format Net,for client-server development,allowing the transferral of arbitrarily complex ariants”,page object structures over a network;the platforms may be the same or different(under 1038. independent store the format is platform-independent). Lex,Parse for language analysis.Parse,in particular,provides an interesting approach to parsing,based on a systematic application of object-oriented concepts to parsing (each production modeled by a class;see the bibliographical notes).A supporting public-domain tool,YOOCC,serves as front-end for Parse. "Object-oriented Math is a numerical library providing an object-oriented view of the fundamental re-architecturing”. techniques of numerical computation.It is based internally on the NAG library and page 441. covers a large set of facilities.Some of its concepts were presented in an earlier chapter as an example of O-O re-architecturing of non-O-O mechanisms
§36.5 LIBRARIES 1151 • Net, for client-server development, allowing the transferral of arbitrarily complex object structures over a network; the platforms may be the same or different (under independent_store the format is platform-independent). • Lex, Parse for language analysis. Parse, in particular, provides an interesting approach to parsing, based on a systematic application of object-oriented concepts to parsing (each production modeled by a class; see the bibliographical notes). A supporting public-domain tool, YOOCC, serves as front-end for Parse. • Math is a numerical library providing an object-oriented view of the fundamental techniques of numerical computation. It is based internally on the NAG library and covers a large set of facilities. Some of its concepts were presented in an earlier chapter as an example of O-O re-architecturing of non-O-O mechanisms. “Storable format variants”, page 1038. A cluster, class and feature under Case (Here on a Sparcstation with Motif, but versions exist for Windows and other look-and-feel variants.) “Object-oriented re-architecturing”, page 441
1152 AN OBJECT-ORIENTED ENVIRONMENT $36.6 ObjEdit provides facilities for editing objects interactively during execution. Web supports the processing of forms submitted by visitors to a Web site, advantageously replacing the Perl or C"CGI scripts"sometimes used for this purpose. The bottom part of the environment diagram shows libraries used for taking care of persistence needs during execution:the STORABLE class and a few complementary tools. discussed in earlier chapters,support storage,retrieval and network transmission of object structures,self-contained through the application of the Persistence Closure principle;and the Store library is the database interface,providing mechanisms for accessing and storing data in relational databases(such as Oracle,Ingres,Sybase)and object-oriented databases. This list is notexhaustive;other components are under development,and users of the environment have provided their own libraries,either free or commercial. A particularly interesting combination is the use of Net,Vision and Store for building client-server systems:a server can take care of the database aspects through Store,and of the heaviest part the computation (possibly using Base,Math etc.);lean clients that only handle the user interface part can rely on Vision (or just one of the platform-specific libraries),and include little else. 36.6 INTERFACE MECHANISMS To support the preceding concepts,the environment provides a visual interface,based on an analysis of the needs of developers and of the requirements of various platforms. This brief presentation will only mention some of the most original aspects of the environment.Ample literature (see the bibliographic notes)is available on its other facilities;the reader familiar with other modern development environments will have no difficulty guessing some of the tools and possibilities not described here. Platforms The screenshots that follow were drawn from a session on a Sun Sparcstation,for no other reason than convenience.Other platforms supported at the time of writing include Windows 95 and Windows NT,Windows 3.1,OS/2,Digital's VMS (Alpha and Vax)and all major brands of Unix (SunOS,Solaris,Silicon Graphics,IBM RS/6000,Unixware, Linux,Hewlett-Packard 9000 Series etc.). Although the general concepts are the same on every platform,and the environment supports source-code compatibility,the exact look-and-feel adapts to the conventions of each platform,especially for Windows which has its own distinctive culture. The following screenshot shows a set of environment windows during a session. Although printed in black and white in this book,the display makes extensive use of colors,especially to distinguish the various parts of class texts(the default conventions, user-changeable,are keywords in blue,identifiers in black,comments in red)
1152 AN OBJECT-ORIENTED ENVIRONMENT §36.6 • ObjEdit provides facilities for editing objects interactively during execution. • Web supports the processing of forms submitted by visitors to a Web site, advantageously replacing the Perl or C “CGI scripts” sometimes used for this purpose. The bottom part of the environment diagram shows libraries used for taking care of persistence needs during execution: the STORABLE class and a few complementary tools, discussed in earlier chapters, support storage, retrieval and network transmission of object structures, self-contained through the application of the Persistence Closure principle; and the Store library is the database interface, providing mechanisms for accessing and storing data in relational databases (such as Oracle, Ingres, Sybase) and object-oriented databases. This list is not exhaustive; other components are under development, and users of the environment have provided their own libraries, either free or commercial. A particularly interesting combination is the use of Net, Vision and Store for building client-server systems: a server can take care of the database aspects through Store, and of the heaviest part the computation (possibly using Base, Math etc.); lean clients that only handle the user interface part can rely on Vision (or just one of the platform-specific libraries), and include little else. 36.6 INTERFACE MECHANISMS To support the preceding concepts, the environment provides a visual interface, based on an analysis of the needs of developers and of the requirements of various platforms. This brief presentation will only mention some of the most original aspects of the environment. Ample literature (see the bibliographic notes) is available on its other facilities; the reader familiar with other modern development environments will have no difficulty guessing some of the tools and possibilities not described here. Platforms The screenshots that follow were drawn from a session on a Sun Sparcstation, for no other reason than convenience. Other platforms supported at the time of writing include Windows 95 and Windows NT, Windows 3.1, OS/2, Digital’s VMS (Alpha and Vax) and all major brands of Unix (SunOS, Solaris, Silicon Graphics, IBM RS/6000, Unixware, Linux, Hewlett-Packard 9000 Series etc.). Although the general concepts are the same on every platform, and the environment supports source-code compatibility, the exact look-and-feel adapts to the conventions of each platform, especially for Windows which has its own distinctive culture. The following screenshot shows a set of environment windows during a session. Although printed in black and white in this book, the display makes extensive use of colors, especially to distinguish the various parts of class texts (the default conventions, user-changeable, are keywords in blue, identifiers in black, comments in red)