- Relational algebra
- Logical View
- Class diagram
- Object diagram
- State-transition diagram
- Process view
- Sequence diagram
- Communication diagram
- Activity diagram
- Interaction diagram
- Time diagram
- Development view
- Component diagram
- Package diagram
- Physical view
- Deployment diagram
- Use case view
Contents
ToggleSoftware analysis
The main objective of software analysis is to control the complexity. Modeling is an abstraction from reality in order to better understand the system to be realized / realized. To verify or build a model, it must be connected to the real world, 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 its functioning and 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 an architecture diagram takes, it always represents only a 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 based on 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, of a computer system allows the description of the system to be organized into several complementary views, each presenting the system from a different point of view. The use of views allows the interests of various stakeholder groups to be addressed separately, thereby better separating functional and 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.