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!
