Basic use cases

From the scenario, we can derive use cases which represents the core functionality of the system. In the use cases we try to describe what the system should do for the user to achieve particular goals. Figure 8.1 shows a graphical representation of the different use cases identified. We also elaborate the most important use cases by using textual representations (UC1-4).

Figure 8.1: All use cases.

UC1: Create project and Import/Calibrate Data

1. To be able to start the analysis, the user needs start a blank session (analogue to creating a blank document in MS Word).

2. The system shall then present to the user a blank work session and an op-portunity to import a set of sensor data.

3. The user then decides which data to import

4. The system shall then import the data and eventually notify the user when the process is complete.

5. To be able to view the data in meaningful context, the user needs select a way to calibrate the input data.

6. The system shall then present to the user an opportunity to set specific calibration polynomials for each channel.

UC2: Create layout

1. As the analysis processes are based on having different visualization compo-nents on the screen in some layout, the user needs to create a new layout to work on.

2. The system shall then add to the project a blank sheet to work on.

UC3: Create visualization and Configure Visualization

1. To be able to analyze the speed trace, the user needs to create a line chart visualization and configure it to show the desired graph.

2. The system shall then place a line chart in the current visualization layout which responds to customizations done by the user.

UC4: Save Layout and Load Layout

1. To be able to re-use a layout that may have taken a lot of time and effort to create, the user needs to store the layout with its configurations.

2. The system shall then store the layout to a persistent file system.

3. To re-use previously created layouts the user needs to load these into new projects.

4. The system shall then load the desired layout from the persistent file system and display it using the data channels in the current project.

8.5. SCENARIO AND USE CASES 55

UC5: Save Project and Load Project

1. To be able to continue working with a dataset and a set of visualization layouts at a later time, the user needs to store the entire session with its configurations.

2. The system shall then store the current work session to a persistent file system.

3. To re-use the previously stored work session, the user needs to load this from the file system.

4. The system shall then load the desired work session from the file system and display it in the graphical user interface.

Chapter 9

Design phase introduction

In this chapter we discuss important decisions made early in the design phase. First off we explain the chosen design process. Second we decide which architectural viewpoints to use as architectural documentation, and at last we go through the quality focus and design issues for the software design.

9.1 Process

It is crucial to have a systematic approach to the design process to achieve good results later in the project. Every aspect of system requirements needs to be considered, and the architecture must be documented in an unambiguous way.

Many generic approaches to developing an architecture are suggested in textbooks and publications, but these are commonly modified to accommodate specific de-velopment team and project needs. Here we describe how we chose to approach the problem in this particular project using a custom set of techniques we found suitable.

Environment description We first combine prestudy knowledge and require-ment specification to define a physical view. This view describes the world the software is suppose to interact with.

User interface and conceptual model In these steps we try to conceptualize the user needs and desires for the system into a user perspective model and a graphical user interface. This step is somewhat inspired by affordance based design [22]; focusing on how the application should look from the user’s perspective and the actual use of the it. The term affordance was originally introduced by Gibson [23, 24]. An affordance is an actionable property of a thing (usually a tangible object, like a software system). Naturally, designing

57

objects with as few negative, and as many positive affordances as possible is desired.

Module Overview Focus is then shifted onto the developers’ perspective, de-scribing high level architecture. The system is divided into separate modules, each representing some functionality. We focus on giving a short graphical description of how these modules interact, and a short textual rationale for each module. How should the architecture look? How should the software be structured? These questions will be answered in this section.

Low level architecture Modules are then designed in detail, and class chart and sequence diagrams are used to demonstrate how the architecture is intended to work. The class charts give an overview of the classes used to realize each module, and the sequence diagrams show how the architecture are used to realize the basic use cases developed earlier in the process. Questions asked here are e.g. what design patterns can be used?

Architecture summary Lastly, we go through the architecture with respect to the different quality focuses and design issues stated in section 9.3, to clarify the strategies used to address each of these. This process does not only serve to produce an overview for the documentation, but will also help us detect deficiencies in the architecture.