[全程建模]用例的子流和分析类的关系

北京-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

是的。