系统约定：用UML描述工作流管理

系统约定：用UML描述工作流管理  UML模型

关键字：UML 统一建模语言（UML）为描述面向对象系统定义了一系列的标准符号。使用UML增强了领域专家、工作流专家、软件设计者和其他不同背景的专家之间的交流联系。UML可以在普遍的场合使用，对工作流系统的用户而言很直观。除了这些，UML符号具有准确的语义，也就是说可视化的工作流描述可以作为软件规约。本文侧重讨论了如何使用UML来描述工作流管理系统，如何跟踪从业务流程到面向对象软件设计的描述信息，如何用UML可交互工件来结构化项目知识库。

　　在本文中，我们先来讨论工作流产品的软件设计者和用户对一种通用语言的需要，然后再来介绍如何使用统一建模语言（UML）描述一般的工作流概念，最后希望和搭建一起探讨如何把面向对象软件规约与工作流系统的描述联系起来。

　　下面我们先来描述一个企业在实现新工作流管理系统时的通常情形：

　　顾问与用户一起描述一个软件解决方案所支持的企业业务流程。开发队伍获得顾问的描述，但是他们很难理解业务术语，发现其中描述了太多的信息以至于难以用来实现此系统。开发者从技术观点来撰写系统规约，当把这个系统规约呈现在用户面前时，由于过于专业，以至于用户难以理解。然而为了进行下一步的工作，双方被迫接受了这个系统规约。

　　这种方式很容易导致系统无法达到用户的需求。用户、顾问和开发者通常都不是用同样的语言，这样的交流问题导致难以保证业务流程所有部分很好沟通，并转换为技术性的软件规约。另外，因为使用此系统的实际用户很难全部理解技术性的系统规约，使软件系统变得难以使用。

　　其挑战性在于能用一种既准确又友好的方法来为业务流程和业务系统建模。用来描述业务流程的每一个符号对用户来说很直观，并有确定的语义，因此开发者可以用它作为一般的描述，甚至用来精确的描述软件系统规约。

　　UML有着丰富和复杂的符号来描述软件系统。这些符号也许太丰富以至于不直观、不友好。然而，恰当地用UML来描述工作流管理系统有两大好处。首先，UML是软件界公认的符号标准；第二，UML也可用在不需要实现细节的一般场合。在显示的UML图与那些领域专家已经在使用的图在直观上很相近，另外，它们的语义有精确的定义。如有必要，可出于软件设计的目的给同样的图增加详细的实现细节。

　　业务系统的描述由流程和静态结构的描述组成。流程最直观的模型就是一个活动或任务的序列，按照顺序完成以到达某个目标。因此，UML的序列图和活动图很适用于友好、准确、详细地描述业务流程，如组织图之类的静态结构，没有实现细节，可以用UML的静态结构图描述。图形化的实现细节往往会误导那些不精通UML的人。例如，导航箭头经常错误地表示方向，最好是仅用UML表示选项的某一特定子集。例如，把元素互相嵌套来表示组装比用实心菱形表示关联要好。用文字来描述各种属性，而不用UML符号，例如《refine》就比带三角形的虚线好理解得多。

　　工作流概念映射到UML概念

　　这里介绍了用UML来描述工作流概念的例子。这仅仅提供了一个一般的指导，如何把工作流概念映像成UML，详细的细节很容易从UML的语义和符号指南[7]得到。工作流管理系统的每个结构都能用合适构造型的UML符号来描述。


图1 用UML表示业务对象、业务流程、团队角色

　　图1显示了用UML描述业务流程、业务对象、团队角色。业务对象在UML中用类和对象表示。类描述没有特性（identity）的业务对象，如发票(invoice)；对象描述有特性的业务对象，比如编号为VM4/55的发票(VM 4/55: invoice)。业务流程1用用例和用例实例来描述，用例根据目标、职责、前置条件和后置条件来描述；用例对象是具体的事件序列。工作流是自动化的业务流程，用带有构造型 <<workflow>> 的用例或用例实例描述。在UML中用类和对象描述团队角色（team roles），用类来描述团队角色的类型，对象描述担任该角色的具体工人（worker）。所有的符号可以用相应的构造型来修饰，如 <<business object>>、<<business process>>和<<team role>> 。每一个构造型都可以用文字或一个特定的图标表示。

　　假设业务流程是在业务系统中的业务对象、角色和其他的实例之间协作完成的。请参看详细介绍“跟踪业务流程到软件设计”。

原文转自：http://www.ltesting.net