I write this note as I am reading “Object oriented analysis and design with applications” written by Booch, Jacobson and Rumbaugh. I took the time out to write this note because of the cynicism that hit me approximately page 224.
I have been looking for an easy way to define a system. I have believed that if it were possible to define a system then it is easy to build it. A variant of a law I believe in “A problem found is a problem solved!” and its corrolary “So keep looking for problems!”. I have been following the evolution of UML as a standard. It started out with a tantalizingly simple notation that got me interested. I have been following the progress of UML studying it every one in a while, but I always had the issue that I don’t seem to be able to use it quite as much as I would like to. It always felt that something more was needed to complete the notation; something more in the diagram.
Well this book is supposed to be the grand finale. The bible of UML with a lot more detail on how to design the system. And as I read it I can see that it does help in defining a system. But it’s become COMPLEX!
The grammar of the “language” has changed. There are nuances to notation that are difficult to internalize. What hurts more is that the diagramming tools cannot keep up. Earlier I could use DIA or StarUML (Free tools) to build a UML diagram, now I cannot. I expect some of the other paid tools will work but I don’t have the energy (read money) to invest in learning something that I am increasingly getting cynical about.
I’m reading about state charts now, and man they have got complex. I took my 25 year old conceptual learning on State Machines and reviewed this approach and the only thing I can say with conviction is “I’m not happy”.
This reminds me about the time I was working on H.323, a VoIP protocol. It had a structured data definition language (ASN.1) that was used to define how the H.323 control data packet (which took care of VoIP signaling) was formed. At that time we had written a data definition language to convert the ASN.1 notation into a usable C structure hierarchy. We had then gone on to using Lex and Yacc and written a parser to covert ASN.1 into a structured data definition in “C”. (Yes we actually built a Lex and Yacc parser in the real world!)
H.323 (and the related data definitions H.225 and H.245) were complex. Later when security got added it got even more so. When a new audio/video codec profile was added it resulted in newer versions of the protocol. Complex, but had a brevity about it that could be understood. It was a tree structure that you used to get at the data. If you had the PER format understood you would get at the right data.
Then came SIP. It was slated to be a game changer. It would take the complexity around H.323 and make it so simple that you would actually wonder why you were using H.323 anyway. It started out like that. A simple textual means of defining destinations that you wanted to call, etc, and with every version it got more and more complex. If you had a parser that worked for SIP the next definition of the format killed it. Sure it was human readable, but converting that human readable packet into something that the computer understood required introducing complexity. A huge amount of complexity. Yuck!
So…I’ll complete reading this book. I will reflect on the concepts and examples presented. I still have another 250 or so pages to go, and I like to think I need to complete the examples (and actually design something) before I can make a claim (“This is great!” or “This Sucks!”) so I will do that. But the nagging thought in the back of my mind. The human mind understands complex concepts pretty easily (dare I say things like Friendship and Love in a technical dissertation!) instead of trying to build complex systems from simplicity, should we be designing notation around the complex, with the idea of simplicity being the outcome…
Samyeer Metrani 