系统分析和设计过程中的类图

Question

有人能解释一下分析和设计过程中类图的区别吗？

到目前为止，我理解设计的类图将是真实的类图，包含所有方法和属性（准备成为代码），但分析呢？我是否必须为每个序列图做一个类图？我是否必须在设计阶段添加方法和属性？还是只有连接？

Answer 1

随着对系统的理解的增加，迭代地生成和改进UML类模型。虽然不同的图表可能概述了该模型的不同方面和细节水平，但您的系统只有一种模型。

通常，您将根据要求（例如用例，用户故事，工作说明，用户访谈等）从domain model开始：

• 首要任务是获得概述。因此，第一个草图将识别域类以及它们如何相互关联。
• 然后，您将通过在图中概述对于理解域必不可少的关键属性和方法来丰富这种初步理解。

然后，在设计解决方案时，您将使用更详细的设计图丰富模型。因此，您将添加实现所需的任何类（例如，用户界面类，应用程序控制器，持久层等）。

设计图用于获得对开发团队内软件结构的共同理解。因此，它们应该易于理解（重点关注重要方面，并且不一定会混杂太多细节，无论如何必须在代码中实现，如果没有大量分析师来更新模型，很快就会过时） 。

如果您使用能够生成代码的UML工具，或者您在合同中有义务以UML形式提供所有详细信息，那么您将使用完全详细的implementation diagram进一步优化模型。注意：对于学者的工作，老师经常要求设计图，但实际上需要一个实施图。

Answer 2

我们在面向对象方法中有三种主要的类图。

1. 需求中的类图（域建模）
2. 分析类图
3. 设计类图

这些类图的主要区别在于它们的抽象。

1. 在Domain Modeling中，我们使用Class Diagrams。但是，我们不对类使用任何继承或任何接口或任何预成型分析。我们只写了很少的类属性（大约3个属性）。我们不写任何类的方法。为什么？因为抽象。域建模的主要目标是对域进行建模。并检测哪些类应该在系统的问题域中。
2. 在分析建模中，我们使用类图。分析中的类比Domain中的类更详细。但这不是最终的规范。

在Analysis中，我们确定分析类。我们可以在它们之间使用继承。我们可以详细编写它们的属性和方法。但是，这个阶段由系统分析师完成。 （不是系统设计师或程序员）。他们的专业是了解商业逻辑和软件技术。因此，他们可以编写比Domain更详细的分析类。但是，他们不能像系统设计师那样写得非常详细。

另一方面，我们可以使用一些分析模式来确定我们的分析类。例如，RUP引入了边界/控制/实体模式。如果我们决定使用现有的分析模式，我们可以使用模式文档中存在的指南。

关于类抽象的边界/控制/实体的指南在this reference中。在这种模式中，我们应该只编写Entity类的属性，只编写Control类的方法，并为Boundary类编写属性和方法。

但是，在我的想法中，我们可以遵循指南与否。我们可以为分析类编写更多属性和方法。怎么了？如果我们的系统分析师尝试编写更详细的属性或方法，那么会发生什么：

我认为1）我们的系统分析师不是系统分析师。也许系统设计师。 2）我们不需要他们的细节。分析阶段只是耗费时间。 3）只有我们的分析和设计团队相同，或者我们将分析和设计（如敏捷方法论）结合起来，分析中的细节才是合乎逻辑且可用的。

3. 在设计建模中，我们使用类图，这种类图应该是最终规范，并且应该包含所有属性和方法。这个类不是概念性的。我们可以使用所有OOD技术，设计模式等。