软件开发中的对象操作与设计

### 软件开发中的对象操作与设计 #### 1. 列出对象的模式契约 在软件开发中，经常需要列出呈现一个或多个属性的对象。例如，列出书店中所有书籍的标题： ``` Context Livir::listBook():Set body: book.title ``` 由于控制器中的书籍角色是一个严格的集合，表达式 `book.title` 的结果也将是一个集合。因此，如果有两本书具有相同的标题，即使它们的 ISBN 不同，也只会列出一次。 如果需要一个多列列表（例如，作者和标题），则需要返回一个元组集合： ``` Context Livir::listBook():Set body: book->collect(aBook| Tuple { authorsName=aBook.authorsName, title=aBook.title } ) ``` 有时，需要对列表应用过滤器，例如只返回没有任何关联项的书籍（即从未售出的书籍）的作者和标题。在这种情况下，可以在形成元组之前对集合应用 `select`： ``` Context Livir::listBookNotSold():Set body: book->select( item->isEmpty() )->collect(aBook| Tuple { authorsName=aBook.authorsName, title=aBook.title } ) ``` 大多数列表查询可能只有这两个构造函数：`select`（过滤）后跟 `collect`（投影）。但也可以创建更复杂的查询，在这些情况下，它们不一定符合列表模式（`list`），而是被视为更复杂的报告（`report`）。 #### 2. 与用例相关的契约 扩展用例是一系列按给定顺序执行的命令和查询。通常，每个操作将为其他操作提供信息或确保前置条件。编写此操作序列契约的最佳方法是遵循系统序列图中描述的用例流程。在这个序列中，设计师必须问以下问题： - 每个操作的目标是什么？ - 它们在信息方面产生了什么？ - 它们期望其前一个操作产生了什么？ - 执行期间可能会发生哪些异常？ - 它们的异常能否重新配置为前置条件？ - 它们的参数是否包含无效的值组？ - 这些操作是否遵循已知的模式？ 在回答这些问题时，设计师将构建契约，使命令和查询能够在用例事务的上下文中以一致的方式执行。如果有必要在序列图中添加新的查询或命令以确保某些前置条件，那么现在就是这样做的合适时机。 #### 3. 领域层设计概述 软件设计的总体目标是为已经通过分析充分阐明的问题提供解决方案。问题的静态方面在概念模型中表示，而功能方面在扩展用例、系统序列图和系统操作契约中表示。现在是设计软件（可能还有硬件）解决方案以实现系统的逻辑和技术方面的时候了。从这个意义上说，设计是对通过分析建模的问题的解决方案。 设计活动可以分为两组： - **逻辑设计**：包括与业务逻辑相关的问题方面。通常，逻辑设计由设计类图（DCD）表示，它从概念模型演变而来，以及交互图，展示对象如何交换消息以执行系统操作并实现契约的后置条件。 - **技术设计**：包括与所使用技术固有的所有问题方面，如界面、数据存储、安全、通信、容错等。与技术设计相关的活动将在后面讨论。 逻辑设计也称为领域层设计。领域层对应于执行所有数据转换和查询的类集。其他层实现系统的技术方面，它们通常源自领域层并依赖于它，其作用是将领域的纯逻辑连接到物理计算机方面（通信网络、人机界面、存储设备等）。 领域层的设计基本上包括两个可以迭代执行的活动： - **动态建模**：为系统操作契约构建执行模型。在面向对象系统中，此类模型通常由交互图（如通信图和序列图）或纯文本算法表示。 - **DCD 构建**：基本上是在概念模型中添加一些之前无法或不希望获得的信息，例如关联的导航方向以及每个类中要实现的方法。如果进行了动态建模，这些方面可以有效地包含在软件设计中。此外，设计类的结构可能与概念模型略有不同，因为可能需要新的类或不同的类组织来执行此时所需的某些功能。 逻辑设计可以系统地进行，如果团队拥有两个工件： - 不断发展的设计类图。 - 由系统操作契约表示的功能模型。 逻辑设计活动包括为系统序列图中找到的系统操作（特别是系统命令）构建交互图，同时考虑 DCD 和相应的系统操作契约。 动态建模可以使用通信图、序列图或算法。每种形式都有其优缺点： | 形式 | 优点 | 缺点 | | ---- | ---- | ---- | | 算法 | 对于程序员来说更容易编写 | 难以在简单文本中清晰地实现对象之间的连接，可能导致类之间的高耦合，产生不良设计 | | 通信图 | 比算法更适合可视化和责任分配，比序列图更能明确显示对象之间的可见性线 | 可能难以组织，在复杂协作的情况下可能比序列图更难阅读 | | 序列图 | 通常比通信图更容易阅读 | 不明确显示对象之间的可见性线，如果设计师不警惕，可能会在图中包含无效或不可能的通信 | #### 4. 对象责任分配 对象之间的责任分配涉及以下问题：哪些方法必须在哪些类中实现？ 许多设计师在简单地尝试向类图添加方法时，很难为这个问题构建一个优雅的解决方案。然而，使用交互图和设计模式可以提供一种更高效、更有效的方式来发现实现每个方法的最合适位置。 DCD 是从概念模型构建的，概念模型提供了所需的基本类、属性和关联集。然后，需要为每个系统操作契约开发交互图。这些图显示对象如何交换消息以实现相应契约的后置条件。有一些技术可以帮助以优雅的方式构建这些图。使用图比算法更好，特别是对于新手设计师