Saturday, March 31, 2007

I have made some small changes to my OO analysis writup on the website. I have come to part C. I am to discuss the advantages and disadvantages of the Structured analysis versus the Object Oriented analysis approach and suggest an approach to that could be used for large software systems.

First of all De Marco wrote about Structured analysis and published his book in 1979. Grady Booch wrote about Object Oriented analysis and published the second edition in 1994. This is a 15 year difference. The chronology of this history is important. De Marco talks about "Classical Analysis" as apposed to "Structured Analysis" and implies a waterfall model with a huge, as he calls it Victorian Novel, design document. In his book he talks about complexity and manageability just as Booch does. He talks about developing dozens or hundreds of mini-specifications rather than this large document, the Victorian Novel. On page 15 section 1.4.1 De Marco lays out his goals for Structured Analysis. "Problem size must be dealt with using effective methods of partitioning. The Victorian novel specification is out. Graphics have to be used where possible. We have to differentiate between logical and physical considerations, and allocate responsibility, based on this differentiation, between the analyst and the user. We have to build logical system models so the user can gain familiarity with system characteristics before implementation." Remember that the computer languages employed at the time were procedural in nature. Grady Booch wrote about C++ in a book in 1993 entitled Object Oriented Programming in C++. This is still 14 years after De Marco`s Structured Analysis book. Booch wrote an elaborate beginning to his book to support the notion that large non-trivial software systems are very complex. But, his vigor in explaining why software systems are complex does not actually confirm that object oriented methods are the best way to design software systems because of there complexity. I do not deny they software systems are complex. Four of the five attributes of a software system, the limitations of the human capacity for dealing with complexity, the notion that object oriented analysis and design reflects the topology of object oriented languages better is not at issue. It is the first of the five attributes of a complex software system that I am at odds with. Booch states: "Frequently, complexity takes the form of a hierarchy, whereby a complex system is composed of interrelated subsystems that have in turn their own subsystems, and so on, until some lowest level of elementary components is reached". Page 12 of object oriented analysis and design. I generally agree with this sentence but I am at odds with a mental leap of part of it. The crux of the issue is: There is an assumption made here that the important issue here is that the system being analyzed is hierarchical and that the issue is the central issue of analysis. First of all not all systems are hierarchical. That part is something easily seen. The second and more major issue is that: "ALL HUMAN BEINGS DOING ANALYSIS, ORGANIZE INFORMATION FOR ANALYSIS HIERARCHICALLY". This is false. I having a learning disability I know this intuitively as fact. I know that I have also read it in a book I think was called "The art of learning". I am still looking for the reference and I could be wrong about the reference. At any rate, not all humans organize things in chunks of information. Some organize data into lists and use chronology. i.e. more like Structured Analysis. Analysis of software systems is the assimilation of information about the system into our human understanding. The assumption of the structure of how things are organized should not be a determination on how to best do analysis. Storage, retrieval, and organization of information in the human mind is not a justification for how to do analysis because the assumption is made that all people think the same way...very presumptuous. The other issue is that the rest of the justification for object analysis methods are really based on when the book was written. I would need more space to explain this one. But, just a taste of that would be to say look when object oriented languages became mainstream.

It took me two days to get this entry ready. I find it hard to put this into the answer for part C of the OO versus Structured question. It does not follow what I would think would be a mainstream answer. I would expect that the testers want you to just take what Booch said and quote it in the answer. This would be easy to do if I thought that it was true. This question is not a PhD question. This question is a question for students who blindly believe what they read. A PhD should really question everything. This question is wrong on several levels. But, how do you ask questions for a test like this unless you generally take the accepted answer. I found the same problem with other exam subjects in this series of candidacy exams, especially the database exam. Being able to memorize the accepted answer is usually the one they want. If they have to think then it is wrong. If you think it is probably wrong. Use the generally accepted answer. I admit I have a better understanding for what Booch wrote given the time that I took to read this text for quotes. Don`t get me wrong the Yourdon text, the modern 2006 book on Structured Analysis called "Just Enough Structured Analysis", has problems too. Could Yourdon get some references that are not from the 70`s? Well anyway, he does have some good points and pokes fun at Booch in some ways.

I will now write part C of the Structured Analysis versus Object Oriented Analysis question. Could you hear the announcer voice I just used? It made me feel better, like this question was important.