用例图O.pptVIP

用户模型视图 用户模型视图从用户的角度描述系统功能，并指出各功能的参与者。它所描述的系统功能依靠参与者来激活，为参与者提供服务，从而实现参与者与系统的交互。 系统实现的最终目标是提供用户模型视图中所描述的功能，用户模型视图的修改会对所有其它的视图产生影响。 用户模型视图是其它视图的核心，其内容直接驱动其它视图的开发。 通过测试用户模型视图，还可以检验和最终校验系统。 用户模型视图由用例图组成。 用户模型视图：用例图 画好用例图是由软件需求到最终实现的第一步，是后续开发工作的基础。 用例图常应用于需求分析阶段，它的建立是由系统开发人员和用户多次讨论、协商的结果，表明了开发人员对需求规格定义达成的共识。 用例图描述待开发系统的功能需求；它将系统看作黑盒，从外部参与者的角度来理解系统； 用例图描述人们希望如何使用一个系统。它显示谁将是相关的用户、用户希望系统提供什么服务，以及用户需要为系统提供的服务。 用例图不仅在开发过程中保证了系统所有功能的实现，而且被用于验证和检测所开发的系统是否满足系统需求，从而影响到开发各个阶段和UML的各个模型。 用户模型视图：用例图 UML中的用例图描述了一组用例、参与者以及它们之间的关系。参与者用人形图形表示，用例用椭圆形符号表示，连线表示它们之间的关系。 参与者 参与者是系统外部的一个实体，它以某种方式参与了用例的执行过程。它是为了完成一个事件而与系统进行交互的实体，是与系统交互作用的外部用户、进程或其他系统的理想化概念。 参与者的特征是作为外部用户与系统发生交互作用。 参与者通过向系统输入或请求系统输入某些事件来触发系统的执行。 参与者由它们参与用例时所担当的角色来表示。在UML中，参与者用名字写在下面的人形图标表示。 参与者 参与者 参与者包括人参与者和外部系统参与者。 系统的用户是人参与者，用户通过与系统的交互操纵系统，完成所需要的工作。 外部系统也可以作为一个参与者，与本系统相互作用，交换信息。外部系统可以是一个软件系统，也可以是一个硬件设备。 参与者 参与者有三大类： ⑴ 系统用户 ⑵ 与所建造的系统交互的其他系统 ⑶ 可以运行的进程。 第一类参与者是真实的人，即用户，是最常见的参与者，几乎存在于每一个系统中。 命名这类参与者时，应当按照业务而不是位置命名。按照业务而不是位置命名可以获得更稳定的参与者。 第二类参与者是其他的系统。（医院医保系统和卫生局的医保系统） 第三类参与者是一些可以运行的进程。（时间、完成某个进程方可触发用例） 参与者的识别 在获取用例前要先确定系统的参与者，可以根据以下的一些问题来寻求系统的参与者。 ⑴ 谁将使用该系统的主要功能； ⑵ 谁将需要该系统的支持以完成其工作； ⑶ 谁将需要安装、维护、管理该系统，以及保持该系统处于工作状态； ⑷ 系统需要处理哪些硬件设备 ⑸ 与该系统发生交互的是什么系统 ⑹ 谁或什么系统对本系统产生的结果感兴趣 参与者的识别 在对参与者建模的过程中，开发人员必须牢记以下几点： ⑴ 参与者对于系统而言总是外部的，因此它们可以处于人的控制之外； ⑵ 参与者可以直接或间接地同系统交互，或使用系统提供的服务以完成某件事务； ⑶ 参与者表示人和事物与系统发生交互时所扮演的角色，而不是特定的人或特定的事物； ⑷ 一个人或事物在与系统发生交互时，可以同时或不同时扮演多个角色； ⑸ 每一个参与者需要一个具有业务一样的名字，在建模中不推荐使用类似与“NewActor”或“新参与者”的名字； 参与者的识别 在对参与者建模的过程中，开发人员必须牢记以下几点： ⑹ 每一个参与者必须有简短的描述，从业务角度描述参与者是什么； ⑺ 和类一样，参与者可以具有表示参与者的属性和可以接受的事件，但使用得不频繁。 参与者间的关系 参与者可以用类描述 多个参与者之间可以具有与类之间相同的关系。 在用例图中，可以使用泛化关系来描述多个参与者之间的公共行为。 参与者间的关系 例如，在图书馆管理系统中，借书者可以泛化成两类：学生和老师。 再如，航空售票系统接受客户预定机票，客户可以进行电话预定和网上预定，如果不考虑客户是如何与系统接触的，可以使用一般角色的参与者，即父类；如果强调接触发生的形式，那么必须使用实际的参与者，即子类。 参与者间的关系 更具一般的，可以由下图表示参与者之间的关系。 用例 用例是外部可见的系统功能单元。 用例是对一个系统或一个应用的一种单一的使用方式所作的描述，是关于单个活动者在与系统对话（交互）中所执行的处理行为的陈述序列。 用例的用途是，在不揭示系统内部构造的前提下定义连贯的行为。 用例 用例是一个叙述型的文档，用来描述参与者使用系统完成某个事