Introduction to the

Every programmer has an architect’s dream. Architecture is so important that every programmer talks about architecture, as if software without architecture has no soul, and a programmer who doesn’t want to be an architect is not a good coder.

So what exactly is architecture? How did the architecture come about? Today, this article will explain the view of architecture from my own experience.

What is architecture

In the early days of software development, there is no architecture. From the earliest assembly languages to procedural languages, they deal with tasks one by one, so a function is programmed to perform the corresponding task. The software programming language at this time is still a process language, so there is no architecture.

With the maturity of hardware technology, more and more tasks can be handled. In order to deal with so many tasks, programming language has also changed from process-oriented to object-oriented, so as to better adapt to the development of tasks. The more complex the software becomes, the more tasks it has to handle, and ultimately the system architecture is born.

Architecture is born out of complex software structures, and its task is to make the tasks in these complex software work together to accomplish common tasks. This, of course, is the goal of the software. If you consider the implementation and extensibility of the software, then a good architecture needs to make the system more readable and extensible, leaving some room for the future. In terms of reliability and availability, a good architecture should also ensure high availability and fault tolerance of the system.

It is important to note that architecture does not come from the sky; its foundation is the program you write. So the architecture needs to be tightly integrated with the program to be viable.

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

Key design principles for the architecture

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

  1. Separation of concerns principle

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 degree. This approach avoids the interdependence between system components and helps simplify the system.

  1. Principle of single liability

Each module of the system has a specific responsibility, which helps the user understand the system clearly. It also facilitates the integration of components with other components.

  1. Principle of least knowledge

No component or object should acquire the internal details of another component. This approach avoids interdependence and improves maintainability.

  1. Minimize large design upfront

Minimize large up-front designs if the requirements of the application are unclear. Start with a small prototype and identify requirements as you explore. Avoid heavy refactoring later due to requirements changes.

  1. Don’t duplicate functions

“Do not repeat functionality” means do not repeat the functionality of a component, a logical implementation, should only exist in a piece of code. If there are multiple copies of the code, the duplication of functionality can make it difficult to implement changes when the logic changes, reducing clarity and introducing potential inconsistencies.

  1. Prioritize composition over inheritance when reusing functionality

Inheritance creates dependencies between subclasses and superclasses, thus preventing the free use of subclasses. In contrast, composition provides a great deal of freedom and reduces the inheritance hierarchy.

  1. Define the communication protocol between the different layers

Have a complete understanding of the deployment scenario and production environment to develop or use appropriate communication protocols.

  1. Define the data format for interactions between components

Various components will interact with each other through data formats. It is best to unify data formats so that applications are easy to implement, extend, and maintain. By using the same data format, the components can communicate with each other without having to encode/decode the data. It reduces processing overhead.

  1. System service components should be abstract

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

  1. Design exceptions and exception handling mechanisms

Define exceptions in advance to help components manage errors or unexpected conditions in an elegant way. It is best to use the same exception handling mechanism throughout the system.

  1. Naming conventions

Naming conventions should be defined in advance. They provide a consistent model that helps users easily understand the system. Team members are more likely to validate code written by others, thus increasing maintainability.

Description of the architecture

Given that architecture is so important, what means can we use to describe the components in the architecture, their relationships, and their interactions? The industry is also exploring many approaches. Here we also introduce some methods.

UML

All of you are familiar with UML. Its full name is Unified Modeling Language (UML). It is a graphics 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 that are related in different ways to form a complete UML diagram. Although UML is commonly 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 a manufacturing unit.

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

Structure diagrams represent the static components of a system. These static components are represented by classes, interfaces, objects, components, and nodes. The structure diagram consists of the following sections:

  1. Class diagram: Represents the classes and their relationships in an object-oriented system.
  2. Object diagram: An object diagram represents objects and their relationships at runtime.
  3. Component Diagram: A component diagram describes all the components, interfaces, and their interactions in a system.
  4. Composite structure: Describes the internal structure of the component, including all classes, the interface of the component, etc.
  5. Packages: Packages are mainly packages that contain 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 possible actions in the system. The behavior diagram can include the following types:

  1. Use case diagrams: Describe functions and the relationships between their internal/external controllers. These controllers are called actors.
  2. Activity diagram: Describes the flow of control in the system. It consists of activities and links. The stream can be sequential, concurrent, or branching.
  3. State diagram: Represents event-driven state changes for the system. It describes state changes for classes, interfaces, and so on.
  4. Sequence diagram: Visualize the order in which specific functions are performed in a system.
  5. Combine activity and sequence diagrams to provide an overview of the control flow of systems and business processes.

Architectural 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’s a view mode called 4 + 1.

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 documentation and makes the design understandable to all stakeholders.

It contains four basic views, which are:

1. Logical view or conceptual view - This describes the object model of the design. 2. Flow view - describes the activities of the system, including concurrency and synchronization. 3. Physical view - it describes the mapping of software to hardware and reflects its distributed relationship. 4. Development view - This describes the static organization and structure of software in environment development.

The final +1 view represents the addition of a view for the end user or customer called the scenario view or use case view. It is consistent with the other four views, so it is called the +1 view.

ADL

Architecture Description Language (ADL) is a language that provides syntax and semantics for defining software architectures. It is an annotation specification that provides the capability to model the conceptual architecture of a software system, as opposed to the implementation of the system.

An 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.

conclusion

Today’s framework ramble to stop here, there is not living place also hope that we can point out. A few common architectural patterns will be introduced later. I hope you like 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, many you do not know the tips to wait for you to discover!

Welcome to pay attention to my public number: “procedures those things”, understand technology, more understand you!