3.2.5 使用ROPES软件开发模型做分析

• 分析阶段主要目的：
  在于明确待开发系统的基本特性，这些基本特性涵盖了功能要求、性能要求。这些是系统正常运作所不可或缺的条件，若缺失，系统可能无法正常运行或无法完全实现设计目标。

• 功能需求：
  涉及系统必须执行的具体操作或服务，如用户界面、数据处理、计算或通信等。这些需求直接定义了系统的核心任务以及用户所期望的输出或行为。

• 非功能需求（性能需求）：
  描述系统如何执行其功能，包括但不限于性能、可靠性、安全性和可维护性等。特别是性能需求，它关注于系统响应时间、处理速度、资源利用率等，直接影响用户的满意度和系统的效率。

• 辨识需求的挑战：
  准确地识别和定义这些需求往往是困难的，需要对业务流程、用户需求和技术约束有深入的了解。功能需求和性能需求之间可能存在交织，加之系统的复杂性，使得需求分析成为一个挑战性任务。

• 分析与设计的区别和联系：

  • 分析阶段：
    侧重于定义“系统应该做什么”（功能需求）以及“如何有效地执行”（非功能需求，尤其是性能需求）。分析阶段为系统设计提供了基础，确立了系统必须满足的基本需求。

  • 设计阶段：
    根据分析阶段确定的需求，进行具体的实现和优化规划，确保系统不仅满足功能需求，也符合性能等非功能需求。

• ROPES过程中的明确决策区分：
  在ROPES过程中，分析与设计是两个分明的阶段，各有其职责和目标。分析阶段明确了系统的基本需求，而设计阶段则致力于满足这些需求，并优化系统的总体表现。这种区分确保了设计的目标性和有效性，使团队能够有序地完成项目目标。

3.2.5.1 需求分析阶段

在需求阶段，整个过程是为了详细地识别和捕获当前原型的需求。这个阶段涉及的关键活动:

• 用例选择和细化：虽然原型的用例在早期已经被选定，但它们包含的具体细节和规格尚未完全确定。这意味着需求阶段的主要工作是深入每一个用例，明确和详述它们各自的功能和行为要求。

半螺旋生命周期模型是一个特例，在进入螺旋开发（半螺旋开发模型）之前已经完成需求分析。针对半螺旋开发模型，该阶段主要确定当前迭代原型中需实现哪些详细需求。

• 用例细化方法：

  • 通过示例：
    这种方法涉及创建一系列场景，展示系统在典型或异常情况下的使用情况。这些场景对于帮助非技术相关者理解系统的潜在行为和交互非常有效，同时也为后续测试和验证提供了基础。不过，场景的缺点在于它们可能分散在多个序列图中，使得整体需求难以集中表示，有时候也难以全面和精确地捕捉所有需求。

  • 通过规格说明：
    规格说明可以是非正式的，如使用文本描述，或正式的，如使用UML状态图或活动图等行为语言。规格说明的优点在于它提供了一种更为简洁和精确的方式来定义用例的需求，尤其是对于那些难以通过场景展示的复杂需求。不过，这种方法可能对非技术人员来说理解起来较为困难，而且将需求直接关联到设计的具体实现也可能更加复杂。

• 需求的表示方法：

  • UML序列图：通常用于捕捉和展示场景，展示系统中各部分之间如何交互。
  • 状态图和活动图：用于形式化地描述系统或组件的行为和状态变化。
  • 控制策略图（非UML）：特别适用于描述系统的连续或分段连续行为，常用于更技术性的系统分析中。
  • 文本描述和约束：提供对需求的文字说明和相关约束，是沟通和记录需求的基本方式。

在ROPES过程中，推荐同时使用示例和规格说明两种方法来详细定义用例，这样既可以利用场景的直观性帮助理解，也可以通过规格说明的精确性确保需求的完整性和可实施性。最终，通过这些详细的需求分析活动，团队能够为设计和构建系统打下坚实的基础，并为后续的测试和验证工作提供明确的依据。

3.2.5.2 系统工程阶段

系统工程阶段实质上是关于高层次架构（体系结构）设计。它是微周期的一个可选部分，在以下项目开发场景下需要进行系统工程分析：

• 项目需要大量软、硬件协同设计
• 项目复杂到需要多个团队协作。

此阶段构建高层架构（体系结构）的目的在于为各团队提供一个框架，使其能够在各自的架构（体系结构）上进行工作。以下是系统工程阶段的主要活动内容：

• 确定子系统的架构（体系结构），明确各部分的结构和功能。
• 定义子系统接口和交互协议，确保消息序列的正确传递和处理。
• 明确子系统间的协作方式，以实现系统用例，包括规定每个子系统在协作中的角色，但不深入到子系统的内部细节。
• 将整体系统用例和需求分解到具体的子系统，确保每个子系统的任务和责任清晰。
• 对于表现出连续或分段连续行为的系统，进行算法分析和控制策略规范。
• 将子系统按照其技术领域分解，如电子、机械、化学和软件等。

在系统工程中，
子系统图是常用的表现形式，它主要展示子系统的构成元素，包括子系统本身、参与者、接口及它们之间的关联。
子系统的协作行为通常通过序列图来表示。
而具体到每个子系统的需求，则采用与需求阶段相同的技术，但在子系统层面进行。
系统的硬件与软件分解通过部署图来呈现，
接口则可以通过类图明确展示或用文本规格说明来描述。重要的是要详细记录接收的消息、它们的参数列表以及使用这些消息的限制条件。

在表示算法和连续行为方面，由于UML本质上是离散的建模语言，通常采用UML活动图或控制策略图来表现，并将其与子系统级别的个别用例关联起来。这些方法为捕捉复杂行为提供了有效工具，使得整个系统工程阶段能够高效而精确地进行。

3.2.5.3 对象分析阶段

用例实现：用例被视为包含单一系统能力相关的一系列详细需求的集合。其实现（在UML中称为实现）是通过一组对象的协作来完成的，这些对象共同努力实现这一连贯的需求集。

对象分析：主要任务是构建这种协作，通常针对每个用例逐一进行。

构建协作：针对当前原型，每个实现的用例都构建一套协作模型。如果项目包含系统工程阶段，则这些协作在子系统层面由各团队构建；否则，协作在整个系统层面构建。

逻辑体系结构：利用合适的逻辑体系结构体来组织系统模型，允许子系统共享公共对象、类和类型。

避免设计元素的引入：在分析阶段，需要注意尽量减少设计元素的引入。关注于绝对必要的元素，确保模型的纯粹性和准确性。例如，在模拟特定用例时，确保包含所有必要的对象，如在银行系统中的“管理账户”，应包括客户、账户等对象。

协作构建的验证：在构建对象协作时，需要持续验证“这是正确的吗？”这涉及确认概念（逻辑体系结构）的正确表达、关系的准确性以及行为的适当性。这种验证通常在纳周期中通过执行和测试对象模型来进行，而不是等到最终阶段。

模型仿真验证：在对象分析阶段，可以采用序列图来展示黑盒方式捕获的需求场景（这些场景以黑箱方式呈现了系统的预期行为）。用刚创建的对象来详细化这些场景，并通过模型仿真来验证这些对象是否履行了预期的角色。例如，使用Rhapsody等工具可以对模型进行仿真（在系统执行时动态构建协作的序列图）。在这个过程中，往往会发现一些在对象分析阶段未被注意到的隐藏需求。这种方法不仅使得模型更加精确和可靠，而且还提供了一种动态和交互式的方式来验证和改进系统设计。

协作和行为的表示：通常采用类图来表示协作，其中各个对象的行为规范通常通过状态图（适用于离散响应对象）或活动图（适用于非离散行为对象）来捕捉。整体协作的行为主要通过序列图来捕获，以清晰描绘对象间的交互和整个流程。

通过这样有条理的分析和构建过程，团队可以确保对象协作模型的准确性和有效性，同时为后续的系统实施和测试提供坚实的基础，确保系统设计的可靠性和一致性。