软件需求分析与设计－绪论

软件需求分析与设计绪论,2018/1/30,2,软件分析与设计绪论,主要内容OOA/D的基本概念迭代开发案例引进,2018/1/30,3,软件分析与设计基本概念,分析是对问题和需求的调查研究，不强调解决问题在面向对象分析过程中强调的是在问题领域发现和描述对象设计满足需求的概念上的解决方案，不强调实现面向对象的分析强调的是定义软件对象以及他们如何协作以实现需求,2018/1/30,4,面向对象分析的几个问题,2018/1/30,5,面向对象的分析模型和过程,2018/1/30,6,面向对象设计的几个问题,2018/1/30,7,OO模型,2018/1/30,8,OOD过程,逐个设计OOD模型的五个部分问题域部分的设计人机交互部分的设计控制流管理部分的设计数据管理部分的设计构件部署设计不强调次序每个部分均采用与OOA一致的概念、表示法及活动，但具有自己独特的策略,2018/1/30,9,问题管理部分的设计,继续运用OOA 的方法，细化使用OOA的结果，并加以修改扩充为服用设计与编程的类而增加结果增加一般类以建立共同协议按编程语言调整集成提高性能为数据存储管理增补属性与服务为编程方便增加底层成分决定关系的实现方式对例外的处理编程语言限制了可用的属性类型构造或优化算法调整服务决定对象间的可访问性考虑采用设计模式,2018/1/30,10,人机交互部分的设计,从use case 分析人机交互命令的组织设计模式：观察者、视图帮助者等开发工具的支持,2018/1/30,11,控制流程管理部分的设计,用主动对象表示每个控制流（进程、线程）所有的主动类构成控制流管理部分识别每个控制流审查与筛选定义各控制流控制流间的同步对进程和线程建模,2018/1/30,12,顺序系统的消息,2018/1/30,13,并发系统中的消息,2018/1/30,14,数据管理部分的设计,利用关系数据系统进行数据存储设计永久类的存放设计设计数据管理部分的类并修改问题域系统保存和恢复对象的时机对关系的存储利用面向对象数据库系统进行数据存储设计利用文件实现数据存储,2018/1/30,15,软件分析与设计基本过程,定义用例用例不是面向对象制品，而是对情节的记录，是需求分析中的工具定义领域模型面向对象分析关注从对象的角度创建领域描述，面向对象分析需要鉴别重要的概念、属性和关联面向对象分析的结果可以表示为领域模型分配对象职责并绘制交互图面向对象设计关注软件对象的定义他们的职责和协作顺序图定义设计类图用设计类图描述类的静态视图,2018/1/30,16,软件分析与设计简单实例,定义用例骰子游戏：游戏者请求掷骰子。系统展示结果：如果骰子的总点数是7，则游戏者赢，否则游戏者输领域模型,2018/1/30,17,软件分析与设计顺序图,2018/1/30,18,软件需求分析与设计_局部设计类图,2018/1/30,19,软件分析与设计迭代、进化和敏捷,软件开发过程描述构造、部署以及维护软件的方式统一软件开发过程（UP)已成为一种流行的构造面向对象系统的迭代开发过程RUP (Rational Unified Process) 是对统一过程的详细细化灵活并且开放，鼓励引进其他迭代方法极限编程Scrum（敏捷开发方法）UP实践提供了如何实施OOA/D的示范结构,2018/1/30,20,软件分析与设计迭代、进化和敏捷,迭代开发（Iterative development）是统一开发过程的关键实践开发被组织成一系列固定的短期小项目每次迭代都产生经过测试、集成并可执行的局部系统每次迭代都具有各自的需求分析、设计、实现和测试随着时间和一次次迭代，系统增量式完善,2018/1/30,21,迭代和进化式,2018/1/30,22,在迭代项目中处理变更,2018/1/30,23,软件分析与设计迭代、进化和敏捷,迭代开发的优点减少项目失败的可能性，提高生产率，降低缺陷率在早期缓解高风险早期反馈、用户参与和调整，会产生更接近真实需求的精化系统可控复杂性，团队不会被“分析瘫痪”或长期且复杂的步骤所淹没一次迭代中的经验可以被系统地用于改进开发过程本身，并如此反复进行下去一次迭代的持续时间和时间定量小步骤，快速反馈和调整时间定量，必需按时间完成,2018/1/30,24,软件分析与设计迭代、进化和敏捷,瀑布模型在编程之前试图定义所有或大部分需求在编程之前试图完成完整的设计试图在开始前定义“可靠的”时间表问题错误的假设，规格说明是可预知的和稳定的，在开始就可以定义，具有低变更率变更对于软件是永恒在复杂变更系统中，反馈和调整是成功的关键不要让瀑布思维侵蚀迭代或UP项目,2018/1/30,25,软件分析与设计迭代的分析设计实例,1)第一次迭代前第一个时间定量需求会议进行高阶需求分析，确定用例和特性名称和关键的非功能属性通过咨询首席架构师和业务人员，选择10用例具有重要的架构意义具有高业务价值对选出的用例的功能和非功能性需求进行详细分析2)召开迭代计划会议，选定特定时间进行设计、构造和测试,2018/1/30,26,软件分析与设计迭代的分析设计实例,3)在34周完成第1次迭代分组进行建模和设计工作编程、测试和集成进行单元测试、验收测试、负载测试和可用性测试在结束前的一周，检查是否能够完成初始的迭代目标，如果不能，则缩小迭代范围冻结代码，检查，集成测试，建立迭代基线向外部显示局部系统，展示可视进展和要求反馈,2018/1/30,27,软件分析与设计迭代的分析设计实例,4)在第1次迭代即将结束时，召开第2次需求工作会议，对上次会议所有的材料进行复查和精化，细化1015的用例5)举行下一个迭代的迭代计划会议6)以相同的步骤进行第2次迭代7)反复进行4次迭代和5次需求工作会议，完成8090需求，实现系统的108）项目推进20，进入细化阶段9）此后一般不进行需求工作会议，需求已稳定,2018/1/30,28,进化式分析和设计早期迭代的主要形式,需求,20%,软件,2%,需求,30%,软件,5%,50%,8%,90%,10%,90%,20%,迭代1 迭代2 迭代3 迭代4 迭代5,1,2,3,4,5,20,需求讨论会,假设该项目最终有20个迭代,在进化式迭代开发中，通过一系列需求讨论会，需求在一组早期迭代中进化。或许经过四次迭代和讨论会后，可以定义和精化90%的需求，然而，只构建了10%的软件。,M,T,W,Th,F,M,T,W,Th,F,M,T,W,Th,F,为期三周的迭代,一星期,二星期,三星期,启动会议，向团队明确迭代目标，1小时,团队进行敏捷建模和设计，在白板上绘制UML草图，5小时,开始编码和测试,在此期间进行大部分OOA/D并应用UML,如果有太多工作，分解迭代目标,为形成迭代基线，最后检入代码并冻结代码,演示和为期两天的需求讨论会,下一次迭代计划会议，2小时,在讨论会上进行用例建模,2018/1/30,29,软件分析与设计迭代、进化和敏捷,风险驱动与客户驱动更明确包含以架构为中心的迭代开发敏捷方法应用时间定量的迭代使用自适应计划，提倡增量交付敏捷宣言个体和迭代、超越过程和工具；工作的软件、超越完整的文档；客户协作、超越合同谈判；相应变更，查阅履行计划,2018/1/30,30,软件分析与设计敏捷原则,2018/1/30,31,软件分析与设计迭代、进化和敏捷,敏捷建模采用敏捷方法并不意味着不进行任何建模建模的目的主要是为了理解和勾通，而不是构建文档不要对所有或大多数软件设计建模或应用UML，可以将简单的设计问题推延到编程阶段尽可能使用最简单的工具不要单独建模，而是结对同时建模并行的创建模型在白板上画草图，“足够好”就可以所有的模型可能是不精确的开发者应为自己进行OO设计建模,2018/1/30,32,敏捷建模草图示例,2018/1/30,33,软件分析与设计迭代、进化和敏捷,敏捷UP推荐使用UP活动和制品简集实现前的需求可以不完整以敏捷建模实践应用UML不应有详细的计划主里程碑计划和下一迭代计划,2018/1/30,34,软件分析与设计迭代、进化和敏捷,UP的其他实践在早期迭代过程中解决高风险和高价值的问题不断地让用户参与评估、反馈和需求在早期迭代中建立内聚的核心架构不断地验证质量；提早、经常和实际地测试在适当地方使用用例进行一些可视化建模认真管理需求实行变更请求和配置管理,2018/1/30,35,初始,细化,构造,移 交,里程碑,发布,增量,最终产品发布,迭代的结束点，此时有重要决策或评估产生,最终产品的稳定可执行子集。每个迭代的结束点都是小型的发布,两次迭代发布子集之间的差异（增量）,此时，为产品的使用发布系统,UP中面向进度表的术语,迭代,阶段,开发周期