I wonder if there are well accepted/standardized types of diagrams to describe the architecture of a software implementation, for example, a Clean Architecture.
By software architecture, I mean a set of defined modules using high-level abstractions without including any libraries, frameworks, or databases.
So far, I have found only the Component Diagram as a suitable diagram. Is this correct for representing the different layers of my software? And is this sufficient to document the software architecture?
Best Answer
What is the purpose of the layers ?
The clean architecture aims to achieve separation of concerns, by dividing the software into concentric layers. The main difference compared to the traditional layered architectures is the principle of dependency: the outer parts depends on the inner part and not the contrary.
In layered architecture, the the higher strates are dependent on the lower strate. However, for graphical reasons, the lowest level tends to rely (and therefore depend) on the a data access layer which is in the outside ring in clean architectures. This leads then to entities that are dependent of the database access layer, so of their implementation.
For concentric as well as layered architecture, there is however one common ground: the layers correspond to a logical grouping of dependencies. These groupings can in some cases coincide with components, but it's not a general rule.
How to diagram the layers in UML
In UML there is no single architecture diagram that summarizes everything. As for a building, whose architecture will be described by several diagrams (e.g. front facade diagram, side diagram, ground diagram for the implementation of the building on the terrain, and a diagram for every floor) software architecture will be described with different diagrams that each focus on different aspects.
For the layers, the logical grouping of related software artifacts and their dependencies are best shown in a package diagram. A package may group not only classes, but also components, and use cases. Here a nice example.
More architecture
Structural views
At the highest level, you'll describe the system under consideration in its environment, and describe the main functions. For this you'll have a use case diagram.
Then you may divide the system into independent components, and show how these are related to each other. You'll describe this in a component diagram.
Then you can zoom in and show the inner structure of the componenets, and show the classes that being assembled make the component. You show this with a composite diagram.
Finally, you'll zoom in further, and show the details of the classes and their associations in a class diagram.
Behavioral view: the inner life of your structure
For each of these structural aspect, you can also show relevant behavioral aspects:
Physical view
All these components and artifacts were considered so far from the logical point of view (i.e. how the developper sees it). However, it is sometimes necessary to get an understanding of how these componennts will be deployed on the operational infrastructure, for example what happens on the server, and what happens on the client.
For this, you can use the deployment diagrams, that show how the components/artifacts are distributed between nodes (e.g. hardware, and within one device, different operating environments (OS, virtual servers, etc...).
Final note
The order above is purely illustrative. In general the elaboration of such a model is iterative. So you can also start with a class diagram, elaborate the interactions, fine-tune the classes, assemble them in composites, etc...