Architecture: talk about software architecture

Introduction

Every programmer has the dream of an architect in his heart. Architecture is so important that every programmer is talking about architecture. It seems that software without architecture has no soul. A programmer who does not want to be an architect is not a good one. The same as the code farmer.

So what exactly is the architecture? How did you get the architecture? Today this article will explain the views on the architecture from my own experience.

What is architecture

In the early stages of software development, there is no architecture. From the earliest assembly language to procedural language, they dealt with tasks one by one, for which one function was compiled to perform the corresponding task. At this time, the software programming language is still a procedural language, so there is no architecture.

With the maturity of hardware technology, more and more tasks can be handled. In order to handle so many tasks, programming languages have also changed from process-oriented to object-oriented, so as to better adapt to the development of tasks. The software becomes more and more complex, and more and more tasks need to be processed, which ultimately leads to the creation of the system architecture.

Architecture is produced in a complex software structure, and its task is to enable tasks in these complex software to cooperate with each other to complete common tasks. Of course, this is from the goal of the software. If you consider the implementation and scalability of the software, a good architecture needs to make the system more readable and scalable, leaving a certain amount of space for the future. In terms of reliability and availability, a good architecture also needs to ensure the system's high availability and fault tolerance.

What we should pay attention to is that the architecture does not come from a fantasy, its cornerstone lies in the written program. Therefore, the architecture needs to be closely integrated with the program to generate vitality.

The architecture of the system mainly describes the main components of the system and the relationship between these components and how they interact.

Key design principles of the architecture

In order to minimize costs, meet functional requirements, and maximize the scalability and availability of the system structure, we need to consider the following key design principles:

1. The principle of separation of concerns

The components of the system are divided according to specific functions, so that there is no duplication between the functions of the components. So as to ensure high cohesion and low coupling. This method avoids the interdependence between system components and helps simplify the system.

2. Single responsibility principle

Each module of the system should bear a specific responsibility, which helps users to understand the system clearly. It also facilitates the integration of components with other components.

3. Principle of Least Knowledge

No component or object should have access to the internal details of other components. This method avoids interdependence and improves maintainability.

4. Minimize the large-scale design in the early stage

If the requirements of the application are not clear, minimize the large-scale design in the early stage. Starting from a small prototype, confirm the needs in the exploration. Avoid the huge refactoring workload caused by changes in requirements in the later period.

5. Don't repeat functions

"Non-repetitive function" refers to not repeating the function of the component. A logical realization should only exist in a piece of code. If there are multiple copies of the code, then when the logic changes, the duplication of functions will make it difficult to implement changes, reduce clarity and introduce potential inconsistencies.

6. Prioritize composition over inheritance when reusing features

Inheritance will establish a dependency relationship between the child class and the parent class, so it will prevent the free use of the child class. On the contrary, composition provides a lot of freedom and reduces the inheritance hierarchy.

7. Define the communication protocol between different layers

To have a complete understanding of the deployment plan and production environment, so as to work out or use a suitable communication protocol.

8. Define the data format for interaction between components

Various components will interact with each other through data formats. It is best to unify the data format so that the application is easy to implement, expand, and maintain. By using the same data format, each component does not need to encode/decode data when communicating with each other. It reduces processing overhead.

9. System service components should be abstract

Code related to security, communication, or system services (such as logging, profile, and configuration) should be abstracted out in separate components. Do not mix this code with business logic, so that the extension design and maintenance will become easier.

10. Design exception and exception handling mechanism

Predefining exceptions helps components manage errors or unexpected situations in an elegant way. It is best to use the same exception handling mechanism throughout the system.

11. Naming convention

The naming convention should be defined in advance. They provide a consistent model that can help users easily understand the system. It is easier for team members to verify the code written by others, thus increasing maintainability.

Description of the architecture

Since the architecture is so important, what means can we use to describe the components in the architecture, the connections between the components, and their interactions? The industry has also explored many methods. Here we also introduce several methods.

UML

Everyone should be familiar with UML. Its full name is Unified Modeling Language, and it is a graphical language. The UML1.0 specification was proposed by the Object Management Group (OMG) in January 1997. It is used as a standard for software requirements analysis and design documents, which are the basis for developing software.

UML is a visual modeling language that contains many components, which are related in different ways to form a complete UML diagram. Although UML is usually used to model software systems, it is not limited to this scope. UML is also used to model non-software systems, such as processes in manufacturing cells.

UML is mainly divided into two categories: structure diagrams and behavior diagrams.

The structure diagram represents the static components of the system. These static components are represented by classes, interfaces, objects, components, and nodes. The structure diagram contains the following parts:

1. Class diagram: Represents the various classes in the object-oriented system and their relationships.
2. Object diagram: The object diagram represents the objects and their relationships at runtime.
3. Component diagram: The component diagram describes all the components, interfaces and their interactions in the system.
4. Composite structure: Describe the internal structure of the component, including all classes, component interfaces, etc.
5. Package: A package mainly contains classes and other packages.
6. Deployment diagram: A deployment diagram is a set of nodes and their relationships. These nodes are the physical entities where the components are deployed.

The behavior diagram represents the actions that may occur in the system, and the behavior diagram can include the following types:

1. Use case diagram: Describe the relationship between functions and their internal/external controllers. These controllers are called participants.
2. Activity diagram: describes the control flow in the system. It consists of activities and links. The stream can be sequential, concurrent or branched.
3. State diagram: indicates the event-driven state change of the system. It describes the state changes of classes, interfaces, etc.
4. Sequence diagram: Visualize the sequence of performing specific functions in the system.
5. Combine activity diagrams and sequence diagrams to provide an overview of the control flow of the system and business processes.

Architecture view

A view is a representation of the entire system from the perspective of a set of related concerns. It is used to describe the system from the perspective of different stakeholders (such as end users, developers, project managers, and testers). Here is a view mode called 4 + 1 for everyone.

The 4+1 view model was invented by Philippe Kruchten. This model describes the architecture of software-intensive systems based on the use of multiple views and concurrent views. It is a multi-view model that addresses the different functions and concerns of the system. It standardizes software design documents and makes it easy for all stakeholders to understand the design.

It contains 4 basic views, namely:

1. 逻辑视图或概念视图-它描述了设计的对象模型。    
   2.  流程视图-描述了系统的活动，包括并发和同步。     
   3. 物理视图-它描述了软件到硬件的映射并反映了其分布式关系。   
   4.  开发视图-它描述了环境开发中软件的静态组织和结构。

The last +1 view means adding a view called the solution view or use case view for the end user or customer. It is consistent with the other 4 views, so it is called the +1 view.

ADL

Architecture description language ADL is a language that provides syntax and semantics for defining software architecture. It is an annotation specification that provides functions for modeling the conceptual architecture of a software system, which is different from the implementation of the system.

Architecture description language is a formal specification language that describes software functions such as processes, threads, data, and subroutines, as well as hardware components such as processors, devices, buses, and memory.

to sum up

Today's structure talks will stop here, and I hope you can correct me if there are any problems. We will introduce several common architecture patterns in the follow-up. Hope everyone likes it.

This article has been included in http://www.flydean.com/06-software-architecture/

The most popular interpretation, the most profound dry goods, the most concise tutorial, and many tips you don't know are waiting for you to discover!

Welcome to pay attention to my official account: "Program those things", know technology, know you better!