《uml建模语言及工具课件-第四章 用例建模》由会员分享，可在线阅读，更多相关《uml建模语言及工具课件-第四章 用例建模（106页珍藏版）》请在金锄头文库上搜索。
1、UML建模语言及工具,第 4 章用例建模 Use-Case Modeling,-3-,Review: A Practice of Visual Modeling with UML,-4-,UML 5类9种图,类 图：类以及类之间的相互关系 对象图：对象以及对象之间相互关系 构件图：构件及其相互依赖关系 部署图：构件在各节点上的部署顺序图：强调时间顺序的交互图 协作图：强调对象协作的交互图 状态图：类所经历的各种状态 活动图：对工作流建模 用例图：需求捕获，测试依据,结 构,行为,用例图,静态图,实现图,交互图,行为图,-5-,学习线路图,-6-,UML,1. 用UML画图很容易,摆脱符号烦恼,
2、全心面对问题,2. UML仅仅是一种表达形式,用好UML首先需要掌握OOAD的基本原则和方法，并在一定的软件开发过程（如统一过程UP/USDP/RUP、XP等）的指导下进行有取舍的运用,但知道要画什么是困难的！,认识问题,分析问题,解决问题,最终用户(提出问题),开发团队(解决问题),以用户的身份站在用户的角度认识问题 获取需求用例建模技术,以开发者的身份站在用户的角度分析问题 分析需求用例分析技术,以开发者的身份站在开发团队的角度分析问题 解决需求面向对象设计,-8-,内容安排,理解需求 需求，难在何处？ 以用例为中心组织需求 基于用例的需求分析过程,-9-,需求建造“正确”的系统,需求：系
3、统必须满足的条件或具备的能力 Robert Grady软件质量准则“FURPS” 功能性（Functionality） 使用性（Usability） 可靠性（Reliability） 性能（Performance） 可支持性（Supportability）,非功能性需求,-10-,内容安排,理解需求 需求，难在何处？ 以用例为中心组织需求 基于用例的需求分析过程,-11-,需求：石头问题,我要一块石头 差不多，但我要小一点的 很好，不过我要蓝色的 啊，没有那么小 咳，还是原来那个好了,小一点的蓝色大理石,难捕获，易变！,-12-,需求：如此脆弱,客户/用户的要求/想法/期望,软件设计,软件产品
4、,分析和设计,编码和测试,验 收,没价值的 软件需求,补文档,-13-,需求：也需要开发,客户/用户的要求/想法/期望,软件设计,软件产品,开发,编码和测试,验收,有价值的 软件需求,分析和设计,-14-,获取好的需求,需求收集包括五个关键步骤 找到可以帮助你理解这个系统的人 倾听这些相关人员的描述，并从他们的角度来理解系统 利用一个容易理解的模型来描述用户希望如何使用这个系统以及为他们提供的什么价值 详细地描述系统和客户以及系统和外部系统之间的交互 重构（refactor）这个详细描述以保证它是可读且易懂的,-15-,内容安排,理解需求 需求，难在何处？ 以用例为中心组织需求 基于用例的需求
5、分析过程,-16-,需求问题：对策,难捕获,易变,从用户视角看问题,合理的结构,用例,-17-,以用例为中心组织需求,用例,可用性,可靠性,网络协议,业务规则,硬件接口,界面约束,性能,-18-,内容安排,理解需求 需求，难在何处？ 以用例为中心组织需求 基于用例的需求分析过程,-19-,基于用例的需求分析过程,1. 获取原始需求 2. 开发一个可以理解的需求 2.1 识别参与者 2.2 识别用例 2.3 构建用例图 3 详细、完整地描述需求 进行用例阐述 4 重构用例模型 4.1 识别用例间的关系 4.2 对用例进行组织和分包,-20-,基于用例的需求分析过程,1. 获取原始需求 2. 开发
6、一个可以理解的需求 2.1 识别参与者 2.2 识别用例 2.3 构建用例图 3. 详细、完整地描述需求 进行用例阐述 4. 重构用例模型 4.1 识别用例间的关系 4.2 对用例进行组织和分包,-21-,获取需求的技巧（MSF）,-22-,获取需求：考勤卡应用程序,初次访谈记录 开发者：谁将使用这个应用程序？ 客 户：所有用它来记录可记帐以及不可记帐的工时的雇员 开发者：现在考勤卡应用程序是什么样的？ 客 户：每半个月就用一个Excel表格来记录。每个雇员都将通过他的表格填好，然后用电子邮件发给我。这个表格相当标准：纵向是收费项目代码，横向是日期。雇员可以在每个条目上填写说明。 开发者：这个
7、收费项目代码可以从什么地方得到？ 开发者：谁来管理收费项目代码？ 客 户：嗯，必要的时候由我来添加这个代码。而每个经理总会告诉他的下属应该填写什么。 ,-23-,基于用例的需求分析过程,1. 获取原始需求 2. 开发一个可以理解的需求 2.1 识别参与者 2.2 识别用例 2.3 构建用例图：确定参与者和用例之间的关系 3. 详细、完整地描述需求 进行用例阐述 4. 重构用例模型 4.1 识别用例间的关系 4.2 对用例进行组织和分包,-24-,2.1 识别参与者,参与者，Actor 关键词：边界 参与者：在系统之外，透过系统边界与系统进行有意义交互的任何事物,-25-,参与者要点,系统外 参
8、与者代表在系统边界之外的真实事物，并不是系统的成分 系统边界 参与者透过系统边界直接与系统交互，参与者的确定代表系统边界的确定 有意义的交互 任何事物 人、外系统、外部因素、时间,-26-,题外话：小人与圣小猪(1),-27-,小人与圣小猪(2),众所周知，use case 图里的actor 用一个小人表示。但是这个小人极具误导性，往往让初学者（包括客户）理解为一个真实的人。大多数UML 学习者都要花好长一段时间来搞明白小人其实不一定代表的是人，而是很抽象的系统不可控的外部因素，比如说另一个系统。那么为什么不干脆用其它的符号来表示Actor 呢？ 如果我开发一个猪圈自动供食供水系统，猪的前蹄触
9、发一个开关系统就供食或供水。显然，这里的Actor 是小猪。那么在use case 图里用小猪代替原来的小人不是更易于交流吗？,-28-,思考：参与者与系统边界？,某企业要求开发一个企业信息管理系统，并与原来已有的库存系统相连接 某企业要求开发一个企业信息管理系统，并把原来已有的库存管理系统加以改造，成为企业信息管理系统的一部分,-29-,思考：识别参与者？,寻呼台系统：用户如果预定了天气预报，系统每天定时给他发天气消息；如果当天气温高于35度，还要提醒用户注意防暑；,在这个叙述里，谁是寻呼台系统的Actor？用户？气温？时间？,-30-,识别参与者思路,谁使用系统的主要功能 谁改变系统的数据
10、 谁从系统获取信息 谁需要系统的支持以完成日常工作任务 谁负责日常维护、管理并保证系统正常运行 系统需要应付（处理）那些硬设备 系统需要和那些外部系统交互 谁（或什么）对系统运行产生的结果（值）感兴趣 时间、气温等内部外部条件 ,-31-,识别参与者：考勤卡系统,开发者：谁将使用这个应用程序？ 客 户：所有用它来记录可记帐以及不可记帐的工时的雇员 开发者：现在考勤卡应用程序是什么样的？ 客 户：每半个月就用一个Excel表格来记录。每个雇员都将通过他的表格填好，然后用电子邮件发给我。这个表格相当标准：纵向是收费项目代码，横向是日期。雇员可以在每个条目上填写说明。 开发者：这个收费项目代码可以从
11、什么地方得到？ 开发者：谁来管理收费项目代码？ 客 户：嗯，必要的时候由我（业务经理）来添加这个代码。而每个经理总会告诉他的下属应该填写什么。 ,-32-,参与者地位,识别用例之前重要 有助于识别用例，宁多勿少 开始书写用例文档以后不重要 涉及的参与者太多 测试和部署阶段重要 需要从参与者的角度考虑,-33-,参与者的泛化：责任重叠,Generalization A generalization from an actor A to an actor B indicates that an instance of A can communicate with the same kinds of
12、 use-case instances as an instance of B 如系统中经理可以参加雇员的所有用例,-34-,泛化关系的误用,-35-,-36-,-37-,-38-,2.2 识别用例,关键词：价值 定义 用例实例是系统执行的一系列动作，这些动作将生成特定参与者可观测的结果值 一个用例定义一组用例实例 简洁：参与者使用系统达到目标,-39-,识别用例：考勤卡系统,开发者：谁将使用这个应用程序？ 客 户：所有用它来记录可记帐以及不可记帐的工时的雇员 开发者：现在考勤卡应用程序是什么样的？ 客 户：每半个月就用一个Excel表格来记录。每个雇员都将通过他的表格填好，然后用电子邮件发给
13、我。这个表格相当标准：纵向是收费项目代码，横向是日期。雇员可以在每个条目上填写说明。 开发者：这个收费项目代码可以从什么地方得到？ 开发者：谁来管理收费项目代码？ 客 户：嗯，必要的时候由我（业务经理）来添加这个代码。而每个经理总会告诉他的下属应该填写什么。 ,-40-,用例要点,可观测用例止于系统边界 结果值用例是有意义的目标 系统执行结果值由系统生成 由参与者观测业务语言、用户观点 一组用例实例用例的粒度,-41-,要点：用例止于系统边界,描述交互，而不是内在的系统活动,-42-,要点：有意义的目标,-43-,要点：结果值由系统生成,系统需要处理的，由系统生成,-44-,要点：业务语言而非
14、技术语言,用户词汇，而不是技术词汇 如：发票，商品，洗衣机 而不是：记录，字段，COM，C+等,-45-,要点：用户观点而非系统观点,用户观点,系统观点,-46-,用例 VS. 功能,呼叫某人 接听电话 发送短信 记住电话号码 ,传输/接收 电源/基站 输入输出（显示、键盘） 电话簿管理 ,用户观点,系统观点,-47-,用例的命名,执行者视角： （状语）动词+（定语+ ）宾语,-48-,要点：用例粒度-1,用例要有路径，路径要有步骤；而这一切都是可观测的 最常犯错误：粒度过细，陷入功能分解 过细的粒度，一般都会导致技术语言的描述，而不再是业务语言,-49-,用例粒度-2,把步骤当用例把系统活动
15、当用例,-50-,用例粒度-3,“四轮马车” C(Create) R(Read) U(Update) D(Delete) 所有业务最终对会成为CRUD？ CRUD能为Actor提供价值？ CRUD掩盖业务，锐变成关系数据库的建模： “系统就是数据的增删改查” 关心数据的存储和维护，反而忽略了用户的目的,-51-,用例粒度-4,如果确实是CRUD？ 如果CRUD不涉及复杂的交互，一个用例“管理”即可 不管是C、R、U、D，都是为了完成“管理”目标 甚至很多种的基本数据管理都可以用一个用例表示,-52-,用例粒度-5,灵活处理CRUD,可以把包含复杂交互的路径独立出去形成用例,-53-,思考：识别
16、用例-1,Email客户端（如：outlook express），A在北京发邮件给上海的B，系统提醒B你有“新邮件”，B收邮件,-54-,思考：识别用例-2,-55-,-56-,-57-,2.3 构建用例图,-58-,定义系统：POST,销售点终端（Point-Of-Sale Terminal，POST）系统 是一个计算机自动化系统 用来记录商品销售信息 处理客户的支付信息 客户可以使用现金、信用卡、支票等多种支付手段 主要用于零售的百货商店 包括计算机和条形码扫描仪等硬件设备和系统运行软件 ,-59-,识别参与者,谁使用系统的主要功能 出纳员Cashier 谁改变系统的数据出纳员Cashier 谁从系统获取信息出纳员Cashier，顾客Customer，系统管理员SystemAdmin 谁需要系统的支持以完成日常工作任务出纳员Cashier，系统管理员SystemAdmin 谁负责日常维护、管理并保证系统正常运行系统管理员SystemAdministrator 系统需要应付（处理）那些硬设备无 系统需要和那些外部系统交互可与库存系统Inventory、信用卡系统CardProcessingCompany、支票处理系统CheckProcessingCompany等交互 谁（或什么）对系统运行产生的结果（值）感兴趣出纳员Cashier，顾客Customer,
