software development life cycle

The Software Development Lifecycle (SDLC) is Life cycle of software from generation to retirement , specifically the following classical models:

Waterfall model

This model is also called "linear order model" or "traditional life cycle". The reason is shown in the figure above:

• It divides the whole process into specific stages, and the sequence is fixed.
• Each stage should have a clear output as the input of the next stage. If problems occur in the next phase, rework is required to return to the previous phase.

It is this kind of fixed and rigid process that the user has no opportunity to feedback and modify the requirements. Therefore, the requirements of the development project must be stable and the developers must be familiar with this development. Otherwise, if there is a slight change, the previous development will be invalid and all previous efforts will be wasted.

The waterfall type is easy to understand.

V type

It divides the whole development process into these stages: requirements analysis, outline design, detailed design, software coding, unit testing, integration testing, system testing, acceptance testing.

but These stages are not linear, but the corresponding relationship between left and right binding.

For example, when users propose requirements, they should also propose acceptance test criteria, that is, which test cases should be passed by acceptance tests.
When analyzing requirements, it is necessary to write the test cases required for the whole system test.

The V model emphasizes the importance of the test phase (grading the test and corresponding to the development phase), but still needs fixed requirements at the beginning, It does not change the waterfall. The stage is still serial, and the user has no chance to give feedback.

Incremental

The above two types of problems are still not solved, but the entire requirement is divided into several versions. Each version still works in a waterfall mode internally.

The advantage of this is that the workload and tasks of each version become smaller, and people's confidence will rise. For example, if you were asked to build an aircraft carrier at the beginning, you must quit. But the task is smaller. Let you build an aircraft carrier chassis first. You think it's OK.

Evolutionary type and fountain type

Both are Iterative 。 I don't think it makes any difference. The term evolutionary describes the overall classification of processes, while the term fountain only refers to the internal development process of each version. The core of iterative type is to solve the problem of unstable requirements at the beginning

Evolutionary type is applicable to requirements that are not particularly clear at the beginning. The demander is too retarded. I want to build a mall system, but I don't understand the details. So the programmer worked overtime to make the first version. Then the demander looked at it and said no, how can you do without advertisements in your mall, and there is no similar recommendation under your product, and the theme of the mall can't change with the mobile phone case (fog~), please change it for me.

So the programmer made the second version, and then there will be the third version, until the final version, the final version 2, the final version 3

in other words The requirements of each version are not determined at the beginning, but users look at the previous version, give feedback, and then propose the requirements of the next version, which is the biggest difference from the incremental version 。

Fountain type It talks about that in the process of iteration, each phase of the two versions can be parallel. （ This is also the second difference from the enhanced model The incremental version is waterfall, while the evolutionary version is fountain)

For example, in Version 1, the programmer's development process and the requirements in Version 2 can be carried out simultaneously, without being serial.

Spiral

have access to The spiral type is an updated version of the iterative type. Each version of it has been added risk analysis 。 And iterative The difference is that the development process of each version has been modified and improved.

Each version development is divided into four parts:

• draw up a plan
• risk analysis
• Implementation works
• Customer evaluation

prototype

There's always something to say Rapid prototyping Then let's go. I don't understand a lot of non human words. This is also a model of software life cycle???

What is a software lifecycle model? It defines every step and method of software development process. Prototype is just a method and a tool for obtaining customer requirements, and it does not involve subsequent development methods at all

The prototype tool can be combined with the iterative or spiral type above. Before the development of each version, make a prototype for the customer to see, so that there will be no talk between the donkey and the duck.

RUP

The full name is Rational Unified Process.
Translation is a unified process model.

In fact, I can understand a little bit from the name.

Several models we mentioned earlier mean that a project is divided into several versions, and then each version is divided into several stages. Although the fountain type allows a certain degree of parallelism, it is not completely parallel. For example, the development of version 1 and the testing of version 2 cannot be carried out at the same time, because the testing of version 2 depends on the development of version 1.

That is to say, there is a certain dependence and order between stages. The development contents of different versions are also different.

Unified process development, the whole development is divided into four versions (initial, detailed, construction, delivery), and the development content (phase) of each version is completely consistent , divided into:

• Business Modeling
• Requirements
• Analysis&Design
• Implementation
• Test
• Deployment
• Configuration&Change Mgmt
• Project Management
• Environment

In this way, each stage can be understood as a classification of the whole project work, because it exists in each version and continues in the whole project development process, but the proportion is different.

Reference link

Various software life cycle models (3) -- spiral, RUP

Similarities and differences between iteration and increment

Advantages, disadvantages and application scenarios of waterfall model, prototype model, fountain model and V model in software engineering

What is UML?

The full name is Unified Modeling Language, and the translation is Unified Modeling Language.

Since it is a language, it must have certain grammatical rules, and these rules express certain functions and meanings.

In short, UML is A graphical rule used to express the relationship between some components 。 At present, UML 1.4 defines 9 kinds of diagrams, each of which corresponds to one type of representation.

Speaking of which, what is UML? UML is a graphic language, not a common text language like java and c, and it consists of the following three parts

UML composition

UML basic building blocks

• Things can be understood as graphic symbols/elements, which graphic symbols are there, and what is the meaning of each graphic symbol

  • Technical elements: interface, active class, use case, collaboration, component, node, class, and object
  • Behavior elements: Interaction, Statemachine
  • Grouping element: Package represents the collection of some classes
  • Annotation element: used to add appropriate explanation parts to the UML model.
• The relationship between things, several graphic symbols need to be connected directly with lines. The dotted line or the solid line are both specified: association, generalization, realization, dependence
• Graph, graph=thing+relationship, graph itself can be regarded as a whole, and become a graphical symbol to connect with another graph

UML Rules

It is impossible for a diagram to have only diagrams without text descriptions. UML diagrams must include text descriptions, that is, they must have UML rules

• Naming: each graphic symbol must have a name
• Scope: similar to the scope of a class
• Visibility: Public, Protected，Private，Package

Public mechanisms

Changing the name is a public rule, which is applicable to every kind of illustration

• description
• Decoration: Each element in the UML notation has a basic symbol, and various decoration details can be added to this symbol. For example: + On behalf of public - On behalf of private # On behalf of protect, etc. Use italics to represent abstract classes.
• Extension mechanism

Learning Notes Components of UML Modeling Technology

UML Modeling Learning 1: Introduction to UML Unified Modeling Language

Classification of UML diagrams

After the above definition, let's talk about the construction rules of the nine UML diagrams in detail:

What is a UML diagram? What are the common UML diagrams?

Use Case Diagram

It is used to describe how users use a system. It is a model diagram of system functions that users can observe and use.

Constituent elements

• role
• Use Case (i.e. a function of the system)
• relationship

Class diagram

It is used to describe the classes in the system and the relationship between each class

component

The first layer is the class name, the second layer is the attribute, and the third layer is the method.

It needs to be noted here that you can add attributes and method names before Embellishment symbol , representing different visibility.

[Object Diagram] ()

The object graph describes the relationship between a group of objects, not the relationship between classes. It is a variant of the class diagram, but it is different from it. Means on At a certain moment Of these classes Specific instances and specific connections between these instances 。 (The object is the instantiation of a class)

component

The object's name should be underlined in the object's diagram. The object name has the following three representation formats:

• Object name: class name
• : Class name
• Object Name

Activity diagram

Essentially, it is a flow chart that describes the sequence of activities, that is, the control flow of the system from one activity to another
It is used to describe use cases and class operations

state diagram

Describe the possible states of an object and the transfer (A state is a stage of an object's life cycle, in which the object must meet some specific conditions and can engage in specific activities.)

Sequence diagram

Describe between objects Time sequence of message delivery , is used to represent the sequence of actions in the use case

Collaboration Diagram

By sending and receiving messages between objects Collaboration 。

Component diagram (component diagram)

It is used to describe the relationship between various components in the system to provide services. (A component is an entity that can provide some functions (interfaces). It is a physical concept.)

Deployment diagram

It describes the structure of the system runtime, and shows the hardware configuration and how the software is deployed to the network structure. One system model has only one deployment diagram Deployment diagrams are often used to help understand distributed systems.

Module independence

Three concepts are involved here: independence, cohesion and coupling of modules

Module independence is achieved by Coupling between modules and Cohesion of modules These two indicators reflect.

The higher the degree of cohesion within the module, the lower the degree of coupling with other modules. The greater the independence. So cohesion is positively correlated with independence, and coupling is negatively correlated with independence. Cohesion of modules refers to the aggregation relationship (correlation) of multiple functional blocks within a module, and coupling refers to the relationship between modules 。

cohesion

coincidental cohesion

Set function happens to have some duplicate codes. We create a new module to accept the duplicate codes. The internal relationship of this new module is coincidental cohesion (ABC is a different module)

Logical cohesion

Multiple modules will call a common module. This common module contains several functions. You can determine which function to use according to the passed in parameters. The cohesive relationship of this common module is Logical cohesion

time cohesion

A module has multiple functions, and all functions are executed in the same time period. The internal relationship of this module is time cohesion

Procedural Cohesion

Each part of a flowchart can be used as a process cohesion module

Communication Cohesion

Each function of a module uses the same input or produces the same output, then the internal relationship of the module is called Communication Cohesion

Functional Cohesion

A module realizes a general function, and the internal sub functions of the module are an indispensable part of the overall function

informational cohesion

It is a combination of multiple function cohesion modules. Select different functions according to different conditions. These functions are based on the same data structure 。 I personally believe that information cohesion is a subset of logical cohesion.

(From left to right, the cohesion becomes stronger)

coupling

Indirect coupling

There is no direct relationship between the two modules. The connection between them is completely realized through the control and invocation of the main module, which is called indirect coupling. The module independence of this coupling is the strongest.

Data coupling

Data exchange between two modules through parameters

Tag Coupling

Tag information (i.e. data of a data structure) is transferred between two modules through parameters

Control coupling

One module obviously controls the function of selecting another module by transmitting control information such as switches, signs, names, etc

External coupling

The relationship between two modules by accessing the same global external simple variable (not the data structure)

Public coupling

Both modules access the same public data environment (the public data environment can be the global data structure, shared communication area, and public memory coverage area)

Content coupling

One module directly accesses the internal data of another module

It can be seen that tag coupling is very similar to data coupling
External coupling is very similar to public coupling

(From left to right, the coupling becomes stronger)

software test

Black box testing and white box testing of software engineering

Black box test

• Equivalence class division
• Boundary value analysis
• Error conjecture
• Cause and effect diagram method

White box test

• Logical overlay
• Basic path test
• Control structure test

( The white box test is related to the internal content of the program, so the method name cannot be separated from the path, structure, and logic )

software design

Scope of function and control of the module

Modular Control range Including itself and all its subordinate modules This is fixed. You can directly use the Subordination It can be seen.

Modular Scope of action Means In module The scope of a decision. This judgment is humanized and changeable. For example, in the following figure, what is the scope of module B2? If we determine that the B2 module will affect the A and B modules, then its scope is A and B, but AB is obviously beyond the control of B2.

If the scope of a decision is included in the control scope of the module where the decision is located, the structure is simple; otherwise, the structure is complex.

Data Flow Diagram and Data Dictionary

Data flow diagram (4 parts)

• data stream
• machining
• data storage
• External Entity

Data dictionary (5 parts)

Data flow term, data element term, data file term, processing term, external entity (5 parts)