Preliminary analysis

Chapter 5

5.1.1 Design approach

Standalone component

Software architecture defines a module as standalone when it can operate au-tonomously and independently from other implementations. This is usually achieved by creating executable programs. With this approach, the component would expose available features directly to the end user. Most of the geographic data that the GMIP framework will manipulate will be provided by the platforms mentioned in 3.3. But, if these platforms were no longer reachable for any reason, the framework could no longer operate independently. Therefore the definition just introduced cannot be fully respected.

Among the advantages offered by this solution, one of the most helpful is being almost ready for use. The rules are simple: install the software, check if it is correctly configured, and, if necessary, make it reachable from the Internet.

Another considerable advantage is modularity. Imagine a computer system made up of various modules, including this one. If the component is no longer needed due to a change in requirements, it could be easily removed without causing problems to the entire system. Speaking of software updates, the framework could even be updated remotely without impact on the system. Another advantage is related to the management of the incoming requests load. This component can be «scaled», i.e., cloned into numerous instances to process all requests as quickly as possible.

Designing a standalone component also offers advantages in the development stages.

Using Docker is one of them. In this way, implementations can be developed regardless of the details of the target operating system, effectively introducing a portable application that can be deployed through docker-enabled machines.

However, selecting an autonomous and independent component can also present disadvantages, based on the software requirements. For the framework, the services will be offered through APIs, so a suitable infrastructure must be adopted to expose them, inevitably adding overhead to code development. Introducing layers for security, monitoring, and other middleware could also increase the code volume.

Advantages Disadvantages

Ready for use Modularity Scalability Upgradeability

Environment isolation

Infrastructure overhead Middlewares overhead

Table 5.1: Advantages and disadvantages of a standalone component

5.1 – Preliminary analysis

Integrable library

The complementary approach is obtained by creating a library that can be inte-grated into third-party applications that need an interface to the maps provider.

In this case, the services offered by the framework would be implemented by classes, functions, and tools made available to developers, almost like a Software Development Kit (SDK).

The first advantage of this solution is obtained indirectly from the nature of the library itself. In fact, the kit can also provide algorithms and tools for low-level data manipulation, in addition to the functionality defined by the requirements.

Another potentiality of the library concerns the shareability between applications.

A dynamic model would allow you to share code and save memory, thus favoring its use on low-resource systems, such as embedded systems. In general, this solution is more open to the concept of extensibility. An open-source scenario could allow third-party developers to extend the available services and tools. These extensions would allow greater code customization while leaving the main logic intact.

Despite these advantages, the main problem with the library is that it is not ready for use, as it is designed to be inserted into third-party systems. From a commercial point of view, this can slow down the Time To Market (TTM).

Moreover, modularity is no longer applicable when exploiting this solution. The library integration prevents it from being easily removed when no longer needed, thus adding unused code to the system. Another critical point is the practical side of the implementations. They will be utterly dependent on the solutions adopted in external systems; therefore, the library will have to be written in different programming languages to meet best the needs of those who will use it.

Upgradeability and maintainability are two other closely related negative aspects.

In the first case, the update process can be difficult and time-consuming, considering that it cannot be performed remotely. Similarly, fixing bugs can be very challenging for those who create the library and those who integrate it. The former will have to keep all the different versions of the library. After updating the library dependency, the latter must validate their systems carefully.

Advantages Disadvantages

Shareability Extensibility Tools provisioning

Modularity Upgradeability Maintainability

Environment dependency Table 5.2: Advantages and disadvantages of an integrable library

Choice

The solution adopted for the GMIP framework bases its implementation on a set of standalone components. The primary motivation concerns modularity, a fundamental characteristic of modern and well-designed software. In addition, a ready-to-use component can easily integrate into external systems without introduc-ing a direct dependency on it. This approach also allows the creation of customized systems consisting of the desired components and nothing more. Finally, standalone components facilitate the update stages, which can perform even remotely.

5.1.2 Development approaches

The creation of the GMIP framework arises from providing geographic data to CCAM applications to promote and strengthen cooperation between vehicles and road infrastructures. As anticipated in the previous chapters, GMIP will act as an interface for the map providers. Therefore, it will embrace a «multi-provider» strategy to support communication with the different available systems.

For this reason, both services and visualization tools will require generalized implementations. In particular, each service will have to define the data needed for the computation and the data generated, i.e., the input and output data structures.

Similarly, the visualization tool will have to supply an interface for user interaction within different web maps. The first version of GMIP will support the providers introduced in section 3.3, i.e., Google Maps, OpenStreetMap and MapBox.

Below is a brief explanation of the two criteria considered at the beginning of the development phase. In particular, a brief evaluation led to understanding which approaches to adopt for developing GMIP functionalities.

Features over generalization

The first approach is based on the identification of the map provider who offers more types of services and allows more customization. Once identified, the application can be developed, considering it the only source of access to geographic data.

Typically, this solution is not very effective in generalization, as it is not sure that the same services offered by other providers need the same input data and accept the same format. However, keeping the implementations as generalized as possible and considering an accurate analysis of the providers’ documentation can help.

Generalization over features

The opposite criterion favors implementing the features individually, focusing on the peculiarities of each provider. For example, identifying the most basic functionality and exploring the differences between map providers allows the creation of simple