| |
|
|
|
This chapter discusses and presents the design decisions made. The issues vary in importance and level of detail, but this is a natural reflection of the fact that some details need more attention than others.
The decisions are results of very dynamic discussions in the design group where several, sometimes quite different, solutions were proposed.
This chapter is useful not only during implementation, but also in case the design of the system would have to be revised. Time can be saved by looking at the motivation for rejecting some design of a particular issue.
For each issue, the background is explained. Then the actual decision is presented. In some cases a brief discussion of the advantages is given. Finally the rejected design ideas are being looked at. More detailed descriptions of rejected design are found in section 8.11, "Rejected class solutions".
Projects and tests are related to each other in a hierarchical way. Also projects can be grouped by one of their three states "dynamic", "active" and "closed". See chapter 5, "Project states and transitions" for details.
It was decided that the projects and tests should be organized in a directory structure as described in chapter 6, "Directory structure". This is a natural way to organize tests and projects. Importing tests from other projects than the current one becomes an easy task. This decision also plays very well with the "make it simple" guideline. See the philosophy chapter of the architecture document [Johansson, 2003].
No real alternatives came up, since the decision in section 4.2.2 seemed so obvious considering the natural relationship between projects and tests and the different project states.
Anyway, an alternative would have been not to store copies of the original audio files inside the directory of the program, but rather pointing at them with reference. This is however not possible for two reasons mainly:
· The project must be self-contained. It is a requirement that the system should work without a network, see the requirements specification [Larsson, 2003]. If a project is distributed with removable media, references to files would become invalid.
· Files may not remain where they were when the project was created. If a file is moved or removed, the references to it would be left dangling.
Yet another solution would be to have all files located in the same directory, including project settings, test settings and audio files. This might look easier at first, but simple actions such as copying a project to a remote location would actually become more complex to perform. In particular, manually copying a project to removable media as described in section 2.2, "Distribution of project" would be virtually impossible.
The projects and tests are organized in directories due to the decision described in section 4.2.2. How should these directories be named?
The project and test names are also stored in the serialized project and test objects. How these names are kept in synchronization is described in section 7.7, "Project and test name synchronization". This design choice also allows projects and tests to be renamed, using the operating system shell, and still avoid the risk of inconsistency between the directory name and the name stored in the serialized object.
Directories could be named automatically by the application and the names could be stored in the setting files alone. This however, would make manual copying of projects to removable media as described in section 2.2, "Distribution of project" less intuitive for the user.
In a typical test situation it is likely that several test subjects in sequence run a specific project on the same computer. Each completed run will generate a file containing the results of the session.
It was decided that a tuple consisting of a project object and a user data object would make up the result object. This object is generated when a test subject has completed a project. This object will then be serialized to file.
At first, it seemed to be a waste of space to serialize the whole project object. Therefore an alternative idea was to extract the results by walking the project object tree visiting all test objects and judgement objects and only extracting the scores from the judgements.
At second thought, space was not an issue. A serialized object really takes very little space, since in essence only the variables are saved. Also all getter methods necessary for examining results are already present implicitly by the design of the project, test and judgement classes.
Result files need to get back from the client programs to the administrator program for them to be assembled, summarized and later reported. This may be accomplished by either using the shared folder or by manual act of the administrator. See section 2.3, "Result collection" for details. The shared folder may not always be accessible and the administrator may not always be able to take a generated result file from the client to the administrator program in between two test runs. Therefore each result file must be uniquely named so it does not overwrite the previous result file.
An alternative idea was to have the results from each test subject to be added incrementally to a result file. This was rejected because of unnecessary complexity and the fact that a name clash would happen sooner or later anyway during result collection when result files from different clients would have to be saved in the same directory.
A project is organized hierarchically on disk with all the audio files located in their respective test directory, see chapter 6, "Directory structure". These directories must be created at some point. Also, the audio files originally are located elsewhere and need to be copied to the right test directory in the project at some point. The question is when during the project build process this point in time is. Directories may be created and files may be copied as soon as the administrator chooses to create a test or include a sound. Another possibility is to postpone all operations until the administrator is done with the current build session and clicks the save button in the project builder. See architecture document [Johansson, 2003], for the prototype of the graphical user interface.
It was decided that project build actions should be postponed until the administrator is done with the current session in the project builder. This means that all actions somehow must be remembered so they can be executed later, which could seem like adding unnecessary complexity. However, it turns out to be very simple to perform with the chosen design in which a project object has a list of test objects. See section 7.6, "Postponed build action commitment" for details on how this is achieved.
The main advantage of this decision is that the application will appear very responsive to the administrator, as there will be no delays during project building. Click actions will execute immediately. There will not be any delay due to file operations. Not until the administrator clicks the save button in the project editor all actions of the session get committed. This delay might be in the order of up to a few minutes depending on disk and network speed. Therefore a special dialog is devoted to notify this. See section 4.9.
The obvious alternative solution is to have build actions be executed immediately. This solution is attractive because of its simpleness and therefore sounds well together with the "make it simple" guideline suggested in the architecture document. The drawback is that the administrator will experience less "flow" when clicking and building the project.
Regardless of in which state a project is, it must be possible to uniquely identify it to avoid confusion.
Project names must be unique. The three project states have a common name domain, which means that there must not be two projects in different states with the same name. See chapter 5, "Project states and transitions" for a description of how this is enforced by the application.
Each project and each test has an instruction which is presented to the user when the project is run. There are two types of instructions: text and audio instructions, see the requirements specification [Larsson, 2003]. The modeling of the instruction class was surrounded by some debate in the design group.
It was decided to let both audio and text instructions be represented by the same class. The instruction class shall have no access to the GUI layer. Instead, the GUI layer should ask the instruction object for data and then display it.
The first idea was to have an abstract instruction class as base class for one text instruction class and one audio instruction class. This was rejected because the only interesting getter method of the two subclasses would do so different things anyway (return a text string versus return a file name) that a common interface would be of no benefit.
Also, initially there was an idea of letting the audio instruction class invoke playback of the sound. This was rejected because in analogy with the text instruction class it would handle visualization of the text on screen. This is completely wrong seen from the layered approach view, see the architecture document [Johansson, 2003].
Due to the accumulated delay described in section 4.6.2, it is necessary to notify the user of the ongoing data transaction. This is in order to not let the user, after having clicked the save button in the project editor, think the program has hung itself.
When the administrator clicks the save button in the project editor, a simple dialog that tells the user that data transactions are in progress should be displayed. It must not be possible to close the dialog or start to interact with the project manager until the dialog closes. The dialog shall auto close when the data transactions are completed.
 Quadralay Corporation http://www.webworks.com Voice: (512) 719-3399 Fax: (512) 719-3606 sales@webworks.com |
| |
|
|
|