软件工程 |领域建模

领域建模被理解为抽象建模。站点模型可以是在缺陷域中显示的想法或对象的说明。它还捕获了这些对象之间的明显关系。此类抽象对象区域的样本有 Book、BookRegister、成员寄存器、LibraryMember 等。

建议的策略是快速生成一个粗略的抽象模型，只要压力是在需求中找到表达的明显想法，同时推迟深入调查。后来在整个事件方法中，抽象模型被逐步细化和扩展。整个领域分析中已知的 3 种对象。

在整个领域分析中已知的对象分为 3 类：

1. 边界对象
2. 控制器对象
3. 实体对象

边界和控制器对象在就业案例图中始终是已知的，而实体对象的识别需要应用。因此，领域建模活动的关键是发现实体模型。

The purpose of various sorts of objects known throughout domain analysis and the way these objects move among one another.

在整个领域分析中已知的不同样式的对象及其关系单元的区域如下：

• 边界对象：
  边界对象区域与参与者移动的对象区域相结合。这些包括屏幕、菜单、表单、对话框等。边界对象区域单元主要负责用户交互。因此，它们通常不包含任何过程逻辑。但是，它们将负责确认输入、格式化、输出等。边界对象早先被称为是因为接口对象。然而，术语接口类别正被用于Java、COM/DCOM 和 UML，其含义完全不同。最初识别边界类别的建议是为每个参与者/用例尝试勾勒出一个边界类别。

• 实体对象：
  这些通常包含信息表和文件等信息，这些信息需要比用例执行更长时间，例如 Book、BookRegister、LibraryMember 等。几个实体对象区域单元“哑服务器”。他们通常负责存储信息、赢得信息以及执行一些通常不会修改的基本操作方式。

• 控制器对象：
  控制器对象协调实体对象集合的活动并与边界对象交互以产生系统的一般行为。分配给与特定用例的信念密切相关的控制器对象区域单元的职责。控制器对象有效地将边界对象和实体对象彼此分离，从而创建能够容忍计算机程序和过程逻辑变化的系统。控制器对象体现了大多数提交应用案例实现的逻辑（此逻辑可能会不时修改）。控制器对象与边界和实体对象的典型交互如下图所示（图） 通常，每个用例都是一个控制器对象的完全牺牲品。然而，一些用例是完整的，而不是牺牲任何控制器对象，即仅通过边界和实体对象。这通常适用于赢得对信息保持的一些简单操作的用例。例如，让我们考虑图书馆数据系统 (LIS) 的“查询图书可用性”用例。就业案例的实现涉及仅将给定的书名与目录中提供的书籍进行匹配。其他复杂的用例可能需要相当多的控制器对象来理解就业案例。一个花哨的用例将有许多控制器对象，如组操作管理器、资源安排器、错误处理程序。在一个用例将有相当一个控制器对象的情况下，还有另一种情况。一般情况下，就业案件需要控制者对象经过多种状态的过渡。

  在这种情况下，可能需要为就业案例的每次执行创建一个控制器对象。