系统约定：用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用用例和用例实例来描述，用例根据目标、职责、前置条件和后置条件来描述；用例对象是具体的事件序列。工作流是自动化的业务流程，用带有构造型 <> 的用例或用例实例描述。在UML中用类和对象描述团队角色（team roles），用类来描述团队角色的类型，对象描述担任该角色的具体工人（worker）。所有的符号可以用相应的构造型来修饰，如 <>、<>和<> 。每一个构造型都可以用文字或一个特定的图标表示。 　　假设业务流程是在业务系统中的业务对象、角色和其他的实例之间协作完成的。请参看详细介绍“跟踪业务流程到软件设计”。 图2 UML的静态结构图描述团队结构 　　图2显示了一个团队结构的例子。团队的角色用对象实例表示，为每个角色指定了雇员数量。一个客户满意团队（Customer Satisfaction Team）有三个开发员、两个测试员、一个产品经理和一个人担任用户角色。角色组叫做客户满意团队（Customer Satisfaction Team），用包符号表示。角色组也可能被表示成对象——作为角色的组装（composition）。如果团队表示为对象，团队和角色之间的关系为组装关系，那么根据UML元模型概念，一个特定的角色实例不能同时属于多于一个团队。如果团队表示为包，特定的角色实例可以同时属于几个团队。 图3 UML序列图描述业务流程的实例 　　图3描述了业务流程的实例。角色客户(customer) 下了一份定单，然后销售(sales)部门中的某个工人确认此定单。如果定单有效，此工人调用另一业务流程“公司运输物品（company ships an item）”的实例。这个类型的图在UML表示法指南中没有明确的提到，然而，它符合UML的元模型。在对象生命线顶部的符号代表分类器角色，如图3中的角色、对象角色和用例角色。 图4 UML用例图描述业务流程之间的静态关系 　　图4是UML用例图，描述了业务流程之间的静态关系。业务流程描述组织(organization)与角色客户（customer）的协作。注意在UML的1.1版本中，用例不能相互联系而总是由角色发送信号触发。这给建模环境带来困难，一个用例在运行期间，当特殊条件出现时，另一个用例也开始启动。在这种情况下，角色通过与另一个用例的联系初始化此用例而不需发出任何特定的开始信号。例如，如果客户的请求被评估为有效，用例公司运输物品（company ships an item）被组织中的对象触发。这个用例实例不直接由客户触发，希望下一版本的UML将减少用例间有关联系的限制。 共4页。 1 2 3 4 : 　　统一建模语言（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用用例和用例实例来描述，用例根据目标、职责、前置条件和后置条件来描述；用例对象是具体的事件序列。工作流是自动化的业务流程，用带有构造型 <> 的用例或用例实例描述。在UML中用类和对象描述团队角色（team roles），用类来描述团队角色的类型，对象描述担任该角色的具体工人（worker）。所有的符号可以用相应的构造型来修饰，如 <>、<>和<> 。每一个构造型都可以用文字或一个特定的图标表示。 　　假设业务流程是在业务系统中的业务对象、角色和其他的实例之间协作完成的。请参看详细介绍“跟踪业务流程到软件设计”。 图2 UML的静态结构图描述团队结构 　　图2显示了一个团队结构的例子。团队的角色用对象实例表示，为每个角色指定了雇员数量。一个客户满意团队（Customer Satisfaction Team）有三个开发员、两个测试员、一个产品经理和一个人担任用户角色。角色组叫做客户满意团队（Customer Satisfaction Team），用包符号表示。角色组也可能被表示成对象——作为角色的组装（composition）。如果团队表示为对象，团队和角色之间的关系为组装关系，那么根据UML元模型概念，一个特定的角色实例不能同时属于多于一个团队。如果团队表示为包，特定的角色实例可以同时属于几个团队。 图3 UML序列图描述业务流程的实例 　　图3描述了业务流程的实例。角色客户(customer) 下了一份定单，然后销售(sales)部门中的某个工人确认此定单。如果定单有效，此工人调用另一业务流程“公司运输物品（company ships an item）”的实例。这个类型的图在UML表示法指南中没有明确的提到，然而，它符合UML的元模型。在对象生命线顶部的符号代表分类器角色，如图3中的角色、对象角色和用例角色。 图4 UML用例图描述业务流程之间的静态关系 　　图4是UML用例图，描述了业务流程之间的静态关系。业务流程描述组织(organization)与角色客户（customer）的协作。注意在UML的1.1版本中，用例不能相互联系而总是由角色发送信号触发。这给建模环境带来困难，一个用例在运行期间，当特殊条件出现时，另一个用例也开始启动。在这种情况下，角色通过与另一个用例的联系初始化此用例而不需发出任何特定的开始信号。例如，如果客户的请求被评估为有效，用例公司运输物品（company ships an item）被组织中的对象触发。这个用例实例不直接由客户触发，希望下一版本的UML将减少用例间有关联系的限制。 共4页。 1 2 3 4 : 下载本文示例代码


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