1

This is vaguely related to:

Should I design the application or model (database) first?

Design from the database first through to UI or t’other way round?

But my question is more about modeling and artifacts and less about the right way to do design. I'm trying to figure out what sort of design artifact would best enunciate the link between features (use cases), screens and database elements (tables and columns, most particularly). UML is very code-centric. Database models are very database centric. And of screen designs are UI centric!

Here's the deal... my team is working on the first release of the product. We used use cases, then did screen designs and database design was somewhat isolated from the two. A critical area for bugs was the lack of traceability between the use cases and their accompanying screens and the database. In our product, there's a very high degree of overlap between use cases and database elements. Many use cases touch over 75% of the database infrastructure. So we have high contention over database design areas, and it's easy for a small database change to disrupt the lower levels of business logic.

For our next release, I want the developers and our DBA to have a really clear insight into what parts of the database each feature touches. The use case/screen design approach worked well, so we're keeping it... the trick is linking each use case and screens to the database model so the relationships are really obvious and hard to forget about.

On smaller projects (we're only 10 people, but often I've worked on teams of 3 or less), I've created my own custom diagrams to show this part of the design. Sort of a fusion of screen, UML and database table, done in Visio with no link to actual code or SQL. I'm not sure it will work for a larger team, as its highly manual to keep up to date, and it doesn't auto generate code the way our database modeling tool does.

Any recommendations? Is there a commonly accepted mechanism for this?

FYI - we're pretty waterfall, that isn't going to change any time soon. And we do love artifacts... Saying "switch to agile" is not a viable solution for our group.

4

4 回答 4

3

我无法从您的问题中看出您的用例有多详细。我的印象是它们可能是高级用例，没有分解为详细的用例（可能通过包含或扩展关系。

无论如何，我更喜欢从需求开始，并将它们跟踪到用例。在编写用例和用例图的同时，我也在创建域模型（高级类图）。这主要是为了给我一些与利益相关者讨论的东西（“我做对了吗？”）。

完成用例和领域模型后，可以开始进行屏幕设计，如果屏幕之间存在复杂的交互，也可能开始设计活动模型。我会将屏幕视为具有 UI 的类 - 屏幕可能具有 FirstName 属性，我注意到它与我的域模型中 Person 实体的 FirstName 属性相关。然而，FirstName 属性可能在该屏幕上表示为文本框。

同时，可以进行物理数据库设计。这将产生一个类或 ER 图，可追溯回域模型。最终，您可能会发现您的某些屏幕属性或活动建模引用了属于物理数据库模型的一部分而在域模型中不存在的事物。可以将屏幕“PersonalName”属性与 People 模式中 Person 表中计算的 PersonalName 列相关联。

我用于这类事情的工具是Sparx Enterprise Architect。这是一个很棒的工具，甚至可以在专业版中完成所有这些以及更多工作。

说实话，我还不得不说，我主要是自己建模——我还没有参与过一个模型、代码和数据库由不同的人开发的项目。如果有人告诉我上述内容在“现实生活”中行不通，我可能会被迫相信他们。

于 2009-04-16T23:05:51.993 回答
1

我不确定我是否清楚地理解了你的问题，但我会尝试根据一些合理的假设做出回应......

本质上，我的建议与John Saunders已经建议的相同：考虑使用 UML 以及一个好的 UML 工具。但我想补充几点在您的具体情况下可能很重要。

首先，我不认为UML“过于以代码为中心”。相反，它可以用来对软件系统的几乎任何方面进行建模，几乎可以在任何抽象级别进行建模。借助手头的好工具（如 Sparx EA），UML 的美妙之处在于您实际上确实获得了一个明确定义的模型（而不仅仅是一组未连接的绘图/图表）。结果，即使该工具本身没有为您提供您正在寻找的功能（例如从数据库到用例的可追溯性）......好吧，至少您可以选择自动化（或至少半自动化）自己的任务：例如，您可以将您的 UML 模型导出到 XMI（标准！），然后从那里导出您需要的任何可追溯性相关信息（例如，使用 XSL 或任何支持 XML 的库，用于您最喜欢的编程/脚本语言） .

顺便说一句，说到 Sparx EA……我还不知道它的所有功能，但它有这么多，如果它允许你选择一个类（甚至是一个类的属性）并显示，我不会感到惊讶您以某种方式依赖于它的其他模型元素。你可能想看看这个。

说了这么多，我确实理解您可能对 UML 至少有以下两个重要的担忧：

  1. 似乎需要太多的建模细节才能获得您想要的东西。
  2. 作为任何“通用工具”，它可能大大不如您已经使用的专业建模工具。

关于问题 #1：同样，手头有一个好的 UML 工具，你可以做尽可能多的快捷方式。例如，您可以只关注用例中涉及的类，而不是为用例构建一个非常详细和准确的活动模型（足以使跟踪类回到用例）。当然，这同样适用于 UI。

关于问题 #2：我不知道您现在使用什么工具来建模用例、UI 和 DB 模式。因此，从理论上讲，它们可能都比 UML 优越，以至于您不想放弃它们中的任何一个来换取更容易的可追溯性。但是，有些事情告诉我，您的数据库建模工具（具有代码生成功能）可能是唯一真正不可或缺的工具。如果是这种情况，那么我仍然建议考虑使用 UML：您只是不要建模到 DB 模式级别并在域模型级别“停止”（即使您的应用程序中没有它！）。那时，UML 工具将为您提供从域模型元素（实体、它们的属性和它们的关系）到用例和 UI 元素的可追溯性，域模型和数据库模式之间的映射可能会“悬而未决”，因为在绝大多数情况下，它们应该足够简单，无需绘制任何东西即可跟踪。这可能不会给你 100% 的你想要的东西，但它可以给你 80% 的东西，足以缓解你的大多数问题。

底线：如果您使用三种不同的工具/技术来对系统的三个不同方面进行建模……那么，很明显，这三个方面之间的任何可追溯性仍然受这三个工具的支配：您只能自动化这些工具允许（这可能意味着您将被困在大量繁重的手动任务中）。到今天为止，UML 似乎是唯一一个定义明确且得到广泛支持的“通用语言”，它可以帮助您连接您的模型，并可以使您的大部分分析活动实现自动化。只需确保将 UML“绘图工具”（如大多数 Visio 插件和模板）与真正的 UML 建模工具（如 Sparx EA 和其他一堆）区分开来。

于 2009-05-24T22:51:36.377 回答
0

您的用例是一个很好的起点。

  • 将您的用例转换为可执行的测试代码。此测试代码需要验证结果返回值是否符合您的用例要求。

  • 您可以识别和测试的工作部分越小，您构建应用程序的能力就越强。

  • 这意味着您的用例与大部分数据库和 GUI 的交互将更容易理解。

通过对不同层进行完整的前期设计，很难锁定复杂项目中的架构或业务逻辑相互作用。只有当您达到实施要求时，才能真正了解什么能够满足您的要求。

作为开发人员，请找到可以帮助您以最佳方式完成工作的技术、工具和流程。不要根据它们的来源来判断这些。判断他们在使您成为可能的最佳开发人员方面的价值。

敏捷世界中的一些项目无疑对我的工作质量和生产力产生了很大影响。这不需要扔掉苹果车，也不需要让经验丰富的瀑布团队陷入混乱。

于 2009-04-16T22:17:48.180 回答
-1

数据库应该为您的问题域建模。它应该对它进行足够完整的建模，以便您可以从中提取解决方案——真理。糟糕的设计本质上是对数据库“撒谎”（允许无效数据或关系的可能性），当您对数据库“撒谎”时，当您向它提问时，它也会对您“撒谎”。

简单的示例是建模多对多关系，其中关系只能是一对多，或者假设值不能为空，或者将外键视为属性。其中许多可以通过适当的规范化来避免，这需要您明确找出什么是密钥，什么不是。

通过在模型中“使非法状态不可表示”，您可以避免编写“防御性”代码来检查不可能或验证关系是否可能，因为由于表结构或声明性检查约束，不可能的事情变得不可表示。

这降低了编写代码的成本，因为您可以将大部分精力集中在需要做的事情上，而不是防范不可能的事情。

于 2009-04-16T22:30:29.270 回答