Preliminary Design Review（初步设计评审（回顾））

 

一、前言  

    初步设计评审（PDR）会话帮助您确保鲁棒图，领域模型和用例文本都相互匹配。针对每个用例来说， 这个评审是初步设计和详细设计阶段之间的“门户”（桥梁）。在本章中，我们提供了PDR的概述，然后我们将展示Internet Bookstore的示例。初步设计评审理论，在本节中，我们将介绍PDR的关键要素，包括我们的前10名PDR指南。

二、为什么选择PDR？

 

    为什么要在鲁棒性分析后重新评审你的模型？ 这是一个假想的的对话，我们希望能够对这个话题有所了解：

1、 问：我为每个用例都绘制了一个鲁棒性图表，结果我认为用例模型很好。可以开始设计吗？

 

    答：首先有一个快速评审步骤：初步设计评审（PDR）。 此评审会话帮助您确保鲁棒性图表，领域模型和用例文本都相互匹配。

 

2、 问：谁应该参与PDR会议（阶段）？

 

    答：和参加需求评审的是同一群人：客户代表，开发团队以及密切参与项目的一些管理人员。 客户将密切参与和涉及这个会议（阶段），但这次评审是客户直接参与的最后阶段。 之后，它是详细的设计 - -这是高级开发人员的工作。

    （注意：当然，客户可能仍然对正在进行的工作，截图等进行评论，但是您不希望非技术性（或更糟糕的是，客观上）客户去进行评论或推动未来的设计）

 

3、 问：但是如果客户想要在以后添加新的需求呢？

 

       答：这是一个不同的问题。 我们所说的只是客户没有介入到设计和编码（即PDR之后的剩余步骤，直到交货）。

4、 问：如果客户确实想添加新的要求，这会对流程有什么影响？

 

    答：对于新的需求，那么至少要回到过程的第1步（根据需要修改用例和领域模型）。处理分析和在不断改变需求的海洋里进行设计工作是一个复杂的难题，并且在这个过程中伴随着陷阱（Handling the analysis and design effort in a sea of changing      requirements is a complex subject with many pitfalls）。所以我们写了一个关于这个问题的另一本书。

 

5、 问：在PDR期间还需要实现什么？

 

        答：这是一个很好的机会来确保您的实体类已经填充了属性，在你的系统中的屏幕（screen）都有名称，并且可以跟踪屏幕（screen）和实体类之间的数据流。

 

 6、 问：如果我们正在做一个详细的设计，我们还不应该考虑技术架构（TA）？

 

    答：是的，在这个会议（阶段）进行的期间，TA也应该被评审。 您需要确保新兴的设计将与您选择的架构配合使用。

三、十大PDR指南

   本章讨论的原则（principles）可以概括为一个准则清单。 我们的前10名列表如下：

 

     10.对于每个用例，请使用“荧光笔测试”（highlighter test）确保用例文本与鲁棒性图匹配。

 

       9.确保所有鲁棒性图中的全部实体都显示在更新的领域模型中。

 

       8.确保您可以跟踪实体类和屏幕（screens）之间的数据流。

 

       7.不要忘记“备用课程”（alternate courses），不要忘了在找到他们时为每个“课程”写行为。

 

       6.确保每个用例都覆盖用户和系统之间“会话”（dialogue）的两侧。

 

       5.确保您没有违反鲁棒性分析的语法规则。

 

       4.确保此评审包括非技术（客户，营销团队等）和技术人员（程序员）。

 

       3.确保您的用例位于对象模型和GUI上下文中。

 

       2.确保您的鲁棒性图（和相应的用例文本）不会尝试在时序图中将显示的相同级别的细节（即不要尝试详细设计）。

 

       1.按照我们的“六个简单的步骤”得到更好的初步设计（见第6章）。

四、十大PDR指南详解

       10. Use the Highlighter Test to Match the Use Case Text with the Diagram

     有时候，人们认为他们应该仅在鲁棒图表上显示基本的行动方案，或者他们应该为每个不同的“方案”做一个单独的图表。 但是最好在单个鲁棒性图上显示整个用例（基本和全部不同的）。 如果图表变得太大（或者如果您发现替代项有自己的子选项），请考虑拆分用例。一个59美分的荧光笔被证明是验证您的用例文本与您的图表匹配的宝贵工具。 只需突出显示您的用例的一个句子，并突出显示您的鲁棒性图表的相应部分，并继续，直到所有文本被突出显示。 您还应该看到整个鲁棒图突出显示部分。如果您发现文本和图表不匹配（并相信我们，您将会），那么您有更多的工作要做。

        9. Make Sure That All the Entities Appear Within the Updated Domain Model

     由于对象发现是鲁棒性分析的主要目的之一，因此在我们的鲁棒图中发现新对象没有任何意义，并不会将它们添加到类模型中去（从领域模型中演变而来）。避免忘记将它们添加到类模型中的最安全的方法是实际上在类模型中添加新类，将它们构造为实体，然后将它们拖到鲁棒图上。

 

        8.确保您可以跟踪实体类和屏幕之间的数据流

 

         您的用例很可能涉及用户的具体信息，通过使用系统屏幕。该数据需要找到进入实体类的方式，它们将输入的值保存为属性。当然，这也可以以其他方式工作：实体类的值将显示在屏幕上。编码之前的任务之一是确定每个类所需的一组属性。因此，当你正在跟踪屏幕和实体类之间的数据流，填充所需的任何缺少的属性的类模型。

 

        7.不要忘记可选方案，不要忘记指定他们的行为

 

         现在听到我们说这些，你可能已经厌倦了，但是如果不重要，我们不会重复。忘记关于“可选方案”是软件开发中的主要失败模式之一。对于每个可选方案，请确保触发它系统行为的条件是完全详细的。确定可选方案可能会发生是很有必要的，但不足以完成您的用例。除了简单地列出可选方案外，还需要详细说明可选方案的处理方式（用户和系统）的确切行为。由于可选方案通常占一个软件的一半以上的复杂性，因此您应该明白为什么需要对于可选方案来制定具体的行为。如果没有，您的类将会失去处理可选方案的所有操作。（可选方案不一定是错误路径，但可以包括不频繁/非典型的使用路径。（类似于后期找BUG））

 

       6.确保每个用例涵盖用户/系统对话的双方

 

        我们在第一次学习编写用例的人中遇到的最常见的错误之一是，它们只是记下用户所遵循的所有步骤，然后宣布他们已经完成了用例（不可避免地比那些在训练班的人更快）。这个有缺陷的过程忽略了一个至关重要的一点：在大多数情况下，目标是完全理解和指定系统的软件行为。如果仅写入用户操作并忽略系统行为，则您不会在指定软件行为的目标方面取得进展。（请记住，用例是用户和系统之间的对话，您需要写出对话的双方。）

 

       5.确保您没有违反鲁棒性分析的语法规则

 

    有关鲁棒性分析的完整规则，请参见图5-8和5-9。特别是在审查期间确保

 

       •演员（Actors）只与边界对象相连。

 

       •边界/实体，边界/边界或实体/实体对象之间没有名词 - 名词通信，在两者之间没有控制器的情况下。控制器代表系统的行为，所以把它们落下是一件非常糟糕的事情。 

 

    鲁棒性分析的语法规则有时可能会有点令人讨厌，但是将用例的初步设计变成模型，以便适合这些规则，严格准备您的用例进行详细设计。（The robustness analysis syntax rules might seem a little bit irksome at times, but bashing your use case’s preliminary design into shape so that it fits these rules seriously prepares your use case for detailed design.）如果你这个阶段做的很不错，编码应该是轻而易举的。考虑一下：如果一个用例证明把它变成一个有效的鲁棒性图表很麻烦，那么把它变成一个有效的工作设计（和有效的工作，可维护的代码）将是十倍的麻烦！鲁棒性图提供了一个方便的预警系统，用例文本需要更多的工作（即模糊，模糊，不完整等）。正如您在第5章中看到的，ICONIX Process的自动化工具支持正在不断改进，验证鲁棒性图语法规则现在与下拉菜单一样简单。

 

       4.将非技术人员和技术人员纳入审查

 

    鲁棒性分析后的用例应被视为客户端和程序员之间的“微型契约”。因此，它们（用例）需要被最终使用者和客户理解，并无歧义而且足以被程序员清楚地理解。在PDR期间，您最终确定了这些锲约。换句话说，每个用例必须达到魔术抽象级别（magic abstraction level） - 不是模糊的，也不是二异性的，而不是极客（geek-speak） - 大家都明白用例意味着什么。

 

      3.确保您的用例位于对象模型和GUI的上下文中

 

       我们刚刚描述的“魔术抽象级别”可以通过将用例放在对象模型和GUI的上下文中来实现。实际上，这意味着你已经命名了你的屏幕和你的领域类。通过使用领域对象和屏幕解决“名称歧义性” 解决了很多问题。这个级别的用例还需要在系统的（演进）技术架构的背景下，但不应该跨入详细的设计，因为如果你将会很快失去非技术客户的注意力。

 

      2.不要漂移到详细的设计领域 

 

    请记住，鲁棒性图表示理想化的概念设计，而不是“真正的软件设计”。实际上，这意味着与分类行为有关的决策不应该在鲁棒性图上。这些决定最好推迟到绘制序列图。ICONIX进程采用双程（两步two-pass）方式进行详细设计。 在第一遍，您故意忽视“谁在做什么”，并专注于识别对象，命名屏幕，并明确描述行为。 一旦你完成了这个工作（你已经在PDR中进行了验证），你可以在详细的设计过程中准备好在行为分配问题（即方法如何分配到各个类之间）。

 

     1.按照我们的“六个简单的步骤”进行更好的初步设计 

 

   为了实现PDR的目的（如本章开头所述），它有助于对初步设计图和用例文本进行一些关键检查。 对于您正在审查的每个鲁棒性图2

 

     •确保图表与用例文本匹配。

 

     •确保图表遵循鲁棒性分析规则。

 

     •检查图表的重点是用例的逻辑流程。

 

     •确保该图显示了用例所有可选方案的操作。

 

     •注意图中的“design-pattern-itis”。

 

     •检查图并未尝试详细设计。

五、初步设计评审实践--网上书店

PDR--“写客户评审”鲁棒性图

 

对于这个例子PDR会话，我们会在评审者/分析师对话展开之后进行跟踪。

我们在图5-15中留下了鲁棒性图，所以当您浏览此示例会话时，值得回看该版本的图。

 

1、顾客评审对象不是“输入评审”文本的容器

 

这个审查中的主题的一个共同话题是，该图没有进入足够的细节，或者跳过了用例文本中提到的重要细节。

 

 

 

评审者：查看鲁棒性图（见图6-1中的摘录），我希望“客户评审”对象成为屏幕上输入的“输入评审”文本的容器，但未连接。

分析者：我们可以在“写评论”页面边界和客户评审实体之间画一条线。 。 。

评审者：这是诱人的，但它会违反鲁棒性分析的规则。记住，名词 - 名词沟通是一个主要的no。

 

（这样一个严格和看似限制的规则存在很好的理由：如果你在图上的两个名词之间画一条线，那么几乎肯定有一些行为（也就是动词）不被考虑。）

 

分析者：来想想，我不认为我们显示两个用户操作的行为：分配评级并输入评审文本。

评审者：我们应该添加控制器来处理这两种行为，并使用它们将“写入审阅”页面与“客户审核”实体链接。问题解决了！ （“点击发送”标签也需要移动，但是我们将在下一节中介绍;图6-2显示了更新的摘录。）

 

单击发送

撰写评审页面

输入评审文字

分配审查评级

客户评审

 

（“但我们是建模网页互动”“

 

对此建议的通常反应（显示用户将文本或其他数据输入到UI中作为控制器）是如果以网页的形式实现，则您永远不会实际编写代码来处理这些事件 - 这一切都是在浏览器中完成

简单的答案就是你现在并没有在这个阶段进行设计。

你对这个图表主要感兴趣的是从图片形式的用例文本中显示所有内容。

开始这个级别的细节似乎是一个拖动，但令人惊奇的是，这个隐藏的功能有多少被揭露出来。否则这些细节将被清除，直到软件设计和编码开始之后。在极端情况下，在软件发货之后，细节可能尚未被发现，用户做了一些意想不到的事情，并且程序崩溃，因为在鲁棒性分析期间，令人难以置信的细节尚未得到适当的分析。所以，从中学习的教训是，如果在用例文本中，将其放在图表上！）

 

2、解决一个问题有时会导致另一个问题的产生。 在仔细观察图6-2中添加的两个新控制器后，我们的评审人员发现另一个潜在的麻烦来源。

 

 

评审者：在鲁棒性图中（见图6-3中的摘录），您已经标记了actor（Customer）和“Write Review page”边界对象之间的消息。

分析者：似乎对我无害。您需要知道用户在边界对象上执行的操作。

评审者：当然，但是这个需要更多的是这个标签要往哪里去？问题是，如果您有多个操作进入一个边界对象，那么对于每个动作在边界对象之后的位置很快就变得模糊。

分析者：因为我们有三个控制器出现在“写评审”页面，我们不知道哪个是“点击发送”动作？

评审者：正确如果相反，您在边界对象和控制器之间标记消息，这将使图表更加清晰。如果您将用户的操作（“单击发送”）放在那里，那么对于哪个控制器处理哪个用户操作就不会有任何疑惑。 （图6-4显示了鲁棒性图中更新的摘录。）

 

 

3、显示控制器需要更多详细的名称

 

有时，当你向左，右和中央添加控制器时，很容易（tempting）将细节从图中删除。但是，在详细的设计过程中，这可能会导致二义性，以后再次咬住你。在下一个例子中，评审者发现一些细节已被巧妙地遗留在图中。

 

评审者：您已使用单个边界对象（“评审拒绝的页面”）显示两个可选方案验证控制器的结果（“评审等级在允许的范围？”和“书面评审长度确定？”）。但是，每个人都有自己的显示控制器。见图6-5摘录）

分析者：但是我以为我们意图要显示单独的显示控制器？

评审者：毫无疑问，但他们是模糊的。问题是，将构建一个具体的消息来告诉用户审查被拒绝的原因，例如“评审长度必须至少为10个字符，但您的评审内容只包含5个字符。”

分析者：让我猜一下，我们没有明确说明每个控制器的“评审被拒绝的页面”显示的内容不同。

审评者：你做到了，为了纠正这一点，我们将每个显示控制器重命名为更具体的内容。 （见图6-6）

 

4、The Use Case Text Is Missing Some Detail

在PDR期间，您应该同样专注于使用案例文本与鲁棒图。

在这次审查的最后一个例子中，审阅者注意到用例描述中缺少一些细节。

 

评审者：好的，这真的开始看起来像一张图，你可以很容易地从中产生一些详细的设计。

只是最后一件事。 该图调用另一个名为Moderate Customer Reviews（好的用户评审）的用例。 在用例中，它与此文本匹配：

然后，系统将显示一个确认屏幕，并将评审发送到的好评审，准备被添加。

但文本中缺少一些实际发生的细节。目前，我们将其视为阅读（可读），新提交的评论将以某种方式找到好评审，然后谁将在网站上发布之前查看客户评论。正如我所提到的，好评审的行为由单独的用例处理，好的客户评价。但是我们没有建模的（或描述）是评审如何进入第二个用例。

分析者：我们将向这样更新用例：系统随后显示确认屏幕，客户评审排队等待好评审（这将由“好的客户评审”用例处理）。

 

分析者：我们将向这样更新用例：系统随后显示确认屏幕，客户评审排队等待好评审（这将由“好的客户评审”用例处理）。

 

评论者：更好，但不要忘记，我们需要将用例与对象绑定（tie）。简单地说，“评审排队等待审核”并不完全这样做，因为它不提供任何类型的链接到对象，将跟踪进入的客户评审。

 

分析师：（思考）“追踪顾客评论的对象”？嗯，听起来好像我们刚刚确定了一个新的域对象 - 这是一个将进来的顾客评价排队的对象。

 

评论者：让我们称之为“待评审队列”。

 

分析员：好的，所以这里是更新的用例文本（更新的文本显示为红色）：系统显示一个确认屏幕，并将客户评价添加到待审核队列中进行审核（这将由中等程度处理

顾客评论用例）。

 

 

 

评论者：这也表明，图书ID需要成为“客户评审”的一个属性，反过来又表明图书应该也在图上。现在我们可以将新的“待评审队列”对象添加到图表中。

 

分析师：哇，所有这些新的细节都发现了，只需将用例文本与模型更紧密地联系起来！

 

5、完成“写客户评审”鲁棒图

鲁棒图的完成版本如图6-7所示。您可以看到，现在可以阅读图表左侧的用例，并同时浏览图表。

（一个常见的场景是在图的左上角启动用例，并在右下方完成，尽管这绝对不是必须的）。

用例中没有任何内容被假定为“机会（chance）”，并且文本与域对象模型很好地绑定在一起。我们已经做了基础，所以通过这个图，我们现在可以很容易地设计的。

 

精明（Astute）的读者会注意到，这个图表现在已经成为我们通常所说的“非常大”。

实际上，它几乎达到用例大小的上限（记住第3章的两条规则）。

 

如果用例已经很长了，或者图表更复杂，我们会认真考虑将其分解成两个或更多个较小的用例（因此，两个或更多更小的鲁棒性图）。