• 1. 软件工程导论第一章
  • 2. 本章要点工程的概念 软件工程的发展 软件工程分析 三种过程模型 工程化思考
  • 3. 工程是什么?工程简而言之就是多人参与并有计划、有步骤地完成一项任务的活动 工程强调 目的 计划 步骤
  • 4. 软件发展与软件工程起源软件的发展四个阶段: 1950年前后到1960年前后,程序设计阶段; 1960年前后到1970年前后,软件系统阶段; 1970年前后到1980年前后互联网络兴起,软件工程阶段; 1980年前后到现在,分布式软件工程阶段; 1968年,北大西洋公约组织的计算机科学家召开国际会议,第一次提出软件危机的概念,产生了应对软件危机的对策---软件工程。
  • 5. 软件工程与建筑工程的对比预算画设计图施工质检可行性分析需求分析 详细设计、概要设计编码测试兴建一座高楼创造一部软件产品销售、入住使用销售、安装使用
  • 6. 工程策略任何工程都有如下的策略: 分而治之 复用 折衷优化 检验并保证质量 软件工程也会充分利用这些策略
  • 7. 分而治之把复杂的问题分解为小的问题并一一解决 分而治之图示复杂问题子问题1子问题2子问题3子程序1子程序2子程序3分 解程序
  • 8. 复用利用现有的组件来构筑软件的一部分功能 组件技术有:CORBA、EJB、COM 软件复用图示:分解系统组件开发创建新组件提取组件从组件库中 查找 可用组件用组件 编制软件组件库组件定义
  • 9. 软件开发的发展与变化 软件技术的发展带来了一些变化: 1 用户对软件要求的变化:软件规模在扩大;对软件的质量要求在提高; 2 软件技术本身的变化:新的理念、新的方法和新的工具 3 软件开发队伍的变化:从单人开发、小组开发,到大规模团队开发;从稳定、相对稳定到全员流动
  • 10. 软件开发的发展与变化 应对这些变化的是: 1 市场化:软件开发由个人爱好行为转变为企业行为,需要大量的投资、大量的人力,并且要按照市场规律来运作 2 知本化:要求技术的积累、模块的积累和成果的积累; 3 开发过程的规范化:来应对需求多变,人员流动 4 标准化:能力成熟度,质量控制
  • 11. 软件工程的目标软件工程的目标是提高软件的质量与生产率,最终实现合格的软件。 质量是软件需求方最关心的问题。 生产率是软件供应方最关心的问题。
  • 12. 软件工程的四项基本原则 选取适宜开发范型 采用合适的设计方法 提供高质量的工程支持 重视开发过程的管理
  • 13. 软件工程准则七条基本准则 1) 生命周期计划; 2) 阶段评审; 3) 变更控制; 4) 改进程序设计技术; 5) 控制人员规模; 6) 定义评审; 7) 不断改进软件工程;
  • 14. 软件工程的要素 方法:软件工程方法为软件开发提供了“如何做”的技术,是完成软件工程项目的技术手段; 工具:软件工具是在开发软件的活动中智力和体力的扩展和延伸,为软件工程方法提供了自动的或半自动的软件支撑环境; 过程:软件工程的过程则是将软件工程的方法和工具综合起来以达到合理、及时地进行计算机软件开发的目的。
  • 15. 软件工程的组成人员管理 项目管理 过程管理
  • 16. 瀑布模型瀑布模型将软件生命周期的各项活动顺序进行,形如瀑布流水,最终得到软件产品 是最早的软件工程模型,是其他所有现代模型的基础 可行性分析需求分析概要设计详细设计编码测试部署维护软件团队Time
  • 17. 瀑布模型 continue
  • 18. 阶段任务、结果及人员 阶段 基本任务工作结果参加者计划期可行性研究与计划研究开发该项目的可行性 可行性研究报告用户、高级程序员 开发期 需求分析理解和表达用户的要求需求说明书用户、高级程序员设 计建立系统的结构模块、数据说明书用户、高级程序员 编 程 编写程序程序高级程序员、初级程序员测 试发现错误和排除错误   测试报告另一独立的部门运行期运行与维护维护 改进的系统用户、高级程序员
  • 19. 瀑布模型特征 从上一项活动接收该项活动的工作对象,作为输入; 利用这一输入实施该项活动应完成的内容; 给出该项活动的工作成果,作为输出传给下一项活动; 对该项活动实施的工作进行评审,若其工作得到确认,则继续下一项活动,否则返回前项,甚至更前项的活动进行返工。
  • 20. 瀑布模型各个阶段概述可行性分析:做还是不做 需求分析: 都有什么功能 概要设计:供有多少子功能 详细设计:子功能怎么实现 编码:子功能实现了吗 测试:功能完备吗 部署:需要多少设备和软件的支持 维护:软件运行的正常吗
  • 21. 可行性分析可行性分析因素 经济 技术 社会环境 人才
  • 22. 需求分析
  • 23. 概要设计提供多少子功能 面向对象分析(OOA)
  • 24. 详细设计子功能如何实现 面向对象设计(OOD)
  • 25. 编码子功能是否实现? 程序员严格按照规范编码;
  • 26. 测试单元测试 系统测试 用户测试
  • 27. 部署部署要求 增强自动化程度,用ant等工具 培训最终用户 要有详细计划 记录详细的过程数据 及时反馈软件兼容性缺陷
  • 28. 维护一般维护分三类: 纠错性维护 改正软件漏洞、发布补丁程序 适应性维护 使得软件在新的硬件、操作系统、编译器和解释器下运行 完善性维护 增加新功能、更改原有的设计等
  • 29. 影响维护成本的因素非技术因素 需求的复杂性 开发人员的岗位稳定性 软件的生命期 外部环境的变化,例如财政政策影响财务软件 技术因素 软件运行环境 编程语言 编程风格 测试工作的有效性 文档的质量
  • 30. 瀑布模型的优点 通过设置里程碑,明确每阶段的任务与目标 可为每阶段制定开发计划,进行成本预算,组织开发力量 通过阶段评审,将开发过程纳入正确轨道 严格的计划性保证软件产品的按时交付
  • 31. 瀑布模型的缺点 缺乏灵活性,不能适应用户需求的改变 开始阶段的小错误被逐级放大,可能导致软件产品报废 返回上一级的开发需要十分高昂的代价 随着软件规模和复杂性的增加,软件产品成功的机率大幅下降
  • 32. 演化模型可行性分析需求分析概要设计详细设计编码测试部署维护软件团队Time可行性分析需求分析概要设计详细设计编码测试部署维护软件团队可行性分析需求分析概要设计详细设计编码测试部署维护软件团队版本1版本2版本3
  • 33. 迭代模型可行性分析需求分析v1概要设计v1详细设计v1编码v1测试v1部署维护软件团队概要设计v2详细设计v2详细设计v3编码v2测试v2需求分析v2Time
  • 34. 迭代模型 continue
  • 35. 迭代模型 continue迭代的定义:迭代包括产生产品发布(稳定、可执行的产品版本)的全部开发活动和要使用该发布必需的所有其他外围元素。 生命周期是基于对一个系统进行连续的扩充和精化,需要经历若干个开发周期,每个周期都需要经历分析、设计、实现和测试阶段。每个开发周期只针对比较小的一部分需求 在某种程度上,开发迭代是一次完整地经过所有工作流程的过程:(至少包括)需求工作流程、分析设计工作流程、实施工作流程和测试工作流程; 类似小型的瀑布式项目。RUP认为,所有的阶段(需求及其它)都可以细分为迭代。每一次的迭代都会产生一个可以发布的产品,这个产品是最终产品的一个子集。
  • 36. 迭代的优点降低了在一个增量上的开支风险。如果开发人员重复某个迭代,那么损失只是这一个开发有误的迭代的花费。 降低了产品无法按照既定进度进入市场的风险。通过在开发早期就确定风险,可以尽早来解决而不至于在开发后期匆匆忙忙。 加快了整个开发工作的进度。因为开发人员清楚问题的焦点所在,他们的工作会更有效率。 由于用户的需求并不能在一开始就作出完全的界定,它们通常是在后续阶段中不断细化的。因此,迭代过程这种模式使适应需求的变化会更容易些。
  • 37. 迭代模型和瀑布模型的差别最大的差别在于风险的暴露时间上。 任何项目都会涉及到一定的风险。如果能在生命周期中尽早确保避免了风险,那么计划自然会更趋精确。 有许多风险直到已准备集成系统时才被发现。不管开发团队经验如何,都绝不可能预知所有的风险。
  • 38. 迭代模型和瀑布模型的差别
  • 39. 统一软件过程RUP模型
  • 40. RUP中的软件生命周期初始阶段(Inception):目标是为系统建立商业案例并确定项目的边界。 细化阶段(Elaboration):目标是分析问题领域,建立健全的体系结构基础,编制项目计划,淘汰项目中最高风险的元素。 构造阶段(Construction):所有剩余的构件和应用程序功能被开发并集成为产品,所有的功能被详细测试。 交付阶段(Transition):重点是确保软件对最终用户是可用的。 每个阶段结束于一个主要的里程碑(Major Milestones);每个阶段本质上是两个里程碑之间的时间跨度。在每个阶段的结尾执行一次评估以确定这个阶段的目标是否已经满足。如果评估结果令人满意的话,可以允许项目进入下一个阶段。
  • 41. RUP模型的优缺点 优点 提高了团队生产力,在迭代的开发过程、需求管理、基于组件的体系结构、可视化软件建模、验证软件质量及控制软件变更等方面,针对所有关键的开发活动为每个开发成员提供了必要的准则、模板和工具指导,并确保全体成员共享相同的知识基础。 建立了简洁和清晰的过程结构,为开发过程提供较大的通用性。 缺点 RUP只是一个开发过程,并没有涵盖软件过程的全部内容,例如它缺少关于软件运行和支持等方面的内容; 没有支持多项目的开发结构,这在一定程度上降低了在开发组织内大范围实现重用的可能性。
  • 42. 软件项目管理第二章
  • 43. 本章要点项目管理一般原理 Project 2002中的项目管理概念 用Project2002做项目计划 关键路径、关键任务计算法则
  • 44. 成功的软件项目有多少?16%53%31%成功实现失控取消
  • 45. 为什么失败?项目失败的前5个原因0%5%10%15%需求分析不完整缺少用户参与缺少资源不现实的期望缺乏系统支持缺少项目管理
  • 46. 项目管理项目管理的定义 项目管理分三个阶段: 制定项目计划 管理和跟踪项目 结束项目
  • 47. 项目管理三角形时间费用范围
  • 48. 项目轮廓定义目标 前提 限制 范围
  • 49. 项目计划要素任务 任务相关性 工期 成本 资源
  • 50. 任务相关性任务相关性:两个链接任务之间的关系;通过完成日期和开始日期之间的相关性进行链接。有四种任务相关性类型:“完成-开始”(FS)、“开始-开始”(SS)、“完成-完成”(FF)、“开始-完成”(SF)。 当关键任务完成或另一系列中的任务发生延迟时,关键路径就会更改。
  • 51. 任务相关性 任务相关性描述 例子完成-开始(FS)只有在任务 A 完成后任务 B 才能开始。 地基要先建好才能盖房子 开始-开始(SS)只有在任务 A 开始后任务 B 才能开始。 所有的人员都到齐后会议才能开始 完成-完成(FF)只有在任务 A 完成后任务 B 才能完成。 所有的资料全部准备齐全后才能结案 开始-完成(SF)只有在任务 A 开始后任务 B 才能完成。 站岗时,下一个站岗的人来了,原本站岗的人才能回去
  • 52. 工作分解结构项目摘要任务1摘要任务2任务3任务1.1任务1.2摘要任务2.1任务2.1.1任务2.1.2任务关系树型图
  • 53. WBS代码列
  • 54. Project 中创建项目计划文档新建项目文档 定义常规工作时间 添加分层任务 读取来自Excel的资料 添加资源 给任务配备资源
  • 55. 任务相关操作创建里程碑(0天) 创建周期性任务 创建和删除任务链接 创建任务相关性 设置任务限制
  • 56. 工时计算公式工时=工期×单位(资源工作分配单位)工期是完成任务所经历的实际时间 工时是资源执行任务的工作时间 单位是资源的分配量 全职工作人员的单位一般是100% 兼职工作人员的单位一般是50%
  • 57. 详细甘特图
  • 58. 关键路径是贯穿整个项目的一条路径,表明在限定的时间成功完成项目涉及的各任务间的依赖关系。 调整关键路径上任务的时间进度将会影响整个项目的交付时间。 关键路径方法(CRM)图是一种网络图,用于项目的进度控制和协调项目的活动和事件。
  • 59. 最早/晚完成日期最早完成日期:根据前置任务和后续任务的最早完成日期、其他限制以及任何调配延迟,任务可能完成的最早日期。 即任务在开始日期和预计工期的基础上能够最早完成的日期。 最晚完成日期:在不延迟项目完成时间的情况下,任务可以完成的最晚日期。该日期基于任务最晚开始日期、前置任务和后续任务的最晚开始和完成日期及其他限制。 即任务在不延迟项目完成时间的情况下能够最晚完成的日期。
  • 60. 关键任务/时差关键任务是指一旦延迟就会影响项目完成日期的任务。 时差:在不影响其他任务或项目完成日期的情况下,任务可以落后的时间量。 可用时差是在不延迟其他任务的情况下,任务可以落后的时间量。 总时差是在不延迟项目的情况下,任务可以落后的总时差。 在典型的项目中,很多任务都有时差,因此即使延迟一小段时间也不会影响其他任务或项目完成日期。
  • 61. 关键任务/时差 continue当一项任务满足以下任何一个条件时,该任务即成为关键任务: 该任务没有时差。 该任务有“必须开始于”(MSO) 或“必须完成于”(MFO) 的日期限制 (限制:对任务的开始日期或完成日期设置的限制。可以指定任务在特定日期开始,或者不晚于特定日期完成。限制可以是弹性的(未指定特定日期),也可以是非弹性的(指定了特定日期)。 在一个从开始日期排定的项目中,该任务有“越晚越好”(ALAP) 的限制。 在一个从完成日期排定的项目中,该任务有“越早越好”(ASAP) 的限制。 该任务的完成日期等同于或超出期限 (期限:表明希望完成任务的目标日期。如果期限日期已过而任务仍未完成,Project 就会显示一个标记。)日期。 当一项任务标记为已完成时,就不再是关键任务,因为它不再影响后续任务的完成或项目完成日期。
  • 62. 关键路径显示项目的内容通过了解和跟踪项目的关键路径和分配给关键任务 的资源,就可以确定哪些任务会影响项目的完成日期以及项目能否按时完成。
  • 63. 任务节点表示任务节点 任务链接最早开始时间持续时间最早结束时间任务标识号时差最晚开始时间最晚结束时间=最早结束时间-最早开始时间 =最晚结束时间-最晚开始时间=最晚结束时间-最早结束时间 =最晚开始时间-最早开始时间工期549421263097167113037
  • 64. 网络初始状态123569478
  • 65. 计算工期5182123105206594477108因为举例子,所以直接填写工期
  • 66. 计算最早开始时间和最早结束时间055158132512173131023517203763754295494971672310338
  • 67. 计算最晚开始时间和最晚结束时间05510558132917512173517131023517271720376173737542937425494263097167303723103382737
  • 68. 计算时差完成这些任务最多用42单位工期 关键路径为13690551005581324917131023541727512173051754942126309716711303723103384273717203760173737542903742
  • 69. 关键任务实例 (1)此任务序列没有时差 ,因而会推动项目的完成日期尽早到来。此序列中的所有任务都在关键路径上,称为关键任务。在“详细甘特图”视图中,关键任务显示为红色。 (2)此任务序列不会推动项目的完成日期尽早到来,因此不是关键任务。在“详细甘特图”视图中,非关键任务显示为蓝色。 (3)总时差是指此任务序列在不影响项目的完成日期的条件下可跳过的时间量。在“详细甘特图”视图中,总时差显示为浅蓝绿色线。 如果项目必须如期完成,应该密切关注关键路径上的任务以及为其分配的资源。这些要素将决定项目能否按时完成。                                                                                                                  
  • 70. 如何缩短关键路径冲击:在不更改任务关系的情况下缩短项目的总体工期。对项目进行冲击通常需要为任务分配额外的资源。 缩短关键路径上任务的工期或工时。 更改任务限制,以增加日程排定的灵活性。 将关键任务分解成多个由不同资源同时进行的小任务。 更改任务相关性,以增加日程排定的灵活性。 在适用的相关任务间设置前置重叠时间。 排定加班工时。 为关键路径上的任务分配额外资源。
  • 71. MSF介绍第三章
  • 72. 本章要点MSF内容 组队模型 过程管理模型 应用程序模型
  • 73. 什么是MSFMSF(Microsoft Solution Framework)是指微软解决方案框架。 MSF描述了微软公司从众多大小软件产品研发实践中总结的管理软件开发过程的经验
  • 74. 程序员眼中的MSF三个核心组队模型 过程管理模型 应用程序模型
  • 75. 三种模型的关系组队模型应用程序模型过程管理资源配置功能划分过程模型
  • 76. 组队原则清晰的责任,共同的职责 赋予小组成员权力 聚焦业务价值 共同的项目设想 保持灵活,预测变化 推动开放式沟通
  • 77. 关键概念 同级小组 以客户为中心 产品理念体系 零缺陷 乐意学习 有动力的小组有效率
  • 78. 成功的做法小型的多学科小组 一起工作 全员参与设计
  • 79. 组队模型开发程序管理产品经理用户体验发布经理测试交流!
  • 80. 角色与目标目标满足客户提高用户效率 根据规格说明创建解决方案 确保产品质量事宜被识别并处理 交付满足项目约束的解决方案 进行平滑的部署及日常运行 产品经理用户体验开发测试程序管理发布经理组队角色
  • 81. 可合并角色表产品管理程序管理开发测试用户体验发布经理产品管理NNPPU程序管理NNUUP开发NNNNN测试PUNPP用户体验PUNPU发布经理UPNPU
  • 82. 案例1:角色合并了的小团队开发程序管理发布经理测试产品管理用户体验
  • 83. 案例2:大项目的功能团队领导 团队开发 经理测试 经理团队 程序 经理产品 管理用户 体验发布经理 经理客服 团队开发测试程序 经理预定 团队开发测试程序 经理计费 团队开发测试程序 管理专注的资源
  • 84. 案例3:一个微软的开发小组示例一个项目经理 两个软件工程师 两个软件测试工程师
  • 85. 案例4:微软的项目产品组行政结构图产品单元经理团队程序经理程序经理组长程序经理软件开发经理软件开发组长软件开发人员测试经理测试组长测试人员
  • 86. 过程模型 构想阶段设计阶段开发阶段稳定阶段组建项目团队前景/范围认可 项目设计认可 范围完成/第一次使用 系统发布
  • 87. 构想阶段定义初步的商业需求(持续性工作) 风险管理 定义项目结构 研究和收集设想 进行初步的用户访问 定义使用场合 确立设计目标 制定初步的解决方案概念 制定初步的项目范围 定义关键的成功因素 定义衡量成功的标准 定义主要的可交付结果(初步) 确定构想/范围
  • 88. 设计阶段创建功能描述 开发计划 测试计划 用户培训计划 后勤计划 产品管理计划 程序管理计划 合并项目计划
  • 89. 开发阶段迭代开发一到多次的内部发布版 开发目标组件 测试单个组件 测试组装为整体的应用程序 功能说明冻结 最后的特性开发 最后的后勤开发 最后的性能支持开发
  • 90. 稳定阶段发布一到多个测试版,包括 α测试版和β测试版 收集错误 改正高优先级的错误,发布无错误版 进行最后的错误分类 黄金发布版
  • 91. 应用程序模型应用程序1应用程序2用户界面服务商业逻辑服务数据存取服务
  • 92. UML:系统结构第四章
  • 93. 本章要点OOAD与UML 用例图 类图与类关系 组件图、包和部署图
  • 94. 分析、设计、编程面向对象分析(OOA) 面向对象设计(OOD) 面向对象编程(OOP)
  • 95. UML诞生面向对象分析和设计的结果需要统一符号来描述并记录。 统一建模语言—— UML(Unified Modeling Language)
  • 96. UML发展OMT BoochOOSEUML 0.91996UML 1.11997UML 1.4 2000UML 2.02001
  • 97. 系统需求(学生注册)管理员按照学校计划预先设置课程 学生可以通过该系统选择课程。 学生选好课程以后财务系统可以发费用清单给学生。 学生可以增删选择的课程。 教授可以获得自己课程的名单。 所有角色都必须经过登陆。
  • 98. 用例图图元(角色)角色 有两种符号表示。角色名称<<角色>> 角色名称
  • 99. 用例图图元(用例)用例 实线椭圆表示用例,用例名称写在椭圆下面。用例名称
  • 100. 用例图图元(系统边界)系统边界,系统边界可以省略 系统名称 箭头表示参与
  • 101. 用例图学生登陆员教授维护选课计划维护课程表请求花名册财务系统学生注册系统
  • 102. 用例之间的关系注册课程<<包含>>登陆验证<<包含>>维护课程表帐号密码验证<<扩展>>登陆验证<<扩展>>指纹验证数字签名验证<<扩展>>
  • 103. 发现类分两步 先发现候选类 然后净化候选类 净化原则: 摒弃冗余 通过继承合并重组类 提取接口或者抽象类重组类 通过拆分类,保证类对应的概念清晰
  • 104. 发现候选类应用专家需求说明原有系统同类系统候选类用例和角色
  • 105. 类图RegistrationFormRegistrationManageraddStudent (Course, StudentInfo)CoursenamenumberCreditsStudentnamemajorCourseOfferinglocationopen()addStudent(StudentInfo)ProfessornametenureStatusScheduleAlgorithm
  • 106. 类图类图由水平线分割为三个部分 类名称属性方法Student-name:String -major:int+register(Lesson):void +showReg():void+表示public - 表示private #表示protected
  • 107. 关联关联分单向或双向RegistrationFormRegistrationManager10..* manageEmployee单向关联双向关联这也是关联中的特殊的一种,递归关联
  • 108. 聚合 StudentCourseOfferingProfessornamenumberCreditsmajorlocationopen()addStudent(StudentInfo)tenureStatusCourse
  • 109. 继承学生和教授用《学生注册管理系统》的第一步要登陆。所以他们都有登录用户的含义StudentProfessornameRegistrationUser
  • 110. 依赖关系RegistrationManagerScheduleAlgorithm依赖关系表达了概念之间的依赖性。比如类R中需要调用类S 的算法,因此表现为依赖,表示方法虚箭头线。
  • 111. 类关系图RegistrationFormRegistrationManagerCourseStudentCourseOfferingProfessoraddStudent(Course, StudentInfo)namenumberCreditsopen()addStudent(StudentInfo)majorlocationopen()addStudent(StudentInfo)tenureStatusScheduleAlgorithm10..*0..*1
  • 112. 抽象类表示StudentProfessornameRegistrationUser
  • 113. 接口表示接口名称MyThread+run():voidRunnable
  • 114. 组件图CourseCourse OfferingStudentProfessorCourse.dllPeople.dllCourseUserRegister.exeBilling.exeBilling System
  • 115. 部署图学生注册 管理系统数据库图书馆宿舍教学楼
  • 116. UML:系统动态第五章
  • 117. 本章要点动态模型 序列图 协作图 状态图 活动图 UML图分类
  • 118. 动态模型动态模型描述系统随时间演化细节 描述系统动态的UML图有: 交互图 序列图 协作图 演化图 状态图 活动图
  • 119. 交互图序列图 描述了对象之间的交互,重点在于描述消息及其时间顺序 协作图 和序列图一样描述了对象之间的交互,但是重点在于描述消息及其实现
  • 120. 交互图的关键消息对象之间的的信息传递就是所谓的消息发送 消息就是对象调用另外一个对象的方法时所传递的参数 发送者和接收者之间的箭头表示消息
  • 121. 消息的类型简单 同步 异步 计时消息 返回消息
  • 122. 序列图元素角色类对象普通对象带有消息编号的先后消息对象的生存期
  • 123. 序列图案例
  • 124. 序列图组成两个方向的扩展 消息穿梭在序列图中 一系列对象 消息编号
  • 125. 绘制序列图相邻摆放 生存期要精确 顺序和编号 系统运行时的微观图
  • 126. 协作图元素角色类对象普通对象带有编号的消息传递
  • 127. 协作图案例
  • 128. 协作图组成对象节点 消息链接 网络布局 消息编号
  • 129. 绘制协作图重点描述消息 网状的图 两个对象之间的多条消息 核心对象放在中间 编号要准确
  • 130. 演化图状态图 描述某一对象的生命周期中需要关注的不同状态 刺激状态转移的事件和对象采取的动作也要被描述 活动图 描述用例内部的活动或方法的流程 多了对并行活动的描述以外它就是流程图 Rose2002中活动图中可以增加对状态的描述
  • 131. 演化图5个要素用例范围动作事件状态1状态2条件活动对象的方法调用
  • 132. 事件类型有两种类型事件 内部事件 为从系统内部激发的事件,一个对象的动作通过事件激活另一个对象动作 外部事件 为从系统边界外的激发的事件
  • 133. 状态和事件状态是某一时间段内对象所保持的稳定态 一个对象的状态一般是有限的 状态可以想象成对象演化当中的照片 事件是来自对象外部的刺激 事件是对象演化的动力 事件可以想象成电击对象的行为
  • 134. 状态图元素对象状态初始状态终结状态事件[条件]
  • 135. 状态图案例
  • 136. 状态图的组成初始状态 终结状态 生存期状态 事件 动作 条件
  • 137. 状态图绘制保证一个初始状态 可以有多个终结状态 状态是对象演化中的离散快照 状态要表示对象的关键快照,有重要的实际意义 事件和动作要明确
  • 138. 活动图元素并行: 条件:[ ] 分支点: 开始结束活动事件
  • 139. 活动图案例
  • 140. 活动图的组成开始活动和结束活动 其他活动 并行活动 分支和循环活动 事件 条件
  • 141. 活动图绘制一个开始活动和一到多个结束活动 活动为中心 并行活动和串行活动的分离 分支逻辑和循环逻辑都可以表示 分支和循环条件最好明确表示
  • 142. UML图分类结构 动态 模型管理
  • 143. 设计模式第六章
  • 144. 内容简介设计模式背景知识 设计模式的种类 Factory Method Abstract Factory Adapter(Object) Observer MVC
  • 145. 设计模式背景知识模式的出现 软件设计中的模式 设计模式的定义
  • 146. 模式的出现 20世纪70年代 Alexander 建筑设计模式
  • 147. 软件设计中的模式Erich Gamma、Richard Helm、Ralph Johnson、John Vlissides 《Design Patterns—Elements of Reusable Software》 GOF 23
  • 148. 设计模式的定义解决重复设计问题 反复出现的设计问题的解决方案 模式被用来在特定场景下解决一般设计问题的类和相互通信的对象的描述 处理同一类软件分析结果的典型设计结构
  • 149. 设计模式的种类类范畴 创建型 结构型 行为型 对象范畴 创建型 结构型 行为型
  • 150. 模式讲解思路模式提出 模式案例 模式原理分析
  • 151. Factory Method案例1
  • 152. Factory Method案例2
  • 153. Factory Method(工厂方法)对象创建型模式 意图:定义一个用于创建对象的接口,让子类决定实例化哪一个类。使一个类的实例化延迟到其子类。 别名:虚构造器 动机:框架使用抽象类定义和维护对象之间的关系,对象的创建由框架负责。但它只知道要创建的对象的抽象父类,而不知道具体哪一种子类将被创建。 工厂方法:它将负责“生产”一个对象。 本质:用一个virtual method完成创建过程。
  • 154. Factory Method(工厂方法)适用性: 当一个类不知道它所必须创建的对象的类的时候; 当一个类希望由它的子类来指定它所创建的具体对象的时候;
  • 155. Factory Method原理1
  • 156. Factory Method原理2
  • 157. Factory Method(工厂方法) 参与者AbstractProduct 定义工厂方法所创建的对象的接口 RealProduct 实现AbstractProduct接口 ProductFactory 声明工厂方法,该方法返回一个AbstractProduct类型的对象。 RealProductFactory 重定义工厂方法以返回一个RealProduct对象。
  • 158. Factory Method(工厂方法)协作过程 ProductFactory依赖于它的子类来定义工厂方法,所以它返回一个适当的RealProduct对象。 效果 工厂方法不再将与特定应用有关的类绑定到代码中。代码仅处理AbstractProduct接口,因此它可以与用户定义的任何RealProduct一起使用。
  • 159. Abstract Factory案例
  • 160. Abstract Factory对象创建型模式 意图:提供一个创建一系列相关或相互依赖对象的接口,而无需指定它们具体的类。 别名:Kit 动机:客户仅通过NotepadFactory接口创建Notepad的组件monitor/battery/cpu,它们并不知道哪些类创建了这些组件。即:客户仅与抽象类定义的接口交互,而不使用特定的具体类的接口。
  • 161. Abstract Factory适用性: 一个系统要独立于它的产品的创建、组合和表示时; 一个系统要有多个产品系列中的一个来配置时; 当你要强调一系列相关的产品对象的设计以便进行联合使用时; 当你要提供一个产品类库,而只想显示它们的接口而不是实现时。
  • 162. Abstract Factory原理
  • 163. Abstract Factory 参与者AbstractFactory 声明一个创建抽象产品对象的操作接口; RealFactory 实现创建具体产品对象的操作; AbstractProduct 为一类产品对象声明一个接口; RealProduct 定义一个将被相应的具体工厂创建的产品对象; 实现AbstractProduct接口;
  • 164. Abstract Factory协作过程 通常在运行时刻创建一个RealFactory类的实例,这一具体的factory创建具有特定实现的产品对象。为创建不同的产品对象,客户应使用不同的具体工厂。 AbstractFactory将产品对象的创建延迟到它的RealFactory子类。
  • 165. Abstract Factory效果 它分离了具体的类; 它使得易于交换产品系列; 它有利于产品的一致性; 难以支持新种类的产品;
  • 166. 工厂方法及抽象工厂 总结了解每一种模式的实质 具体实现的时候可能会有变化情况,或者扩展,或者退化 factory method是基础,abstract factory是它的扩展 factory method、abstract factory都涉及到类层次结构中对象的创建过程,有所取舍 factory method需要依附一个creator类 abstract factory需要一个平行的类层次 根据应用的其他需求,以及语言提供的便利来决定使用哪种模式
  • 167. Adapter(Object)案例
  • 168. Adapter 适配器意图:将一个类的接口转换为客户希望的另外一个接口。 Adapter 模式使原本由于接口不兼容而不能一起工作的类可以一起工作。 动机:为复用而设计的工具箱类不能被复用的原因仅仅因为它的接口与专业应用领域所需要的接口不匹配。
  • 169. Adapter 适配器适用性: 你希望使用一个已经存在的类,而它的接口不符合你的需求。 你想创建一个可以复用的类,该类可以与其他不相关的类或不可预见的类协同工作。
  • 170. Adapter(Object)原理
  • 171. Adapter(Object) 参与者Target:定义客户端使用的与特定领域相关的接口。 Adaptee:定义一个已经存在的接口,这个接口需要适配 Adapter:对Adaptee的接口与Target接口进行适配。
  • 172. Adapter(Object) 协作过程: 客户端在Adapter实例上调用一些操作,接着适配器调用Adaptee的操作实现这个请求。
  • 173. Adapter(Object) 效果(对象适配器): 允许一个Adapter与多个Adaptee—即Adaptee本身以及它的所有子类同时工作。 使得重定义Adaptee的行为比较困难。 需要考虑的问题: Adapter的匹配程度:Adapter的工作量取决于Target接口与Adaptee接口的相似程度。
  • 174. Observer意图:定义对象间的一种一对多的依赖关系,当一个对象的状态发生改变时,所有依赖于它的对象都得到通知并被自动更新。 动机:需要维护相关对象间的一致性。且不希望为了维持一致性而使各类紧密耦合,这样会降低它们的可重用性。
  • 175. Observer案例
  • 176. Observer案例
  • 177. Observer原理
  • 178. Observer原理
  • 179. Observer参与者Subject(目标): 目标知道它的观察者。可以有任意多个观察者观察同一个目标。 提供注册和删除观察者对象的接口。 Observer(观察者) 为那些在目标发生改变时需获得通知的对象定义一个更新接口。 ConcreteSubject(具体目标) 将有关状态存入各ConcreteObserver对象。 当它的状态发生改变时,向它的各个观察者发出通知。 ConcreteObserver(具体观察者) 维护一个指向ConcreteSubject对象的引用。 存储有关状态,这些状态应与目标的状态保持一致。 实现Observer的更新接口以使自身状态与目标状态保持一致。
  • 180. Observer协作过程: 当ConcreteSubject发生任何可能导致其观察者与其本身状态不一致的改变时,它将通知它的各个观察者。 在得到一个具体目标的改变通知时,ConcreteObserver对象可向目标对象查询信息, ConcreteObserver使用这些信息以使它的状态与目标对象的状态一致。
  • 181. Observer –观察者模式序列图
  • 182. MVCModel 模型 View 视图 Controller 控制器
  • 183. MVC模式原理图-MVC模式的UML类图
  • 184. MVC模式原理图-MVC模式的UML序列图
  • 185. MVC关系图
  • 186. 对MVC关系图的理解
  • 187. Iterator(迭代器)意图: 提供一种方法顺序访问一个聚合对象中的各个元素,而又不需暴露该对象的内部表示。 动机: 一个聚合对象(如list),应提供一种方法让别人可以访问其中的元素,又不需暴露其内部结构。针对不同的需要,可以不同的方式遍历这个列表。
  • 188. Iterator(迭代器)关键思想: 将对列表的访问和遍历从列表对象中分离出来并放入一个迭代器(iterator)对象中。由迭代器定义一个访问该列表元素的接口。迭代器负责跟踪当前的元素,即:它知道哪些元素被遍历过了。
  • 189. Iterator(迭代器)案例不使用迭代器: for(int i=0; i
  • 190. Iterator(迭代器)案例迭代器接口定义: public interface Iterator {  boolean hasNext();  Object next();  void remove(); } 使用迭代器完成遍历: for(Iterator it = c.iterator(); it.hasNext(); ) {  Object o = it.next();  // 对o的操作... }
  • 191. Iterator(迭代器)案例
  • 192. Iterator(迭代器)原理
  • 193. Iterator(迭代器)参与者Iterator(迭代器) 迭代器定义访问和遍历元素的接口; ConcreteIterator(具体迭代器) 具体层迭代器实现迭代器接口; 对该聚合遍历时跟踪当前位置; Aggregate(聚合) 定义创建相应迭代器对象的接口。 ConcreteAggregate(具体聚合) 实现创建相应迭代器的接口,该操作返回ConcreteIterator的一个适当实例。
  • 194. Iterator(迭代器)协作过程: ConcreteIterator跟踪ConcreteAggregate聚合对象中的当前对象,并能够计算出待遍历的后继对象。 效果: 支持以不同的方式遍历一个聚合对象;也可以自己定义迭代器的子类以支持新的遍历。 迭代器简化了聚合的接口; 在同一个聚合对象上可以有多个遍历,即可以同时进行多个遍历。
  • 195. 配置管理第七章
  • 196. 本章要点为什么做配置管理 什么是软件配置管理 配置管理中的关键概念 SCM工具的功能 检入检出
  • 197. 为什么做配置管理开发环境的复杂性 软件开发过程中的很多困境
  • 198. OracleSybaseAPPCMVSWINDOWSSQLOS/2TCP/IPUNIXOOPMDB2NTC++INTERNETINTRANET开发环境的复杂性
  • 199. 软件开发过程中面临的困境需求管理 程序和文档维护 代码可重用性 人员流动 构建管理需要配置管理
  • 200. 什么是软件配置管理一般定义 软件配置管理就是管理变更的过程 变更是指软件开发活动中的文档、源码和数据的更改。 标准定义 IEEE标准729-1983 软件配置管理(Software Configuration Management,简称SCM)是一门应用技术管理和监督相结合的学科,通过表示和文档标记配置项的功能和物理特性,控制这些特性的变更,记录和报告变更的状态和过程,并验证它们与需求是否一致。
  • 201. 配置管理的标准定义标识 控制 状态统计 审计和审查 生产 过程管理 小组协作
  • 202. SCM贯穿软件工程整个生命期可行性分析需求分析概要设计详细设计编码测试部署维护软件团队Time
  • 203. 软件配置软件配置定义 配置项(CI, Configuration Item) 配置管理是标识和控制配置项。
  • 204. 配置管理常规内容标识和版本控制 变更控制 状态报告 配置审核
  • 205. 配置管理逻辑记录配置项的五个方面: 谁创建的? 从哪里来? 什么时间创建的? 为什么创建此配置项? 当前在哪里? 将到哪里去?
  • 206. 配置项粒度文件内容级 文件级 文件夹级 其他
  • 207. SCM工具核心功能版本控制 变更控制 配置控制 状态统计 配置审计
  • 208. 版本控制定义 版本控制是配置管理的基本要求,它可以保证在任何时刻恢复任何一个配置项的任何一个版本。 版本控制主要是对变更配置项的软件行为及变更结果提供一个可跟踪的手段,便于软件开发工作以基线渐进的方式完成。 版本 配置标识 软件组成单元
  • 209. 变更控制 定义 变更管理主要是控制和协调不同责任的软件开发人员有效的交流。软件过程中某一阶段的变更,均要引起软件配置的变更,这种变更必须严格加以控制和管理,保持修改信息,并把精确、清晰的信息传递到软件工程过程的下一步。 变更请求(Change Request,简称CR) 变更的起源 对变更进行控制的机构
  • 210. 变更控制规范所有的变更处理都要经过统一规范的处理,程序员不能直接处理用户的请求、修改缺陷而没有任何记录的情况。 变更审核:由变更控制负责人审核变更内容是否合理。 变更完毕提交变更报告,报告包括变更的内容、过程、通报情况等; 对于用户不合理的变更需求或有危险的变更需求予以排除,并写出原因。 对于工程现场的变更,可先变更后补办变更手续,但必须是在项目负责人同意之后才能变更。 变更之后,通知与之相关的部门和人员,与之相关的配置项也应做相应的修改。
  • 211. 变更机制产生CR修改配置项测试建立基线发布新版本或补丁关闭CRCCB评估接受提交拒绝没有通过测试
  • 212. 配置控制定义 主要是以用户和开发团队均认可的衡量尺度(如:与用户签定的软件合同),通过正式配置审核和软件配置审核两种方式,对软件实施过程和软件功能的完整性、正确性审核。 正式技术复审主要是进行配置项的功能性审核,复审者评估SCI(软件配置项)以确定它与其他SCI的一致性、遗漏、及潜在的副作用,正式复审应该对所有变化进行。软件配置审核通常是在软件开发生命周期上每个阶段的末尾开始。 构建管理 里程碑 配置项基线
  • 213. 软件配置审核的内容 审核产品功能是否能满足用户要求。 审核产品功能是否与需求文档一致。 审核发布出去的产品是否有帮助文档,文档内容是否与应用程序一致。 审核发布产品的功能是否与用户签定的合同一致。
  • 214. 基线基线(BaseLine)是已经通过复审和批准的某规约或产品,可以作为进一步开发的基础,并且只能通过正式的变化控制过程的改变。 基线是软件生命周期中各开发阶段的一个特定点(也称里程碑),它的作用是把开发各阶段工作的划分更明确化,使本来连续的工作在这些点上断开,以便于检查与肯定阶段成果。 基线可以作为一个检查点,在开发过程中,当采用的基线发生错误时,可以知道其所在的位置,返回到最近和最恰当的基线上。
  • 215. 基线的定义c.javab.javaa.java正式版Beta 11.01.11.21.31.01.11.21.01.11.21.31.4
  • 216. 状态报告Configuration status reporting,简称CSR 发生了什么? 为什么要发生? 谁做的? 什么时候发生的? 在哪儿改变的? 将影响别的什么吗? 每次当配置审计进行时,其结果作为CSR任务的一部分被报告。
  • 217. 配置审计配置是否符合规范 配置项是否记录正确 变更控制记录的完整性 SQA(软件质量保证)
  • 218. 检入检出(CICO)Check In: 配置管理者从程序开发人员的工作空间(目录)中拷贝配制项到项目空间(目录)中。 Check Out: 配置管理者从配置库中检出(Check Out)相应的配置项,拷贝到程序开发人员的工作空间中。
  • 219. CICO模型v1v2v3v4v2.1v1v2a.javab.javaa.javab.javawkcp1wkcp1程序员1的Working CopyCM 数据库a.javab.javawkcp2wkcp2程序员2的Working CopyCheck OutCheck InCheck OutCheck In
  • 220. 配置管理工具第八章
  • 221. 本章要点基础知识 WinCVS登陆 WinCVS操作 WinCVS高级版本控制技术
  • 222. 软件配置管理的工具支持 开源工具CVS 购置配置管理工具进行软件配置管理,如基于团队开发的配置管理工具,提供以过程为基础的包含版本管理,过程控制等功能; 利用Visual Studio6.0中所提供的VSS6.0(Visual SourceSafe)工具进行软件配置管理。 另外还有butter fly,Rational Clear Case等配制管理工具。
  • 223. CVSConcurrent Versions System GNU协议 C/S CVSNT
  • 224. WinCVSCVS客户端工具 图形化 CheckOut和CheckIn 开发人员可以配置项的旧版本、查看更改日志等操作
  • 225. CVS的使用CVSNT 服务器 中的项目空间用WinCVS等 客户端工具
  • 226. CVS术语CVSROOT: 配置库 Repository: 项目空间 WorkSpace:工作空间 SourceSpace:资源空间 Version: 版本 Branch: 版本分支 Tag:标签 Update:更新 Commit:提交
  • 227. 配置CVSNT指定临时工作目录 创建CVSRoot 创建Repository
  • 228. WinCVS登陆配置登陆选项 login到特定的Repository 选择工作空间 logout
  • 229. WinCVS操作Import Module Checkout Module Update Selection View Selection Graph Selection Commit Selection
  • 230. Import Module目的是资源空间拷贝一个Module到项目空间里面去 Create->Import Module 选择本地目录
  • 231. Checkout module目的是从项目空间中选择一个Module检出到工作空间中,以备后续修改 Create->Checkout module Checkout settings
  • 232. Update selection目的是将工作空间和项目空间中的配置项同步起来 Update selection 原因 Modify->Update selection Update settings
  • 233. View Selection目的是查看或修改工作空间中的配置项 选择文件,点击鼠标右键,选择菜单 View Selection 修改文件 保存文件
  • 234. Graph Selection目的是查看配置项的版本树 Ctrl+G选择 Log settings
  • 235. Commit selection目的是将配置项从工作空间检入到项目空间中 鼠标右键点击配置项,选择“Commit Selection” Commit settings
  • 236. WinCVS高级版本控制技术标签的使用 标签是给配置项贴的文字标记 不同的配置项可以贴相同的标签 版本分支 版本分支是让配置项的版本树分叉的动作 版本分支的目的是让配置项沿着不同的方向进化
  • 237. 标签创建标签 删除标签 按标签检出
  • 238. 版本分支创建分支 按分支检出 分支上的新版本
  • 239. 软件测试第九章
  • 240. 本章要点软件测试概述 软件测试分类 几种单元测试方法 组织软件测试 软件测试文档
  • 241. 软件测试的定义软件测试定义(1983,IEEE): “使用人工或自动手段来进行或测定某个系统的过程,其目的在于检验它是否满足规定的需求或是弄清预期结果与实际结果之间的差别。软件测试以检验是否满足需求为目标”。 软件质量保证和软件测试不同
  • 242. 测试的目的寻找缺陷。 发现新的缺陷。 不能保证没有缺陷。
  • 243. 软件测试的原则追溯根源 计划在先 从小到大 不能穷举
  • 244. 正确认识软件测试软件测试不是程序测试 测试心态 测试的分量
  • 245. 软件缺陷的来源编程错误 软件复杂度 沟通 不断变更的需求 时间的压力 人员风险意识 缺乏文档 软件开发工具
  • 246. 总体分类静态测试 代码审查 代码分析 文档检查 动态测试 结构测试(白盒) 功能测试(黑盒)
  • 247. 单元测试 集成测试 系统测试 用户测试工程分类
  • 248. 单元测试模块出错处理模块接口局部数据结构边界条件执行路径通过接口的调用参数 数据定义、 使用 循环边界 输入边界重要路径 关键路径 非合理输入 系统异常 是一种白盒测试
  • 249. 集成测试全局数据结构是否正确 通过模块接口的数据是否正确 模块间的耦合影响性能了吗有些软件公司,在单元测试 和系统测试中分别完成了 集成测试的目的
  • 250. 系统测试◆ 有效性测试在模拟的环境下,运用黑盒测试的方法,验证所测软件是否满足需求规格说明书列出的要求◆ 软件设计复查保证软件配置的所有成分都齐全,各方面的质量都符合要求,具有维护阶段所必需的细节,而且已经编排好分类的目录也叫功能测试 是一种黑盒测试
  • 251. ◆ 测试 测试人员模拟最终用户测试◆ 测试 最终用户的实际测试用户测试
  • 252. 几种单元测试方法 边界值分析 语句覆盖 判定覆盖 条件覆盖 判定-条件覆盖 路径覆盖
  • 253. 测试活动的生命周期
  • 254. 软件测试小组测试组测试经理测试工程师测试工程师测试工程师任务1任务2任务n
  • 255. 测试文档测试计划 测试用例
  • 256. 软件测试工具第十章
  • 257. 内容简介JUnit 背景 用TestCase测试一个类 TestRunner TestCase原理 用TestSuite一次测试多各类 TestSuite原理
  • 258. JUnit是什么?开源的 单元测试框架 xUnit JUnit 的特点 www.JUnit.org
  • 259. JUnit与XPExtreme Programming 测试驱动开发 单元测试用例 JUnit与XP Kent Beck和Erich Gamma
  • 260. 用TestCase测试一个类新建JBuilder9 项目 给项目添加一个新类 全手工写的测试代码 创建测试用例 执行测试用例
  • 261. 新建JBuilder 项目点击菜单File->New Project Step1:设立项目名称 Step2:点击Next到下一步 Step3:点击Next到下一步 项目建好
  • 262. 给项目添加一个新类Ctrl+N->General Tab->Class 填写类名称 类的原型生成 给类添加方法 类创建完毕
  • 263. 创建测试用例 Ctrl+N->Test Tab->TestClass Step1:选择方法 Step2:测试用例类名称 Step3:点击Next Step4:设置SwingUI 测试案例类原型生成
  • 264. 执行测试用例执行测试用例类TestCompute 测试结果没发现错误 更改testAdd方法在执行一次 发现了断言失败
  • 265. TestRunnerText 版 Awt 版 Swing 版
  • 266. TestCase 原理TestCase类继承结构 TestCase生命周期 断言
  • 267. 用TestSuite一次测试多各类再给项目添加一个新类 给新类创建测试用例类 创建测试套件类 执行测试套间类
  • 268. TestSuite原理静态suite方法 addTestSuite方法 addTest(Test)方法 run(TestResult)方法
  • 269. run(TestResult) addTest()TestSuiterun(TestResult)TesttestComputeSum()TestSumrun(TestResult) runTest() setup() tearDown()fNameTestCasetestAddTestComputefTestsTestResultJUnit基本框架