Software Engineering General Review Notes

Special statement:
This article is for reference only. Part of the content of this article comes from AI summary, Internet collection and personal practice. If any information contains errors, readers are welcome to criticize and correct them. This article is only for learning and communication, not for any commercial purposes.

Software Engineering Course Review Outline

1. Basic knowledge points

1. Concepts and goals of software engineering

software engineering definition

Software engineering is the related technology and management methods for developing and maintaining computer software using the principles and methods of engineering, science and mathematics. According to the definition of IEEE in 1993, software engineering is the application of systematic, standardized, and measurable engineering methods to the entire process of software development, operation, and maintenance. It is also a subject area that studies these methods.

Software engineering consists of three main components: methods, tools, and processes.

• Methods: Provides "how-to" techniques for software development. It supports project planning and estimating, system and software requirements analysis, software design, coding, testing and maintenance.

• Tools: Provide automatic or semi-automatic software support environment for software engineering methods. An integrated computer-aided software engineering (CASE) environment has been established.

• Process: Defines the order in which methods are used, the documentation required to be delivered, the management required to ensure quality and coordinate changes, and the milestones at each stage of software development.

Software engineering methods, tools, and processes constitute the three elements of software engineering. These elements work together to achieve the successful development and maintenance of software projects.

Software Engineering Goals

The goal of software engineering is to develop software products with the following characteristics within a given cost and schedule:

1. Modifiability: Software can be easily modified and upgraded to adapt to new needs and environments.

2. Reliability: The software can run stably under various conditions and is not prone to failures and errors.

3. Effectiveness: The software can complete its intended function in an efficient manner without wasting resources.

4. Understandability: The structure and code of the software are easy to understand, making it easy for developers to maintain and improve.

5. Maintainability: Software can be easily maintained, including fixing bugs, updating functionality, and adapting to new hardware or software environments.

6. Reusability: Software modules or components can be effectively applied to other systems or modules to improve development efficiency and reduce costs.

7. Adaptability: Software can adapt to changing environments and needs, and is flexible and scalable to meet future challenges.

8. Portability: The ability of software to be easily ported and run on different hardware platforms, operating systems, or environments without extensive modification.

9. Traceability: The ability to track the software development and maintenance process to ensure that the project proceeds as planned and to understand the status and progress of the project at any time.

10. Interoperability: Software can effectively interact and integrate with other software or systems to share data and functions.

Together, these goals ensure that software engineering results meet user needs, are of good quality and maintainability, while remaining economical during the development process.

Standard definition: Software engineering is an engineering field that develops, maintains and manages software through systematic, standardized and measurable methods. The goal is to improve software quality, reduce development costs, and ensure software projects are delivered on time.

Popular explanation: Software engineering is like the process of building a house. Through orderly steps and specifications, we can create, maintain and manage software more effectively. The goal is to make software better, cheaper, and on time. Just like building a house, software engineers need to plan their work to ensure the quality and reliability of the final product.

2. The concept and typical manifestations of software crisis

Software crisis concept

Software crisis refers to a series of serious problems encountered in the development and maintenance of computer software. It involves two main aspects of challenges:

1. How to develop software to meet the growing demand for software.
2. How to maintain an ever-expanding amount of existing software.

Generally speaking, the core problem of the software crisis lies in the imbalance between supply and demand and out-of-control development costs, resulting in delayed progress, poor reliability, and difficulty in maintenance. The following are typical symptoms of a software crisis:

Typical manifestations of software crisis

1. Estimate accuracy issues: Estimates of software development cost and schedule are often inaccurate, causing projects to potentially go over budget and be delayed.

2. User satisfaction issues: Users are often dissatisfied with the "completed" software system, indicating that there is a gap between the products delivered by the software and user expectations.

3. Software quality issues: The quality of software products is often unreliable, and errors and defects may exist, affecting the stability and reliability of the system.

4. Maintenance difficulties: Software is often unmaintainable and difficult to update, repair, and expand, which increases the difficulty of subsequent maintenance.

5. Insufficient documentation problem: Software often does not have proper documentation and lacks detailed instructions and guides, causing trouble for maintenance personnel.

6. The problem of rising cost proportion: The proportion of software cost in the total cost of computer systems is increasing year by year, making software development economically unsustainable.

7. The problem of insufficient productivity improvement: The rate of improvement in software development productivity cannot keep up with the development speed of hardware, and it is far behind the trend of popularization and deepening of computer applications, resulting in development lag.

Together, these manifestations constitute clinical symptoms of a software crisis, highlighting the difficulty of traditional software development models in coping with rapidly growing demand and complexity. Therefore, the development of software engineering aims to solve these problems and improve the quality and efficiency of software development.

Standard definition of the concept: Software crisis refers to a series of serious problems and challenges encountered during the software development process, resulting in the inability to complete the project as planned, unstable quality, and excessive consumption of resources. Software crises usually manifest themselves as unclear requirements, schedule delays, cost overruns, etc., threatening the feasibility and reliability of software engineering.

Popular explanation of the concept: A software crisis is like discovering that there are many problems with the original design drawings during the construction of a house. The project cannot be completed on time and the cost exceeds the budget. In software development, this means that projects can get stuck due to unclear requirements, delays, development cost overruns, etc.

Standard definition of typical manifestations: Typical manifestations of a software crisis include, but are not limited to: inflated demand, lagging project schedules, unstable quality, development costs exceeding budget, and inability to meet user expectations. These problems may lead to the failure of software projects or the inability to effectively deliver software products that meet requirements.

Popular explanation of typical manifestations: A software crisis is like a storm that brings a series of problems to software projects. Just like when building a house, it is discovered that there are many errors in the original design drawings, which leads to delays in the progress of the construction project and increasing costs. In software development, this may mean that project requirements become increasingly complex, leading to schedule delays, unstable quality, and development costs spiraling out of control, and ultimately may not be delivered as scheduled.

3. Concept and characteristics of waterfall model

The waterfall model is a classic traditional software engineering process model. It stipulates the connection sequence of six software engineering activities, similar to the waterfall flow process.

1. Accept input: Accept the work objects of this activity from the previous activity as input.
2. Implementation activity content: Use this input to implement the content that should be completed in the activity.
3. Produce work results: Give the work results of this activity and pass them to the next activity as output.
4. Review work: Review the work implemented for this activity. If the work is confirmed, proceed to the next activity; otherwise, return to the previous activity or even the previous activity for feedback and modifications.

Advantages of waterfall model:

1. Effective management diagram: Provides a clear development flow chart to help formulate software development plans, conduct cost budgets and organize development forces.

2. Stage review and document control: Review and document control are carried out at each stage to help effectively monitor and guide the entire development process, ensuring that software products are delivered on time and meet expected quality requirements.

3. Project control and management: The waterfall model provides clear stages for the project, making the control and management of the project more intuitive and operable.

Disadvantages of waterfall model:

1. Lack of flexibility: The waterfall model requires strict sequence of stages, lacks flexible response to changes, and is difficult to adapt to changes in project requirements.

2. Inability to solve requirements problems: When software requirements are unclear, inaccurate, or require continuous improvement, the waterfall model can cause development difficulties because changes in requirements are difficult to implement at a later stage.

3. Insufficient support for reuse and integration: The waterfall model is difficult to support the reuse of components and the integration of multiple development activities, which is an important challenge in modern software development.

In order to solve these shortcomings of the waterfall model, a variety of other software development models have emerged in recent years, such as the spiral model, prototype model, etc., which focus more on flexibility, iterative development, and agile response to changes in requirements. These models are more adaptable to complex and rapidly changing software development environments.

The concept of waterfall model:

Standard definition:
The waterfall model is a classic development method in the field of software engineering. The process is linear and sequential, divided into stages, and the output of each stage is used as the input of the next stage. The main stages of the waterfall model include requirements analysis, system design, implementation, testing, deployment and maintenance.

Popular explanation:
The waterfall model is like a waterfall. The development process advances step by step along a fixed process, and each stage has specific tasks and goals. Just like the flow of water is irreversible, once you enter the next stage, it is difficult to return to the previous stage. This approach facilitates clear planning and execution of the project, but also requires a relatively complete understanding of the requirements before starting.

4. Characteristics of rapid prototyping models

• Standard definition: A prototype is an operational model that implements some important aspects of a target software system. The rapid prototyping model is to quickly create a prototype of the system to understand user needs, collect feedback, and gradually improve the system on this basis.
• Popular explanation: The rapid prototyping model is like making a preliminary model, allowing users to see the prototype of the software in advance, so as to better adjust and improve requirements.
  
  Advantages of Prototypes

1. Facilitate user and software analyst learning

• Advantages: Prototype models help both users and software analysts learn from each other's domain knowledge.
• Detailed explanation: By quickly generating visual prototypes, users can more intuitively understand the potential functions and interfaces of the software system. At the same time, software analysts can gain an in-depth understanding of user needs and promote communication and cooperation between users and development teams.

2. Understanding and defining unified requirements

• Advantages: The prototype model helps users and developers unify their knowledge and understanding of software requirements, and facilitates the definition review of requirements.
• Detailed explanation: By showing a prototype, users and developers can more clearly understand how the system will look and behave. This helps eliminate ambiguities in understanding and ensures accuracy of requirements. During the review process, through prototypes, team members can discuss and verify the requirements in more detail, improving the quality of the requirements definition.

These advantages of prototype models make them a powerful tool for dealing with requirements uncertainty and promoting teamwork. However, it is important to note that when using prototype models, timely user feedback and effective communication are key factors to ensure success.

Characteristics of rapid prototyping models:

Standard definition:

1. Rapid design: The rapid prototyping model is a rapid design and iterative software development method that focuses on quickly creating prototypes of the system to obtain early user feedback.
2. User involvement: User involvement is a key feature as they are able to provide feedback based on prototypes and help refine system requirements.
3. Iterative development: Prototypes are used to verify and improve the system design, which gradually evolve into the final product through multiple iterations.
4. Flexibility: Rapid prototyping models are highly flexible, allowing requirements and designs to be flexibly adjusted during the development process.

Popular explanation:

1. Draw a blueprint: Like a simple model drawn before building a house, rapid prototyping is about quickly presenting design ideas.
2. Shake hands with users: Users are no longer spectators, they interact with prototypes and provide feedback to ensure the final product meets their expectations.
3. Repeated building: Like building blocks, by constantly adjusting and improving the prototype, the final software product is gradually formed.
4. Flexibility: Flexibility is key, allowing you to adjust prototypes based on user feedback and needs, and adapt to changing project requirements.

5. Basic idea of ​​the spiral model

• Standard definition: The spiral model is an evolutionary software development process model that takes into account the iterative characteristics of rapid prototyping and the systematic and strict monitoring of the waterfall model. The biggest feature of the spiral model is that it introduces risk analysis that other models do not have, allowing the software to have the opportunity to stop when major risks cannot be eliminated to reduce losses. At the same time, building prototypes at each iteration stage is the way the spiral model reduces risk. The spiral model is more suitable for large and expensive system-level software applications. 【1】Zheng Renjie·"Introduction to Software Engineering": Machinery Industry Press, 2010
• Popular explanation: The spiral model is like a spiral ladder that continues to rise. Each iteration is climbing one level while considering and solving possible risks.
  

The spiral model is a software development model that combines the advantages of the waterfall model and the prototype model and introduces a new component - risk analysis. The following are the components and characteristics of the spiral model

Model composition

1. Requirement definition:

   • Use demand analysis technology to understand application areas, obtain preliminary user needs, and formulate project development plans.

2. Risk Analysis:

   • Review options based on initial requirements or improvement suggestions, and provide ways to eliminate or reduce risks.

3. Project implementation:

   • Use the prototype construction method introduced earlier to generate rapid prototypes based on known user needs.

4. Review:

   • Submit the prototype to users for use and solicit their feedback for improvements. If the user thinks that the prototype can meet the needs, it will enter the running stage; otherwise, the developer will sort out the new user needs with the close cooperation of the user and formulate the next prototype evolution plan.

Model features

1. Combined advantages:

   • The spiral model embodies the advantages of the waterfall model and the prototype model, integrating the linear sequential development process and the rapid iterative prototype construction method.

2. Add new ingredients—risk analysis:

   • The spiral model introduces risk analysis as an important component. By analyzing risks in each iteration, potential problems can be identified and resolved early, improving the success rate of the project.

3. Loop iteration:

   • The spiral model iterates in the form of a spiral, with each spiral circle representing a development stage, including risk analysis, prototype building, and user review. This iterative approach helps adapt to changing requirements and handle risks in a timely manner.

The spiral model improves the adaptability and flexibility of the project by introducing risk analysis and iterative development. It is suitable for large, complex, and high-risk projects, providing more guarantees for the success of the project.
Advantages and problems of the spiral model

advantage

1. Integrates the advantages of waterfall model and prototype:

   • The spiral model combines the structured process of the waterfall model with the iterative and rapid development of prototype models, combining the advantages of both.

2. Requirements analysis and software implementation are interdependent and closely related:

   • The spiral model emphasizes the interdependence of requirements analysis and software implementation to ensure accurate understanding of requirements during the development process and timely adjustments.

3. User participation in decision-making:

   • User participation during the prototyping stage enables users to participate in all key decisions of software development and helps ensure that the final software product meets user expectations.

4. Formal requirements specification:

   • As a form of executable requirements specification, the prototype is easy for users and developers to jointly understand. It can also serve as the basis for subsequent development and provide a clear development direction.

5. Convenient project management:

   • It provides convenience for project managers to adjust management decisions in a timely manner, thereby reducing software development risks.

question

1. Relatively long development cycle:

   • Compared with other models, the spiral model has a longer development cycle. Excessive iterations may increase development costs and delay submission time.

2. Development costs are high:

   • During the prototype evolution process, failure to identify important user needs and key improvement points may lead to unnecessary losses in manpower, financial resources, and time.

The advantage of the spiral model is that it combines the advantages of different models, but in practical application it is necessary to weigh the relationship between development cycle and cost according to the characteristics of the project.

6. The concept of software life cycle and the stages it is divided into

software life cycle

The software life cycle, like ordinary things, has a life cycle, that is, stages of gestation, birth, growth, maturity, and death. The entire process of a software product starts from conception, through development, use and maintenance, until final retirement. The software life cycle includes three parts: software definition, software development, software use and maintenance.
The software life cycle is divided into several stages: feasibility study, requirements analysis, outline design, detailed design, implementation (coding), testing, use, maintenance, and retirement.

1. Feasibility Study:

   • Objective: Evaluate the feasibility of the project and determine whether it is worth pursuing.
   • Activities: Conduct market research, technical evaluation, economic analysis, etc., and formulate project feasibility report.

2. Requirements Analysis:

   • Goal: Clarify the functional and performance requirements of the system.
   • Activities: Communicate with users, collect and analyze user requirements, and write requirements specifications.

3. System Design:

   • Goal: Define the overall structure and module division of the system.
   • Activities: Design the basic framework of the system, determine the interfaces between modules, and create outline design documents.

4. Detailed Design:

   • Objective: Detail the design of each module in the system.
   • Activity: Write detailed design documents for each module, including details such as algorithms and data structures.

5. Implementation (coding) (Implementation/Coding):

   • Goal: Convert designs into actual executable code.
   • Activities: Write, test, and debug code to create an executable version of the software.

6. Testing:

   • Goal: Verify that the software meets requirements and find and fix bugs.
   • Activities: Perform various tests including unit testing, integration testing and system testing.

7. Use (Deployment):

   • Goal: Deploy the software to the target environment for use by users.
   • Activities: Install, configure and launch software, provide user training and support.

8. Maintenance:

   • Goal: Keep the software functioning properly and make necessary improvements.
   • Activities: Fix bugs, add new features, adapt to environmental changes, etc.

9. Retirement:

   • Objective: Determine and implement a software retirement strategy.
   • Activities: Archiving data, notifying users, shutting down systems, etc.

Each phase has its own unique tasks and activities, and software lifecycle management helps ensure that software projects proceed on schedule, quality, and cost.

7. Definition of software requirements

• Standard definition: Software requirements are a description of the functionality and performance of a system or system component, and the desired results that users want the system to achieve.
• Popular explanation: Software requirements are like a list of user requirements for software, including the functions that the software should implement and the performance level it should achieve.

To be precise, software requirements are divided into three main levels, including business requirements, user requirements and system requirements (which include functional and non-functional requirements):

1. Business Requirements:

   • Characteristics: Reflect the high-level expectations and goals of the organization or customer for the system or product.
   • Content: Emphasizes understanding of business processes, strategic goals, and organizational needs.

2. User Requirements:

   • Features: Describes the tasks that users need to complete when using the product, focusing on user operations and expectations.
   • Content: Focuses on user experience, interactions, and expectations for system behavior.

3. Functional Requirements:

   • Features: Defines the software functions that developers must implement to ensure that users can complete their tasks.
   • Content: Focus on the specific functions of the system, such as user interface, data processing, security, etc.

4. Non-functional Requirements:

   • Features: Describes the quality attributes and constraints of the system, focusing not only on functional aspects, but also on performance, reliability, security, etc.
   • Content: Including performance requirements, security standards, usability requirements, etc., affecting the overall quality and performance of the system.

These three levels of requirements are interrelated. Business requirements guide user requirements, and user requirements are further refined into functional and non-functional requirements so that developers can clearly understand the goals to be achieved. The effectiveness of requirements management is critical to ensuring that software projects proceed as expected.

8. Common software requirements obtaining techniques

Preliminary requirements elicitation is a crucial step in the software development process, and the following are some commonly used preliminary requirements elicitation techniques:

1. Interviews and Meetings: Gain insights, expectations, and needs through face-to-face interviews and meetings with key stakeholders (e.g., customers, end users, business analysts). This provides insight into business processes and system expectations.

2. Observe users’ workflows: Observe and analyze users’ operations and processes in actual work environments to identify potential issues, bottlenecks, and improvement points. This approach helps capture the details of actual requirements and user experience.

3. Establish a joint working group: Bring together development team members, end users, and other stakeholders into a joint working group. Through collaboration and discussion, teams are able to jointly understand requirements, facilitate information sharing, and ensure that the expectations of all parties are considered.

These techniques are often used in combination to ensure accurate and comprehensive requirements are gathered from multiple perspectives. Through effective preliminary requirements acquisition, a solid requirements foundation can be established to provide guidance for subsequent system design and development work.

9. What aspects are included in functional requirements and non-functional requirements?

• Functional requirements: Describe the specific functions that the system should have, such as user login, data export, etc.
• Non-functional requirements: describe system performance and constraints, such as performance, security, reliability, etc.

Functional requirements:

Standard definition:
Functional requirements are specifications that describe how a system should perform a specific task or satisfy a specific function. They usually involve the input, processing, and output of the system and describe the behavior the system should exhibit in different situations.

Including aspects:

1. Input requirements: Define the various input types and formats that the system should accept.
2. Processing requirements: Describe how the system processes input data and performs specific functions.
3. Output requirements: Specify how the system should present or output the input processing results.
4. Data management: including operations such as data storage, retrieval, update and deletion.
5. User interface: Defines how the system interacts with users, including interface design and user experience.

Non-functional requirements:

Standard definition:
Non-functional requirements describe the quality attributes and constraints of the system. They are usually not directly related to specific functions, but focus on the performance, security, maintainability and other aspects of the system.

Including aspects:

1. Performance requirements: including response time, throughput, etc.
2. Security requirements: Describe the system's security requirements for data protection and user identity authentication.
3. Reliability/Availability: Describes the reliability and availability of a system during normal operation and in the face of failures.
4. Maintainability: Specifies the degree to which the system is easy to maintain and modify, including code readability and scalability.
5. Portability: Describes the ability of a system to be deployed and run in different environments.
6. Regulations and standards: Includes regulations and industry standards that the system needs to comply with.

Functional requirements focus on what the system can do, while non-functional requirements focus on how the system should do it and under what conditions it should operate. Together, these two form a comprehensive system requirements specification.

10. Definition of Feasibility Analysis

• Standard definition: Feasibility analysis is based on the main content and supporting conditions of the project, such as market demand, resource supply, construction scale, process route, equipment selection, environmental impact, financing, profitability, etc., from the perspective of technology, economy, and engineering. Conduct investigation, analysis and comparison in other aspects, and predict the financial, economic benefits and social environmental impact that may be achieved after the project is completed, so as to provide consultation opinions on whether the project is worth investment and how to proceed with construction, and provide a basis for project decision-making. A comprehensive system analysis method. Feasibility analysis should be predictable, fair, reliable, and scientific.
• Popular explanation: Feasibility analysis is like a comprehensive investigation and estimation of the plan to see whether the project is feasible and worthy of investing resources.

11. In order to improve the maintainability of software, what coding standards are there?

• The importance of coding standards: The first step in maintaining software is code that is easy to read and maintain.
• Coding standards to improve maintainability: adequate comments, naming conventions, avoiding code redundancy, etc.

In order to improve the maintainability of software, it is crucial to formulate and follow some coding standards. Here are some common coding practices that can help improve code readability, maintainability, and teamwork efficiency:

1. Naming conventions: Use meaningful, clear, and consistent naming rules when naming variables, functions, classes, etc., and avoid using names that are too simple or ambiguous.

2. Indentation and formatting: Unify the code indentation style, choose a formatting method, and ensure that the entire team follows the same style to improve code consistency.

3. Comments: Add clear and concise comments to explain key parts of the code, algorithm ideas, special processing, etc. to help other developers understand the intent of the code.

4. Length of functions and methods: Controlling the length of functions and methods to avoid overly large functions will help improve the readability and maintainability of the code.

5. Exception handling: Add appropriate exception handling mechanisms to ensure that the code can handle exceptions gracefully and provide meaningful error information.

6. Modularity and the single responsibility principle: Divide the code into small, independent modules, each module is responsible for a clear task, and follow the single responsibility principle.

7. Code reuse: Reuse existing code to avoid reinventing the wheel. Use functions, classes and modules to improve the maintainability of the code.

8. Version control: Use a version control system (such as Git) to track code changes, ensure code history is traceable, and facilitate team collaboration and code rollback.

9. Unit testing: Write and execute unit tests to ensure the stability and correctness of the code and help detect potential problems.

10. Documentation: Write appropriate documentation, including code documentation, API documentation, etc., so that other developers can quickly understand and use your code.

These coding standards help form a consistent coding style, reduce the difficulty of code maintenance, improve team collaboration efficiency, and ensure the maintainability of software systems.

12. Principles of software design

• Overview of design principles: Design principles are general guidelines that help design well-structured and maintainable software.
  • Single Responsibility Principle: A class should have one and only one reason to change.
  • Open-closed principle: Software entities should be open for extension and closed for modification.
    The principles of software design refer to some basic principles and guidelines that should be followed when designing software systems to ensure the design of high-quality, maintainable, scalable and easy-to-understand software. Here are some common software design principles:

1. Single Responsibility Principle (SRP): A class should have only one reason for change, that is, a class should have only one responsibility.

2. Open/Closed Principle (OCP): Software entities (classes, modules, functions, etc.) should be open to extensions and closed to modifications, that is, new functions can be added through extensions without modifying existing code.

3. Liskov Substitution Principle (LSP): A subclass should be able to replace its base class, and the program should still be able to run without knowing whether it is a base class or a subclass.

4. Dependency Inversion Principle (DIP): High-level modules should not depend on low-level modules, both should depend on abstraction; abstraction should not depend on details, details should depend on abstraction.

5. Interface Segregation Principle (ISP): Clients should not be forced to rely on interfaces they do not use, that is, the dependence of one class on another class should be based on the smallest interface.

6. Composition/Aggregation Reuse Principle (CARP): It is preferred to use composition/aggregation rather than inheritance to achieve code reuse.

7. Law of Demeter (LoD): An object should have the least knowledge about other objects, that is, an object should know as little as possible about the structure and implementation of other objects.

8. Principle of Least Astonishment (POLA): Design should be such that users or programmers of the system will not be surprised when using the system.

9. Modularity principle: Divide the system into small, independent modules to better understand, maintain and expand the system.

10. High cohesion and low coupling principle: The elements within the module are closely integrated with each other, and the degree of coupling between modules should be as low as possible.

These principles in software design help create code that is maintainable, flexible, extensible, and easy to understand. Depending on the specific application scenario and project needs, some principles may be emphasized and the application of other principles weakened.

13. The concepts of cohesion and coupling and several common cohesion and couplings

• Cohesion: refers to how closely the parts within the module are related to each other.
  • Sequential cohesion: Each part is executed in order.
  • Functional cohesion: All parts work together to complete a function.
• Coupling: The degree of interdependence between modules.
  • Data coupling: interaction through shared data.
  • Control coupling: One module controls another module.

Cohesion is a measure of how closely the components within a module are connected. Divide and conquer decomposes a task into several small tasks, while cohesion emphasizes putting related content together during decomposition. Cohesion is used to determine whether each module in the system is a reasonable program unit, that is, whether it is a reasonable module. The closer the various components in a module are connected, the better, indicating that they should form this module together.

Coupling is a measure of the strength of the interconnection between modules, and is used to help designers ensure that the designed system is composed of a series of loosely coupled modules. The strength of coupling between modules depends on the way data is transferred between modules, the complexity of the interface, and the type of data transferred.

Several common cohesion and couplings:

1. Sequential Cohesion: Each module element is closely connected according to the order of execution, and the output of one element serves as the input of another element. This cohesion is usually done to complete a sequential process.

2. Functional Cohesion: Elements within a module perform similar functions and are related to each other to complete a specific task. This is a high degree of cohesion, and each element within the module revolves around the same function.

3. Communication Cohesion: Elements within a module share the same data and communicate with each other by passing messages. This cohesion measures the extent to which information is shared between elements within a module.

4. Procedural Cohesion: The elements within the module are executed in a certain logical order, but are weakly related to each other. This degree of cohesion is low, and the elements within the module only perform tasks in a certain order.

5. Coincidental Cohesion: The elements within the module are not directly related to each other, but are placed in the same module only for historical or other reasons. This is a minimal level of cohesion.

6. Tight Coupling: The dependencies between different modules are strong, and modifications to one module may affect other modules. Tightly coupled systems are difficult to modify and maintain.

7. Loose Coupling: The dependencies between different modules are weak, and modifications to one module are unlikely to affect other modules. Loosely coupled systems are more flexible and maintainable.

In software design, the pursuit of high cohesion and low coupling is to create systems that are easy to understand, modify, and maintain. Reasonable cohesion and coupling relationships help improve the quality and scalability of the system.

14. Software detailed design and software outline design concepts and main tasks

• Software detailed design: The design phase that specifically describes how each module is implemented.
  • Main tasks: Define details such as data structures, algorithms, interfaces, etc.
• Software outline design: The design phase that describes the overall system structure and the relationships between modules.
  • Main tasks: Divide system modules and define interfaces between modules.

The concepts and main tasks of software detailed design and software outline design:

1. Software High-Level Design:

   • Concept: Software outline design is a stage after requirements analysis and before overall software design. The main goal is to define the overall structure of the system and the relationship between modules, provide a high-level view, and ensure that the system design matches the requirements.

   • main mission:

     • Formulate the architecture: Determine the overall structure of the system, including module division, interfaces and data flows between modules.
     • Define module functions: describe the basic functions and responsibilities of each module, and outline the collaboration between modules.
     • Determine data structures: Determine the main data structures used in the system and how data is transferred and processed between modules.
     • Develop interface specifications: Define interface specifications between modules, including input parameters, output parameters and calling methods.
     • Determine system performance: A rough assessment of the system's performance requirements, such as response time, throughput, etc.
     • Develop a preliminary test plan: Plan how to verify and test the outline design.

2. Software Detailed Design:

   • Concept: Detailed software design is a stage after the outline design and before coding. The main task is to further refine the outline design modules, clarify the internal implementation details of each module, and provide programmers with specific development guidance.

   • main mission:

     • Module internal design: Detailed description of the internal structure of each module, including data structure, algorithm, data flow, etc.
     • Interface refinement: further improve the interfaces between modules and define detailed specifications for functions, procedures, classes, etc.
     • Data structure design: Define the specific data structures used within the module, including how the data is organized, stored and accessed.
     • Algorithm design: Formulate the specific algorithms involved in the module to ensure that performance and functional requirements are met.
     • Error handling and exception design: Define the system's handling mechanism when facing errors and exceptions to ensure system stability.
     • Resource management design: Determine how the system manages and utilizes computing resources, storage resources, network resources, etc.
     • Programming language and tool selection: Select appropriate programming languages ​​and development tools, ensuring they fit the needs and constraints of the project.

Software outline design and software detailed design are both important components of the design phase in software engineering, helping to ensure that the software project proceeds smoothly as planned and improve the quality and maintainability of the system.

15. Definition of Software Testing

• Standard definition: Software testing refers to the process of running a software system or application to verify whether it meets specified requirements, functionality and performance standards during the software development process. The purpose of software testing is to find potential errors or defects and ensure that the software has high quality, stability and reliability before it is delivered to users.
• Baidu Encyclopedia: Software Testing (English: Software Testing) is a process that uses manual operation (manual testing) or the software to run automatically (automated testing) to check whether the software meets user needs.

16. The main ideas of white box testing and black box testing

• White box testing: testing based on the internal structure of the code, focusing on program logic and internal paths.
• Black box testing: Testing based on software functions and user needs, ignoring internal implementation details.
• Main idea: White box focuses on internal logic, and black box focuses on external behavior.

The main ideas of white box testing and black box testing:

1. The main idea of ​​White Box Testing:

   • Concept: White-box testing, also known as structural testing or logic-driven testing, focuses on testing the logical structure, code and algorithms inside the software. Testers need to understand the internal implementation of the software under test in order to design test cases to cover each logical path of the program.

   • The main idea:

     • Transparency: White-box testing examines the internal structure of the software. The tester has a more detailed understanding of the source code, algorithm and data structure of the software being tested.
     • Comprehensive test coverage: The goal of white-box testing is to ensure that every logical path is tested to achieve maximum test coverage.
     • Path testing: Find possible errors by testing each logical path of the program, including loops, conditional statements, branch statements, etc.
     • Code coverage: White-box testing usually targets code coverage, including statement coverage, branch coverage, path coverage, etc.

2. The main idea of ​​Black Box Testing:

   • Concept: Black box testing focuses on testing the functionality and behavior of software without considering its internal implementation details. In this case, the tester treats the software as a "black box" and only cares about the relationship between input and output.

   • The main idea:

     • Functional independence: Black box testing ignores the internal implementation details of the software and treats the software as an independent functional module. The tester does not need to know the internal logic of the software.
     • Based on user needs: The design of black box testing is based on user needs and system specifications. The test cases are designed to verify whether the software meets the specified function and performance standards.
     • Input-output relationship: The tester inputs appropriate data and observes the output of the software to confirm whether the software works normally according to the specifications.
     • User perspective: Black box testing mainly starts from the user's perspective, focusing on the external behavior, interface and interaction of the software.

Overall comparison:

• The choice between white box testing and black box testing: Choosing between white box testing and black box testing usually depends on the objectives of the test, the testing phase and the role of the tester. Generally speaking, white box testing is mainly used in unit testing and integration testing phases, while black box testing is mainly used in system testing and acceptance testing phases.

• Complementarity: These two testing methods are usually complementary in software testing, and their combined use helps ensure comprehensive coverage of the software, taking into account both internal logic and user needs.

17. Understand use case diagrams and their use

• Use case diagram definition: used to describe the functional relationship between the system and external entities (usually users).
• Usage: Used to visualize and understand the functional requirements of the system and the interaction between the system and its users.

Understanding and using Use Case Diagram:

Concept:
A use case diagram is a UML (Unified Modeling Language) diagram used to describe the functional requirements of a system. It mainly displays each use case (Use Case) in the system and the external entities (Actors) participating in these use cases. . Use case diagrams provide a high-level view of a system's functionality and are used to understand how the system interacts with external entities.

Main elements:

1. Use Case: A use case represents a functional unit in the system, usually corresponding to a specific function of the system or a user task.
2. Actor: Actor represents an entity outside the system, which can be a person, other system, or external component, and interacts with one or more use cases of the system.
3. Relationship: used to describe the relationship between use cases and participants, including include relationships, extension relationships, generalization relationships, etc.

use:

1. Requirements analysis: Use case diagrams are often used in the system requirements analysis stage to help the team understand the functional requirements of the system and capture the interaction between users and the system.

2. System design: Use case diagrams can be used to support the system design phase, helping designers determine system functional boundaries and identify key use cases and actors.

3. Communication tool: Use case diagrams are a simple, intuitive communication tool that provide project teams, customers, and other stakeholders with a high-level overview of system functionality.

4. Test case design: Use case diagrams can provide the basis for test case design and help testers understand the main functions of the system so as to write effective test cases.

5. System evolution: As the system evolves, use case diagrams can help the team better understand and manage the introduction of new features and changes to existing features.

6. Document writing: Use case diagrams are often used to write user manuals, system specifications and other documents to provide users and developers with an overall understanding of the system.

Example:

Use case diagram example 1: Online book shopping system

@startuml
left to right direction
actor Customer
actor Admin
rectangle "Online Bookstore" {
  Customer --> (Browse Books)
  Customer --> (Add to Cart)
  Customer --> (Checkout)
  Admin --> (Manage Inventory)
}
@enduml

This example represents an online book shopping system with two participants: Customer and Admin. Use cases include "browse books," "add books to cart," and "check out order."

Use Case Diagram Example 2: Simple Banking System

@startuml
left to right direction
actor Customer
actor BankTeller
rectangle "Simple Banking System" {
  Customer --> (View Balance)
  Customer --> (Withdraw Money)
  Customer --> (Transfer Money)
  BankTeller --> (Manage Accounts)
}
@enduml

This example represents a simple banking system with two participants: the customer and the bank teller. Use cases include "check balance," "withdraw money," "transfer money," and a bank teller can "manage account."

You can paste the above code into an online UML editor (such as PlantText or PlantUML Editor .) and run it to generate a use case diagram. If you use a native UML tool, you can also save the code as a .plantuml file and open it in the tool.

18. Understand and use data flow diagrams

• Data flow diagram definition: A graphical tool that represents how data flows in a system.
• Usage: Used to understand the data processing process within the system and assist in design and analysis.

Data flow diagram is an information system modeling technique that emphasizes data flow and processing. Based on the IPO model (input-processing-output model), the function of the software can be viewed as the process of format conversion of data, converting input data into output data. The following is the essence of data flow diagram modeling:

1. Data transfer and transformation:

   • Features: Data flow diagrams mainly focus on the transfer of data in the system and the corresponding transformation process.
   • Purpose: Reveal how data flows from one state to another and changes through a series of transitions.

2. From top to bottom, gradually refine and decompose:

   • Features: The data flow diagram adopts a top-down decomposition method to gradually decompose each part of the system from the whole to the details.
   • Purpose: By decomposing complex system problems into more manageable and understandable modules through step-by-step decomposition, it helps to capture the functions and processes of the system in detail.

3. The composition of the information processing system:

   • Concept: An information processing system consists of a flow of data and a series of transformations.
   • Function: Transformation defines various functions performed by the system, that is, the process of converting input data streams into output data streams.

Through data flow diagrams, analysts can gain insight into the data flow of a system, identify important transformation processes, and ensure that the system meets user needs. This method allows software functional requirements to be clearly presented and provides powerful guidance for system design and development.

19. Understand class diagrams and their use

• Class diagram definition: used to represent classes in the system and the relationships between them.
• Usage: Used in object-oriented design to represent the properties, methods and relationships of classes.

UML class diagram (combination, aggregation, association, dependency)

UML classes represent domain conceptual models

In UML, concepts are represented through classes, and class diagrams display domain conceptual models. In the early stages of requirements analysis, it is not necessary to enumerate the attributes and methods of all classes at once. Initially, only the class name is required, and as analysis and design progress, the attribute list and method list are gradually improved.

Three parts of UML classes:

1. Class name
2. Property list
3. method list

The form of the elements is expressed in the diagram.

The relationships between UML classes mainly include inheritance, aggregation, association and dependence. Inheritance means that the subclass reuses the attributes and operations of the parent class. The objects of the subclass are also the objects of the parent class. This is sometimes called generalization.

20. Understand the relationship between classes

• Overview of relationships between classes: including association, aggregation, combination, inheritance and other relationships.
• Usage: Used to define the relationship between classes to promote the modularity and maintainability of the system.
  Aggregation relationships between classes simulate part-whole relationships in the real world.
  # Aggregation relationships in UML

UML divides aggregation relationships into two types:

1. Ordinary aggregation relationship: A component object can participate in multiple overall objects at the same time.

2. Composition relationship: Limit a component object to only participate in one object of the overall class at any time, and the component class object and the overall class object coexist.
   

# connection relation

The association relationship indicates that there is a stable channel for message transmission between objects of two classes. In the course registration management system, for example, there is an association between the "student" class, the "teacher" class and the "course setting" class, because the "course setting" is related to course-selecting students and teachers, and students and teachers need to query the course setting. related information.

Usually, there is a quantitative correspondence between objects of two classes, which is a concrete manifestation of business rules. After the analysis and design has advanced to a certain stage, it should be clearly marked next to the expression of aggregation, composition and association. For example, it means that each "course setting" object should have no less than 10 and no more than 50 course-selecting students.

# Dependencies

The dependency relationship means that the object of dependent class B needs to send messages to the object of dependent class A, and the dependent class A can be used as the formal parameter type of the operation of dependent class B. Dependencies are temporary messaging channels that disappear after the operation is completed.

For example, the classes in the "Order" package only depend on the classes (interfaces) in the "Database Interface" package and do not need to establish an association relationship. Dependency is a weakening of the association, which means that changes in the dependent class will affect the dependent class.

The strengthening of dependence is association, the strengthening of association is aggregation, and the strengthening of aggregation is composition.

21. Which two stages can software design be divided into?

• Stage division:
  • Outline design phase: describe the overall system structure and module relationships.
  • Detailed design phase: Describe the implementation details of each module in detail.

Software design can generally be divided into two main phases:

1. Outline design (High-Level Design):

   • Concept: The outline design stage is a high-level planning and design of the entire system after demand analysis. It mainly focuses on high-level structural issues such as the overall structure of the system, module division, interface definition between modules, and the design of data flow and control flow.
   • Task: During the outline design phase, the design team needs to determine the main modules of the system, the relationships between them, and the overall framework of the system. Design decisions at this stage have an impact on the overall architecture of the system and provide the basis for detailed design.

2. Detailed design (Low-Level Design):

   • Concept: The detailed design phase is to conduct a more specific design for each module in the system based on the outline design. It focuses on the implementation details inside the module, including the selection of algorithms, the specific implementation of data structures, the definition of functions, etc.
   • Task: In the detailed design stage, the design team needs to further clarify the functions and implementation methods of each module, determine the specific algorithms and data structures, and define functions and interfaces so that programmers can implement specific implementations based on the detailed design during the coding stage.

These two stages play a key role in the software development life cycle. The outline design provides the overall framework and structure of the system and provides guidance for the detailed design; while the detailed design provides specific guidance for coding to ensure the quality of each module. Functionality and implementation are planned in detail. Design decisions in these two stages directly affect the quality, maintainability and performance of the software.

22. Key principles of user interface design

• Main principles:
  • Consistency: Interface elements should be consistent to provide a consistent user experience.
  • Visibility: Functionality and information that users need should be visible.
  • Feedback: Provide timely and clear operational feedback to users.

User interface design is a vital part of software development, which directly affects user experience and software usability. Here are some key principles of user interface design:

1. Visibility:

   • Definition: The operations and functions in the system should be visible, and users can clearly understand the current operations that can be performed.
   • Implementation: Use clear labels, icons, and menus to ensure users can intuitively identify and understand the functionality of interface elements.

2. Consistency:

   • Definition: The design elements of an interface should be consistent throughout the system, providing similar appearance and behavior, allowing users to establish reliable usage patterns.
   • Implementation: Unify colors, fonts, button styles and other elements to ensure that operations with similar functions are presented in similar ways in different parts of the interface.

3. Feedback:

   • Definition: Provide timely feedback to inform users that their operations have been accepted by the system and provide information about the status and results of the operations.
   • Implementation: Use prompts, animations, status bars, etc. to clearly display the results of operations and the current system status to users.

4. Error Prevention:

   • Definition: Taking into account possible user errors in design and taking steps to prevent or mitigate the impact of these errors.
   • Implementation: Provide clear identification and help information, as well as appropriate validation mechanisms to help users avoid input errors and correct possible errors.

5. Simplicity:

   • Definition: The interface should be concise and clear, avoiding too many complex elements and functions, so that users can easily understand and use the system.
   • Implementation: Streamline unnecessary functions, place commonly used operations in prominent locations, and avoid clutter and overly complex layouts.

6. Flexibility and Efficiency:

   • Definition: Allow users to perform tasks in multiple ways, providing shortcut keys, custom options, etc. to meet the needs and work styles of different users.
   • Implementation: Provide shortcut keys, search functions, custom settings, etc. to enable users to use the system more efficiently.

7. Predictability:

   • Definition: Users should be able to predict the behavior of a system, understand the results of an operation, and develop confidence in using the system.
   • Implementation: Follow common interface design conventions to ensure that users can accurately predict the system's response when performing operations.

8. Controllability:

   • Definition: Users should have control over the system and be able to perform operations freely and undo or roll back when necessary.
   • Implementation: Provides functions such as undo, redo, and setting options, allowing users to independently control the behavior of the system.

These principles together form a user-friendly interface design that helps improve user experience, reduce user learning costs, and improve system usability.

23. RUP model

• RUP model overview: RUP (Rational Unified Process) is an iterative software development process.
  • Features: Emphasis on iteration, use case-driven, and architecture-oriented.

24. Basic ideas of structured software development

• Basic idea: Structured software development adopts a modular, top-down, and step-by-step refinement approach to software design and development.
  • Modularization: Divide the system into independent modules to reduce complexity.

Data flow-oriented design method (SD method)

The data flow-oriented design method, namely the structured design method (SD method), generates data flow diagrams and data dictionaries by analyzing the data flow in the requirements phase, and designs the software structure based on this.

A data flow diagram describes the processing and flow of information within a system. This method defines two mappings based on the characteristics of the data flow graph: transformation flow and transaction flow. These two mappings mechanically transform data flow diagrams into program structures.

The goal of the method is to provide a systematic approach to software structure design so that designers can have an overall understanding of the software and define the program structure by analyzing the characteristics of the data flow.

• Disadvantages of structured approach

1. Poor stability:

   • Problem: Structural analysis and design techniques are based on functional decomposition, but when user requirements change, the impact on the system structure can be catastrophic.
   • Reason: The system structure revolves around the process of realizing functions, and changes in functions may lead to structural instability.
   • Impact: Changes may be propagated to multiple parts of the system, making the system difficult to maintain and extend.

2. Poor modifiability:

   • Problem: Structural analysis and design techniques clearly define the boundaries of a system, but this also means that the system is difficult to expand across new boundaries.
   • Reason: The system structure relies on the definition of system boundaries, and expanding the system requires reconsideration and adjustment of boundaries.
   • Impact: In response to changing or adding new functional requirements, the system may require major modifications.

3. Poor reusability:

   • Problem: The arbitrariness of functional decomposition may lead to uncertain functions of the decomposed modules, reducing the reusability of the modules.
   • Reason: The lack of clearly defined module functionality can lead to large differences between modules with similar functionality.
   • Impact: Module-level reuse is difficult to achieve because modules with similar functionality are less likely.

Taken together, these issues highlight some of the challenges that structured analysis and design techniques can face when dealing with change, modification, and reuse. Modern software development methods and architecture design tend to adopt more flexible, modular and object-oriented methods to better meet changing needs and improve the maintainability, modifiability and reusability of the system.

25. Basic ideas of object-oriented software development

• Basic idea: Object-oriented software development performs system modeling and design by defining and organizing objects.
  • Object: An entity that encapsulates data and methods.
    The core of the method is to use object-oriented concepts and methods to build models for software requirements. It contains object-oriented style graphical language mechanisms and object-oriented methodologies for guiding requirements analysis.

Object-oriented requirements analysis method

The object-oriented (OO) requirements analysis method allows analysts to directly simulate objects and their behaviors in the problem space in the solution space by providing language mechanisms such as objects and message passing between objects, thus reducing semantic gaps. Provides intuitive, natural language support and methodological guidance for requirements modeling activities.

In order to simulate real-life problems in solution space and be consistent with human thinking habits, OO methodology encompasses the following core concepts:

1. object

   • Objects are abstract representations of individuals or things in the real world.
   • Attributes represent the properties of an object, and attribute values ​​specify all possible states of the object.
   • The operations of an object refer to the external services that the object can expose.

   Example: A large passenger aircraft can be regarded as an object, with attributes such as position, speed, color, and capacity, and can perform operations such as takeoff, landing, acceleration, and maintenance.

2. kind

   • Classes represent the common characteristics of certain objects in terms of properties and operations.
   • Common attributes and operations form the characteristics of a class.

   Example: Helicopters, large passenger planes, and bombers can be classified as aircraft. Common attributes include position, speed, and color. Common operations include takeoff, landing, acceleration, and maintenance.

3. inherit

   • The inheritance relationship between classes simulates the genetic relationship in the real world.
   • Represents the intrinsic relationship between classes and the sharing of attributes and operations.

   Example: Aircraft, cars and ships can be classified into the vehicle class, and the aircraft class can inherit some properties and operations of the vehicle class.

4. gather

   • Describe part-whole relationships in the real world.
   • In OO methodology, it is expressed as an aggregation relationship between classes.

   Example: An aircraft consists of an engine, fuselage, mechanical control system, electronic control system, etc.

5. information

   • Messaging is how objects relate to the outside world.
   • Objects provide services by sending and receiving messages.

   Example: A helicopter responds to a ship's emergency signal and performs a rescue operation.

Object-oriented = object + class + inheritance + aggregation + message.

26. In structured software development, how to obtain software structure

• Software structure acquisition: Through modular, top-down design methods, the system is decomposed into modules and the relationships between modules are defined.

In structured software development, the following steps are followed to obtain the software structure:

1. Requirements analysis : First, conduct a detailed requirements analysis to understand the functionality and user needs of the software system. This helps clarify the problem the software is meant to solve and identify the functional modules it requires.

2. Module partitioning : Dividing a software system into smaller modules or components, each module handles a specific function. There should be clear boundaries and responsibilities between modules to achieve high cohesion and low coupling.

3. Define the interface : Each module should have a well-defined interface that specifies input and output, as well as how to communicate with other modules. This helps ensure that interactions between modules are reliable and consistent.

4. Draw structure diagram : Use appropriate graphical representation methods, such as UML (Unified Modeling Language), etc., to draw software structure diagrams. The structure diagram should clearly show the relationships and dependencies between modules.

5. Hierarchical design : Design the software structure in a hierarchical manner, dividing functions into different levels, with each level responsible for specific tasks. For example, a three-tier architecture (presentation layer, business logic layer, data access layer) can be used to achieve separation of concerns and improve scalability.

6. Design Pattern Application : Apply appropriate design patterns to solve common software design problems. Design patterns provide proven solutions that can help build flexible, maintainable, and scalable software structures.

7. Write documentation : Write detailed documentation for the software structure, including system overview, module functions, interface definitions, structure diagrams, etc. Documentation should be clear, easy to understand, and help others understand and maintain the software.

8. Continuous improvement : The software structure is not static. As requirements change and the system evolves, the structure may need to be adjusted and improved. Continuously evaluate and improve software structures to ensure system robustness and maintainability.

Through the above steps, a good software structure can be obtained, making the software development process more controllable and reliable, while improving the quality and maintainability of the software.

27. Types of software maintenance

1. Corrective Maintenance

   • Definition: Fixing known errors, defects, or glitches in software to ensure the system operates properly.
   • Purpose: Diagnose and fix problems found in the current system, usually to fix existing defects.

2. Adaptive Maintenance

   • Definition: Adjusting a software system so that it can adapt to environmental changes or new requirements and ensure that it continues to operate effectively in the new environment.
   • Purpose: To respond to external changes, such as operating system updates, hardware changes, or regulatory updates.

3. Perfective Maintenance

   • Definition: Optimizing the performance, maintainability, and user experience of a software system rather than just fixing bugs.
   • Purpose: Improve software quality, enhance performance, add new features or enhance user experience.

4. Preventive Maintenance

   • Definition: Taking steps to prevent future problems to reduce potential failures and errors.
   • Purpose: Prevent potential defects and problems by optimizing code structure, conducting code reviews, updating documentation, etc.

These types of maintenance are typically performed on an ongoing basis throughout the software development cycle. Corrective and adaptive maintenance mainly focus on known or upcoming problems, while perfective and preventive maintenance focus more on improving the quality and performance of the system to cope with future challenges. Maintenance work is critical throughout the software life cycle and helps ensure the robustness and continuity of the system.

28. The difference between software debugging and testing

• the difference:
  • Software debugging: finding and fixing bugs in your code.
  • Software testing: Verify whether the software meets requirements and discover potential errors.

There are big differences between software testing and software debugging in terms of purpose, technology and methods, mainly in:

① Testing proves the failure of the program from one side, while debugging is to prove the correctness of the program.

② The test starts from known conditions, uses a predefined program, and has a predictable result. What is unforeseen is whether the program passes the test. Debugging generally starts with unknowable internal conditions, and except for statistical debugging, the results are unpredictable.

③ Testing is planned and test design is required, while debugging is not subject to time constraints.

④ Testing is a process of finding errors, correcting errors, and retesting, while debugging is a reasoning process.

⑤ The execution of tests is regulated, while the execution of debugging often requires programmers to make necessary reasoning and leaps of perception.

⑥ Testing is often completed by an independent testing group without understanding the software design, while debugging must be completed by programmers who understand the detailed design.

⑦The execution and design of most tests can be supported by tools, and when debugging, the main tool that programmers can use is the debugger.

29. How to measure software development effort

• Measurement method:
  • Function point analysis: Measure the workload based on the functional requirements of the system.
  • Behavior point analysis: Measure workload based on user interaction behavior.
    Measuring software development effort is an important part of managing projects, evaluating progress, and allocating resources. Here are some commonly used methods and metrics:

1. Function Points Analysis

   • An evaluation method based on software functionality and complexity, using function points as the unit of measurement.
   • Assess effort by identifying and counting the type and number of software features.

2. Lines of Code (LOC)

   • Effort is measured in terms of lines of source code. However, LOC is not always the most accurate measurement, as lines of code may not accurately reflect complexity and effort.

3. Manpower time estimation

   • Effort is estimated based on the time a developer estimates it will take to complete a specific task.
   • Estimations can be made using methods such as professional experience, historical data, and task breakdown.

4. Estimates based on tasks and function points

   • Break down tasks and function points into smaller units and estimate each unit.
   • This approach requires a detailed assessment of the effort for each task, which is then aggregated to arrive at a total effort.

5. Use professional tools and software

   • There are many project management tools and software that can help automate and simplify the measurement and estimation of workload, such as JIRA, Trello, MS Project, etc.

6. risk estimate

   • Make certain adjustments and corrections to the workload to take into account potential risk factors.

7. Rules of thumb and historical data

   • Estimate effort based on data and rules of thumb from similar past projects, such as using completion times and resource allocations for similar projects as a reference.

In actual projects, multiple methods and metrics are often combined to estimate effort more accurately. It is important to continually track work progress and actual completion so that estimates can be adjusted when needed and improve estimate accuracy.

30. Understand the balance issue in data flow diagrams

• Explanation of the balance problem: The input and output of each processing module in the data flow diagram should be balanced to avoid a backlog or insufficient data somewhere.

Data flow diagrams and balancing principles

31. What is included in the Java technology stack?

The Java technology stack refers to a collection of technologies, frameworks, and tools used in the Java ecosystem to develop Java applications. This technology stack covers various aspects, including but not limited to:

1. Core Java

   • Java SE (Standard Edition): The basic core of Java, including basic language features, class libraries and tools.
   • Java EE/Jakarta EE (Enterprise Edition): Java extension for enterprise-level application development, providing enterprise-level APIs and tools, such as Servlets, JSP, JPA, EJB, etc.

2. development tools

   • Integrated development environment (IDE): such as Eclipse, IntelliJ IDEA, NetBeans, etc., used to write, debug and test Java code.
   • Build tools: such as Apache Maven and Gradle, used for automated builds, dependency management and project management.

3. Web development

   • Spring Framework: Provides comprehensive enterprise-level Java development support, including dependency injection, AOP, MVC, etc.
   • Spring Boot: Simplifies the development of Spring-based applications, providing automated configuration and rapid development.
   • Servlets and JSP: used for building web-based Java applications.
   • Jakarta EE: Formerly Java EE, it provides a series of enterprise-level Java specifications and APIs.

4. database

   • JDBC (Java Database Connectivity): used for connection and interaction between Java and database.
   • Hibernate, JPA (Java Persistence API): used for object-relational mapping (ORM) to simplify the mapping between Java objects and databases.

5. Front-end development

   • JavaServer Faces (JSF): Java web framework for building user interfaces.
   • Spring Web Flow: Used to manage page flow and navigation in web applications.

6. Microservices and cloud native

   • Spring Cloud: for building applications based on microservices architecture.
   • Quarkus, Micronaut: lightweight Java frameworks for building cloud-native applications.

7. Test and deploy

   • JUnit, TestNG: Java testing framework for writing and running unit tests.
   • Docker, Kubernetes: For containerizing and deploying Java applications.

The Java technology stack is very rich and diverse, covering everything from basic language features to various tools, frameworks and libraries required for enterprise-level applications and cloud-native development. Choosing the right technology stack depends on project needs, size, and your team’s preferences and experience.

32. Flowchart

• Flowchart concept: Graphical representation of a process, showing processing steps and process control.
• Use: For visualizing and understanding systems, algorithms, or business processes.
  

Example 1: Simple flowchart

import graphviz

# 创建流程图对象
dot = graphviz.Digraph()

# 添加流程图元素
dot.node('A', '开始', shape='ellipse', fontname='SimSun')
dot.node('B', '步骤1', shape='box', fontname='SimSun')
dot.node('C', '步骤2', shape='box', fontname='SimSun')
dot.node('D', '结束', shape='ellipse', fontname='SimSun')

# 添加连接线
dot.edge('A', 'B')
dot.edge('B', 'C')
dot.edge('C', 'D')

# 保存并显示流程图
dot.format = 'png'
dot.render('flowchart_example1', view=True)

Example 2: Flowchart with decision conditions

import graphviz

# 创建流程图对象
dot = graphviz.Digraph()

# 添加流程图元素
dot.node('A', '开始', shape='ellipse', fontname='SimSun')
dot.node('B', '步骤1', shape='box', fontname='SimSun')
dot.node('C', '决策', shape='diamond', fontname='SimSun')
dot.node('D', '步骤2', shape='box', fontname='SimSun')
dot.node('E', '结束', shape='ellipse', fontname='SimSun')

# 添加连接线和决策条件
dot.edge('A', 'B')
dot.edge('B', 'C')
dot.edge('C', 'D', label='条件1', fontname='SimSun')
dot.edge('C', 'E', label='条件2', fontname='SimSun')
dot.edge('D', 'E')

# 保存并显示流程图
dot.format = 'png'
dot.render('flowchart_example2', view=True)

Thinking Graphically: The Art and Practice of Graphviz and the DOT Language
Install Graphviz and add its path to your system's PATH environment variable. You can follow these steps:

1. Download the Graphviz installer: You can download the appropriate installer for your operating system from the Graphviz official website .

2. Install Graphviz: Run the downloaded Graphviz installer and follow the instructions to complete the installation process.

3. Add the Graphviz path to the system's PATH environment variable:

   • On Windows, open "Control Panel", go to "System and Security" -> "System", and click "Advanced system settings" on the left.
   • In the System Properties dialog box, click the Advanced tab, and then click the Environment Variables button.
   • In the "System Variables" section, find the variable named "Path" and click the "Edit" button.
   • In the "Edit Environment Variables" dialog box, click the "New" button and add the installation path of Graphviz (for example: C:\Program Files\Graphviz\bin).
   • Click OK to save changes and close all dialog boxes.

4. Restart your terminal or editor and run the code again, and you should be able to successfully draw the flowchart.

If you've followed the steps above and are still having issues, make sure Graphviz is installed correctly and check that the paths are set correctly. graphvizAlso, if you are using an Anaconda environment, make sure you have Graphviz and libraries installed in the correct environment .

33. Drivers and stubs in software testing

• Driver and stub definitions:
  • Driver: a program that calls the module under test and provides test data.
  • Stub program: a simulation program called by the module under test to provide simulation data.

In software testing, especially in the integration testing phase, driver and stub are two important testing tools used to simulate various parts of the system.

1. Driver:

   • Definition: A driver is a testing tool used to simulate the behavior of upper-level modules in order to test the lower-level modules being developed or integrated. It calls the interface of the module under test and passes test data to simulate the behavior of the upper module.
   • Function: The main function of the driver is to call the module under test and pass the test data to it. In this way, the driver helps the tester verify whether the function of the module under test is correct and meets the design requirements.

2. Stub:

   • Definition: A stub is a testing tool used to simulate the behavior of lower-level modules in order to test the upper-level modules being developed or integrated. It provides an interface called by the upper module and returns simulated data or results to simulate the behavior of the lower module.
   • Function: The main function of the stub is to replace the lower module in order to test the correctness of the upper module. Stubs are usually used for integration testing. When the lower-level modules have not been fully developed, stubs can be used to simulate the behavior of the lower-level modules so that the upper-level modules can be tested.

In integration testing, drivers and stubs are often used together to gradually assemble and test various parts of the system. Testers can use drivers to call upper-level modules and use stubs to simulate lower-level modules, thereby gradually verifying the integration and functionality of the entire system.

This use of drivers and stubs helps isolate parts of the system so that testing can focus on the functionality of one module without being affected by other modules. This also enables parallel development and testing, since stubs can be used to simulate the behavior of other modules before development of one module is complete.

34. Generation of white box testing and black box test cases

• White-box test case generation: Design test cases according to the code structure to cover different paths.
• Black box test case generation: Design test cases based on functional requirements to ensure that the system meets user expectations.

White box testing:

White box testing, also known as structured testing or glass box testing, involves testing the internal structure of the software. Test cases are derived from an understanding of the code, logic, and code execution paths.

1. Statement coverage:

   • Test every statement in your code at least once.
   • Ensure that all executable statements are executed during testing.

2. Branch coverage:

   • Test every branch (decision) in your code.
   • Ensures that both true and false outcomes of decision points are implemented.

3. Path coverage:

   • Identify and test different paths in your code.
   • Execute all possible combinations of conditions.

4. Boundary value analysis:

   • Test the bounds or extreme values ​​of an input variable.
   • Check the behavior of the system at upper and lower limits.

5. Error handling:

   • Test the error path and verify that an appropriate error message is generated.
   • Check how the system handles unexpected input.

6. Integration Testing:

   • Verify correct interaction between different components.
   • Test the integration of modules to identify interface issues.

Black box testing:

Black box testing focuses on testing the functionality of the software without knowing the internal code structure. Test cases are designed based on specifications and requirements.

1. Equivalence class division:

   • Divide the input range into equivalence classes.
   • Test representative values ​​within each category.

2. Boundary value analysis:

   • Test input values ​​on the boundaries of equivalence classes.
   • Check how the system handles upper and lower bounded values.

3. Decision table test:

   • Identify different input conditions and their corresponding actions.
   • Test various combinations of inputs to cover all possible scenarios.

4. State transition test:

   • For systems with different states, transitions between states are tested.
   • Ensure that the system behaves correctly in different states.

5. Use case test:

   • Create test cases based on use cases.
   • Test the system's behavior in real-world scenarios.

6. Random testing:

   • Randomly select inputs and test their impact on the system.
   • This can uncover unexpected problems.

7. User interface testing:

   • Test the software's user interface to ensure it meets usability requirements.
   • Verify that all user input is processed correctly.

Keep in mind that an effective testing strategy typically combines white-box and black-box testing techniques to ensure complete coverage of the software’s functionality and internal structure.

1. Read the following instructions, answer questions 1 to 4, and fill in the answers in the corresponding columns on the answer sheet.

[Explanation]
Suppose you have completed a four-arithmetic operation automatic generation software and submitted it to the user. However, users are very dissatisfied with the software and have put forward new demands one after another, asking you to expand on the original software. For example, in addition to integers, it must also support the four arithmetic operations of true fractions, such as: 1/6+1/8=7/24; the program must be able to process user input, determine right and wrong, and accumulate scores; program support can be provided by the user. Choose addition, subtraction, multiplication, division, etc. operations.
[Question 1] What is a software crisis and what are the causes of software crises?
[Question 2] In the software development process, it is important to obtain user needs. Let’s talk about common preliminary requirements elicitation techniques?
[Question 3] If you are responsible for developing this software, talk about which software development model you plan to adopt (such as waterfall model, spiral model, prototype model, etc.) and explain the reasons.
[Question 4] Describe the type and work content of software maintenance, and explain what type of software maintenance this case belongs to.

Question 1: What is a software crisis and what are the causes of software crises?

Software crisis refers to a series of problems and challenges that arise in software development, making it difficult for software projects to be completed according to scheduled plans and budgets, leading to project failure or the delivered software being unable to meet user needs. The main causes of software crises include:

1. Increased complexity: The complexity of software systems increases with the addition of functionality, making it difficult to understand and maintain.

2. Change requirements: Frequent changes in user requirements for software make the original development plan invalid and increase the difficulty of development.

3. Technical level: In the early stages of software development, the technical level is relatively low, resulting in many errors during the development process and increasing the cost of repair.

4. Project management: Lack of effective project management and control leads to project schedule delays and cost overruns.

5. Lack of standards: The lack of unified software development standards and specifications leads to confusion in the development process.

Question 2: In the software development process, it is important to obtain user needs. Let’s talk about common preliminary requirements elicitation techniques?

Techniques for capturing user needs include:

1. Interview: Communicate directly with users and obtain user needs through questions and answers.

2. Questionnaire survey: Distribute questionnaires to collect information about users’ expectations and needs for the system.

3. Brainstorming: Team members brainstorm and summarize various possible requirements.

4. Prototype design: Make simple prototypes to allow users to understand the system more intuitively and provide feedback.

5. User observation: Observe users’ behavior in actual operations and discover their needs and problems.

Question 3: If you are responsible for developing this software, talk about which software development model you plan to adopt and explain why?

In this case, the spiral model might be chosen . Here’s why:

The main reasons for choosing the spiral model are as follows:

1. Risk management: This project faces changing user needs. The spiral model can conduct a more comprehensive consideration and analysis of demand changes, technical risks, etc. through the risk analysis stage, helping to better manage these risks.

2. Flexibility and iterative development: The spiral model allows for repeated iterations, with each spiral containing multiple phases, each of which can carry out requirements analysis, design, development and testing. This kind of flexibility can adapt to changes in demand and continue to be improved and adjusted during iterations.

3. User involvement and feedback: The spiral model encourages users to participate and provide feedback at every stage, which is crucial for projects facing frequent changes in requirements. Able to obtain user feedback in a timely manner and adjust and optimize software design and functions based on feedback.

4. Risk control: Through risk analysis and assessment at each spiral stage, risks in the project can be identified and dealt with in a timely manner, reducing the possibility of project failure.

5. Adaptability: The spiral model is suitable for projects that require flexibility and sensitivity to change, allowing iteration and adjustment during the development process to ensure that the software system meets actual needs.

Overall, choosing the spiral model can better manage risks, adapt to demand changes, continuously optimize software quality, and allow users to participate and provide feedback. It is a more appropriate choice for projects facing changing project environments.

Question 4: Describe the type and work content of software maintenance, and explain what type of software maintenance this case belongs to.

Software maintenance includes the following types:

1. Corrective Maintenance: Fix discovered errors and defects to ensure the normal operation of the software.

2. Adaptive Maintenance: Adjust to environmental changes (such as operating system upgrades, hardware replacement, etc.) to adapt to the new environment.

3. Perfective Maintenance: Optimizing and improving software to improve performance, maintainability and user experience.

4. Preventive Maintenance: Preventing future errors by identifying and fixing potential problems.

In this case, due to the new requirements raised by users, the original automatic generation software of four arithmetic operations needs to be expanded to support the four arithmetic operations of true fractions and other functions. This is adaptive maintenance because the software needs to be adjusted to accommodate new needs and changes. At the same time, operations such as judging user input and accumulating scores may also involve corrective maintenance and perfection maintenance to ensure the correctness and performance of the software.

---

2. Read the following instructions and fill in the answers in the corresponding columns on the answer sheet.

There are two types of users in a restaurant ordering system: customers and administrators. After logging in, customers can browse the menu, order dishes, view ordered menus, modify ordered menus, and check out; after logging in, administrators can manage menus and view ordered menus; after the corresponding operations are completed, customers and administrators can exit the system.
[Question 1] Briefly describe the RUP model of the object-oriented software development process.
[Question 2] What is a use case diagram? Please draw a use case diagram for the restaurant ordering system. (5 points)
[Question 3] In object-oriented design, what diagrams can be used to describe the use case implementation process? Describe at least two diagrams.
[Question 4] Discuss the differences and connections between object-oriented software development methods and structured software development methods.

Question 1: Briefly describe the RUP model of the object-oriented software development process.

The RUP (Rational Unified Process) model is an object-oriented software development process that emphasizes iterative and incremental development methods. RUP includes the following key features:

• Iterative: Divide the entire software development process into multiple iterations, each iteration contains part of the system's functions. Each iteration produces an executable version of the software.

• Incremental: Each iteration adds new functionality to the system and gradually improves the software. This incremental approach allows the software to gradually become more complete as it is developed.

• Use case driven: RUP emphasizes the use case driven approach, that is, clearly defining the functions and behaviors of the system from the user's perspective.

• Architecture-driven: Emphasis on the system's architecture design to ensure that the system is reasonably structured, scalable, and easy to maintain.

Question 2: What is a use case diagram? Please draw a use case diagram of the restaurant ordering system.

A use case diagram is a diagram that describes the functionality of a system, showing the various use cases (functions) of the system and the relationships between them. Here we can describe a use case diagram of a simple restaurant ordering system:

In this use case diagram, it may include two main roles: customer and administrator, as well as use cases such as customers ordering, viewing menus, and checkout, and use cases such as administrators managing menus and viewing orders. The relationship between use cases can be represented by association lines.

@startuml
left to right direction
package  餐厅点餐系统 {
    
    

actor 顾客 as C
actor 管理员 as A

rectangle  {
    
    
  C --> (浏览菜单)
  C --> (点菜)
  C --> (查看已点菜单)
  C --> (修改已点菜单)
  C --> (结账)
  A --> (管理菜单)
  A --> (查看已点菜单)
}
}
@enduml

Question 3: In object-oriented design, what diagrams can be used to describe the use case implementation process? Describe at least two diagrams.

In object-oriented design, the following two diagrams can be used to describe the use case implementation process:

1. Class Diagram: A class diagram represents the classes in the system and the relationships between them. Each use case usually corresponds to a class, which contains properties and methods that describe the structure and behavior of the use case.

2. Interaction Diagram: Interaction diagrams include sequence diagrams and collaboration diagrams, which are used to describe the interaction process between objects in the system. Sequence diagrams show the sequence of messages between objects, and collaboration diagrams show the collaboration relationships between objects.

Question 4: Discuss the differences and connections between object-oriented software development methods and structured software development methods.

• the difference:

  • Methodology: The object-oriented method emphasizes concepts such as objects, classes, inheritance, etc., and focuses on abstracting and modeling the system; while the structured method pays more attention to the design of processes, modules, data flows, etc.

  • Reusability: Object-oriented methods focus more on improving the maintainability and flexibility of the system through the reuse of classes and objects; structured methods are relatively weak in reuse.

  • Modularization: The object-oriented method realizes modular design through class encapsulation, which improves the maintainability of the system; the structured method realizes modular design through the division of modules.

• connect:

  • Goal: Both aim to build reliable, maintainable, and scalable software systems through good design and development methods.

  • Development process: All adopt an iterative and gradually improved development method, emphasizing staged and modular design.

  • Requirements analysis: Both focus on understanding and capturing user needs to ensure that the final system meets user expectations.

In practical applications, the two methods can often be used in combination, that is, using object-oriented ideas for system design, and using structured methods to achieve specific coding and module division. Such a combination can give full play to their respective advantages and improve the efficiency and quality of software development.

3. Read the following instructions and pictures, and fill in the answers in the corresponding columns on the answer sheet.

A hospital plans to develop a patient monitoring system. The system monitors the patient's vital signs through various devices and alerts doctors and nursing staff when vital signs are abnormal. The main functions of the system are as follows:
(1) Local monitoring: regularly obtain the patient's vital characteristics, such as body temperature, blood pressure, heart rate and other data.
(2) Format vital characteristics: Format the patient's important vital characteristics data, then store it in the log file and check the vital characteristics.
(3) Check vital characteristics: Compare the formatted vital characteristics with the preset normal range in the vital characteristics range file. If the preset range is exceeded, the system sends a warning message to doctors and caregivers.
(4) Maintain the range of vital characteristics: Doctors add or update the normal range of vital characteristic values ​​when necessary (for example, when new research results appear).
(5) Extract report: When a doctor or nursing staff requests a patient's vital characteristics report, the patient's vital characteristics are obtained from the log file to generate a characteristics report and returned to the requester.
(6) Generate medical records: Based on the vital characteristics in the log file, the doctor describes the patient's condition, forms a medical record and stores it in the medical record file.
(7) Medical record query: According to the doctor's medical record query request, the medical record file is searched and a medical record report is returned to the doctor.
(8) Generate treatment opinions: Based on the vital characteristics and medical records in the log file, the doctor gives treatment opinions, such as prescriptions, and stores them in the treatment opinion file.
(9) Inquire about treatment opinions: Doctors and nursing staff inquire about treatment opinions and treat patients accordingly.
Now we use structured methods to analyze and design the patient monitoring system, and obtain the top-level data flow diagram shown in Figure 3-1 and the layer 1 data flow diagram shown in Figure 3-2.

[Question 1] Using the words in the description, give the names of entities E1 to E3 in Figure 1.
[Question 2] Using the words in the description, give the names of the data stores D1 to D4 in Figure 2.
[Question 3]
(1) Four data flows are missing in Figure 2. Use the instructions, terms in Figure 3-1 and Figure 2, and give the name of the data flow and its starting point and end point.
(2) Explain whether there is data flow between entities E1 and E3, and explain the reason.
[Question 5] Describe the steps for mapping transformational data flow diagrams to software structures.

Figure 1 Top-level data flow diagram

Figure 2 Layer 1 data flow diagram

Question 1: Using the words in the description, give the names of entities E1 to E3 in Figure 1.

• E1: Patient
• E2: Nursing staff
• E3: Doctor

Question 2: Using the words in the description, give the names of the data stores D1 to D4 in Figure 2.

• D1: Vital Signs Range File
• D2: Log file
• D3: Medical records documents
• D4: Treatment opinion document

Question 3:

Data flow name	starting point	end
important vital signs	local monitoring	Format vital signs
Formatted vital signs	Format vital signs	Check vital signs
Medical records	Generate medical records	D3 or medical record file
vital signs	D2 or log file	Generate medical records

There cannot be data flow between E1 and E3, because one of the starting point and the end point of the data flow must be processing (processing).

Question 5: Describe the steps for mapping transformational data flow diagrams to software structures.

1. Identify processing (Processes): Identify all processes from the data flow diagram, and these processes will be mapped to modules or functions in the software.

2. Identify Data Stores: Identify data stores in the data flow diagram that will be mapped to databases or file systems.

3. Identify Data Flows: Identify data flows that represent the flow of information through the system. They will map to function calls or data passing between modules.

4. Identify External Entities: Identify external entities that represent entities outside the system, such as users or other systems. They will map to the system's interface with the external environment.

5. Draw Structure Chart: Draw a structure chart based on the identified processing, data storage, data flow and external entities. This chart represents the structure of the software system and the relationship between modules.

6. Clarify the interface and data transmission: Clarify the interface and data transmission method of each module in the structure diagram to ensure the collaborative work between various parts of the system.

7. Verification and adjustment: Verify the rationality of the structure diagram and make adjustments as needed to ensure that the system structure meets the design requirements and performance requirements.

---

4. Read the following instructions, answer the questions, and fill in the answers in the corresponding columns on the answer sheet.

【说明】
For years, programmers in industry have claimed that by working collaboratively, they have produced higher-quality software products in shorter amounts of time. But their evidence was anecdotal and subjective: “It works” or “It feels right.” To validate these claims, we have gathered quantitative evidence showing that pair programming—two programmers working side by side at one computer on the same design, algorithm, code, or test—does indeed improve software quality and reduce time to market. Additionally, student and professional programmers consistently find pair programming more enjoyable than working alone.
Yet most who have not tried and tested pair programming reject the idea as a redundant, wasteful use of programming resources:“Why would I put two people on a job that just one can do? I can’t afford to do that!” But we have found, as Larry Constantine wrote, that Two programmers in tandem is not redundancy; it’s a direct route to greater efficiency and better quality.”
【问题 1】什么是结对编程（pairwise programming）？
【问题 2】结对编程存在什么优缺点？
【问题 3】结合文中对结对编程的讨论，谈谈个人软件开发流程和团队开发流程？

Question 1: What is pairwise programming?

**Pair Programming** is a software development practice in which two programmers work together on the same computer to complete tasks such as design, algorithm, coding, or testing. In pair programming, one programmer is the "Driver" and is responsible for the actual coding work, while the other programmer is the "Observer" or "Navigator" and is responsible for reviewing the code. , make suggestions and think about higher-level design issues. The two programmers often swap roles to maintain a balance in the collaboration.

Question 2: What are the advantages and disadvantages of pair programming?

advantage:

1. Improve software quality: Pair programming helps find and correct errors, reduce the number of defects, and improve code quality.
2. Reduce post-launch problems: Since the code is double-reviewed, there are fewer problems that need to be fixed after go-live.
3. Knowledge sharing: Pair programming promotes knowledge sharing among team members and reduces information silos.
4. Accelerated learning: Beginners can learn and improve their skills faster by pair programming with experienced developers.

shortcoming:

1. Resource consumption: It requires the time and energy of two programmers, which may lead to seeming inefficiency.
2. Communication costs: If the partnership is not good or communication is poor, pair programming may not be effective.
3. Poor adaptability: Not all tasks and not everyone are suitable for pair programming, and some developers may prefer to work independently.

Question 3: Combined with the discussion of pair programming in the article, talk about the personal software development process and team development process?

Personal software development process:

• Work independently: Individual software developers typically complete the entire software development process alone, including requirements analysis, design, coding, testing, and maintenance.
• Independent decision-making: Developers make technical and design decisions independently and have high flexibility, but are prone to blind spots in independent thinking.

Team development process:

• Pair programming: In a team, using pair programming can improve code quality, reduce errors, accelerate learning, and promote team collaboration.
• Collaboration and communication: Team members need good communication and collaboration to jointly promote project progress through code review, iterative development, etc.
• Knowledge sharing: Knowledge sharing needs to be achieved within the team to avoid information silos and ensure that every member understands the overall architecture and design of the project.

In practice, individual software developers may focus more on independence and autonomous decision-making, while team development processes place greater emphasis on collaboration, communication, and sharing. In a team, appropriate development methods can be selected based on the nature of the project and the characteristics of the team members. Sometimes, individual independent work and team collaboration can also be combined to achieve the best development results.

5. Draw the corresponding UML class diagram model based on the following Java code snippets.

public class Animal {
public void move(){}
}
public interface ICanEat {
public void eat();
}
public class Dog extends Animal implements ICanEat {
public void eat() {}
public void bark(){}
}

Based on the provided Java code snippets, the following UML class diagram model can be drawn:

+-------------------+          +-----------------+          +----------------+
|      Animal       |          |    ICanEat      |          |      Dog       |
+-------------------+          +-----------------+          +----------------+
|                   |          |                 |          |                |
|                   |          |                 |          |                |
| + move()          |          | + eat()         |          | + eat()        |
|                   |          |                 |          | + bark()       |
+-------------------+          +-----------------+          +----------------+

In this UML class diagram:

• AnimalClass has one method move().
• ICanEatAn interface has one method eat().
• DogThe class inherits from Animalthe class and implements ICanEatthe interface. It has move()methods (from inheritance) and eat()methods (from interface implementation), as well as its own unique bark()methods.

Relationship description:

• Inheritance relationships are represented by solid arrows.
• Interface implementation relationships are represented by dashed arrows.
  The following is a simple UML class diagram model generated from the provided Java code snippet:

@startuml
class Animal {
  +move()
}

interface ICanEat {
  +eat()
}

class Dog {
  +eat()
  +bark()
}

Animal <|-- Dog
ICanEat <|.. Dog
@enduml

This UML class diagram represents the relationship between the Animal class, the ICanEat interface and the Dog class. Arrows between classes indicate inheritance or implementation relationships. The Animal class is a base class, and the Dog class inherits the Animal class and implements the ICanEat interface.

This code is written in PlantUML language and is used to generate UML use case diagrams to represent the participants and use case relationships of the tourist attraction guide system. You can use it to generate UML diagrams by following these steps:

1. Online editor: Use an online PlantUML editor such as PlantText or PlantUML Editor . Paste the code into the editor and it will generate the UML diagram for you.

2. Local environment: If you want to generate the diagram locally, you need to install PlantUML and use a text editor to create a file containing this code. Then, run PlantUML on the command line to generate the diagram.

   • Installation: Download PlantUML from the official website and install according to the instructions.

   • Command line: After the installation is complete, run PlantUML in the command line, for example:

     plantuml yourfile.uml
     

     will be yourfile.umlreplaced with the actual file name.

   • View image: After running the command, it will generate an image file (e.g. PNG). Open the image file using an image viewer to view the UML diagram.

6. Please answer the questions based on the following material descriptions.

The tourist attraction guide system implements the browsing and publishing of scenic spot guide information based on the Spring Boot framework and Vue.js framework. The roles that use this system include unauthorized users, authorized users, and backend administrators. Unauthorized users are allowed to use the system to register accounts, browse attraction introductions, browse attraction reviews, and search for scenic spots; authorized users, in addition to having the functional permissions to browse attraction introductions, browse attraction reviews, search for scenic spots, and can also log in to the system, post attraction reviews, Order tickets. When authorized users order tickets, they use the WeChat system to pay for the order. The backend administrator is an authorized user who can manage user information, scenic spot information, scenic spot information, etc.
1) Please analyze who are the system participants in the tourist attraction guide system?
2) Analyze the use cases associated with different participants, and draw a UML use case diagram of the tourist attraction guide system based on the analysis results.

1) System participants:

• Unauthorized user
• Authorized user
• Backstage administrator

2) Associated use case analysis and UML use case diagram:

• Unauthorized users:

  • register account
  • Browse attraction introductions
  • Browse attraction reviews
  • Search scenic spots

• Authorized users:

  • log in system
  • Post a review of an attraction
  • Order tickets
  • Browse attraction introductions
  • Browse attraction reviews
  • Search scenic spots

• Backend administrator:

  • Manage user information
  • Manage scenic spot information
  • Manage attraction information

UML use case diagram:

+------------------------+        +------------------------+       +------------------------+
|   Unauthorized User   |         |     Authorized User    |       |  Back-End Administrator|
|------------------------|        |------------------------|       |------------------------|
| + RegisterAccount()    |        | + Login()              |       | + ManageUserInfo()     |
| + BrowseSpotIntro()    |        | + PostComment()        |       | + ManageScenicInfo()   |
| + BrowseSpotComments() |--------| + OrderTicket()        |       | + ManageSpotInfo()     |
| + SearchScenic()       |        | + BrowseSpotIntro()    |       +------------------------+
+------------------------+        | + BrowseSpotComments() |
                                  | + SearchScenic()       |
                                  +------------------------+

This is a simplified UML use case diagram without drawing specific relationship lines. Relationship lines usually include association, inheritance, include, etc. Based on the actual needs of the system, appropriate relationships can be added to the use case diagram to more accurately express the relationship between actors and use cases.

The association of the use case diagram is as follows:

• Unauthorized users: Register an account, browse attraction introductions, browse attraction reviews, and search scenic spots.
• Authorized users: log in to the system, post comments on attractions, order tickets (including WeChat payment), browse attraction introductions, browse attraction reviews, and search for scenic spots.
• Backend administrator: manages user information, manages scenic spot information, and manages scenic spot information.

UML use case diagram example:

@startuml
left to right direction
package "旅游景区指南系统" {

actor 未授权用户 as UU
actor 已授权用户 as AU
actor 后台管理员 as Admin

  rectangle  {
    UU --> (注册账户)
    UU --> (浏览景点介绍)
    UU --> (浏览景点评论)
    UU --> (搜索景区)

    AU --> (登录系统)
    AU --> (发表景点评论)
    AU --> (订购门票)

    Admin --> (管理用户信息)
    Admin --> (管理景区信息)
    Admin --> (管理景点信息)
  }
}
@enduml

This use case diagram briefly shows the actors of the system and their associated use cases.

This code is written in PlantUML language and is used to generate UML use case diagrams to represent the participants and use case relationships of the tourist attraction guide system. You can use it to generate UML diagrams by following these steps:

1. Online editor: Use an online PlantUML editor such as PlantText or PlantUML Editor . Paste the code into the editor and it will generate the UML diagram for you.

2. Local environment: If you want to generate the diagram locally, you need to install PlantUML and use a text editor to create a file containing this code. Then, run PlantUML on the command line to generate the diagram.

   • Installation: Download PlantUML from the official website and install according to the instructions.

   • Command line: After the installation is complete, run PlantUML in the command line, for example:

     plantuml yourfile.uml
     

     will be yourfile.umlreplaced with the actual file name.

   • View image: After running the command, it will generate an image file (e.g. PNG). Open the image file using an image viewer to view the UML diagram.

Test questions and answers:

1. The functions of a certain book management system are as follows:
   ① After logging into the system, readers can query information, reserve books and renew books;
   ② After logging into the system, librarians can query information, manage reader information and book information, and borrow and return books. ③
   When a reader returns a book, if it exceeds the expected time, the librarian will fine the reader in accordance with library regulations;
   ④ The background administrator can maintain the system after logging in to the system
   . Please analyze the needs and answer the following questions:
   (1) Please Who are the system participants in analyzing requirements?
   (2) Based on the analysis results of question (1), further analyze the system use cases associated with each participant.
   (3) Use UML use case diagrams to visualize the analysis results of questions (1) and (2).
   Reference answers:
   (1) Readers, librarians and administrators;
   (2) Readers: login, book reservation, book renewal, information inquiry;
   librarian: login, information inquiry, reader information management, book information management;
   management Member: Login, System Maintenance
   (3) The reference diagram of the use case diagram is as follows:
   

2. A hospital plans to develop a distributed patient monitoring system (PMS: ​​Patients Monitoring System). PMS will be used to monitor the important physiological signals of each patient in the ward (such as body temperature, blood pressure, pulse signal, etc.), and can regularly update and manage the patient's medical records. In addition, when the patient's physiological signal exceeds the safety range specified by the doctor, the system can immediately notify the nursing staff, and the nursing staff can generate a patient-related report through the system at any time when needed.
   The main functions of PMS are:
   ① Realize local monitoring through a bed monitor to obtain the patient's physiological signals.
   ② Implement central monitoring in the nurse’s office
   ③ Update and manage patient medical records
   ④ Generate patient status reports and alarm information
   Questions:
   (1) Please analyze what are the data source points and data end points of PMS?
   (2) According to the demand description, which data processing can PMS be broken down into?
   (3) Based on the analysis results of questions (1) and (2), draw a layer 1 data flow diagram.
   Reference answers:
   (1) The data source of PMS is patients and nurses; the data end point is nurses;
   (2) PMS can be divided into four data processing: local monitoring, central monitoring, generating reports and recording patient physiological data
   (3) 1-layer data The flow diagram reference diagram is as follows: