A Method for Program Design
IT, Høgskolen i Østfold
IT, Høgskolen i Østfold
Running a program is like shopping in a market. We can shop in an open market or we can get entangled in a bazaar without any understandable structure with narrow passages. We will use this market metaphor to describe and discuss the functionality and the pedagogy of a program.
The market diagram is one of the most important documents in the design process. It helps us:
The market diagram is a compromise between precision an overview. Trained programmers and system analysts will find that the diagram lacks many elements we would expect to find if it should be a precise tool for program descriptions. The most important is that it has no syntax for describing conditions, and that data flow is only described in a rudimentary way.
When the diagram, in spit of this severe lacks, play an important role in design is it because it supports an holistic approach, and that it enhance communication.
The main elements in a market diagram is one or more marketplaces with shopping booths. The availability and the connections between these elements describes the functionality. It describes how our shopping can be performed. Connections from one area to another may be open, two way connections or they may lead us into paths with no return. Some connections may need a password. To perform an action in the program is analogue to entering a booth in the market.
The limitations are obvious; we have no conditional paths, we have only rudimentary tools for indicating data and models. What we do have is a visual metaphor that enables us to plan and communicate the overall structure of our design. And that is basically what we are looking for.
A booth is not a storage room for data, it is a place for action. The actions from the activity table finds their places in booths in the market.
Markets have different architecture. We will find open markets and sequential markets. The intention with the market diagram is to be able to identify the architecture and discuss it qualities in respect to our functional and pedagogical objectives.
If we stay in the metaphor, it is clear that we need a basket to carry with us the things we shop in the booths. The market metaphor thus lets us discuss the learning that takes place as accumulating experiences from the use of the program.
This may seem like a natural and uncomplicated train of thoughts, but the concept of the basket is a rather difficult and challenging one. We may have at least two perspectives on the basket:
An interpretation of the basket as a symbol for the students portfolio may be fruitful and we can find some interesting theoretical approaches that may help us grasp this concept. This discussion is beyond this text.
The structure of the market discloses the pedagogical reasoning in the design.
A market that contains long sequential rows of booths reflects the designers urge to control the learning. The actions must follow a planned sequence. This is a typical problem in a large number of designs. The designer has in the back of her head an idea of what is the best sequence to do things, and usually the argument is that "it is not possible to understand this before the student has done that". This is in many designs the core of the matter, and where the pedagogical challenge of the design becomes evident. In almost all designs it is possible to break these sequences and find another approach. An argument for an open experimenting pedagogy is an argument for an open market.
The markets with large hierarchical parts usually disclose a design where the structuring of data or functionality has been the major priority in design. It is not necessarily a connection between these structures and a learning strategy.
Both the sequential and the hierarchical approaches find their applications in areas where drill and training is essential. There may be good reasons to consider very controlled learning of critical work sequences in for instance industrial security applications.
In general the method is based on a philosophy that promotes the open, free market. We want the user to control what she wants to do, when she wants to do it and in which sequence she prefers to work. The user should be in control.
Experience shows that there are a few things to look out for when working with the market diagram.
Details
All the techniques should contribute to the progress of the work. To achieve this it is important to find a reasonable level of detail. It is very easy, and in a sense correct to draw a market diagram like the one on the left.
The one on the right does however opens up for a more detailed discussion about the activities.
Swan necks
A very typical discussion in design of "canned" pedagogy is that of sequence and inherent dependency in the material. Some things does not have meaning until something else is understood, or done. This kind of reasoning often ends up in the typical swan necked diagrams, as the left one below..
|
|
It turns out that it is almost always possible to find a solution as on the right figure. It has rather obvious parallels to general program design; it would be rather awesome if a modern word processor should prompt us on all possible settings before we would be able to start writing.
Standards
Most programs has some standard situations that should be treated in a standard way. If we have some kind of document based application, it is reasonable to expect that we will have the usual, new, open, save functionality, and there is no reason to overload the market diagram with these details; a simple archive booth would do.
