需求建设与面向对象的系统分析.pptVIP

需求建设与面向对象的系统分析 提纲 面向对象系统分析过程 1 如何建设需求？ 2 3 4 面向对象的系统分析 系统设计的一些想法 面向对象系统分析与设计过程 识别信息系统目标和系统边界 需求建设 系统分析 系统设计 系统实施 系统测试 识别信息系统目标和系统边界 目标：说明系统是干什么的，为什么开启这个项目，目的是什么，能够解决什么问题。 边界：能够处理哪些范围的工作，哪些问题不在系统中。 我们为什么要做这项工作？（个人理解） 让客户确定我们对系统的理解是否正确； 开发组的人员从上到下都能够知道我们做的是什么，要有一个整体的概念。什么做，什么不做，做到哪。后续处理问题时，就会有一个基本的导航。 如何建设需求？ 需求的重要性 1 需求调研 2 3 4 需求定义 需求变更 如何建设需求——需求的重要性 软件开发设计有如一条食物链。需求是保证形成健康食物链的开端。如果需求被污染了，那么它就会污染架构，而架构又会污染建构。这样会导致编码人员脾气暴躁，营养失调；开发出的软件具有放射性污染，而且周身都是缺陷。 ——《code complete》 如何建设需求—需求调研 需求调研：获取用户的需求。 问题定义：需要解决什么问题？ 用客户的语言来描述问题： “我们跟不上订单了” “我们需要优化数据自动采集系统，使之跟上订单” 对定义的问题寻找解决方法 定义系统的需求 一定要保证问题定义的正确性：如果没有一个良好的问题定义，你努力解决的可能是一个错误的问题。 如何保证需求调研的质量和问题定义的正确性？ 如何建设需求——需求定义 通过需求事件来定义需求，需求事件是系统分析建模的第一步； 需求事件分为三种：外部事件、临时事件、状态事件 外部事件：外部实体与系统交互的事件；eg.用户读帖； 临时事件：系统因为达到某一时刻而自动产生的事件；eg.凌晨生成热帖排行；每2s生成一次帖子列表； 状态事件：系统内部达到某一状态而发生的事件；eg.回收站满后自动清理； 事件的确认（如何定义所有的事件？）： 将系统按照功能划分，将每个功能细分； 以系统外的实体类型（eg.角色）为基础整理事件； 如何描述事件？ 事件名称：谁作什么；引起系统去执行某种操作的事件； (触发器)：什么促使事件的发生；系统如何知道这个事件发生了； 响应：获得了什么；系统产生了什么样的输出结果； 目的地：谁获得响应；那个外部实体获得了产生的输出结果； 说明：事件本身的相关说明；eg.帖子具体展现哪些内容 （前期的描述方式，后面再说） 操作流程 如何建设需求——需求变更 稳定需求的神话 稳定的需求是软件开发的圣杯。一旦需求稳定，项目就能以有序的、可预测的、平稳的方式，完成从架构到设计到编码到测试等一系列工作。这是软件的天堂！ 然而，这只是一个美好的愿望。需求变更是一定存在的，一般项目需求会有25%的变化。 如何处理需求变更 对已做的需求评估质量； 确保每一个人都知道需求变更的代价：进度、成本； 建立一套变更控制程序 使用能适应变更的开发方法 放弃这个项目 注意项目的商业案例 需求变更—需求评估 参照《需求质量核对表》 根据以上内容和遇到的问题，说明增加如下项： 定义全部需求或部分需求后，检查需求： 需求变更—建立变更目录 面向对象的系统分析 面向对象分析的主要任务：分析问题空间的主要目标和功能，寻找存在的对象，找出这些对象的特征和责任（即属性和服务），以及对象间的关系，并由此产生一个完整表达系统需求的规则说明——解决”做什么”； 面向对象设计的主要任务：将分析得到的需求作进一步的明确和调整，选用有效的设计样式优化对象结构，设计用户界面类，设计数据库结构等，强调的是根据分析结果产生一个知道面向对象编成的详细规格说明——解决“怎么做”； 采用面向对象建模符号——统一模型语言UML； UML定义了几种视图，从不同角度反映系统： 用例视图（用例图） 逻辑视图（类图、对象图） 行为视图（顺序图、协作图、状态图） 组件视图（组件图） 配置视图（配置图） 我们经常使用类图、用例图、(协作图) 、顺序图和状态图，与需求事件一起相互辅助，不断更改统一。 用例模型(1) 作用：更清晰地描述事件，确定需求，展现不同的用户角色和这些角色如何使用系统，表达需求事件之间的关系； 用例一般可分为： 基本用例 包含用例—经过封装后可以在不同的基本用例中复用的行为 扩展用例—表达某些可选或只在特定条件下才执行的系统行为 泛化用例—将存在共性的用例一般-特殊化 还包括其他关系用例：调用、前提 用例模型(2) 类模型 类图 通过事件的分析，确定实体关系图。这是一个迭代的