Object Master 1.0ß4

Jeffrey J. Barbose

Because of the near-ubiquity of structured programming, most tools (and languages) have been designed to aid in structured software development. Witness MPW and the THINK products, which provide access to such traditional mainstays as source-level debugging, ordinary (linear) text editing tools, and the familiar edit-compile-run development cycle. The most popular object-oriented programming languages (C++, Object Pascal, Modula2-P1) are merely structured languages with extensions to support the enforcement of object concepts; they may thus be called "hybrid" languages.

Early object-oriented languages, such as Smalltalk, are "pure" object languages. They espouse the "everything is an object" concept-a radical departure from traditional systems. Unfettered by the need to appear similar to existing structured development tools, Smalltalk inventors created an entire development and run-time environment based on the concept of a virtual machine: "…Smalltalk is designed so that every component of the system that is accessible to the user can be presented in a meaningful way for observation and manipulation." In other words, the complexities involved in larger-scale object-oriented software development were addressed right from the beginning.

All along, MacApp programmers have been creating their classes and interactions without a "meaningful way for observation and manipulation" of MacApp's complexity. With one or two exceptions, Object Master from ACIUS provides a complete environment for object-oriented software development.

Divide et impera

The purpose of software design, analysis and construction is complexity management. Decomposition, abstraction and hierarchical organization each have roles in the design of non-trivial applications.

The goal of improving design techniques is to find the best symbolic mapping of the problem domain to the software solution domain. Development environments should also provide as close to a one-to-one mapping of programming paradigm-to-program-development as possible; namely, the class (or, more generally, the module) should represent the fundamental unit for editing source code.

Shifting paradigms

The benefits of a gestalten object development environment are not immediately obvious. In fact, traditional environments are often adequate (though not optimal) to the task of object programming.

MacBrowse and SourceBug are two notable additions to the MPW development system that are designed for object programming. The need for breadth- and depth-browsing of classes-especially classes within a well-defined framework-quickly becomes obvious when trying to familiarize yourself with MacApp.

Browsing, as a general tool, organizes hierarchical (and, to a lesser extent, reticular) systems in a straightforward, meaningful way. The browser nature of SourceBug is its advantage over SADE with respect to MacApp programming.

The editing environment of MPW and the THINK products require you to implement object-oriented constructs within the world of structured programming-manual construction and maintenance of separate interface and implementation files, #include and other compiler directive management, etc.

Described in its manual as an editing tool, Object Master is much more. It provides, through internal facilities and through AppleEvent magic, a virtual environment expressly tailored to the needs of developers of object-oriented applications-with or without MacApp. Browsing with full editing allows object-oriented development to proceed apace, and eliminates the need to fit your object-oriented code into a structured source format.

elemental overview

Object Master is a large, complex program. Large in the sense that there are many visual components; complex in the sense that it incorporates and automates nearly every activity involved in object-oriented development.

Even to review such a product requires a bit of complexity management, so I'll first describe it, component by component. Again, it helps to think of Object Master as more of an integrated environment than a Macintosh application.

_ValidateConfiguration(gConfiguration);

Object Master requires at least System 6, but to take full advantage of its features (in particular, Apple Events), System 7 is recommended. Most of this review was written while working with 1.0ß2, but 1.0ß4 arrived near the tail end of the process.

I ran Object Master on a IIci with 32mb RAM, System 7, and 32-bit addressing on. 1.0ß4 requests a 1480K partition, but may require an even larger partition if the MacApp CPlusIncludes and Libraries are to be included in a given project.

Since Object Master requires a separate, external compiler, you must also have enough RAM to run MPW/ToolServer (MPW 3.3 and ToolServer 1.0 or better are required) or a THINK system. Object Master can also control (to varying degrees) other development tools, including Jasik Designs' The Debugger/Integrated Build System, ResEdit, ViewEdit and IcePick. Decide which of these tools you'd like to have running concurrently to determine how much RAM you will require. For example, to run Object Master, MPW/ToolServer, and C++, you'll need 8mb at the very least.

Project-centered design Object Master organizes source files, classes, methods, fields, resources, and documentation-in other words, all application components-inside a project. An Object Master project is similar to a THINK Pascal or Think C project, or an MPW/ToolServer Projector database.

Unlike other source code systems, the Object Master project takes an active role. It acts like a control center for software development, orchestrating all development activities to some degree. For instance, if you're using MPW/ToolServer, you can specify an MPW Projector database and do simple CheckIns and CheckOuts, all from within Object Master, via Apple Events. Object Master respects Projector status on all files. When source files are added to a project, or existing source files have changed, Object Master parses those files and adds class, method, field, file and segment information to a project dictionary. You can use this dictionary to do project-wide searches. Object Master uses this dictionary to generate its views.

Object Master's application menu bar

Every Macintosh application makes use of the Macintosh menu bar to control application functionality. Object Master does as well, but it provides only commands that have effects outside the scope of any one project. File-, class-, method- and field-specific commands are handled from within the Object Master windows and will be described later. The menus and their items are well organized and are aptly named, resulting in straightforward, intuitive use.Briefly, Object Master's menu bar is as follows:

File	Fairly standard Macintosh file menu. The New and Open items refer to source code files, not Object Master projects.
Edit	Standard Macintosh Edit menu. Also provides menu items for code alignment and duplication.
Settings	Allows for preferences with respect to the appearance of language-specific constructs within editing views. Project preferences are also available (see Figure 1).
Project	Contains all commands for opening, closing, saving whole projects, adding source files and 411 (MPW help format) files, and source code parsing.
Build	Automated, AppleEvent- or QuicKey-orchestrated application building functions. Provides specific access to MPW/ToolServer, THINK compilers, and Jasik's IBS.
Goodies	Mainly provides access to documentation facilities. Also allows for project-wide text searching and project meta-functions for writing Make files, Fields information, and for constructing 411 documentation.
Windows	Commands for creating new instances of each of Object Master's project-related windows, and for organizing existing windows.

Bar Hopping

To call the views within Object Master "windows" doesn't quite do them justice. Each window contains its own menu bar, and acts more like a mini-application within the Object Master virtual environment. A window's menu bar behaves exactly as a standard Macintosh menu. It was surprisingly easy to get used to having additional menu bars within the windows. Object Master's main windows are described below.

Project Window

Figure 2 is a Project Window. Its primary purpose is the organization and presentation of the files (source, resource, help and other files) that are included in an Object Master project. The menu bar contains the following:

Files	Allows opening and printing any file contained in the project; specifying and selecting an MPW Projector Database; and checking files in and out of that database.
Columns	Control visibility of various file attributes, such as Unit name, Projector status, or modification date.
Sort	Sort the list by any of the file attributes, in ascending or descending order.
Color	Set any file to any color.

Browser Window

Figure 3 is a Browser Window. This is where nearly all day-to-day interaction with Object Master takes place.

Those of you familiar with the Smalltalk/V or Objectworks Smalltalk-80 environments will feel right at home within the Browser. In standard fashion, the browser is split up into four panes: Class List, Method List, Field List, and Edit view. This window is responsible for hiding most of the standard file-based housekeeping. With it you can create and modify classes, and add and remove methods and fields. Modules (units) and structs (records) are added as pseudo classes, and denoted in the Class List with a prepended "•" for modules, "••" for structs. Any functions or procedures that are outside the scope of any class become pseudo-methods of that pseudo-class.

To create a subclass of another class, select the class that is to serve as the new class' superclass. When creating new classes, you are presented with the New Class Dialog (Figure 4). Object Master will create new interface and implementation files to contain the nascent class. The Location buttons are used to specify where the new files will be saved.

It would be convenient here to be able to specify an existing file, since it is often preferable to have a number of classes all within one file. As Booch suggests, the module (unit)-not the class-is the fundamental construct in an object-oriented system. In this way, any number of functionally interdependent classes can be gathered, and so visibility can be determined and restricted as a group.

It is possible, at this point, to specify (by double-clicking) any existing method as being one that will be overridden in this new derived class. Conveniently, this list contains not only the methods of the immediately ancestral class, but the methods of all the classes from which it is inheriting.

The only significant instance where Object Master fails to present a complete object environment is in the creation of the interface and implementation files. There is currently no means of specifying #include files, other than by opening the files and manually adding the necessary compiler directives to both files. It would be nice if the New Class Dialog could be enhanced to allow specification (via popup menu or modified Standard File Dialog) of those header files that are necessary to the interface and implementation of the nascent class.

When creating new methods within a given class, you are presented with the New Method Dialog (Figure 5). For those languages that allow restriction of method and field visibility, desired restriction can be set. For languages that don't, Object Master will add comments stating the intended visibility of this method.

The compilation segment is also specified at this point, either by typing in a new or existing segment name, or by using the popup menu and selecting an existing segment. If you are overriding an existing method, the ancestral method is selected (by double-clicking) from the list of existing methods.

The browser window similarly allows for addition and deletion of fields. I was unable to do this with ß2, but have not yet tried the operation with ß4. I expect that the procedure for adding a field to a class will be similar to that for creating a new method.

See Figure 6 for an example of the .h and .cp files generated by Object Master for a simple class with no fields and no overrides. For C++, note that an empty constructor is created. For Object Pascal, an empty PROCEDURE <MyClass>.I<MyClass> would have been generated.

From this point on, all method and field manipulation can be done from within the Browser. Object Master maintains both interface and implementation files automatically. Again, the only manual intervention required involves changing header dependencies (for example, a newly created method might require additional header files, which must then be added manually to the implementation file).

Object Master can also create indexed MPW 411 files for documentation purposes. You can write the documentation for a particular class or method concomitantly with implementation.

The menus for this Window are more or less intuitive:

Filing	Creation and deletion of classes, methods and fields.
Classes	Class manipulation. Conveniently, you can view the class from a variety of perspectives (as Client, as Friend, as Implementor, or from Open Method), allowing you to double check that visibility restrictions are set up as needed.
Color	Identical to the Color menu in the Project Window.
Methods	Method manipulation. Documentation can be viewed for the method currently being edited. Also, a disassembly listing of 680x0 code generated by any method can be viewed. Note that Object Master does not generate any code, but rather utilizes existing .o and .SYM files to produce Code Window output (Figure 7).
Fields	Basic field manipulation.
Text	Allows for text level manipulations, based on the method currently being edited.
Find	Basic search commands, with respect to the method currently being edited.
Macros	Text for fundamental language-sensitive constructs and data types can be generated by typing or selecting any of these menu items, then executing "Expand Macro" from this menu.

Class Tree

Figure 8 is a Class Tree Window. Object Master automatically generates an inheritance tree based from the source files of the project. In short, it is a graphical analog to the Browser; another way of visualizing the class inheritance relationships. No editing can be done directly in this view, but a Browser can be automatically opened, based on the class ± method/field selected. Class names can be typed into the cell in the upper right of this window to navigate the tree by class name. Additionally, the currently selected class appears in this cell. Menu organization is straightforward and intuitive, but is described briefly below:

Classes	Selects information be displayed in the tree.
Tree	Controls appearance of tree with respect to node placement, fanout and text styles. Also allows tree to be exported as a PICT file.
Color	Identical to Color menu of Project Window.

Segment Map

Figure 9 is a Segment Map. It provides a view of all the segments involved in the project by scanning the sources for segmentation compiler directives (such as "#pragma segment," for example). Object Master does not use the final 'CODE' resources to determine segmentation. The Segment Map is largely a convenience view, and comes into play when optimizing segmentation schemes. The menus of this view provide sorting options, by both Segment and Method attributes. Methods can be opened from within this window.

File Map

Figure 10 is a File Map. It is functionally analogous to the Segmentation Map, but instead shows file locations of project methods.

Resource Map

Figure 11 is a Resource Map. It contains three panes: The ResType Pane, the Resource Pane, and the View Pane. The Resource Map provides improved access to tools that edit other-type resources. It can invoke any other resource editor, based on the ResType of the currently selected resource. For example, you can specify that all resources of type 'view' and 'View' are to be opened by IcePick. Then, when a specific 'view' resource is selected and displayed, Object Master will invoke IcePick to edit that 'view'. Here are the menus for the Resource Map:

ResTypes	Controls appearance of the ResType Pane and allows you to set resource editors to be invoked (according to ResType).
Resources	Controls appearance of the Resources Pane. Also, provides means of displaying resources and invoking external editors.

Reference List Window

Figure 12 is a Reference List Window. When a search results in more than one match, all matches are displayed in this window. Double-clicking on any item opens a browser or file window.

File Window

A file window is much like an MPW or THINK editing window (Figure 6), except that, like other Object Master windows, it also contains a menu bar:

Text
Find
Macros	Identical to their Browser Window counterparts.
Markers	Object Master automatically generates MPW-compatible markers for all methods within an implementation file. Files can be navigated by selecting one of these automatic markers, much like in MPW. Additional manual markers can be generated or removed. Additionally, the cell located left of this window's horizontal scroll bar pops up to display all current markers.

Worksheet

Figure 13 is the Worksheet. This window is used exactly like the MPW worksheet, and can be used to remotely control MPW or especially ToolServer. The menus are identical to File Window menus. Below this window's menu bar is a horizontal button list. Any MPW script (or alias thereof) can be dropped into the Buttons folder (which needs to be in the same folder as the original Object Master application). By clicking a button, that script is sent to MPW/ToolServer for execution.

Functional overview

In learning MacApp, you must not only learn what each class does, but also how it interacts with other classes. This is also true in learning to use the Object Master environment. Except for the occasional trip to the File Window to maintain the required interface files or to interact with the MPW Projector in a complex way, you can conduct all application development from within the virtual environment created by Object Master. I call it a virtual environment because not all the functionality of Object Master comes directly from Object Master. It relies on other external tools, such as resource editors, compilers, linkers and debuggers, to flesh out the development environment.

Object Master as editor

The reference manual for Object Master calls it an editor. This is an understatement. All the facilities described above contribute to a cohesive, consistent environment for editing an object-oriented project, but this is only one part of the development cycle.

Object Master excels at making navigation of a large object system as swift and easy as possible. Object Master creates the illusion of a native object system (such as Smalltalk) by handling most aspects of source file maintenance behind the scenes. This means you can proceed with implementing classes in a convenient, organized fashion.

Object Master as Apple Events switchboard

Object Master invokes external tools necessary to complete the development cycle via AppleEvents. Certain tools, namely MPW/ToolServer and ResEdit, are AppleEvents-aware, and so fit nicely into the Object Master environment scheme. Since Jasik's Debugger and Incremental Build System (IBS) is integrated into the MPW environment, the IBS facility is also available from within Object Master. Object Master includes UserStartup•≈ and UserStartupTS•≈ scripts for setting up MPW to respond to specific Object Master-generated AppleEvents.

To take advantage of AppleEvents, you must be running System 7 or later. However, Object Master does provide a QuicKeys hook for invoking MPW on pre-System 7 Macintoshes, or for invoking one of the THINK environments (which are not yet AppleEvent-aware). Once the build services have been set up in the Preferences Dialog (Figure 1), building can be initiated from within Object Master. The following steps illustrate the Object Master's orchestration of the build process via MPW/ToolServer and AppleEvents:

• Object Master can instruct MPW to build the project according to a script in an Object Master-generated file named "CompileProject", which is placed in the project folder. This script defaults to a standard "MABuild" command and can be edited by the user. For example, the script could be extended to launch SourceBug (with the target application as an argument) from MPW to debug the application (though there are minor problems with SourceBug 1.0ß4 with respect to opening application files from within MPW).
• Standard output is redirected to "CompileProject.out" in the project folder.
• Standard error is redirected to "CompileProject.err" in the project folder. If the build failed during compilation, Object Master regains control, parses this file, and displays an Error Window (Figure 14). Double-clicking on the error brings up the offending code in a file or browser window; default behavior can be set in the Preferences Dialog (Figure 1).
• If the build was successful, the application can be run within a debugger.
• Similarly, Object Master could invoke Jasik's IBS, providing incremental builds and faster development cycles.
• ResEdit is also AppleEvents-aware, and can be invoked in a similar fashion from within the Resource Map.

Source file and project strategies for MacApp

Source files are added to the project from the Project menu (in the Application menu bar). A modified version of the Standard File Dialog is presented to select single or multiple files. After dismissing this dialog with "Done," the added files are immediately parsed, and their information is added to the project dictionary.

To take full advantage of Object Master as a complete MacApp development environment:

• Add user-developed source code to the project.
• Add all MacApp interfaces and source code to the project.
• Add all 411 files to the project.

It may seem like overkill to include MacApp as part of the project (including MacApp 3.0ß2 adds 154 files, over 400 classes and pseudo-classes, and over 600 methods and fields). There are disadvantages to doing this:

• A full re-parse of the project can take several minutes to complete.
• Opening and saving the project takes considerably longer to complete.
• If the -AutoBuild option is included in the MABuild command line, every build will take longer (since Make will have to scan all MacApp files).

Project Window clutter might also be a factor, but Object Master provides a means of displaying only those files contained in the project folder (i.e., user-developed files).

In spite of the negative aspects, I highly recommend including MacApp in your Object Master projects. The advantages:

• The entire inheritance hierarchy is just a mouse-click away within the Browser and Class Tree windows.
• Discerning when and where to override methods and where to call back inherited methods is one of the biggest problems facing a MacApp programmer. With all MacApp sources included, inherited methods can be inspected easily in a meaningful context.
• Using the Class Access facility within the browser, you can avoid visibility violations.
• The Class Tree Window, which would contain all MacApp classes, can be printed and used as a wall chart reference.
• With 411 files included, sorely-needed MacApp documentation is available immediately within the context of a class or a method.
• MacApp method call interfaces can be easily obtained and quickly pasted at the insertion point of the method currently being edited.

inheritance and precedents

In general, Object Master borrows heavily from existing strategies-such as Smalltalk, MacBrowse, and the Macintosh interface-resulting in a system which will be familiar in some respects, but pleasantly new and surprisingly powerful in other respects. Those of you familiar with Smalltalk/V or Smalltalk-80 will feel right at home inside the browser. My biggest problem was trusting Object Master to handle the manual tasks I was used to performing manually.

Despite all this borrowing from familiar sources, Object Master and ACIUS still manage to set some significant precedents, both with respect to software construction and software distribution.

Object Master and document-centered design

For some time now, Apple has been pushing its developers to get away from building large, "everything but the kitchen sink" applications, and to instead write smaller, modular "tools" that can respond to AppleEvents, providing services to other AppleEvents-aware applications, and that can generate AppleEvents to request services from other tools. This means you begin a computing session with the proverbial empty canvas, constructing the blank document by calling upon a variety of tools to complete tasks. Modality would be all but eliminated.

In the Pink

If the above has a familiar but distant ring, think Pink. What Taligent will be offering is an object-oriented system from the ground up. The traditional shrink-wrapped "application" will probably not exist for the native Taligent environment. Rather, commercial object extensions (analogous to building blocks in MacApp) to the environment will provide enhancement to the environment as a whole, allowing you that much more facility in creating your document.

The scheme of commercial software distribution for the Taligent OS offers some interesting problems, since it may be difficult to singularly identify these third-party extensions once they are assimilated into the Taligent environment.

ACIUS has taken two interesting approaches to marketing Object Master. The first has little to do with software functionality, but sets a precedent that may change how Macintosh development tools are made available to the developer community. The second approach suggests a solution to commercial software distribution problems that may arise from the Taligent environment.

Pre-release me, let me go

Due to developer demand for Object Master, ACIUS established a pre-release purchase program, whereby the developer pays for the software and gets alpha- and beta-quality software immediately and in the form of regular updates, including the final release when available (similar to what Apple has done in providing ETO). This is good for ACIUS, since they know before "official" release how well the product is doing. As if that weren't enough, they're also getting a killer beta-test program for the product. And that's good for us, too, since we'll be getting a much better product. Looking at the release notes for the ß2 version, it appears that a significant number of pre-release purchaser input was incorporated into the beta versions. The pre-release program is also good for us, because it means we get "insanely great" software that much sooner.

Cooperative multi-vending

Because Object Master doesn't "do it all," it relies on other vendor products to flesh out its environmental approach. It does not compete against other products directly. In fact, Object Master's reference manual is rife with other-vendor information and product plugs, including descriptions of general facilities and how Object Master users can tap them (actually, there's never been better advertising for MPW or ResEdit, and never a better reason than Object Master to go out and buy them both).

ACIUS, merci!

Despite all I've said about Object Master already, I've still failed to mention many of the convenient and clever aspects, such as being able to directly hack preferences and layout resources with a resource editor like ResEdit. The pre-release reference manual shows you how. I've also not mentioned all the possible shortcuts and key command equivalents available in all the menus of all Object Master windows. Loïc Vandereyken, Object Master's author, shows admirable consistency in selecting and assigning key command equivalents. Not an easy task, considering the number of menus in Object Master. The reference manual also points of all of Object Master's shortcuts.

I wholeheartedly recommend using Object Master, even with one or two seams showing in an otherwise seamless product. Remember, it's still in beta.

Object Master-all this, and… it's written with MacApp!