UML用例和用例图

用例与用例图面向对象的UML设计基础翟亚红计算机工程系主要内容基本概念：Usecase、Actor、ScenarioUsecase间的关系UseCase分析技术案例讲解UseCase定义定义1：用例是对一个活动者(actor)使用系统的一项功能时所进行的交互过程的一个文字描述序列。定义2：用例是系统、子系统或类和外部的参与者（actor）交互的动作序列的说明，包括可选的动作序列和会出现异常的动作序列。UseCase特点用例是代表系统中各个项目相关人员之间就系统的行为所达成的契约。它有如下一些特点：用例描述了用户提出的一些可见的需求，对应一个具体的用户目标；用例从使用系统的角度描述系统中的信息，即站在系统外部察看系统功能，而不考虑系统内部对该功能的具体实现形式；用例是对系统行为的动态描述，属于UML的动态建模部分；用例并不是系统的全部需求，用例描述的只是功能性方面的需求。定义：参与者是指系统以外的、需要使用系统或与系统交互的东西，包括人、设备、外部系统等。通过系统边界与系统进行有意义交互。参与者未必是人，可以是设备、外部系统等。一个参与者可以执行多个用例，一个用例也可以由多个参与者使用。参与者并不是系统的一部分，尽管在模型中会使用参与者。参与者（Actor）IconLabelActorDecoration参与者的三种表现形式参与者—识别思路谁使用该系统谁改变系统的数据谁从系统获取信息谁需要系统的支持以完成日常工作任务谁负责维护、管理并保持系统正常运行谁对系统运行产生的结果感兴趣系统需要应付那些硬件设备系统需要和那些外部系统交互案例：库存管理系统某汽车制造厂需要一套库存管理系统，该系统实现的业务：生产工人根据生产计划领取物料，库存操作员根据生产系统的派单，将物料交付给领料工人，余料即时归还库房。库房管理人员定期盘点库存，通知供应商供货，对长期积存的货物，申请退货。识别思路：谁使用该系统谁改变系统的数据谁从系统获取信息谁需要系统的支持以完成日常工作任务谁负责维护、管理并保持系统正常运行系统需要应付哪些硬件设备系统需要和哪些外部系统交互谁对系统运行产生的结果感兴趣操作员，管理员领料员,退料员,操作员,管理员,供应商管理员生产系统,供应商系统操作员,管理员,领料员,退料员操作员，管理员操作员，管理员库存管理系统的参与者2、用例（UseCase）•用例描述了系统的功能需求，是系统的一组动作序列的描述。•用例的本质是用户与计算机之间的一次交互作用。识别用例执行者使用这个系统达到什么目标？语法测试：【执行者】使用系统来【用例】识别用例——有意义的目标识别用例——业务语言而非技术语言识别用例——用户观点而非系统观点用户观点系统观点识别用例——用例命名：通常采用动宾语结构或主谓结构命名脚本（scenario)在UML中，脚本指贯穿用例的一条单一路径，用来显示用例中的某种特殊情况。脚本是用例的实例，脚本与用例的关系相当于对象和类的关系。每个用例都有一系列的脚本，包括一个主要脚本和多个次要脚本。次要脚本描述了执行路径中的异常或可选择的情况。脚本（scenario)例：在“订货”这个用例中，包含着几个相关的脚本。一个是订货进行顺利的脚本；一个是相关货源不足的脚本；一个是涉及购货者的信用卡被拒的脚本等。这些脚本的组合构成了一个用例。主要内容基本概念：Usecase、Actor、ScenarioUsecase间的关系UseCase分析技术案例讲解关系参与者与用例之间关联关系用例与用例之间包含关系(include)扩展关系(extend)泛化关系(generalization)参与者与参与者之间泛化关系(generalization)关系—参与者与用例之间关联关系描述参与者与使用用例之间的关系。在UML中，关系用实线表示，实线可以有箭头，也可以没有箭头。例：参与者与用例通过关联相连。1）包含关系(include)包含关系指两个用例之间的关系，其中一个用例（即基本用例）的行为包含了另一个用例（即包含用例）的行为。包含关系中箭头的方向是从基本用例到包含用例。用例间的关系——包含关系基本用例包含用例include用例间的关系——包含关系预订座位检查座位信息安排座位includeinclude本例中，用例“CheckCredit”检查输入的信用卡号是否有效以及信用卡是否有足够的资金。2）扩展关系(extend)扩展关系允许一个用例（可选）扩展另一个用例的功能。扩展只能发生在基本用例的序列中某个特定的点上，这个点叫扩展点。扩展关系中基本用例本身是完整的。在扩展关系中，箭头的方向是从扩展用例到基本用例。用例间的关系——扩展关系用例间的关系——扩展关系基本用例扩展用例extend预订座位处理等候队列extend3）泛化关系泛化关系其实是子类与父类的关系。和类之间的泛化关系一样，用例和参与者也可以继承另一个用例和参与者。泛化的示例：银行存款有两种方式，一种是银行柜台存款，一种是ATM机存款。用例间的关系——泛化关系父用例子用例关系—参与者与参与者之间泛化关系CustomerCompanyPersonal用例的粒度用例的粒度指用例所包含的系统服务或功能单元的多少。用例的粒度越大，用例包含的功能越多，反义包含的功能越少。例：学生管理系统中维护学生信息用例图如下：管理员维护学生信息添加学生信息修改学生信息管理员删除学生信息主要内容基本概念：Usecase、Actor、ScenarioUsecase间的关系UseCase分析技术案例讲解用例的描述没有描述的UseCase就像是一本书的目录从用例的定义也可以看出，用例是一个“文字描述序列”，是“动作序列的说明”。用例的描述是用例的主要部分，是后续的交互图分析和类图分析必不可少的部分。用例的描述一般说来，用例采用自然语言描述参与者与系统进行交互时双方的行为，不追求形式化的语言表达（面向不同人员）。用例描述的内容用例的目标用例是怎么启动的参与者和用例之间的消息是如何传送的用例中除了主路径外，其他路径是什么用例结束后的系统状态其他需要描述的内容用例描述原则：尽可能写的“充分”，而不是追求写的形式化、完整或漂亮。书写用例文档——路径交互步骤的描述只书写“可观测”的使用主动语句句子必须以执行者或系统作为主语每一句都要朝目标迈进分支和循环不要涉及界面细节书写用例文档——路径交互步骤的描述(1)系统通过ADO建立数据库连接，传送SQL查询语句，从“零件”表查询…系统按照查询条件搜索零件只书写“可观测”的书写用例文档——路径交互步骤的描述(2)系统从会员处获取用户名和密码会员提交用户名和密码使用主动语句用户名和密码被验证系统验证用户名和密码书写用例文档——路径交互步骤的描述(3)执行者×××××系统×××××系统×××××执行者×××××句子必须以执行者或系统作为主语书写用例文档——路径交互步骤的描述(4)执行者填写姓名执行者填写电话执行者填写联系地址执行者提交×××××每一句话都要朝目标迈进书写用例文档——路径交互步骤的描述(5)分支：放到扩展路径循环：直接描述分支和循环书写用例文档——路径交互步骤的描述(6)会员从下拉框中选择类别会员在相应文本框中输入查询条件会员点击“确定”按钮……不要涉及到界面细节常见错误只描述系统的行为，没有描述参与者的行为只描述参与者的行为，没有描述系统的行为在用例描述中就设定对用户界面设计的详细要求描述过于冗长UseCase：取款Actor：储户主事件流：1、储户插入ATM卡，并键入密码；2、储户按“取款”按钮，并键入取款数目；3、储户取走现金、ATM卡并拿走收据；4、储户离开。问题：只描述了参与者的动作序列，而没有描述系统的行为ATM取款案例ATM取款案例UseCase：取款Actor：储户主事件流：1、ATM系统获得ATM卡和密码；2、设置事物类型为取款；3、ATM系统获取要提取的现金数目；4、验证帐户上是否有足够储蓄金额；5、输出现金、数据和ATM卡；6、系统复位。问题：只描述了ATM系统的行为，而没有描述参与者的行为ATM取款（修改后的描述）UseCase：取款Actor：储户主事件流：1、通过读卡机，储户插入ATM卡；2、ATM系统从卡上读取银行ID、帐号、加密密码、并用主银行系统验证银行ID和帐号；3、储户按“取款”按钮，ATM系统根据上面读出的卡上加密密码，对密码进行验证；4、储户按“快速取款”按钮，并键入取款数量，取款数量应该是100的倍数；5、ATM系统通知主银行系统，传递储户帐号和取款数量，并接收返回的确认信息和储户帐户余额；6、ATM系统输出现金、ATM卡和显示帐户余额的收据；7、ATM系统记录事务到日志文件；用例描述分析UseCase:BuySomething参与者：Customer主事件流：1、系统显示ID和密码窗口；2、顾客键入ID和密码，然后按OK键；3、系统验证顾客ID和密码，并显示个人信息窗口；4、顾客键入姓名、街道地址、城市、邮政编码、电话号码，然后按OK键；5、系统验证用户是否为老顾客；6、系统显示可以卖的商品列表；7、顾客在准备购买的商品图片上单击，并在图片旁边输入要购买的数量。选购商品完毕后按Done按钮；8、系统通过库存系统验证要购买的商品是否有足够库存；…….（后续描述省略）问题：对用户界面的描述过于详细，对于需求文档来说，详细的用户描述对获取需求并无帮助。改进后的描述UseCase：BuySomething参与者：Customer主事件流：1、顾客使用ID和密码进入系统；2、系统验证顾客身份；3、顾客提供姓名、地址、电话号码；4、系统验证顾客是否为老顾客；5、顾客选择要购买的商品和数量；6、系统通过库存系统验证要购买的商品是否有足够库存…….（后续描述省略）主要内容基本概念：Usecase、Actor、ScenarioUsecase间的关系UseCase分析技术案例讲解案例1：ATM系统建立一个具有基本功能的ATM机软件客户可以存钱，取钱客户可以查询帐户余额客户可以修改密码客户可以进行转帐需求建模—用例图建立用例图分为以下几个步骤：确定参与者（Actors）创建用例（UseCase）创建参与者（Actors）—用例（UseCase）关系图参与者系统用户与本系统交互的其他系统确定参与者(Actor)创建用例（UseCase）用例是参与者启动的，基于这样的考虑，ATM系统根据业务流程大致可以分为以下的几个用例：客户取钱客户存钱客户查询余额客户转帐客户更改密码建立用例图完整用例图客户(fromActors)存款(fromUseCases)取款(fromUseCases)查询账户余额(fromUseCases)转账(fromUseCases)修改密码(fromUseCases)交易系统(fromActors)建立事件流（用例描述）事件流的目的是建立使用用例中的逻辑流程，详细描述系统的工作。用例“取钱”的事件流（1）简要说明：客户可以从ATM机上取出自己帐目上的部分或者全部存款。前提条件：无主事件流：1.客户将卡插入ATM机，开始用例。2.ATM显示欢迎消息并提示客户输入密码。3.客户输入密码。4.ATM确认密码有效。如果无效则执行其他事件流A1。如果与主机联接有问题，则执行异常事件流E1。5.ATM提供以下选项：存钱，取钱，查询。6.用户选择取钱选项。7.ATM提示输入所取金额。8.用户输入所取金额。9.ATM确定该帐户是否有足够的金额。如果余额不够，则执行A2，如果与主机联接有问题，则执行异常事件流E1。10.ATM从客户帐户中减去所取金额。11.ATM向客户提供要取的钱。12.ATM打印清单。13.ATM退出客户的卡，用例