Version: 1.2 Date: 2003-05-01 - LiU

Abstract

This document describes the architecture of Audio Jury. It presents and motivates decisions madeconcerning architecture and gives a general understanding of how the system is going to work. This isaccomplished by presenting which modules the system will consist of, as well as showing a prototype ofthe user interface.

A combination of use case diagrams and module descriptions will also show how the architecture fulfilsthe requirement specification.

The document is the basis on which the detailed design document will rely on.

Architecture document

Editor: Robert Johansson

Version: 1.2

Date: 2003-05-01

Linköping Institute of TechnologyDept. of Computer & Information SciencePUM-group 6

Architecture documentRobert Johansson2003-05-01 / v1.2The Shimpsons

ii



PROJECT IDENTITY

The ShimpsonsPUM-group 6, 2002 - 2003

Linköping Institute of TechnologyDepartment of Computer and Information Science (IDA)

Project members

Mailing list for the entire group

[email protected]

Homepage

http://www.lysator.liu.se/~lunkwill/pum6

Customer

Sony Ericsson Mobile Communications AB

Customer contact

Wanqing Shi, [email protected]

Sonia Sangari, [email protected]

Mentor

Mustapha Skhiri, [email protected]

Course responsible

Uwe Assman, [email protected]

Name Responsibility Telephone E-mail

Per Andersson Document responsible (DOK) 0733-742995 [email protected]

David Akhvlediani Implementation responsible (IMP) 013-4730999 [email protected]

Robert Johansson Design responsible (DES) 0705-382170 [email protected]

Lars Larsson Customer responsible (KUND) 0705-973390 [email protected]

Johan Marnetoft Quality responsible (KVAL) 0706-008442 [email protected]

Gustav Rosén Project leader (PL) 0701-754456 [email protected]

Mikael Svärd Test responsible (TEST) 0707-343272 [email protected]

Christoffer Årstrand System responsible (SYS) 0707-733934 [email protected]

PROJECT IDENTITY iii



iv



DOCUMENT HISTORY

Date Version Name Change

2003-02-06 0.1 Robert Johansson The making of this document (DES, IMP, DOC).

2003-02-25 0.2 Robert Johansson Update after scrutiny.

2003-03-01 0.3 Robert Johansson Update after opposition.

2003-03-03 1.0 Per Andersson Update after inspection.

2003-03-07 1.1 Robert Johansson Added gui call diagrams.

2003-05-01 1.2 Christoffer Årstrand Layout modified for HTML export.

DOCUMENT HISTORY v



vi DOCUMENT HISTORY



DOCUMENT HISTORY vii

viii DOCUMENT HISTORY





1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.1 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Document overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.3 Reading instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.4 System overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.4.1 Hardware and software requirements . . . . . . . . . . . 2

1.4.2 Data distribution and collection . . . . . . . . . . . . . . . . 2

1.5 Document dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.5.1 Documents that effect the architecture . . . . . . . . . . 3

1.5.2 Documents effected by the architecture . . . . . . . . . 3

1.6 Document distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.7 Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Architectural decisions. . . . . . . . . . . . . . . . . . . . . . . . 72.1 Desired properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1.1 Usability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1.2 Extensibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1.3 Modular structure . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2 Philosophy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.2.1 Make it simple . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.2.2 Make it right . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.2.3 Make it clean . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.2.4 Make it usable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.3 Modularization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.4 Testability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.5 Identifying modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.5.1 Choice and motivation . . . . . . . . . . . . . . . . . . . . . . . 9

2.5.2 Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.6 Layered approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.6.1 GUI layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.6.2 Action layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.6.3 Proxy layer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.6.4 API layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.7 Choice of design method. . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.7.1 Object Oriented Design . . . . . . . . . . . . . . . . . . . . . 11

2.7.2 Notation standard . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.8 Choice of development environment . . . . . . . . . . . . . . . . . 11

2.8.1 Modeling tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.8.2 Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.8.3 Development environment. . . . . . . . . . . . . . . . . . . 12

2.9 Project states . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3 Use cases. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.1 Subsystems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Table of contents ix



3.1.1 Project management . . . . . . . . . . . . . . . . . . . . . . . 13

3.1.2 Test management . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.1.3 Result management . . . . . . . . . . . . . . . . . . . . . . . . 13

3.1.4 Configuration management . . . . . . . . . . . . . . . . . . 13

3.2 Fulfilment of requirements . . . . . . . . . . . . . . . . . . . . . . . . . 14

4 Modules and layers . . . . . . . . . . . . . . . . . . . . . . . . . 174.1 GUI layer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.2 Action layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.2.1 Project Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.2.2 Project Builder . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4.2.3 Test Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4.2.4 Test Runner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4.2.5 Result Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4.2.6 Configuration Manager . . . . . . . . . . . . . . . . . . . . . . 18

4.3 Proxy layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.3.1 Storage Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.3.2 Sound API Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.3.3 Configuration Proxy . . . . . . . . . . . . . . . . . . . . . . . . 19

4.3.4 Result Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.4 API layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4.4.1 Java IO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4.4.2 Java Sound API: . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4.5 Layers overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.6 Dynamic aspect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

5 Graphical user interface . . . . . . . . . . . . . . . . . . . . . 235.1 Audio Jury Administrator. . . . . . . . . . . . . . . . . . . . . . . . . . . 23

5.1.1 Project manager . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

5.1.2 Project creator . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

5.1.3 Project renamer . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

5.1.4 Project deleter . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

5.1.5 Closed project deleter. . . . . . . . . . . . . . . . . . . . . . . 23

5.1.6 Project editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

5.1.7 Test creator. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

5.1.8 Test importer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

5.1.9 Test duplicator . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

5.1.10 Test deleter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

5.1.11 Test editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

5.1.12 Single selector . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

5.1.13 Pair selector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

5.2 Audio Jury Client. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

5.2.1 Project selector. . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

5.2.2 Project instructor. . . . . . . . . . . . . . . . . . . . . . . . . . . 24

x Table of contents



5.2.3 Data collector. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

5.2.4 Test instructor . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

5.2.5 Practice completion notifier . . . . . . . . . . . . . . . . . . 24

5.2.6 Interactive CCR rater . . . . . . . . . . . . . . . . . . . . . . . 25

5.2.7 Interactive ACR rater . . . . . . . . . . . . . . . . . . . . . . . 25

5.2.8 Automatic rater . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

5.2.9 Endorser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

5.2.10 Project completion notifier . . . . . . . . . . . . . . . . . . . 25

5.2.11 Interrupt notifier . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

6 Possible extensions . . . . . . . . . . . . . . . . . . . . . . . . . 276.1 Further development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

6.1.1 Custom scale creation. . . . . . . . . . . . . . . . . . . . . . 27

6.1.2 Built-in result preview . . . . . . . . . . . . . . . . . . . . . . 27

6.1.3 New test methods . . . . . . . . . . . . . . . . . . . . . . . . . 27

6.1.4 Advanced database. . . . . . . . . . . . . . . . . . . . . . . . 27

6.1.5 Remote client management. . . . . . . . . . . . . . . . . . 27

6.2 Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

7 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297.1 Internal documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

7.2 External documents. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Appendix A Activity diagrams . . . . . . . . . . . . . . . . . . . . . 1

Appendix B Low-Fi GUI prototype . . . . . . . . . . . . . . . . . 1

Appendix C GUI call diagrams . . . . . . . . . . . . . . . . . . . . 1

Table of contents xi



xii Table of contents



1 Introduction

This chapter gives the background to and the overview of the rest of thisdocument. Dependencies between this and other project documents arelisted and finally the terminology that has been used is explained.

1.1 PurposeThe purpose of this document is to give an overview of the structure of thesystem. The document describes and motivates what has been decidedregarding the architecture. The main components of the system are definedand the decisions that affect the architecture are dealt with.

1.2 Document overview

1. Introduction

Describes the structure and substance of the document.

2. Architectural decisions

Motivates and states the decisions made concerning the architecture. of thesystem

3. Use cases

Presents detailed use cases and shows how the architecture fulfils therequirements.

4. Modules and layers

Presents the identified modules and places them in layers.

5. Graphical user interface

Describes the graphical user interface.

6. Possible extensions

Shows how the design facilitates extension of the system.

Chapter 1: Introduction 1



1.3 Reading instructionsThe reader should get familiarized with the words listed in section 1.7. It isrecommended to have the requirement specification [Larsson, 2003] andthe design document [Johansson, 2003] at hand when reading. The wholedocument should be read to get a general overview of the architecture.

1.4 System overviewSee the requirement specification [Larsson, 2003] to get a functional over-view of the system.

1.4.1 Hardware and software requirements

The system will run on a regular PC with Windows XP or Windows 2000installed. The recommended requirements of Windows XP apply. In addi-tion a soundcard capable of playback at least 16 bits at 44 kHz ismandatory. Java Runtime Environment v1.4 should also be installed on thesystem.

1.4.2 Data distribution and collection

To transfer projects and results between the client and the administrationprogram either a windows network (”shared folder”), or any removablemedia with sufficient capacity can be used. Typically this will be CD-RWsor USB mass storage devices (i.e.ThumbDrive, USBstick and others).

Figure 1: Data distribution and collection

2 Chapter 1: Introduction



1.5 Document dependencies

1.5.1 Documents that effect the architecture• Requirement specification [Larsson, 2003]

Modification of the requirements can effect the architecture.

1.5.2 Documents effected by the architecture• Design specification [Johansson, 2003]

Modification of the architecture means major modifications of thedesign.

• Test documentation [Svärd, 2003]

Modification of the architecture might alter some of the test cases.

• Technical documentation [Akhvlediani, 2003]

Modification of the architecture effects the design which effects theimplementation. This means that the technical documentation needsalterations.

1.6 Document distributionThis document will be distributed to:

• The customer: Sony Ericsson Mobile Communications AB.

• The project group’s mentor and the examiner of this document: Mus-tapha Skhiri.

• The project file.

• The project web page.




1.7 GlossaryHere follows a definition list of terms and abbreviations that are usedthroughout this document:

Administrator A person who manages listening tests by using theadministrator part of the system.

Participant A person who takes listening tests by using the clientpart of the system.

Project A unit consisting of a set of tests and a number ofattributes.

Test (or listeningtest)

A set of judgements based on sounds.

Judgement A judgement is a sequence of events where a participantfirst listens to one or two sounds and then gives a ratingof the sounds on a certain scale.

ITU-T P.800 A set of recommendations for subjective determinationof transmisson quality issued by the telecommunicationstandardization sector of the International Telecommuni-cation Union (ITU). These recommendations includesthe methods described below, ACR, DCR, and CCR.

Processed sample A sound sample that has been processed, typically by atelecommunication system, in any way.

Unprocessed sample An original sound sample that has not been processed inany way. This is used as a reference when judging a pro-cessed version of the same sample.

Absolute CategoryRating (ACR)

A standardized method for subjective determination oftransmission quality. Used for judgements of one soundat a time, typically rated on a scale from one to five.

Degradation Cate-gory Rating (DCR)

A standardized method for subjective determination oftransmission quality. Used for judgements of pairs ofsounds, where one of the samples is unprocessed and theother has been processed in some degrading way. Thesounds are compared and the degradation of the pro-cessed sample is typically rated on a scale from one tofive.

Comparison Cate-gory Rating (CCR)

A standardized method for subjective determination oftransmission quality, similar to DCR. The difference isthat this method can assess sound processing that eitherdegrades or improves sound quality. The second soundsquality compared to the first sound is typically rated on ascale from minus three to three.

Paired comparisontest

Any test where each judgement is based on a comparisonof two different sounds at a time.

General pair test A general form of paired comparison test where you forexample can compare two completely different soundsby preference.




Completecomparison test

A paired comparison test where all possible combina-tions between the included sounds are judged.

Product The complete Audio Jury system. The system consists ofan administrator program and a client program.

Core The non-visible parts and components of the product.

Module A high level compound of several still unidentified Javaclasses.

View Rectangular area (window) on the screen that presentsinformation and action choices to the user. Only oneview can be visible and possible to interact with at atime. Typically a view has many interaction choices.

Dialog A smaller rectangular area which may in part cover aview. A dialog typically has limited interaction capabili-ties and only asks the user for some simple input or con-firmation.

API Acronym for ”Application Programming Interface”




2 Architectural decisions

This chapter describes and motivates the decisions that have been madeconcerning the architecture of the product.

First a description of the desired properties of the product will be pre-sented. These desired properties have influenced the choices made duringthe architectural work.

Next the philosophy of the design group is presented. This part will facili-tate future extensions of the product by catching ”the spirit” in which theoriginal design group has worked.

Then follows a description of how the different parts of the product havebeen divided into modules and how testability will be achieved.

After that the methodology that will be used in the detailed design is pre-sented.

In section 2.8, the choice of development environment is presented andmotivated.

Finally, the project states of the administration program are explained.

2.1 Desired properties

2.1.1 Usability

The product consists of two programs: one administrator program and oneclient program, also see the requirement specification[Larsson, 2003]. In thecase of the administrator program the user is expected to be an expert userwith good knowledge in designing audio tests and using tools for doingthat. In contrast, the user of the client program will typically have averageor below average skills in interacting with a computer. Therefore, when itcomes to the GUI design, the focus will be slightly different in the two pro-grams.

The administrator program has to be fast and efficient to work with,whereas the client must be very intuitive and additionally offer help to theuser where needed.

2.1.2 Extensibility

The customer has wishes for the system which cannot be accomplishedwithin this projects’ time and resource constrains. Also some wishes are outof the scope of the product. Therefore the architecture must allow the prod-uct to be extended and, in cases where extension is inappropriate, to exportdata to external applications which can satisfy those wishes.

2.1.3 Modular structure

To be able to perform the detailed design and implementation in a timeframe as short as possible, different tasks must be performed in parallel.This is why modular structure will be strived for in the architecture. Byidentifying independent modules in the architecture of the product, tasksin design and implementation phases can be performed concurrently byproject members.

Chapter 2: Architectural decisions 7



2.2 PhilosophyThis section will describe the philosophy of the design group. The philoso-phy is the most general idea of how software should be created and thedesign group regards it as a set of fundamental guidelines which lie on aeven more general level than design patterns, and influence the choice ofthe latter. These guidelines will hopefully propagate as a red line through-out the architecture, detailed design and finally implementation of theproduct. The philosophy is provided as a help in catching the originaldesign group’s ideas and ”thinking right” when the product will beextended in the future.

In short - this is the ”spirit” that the design group has worked in.

For each guideline there is an example of how it has been applied in thecreation of Audio Jury.

2.2.1 Make it simple

Solutions should be simple and robust. Also, each component in the prod-uct should have a limited and well-defined purpose. A part which has toomany functions should be broken down in smaller parts.

Application: The user interface and core parts of the programs of AudioJury have been separated. Classes will be very small in the detailed design.

2.2.2 Make it right

Even though each part may be simple, it shall carry out it’s task well. Alsothere should be no doubt that its functionality can easily be tested and veri-fied.

Application: Modules will be broken down further in the detailed design.

2.2.3 Make it clean

The focus should be on uniqueness, meaning that the product should con-tain only functionality that is unique and central for fulfilling its purpose.Additional features should be performed by external programs.

Application: The core purpose of Audio Jury is to create and perform audiotests. Features such as statistical analysis of test results should be per-formed by exporting results to a format readable by programs that performsuch analysis.

2.2.4 Make it usable

Software that is aimed towards end-users should also be designed withtheir expected level of knowledge and skill in mind. Prototyping and eval-uation of user interfaces is a must.

Application: The user interface of the two different programs of have beendesigned and evaluated separately. See section 2.1.1.

8 Chapter 2: Architectural decisions



2.3 ModularizationThe reasons for modularizing the product are to:

• simplify the detailed design by making major decisions early

• simplify testing

• prepare for future extensions of the product

• enable independent design and implementation tasks to be performedconcurrently

2.4 TestabilityTo simplify the work of testing, the modules identified and described inchapter 4 will be split down into well delimited classes as described in thedesign specification [Johansson, 2003]. Each class will be minimally depen-dent on other modules. This will enable each class to be tested separately.

2.5 Identifying modulesOne step towards detailed design on a class level, is having a clear generalview. To obtain this view the product has been split in main modules.

2.5.1 Choice and motivation

”The use case view doesn’t really specify the organization of a softwaresystem. Rather, it exists to specify the forces that shape the system’s archi-tecture.” [Booch et al., 1999]

We have used a use case driven method for identifying modules.

This was a natural choice since the use cases and requirements were verywell specified by the customer, see requirement specification [Larsson,2003]. Also a user interface study had been done which further facilitatedthe identification process. Use cases greatly helped us in understanding thesystem. In our case the process of going from use cases to modules waspainless and natural.

2.5.2 Process

The architecture design process started with grouping use cases that speci-fied functional requirements of the system into functional groups.

A group may represent a subsystem with a particular set of responsibilitiesfor the users, in our case for the administrator and the test participant.

The system, before the architecture design, could be viewed as a black box.It has a particular shape seen from outside but nothing is known about itsinternal composition. The internal components and their relations hadsomehow to be deduced. Use cases were the perfect starting point of look-ing into the black box, as most of them were known from the requirements.

1. First the use cases were grouped according to their functions. Thisrevealed major high-level subsystems.

2. Each subsystem was broken down into a set of modules.3. The relations between the modules were fixed. This gave new insight

and sometimes the need to go back to step 2 again and reconsider.




2.6 Layered approachIn order to increase reusability and independence further the identifiedmodules have been placed in different layers. The idea is that a layershould only rely upon the layer below.

Figure 2: Layers

2.6.1 GUI layer

This is where the user interface is located. This layer contains no functional-ity of its own. It is event driven and responds to user input. The input istranslated into calls to the action layer.

2.6.2 Action layer

This is the core of the two programs. All the functionality, logic, algorithms,i e ”smart behavior” is located here.

2.6.3 Proxy layer

This layer works as a proxy between the action layer and the API layer. Thelayer is very thin and has no functionality of it’s own. It’s only purpose is totranslate storage requests and playback requests from the action level intocalls to the API layer.

If, in the future, other storage or playback solutions are preferred, this is theonly layer that would have to be rewritten. Thus keeping the rest of thecode intact.

2.6.4 API layer

This layer is simply the Java API.




2.7 Choice of design methodObject Oriented Design will be used as design method. The motivation ofthis choice follows.

2.7.1 Object Oriented Design

The product has properties which makes Object Oriented Design (OOD) asuitable choice. It has abstract concepts such as ”project”, ”test” and”judgement” which are well delimited. There are dependencies among theconcepts and for each concept there is a number of operations that can beperformed upon it.

2.7.2 Notation standard

UML was chosen as notation standard due to the object oriented propertiesdiscussed in section 2.7.1

2.8 Choice of development environment

2.8.1 Modeling tool

Rational Rose will be used for modeling classes in the detailed design.

With Rational Rose it is easy to model classes using UML. The models canthen be used to generate Java code skeletons. These code skeletons willmake up the starting point in the implementation.

2.8.2 Platform

Java2 v1.4 was chosen as platform. The motivation of this choice follows:

Limited time

There is limited time for implementation. By using Java the implementa-tion will not be delayed by debugging dangling pointers and other artifactsthat languages as C and C++ suffer from.

Class library

Java has an extensive class library provided as default. This will reduceimplementation time since the implementation group will not have to”reinvent the wheel”, but rather use existing functionality.

Also further extension of the product is facilitated by the class library.

Group knowledge

The implementation group has better knowledge of and experience withJava than other high-level languages (i e C++ and C#). No or very little timewill be spent on education.

User interfaces

The Java platform supports creation of user interfaces. This functionality iswidely used and well tested.




2.8.3 Development environment

Sun ONE Studio was chosen as development environment. The motivationof this choice follows.

Project overview

Sun ONE Studio allows easy overview of written classes and their methodsand variables.

Code completion

The code editor has code completion, which minimizes time spent on look-ing up information in the Java API documentation.

Integrated debugger

A very competent debugger is included in Sun ONE Studio. It allows stepexecution of the code and provides detailed inspection of variables.

Creation of user interfaces

Sun ONE Studio provides functionality for creating good looking userinterfaces with little effort.

License and budget

The license of Sun ONE Studio permits the type of usage and developmentmodel that the product is subject to. Other development environment soft-ware such as Borland JBuilder either have a more restrictive license or havehigh licensing costs.

2.9 Project statesDuring the process of creating a graphical user interface the design groupcame to deeper insight of possible architectural solutions.

The need for separating projects based on some kind of state was identi-fied. This is also reflected in the user interface. See section 2.1.1 and Appen-dix B. The possible states of a project are:

• Dynamic state

• Active state

• Closed state

For a description of the semantics of the states see the design specification[Johansson, 2003].




3 Use cases

This chapter contains detailed use cases. These use cases are expansions ofthe use case presented in the requirement specification [Larsson, 2003].First a brief overview, then use case diagrams follow.

Use cases will help developers to come to a common understanding of thesystem. Use cases not only represent the desired behavior, but they can alsobe used as the basis of test cases of system components.

The use cases also capture the functional requirements of the system. Thearchitecture must support the functional requirements and therefore it isimportant to have a good understanding of what is required.

3.1 SubsystemsThe use cases of Audio Jury have been divided into the following groups,each of them representing a high level subsystem.

3.1.1 Project management

This subsystem deals with the project creation, modification, status change,project running, generation, etc.

3.1.2 Test management

This subsystem’s responsibilities are to create tests, edit tests, run tests, etc.

3.1.3 Result management

This subsystem performs import of results that were generated in the clientwhile running a test, result viewing, deletion and export to a portable textformat for further statistical analysis.

3.1.4 Configuration management

This subsystem’s responsibility is to create, save and retrieve system con-figuration information.

Figure 3: Subsystems and modules at Action Layer

Chapter 3: Use cases 13



3.2 Fulfilment of requirementsThe following use case diagrams contain references to reqirements in therequirements specification. They explicitly state in which subsystem andmodule of the action layer the respective requirement will be fulfilled.

Figure 4: Project Manager use cases and requirements

14 Chapter 3: Use cases



Figure 5: Test Manager use cases and requirements

Figure 6: Result Manager use cases and requirements

Chapter 3: Use cases 15



Figure 7: Configuraion Manager use cases and requirements

16 Chapter 3: Use cases



4 Modules and layers

This chapter gives a description of the identified modules and their pur-pose.

4.1 GUI layerThere is only one module in the GUI layer. This module only communi-cates with the modules in the action layer. In the design specification[Johansson, 2003], a number of classes representing the screens in appendixB will be identified.

4.2 Action layerThe action layer is the core of Audio Jury. It is here that almost all require-ments 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, EditProject, Save Project, Delete Project, Activate Project, Close Project, Dupli-cate Project and Run Project.

ProjectManager also communicates with Result Manager when results areto be imported.

Accessed by: GUI.

Chapter 4: Modules and layers 17



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

4.2.2 Project Builder

This module operates on a single project. It contains operations for editingand 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, editand 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 andalso to collect test results during the test. When the test is finished resultsare passed to Result Manager.

When the whole project is finished all results from all tests in the project aresaved 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 beingrun. When the project is finished Result Manager will pass all results fromthe 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 configu-ration for both administrator and client programs.

Configuration settings include project paths, result paths, user definedscales, etc.

Physical implementation, how and where to store configuration informa-tion, is delegated to Configuration Proxy module. It provides a service forthe proxy level modules Storage Proxy and Result Proxy, when they needconfiguration information.

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

Depends on: Configuration Proxy.

18 Chapter 4: Modules and layers



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 storingprojects 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 forplaying sounds. It does not implement the sound playing function, rather itjust provides an interface. It relies on sound playing functionality in theAPI layer.

Accessed by: Test Runner.

Depends on: Java Sound API.

4.3.3 Configuration Proxy

This module implements the configuration access and storage functional-ity.

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 anycode here.

4.4.1 Java IO

This module provides system input and output through data streams, seri-alization 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 playingback audio data.

Accessed by: Test Runner.

Depends on: None.




4.5 Layers overviewThe connections between layers and the dependencies between modulesdescribed in sections 4.1 - 4.4 will below be shown graphically.

Figure 11: Administrator layer overview




Figure 12: Client layer overview

4.6 Dynamic aspectUse case and module diagrams presented in chapter 3 and sections 4.1 - 4.5show the static aspects of the system. Modules are not static components,they interact with one another, accomplishing a particular use case. Dia-grams, that show how modules communicate, help more clearly under-standing responsibilities of the modules and will be used during the designphase.

Activity diagrams have been chosen as method to represent communica-tion between modules. Interaction diagrams will be used in the design toshow interaction between objects.

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

The diagrams can be found in appendix A.




5 Graphical user interface

This chapter gives a textual description of the graphical user interface.

The most important views and dialogs of the administrator and client partwill be named and their purpose presented in short. Standard dialogs suchas save dialogs will not be described.

See appendix B for the low-fi paper prototype. Appendix C describes howand by which actions (mouse clicks) the views and dialogs in appendix Bcan be reached from eachother.

5.1 Audio Jury Administrator

5.1.1 Project manager

When the administrator starts the administrator program, this is the firstview he gets to. The project manager gives an instant overview of whichprojects are in which state, also see section 2.9, "Project states", on page 12.

5.1.2 Project creator

This is a simple dialog asking the user to input the name of the project to becreated.

5.1.3 Project renamer

This dialog asks the user to assign a new name to an existing project.

5.1.4 Project deleter

This dialog warns the user when he tries to delete a project under develop-ment. The dialog asks for confirmation.

5.1.5 Closed project deleter

This dialog warns the user when he tries to delete a closed project. The dia-log asks for confirmation.

5.1.6 Project editor

From this view it is possible to add and remove tests from a project. Theuser can also set properties that are general to the project as a whole.

5.1.7 Test creator

This dialog asks the user to input the name of a newly created test. Also theuser must select what kind of test method to use. The test can be one ofthose described in the standard ITU-T P.800 or any other implemented test.

5.1.8 Test importer

This dialog will present to the user a hierarchical browser which containsall dynamic projects and their respective tests. The user will be able toselect a test to import in the current project.

Chapter 5: Graphical user interface 23



5.1.9 Test duplicator

When the user chooses to duplicate a test this dialog will ask which nameto assign to the copy.

5.1.10 Test deleter

This dialog warns the user when he tries to delete a test from the project.The dialog asks for confirmation.

5.1.11 Test editor

From this view it is possible to edit all aspects of a test. The view also givesan overview of the test currently being edited.

5.1.12 Single selector

In this dialog the user can choose a sound file for a single sound judgement(i e ACR).

5.1.13 Pair selector

In this dialog the user will choose two different sounds that will be used ina paired comparison (i e CCR, DCR etc.).

5.2 Audio Jury Client

5.2.1 Project selector

This dialog shows a list of active projects and enables the user to selectwhich one to run.

5.2.2 Project instructor

The user will get a textual or an audible instruction for the current project.This instruction was entered by the administrator in view section 5.1.6,"Project editor".

5.2.3 Data collector

Here the user is asked to enter data requested. The selection of which datato collect is done in view section 5.1.6, "Project editor".

5.2.4 Test instructor

This dialog gives a textual or an audible instruction for the current test.This instruction was entered by the administrator in the view section 5.1.11,"Test editor".

5.2.5 Practice completion notifier

This dialog notifies the user that the practice test is over and that the realtests will start.

24 Chapter 5: Graphical user interface



5.2.6 Interactive CCR rater

This dialog displays the form for an interactive CCR test. The user canselect sounds to play and rate them.

5.2.7 Interactive ACR rater

This dialog displays the form for an interactive ACR test. The user canselect sounds to play and rate them.

5.2.8 Automatic rater

This dialog has the same basic look regardless of which kind of automatictest is taken. One or two sounds (depending on test method) are playedonce and the user will have to rate the sound(s) before going to the nextjudgement.

5.2.9 Endorser

This dialog displays an affirmative and encouraging text that tells the userthat a test has been completed.

5.2.10 Project completion notifier

This dialog tells the user that all tests have been completed and thanks forhis/her participation.

5.2.11 Interrupt notifier

This dialog pops up if the user at any point chooses to interrupt the test. Anotification is showed and the user is asked to confirm the action.

Chapter 5: Graphical user interface 25



26 Chapter 5: Graphical user interface



6 Possible extensions

The chosen architecture facilitates and allows further development andextension of the product without requiring major architectural changes,which was one of the goals of the architecture.

6.1 Further developmentAs an example of how the system could further be developed, a number ofpossible extensions are listed together with a suggestion of which moduleswould have to be altered or added. To really show how extensible the archi-tecture is, some examples are purely results of wild imagination and are noteven marked as extra in the requirements specification [Larsson, 2003].

6.1.1 Custom scale creation

It might be useful for the administrator to create his/her own scales.

With little effort a GUI for editing scales could be written. TheConfigurationManager and the TestRunner would have to be expanded.Also an additional GUI component would have to be created.

6.1.2 Built-in result preview

The administrator may want to preview results before exporting them.

This would require a new GUI component as well as a new module in theaction level. This module would use functionality from ResultManager.

6.1.3 New test methods

The need for new test methods could arise.

TestRunner would have to be expanded and some additional GUI compo-nent, in both the administrator and client parts would have to be written.

6.1.4 Advanced database

It might be useful to let the test results and projects be managed by a gen-eral DBMS such as MySQL instead of the built in one.

The ResultProxy would have to be rewritten for saving results into aDBMS. The StorageProxy would have to be rewritten for saving projectsand tests into a DBMS.

6.1.5 Remote client management

The administrator and clients could be extended so that an administratorcould instruct a number of clients to start a specific project remotely.

This could be achieved by adding a communication module in the proxylevel and some functionality.

Chapter 6: Possible extensions 27



6.2 MaintenanceThe architecture facilitates maintenance by being clear and having wellnamed modules. This helps to quickly get a good picture of the system.Also section 2.2, "Philosophy", on page 8 will further speed up the processof getting familliar with the architecture.

For locating errors, reading of chapters 3, "Use cases" and 4, "Modules andlayers" is highly recommended.

28 Chapter 6: Possible extensions



7 References

7.1 Internal documents[Larsson, 2003] Larsson, Lars, (2003), Requirement specification, Departmentof Computer and Information Science (IDA), Linköping University,Linköping.

[Johansson, 2003] Johansson, Robert, (2003), Design specification,Departmentof Computer and Information Science (IDA), Linköping University,Linköping.

[Svärd, 2003] Svärd, Mikael, (2003), Test documentation,Department ofComputer and Information Science (IDA), Linköping University,Linköping.

[Akhvlediani, 2003] Akhvlediani, David, (2003), Technical documentation,Department of Computer and Information Science (IDA), LinköpingUniversity, Linköping.

7.2 External documents[Booch et al., 1999] Grady Booch, James Rumbaugh, Ivar Jacobsson, (1999),”The Unified Modeling Language User Guide”, Addison Wesley.

Chapter 7: References 29



30 Chapter 7: References



Appendix A Activity diagrams

A.1 Create/edit project - Activity diagram

Appendix A: Activity diagrams 1



A.2 Create/edit test - Activity diagram

2 Appendix A: Activity diagrams



A.3 Run project - Activity diagram

Appendix A: Activity diagrams 3



A.4 Run test - Activity diagram

4 Appendix A: Activity diagrams



Appendix B Low-Fi GUI prototype

B.1 Project manager

Appendix B: Low-Fi GUI prototype 1



B.2 Project manager actions

2 Appendix B: Low-Fi GUI prototype



B.3 Project editor




B.4 Test creator




B.5 Project editor actions




B.6 Test editor




B.7 Single selector




B.8 Pair selector




B.9 Project selector




B.10 Project instructor




B.11 Data collector and test instructor




B.12 Notifiers, automatic rater and endorser




B.13 Raters and project completion notifier




Appendix C GUI call diagrams

C.1 Administrator

Project manager

Project editor

Test editor

Project creator

Test creator

Project renamer

Project deleter

Closed projectdeleter

Test importer Test deleter

Pair selector

Single selector

Test duplicator

New

New

Ok

Ok

Delete (Closed)

Delete (Under constr.)

Rename

Add (Paired comparison)

Add

Duplicate

DeleteImport

Appendix C: GUI call diagrams 1



C.2 Client

Start

Project selector

Project instructor

Data collector

Test instructor

Automatic rater Interactive CCRrater

Interactive ACRrater

Practice completionnotifier

Automatic rater Interactive CCRrater

Interactive ACRrater

Endorser

Project completionnotifier

Interrupt notifier

Continue

Continue Continue

Continue

Continue Continue

Continue

Continue

Start test

Start testStart test

Start practice

Start practiceStart practice

Interrupt

Yes

Done

Continue

2 Appendix C: GUI call diagrams



A

abstract concepts ......................................................11

activity diagrams ..................................................... 22

C

C .....................................................................................11

C# ...................................................................................11

C++ ...............................................................................11

clean ............................................................................... 8

code completion ...................................................... 12

D

DBMS .......................................................................... 27

debugger .................................................................... 12

design philosophy ..................................................... 8

E

errors ........................................................................... 28

G

glossary ......................................................................... 4

graphical user interface ......................................... 23

guidelines ..................................................................... 8

I

ITU-T P.800 .................................................................. 4

J

Java2 .............................................................................11

JBuilder ....................................................................... 12

L

layers ........................................................................... 10

license .......................................................................... 12

M

mass storage devices ................................................ 2

modules ...................................................................... 17

MySQL ........................................................................ 27

P

platform .......................................................................11

preview results ......................................................... 27

R

Rational Rose .............................................................11

S

scales ............................................................................27

shared folder ................................................................2

smart behavior ..........................................................10

Sony Ericsson Mobile Communications AB .....3

soundcard .....................................................................2

step execution ............................................................12

subsystem ...................................................................13

Sun ONE Studio .......................................................12

T

transfer ...........................................................................2

U

UML .............................................................................11

W

Windows .......................................................................2

Index 1



2 Index

Version: 1.2 Date: 2003-05-01 - LiU

Documents

Transcript of Version: 1.2 Date: 2003-05-01 - LiU