Useful charts from UML (Category Architecture)
This morning I was thinking about the book UML Self-Teacher, and the applicability of language to communication and thinking about architectural solutions. (1 and 2). There I decided to talk separately about the charts that I find useful, and now the time has come. Below is a list that I find useful in the current environment, when UML lost to other simulation tools, such as the C4 Model, which is well described by Simon Brown, the creator of the concept. (Look at this. analysis The C4 Model: Misconceptions, Misuses & Mistakes 2024 year)
1) Use case diagram (diagram of use cases) - This is a standard diagram with scripts, from which everyone usually remembers men and ellipses, but forgets that these are only illustrations, and the basis is in the text with a happy path and an exceptional flow. There's also magic about decomposition and script composition. The diagram type itself is sometimes still used, but it was once fashionable to describe it through user stories, then customer journey map, then jobs to be done scripts, and so on. 2) Class diagram (class-diagram) - in fact, it's the legacy of the ER chart. (entity-relationship)but in an object-oriented setting. Almost any IDE can generate such diagrams by code. They are easy for engineers to understand and are sometimes used. 3) Sequence diagram (sequence diagram) It is a popular diagram to describe the interaction between different parts of a system. It is intuitive enough to describe and analyze complex interactions. A good example of this is the recent Google article, “A Model-based, Quality Attribute-guided Architecture Re-Design Process at Google.” told earlier. By the way, there is a similar diagram, which is also about interactions, but the display is slightly different. Activity diagram (activity chart). These diagrams show the dynamic behavior of the system. 4) Component diagram (component diagram) This diagram allows you to display components with their interfaces, as well as how they depend on each other. This diagram shows the static state of the system. 5) Deployment diagram (diagram) This type of diagram allows you to connect the logical description of the system with its physical embodiment. So we understood how our components would be physically embedded in processes, inside servers, connected by a network, and so on. 6) State chart diagram (graph) This type of diagram allows you to describe finite automata. It has states and transitions between them, available activities and so on. In this diagram, we can describe, for example, the logic of the kettle. Its states can be as follows: “off”, “heating” and “boiling”. When we press the button, it performs an action – it goes from the “off” state to the “heat” state. And when the water in the kettle boils, it automatically changes to the state of “boiling”. Each of these actions, such as pressing a button or boiling water, causes the kettle to move from one state to another, according to predetermined rules.
So these kinds of diagrams have really helped me structure my understanding of how to decompose a system and think about it separately, which is the analytical part of design. And only later learned not just to disassemble the system into arbitrary parts, but also to collect something meaningful back. And gradually it became clear to me how to think about emergent properties of a system that satisfy both functional and nonfunctional requirements for a system. But that's a story for another post.
P.S. Visual examples of diagrams are available in next post.
#Software #Architect #SystemDesign #SoftwareArchitecture #Processes