[全程建模]用例的子流和分析类的关系
北京-FireSpider 男 14:48:17
请教青润老师：一个用例对应一个分析类吗？
北京-FireSpider 男 14:49:28
我的表述可能有点问题：就是一个用例对应一个Boundary类，一个Control类，一个Entity类？
青润 14:50:47
一般来说一个用例对应一组分析类，包括一个边界类，一个控制类，一个实体类。
但是如果这个用例涉及到与多个用例的交互，那这个用例的分析模型图上还应该有这几个交互用例的分析类。
极特殊的情况下，有可能有几个实体分析类，或者几个边界分析类，但是控制分析类，一般就一个。
北京-FireSpider 男 14:51:44
哦，所说的涉及是引用还是包含？
青润 14:52:24
include，extend，communicate等关系都会有可能。
只要两者之间有数据交互或者方法的接口调用，都需要。
北京-FireSpider 男 14:52:53
比如书中"合同管理"用例，它包含几个“子用例”：合同付款、增加付款明细、修改付款明细、删除付款明细，是不是可以认为是子用例？
青润 14:53:32
一般来说不是子用例，这是子流，书中应该写的很清楚了。
一个uc可以有多个子流和分支流。
北京-FireSpider 男 14:53:56
嗯，是用子流描述的。但是是不是也可以认为是用例呢？
青润 14:54:07
不可以。
子流就是子流。
如果一个uc较大，各个子流可以有自己对应的分析类出现。
北京-FireSpider 男 14:55:02
哦
北京-FireSpider 男 15:19:22
如果某些用例不需要与数据库交互还需要控制类和实体类吗？比如：上传文件到FTP文件服务器。
青润 15:23:27
那你上传到ftp上的文件不需要管理么？
至少也要记录一下位置和上传文件大小和名字吧？否则，中毒了怎么办？被人利用了怎么办？
青润 15:24:37
所有的用例都必然会有数据交互，这是绝对不可避免的，否则，就是文件型数据库自己进行控制，那也是数据库——早期我们经常如此做。
北京-FireSpider 男 15:24:44
每次从FTP服务器读取文件列表，现实在界面上供用户操作。上传，下载，删除，重命名都直接在FTP服务器上进行。
青润(3291191) 15:25:07
那也必须对这些文件进行管理。否则，就至少会有安全隐患。
北京-FireSpider 男 15:25:17
哦
北京-FireSpider 男 15:26:21
也就是说，必须在数据库里做相应的记录，是吧？
青润 15:26:43
是的。
