Software Design

Most used UML diagrams:

  • Logic view
    • Class
    • Object
    • State machine
  • Process view
    • Communication
    • Activity
    • Interaction
    • Timing
  • Dev view
    • Component
    • Package
  • Physical view
    • Deployment
  • Use case
    • Use case



The main goal of modeling is to manage the complexity. Modeling is an abstraction of reality to better understand the system we want to realize. To check or make a model, it must be connected to the real world, know what exists before the work and the rest to achieve. A model is expressed with different levels of abstraction, a single view of the system is not enough to understand all its operation and intrinsic interactions.

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

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

4+1 Kruchten’s view

Kruchten’s « 4 + 1 » model is used to organize the system description into several complementary views, each presenting the system from a different point of view. The use of views makes it possible to organize the interests of the various groups of stakeholders separately and thus to better separate functional concerns from extrafunctional concerns:

  • 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 aspects of competition and synchronization, and breaks them down into execution flows (process, thread, etc.). It relates to active objects and interactions.
  • The « development » view represents the static organization of the modules (executable, source code, packages, etc.) in the development environment.
  • The « physical » view describes the different hardware resources and the software implementation taking into account these resources. So, it refers to the physical nodes of execution and the placement of objects on the nodes.
  • The last view, called the « use case », focuses on consistency by presenting usage scenarios that implement the elements from the first four views. The scenarios are an abstraction of the functional requirements of the application. This last view validates the other views and ensures overall consistency. It is also this last view that is built first, just after the specification is established, to set the contours of the system to achieve.