| |
|
|
|
This chapter describes and motivates the decisions that have been made concerning the architecture of the product.
First a description of the desired properties of the product will be presented. These desired properties have influenced the choices made during the architectural work.
Next the philosophy of the design group is presented. This part will facilitate future extensions of the product by catching "the spirit" in which the original design group has worked.
Then follows a description of how the different parts of the product have been divided into modules and how testability will be achieved.
The product consists of two programs: one administrator program and one client program, also see the requirement specification[Larsson, 2003]. In the case of the administrator program the user is expected to be an expert user with good knowledge in designing audio tests and using tools for doing that. In contrast, the user of the client program will typically have average or below average skills in interacting with a computer. Therefore, when it comes to the GUI design, the focus will be slightly different in the two programs.
The administrator program has to be fast and efficient to work with, whereas the client must be very intuitive and additionally offer help to the user where needed.
The customer has wishes for the system which cannot be accomplished within this projects' time and resource constrains. Also some wishes are out of the scope of the product. Therefore the architecture must allow the product to be extended and, in cases where extension is inappropriate, to export data to external applications which can satisfy those wishes.
To be able to perform the detailed design and implementation in a time frame as short as possible, different tasks must be performed in parallel. This is why modular structure will be strived for in the architecture. By identifying independent modules in the architecture of the product, tasks in design and implementation phases can be performed concurrently by project members.
This section will describe the philosophy of the design group. The philosophy is the most general idea of how software should be created and the design group regards it as a set of fundamental guidelines which lie on a even more general level than design patterns, and influence the choice of the latter. These guidelines will hopefully propagate as a red line throughout the architecture, detailed design and finally implementation of the product. The philosophy is provided as a help in catching the original design group's ideas and "thinking right" when the product will be extended in the future.
Solutions should be simple and robust. Also, each component in the product should have a limited and well-defined purpose. A part which has too many functions should be broken down in smaller parts.
Application: The user interface and core parts of the programs of Audio Jury have been separated. Classes will be very small in the detailed design.
Even though each part may be simple, it shall carry out it's task well. Also there should be no doubt that its functionality can easily be tested and verified.
The focus should be on uniqueness, meaning that the product should contain 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 audio tests. Features such as statistical analysis of test results should be performed by exporting results to a format readable by programs that perform such analysis.
Software that is aimed towards end-users should also be designed with their expected level of knowledge and skill in mind. Prototyping and evaluation of user interfaces is a must.
Application: The user interface of the two different programs of have been designed and evaluated separately. See section 2.1.1.
To simplify the work of testing, the modules identified and described in chapter 4 will be split down into well delimited classes as described in the design specification [Johansson, 2003]. Each class will be minimally dependent on other modules. This will enable each class to be tested separately.
One step towards detailed design on a class level, is having a clear general view. To obtain this view the product has been split in main modules.
"The use case view doesn't really specify the organization of a software system. Rather, it exists to specify the forces that shape the system's architecture." [Booch et al., 1999]
This was a natural choice since the use cases and requirements were very well specified by the customer, see requirement specification [Larsson, 2003]. Also a user interface study had been done which further facilitated the identification process. Use cases greatly helped us in understanding the system. In our case the process of going from use cases to modules was painless and natural.
The architecture design process started with grouping use cases that specified functional requirements of the system into functional groups.
A group may represent a subsystem with a particular set of responsibilities for 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 its internal composition. The internal components and their relations had somehow to be deduced. Use cases were the perfect starting point of looking into the black box, as most of them were known from the requirements.
1. First the use cases were grouped according to their functions. This revealed major high-level subsystems.
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.
In order to increase reusability and independence further the identified modules have been placed in different layers. The idea is that a layer should only rely upon the layer below.
This is where the user interface is located. This layer contains no functionality of its own. It is event driven and responds to user input. The input is translated into calls to the action layer.
This is the core of the two programs. All the functionality, logic, algorithms, i e "smart behavior" is located here.
This layer works as a proxy between the action layer and the API layer. The layer is very thin and has no functionality of it's own. It's only purpose is to translate storage requests and playback requests from the action level into calls to the API layer.
If, in the future, other storage or playback solutions are preferred, this is the only layer that would have to be rewritten. Thus keeping the rest of the code intact.
The product has properties which makes Object Oriented Design (OOD) a suitable choice. It has abstract concepts such as "project", "test" and "judgement" which are well delimited. There are dependencies among the concepts and for each concept there is a number of operations that can be performed upon it.
UML was chosen as notation standard due to the object oriented properties discussed in section 2.7.1
With Rational Rose it is easy to model classes using UML. The models can then be used to generate Java code skeletons. These code skeletons will make up the starting point in the implementation.
There is limited time for implementation. By using Java the implementation will not be delayed by debugging dangling pointers and other artifacts that languages as C and C++ suffer from.
Java has an extensive class library provided as default. This will reduce implementation time since the implementation group will not have to "reinvent the wheel", but rather use existing functionality.
The implementation group has better knowledge of and experience with Java than other high-level languages (i e C++ and C#). No or very little time will be spent on education.
The Java platform supports creation of user interfaces. This functionality is widely used and well tested.
The code editor has code completion, which minimizes time spent on looking up information in the Java API documentation.
A very competent debugger is included in Sun ONE Studio. It allows step execution of the code and provides detailed inspection of variables.
The license of Sun ONE Studio permits the type of usage and development model that the product is subject to. Other development environment software such as Borland JBuilder either have a more restrictive license or have high licensing costs.
During the process of creating a graphical user interface the design group came to deeper insight of possible architectural solutions.
The need for separating projects based on some kind of state was identified. This is also reflected in the user interface. See section 2.1.1 and Appendix B. The possible states of a project are:
 Quadralay Corporation http://www.webworks.com Voice: (512) 719-3399 Fax: (512) 719-3606 sales@webworks.com |
| |
|
|