Introduction to Software Design 1 architecture design

Love programming to be a good software designer!

Software design has some methods to refer to. But it is more important to have good demand analysis, a wealth of technical knowledge and design experience (more hands-on!) Constantly striving for a better spirit (multi-brain!) ）。

Meet other people's system to think about whether you can achieve, how to achieve?

First, the standard of excellent design: cost-effective design.

1) Excellent design is demand- driven , not familiar with the need to do out of the design is not reliable;

2) Excellent design should be the current team can understand to achieve , too ahead of the design project team do not come out, this design can only be furnished;

3) Excellent design should fully consider the current constraints , appropriate to make a balance, to ensure the achievement of the objectives of the project;

4) Excellent design to minimize the overall workload of the project, so that the whole project more controllable.

Second, the excellent design starts from the demand

Case challenge: Software design for attendance system:

A company to do an internal attendance system, hoping to achieve the following objectives:

1) Standardize employees ' commute, leave, work and other activities.

2) Easy to calculate employee's salary.

3) Easy to manage all kinds of paid holidays.

How to design this system?

Do a requirement analysis to ensure that there is no problem with the requirements analysis.

Analysis of requirements, first from the business perspective, and then from the perspective of Software Design analysis (5 steps):

1) Who will use this system? (List all possible users)

2) What functions are used by different people? (use case diagram)

3) What are the uncertain or non-specific demand points? (User scenario)

4) What are the requirements for technology? (Solutions for specific problems)

5) How to consider the approximate structure of the system? (deployment diagram, Component diagram, package diagram)

Need analysis not only to do 1th 2) step further analysis of the business (business process, business data ...) ）

Third, the software system is not wooden bucket type (software design is generally considered as a whole)

There is a relationship between user scenarios, such as the underlying data. Different user scenarios may use the same basic data, can not make the system into a wooden bucket (each more than one user scene to add a presentation layer, logic layer, database table), this will be very disgusting.

Common internal architectures for software:

This figure illustrates:

1) There is an association between individual user scenarios, not independent. Software design should be more from the perspective of business concepts, business processes;

2) There may be reusable and shared portions (common base information) between the interfaces of each user's scene;

3) Some classes in the business logic are inherently a whole.

Iv. "The sermon" of Software Design

1, Software design ideas:

1) by the top of the bottom: first assume that the software has been made, think good software external performance, from this backward software implementation method;

2) from the bottom: Consider the data structure of the program, first design the database, and then build the superstructure of the software;

3) have middle to top and bottom.

N-tier Architecture: take 4 layers as an example

A UML package diagram that represents a dependency between a virtual arrow between a package and a package.

The meaning is as follows:

1) Four layer architecture includes: presentation layer, logic layer, data access layer, data layer;

2) The presentation layer relies on the logical layer, the logical layer relies on the data access layer, and the data access layer relies on the data layer.

Dependency can make one of the following:

1) A needs to invoke the method of B, a depends on B;

2) The type of some parameters in a method is b,a dependent on B;

3) The return value type of some methods of a is b,a dependent on B.

How is the data passed between the layers (parameters? ) no! Save the data to the entity class, each layer depends on the entity class! ：

。

Entity classes: Typically, there are only classes with properties that do not have methods, and we typically place data for some business objects in an entity class. such as: The entity of the absence of the class (the name of the leave, leave and start date, leave category, leave reasons, etc.).

2, from the top down: first think clearly the presentation layer, and then think about the logic layer, data access layer, data layer implementation.

What part of the demand-driven design is driving the design? Look at the picture:.

This diagram expresses the meaning: 1 The software design must first have the correct demand analysis, needs to decompose the requirement into the use case, the business flowchart, the business concept diagram.

2) When designing different layers, the main dependencies are not the same.

3, from the bottom of the top:

。

4, there is the middle to up and down: (Usage: Performance layer is not moving, data layer changes. such as: Change SQL Server to Oracle)

Define entity classes and data-tier interfaces to implement interface functions at the database operations layer. The interface is the same for the logical layer.

Software architecture from the middle to the bottom.

This is not without drawbacks, and it is not possible to use the attributes of the database, such as possessed stored procedures, triggers, views, etc. in the database. The complexity and workload of the program are increased.

The skeleton of planning system--Architecture design

1, the software design needs at least 4 aspects of design: architecture design, database design, module design, user experience design.

Architecture Design: After the overall consideration of the requirements, from the macro-planning system of the various parts and the relationship between the parts;

Database design: After the system analysis of the business concept in the requirement, the database elements such as table and table relation and view are designed.

Module Design: The architecture design divides the system into several modules, and the module designs the specific design for some or a certain module;

User Experience Design: need to consider the software's overall mask planning, interface relations, text expression, software and user how to interact and so on. Designed from top to bottom.

2, do not "universal" architecture design

Consider the role of architecture design, the following software architecture design has the equivalent of no, that is nonsense:

Does not reflect the demand, does not reflect the particularity of the system!

The system architecture below has made the same mistake:.

3, architecture design is to consider "all requirements" after the made.

1), first list all requirements by use case diagram:

, where the focus of the analysis diagram needs to be focused.

。

Find the problem from the point of concern and propose a solution.

4. Progressive Disassembly Architecture Design

Not to solve the demand for the purpose of software design is bullying!

To illustrate the workflow:

1), Dead Workflow: The code is dead, the database design is dead, the process or form is changed by any changes, you may need to change the code and database design.

2), Half-life workflow: Part of the place is written dead, part of the place is flexible, can adapt to part of the demand change.

3), full live Workflow: Code and database design are flexible, can basically adapt to the process and form changes, do not need to modify the code or database design, as long as the configuration can be done.

Development design is best made easy to difficult.

　　Preliminary architecture design-first-level disassembly

For a specific project to do architecture design, can not be separated from the specific technical framework, you must first determine your development language, database type, and so on. Architecture design should be considered from the depth of physical design, not just theoretical design or logical design, otherwise it will be too empty ("universal" of the problem).

。

Summary of preliminary architectural design points:

1), the system involves the client and the server, we need to consider what the system needs the client and the server to do? This requires configuration properties for the client and server: System Properties, software properties, hardware properties, and so on.

2), client and server physical contact: LAN? Internet? Still is?

3), what software do we need to develop on the client and server? Equivalent to the first piece of software properties. The first article focuses more on hardware and its performance.

What we need to develop in this diagram are: webapplication, client software for workflow definition, three databases.

The first architectural design is divided into several parts of the system and the relationship between the parts.

　　continue in-depth disassembly-the second layer of disassembly (into each part of the first Division is divided again)

Take the Web application as an example to design in depth.

When analyzing the internal architecture of Web application and how they relate to each other, it is also necessary to consider what the appetite is for external interaction.

This graph highlights the connection between the modules inside the Web application module and the external modules, and the modules that are not connected to the external modules are hidden.

Subdivide to this step and begin to discover the issues that need to be addressed:

, a list of possible solutions to each problem, and specific issues to be considered by the programme.

Architectural Design Disassembly Summary:

　　1), the first layer of disassembly: to solve the "whole system is divided into several pieces, need to develop what software and database" problem.

2), second layer disassembly: deep into a module of the system, the division can be divided into several sub-modules, considering their relationship, which sub-modules are connected with the external module. You can refer to hierarchical schemas.

3), the "second layer disassembly" result can be a component, a code package, a hierarchy, and so on, may be "physical split", or "logical split."

What is the appropriate level of split? : If the disassembly goes down, the next disassembly is to the class, then you can think the current disassembly granularity is more appropriate. The disassembly to the class can be further considered in the module design.

　　

"Physical split" and "Logical Split":

Physical split: Explains the physically independent part, possibly EXE, DLL, database file, etc. The system can be physically split into 5 parts: The WEB application, the client software for the process definition, and 3 databases. When the Web application is further split, the calendar control is physically split, and the control is used in a binary way for the program to partially invoke it, and the control will be available to other systems in the future.

Logical split: A code package, a hierarchy these are often logical splits, and they are physically not compiled into a separate part, but are generally mutated into the software.

The purpose of "second layer dismantling" is to make the system more convenient, and another important purpose is to design the system reuse. Physical split-binary reuse; logical split-source code reuse. These reuse will facilitate other software development in the future.

5. Architecture design of distributed system and stand-alone system

Distributed systems often require us to deploy on more than one device, and the whole system will work properly after the parts need to be tuned.

The system architecture in front of this article is distributed architecture.

Introduction to Software Design 1 architecture design