这模糊地与:
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。我不确定它是否适用于更大的团队，因为它高度手动以保持最新状态，并且它不会像我们的数据库建模工具那样自动生成代码。
有什么建议吗？对此是否有普遍接受的机制？
仅供引用 - 我们是漂亮的瀑布，短期内不会改变。我们确实喜欢工件……说“转向敏捷”对我们团队来说不是一个可行的解决方案。
最佳答案
我无法从您的问题中看出您的用例有多详细。我的印象是它们可能是高级用例，没有分解成详细的用例(可能通过include 或extend 关系。
无论如何，我更喜欢从需求开始，然后追踪到用例。在编写用例和用例图的同时，我也在创建域模型(高级类图)。这主要是为了让我可以与利益相关者讨论(“我做对了吗？”)。
完成用例和领域模型后，就可以开始进行屏幕设计，如果屏幕之间存在复杂的交互，也可以开始进行事件模型。我会将屏幕视为带有 UI 的类 - 屏幕可能具有 FirstName 属性，我注意到它与域模型中 Person 实体的 FirstName 属性相关。然而，FirstName 属性可能会在该屏幕上表示为文本框。
同时，可以进行物理数据库设计。这将生成一个类图或 ER 图，可以追溯到领域模型。最终，您可能会发现您的某些屏幕属性或事件建模引用的内容属于物理数据库模型的一部分，但在域模型中不存在。可以将屏幕“PersonalName”属性与 People 模式中 Person 表中计算的 PersonalName 列相关联。
我用于此类事情的工具是 Sparx Enterprise Architect .这是一个很棒的工具，即使在专业版中也可以完成所有这些甚至更多。
我还必须说实话，我主要是自己建模——我还没有参与过模型、代码和数据库由不同的人开发的项目。如果有人告诉我以上内容在“现实生活”中行不通，我可能不得不相信他们。
关于database - 追踪设计 - 屏幕到数据库的可追溯性，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/758155/