图7是UML活动图，描述了用例包订单管理（order management）的生命周期。在活动图中的活动与图4、5、6中的用例相对应。
注意UML元模型没有定义任何从状态或行为状态到用例实例的映射，这种映射可以在开发过程进行，与Martin和Odell方法相似，其中子系统的每个状态都指明子系统中的一个候选类。参考[5]。然后，其他开发过程可能以其它方式定义用例包生命周期。例如，用例包生命周期的目的在用例包的范围内可被指定为子系统接口操作允许的顺序。
用例交互模型和用例生命周期还有一个显著的区别——它们在项目知识库中的位置不同，并且与其它设计工件的关系不同。工件用例交互模型与工件用例模型相关，工件用例包生命周期与工件用例包相关，后者的抽象级别比相对应的用例模型和用例交互模型高。
图8 在项目知识库里的用例视图中工件之间的关系。
符号用UML表示，为了更加清楚，依赖关系用role ends3表示。
项目知识库的结构化
在开发流程中，软件构架师、设计者和开发者确认软件产品的某些信息，如用例、软件构架、对象协作和类描述。这些信息可能十分抽象，如产品前景，也可能非常具体，如源代码。在本文中，我们把这些信息叫作软件产品设计工件（design artifacts）。
我们必须认识到设计工件与它的表达之间的区别：设计工件决定业务系统的信息，而表达决定如何把这些信息表示出来。有些设计工件用UML表示，有些用文字或表格表示，例如，类的生命周期可以用UML状态图、活动图、状态转移表或Backus-Naur范式表示。类库用文字来表示。
工作流管理系统的规格说明是定义在精确定义的设计工件基础上的，而不是在图上。这一节和下一节将讨论设计工件的结构，此结构可以明确业务流程、业务规则、软件构架和业务系统设计之间的关系，并且很容易扩展到覆盖业务系统的其他方面，如团队结构和项目计划。
业务系统可被描述为多级的抽象和多种视图。多级的抽象如组织级、系统级、构架级、类级；多种视图如逻辑视图、用例视图、分析视图、测试视图或文档视图。在抽象的每一级和在每一视图里，软件产品可以用四个设计工件来描述：分类器之间的静态关系、分类器之间的动态交互、分类器职责和分类器生命周期。每个工件可用UML图或文字来表示。如图9和图10。
图9 结构化项目知识库的设计工件模式
图10 在每一抽象级的每一视图中，都可以用四种设计工件描述软件产品。
UML分类器是：类、接口、用例、节点、子系统和组件。
分类器模型(classifier model)指定了分类器之间的静态关系。分类器模型可以是一组静态结构图（如果分类器是子系统，类或接口），可以是一组用例图（如果分类器是用例和执行者），可以是一组部署图（如果分类器是节点），还可以是一组组件图（如果分类器是组件）。
分类器交互模型（classifier interaction model）指定了分类器之间的交互。分类器交互模型可以用交互图表示：序列图或协作图。UML表示指南（UML Notation Guide）仅仅描述了那些分类器是对象的交互图，并不描述那些分类器是用例、子系统、节点或组件的交互图。
文章来源于领测软件测试网 https://www.ltesting.net/
