Software Engineering - Summary of Exam Key Points

overview

• What is software engineering? is to use engineering methods to develop software

• The goal of software engineering: to create good enough software

• Definition of Software Engineering: Software engineering is an engineering discipline that guides the development and maintenance of computer software. Use engineering concepts, principles, techniques and methods to develop and maintain software, combine time-tested and proven correct management techniques with the best technical methods currently available, in order to economically develop high-quality software and effectively maintain it.

• The software engineering process refers to a series of related activities in order to achieve a specific goal in the life cycle

• Software engineering methods include software development methods, software measurement methods, software management methods and software environment methods

• Software = program + data + document

• Essential characteristics of software: complexity, variability, invisibility, consistency

• Software Crisis: A series of serious problems encountered in the development and maintenance of computer software

• Software development process: problem definition, requirements development, software design, software construction, software testing

• Software life cycle: feasibility study and project development plan, requirements analysis, outline design, detailed design, software construction, testing, maintenance

 

waterfall model

Suitable for software project development with clear and complete user requirements and no major changes

It is a document-driven model. After the completion of each stage of the task, the corresponding document is generated

Review the work implemented for each activity , emphasizing the stages of development, early planning and demand investigation, and product testing

Disadvantages: Since it is an ideal linear development model, it cannot solve the problem of unclear or changing requirements

 

rapid prototyping model

It is suitable for many situations where the user cannot give a complete and accurate description of the requirements, or the developer cannot determine the effectiveness of the algorithm, the adaptability of the operating system, or the form of human-computer interaction. It can be quickly built according to a set of basic needs of the user. a prototype

Step 4: Quick Analysis

Construction prototype

Run and evaluate prototypes

Modifications and Improvements

incremental model

A model for incrementally developing progressively refined software releases. Modularize the software system to be developed, treat each module as an incremental component, and analyze, design, code and test these incremental components in batches

Incrementally add features with each new release until full functionality is built

 

 

advantage:

• The entire product is decomposed into many incremental components, which developers can develop step by step.

  • Submit products that can complete part of the work to users in a short period of time, and submit them in batches and gradually. Users can do useful work from the day the first artifact is delivered.

• Developing in units of components reduces the risk of software development. Errors within one development cycle do not affect the entire software system.

• The development sequence is flexible. Developers can prioritize the implementation order of components, and complete the core components with stable requirements first. When the priority of components changes, the implementation order can be adjusted in time.

• Gradually increasing product functions can allow users to have more time to learn and adapt to new products, thereby reducing the impact that a brand new software may bring to the customer organization.

difficulty:

• When integrating each new incremental component into the existing software architecture, it must not destroy the products that have been developed originally. In addition, the software architecture must be designed to facilitate expansion in this way, and the process of adding new components to existing products must be simple and convenient, that is, the software architecture must be open.

• Developers should regard the software system not only as a whole, but also as independent components, which are contradictory. Multiple components are developed in parallel, and there is a risk that they cannot be integrated.

• Using the incremental model requires more careful design than the waterfall and rapid prototyping models, but the extra effort in the design phase will pay off in the maintenance phase.

spiral model

• Suitable for large complex systems,

• risk driven

• The spiral model combines the waterfall model and the incremental model, adding risk analysis

• The basic idea of ​​the spiral model is to reduce risk

Can be seen as a rapid prototyping model that adds risk analysis process before each phase

The spiral model divides the development process into planning, risk analysis, implementation engineering, and customer evaluation

fountain model

Mainly used to support object-oriented development process, iterative

Driven by user needs and driven by objects

iterative model

Submit a complete system at the beginning, and supplement and improve the functions of each subsystem in subsequent releases

 

 

RUP (Rational Unified Process, unified process model)

• RUP repeats a series of cycles, each cycle ending with a product delivered to the user.

• Each cycle is divided into four phases : initiation, refinement, construction, and handover , and each phase is iterated around nine core workflows.

• Core Support Workflows: Environment, Project Management, Administration and Change Management

• Core Process Workflows: Deployment, Testing, Implementation, Analysis and Design, Business Modeling

1. Initial Phase : Perform problem definition, determine the scope of the target system, assess its feasibility, and reduce key risks. **Equivalent to the planning period in the three-segment lifecycle model.

2. Refinement stage: mainly complete domain problem analysis and software design, configure various resources, and establish system architecture (including various views).

3. Construction phase: This phase is the manufacturing process of the product, focusing on system implementation and testing, focusing on managing resources and controlling operations to optimize cost, schedule, and quality.

4. Handover phase: * *Product launch, installation, user training. **The focus is on making sure the software is usable to the end user.

Features: risk-driven, architecture-centric, iterative, and configurable software development process based on UseCase technology

agile development

With the characteristics of people-centered, cyclic iteration, and response to changes, we focus on high-quality and rapid delivery of working software that satisfies customers

The development process is code-centric, not document-centric

Agile development divides the entire software life cycle into multiple small iterations (2-4 weeks). Each iteration is a small waterfall model, and a stable and verified software version must be generated at the end

extreme programming

A flexible approach to software development with coding at its core

The goal of XP : to convert vague and changing user needs into software products that meet user requirements in the shortest possible time

The difference between RUP and XP:

RUP is oriented to the management level, and XP is oriented to the implementation level. The two are complementary and complementary to each other.

Only under the RUP management framework can XP be adopted in the iterative implementation process and play the "fast" role of XP

feasibility study

Technical Feasibility, Social Feasibility, Economic Feasibility

Three conclusions: feasible, basically feasible, not feasible

Software Requirements Analysis

• Business needs

• User needs

• system requirement

• Functional Requirements

Process: requirements acquisition—>analysis and modeling—>document writing—>requirements verification—>requirements change

UML

constitute

Views: use case view, design view, process view, implementation view, deployment view

picture:

• use case diagram

• Static diagrams: class diagrams, object diagrams, package diagrams

• Behavioral diagrams: state diagrams, activity diagrams

• Interaction diagram: sequence diagram, cooperation diagram

• Implementation Diagram: Component Diagram, Deployment Diagram

Model elements: base elements, stereotype elements

general mechanism

use case diagram

 

relationship between use cases

1. Include

　　The containment relationship means that a use case can simply contain the behaviors of other use cases, and use the behaviors of the use cases it contains as part of its own behavior. In UML, the containment relationship is represented by a dotted line segment with an arrow plus the word <>, and the arrow points from the base use case (Base) to the included use case (Inclusion).

　　When dealing with the containment relationship, the specific method is to abstract the common parts of several use cases into a new use case. There are two main situations that require the use of containment relationships:

• First, if multiple use cases use the same behavior, you can abstract this common behavior into a single use case, and then allow other use cases to include this use case.

• Second, when a certain use case has too many functions and the event flow is too complex, we can also abstract a certain event flow into a contained use case to simplify the description.

　　

　　

1. expand

　　Under certain conditions, new behaviors are added to existing use cases, and the obtained new use cases are called extension use cases (Extension), and the original use cases are called base use cases (Base), and the relationship from extension use cases to base use cases is the extension relationship . A base use case can have one or more extension use cases, and these extension use cases can be used together.

3. Generalization

　　The generalization of a use case means that a parent use case can be specialized to form multiple sub-use cases, and the relationship between the parent use case and the sub-use cases is the generalization relationship. In the generalization relation of the use case, the child use case inherits all the structures, behaviors and relationships of the parent use case, and the child use case is a special form of the parent use case. Sub-cases can also add, override, and change inherited behavior. In UML, the generalization relationship of a use case is represented by a triangular arrow pointing from a child use case to a parent use case.

　　Generalized example: There are two ways of bank deposits, one is bank counter deposit and the other is ATM machine deposit. Here, bank counter deposits and ATM machine deposits are both special ways of depositing, so "deposit" is the parent use case, and "bank counter deposits" and "ATM machine deposits" are child use cases.

example:

Class Diagram

The main purpose of the class diagram is to reflect the structure of the class (attributes, operations) and the relationship between the classes. It describes the structure of the software system and is a static modeling method.

The "class" in the class diagram corresponds to the concept of "class" in the object-oriented language, which is an abstraction of things in the real world

specification

1. Lowercase the attribute name of a single word.

2. If the attribute name is composed of multiple words, then combine the multiple words, except for the first word. Capitalize the first letter of other words.

3. The syntax of the attribute: VisibilityName:Type=DefaultValue[ConstraintCharacteristics]

• Visibility indicates whether the attribute is visible to elements outside the class. Commonly used are public (+), protected (#) and private (-).

• Name indicates the name of the attribute, which is a string.

• Type defines the kind of attribute (basic type or custom type)

• The default value represents the initial value of the property.

Constraint property representations describe constraints on attributes.

things in the class diagram

(one type

1. It is divided into three parts from top to bottom, which are class name, attribute and operation. class name is required

2. If a class has attributes, each attribute must have a name, and it can also have other description information, such as visibility, data type, default value, etc.

3. If the class has operations, each operation also has a name, and other optional information includes visibility, parameter name, parameter type, parameter default value, and type of return value of the operation, etc.

(2) Interface

A set of operations, only the declaration of the operation but no implementation

(3) Abstract class

Classes that cannot be instantiated generally contain at least one abstract operation

(4) Template class

A parameterized class that binds template parameters to different data types at compile time, resulting in different classes

3. The relationship and explanation in the class diagram

(1) Association relationship - describes the relationship between the structure of the class. Has information such as direction, name, role, and multiplicity. General association semantics are weak.

There are also two strong semantics, namely aggregation and combination

1. Aggregation relationship - special association relationship, indicating the relationship between an aggregate (whole) and its components

   

2. Composition relationship - aggregation with stronger semantics, part and whole have the same life cycle

(2) Generalization relationship——※In object-oriented, it is generally called inheritance relationship, which exists between parent class and subclass, parent interface and subinterface

(3) Implementation relationship - corresponding to the relationship between classes and interfaces

(4) Dependency - ※ describes the situation in which a change in a class has an impact on classes that depend on it. There are many forms of expression, such as binding (bind), friend (friend), etc.

example:

State diagram

Describes the sequence of states that objects go through in response to events during their lifetime, and their responses to those events.

Flowchart

Sequence diagrams are used to represent the sequence of actions in a use case. Each message in the sequence diagram corresponds to a class operation or event that causes a transition in the state machine when executing a use case behavior.

 

 

Collaboration diagram

A collaboration diagram is an interaction diagram that emphasizes the organizational structure between objects that send and receive messages , and uses a collaboration diagram to illustrate the dynamics of the system.

activity diagram

example:

Object Oriented Software Engineering Method

• Object-Oriented Analysis (OOA)

• Object-Oriented Design (OOD)

• Object-Oriented Programming (OOP)

• Object Oriented Testing (OOT)

To develop software with the object-oriented method, it is usually necessary to establish three kinds of models:

• A functional model that describes the functionality of the system

• An object model that describes the data structure of the system

• A Dynamic Model to Describe the Control Structure of a System

software design

Software design includes two parts, one is structural design and the other is detailed design.

• System structure design (architectural design) is also called overall design or outline design. (including data/class design, software architecture design, interface design)

• The procedural design of the system is also called detailed design (including component-level design)

Outline design (overall design, structural design):

Including the overall design document of the system and the outline design document of each module. On the basis of the requirements specification, describe the system architecture, division of functional modules, definition of module interfaces, user interface design, database design, etc.

Detailed design (process design):

According to the module division based on the outline design, realize the algorithm design of each module, realize the refinement of user interface design, form, required data, and data structure design, etc.

object-oriented design

The main features are: easy maintenance

data persistence

Two ways:

• Database Management System (DBMS)

• file storage mode

MVC structure

Model object

View (VIew) object

Controller (Control) object

 

Object Oriented Detailed Design

It mainly describes each class in the component in detail, including:

• Data Structure Design of Attributes

• method design

• The design of the mechanisms needed to implement the interface

Program flow chart

 

example:

 

NS diagram (understand)

 

Judgment table

 

decision tree

 

note

Divided into:

• Preamble comments (at the beginning of the program), including:

  1. program title;

  2. A description of the function and purpose of this module;

  3. main algorithm;

  4. Interface description: including calling form, parameter description, subroutine list;

  5. Relevant data description: important variables and their uses, constraints or restrictions, and other relevant information;

  6. Module location: in which source file, or which software package it belongs to;

  7. Development resume: module designer, reviewer, review date

• Functional comments (in program body)

Explain what a program or statement does

the data shows

 

When multiple variable names are declared in one statement, the variables should be listed in alphabetical order.

software test

Software testing runs through the entire life cycle of software development

Testing can only find bugs in the program, but when no bugs are found, it cannot prove that there are no bugs in the program.

Finding bugs is not the ultimate goal of software testing. The fundamental goal of the testing phase is to find as many hidden errors in the software as possible, and finally deliver a high-quality software system to users.

The purpose of software testing is to find and correct errors and defects in software, design appropriate test cases, and use as few test cases as possible to find as many software errors as possible

Classification:

• Unit testing (testing of program modules for correctness) (unit)

• Integration testing (incremental integration method and non-incremental integration method) (partial)

• System Test (Overall)

• Acceptance testing (must have active user participation, or user-focused testing) (user participation)

 

The process of analyzing a software product is called static testing , and the testing process of running the software is called dynamic testing .

Verification ensures that the product is correct, and validation ensures that the correct product has been produced.

 

static test

Confirm program correctness by means of manual analysis or program correctness proof.

Desk inspection, code triage, walk inspection

Dynamic Testing

Verify the dynamic behavior of the software and the correctness of the running results by inputting data, running the software, and observing the execution status and results

White box testing (known internal working process of the product):

 

Black box testing (known product functionality)

Equivalence Taxonomy: Regardless of the internal structure of the program

Boundary value analysis method (select exactly equal to, just greater than or less than the boundary value as the test data)

Bad Guessing: Empirical

Cause-and-effect graph method (describing the combination of multiple input conditions, correspondingly generating multiple actions to design test cases, and finally generating a decision table)

Integration Testing

Non-incremental test:

Adopt a one-step method to integrate the system. On the basis of unit testing each module, assemble all modules together according to the design requirements

Incremental test:

Top-down combination: no need to write driver modules, only need to write stub modules

Bottom-up combination: only need to write the driver module

Alpha testing and beta testing

• Alpha test: The developer simulates users to test the software product that will be launched soon. Developers need to record the errors found and problems encountered in use. The test is carried out in a controlled environment.

• Beta Testing: Conducted by end users of the software at one or more customer sites. Beta testing is the "real" application of software in an environment beyond the developer's control. Users record all problems (real or imagined) encountered during beta testing and report these problems to developers on a regular basis. After receiving the problems reported during beta testing, the developer makes necessary changes to the software product and prepares to release the final software product to all customers

Regression Testing

• Regression testing is a testing activity used to ensure that changes due to debugging or other reasons will not lead to unexpected software behavior or additional errors.

• Regression testing refers to re-executing a subset of tests that have already been done to ensure that changes do not have unintended side effects.

object-oriented testing

Strategy:

• Intra-class test: equivalent to unit test, including method test and class behavior test in the class.

• Inter-class testing: equivalent to integration testing, it should be assembled according to the relationship between classes, including independent classes and dependent classes.

• Scenario-based testing: equivalent to confirmation testing and system testing.

White box testing and black box testing methods are also applicable to object-oriented testing

Software debugging

Debugging is the process of troubleshooting errors after testing finds them

method:

• Brutal method --- point-by-point (single-step) tracking

• Backtracking --- backtracking from the point of error along the flow of control

• Elimination of Causes --- Binary Search, Induction and Deduction

Software maintenance

Documentation is the determining factor affecting software maintainability

Maintenance process:

 

type:

• Corrective maintenance (in order to identify and correct software errors, correct defects in software performance, and eliminate misuse in implementation)

• Adaptive maintenance (modifying the software in order to adapt it to the change)

• Expansion and integrity maintenance (users propose new functions and performance requirements)

• Preventive maintenance (in order to improve the maintainability and reliability of the software, lay a good foundation for further software improvement in the future) (also known as software reengineering)

non-structural maintenance

• Only the source code is included in the configuration of the software.

• Since there is no analysis and design document, it is impossible to reverse trace the function of the program, and it is very painful to understand other people's code.

• Since there is no test documentation in the configuration, the maintained code cannot be regression tested. As a result, the structure of the program is constantly destroyed, and the quality of maintenance cannot be guaranteed.

structural maintenance

• The configuration of the software to be maintained is complete.

• The maintenance application submitted by the user can be easily traced from the analysis and design document to the code through forward tracking, so that the maintainer can easily locate the maintenance point of the code. So this maintenance does not break the structure of the software.

• Structured maintenance can not only reduce the workload of maintenance, but also improve the quality of maintenance.

Documentation Types for Software Systems

• User documentation : mainly describes system functions and usage methods, and does not care how these functions are implemented.

• System documentation : describes all aspects of system design, implementation, and testing

software reengineering

Preventive maintenance is also known as software reengineering . Refers to refactoring or rewriting part or all of an existing system without changing its functionality

Purpose:

• In an effort to make the system more maintainable, the system needs to be restructured and redocumented.

• Reduce risk: Redeveloping a live system is very risky, with potential for development issues, people issues, and specification issues.

• Low cost: the cost of reengineering is much smaller than the cost of redeveloping software

refactor

On the basis of not changing the existing functions of the software, the quality and performance of the software are improved by adjusting the program code, so that the design mode and structure of the program are more reasonable, and the scalability and maintainability of the software are improved.

Refactoring should pay attention to two points:

1. Keep the core value of the system unchanged

2. Pay attention to risks