Special perspective of software architects

We know that the process of software architecture is an abstract process. Generally, developers only perform abstract modeling of business needs from the development perspective, and strive to grasp every detail. Most architects come from the originalProgramPersonnel, so often appear to pay too much attention to some details, ignoring the establishment of the overall conceptual architecture. In most cases, this is because the architect has not switched from the development perspective to the architecture perspective.

 

In the process of software development, the software architect is in a very special position. On the one hand, the software architect needs to communicate with the user to collect and sort out the user's needs. On the other hand, the software architect needs to design the overall architecture of the software project, and finally ensure that the architecture design is feasible, and can be understood by developers. Although the above three points are to solve the same problem of software projects, it is clear that they need to be different perspectives. This is a very important and basic requirement for software architects-requiring architects to be able to look at the same issue from different perspectives.

 

Generally, software architects need to abstract projects from three basic perspectives: conceptual, normative, and implementation perspectives.

FirstConcept: This requires the architect to define the system, analyze the requirements, and establish a model from the user's perspective. In this model, we generally do not point out how each requirement is implemented, becauseThe user does not care about the specific process, but clarifies to the user whether the user's understanding of the needs meets the user's expectations, whether there are misunderstandings, and avoid risks..

The commonly used method of conceptual perspective is to drawUse case diagram or data flow diagram (DFD);

 

SecondNormative perspective: This perspective can also be thought of as a design perspective. At this time, the architect only relates to the interface definitions between systems and does not focus on implementation details.From this perspective, the architect divides the system into subsystems, modules, and other systems, and defines interfaces between them without focusing on how each module is implemented, do not even care about the platform used for project developmentSuch as C # or Java. Generally, through the definition and division of the module interface, and other auxiliary means, such as TDD, you can have a deeper understanding of the system, this is a repetitive process because of the unreasonable design, hidden coupling, and potential requirements found during the first design.

There are a variety of methods to achieve standardized view, such as using EXCEL to list modules (including module names, inputs, and inputs), but they are not related to the platform;

 

FinallyImplementation perspective: We know that all the designs must be put into practice.CodeDevelopment. The design result is often a UML class diagram, just like a design drawing, which usually has nothing to do with the actual development environment. If developers are not competent enough, they will be confused when looking at the design. In addition, as mentioned in the normative perspective, in the iterative design process, only class diagrams are usually difficult to find potential risks. Therefore, writing canCode that reflects design ideasIt makes sense. ThisOn the one hand, the design will not be separated from the specific development environment, on the other hand, it can also help current and future developers or maintenance personnel to better understand the design.

The implementation perspective usually refers to the sample code used to verify the design.

 

Summary: This article is a summary of today's advanced software architect training. You are welcome to leave your valuable comments!