What is software architecture?

What is software architecture?

In the early stage of last year's graduation, large and small enterprises came to the school to give lectures on the so-called software development career plan. Every company has its own characteristics, but in general, it is still divided into two lines: technology and management. I do not like management very much, so I only pay attention to the development of technology, most of which are like this: junior programmers --> intermediate programmers --> Senior programmers --> architects --> Technical Director, I have been developing smoothly, and now I am at the edge of senior programmers, based on the principle that "soldiers who don't want to be generals are not good soldiers", I should have a deep understanding of the architect, which is still mysterious, when I had no specific practice to interact with abstract theories, the company gave me a project of over 100 people and months in a timely manner, so that I could assume the role of a Technical Manager ,.

When you get to know something, the first step is to know the definition of this stuff. This is also true for the software architecture. After online queries and books help, I figured out a rough outline.

The software industry is an industry that is keen on making 'terminologies. If it is returned for 15 years, it is estimated that few people will know what 'Software framework' is. In the 1980s s, with the continuous expansion of software development, software development has become an industry. In the early stage, more and more software projects have failed, causing many causes of project failure, however, it is mainly concentrated in the development process, so software engineering came into being, and other process standards such as cmme are constantly emerging.

When software engineering began to take shape, software development still existed in the form of data structures and algorithms, and entered the last 10 years of the 20th century, with the successful application of object-oriented technology, design patterns, and so on in the development process, the software architecture has entered into everyone's field of view.

The software architecture is defined in the "Composition" and "decision-making" camps, which are described as follows:

The component school considers the software architecture to describe the system as a computing component and interaction between components. It has two distinct features:

• Focus on the object of architecture practice-software, with the software itself as the description object.
• After analyzing the composition of the software, it means that the software is not an 'atomicity, but a whole composed of different parts connected through specific interfaces, this is important for software development.

The decision-making school holds that the software architecture includes a series of decisions, including:

• Software System Organization
• Select the structural elements that constitute the system and the interfaces between them, and the actions that are embodied when these elements work together.
• How to combine these elements to gradually synthesize them into larger subsystems
• The architectural style used to guide the system organization: these elements and their interfaces, collaboration, and combinations

The software architecture focuses not only on the structure and behavior of the software, but also on other features: Use, functionality, performance, elasticity, reuse, understandable, economic, and technical constraints and trade-offs.

The decision-making school has the following two notable features:

• Focus on the entity-person in the software architecture, and take human decision as the description object.
• This paper summarizes the types of software architecture decision-making, and points out that architecture decision-making includes not only the Organization, elements, subsystems and architecture style of software systems, but also the decision-making of many non-functional requirements.

According to the 'composition conput', the software architecture focuses on the entire separation and interaction of the software. The reason is that different parts are logically or physically independent, the principle of "divide and conquer" can better understand the entire system and grasp users' needs. However, although the entire software can be divided into multiple modules or subsystems, however, communication and interaction between modules and subsystems are also very important. From this point of view, the architect's main task is to divide the software into different modules and define interfaces between modules.

According to the 'decision authorization', software is a product generated under many restrictions. These restrictions include user and technology, user requirements include functional requirements, performance requirements, and hardware requirements. Technical requirements include technical selection, scalability, reusability, and maintainability. I think from this point of view, the main task of the architect is to make choices or decisions based on the above constraints.

I don't think so, as to whether it is mutually exclusive between the 'composition pa' and the 'decision pa'. In fact, many cool people don't think it is like this (haha, I am also a bit cool), these two views should be in a different perspective to look at the software architecture, the architect in the division of modules, will have to make various decisions.

References:
Software Architecture Design