有人能解释一下分析和设计过程中类图的区别吗？
到目前为止，我理解设计的类图将是真实的类图，包含所有方法和属性（准备成为代码），但分析呢？我是否必须为每个序列图做一个类图？我是否必须在设计阶段添加方法和属性？还是只有连接？
答案 0 :(得分：0)
随着对系统的理解的增加，迭代地生成和改进UML类模型。虽然不同的图表可能概述了该模型的不同方面和详细程度，但您的系统只有一种模型。
通常，您会根据要求（例如用例，用户案例，工作说明，用户访谈等）从 domain model 开始：
在设计解决方案时，您将使用更详细的设计图来丰富模型。因此，您将添加实现所需的任何类（例如，用户界面类，应用程序控制器，持久层等）。
设计图用于获得对开发团队内软件结构的共同理解。所以它们应该易于理解（重点关注重要方面，不一定会混杂太多细节，无论如何必须在代码中实现，如果你没有一大批分析师来更新，很快就会过时模型）。
如果您使用能够生成代码的UML工具，或者您有合同义务以UML形式提供所有详细信息，那么您将使用完全详细的implementation diagram进一步优化模型。注意：对于学者工作，老师经常要求设计图，但实际上需要一个实施图。
答案 1 :(得分：-1)
我们在面向对象方法中有三种主要的类图。
这些类图的主要区别在于抽象。
在域建模中，我们使用类图。 但是，我们不会对类使用任何继承或任何接口或任何预成型分析。我们只写了很少的类属性（大约3个属性）。我们不写任何课程方法。 为什么？因为抽象。域建模的主要目标是对域进行建模。并检测哪些类应该在系统的问题域中。
在分析建模中，我们使用类图。分析中的类比Domain中的类更详细。但这不是最终的规范。
在Analysis中，我们确定分析类。我们可以在它们之间使用继承。我们可以详细编写它们的属性和方法。 但，此阶段由系统分析师完成。 （不是系统设计师或程序员）。他们的专业是了解商业逻辑和软件技术。因此，他们可以编写比Domain更详细的分析类。但是，他们不能像系统设计师那样写得非常详细。
另一方面，我们可以使用一些分析模式来确定我们的分析类。例如，RUP引入了边界/控制/实体模式。如果我们决定使用现有的分析模式，我们可以使用模式文档中存在的指南。
关于类抽象的边界/控制/实体的准则在this reference中。在这种模式中，我们应该只编写Entity类的属性，只编写Control类的方法，并为Boundary类编写属性和方法。
然而，在我的想法中，我们可以遵循指南与否。我们可以为分析类编写更多属性和方法。 发生了什么？如果我们的系统分析师尝试编写更详细的属性或方法，那么会发生什么：
我认为 1）我们的系统分析师不是系统分析师。也许系统设计师。 2）我们不需要他们的详细信息。分析阶段只是耗费时间。 3） 仅如果我们的分析和设计团队相同，或者我们将分析和设计（如敏捷方法论）结合起来，Analysis中的细节可以合理且可用。