求助 这个活动图这样画可以吗？

用例描述：部门管理人员启动部门计划操作，填写培训计划，管理人员审核，审核通过后的计划记录可进行状态设置（包括待定计划、列于计划、允许报名、停止报名、培训结束、中途取消）。

有劳各位帮小女子看看 这个活动图这样画可以吗？

事件好多啊
比以前我们项目的复杂多
不过差着不是很多

系统那层有点画蛇

图怎么画都可以，也没有好坏的区别，只有对你合适不合适的区别。
这里其实有个问题，我们为什么要画活动图？还有就是活动图表达了些说明什么内容更加合适。
建议看看《UML Distilled》，你就不会有这么多烦恼了。
上面抛出异常的爱说的不错，实际上很少有把业务概念和软件概念画在一起的人，大多数人都不习惯这样的图。

我来做结论吧。
在这里出现系统这个角色是不合适的。你只要单纯的捕获业务用例就可以了。

错误，业务用例是应该在这之前就捕获了得，在这里活动图只能是来验证你的判断是否正确，并且理解业务用例的具体内容。这个错误是根本性的内在逻辑混乱造成的，其后果可能会造成业务用例的循环构成，从而导致业务规则的内在混乱。

系统不放在里面时
就成为工作流程图了

PS:我认为所有的图的东西都不应在太复杂(包含太多的东西.)

谢谢各位，我说明一下： 这个活动图是我用来在需求分析阶段 细化用例的
不想文本描述用例了，就用活动图画的。

我的系统设计与实现大概过程是：
需求分析：系统功能需求、用例建模、用例细化
领域分析：实体类、控制类、边界类、顺序图描述
系统总体设计：体系结构（Struts+ Hibernate）数据库设计
系统详细设计与实现：领域分析的类转化为详细设计的类，顺序图、分层实现代码。

这样可以吗？

还有就是你们说的业务概念和软件概念不要画在一起，意思是应该怎么画呢？不涉及系统，只是把业务流程画出来么？

在用例描述中，不是主事件流中也要写“系统显示****页面。”之类的么？可以不用文本描述用例，采用活动图，那不是也就是应该画系统吗？

请教。：）

需求不要写入实现方式(那是设计的活)
只把日常的流程写出来,并把他们的想要功能备注上就差不多了...



系统显示什么那是详设的活...你先给干了?只能作为功能备注写上