Chapter 1 - Hardware Abstraction
The software requirements are usually set by a person or group of people. The customer expresses a need that the software solution must meet.
A group of services is typically not implemented in a monolithic software entity but is instead dispersed into several logic components assembled to provide all services to a client. This client can be as much a person as a process of the solution.
A distributed software solution relies on a set of computers that communicate together through a computer network in order to achieve a common goal [6], contrary to a monolithic software solution where the solution relies on a single computer. In the same vein, a processes federation on the same computer is also a way to distribute a solution in order to use its own physical resources. A software solution is distributed as long as different hardware resources are used by logic components of the solution.
In the case of a monolithic solution, the public interface is connected to the single logic component of the software solution. In the case of distributed solutions, the interface is divided into several logic components that communicate with each other. There may be several public interfaces, and each is connected to one of the logic components of the solution.
Whether or not the distribution of a solution is performed on the same computer, it requires relationships between the logic components of the solution, usually by communication links. Often these communication links are implemented by physical communication links. The hardware used to implement these physical communication links is part of the physical deployment environment of the software solution. In the context of a distributed software solution, there is no guarantee that the distribution is identical in all deployment environments. As long as logical communication links are available, the various logic components can be deployed in various ways insofar as the physical implementation of a logic component respects its own characteristics. We must therefore highlight these characteristics in order to set the scope of what can be controlled during the design of the solution.
Some architectural models define the granularity of the architecture of the software solution in three principal layers of abstraction: conceptual, logical and physical. [5] The conceptual layer describes the main interactions between the client and the software solution, the logic layer describes the services to be developed to meet the requirements, and the physical layer describes the actual implementation of the services of the solution.
Links allow interaction between the components of the logic layer. These components and links are detailed in the physical layer of the architecture. When they are not known in advance, the logic model can be deployed by multiple physical models. The same logic component may depend on several physical components, depending on the model used.
Conversely, the diverse physical components that can be used have common characteristics, so that they can meet the requirements of a logic component. The abstraction of these specific characteristics can reduce the coupling between hardware and software. The abstraction of these characteristics also alleviates the problem of an unlimited number of deployment environments forming groups of components with unique characteristics.
These groupings constitute hardware abstractions that allow insertion of a virtual layer between the logic and physical abstraction layers. This virtual layer defines dependencies between a logic component and the physical components, as well as characteristics of these dependencies.