1,265
社区成员
发帖
与我相关
我的任务
分享mfc中的文档视图结构如何适应Rup中的 boundary control entity？
Rational unified process 中分析类的时候是按着 boundary，control，entity几种类型组织的，但是mfc有自己的文档视图结构，我感觉boundary应该对应视图，control和entity对应文档，不知道对不对，大家有什么看法？
...全文
请发表友善的回复…
发表回复
whwjn 2005-05-13
- 打赏
- 举报
mark
caosheng 2004-12-22
- 打赏
- 举报
非常感谢 tianxinet(越来越胖的猴子）你的解释，我有点明白了。
再次对你表示感谢！
再次对你表示感谢！
tianxinet 2004-12-21
- 打赏
- 举报
解释问题前先说一下基本原则：
分析类不是具体的类，是抽象的类，是一个较高的概念化层次上的说法。（不是指abstract class这种在程序代码中存在的类，而是指概念上的类）
分析类（boundary，control，entity）不能对应具体类或子系统，只能对应类或子系统的抽象！所以“boundary应该对应视图”这样的说法是错误的，或者说是不准确的。（有点咬文嚼字？呵呵，不过，基本概念还是说清楚些好）
下面解释一下：
分析类：是对系统中一个或几个类、一个或几个子系统的抽象。 --注意这里着重的“抽象”
boundary（边界类）：表达系统和用户（或外部系统）之间的交互。 --注意这里的“系统”外部，一定要界定你的系统边界。
边界类可以代表程序窗口、通讯接口、终端、API等和用户或外部系统交互的部分的抽象。（还是抽象，而不是具体类）
所以，可以说“boundary能够用来表达对应视图的‘抽象’”。
entity（实体类）：从现实世界转化来的具体存在的东东的抽象（如订单、文档等）。
所以，可以说“entity能够用来表达对应文档的‘抽象’”。
而control是不能用来表达文档的抽象的。
control（控制类）：对业务逻辑或算法逻辑的抽象。
所以，control不能表达文档。
分析类不是具体的类，是抽象的类，是一个较高的概念化层次上的说法。（不是指abstract class这种在程序代码中存在的类，而是指概念上的类）
分析类（boundary，control，entity）不能对应具体类或子系统，只能对应类或子系统的抽象！所以“boundary应该对应视图”这样的说法是错误的，或者说是不准确的。（有点咬文嚼字？呵呵，不过，基本概念还是说清楚些好）
下面解释一下：
分析类：是对系统中一个或几个类、一个或几个子系统的抽象。 --注意这里着重的“抽象”
boundary（边界类）：表达系统和用户（或外部系统）之间的交互。 --注意这里的“系统”外部，一定要界定你的系统边界。
边界类可以代表程序窗口、通讯接口、终端、API等和用户或外部系统交互的部分的抽象。（还是抽象，而不是具体类）
所以，可以说“boundary能够用来表达对应视图的‘抽象’”。
entity（实体类）：从现实世界转化来的具体存在的东东的抽象（如订单、文档等）。
所以，可以说“entity能够用来表达对应文档的‘抽象’”。
而control是不能用来表达文档的抽象的。
control（控制类）：对业务逻辑或算法逻辑的抽象。
所以，control不能表达文档。
