Designing domain models.
I had originally planned on titling this article "Designing software", but this title is more accurate, I think....
When Apple first launched OS X, I was devouring this new (to me) programming environment of theirs. Objective-C, or Cocoa as Apple referred to it had been around for a while and was the foundation of OpenStep (OS X's parentage). Well, there was slim pickin's on the commercial bookshelf when trying to find information on Cocoa... but I came across this book in the bargain bin called OpenStep for Enterprises by Nancy Craighill. the gist of the book is a fairly complete, and not overly simplistic, soup-to-nuts software design project using Cocoa's ancestor, OpenStep.
The interesting bit is that a part of the book is devoted to CRC cards. As in, the design project is actually building a CRC card analysis tool.
Even more interesting is that as I was reading OpenStep for Enterprises I was struck by an interesting familiarity. I am not classically trained as a software engineer. I spent years at Texas A&M getting a degree in Environmental Design (think "architecture"). In my third-year design studio, the required text for the class was Problem Seeking, An Architectural Programming Primer. Betwixt it's covers you will find words like user requirements and design goals. Both are terms that also come up quite frequently in software engineering as well.
And much like CRC cards, this design book outlined the use of "Analysis Cards" to capture program requirements during the design of a structure. The book has been an excellent teacher and it's name is apt -- problem seeking is the act of identifying the nature of a design. In architectural practice this is (coincidentally) known as programming. Its purpose is "to provide a broad spectrum of analyses leading to client decision-making and problem definition". That last bit is the key -- problem definition is (IMHO) the holy grail. It's too bad that in software, that's frequently a moving target.
Anyway, I've just been rambling. I don't have much of a point, other than to demonstrate the myriad correlations between architecture and software (at least in the abstract).
technorati tags:architecture, problem seeking, programming, CRC, class, responsibility, collaboration, analysis, design
Blogged with Flock

0 Comments:
Post a Comment
<< Home