追踪设计 - 屏幕到数据库的可追踪性
这与：
但我的问题更多的是关于建模和工件，而不是关于正确的设计方法。 我试图找出哪种设计工件最能阐明功能（用例）、屏幕和数据库元素（尤其是表和列）之间的联系。 UML 非常以代码为中心。 数据库模型非常以数据库为中心。 而且屏幕设计都是以 UI 为中心的！
事情是这样的……我的团队正在开发该产品的第一个版本。 我们使用用例，然后进行屏幕设计，而数据库设计在某种程度上与两者隔离。 错误的一个关键领域是用例及其随附屏幕和数据库之间缺乏可追溯性。 在我们的产品中，用例和数据库元素之间存在高度重叠。 许多用例涉及超过 75% 的数据库基础设施。 因此，我们在数据库设计领域存在很大的争议，并且一个小的数据库更改很容易破坏较低级别的业务逻辑。
对于我们的下一个版本，我希望开发人员和我们的 DBA 能够真正清楚地了解每个功能涉及数据库的哪些部分。 用例/屏幕设计方法效果很好，所以我们保留了它......技巧是将每个用例和屏幕链接到数据库模型，这样关系就非常明显并且很难忘记。
在较小的项目中（我们只有 10 人，但我经常在 3 人或更少的团队中工作），我创建了自己的自定义图表来显示这部分设计。 有点像屏幕、UML 和数据库表的融合，在 Visio 中完成，没有与实际代码或 SQL 的链接。 我不确定它是否适用于更大的团队，因为它需要高度手动才能保持最新状态，并且它不会像我们的数据库建模工具那样自动生成代码。
有什么建议吗？ 是否有一个普遍接受的机制？
仅供参考 - 我们是瀑布式的，这一点不会很快改变。 我们确实喜欢工件......说“转向敏捷”对于我们团队来说并不是一个可行的解决方案。
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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我无法从你的问题中看出你的用例有多详细。 我的印象是它们可能是高级用例，没有分解为详细的用例（可能通过包含或扩展关系。
无论如何，我更喜欢从需求开始，跟踪它们到用例。当我编写用例和用例图时，我也在创建一个域模型（一个高级类图）。与利益相关者讨论（“我做对了吗？”）
完成用例和域模型后，就可以开始进行屏幕设计，如果屏幕之间存在复杂的交互，也可能开始进行活动模型。我会将屏幕视为具有 UI 的类 - 屏幕可能具有 FirstName 属性，我会注意到该属性与我的域模型中的 Person 实体的 FirstName 属性相关，但 FirstName 属性可能会在上表示。 。
同时，可以进行物理数据库设计，这将生成一个类或 ER 图，并可追溯到域模型 最终，您可能会发现某些屏幕属性或活动建模引用了物理数据库模型的一部分，但域模型中不存在。 可以将屏幕“PersonalName”属性与人员架构中的 Person 表中计算出的 PersonalName 列相关联。
我用于此类事情的工具是 Sparx Enterprise Architect。 它是一个很棒的工具，甚至可以在专业版中完成所有这些工作以及更多功能。
说实话，我还必须说，我主要是自己建模——我还没有参与过模型、代码和数据库由不同的人开发的项目。 如果有人告诉我上述内容在“现实生活”中行不通，我可能会被迫相信他们。
I can't tell from your question how detailed your use cases are. I get the impression that they may be high-level use cases, not broken down into detailed uses cases (perhaps through include or extend relationships.
In any case, I prefer to start with Requirements, and trace them to use cases. While I'm writing the use cases and the use case diagrams, I'm also creating a domain model (a high-level class diagram). This is mostly to give me something to discuss with stakeholders ("did I get that right?").
When the use cases and domain model are finished, it's possible to begin to work on screen design, and possibly also for an activity model, if there are complex interactions between screens. I would treat the screens as though they were classes with UI - a screen might have a FirstName attribute, which I'd note as being related to the FirstName attribute of the Person entity in my domain model. Yet the FirstName attribute might be represented on that screen as a text box.
At the same time, physical database design can occur. This would produce a class or ER diagram, with traceability back to the domain model. Eventually, you might find that some of your screen attributes or activity modeling refer to things that are part of the physical database model that are not present in the domain model. It's ok to relate a screen "PersonalName" attribute to the computed PersonalName column in the Person table in the People schema.
The tool I use for this sort of thing is Sparx Enterprise Architect. It's a great tool, and can do all of this and more, even in the Professional edition.
I also have to say for the sake of Truth that I mostly model on my own - I haven't yet worked on a project where the model, code and database were being developed by separate people. If someone told me that the above wouldn't work in "real life", I might be forced to believe them.
我不确定我是否清楚地理解你的问题，但我会尝试根据一些合理的假设做出回应...
本质上，我的建议与 John Saunders 已经建议的相同：考虑使用 UML以及一个好的 UML 工具。 但我想补充几点对于您的具体情况可能很重要的几点。
首先也是最重要的，我不认为 UML“过于以代码为中心”。 相反，它可以用来对软件系统的几乎任何方面、几乎任何抽象级别进行建模。 有了手头的好工具（如 Sparx EA），UML 的美妙之处在于您实际上确实在幕后获得了一个定义明确的模型（而不是一组未连接的绘图/图表）。 因此，即使该工具本身没有为您提供您正在寻找的功能（例如从数据库到用例的可追溯性）......好吧，至少您可以选择自动化（或至少半自动化）自己完成任务：例如，您可以将 UML 模型导出到 XMI（标准！），然后从那里导出您需要的任何可追溯性相关信息（例如，针对您最喜欢的编程/脚本语言使用 XSL 或任何 XML 感知库） 。 我并不是说这很容易做到（特别是如果您希望在单个数据库列 8- 的级别上进行跟踪），但这是可能的，并且如果它必须沿着该项目。
顺便说一句，说到 Sparx EA...我还不知道它的所有功能，但它有很多功能，如果它允许您选择一个类（甚至类的属性）并显示，我不会感到惊讶以某种方式依赖于它的其他模型元素。 您可能想检查一下。
说了这么多，我确实理解您可能至少对 UML 有以下两个重要的担忧：
关于问题 #1：同样，如果手头有一个好的 UML 工具，您可能可以根据需要使用任意多的快捷方式。 例如，您可以只关注用例中涉及的类（足以将类跟踪回用例），而不是为用例构建非常详细且准确的活动模型。 当然，这同样适用于 UI。
关于问题#2：我不知道您现在使用什么确切的工具来建模用例、UI 和数据库模式。 因此，从理论上讲，它们可能都比 UML 更优越，以至于您不想放弃它们中的任何一个来换取更容易的可追溯性。 然而，有件事告诉我，您的数据库建模工具（及其代码生成功能）可能是唯一真正不可或缺的工具。 如果是这种情况，那么我仍然建议考虑使用 UML：您只是不要建模到数据库模式级别并在域模型级别“停止”（即使您的应用程序中没有它！）。 那时，UML 工具将为您提供从域模型元素（实体、它们的属性及其关系）到用例和 UI 元素的可追溯性，并且域模型和数据库模式之间的映射可能会“悬而未决”因为，在绝大多数情况下，它们应该足够简单，无需绘制任何内容即可进行跟踪。 这可能无法为您提供 100% 的想要的结果，但它可以为您提供 80% 的结果，足以缓解您的大多数问题。
底线：如果您使用三种不同的工具/技术来对系统的三个不同方面进行建模...那么，很明显，这三个方面之间的任何可追溯性仍然受这三种工具的支配：您只能实现尽可能多的自动化这些工具允许（这可能意味着您将不得不执行大量费力的手动任务）。 截至今天，UML 似乎是唯一定义明确且得到广泛支持的“通用语言”，它可以帮助您连接模型并实现大部分分析活动的自动化。 只要确保将 UML“绘图工具”（如大多数 Visio 附加组件和模板）与真正的 UML 建模工具（如 Sparx EA 和其他一些工具）区分开来即可。
I am not sure I understand your question clearly, but I'll try to respond based on some reasonable assumptions...
Essentially, my recommendation is the same as what John Saunders already suggested: to consider using UML along with a good UML tool. But I would like to add a few points that might be important in your specific situation.
First and foremost, I don't think that UML is "too code-centric". To the contrary, it can be used to model pretty much any aspect of a software system, almost at any level of abstraction. With a good tool at hand (like Sparx EA), the beauty of UML is that you actually do get a well-defined model under the hood (as opposed to just a set of unconnected drawings/charts). As a result, even if the tool itself does not give you a feature that you are looking for (like traceability from DB to use cases)... well, at least you have an option to automate (or at least semi-automate) the task yourself: for example, you can export your UML model into an XMI (standard!) and then derive whatever traceability-related info you need from there (e.g. using XSL or any XML-aware library for your favorite programming/scripting language). I am not saying that it would be easy to do (especially if you want traceability on the level of individual DB columns 8-), but it's possible and it is very likely to beat any manual method if it has to scale along the size of the project.
BTW, speaking of Sparx EA... I don't know all of its capabilities yet, but it has so many that I would not be surprized if it allowed you to select a class (or even an attribute of a class) and show you other model elements that depend on it in some way. You might want to check this out.
Having said all that, I do understand that you may have at least the following two important concerns about UML:
Regarding issue #1: Again, with a good UML tool at hand, you might be able to do as many shortcuts as you want. For example, instead of building a very detailed and accurate activity model for a use case, you could focus just on classes involved in the use case (just enough to enable tracking classes back to use cases). The same applies to UI, of course.
Regarding issue #2: I don't know what exact tools do you use now to model use cases, UI, and DB schema. So, theoretically it is possible that they are all so superior to UML that you wouldn't want to give any of them up in exchange of easier traceability. However, something tells me that your DB modeling tool (with its code-generating capabilities) might be the only one that is truly indispensable. If that's the case, then I would still recommend to consider using UML: you just do not model down to DB schema level and "stop" at the level of domain model (even if you do not have it in your application!). At that point, the UML tool would give you traceability from domain model elements (entities, their attributes, and their relationships) back to use cases and UI elements, and mappings between your domain model and DB schema could be left "in the air" because, in the vast majority of cases, they should be simple enough to track without drawing anything. This might not give you 100% of what you want, but it could give you 80% that would be sufficient to mitigate most of you problems.
The bottom line: if you are using three different tools/technologies to model three different aspects of your system... well, it's obvious that any traceability between those three aspects remains at mercy of those three tools: you could automate only as much as those tools allow (which probably means that you are going to be stuck with a lot of laborous manual tasks to do). As of today, UML appears the only well-defined and widely supported "lingua franca" that could help you to connect your models and could enable automation of substantial part of your analytical activities. Just make sure you distinguish UML "just-drawing tools" (like most of Visio add-ons and stencils) from true UML modeling tools (like Sparx EA and a bunch of others).
您的用例是一个很好的起点。
将您的用例转换为
可执行的测试代码。 这个测试代码
需要验证结果
返回值根据
您的用例的要求。
你的工作部分越小
可以识别和测试，越多
强大的你将能够构建
您的应用程序。
这意味着
您的用例有很大一部分
您的数据库和 GUI 的
更容易理解。
通过不同层的完整前期设计来锁定复杂项目中的架构或业务逻辑相互作用是很困难的。 只有当您真正实现了您的需求时，人们才会真正了解什么能够满足您的需求。
作为开发人员，找到可以帮助您以最佳方式完成工作的技术、工具和流程。 不要根据它们的起源来判断它们。 根据它们在使您成为最佳开发人员方面的价值来判断它们。
敏捷世界中的一些项目无疑对我的工作质量和生产力产生了很大的影响。 这不需要扔掉苹果车，也不需要让经验丰富的瀑布团队陷入混乱。
Your use cases is a good place to start from.
Convert your use cases into
executable test code. This test code
needs to verify that the resultant
return values are according to the
requirements of your use cases.
The smaller the parts of the work you
can identify and test, the more
robust you will be able to build
your application.
This means that the interaction of
your use cases with a large part
of your database and the GUI, will
be simpler to understand.
It's hard to lock-down the architecture or business logic interplay in complex projects with complete upfront design of the different layers. One truly learns about what will be able to facilitate your requirements only as you get to the point of implementing them.
As a developer, find the techniques, tools and processes that help you do your job in the best way possible. Don't judge these on their origin. Judge them on their value in making you the best developer possible.
Some items from the agile world has certainly made a big difference to the quality and productivity of my work. This doesn't require throwing out the apple cart and putting an experienced waterfall team into disarray.
数据库应该对您的问题域进行建模。 它应该足够完整地建模，以便您可以从中提取解决方案 - 真相。 糟糕的设计本质上是对数据库“撒谎”（允许出现无效数据或关系的可能性），当你对数据库“撒谎”时，当你向它提问时，它也会对你“撒谎”。
简单的示例是建模多对多关系，其中关系只能是一对多，或者假设值不能为空，或者将外键视为属性。 其中许多问题可以通过适当的规范化来避免，这要求您明确找出什么是键，什么不是。
通过在模型中“使非法状态不可表示”，您可以避免编写“防御性”代码来检查不可能的情况或验证关系是否可能，因为由于表结构或声明性检查约束，不可能的事情变得不可表示。
这降低了编写代码的成本，因为您可以将大部分精力集中在需要执行的操作上，而不是防范不可能的事情。
The database should model your Problem Domain. It should model it completely enough so that you can extract solutions -- truths -- from it. Bad design is essentially "lying" to the database (allowing the possibility of invalid data or relationships), and when you "lie" to your database, it'll "lie" to you when you ask it questions.
Simple examples are modeling many-to-many relation where a relation can only be one-to-many, or assuming values can't be null, or treating a foreign key as an attribute. Many of these can be avoided by proper normalization, which requires you to explicitly find out what is a key and what isn't.
By "making illegal states unrepresentable" in the model, you avoid having to write "defensive" code to check for the impossible or to validate that a relation is possible, as impossible things are made unrepresentable because of table structures or declarative check constraints.
This lowers the cost of writing your code, as you can concentrate for the most part, on what it needs to do, rather than guarding against the impossible.