|
Home | Login | Recent Changes | Search | All Pages | Help
AssumptionsAboutModelingSee also: DoTestersResonateWithModels Becky, would you like to post that article on the AYE 2002 Articles? I think it touches some interesting preconceived notions -- our discussion exposed several assumptions that I hadn't aired before "Doesn't everybody know that..." Becky, my assumptions on graphic models go back to about 1975. At that time (pre-word processing) documentation was really a burden. Changing documents was major work, getting graphics in-line was unbearable. There were computer-generated model languages (Autoflow, for flow-charting), but they weren't worth the maintenance in my opinion. Structured COBOL was easier and more accurate to review than flow charts were. At that time I was developing Aetna's first billing system using an online database [read-only online]. The group immediately behind my chair were revising an existing policy writing system, and the individual just behind me had just finished about 75 pages of india-inked diagrams of the system flow. One day, while leaning back in my chair [thinking posture] the portable brain-wave reflector [sorry, arc-shaped divider] tipped over and hit a cup of coffee on his desk, soaking the entire pile of originals! I felt terrible - he told me that there weren't any copies yet! Worse - he quit 2 weeks later! I think that experience poisoned the waters of high-fidelity modeling effort for me for quite a while. Later, when the Macintosh made word processing with integrated graphics practical (savable & re-editable) I softened my stance on documentation vs. self-commented code. Another assumption I carry is that the quality of customer review is inversely proportional to the layout quality of the document. That is, if things are very neat, aligned, with consistent fonts, people's critical facility switches off. On the other hand, a diagram on a white board with Post-It notes and several colors of markers is much more acceptable for critique, so the reviewers actually consider where it might be improved or corrected. While word processors and graphic editors make model editing & generation easy, they don't get the kind of critical review that is warranted. Scott Ambler recognizes this and prefers white board modeling - record it via digital camera for posterity and for difference analysis. I have trouble imagining "executable models" being useful enough for significant programming. Visual languages, ultra-high-level languages, etc. have failed to provide enough fine-grained control for me to meet requirements that scale. My assumption is that detailed models are harder to read/maintain than detailed code -- we have a vast discipline of modularity to deal with code, but I don't personally know how to manage detail complexity on a model. For example, what is/was the revision delta? A model that's too hard to maintain encourages inappropriate freezing of the requirements for all the wrong reasons. In my view, abstraction (modeling) is how to deal with complexity - reduce the strength of the details' complexity by ignoring (information hiding) irrelevant details. I'm willing to re-evaluate, but haven't seen large scale use to demonstrate where my assumptions fail. BobLee 2002.07.19 Bob, I can feel the pain as the india ink slid off your colleagues charts. While you were working at Aetna, I had just left Prudential for Scientific Time Sharing and the brave new world of APL. Oddly enough this culture is where I eventually learned to build visual models. I heartily agree about the usefulness and ease of updating early models - NOT!. One friend of mine who worked on OS 370 told me his team went through the discipline of building structure charts. They abandoned the practice after 12 3-inch binders were filled. Your assumptions about reviews ring 100% true to me. I heartily agree that sketching and collage is a great way to elicit information. Showing people too pretty or perfect a picture isn't a conversation opener. I'm with you and Scott on white boards and other handy tools for immediate capture. My current stance is not to rely on models for presentation. I use models as technical tools and use something else as a communication tool. Note that people offering perfect documents aren't always expecting critiques! As a young consultant my client gave me a beautifully produced model. I thanked him and went to work reading all the detail to help find opportunities for improvement. When I returned with about a dozen ideas, I could see his face fall, and I learned a BIG lesson. I have trouble imagining "executable models" being useful enough for significant programming. This is a common and quite reasonable reaction. The process of executable models and translation is not "your father's" process ...(er....our! process) and is a significant divergence in system development. Executable models and translation have been around (in something like its present form) since about 1990. Most people have used it on highly critical systems - NASA projects, Avionics, medical equipment, telecom and automotive, to name a few. Modeling, like planning, requires more focus up front. Most businesses just want to move past the front and get to the back - code. :) A colleague's and my peak experience was a mode control model we built and sold to be used for the engine controls for the X-33. (They integrated it with their models for a translation process. All worked fine). References for executable modeling and translation can be found on www.projtech.com and ww.kc.com. One invaluable resource is Leon Starr's Executable UML: The models are the code. It is a case study and comes with two CDs. One is a demo version of Project Technology's simulation and translation tools, the other CD is Leon's model for an elevator (and not just a toy model, either). Seeing and doing brings better understanding. (To see and do you will need to be running Windows 95/98 or NT/200 on a PC). Once a model becomes a technical document (like code) it becomes less usable as a communication tool for a broader audience. As much as I like executable models, I also love sketches and am happy building non-technical models. One approach doesn't fit all. Everyone shouldn't build executable models. Because in some cases the software and the culture won't support the discipline needed. That would be a massive waste of everyone's time and good will, not to mention the cost involved. My assumption is that detailed models are harder to read/maintain than detailed code . I remember someone telling me tsomething similar about APL. :) Harder to read? Well, not when you know the graphic language and how the pieces fit together. (I always thought Greek was harder than Latin, but then I couldn't interpret the Cyrillic(?) - Greek - alphabet). Juggling the dimensions of a model does require some comfort with spatial reasoning. Harder to maintain? Sure. You have to keep your views consistent. One of the BIG mis-conceptions about models is that they are all the same - i.e. If you read UML, you can read any model. Not so! The semantics for the notations are not sufficiently rigorous for everyone to assign the same meaning. And that can result in so me very hard to read models! ("hmmmm, what do they really mean?") Then you need to call in Model Psychics. I've had some practice here! - BeckyWinant 2002.07.19 Terminology clarification: does executable model == Simulation? It sounds like you're describing simulation models of physical systems ranging from automotive vibration damping, flight simulators, to elevator systems. [Correct me if I've got this wrong!] Do you see executable models for transaction processing systems with moving target business/legal rules? I agree, compared to APL <grin!> anything is easier to grasp. APL is a write-only language, at least to me! Anyone want to segue into AssumptionsAboutLanguages - I've got a few hundred of them... Bob, Yes, executable models are models which can be run through a model simulation tool. These days UML models. Simulations of physical systems inspired model simulations, Folks in the embedded community wanted to test that their requirements for their software met specs and workable for the job (say, engine control) before they actually wrote the software. Do you see executable models for transaction processing systems with moving target business/legal rules . That I know of, translation has been used in stock market trading. A client of mine who built commercial software for the chemical industry used the front end of a translation approach (domain partitioning, high level of abstraction) to deal with the changing industry regulation and even more the ever changing customer desires. They didn't do simulation or translation because budgets didn't allow, but they used their models in addressing changes to their product and vreleases. I'm not sure if deep conversation about model abstraction are of interest to anyone else, but that is the heart and soul of robust, reusable and usable models and executable models. Model simulations come in two forms: code-based simulations and model-based simulations. Some tools (such as Rational's Real-time suite) run a simulation from code planted in the model. Other tools run a simulation based on a "platform-independent" language that maps to the model's inherent constructs. In UML an association is a model construct. C++ and other object languages don't have a "native" association operation. You have to naviagate the association using what the code allows. Usually setting up foreign keys and such for the objects to talk to one another. A model-based simulation executes "model construct semantics". Model-based simulation is used for translation, because this approach keeps the knowledge models (aka analysis, domain models) separate from design patterns and specific implementation mappings. This supports the translation goal of higher level of analysis and design reuse and quicker assembly using stable components. I LOVE APL! :) I spent seven years in the APL time-sharing biz (which may be nearly as long as it existed). I got out because I didn't see much future - APL or Time-sharing. Becky
Updated: Saturday, July 20, 2002 |
