Shulou(Shulou.com)06/02 Report--

This article mainly introduces "what is the method of frame drawing". In the daily operation, I believe that many people have doubts about what the method of structure drawing is. The editor consulted all kinds of data and sorted out simple and easy-to-use operation methods. I hope it will be helpful for you to answer the question of "what is the method of frame drawing?" Next, please follow the editor to study!

What is software architecture?

Software architecture definition

The definition given by IEEE: architecture is a set of basic concepts (concepts) and attributes (properties) of the system in the environment, which is represented by its elements (elements), relationships (relationships), and the basic principles of design and evolution (principles).

The definition of CMU Software Engineering Institute: architecture is a set of structures (structures) used to deduce the system, which is composed of software elements (elements), relationships between elements (relationships), and their respective attributes (properties).

The definition given by Uncle Bob in his book Clean Architecture: architecture is the shape that the creator gives to the system. The concrete form of this form comes from the division and arrangement of system components (components) and the way these components communicate with each other.

Core elements of architecture

Combining the above authoritative definitions, the architecture of a software system usually needs to include the following four core elements:

Elements (elements): split the system into a set of elements-modules, components, structures, subsystems.

Relationships: relationships between different elements-interaction, dependency, inheritance, composition, aggregation.

Properties: the attributes that each element has-name, responsibility, interface, implementation restrictions, and so on.

Principle (principles): why it is so designed-split basis, design principles, decision reasons, etc.

Why is architecture important?

Architecture is the blueprint for system implementation.

Recently, there is a very popular online drama called "skyscrapers", which tells a strange suspense story. Why are you talking about this? Because I want to borrow the title of this play to ask a question: who built the skyscrapers?

Perhaps you will say to yourself: nonsense, it is the construction workers who pile up brick by brick. Think about it? Is there a bunch of heartbroken architects (such as the handsome Lin Dasen in the show) and civil engineers behind it?

Although they do not carry bricks or cement, without the tedious and rigorous design drawings they produce, skyscrapers cannot be erected as quickly and smoothly as rural self-built houses based on their own experience and imagination.

It is by virtue of the engineering blueprint (blueprints) depicted by these drawings that hundreds of thousands of workers' division of labor and acceptance standards have been based.

All you need to do is to add the bricks and tiles you are responsible for step by step according to the blueprint; as long as the blueprint is correct and there is no deviation in the construction process, it is only a matter of time before the final completion is successful.

Like construction, automotive, or any other engineering industry, software needs a blueprint before it can be implemented (coded), and the most important blueprint is architectural design.

Without architecture, you may be able to create nice and useful little things (such as Linux version 0.01) on your own, just like traditional craftsmen, with vague ideas in the programmer's mind.

But it is unlikely to work with a team to build a complex software system of the same size as a skyscraper (such as a modern Linux system).

On the one hand, human thinking ability is limited after all, and we must rely on the highly abstract and simplified blueprint of architecture to make the creation, understanding, analysis and governance of complex systems feasible.

On the other hand, large-scale systems of a certain magnitude can only be completed by multi-person division of work and cooperation, and the architecture is an important basis for multi-person communication and cooperation.

Architecture is the basis of communication and collaboration

The ultimate value output of a software project is the software system, and architecture, as the soul and skeleton of the software system, can play the following roles:

① understanding alignment: the purpose of all software systems is to meet the needs of users, but there are unlimited possibilities for implementation (software is more flexible and knowledge iterates faster than traditional engineering industries).

Architectural design is about choosing one of the most appropriate approaches to implementation, so it involves a lot of critical routing decisions (why split up like this? Why choose A technology instead of B?).

These important technical decisions need to be recorded and synchronized in the form of architectural description in order to align and reach a consensus among all members of the project team on the understanding of the whole system.

Quantification of ② work: one of the most important steps in project management is man-hour evaluation, which is the direct basis for determining project schedules and milestones.

Obviously, it is impossible to scientifically quantify the project workload only through the PRD/ interaction diagram, because it is difficult to intuitively judge how much code to write and how difficult it is to implement behind a short requirement or a simple page.

With a clear architecture, in theory, most of the development work can be visible, predictable, and disassembled, and naturally can be more accurately quantified.

Of course, accurate workload assessment has always been a mystery in the IT industry, and the actual duration will be affected by too many unknown factors, including programmers' skill proficiency, mood, whether they have enough to eat, and so on.

③ standard term: programming, as a creative job, is similar to writing science fiction in some ways.

Good science fiction likes to create concepts, such as Tomoko in the three-body. If you haven't read the novel, you won't know what it is.

In terms of creating concepts, software systems are only better than science fiction. After all, the world in novels is usually based on reality, while the world in software depends entirely on the imagination of the creator (programmer).

Slightly more complex software systems will introduce some domain-specific or even brand-new creative concepts. In order to avoid communication obstacles and ambiguity between chicken and duck in the course of the project, it is necessary to unify the terms that describe these concepts.

An important purpose of the architecture is to define and explain all the key concepts involved in the system, and to use standard and consistent terminology in the whole process of architecture design and description, so that everyone's communication is on the same channel.

④ has something to say: just as you need to look directly at the code when discussing product interactions and discussing code details, architecture is a necessary physical object when discussing some higher-dimensional technical issues (the specific physical form is the so-called architecture description).

Otherwise, either a bunch of people talk to the air (you can't even talk on paper), or find a new whiteboard to draw a picture every time you communicate (it's time-consuming and easy to leave information, which is obviously not a long-term solution).

⑤ knowledge precipitation-newcomer training: architecture should be continuously deposited and maintained as a document asset as important as code, and it is also an important basis for project newcomers to quickly understand and get started with the system.

Don't let your system be like some ancestral legacy systems in the company-only the code is left behind, but no architectural documentation; you can only rely on some residual design memories handed down by word of mouth to sustain the life of the project.

Architecture determines product quality.

How to measure the quality of a software product? The above figure shows the software product quality model defined by the ISO/IEC 25010 standard, which includes the following eight categories:

Functional suitability: functional integrity, functional correctness and functional appropriateness.

Performance efficiency: time performance (e.g. Response time), resource utilization and capacity.

Compatibility: coexistence ability (e.g. Multi-version components coexist) and interoperability.

Usability: learnability, maintainability, user error protection (e.g. Automatic error correction), UI aesthetics, accessibility.

Reliability: maturity, availability, fault tolerance, recoverability.

Security: confidentiality, integrity, unforgeability, authority and auditability.

Maintainability: modularity, reusability, analyability, modifiability, testability.

Portability: adaptable, installable, replaceable.

All the points listed in the above quality model are important points for architecture design. Except for functional suitability, all the other points belong to the category of non-functional requirements, which is the real watershed to distinguish between good and bad architecture.

Good architectural design will not only meet the most basic level of functional requirements (the worst architectural design can do the same), but many other non-functional requirements are more important and more difficult to deal with.

Of course, you can't have both. Architecture, like life, is also a game of trade-offs, which may end up like the Dragon Mother in season 8: both want and want, but get nothing in the end.

A good architect should learn from Comrade Snow. On the surface, he is "know nothing", but in fact he is "know everthing".

Clear all the stakeholders (stakeholders) of the system, strive to explore the main requirements of all parties (concerns), and balance their own architectural decisions (decisions) accordingly, and finally achieve the ultimate architectural goal of Hello, Hello, me, Hello, everyone.

I can give you more reasons.

If it were not for the space limit, this page of PPT would obviously not be enough:

The architecture contains all the most important early decisions of the system, which in turn affect all subsequent technical decisions, large and small. Therefore, the early architectural design needs to be very rigorous and careful, to be "right at once" as much as possible (though difficult), otherwise the cost of error correction will be higher later.

Architecture has a very high reuse value within the organization, because products in the same organization must have a lot in common (requirements, limitations, environment, etc.), which is very suitable for maximizing reuse at the architectural level to avoid repeatedly solving similar problems.

Conway's law states that software architecture reflects organizational structure. The reverse is true: a good structure also makes the organizational structure more efficient.

The larger and more complex the system, the more important the architecture, because only a good architecture can effectively control, manage and reduce the complexity of the system.

Is it that the more you listen to it, the more confused you become, as if the structure has countless interpretations and meanings? There is no need to struggle too much, according to GoF's design pattern: Architecture is about the important stuff. Whatever that is. Yeah, whatever it is, it's enough to remember that architecture is important.

How to design a good architecture?

After understanding the concept and importance of architecture, the road to true architect practice has only just begun. How to design a good architecture?

This is obviously a very broad and profound topic, but it is not the focus of this article, so here are only some basic ideas (principles) and classical routines (patterns).

Of course, architecture design is closer to an empirical discipline, and it is certainly not enough to blurt out some mysterious and high-end theoretical concepts, it needs to be combined with the actual work content and business scenarios to practice and speculate a lot, otherwise it can only be regarded as hovering outside the architecture, not even talking about getting started.

Architectural principles (principles)

The SOLID principle is a classic and popular set of architectural principles (mainly with a good name):

Single responsibility: coincides with the "Do one thing and do it well" advocated by Unix philosophy.

Opening and closing principle: replace modification (breaking existing encapsulation) with new (expansion), which is similar to the functional immutable idea.

Inner substitution: where the parent class can appear, the subclass must appear, so that they can be regarded as having an inherited "Is-A" relationship.

Interface isolation: don't let one class rely on interfaces that are not used in another class. To put it simply, minimize interface dependencies and coupling between components.

Dependency inversion: rely on abstract classes and interfaces rather than concrete implementation; let low-level modules rely on the stable abstraction of high-level modules to achieve decoupling.

In addition, we will try our best to follow the following principles when designing the architecture (which is essentially the same as the above SOLID principles):

Orthogonality: the components separated at the same level of the architecture should be orthogonal as far as possible, that is, the responsibilities of each other are independent, the boundaries are clear, and there is no overlap.

High cohesion: the same component should be highly cohesive (cohesive), like an indivisible whole (otherwise it should be taken apart).

Low coupling: coupling should be minimized between different components to reduce mutual change and enhance component reusability.

Isolating change: the essence of many architectural principles and patterns is to isolate changes-- isolating parts that are expected to change together, reducing other stable parts that are affected by changes that require code modification, retesting, or potential failures.

Architectural pattern (patterns)

Architectural patterns (architectural patterns) are not the same thing as design patterns (design patterns) that we often discuss, but if we interpret them only from the perspective of "patterns", the ideas of both are the same: universal, reusable solutions to problems that often arise in a given context.

The main difference is that architectural patterns are more abstract and global (after all, at the architectural design level).

Common architectural patterns include some traditional patterns (e.g. Layering, Cpact S, MVC, event-driven), including some new games (e.g. Cloud Native, Micro Services, Serverless). Different models have different scenarios, and no one can kill all the requirements.

A mature architect should be like an emotional killer who will always objectively evaluate and choose the most suitable solution for the moment, even if it seems simple and tedious to do so; on the contrary, immature architects always want to make trouble (e.g. Force the application of micro-service architecture), rather than really solve the problem.

How would you describe your architectural design?

With a good architectural design, we have already walked more than half of the long march. It's like when a young director meets a good script for the first time, his eyes shine with emotion, as if he had foreseen the box office spectacle after the film was released.

Of course, the remaining half of the road will not be as smooth as expected-the same script will be qualitatively different from one director to another.

A good "Best Director" is capable of making "Best Picture" even in the face of a script that is not "Best Screenplay".

Similarly, a good architect should also have the ability to describe a good architectural design; even if he cannot add points to the wonderful content, he should not lose points because of the lack of a good description in form. otherwise, it will be as frustrating and sad as the composition of the college entrance examination.

The meaning of Architectural description

Why describe the architecture? Can't you just let it exist in my deep mind? There is a Western proverb: a good memory is not as good as a bad pen. Anything that doesn't persist is volatile, just like memory.

On the other hand, as mentioned earlier, architecture is the basis of communication and collaboration. If it is not precipitated through architecture description (Architecture Description) so that all project stakeholders can see it, the only carrier of communication and communication will be lost.

According to personal observation, there is no problem with "architecture needs to be described", so most projects will more or less produce some decent architecture description documents.

But the gap between "having an architectural description" and "having a good architectural description" is huge, even greater than the difference between "no" and "have".

If, like me, you have read countless architectural documents, clapped your hands and felt grateful, and patted your thighs angrily, you should be able to feel the same.

The way the architecture is described

For the same thing, the writer will choose to describe it in words, while the painter will use pictures. Although the message they want to convey is the same, the difference in the way they describe it can also make a big difference in effect.

Architecture descriptions are also divided into two forms: Text and Diagram, each of which has its own advantages:

Behind the text is a rigorous and complete language as the support, so its description can be very accurate and detailed, but also very convenient to write, any open notepad software can write; in addition, like writing code, the text is easy to do version management, with the help of simple text diff tools can be clearly compared between different versions of the details of the differences.

Comparatively speaking, the picture does not have the unique characteristics of the above words, but it also has its own unique advantages: the picture is intuitive and vivid, conforming to the innate visual recognition instinct of human beings. The expressive ability of a picture is stronger, and many times the information that a small picture can convey (such as spatial position relationship, color classification, icon shape) may not be described completely and accurately with a thousand lines, that is, the so-called "one picture is worth a thousand words".

Smart you sneered: well, it's not a child who has to do multiple-choice questions. Can't you have both words and pictures? Of course, the ideal architecture description must be illustrated.

But the real world is obviously more cruel than the ideal, and it is difficult to leave enough time for you to produce a perfect architecture document in the actual software project.

If you consider the input-output ratio (ROI) from an adult's point of view, then you will certainly give priority to drawing.

Why should you give priority to drawing?

The Agile Software Development Manifesto mentions that operational software is more important than detailed documentation (Working software over comprehensive documentation).

Of course, this does not mean that there is no need to write documentation, it just advocates that there is no need to write too detailed documentation. Why?

Because detailed documentation costs a lot of writing and maintenance costs, it does not meet the principles of small-step iteration and rapid response to change in agile development.

So, in today's era of comprehensive agile development, how to go with the trend and write architecture documents more agile?

ROI is your friend-- does not ask for much, but refinement, using as little pen and ink as possible to express the core content.

In terms of content, the high part of ROI is generally the overall architecture of the top level or the core critical link, which is also reflected in the concept of C4 model later.

In terms of form, the picture has an unparalleled advantage of expressive power in front of the text, which is obviously a higher choice for ROI.

Why do you need to learn to draw?

It's right to draw more pictures, but is it necessary to study specially? It's not a sketch pen ink painting, it's just a bunch of rules and regulations, and anyone with a little engineering knowledge can do it.

Is it a little ugly? It doesn't matter, at most, use the innate artistic beauty, put these lines in alignment with those frames, and then point out the colorful background colors and so on, doesn't it look very professional?

Seeing this, you smiled contemptuously in front of the screen: well, obviously it's not that simple. Indeed, we all understand that structural drawing, like engineering drawing, is a matter that needs to be taken seriously.

But in reality, most people really don't have the time to do that, such as the two common architecture pictures posted above.

Needless to say in the first picture, this kind of sketch is good to smear by yourself, but it is your fault to take it out to meet people.

What about the second picture, it looks like that? No, if you speculate more carefully, you will find a lot of vagueness and imprecation hidden under this picture.

Therefore, being able to draw a picture does not mean that you can draw a good picture; to make a good picture that is both beautiful and readable, you still need to go through continuous learning and deliberate practice, and it is difficult to grasp the key points by intuition and understanding alone.

In addition, the wrong picture is often worse than no one. Even if you just have a picture, you should at least understand some of the key elements of scientific mapping. Avoid putting a fuzzy filter on an already complex and difficult project, or even have the opposite effect of confusion and misleading.

The goal of architectural mapping

Before discussing the specific mapping methods and tools, we need to set up a clear mapping goal. Tools are the ladder of human evolution, but if they are not understood and used properly, it is easy to be restricted or even enslaved by tools, forgetting the original intention of inventing and using tools in the first place.

For architecture mapping, there are already so many methods and tools, what is the original intention to use them?

I think the essence is to change the mapping process from a free craft to a scientific project: systematic, rigorous, complete, standardized, while being repeatable, sustainable and efficient.

P.S: at that time, I was in a hurry to do PPT, so the matching pictures starting from this chapter can only be forced to take the minimalist route, please forgive me.

Architectural drawing methods and tools

After laying the groundwork for the "brief" of the previous chapters, I believe that you have already had enough knowledge about the background knowledge of architecture drawing.

This chapter will enumerate and describe some typical architectural mapping methods and tools, some of which are common and rare. The key point is to deepen people's understanding of the nature of mapping methods through the horizontal comparison of various methods.

Method 1: UML

UML should be the most familiar mapping method for most people, and the latest version of UML 2.x consists of the following two categories of graphs:

Structure diagrams (Structural Diagrams): emphasize the static structure of the system by means of objects, attributes, operations, and relationships. The most common types include class diagrams (Class Diagram), component diagrams (Component Diagram), and deployment diagrams (Deployment Diagram).

Behavior diagram (Behavioral Diagrams): emphasizes the dynamic behavior of the system by showing the cooperative relationships between objects and the state changes within the objects. The most common types include use case diagrams (Use Case Diagram), activity diagrams (Activity Diagram), sequence diagrams (Sequence Diagram) and state machine diagrams (State Machine Diagram).

As a general "unified modeling language", UML contains a total of 14 different types of diagrams, which can fully cover all kinds of drawing requirements in the field of software design, including architecture drawing.

At the same time, it is precisely because UML regards itself as a language, so its various notations (notion) and semantics (sematics) have very strict definitions, and there will be no ambiguity or ambiguity.

Finally, after decades of development and promotion, UML has become a widely used standard around the world, and its hidden value is that the cost of using UML to communicate in a team is relatively low, because it can be assumed that most technicians can understand the meaning and usage of UML.

However, UML is not a panacea (although it was once regarded as a silver bullet in software design), and its most criticized drawback is its complexity.

You can't blame UML, after all, it was designed to be generic, rigorous, and powerful enough to run counter to "simplicity" and evolve into the complex and rigid behemoth it is today.

Although we confidently assume that most of the technicians understand UML, I think it would be nice to have an average of 20% with a degree quantifier-most of them can recognize several common class diagrams and sequence diagrams, and it is estimated that it is difficult to accurately say the meaning of the various arrows in the class diagram.

In any case, UML should still be one of the most commonly used and essential tools in every programmer's graphics toolbox. Of course, it shouldn't be the only one, because there are some good things that can't be missed.

Method 2: 4: 1 View Model

What is "4 times 1"? It doesn't matter if I don't know. Have you ever heard of "611"? Yes, it's the "very 61st" program that I used to watch when I was a kid.

The relationship between it and "411" is the same as that between them and Shao Jiayi, Zhang Jiaye and Shen Jiayi, except that they happen to share the same suffix.

So, what exactly does "4-month-1" mean? Let's Wiki: "4room1" is a view model (view model) that describes the architecture of software-intensive systems through a variety of co-existing views.

These views are based on the viewpoint of different project stakeholders (stakeholders), such as end users, developers, systems engineers, and project managers.

"4room1" consists of four base views and selected use cases or scenarios (that is, additional "+ 1" views), each with the following specific meanings:

Logical view (Logical view): describes the functions that the system provides to end users, usually represented by class diagrams and state diagrams in UML.

Process View (Process view): describes the dynamic behavior of the system, including processes and interactions, which is generally represented by timing diagrams, activity diagrams and communication diagrams in UML.

Development View (Development view): describes the system from the programmer's point of view, also known as the "implementation view", which is generally represented by component diagrams and package diagrams in UML.

Physical view (Physical view): describes the system from the perspective of a system engineer, including the physical topology of the system components and the physical connections between the components, also known as the "deployment view", which is generally represented by the deployment diagram in UML.

Scenarios: describes the architecture through a small set of use cases or scenarios, including the timing of interactions between various objects and processes in the system, also known as the "use case view".

These scenarios are used to identify architectural elements (architectural elements) and to illustrate and validate the entire architectural design, and can also be used as a starting point for testing architectural prototypes.

Although the various views mentioned above are generally represented by UML diagrams, in fact, "44th 1" itself is a general view model, which does not limit the markings and tools for drawing.

For engineers, this academic approach may not be used directly in a lifetime, but a key architectural mapping idea is very valuable.

The architecture needs to be described by a variety of views, which come from the perspectives of different project stakeholders; only in this way can we produce a comprehensive, three-dimensional and objective description of the architecture.

Method 3: C4 Model

The C4 model is an "abstraction first" (abstraction-first) architectural mapping method, which is also inspired by the previous UML and "4x1" view model, but it is relatively simple and lightweight, contains only a small set of abstractions and diagrams, and is easy to learn and use.

Definition, concept and key ideas of ①

The C4 model describes the static structure of a software system through the abstractions of containers, components, code and people. Its core idea is to build a guide map for the code that can be zoomed in and out through different levels of detail like Google Map.

Its key idea is to split the static structure of the system step by step from top to bottom, and describe the responsibilities, relationships and external dependencies of objects at each level in turn.

In addition to the core hierarchical static structure view, it can also include dynamic views, deployment views, and other supplementary views.

The left figure above shows the mapping between the various levels of abstraction in the C4 model: a software system consists of 1N containers, a container consists of 1N components, and a component consists of 1N code structures.

The figure on the right takes a simple Spring PetClinic project as an example to demonstrate the hierarchical structure of a real software system under the C4 model: the top layer is the PetClinic software system, which can be divided into several containers such as database, Web application and so on.

Web applications can further split the ClinicService component, and this component contains ClinicService interface class, ClinicServiceImple implementation class, Owner/Pet/Visit and other domain object classes.

Architecture mapping using C4 model is essentially a visualization of the above abstractions. The specific approach is to create the following types of coarse-to-fine structural diagrams in turn: Context, Container, Component and Code (optional), which is also the origin of the C4 model name.

② Level 1:System Context diagram

As the first level (L1), the system context graph provides a top-level large picture (big picture) view to show the whole picture of the system, including the most central software system, surrounding users and other interactive systems.

The two most critical concepts are:

Person: users who use software systems, such as consumers, operators, system administrators, etc., of an online mall system.

Software system (Software System): as the highest level of abstraction, it describes the software products that create value for users; it includes not only the software systems currently being designed, but also other software systems that the system depends on (or is dependent on). A software system is usually the responsibility of a single software development team.

When drawing the system context diagram, there is no need to care about any underlying details such as technology stack, protocol and so on. This kind of map has the widest audience because anyone can understand and get enough information from it, including technicians and non-technicians, as well as team members and non-team members.

③ Level 2:Container diagram

After understanding the positioning of the system in the entire IT environment through the context diagram of L1, the next step is to enlarge the frame of the system and take a closer look at which "containers" it contains (Container, be careful not to be confused with Docker containers!).

Containers in the C4 model refer to a single application or data store, which can usually be deployed and run independently (there is an independent process space that communicates with each other through IPC mechanisms), such as: SpringBoot micro-services, React SPA, mobile App, databases, Serverlss functions, Shell scripts.

The container diagram of L2 not only shows the further separation of responsibilities of the system, but also includes the key architecture information such as the main technology selection, the mode of communication between containers and so on.

Such diagrams can be open to all technical personnel, including architects, developers, operations and maintenance staff, technical support, and so on.

④ Level 3:Component diagram

Continuing the previous routine, the next step is to locally enlarge each container in the system and further split each container into multiple components (Component).

In the C4 model, a component is a set of related functions encapsulated together by a good interface definition (usually running in the same process space).

For example: a Controller in Spring (including not only the Controller main class that defines the REST interface, but also all the associated implementation classes behind it, such as Service/Repository, etc.).

Similar to the container diagram, the component diagram of L3 contains not only the component division of the container, but also the responsibility definition, technical and implementation details of each component.

With the sinking of levels and the increase of detail, the audience of component diagrams is further narrowed, generally applicable only to software architects and developers (other roles do not need to understand and generally do not understand).

⑤ Level 4:Code (optional)

Then continue to zoom in on the component, and the lowest and most detailed information you can see is the L4 code (Code).

Of course, the so-called "code" here is a code structure that shows the granularity of a class or file in the form of a diagram (e.g. UML class diagram, database Ehand R diagram), not the real code itself.

Even so, the code diagram is still too detailed in 99% of the architecture description scenarios. On the one hand, the number is large and the drawing cost is high; on the other hand, it is easy to change and the maintenance cost is also very high.

Therefore, generally only very important and complex components need to be described at this level. If you do need to draw, you should also give priority to automation. For example, many IDE support automatic generation of UML class diagrams.

⑥ supplementary figure: Landscape/Dynamic/Deployment Diagram

In addition to the static structure diagrams at all levels mentioned above, the C4 model also proposes a series of supplementary diagrams (Supplementary diagrams), including:

System panorama (System Landscape diagram): the panorama is similar to the drawing method of the system context diagram, except that it gives a panoramic view of all software systems (including those that are not directly related to the current system) and related user and system interactions from the point of view of the enterprise or organization, that is, the scope of the further enlarged architecture diagram.

Dynamic diagram (Dynamic diagram): because the structure diagram can only describe the static structural properties of the system, the communication diagram and timing diagram of UML are recommended in the C4 model to supplement the description of the dynamic behavior of the key links in the system, that is, the combination of dynamic and static.

Deployment diagram (Deployment diagram): in addition to the lack of dynamic attributes, the above structure diagram has a limitation: it only describes the abstract logical architecture of the system, but does not describe the specific physical architecture when the system is actually deployed.

Therefore, the C4 model recommends the use of UML deployment diagrams for system logical nodes (usually L2 "container" granularity) and physical nodes (e.g. The mapping relationship between physical machine / virtual machine / Docker container / application Runtime) is described as a supplement, that is, "virtual-real combination".

After combining these supplementary drawings, the C4 model is a complete architecture mapping method that can comprehensively and stereoscopically describe all aspects of the software architecture.

Method 4: arc42

Strictly speaking, arc42 is not a method of architectural mapping, but rather a template of architectural documents. Although, as mentioned earlier, "diagram" is a better choice than "text" in architecture description, you still need to produce a relatively complete architectural document with pictures and text in the actual project process.

Arc42 is designed to help people better write architecture documents, and as the most important architecture diagram in the architecture document, arc42 obviously won't let go-- many of the core chapters are related to the architecture diagram, and the corresponding mapping methods are described in detail.

Arc42 will not be introduced in detail here, but will only briefly introduce the similarities and differences between the mapping method in arc42 and the C4 model.

Great ideas are similar, and arc42 is no exception. The right part of the upper left image summarizes several core chapters related to mapping in the arc42 template, which are:

Chapter 3 Context: this chapter is used to introduce the background and context of the system, so its mapping idea is almost equivalent to L1 (system context diagram) in the C4 model.

Chapter 5 Building block view: this chapter is used to introduce the basic elements of the system, which is no different from the top-down hierarchical split idea in the C4 model according to the official guiding ideology, the only area is that arc42 does not specify the specific level of the split, as long as it is necessary to follow the "black box → white box" routine has been dismantled to the end.

Chapter 6 Runtime view: there is no need to explain the name, which is equivalent to the runtime view supplemented in the C4 model.

Chapter 7 Deployment view: again, this is equivalent to the supplementary deployment view in the C4 model; however, arc42 emphasizes that the deployment view can also be split hierarchically from the top down like the structural view (hierarchy is really necessary for more complex deployment architectures).

Therefore, in essence, the drawing method advocated in arc42 is equivalent and compatible with the C4 model, and can be used together: using arc42 as the framework document framework, in which the architecture drawing adopts a more specific C4 model. This is also the actual method used in our project at present.

Other methods & drawing tools

In addition to the above methods, many other excellent architectural mapping methods have emerged in the decades when the software industry is booming, including some general methods.

For example, SysML, AADL, ArchiMat, also include some domain-specific methods, such as BPMN, which is common in back-end business modeling scenarios in enterprises.

A more detailed description of the various methods will obviously make this article smelly and long (although it seems destined to be written here), and interested readers can search and explore on their own.

So far, this chapter has introduced various methods of structural mapping, but in fact, there is an unavoidable link in the process from the method to the landing: what kind of tools to choose to draw?

You can't really use paper and pen like doing engineering drawing homework, can you? As promoters of digital reform, programmers must embrace digital tools in an all-round way; they must have accumulated a lot of convenient drawing tools in their daily work.

So here I only recommend two that I use more:

Draw.io: this is an open source online drawing software, I believe many people have used it. Considering the problem of data security, it is recommended that you use a completely offline desktop version.

As a programmer-friendly drawing tool, the biggest advantage of draw.io is that it supports tripartite plug-ins, such as this open source c4-draw.io plug-in, which can help you more easily draw C4 model architecture in draw.io.

PlantUML: as a representative tool for text mapping, PlantUML can be used to draw various types of UML diagrams, as well as other maps suitable for text mapping scenarios (such as this open source C4-PlantUML extension).

In these scenarios, text mapping has incomparable advantages over visual mapping: light weight, high efficiency, versioning, automation, consistency, easy reuse and so on.

Although text drawing tools have been born for a long time (such as the widely used Graphviz, which was first released in 1991), it is believed that with the awakening of modern XXX as Code consciousness, such Diagram as Code tools will also be more popular (btw, Voice document already supports embedded PlantUML mapping).

Summary of Architectural Mapping Methodology

Gu Youyun: it is better to teach people to fish than to teach people to fish. By extension: it is better to teach people with methods than to teach people with methodology.

What is methodology? Although the word has been used badly in the company, it does have its value and meaning: methodology is a higher-dimensional abstraction of the method from which it can deduce a concrete way to solve the problem (method).

Only by understanding the methodology can you master the essential points of solving the problem, and you will no longer be limited to a single specific method, because you can get started quickly and flexibly with almost the same effect by using any method.

Therefore, the last chapter of this paper will summarize various architectural mapping methods and try to extract a general architectural mapping methodology, hoping to help people better understand the principles and ideas behind architectural mapping.

Even if the methods and tools we are familiar with will eventually become obsolete, we can still take a light look at their replacement between the old and the new: UML in the past, C4 now, what is the future? This is not critical, because even if the method is out of date, the methodology behind it will not be out of date.

So, what kind of core methodology is supporting behind those boundless methods? After nearly 15 seconds of painstaking meditation, the author finally summed up the following set of classical methodology (p.s: it is to make up the numbers, don't take it too seriously).

Since it contains five interlocking points, let's call it the five-ring theory.

Understand the goal of drawing

The first point of structural mapping is that you need to have a deep understanding of cartographic objectives. As the saying goes, "take the beginning as the end". Only with a goal can we move forward clearly; otherwise, if we run aimlessly, we will often take many detours or even go in the opposite direction.

What is the goal of architecture mapping? As a matter of fact, we have mentioned a lot in the previous article, so let's briefly summarize it here:

Accurate (accurate): wrong pictures are worse than none; even if they are accurate at first, proofreading needs to be updated regularly later.

Complete: need to cover the core elements and key information of the architecture to present a complete architectural design without imperfections to the audience.

Clear (clear): it is best to bring legends (shapes, colors, linetypes, arrows) when drawing; where the picture is not clear, you can add text marks as a supplement.

Consistent: for example, for the same type of graphics, it is best to use the same notation style to reduce the cost of understanding for the audience; inconsistencies often lead to confusion.

Consise: in addition to the above four points, we also need to make the diagram more concise, on the one hand, it is easier to be accepted (no one reads = does not write), and on the other hand, it is cheaper to update and maintain.

Find the right audience and concerns

The second important point of architectural mapping is to identify the audience (audience) and their respective concerns (concern) of your mapping.

If you are not sure, the effect will either be greatly reduced (not what they want to hear), or it will be like casting pearls before swine (they don't understand at all).

Some common audiences and concerns can include:

R & D: generally pay attention to a lot of implementation-related details, such as technology selection, implementation feasibility, maintainability, etc., after all, they are the most direct consumers of the architecture.

OPS: do not care much about the specific technology implementation in the application (as a black box), but are very concerned about the physical deployment, network connectivity, operation and maintainability of each application instance.

Security: only focus on whether the system has security risks, such as whether malicious code may be injected, whether there are permission vulnerabilities, etc. If you have experienced a security review, you should have a good sense of body.

Products: in most cases, we only care about whether the project can be launched on schedule, other aspects. You may show a little concern on the surface, but in fact you either don't care or you really don't understand.

Describe layer by layer from top to bottom

The third point of architecture mapping is the rational use of hierarchical (hierarchical) routines, from top to bottom layer by layer description.

Both the C4 model and the arc42 template are used profoundly and significantly behind this point. Why do we have to do this?

It contains two universal principles:

Divide and conquer: in the software field, divide and conquer is the most effective way to control and deal with complex systems. Hierarchical splitting is essentially a means of divide and conquer: according to the coarse to fine granularity, the system is divided into several relatively independent and low coupling elements (subsystems, applications, components, etc.).

Pyramid principle: the core idea of this book is to first throw out the main point of view and then demonstrate it with each sub-point of view in a top-down manner.

This way of communication is more in line with the logic of human thinking, but also easier for readers to accept. To put it simply, it is necessary to "get to the point first" to help readers summarize and draw key points, rather than throwing out a lot of bits and pieces for readers to digest and deduce.

Use multiple schema views

The fourth point of architecture mapping is to pay homage to the traditional engineering drawing methodology: use multiple architectural views to describe your architecture.

In the world of engineering drawing, any three-dimensional product, from machine tools to parts, needs to be described by at least three views (main view, top view, left view).

As a reflection of the real world, software systems are also multi-dimensional and three-dimensional, and it is impossible to cover all key architectural information with a single view; even if they are forced into one picture, it must be too complex to understand.

In the field of architecture design, the architecture view (architectural view) is specifically defined as a description of an aspect of the system architecture (aspect); each view covers one or more concerns of the project stakeholders.

As can be seen from the above definition, different architectural views have different priorities, and other details that have nothing to do with the current view will be omitted when describing what they are focused on.

In fact, this is also a kind of divide-and-conquer idea similar to hierarchical split, except that here it is aimed at the dimensional decomposition of the complete system, while hierarchical is to do top-down vertical drilling (drill-down) for a specific view.

The two are orthogonal and can cooperate with each other, such as the previously mentioned structural view, deployment view, and even dynamic view, which can be hierarchically split separately.

Follow specifications and best practices

The fifth point of architectural mapping is actually just the right nonsense: follow norms and best practices. This point is no longer limited to architectural drawing, but has risen to the level of general methodology in the field of engineering practice.

As mentioned in the previous chapter, "the goal of learning architecture drawing is to change it from a craft to a project."

Therefore, the "construction" process of structural drawing should also be in line with engineering thinking:

On the one hand, drawing needs to follow clear norms and carry out constraints and guidelines at the theoretical level to ensure the high quality and standardization of processes and products.

On the other hand, cartography also needs to follow the best practices of the industry, continuously absorb excellent experience at the practical level, and constantly refine the mapping skills of yourself and the team.

At this point, the study of "what is the method of architecture drawing" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.