现正在开发一个国土房产局的办公自动化系统，公司已经有了一个后台系统，能够实现流程定制、表单定制和角色配置。
这种情况下是否需要绘制业务用例图。

 回复: 有强大的工作流定制功能后台系统的情况下是否有必要画业务用例图
　

---

刚刚因为要去吃饭，没有说清楚，现在接着说。
整个系统分为两部分，服务端的后台系统和客户端系统，前者负责审批流程定制（包括新增流程、流程节点调整、表单定制和角色管理等），该系统只安装在一台服务器上，用户是系统管理员，后者是业务办理人员使用的系统（包括收件、初审、复审、终审、缴费、发件和存档），计划用B/S结构。
以下房地产开发商向国土房产局申请《商品房预售许可证》这个具体业务来说明：
房地产开发商完成了楼房的主体框架后，带着《土地使用证》等材料到国土房产局，填写《许可证申请表》，窗口收件员，将这些表格内容录入电脑，接下来是经办人员初审，科长复审、主管局长终审，财务收费，打证室打证，发件窗口发证，档案室存档。局里类似这样的业务有上百个。
后台系统能够实现新增业务、调整业务流程顺序、表单定制等功能。
这种情况下是不是没必要为各个业务画用例图，因为画用例图的最终目的是系统代码设计，基本上是按照用例图——〉序列图——〉类图进行的，业务流程是可新增和调整的，也就是序列图是不能预先画出来的，同样类也是不能确定的，比如《商品房预售许可证》其实是不能画成一个类的，因为它是定制出来的，以后编码中可能不会有一个类叫《商品房预售许可证》，同样也不会有开发商，因为角色也是依靠定制出来的。
我认为即使把这些业务用例画出来，也只是系统部署的时候可用来作为定制业务的依据，并不能用来指导编码。你们认为呢？可能说得不太清楚，请指出。

 回复: 有强大的工作流定制功能后台系统的情况下是否有必要画业务用例图
　

---

上面有个地方理解错了，序列图的序列与业务流程不是一回事，流程中每个具体节点执行者所作的一连串动作才是序列，而整个业务流程不应当是序列。
请问：一个序列图是不是可以理解成一个用例的动作细化？

你的系统很有意思，可能的话我们可以一起探讨设计上的问题。比如类的划分。

 回复: 有强大的工作流定制功能后台系统的情况下是否有必要画业务用例图
　

---

好！哪怕是不看欧洲杯也要向你请教

 回复: 有强大的工作流定制功能后台系统的情况下是否有必要画业务用例图
　

---

经过再三考虑，我觉得还是要画用例图。因为即便是使用后台系统定制业务流程，也是系统开发的一部分，用例图的最终不一定要走向代码，即便是开发硬件也是可以使用用例图。
这里竟然如此冷清，看以前的帖子，发现本组有过辉煌，是什么使它走向没落呢？UML也过时了吗？

你希望我们用什么形式讨论呢？在这里跟贴么？还是发邮件？还是其他的形式？希望我们能共同提高，加深对软件架构方面的理解！

你希望我们用什么形式讨论呢？在这里跟贴么？还是发邮件？还是其他的形式？希望我们能共同提高，加深对软件架构方面的理解！
我的Email是：zengdou@163.com

你的对象持久化怎么解决的？

 回复: 就在这里吧，让其他人也能一起参与
　

---

我做的东西还不是完全的面向对象，我没你的雄心壮志，要把整个世界对象化，呵呵。在我这个项目中，编码阶段不需要考虑业务，所以代码里不会有具体的与业务有关的类和对象，也就没有了持久化的烦恼了，不过我建议你需要用到的时候再加载进去，要不然初始化效率太差。你把被引用的对象当作普通的成员变量好了，构造对象的时候不一定需要把所有的成员都初始化。
不知道我是否理解了你的问题。

 回复: 有强大的实现能力要不要思考到底该做些什么?
　

---

你说得对。画用例图不仅可以用作编码设计的目的，也可以指导以后定制业务时的指导，一句话，有业务需求就可以画用例。
这个问题就不讨论了，我已经着手开始画了，我会把它贴出来，欢迎指正。

use case view可分Business Use-Case Model和Use-Case Model，画这两个模型的时候，考虑的系统边界是否可以不一样，前者的系统范围是否更大一些。比如订飞机票的系统，在Business Use-Case Model中系统边界应当涵盖订票操作员和订票的软件系统，actor是旅客；在 Use-Case Mode中系统边界不能涵盖订票操作员，此时他是actor。