Chapter III Building software flow

Software Design Flow 1. Feature List

First we need to understand what the software should do and then list the features

Three questions about architecture A. Is it part of the nature of the system?

Personal Summary: Is this part of the system must be required, if not what to do

B. What the hell does that mean?

Summary: If you don't know what the description of the feature means, it's important to focus on that function.

c. What should I do?

Summary: Find the part that you think you cannot achieve, that is, a specific problem you cannot handle, think carefully

2. Use case diagram use case Brief introduction

1. Use case diagrams require us to think about how the software will be used without the need for deep
2. Use cases reflect usability, function reflects functionality
3. The point is that we need to understand the differences and interrelationships between use cases and functions
4. Use cases need to change according to the real world, because the program runs in the real world

What can a use case do

1. Most of the nouns in use cases are converted into classes
2. Translating verbs into methods in use cases

What are the Use cases

Use cases are the process of thinking about your problems. Use cases can help us understand requirements

What primary path is required for use cases

1. The primary path is the main step in solving the problem logic
2. The primary path can have a replacement path.

Optional path

The optional path is the refinement under the main path

Replace path

Contains one or more steps, similar to plan B

Scene

The scenario is the full path from the first step to the last step through the use case

What the scene can do

Scenarios can help gather requirements, help identify use cases intact, reduce risk in the architecture, reduce confusion and confusion, and clarify what specific modules or program code do

Summarize

A scenario is an example of a system, such as a strategy game, moving a person to a certain location on a chessboard, which helps us understand without having to go into detail.

3. Problem decomposition X. Understanding Issue 4. Demand-oriented Approach requirements List text analysis

View nouns and verbs in use cases to sort out the actions of classes and methods called text analysis
Personal understanding: Identify the classes and methods required by the system from the use case description

How to get the demand

Using use cases to get demand, whenever a use case changes to check whether there are new requirements or the old requirements need to be changed

5. Domain Analysis

Combine everything in a game system in a way that customers can really understand

6. Preliminary Design 7. Implementation 8. Delivery

The next step is to use some knowledge in software development.

Iterative Introduction

First, for the overall contour operation, then iterate over each fragment of the application.

Start and end

Start with step 4th and end with step 7th. Between these steps, we are constantly circulating

Mode 1. Feature-Driven development

Select specific features of the application and plan, analyze, and develop the feature

2. Use case-driven development

Select the scenario for the use case and write program code to support the complete scenario through the use case

Summarize

1. 2 iterations are driven by good demand
2. 2 iterations focused on delivering what the customer wants

OO principle 1. Simple principle

1. To encapsulate the things that change.
2. Encode the interface, not the implementation
3. Each class in the application has only one reason to change
4. Class is about behavior and function.

2. OCP (open-closed Principle) opening and closing principle

Class should be open for expansion, prohibit closing for modification

Personal Summary

Is that the method can be overridden after being inherited. Of course, this method is written in the parent class. Inheritance is a simple implementation of the OCP examples and methods. The OCP principle can also be achieved by crafting.

Example

If you have many private methods, you can add some public methods that call these private methods in different ways

3. DRY (don ' t Repeat yourself Principle) No self-repetition principle

Extract common objects from a single place to avoid duplication of code

Personal Summary

This principle can also be applied to demand analysis to ensure the uniqueness of the requirements. Keep every information and behavior in the system in a single, reasonable place

4. SRP (single Responsibility Principle) sole Responsibility principle

Each object in the system should have a single duty, all

Check whether the SRP method is used

The class name is within the class method Itselfs. This method checks if the class method within the class is supposed to be by the class
Called, when the method has parameters, put the parameters in the class after the method, you can add a quantifier and the like

Personal Summary

The service of the object is focused on the realization of this responsibility, but also on behalf of cohesion, high cohesion refers to the application of the SRP good. The SRP usually makes the class larger, making your program classes rarely make the program much easier to manage and maintain.

5. LSP (Liskov Substitution Principle) Replacement principle

Subtypes must be able to replace their base types. If you inherit the parent class, but the subclass's method is completely different from the parent class, the subclass cannot replace the parent class, which violates the LSP principle

Personal Summary

A delegate is one of several alternatives to inheritance. A delegate or aggregation is a good way to fix a non-compliant LSP inheritance tree. The good use of LSP complements the entrustment, combination and aggregation

Chapter III Building software flow