UML for developers
UML notation is redundant. On the other hand, it is not enough for the design of distributed systems, and here Archimate helps us. In this article we will tell you what is really useful from all this variety, and consider the full cycle of creating diagrams for a project as an example.
What will we draw in?
If your goal is “fast and beautiful” (for example, for a presentation or for this article), then Visio is more than suitable: its editor is convenient and forgives any deviations from the notation.
If you are engaged in designing, then you need a complete system with support for relationships between diagrams. We use Enterprise Architect product, cheap and cheerful. A comparison of design systems and a story about how to use them correctly is a topic for a separate article.
We will design a hypothetical mobile application for learning foreign languages. The terms of reference are usually prepared by analysts who will prepare the first batch of diagrams. Developers, in this case, are only required to read them correctly.
The simplest chart is Use Case:
The diagram shows the types of users and lists the functions or groups of functions that are associated with them. An element that is absent in UML but is often missing is highlighted in blue: Requirement – Requirement (from Archimate notation), refinement of functions.
You ask – and what’s the point? After all, the list of functions can be specified simply in text, in one compact list! And you will be right, but there are nuances:
1) Some functions apply to several users, it is difficult to display this text.
2) When you draw all the functions and requirements in the design system, you can then upload them to the same Jira, and then associate them with tasks and bugs, which simplifies project management.
Why did we mix UML and Archimate in the same diagram? You do not need to strictly follow the notations; you do not have to pass exams at the university with this, but communicate with the team, for which you are preparing it all.
Why did we use lines rather than arrows to connect elements? Because no one remembers what the “Generalization” and “Extension” arrows look like, and what they really are. The simpler you draw, the more people will understand the chart without your participation.
The second kind of diagrams that you can meet in the terms of reference is Activity diagram:
Here, everything is obvious to the developer, except for one thing: why does the AI make Student calls? Does not. This diagram is drawn by analysts, not programmers, they do not know where the client is, but where the server is, and they are not interested in data streams. On the Activity diagram, you see a sequence of actions and nothing more. How to make a code from this? We pass to the design stage.
The architecture of the mobile application is obvious: client, server, database. If we are designing something serious, then we should take care of dividing the project into Subsystems, in our case it will be at least:
- Lesson Booking Subsystem
- Web Training Subsystem
- Voice Recording Management Subsystem
Subsystems should be isolated from each other: own databases without relational connections with other subsystems, communication between subsystems only through the API. The subsystem can be either a set of microservices or a monolith, at your discretion.
You can give each subsystem to a dedicated development team, they will immerse themselves in their topic and will less interfere with colleagues with their unexpected commits.
For each subsystem it will be required Architectural schemehow to draw it right? There are no suitable diagrams in UML for this, let’s look at Archimate:
Even without knowledge of notation, the diagram is generally readable. Remember that 90% of your team members do not know either UML, let alone Archimate, and they will never learn these notations, so focus on the inscriptions. However, a few words about the cubes and arrows:
You can easily find the full Archimate specification.
Color – to your taste, the notation does not regulate them in any way. Color the current subsystem with one color, the adjacent subsystems with the second, external systems with the third, this greatly improves the readability of the circuit.
The diagram uses only two types of arrows: Flow and Access. The stream shows the direction of data transfer, and the Call – who is talking to whom. The flow arrow should be understood correctly:
The flowchart from the mobile application to the server is not shown in the diagram, although in fact it is (the “Data request” stream goes first). This is done to make the scheme easier to read: we show only the most important. The fact that there is also an initial data request is already evident from the cube with the inscription API.
The last two diagrams, which are very useful (the attentive reader, of course, noticed that there are no longer 2-3 types of diagrams): Sequence diagram (Class diagram) and Class Diagram (Class diagram, but not for classes at all).
Sometimes the client-server interaction is multistage, using third resources. For example, authorization with Oauth2: a textual description of this process is very difficult to understand. Help here Sequence diagram:
This Oauth2 implementation is not a reference, there can be many options. The most important thing to understand in the diagram is that there are no data streams in this diagram, only Calls and Answers to calls. Although this did not stop us from specifying streams with text on arrows.
When you delve into the study of the Sequence diagram, you will find that it allows you to display loops and branches, but do not abuse them: you do not need to draw branches on one diagram “If the user has chosen local authorization, then” and “If I chose FB authorization, then”, instead, draw two diagrams for each option. Conditions, especially nested ones, on the Sequence diagram greatly reduce the readability of the circuit.
The last chart (not for today, but in general) – Class diagram. Her name is speaking, it was assumed that with the help of her classes would be designed. In the old days of DOS text editors, this may have been justified, but modern development environments allow you to design and analyze classes without leaving their dark and light themes.
But the practical application of the Class Diagram still remains – database design:
If you know what relational databases are, then this is more than visual. Attributes on the diagram do not fully sign, only relationships, data types, and sometimes restrictions are indicated.
Do not try to draw it in Visio, Enterprise Architect or equivalent. For database design, there are many specialized tools that are tailored for specific DBMSs, use them.
That’s all. Of all the diagrams in UML and Archimate, in practice more than enough are listed. How many diagrams of each kind are needed for a project? Should I draw them for each process and subsystem? The main rule is that the diagram accompanies the text description, it is needed only where the text is not enough, i.e. where the team does not understand you.
Thank you for your attention, there was a Software Product company with you.