BAMADA Notes

James Plamondon

AUGUST-Larry Rosenstein

An audience of 75 was treated to an evening with Larry Rosenstein, MacApp Wizard, at the August meeting of the Bay Area MacApp Developers Association.

Rosenstein is one of the authors of the original version of MacApp, and was deeply involved with the Lisa Toolkit before that. More recently, he co-wrote the book Programming with MacApp [in C++] from Addison-Wesley, along with David Wilson and Dan Schafer. Lately, he's been looking a little Pink, though he won't say why.

Windows?

The meeting began with a grumble from the assembled host regarding the presence of a traitor in their midst-namely, me-who had abandoned the Mac to program for Windows. After arguing among themselves for a while, trying to decide whether I was a turncoat, a heretic, or a pioneer, the audience collectively decided that there wasn't a term foul enough to describe my actions. My protests that I was just taking a sabbatical from the Mac, and would be back in a year, were grudgingly accepted. Later, privately, many attendees said (in hushed whispers, so that none would overhear) that they, too, were under pressure to produce Windows versions of their software, and that they wouldn't mind getting a travelogue of my journeys in Windows land. Watch for such a series in a Mac programming magazine near you.

While we were on the subject, I informally broached the question of whether MADA's charter should be expanded to include frameworks for Windows. It was hard to decide which response was louder-the hisses or the boos. Either way, the idea was universally detested. Having MADA become one rib of an umbrella organization which covered lots of frameworks was more acceptable, so long as FrameWorks didn't get cluttered up with Windows stuff.

Filtered Commands

Finally, we were ready for Rosenstein's presentation. He began with filtered commands, which are a mechanism to reduce the amount of information that one must maintain in order to undo or redo a command. Rosenstein used the example of a complex styled text document containing hundreds of different style runs-a little bold Times, some 9-point Zapf Chancery, a dash of italic Courier, etc. If the user selected all of the document's styled text, and set it to plain Geneva 12, saving the previous state of the document-with all of its different styles-could take a lot of space. In the worst case, you might have to save off the entire old version of the document.

Filtered commands solve this problem. Instead of saving the pre-change data, and then altering the document in accordance with the command, the command installs a filter into each affected piece of data which makes it look as if it has been changed. In the example above, each style run object would be filtered to look like it was plain Geneva 12. To undo the command, the filter is simply removed; to redo it, the filter is reapplied.

Filtered commands simplify the implementation of Undo and Redo significantly, and reduce storage requirements at the cost of slightly slower data access times. See chapter 25 of Rosenstein's excellent book for a detailed description of the mechanics of the approach.

Streams

After Rosenstein described filtered commands, he moved on to streams, which are a major feature of MacApp 3. By using streams for data I/O, you can handle input and output more abstractly; for instance, you can stream to a file or to the clipboard with equal ease. Streams are discussed in detail in chapter 22 of Rosenstein's book.

The TStream class is responsible for reading and writing bytes, or aggregates of bytes, from and to "something." TStream's subclasses implement the abstract methods that do the actual reading and writing. For example, a TFileStream implements reading and writing to a file, while a THandleStream implements reading and writing to a memory block. A TCountingStream doesn't read or write anything-it just counts the bytes that it was told to write. This is particularly useful when trying to find out if there's enough room on a disk to hold a file, before you actually write it out via a TFileStream.

Rosenstein did a great job presenting his material to a interested and knowledgeable audience. We look forward to a presentation on Pink at his earliest convenience. (Would you care to schedule that now, Larry?)

September- Solution-based modelling

At the September BAMADA meeting, Jeff Alger introduced a crowd of over fifty attendees to Solution-Based Modeling (SBM). SBM is the subject of a book forthcoming from Addison-Wesley entitled "Developing Object-Oriented Software for the Macintosh," and is the brainchild of Alger and his coauthor, Neal Goldstein.

SBM is an integrated, lifecycle approach to software development. It emphasizes the importance of involving marketing, management, and other diverse groups in the software development process from the outset. Where other methodologies-most notably the "waterfall" model, in which analysis "flows" into design, design into programming, and so on-look at software development as a series of separate stages, SBM takes a more incremental approach.

Despite the title of Alger and Goldstein's book, SBM is a platform and language- independent methodology. (The publisher insisted that the word "Macintosh" be in the title; their studies have shown that people prefer to buy books directed at a specific platform. This led Goldstein to suggest that the book be titled "Platform-independent Software Development for the Macintosh," to be followed by "…for Windows," "…for OSF/Motif," etc.)

Although one could, in theory, do the actual programming in a non-object-oriented language, SBM takes a very object-oriented approach to analysis and design.

Involving non-programmers in design decisions

Project scheduling and task duration estimation are key to the success of any project. SBM addresses this issue in part by involving non-programmers in the design decisions as early as possible. Doing so leads these participants to buy into the process, so that they can better understand the technical tradeoffs. In fact, throughout the talk, Alger emphasized the need to get those darn marketing types involved as early as possible, so the programmers had a chance to pound some sense into them. I wonder if the talk would have been different, if given to a marketing group…

Visual Design Language

SBM introduces yet another graphical analysis and design language to the OOP world. Aptly named the Visual Design Language (VDL), it has the singular advantage of having been designed by graphic artists, rather than programmers. As a result, it is easier to read and understand than any other I've seen (such as the Booch Notation). Various other graphical design languages have left a bad taste in my mouth, but VDL looks yummy. No application yet exists to facilitate the process of writing in VDL, but we were assured such an application would exist in the near future. But then, I'm still waiting for Eiffel for the Macintosh.

SBM's strengths

SBM admits a number of unpleasant truths that are often ignored. For example, it admits that half of the project cycle will be taken up with analysis, and emphasizes the advantages of doing this analysis up front, rather than in numerous mid-course corrections. (Once a boss of mine asked me what I was doing "staring off into space." "Thinking," I answered. He actually replied, with some heat, "Well, get back to work!" I hope that guy discovers SBM, for the sake of his current employees.)

If half of the available time is taken up in analysis, half of what's left goes to design, with the remainder going to actual programming. Alger commented that this breakdown makes code reuse look less important in the long run; under SBM, reuse of analysis is twice as important as reuse of code. On the other hand, application frameworks like MacApp encapsulate not just code, but analysis and design, as well-so the "win" from using MacApp applies to all project phases, not just programming. Look at MacApp's failure handling, memory management, and command mechanisms, for example. Most pre-MacApp applications didn't have anything like them-not because they were so hard to code, but because they were so hard to invent. (And let me tell you, so far, no Windows framework I've seen has come close to these capabilities.)

Solution-Based Modeling (SBM) looks like a good tool for use in large, real-world software development projects. If you've found that there's more to the management of your multi-programmer projects than just using Projector, spend some time with Alger and Goldstein's book when it becomes available.

Upcoming in October- Feedback to the MacApp Team

At the BAMADA meeting in October, we'll have the MacApp Team at our mercy; the evening's topic will be "Feedback to the MacApp Team." Bring neither rotting fruit nor laurel accolades, but rather your comments, suggestions, bugs, gotchas, fixes, workarounds, feature requests, insolvable dilemmas, and ingenious solutions. Whether your comments relate to MacApp 2.0 (yes, there are still a lot of people using MacApp 2.0), 3.0, or X.x, bring them over and let's see what we can do with them. We may even get demos of the latest versions of Mouser and ViewEdit, if we're sufficiently polite.

As (almost) always, we'll be meeting on the fourth Wednesday of the month-October 23rd-at 7pm, in the Mountain View room of Apple's City Center Four building, on the southwest corner of Stevens Creek and De Anza Boulevards (at 20450 Stevens Creek), in Cupertino. Come early to grab a good seat. Be there or be tetrahedral!