用例建模1 - 副本

1、1用例建模用例建模21. 获取原始需求(收集资料、现场观察、访谈、开会、问卷调查、原型）2. 开发一个可以理解的需求识别参与者识别用例构建用例图3 详细、完整地描述需求进行用例阐述4 重构用例模型识别用例间的关系对用例进行组织和分包3用例模型用例模型v用例模型用于需求分析阶段，用例模型用于需求分析阶段，反映了系统能够完成什么样的功能，描述了软件系统外部参与者所理解的系统功能。4用例模型的目的用例模型的目的v构建用例模型是通过开发者与客户，或最终使用者共同协商完成的。v经过反复讨论需求的规格说明，达成共识，达成共识，明确系统的基本功能明确系统的基本功能，为后阶段的工作打下基础。v确定系统应具备哪

2、些功能、为系统的功能提供清晰一致的描述5用例视图用例视图: :v用例是用例是JacobsonJacobson在面象对象的软件在面象对象的软件工程中提出的。工程中提出的。v用例是获取业务过程和系统需求的用例是获取业务过程和系统需求的有效方式，使得需求可浏览。有效方式，使得需求可浏览。6用例图v三种主要建模元素：用例（Use Case）。参与者（Actor）。关系。v可选元素：注释和约束。包。系统边界框。7用例图8参与者v参与者代表与系统接口的事物或人，它是具有某一种特定功能的角色，因此参与者是虚拟的概念，它可以是人，也可以是外部系统或设备。v同一个人可能对应多个参与者，因为一个人可能扮演多个角色

3、。v参与者不是系统的一部分，它们处于系统的外部。v如何识别出参与者？ 参与者代表角色。参与者不是对职位进行建模。9例：自动饮料售货机例：自动饮料售货机客户买饮料供货人供货收银员取货款用例图中包含系统角色和用例等三种模型元素，以及它们之间的关系。10角色角色 Actor角色定义：角色定义：在系统边界之外，透过在系统边界之外，透过系统边界系统边界与系统进行有意与系统进行有意义的交互的任何人或事物。义的交互的任何人或事物。角色与系统交互：角色与系统交互：角色向系统发送消息、从系统接受消息、或是与系统交换信息。角色类型：角色类型：人、外部系统、外部设备或Timer角色与用例：角色与用例：角色往往是发现

4、新用例的基础，同时也是分析员和用户交流的起点aActor11某个角色的存在是因为其和系统有交互行为某个角色的存在是因为其和系统有交互行为角色透过系统边界和系统进行交互角色透过系统边界和系统进行交互12软件解软件解决方案决方案I/OI/O系统边界系统边界?其他系统aActor13v角色是一个类，包含属性、行为和描述角色的角色是一个类，包含属性、行为和描述角色的文档，而不是类的实例文档，而不是类的实例。v角色的确定代表着系统边界的确定。角色的确定代表着系统边界的确定。v角色的命名：角色的命名：必须是名词，不能写成角色的某个实例角色的特征角色的特征14识别系统边界和角色识别系统边界和角色 通过向用户

5、提问来识别角色：v谁使用系统提供的主要功能？（主要角色）谁使用系统提供的主要功能？（主要角色）v谁来维护、管理系统？（次要角色）谁来维护、管理系统？（次要角色）v谁需要借助于系统完成日常工作任务？谁需要借助于系统完成日常工作任务？v系统需要控制的系统需要控制的硬件设备硬件设备有哪些？有哪些？v系统需要与其他系统需要与其他哪些系统哪些系统交互交互？v系统从哪儿得到信息？系统从哪儿得到信息？v对系统产生的结果感兴趣的人或事是哪些？对系统产生的结果感兴趣的人或事是哪些？！不能把目光只专著于人身上。不能把目光只专著于人身上。15角色：_角色职责：_角色识别问题：_角色描述模板角色描述模板在完成了角色的

6、识别工作之后，建模者就可以建立使用系统或与系统交互的实体了，即可以从角色的角度出发，考虑角色需要系统完成什么样的功能，从而建立角色需要的用例。16角色间可引入继承关系角色间可引入继承关系学生小学生中学生大学生本科生研究生硕士研究生博士研究生17ATM系统的Actor1、谁使用、谁使用ATM系统的主要功能（提款）？系统的主要功能（提款）？答：储户答：储户2、谁使用、谁使用ATM系统的支持以完成日常工作任务？系统的支持以完成日常工作任务？答：出纳员？还不肯定，先放在这里答：出纳员？还不肯定，先放在这里3、谁来维护、管理并保持系统正常运行？、谁来维护、管理并保持系统正常运行？答：答： ATM系统工程

7、师，银行人员系统工程师，银行人员185、ATM系统需要处理哪些设备？系统需要处理哪些设备？答：信用卡答：信用卡6、谁对、谁对ATM系统运行的结果感兴趣？系统运行的结果感兴趣？答：银行会计、储户答：银行会计、储户4、该系统需要和哪些系统交互？、该系统需要和哪些系统交互？答：目前还不清楚答：目前还不清楚19?储户?信用卡?银行人员?银行会计ATM系统的系统的Actor20角色：储户角色职责：插入信用卡输入口令输入交易额：角色识别问题：（1）使用系统主要功能（2）对系统运行结果感兴趣储户角色描述储户角色描述21用例用例 v从外部用户的角度观察系统应支持哪些功能，帮助分析人员理解系统的行为，它是对系统

8、功能的宏观描述。用例事件流文档（脚本）是对系统行为的动态描述，它可以增进设计人员、开发人员与用户的沟通，理解正确的需求；还可以划分系统与外部实体的界限，是系统设计的起点，是类、对象、操作的来源，而通过逻辑视图的设计，可以获得软件的静态结构。NewUseCase22识别用例识别用例v首先弄清楚系统的问题域、业务流程，整理出系统的功能需求，在此基础上结合已经识别出来的角色识别、抽象出系统用例，定义并描述它。v针对角色某个角色要求系统为其提供什么功能；该角某个角色要求系统为其提供什么功能；该角色需要做哪些工作？色需要做哪些工作？角色需要阅读、创建、销毁、更新或存储系角色需要阅读、创建、销毁、更新或存

9、储系统中的某些（类）信息码？统中的某些（类）信息码？23系统中的事件一定要告知角色吗？角色需系统中的事件一定要告知角色吗？角色需要告诉系统一些什么吗？（关注：系统内要告诉系统一些什么吗？（关注：系统内外变化）外变化）v针对系统针对系统系统需要什么样的输入和输出？输入来自系统需要什么样的输入和输出？输入来自哪里？输出去往哪里？哪里？输出去往哪里？该系统的当前状况还存在哪些问题？该系统的当前状况还存在哪些问题？改进的方向？改进的方向？24！在用例描述中不要包含！在用例描述中不要包含GUIGUI设计设计，因为用例是针对需求，因为用例是针对需求的，而界面设计是的，而界面设计是“设计设计”，不，不要把设

10、计的东西放进需求里。要把设计的东西放进需求里。25用例间的关系v类属关系如同类间的类属关系。即，子用例继承父用例的行为和含义，子用例可以添加新行为或覆盖父用例的行为。 vInclude关系（包含关系）用例间的包含关系表示在基用例的指定位置，基用例显式地包含另一个用例的行为。被包含的用例是不能独立存在的，只是包含它的更大用例的一部分。vExtend关系（扩充关系）扩充关系用来说明可选的、只在特定条件下运行的行为。 扩充关系用衍型为的依赖关系表示，并在基用例中列出基用例的扩充点，这些扩充点是出现在基用例的流中的标记。基本用例执行时,扩展用例不一定执行26类属关系 Validate user Val

11、idate password Scan IDCard 27 CustomerActor Maintain Account Login Clerk Transfer fund within a bank Deposit fund Withdraw fund Transfer fund Clerk BankActor Transfer fund between banks v参与者与用例之间的关系用带箭头的直线表示，箭头表示参与者和用例之间信息传输的方向，如不强调信息传输方向，则可省略箭头。v（1）启动用例v（2）获取用例提供的服务v（3）为用例提供服务2829示例：（示例：（include）启动

12、Administrator管理用户SystemAdminCardProcessingCompany信用卡支付CheckProcessingCompany支票支付登录购买商品CashierInventory退还商品现金支付30Extend关系 Take exam Extension points fail Make up exam Finish homework Have lessons Student 3132用例描述用例描述v通过每一个角色的观点来描述每一个用例的事件流v脚本或场景（Scenario）是系统行为的一个特定动作序列33事件流文档模板v事件流文档模板： X. 用例XX（用例名）的

13、事件流X.1 前置条件（Pre-Conditions）X.2 后置条件（Post-Conditions）X.3 扩充点（Extension Points）X.4 事件流X.4.1 基流（Basic Flow）X.4.2 分支流（Subflows）（可选）X.4.3 替代流（Alternative Flows）34v前置条件：指出该用例在执行之前必须具备什么条件。v后置条件：指出该用例执行之后系统系统应处于什么状态。v基本流：指出典型的成功路径，其中一般不包括任何条件或者分支语句，所有的条件和分支都推迟到扩展部分。需求分析v图书馆图书管理系统的域描述如下： 在图书管理系统中，要为每个借阅者建立一

14、个账户，并给借阅者发放借阅卡（借阅卡可以提供借阅卡号、借阅者名），账户中存储借阅者的个人信息、借阅信息以及预订信息。持有借阅卡的借阅者可以借阅书刊、返还书刊、查询书刊信息、预订书刊并取消预订，但这些操作都是通过图书管理员进行的，也即借阅者不直接与系统交互，而是图书管理员充当借阅者的代理与系统交互。在借阅书刊时，需要输入所借阅的书刊名、书刊的ISBN/ISSN号，然后输入借阅者的图书卡号和借阅者名，完成后提交所填表格，系统验证借阅者是否有效（在系统中存在账户），若有效，借阅请求被接受，系统查询数据库系统，看借阅者所借阅的书刊是否存在，若存在，则借阅者可借出书刊，建立并在系统中存储借阅记录。借阅者

15、还书后，删除关于所还书刊的借阅记录。如果借阅者所借的书刊已被借出，借阅者还可预订该书刊，一旦借阅者预订的书刊可以获得，就将书刊直接寄给预订人（为了简化系统，预订书刊可获得时就不通知借阅者了）。另外，为了简化系统，也不考虑书刊的最长借阅期限，假设借阅者可以无限期地保存所借阅的书刊。36需求分析v功能性需求：v（1）借阅者持有借阅卡（借阅者名和借阅卡号）。v（2）图书管理员作为借阅者的代理借书。v（3）图书管理员作为借阅者的代理预订书刊。v（4）图书管理员作为借阅者的代理取消预订。v（5）图书管理员作为借阅者的代理还书。v（6）图书管理员可以创建新的借阅者账户。v（7）图书管理员可以修改借阅者的账

16、户信息。v（8）图书管理员可以删除已存在的借阅者账户。v（9）图书管理员可以添加新书刊种类。v（10）图书管理员可以修改书刊种类信息。v（11）图书管理员可以删除系统中的书刊种类。v（12）图书管理员可以在系统中添加书刊信息（注意区分“书刊种类”与“书刊”）。v（13）图书管理员可以编辑书刊信息。v（14）图书管理员可以删除书刊信息。37 需求分析 BorrowerActor Maintain Borrower Info Maintain Title Info Maintain Book info Log In Librarian Borrow Book Cancel Reservation

17、Reserve Title Return Book Librarian 38用例的事件流描述：例用例的事件流描述：例1借阅物理书刊（Borrow Book）1.1前置条件（Pre-Conditions）在这个用例开始前，Librarian必须登录到系统中。1.2后置条件（Post-Conditions）如果这个用例成功，在系统中建立并存储借阅记录，如果必要还要删除预订记录。反之，系统的状态没有变化。1.3扩充点（Extension Points）没有。1.4事件流1.4.1基流（Basic Flow）当借阅者从图书馆借阅物理书刊时，用例启动。如果Librarian选择“借书”，则执行分支流S-

18、1：借阅物理书刊。如果所借的物理书刊是经过预订的，则执行分支流S-2：通过预订借阅物理书刊。1.4.2分支流（Subflows）S-1：借阅物理书刊（1）提供书刊种类、借阅者信息。（2）检索书刊种类（Title）（E-1）。（3）确定所借阅的物理书刊是否可以获得（E-2），也即物理书刊是否都已借出。39用例的事件流描述：例用例的事件流描述：例（4）检索借阅者（E-3）。（5）图书馆将物理书刊借给借阅者。（6）创建借阅记录。（7）存储借阅记录。S-2：通过预订借阅物理书刊（1）提供书刊种类、借阅者信息。（2）检索书刊种类（Title）（E-1）。（3）检索借阅者（E-3）。（4）确定该种类书刊的

19、物理拷贝是否可以获得（E-2）。（5）将物理书刊发给借阅者。（6）创建借阅记录。（7）存储借阅记录。（8）删除预订记录。1.4.3替代流（Alternative Flow）E-1：该种书刊不存在，系统显示提示信息，用例终止。E-2：物理书刊都已借出，系统显示提示信息，用例终止。E-3：系统中不存在该借阅者，系统显示提示信息，用例终止。40用例的事件流描述：例用例的事件流描述：例5维护借阅者信息（Maintain Borrower Info）5.1前置条件（Pre-Conditions）在这个用例开始前，Librarian必须登录到系统中。5.2后置条件（Post-Conditions）如果这个

20、用例成功，系统添加、修改或删除借阅者信息。反之，系统的状态没有变化。5.3扩充点（Extension Points）没有。5.4事件流5.4.1基流（Basic Flow）当Librarian想维护借阅者信息时，用例启动，系统要求Librarian选择所想执行的活动（添加借阅者、删除借阅者、或修改借阅者）如果所选的活动是“添加借阅者”，则执行分支流S-1：添加借阅者。如果所选的活动是“删除借阅者”，则执行分支流S-2：删除借阅者。如果所选的活动是“修改借阅者”，则执行分支流S-3：修改借阅者。5.4.2分支流（Subflows）S-1：添加借阅者（1）提供借阅者的信息，如姓名、地址、邮政编码和

21、身份证号码等。（2）系统存储借阅者信息（E-1）。41用例的事件流描述：例用例的事件流描述：例S-2：删除借阅者（1）提供借阅者的信息。（2）查询借阅者（E-2）。（3）查询借阅者的借阅记录（E-3）。（4）从系统中删除借阅者的信息，以及借阅者的预订记录。S-3：更改借阅者（1）提供借阅者的信息。（2）查询并显示借阅者的信息（E-2），修改相应的信息。（3）更新系统中借阅者的信息。5.4.3替代流（Alternative Flow）E-1：若借阅者已存在，系统显示提示信息，用例终止。E-2：若查询不到借阅者，系统显示提示信息，用例终止。E-3：若存在借阅记录，系统显示提示信息，用例终止。42网

22、上选课系统用例图v需求： 某学校网上选课系统主要包括如下功能：管理员通过系统管理界面进入，建立本学期要开的各种课程、将课程信息保存在数据库中并可以对课程进行改动和删除。学生通过客户机浏览器根据学号和密码进入选课界面，可以查询课程、选课以及付费，这些结果存入数据库中。4344454647484950ATMATM取款用例图取款用例图51vATMATM取款用例图取款用例图 52v 用例编号用例编号:001:001v 用例名用例名:ATM:ATM取款取款v 用例描述用例描述: :储户使用信用卡，在储户使用信用卡，在ATMATM机上取款机上取款v 参与者：储户参与者：储户v 前置条件：前置条件：ATMA

23、TM机器处于正常准备状态机器处于正常准备状态v 后置条件：若成功，则储户取出钱，帐户上扣除钱；若失后置条件：若成功，则储户取出钱，帐户上扣除钱；若失败，储户没有取到钱，帐户上钱数不变。败，储户没有取到钱，帐户上钱数不变。v 基本路径基本路径 1, 1, 储户插卡；储户插卡； 2. ATM2. ATM机提示输入用户口令；机提示输入用户口令； 3.3.储户输入口令；储户输入口令； 4.ATM4.ATM机口令验证通过，提示输入钱数；机口令验证通过，提示输入钱数； 5.5.储户输入钱数；储户输入钱数； 6.ATM6.ATM机进行钱数有效性检查，提示操作成功，吐出机进行钱数有效性检查，提示操作成功，吐出

24、卡和钱；卡和钱；ATM取取款款用用例例描描述述53 7.7.储户取走卡和钱；储户取走卡和钱； 8.ATM8.ATM机屏幕恢复为初始状态。机屏幕恢复为初始状态。v 扩展点扩展点 4a. ATM4a. ATM机验证用户口令不通过机验证用户口令不通过 4a1. ATM4a1. ATM机给出提示信息，并吐出信用卡；机给出提示信息，并吐出信用卡； 4a2. 4a2. 储户取出卡；储户取出卡； 4a3. ATM4a3. ATM机屏幕恢复为初始状态机屏幕恢复为初始状态. . 6a. ATM 6a. ATM验证用户输入钱数超过验证用户输入钱数超过30003000 6a1. ATM 6a1. ATM机给出提示信

25、息，并吐出信用卡；机给出提示信息，并吐出信用卡； 6a2. 6a2. 储户取出卡；储户取出卡； 6a3. ATM6a3. ATM机屏幕恢复为初始状态机屏幕恢复为初始状态. .54简化银行系统的需求分析v域描述：银行是与生活紧密相关的一个机构，银行提供了存款、取款、转账等业务。在银行立账户的人或机构通常被称为银行的客户。一个客户可以在银行开多个账户，客户可以存钱到账户中，也可以从自己的账户中取钱，还可以将存款从一个账户转到另一个账户。客户还可以随时查询自己账户的情况，并查询以前所进行的存款、取款等交易记录。客户也有权利要求关闭账户。v在对上述银行系统的基本需求进行分析后，可知这个简化的银行系统至

26、少应该具有如下功能：一个银行可以有多个账户一个银行可以有多个客户一个客户可以持有多个账户一个账户可以有多个持有者可以开户可以注销账户可以取钱可以存钱可以在银行内的账户之间转账可以在不同银行的账户之间转账55用例图 CustomerActor Maintain Account Login Clerk Transfer fund within a bank Deposit fund Withdraw fund Transfer fund Clerk BankActor Transfer fund between banks 56用例的事件流描述例1 1 “Deposit fund”（存款）1.1

27、简单描述本用例允许客户借助Clerk存款到账户中。1.2 前置条件（Pre-Conditions）在本用例开始前，Clerk必须登录到系统中。1.3 后置条件（Post-Conditions）如果用例成功，则客户CustomerActor账户中存款的金额发生变化。否则，系统状态不变。1.4 扩充点（Extension Points）无。1.5 事件流1.5.1 基流（Basic Flow）当CustomerActor想存钱到自己的账户时，要向Clerk提交存款单和现金，用例启动。（1）系统提示Clerk输入用户姓名、用户的id号、账号和所存款项的金额。（2）Clerk输入相关信息后提交，系统确

28、认账户是否存在并有效（当用户名、用户id与账户的户主信息一致，且账户处于非冻结状态时，账户有效）（E-1）。（3）系统建立存款事件记录，并更新账户的相关信息。1.5.2 替代流（Alternative Flow）E-1：账户不存在或无效，显示提示信息，用户可以重新输入或终止该用例。57 input information submit pop up information dialog the account exists and valid? create transaction record yes display error message no save record into DB

29、update account system clerk 58用例的事件流描述例22 “Withdraw fund”（取款）2.1 简单描述本用例允许Clerk按照客户的要求从客户的账户中取款。2.2 前置条件（Pre-Conditions）在本用例开始前，用户必须登录到系统中。2.3 后置条件（Post-Conditions）如果用例成功，则客户CustomerActor账户中存款的金额发生变化。否则，系统状态不变。2.4 扩充点（Extension Points）无。2.5 事件流2.5.1 基流（Basic Flow）当Customer想从自己的账户中取钱时，要向Clerk提交取款单，用例

30、启动。（1）系统提示Clerk输入用户姓名、用户的id号、账号和取款金额。（2）Clerk输入相关信息后提交，系统确认账户是否存在并有效（当用户名、用户id与账户的户主信息一致，且账户处于非冻结状态时，账户有效）（E-1），账户中的存款金额是否足够支付所取款项（E-2）。（3）系统建立取款事件记录，并更新账户的相关信息。2.5.2 替代流（Alternative Flow）E-1：若账户不存在或无效，显示提示信息，用户可以重新输入或终止该用例。E-2：账户中的存款金额不足，显示提示信息，用户可以重新输入金额或终止该用例。59 input information submit account e

31、xists & valid? pop up information dialog display error message no money enough? yes create transaction record update account save record into DB no yes system clerk 60用例的事件流描述例33 “Transfer fund”（转账）3.1 简单描述本用例允许Clerk按照客户的要求将资金从一个账户转到另一个账户。3.2 前置条件（Pre-Conditions）在本用例开始前，用户必须登录到系统中。3.3 后置条件（Post-

32、Conditions）如果用例成功，则客户CustomerActor账户中存款的金额发生变化。否则，系统状态不变。3.4 扩充点（Extension Points）无。3.5 事件流3.5.1 基流（Basic Flow）当Customer要求转账时，用例启动（1）系统提示Clerk输入用户姓名、用户的id号、账户号码和转账金额。（2）Clerk输入相关信息后提交。（资金转入账户所在的银行只能在所提供的银行列表中选择）。（3）系统确认资金转出账户是否存在并有效（当用户名、用户id与账户的户主信息一致，且账户处于非冻结状态时，账户有效）（E-1），资金转出账户中的金额是否足够支付所转款项（E-2

33、）。（4）更新资金转出账户的相关信息。（5）为资金转出账户建立转账记录。（6）存储转账记录。（7）判断资金转入账户是否属于同一银行，如果资金转入账户与资金转出账户属于同一银行，则执行分支流S-1：在同一银行的账户间转账。如果资金转入账户与资金转出账户属于不同银行，则执行分支流S-2：在不同银行的账户间转账。61用例的事件流描述例33.5.2 分支流（Subflows）S-1：在同一银行的账户间转账（1）系统确认资金转入账户是否存在并有效（当账户处于非冻结状态时，账户有效）（E-1）。（2）更新资金转入账户的相关信息。（3）为资金转入账户建立转账记录。（4）存储转账记录。S-2：在不同银行的账户

34、间转账（1）发送转账通知给另一个银行。3.4.3 替代流（Alternative Flow）E-1：账户不存在或无效，显示提示信息，用户可以重新输入或终止该用例。E-2：账户中的存款金额不足，显示提示信息，用户可以修改所转款项的金额或终止该用例。62 input information submit s_account exists & valid? money enough in s_account? yes pop up information dialog display error message no create s_transfer record update s_acc

35、ount save s_transfer record in DB transfer within a bank? notify another bank d_accout exists & valid? update d_account create d_transfer record save d_transfer record in DB no yes yes no no yes system clerk 63示例：用例规约（示例：用例规约（include）启动Administrator管理用户SystemAdminCardProcessingCompany信用卡支付CheckP

36、rocessingCompany支票支付登录购买商品CashierInventory退还商品现金支付6465成绩管理用例图66676869用例粒度用例粒度70主要内容Rational Rose 简介 用例视图逻辑视图构件视图部署视图71 Rational Rose 是用来分析与设计面向对象软件系统的强大工具，也是当前最流行的可视化软件开发工具之一72模型图图标描述建模角度类图Class?diagram显示系统中的类和包，提供系统构件及其相互关系静态结构建模静态结构建模用例图Use-case?diagram用例图从用户的角度描述系统功能的使用者和主要的系统操作流程。显示用例与参与者及其相互关系系

37、统功能建模系统功能建模协作图Collaboration?diagram从对象组织结构的角度显示用例中特定情形的操作流程动态行为建模动态行为建模时序图Sequence?diagram按时间顺序显示用例中特定情形的操作流程动态行为建模动态行为建模状态图Statechart?diagram显示系统中类的对象所有可能的状态以及事件发生时状态的转换条件动态行为建模动态行为建模活动图Activity?diagram描述满足用例要求所需进行的活动以及活动间的关系的图动态行为建模动态行为建模构件图Component?diagram描述代码构件的物理结构以及构件之间的依赖关系。构件图有助于分析和理解组件之间的影

38、响程度静态结构建模静态结构建模部署图Deployment?diagram描述系统中的物理结构静态结构建模静态结构建模73标准工具条浏览区文档描述窗口日志图形工具条图形窗口74 从菜单中选择FileNew，或标准工具栏中的New按钮 选择可用框架或单击Cancel不用75n从菜单中选择FileSave 或n标准工具栏中的Save按钮nROSE模型都以扩展名为.mdl的文件进行保存，这个文件包括了所有的模型图，对象和其它 模型元素76视图是对模型中逻辑元素的可视化表示ROSE提供了四种视图用例视图逻辑视图构件视图部署视图只关心系统的高级功能，不关心系统的具体实现细节。包括：用例图，活动图，交互图，

39、包 浏览区窗口中的视图关注系统如何实现用例中提到的功能包括：类，类图，交互图，状态图，活动图，包可看出系统实现的物理结构，包括：构件，构件图，包 关心系统的实际部署情况。77主要内容Rational Rose 简介 用例视图逻辑视图构件视图部署视图78 用例视图图形化地说明了一个系统涉及到的所有参与者，用例和用例图。此外还包括一些交互图（时序图，协作图）。用例视图是系统中与实现无关的视图。用例视图关注系统功能的高层形状，而不关注系统的具体实现方法79用例图用例视图参与者用例关联808182注意：删除用例图不会删除其中的模型要素。Rose不允许删除主用例图（Main）83选择工具文本注释连接注释

40、包用例参与者关联依赖泛化84新建的模型元素自动加入用例视图85拖动至适当位置放开拖动至适当位置放开86 仅从用例图中删除 选择元素后按Delete 从整个模型中删除 选择模型图中的元素后按Ctrl+D 或菜单EditDelete from Model87 规范窗口允许显示和修改模型元素的细节信息88 参与者与类使用相同的规范窗口 窗口中与参与者有关的标签是 General 标签 Detail 标签 Relations 标签 Files 标签定义参与者名称指定参与者的构造型，参与者只有一种构造型actor描述参与者89 规范窗口显示和修改用例的属性和关系 通用标签 模型图标签 关系标签 文件标签

41、构造型一般不用于用例，需要可以增加90与其他用例或参与者存在的关联所涉及的辅助文档91 关联关系 从启动信息方拖动到另一方 泛化关系 从具体用例（或参与者）拖动到另一方 扩展关系和包含关系 在泛化关系的规范窗口中设定相应的构造型92 主要参与者： 出纳员 前置条件： 出纳员需要身份识别并进行授权 后置条件：存储了销售情况，正确地计算了税金，更新了账目和存货清单，记录了销售额，打印了收据。93主要的成功场景： 1.顾客带着商品到POS终端准备购买 2.出纳员开始一次新的销售。 3.出纳员输入商品标识码。 4.系统记录销售的商品并给出商品的描述、 单价和折扣，并根据某些价格规则计算所应付的款额。出

42、纳员重复步骤3和步骤 4，一直到处理完所有商品为止。 5.系统给出所应支付的总款额并计算税金。 6. 出纳员告诉顾客总价并请求付款。 7.顾客付款，系统处理支付。 8.系统记录下已完成的销售，并将销售和支付信息发送给外部的账目系统（用于账目和销售额）以及存货清单系统（用来更新存货清单） 9.系统打印收据 10. 顾客带着收据和商品离开（如果买了商品）94 扩展： 在系统失败时，要恢复和校正账目，确保所有的交易敏感状态以及事件能够从场景的任何步骤中恢复。 1.出纳员重启系统和登录，并请求恢复先前的状态。 2. 系统重建先前的状态。 2a. 系统检测阻止恢复的异常状态： 1. 系统给出出纳员发一个

43、出错信号，记录该错误并进入一个干净的状态。 2. 出纳员开始一次新的销售。 3a. 无效的标识码： 1.系统发一个出错信号并拒绝输入。 3b. 顾客可能会购买多件相同类别的商品，因此记不记录每件商品的唯一标识码并不重要（例如：3袋洗衣粉） 1. 出纳员可以输入商品类别号以及数量95 3-6a: 顾客请求出纳员从购买的货物中去掉一件商品： 1.出纳员输入不想要的商品的标识码 2.系统显示更新后的总价格。 3-6b 顾客告诉出纳员取消销售： 1. 出纳员在系统上取消销售。 5a. 系统检测到和外部税金计算机系统之间的通信失败： 1.系统发出一个出错信号。 2.出纳员可以手动计算并输入税金，或取消此

44、次销售。96 5b.顾客说他们符合打折条件 1.出纳员发出打折请求。 2.出纳员输入顾客的标识码。 3.系统根据打折规则计算出折扣总额 7a. 用现金付账： 1.出纳员输入顾客所付的总款数。 2. 系统计算出应找的余款，并弹出现金抽屉。 3.出纳员存放现金并找零给顾客。 4.系统记录此次现金支付情况。97 7b. 用信用卡付账： 1.顾客输入他们的信用卡账户信息。 2. 系统向外部支付授权服务系统发出支付授权请求，并请求支付批准。 2a. 系统检测到和外部系统之间协作上的失败： 1. 系统给出纳员一个出错信号。 2. 出纳员请顾客用其他方式付款。 3. 系统收到批准支付回应并向出纳员发出一个批

45、准支付信号。 3a. 系统收到拒绝支付信号： 1.系统发拒绝支付信号给出纳员。 2. 出纳员请顾客用其他方式付款。98 4.系统记录信用卡支付情况，其中包括批准支付情况。 5.系统给出信用卡支付签名输入机制。 6. 出纳员请客户进行信用卡支付签名，客户输入签名。7c. 顾客 拿出优惠劵 1. 在处理付款之前，出纳员记录每张优惠劵，系统降低商品价格。系统为了记账而记录下所使用的优惠劵。 1a. 所输入的优惠劵不能用在此次购买的商品上。 9. 商品打折： 1.系统给出打折的形式以及每种商品打折的收据。99特殊的需求： 在1m 之外看清屏幕上的文字 信用卡授权90%的情况下应能30s做出响应 文本显

46、示语言国际化尚未解决的问题： 税法变换了怎么办？ 是由顾客直接使用信用卡阅读器还是出纳员来使用？100101 用例名称：浏览目录 活动者：顾客 前置条件：网站可用 后置条件：购物篮中的已选条目 主要路线： 1.顾客从主页选择目录 2.显示出有缩略图的鞋样式列表。 3.选择鞋的样式。 4.显示鞋和价格列表。 5.选择一种鞋。 6.显示鞋的完整图片，当前的价格、尺寸、 库存和颜色列表。 7.顾客填写数量、尺码及颜色。 8 . 点击“add to basket” (加入购物篮）102103 用例名：发邮件 参与者：用户、服务器、数据库 入口条件：用户已完成写邮件操作 事件流： 用户选择”发送“；系统

47、将该邮件发送至服务器，保存已发送邮件到数据库；用户选择”取消“则回到系统界面 出口条件：系统发送邮件结束。 异常事件：网络故障、收件人地址不存在提示错误信息。104系统边界模糊或者变化无常系统边界模糊或者变化无常用例描写来自于系统（并非角色）用例描写来自于系统（并非角色）角色名称相互矛盾角色名称相互矛盾过多的用例过多的用例(需求有层次组织，高层一般不超过需求有层次组织，高层一般不超过12个左右用例，在接下来层次中，个左右用例，在接下来层次中，用例的数量不应超过当前用例用例的数量不应超过当前用例510倍）倍）角色和用例的关系连接象蜘蛛网一样（复杂）角色和用例的关系连接象蜘蛛网一样（复杂）用例叙述

48、规格过长用例叙述规格过长用例规格叙述混乱用例规格叙述混乱用例没有正确描述功能用例没有正确描述功能用户不可理解用例用户不可理解用例用例从来不会结束用例从来不会结束1051、定义准确的系统边界2、使用标准化模板书写用例规格3、观察点：只关注目标4、经常检查用例图和用例规格106选择比赛日期选择场馆区域亭售用户(from Actors)提交信用卡亭售用户(from Actors)选择比赛日期选择场馆区域订票提交信用卡107订票信用卡确认系统亭售用户(from Actors)查看赛程赛程管理员创建赛程订票信用卡确认系统亭售用户(from Actors)查看赛程赛程管理员创建赛程系统边界在哪里？系统边界

49、在哪里？108109110不是直接的相关于目标；经常会关联过多的角色111112113?读者?借阅图书?管理图书?管理员?管理用户权限114?管理员?管理角色?管理用户权限?管理用户?115 用例模型易于理解吗？ 避免二义性、不一致性。 满足了所有的功能需求吗？ 用例模型中有多余的行为吗？116 1.用例之间是否独立？(合并） 2.多个用例之间是否有非常相似的行为或事件流？（合并） 用例事件流的一部分是否已被构建为另一个用例？（include) 4.是否应该将一个用例的事件流插入另一个用例的事件流中？（extend)117检查检查Actor 识别了所有的Actor吗？ 每个Actor至少参与了

50、一个用例吗？ 每个Actor确实是一个角色(role)吗？是否应该合并或分解？ 是否有两个Actor在一个用例中扮演相同的角色？ Actor是否有直观的、描述性的名字？用户和客户是否能理解这些名字？118检查用例检查用例 每个用例中至少有一个actor吗？ 每个用例都独立于其他用例吗？如果两个用例总是以同样的顺序执行，也许应该合并成一个 有具有非常类似的行为或事件流程的用例吗？ 为了以后不会混淆，用例具有唯一的、直观的、说明性的名字吗？ 客户和用户能理解用例的名字和描述吗？119检查用例规约检查用例规约 谁要执行用例明确吗？ 用例的目的明确吗？ 简单的描述刻画了用例的真实情况吗？ 用例的时间流

51、程何时/如何开始/结束明确吗？Actor的交互和信息交换清晰吗？ 是否有过于复杂的用例？120 某市某局，需要在内部举办两种形式的会议：某市某局，需要在内部举办两种形式的会议： 召集下属区县相关部门开会；召集召集下属区县相关部门开会；召集局内相关处室开会；局内相关处室开会；对于每种会议都要：对于每种会议都要：1）由某处室的某人根据指令（来自该处室的负责人）起草会议文件；）由某处室的某人根据指令（来自该处室的负责人）起草会议文件；2）该文件经过该处的负责人批阅后，或返回起草人，进行重新修改；或上交给局）该文件经过该处的负责人批阅后，或返回起草人，进行重新修改；或上交给局办公室主任；办公室主任；3

52、）办公室主任进行批注，或返回给提交文件的处室负责人，说明不能按期进行的）办公室主任进行批注，或返回给提交文件的处室负责人，说明不能按期进行的理由；或提交给局领导审批；理由；或提交给局领导审批；4）局领导批准后，文件返回到局办公室主任；）局领导批准后，文件返回到局办公室主任；5）若局领导不同意，办公室主任把文件返回到提交该文件的处室负责人；处室负）若局领导不同意，办公室主任把文件返回到提交该文件的处室负责人；处室负责人做消会处理。责人做消会处理。6）若局领导同意，办公室主任通知办公室工作人员；）若局领导同意，办公室主任通知办公室工作人员；7）办公室工作人员通知）办公室工作人员通知，安排食宿；并向

53、，安排食宿；并向发会议通知；发会议通知；8）相关单位收到会议通知后，要向局办公室回复；）相关单位收到会议通知后，要向局办公室回复；9）会议结束后，召集会议的处室要形成会议纪要。）会议结束后，召集会议的处室要形成会议纪要。 121会议文件起草通知单会议文件起草通知单 处室负责人处室负责人: XXXX 日期：日期：XXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX会议文件会议文件 起草人：起草人：: XXXX 起草日期：起草日期：XXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX会议批文会议批

54、文 处室负责人处室负责人 : XXXX 批示日期：批示日期：XXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 办公室主任办公室主任: XXXX 批示日期：批示日期：XXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 局领导局领导: XXXX 批示日期：批示日期：XXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX拟订会议纪要通知单拟订会议纪要通知单 处室负责人处室负责人: XXXX 日期：日期：XXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

55、会议纪要会议纪要 纪要人：纪要人： XXX 纪要日期：纪要日期：XXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX122拟订发布会议通知单拟订发布会议通知单 办公室负责人办公室负责人: XXXX 日期：日期：XXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX会议通知会议通知(服务中心服务中心) 办公室工作人员办公室工作人员:XXXX 发送日期：发送日期：XXXX 通知标题：通知标题：XXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX会议通知会议通知(相关单位相关单位) 办公室工作人员办公室工作人员:XXXX 发送日期：发送日期：XXXX 通知标题：通知标题：XXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX123类型包括类型包括: 会议文件、批文、通知、纪要会议文件、批文、通知、纪要124125 某市某局，需要在内部举办两种形式的会议：某市某局，需要在内部举办两种形式的会议： 召集下属区县相关部门开会；召集召集下属区县相关部门开会；召集局内相关处室开会；局内相关处室开会；对于每种会议都要：对于每种