uml第六章.pptVIP

Review: Knowledge structure of UML UML 5类9种图 类 图：类以及类之间的相互关系 对象图：对象以及对象之间相互关系 构件图：构件及其相互依赖关系 部署图：构件在各节点上的部署 顺序图：强调时间顺序的交互图 协作图：强调对象协作的交互图 状态图：类所经历的各种状态 活动图：对工作流建模 用例图：需求捕获，测试依据 学习线路图 需求：石头问题 需求—建造“正确”的系统 需求：系统必须满足的条件或具备的能力 Robert Grady软件质量准则“FURPS” 功能性（Functionality） 使用性（Usability） 可靠性（Reliability） 性能（Performance） 可支持性（Supportability） 需求收集包括五个关键步骤 找到可以帮助你理解这个系统的人 倾听这些相关人员的描述，并从他们的角度来理解系统 利用一个容易理解的模型来描述用户希望如何使用这个系统以及为他们提供的什么价值 详细地描述系统和客户以及系统和外部系统之间的交互 重构（refactor）这个详细描述以保证它是可读且易懂的 用例的命名 执行者视角： （状语）动词+（定语+ ）宾语 思考：识别用例-1 Email客户端（如：outlook express），A在北京发邮件给上海的B，系统提醒B你有“新邮件”，B收邮件 思考：识别用例-2 用例的粒度指的是用例所包含的系统服务或功能单元的多少。用例的粒度越大，用例包含的功能越多，反之则包含的功能越少。 如果用例的粒度很小，得到的用例数就会太多。反之，如果用例的粒度很大，那么得到的用例数就会很少。 如果用例数目过多会造成用例模型过大和引入设计困难大大提高。 如果用例数目过少会造成用例的粒度太大，不便于进一步的充分分析。 最常犯错误：粒度过细，陷入功能分解 过细的粒度，一般都会导致技术语言的描述，而不再是业务语言 用例粒度 把步骤当用例 把系统活动当用例 用例粒度 “四轮马车” C(Create)R(Read)U(Update)D(Delete) 所有业务最终对会成为CRUD？ CRUD能为Actor提供价值？ CRUD掩盖业务，锐变成关系数据库的建模： “系统就是数据的增删改查” 关心数据的存储和维护，反而忽略了用户的目的 用例粒度 如果确实是CRUD？ 如果CRUD不涉及复杂的交互，一个用例“管理××”即可 不管是C、R、U、D，都是为了完成“管理”目标 甚至很多种的基本数据管理都可以用一个用例表示 用例粒度 灵活处理CRUD 进行用例阐述：写用例规约 用例规约：更进一步的精度 用例文档的核心，作为用例文档的总图 进一步的精度：有层次的文档 文档中每一句话都有其价值 说明 下周进一步学习用例规约的详细内容 用例规约组成 用例名称 用例标识 涉及的参与者 描述 用例的规格说明 前置条件 PreConditions 后置条件 PostConditions 正常事件流 Flow of events 备选事件流 Alternate flow 其它 非功能需求、设计约束、尚存在的问题 前置、后置条件-1 前置条件约束在用例开始前系统的状态 把它们看做是看门人，它阻止参与者触发该用例直到满足所有条件 说明在用例触发之前什么必须为真 后置条件约束用例执行后系统的状态 用例执行后什么必须为真 对于有多个事件流的用例，则应该有多个后置条件 前置、后置条件-2 某些用例依赖于其他用例 一个用例在离开系统时，可能是另一个用例的前置条件（例如：“登录”和“管理系统”） 有助于识别漏掉的用例 如果一个用例的前置条件不能有执行其他用例满足，可能意味着丢失了用例（例如：“管理订单”却没有“登录”用例） 用例交互四部曲-事件流 事件流描述要点 1.只书写“可观测”的（说人话） 2.使用主动语句 3.句子必须以参与者或系统作为主语 4.不要涉及界面细节 5.分支和循环 要点1：只写“可观测”的 系统通过ADO建立数据库连接，传送SQL查询语句，从“商品表”查询商品的详细信息… 系统按照查询条件搜索商品的详细信息 要点2：主动语句 欧文丛贝克汉姆处得到传球，守门员… 贝克汉姆传球给欧文，欧文射门，守门员扑救… 出纳员…… 系统…… 要点3：以参与者或系统作主语 参与者…… 系统…… 出纳员接收顾客的付款—顾客的付款数可能高于商品总额 出纳员录入顾客所付的现金总额 系统显示出应找还给顾客的余额，打印付款收据 要点4：不涉及界面细节 会员从下拉框中选择类别 会员在相应文本框中输入查询条件 会员点击“确定”按钮 要点5：分支和循环 分支：放到扩展路径 参与者的选择 另一条成功线路 系统进行验证 …… 循环：直接描述 用例规约：记录时间 用例规约：记录时间(续) 用例规