用UML进行有效业务建模 大多数软件开发实践者都知道,UML在对真实世界的现象进行建模时非常优秀。这一特性可以有效帮助分析员和客户进行沟通。
一些希望使用业务建模的团队常常有一些经验性的问题,例如:
很不幸,本文的焦点集中于应用UML进行业务建模的问题,而很少把业务建模和系统建模进行比较。这将使用户和分析员对使用UML进行业务建模的感到灰心。 业务用例模型概览 在这个简单的例子中的第一步是完成业务用例模型概览。如图所示,有两个业务主角和两个业务用例。
我们总结业务用例如下:
我们总结业务主角如下:
在这个例子中,得到一个新系统的核心业务目标被精化为两个子目标:
业务用例规约 这一部分,我们来看看如何描述业务用例,虽然RUP中对业务用例规约有很详细的模版,但我们主要把精力放在基本流和扩展流上。 Prepare Tender的基本流:
扩展流:
业务用例实现 在这部分,我们从几个方面去实现业务用例。
焦点集中在工作流 我们要精力集中在业务角色的职责上,如图所示,Prepare Tender有三个业务角色:
下面的顺序图描述了Prepare Tender的基本流。
上图中的消息可以映射到每个业务角色的职责(如下图所示)。这个技术非常类似于用例分析。由此可见RUP业务建模的技术是很强大的:相同的技术可用于业务建模和系统建模。
焦点集中在流程自动化 现在我们准备去探索业务主角和业务角色职责,明确什么时候使用业务系统以及如何使用业务系统。在我们的例子中,我们有两个业务系统,如下图所示。
下面的顺序图描述了Prepare Tender基本流的实现,包含了需求的业务系统。
上图中的消息可以映射到业务角色的职责。如下图所示:
从上图中可以得到系统用例,如下图:
焦点集中在信息处理
下图是实现Prepare Tender的交互图(侧重于信息处理)。
下图是上图的一个简化。
结论 软件系统开发出来是为了达到业务目标,可是,用户,分析员,和开发人员常常生活在不同的世界;他们有不同的看法和用不同的行话。小组间的通讯障碍导致在解释各种系统需求时发生很多激烈的争论。具有代表性的一点是,他们的改变不是因为用户改变了想法,而是因为最初的需求需要净化。 1
|
|