uml - 系统分析和设计期间的类图

Question

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

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

Answer 1

The UML class model is produced and refined iteratively as the understanding of the system increases. There's only one model for your system, although different diagrams may outline different aspects and level of details of this model.

Typically you would start with the domain model based on the requirements (e.g. use cases, user stories, statement of work, user interviews, etc.):

• Top priority is to get an overview. So the first sketch would identify the domain classes and how they relate to each other.
• You would then enrich this initial understanding by outlining in the diagram the key properties and methods that are essential to the understanding of the domain.

You would then enrich the model with more detailed design diagrams as you design your solution. So you would add any classes required for the implementation (e.g.user interface classes, application controllers, persistence layers, etc.).

Design diagrams are used to get a shared understanding about the software structure within the development team. So they should be easy to understand (i.e.focus on important aspects and not necessarily be cluttered with too many details that would anyhow have to be implemented in code and quickly be outdated if you don't have an army of analysts to update the model).

If you'd use an UML tool able to generate code or if you are contractually obliged to provide all the details in UML form, you would further refine the model with a fully detailed implementation diagram. Attention: for scholar work it is frequent that the teacher asks for a design diagram but expects in reality an implementation diagram.

Answer 2

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

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

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

1. 在领域建模中，我们使用类图。但是，我们不使用任何继承或任何接口，或对类进行任何预分析。我们只写了这么少的类属性（大约 3 个属性）。我们不编写任何类的方法。为什么？因为抽象。领域建模的主要目标是对领域进行建模。并检测哪些类应该在系统的问题域中。

2. 在分析建模中，我们使用类图。分析中的类比领域中的类更详细。但这不是最终的规范。

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

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

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

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

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

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