A Method for Program Design
IT, Høgskolen i Østfold
IT, Høgskolen i Østfold
At some early stage in the design process we will have to start thinking about the functionality of the program. Normally we have a coarse idea of this already, when we work with the idea. It is however necessary to focus on this and attempt to make a fairly complete list of the functionality we want to offer the user.
This methodical approach offers three different tools for working with functionality:
We will start with the scenario. What we want to do is to try to write down what is going on in one or two or three imaginary sessions with the program. This technique is well known, independent of the design approach we apply.
The important, and difficult, aspect of this is to choose the right level of detail. If we go too much into detail, we tend to lock the functions up to a concrete interface design. If we don't include any details we don't get any effect from the description. The key is to be fairly detailed, but to keep the language in line with the metaphor. If we have chosen a book metaphor in some program we can write: " the user turns a page and inspects the suggested solution". If we write: " the user clicks on the next page button to see the suggested solution", we have decided that the turning of pages is implemented as buttons. We should try to avoid jumping to this kind of conclusions at this stage in the design.
Let us look at a very simple example: A part of a scenario for a program that is meant to be an editor for putting together chess articles in a newspaper:
"...the user then makes a new move on the chessboard and the program update the list of moves. The user places an image of the board in the test column. He then writes the final comments. Before closing the session he decides how many columns he want in the article and inspects the laid out chess article for the week. Finally he saves the article."
The verb phrases are:
These are the things we take with us for analysis. We want to identify synonyms and we want to identify the roles responsible for the different actions. This is the foundation for the activity table and the market diagram.
It is obvious that we have also given names to some important objects in the program: (chess)board, move, article, layout, column. This is, hopefully, concepts that are part of the chosen metaphor. We can use the scenario to check out whether the metaphor does cover the concepts we need.
An other interesting path to follow is to use the nouns as starting point for an object oriented design. We will not follow this path in this text, but it may take us into very interesting terrain. We may find ground for thinking pedagogy in quite another setting than we do in the market diagram in a later section.
