我现在使用 NetBeans 作为我的首选 IDE,它有一个用于 UML 建模的插件。在类图中,有称为Boundary Class
、Control Class
和的模型元素Entity Class
。但是,我找不到它们的良好定义,但我确实在 UML Class Diagrams 上找到了这个站点。
6 回答
健壮性图是在用例之后和类图之前编写的。它们有助于识别用例步骤的角色。您可以使用它们来确保您的用例足够健壮,以代表您正在构建的系统的使用要求。
它们涉及:
- 演员
- 用例
- 实体
- 边界
- 控件
模型-视图-控制器模式用于用户界面,而实体-控制-边界模式 (ECB) 用于系统。如果有帮助,ECB 的以下方面可以比作 MVC 的抽象版本:
实体 (模型)
表示系统数据的对象,通常来自域模型。
边界 (视图/服务协作者)
与系统参与者(例如用户或外部服务)交互的对象。窗口、屏幕和菜单是与用户交互的边界示例。
控件 (controller)
在边界和实体之间进行调解的对象。它们充当边界元素和实体元素之间的粘合剂,实现管理各种元素及其交互所需的逻辑。重要的是要理解,您可能决定在设计中将控制器实现为对象以外的其他东西——例如,许多控制器足够简单,可以作为实体或边界类的方法来实现。
四个规则适用于他们的沟通:
- Actor 只能与边界对象对话。
- 边界对象只能与控制器和参与者对话。
- 实体对象只能与控制器对话。
- 控制器可以与边界对象和实体对象以及其他控制器对话,但不能与参与者对话
允许通讯:
Entity Boundary Control
Entity X X
Boundary X
Control X X X
通常与 OOAD 和业务建模一起使用/作为其一部分。Neil 的定义是正确的,但它与 MVC 基本相同,只是为了业务抽象而已。“好的总结”做得很好,所以我不会在这里复制它,因为它不是我的工作,更详细但符合尼尔的要点。
这些是分析中使用的类刻板印象。
边界类是系统边界的类——您或其他系统与之交互的类
实体类类是您的典型业务实体,如“人”和“银行账户”
控制类实现一些业务逻辑或其他
边界控制实体模式有两个版本:
- 旧结构,在 127 中描述(实体作为数据模型元素,控件作为函数,边界作为应用程序接口)
- 新对象模式
作为对象模式:
- 边界是“另一个世界”
- 任何内部逻辑中的控制(如 DDD 模式中的服务)
- 实体是对象的持久性服务(如 DDD 模式中的存储库)。
所有类都有操作(参见 Fowler 贫血域模型反模式)
它们都是 MVC 模式中的模型组件。规则:
- 只有 Boundary 为“另一个世界”提供服务
- Boundary 只能调用 Controll
- Control 可以调用任何人
- 实体不能呼叫任何人(!),只能被呼叫。
jz
实际上,稳健性图(或有时称为分析图)只是专门的类图。它们是 UML 的一部分,并且从一开始就是(参见 Jacobson 的书,统一软件开发过程 - “三个朋友”系列书籍的一部分)。上述书在第 183-185 页对这三个类有很好的定义。
作为记录,实体-边界-控制模式来自用例驱动的软件开发,并且比Scott Ambler仅重用该概念的健壮性图要古老得多。
该模式不是 UML 的一部分,但与它密切相关,因为它是由 Ivar Jacobson(他于 1992 年发起)、Grady Booch 和 Jim Rumbaugh 推动的,他们是 UML 的创始人......以及统一过程(UP , RUP)。在 UML 中,它和其他任何东西一样只是刻板印象。
维基百科解释得最好,但控制类对应于用例,边界类对应于用例和参与者之间的关联,实体对应于被识别为涉及用例的域对象。
大多数 UML 工具与预定义的 BCE 构造型一起使用的循环符号也来自 Jacobson。稳健性规则只是上述用例映射的转置。