4 Modules and layers

This chapter gives a description of the identified modules and their purpose.

4.1 GUI layer

There is only one module in the GUI layer. This module only communicates with the modules in the action layer. In the design specification [Johansson, 2003], a number of classes representing the screens in appendix B will be identified.

4.2 Action layer

The action layer is the core of Audio Jury. It is here that almost all requirements are fulfilled. See section 3.2. Fulfilment of requirements for details.

Figure 8:  Admin and Client Action layer

4.2.1 Project Manager

This is a high-level interface that covers use cases like Create Project, Edit Project, Save Project, Delete Project, Activate Project, Close Project, Duplicate Project and Run Project.

ProjectManager also communicates with Result Manager when results are to be imported.

Accessed by: GUI.

Depends on: ProjectBuilder, Test Manager, Result Manager, Configuration Manager.

4.2.2 Project Builder

This module operates on a single project. It contains operations for editing and building up a project.

Accessed by: GUI, Project Manager.

Depends on: Test Runner, Storage Proxy.

4.2.3 Test Manager

This is a high-level interface for managing tests. Its task is to create, edit and run tests.

Accessed by: GUI, Project Manager.

Depends on: None.

4.2.4 Test Runner

This module's task is to run a test opened by Project Builder module and also to collect test results during the test. When the test is finished results are passed to Result Manager.

When the whole project is finished all results from all tests in the project are saved by Result Manager.

Accessed by: Project Manager.

Depends on: Result Manager.

4.2.5 Result Manager

This module's task is to collect incremental results while the project is being run. When the project is finished Result Manager will pass all results from the tests to Result Proxy.

Accessed by: GUI, Test Runner, Project Manager.

Depends on: Result Proxy.

4.2.6 Configuration Manager

This module represents a high-level service for managing system configuration for both administrator and client programs.

Configuration settings include project paths, result paths, user defined scales, etc.

Physical implementation, how and where to store configuration information, is delegated to Configuration Proxy module. It provides a service for the proxy level modules Storage Proxy and Result Proxy, when they need configuration information.

Accessed by: GUI, Test Runner, Storage Proxy, Result Proxy.

Depends on: Configuration Proxy.

4.3 Proxy layer

Figure 9:  Admin and Client Proxy layer

4.3.1 Storage Proxy

This module will implement the procedures for accessing and storing projects and tests in the shared folder.

Accessed by: Project Builder.

Depends on: Java IO, Configuration Manager.

4.3.2 Sound API Proxy

This module acts as a proxy between the action layer and the API layer for playing sounds. It does not implement the sound playing function, rather it just provides an interface. It relies on sound playing functionality in the API layer.

Accessed by: Test Runner.

Depends on: Java Sound API.

4.3.3 Configuration Proxy

This module implements the configuration access and storage functionality.

Accessed by: Configuration Manager.

Depends on: Java IO.

4.3.4 Result Proxy

This module implements the result access and storage functionality.

Accessed by: ConfigurationManager.

Depends on: Java IO.

4.4 API layer

Figure 10:  Admin and client API layer

This layer is actually the Java API and the project group will not write any code here.

4.4.1 Java IO

This module provides system input and output through data streams, serialization and the file system.

Accessed by: Storage Proxy, Result Proxy, Configuration Proxy.

Depends on: None.

4.4.2 Java Sound API:

This module provides functionality for capturing, processing and playing back audio data.

Accessed by: Test Runner.

Depends on: None.

4.5 Layers overview

The connections between layers and the dependencies between modules described in sections 4.1 - 4.4 will below be shown graphically.

Figure 11:  Administrator layer overview

Figure 12:  Client layer overview

4.6 Dynamic aspect

Use case and module diagrams presented in chapter 3 and sections 4.1 - 4.5 show the static aspects of the system. Modules are not static components, they interact with one another, accomplishing a particular use case. Diagrams, that show how modules communicate, help more clearly understanding responsibilities of the modules and will be used during the design phase.

Activity diagrams have been chosen as method to represent communication between modules. Interaction diagrams will be used in the design to show interaction between objects.

Only high-level actions like Create Project, Run Project and Result Processing are described by the activity diagrams.

The diagrams can be found in appendix A.

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