设计项目初始类图的常用做法是什么？

Question

我目前正在参加一个课程，介绍项目规划。主要是关于如何绘制UML图（blegh），但也有一些其他主题。

有一部分特别让我烦恼。在这个过程中，他们描述了从一组需求到一个初始类图的方法，但是关于该方法的一切都给了我这种感觉，它绝对不是要走的路。在继续之前，让我先举一个例子。

让我们考虑一个管理温室公司的系统。该公司有多个温室，每个员工都分配到他/她自己的温室。温室有一个位置和一种植物种植在那里。员工有姓名和电话号码。

下面是根据课程的方法的类图是什么样子：

对我来说，这看起来像适合代码数据库布局。当我设计一个程序时，我试图找出主要的抽象。像所有与数据库交互的代码或负责GUI的代码都是系统的不同部分。那将是我认为是最初的类图。

我简直无法想象这是开始设计项目体系结构的常用方法。这些课程看起来很丑陋，因为如果你拿一个稍微大一点的例子，这些课程将会充满责任。对我来说，他们看起来像数据对象具有他们不应该拥有的功能。它并没有给我提供关于如何从这里继续并获得一般架构的线索。关于它的一切似乎已经过时。

所有我想知道的是，如果有人在那里可以告诉我，这是一种常见方式，因为我忽略了原因在纸上获得头等图。

Answer 1

我会说从一个没有实现约束的逻辑模型开始是合理的。该逻辑模型不一定涉及物理实现细节（例如是否使用数据库，什么类型的数据库，操作系统/用户界面的选择等），因此仅代表“真实”的业务领域对象和过程。这个简单的例子与潜在的数据库实现的相似性应该不会令人意外。

通过理解您的业务领域（通过您开始构建的逻辑模型），您将能够更好地确定哪些架构模式适合，需要构建哪些屏幕以及数据库元素来设计。可能的话，在这个阶段会有另一部分课程能够帮助你。

实际上，您经常会知道您打算实施使用MVC和后端数据库的基于Web的应用程序，并且可能会考虑与业务项目并行建模实现类。因为你的课程使用强调逻辑阶段和物理阶段区分的方法听起来不合理。

Answer 2

当我去设计一个程序，我试图找出主要 抽象

同样的原则在UML为好。您表示抽象概念及其关系，并且由于现有的Visual Tools，您可以向利益相关者进行系统演示，甚至可以从设计中生成自动存根。