Summary of framework module design experience

I haven't written any logs for three months, so I'm lazy ...... Preparing for the B/s version of OEA in the second half of the year is complicated and requires careful starting from the architectural design. Today is the time for reflecting on the department. Today, we will summarize some of the original design experiences to facilitate future review.

This log is used to summarize some framework-level module design experience.

 

Overview

 

A large framework must consist of multiple independent subsystems/submodules. How these sub-modules interact and how interfaces are defined between them are the architectural design of the framework. Today I will summarize how to design a sub-module. (For example, there are these relatively independent modules in OEA: distributed framework, Entity Framework, interface generation framework, command framework, product line framework, distributed cache framework, report module ......)

When I design a module, the process is roughly as follows:Pre-design stage, logic design stage, design review, design adjustment stage, design implementation stage, module integration stage. In a separate design, it is not necessary to go through each of the above stages. For example, when the module is relatively simple, there is no need for design review, design adjustment, and other stages. I will describe them one by one.

 

 

Pre-design phase

 

Before the design starts, we need to do a lot of work for the design. Its main goal is to collect and sort out the module requirements, and strive to describe the requirements in a structured manner. These requirements mainly include: Scenario requirements, quality attribute requirements, and environmental constraints. This process is very important for the subsequent design process, and the reasons are also obvious.

Scenarios: Framework users' functional requirements for modules, 70% scenarios, 20% scenarios, 10% scenarios, and API requirements.

Quality attributes: see ISO 9126. Key quality attributes should be analyzed here.

Environmental constraints: technical constraints, system environment, etc. It is common to have compatibility with the original system.

Depending on the complexity of the module, the duration of this phase may vary greatly. For example, the interface generation framework is the core module in the OEA framework. Before the design of its 2.0 version, we will constantly collect the shortcomings and shortcomings of the previous version, after finishing and structuring these messy demands, this job is "informal" for a year, and these times can be considered in the pre-design phase.

The final deliverables are: module Requirement Specification. Of course, this document is mainly used for communication and teaching. Depending on the situation, this is not necessarily necessary. However, if there is a formal review meeting later, it is best to prepare a formal document.

 

 

Logic Design Phase

Key points: Scenario-driven design, quality attribute verification design, and environment constraint verification design. The former performs addition, and the latter performs subtraction.

The more experience the designer has, the more chance to succeed at this stage. To satisfy a set of key quality attributes, if you have never encountered similar problems before, you may feel that your design can be implemented, but the final facts are often incorrect. And the design is not as strict as the mathematics, more like art, what art depends on, inspiration! Therefore, at this stage, different designers may have different designs. (Of course, if this module is relatively simple, there may be no difference in design. After all, there are many existing software design models .)

The main logic design method is drawing. The design is mainly based on some general design principles.

What is it? It mainly involves two types of diagrams in UML: static structure diagram (package diagram and class diagram) and dynamic structure diagram (sequence diagram ).

By the way, many designers may sit next to a computer and draw pictures using tools such as ea. However, my personal favorite method is:

1. Draw some manuscripts with paper and pen.
   This method is mainly convenient and can be painted in any place, for example, when opening some unimportant meetings, you can easily draw. Finally, I looked at many useful manuscripts and felt very fulfilled, just like a painter ~ Haha.
2. Image anytime:
   In my opinion, some complex designs are not simple to come up with. In particular, I think my IQ is only within the scope of ordinary people's IQ. I want to come up with some excellent designs, it's impossible to just sit in the office for a little time. (I remember coming up with something I couldn't think of while I was awake ......)
3. Summarized into a formal design draft.

Deliverables: UML diagram! This is required!

In this phase, we mainly consider quality attributes and key requirements.

To improve the capabilities at this stage, I recommend several famous books: Pattern of enterprise application architecture, Microsoft application architecture guide, and enterprise solution patterns using Microsoft.. net.

 

 

Design Review

Reasons for holding design review meetings:

1. No one is perfect. My personal thoughts may be wrong.
2. Hear from more experienced people.
3. Team collaboration and team communication.
4. Listen to the suggestions of the module users.

Therefore, we recommend that you hold a review meeting if it is not 100,000 urgent!

The review meeting I hosted has encountered many problems. You can refer to my reflection: Reflection-in-group design review meeting. Do not make the same mistakes as me.

 

 

Design adjustment phase

No. Check the conclusion of the review meeting. Either make small adjustments, make major changes, or even redesign. If the changes are large, don't forget to hold another review meeting.

 

 

Design implementation phase

This stage includes the designCodeVerification phase.

Because the company's organizational structure is different, this stage may not be completed by the designer. However, it is not surprising that I do not want to be completely done by others. The design is just like my own child. If you have worked hard to raise it, Do you want others to raise it? If you think you have to design too many things and don't have time to complete them, I think you should do less and do better.

It is recommended that design engineers with weak or even no practical skills do not need to design any more. First, we should refine the bottom layer. Designer fromProgramAs architects grow from designers, this is a practical approach!

This stage tests the code implementation and team collaboration capabilities of the designers. The implementation ability of code often truly shows a person's design ability. The software design principles are all described. However, it takes time to apply these principles to code implementation. If there are several tech-obsessed people in the development team, that would be the best thing.

Compared with the design draft, the implementation can have more flexibility and does not necessarily meet the design draft 100%. This is because the code implementation itself is a micro-design. However, more than 80% of the requirements must comply with the design draft. If too many parts do not match the original design draft. Please: hold a discussion meeting! Redraw to describe the current design! Summary and reflection!

It is worth noting that the implementation stage should focus on 721 Analysis of application scenarios, design good APIs to deal with these scenarios, and configure corresponding unit detection. Let's take a look at the scenario-driven design in the framework design.ArticleRecommended books: Framework Design Guidelines 2nd edition.

 

 

Module integration stage

In fact, the work in this stage needs to be prepared in the previous stage. That is to say, during coding, we need to constantly consider whether the designed code can run in a large environment. Whether the designed interface can be correctly connected to the current system. If the previous code is not considered enough, some integration problems may occur in this integration phase. However, I have encountered a small number of such cases, so I will not proceed here.

After this stage is completed, it is best to match the integration test. (I have not done it yet .)

 

 

Considerations of the evolution Module 

After the architecture design of the entire framework is completed, the involved modules are divided into two categories: one is the modules that have been taken into account and clearly defined during the architecture design; the other is that the initial design of the architecture is not taken into account, but as the system evolves, it is found that the modules must be added.Evolution Module". The design of the two modules has many similarities. More things need to be considered when designing the evolution module.

For the evolution module, in the pre-design phase, the constraints must specify the compatibility constraints of the historical system on the current module. In the design phase, you need to analyze the current system and find a breakthrough.

Compatibility is a troublesome constraint. To satisfy this constraint, simple design is often complicated. The final Code may also be incorrectly written. In future versions, if you make a decision that is no longer compatible with the historical Code, these compatibility designs need to be deleted.

 

 

Common Causes of design failure 

 

1. The pre-design phase is inadequate.
   Without collecting scenarios, entering the logic design stage early, or even starting Code directly, the unnecessary part of the final design may not meet the requirements at all.
2. Too confident, no review meeting was held.
3. Insufficient design experience. (Experience and inspiration are required for logical design)
   Improvement Solution: Draw out more existing systems. Are architecture and design patterns familiar? Do you need to design more things during off-work hours? Are there too few books?
4. The encoding capability is not strong. (Code implementation requires real experts .)
   Improvement Solution: Do I write boring code every day? How much does the non-work time spend on code? Reading too many books?
5. Logic Design and code implementation are divided into two waves.

 

Summary

 

This article is based on my current design experience and may be updated in the future ......

At the same time, we hope that our friends can exchange design experience. We hope that platform developers can communicate with me about platform-level development.

You can send me text messages and exchange QQ and email messages.