这与以下内容含糊不清：
Should I design the application or model (database) first?
Design from the database first through to UI or t’other way round?
但我的问题更多的是建模和工件，而不是正确的设计方法。我试图找出哪种设计工件最能说明功能（用例），屏幕和数据库元素（特别是表和列）之间的链接。 UML非常以代码为中心。数据库模型非常以数据库为中心。屏幕设计是以UI为中心的！
这是交易......我的团队正在开发该产品的第一个版本。我们使用了用例，然后屏幕设计和数据库设计与这两者有些隔离。错误的一个关键领域是用例及其附带的屏幕和数据库之间缺乏可追溯性。在我们的产品中，用例和数据库元素之间存在很高程度的重叠。许多用例触及超过75％的数据库基础结构。因此，我们对数据库设计领域存在高度争议，并且很容易通过小型数据库更改来破坏较低级别的业务逻辑。
对于我们的下一个版本，我希望开发人员和我们的DBA能够非常清楚地了解每个功能涉及的数据库的哪些部分。用例/屏幕设计方法运行良好，所以我们保留它......诀窍是将每个用例和屏幕链接到数据库模型，这样关系就非常明显，很难忘记。
在较小的项目上（我们只有10人，但我经常在3人或更少的团队中工作），我已经创建了自己的自定义图表来展示这部分设计。屏幕，UML和数据库表的融合，在Visio中完成，没有实际代码或SQL的链接。我不确定它是否适用于更大的团队，因为它是高度手动的，以保持最新，并且它不会像我们的数据库建模工具那样自动生成代码。
有什么建议吗？是否有一个普遍接受的机制？
仅供参考 - 我们是漂亮的瀑布，不会很快改变。我们确实喜欢文物......说“切换到敏捷”并不是我们团队的可行解决方案。
答案 0 :(得分：3)
我无法从您的问题中看出您的用例有多详细。我得到的印象是，它们可能是高级用例，而不是分解为详细的用例（可能通过 include 或扩展关系。
无论如何，我更喜欢从Requirements开始，并将它们跟踪到用例。在我编写用例和用例图时，我还创建了一个域模型（一个高级类图）。这主要是为了给我一些与利益相关者讨论的东西（“我做对了吗？”）。
当用例和域模型完成时，如果屏幕之间存在复杂的交互，则可以开始处理屏幕设计，也可能开始处理活动模型。我会把屏幕视为具有UI的类 - 屏幕可能具有FirstName属性，我注意到它与我的域模型中Person实体的FirstName属性相关。然而，FirstName属性可能会在该屏幕上显示为文本框。
同时，可以进行物理数据库设计。这将生成一个类或ER图，可追溯到域模型。最终，您可能会发现某些屏幕属性或活动建模是指属于域模型中不存在的物理数据库模型的一部分。可以将屏幕“PersonalName”属性与People模式中Person表中的计算PersonalName列相关联。
我用于此类事情的工具是Sparx Enterprise Architect。它是一个很棒的工具，即使在专业版中也可以完成所有这些工作。
我还必须说，为了真理我主要是自己模型 - 我还没有参与过一个项目，模型，代码和数据库是由不同的人开发的。如果有人告诉我上述内容在“现实生活”中不起作用，我可能会被迫相信它们。
答案 1 :(得分：1)
我不确定我清楚地理解你的问题，但我会尝试根据一些合理的假设做出回应......
基本上，我的建议与 John Saunders 已经提出的建议相同：考虑使用UML和一个好的UML工具。但我想补充一些在您的具体情况下可能很重要的要点。
首先，我不认为UML“过于以代码为中心”。相反，它几乎可以在任何抽象层次上用于模拟软件系统的任何方面。有了一个很好的工具（比如Sparx EA），UML的优点在于你实际上确实得到了一个定义明确的模型（而不仅仅是一组未连接的图纸/图表）。因此，即使工具本身没有为您提供您正在寻找的功能（例如从数据库到用例的可追溯性）......好吧，至少您可以选择自动化（或至少半自动化）您自己的任务：例如，您可以将您的UML模型导出到XMI（标准！），然后从那里导出您需要的任何可跟踪性相关信息（例如，使用XSL或任何XML感知库为您喜欢的编程/脚本语言） 。我并不是说这很容易（特别是如果你想要在各个DB列8-的级别上追溯），但它是可能的，如果它必须按照规模扩展，它很可能会超过任何手动方法。该项目。
BTW，谈到Sparx EA ......我还不知道它的所有功能，但它有很多，如果它允许你选择一个类（甚至是一个类的属性）我就不会惊讶并以某种方式向您展示依赖于它的其他模型元素。你可能想看看这个。说了这么多，我明白你可能至少有以下两个关于UML的重要问题：
关于问题＃1：同样，使用一个好的UML工具，您可以根据需要执行任意数量的快捷方式。例如，不是为用例构建非常详细和准确的活动模型，而是只关注用例中涉及的类（足以使跟踪类回到用例）。当然，这同样适用于UI。
关于问题＃2：我不知道您现在使用什么确切的工具来建模用例，UI和数据库架构。因此，从理论上讲，它们可能都优于UML，您不希望为了更容易追溯而提供任何优先级。但是，有些东西告诉我，你的数据库建模工具（具有代码生成功能）可能是唯一真正不可或缺的工具。如果是这种情况，那么我仍然建议考虑使用UML：你只是不建模到数据库模式级别并在域模型级别“停止”（即使你的应用程序中没有它！）。此时，UML工具将为您提供从域模型元素（实体，它们的属性和它们的关系）到项目和UI元素的可追溯性，并且您的域模型和数据库模式之间的映射可以“留在空中”因为，在绝大多数情况下，它们应该足够简单，无需绘制任何东西即可跟踪。这可能不会给你100％的你想要的东西，但它可以给你80％，这足以缓解大多数你的问题。
底线：如果您使用三种不同的工具/技术来模拟系统的三个不同方面......那么，很明显，这三个方面之间的任何可追溯性都依旧于这三个工具：您只能自动化尽可能多的工具允许（这可能意味着你将面临许多繁重的手工任务）。截至今天，UML似乎是唯一定义明确且得到广泛支持的“通用语言”，它可以帮助您连接模型，并可以实现大部分分析活动的自动化。只需确保将UML“只是绘图工具”（如大多数Visio附加组件和模板）与真正的UML建模工具（如Sparx EA和其他一些工具）区分开来。
答案 2 :(得分：0)
您的使用案例是一个很好的起点。
将您的用例转换为 可执行测试代码。这个测试代码 需要验证结果 返回值是根据的 用例的要求。
你工作的部分越小 可以识别和测试，更多 健壮，你将能够建立 你的申请。
这意味着互动 你的用例有很大一部分 你的数据库和GUI 更容易理解。
通过完整的不同层的前期设计，很难锁定复杂项目中的架构或业务逻辑相互作用。只有在您实现这些要求时，才能真正了解什么才能满足您的要求。
作为开发人员，找到有助于您以最佳方式完成工作的技术，工具和流程。不要根据它们的来源判断这些。判断他们的价值在于让你成为最好的开发者。
敏捷世界的一些项目无疑对我作品的质量和生产力产生了很大的影响。这不需要扔掉苹果车，让经验丰富的瀑布队陷入混乱。
答案 3 :(得分：-1)
数据库应该为您的问题域建模。它应该足够模型化，以便您可以从中提取解决方案 - 真相。糟糕的设计基本上是“撒谎”到数据库（允许无效数据或关系的可能性），当你“欺骗”你的数据库时，当你提出问题时，它会“骗你”。
简单示例是建模多对多关系，其中关系只能是一对多，或者假设值不能为null，或者将外键视为属性。其中许多可以通过适当的规范化来避免，这需要您明确地找出什么是关键，什么不是。
通过在模型中“使非法国家无法代表”，您可以避免编写“防御性”代码来检查不可能或验证关系是否可能，因为不可能的事情由于表结构或声明性检查而无法代表约束
这降低了编写代码的成本，因为您可以在很大程度上集中注意力，而不是防范不可能的事情。