Software analysis

The main objective of software analysis is to master complexity. Modeling is an abstraction of reality in order to better understand the system to be produced/created. To verify or manufacture a model, the latter must be connected to the real world, to know what exists before the work, what has been done and what remains to be done. A model can be expressed with different levels of abstraction/refinement, a single view of the system is not sufficient to understand all of its functioning and the intrinsic interactions.

The modeling is based on graphics of computer systems. The most used graphics are part of the Unified Modeling Language (UML). The latter includes a set of tools and rules for defining diagrams.

Regardless of the form that an architecture diagram takes, it always represents only one point of view on the considered system, the most important being the motivations. Indeed, what is the point of producing a diagram if it is useless (not used) or if the reasons for the architectural choices are vague and unexplained. To avoid formulating the motivations for each diagram, the IT architect will produce the different diagrams according to a design template and will reuse proven design patterns.

4 + 1 views of Kruchten

In software analysis, the "4+1" view model, known as Kruchten's model, of a computer system makes it possible to organize the description of the system into several complementary views, each presenting the system from a different point of view. The use of views makes it possible to treat the interests of the various stakeholder groups separately and thus to better separate the functional concerns from the extra-functional concerns.

The figure schematizes the “4 + 1” views model. This model is made up of five views.

• The "logical" view describes the static and dynamic aspects of a system in terms of classes, objects, connections and communications. It focuses on abstraction and encapsulation.
• The "process" view captures the concurrency and synchronization aspects, and breaks them down into execution flows (process, execution thread, etc.). It relates to active objects and interactions.
• The "development" view represents the static organization of modules (executable, source codes, packages, etc.) in the development environment.
• The “physical” view describes the various hardware resources and the software implementation taking these resources into account. So, it relates to the physical execution nodes and the placement of objects on the nodes.
• The final view, called a “use case,” focuses on consistency by presenting use cases that implement elements of the first four views. Scenarios are an abstraction of the functional requirements of the application. This last view somewhat validates the other views and ensures overall consistency. It is also this last view which is built first, just after the establishment of the specifications, to fix the contours of the system to be produced with its functionalities called, in UML terminology, use cases.