《《UML需求建模》PPT课件.ppt》由会员分享，可在线阅读，更多相关《《UML需求建模》PPT课件.ppt（66页珍藏版）》请在三一办公上搜索。
1、第二部分,UML需求建模,Sunny Liu,教学内容,用例建模（需求建模）用例图用例文档,用例建模,用例建模（Use Case Modeling）是使用用例的方法来描述系统的功能需求的过程，用例建模促进并鼓励了用户参与，这是确保项目成功的关键因素之一。用例建模主要包括以下两部分内容：用例图(Use Case Diagram)用例描述文档(Use Case Specification),用例建模步骤,识别执行者识别用例绘制用例图书写用例文档检查用例模型,用例建模步骤,识别执行者识别用例绘制用例图书写用例文档检查用例模型,识别执行者,执行者Actor定义：在系统之外，透过系统边界与系统进行有意义
2、交互的任何事物。引入执行者的目的：帮助确定系统边界。,识别执行者,人,其它系统,自动发生的事件,思路 谁使用系统？谁改变系统的数据？谁从系统获取信息？谁需要系统的支持以完成日常工作任务？谁负责维护、管理并保持系统正常运行？系统需要和哪些外部系统交互？有没有自动发生的事件？,识别执行者,都对，不丢用例就行（慢慢清理）,哪个是正确的执行者？,识别执行者,识别执行者,识别执行者练习,某酒店订房系统描述如下：（1）顾客可以选择在线预订，也可以直接去酒店通过前台服务员预订；（2）前台服务员可以利用系统直接在前台预订房间；（3）不管采用哪种预订方式，都需要在预订时交相应订金；（4）前台预订可以通过现金或信
3、用卡的形式进行订金支付，但是网上预订只能通过信用卡进行支付；（5）利用信用卡进行支付时需要和信用卡系统进行通信；（6）客房部经理可以随时查看客房预订情况和每日收款情况。识别该系统的执行者。,用例建模步骤,识别执行者识别用例绘制用例图书写用例文档检查用例模型,识别用例,识别用例,用例用例是在系统中执行的一系列动作，这些动作将生成特定执行者可见的价值结果。一个用例定义一组用例实例。,识别用例,用例要点：有意义的目标价值结果由系统生成业务语言，用户观点注意用例的命名用例的“粒度”,识别用例,错！,对！,有没有意义？涉众说了算！,有意义的目标,识别用例,价值结果由系统生成,?,识别用例,业务语言而非技
4、术语言,识别用例,用户观点而非系统观点,用户观点,系统观点,对！,错！,识别用例,用例命名,动词（宾语）,状语,定语,识别用例,用例命名：慎用弱动词弱名词,弱动词：进行、使用、复制、加载、重复弱名词：数据、报表、表格、表单、系统,会掩盖真正的业务！,识别用例,用例的“粒度”,粒度原则：用例要有路径，路径要有步骤。而这一切都是“可观测”的。,识别用例,用例的“粒度”,最常犯错误把步骤当作用例把执行者动作当作用例把系统活动当作用例,识别用例,用例的“粒度”,四轮马车警惕CRUD泛滥！,识别用例,用例的“粒度”,四轮马车,识别用例,用例的“粒度”,四轮马车,也可以把包含复杂交互的路径独立出去形成用例
5、,识别用例,形式检查,【执行者】使用系统来【用例】,识别用例练习,某酒店订房系统描述如下：（1）顾客可以选择在线预订，也可以直接去酒店通过前台服务员预订；（2）前台服务员可以利用系统直接在前台预订房间；（3）不管采用哪种预订方式，都需要在预订时交相应订金；（4）前台预订可以通过现金或信用卡的形式进行订金支付，但是网上预订只能通过信用卡进行支付；（5）利用信用卡进行支付时需要和信用卡系统进行通信；（6）客房部经理可以随时查看客房预订情况和每日收款情况。识别该系统的用例。,用例建模步骤,识别执行者识别用例绘制用例图书写用例文档检查用例模型,绘制用例图,执行者与用例之间的关联关系在用例图中，执行者和
6、用例之间进行交互，相互之间的关系用一根直线来表示，称为关联关系(Association)或通信关系(Communication)。,绘制用例图,执行者之间的泛化关系执行者之间可以有泛化(Generalization)关系（或称为“继承”关系）。,绘制用例图,执行者之间的泛化关系,绘制用例图,用例之间的关系包含关系描述在多个用例中都有的公共行为，由用例A指向用例B，表示用例A中使用了用例B中的行为或功能，包含关系是通过在依赖关系上应用构造型（衍型）来表示的。,绘制用例图,用例之间的关系包含关系,绘制用例图,用例之间的关系扩展关系扩展用例可以在基用例之上添加新的行为，但是基用例必须声明某些特定的“
7、扩展点”，并且扩展用例只能在这些扩展点上扩展新的行为。在扩展（extend）关系中，基础用例(Base)中定义有一至多个已命名的扩展点，扩展关系是指将扩展用例(Extension)的事件流在一定的条件下按照相应的扩展点插入到基础用例(Base)中。扩展关系是通过在依赖关系上应用构造型（衍型）来表示的。,绘制用例图,用例之间的关系扩展关系,绘制用例图,用例之间的关系泛化关系当多个用例共同拥有一种类似的结构和行为的时候，可以将它们的共性抽象成为父用例，其他的用例作为泛化关系中的子用例。在用例的泛化关系中，子用例是父用例的一种特殊形式，子用例继承了父用例所有的结构、行为和关系。泛化关系一般很少使用。
8、,绘制用例图,用例之间的关系泛化关系,绘制用例图练习,某酒店订房系统描述如下：（1）顾客可以选择在线预订，也可以直接去酒店通过前台服务员预订；（2）前台服务员可以利用系统直接在前台预订房间；（3）不管采用哪种预订方式，都需要在预订时交相应订金；（4）前台预订可以通过现金或信用卡的形式进行订金支付，但是网上预订只能通过信用卡进行支付；（5）利用信用卡进行支付时需要和信用卡系统进行通信；（6）客房部经理可以随时查看客房预订情况和每日收款情况。绘制该系统的用例图。,综合练习,某电话公司决定开发一个管理所有客户信息的交互式网络系统，系统功能如下：浏览客户信息：任何使用Internet的网络用户都可以浏
9、览电话公司所有的客户信息（包括姓名、住址、电话号码等）。登录：电话公司授予每个客户一个账号。拥有授权账号的客户可以使用系统提供的页面设置个人密码，并使用该账号和密码向系统注册。公司管理人员也可以通过登录对客户信息进行管理。修改个人信息：客户在系统中注册后，可以发送电子邮件或者使用系统提供的页面对个人信息进行修改。删除客户信息：只有公司的管理人员才能删除不再接受公司服务的客户的信息。构造该系统的用例模型。,用例建模步骤,识别执行者识别用例绘制用例图书写用例文档检查用例模型,书写用例文档,用例是文本文档，而非图形；用例建模主要是编写文本的活动，而非制图；用例不是面向对象的，编写用例时也不会进行OO
10、分析；用例是经典OOA/D的关键需求输入。,书写用例文档,用例的内容,用例编号用例名执行者前置条件后置条件涉众利益基本路径 1.23.扩展路径2a.：2a1.字段列表业务规则非功能需求设计约束,书写用例文档,书写用例文档,前置、后置条件,开始用例前所必需的系统及其环境的状态,注意：系统必须能检测到,用例成功结束后系统应该具备的状态,书写用例文档,前置、后置条件,必须是系统能检测到的,前置条件：顾客提着商品来结账,前置条件：收银员已通过身份识别,错！,对！,书写用例文档,前置、后置条件,前置条件必须是系统在用例开始前能检测到的,前置条件：用户账户中有足够的余额,错！,书写用例文档,前置、后置条件
11、,书写用例文档,前置、后置条件,把基本路径单独分离，凸现用例的核心价值。,核心的核心：客户最想看到、最关心的路径,书写用例文档,基本路径用例交互四步曲,在步骤中写需求！,书写用例文档,基本路径只书写“可观测”的（说人话）使用主动语句句子必须以执行者或系统作为主语每一句都要朝目标迈进分支和循环不要涉及界面细节,书写用例文档,基本路径,系统通过ADO建立数据库连接，传送SQL查询语句，从“零件”表查询系统按照查询条件搜索零件,只书写“可观测”的,错,对,书写用例文档,基本路径,欧文从贝克汉姆处得到传球，守门员贝克汉姆传球给欧文，欧文射门，守门员扑救.,主动语句球在谁那里？,错,对,书写用例文档,基
12、本路径,系统从会员处获取用户名和密码会员提交用户名和密码用户名和密码被验证系统验证用户名和密码,使用主动语句,错,对,错,对,书写用例文档,基本路径,执行者系统系统执行者,句子必须以执行者或系统作为主语,书写用例文档,基本路径,执行者填写姓名执行者填写电话执行者填写联系地址执行者提交,每一句都要朝目标迈进,X,书写用例文档,基本路径,分支：放到扩展路径循环：直接描述,分支和循环,书写用例文档,基本路径,会员从下拉框中选择类别会员在相应文本框中输入查询条件会员点击“确定”按钮,不要涉及界面细节,X,书写用例文档,扩展路径,注意意外和分支,替换路径,异常路径,书写用例文档,补充约束,可以直接放在用
13、例中，也可以单独集中到另外的文档，从用例文档指向,字段列表业务规则非功能需求设计约束,书写用例文档,用例文档实例,用例文档示例一用例文档示例二,书写用例文档练习,某酒店订房系统描述如下：（1）顾客可以选择在线预订，也可以直接去酒店通过前台服务员预订；（2）前台服务员可以利用系统直接在前台预订房间；（3）不管采用哪种预订方式，都需要在预订时交相应订金；（4）前台预订可以通过现金或信用卡的形式进行订金支付，但是网上预订只能通过信用卡进行支付；（5）利用信用卡进行支付时需要和信用卡系统进行通信；（6）客房部经理可以随时查看客房预订情况和每日收款情况。书写用例“在线预订客房”和“前台预订客房”的用例文档。,用例建模步骤,识别执行者识别用例绘制用例图书写用例文档检查用例模型,检查用例模型,用例模型完成之后，需要对用例模型进行检查，看看是否有遗漏或错误之处。主要可以从以下几个方面来进行检查：功能需求的完备性 模型是否易于理解 是否存在不一致性 避免语义二义性,检查用例模型,Thanks!,END,
