8 Classes

8.1 Introduction

This chapter contains the detailed class diagrams which will be the starting point for implementation. It also contains information necessary for tracking fulfilment of requirements. For text descriptions of the classes, their attributes and methods and parameters, see appendix B.

8.2 Fulfilment of requirements

Each class in this chapter belongs to a high-level module. Which one is shown in the diagrams below. To see how the requirements are met in the design, it is necessary to read the architecture document [Johansson, 2003] as well. There the high-level modules are listed together with use cases that in a clear way show which module is responsible for satisfying a certain requirement.

8.3 Detailed layer overview

This diagram shows a detailed description of classes and in which layer they are. It is a refined version of the module diagram presented in the architecture document [Johansson, 2003].

Figure 3:  Detailed layer overview

8.4 Domain classes

The domain classes can be seen as the primitive data types of AudioJury. They are data containers which encapsulate the data. Their internal relationship reflects the real world relationship between the concepts they model. The domain classes are accessed from nearly all layers in some way.

Figure 4:  Domain classes

8.5 GUI classes

The GUI classes make up visual elements that must be presented in a certain way for tests to be interpreted correctly by the test participant. Some classes have not been designed, since they are trivial, have no logic at all and are already shown in the user interface appendix of the architecture document [Johansson, 2003].

Figure 5:  GUI classes

8.6 Central function classes

These classes contain the central function of AudioJury and make up the action and proxy layers. See section 8.3, "Detailed layer overview". Many of these classes are single instance classes. See section 3.3.2, "Singleton design pattern".

Figure 6:  Central function classes

8.7 Project processing

This diagram shows the interface of project processing and how its implementing classes have been designed. See section 3.3.1, "Proxy design pattern".

Figure 7:  Project processing

8.8 Result processing

This diagram shows the interface of result processing and how its implementing classes have been designed. See section 3.3.1, "Proxy design pattern"

Figure 8:  Result processing

8.9 Configuration processing

This diagram shows the interface of configuration processing and how its implementing classes have been designed. See section 3.2.1, "Proxy pattern".

Figure 9:  Configuration processing

8.10 Package overview

This diagram shows which packages are used and their dependencies.

Figure 10:  Package overview

8.11 Rejected class solutions

8.11.1 Instruction class

Even though this is the most general design for instructions, it was rejected since there will be no future need for adding more instruction types. The chosen design is shown in section 8.4, "Domain classes".

Figure 11:  Rejected Instruction class

8.11.2 Judgement related classes

This judgement design was rejected because it does not allow judgements with an arbitrary number of sounds.

Figure 12:  Rejected Judgement related classes

8.11.3 Test method classes

This test class was rejected because we needed a more detailed way of describing methods. Therefore, a complete class was devoted for that instead of just identifying it with a string.

Figure 13:  Rejected Test method classes

8.11.4 Test result alternative

In this design alternative the results are stored in the TestResults class. This is bad because results belong to a specific judgement and should be stored there.

Figure 14:  Rejected Test result alternative

8.11.5 Proxyless pattern alternative

In this alternative there is no common interface, which makes extension and modification more time consuming.

Figure 15:  Rejected Proxyless pattern alternative

Quadralay Corporation http://www.webworks.com Voice: (512) 719-3399 Fax: (512) 719-3606 sales@webworks.com