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

Question

我目前正在上一门课程，介绍项目规划。它主要是关于如何绘制UML图表（blegh），还有一些其他主题。

特别是有一部分让我烦恼。在课程中，他们描述了从一组需求到初始类图的方法，但是关于该方法的所有内容都让我觉得这绝对不是最佳选择。在继续之前，我先举一个例子。

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

根据课程方法，类图如下所示：

对我而言，这看起来像是适合代码的数据库布局。当我开始设计程序时，我尝试识别主要的抽象。像所有与数据库交互的代码或负责GUI的代码都是系统的不同部分。这将是我认为的初始类图。

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

所有我想知道是否有人在那里可以告诉我这是否是一种常见的方法来获取我在俯瞰的理由上的第一类图表。

Answer 1

我认为从一个没有实现约束的逻辑模型开始是合理的。该逻辑模型不一定涉及物理实现细节（例如，是否使用数据库，什么类型的数据库，OS / UI选择等），因此仅表示“真实的”业务域对象和过程。对于这个简单的例子，与潜在数据库实现的相似性不应该令人惊讶。

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

在实践中，您经常会知道您打算使用带有后端数据库的MVC来实现基于Web的应用程序，并且可能希望与您的业务项并行地对实现类进行建模。对于您的课程使用强调逻辑阶段和物理阶段之间区别的方法听起来并不合理。

Answer 2

  

当我开始设计一个程序时，我会尝试识别专业   抽象

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