对象规划或用户流规划 - 应该先行？

Question

在开始一个新的软件时，您是否发现首先规划界面和用例，或概述需要构建的对象更有帮助？

我可以看到前者的争论，因为在你到达那里之前你必须知道你要去哪里。但是，当我说'界面用例'时，我的意思是非常具体的应用程序流程。基本上，整个软件都在纸上。

第二，规划程序化的“大局”，可以让您了解潜在的发展瓶颈。它还有助于理解应用程序流程，并可能在某种程度上改变用户交互。

根据您的经验，预先最佳使用时间是什么？

Answer 1

用户流程优先：您正在为用户构建软件。一旦你知道你需要做什么（整个画面），你就可以考虑如何做到这一点。

Answer 2

我肯定会建议首先布置用户流，在这种情况下，因为它是如此具体。使用更常见的UI，计划/猜测对象会更容易。但是，由于你有一个详细的应用程序流规范，首先要处理它，因为太早计划对象肯定会错过很多规范的目标。

Answer 3

这些可以并行发生，无需在编码开始之前完成。

通过迭代开发，您不一定要预先设计纸上的整个软件或整个类模型。

用户交互会影响班级模型。但是，您可能有足够的信息在用户交互设计完成之前开始设计一些架构层。例如，在您开始设计特定交互之前，可以全部或部分地了解数据模型。

日程安排问题可能使得并行工作更加可取，特别是如果您从一开始就有多名员工参与。

Answer 4

我在这个问题上看到了错误的选择。

有些系统甚至没有UI！因此，您无法合理地期望对此问题采用单一的，普遍适用的答案。

在许多系统中，实际上有业务逻辑层和UI层的不同对象模型，实际上可能存在多个UI。例如，客户UI在客户支持团队的浏览器和胖客户端应用程序中提供。

用例和用户界面也不是一回事。第一个问题可能是：“告诉我你在创建一个新的Wibble时需要做些什么。”一开始根本不需要谈论UI。您可以仅根据“我希望系统...”来建模方案。

在绘制屏幕时务实，您可能正在构建Business Objects的心理模型。在简单的商业案例中，您可能不需要立即记录该模型。在更复杂的场景中，特别是在处理传统的后端系统时，你很快就会发现需要捕获一些模型：“这个屏幕是关于Wibbles的？关于它们的Zetules？每个Wibble都有自己的Zetule吗？哦，几个！我们可以改变它们，将它们传递给其他Wibbles吗？哦只有Blue Zetules可以转让吗？“

如前所述，它将具有互动性和创造性。第一个切割屏幕模型将改变。你会发现越来越多的粗糙位。

我明确的答案是：最好利用时间预先定位龙。龙隐藏在未知之中。大龙是一种风险，隐藏在粗糙的地方。 Gnarlyness特定于项目，有时它的UI有时不是。特别是在处理遗留系统时，通常不会让用户界面咬你。花时间来承担风险。