文档介绍：业务用例与系统用例一个业务用例描述的是业务过程——而不是软件系统过程。业务用例:业务过程是描述这个业务的具体工作流的;一次涉众与实现业务目标的业务之间的交互。它可能包含手工和自动化的过程,也可能发生在一个长期的时间段中。系统用例的设计范围就是这个计算机系统设计的范围。它是一个系统参与者,与计算机系统一起实现一个目标。系统用例就是参与者如何与计算机技术相联系,而不是业务过程。业务用例着重于业务操作。它们表示实现业务目标的业务中的具体工作流。业务过程可能涉及手工和自动过程,并且在一段长期的时间内进行。系统用例着重于要设计的软件系统。参与者如何与软件系统进行交互?我们在系统用例说明中书写的事件流应该足够详细,从而用作编写系统测试脚本的出发点。UML业务模型包括两个模型:用例视图(Use-CaseView中的业务用例模型和逻辑视图(LogicalView中的业务分析模型。1业务用例模型中的主图是业务用例图。您还可以随意加入表示单个业务用例的UML活动图,来图形化地显示工作流过程。业务分析模型描述了通过业务角色和业务实体的交互来实现业务用例。它用作业务角色和业务实体需要如何相关联,以及它们需要如何协作,来执行业务用例的抽象。业务分析模型中有三种类型的UML图,如图3所示:类(Class、时序(munication图。图3:业务分析模型图业务分析模型中的主要的图是时序图。您手工地创建显示出业务参与者、业务角色,和业务实体如何交互执行业务用例的时序图。时序图显示出以时间时序安排的对象交互。特别是,它显示出参与交互的对象,以及消息交换的顺序。(Collaborationdiagram,它描述了对象之间交互的模式,通过对象间的链接和发送给对方的消息来展示参与交互的对象。通信图和时序图都显示出交互,但它们强调了不同的方面。时序图清楚地显示出时间顺序,但没有明确地显示出对象关系。通信图清楚地显示出对象关系,但必须从顺序号那儿获得时间顺序。两个图都显示出同样的行为,但方式不同。我个人喜欢时序图,因为它通常比较容易读懂。您还可以使用参与类的视图(ViewofParticipatingClasses,VOPC来显示协作执行业务用例的业务参与者、业务角色和业务实体的静态视图。用例模型往往描述的是用户对整个项目提出的所有功能的集合。对于每个功能,我们通常使用用例,并在用例描述中描述该用例的主要流程。因此用例模型描述的通常是需求分析中动态的部分。领域模型往往描述的是用户提出的整个问题空间中的各种事物及它们的相互关系,因此领域模型描述的是需求分析中静态部分。领域模型虽然不是完全,但却是以此为基础,形成软件系统中的软件类。为什么不是“完全”呢?因为软件系统中需要什么类,是软件系统功能的要求。假如在领域模型中的某个对象,它的确是用户问题空间中的事物,但是它在软件系统功能的要求中使用不到它,那么在软件系统中它同样不能成为一个软件类。当我们设计好了软件类以后,我们就将根据用例模型,为所有的软件类分配职责,确定它们各自应具有的行为及相互的协作。每个软件类应当如何分配它们的职责,也就是说用例模型中描述的各个功能应当交给哪个或哪些软件类去实现,这个工作就是对软件类的职责分配。完成这个工作的阶段主要在对象分析的中前期。.