统一建模语言(UML)为描述面向对象系统定义了一系列的标准符号。使用UML增强了领域专家、工作流专家、软件设计者和其他不同背景的专家之间的交流联系。UML可以在普遍的场合使用,对工作流系统的用户而言很直观。 除了这些,UML符号具有准确的语义,也就是说可视化的工作流描述可以作为软件规约。本文侧重讨论了如何使用UML来描述工作流管理系统,如何跟踪从业务流程到面向对象软件设计的描述信息,如何用UML可交互工件来结构化项目知识库。
图1显示了用UML描述业务流程、业务对象、团队角色。业务对象在UML中用类和对象表示。类描述没有特性(identity)的业务对象,如发票(invoice);对象描述有特性的业务对象,比如编号为VM4/55的发票(VM 4/55: invoice)。业务流程1用用例和用例实例来描述,用例根据目标、职责、前置条件和后置条件来描述;用例对象是具体的事件序列。工作流是自动化的业务流程,用带有构造型 <
图2显示了一个团队结构的例子。团队的角色用对象实例表示,为每个角色指定了雇员数量。一个客户满意团队(Customer Satisfaction Team)有三个开发员、两个测试员、一个产品经理和一个人担任用户角色。角色组叫做客户满意团队(Customer Satisfaction Team),用包符号表示。角色组也可能被表示成对象——作为角色的组装(composition)。如果团队表示为对象,团队和角色之间的关系为组装关系,那么根据UML元模型概念,一个特定的角色实例不能同时属于多于一个团队。如果团队表示为包,特定的角色实例可以同时属于几个团队。
图3描述了业务流程的实例。角色客户(customer) 下了一份定单,然后销售(sales)部门中的某个工人确认此定单。如果定单有效,此工人调用另一业务流程“公司运输物品(company ships an item)”的实例。这个类型的图在UML表示法指南中没有明确的提到,然而,它符合UML的元模型。在对象生命线顶部的符号代表分类器角色,如图3中的角色、对象角色和用例角色。
图4是UML用例图,描述了业务流程之间的静态关系。业务流程描述组织(organization)与角色客户(customer)的协作。注意在UML的1.1版本中,用例不能相互联系而总是由角色发送信号触发。这给建模环境带来困难,一个用例在运行期间,当特殊条件出现时,另一个用例也开始启动。在这种情况下,角色通过与另一个用例的联系初始化此用例而不需发出任何特定的开始信号。例如,如果客户的请求被评估为有效,用例公司运输物品(company ships an item)被组织中的对象触发。这个用例实例不直接由客户触发,希望下一版本的UML将减少用例间有关联系的限制。 UML用例图不容易表达出用例实例的顺序,例如,首先客户请求一项物品,然后公司将传送此物品,最后客户付款。一个解决的方法就是在用例间使用约束{precedes}或依赖关系 <
角色可以通过特殊顺序启动用例的方法来使用系统。像这样的场景——用例实例序列——可以用顺序图或协作图描述,参看图5和图6。对照对象交互图,场景被描述为消息序列,用例交互图把场景描述为用例序列。这个图仅仅是由其他场景的实例组成的一个场景的UML图。在图5中消息调用(invoke)表示用例构造器和映射为从角色到用例的信号。根据每个用例的最开始操作,如调用请求(invoke request), 调用运输(invoke shipment)和调用付款(invoke payment),可以命名这些消息,除了这些消息之外,用例交互图能表示角色与系统间其他消息的交互,并描述了用例与角色的全部交谈。
用例协作图也描述业务流程实例组成的一个场景。不象用例序列图,用例协作图描述用例实例和角色实例之间的用例关系和消息交互。用例协作图如图6所示。
用例交互图描述的仅仅是由用例实例组成的一种典型场景。因此它不能表达用例实例所有允许的顺序,属于用例包的用例实例所允许的顺序可以在用例包生命周期内详细说明。用例包的生命周期可用静态图、Backus-Naur范式(BNF)(请参看[4]如何使用BNF指定生命周期。)的活动图表示,在这些状态中,活动状态或BNF声明映射为用例包中的用例。用例包生命周期是用例包行为的准确描述,然而它难以正确表达,尤其在复杂的用例中。用例交互图很容易表达,但它描述的仅仅是由包中用例组成的某一典型场景。 统一建模语言(UML)为描述面向对象系统定义了一系列的标准符号。使用UML增强了领域专家、工作流专家、软件设计者和其他不同背景的专家之间的交流联系。UML可以在普遍的场合使用,对工作流系统的用户而言很直观。 除了这些,UML符号具有准确的语义,也就是说可视化的工作流描述可以作为软件规约。本文侧重讨论了如何使用UML来描述工作流管理系统,如何跟踪从业务流程到面向对象软件设计的描述信息,如何用UML可交互工件来结构化项目知识库。
图1显示了用UML描述业务流程、业务对象、团队角色。业务对象在UML中用类和对象表示。类描述没有特性(identity)的业务对象,如发票(invoice);对象描述有特性的业务对象,比如编号为VM4/55的发票(VM 4/55: invoice)。业务流程1用用例和用例实例来描述,用例根据目标、职责、前置条件和后置条件来描述;用例对象是具体的事件序列。工作流是自动化的业务流程,用带有构造型 <
图2显示了一个团队结构的例子。团队的角色用对象实例表示,为每个角色指定了雇员数量。一个客户满意团队(Customer Satisfaction Team)有三个开发员、两个测试员、一个产品经理和一个人担任用户角色。角色组叫做客户满意团队(Customer Satisfaction Team),用包符号表示。角色组也可能被表示成对象——作为角色的组装(composition)。如果团队表示为对象,团队和角色之间的关系为组装关系,那么根据UML元模型概念,一个特定的角色实例不能同时属于多于一个团队。如果团队表示为包,特定的角色实例可以同时属于几个团队。
图3描述了业务流程的实例。角色客户(customer) 下了一份定单,然后销售(sales)部门中的某个工人确认此定单。如果定单有效,此工人调用另一业务流程“公司运输物品(company ships an item)”的实例。这个类型的图在UML表示法指南中没有明确的提到,然而,它符合UML的元模型。在对象生命线顶部的符号代表分类器角色,如图3中的角色、对象角色和用例角色。
图4是UML用例图,描述了业务流程之间的静态关系。业务流程描述组织(organization)与角色客户(customer)的协作。注意在UML的1.1版本中,用例不能相互联系而总是由角色发送信号触发。这给建模环境带来困难,一个用例在运行期间,当特殊条件出现时,另一个用例也开始启动。在这种情况下,角色通过与另一个用例的联系初始化此用例而不需发出任何特定的开始信号。例如,如果客户的请求被评估为有效,用例公司运输物品(company ships an item)被组织中的对象触发。这个用例实例不直接由客户触发,希望下一版本的UML将减少用例间有关联系的限制。 UML用例图不容易表达出用例实例的顺序,例如,首先客户请求一项物品,然后公司将传送此物品,最后客户付款。一个解决的方法就是在用例间使用约束{precedes}或依赖关系 <
角色可以通过特殊顺序启动用例的方法来使用系统。像这样的场景——用例实例序列——可以用顺序图或协作图描述,参看图5和图6。对照对象交互图,场景被描述为消息序列,用例交互图把场景描述为用例序列。这个图仅仅是由其他场景的实例组成的一个场景的UML图。在图5中消息调用(invoke)表示用例构造器和映射为从角色到用例的信号。根据每个用例的最开始操作,如调用请求(invoke request), 调用运输(invoke shipment)和调用付款(invoke payment),可以命名这些消息,除了这些消息之外,用例交互图能表示角色与系统间其他消息的交互,并描述了用例与角色的全部交谈。
用例协作图也描述业务流程实例组成的一个场景。不象用例序列图,用例协作图描述用例实例和角色实例之间的用例关系和消息交互。用例协作图如图6所示。
用例交互图描述的仅仅是由用例实例组成的一种典型场景。因此它不能表达用例实例所有允许的顺序,属于用例包的用例实例所允许的顺序可以在用例包生命周期内详细说明。用例包的生命周期可用静态图、Backus-Naur范式(BNF)(请参看[4]如何使用BNF指定生命周期。)的活动图表示,在这些状态中,活动状态或BNF声明映射为用例包中的用例。用例包生命周期是用例包行为的准确描述,然而它难以正确表达,尤其在复杂的用例中。用例交互图很容易表达,但它描述的仅仅是由包中用例组成的某一典型场景。 |
|
来自: 馨馨 > 《软件管理综合信息》