《uml建模语言及工具uml03new课件》由会员分享，可在线阅读，更多相关《uml建模语言及工具uml03new课件（141页珍藏版）》请在金锄头文库上搜索。
1、UML建模语言及工具建模语言及工具第三章第三章用例建模用例建模Use-Case ModelingReview: A Practice of Visual Modeling with UMLUML构造块构造块公共机制公共机制架构架构物件物件关系关系图图规格说明规格说明修饰修饰公共分类公共分类扩展机制扩展机制用例视图用例视图逻辑视图逻辑视图进程视图进程视图实现视图实现视图部署视图部署视图结构物件结构物件行为物件行为物件分组物件分组物件注解物件注解物件关联关联依赖依赖泛化泛化实现实现类图类图顺序图顺序图对象图对象图协作图协作图构件图构件图状态图状态图部署图部署图活动图活动图用例图用例图3UML 5类
2、类9种图种图类类 图：类以及类之间的相互关系图：类以及类之间的相互关系对象图：对象以及对象之间相互关系对象图：对象以及对象之间相互关系构件图：构件及其相互依赖关系构件图：构件及其相互依赖关系部署图：构件在各节点上的部署部署图：构件在各节点上的部署顺序图：强调时间顺序的交互图顺序图：强调时间顺序的交互图协作图：强调对象协作的交互图协作图：强调对象协作的交互图状态图：类所经历的各种状态状态图：类所经历的各种状态活动图：对工作流建模活动图：对工作流建模用例图：需求捕获，测试依据用例图：需求捕获，测试依据结结构构行行为为用例图用例图用例图用例图静态图静态图静态图静态图实现图实现图实现图实现图交互图交互
3、图交互图交互图行为图行为图行为图行为图4学习线路图学习线路图OOUMLOOAOODDP Case-Study 学学 习习 线线 路路 图图第二章第二章第三章第三章第四章第四章5本章目录本章目录3.1 前言前言 3.2 需求需求3.3 基于用例的需求分析过程基于用例的需求分析过程3.4 用例分析示例用例分析示例63.1 前言前言学习用例建模的必要性学习用例建模的必要性UML的局限性不可避免的局限性不可避免解决问题的客观需要解决问题的客观需要7UML的局限性的局限性1. 用用UML画图很容易画图很容易摆脱符号烦恼摆脱符号烦恼全心面对问题全心面对问题2. UML仅仅是一种表达形式仅仅是一种表达形式用
4、好用好UML首先需要掌握首先需要掌握OOAD的基本原则和的基本原则和方法方法，并在一定的，并在一定的软件开发过程软件开发过程（如统一过程（如统一过程UP/USDP/RUP、XP等）的指导下进行有取等）的指导下进行有取舍的运用舍的运用但知道要画什么是困难的！但知道要画什么是困难的！8认识问题认识问题认识问题认识问题分析问题分析问题分析问题分析问题解决问解决问解决问解决问题题题题最终用户最终用户最终用户最终用户( (提出问题提出问题提出问题提出问题) )开发团队开发团队开发团队开发团队( (解决问题解决问题解决问题解决问题) )认识问题认识问题认识问题认识问题分析问题分析问题分析问题分析问题解决问
5、解决问解决问解决问题题题题以以以以用户用户用户用户的身份站在的身份站在的身份站在的身份站在用户用户用户用户的的的的角度认识问题角度认识问题角度认识问题角度认识问题获取需求获取需求获取需求获取需求用例建模技术用例建模技术用例建模技术用例建模技术最终用户最终用户最终用户最终用户( (提出问题提出问题提出问题提出问题) )认识问题认识问题认识问题认识问题分析问题分析问题分析问题分析问题解决问解决问解决问解决问题题题题以以以以开发者开发者开发者开发者的身份站在的身份站在的身份站在的身份站在用户用户用户用户的角度分析问题的角度分析问题的角度分析问题的角度分析问题分析需求分析需求分析需求分析需求用例分析技
6、术用例分析技术用例分析技术用例分析技术认识问题认识问题认识问题认识问题分析问题分析问题分析问题分析问题解决问解决问解决问解决问题题题题以以以以开发者开发者开发者开发者的身份站在的身份站在的身份站在的身份站在开发开发开发开发团队团队团队团队的角度分析问题的角度分析问题的角度分析问题的角度分析问题解决需求解决需求解决需求解决需求面向对象设计面向对象设计面向对象设计面向对象设计开发团队开发团队开发团队开发团队( (解决问题解决问题解决问题解决问题) )本章目录本章目录3.1 前言前言 3.2 需求需求3.3 基于用例的需求分析过程基于用例的需求分析过程3.4 用例分析示例用例分析示例133.2 需求
7、需求什么是需求什么是需求需求理解的难点需求理解的难点需求应对的误区需求应对的误区需求采集的步骤需求采集的步骤14什么是需求什么是需求需求：系统必须满足的条件或具备的能力需求：系统必须满足的条件或具备的能力理解需求的目的：建造理解需求的目的：建造”正确正确”的系统的系统Robert Grady软件质量准则软件质量准则“FURPS”功能性（功能性（Functionality）使用性（使用性（Usability）可靠性（可靠性（Reliability）性能（性能（Performance）可支持性（可支持性（Supportability）非功能性需求非功能性需求15需求理解的难点需求理解的难点需求：石
8、头问题需求：石头问题我要一块石头我要一块石头差不多，但我要小一点的差不多，但我要小一点的很好，不过我要蓝色的很好，不过我要蓝色的啊，没有那么小啊，没有那么小咳，还是原来那个好了咳，还是原来那个好了 小一点的蓝色大理石小一点的蓝色大理石难难捕捕获获，易易变变！16需求应对的误区需求应对的误区客户客户/用户的要用户的要求求/想法想法/期望期望软件设计软件设计软件产品软件产品1.分析和设计分析和设计2.编码和测试编码和测试3.验收验收没价值的没价值的软件需求软件需求4.补文档补文档需求：如此脆弱需求：如此脆弱17需求：也需要开发需求：也需要开发客户客户/用户的要用户的要求求/想法想法/期望期望软件设
9、计软件设计软件产品软件产品1.开发开发3.编码和测试编码和测试4.验收验收有价值的有价值的软件需求软件需求2.分析和设计分析和设计18需求采集的步骤需求采集的步骤需求收集包括五个关键步骤需求收集包括五个关键步骤找到找到可以帮助你理解这个系统的可以帮助你理解这个系统的人人倾听这些相关人员的描述，并倾听这些相关人员的描述，并从他们的角度从他们的角度来理解系来理解系统统利用一个容易理解的模型利用一个容易理解的模型来描述用户希望如何使用这来描述用户希望如何使用这个系统以及为他们提供的什么价值个系统以及为他们提供的什么价值详细地描述系统和客户以及系统和外部系统之间的详细地描述系统和客户以及系统和外部系统
10、之间的交交互互重构重构（refactor）这个详细描述以保证它是可读且易）这个详细描述以保证它是可读且易懂的懂的19本章目录本章目录3.1 前言前言 3.2 需求需求3.3 基于用例的需求分析过程基于用例的需求分析过程3.4 用例分析示例用例分析示例203.3 基于用例的需求分析过程基于用例的需求分析过程需求问题对策需求问题对策以用例为中心的需求组织方式以用例为中心的需求组织方式基于用例的需求分析过程基于用例的需求分析过程补充需求规约补充需求规约何时适用用例建模何时适用用例建模学习的重学习的重点点21需求问题对策需求问题对策难捕获难捕获难捕获难捕获易变易变易变易变从用户视角从用户视角从用户视角
11、从用户视角看问题看问题看问题看问题合理的结构合理的结构合理的结构合理的结构用例用例22以用例为中心的需求组织方式以用例为中心的需求组织方式用例用例可用性可用性可用性可用性可靠性可靠性可靠性可靠性网络协议网络协议网络协议网络协议业务业务业务业务规则规则规则规则硬件接口硬件接口硬件接口硬件接口界面界面界面界面约束约束约束约束性能性能性能性能23基于用例的需求分析过程基于用例的需求分析过程1. 获取原始需求获取原始需求2. 开发一个可以理解的需求开发一个可以理解的需求2.1 识别参与者识别参与者2.2 识别用例识别用例2.3 构建用例图构建用例图3. 详细、完整地描述需求详细、完整地描述需求进行用例
12、阐述进行用例阐述4. 重构用例模型重构用例模型4.1 识别用例间的关系识别用例间的关系4.2 对用例进行组织和分包对用例进行组织和分包241. 获取原始需求获取原始需求学习内容学习内容获取需求的技巧获取需求的技巧一个考勤卡应用程序的例子一个考勤卡应用程序的例子25获取需求的技巧（获取需求的技巧（MSF）技巧技巧技巧技巧描述描述描述描述实地观察实地观察实地观察实地观察直接观察个人工作的情况，以发现现存的实践方式和问直接观察个人工作的情况，以发现现存的实践方式和问题题访谈访谈访谈访谈从个人处收集特定信息从个人处收集特定信息特定群体特定群体特定群体特定群体调查调查调查调查对一组人员进行调查，以便了解
13、工作态度和共同看法对一组人员进行调查，以便了解工作态度和共同看法问卷调查问卷调查问卷调查问卷调查收集详细数据和统计意义上比较重要的数据收集详细数据和统计意义上比较重要的数据用户指导用户指导用户指导用户指导让最终用户告诉你，他们是如何操作系统的让最终用户告诉你，他们是如何操作系统的原型制作原型制作原型制作原型制作模拟一个无法直接测试的系统模拟一个无法直接测试的系统统计版本统计版本统计版本统计版本使用具有统计功能的应用程序来记录用户完成任务的方使用具有统计功能的应用程序来记录用户完成任务的方式式26获取需求：考勤卡应用程序获取需求：考勤卡应用程序初次访谈记录初次访谈记录初次访谈记录初次访谈记录开发
14、者开发者：谁将使用这个应用程序？客客 户户：所有用它来记录可记帐以及不可记帐的工时的雇员开发者开发者：现在考勤卡应用程序是什么样的？客客 户户：每半个月就用一个Excel表格来记录。每个雇员都将通过他的表格填好，然后用电子邮件发给我。这个表格相当标准：纵向是收费项目代码，横向是日期。雇员可以在每个条目上填写说明。开发者开发者：这个收费项目代码可以从什么地方得到？开发者开发者：谁来管理收费项目代码？客客 户户：嗯，必要的时候由我来添加这个代码。而每个经理总会告诉他的下属应该填写什么。27基于用例的需求分析过程基于用例的需求分析过程1. 获取原始需求获取原始需求 2. 2. 开发一个可以理解的需求
15、开发一个可以理解的需求开发一个可以理解的需求开发一个可以理解的需求2.1 识别参与者识别参与者2.2 识别用例识别用例2.3 构建用例图构建用例图3. 详细、完整地描述需求详细、完整地描述需求进行用例阐述进行用例阐述4. 重构用例模型重构用例模型4.1 识别用例间的关系识别用例间的关系4.2 对用例进行组织和分包对用例进行组织和分包282.1 识别参与者识别参与者学习内容学习内容参与者定义参与者定义参与者要点参与者要点关于识别参与者的思考题关于识别参与者的思考题识别参与者思路识别参与者思路参与者的重要性参与者的重要性参与者的泛化参与者的泛化泛化关系的误用泛化关系的误用29参与者定义参与者定义参
16、与者，参与者，Actor关键词：关键词：边界边界参与者：在参与者：在系统之外系统之外，透过，透过系统边界系统边界与系统与系统进行进行有意义交互的任何事物有意义交互的任何事物30参与者要点参与者要点系统外系统外参与者代表在系统边界之外的真实事物，并参与者代表在系统边界之外的真实事物，并不是系统的成分不是系统的成分系统边界系统边界参与者透过系统边界参与者透过系统边界直接直接与系统交互，参与与系统交互，参与者的确定代表者的确定代表系统边界系统边界的确定的确定有意义的交互有意义的交互任何事物任何事物人、外系统、外部因素、时间人、外系统、外部因素、时间31思考思考1：识别参与者识别参与者?寻呼台系统：用
17、户如果预定了天气预报，系统寻呼台系统：用户如果预定了天气预报，系统每天定时给他发天气消息；如果当天气温高于每天定时给他发天气消息；如果当天气温高于35度，还要提醒用户注意防暑；度，还要提醒用户注意防暑；在这个叙述里，谁是寻呼台系统的在这个叙述里，谁是寻呼台系统的Actor？用户？气温？时间？用户？气温？时间？32思考思考2：识别参与者识别参与者?仪器分析系统仪器分析系统一系列样品溶液在分析仪器上进行测试一系列样品溶液在分析仪器上进行测试，实实验员把每个样品的数据输入计算机验员把每个样品的数据输入计算机，最后系最后系统对数据进行分析统对数据进行分析，并给出分析结果并给出分析结果.33思考思考3：
18、识别参与者识别参与者?订货系统订货系统客户给销售员发来传真订货客户给销售员发来传真订货，销售员在下班销售员在下班前将当日订货单汇总输入系统前将当日订货单汇总输入系统.34思考思考4：识别参与者识别参与者?猪圈自动供食供水系统猪圈自动供食供水系统猪的前蹄触发一个开关系统就供食或供水。猪的前蹄触发一个开关系统就供食或供水。这里的这里的Actor 是小猪是小猪35题外话：小人与圣小猪题外话：小人与圣小猪(1)众所周知，众所周知，use case 图里的图里的actor 用一个小用一个小人表示。但是这个小人极具误导性，往往让初人表示。但是这个小人极具误导性，往往让初学者（包括客户）理解为一个真实的人。
19、大多学者（包括客户）理解为一个真实的人。大多数数UML 学习者都要花好长一段时间来搞明白学习者都要花好长一段时间来搞明白小人其实不一定代表的是人，而是很抽象的系小人其实不一定代表的是人，而是很抽象的系统不可控的外部因素，比如说另一个系统。那统不可控的外部因素，比如说另一个系统。那么为什么不干脆么为什么不干脆用其它的符号来表示用其它的符号来表示Actor 呢呢？对于最后一个例子，在对于最后一个例子，在use case 图里用小猪图里用小猪代替原来的小人不是更易于交流吗？代替原来的小人不是更易于交流吗？36小人与圣小猪小人与圣小猪(2)37思考思考5：参与者与系统边界：参与者与系统边界?某企业要求
20、开发一个企业信息管理系统，并某企业要求开发一个企业信息管理系统，并与原来已有的库存系统相连接与原来已有的库存系统相连接某企业要求开发一个企业信息管理系统，并某企业要求开发一个企业信息管理系统，并把原来已有的库存管理系统加以改造，成为把原来已有的库存管理系统加以改造，成为企业信息管理系统的一部分企业信息管理系统的一部分38思考思考6：识别参与者：识别参与者?商品销售系统商品销售系统顾客通过网络下单以后顾客通过网络下单以后，系统计算出总计金系统计算出总计金额额，税金税金，运费运费，并将数目传递给一个外挂并将数目传递给一个外挂的会计系统的会计系统，该系统是另外购买的该系统是另外购买的.39识别参与者
21、思路识别参与者思路谁使用系统的主要功能谁使用系统的主要功能谁改变系统的数据谁改变系统的数据谁从系统获取信息谁从系统获取信息谁需要系统的支持以完成日常工作任务谁需要系统的支持以完成日常工作任务谁负责日常维护、管理并保证系统正常运行谁负责日常维护、管理并保证系统正常运行系统需要应付（处理）那些硬设备系统需要应付（处理）那些硬设备系统需要和那些外部系统交互系统需要和那些外部系统交互谁（或什么）对系统运行产生的结果（值）感兴谁（或什么）对系统运行产生的结果（值）感兴趣趣时间、气温等内部外部条件时间、气温等内部外部条件40识别参与者：考勤卡系统识别参与者：考勤卡系统开发者开发者：谁将使用这个应用程序？客
22、客 户户：所有用它来记录可记帐以及不可记帐的工时的雇员雇员雇员雇员开发者开发者：现在考勤卡应用程序是什么样的？客客 户户：每半个月就用一个Excel表格来记录。每个雇员都将通过他的表格填好，然后用电子邮件发给我。这个表格相当标准：纵向是收费项目代码，横向是日期。雇员可以在每个条目上填写说明。开发者开发者：这个收费项目代码可以从什么地方得到？开发者开发者：谁来管理收费项目代码？客客 户户：嗯，必要的时候由我（业务经理）（业务经理）（业务经理）（业务经理）来添加这个代码。而每个经理总会告诉他的下属应该填写什么。41参与者的重要性参与者的重要性识别用例之前识别用例之前重要重要有助于识别用例，宁多勿少
23、有助于识别用例，宁多勿少开始书写用例文档以后开始书写用例文档以后不重要不重要涉及的参与者太多涉及的参与者太多测试和部署阶段测试和部署阶段重要重要需要从参与者的角度考虑需要从参与者的角度考虑42参与者的泛化：责任重叠参与者的泛化：责任重叠Generalization A generalization from an actor A to an actor B indicates that an instance of A can communicate with the same kinds of use-case instances as an instance of B如系统中经理可以参加雇
24、如系统中经理可以参加雇员的所有用例员的所有用例43泛化关系的误用泛化关系的误用无意义的参与者无意义的参与者, 不访问任何用例不访问任何用例442.2 识别用例识别用例学习内容学习内容用例定义用例定义用例要点用例要点用例与功能的区别用例与功能的区别用例的命名用例的命名用例粒度用例粒度关于识别用例的思考题关于识别用例的思考题45用例定义用例定义关键词：价值关键词：价值定义定义用例实例是用例实例是系统执行系统执行的的一系列动作一系列动作，这些动，这些动作将生成特定作将生成特定参与者可观测参与者可观测的的结果值结果值一个用例定义一个用例定义一组用例实例一组用例实例参与者参与者使用系统使用系统达到目标达
25、到目标46识别用例：考勤卡系统识别用例：考勤卡系统开发者开发者：谁将使用这个应用程序？客客 户户：所有用它来记录可记帐以及不可记帐的工时记录可记帐以及不可记帐的工时记录可记帐以及不可记帐的工时记录可记帐以及不可记帐的工时的雇员雇员雇员雇员开发者开发者：现在考勤卡应用程序是什么样的？客客 户户：每半个月就用一个Excel表格来记录。每个雇员都将通过他的表格填好，然后用电子邮件发给我。这个表格相当标准：纵向是收费项目代码，横向是日期。雇员可以在每个条目上填写说明。开发者开发者：这个收费项目代码可以从什么地方得到？开发者开发者：谁来管理收费项目代码管理收费项目代码管理收费项目代码管理收费项目代码？客
26、客 户户：嗯，必要的时候由我（业务经理）（业务经理）（业务经理）（业务经理）来添加这个代码。而每个经理总会告诉他的下属应该填写什么。47用例要点用例要点可观测可观测用例止于系统边界用例止于系统边界结果值结果值用例是有意义的目标用例是有意义的目标系统执行系统执行结果值由系统生成结果值由系统生成由参与者观测由参与者观测业务语言、用户观点业务语言、用户观点一组用例实例一组用例实例用例的粒度用例的粒度48要点：用例止于系统边界要点：用例止于系统边界描述交互，而不是内在的系统活动描述交互，而不是内在的系统活动描述交互，而不是内在的系统活动描述交互，而不是内在的系统活动49要点：有意义的目标要点：有意义的
27、目标50要点：结果值由系统生成要点：结果值由系统生成系统需要处理的，由系统生成系统需要处理的，由系统生成系统需要处理的，由系统生成系统需要处理的，由系统生成51要点：业务语言而非技术语言要点：业务语言而非技术语言用户词汇，而不是技术词汇用户词汇，而不是技术词汇如：发票，商品，洗衣机如：发票，商品，洗衣机而不是：记录，字段，而不是：记录，字段，COM，C+等等52要点：用户观点而非系统观点要点：用户观点而非系统观点用户观点用户观点用户观点用户观点系统观点系统观点系统观点系统观点53用例用例 VS. 功能功能呼叫某人呼叫某人接听电话接听电话发送短信发送短信记住电话号码记住电话号码传输传输/接收接收
28、电源电源/基站基站输入输出（显示、键盘）输入输出（显示、键盘）电话簿管理电话簿管理用户观点用户观点用户观点用户观点系统观点系统观点系统观点系统观点54用例的命名用例的命名执行者视角：执行者视角：（状语）动词（状语）动词+（定语（定语+ ）宾语）宾语55用例粒度用例粒度-1用例要有路径，路径要有步骤；而这一切用例要有路径，路径要有步骤；而这一切都是可观测的都是可观测的最常犯错误：粒度过细，陷入功能分解最常犯错误：粒度过细，陷入功能分解过细的粒度，一般都会导致技术语言的描述，过细的粒度，一般都会导致技术语言的描述，而不再是业务语言而不再是业务语言56用例粒度用例粒度-2把步骤当用例把步骤当用例把系
29、统活动当用例把系统活动当用例57用例粒度用例粒度-3“四轮马车四轮马车”C(Create)R(Read)U(Update)D(Delete)所有业务最终对会成为所有业务最终对会成为CRUD？CRUD能为能为Actor提供价提供价值？值？CRUD掩盖业务，掩盖业务，锐变成关系数据库的建模：锐变成关系数据库的建模：“系统就是数据的增删改查系统就是数据的增删改查”关心数据的存储和维护，反而忽略了用户的目的关心数据的存储和维护，反而忽略了用户的目的58用例粒度用例粒度-4如果确实是如果确实是CRUD？如果如果CRUD不涉及复杂的交互，一个用例不涉及复杂的交互，一个用例“管理管理”即可即可不管是不管是C
30、、R、U、D，都是为了完成，都是为了完成“管理管理”目标目标甚至很多种的基本数据管理都可以用一个用例表示甚至很多种的基本数据管理都可以用一个用例表示59用例粒度用例粒度-5灵活处理灵活处理CRUD可以把包含复杂交互的路径独立出去形成用例可以把包含复杂交互的路径独立出去形成用例可以把包含复杂交互的路径独立出去形成用例可以把包含复杂交互的路径独立出去形成用例60思考题：分析下列用例思考题：分析下列用例Email客户端（如：客户端（如：outlook express），），A在北京发邮件给上海的在北京发邮件给上海的B，系统提醒，系统提醒B你有你有“新新邮件邮件”，B收邮件收邮件61思考：识别用例思考
31、：识别用例-262思考题思考题:识别电梯系统的用例识别电梯系统的用例电梯电梯参与者和用例参与者和用例63642.3 构建用例图构建用例图学习内容学习内容用例图示例用例图示例用例图构建过程示例用例图构建过程示例识别参与者识别参与者候选参与者候选参与者识别用例识别用例65用例图示例用例图示例66用例图构建过程示例：用例图构建过程示例：POST系统系统销售点终端（销售点终端（Point-Of-Sale Terminal，POST）系统）系统是一个计算机自动化系统是一个计算机自动化系统用来记录商品销售信息用来记录商品销售信息处理客户的支付信息处理客户的支付信息客户可以使用现金、信用卡、支票等多种支付手
32、段客户可以使用现金、信用卡、支票等多种支付手段主要用于零售的百货商店主要用于零售的百货商店包括计算机和条形码扫描仪等硬件设备和系统运行包括计算机和条形码扫描仪等硬件设备和系统运行软件软件67识别参与者识别参与者-1谁使用系统的主要功能谁使用系统的主要功能 出纳员出纳员Cashier谁改变系统的数据谁改变系统的数据出纳员出纳员Cashier谁从系统获取信息谁从系统获取信息出纳员出纳员Cashier，顾客，顾客Customer，系统管理员，系统管理员SystemAdmin谁需要系统的支持以完成日常工作任务谁需要系统的支持以完成日常工作任务出纳员出纳员Cashier，系统管理员，系统管理员Syste
33、mAdmin68识别参与者识别参与者-2谁负责日常维护、管理并保证系统正常运行谁负责日常维护、管理并保证系统正常运行系统管理员系统管理员SystemAdministrator系统需要应付（处理）那些硬设备系统需要应付（处理）那些硬设备无无系统需要和那些外部系统交互系统需要和那些外部系统交互可与库存系统可与库存系统Inventory、信用卡系统、信用卡系统CardProcessingCompany、支票处理系统、支票处理系统CheckProcessingCompany等交互等交互谁谁(或什么或什么)对系统运行产生的结果对系统运行产生的结果(值值)感兴趣感兴趣出纳员出纳员Cashier，顾客，顾客
34、Customer69候选参与者候选参与者70识别用例：识别用例：POST71基于用例的需求分析过程基于用例的需求分析过程1. 获取原始需求获取原始需求2. 开发一个可以理解的需求开发一个可以理解的需求2.1 识别参与者识别参与者2.2 识别用例识别用例2.3 构建用例图构建用例图 3 3 详细、完整地描述需求详细、完整地描述需求详细、完整地描述需求详细、完整地描述需求进行用例阐述进行用例阐述4 重构用例模型重构用例模型4.1 识别用例间的关系识别用例间的关系4.2 对用例进行组织和分包对用例进行组织和分包723 描述需求描述需求学习内容学习内容用例规约文档用例规约文档谁来写用例规约文档谁来写用
35、例规约文档用例规约组成用例规约组成前置后置条件前置后置条件事件流描述要点事件流描述要点用例规约示例和场景示例用例规约示例和场景示例活动图在用例需求分析中的作用活动图在用例需求分析中的作用用例小结用例小结73进行用例阐述：写用例规约进行用例阐述：写用例规约用例规约：更进一步的精度用例规约：更进一步的精度用例文档的核心，作为用例文档的总图用例文档的核心，作为用例文档的总图进一步的精度：有层次的文档进一步的精度：有层次的文档文档中每一句话都有其价值文档中每一句话都有其价值用例图是骨架，而用例规约则是其内在的肉用例图是骨架，而用例规约则是其内在的肉用例图是骨架，而用例规约则是其内在的肉用例图是骨架，而
36、用例规约则是其内在的肉74谁来写用例规约文档谁来写用例规约文档最完美：最完美：业务人员接受训练，写出优美的用例文档业务人员接受训练，写出优美的用例文档最现实：最现实：业务人员提供素材，开发人员写用例文档业务人员提供素材，开发人员写用例文档最糟糕：最糟糕：业务人员不管，完全由开发人员杜撰业务人员不管，完全由开发人员杜撰75用例规约组成用例规约组成用例名称用例名称用例标识用例标识涉及的参与者涉及的参与者描述描述用例的规格说明用例的规格说明前置条件前置条件 PreConditions后置条件后置条件 PostConditions正常事件流正常事件流 Flow of events备选事件流备选事件流
37、Alternate flow其它其它非功能需求、设计约束、尚存在的问题非功能需求、设计约束、尚存在的问题76前置、后置条件前置、后置条件-1前置条件约束在用例开始前前置条件约束在用例开始前系统的状态系统的状态把它们看做是看门人，它阻把它们看做是看门人，它阻止参与者触发该用例直到满止参与者触发该用例直到满足所有条件足所有条件说明在用例触发之前什么必说明在用例触发之前什么必须为真须为真后置条件约束用例执行后系后置条件约束用例执行后系统的状态统的状态用例执行后什么必须为真用例执行后什么必须为真对于有多个事件流的用例，对于有多个事件流的用例，则应该有多个后置条件则应该有多个后置条件77前置、后置条件前
38、置、后置条件-2某些用例依赖于其他用例某些用例依赖于其他用例一个用例在离开系统时，可能是另一个用例的前置一个用例在离开系统时，可能是另一个用例的前置条件（例如：条件（例如：“登录登录”和和“管理系统管理系统”）有助于识别漏掉的用例有助于识别漏掉的用例如果一个用例的前置条件不能有执行其他用例满足，如果一个用例的前置条件不能有执行其他用例满足，可能意味着丢失了用例（例如：可能意味着丢失了用例（例如：“管理订单管理订单”却没却没有有“登录登录”用例）用例）78用例交互四部曲用例交互四部曲-事件流事件流1. 动动 作作4. 回回 应应2.改变改变3.验证验证系系 统统写：可观测的、体现客户利益的文字写
39、：可观测的、体现客户利益的文字写：可观测的、体现客户利益的文字写：可观测的、体现客户利益的文字79事件流描述要点事件流描述要点1.只书写只书写“可观测可观测”的（说人话）的（说人话）2.使用主动语句使用主动语句3.句子必须以参与者或系统作为主语句子必须以参与者或系统作为主语4.不要涉及界面细节不要涉及界面细节5.分支和循环分支和循环80要点要点1：只写：只写“可观测可观测”的的系统通过系统通过ADO建立数据库连接，传送建立数据库连接，传送SQL查询语句，从查询语句，从“商品表商品表”查询商品查询商品的详细信息的详细信息系统按照查询条件搜索商品的详细信息系统按照查询条件搜索商品的详细信息81要点
40、要点2：主动语句：主动语句欧文丛贝克汉姆处得到传球，守门员欧文丛贝克汉姆处得到传球，守门员贝克汉姆传球给欧文，欧文射门，守门贝克汉姆传球给欧文，欧文射门，守门员扑救员扑救出纳员出纳员系统系统82要点要点3：以参与者或系统作主语：以参与者或系统作主语参与者参与者系统系统出纳员接收顾客的付款出纳员接收顾客的付款顾客的付款数可能顾客的付款数可能高于商品总额高于商品总额出纳员录入顾客所付的现金总额出纳员录入顾客所付的现金总额系统显示出应找还给顾客的余额，打印付款系统显示出应找还给顾客的余额，打印付款收据收据83要点要点4：不涉及界面细节：不涉及界面细节会员从下拉框中选择类别会员从下拉框中选择类别会员在
41、相应文本框中输入查询条件会员在相应文本框中输入查询条件会员点击会员点击“确定确定”按钮按钮84要点要点5：分支和循环：分支和循环分支：放到扩展路径分支：放到扩展路径参与者的选择参与者的选择另一条成功线路另一条成功线路系统进行验证系统进行验证循环：直接描述循环：直接描述85用例规约：记录时间用例规约：记录时间UC01：“Record Time”用例文档用例文档用例名称：用例名称：Record Time（记录时间）（记录时间）用例标识：用例标识：UC01涉及的参与者：涉及的参与者：雇员、系统管理员描述：描述：雇员利用“Record Time”用例来登记他们的工时 系统管理员用这个用例为任何雇员登记
42、时间前置条件：前置条件：用户必须已经登录到这个系统后置条件：后置条件：系统将雇员的工时正确的记录到数据库中86用例规约：记录时间用例规约：记录时间(续续)正常事件流：正常事件流：1.雇员查看当前时间之前输入的数据；2.雇员从已有的支付号码中选择一个，这些收费代码是按客户和项目组织的；3.雇员从当前的时间段选择一个日期；4.雇员输入以正整数表示的工时；5.系统在视图中显示这个数据，并在以后的视图中看到这个数据。备选事件流备选事件流1：雇员更改他的时间雇员更改他的时间1.雇员查看当前时间之前输入的数据；2.雇员选择一个已有的条目；3.雇员改变工时；4.在视图中更新这个信息，并在以后的视图中都可以看
43、到。87用例规约：记录时间用例规约：记录时间(续续)非功能需求：非功能需求：无设计约束：设计约束：无部署约束：部署约束：用户可以从客户端或雇员的家中访问到“Record Time”用例，如果是从客户端访问，则要考虑到客户端的防火墙未解决的问题未解决的问题雇员是否可以在以前的考勤卡上输入和更改时间雇员是否可以在以后的考勤卡上输入和更改时间，例如，在休假之前？88活动图活动图-推荐的使用场合推荐的使用场合 分析用例：分析用例：分析用例：分析用例：能直观清晰地分析用例，了解应当能直观清晰地分析用例，了解应当采取哪些动作以及这些动作之间的依赖关系。采取哪些动作以及这些动作之间的依赖关系。一张完整的活动
44、图是所有用例的集成图一张完整的活动图是所有用例的集成图 理解牵涉多个用例的工作流：理解牵涉多个用例的工作流：理解牵涉多个用例的工作流：理解牵涉多个用例的工作流：在难于区分不同在难于区分不同用例而对整个系统的工作过程又十分清楚时，用例而对整个系统的工作过程又十分清楚时，可以先构造活动图可以先构造活动图89活动图活动图-简述用例流程简述用例流程目的目的:分分析用例析用例90Use Case 小结小结-1Use Case的获取分两步：的获取分两步：要获取要获取Actor，请对用户客户提问：，请对用户客户提问：谁使用系统的主要功能（谁使用系统的主要功能（Primary Actor）？）？谁需要系统支持
45、他们的日常工作？谁需要系统支持他们的日常工作？谁来维护、管理系统（谁来维护、管理系统（Secondary Actor）？）？系统需要控制哪些硬件？系统需要控制哪些硬件？系统需要与其他哪些系统交互？系统需要与其他哪些系统交互？对系统产生的结果感兴趣的是哪些人或事物？对系统产生的结果感兴趣的是哪些人或事物？91Use Case小结小结-2要获取要获取Use Case，请对，请对Actor提问：提问：Actor要做的是什么、要求系统提供哪些功能？要做的是什么、要求系统提供哪些功能？Actor需要读、产生、删除、修改或存储系统中的需要读、产生、删除、修改或存储系统中的信息有哪些类型？信息有哪些类型？必
46、须提醒必须提醒Actor的系统事件有哪些？的系统事件有哪些？Actor必须提醒系统的事件有哪些？怎样把这些事必须提醒系统的事件有哪些？怎样把这些事件表示成件表示成Use Case中的功能？中的功能？92Use Case小结小结-3还可以考虑两个问题：还可以考虑两个问题：系统需要何种输入输出？它们从哪里来往哪里去？系统需要何种输入输出？它们从哪里来往哪里去？现存的系统究竟有什么主要问题，以至于要换掉它现存的系统究竟有什么主要问题，以至于要换掉它？若直接总结若直接总结Use Case有困难，用有困难，用场景场景帮忙：帮忙：基于场景和基于场景和Use Case的需求提取：现实场景的需求提取：现实场景
47、想想象场景象场景快速、小型原型快速、小型原型系统描述系统描述 Use Case形式的需求定义。形式的需求定义。难于区分不同用例而对整个系统的工作过程又难于区分不同用例而对整个系统的工作过程又十分清楚时，可以先构造十分清楚时，可以先构造活动图活动图93基于用例的需求分析过程基于用例的需求分析过程1. 获取原始需求获取原始需求2. 开发一个可以理解的需求开发一个可以理解的需求2.1 识别参与者识别参与者2.2 识别用例识别用例2.3 构建用例图构建用例图3 详细、完整地描述需求详细、完整地描述需求进行用例阐述进行用例阐述 4 4 重构用例模型重构用例模型重构用例模型重构用例模型4.1 识别用例间的
48、关系识别用例间的关系4.2 对用例进行组织和分包对用例进行组织和分包944.1 识别用例间的关系识别用例间的关系学习内容学习内容扩展关系扩展关系扩展关系示例扩展关系示例扩展关系误用扩展关系误用识别扩展点思路识别扩展点思路扩展关扩展关系图示系图示包含关系包含关系包含关系示例包含关系示例包含关系误用包含关系误用包含关系图示包含关系图示泛化关系泛化关系基于用例关系重构基于用例关系重构的两例子的两例子用例关系的准则用例关系的准则95用例关系用例关系ExtendIncludeGeneralization96关系的含义关系的含义Extend分离扩展路径分离扩展路径Include提取公共步骤，便于复用提取公
49、共步骤，便于复用Generalization同一业务目的的不同技术实现同一业务目的的不同技术实现97扩展关系扩展关系基用例路径本身是完整的基用例路径本身是完整的，它也可能是一条扩，它也可能是一条扩展路径展路径扩展路径步骤多扩展路径步骤多扩展路径内部还有扩展点扩展之扩展扩展路径内部还有扩展点扩展之扩展扩展路径未定或容易变化分离以扩展路径未定或容易变化分离以“冻结冻结”基用例基用例98扩展关系示例扩展关系示例罚款罚款99扩展关系误用扩展关系误用100识别扩展点思路识别扩展点思路执行者的选择执行者的选择系统验证系统验证步骤失败步骤失败101扩展关系扩展关系图示图示102包含关系包含关系包含（包含（i
50、nclude）关系将一个用例合并到另一个）关系将一个用例合并到另一个用例的行为序列中用例的行为序列中被包含的用例就像是被包含的用例就像是子程序子程序某些步骤某些步骤在多个用例重复出现，且单独形成价值在多个用例重复出现，且单独形成价值用例步骤较多用例步骤较多时，可用时，可用Include简化（慎用）简化（慎用）103包含关系示例包含关系示例104包含关系误用包含关系误用105包含关系包含关系图示图示106泛化关系泛化关系同一业务目的不同技术实现：同一业务目的不同技术实现：一个用例可以特化另一个更普通用例（更普通用例一个用例可以特化另一个更普通用例（更普通用例泛化特殊用例）泛化特殊用例）UML 1
51、.5: 用例间的泛化关系表明子用例包含父用用例间的泛化关系表明子用例包含父用例中定义的所有属性、行为序列和扩展点，并且参例中定义的所有属性、行为序列和扩展点，并且参与父用例中所有的关系与父用例中所有的关系107重构后的用例图：重构后的用例图：POST108重构后的用例图：考勤卡系统重构后的用例图：考勤卡系统109用例关系的准则用例关系的准则不要过度使用用例关系不要过度使用用例关系，更不要将用例关系用到编程当中。用，更不要将用例关系用到编程当中。用例的目标是澄清需求。例的目标是澄清需求。用例泛化用例泛化：如果一个用例有几种变体，那么就用抽象用例建模：如果一个用例有几种变体，那么就用抽象用例建模公
52、共的行为，再特化每种变体。公共的行为，再特化每种变体。用例包含用例包含：如果一项用例包含有一段定义良好且有可能用在其：如果一项用例包含有一段定义良好且有可能用在其他场合的行为片段，那么就该为该行为定义一项用例，并把该他场合的行为片段，那么就该为该行为定义一项用例，并把该用例包含在原始用例中。用例包含在原始用例中。用例扩展用例扩展：如果用可选特性来定义一项有意义的用例，那么要：如果用可选特性来定义一项有意义的用例，那么要把基行为建模为用例，并用扩展关系来增加特性。把基行为建模为用例，并用扩展关系来增加特性。包含关系和扩展关系包含关系和扩展关系：都可以把行为分解成较小的片段。但是，：都可以把行为分
53、解成较小的片段。但是，包含关系隐含着被包含行为是配置系统的一个必要的部分，而包含关系隐含着被包含行为是配置系统的一个必要的部分，而扩展关系暗示着没有增加的行为的系统也是有意义的。扩展关系暗示着没有增加的行为的系统也是有意义的。1104.2 对用例进行组织和分包对用例进行组织和分包学习内容学习内容用例和开发周期用例和开发周期用例分类原则用例分类原则用例分类实施策略用例分类实施策略用例的分包用例的分包111用例和开发周期用例和开发周期开发周期是围绕用例的需求来组织的开发周期是围绕用例的需求来组织的一个开发周期要被指派一个到多个用例，如果一个开发周期要被指派一个到多个用例，如果完全版本的用例在一个开
54、发周期中处理起来太完全版本的用例在一个开发周期中处理起来太复杂的话，那就采用简化版本的用例复杂的话，那就采用简化版本的用例用例用例A-简化版本简化版本用例用例A-完整版本完整版本用例用例B用例用例C112用例分类原则用例分类原则用例分类的一个基本原则用例分类的一个基本原则高级别的用例是那些对系统核心体系结构影响最大高级别的用例是那些对系统核心体系结构影响最大的用例的用例提高用例级别的特性：提高用例级别的特性：a. 对体系结构设计有重要影响的用例，如在领域层对体系结构设计有重要影响的用例，如在领域层中增加多个类的用例或者需要持久化的用例中增加多个类的用例或者需要持久化的用例b. 不需要花费很多努
55、力就可以从中获得重要信息和不需要花费很多努力就可以从中获得重要信息和线索的那些用例线索的那些用例c. 含有开发风险、时间紧迫或功能复杂的用例含有开发风险、时间紧迫或功能复杂的用例d. 涉及到重要技术研究或者新技术和高风险的用例涉及到重要技术研究或者新技术和高风险的用例e. 代表主要的在线业务流程的用例代表主要的在线业务流程的用例f. 能产生直接经济效益或者降低成本的用例能产生直接经济效益或者降低成本的用例113用例分类实施策略用例分类实施策略(1)可以使用一个简单的但是有些不精确的分类方可以使用一个简单的但是有些不精确的分类方法，如将用例划分成高、中、低三个等级法，如将用例划分成高、中、低三个
56、等级114用例分类实施策略用例分类实施策略(2)依照上述的影响用例级别的特性给用例打分依照上述的影响用例级别的特性给用例打分（用例也可能带有权值（用例也可能带有权值115用例的分包用例的分包 对用例进行分包对用例进行分包让用例图能够更为清晰地表现出系统的业务逻辑关让用例图能够更为清晰地表现出系统的业务逻辑关系和层次系和层次对系统进行模块的分割，这将影响到今后的开发和对系统进行模块的分割，这将影响到今后的开发和系统的最终表现形式系统的最终表现形式常见的分包方式常见的分包方式按参与者分包按参与者分包按主题分包按主题分包按开发团队分包按开发团队分包按发布情况分包按发布情况分包可以先按主题分包，主题内
57、再按开发团队和发布情况分包可以先按主题分包，主题内再按开发团队和发布情况分包可以先按主题分包，主题内再按开发团队和发布情况分包可以先按主题分包，主题内再按开发团队和发布情况分包116后继后继: 补充需求规约补充需求规约Supplementary Specification补充需求规约补充需求规约Supplementary Specification非功能需求非功能需求(URPS)可用性（可用性（Usability）可靠性（可靠性（Reliability）性能（性能（Performance）可支持性（可支持性（Supportability）设计约束设计约束用用Oracle数据库平台，用数据库平台
58、，用PB开发开发软件必须符合软件必须符合ISO标准标准本质上不是需求，只是从商业、行政、技术上的约束本质上不是需求，只是从商业、行政、技术上的约束词汇表词汇表Glossary描述数据描述数据117何时适用用例建模何时适用用例建模用例是从参与者角度捕获系统功能，当系统用例是从参与者角度捕获系统功能，当系统只有一个或者没有参与者时，显然它们不是只有一个或者没有参与者时，显然它们不是非常有效的非常有效的用例捕获功能需求，因此它们对于系统的非用例捕获功能需求，因此它们对于系统的非功能需求不是有效功能需求不是有效118适用用例建模的情况适用用例建模的情况当遇到下述情况时，用例是需求捕获的当遇到下述情况时
59、，用例是需求捕获的最好选择最好选择系统由功能需求所主导系统由功能需求所主导系统具有很多类型的用户，系统对他们提供系统具有很多类型的用户，系统对他们提供不同的功能不同的功能系统具有很多接口系统具有很多接口119不适用用例建模的情况不适用用例建模的情况当遇到下述情况时，用例是一个糟糕的当遇到下述情况时，用例是一个糟糕的选择：选择：系统有非功能需求所主导（如：系统有非功能需求所主导（如：google）系统具有很少的用户系统具有很少的用户系统具有很少的接口（非内部功能）系统具有很少的接口（非内部功能）如：嵌入式系统、算法复杂但接口少的系统等如：嵌入式系统、算法复杂但接口少的系统等120本章目录本章目录
60、3.1 前言前言 3.2 需求需求3.3 基于用例的需求分析过程基于用例的需求分析过程3.4 用例分析示例用例分析示例某学校网上选课系统某学校网上选课系统图书馆图书借阅图书馆图书借阅121用例分析用例分析示例示例1：某学校网上选课系统某学校网上选课系统 管理员通过学校网络课程管理系统，建立本学管理员通过学校网络课程管理系统，建立本学期要开设的各种课程，将课程信息发布网上，并期要开设的各种课程，将课程信息发布网上，并可以对课程进行改动和删除。可以对课程进行改动和删除。 学生通过自己的计算机进入系统，可以浏览课学生通过自己的计算机进入系统，可以浏览课程目录，查询课程详细信息，选择课程，网上支程目录
61、，查询课程详细信息，选择课程，网上支付课程费用。付课程费用。122 找出系统外部参与者，确定系统边界和范围。找出系统外部参与者，确定系统边界和范围。 123 确定各参与者所期望的系统行为。确定各参与者所期望的系统行为。 管理员：管理员： 建立课程建立课程 发布课程发布课程 修改课程信息修改课程信息 删除课程删除课程学生：学生： 浏览课程目录浏览课程目录 查询课程信息查询课程信息 选择课程选择课程 网上付费网上付费124 把这些系统行为命名为用例。把这些系统行为命名为用例。 125 绘制用例图。绘制用例图。 126 用例：建立课程参与者：管理员事件流： 管理员选择进入管理界面，用例开始； 系统提
62、示输入管理员密码； 管理员输入密码； 系统检验密码； A1：密码出错。 进入管理界面，系统显示当前所建立的全部课程信息； 管理员选择建立课程，管理员输入新课程信息； 系统验证是否与已有课程冲突； A2：有冲突。 系统添加新课程，并提示添加成功； 系统回到管理主界面，显示所有课程，用例结束。 编制用例叙述。编制用例叙述。127用例分析：用例分析： 确定图书管理的参与者；确定图书管理的参与者； 确定参与者所看到的图书管理功能；确定参与者所看到的图书管理功能； 把这些功能分解为用例；把这些功能分解为用例； 确定用例之间的关系；确定用例之间的关系； 画用例图；画用例图； 描述事件流。描述事件流。用例分
63、析用例分析示例示例2 2：图书馆的图书借阅：图书馆的图书借阅128 找出系统外部参与者，确定系统边界和范围。找出系统外部参与者，确定系统边界和范围。 129 确定各参与者所期望的系统行为。确定各参与者所期望的系统行为。 管理员：管理员： 借书证管理借书证管理: 办证办证,补证补证,注销注销,证件查询证件查询 图书管理图书管理: 查询查询,添加添加,修改修改,删除删除 借阅管理借阅管理: 目查询目查询,借书借书,还书还书,过期催还过期催还,丢失处理丢失处理借阅者：借阅者： 借书证管理借书证管理: 办证办证,补证补证,注销注销 借阅管理借阅管理: 书目查询书目查询,借书借书,还书还书,丢失处理丢失
64、处理130 把这些系统行为命名为用例。把这些系统行为命名为用例。 131 确定各用例之间的关系确定各用例之间的关系(泛化，包含，扩展泛化，包含，扩展)。 132 绘制用例图。绘制用例图。1 图书借阅管理图书借阅管理借书证管理借书证管理图书管理图书管理借阅管理借阅管理133 绘制用例图。绘制用例图。2 134 绘制用例图。绘制用例图。3 135 绘制用例图。绘制用例图。4 136 用例：借书参与者：管理员操作流： 管理员进入图书借阅界面，用例开始。 系统要求输入借阅者的借书证编码。 系统检验借书证编码,如果正确,则显示借阅者的信息。 A1：借书证编码有错。 A2: 如果该借阅者所借图书已经超期,
65、则提示,本次拒借. 系统要求输入所借图书的条码。 系统显示所借图书的信息。 确认借书。 系统回到上一界面，等待处理下一借书。 编制用例叙述。编制用例叙述。1137 用例：还书参与者：管理员,借阅者事件流： 管理员进入图书借阅界面，用例开始。 系统要求输入所还图书的条码。 系统显示所借图书的信息。 确认还书。 系统回到上一界面，等待处理下一业务。 编制编制用例叙述。用例叙述。2138作业：用例建模作业：用例建模-题目要求题目要求参阅下页的初步用户需求，完成下面所要求的内参阅下页的初步用户需求，完成下面所要求的内容容完成完成“旅店管理系统旅店管理系统旅店管理系统旅店管理系统”的系统用例图，注意用例
66、的命的系统用例图，注意用例的命名和用例间的关系的使用名和用例间的关系的使用标识每个参与者和用例（可以考虑以词汇表的形式提标识每个参与者和用例（可以考虑以词汇表的形式提供，至少包括名称以及描述）供，至少包括名称以及描述）选择至少两个以上的、体现系统核心功能的用例，完选择至少两个以上的、体现系统核心功能的用例，完成用例规约，如果该用例有成用例规约，如果该用例有“扩展扩展”、“包含包含”或或“泛化泛化”的子用例，则至少还需要写出一个子用例的规的子用例，则至少还需要写出一个子用例的规约约139“旅店管理系统旅店管理系统”初步用户需求初步用户需求某公司要开发一个旅店管理系统，该旅店可对外开放某公司要开发
67、一个旅店管理系统，该旅店可对外开放10个双人间和个双人间和10个单人间，房间费用视情况按季节调个单人间，房间费用视情况按季节调整，但周一到周五半价（周末全价）折扣不变。对于整，但周一到周五半价（周末全价）折扣不变。对于外界请求，该系统应能根据请求入住时间预定指定档外界请求，该系统应能根据请求入住时间预定指定档次的房间，记录旅客姓名、地址、联系电话、有效证次的房间，记录旅客姓名、地址、联系电话、有效证件号、房间类型和预定天数，并计算出总费用。预定件号、房间类型和预定天数，并计算出总费用。预定的同时旅客按规定须提交的同时旅客按规定须提交10%定金。六个小时之内旅定金。六个小时之内旅店允许旅客取消预
68、定，并退回所有定金，超过六个小店允许旅客取消预定，并退回所有定金，超过六个小时定金不退还。每周一系统自动打印一周预定情况清时定金不退还。每周一系统自动打印一周预定情况清单。采用哪种费用支付方式和何种类型操作界面尚不单。采用哪种费用支付方式和何种类型操作界面尚不确定。确定。140作业作业根据上述需求建立根据上述需求建立用例需求文档用例需求文档，文档包括用例图和，文档包括用例图和各个用例文档。各个用例文档。 提交电子文件提交电子文件每组每组34人，自己分配角色（组长和组员）人，自己分配角色（组长和组员）各个小组将各个小组将word文件（文件中列出组成员信息，包括班级、文件（文件中列出组成员信息，包括班级、姓名、学号）提交给班长，文件名姓名、学号）提交给班长，文件名=班级班级+组长名组长名+是否优是否优秀秀班长将班内作业置于文件夹中，以班级命名，然后压缩成班长将班内作业置于文件夹中，以班级命名，然后压缩成rar。 141
