*2.1.2. The network design stage*

**•** The forth area includes a diagram that will plot the network usage from the last 60 sec of the simulation (the complete network usage is saved in a text file, at the end of the simula‐

Proceedings of the International Conference on Interdisciplinary Studies (ICIS 2016) - Interdisciplinarity and Creativity

The main window can be resized upwards of the minimum size of 1000 px (width) × 500 px (height). During the resize process, the following can be observed: the size of graphical zone remains unmodified (500 px × 300 px) for objective reasons (the devices have fixed represen‐

The right-sided scrollbar of the main window (see Figure 1) allows changing the sizes of the routing information area and the network usage diagram area: The ratio determined by the scroll thumb in this scrollbar is equal to the ratio between the heights of the areas in question.

Its functionality changes depending on the stage in which the application currently is in. Two

In both stages, the mouse position is continuously monitored, more precisely: the coordinates of the cursor when left click is pressed, its position in the proceeding moments and the coordinates when left click is released. These three events are necessary for a single left click

The graphical zone represents one of the most complex parts of this application.

tion). This area is detachable from the main window via a double click on it.

**Figure 1.** The main window divided into its four main areas.

*2.1.1. The graphical zone*

in the Knowledge Society

56

main stages distinguish themselves:

**•** The RIP protocol simulation stage.

**•** The network design stage.

tation sizes) and only the other areas modify their sizes.

At the beginning of the application, in the network design stage, a right click on the graphical zone will give two device insertion options: host or router.

Programmatically, by choosing one of these options, an object of class type Device will be created in a list from the class Topology, which will have as coordinates, the upper-left position of the previous contextual menu. These devices will be represented on the graphical zone through discs of different dimensions and colours depending on their respective states. Next to the discs, a unique name will be shown for quick visual identification (see Figure 2).

**Figure 2.** Device representation example: R1 is a selected router; R2 is an online router; H1 is an offline host; the seg‐ ment [R1,R2] is a connection; the segment [R1,H1] is a deactivated connection.

Once a device has been inserted, the user can select this device or move it around, for reposi‐ tioning, by dragging it with the mouse.

In order to detect if a device was selected, the application runs the following algorithm:

**Step 1.** All the devices d from the devices list from the Topology class are retrieved and checked one by one as in the following algorithm:


**Step 2.** If this step is reached, then no device has been selected. **STOP**

The same algorithm (with minor changes) is used for the right-click event, in order to determine the contents of contextual menu. The changes consist in:


In the situation in which the left-click mouse button was clicked over a device, but it was not yet released, mouse movements are monitored as follows:

**Step 3.** If the Euclidean distance between P\_initial (the initial point of click) and P\_current (the current cursor location) is smaller than 6 px, it is considered that the user's hand just trembled when the button was pressed, thus no action will be taken.

**Step 4.** If the distance increases over 6 px, this means that the user actually wants to move the selected device. This movement will be done continuously until the left click is released (the 6 px protection from step 1 is deactivated). During this movement, two scenarios may occur:


**Step 5.** If at the left-click button release event, the distance between P\_initial and P\_current has never exceeded 6 px, this means the user wanted to select the object, thus it will be highlighted as such (with green).

The management of these warning colours is done through the existence of multiple Booleantype variables throughout the Device class. They determine the current status of a device. The order of colouring is given by the following method:

```
private void setNormalColor()
 {
  if (flag_deletion)
 {
 colour = Settings.getColor_Device_Dispose();
 }
else if (flag_overlapp)
 {
 colour = Settings.getColor_Device_Overlap();
 }
else if (flag_tracert)
 {
 colour = Settings.getColor_Device_Traced();
 }
else if (flag_selected)
 {
 colour = Settings.getColor_Device_Selected();
 }
else if (flag_online)
```

```
 {
 colour = Settings.getColor_Device_Online();
 }
else
 {
 colour = Settings.getColor_Device_Offline();
 }
 }
```
The following order is distinguished: deletion colour, overlap colour, trace colour, selection colour and online/offline status colour.

The selection of two devices during the network design stage will create/delete a connec‐ tion between the devices, and during the second stage, it will start a 'trace route' type command from the first device to the second (as it will be shown in Section 2.5).
