UML預習與復習

问题：

What is object technology?
什么是面向对象技术？
What do you perceive as object technology’s strength?
你认为面向对象技术的优势是什么？
What is its weakness?
它的弱点是什么？

答案：

1. What is object technology?

Answer:
Object technology is a set of principles (abstraction, encapsulation, polymorphism) guiding software construction, together with languages, databases, and other tools that support those principles.
翻译：
面向对象技术是一系列支持软件开发的原则（抽象、封装、多态性），以及支持这些原则的程序设计语言、数据库和其他工具。

2. What do you perceive as object technology’s strength?

Answer:
The strengths of object technology include:
• It reflects a single paradigm.
• It facilitates architectural and code reuse.
• It reflects real-world models more closely.
• It encourages stability.
• It is adaptive to change.
翻译：
面向对象技术的优势包括：
• 它反映一个特定的范式。
• 它有利于架构和代码的重用。
• 它更真实地反映现实世界的模型。
• 它鼓励稳定性。
• 它能适应需求的变化。

3. What is its weakness?

Answer:
The weaknesses of object technology include:
• Complexity: Object-oriented systems can become overly complex, especially for large-scale projects, making them harder to understand and maintain.
• Performance Overhead: The use of objects and their interactions (e.g., method calls, inheritance) can introduce performance overhead compared to procedural programming.
• Steep Learning Curve: Developers need to understand concepts like abstraction, encapsulation, inheritance, and polymorphism, which can be challenging for beginners.
• Over-Engineering: There is a risk of over-engineering solutions by creating too many classes or abstractions, which can lead to unnecessary complexity.
翻译：
面向对象技术的弱点包括：
• 复杂性： 面向对象的系统可能变得过于复杂，尤其是在大型项目中，这使得它们更难理解和维护。
• 性能开销： 使用对象及其交互（如方法调用、继承）可能会比过程式编程引入更多的性能开销。
• 学习曲线陡峭： 开发人员需要理解抽象、封装、继承和多态等概念，这对初学者来说可能具有挑战性。
• 过度设计： 存在通过创建过多的类或抽象来过度设计解决方案的风险，这可能导致不必要的复杂性。

解释：

What is object technology?
面向对象技术是一种软件开发方法，它基于对象的概念，强调通过抽象、封装和多态等原则来组织代码。它还包括支持这些原则的工具和语言（如Java、C++、Python等）以及数据库（如对象数据库）。
What do you perceive as object technology’s strength?
面向对象技术的优势在于它的模块化和现实世界的映射能力。通过封装，代码更易于维护；通过继承和多态，代码可以重用和扩展；通过抽象，复杂的系统可以被简化为可管理的部分。此外，面向对象技术能够更好地适应需求的变化，因为它允许在不修改现有代码的情况下扩展功能。
What is its weakness?
尽管面向对象技术有许多优点，但它也有一些缺点。首先，它可能导致系统的复杂性增加，尤其是在设计不当的情况下。其次，面向对象的性能可能不如过程式编程高效，特别是在需要频繁创建和销毁对象的场景中。此外，学习面向对象的概念需要时间和经验，初学者可能会感到困难。最后，过度使用面向对象的设计模式可能导致过度工程化，增加不必要的复杂性。

问题：

What is UML?
什么是UML？
List at least three benefits of developing with UML.
列举至少三个使用UML开发的优点。

答案：

1. What is UML?

Answer:
UML (Unified Modeling Language) is a language for Visualizing, Specifying, Constructing, and Documenting the artifacts of a software-intensive system.
翻译：
UML（统一建模语言）是一门用于对面向对象开发的产品进行可视化建模、说明、架构和文档编制的标准语言。

2. List at least three benefits of developing with UML.

Answer:
The benefits of developing with UML include:

Precision and Clarity: UML helps build models that are precise, unambiguous, and complete, reducing misunderstandings among stakeholders.
Language Independence: UML models can be directly connected to a variety of programming languages, making it easier to implement designs across different platforms.
Comprehensive Documentation: UML supports documentation for system architecture, requirements, tests, project planning, and release requirements, ensuring that all aspects of the system are well-documented.
翻译：
使用UML开发的优点包括：
精确性和清晰性： UML帮助建立精确、完整、不含糊的模型，减少利益相关者之间的误解。
语言独立性： UML模型可以和多种程序设计语言建立直接连接，使得在不同平台上实现设计更加容易。
全面的文档支持： UML支持系统架构文档、需求文档、测试文档、项目计划和版本说明等文档的编制，确保系统的各个方面都有良好的记录。

解释：

What is UML?
UML（统一建模语言）是一种标准化的建模语言，主要用于面向对象的软件开发。它提供了一种通用的方式来描述系统的结构、行为和交互。UML的核心用途包括可视化系统设计、明确系统需求、构造系统模型以及记录系统文档。它的图形化表示方式使得开发者、分析师和其他利益相关者能够更直观地理解系统。
Benefits of developing with UML:
• Precision and Clarity: UML通过标准化的图形符号和建模方法，帮助开发团队创建清晰、精确的模型，避免因沟通不畅导致的误解。
• Language Independence: UML模型的抽象性使得它可以与多种编程语言（如Java、C++、Python等）对应，开发者可以根据项目需求选择合适的实现语言。
• Comprehensive Documentation: UML不仅用于设计系统架构，还可以用于记录需求、测试计划、项目管理和版本控制等文档，确保系统的整个生命周期都有良好的文档支持。

UML的优点使得它在复杂的软件开发项目中尤为重要，尤其是在需要多方协作和长期维护的项目中。

问题：

What process characteristic best fit the UML? Describe each characteristic.
什么过程特性最适合UML？请描述每个特性。

答案：

Process Characteristics that Best Fit the UML:

The process characteristics that best fit the UML are:

Use-case driven
Architecture-centric
Iterative and incremental

Description of Each Characteristic:

Use-case driven:
• Description: UML emphasizes the use of use cases to capture system requirements and define system functionality. Use cases describe how users interact with the system and what the system should do from the user’s perspective.
• Explanation: By focusing on use cases, UML ensures that the system is designed to meet user needs and expectations. Use cases serve as a foundation for modeling system behavior, interactions, and functionality throughout the development process.
Architecture-centric:
• Description: UML focuses on creating and maintaining a robust system architecture as the backbone of the development process. The architecture defines the overall structure of the system, including its components, relationships, and interactions.
• Explanation: By being architecture-centric, UML ensures that the system is well-structured, scalable, and maintainable. It helps developers focus on high-level design decisions early in the process, which guide the detailed design and implementation phases.
Iterative and incremental:
• Description: UML supports an iterative and incremental development approach, where the system is developed in small, manageable iterations. Each iteration adds functionality to the system and refines existing features.
• Explanation: This approach allows for continuous feedback, risk management, and adaptation to changing requirements. It ensures that the system evolves over time, with each iteration building on the previous one.

解释：

Use-case driven:
UML的核心特性之一是以用例为驱动。用例是从用户的角度描述系统功能和行为的一种方式。通过用例，开发团队可以明确系统的需求，并以此为基础进行系统建模和设计。用例驱动的开发确保了系统始终以满足用户需求为目标。
Architecture-centric:
UML强调以系统架构为中心。架构是系统的骨架，定义了系统的整体结构、组件及其关系。通过以架构为中心，UML帮助开发团队在早期阶段做出高层次的设计决策，从而确保系统的可扩展性、可维护性和稳定性。
Iterative and incremental:
UML支持迭代和增量开发方法。这种方法将系统开发分为多个小的迭代周期，每个周期都会增加新的功能并改进现有功能。迭代和增量开发允许团队持续收集反馈、管理风险，并根据需求的变化进行调整，从而使系统逐步完善。

总结：

• Use-case driven 确保系统设计以满足用户需求为核心。
• Architecture-centric 确保系统具有良好的结构和可扩展性。
• Iterative and incremental 确保系统可以逐步开发和改进，适应变化的需求。

这些特性使得UML成为一种强大的建模语言，适用于复杂的软件开发项目。

问题：

What is a use-case driven process?
什么是用例驱动的过程？
What is use-case?
什么是用例？
What’s the benefits of use case?
用例的好处是什么？

答案：

1. What is a use-case driven process?

Answer:
A use-case driven process is a development approach where use cases are the foundation for the entire software development lifecycle. Use cases define the interactions between users (actors) and the system to achieve specific goals. They guide the analysis, design, implementation, and testing of the system.
翻译：
用例驱动的过程是一种开发方法，其中用例是整个软件开发生命周期的基础。用例定义了用户（角色）与系统之间的交互，以实现特定目标。它们指导系统的分析、设计、实现和测试。

2. What is use-case?

Answer:
A use case is a text-based description of a sequence of events that a system performs to achieve a specific goal for a user or actor. It describes how a system interacts with its users (actors) to fulfill their needs and the results they observe. Use cases are often written as “text stories” and are widely used to discover and record system requirements.
翻译：
用例是对系统为完成用户或角色的特定目标而执行的一系列事件流的文本描述。它描述了系统如何与用户（角色）交互以满足他们的需求以及他们观察到的结果。用例通常以“文本故事”的形式编写，广泛用于发现和记录系统需求。

3. What’s the benefits of use case?

Answer:
The benefits of use cases include:

Simplicity and Clarity: Use cases are concise, simple, and understandable by a wide range of stakeholders, including domain experts and non-technical users.
Requirement Discovery and Documentation: Use cases help discover and record system requirements in a structured way.
User-Centric Design: They emphasize user goals and perspectives, ensuring the system meets user needs effectively.
Model Synchronization: Use cases help synchronize the content of different models (e.g., design models, implementation models) throughout the development process.
翻译：
用例的好处包括：
简洁明了： 用例简洁、清晰，可以被广泛的利益相关者（包括领域专家和非技术用户）理解。
需求发现与记录： 用例以结构化的方式帮助发现和记录系统需求。
以用户为中心的设计： 它们强调用户目标和视角，确保系统能够有效满足用户需求。
模型同步： 用例有助于在整个开发过程中实现不同模型（如设计模型、实现模型）之间的同步。

解释：

1. What is a use-case driven process?

用例驱动的过程是一种以用例为核心的开发方法。在这种方法中，用例不仅是需求的载体，还贯穿于整个软件开发生命周期。通过用例，开发团队可以明确系统的功能需求、用户交互以及系统的行为。这种方法确保了开发过程的每一步都与用户需求紧密相关，从而提高了系统的实用性和用户满意度。

2. What is use-case?

用例是对系统功能的描述，通常以文本形式记录。它从用户的角度出发，描述了用户如何与系统交互以实现特定目标。用例的核心是用户（角色）和系统的交互过程，包括用户的行为、系统的响应以及最终的结果。用例的描述方式简单易懂，便于团队成员之间的沟通和需求的记录。

3. What’s the benefits of use case?

• 简洁明了： 用例以简单的文本形式描述系统功能，避免了复杂的技术术语，使得非技术人员也能理解系统的需求。
• 需求发现与记录： 用例帮助团队在开发早期阶段发现和记录需求，确保需求的完整性和准确性。
• 以用户为中心的设计： 用例强调用户的目标和视角，确保系统设计围绕用户需求展开，从而提高用户体验。
• 模型同步： 用例作为系统的核心需求描述，可以帮助不同开发阶段（如分析、设计、实现）的模型保持一致，避免需求偏差。

总结：

• 用例驱动的过程 确保了开发过程以用户需求为核心，贯穿整个开发生命周期。
• 用例是对系统功能的简单描述，强调用户与系统的交互。
• 用例的好处 包括简洁性、需求管理、用户导向以及模型同步，使得用例成为软件开发中的重要工具。

问题：

What is system’s architecture?
什么是系统的架构？
What is an architecture-centric Process?
什么是以架构为中心的开发过程？
What is an iteration?
什么是迭代？
What is the benefits of Iterative Development?
迭代开发的好处是什么？

答案：

1. What is system’s architecture?

Answer:
A system’s architecture is the primary artifact for conceptualizing, constructing, managing, and evolving the system. It defines the system’s concepts and structure, guiding the development process.
翻译：
系统的架构是开发过程中最重要的产出，它定义了系统的概念和结构，是管理开发过程和指导系统开发的重要依据。

2. What is an architecture-centric Process?

Answer:
An architecture-centric process emphasizes that the architecture is the central focus of the project team to shape the system. Since a single model cannot reflect all aspects of a system, this process supports multiple models and views.
翻译：
以架构为中心的开发过程强调架构是项目团队塑造系统的核心。由于单一模型无法反映系统的所有方面，这种过程支持多个模型和视图。

3. What is an iteration?

Answer:
An iteration is a series of software development activities performed under a defined plan and evaluation criteria. Each iteration is an integrated development process, including testing, and produces an executable software version.
翻译：
迭代是在既定计划和评价标准下执行的一系列软件开发活动。每次迭代是一个集成的开发过程，包括测试，并产生一个可执行的软件版本。

4. What is the benefits of Iterative Development?

Answer:
The benefits of iterative development include:

Resolving foreseeable risks before large investments.
Gaining user feedback in early iterations.
A continuous testing and integration process.
Objective milestones focused on short-term goals.
Measuring development progress by evaluating the execution process.
Partial executable components can be deployed.
翻译：
迭代开发的好处包括：
在大规模投资前解决可预见的风险。
在早期迭代中获得用户反馈。
持续的测试和集成过程。
短期目标集中于客观的里程碑。
通过评估执行过程来衡量开发进度。
部分可执行部件可以被配置或部署。

解释：

1. What is system’s architecture?

系统的架构是整个开发过程的核心产物，它定义了系统的整体结构和功能组织方式。架构为开发团队提供了指导，帮助他们理解系统的组成部分及其关系，从而更高效地进行开发和维护。

2. What is an architecture-centric Process?

以架构为中心的开发过程强调架构在整个开发中的核心地位。由于单一模型无法全面描述系统的所有方面（如功能、性能、安全性等），这种过程支持多个模型和视图，以便从不同角度描述系统。

3. What is an iteration?

迭代是软件开发中的一个阶段，包含一系列计划好的活动（如设计、编码、测试等）。每次迭代都会产生一个可运行的软件版本，逐步完善系统功能，直到满足最终需求。

4. What is the benefits of Iterative Development?

• 风险管理： 在项目早期阶段，通过迭代可以发现并解决潜在风险，避免后期大规模修改。
• 用户反馈： 早期迭代可以交付部分功能，帮助团队获取用户反馈并及时调整方向。
• 持续测试和集成： 每次迭代都包含测试和集成，确保软件质量逐步提高。
• 短期目标： 迭代开发将项目分解为短期目标，便于管理和跟踪进度。
• 可部署部件： 部分功能可以在迭代中交付，提前投入使用。

总结：

• 系统架构 是开发的核心指导，定义了系统的结构和功能。
• 以架构为中心的开发 支持多模型和多视图，全面描述系统。
• 迭代是开发中的阶段性活动，每次产生一个可运行的软件版本。
• 迭代开发的好处 包括风险管理、用户反馈、持续测试、短期目标和部分交付。

7. What are the basic principles of OO technology? Describe each in detail.

Principles:

Abstraction (抽象)
• Definition: Extracts the essential characteristics of an entity that distinguish it from others, defines the boundary from the viewer’s perspective, and represents the ideal essence of something without being a concrete manifestation.
• 解释: 抽象是从实体中提取区分其他类型实体的本质特征，定义外界所能观察到的边界，并不具体表示某个实体，而是表示出其基本特征。
Encapsulation (封装)
• Definition: Hides the implementation details from clients.
• 解释: 封装是对用户隐藏执行过程，仅暴露必要的接口，增强安全性和可维护性。
Modularity (模块化)
• Definition: Breaks up complex systems into manageable pieces.
• 解释: 模块化是将复杂系统分成几个可控制的模块，帮助人们理解复杂系统。
Hierarchy (层次)
• Definition: A structured organization from high to low with a clear order, where elements at the same level share the same level of abstraction.
• 解释: 层次是一种从高到低有确定次序的结构，同一层的元素具有相同的抽象程度，常用于表示继承关系。

8. What is a use case model? Which artifacts can be included in a use case model?

Definition:
• 英文: A use case model describes a system’s functional requirements in terms of use cases, representing the system’s intended functions (use cases) and its environment (actors).
• 中文: 用例模型是根据用例描述系统的功能需求，表示系统的预期功能（用例）及其环境（参与者）。

Artifacts in a Use Case Model (用例模型中的工件):

Actors (参与者): External entities (users or systems) that interact with the system.
• 中文: 参与者是与系统交互的外部实体（用户或系统）。
Use Cases (用例): Specific functionalities or behaviors the system provides.
• 中文: 用例是系统提供的具体功能或行为。
Communicate-Association (通信关联): Relationships between actors and use cases, showing interactions.
• 中文: 通信关联是参与者和用例之间的关系，表示它们之间的交互。

Explanation (解释):
A use case model includes all written use cases and represents the system’s functionality and environment. It also captures requirements, helping stakeholders understand how the system will be used.
• 中文解释: 用例模型包括所有书写的用例，描述了系统的功能和运行环境，同时捕获需求，帮助利益相关者理解系统的使用方式。

9. List three types of relationships existed between different use cases and give examples.

1. 泛化关系 (Generalization)
• 解释: 用例的泛化关系表示子用例可以继承父用例的结构，并可以在父用例的基础上增加额外的行为。
• 例子:
• 父用例: “用户登录”
• 子用例: “普通用户登录”, “管理员登录”
• 解释: “普通用户登录”和”管理员登录”继承了”用户登录”的基本行为，但可能在权限验证或功能上有额外的行为。

2. 包含关系 (Include)
• 解释: 包含关系表示基用例显式地在其指定位置将另一个用例包含进来，使其成为自己的行为的一部分。被包含的用例不能单独存在，只能作为基用例的一部分。
• 例子:
• 基用例: “下订单”
• 被包含用例: “验证库存”
• 解释: “下订单”过程中需要显式地包含”验证库存”的步骤，因为库存验证是下订单流程的一部分。

3. 扩展关系 (Extend)
• 解释: 扩展关系表示基用例可以隐式地包含另一个用例作为其行为的一部分，扩展用例的行为通常是可选的，且发生的位置由扩展用例决定。
• 例子:
• 基用例: “结账”
• 扩展用例: “应用优惠券”
• 解释: “结账”过程中可以选择性地包含”应用优惠券”的步骤，这并不是结账的必要流程，但在特定条件下可以触发。

10. Explain the following diagram and their elements with examples.

1) Use Case Diagram (用例图)
• 解释: 用例图由角色（Actor）、用例（Use Case）以及它们之间的关系构成，描述了角色与系统之间的交互。
• 例子:
• 角色: “顾客”
• 用例: “浏览商品”, “下订单”, “支付”
• 关系: “顾客”可以触发”浏览商品”和”下订单”，”下订单”可能包含”验证库存”。
• 解释: 用例图展示了系统的主要功能和外部角色的交互。

2) Activity Diagram (活动图)
• 解释: 活动图是一种行为图，用于描述用例中的活动流程，展示从一个活动到另一个活动的控制流。
• 例子:
• 描述”下订单”的流程：

1. 浏览商品 → 2. 添加到购物车 → 3. 结账 → 4. 支付 → 5. 订单完成

• 解释: 活动图类似于流程图，展示了业务流程中的步骤和决策点。

3) Sequence Diagram (顺序图)
• 解释: 顺序图是一种交互图，强调消息传递的时间顺序，展示对象之间的交互过程。
• 例子:
• 在”支付”过程中：

1. 用户 → 系统: 输入支付信息  
2. 系统 → 支付网关: 发送支付请求  
3. 支付网关 → 系统: 返回支付结果  
4. 系统 → 用户: 显示支付成功

• 解释: 顺序图按时间顺序展示了对象之间的消息传递。

4) Collaboration Diagram (协作图)
• 解释: 协作图强调对象在交互中的组织和关系，展示对象如何协作完成任务。
• 例子:
• 在”下订单”过程中：
◦ 用户 → 购物车: 添加商品
◦ 购物车 → 订单系统: 创建订单
◦ 订单系统 → 库存系统: 验证库存
• 解释: 协作图关注对象之间的交互关系，而不是时间顺序。

5) Class Diagram (类图)
• 解释: 类图是系统的静态视图，展示类、类的内部结构以及它们之间的关系（如继承、关联等）。
• 例子:
• 类: “用户” (属性: 用户名, 密码; 方法: 登录, 注销)
• 类: “订单” (属性: 订单号, 总金额; 方法: 创建订单, 取消订单)
• 关系: “用户”与”订单”之间的关联关系。
• 解释: 类图展示了系统的静态结构，描述了类的属性、方法及其关系。

6) Statechart Diagram (状态图)
• 解释: 状态图描述实体基于事件反应的动态行为，展示实体如何根据当前状态对不同事件做出反应。
• 例子:
• 订单状态:

1. 待支付 → 支付成功 → 已发货 → 已完成  
2. 待支付 → 支付失败 → 取消订单

• 解释: 状态图展示了订单在不同事件下的状态变化。

7) Deployment Diagram (部署图)
• 解释: 部署图展示系统中软件和硬件的物理架构，包括处理节点、通信链接以及组件分布。
• 例子:
• 节点: “Web服务器”, “数据库服务器”
• 组件: “Web应用”, “数据库服务”
• 通信链接: “Web服务器 ↔ 数据库服务器”
• 解释: 部署图展示了系统的物理部署结构，帮助理解硬件和软件的分布及交互方式。

11. Describe the similarities and differences between the sequence diagram and collaboration diagram.

相同点 (Similarities):

语义等价: 协作图和顺序图可以相互转换而不丢失任何信息。
动态行为建模: 都用于对系统的动态行为进行建模。
用例情节建模: 都可以用来描述用例的具体情节。

不同点 (Differences):

协作图 (Collaboration Diagram)	顺序图 (Sequence Diagram)
根据交互行为显示对象间的关系。	显示消息传递的明确顺序。
更适合观察协作模型。	更适合观察控制焦点。
更适合观察一个对象所受到的各种影响。	更适合观察全部的事件流。
更适合头脑风暴会议。	更适合实时描述和复杂情景建模。

解释 (Explanation):
• 协作图更关注对象之间的关系和协作模式，适合用来分析对象之间的交互结构，尤其是在头脑风暴阶段。
• 顺序图则强调消息的时间顺序和控制焦点，更适合用来描述复杂的实时场景和事件流。

12. Define the different relationships in class diagram: dependency, association, aggregation, composition, generalization.

1. Dependency (依赖)
• 定义: 一个类的改变可能影响或提供信息给其他类。依赖关系表明一个类（客户类）依赖于另一个类（供应类）所提供的某些服务。
• 解释: 依赖是一种较弱的关系，通常表现为方法参数、局部变量或静态方法调用。
• 例子:
• 类A的某个方法使用了类B的对象作为参数。
• 中文解释: 类A依赖于类B，但这种依赖是临时的，不会长期持有类B的实例。

2. Association (关联)
• 定义: 表示两个或多个类之间的语义联系，说明了它们实体之间的关系。
• 解释: 关联是一种持久的关系，表示类之间的连接，可能是单向或双向的。
• 例子:
• 学生和课程之间的关系，学生可以选修多门课程。
• 中文解释: 学生类和课程类之间存在关联关系，表示学生可以选课。

3. Aggregation (聚合)
• 定义: 聚合是一种特殊的关联关系，表示整体与部分的关系（“是部分”的关系），但部分可以独立于整体存在。
• 解释: 聚合是一种较弱的关系，部分对象的生命周期不依赖于整体对象。
• 例子:
• 汽车和轮胎之间的关系，轮胎可以独立于汽车存在。
• 中文解释: 汽车是整体，轮胎是部分，但轮胎可以在其他地方使用。

4. Composition (组合)
• 定义: 组合是强聚合，表示整体对部分的包容关系（“包含”的关系），部分不能独立于整体存在。
• 解释: 组合是一种强关系，部分对象的生命周期依赖于整体对象。
• 例子:
• 公司和部门之间的关系，部门不能独立于公司存在。
• 中文解释: 公司是整体，部门是部分，部门的存在依赖于公司。

5. Generalization (泛化)
• 定义: 表示一个类共享其他类的结构或行为的一种类与类之间的关系（“是一种”的关系）。
• 解释: 泛化是一种继承关系，子类继承父类的属性和方法。
• 例子:
• 动物和狗之间的关系，狗是动物的一种。
• 中文解释: 狗类继承了动物类的特性，狗是动物的一种具体类型。

总结:
• 依赖: 临时使用，关系较弱。
• 关联: 持久连接，关系中等。
• 聚合: 整体与部分，部分可独立存在。
• 组合: 整体与部分，部分不可独立存在。
• 泛化: 继承关系，“是一种”关系。

13. What is a node in deployment diagram? List two different types of nodes.

定义:
• 中文: 结点是存在于运行时系统中的物理元素，代表了一种可计算资源。
• 英文: A physical element that exists at run-time and represents a computational resource.

两种类型的结点 (Two types of nodes):

处理机节点 (Processor Node):
• 中文: 运行软件的计算设备，例如服务器、计算机等。
• 英文: A node that runs software, such as servers or computers.
设备节点 (Device Node):
• 中文: 由处理机控制的设备，例如打印机、传感器等。
• 英文: A device that is controlled by a processor, such as printers or sensors.

14. Describe the extensibility mechanisms of UML.

定义:
• 中文: UML的扩展机制允许用户根据特定需求对UML进行定制，增加新的建模元素、属性或语义。
• 英文: UML’s extensibility mechanisms allow users to customize UML for specific needs by adding new modeling elements, attributes, or semantics.

三种扩展机制 (Three extensibility mechanisms):

构造型 (Stereotype):
• 中文: 表示新的建模元素，用于扩展UML的基本元素。
• 英文: Represents new modeling elements by extending basic UML elements.
• 例子: 在类图中添加 «interface» 或 «entity» 等构造型。
标记值 (Tagged Value):
• 中文: 表示新的建模属性，用于为模型元素添加额外的信息。
• 英文: Represents new modeling attributes by adding extra information to model elements.
• 例子: 为类添加 «version=1.0» 或 «author=John» 等标记值。
约束 (Constraint):
• 中文: 表示新的建模语义，用于定义模型元素的附加规则或限制。
• 英文: Represents new modeling semantics by defining additional rules or restrictions for model elements.
• 例子: 在关联关系上添加约束 «{ordered}» 或 «{max=5}»。

总结:
• 构造型 (Stereotype): 扩展建模元素。
• 标记值 (Tagged Value): 扩展建模属性。
• 约束 (Constraint): 扩展建模语义。

15. What is the function of Stereotypes? Give two examples of stereotypes.

功能 (Function):
• 中文: 构造型（Stereotypes）是UML的扩展机制之一，用于为现有的建模元素添加新的语义或含义，表示特定的建模元素类型。
• 英文: Stereotypes extend UML by adding new semantics to existing modeling elements, allowing the representation of specific types of elements.

两个构造型示例 (Two examples of stereotypes):

«interface»:
• 中文: 表示接口，用于类图中标记一个类为接口。
• 英文: Represents an interface, marking a class as an interface in a class diagram.
«entity»:
• 中文: 表示实体类，通常用于领域建模中标记一个类为实体。
• 英文: Represents an entity class, often used in domain modeling to mark a class as an entity.

16. Explain the six best practices of software engineering.

1. 迭代开发软件 (Develop Iteratively):
• 中文: 软件开发应分阶段进行，通过多次迭代逐步完善系统，每次迭代都包含需求分析、设计、实现和测试。
• 英文: Software development should be done in phases, gradually improving the system through multiple iterations, each including analysis, design, implementation, and testing.

2. 需求管理 (Manage Requirements):
• 中文: 明确和管理软件需求，确保需求在整个开发过程中得到跟踪和验证。
• 英文: Clearly define and manage software requirements, ensuring they are tracked and validated throughout the development process.

3. 使用基于构件的体系结构 (Use Component Architectures):
• 中文: 将系统划分为可重用的构件模块，便于开发、维护和扩展。
• 英文: Divide the system into reusable component modules to facilitate development, maintenance, and scalability.

4. 可视化软件建模 (Model Visually):
• 中文: 使用可视化建模工具（如UML）描述系统的结构和行为，帮助团队理解和沟通。
• 英文: Use visual modeling tools (such as UML) to describe the structure and behavior of the system, aiding understanding and communication within the team.

5. 验证软件质量 (Continuously Verify Quality):
• 中文: 在开发过程中持续进行测试和评审，确保软件质量符合预期。
• 英文: Continuously test and review the software during development to ensure it meets quality expectations.

6. 控制软件变更 (Manage Change):
• 中文: 对需求、设计和代码的变更进行有效管理，确保变更不会引入新的问题。
• 英文: Effectively manage changes to requirements, design, and code to prevent introducing new issues.

总结:
这六大最佳实践是软件工程的核心原则，旨在提高开发效率、保证软件质量和可维护性。

17. What is RUP? How many phases is in RUP? Describe each phase’s purpose and milestone.

定义 (Definition):
• 中文: RUP（Rational Unified Process）是一种软件开发过程框架，提供了一种迭代的、以用例驱动的开发方法。
• 英文: RUP (Rational Unified Process) is an iterative software development process framework that provides a use-case-driven approach to software development.

RUP的四个阶段 (Four phases of RUP):

初始阶段 (Inception):
• 目的 (Purpose): 为系统建立商业案例，确定项目的边界和可行性，识别主要风险。
• 里程碑 (Milestone): 生命周期目标（Lifecycle Objective），明确项目是否值得继续。
• 中文解释: 确定项目的基本目标和范围，评估可行性。
细化阶段 (Elaboration):
• 目的 (Purpose): 分析问题领域，建立系统的体系结构基础，制定详细的项目计划，消除最高风险。
• 里程碑 (Milestone): 生命周期架构（Lifecycle Architecture），确保体系结构可行。
• 中文解释: 确定系统的主要架构和技术方案，降低项目风险。
构建阶段 (Construction):
• 目的 (Purpose): 开发所有剩余的构件和应用程序功能，并将其集成到产品中，进行全面测试。
• 里程碑 (Milestone): 初始运行能力（Initial Operational Capability），确保系统可以交付。
• 中文解释: 完成系统的开发和测试，确保系统可以初步运行。
交付阶段 (Transition):
• 目的 (Purpose): 将软件产品交付给用户群体，进行部署和支持，收集反馈并进行调整。
• 里程碑 (Milestone): 产品发布（Product Release），确保系统可以正式投入使用。
• 中文解释: 将系统交付给用户，完成最终部署。

18. Name and briefly describe the “4+1” views of architecture.

定义 (Definition):
• 中文: “4+1”视图模型是一种描述软件体系结构的方法，从五个不同的视角来描述系统，重点关注系统的不同方面。
• 英文: The “4+1” view model is a method for describing software architecture by viewing the system from five different perspectives, focusing on various aspects of the system.

“4+1”视图的五种视图 (Five views of the “4+1” view model):

用例视图 (Use-case View):
• 中文: 描述系统的功能需求和用户与系统的交互，通常通过用例图表示。
• 英文: Describes the functional requirements of the system and the interaction between users and the system, typically represented by use-case diagrams.
逻辑视图 (Logical View):
• 中文: 描述系统的静态结构，包括类、接口和它们之间的关系，通常通过类图表示。
• 英文: Describes the static structure of the system, including classes, interfaces, and their relationships, typically represented by class diagrams.
实现视图 (Implementation View):
• 中文: 描述系统的模块化结构，包括代码组织和构件之间的关系，通常通过组件图表示。
• 英文: Describes the modular structure of the system, including code organization and relationships between components, typically represented by component diagrams.
过程视图 (Process View):
• 中文: 描述系统的动态行为，包括并发、同步和进程间的交互，通常通过活动图或状态图表示。
• 英文: Describes the dynamic behavior of the system, including concurrency, synchronization, and inter-process interactions, typically represented by activity or state diagrams.
部署视图 (Deployment View):
• 中文: 描述系统的物理部署，包括硬件节点、软件构件及其分布，通常通过部署图表示。
• 英文: Describes the physical deployment of the system, including hardware nodes, software components, and their distribution, typically represented by deployment diagrams.

总结:
• RUP: 提供了一种迭代的开发方法，分为四个阶段，每个阶段都有明确的目标和里程碑。
• “4+1”视图: 从五个视角描述系统，分别关注功能、结构、实现、动态行为和物理部署。

19. What is the difference between analysis and design?

分析 (Analysis)	设计 (Design)
集中在理解问题。	集中在理解解决方案。
是理想化设计。	设计相关操作和属性。
行为。	性能。
系统架构。	接近真实代码。
功能需求。	对象生命周期。
是一个小模型。	包括非功能需求，是一个大模型。

解释 (Explanation):
• 分析 (Analysis): 主要关注问题的理解和建模，强调系统的功能和行为，通常不涉及具体的实现细节，是一个高层次的抽象模型。
• 设计 (Design): 主要关注解决方案的实现，描述系统的具体结构、操作、属性和性能，接近真实的代码实现，包含功能需求和非功能需求。

20. Please describe the whole process of OO analysis and design with UML.

OO分析与设计的关键概念 (Key Concepts of OO Analysis and Design):

定义高层组织和子系统 (Define the High-Level Organization of Subsystems):
• 中文: 确定系统的高层结构，划分子系统及其职责。
• 英文: Determine the high-level structure of the system and divide subsystems and their responsibilities.
识别关键的抽象 (Identify Key Abstractions):
• 中文: 找出系统中的核心概念和对象，例如类和接口。
• 英文: Identify the core concepts and objects in the system, such as classes and interfaces.
创建用例实现 (Create Use-Case Realizations):
• 中文: 使用UML图（如顺序图、协作图）描述用例的具体实现。
• 英文: Use UML diagrams (such as sequence diagrams, collaboration diagrams) to describe the implementation of use cases.
设置检查点 (Checkpoints):
• 中文: 在分析过程中设置检查点，确保模型符合需求。
• 英文: Set checkpoints during the analysis process to ensure the model meets requirements.

OO分析与设计的完整过程 (Complete Process of OO Analysis and Design):

识别类和子系统 (Identify Classes and Subsystems):
• 中文: 根据需求分析，识别系统中的类和子系统。
• 英文: Identify classes and subsystems based on requirements analysis.
识别子系统的接口 (Identify Subsystem Interfaces):
• 中文: 定义子系统之间的交互方式和接口。
• 英文: Define the interaction methods and interfaces between subsystems.
校正设计模型的组织结构 (Update the Organization of the Design Model):
• 中文: 根据需求和实现细节调整设计模型，确保其合理性和完整性。
• 英文: Adjust the design model based on requirements and implementation details to ensure its rationality and completeness.
设置检查点 (Checkpoints):
• 中文: 在设计过程中设置检查点，验证设计的可行性和一致性。
• 英文: Set checkpoints during the design process to verify the feasibility and consistency of the design.

总结 (Summary):
• OO分析: 关注问题建模，识别需求和核心概念。
• OO设计: 关注解决方案建模，描述系统的具体实现和结构。
• UML工具: 在分析和设计过程中，使用UML图（如用例图、类图、顺序图等）来辅助建模和验证。

21. What is a layered architecture? Give examples of typical layers.

定义 (Definition):
• 中文: 分层体系结构是一种通过分层方式处理复杂功能的设计方法。上层子系统可以使用下层子系统的功能，但下层子系统不能使用上层子系统的功能。
• 英文: A layered architecture is a design method that handles complex functionality by dividing the system into layers. Upper layers can use the functionality of lower layers, but lower layers cannot use the functionality of upper layers.

典型的层次 (Typical Layers):

应用子系统 (Application Subsystems):
• 中文: 包含具体的业务逻辑和功能模块，直接与用户交互。
• 英文: Contains specific business logic and functional modules, directly interacting with users.
业务特定层 (Business Specific):
• 中文: 实现核心业务逻辑，独立于具体的技术实现。
• 英文: Implements core business logic, independent of specific technical implementations.
中间件 (Middleware):
• 中文: 提供服务和工具，支持上层应用的运行，例如数据库访问、消息队列等。
• 英文: Provides services and tools to support the operation of upper-layer applications, such as database access and message queues.
系统软件 (System Software):
• 中文: 提供底层支持，例如操作系统、网络协议等。
• 英文: Provides low-level support, such as operating systems and network protocols.

例子 (Example):
• C/S（两层）体系结构:
• 中文: 客户机/服务器结构，简称C/S结构或两层体系结构。客户端负责用户交互，服务器负责数据处理和存储。
• 英文: Client/Server architecture, abbreviated as C/S architecture, where the client is responsible for user interaction, and the server handles data processing and storage.

22. What are analysis mechanisms? What are design mechanisms? Give examples.

分析机制 (Analysis Mechanisms):
• 定义 (Definition):
• 中文: 分析机制是用于描述系统功能的高层次抽象，关注系统的行为和功能实现，而不涉及具体的技术细节。
• 英文: Analysis mechanisms are high-level abstractions used to describe system functionality, focusing on the system’s behavior and functional implementation without involving specific technical details.

• 例子 (Examples):
• 用例模型 (Use-case model)
• 类图 (Class diagram)
• 状态图 (Statechart diagram)

• 特点 (Characteristics):
• 是概念模型，描述系统的抽象视图。
• 对设计是通用的，适用于多种实现方式。
• 开发成本较低，形式化程度较低。

设计机制 (Design Mechanisms):
• 定义 (Definition):
• 中文: 设计机制是将分析模型转化为具体的实现方案，关注系统的物理实现和技术细节。
• 英文: Design mechanisms transform the analysis model into a specific implementation plan, focusing on the physical implementation and technical details of the system.

• 例子 (Examples):
• 组件图 (Component diagram)
• 部署图 (Deployment diagram)
• 数据库设计 (Database design)

• 特点 (Characteristics):
• 是物理模型，描述系统的实现蓝图。
• 针对特定的实现方式，不具备通用性。
• 开发成本较高，形式化程度较高。

分析模型 vs 设计模型 (Analysis Model vs Design Model):

特性 (Feature)	分析模型 (Analysis Model)	设计模型 (Design Model)
类型 (Type)	概念模型 (Conceptual Model)	物理模型 (Physical Model)
通用性 (Generality)	对设计是通用的，适用于多种实现方式	针对特定的实现方式，不具备通用性
形式化程度 (Formality)	不太形式化	比较形式化
开发成本 (Cost)	开发成本较低	开发成本较高（约为分析模型的5倍）
层数 (Layers)	层数较少	层数较多
用途 (Purpose)	勾画系统的设计轮廓，包括系统架构	进行系统的详细设计，包括系统架构
维护 (Maintenance)	不需要在整个软件生命周期内维护	需要在整个软件生命周期内维护

总结 (Summary):
• 分析机制: 关注系统的功能和行为，描述高层次的抽象模型。
• 设计机制: 关注系统的具体实现和技术细节，描述物理实现模型。

23. What is an analysis class? Name and describe the three analysis stereotypes. Give examples.

定义 (Definition):
• 中文: 分析类是问题域中的简洁抽象，映射到真实世界的业务概念，并根据业务概念仔细命名。
• 英文: An analysis class is a concise abstraction of the problem domain, mapped to real-world business concepts and carefully named based on those concepts.

三种分析构造型 (Three Analysis Stereotypes):

边界类 (Boundary Class):
• 中文: 边界类中介于系统接口与系统外部环境之间的协作，负责处理系统与外界的交互。
• 英文: Boundary classes mediate the collaboration between the system’s interface and the external environment, handling interactions between the system and the outside world.
• 例子 (Examples):
1. 用户界面类：人与系统之间的接口类。
2. 系统接口类：与其他系统之间的接口类。
3. 设备接口类：与外部设备（如传感器）之间的接口类。
控制类 (Control Class):
• 中文: 控制类封装特定用例的行为，协调用例的执行流程。
• 英文: Control classes encapsulate the behavior of specific use cases, coordinating the execution flow of the use case.
• 例子 (Examples):
◦ 在课程注册系统中，可能引入控制类 CourseRegistrationController 来协调整个注册过程。
实体类 (Entity Class):
• 中文: 实体类用于建模系统中事物的永久信息，代表系统中的关键抽象。
• 英文: Entity classes model the permanent information of things in the system, representing key abstractions in the system.
• 例子 (Examples):
◦ 表由系统管理的主要事物（如客户、订单等）。例如，Customer 类表示系统中的客户信息。

24. What is Use-case realization? What’s your understanding of the benefit of the use-case realization structure?

定义 (Definition):
• 中文: 用例实现是用例的具体实现方式，通过描述抽象元素之间的协作关系来分析实现方式并进一步细化。
• 英文: Use-case realization is the implementation of a use case, analyzing the implementation approach and further refining it by describing the collaboration among abstract elements.

用例实现的好处 (Benefits of Use-case Realization Structure):

需求与实现分离 (Separation of Requirements and Implementation):
• 中文: 用例实现将需求（用例）与具体实现分离，使得设计更加灵活。
• 英文: Use-case realization separates requirements (use cases) from implementation, making the design more flexible.
支持多对多关系 (Support for Many-to-Many Relationships):
• 中文: 一个用例实现可以对应多个用例，一个用例也可以由多个用例实现来完成，避免了需求划分对具体实现的过度依赖。
• 英文: One use-case realization can correspond to multiple use cases, and one use case can be realized by multiple use-case realizations, reducing the over-dependence of implementation on the use-case division in the requirements phase.
提高可维护性 (Improved Maintainability):
• 中文: 用例实现结构清晰，便于后续的维护和扩展。
• 英文: The use-case realization structure is clear, making it easier for subsequent maintenance and extension.
促进团队协作 (Facilitating Team Collaboration):
• 中文: 不同的团队可以专注于不同的用例实现，提升开发效率。
• 英文: Different teams can focus on different use-case realizations, improving development efficiency.

总结 (Summary):
• 分析类: 是问题域的抽象，分为边界类、控制类和实体类，分别处理系统与外界的交互、用例行为协调和系统核心数据建模。
• 用例实现: 是用例的具体实现方式，强调需求与实现的分离，支持多对多关系，提升系统的灵活性和可维护性。

25. Describe the steps occurred in the use-case analysis.

用例分析的步骤 (Steps in Use-Case Analysis):

补充用例说明 (Supplement the Use-Case Description):
• 中文: 对用例进行详细描述，明确用例的目标、参与者、前置条件、后置条件、基本流程和可选流程。
• 英文: Provide a detailed description of the use case, clarifying its goals, actors, preconditions, postconditions, basic flow, and alternative flows.
找出用例中的行为 (Find Classes from Use-Case Behavior):
• 中文: 分析用例的行为，识别出与用例相关的类。
• 英文: Analyze the behavior of the use case and identify classes related to the use case.
把行为合理分配给各个类 (Distribute Use-Case Behavior to Classes):
• 中文: 将用例的行为分配到识别出的类中，确保每个类的职责清晰。
• 英文: Distribute the behavior of the use case to the identified classes, ensuring clear responsibilities for each class.
对每一个分析出来的类进行描述 (For each resulting analysis class):
• 描述职责 (Describe Responsibilities): 明确类的功能和任务。
• 描述属性和关联 (Describe Attributes and Associations): 定义类的属性及其与其他类的关系。
• 限定分析机制 (Qualify Analysis Mechanisms): 确定类中使用的分析机制（如边界类、控制类、实体类等）。
统一分析类 (Unify Analysis Classes):
• 中文: 检查并合并重复或冗余的类，确保类的设计合理且一致。
• 英文: Check and merge duplicate or redundant classes to ensure a reasonable and consistent class design.
检查分析过程和结果 (Checkpoints):
• 中文: 验证用例分析的完整性和正确性，确保没有遗漏或错误。
• 英文: Verify the completeness and correctness of the use-case analysis, ensuring no omissions or errors.

26. What’s the package, and Why we need package?

定义 (Definition):
• 中文: 包是一种用于将模型元素分组的通用机制，是一种可以包含其他模型元素的模型元素。
• 英文: A package is a general-purpose mechanism for organizing elements into groups. It is a model element that can contain other model elements.

包的作用 (Purpose of Packages):

组织模型 (To organize the model under development):
• 中文: 在开发过程中，包用于将相关的模型元素（如类、用例、组件等）分组，便于管理和理解。
• 英文: During development, packages are used to group related model elements (such as classes, use cases, components) for better management and understanding.
配置管理单元 (As a unit of configuration management):
• 中文: 包可以作为配置管理的单位，便于版本控制和团队协作。
• 英文: Packages can serve as units of configuration management, facilitating version control and team collaboration.

总结 (Summary):
• 用例分析步骤: 从补充用例说明开始，识别类、分配行为、描述类职责和属性，统一类设计，并检查分析结果。
• 包的作用: 包是组织模型元素的工具，便于开发管理和配置控制。

27. What is a subsystem? What is an interface? How does a subsystem differ from a package?

子系统 (Subsystem):
• 定义 (Definition):
• 中文: 子系统是一种模型元素，介于包和类之间，具有包的语义（可以包含其他模型元素）和类的行为语义（其包含的类或其他子系统提供行为）。
• 英文: A subsystem is a model element that lies between a package and a class, with the semantics of a package (it can contain other model elements) and the behavior of a class (its contained classes or subsystems provide behavior).

• 特点 (Characteristics):
• 子系统的行为由其包含的类或其他子系统提供。
• 子系统实现一个或多个接口，这些接口定义了子系统可以执行的行为。
• 子系统用于封装一组协作类，这些类仅在内部交互并生成明确的结果。

接口 (Interface):
• 定义 (Definition):
• 中文: 接口定义了子系统或类可以执行的操作和行为，描述了系统对外提供的功能。
• 英文: An interface defines the operations and behaviors that a subsystem or class can perform, describing the functionality provided by the system.

28. What is the purpose of describing the run-time architecture? How to model the process view?

运行时架构描述的目的 (Purpose of Describing the Run-time Architecture):

分析并发需求 (Analyze Concurrency Requirements):
• 中文: 确定系统中需要并发执行的任务或功能。
• 英文: Determine the tasks or functions that need to execute concurrently in the system.
识别进程和线程 (Identify Processes and Threads):
• 中文: 明确系统中需要运行的进程和线程。
• 英文: Identify the processes and threads required in the system.
识别进程生命周期 (Identify Process Lifecycles):
• 中文: 描述每个进程的生命周期及其状态变化。
• 英文: Describe the lifecycle of each process and its state transitions.
从进程到实现的映射 (Map Processes onto the Implementation):
• 中文: 将进程与系统的实现（如硬件、软件组件）关联起来。
• 英文: Map processes to their implementation (e.g., hardware, software components).
在进程间分配模型元素 (Distribute Model Elements Among Processes):
• 中文: 确定哪些模型元素（如类、组件）分配到哪些进程中运行。
• 英文: Determine which model elements (e.g., classes, components) are assigned to which processes.

建模过程视图的方法 (How to Model the Process View):
• 中文: 过程视图可以通过类图、交互图和构件图来建模，描述系统中进程的交互和行为。
• 英文: The process view can be modeled using Class Diagrams, Interaction Diagrams, and Component Diagrams to describe the interactions and behaviors of processes in the system.

总结 (Summary):
• 子系统 vs 包: 子系统更关注行为和协作，而包仅用于组织模型元素。
• 运行时架构: 描述系统的并发需求、进程和线程、生命周期以及进程间的映射关系。
• 过程视图建模: 使用类图、交互图和构件图来描述进程的交互和行为。

29. What is the purpose of describing the distribution? How to model the deployment view?

描述分布的目的 (Purpose of Describing the Distribution):

减轻处理器负载 (Reduce Processor Load):
• 中文: 将任务合理分配到多个处理器上，避免单一处理器过载。
• 英文: Distribute tasks across multiple processors to avoid overloading a single processor.
满足特殊的处理要求 (Special Processing Requirements):
• 中文: 针对特定任务分配专用资源，满足性能或功能需求。
• 英文: Allocate dedicated resources for specific tasks to meet performance or functional requirements.
减少经济开支 (Economic Concerns):
• 中文: 通过分布式架构降低硬件和维护成本。
• 英文: Reduce hardware and maintenance costs through distributed architecture.
分布式访问系统 (Distributed Access to the System):
• 中文: 支持用户通过网络从不同地点访问系统，提高系统的可用性。
• 英文: Support users in accessing the system from different locations via the network, improving system availability.

如何建模部署视图 (How to Model the Deployment View):

在特定的项目图上注明软件组件 (Annotate Software Components on Specific Project Diagrams):
• 中文: 在图中明确标注软件组件的位置和作用。
• 英文: Clearly annotate the location and role of software components in the diagram.
集中在企业级图上的节点和通信关联 (Focus on Nodes and Communication Associations in Enterprise-Level Diagrams):
• 中文: 在企业级部署图中，重点描述节点（硬件设备）及其通信连接。
• 英文: In enterprise-level deployment diagrams, focus on nodes (hardware devices) and their communication connections.
节点和组件的命名与建模 (Naming and Modeling Nodes and Components):
• 中文:
◦ 使用描述性术语命名节点。
◦ 仅建模重要的软件组件。
◦ 为组件一致地应用版型（Stereotype）。
◦ 将可视化的版型应用到节点。
• 英文:
◦ Use descriptive terms to name nodes.
◦ Model only important software components.
◦ Consistently apply stereotypes to components.
◦ Apply visual stereotypes to nodes.
依赖和通信关联 (Dependencies and Communication Associations):
• 中文:
◦ 使用版型标注通信协议。
◦ 仅建模组件间的关键性依赖。
• 英文:
◦ Use stereotypes to annotate communication protocols.
◦ Model only critical dependencies between components.

30. Describe the two typical distribution patterns, C/S and P2P.

C/S结构 (Client/Server Structure):
• 定义 (Definition):
• 中文: C/S结构是一种软件系统体系结构，通过将任务分配到客户端（Client）和服务器端（Server），充分利用两端硬件环境的优势，降低系统通信开销。
• 英文: The Client/Server (C/S) structure is a software system architecture that distributes tasks between the client and server, leveraging the advantages of both hardware environments and reducing communication overhead.

• 特点 (Characteristics):

服务器端 (Server):
◦ 使用高性能设备（如PC、工作站或小型机）。
◦ 采用大型数据库系统（如ORACLE）。
◦ 负责集中管理和提供服务。
客户端 (Client):
◦ 需要安装专用客户端软件。
◦ 负责用户交互和部分任务处理。

• 变体 (Variants):
• 3-tier: 分为表示层、业务逻辑层和数据层。
• Fat Client: 客户端承担更多任务，减少服务器压力。
• Fat Server: 服务器承担更多任务，客户端仅负责交互。
• Distributed C/S: 分布式C/S结构，任务分散到多个服务器。

P2P结构 (Peer-to-Peer Structure):
• 定义 (Definition):
• 中文: P2P是一种直接将用户连接起来的网络结构，用户通过互联网直接交互，消除中间商，实现去中心化。
• 英文: P2P (Peer-to-Peer) is a network structure that directly connects users, enabling direct interaction over the internet and eliminating intermediaries for decentralization.

• 特点 (Characteristics):

去中心化 (Decentralization):
◦ 用户可以直接连接到其他用户的计算机，交换文件或数据。
◦ 没有中心服务器控制，网络更加平等。
共享与交互 (Sharing and Interaction):
◦ 用户之间可以直接共享资源，提升效率。
◦ 消除了传统客户端-服务器模式中的中间环节。
用户赋权 (User Empowerment):
◦ 用户拥有更多控制权，网络权力从大网站回归到用户。