建模UML.pptVIP

面向对象的系统开发方法 登山的故事(什么是XP,设计)  教学目标 基本概念 清晰、准确、熟练地掌握面向对象方法的主要思想、基本概念与原则。 面向对象的分析（ OOA ） 掌握 OOA 的主要概念，了解建模过程，会应用 面向对象的设计（ OOD ） 掌握 OOD 的主要概念，了解建模过程，会应用。 1 面向对象系统开发过程概述 面向对象系统开发的主要阶段 业务需求建模阶段 业务角色的查找与建立、业务用例的查找与分析 用例模型的建立、业务规则及其建模 用活动图表示用例结构 业务实体的分析与提取、业务对象模型的建立 系统需求建模阶段 需求的捕获与理解、系统功能的理解 系统角色的建立、系统用例的建立 基本用例及其分类、用例的扩展、包含与泛化关系 用例规约及文档标准 面向对象系统开发的主要阶段 系统分析阶段 业务角色的查找与建立、业务用例的查找与分析 用例模型的建立、业务规则及其建模 用活动图表示用例结构 业务实体的分析与提取、业务对象模型的建立 系统设计阶段 需求的捕获与理解、系统功能的理解 系统角色的建立、系统用例的建立 基本用例及其分类、用例的扩展、包含与泛化关系 用例规约及文档标准 2.1需求—建造“正确”的系统 需求：系统必须满足的条件或具备的能力 Robert Grady软件质量准则“FURPS” 功能性（Functionality） 可用性（Usability） 可靠性（Reliability） 性能（Performance） 可支持性（Supportability） 需求示例：石头问题 我要一块石头… 差不多，但我要小一点的… 很好，不过我要蓝色的… 啊，没有那么小… 咳，还是原来那个好了… 需求：如此脆弱 找到可以帮助你理解这个系统的人 倾听这些相关人员的描述，并从他们的角度来理解系统 利用一个容易理解的模型来描述用户希望如何使用这个系统以及为他们提供的什么价值 详细地描述系统和客户以及系统和外部系统之间的交互 重构（refactor）这个详细描述以保证它是可读且易懂的 2.2 基于用例的需求分析 获取需求：考勤卡应用程序 识别参与者参与者：在系统之外，透过系统边界与系统进行有意义交互的任何事物关键词：边界 思考：参与者与系统边界？ 某企业要求开发一个企业信息管理系统，并与原来已有的库存系统相连接 某企业要求开发一个企业信息管理系统，并把原来已有的库存管理系统加以改造，成为企业信息管理系统的一部分 思考：识别参与者？ 寻呼台系统：用户如果预定了天气预报，系统每天定时给他发天气消息；如果当天气温高于35度，还要提醒用户注意防暑； 识别参与者思路 谁使用系统的主要功能 谁改变系统的数据 谁从系统获取信息 谁需要系统的支持以完成日常工作任务 谁负责日常维护、管理并保证系统正常运行 系统需要应付（处理）那些硬设备 系统需要和那些外部系统交互 谁（或什么）对系统运行产生的结果（值）感兴趣 时间、气温等内部外部条件 …… 示例考勤卡系统：识别参与者 参与者地位 识别用例之前—重要 有助于识别用例，宁多勿少 开始书写用例文档以后—不重要 涉及的参与者太多 测试和部署阶段—重要 需要从参与者的角度考虑 参与者的泛化：责任重叠 泛化– 参与者B是参与者A的特化意味着：参与者B和与参与者A有关联的所有用例有关联 示例考勤卡系统中：经理可以使用雇员的所有用例 泛化关系的误用 用例实例是系统执行的一系列动作，这些动作将生成特定参与者可观测的结果值 一个用例定义一组用例实例 参与者使用系统达到目标 用例要点：止于系统边界 用户词汇，而不是技术词汇 如：发票，商品，洗衣机 而不是：记录，字段，COM，C++等 执行者视角： （状语）动词+（定语+ ）宾语 用例粒度 用例要有路径，路径要有步骤；而这一切都是可观测的 最常犯错误：粒度过细，陷入功能分解 过细的粒度， 导致技术语言的描述，而不是业务语言 把步骤当用例 把系统活动当用例 “四轮马车” C(Create)R(Read)U(Update)D(Delete) 所有业务最终对会成为CRUD？ CRUD能为Actor提供价值？ CRUD掩盖业务，锐变成关系数据库的建模： “系统就是数据的增删改查” 关心数据的存储和维护，反而忽略了用户的目的 如果确实是CRUD？ 如果CRUD不涉及复杂交互，一个用例“管理××”即可 不管是C、R、U、D，都是为了完成“管理”目标 甚至很多种的基本数据管理都可以用一个用例表示 构建用例图 用例规约：更进一步的精度 用例文档的核心，作为用例文档的总图 进一步的精度：有层次的文档 文档中每一句话都有其价值 谁写用例规约 最完美：业务人员接受训练，写出优美的用例文档 最现实：业务人员提供素材，开发人员写用例文