UML簡答題

1. Design and Analysis

英文:
• Design: Emphasizes a conceptual solution that fulfills the requirements, rather than its implementation.
• Analysis: Emphasizes an investigation of the problems and requirements, rather than a solution.

中文:
• 设计 (Design): 强调满足需求的概念性解决方案，而不是具体的实现。
• 分析 (Analysis): 强调对问题和需求的调查和研究，而不是解决方案。

解释 (Explanation):
• 设计 (Design): 设计阶段关注如何构建系统以满足需求，通常包括高层次的架构设计和模块划分，但不涉及具体的代码实现。
• 分析 (Analysis): 分析阶段关注理解问题和需求，明确系统的目标和功能，通常包括需求收集和问题建模。

2. OOD Principles (Object-Oriented Design Principles)

英文:
• Abstraction: Focus on essential properties and ignore irrelevant details.
• Encapsulation: Hide implementation details and expose only necessary interfaces.
• Polymorphism: Allow objects of different classes to be treated as objects of a common superclass.
• Hierarchy: Organize classes into levels of abstraction, where higher-level classes are more general and lower-level classes are more specific.

中文:
• 抽象 (Abstraction): 关注事物的本质属性，忽略无关细节。
• 封装 (Encapsulation): 隐藏实现细节，仅暴露必要的接口。
• 多态 (Polymorphism): 允许不同类的对象以统一的方式被处理。
• 层次化 (Hierarchy): 将类按抽象层次组织，高层类更通用，低层类更具体。

解释 (Explanation):
• 抽象 (Abstraction): 通过提取关键特征简化复杂问题，便于理解和建模。
• 封装 (Encapsulation): 通过隐藏内部实现细节，提高系统的安全性和可维护性。
• 多态 (Polymorphism): 提高代码的灵活性和复用性，允许不同对象对同一操作做出不同的响应。
• 层次化 (Hierarchy): 通过分层组织类，简化系统设计并支持扩展。

3. UML (Unified Modeling Language)

英文:
UML is a visual language for specifying, constructing, and documenting the artifacts of systems.

中文:
UML是一种用于指定、构建和记录系统工件的可视化语言。

解释 (Explanation):
• UML提供了一套标准化的图形符号，用于描述系统的结构、行为和交互。
• 它广泛应用于软件工程中，帮助开发者和利益相关者理解系统设计和需求。
• 用途: 包括用例图、类图、顺序图、活动图等，用于建模系统的不同方面。

4. UP (Unified Process)

英文:
UP is a popular iterative software development process for building object-oriented systems.

中文:
UP是一种流行的迭代式软件开发过程，用于构建面向对象的系统。

解释 (Explanation):
• UP是一种灵活的开发框架，支持迭代开发和增量交付。
• 它强调需求驱动、风险管理和持续改进。
• UP的核心特点包括：
• 迭代开发: 将开发过程分为多个迭代周期，每个周期交付部分功能。
• 用例驱动: 以用例为核心，指导系统设计和实现。
• 架构为中心: 强调系统架构在整个开发过程中的作用。

5. Software Development Process

英文:
The software development process describes an approach to building, deploying, and possibly maintaining software.

中文:
软件开发过程描述了构建、部署和可能维护软件的方法。

解释 (Explanation):
• 软件开发过程是软件开发生命周期的框架，定义了从需求分析到部署和维护的各个阶段。
• 常见的软件开发过程模型包括：
• 瀑布模型 (Waterfall Model): 线性顺序开发，每个阶段完成后进入下一阶段。
• 敏捷开发 (Agile Development): 迭代和增量开发，强调快速响应变化。
• 迭代模型 (Iterative Model): 将开发分为多个迭代周期，逐步完善系统。
• 目标: 确保软件按时交付，满足用户需求，并具有良好的质量。

总结 (Summary):

术语 (Term)	英文定义 (English Definition)	中文定义 (Chinese Definition)
Design and Analysis	Design: Conceptual solution for requirements. Analysis: Investigation of problems and needs.	设计: 满足需求的概念性解决方案。分析: 对问题和需求的调查和研究。
OOD Principles	Abstraction, Encapsulation, Polymorphism, Hierarchy.	抽象、封装、多态、层次化。
UML	A visual language for specifying, constructing, and documenting system artifacts.	用于指定、构建和记录系统工件的可视化语言。
UP	An iterative software development process for building object-oriented systems.	一种迭代式软件开发过程，用于构建面向对象的系统。
Software Development Process	An approach to building, deploying, and possibly maintaining software.	构建、部署和可能维护软件的方法。

关键要点 (Key Takeaways):

设计 vs 分析: 设计关注解决方案，分析关注问题。
OOD原则: 抽象、封装、多态和层次化是面向对象设计的核心原则。
UML: 是一种标准化的建模语言，用于描述系统的结构和行为。
UP: 是一种迭代开发框架，强调需求驱动和架构为中心。
软件开发过程: 描述了从需求分析到部署和维护的整个生命周期。

6. Domain Model

英文:
A visual representation of conceptual classes or real-situation objects in a domain.

中文:
领域模型是对领域中的概念类或实际场景对象的可视化表示。

解释 (Explanation):
• 定义: 领域模型是对特定领域（如业务领域）中的核心概念和对象的结构化描述，通常以图形化方式展示类及其关系。
• 用途: 帮助开发者和利益相关者理解领域的核心概念和它们之间的关系，为系统设计提供基础。
• 例子: 在“图书馆管理系统”中，领域模型可能包括Book（书）、Member（会员）和LibrarySystem（图书馆系统）等类，以及它们之间的关系（如会员可以借书）。

7. Main Phases of UP (Unified Process)

英文:
• Inception: Approximate vision, business case, scope, vague estimates.
• Elaboration: Refined vision, iterative implementation of the core architecture.
• Construction: Iterative implementation of remaining lower risk and easier elements, and preparation for development.
• Transition: Beta tests, deployment.

中文:
• 初始阶段 (Inception): 初步愿景、商业案例、范围、粗略估算。
• 细化阶段 (Elaboration): 细化愿景，迭代实现核心架构。
• 构建阶段 (Construction): 迭代实现剩余风险较低且较容易的元素，并为开发做准备。
• 交付阶段 (Transition): 测试版测试、部署。

解释 (Explanation):
• 初始阶段 (Inception): 确定项目的基本目标、范围和可行性，识别主要风险。
• 细化阶段 (Elaboration): 深入分析需求，设计核心架构，验证技术可行性。
• 构建阶段 (Construction): 完成剩余功能的开发，优化系统性能，准备发布。
• 交付阶段 (Transition): 将系统交付给用户，进行测试和部署，收集反馈。

8. Iterations

英文:
Development is organized into a series of short, fixed-length mini-projects called iterations.

中文:
开发被组织为一系列短期的、固定长度的小型项目，称为迭代。

解释 (Explanation):
• 定义: 迭代开发是一种将整个开发过程划分为多个短周期的方法，每个周期完成一部分功能并交付可运行的版本。
• 优点:
• 快速反馈: 每个迭代结束后，利益相关者可以提供反馈，帮助改进后续开发。
• 降低风险: 通过逐步实现功能，早期发现和解决潜在问题。
• 灵活性: 可以根据需求变化调整后续迭代计划。
• 例子: 在敏捷开发中，一个迭代可能持续2周，每个迭代完成一个或多个用例的实现。

9. Requirement (FURPS+)

英文:
• Functional: Features and functions of the system.
• Usability: User interface design and ease of use.
• Reliability: System stability and error handling.
• Performance: System speed and responsiveness.
• Supportability: Maintainability, testability, and compatibility.
• + (Other): Design constraints, implementation requirements, interface requirements, etc.

中文:
• 功能性 (Functional): 系统的功能和特性。
• 可用性 (Usability): 用户界面设计和易用性。
• 可靠性 (Reliability): 系统的稳定性和错误处理能力。
• 性能 (Performance): 系统的速度和响应能力。
• 可支持性 (Supportability): 系统的可维护性、可测试性和兼容性。
• + (其他): 设计约束、实现需求、接口需求等。

解释 (Explanation):
• FURPS+ 是一种需求分类方法，用于系统化地组织和分析需求。
• 功能性 (Functional): 描述系统需要实现的核心功能。
• 非功能性需求 (Usability, Reliability, Performance, Supportability): 关注系统的质量属性，确保系统满足用户体验和性能要求。
• + (其他): 包括一些额外的需求，如法律合规性、安全性等。

10. Agile Method

英文:
Short timeboxed iterations with evolutionary refinement of plans, requirements, and design is a basic practice of the methods.

中文:
短期的时间盒迭代，计划、需求和设计的逐步完善是敏捷方法的基本实践。

解释 (Explanation):
• 定义: 敏捷方法是一种以快速迭代和持续改进为核心的软件开发方法，强调灵活性和对变化的快速响应。
• 核心特点:
• 短迭代 (Short Iterations): 每个迭代周期通常为1-4周，完成一部分功能并交付可运行的版本。
• 时间盒 (Timeboxing): 每个迭代有固定的时间限制，确保团队专注于当前目标。
• 逐步完善 (Evolutionary Refinement): 计划、需求和设计在每个迭代中不断优化和调整。
• 协作 (Collaboration): 强调团队协作和利益相关者的持续沟通。
• 例子: Scrum 和 Kanban 是敏捷方法的典型实践。

总结 (Summary)

术语 (Term)	英文定义 (English Definition)	中文定义 (Chinese Definition)
Domain Model	A visual representation of conceptual classes or real-situation objects in a domain.	领域模型是对领域中的概念类或实际场景对象的可视化表示。
Main Phases of UP	Inception, Elaboration, Construction, Transition.	初始阶段、细化阶段、构建阶段、交付阶段。
Iterations	Development is organized into short, fixed-length mini-projects called iterations.	开发被组织为一系列短期的、固定长度的小型项目，称为迭代。
Requirement (FURPS+)	Functional, Usability, Reliability, Performance, Supportability, and other constraints.	功能性、可用性、可靠性、性能、可支持性及其他约束。
Agile Method	Short timeboxed iterations with evolutionary refinement of plans, requirements, and design.	短期的时间盒迭代，计划、需求和设计的逐步完善是敏捷方法的基本实践。

关键要点 (Key Takeaways):

领域模型 (Domain Model): 用于描述领域的核心概念和对象之间的关系，帮助理解系统需求。
UP阶段 (Main Phases of UP): 包括初始、细化、构建和交付四个阶段，强调迭代开发和风险管理。
迭代开发 (Iterations): 将开发分为多个短周期，每个周期完成部分功能并交付可运行版本。
需求分类 (FURPS+): 系统化地组织功能性需求和非功能性需求，确保系统满足质量要求。
敏捷方法 (Agile Method): 强调快速迭代、持续改进和对变化的灵活响应，适合动态需求的项目。

11. Disciplines and Phases

英文:
• Disciplines: A set of activities in one subject.
• Artifact: The general term for any work product.

中文:
• 学科 (Disciplines): 某一领域中的一组活动。
• 工件 (Artifact): 任何工作成果的统称。

解释 (Explanation):
• 学科 (Disciplines): 在软件开发中，学科是指与特定领域相关的活动集合。例如，在面向对象开发中，”分析”和”设计”是两个不同的学科，分别关注需求分析和系统设计。
• 工件 (Artifact): 工件是开发过程中产生的任何成果，例如用例图、类图、代码、文档等。工件的形式可以是模型、文件或可运行的软件。

12. Use Case

英文:
• Use Case: Text stories of some actor using a system to meet a goal. (A collection of related success and failure scenarios that describe an actor using a system to support the goal.)
• Actor: Something with behavior.
• Scenario: Specific sequence of actions and interactions between actors and the system. (Use case instance)

中文:
• 用例 (Use Case): 描述某个参与者使用系统以实现目标的文本故事。（一组相关的成功和失败场景，描述参与者如何使用系统支持目标。）
• 参与者 (Actor): 具有行为的实体。
• 场景 (Scenario): 参与者和系统之间的特定动作和交互序列。（用例的一个实例。）

解释 (Explanation):
• 用例 (Use Case): 用例是从参与者的角度描述系统功能的一种方式，通常以文本形式记录。它包括成功路径（正常流程）和失败路径（异常流程）。
• 参与者 (Actor): 参与者是与系统交互的外部实体，可以是用户、设备或其他系统。
• 场景 (Scenario): 场景是用例的具体实例，描述了参与者和系统之间的具体交互过程。

13. Use Case Model

英文:
A set of all written use cases and a model of the system’s functionality and environment.

中文:
用例模型是所有书面用例的集合，描述了系统的功能和运行环境。

解释 (Explanation):
• 定义: 用例模型是对系统功能的整体描述，包含所有用例及其关系，展示了系统如何与外部参与者交互。
• 用途: 用例模型帮助开发者和利益相关者理解系统的功能需求，并为后续的设计和分析提供基础。
• 例子: 在“图书馆管理系统”中，用例模型可能包括Borrow Book（借书）、Return Book（还书）等用例，以及参与者Member（会员）和Librarian（图书管理员）。

14. Use Case Relationship

英文:
• Extend: An extension of a base use case, adding optional behavior.
• Include: A base use case explicitly incorporates another use case to reuse its behavior.
• Generalization: A relationship where a specialized use case inherits behavior from a general use case.

中文:
• 扩展 (Extend): 对基本用例的扩展，添加可选行为。
• 包含 (Include): 基本用例显式地包含另一个用例以复用其行为。
• 泛化 (Generalization): 一种继承关系，特殊用例继承一般用例的行为。

解释 (Explanation):
• 扩展 (Extend):
• 用途: 当某个用例在特定条件下需要额外的行为时使用扩展关系。
• 例子: 在“借书”用例中，如果会员的借书额度不足，可以扩展出一个Check Loan Limit（检查借书额度）用例。
• 包含 (Include):
• 用途: 当多个用例共享某些共同行为时，将这些行为提取到一个单独的用例中，并通过包含关系复用。
• 例子: 在“借书”和“还书”用例中，可能都需要验证会员身份，可以将Verify Membership（验证会员身份）提取为一个公共用例。
• 泛化 (Generalization):
• 用途: 表示用例之间的继承关系，特殊用例可以继承一般用例的行为并添加自己的特定行为。
• 例子: Student（学生）和Professor（教授）可以泛化为User（用户），并继承Login（登录）行为。

15. Use Case Realization

英文:
How a particular use case is realized within the design model in terms of collaborating objects.

中文:
用例实现是指在系统设计模型中，通过协作对象的方式实现特定用例的过程。

解释 (Explanation):
• 定义: 用例实现描述了如何通过设计模型中的对象协作来完成用例的功能。
• 用途: 将用例的功能需求转化为具体的设计实现，明确哪些对象参与协作以及它们之间的关系。
• 例子:
• 用例: Borrow Book（借书）
• 实现:
◦ 参与对象: Member（会员）、LibrarySystem（图书馆系统）、Book（书）。
◦ 交互过程:

  1. 会员请求借书。  
  2. 图书馆系统检查书籍库存。  
  3. 图书馆系统更新书籍状态为“已借出”。

总结 (Summary)

术语 (Term)	英文定义 (English Definition)	中文定义 (Chinese Definition)
Disciplines	A set of activities in one subject.	某一领域中的一组活动。
Artifact	The general term for any work product.	任何工作成果的统称。
Use Case	Text stories of some actor using a system to meet a goal.	描述参与者如何使用系统实现目标的文本故事。
Actor	Something with behavior.	具有行为的实体。
Scenario	Specific sequence of actions and interactions between actors and the system.	参与者和系统之间的特定动作和交互序列。
Use Case Model	A set of all written use cases and a model of the system’s functionality and environment.	所有用例的集合，描述系统的功能和运行环境。
Use Case Relationship	Extend, Include, Generalization	扩展、包含、泛化是用例之间的三种关系，分别表示扩展行为、复用行为和继承行为。
Use Case Realization	How a particular use case is realized within the design model in terms of collaborating objects.	用例实现描述了如何通过设计模型中的对象协作来完成用例的功能。

关键要点 (Key Takeaways):

学科和工件 (Disciplines and Artifacts): 学科是某一领域的活动集合，工件是开发过程中产生的成果。
用例 (Use Case): 描述参与者如何使用系统实现目标，包括成功和失败场景。
用例模型 (Use Case Model): 包含所有用例及其关系，描述系统的功能和运行环境。
用例关系 (Use Case Relationship): 包括扩展、包含和泛化，用于描述用例之间的交互和复用。
用例实现 (Use Case Realization): 将用例的功能需求转化为设计模型中的对象协作。

16. Architecture

英文:
Architecture is the fundamental organization of a system.

中文:
架构是系统的基本组织结构。

解释 (Explanation):
• 定义: 系统架构描述了系统的整体结构，包括组件、模块、它们之间的关系以及系统的运行方式。
• 用途: 架构为系统的设计、开发和维护提供了一个高层次的蓝图，确保系统满足功能需求和非功能需求（如性能、可扩展性、安全性等）。
• 例子: 在一个Web应用中，架构可能包括前端、后端、数据库和网络通信模块。

17. 4+1 View

英文:
• Logical View: Focuses on the design of the system’s functionality and how it is implemented.
• Physical View: Describes the physical deployment of the system, including hardware and software components.
• Process View: Models the system’s processes and their interactions, focusing on runtime behavior.
• Deployment View: Shows the system’s hardware and software components and their connections.
• Use Case View: Represents the system’s functionality from the perspective of use cases, showing how users interact with the system.

中文:
• 逻辑视图 (Logical View): 关注系统的功能设计和实现方式。
• 物理视图 (Physical View): 描述系统的物理部署，包括硬件和软件组件。
• 过程视图 (Process View): 模型系统的运行时行为，展示进程及其交互。
• 部署视图 (Deployment View): 展示系统的硬件和软件组件及其连接关系。
• 用例视图 (Use Case View): 从用例的角度表示系统的功能，展示用户如何与系统交互。

解释 (Explanation):
• 4+1 视图模型: 是一种多视角的系统建模方法，用于描述系统的不同方面。
• 逻辑视图: 关注系统的功能设计和实现，通常通过类图、序列图等表示。
• 物理视图: 描述系统的物理部署，通常包括服务器、网络设备和软件组件。
• 过程视图: 关注系统的运行时行为，展示进程、线程及其交互。
• 部署视图: 展示系统的硬件和软件组件的分布和连接关系。
• 用例视图: 从用户的角度描述系统的功能，展示用例和参与者的交互。

18. GRASP

英文:
GRASP (General Responsibility Assignment Software Patterns) is a set of design patterns that provide guidelines for assigning responsibilities to objects in object-oriented design.

中文:
GRASP（通用职责分配软件模式）是一组设计模式，为面向对象设计中职责分配提供指导原则。

解释 (Explanation):
• 定义: GRASP 是一组设计原则，用于在面向对象设计中合理分配对象的职责。
• 主要模式:
• 信息专家 (Information Expert): 将职责分配给拥有完成任务所需信息的对象。
• 创建者 (Creator): 负责创建对象的类通常是依赖该对象的对象。
• 低耦合 (Low Coupling): 减少对象之间的依赖，提高系统的灵活性。
• 高内聚 (High Cohesion): 确保对象的功能集中且单一。
• 控制器 (Controller): 将系统与用户交互的职责分配给控制器对象。
• 多态 (Polymorphism): 使用多态来处理行为的扩展。
• 纯虚构 (Pure Fabrication): 创建没有直接现实对应关系的类来简化设计。
• 间接性 (Indirection): 通过中间对象减少直接依赖。
• 防止变异 (Protected Variations): 隔离可能变化的元素，保护系统其他部分不受影响。

19. Design Principles

英文:
• Decomposition: Break down a system into smaller, manageable components.
• Abstract: Focus on essential properties while ignoring irrelevant details.
• Separation of Concerns: Divide a system into distinct sections, each addressing a specific concern.
• Information Hiding and Localization: Hide implementation details and localize data to reduce complexity.
• Modularity: Design the system as a collection of independent, reusable modules.
• SOLID Principles:
• Single Responsibility Principle (SRP): A class should have only one reason to change.
• Open/Closed Principle (OCP): Software entities should be open for extension but closed for modification.
• Liskov Substitution Principle (LSP): Subtypes must be substitutable for their base types.
• Interface Segregation Principle (ISP): Interfaces should be small and focused, avoiding unnecessary dependencies.
• Dependency Inversion Principle (DIP): High-level modules should not depend on low-level modules; both should depend on abstractions.

中文:
• 分解 (Decomposition): 将系统分解为更小、更易管理的组件。
• 抽象 (Abstract): 关注事物的本质属性，忽略无关细节。
• 职责分离 (Separation of Concerns): 将系统划分为不同的部分，每部分专注于特定的关注点。
• 信息隐藏与局部化 (Information Hiding and Localization): 隐藏实现细节并将数据局部化以降低复杂性。
• 模块化 (Modularity): 将系统设计为独立的、可重用的模块集合。
• SOLID 原则:
• 单一职责原则 (SRP): 一个类应该只有一个修改的原因。
• 开闭原则 (OCP): 软件实体应该对扩展开放，对修改关闭。
• 里氏替换原则 (LSP): 子类必须能够替换其基类。
• 接口隔离原则 (ISP): 接口应该小而专注，避免不必要的依赖。
• 依赖倒置原则 (DIP): 高层模块不应依赖低层模块，两者都应依赖抽象。

解释 (Explanation):
• 设计原则: 是指导软件设计的基本规则，确保系统具有良好的可维护性、可扩展性和灵活性。
• SOLID 原则: 是面向对象设计的五个核心原则，旨在提高代码质量和系统的可维护性。

20. GoF (Gang of Four) Design Patterns

英文:
• Adapter: Converts the interface of a class into another interface that clients expect.
• Factory Method: Defines an interface for creating an object but lets subclasses alter the type of objects that will be created.
• Observer: Defines a one-to-many dependency between objects so that when one object changes state, all its dependents are notified.
• Strategy: Defines a family of algorithms, encapsulates each one, and makes them interchangeable.
• Facade: Provides a simplified interface to a larger body of code.
• Singleton: Ensures a class has only one instance and provides a global point of access to it.
• Composite: Composes objects into tree structures to represent part-whole hierarchies.

中文:
• 适配器 (Adapter): 将一个类的接口转换为客户端期望的另一种接口。
• 工厂方法 (Factory Method): 定义创建对象的接口，但允许子类决定实例化的对象类型。
• 观察者 (Observer): 定义对象之间的一对多依赖关系，当一个对象状态改变时，所有依赖对象都会被通知。
• 策略 (Strategy): 定义一系列算法，将每个算法封装起来并使其可以互换。
• 外观 (Facade): 为复杂的代码提供一个简化的接口。
• 单例 (Singleton): 确保一个类只有一个实例，并提供全局访问点。
• 组合 (Composite): 将对象组织成树形结构，表示部分-整体的层次关系。

解释 (Explanation):
• GoF 设计模式: 是由 Erich Gamma、Richard Helm、Ralph Johnson 和 John Vlissides 提出的 23 种经典设计模式，分为创建型、结构型和行为型三类。
• 用途: 这些模式为常见的设计问题提供了可重用的解决方案，帮助开发者设计更灵活、可维护的系统。

总结 (Summary)

术语 (Term)	英文定义 (English Definition)	中文定义 (Chinese Definition)
Architecture	The fundamental organization of a system.	系统的基本组织结构。
4+1 View	Logical, Physical, Process, Deployment, and Use Case Views.	逻辑视图、物理视图、过程视图、部署视图和用例视图。
GRASP	Guidelines for assigning responsibilities in object-oriented design.	面向对象设计中职责分配的指导原则。
Design Principles	Decomposition, Abstract, Separation of Concerns, Information Hiding, Modularity, SOLID Principles.	分解、抽象、职责分离、信息隐藏、模块化、SOLID 原则。
GoF Design Patterns	Adapter, Factory Method, Observer, Strategy, Facade, Singleton, Composite.	适配器、工厂方法、观察者、策略、外观、单例、组合等设计模式。

关键要点 (Key Takeaways):

架构 (Architecture): 系统的整体结构，为设计和开发提供蓝图。
4+1 视图: 从不同角度描述系统，帮助全面理解系统设计。
GRASP: 提供职责分配的指导原则，帮助设计灵活的系统。
设计原则: 包括分解、抽象、职责分离等，确保系统具有良好的可维护性和扩展性。
GoF 设计模式: 提供常见设计问题的解决方案，帮助开发者编写高质量代码。

21. Relationship of Class

英文:
• Association: A relationship between two classes that indicates some kind of connection or interaction.
• Aggregation: A special type of association where one class represents a “whole” and the other represents a “part.” The part can exist independently of the whole.
• Generalization: A relationship where one class is a specialized version of another class (a subclass of the other class). It represents “is a kind of” relationship.

中文:
• 关联 (Association): 表示两个类之间的某种连接或交互关系。
• 聚合 (Aggregation): 一种特殊的关联关系，其中一个类表示“整体”，另一个类表示“部分”。部分可以独立于整体存在。
• 泛化 (Generalization): 一种继承关系，其中一个类是另一个类的特殊版本（子类）。它表示“是一种”关系。

解释 (Explanation):
• 关联 (Association):
• 用途: 描述类之间的连接关系，通常用于表示“拥有”、“使用”等关系。
• 例子: 在“图书馆管理系统”中，Student类和Book类之间存在关联关系，表示学生可以借阅书籍。

• 聚合 (Aggregation):
• 用途: 表示“整体-部分”关系，但部分可以独立于整体存在。
• 例子: 在“汽车系统”中，Car类和Wheel类之间是聚合关系，因为车轮可以独立于汽车存在。

• 泛化 (Generalization):
• 用途: 表示类之间的继承关系，子类继承父类的属性和行为。
• 例子: 在“动物系统”中，Dog类是Animal类的子类，表示“狗是一种动物”。

22. Diagrams

英文:
• SSD (System Sequence Diagram): A diagram that shows the interactions between system objects in response to a system operation, focusing on the flow of messages between objects.

中文:
• 系统序列图 (SSD): 一种展示系统对象在响应系统操作时的交互的图，重点描述对象之间的消息传递流程。

解释 (Explanation):
• 定义: 系统序列图（SSD）是一种动态建模工具，用于描述系统在执行某个操作时，各个对象之间的交互过程。
• 用途:
• 展示系统如何响应外部请求。
• 描述对象之间的消息传递顺序。
• 例子:
• 在“在线购物系统”中，当用户下订单时，系统序列图可能展示以下交互：

1. 用户 → 系统: 提交订单请求。  
2. 系统 → 库存模块: 检查库存。  
3. 系统 → 支付模块: 处理支付。  
4. 系统 → 用户: 返回订单确认信息。

总结 (Summary)

术语 (Term)	英文定义 (English Definition)	中文定义 (Chinese Definition)
Association	A relationship between two classes indicating some kind of connection or interaction.	类之间的连接或交互关系。
Aggregation	A special type of association where one class is a “whole” and the other is a “part.”	表示“整体-部分”关系，部分可以独立于整体存在。
Generalization	A relationship where one class is a specialized version of another class (“is a kind of”).	表示类之间的继承关系，子类是父类的特殊版本。
SSD (System Sequence Diagram)	A diagram showing interactions between system objects in response to a system operation.	系统序列图，展示系统对象在响应系统操作时的交互过程。

关键要点 (Key Takeaways):

类关系 (Class Relationships):
• 关联 (Association): 描述类之间的连接关系。
• 聚合 (Aggregation): 表示“整体-部分”关系，部分可以独立存在。
• 泛化 (Generalization): 表示类之间的继承关系，子类继承父类的属性和行为。
系统序列图 (SSD):
• 用于描述系统在执行某个操作时，对象之间的消息传递顺序。
• 帮助理解系统的动态行为和交互流程。

Use-Case Model

英文:
A set of typical scenarios of using a system. There are primarily for functional (behavioral) requirements.

中文:
用例模型是一组典型的系统使用场景，主要用于描述系统的功能（行为）需求。

解释 (Explanation):
• 定义: 用例模型是对系统功能的整体描述，包含所有用例及其关系，展示了系统如何与外部参与者交互以实现目标。
• 用途:
• 描述系统的功能需求。
• 为后续的设计和分析提供基础。
• 例子: 在“图书馆管理系统”中，用例模型可能包括Borrow Book（借书）、Return Book（还书）等用例，以及参与者Member（会员）和Librarian（图书管理员）。

Supplementary Specification

英文:
Basically, everything not in the use cases. This artifact is primarily for all non-functional requirements, such as performance or licensing. It is also the place to record functional features not expressed (or expressible) as use cases; for example, a report generation.

中文:
补充说明是所有未包含在用例中的内容。这个工件主要用于描述所有非功能性需求，例如性能或许可。它还用于记录无法用用例表达的功能特性，例如报告生成。

解释 (Explanation):
• 定义: 补充说明是对用例模型的补充，记录了系统的非功能性需求和无法通过用例表达的功能特性。
• 用途:
• 描述系统的非功能性需求，如性能、安全性、许可等。
• 记录无法通过用例表达的功能特性，例如报告生成、日志记录等。
• 例子:
• 非功能性需求: 系统需要在1秒内响应用户的查询请求。
• 功能特性: 系统需要定期生成销售报告。

Glossary

英文:
In its simplest form, the glossary defines noteworthy terms. It also encompasses the concept of the data dictionary, which records requirements related to data, such as validation rules, acceptable values, and so forth. The glossary can detail any element: an attribute of an object, a parameter of an operation call, a report layout, and so forth.

中文:
术语表以最简单的形式定义了值得注意的术语。它还包括数据字典的概念，记录与数据相关的需求，例如验证规则、可接受的值等。术语表可以详细描述任何元素：对象的属性、操作调用的参数、报告布局等。

解释 (Explanation):
• 定义: 术语表是一个记录系统中重要术语和数据定义的文档，帮助统一团队对术语的理解。
• 用途:
• 定义系统中的关键术语，避免歧义。
• 记录数据相关的需求，如字段的验证规则、取值范围等。
• 例子:
• 术语: Customer（客户）
◦ 定义: 系统中注册的用户。
◦ 验证规则: 客户姓名必须包含字母，长度不超过50个字符。
• 数据字段: Email
◦ 可接受值: 必须是有效的电子邮件格式。

Vision

英文:
Summarizes high-level requirements that are elaborated in the Use-Case Model and Supplementary Specification, and summarizes the business case for the project. A short executive overview document for quickly learning the project’s big ideas.

中文:
愿景总结了用例模型和补充说明中详细描述的高层次需求，并概述了项目的商业案例。它是一个简短的高管概览文档，用于快速了解项目的主要思想。

解释 (Explanation):
• 定义: 愿景文档是对项目高层次需求的总结，描述了项目的目标、范围和商业价值。
• 用途:
• 提供项目的总体方向和目标。
• 帮助利益相关者快速理解项目的核心思想。
• 例子:
• 项目目标: 开发一个在线购物系统，提升用户体验并增加销售额。
• 商业价值: 通过优化用户界面和提高系统性能，预计在一年内增加20%的销售额。

Business Rules

英文:
Business rules (also called Domain Rules) typically describe requirements or policies that transcend one software project—they are required in the domain or business and many applications may need to conform to them. An excellent example is government tax laws. Domain rule details may be recorded in the Supplementary Specification, but because they are usually more enduring and applicable than for one software project, placing them in a central Business Rules artifact (shared by all analysts of the company) makes for better reuse of the analysis effort.

中文:
业务规则（也称为领域规则）通常描述超越单个软件项目的需求或政策，这些规则在某个领域或业务中是必需的，并且许多应用程序可能需要遵守它们。一个很好的例子是政府税收法。领域规则的详细信息可以记录在补充说明中，但由于它们通常比单个软件项目更持久且适用范围更广，因此将它们放在一个中央业务规则工件中（由公司所有分析师共享）可以更好地重用分析工作。

解释 (Explanation):
• 定义: 业务规则是描述业务领域中通用需求或政策的规则，适用于多个项目或系统。
• 用途:
• 确保系统设计符合业务领域的政策和法规。
• 提高分析工作的重用性，避免重复定义规则。
• 例子:
• 政府税收法: 所有在线销售系统必须遵守税收法规，自动计算并收取增值税。
• 公司政策: 员工请假需要经过经理批准，系统需记录请假申请和审批状态。

总结 (Summary)

术语 (Term)	英文定义 (English Definition)	中文定义 (Chinese Definition)
Use-Case Model	A set of typical scenarios of using a system, focusing on functional requirements.	用例模型是一组典型的系统使用场景，主要用于描述系统的功能需求。
Supplementary Specification	Everything not in the use cases, including non-functional requirements and unexpressed features.	补充说明是所有未包含在用例中的内容，包括非功能性需求和无法通过用例表达的功能特性。
Glossary	Defines noteworthy terms and data dictionary, recording requirements related to data.	术语表定义了值得注意的术语和数据字典，记录与数据相关的需求。
Vision	Summarizes high-level requirements and the business case for the project.	愿景总结了项目的高层次需求和商业案例，提供项目的总体方向和目标。
Business Rules	Rules that transcend one software project, describing requirements or policies in the domain.	业务规则是描述业务领域中通用需求或政策的规则，适用于多个项目或系统。

关键要点 (Key Takeaways):

用例模型 (Use-Case Model): 描述系统的功能需求，展示系统如何与用户交互。
补充说明 (Supplementary Specification): 记录非功能性需求和无法通过用例表达的功能特性。
术语表 (Glossary): 定义系统中的关键术语和数据规则，确保团队对术语的理解一致。
愿景 (Vision): 提供项目的总体方向和目标，帮助利益相关者快速理解项目的核心思想。
业务规则 (Business Rules): 描述业务领域的通用规则，确保系统设计符合业务政策和法规。

Contract Co2: enterItem

英文:
Operation:
• Name: enterItem(itemID: ItemID, quantity: integer)
• Description: This operation is used to add an item to the current sale. It creates a SalesLineItem instance, associates it with the current sale, sets its quantity, and links it to a ProductDescription based on the provided itemID.

Cross References:
• Use Cases: Process Sale

Preconditions:
• There is a sale underway.

Postconditions:
• A SalesLineItem instance sli was created (instance creation).
• sli was associated with the current Sale (association formed).
• sli.quantity became quantity (attribute modification).
• sli was associated with a ProductDescription, based on the itemID match (association formed).

中文:
操作 (Operation):
• 名称: enterItem(itemID: ItemID, quantity: integer)
• 描述: 该操作用于将商品添加到当前销售中。它会创建一个SalesLineItem实例，将其与当前销售关联，设置其数量，并根据提供的itemID将其与ProductDescription关联。

交叉引用 (Cross References):
• 用例: Process Sale

前置条件 (Preconditions):
• 当前有一个销售正在进行中。

后置条件 (Postconditions):
• 创建了一个SalesLineItem实例sli（实例创建）。
• sli与当前Sale关联（关联形成）。
• sli.quantity被设置为quantity（属性修改）。
• 根据itemID匹配，sli与一个ProductDescription关联（关联形成）。

解释 (Explanation):

操作 (Operation):
• enterItem(itemID: ItemID, quantity: integer) 是一个操作，用于在销售过程中添加商品。
• 参数:
◦ itemID: 商品的唯一标识符。
◦ quantity: 商品的数量。
交叉引用 (Cross References):
• 该操作与用例Process Sale相关联，表示它是销售流程的一部分。
前置条件 (Preconditions):
• 在调用此操作之前，必须有一个正在进行的销售流程。
后置条件 (Postconditions):
• 实例创建: 创建了一个SalesLineItem实例sli，用于表示销售中的商品行项目。
• 关联形成:
◦ sli与当前Sale关联，表示该商品行项目属于当前销售。
◦ sli与一个ProductDescription关联，基于itemID匹配，表示该商品行项目的详细信息（如名称、价格等）。
• 属性修改: sli.quantity被设置为传入的quantity，表示该商品的数量。

场景示例 (Scenario Example):

假设用户在销售系统中输入商品ID为123，数量为2，系统执行以下步骤：

检查是否有一个正在进行的销售（前置条件）。
根据itemID查找对应的ProductDescription（如商品名称、价格等）。
创建一个新的SalesLineItem实例sli。
将sli与当前Sale关联。
设置sli.quantity为2。
将sli与对应的ProductDescription关联。

最终，销售系统中会记录一条商品行项目，表示用户购买了2个ID为123的商品。

总结 (Summary):

术语 (Term)	英文定义 (English Definition)	中文定义 (Chinese Definition)
Operation	`enterItem(itemID: ItemID, quantity: integer)`	将商品添加到当前销售中的操作。
Preconditions	There is a sale underway.	前置条件：当前有一个销售正在进行中。
Postconditions	- A `SalesLineItem` instance is created. - Associations are formed with `Sale` and `ProductDescription`. - Quantity is set.	后置条件：创建`SalesLineItem`实例，与`Sale`和`ProductDescription`关联，并设置数量。
Use Case	`Process Sale`	该操作属于`Process Sale`用例，描述了销售流程中添加商品的步骤。

关键要点 (Key Takeaways):

操作 (Operation):
• enterItem 是一个核心操作，用于在销售系统中添加商品行项目。
前置条件 (Preconditions):
• 必须有一个正在进行的销售流程，否则操作无法执行。
后置条件 (Postconditions):
• 创建SalesLineItem实例并完成必要的关联和属性设置。
用例 (Use Case):
• 该操作是Process Sale用例的一部分，描述了销售流程中添加商品的具体步骤。
场景示例 (Scenario Example):
• 提供了一个具体的例子，展示了如何通过enterItem操作将商品添加到销售中。

GRASP Summary

GRASP Principle	英文定义 (English Definition)	中文定义 (Chinese Definition)
Low Coupling	How to support low dependency, low change impact, and increased reuse?	如何支持低依赖、低变更影响以及提高重用性？
High Cohesion	How to keep objects focused, understandable, and manageable, and as a side effect, support Low Coupling?	如何保持对象的专注性、可理解性和可管理性，并间接支持低耦合？
Creator	Who creates the Square object?	谁负责创建`Square`对象？
Information Expert	What is a general principle of assigning responsibilities to objects?	分配对象职责的一般原则是什么？
Controller	What is the first object beyond the UI layer that receives and coordinates (“controls”) a system operation?	在UI层之外，第一个接收并协调（“控制”）系统操作的对象是什么？

GRASP Pattern	英文定义 (English Definition)	中文定义 (Chinese Definition)
Polymorphism	Use polymorphism to handle variations in behavior by assigning behavior to subclasses.	使用多态性通过将行为分配给子类来处理行为的变化。
Indirection	Use an intermediary object to reduce direct dependencies between objects.	使用中介对象减少对象之间的直接依赖。
Pure Fabrication	Create a class with no direct real-world correspondence to handle responsibilities that do not naturally belong to any domain object.	创建一个没有直接现实对应关系的类，用于处理不属于任何领域对象的职责。
Protected Variations	Identify points of predicted variation or instability and encapsulate them to protect the system from their impact.	识别预测中的变化点或不稳定性，并将其封装起来，以保护系统免受其影响。

详细解释 (Detailed Explanation):

1. Low Coupling (低耦合):

• 英文定义: How to support low dependency, low change impact, and increased reuse?
• 中文定义: 如何支持低依赖、低变更影响以及提高重用性？
• 解释:
• 目的: 减少对象之间的依赖关系，使系统更灵活，易于维护和扩展。
• 方法:
◦ 使用接口或抽象类定义交互。
◦ 避免直接依赖具体实现。
• 例子: 在支付系统中，PaymentProcessor类依赖于PaymentStrategy接口，而不是具体的支付方式（如信用卡或支付宝），从而降低耦合。

2. High Cohesion (高内聚):

• 英文定义: How to keep objects focused, understandable, and manageable, and as a side effect, support Low Coupling?
• 中文定义: 如何保持对象的专注性、可理解性和可管理性，并间接支持低耦合？
• 解释:
• 目的: 确保每个对象只负责一个明确的功能或职责，避免功能过于分散。
• 方法:
◦ 将相关的功能集中在一个类中。
◦ 避免将不相关的功能放在同一个类中。
• 例子: Order类只负责订单管理，而Payment类只负责支付处理。

3. Creator (创建者):

• 英文定义: Who creates the Square object?
• 中文定义: 谁负责创建Square对象？
• 解释:
• 目的: 确定哪个类应该负责创建另一个类的实例。
• 原则:
◦ 如果一个类依赖于另一个类的创建，通常由依赖类自己创建，或者由更高层次的类创建。
• 例子: 在图形系统中，ShapeFactory类负责创建Square对象。

4. Information Expert (信息专家):

• 英文定义: What is a general principle of assigning responsibilities to objects?
• 中文定义: 分配对象职责的一般原则是什么？
• 解释:
• 目的: 确定将职责分配给哪个类的最佳方式。
• 原则:
◦ 将职责分配给拥有完成任务所需信息的类。
• 例子: 在订单系统中，Order类负责计算总价，因为它拥有商品和数量的信息。

5. Controller (控制器):

• 英文定义: What is the first object beyond the UI layer that receives and coordinates (“controls”) a system operation?
• 中文定义: 在UI层之外，第一个接收并协调（“控制”）系统操作的对象是什么？
• 解释:
• 目的: 管理用户输入并协调系统的响应。
• 原则:
◦ 控制器位于UI层之上，负责接收用户输入并调用适当的业务逻辑。
• 例子: 在Web应用中，UserController处理用户注册请求并调用UserService完成注册。

6. Polymorphism (多态):

• 英文定义: Use polymorphism to handle variations in behavior by assigning behavior to subclasses.
• 中文定义: 使用多态性通过将行为分配给子类来处理行为的变化。
• 解释:
• 目的: 通过继承和接口实现行为的动态变化。
• 方法:
◦ 定义一个基类或接口，并在子类中实现具体行为。
• 例子: 在图形系统中，Shape接口定义了draw()方法，Circle和Square类分别实现了draw()方法。

7. Indirection (间接性):

• 英文定义: Use an intermediary object to reduce direct dependencies between objects.
• 中文定义: 使用中介对象减少对象之间的直接依赖。
• 解释:
• 目的: 降低对象之间的耦合度，提高系统的灵活性。
• 方法:
◦ 引入中介对象（如代理、服务层）来协调对象之间的交互。
• 例子: 在支付系统中，PaymentGateway作为中介，协调Order和PaymentProcessor之间的交互。

8. Pure Fabrication (纯虚构):

• 英文定义: Create a class with no direct real-world correspondence to handle responsibilities that do not naturally belong to any domain object.
• 中文定义: 创建一个没有直接现实对应关系的类，用于处理不属于任何领域对象的职责。
• 解释:
• 目的: 解决领域对象无法直接承担某些职责的情况。
• 方法:
◦ 创建一个专门的服务类来处理这些职责。
• 例子: 在订单系统中，OrderValidator类负责验证订单，但它并不直接对应现实中的某个实体。

9. Protected Variations (保护变化):

• 英文定义: Identify points of predicted variation or instability and encapsulate them to protect the system from their impact.
• 中文定义: 识别预测中的变化点或不稳定性，并将其封装起来，以保护系统免受其影响。
• 解释:
• 目的: 提高系统的稳定性，减少外部变化对系统的影响。
• 方法:
◦ 使用接口或抽象类封装可能变化的实现。
• 例子: 在支付系统中，PaymentStrategy接口封装了不同的支付方式（如信用卡、支付宝），当新增支付方式时，只需实现该接口，而不需要修改现有代码。

总结 (Summary):

GRASP Principle/Pattern	英文定义 (English Definition)	中文定义 (Chinese Definition)
Low Coupling	How to support low dependency, low change impact, and increased reuse?	如何支持低依赖、低变更影响以及提高重用性？
High Cohesion	How to keep objects focused, understandable, and manageable, and as a side effect, support Low Coupling?	如何保持对象的专注性、可理解性和可管理性，并间接支持低耦合？
Creator	Who creates the Square object?	谁负责创建`Square`对象？
Information Expert	What is a general principle of assigning responsibilities to objects?	分配对象职责的一般原则是什么？
Controller	What is the first object beyond the UI layer that receives and coordinates (“controls”) a system operation?	在UI层之外，第一个接收并协调（“控制”）系统操作的对象是什么？
Polymorphism	Use polymorphism to handle variations in behavior by assigning behavior to subclasses.	使用多态性通过将行为分配给子类来处理行为的变化。
Indirection	Use an intermediary object to reduce direct dependencies between objects.	使用中介对象减少对象之间的直接依赖。
Pure Fabrication	Create a class with no direct real-world correspondence to handle responsibilities that do not naturally belong to any domain object.	创建一个没有直接现实对应关系的类，用于处理不属于任何领域对象的职责。
Protected Variations	Identify points of predicted variation or instability and encapsulate them to protect the system from their impact.	识别预测中的变化点或不稳定性，并将其封装起来，以保护系统免受其影响。