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

Question

......下一步是什么？

在你定义了哪些演员做了什么动作之后，你走哪条路？您是建模数据库还是更喜欢从类开始？

我认为更好的方法是从类似类的建模图开始，专注于对象之间的关系。 事实证明这是错误的，因为我在细节方面做得太深了，即使系统“似乎工作”，当我进行数据库建模时，一切都不适合我在前一阶段选择的位置

我读到有人说人们应该将应用程序逻辑放入数据库并利用其检索数据的速度，而不是在内存中构建被查询的大对象并提供底层数据库的抽象。 我一直认为db存储我的数据并提供快速访问它的方法。但也许我错了，我的意思是，我是否真的需要构建一个数据库，该数据库内部存在我将放在一组类中的相同逻辑？数据库缺乏实现这一目标的工具吗？

我认为我没有确定从哪里开始的正确点，如果我选择从数据库开始，我发现很难不将其视为“存储我的数据的地方”，让我们做app逻辑在更高的层面上“事情，如果我从类开始，数据库最终看起来像一个不自然的类表示，我感到缺少一些重要的感觉，比如没有为正确的工具分配正确的目的。

你是如何处理的？ 在根据您的经验确定是否从建模数据库或类开始时，已经证明了哪种方法可以实现自然而干净的实现？

提前致谢

Answer 1

我使用稳健性分析取得了成功。

  

本文重点介绍稳健性   分析，涉及分析   用例叙述文本   识别第一组猜测   将参与每个对象的对象   用例，然后对这些进行分类   对象分为三种类型：

     

  
1. 边界对象，演员用于与系统通信。
  
2. 实体对象，通常是域模型中的对象   （“驾驶设计：主题”）的主题   问题域，“ 2001年1月）。
  
3. 控制对象（我们通常称之为控制器，因为它们   通常不是真正的对象），其中   用作“胶水”。在边界之间   对象和实体对象。图1   显示这三个的可视图标   对象类型。
  

实体对象（通常）最终出现在数据库/

中

关于类和数据库之间的映射，我建议 S.Lott关于“ORM问题”的文章（他也是StackOverflow的参与者

Answer 2

如果使用测试驱动开发，请先编写单元测试。 您的课程将在您出发时进行概述。

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

请记住，您的数据库和域模型不应该一对一地映射。