面向对象需求分析.ppt

* 时间 气温不是，仅是一个条件 * 系统的存在是因为：参与者有一些需要使用它来满足的目标 * 用户可以看见的，是由系统生成的 * 用例是一个完整的交互，用例之间没有顺序的关系 * * -*- 前置、后置条件-2 某些用例依赖于其他用例 一个用例在离开系统时，可能是另一个用例的前置条件（例如：“登录”和“管理系统”） 有助于识别漏掉的用例 如果一个用例的前置条件不能由执行其他用例满足，可能意味着丢失了用例（例如：“管理订单”却没有“登录”用例） -*- 用例交互四部曲-事件流 1. 动 作 4. 回 应 2.改变 3.验证 系 统 写：可观测的、体现客户利益的文字 -*- 事件流描述要点 1.只书写“可观测”的（说人话） 2.使用主动语句 3.句子必须以参与者或系统作为主语 4.不要涉及界面细节 5.分支和循环 -*- 要点1：只写“可观测”的 系统通过ADO建立数据库连接，传送SQL查询语句，从“商品表”查询商品的详细信息… 系统按照查询条件搜索商品的详细信息 -*- 要点2：主动语句 欧文丛贝克汉姆处得到传球，守门员… 贝克汉姆传球给欧文，欧文射门，守门员扑救… 出纳员…… 系统…… -*- 要点3：以参与者或系统作主语 参与者…… 系统…… 出纳员接收顾客的付款—顾客的付款数可能高于商品总额 出纳员录入顾客所付的现金总额 系统显示出应找还给顾客的余额，打印付款收据 -*- 要点4：不涉及界面细节 会员从下拉框中选择类别 会员在相应文本框中输入查询条件 会员点击“确定”按钮 -*- 要点5：分支和循环 找清楚分支条件和循环条件 -*- 基于用例的需求分析过程 1. 获取原始需求 2. 开发一个可以理解的需求 2.1 识别参与者 2.2 识别用例 2.3 构建用例图 3 详细、完整地描述需求 进行用例阐述 4 重构用例模型 4.1 识别用例间的关系 4.2 对用例进行组织和分包 -*- 对用例进行分类 用例和开发周期 开发周期是围绕用例的需求来组织的 一个开发周期要被指派一个到多个用例，如果完全版本的用例在一个开发周期中处理起来太复杂的话，那就采用简化版本的用例 开发周期 开发周期 开发周期 用例A -简化版本 用例A -完整版本 用例B 用例C * 用例分级 每一个用例都要根据它的风险、对用户和架构的重要性、团队是否有能力开发进行分级。 一旦用例已经按这些类别来分类，就可以确定哪一个用例的子集是最重要的，并适合在第一次系统的迭代中实现。 这个过程包括一些权衡和妥协的综合考虑。 例如，一个用例的风险可能很高，这使得我们想在第一次迭代中实现它。但是，如果开发团队对实现这种用例完全没有把握，那么，作为妥协，我们应该选择一个风险较低的、较容易实现的用例。 * 用例分级 为了让这些工作简单一点，将用例的风险、重要性、合适性分成从1到5的五个级别。 级别越高，那么这个用例就越适合在第一个或者下一个迭代中实现。 考勤卡应用程序找到了6个用例，下图显示了这个高层用例图。 * 1．风险(risk) 你应该尽可能在开发周期的初期攻克系统有风险的部分。然后，即使出师不利，你仍然有足够的时间和机会来试着用其他的方法来做。 在考虑用例的风险之前，需要先列出项目的风险清单。以下的风险，对多数的项目来说都是存在的，它们可以作为考虑项目风险的出发点，并按此顺序考察每一个用例。 无法接受的系统性能。 无法应付新的需求。 不确定的进度以及开发周期。 无法接受的用户界面。 * 在按风险分级用例之前，我们将问开发人员这样一个问题：他们是否有把握在第一次尝试中解决某个问题，然后让他们从以下的答案中选择一个： 1)当然可以，我们的项目团队以前解决过这种问题。 2)没问题，我们机构以前解决过这种问题。 3)可以采用第三方提供的产品、培训、书或者其他的技术资源，但我们内部没有任何经验。 4)可能吧，我们听过类似的可以解决的问题。 5)我希望可以，但我们得做一些开创性的工作。 在评估用例的时候我们将会看到，这个简单的风险“谱”将帮助我们识别出在下一次迭代中必须考虑的高风险用例。 * 2．重要性(significance) 如果一个用例差不多就是系统的愿景，那它对用户以及架构就是很重要的。一个重要的用例应该能够体现系统的特性和目标。其他的用例也可能会很重要，但它们只是扮演支持的角色。 第12章 案例-续 * 是否可以这样衡量用例的重要性：我们询问开发人员，如果这个用例在本次迭代中忽略掉，或者用其他的用例来取代，那么用户将会怎样反应?让他们从以下的答案中选择一个： 1)他们几乎不会注意到这个用例不存在，在没有它的情况下使用这个系统不会有什么影响。 2)他们会注意到这个用例不存在，但是，稍加想像，这个系统仍然可以很好的使用。 3)系统的大部分可以独立于这个用