November 91 - BAMADA Notes
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!