A useful feature of a design tool is the ability to communicate to the user how the product will function. Some might say that this should fall into the area of requirements, but often there are areas where the design will impact the interaction with the user.
That's a problem with UML and many of the design tools out there. They are too technical to present to a user. I find that simple flow diagrams can be used to communicate a lot of information to the user, and capture many requirements as well, so requirements can be debugged along with usability and design through user reviews.
But perhaps flowcharts should be updated to better capture the types of interactions that can happen with a user and the type of functionality a program can have. Currently, once you get past the basic flowchart notation (and what is that anyways?) there seems to be a gamut of possibilities .. probably similar to OO-design before the Rational Unified Process. And when I make a flowchart and follow the standard conventions, I feel like I'm designing a COBOL program that is connecting to a mainframe ... which is what they were designed to do, and probably do well.
This brings up a host of possibilties ... there could be language-specific or environment-specific flowchart conventions/notations that would facilitate lower-level design without descending to the code level ... yet provide some higher-level specification. And ideally there would be a hierarchy of notation, so that commonalities between languages/environments could be specified in a language/environment independent way, and refined to a more detailed specification only as required. Or better yet would be a flowchart language that captures the functionality of language-specific features (as currently implemented) in a language-independent way ... languages evolve, and we see convergence in the feature-set of various languages with each version (objects being added to perl, etc.).
No comments:
Post a Comment