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

1、软件需求分析与设计绪论软件分析与设计绪论主要内容OOA/D的根本概念迭代开发案例引进9/22/20222软件分析与设计根本概念分析是对问题和需求的调查研究，不强调解决问题在面向对象分析过程中强调的是在问题领域发现和描述对象设计满足需求的概念上的解决方案，不强调实现面向对象的分析强调的是定义软件对象以及他们如何协作以实现需求9/22/20223面向对象分析的几个问题9/22/20224面向对象的分析模型和过程9/22/20225面向对象设计的几个问题9/22/20226OO模型9/22/20227OOD过程逐个设计OOD模型的五个局部问题域局部的设计人机交互局部的设计控制流管理局部的设计数据管理

2、局部的设计构件部署设计不强调次序每个局部均采用与OOA一致的概念、表示法及活动，但具有自己独特的策略9/22/20228问题管理局部的设计继续运用OOA 的方法，细化使用OOA的结果，并加以修改扩充为服用设计与编程的类而增加结果增加一般类以建立共同协议按编程语言调整集成提高性能为数据存储管理增补属性与效劳为编程方便增加底层成分决定关系的实现方式对例外的处理编程语言限制了可用的属性类型构造或优化算法调整效劳决定对象间的可访问性考虑采用设计模式9/22/20229人机交互局部的设计从use case 分析人机交互命令的组织设计模式：观察者、视图帮助者等开发工具的支持9/22/202210控制流程管

3、理局部的设计用主动对象表示每个控制流进程、线程所有的主动类构成控制流管理局部识别每个控制流审查与筛选定义各控制流控制流间的同步对进程和线程建模9/22/202211顺序系统的消息9/22/202212并发系统中的消息9/22/202213数据管理局部的设计利用关系数据系统进行数据存储设计永久类的存放设计设计数据管理局部的类并修改问题域系统保存和恢复对象的时机对关系的存储利用面向对象数据库系统进行数据存储设计利用文件实现数据存储9/22/202214软件分析与设计根本过程定义用例用例不是面向对象制品，而是对情节的记录，是需求分析中的工具定义领域模型面向对象分析关注从对象的角度创立领域描述，面向对

4、象分析需要鉴别重要的概念、属性和关联面向对象分析的结果可以表示为领域模型分配对象职责并绘制交互图面向对象设计关注软件对象的定义他们的职责和协作顺序图定义设计类图用设计类图描述类的静态视图9/22/202215软件分析与设计简单实例定义用例骰子游戏：游戏者请求掷骰子。系统展示结果：如果骰子的总点数是7，那么游戏者赢，否那么游戏者输领域模型PlayernameDieFace valueDie game1 Rolls 21Plays11 Includes29/22/202216软件分析与设计顺序图9/22/202217软件需求分析与设计_局部设计类图9/22/202218软件分析与设计迭代、进化和敏

5、捷软件开发过程描述构造、部署以及维护软件的方式统一软件开发过程UP)已成为一种流行的构造面向对象系统的迭代开发过程RUP (Rational Unified Process) 是对统一过程的详细细化灵活并且开放，鼓励引进其他迭代方法极限编程Scrum敏捷开发方法UP实践提供了如何实施OOA/D的示范结构9/22/202219软件分析与设计迭代、进化和敏捷迭代开发Iterative development是统一开发过程的关键实践开发被组织成一系列固定的短期小工程每次迭代都产生经过测试、集成并可执行的局部系统每次迭代都具有各自的需求分析、设计、实现和测试随着时间和一次次迭代，系统增量式完善9/22

6、/202220迭代和进化式9/22/202221在迭代工程中处理变更 早期迭代远离系统的“真实路径”。通过反馈和调整，系统向最适宜的需求和设计收敛包括设计、实现、集成和测试的一次迭代 在后期迭代中，很少会在需求上产生显著变化，但是存在这种可能性。这种后期的变化可能会给组织带来业务竞争优势9/22/202222软件分析与设计迭代、进化和敏捷迭代开发的优点减少工程失败的可能性，提高生产率，降低缺陷率在早期缓解高风险早期反响、用户参与和调整，会产生更接近真实需求的精化系统可控复杂性，团队不会被“分析瘫痪或长期且复杂的步骤所淹没一次迭代中的经验可以被系统地用于改进开发过程本身，并如此反复进行下去一次迭

7、代的持续时间和时间定量小步骤，快速反响和调整时间定量，必需按时间完成9/22/202223软件分析与设计迭代、进化和敏捷瀑布模型在编程之前试图定义所有或大局部需求在编程之前试图完成完整的设计试图在开始前定义“可靠的时间表问题错误的假设，规格说明是可预知的和稳定的，在开始就可以定义，具有低变更率变更对于软件是永恒在复杂变更系统中，反响和调整是成功的关键不要让瀑布思维侵蚀迭代或UP工程9/22/202224软件分析与设计迭代的分析设计实例1)第一次迭代前第一个时间定量需求会议进行高阶需求分析，确定用例和特性名称和关键的非功能属性通过咨询首席架构师和业务人员，选择10用例具有重要的架构意义具有高业务

8、价值对选出的用例的功能和非功能性需求进行详细分析2)召开迭代方案会议，选定特定时间进行设计、构造和测试9/22/202225软件分析与设计迭代的分析设计实例3)在34周完成第1次迭代分组进行建模和设计工作编程、测试和集成进行单元测试、验收测试、负载测试和可用性测试在结束前的一周，检查是否能够完成初始的迭代目标，如果不能，那么缩小迭代范围冻结代码，检查，集成测试，建立迭代基线向外部显示局部系统，展示可视进展和要求反响9/22/202226软件分析与设计迭代的分析设计实例4)在第1次迭代即将结束时，召开第2次需求工作会议，对上次会议所有的材料进行复查和精化，细化1015的用例5)举行下一个迭代的迭

9、代方案会议6)以相同的步骤进行第2次迭代7)反复进行4次迭代和5次需求工作会议，完成8090需求，实现系统的108工程推进20，进入细化阶段9此后一般不进行需求工作会议，需求已稳定9/22/202227进化式分析和设计早期迭代的主要形式需求20%软件2%需求30%软件5%50%8%90%10%90%20%迭代1 迭代2 迭代3 迭代4 迭代51234520需求讨论会假设该工程最终有20个迭代在进化式迭代开发中，通过一系列需求讨论会，需求在一组早期迭代中进化。或许经过四次迭代和讨论会后，可以定义和精化90%的需求，然而，只构建了10%的软件。MTWThFMTWThFMTWThF为期三周的迭代一星

10、期二星期三星期启动会议，向团队明确迭代目标，1小时团队进行敏捷建模和设计，在白板上绘制UML草图，5小时开始编码和测试在此期间进行大部分OOA/D并应用UML如果有太多工作，分解迭代目标为形成迭代基线，最后检入代码并冻结代码演示和为期两天的需求讨论会下一次迭代方案会议，2小时在讨论会上进行用例建模9/22/202228软件分析与设计迭代、进化和敏捷风险驱动与客户驱动更明确包含以架构为中心的迭代开发敏捷方法应用时间定量的迭代使用自适应方案，提倡增量交付敏捷宣言个体和迭代、超越过程和工具；工作的软件、超越完整的文档；客户协作、超越合同谈判；相应变更，查阅履行方案9/22/202229软件分析与设计

11、敏捷原那么优先级最高的是，通过早期和持续交付有价值的软件来满足客户欢迎变更需求，即使在开发的后期提出，敏捷过程为客户的竞争优势而控制变更以2周到2月为周期，频繁的交付可运行的软件，首推较短的时间定量在整个项目的过程中，每一天开发人员都要和业务人员合作由个体推动项目的建设，为个体提供所需的环境、支持和信任在开发团队中或开发团队间传递信息的最为有效和高效的方法是面对面交流衡量进展的重要尺度是可运行的软件敏捷过程提倡可持续的开发发起人、开发者和用户应该步调一致不断地关注技术上优越的设计会提高敏捷性简洁是最重要的，简洁就是尽量减少工作量的艺术最佳的架构、需求和设计来自组织的团队团队要定期反省如何使工作

12、更有效，然后相应地调整行为9/22/202230软件分析与设计迭代、进化和敏捷敏捷建模采用敏捷方法并不意味着不进行任何建模建模的目的主要是为了理解和勾通，而不是构建文档不要对所有或大多数软件设计建模或应用UML，可以将简单的设计问题推延到编程阶段尽可能使用最简单的工具不要单独建模，而是结对同时建模并行的创立模型在白板上画草图，“足够好就可以所有的模型可能是不精确的开发者应为自己进行OO设计建模9/22/202231敏捷建模草图例如9/22/202232软件分析与设计迭代、进化和敏捷敏捷UP推荐使用UP活动和制品简集实现前的需求可以不完整以敏捷建模实践应用UML不应有详细的方案主里程碑方案和下一

13、迭代方案9/22/202233软件分析与设计迭代、进化和敏捷UP的其他实践在早期迭代过程中解决高风险和高价值的问题不断地让用户参与评估、反响和需求在早期迭代中建立内聚的核心架构不断地验证质量；提早、经常和实际地测试在适当地方使用用例进行一些可视化建模认真管理需求实行变更请求和配置管理9/22/202234 初始细化构造 移 交里程碑发布增量最终产品发布 迭代的结束点，此时有重要决策或评估产生 最终产品的稳定可执行子集。每个迭代的结束点都是小型的发布 两次迭代发布子集之间的差异增量 此时，为产品的使用发布系统UP中面向进度表的术语迭代阶段开发周期9/22/202235科目9/22/202236科目与阶段UP科目样例初始 细化 构造 移交业务建模需求设计实现 科目的相对工作量在不同阶段有所变化 本例只是建议，并非严格规定9/22/202237简单开发案例s:开始，r:精化科目实践制品迭代初始I1细化E1.E