0

我是一名信息工程专业的学生，​​正在准备考试。我必须将用例中的名词以项目符号列表的形式替换为使用 CRC 卡提取的类的名称。我遇到了麻烦，因为我不知道如何正确地做。

  • 示例 A：“系统更新页面”->“图腾更新页面”

CRC 卡是否必须包含控制视图的类？此控件是否必须通过“控制器”类，如（在我的情况下）“连接”？

  • 示例 A 2.0：“系统更新页面”->“图腾请求连接更新页面”

CRC 卡是否必须包含控制数据库的类？

  • 示例 B：“系统在数据库中添加产品”->“连接添加对象产品到目录

有人可以帮助我了解如何正确执行此操作吗？对不起我的英语，对不起“奇怪”的问题

注意：所有示例都是我创建的，所以我不知道它们是否正确

4

1 回答 1

0

没有直接关系

CRC 卡和用例是两种独立的技术：

  • CRC 卡是关于班级、他们的职责和他们的协作（与其他班级）。它是一个有助于探索潜在类和类之间交互的工具。它可以与任何类一起使用，包括视图类和控件类。

  • 用例是面向目标的。重点是外部参与者可能与系统交互的原因。它是一种有助于捕捉系统目的及其与外部世界边界的工具。它原则上独立于任何内部类。

开始派生具有间接关系的类

使用实体控制边界技术可以将用例映射到类。让我们想象一个演员Sales admin和一个用例Manage products：

  • 每个用例都映射到特定的控制类，例如 ManageProduct；
  • 参与者和用例之间的每个链接都映射到一个边界类，例如ManageProductsForSalesAdmin；
  • 对参与者重要的已识别业务对象也映射到实体类，例如Product.

使用 CRC 卡微调设计

这可能是 3 个第一个 CRC 卡的开始，它将阐明什么类做什么（包括 UI 和 DB 持久性）。您很快就会发现这些初始的“分析类”需要进一步分解和丰富。

例如：

  • 根据您喜欢的框架，用户界面可能需要不同的类。因此，将分解ManageProductsForSalesAdmin分解为更详细的类，例如ManageProductsView和ManageProductsListener或任何需要的类。如果初始卡的所有职责都转移到新卡上，您可以将其停用。
  • 您可能会突然意识到 a与 aProduct相关联ProductCategory：使用新发现的实体的新 CRC 卡来丰富您的集合。
  • 这ManageProducts可能需要一些专业知识来处理不同的行为，例如CreateProduct, DuplicateProduct, ChangeProduct, DeleteProduct. 最初的卡片可能会保留一些共同的责任，并与更专业的卡片共存。

您可以继续丰富您的 CRC 集并玩牌，直到您对课程感到满意并达到稳定的职责划分。CRC 是迭代工作的理想选择；-)

附加评论

EBC 方法的主要好处是它能够将类与用例相关联。这不仅是理论上的好处，而且是非常实用的：如果你改变一个类，你可以很容易地确定对用户的潜在影响（以及测试的注意点）。因此，每次创建新的 CRC 卡时，您都可以简单地跟踪相关用例。

关于用例的最后一句话：“系统更新页面”不是用例：这不是参与者的目标。这是系统必须在更大的上下文中执行的一些操作。

PS：对不起，如果这可能会迟到你的考试

于 2021-07-22T17:35:39.767 回答