在定义了UML用例之后对系统进行建模

Question

...接下来是什么？

在你定义了什么动作者做了什么动作后，你走哪条路？你对数据库建模还是你喜欢从类开始？

我认为更好的方法是从一个类似的建模图开始，重点关注对象之间的关系。 这已被证明是错误的，因为我在详述课程方面做得太深，即使系统“似乎有效”，当我进入数据库建模时，一切都不适合自己在上一阶段选择的位置。

我读过关于人们应该将应用程序逻辑放入数据库并利用其检索数据的速度，反对在查询内存中构建大型对象并提供底层数据库抽象的人。 我一直认为数据库是存在我的数据，并提供一个快速的方式来访问它。但也许我错了，我的意思是，我真的必须建立一个数据库，其内部的逻辑是相同的，我会放在一组类上？数据库不是缺乏实现这一目标的工具吗？

我想我找不到合适的开始点，如果我选择从数据库开始，我发现很难不把它看作是“存储我的数据的地方，让我们做应用逻辑在更高层次上“的事情，如果我从课程开始，数据库最终看起来像是一个非自然的类表示，我觉得错过重要的东西的感觉，就像不把正确的目的分配给正确的工具。

你如何处理这个问题？ 当谈到决定是否开始建模数据库或类时，根据您的经验，已经证明什么样的方法会导致自然而清晰的实现？

在此先感谢

Answer 1

我已经使用Robustness Analysis成功了。

本文侧重于稳健性 分析，包括分析用例的 叙事文本和 识别第一猜测设定将参加每个 使用的情况下，那么这些 对象分成 对象三种类型：

1. 边界对象，演员用于与系统进行通信。
2. 实体对象，它们通常是来自域模型 （“驾驶设计： 问题域”，2001年1月）的对象。
3. 控制对象（即我们通常称之为控制器，因为他们往往 不是真正的对象），其 作为边界 对象和实体objects.Figure 1 之间的“胶水”示出了用于这三种类型的 的可视图标的物体。

实体对象是那些在数据库中（usuallly）结束/

在类和数据库，我会建议S.Lott's article on "The ORM Problem"之间的映射（他也是在计算器上

Answer 2

如果使用测试驱动开发，先写单元测试。 您的课程将按照您的要求进行概述。

您可以选择在没有数据库（模拟或存根对象）的情况下开发业务逻辑，或者在继续进行测试时开发数据库。

记住你的数据库和域模型不应该一个映射到另一个上。