The purpose of creating use cases is to identify in more detail the functionality required of the application, and how this functionality is used to solve specific tasks. All actions in the application have been described which has resulted in 52 use cases. The use cases are divided into 4 areas: circuit, operators panel, train and administration as listed in table3.1to 3.4.
The details for each use case can be seen in appendix E.
Several fields generally used in use cases have been delimited from the use case template used in this thesis. The reason for excluding the fields is either because the value of the field is the same for all use cases, or simply because the field is evaluated as having no relevance pursuant to this project. The more detailed reasons are as follows:
Scope The scope field describes which system is considered black box. Since all use cases are started by a user’s actions, and no other systems or actors are involved, the scope would always be the application it self.
Post condition The field ”Post condition” has been replaced by the field
”Suc-3.3 Use cases 33
24 Set spare filament non-conducting
25 Repair relay
Table 3.1: Use cases for the circuit.
34 Analysis
Use case # Name
34 Add track section
35 Add point
36 Assemble track sections/points
37 Occupy track section
38 Free track section
39 Occupy point
40 Free point
41 Switch point
Table 3.2: Use cases for the operators panel.
Use case # Name
42 Start train
43 Occupy next track section 44 Free rear track section
45 Cancel train
Table 3.3: Use cases for the train.
Use case # Name
46 Create project
47 Create diagram
48 Create operators panel
49 Save project
50 Load project
51 Reset station
52 Rename diagram
Table 3.4: Use cases for application administration.
3.3 Use cases 35
cess end condition”, since they are evaluated as having the same meaning.
Failed end condition The field ”Failed end condition” has not been included in the template since a failed end condition always is the inverse of ”Success end condition”. Furthermore the negative scenarios are described in detail under the ”Extensions”-description in the use case template.
Primary actors The field is excluded since there is only one primary actor and hence one primary user of the application, i.e. the personnel at Banedan-mark.
Secondary actors Secondary actors specify other systems required for the spe-cific use case. Since the application does not interact with other systems, the field would be empty.
Trigger Since the usage pattern is quite simple, it will always be the user’s wish to perform an action that triggers a use case.
Performance The performance field describes how time-consuming a task of a use case is on a system. All tasks described in the use cases are expected to be performed ”at once”.
Frequency The frequency field describes how often an action is expected to be performed. The frequency of the use cases is not significantly different and hence the field is excluded.
36 Analysis
Chapter 4
Design
In the following sections, the design of the application will be described. First general design issues will be resolved, whereafter the different parts of the ap-plication will be designed separately.
4.1 General issues
In the analysis the entities and functions of the domain were found. The enti-ties and functions can be used to describe the functionality of the interlocking system. This is an important issue when deciding which type of programming language to use for the application. Entities can be mapped into objects and functions into methods in an object-oriented programming language. For this reason we have chosen to use an object-oriented programming language for the application.
4.1.1 Application architecture
As mentioned in the analysis it is a requirement that the application includes a GUI through which the state of the electrical circuit and the rest of the
in-38 Design
terlocking system can be observed and the operators panel can be operated.
Furthermore the application is not meant to be used across a network but in an environment comprised by a single computer. This sets the state for choos-ing the model-view-controller (MVC) architectural pattern which is graphically illustrated in figure 4.1. The idea of this pattern is that the model layer only
Figure 4.1: The composition of the model-view-controller architectural pattern.
knows about its own existence and takes care of the calculations and data stor-age of the application. In addition to this is aview layer that knows about the model layer. This layer is used to graphically display the information stored in the model and to collect events from the model and the user interacting with the application. The final layer is thecontroller layer which processes and responds to events created either by the user or internally in the application. These events can cause the controller to invoke changes in the model and/or view layers.
We have chosen to use a slightly different pattern which joins the view and controller layers into one; the presentation layer. This layer then takes care of displaying the information given in the model, listening for events created by the user or model and responding to these events.
In this application it is necessary for the presentation layer to always reflect the current state of the model, i.e. when a relay is being drawn it should immediately be displayed. A way for this to happen is to use theobserver pattern. The idea behind this is that the GUI – or every GUI, in the case that more GUIs are used on the same model – is registered within the model as an observer. When the model experiences an internal change it invokes some predefined methods on all registered observers.
Again, in this application only one GUI is used and all changes made in the model are caused by actions triggered by the GUI. This makes the models knowledge of the GUI redundant. Instead the GUI just needs to look for changes in the model every time a method in the model is invoked by the GUI.
Another aspect is what should happen when errors are encountered within the
4.1 General issues 39
model as a result of faulty input from the GUI or user. When not using the observer pattern it can be handled by using return values and/or throwing exceptions to the GUI. This option has been chosen for the application.
In general the model is designed without considering how the presentation layer is functioning. It is an advantage that the presentation layer can be replaced without having to change the core functionality.
Likewise it has to be determined whether the creation of model layer components (relays, buttons, fuses, lamps, resistors, points and track sections) should occur only within the model or anywhere in the application. The advantage of creating the objects in the presentation is that whereever possible only objects are passed on and not simple variables. But a draw bag is that it is harder for the model layer to control when different objects are initialized and how they are treated before being added to the model layer – if ever. By always initializing the components in the model, it is not possible for the presentation layer to blindly use a component that is unknown to the model layer. For these reasons all components are created within the model layer and afterwards passed on to the presentation layer as desired.
4.1.2 Division of entities
There are several entities in the domain. A structuring of these entities will give an overview and a better design. The entities can be divided into different groups sorted by a number of criteria, the question is which criteria will give a reasonable design. The design chosen here is made in accordance with the real world. There seems to be two different areas, the circuit consisting of connected electrical components, and the physical components on a station, accessible to the outside world. When the entities are divided in accordance with this perception, we get the following groups:
1. Circuit (g) Steel core coil pins
40 Design
According to the domain the button is placed on the operators panel and con-nected in the circuit. In the division above the button only belongs to the circuit. Displaying the button on the operators panel is delimited since the functionality of the button is covered in the circuit. Instead of pushing buttons on the operators panel the buttons can be pushed directly at their location in the circuit.
The functionality of the operators panel is extended to include a train. The reason for this is that the operators panel already contains the track sections and points of the station and their assemblings. The train will initially only be visible by looking at the states of track sections and points. In reality small lamps placed by the track sections and points on the operators panel indicates whether the relevant track section / point is occupied so the design is quite similar to the domain. Station is the common term for the circuit and the operators panel, and thus not in the above division.