软件架构设计教程.ppt

软件工程导论第一章本章要点工程的概念软件工程的发展软件工程分析三种过程模型工程化思考工程是什么？工程简而言之就是多人参与并有计划、有步骤地完成一项任务的活动工程强调目的计划步骤软件发展与软件工程起源软件的发展四个阶段：1950年前后到1960年前后，程序设计阶段；1960年前后到1970年前后，软件系统阶段；1970年前后到1980年前后互联网络兴起，软件工程阶段；1980年前后到现在，分布式软件工程阶段；1968年，北大西洋公约组织的计算机科学家召开国际会议，第一次提出软件危机的概念，产生了应对软件危机的对策-软件工程。软件工程与建筑工程的对比预算画设计图施工质检可行性分析需求分析详细设计、概要设计编码测试兴建一座高楼兴建一座高楼创造一部软件产品创造一部软件产品销售、入住使用销售、安装使用工程策略任何工程都有如下的策略：分而治之复用折衷优化检验并保证质量软件工程也会充分利用这些策略分而治之把复杂的问题分解为小的问题并一一解决分而治之图示复杂问题子问题1子问题2子问题3子程序1子程序2子程序3分分 解解程序复用利用现有的组件来构筑软件的一部分功能组件技术有：CORBA、EJB、COM软件复用图示：分解系统组件开发创建新组件提取组件从组件库中查找可用组件用组件编制软件组件库组件定义软件开发的发展与变化软件技术的发展带来了一些变化：1用户对软件要求的变化：软件规模在扩大；对软件的质量要求在提高；2软件技术本身的变化：新的理念、新的方法和新的工具3软件开发队伍的变化：从单人开发、小组开发，到大规模团队开发；从稳定、相对稳定到全员流动软件开发的发展与变化应对这些变化的是：1市场化：软件开发由个人爱好行为转变为企业行为，需要大量的投资、大量的人力，并且要按照市场规律来运作2知本化：要求技术的积累、模块的积累和成果的积累；3开发过程的规范化：来应对需求多变，人员流动4标准化：能力成熟度，质量控制软件工程的目标软件工程的目标是提高软件的质量与生产率，最终实现合格的软件。质量是软件需求方最关心的问题。生产率是软件供应方最关心的问题。软件工程的四项基本原则软件工程的四项基本原则选取适宜开发范型采用合适的设计方法提供高质量的工程支持重视开发过程的管理 软件工程准则七条基本准则1)生命周期计划；2)阶段评审；3)变更控制；4)改进程序设计技术；5)控制人员规模；6)定义评审；7)不断改进软件工程；软件工程的要素软件工程的要素1.1.方法方法：软件工程方法为软件开发提供了“如何做”的技术，是完成软件工程项目的技术手段；2.2.工具工具：软件工具是在开发软件的活动中智力和体力的扩展和延伸，为软件工程方法提供了自动的或半自动的软件支撑环境；3.3.过程过程：软件工程的过程则是将软件工程的方法和工具综合起来以达到合理、及时地进行计算机软件开发的目的。软件工程的组成人员管理项目管理过程管理瀑布模型瀑布模型将软件生命周期的各项活动顺序进行，形如瀑布流水，最终得到软件产品是最早的软件工程模型，是其他所有现代模型的基础可行性分析可行性分析需求分析需求分析概要设计概要设计详细设计详细设计编码编码测试测试部署部署维护维护软件团队软件团队Time瀑布模型continue阶段任务、结果及人员阶段基本任务工作结果参加者计划期可行性研究与计划研究开发该项目的可行性可行性研究报告用户、高级程序员开发期需求分析理解和表达用户的要求需求说明书用户、高级程序员设计建立系统的结构模块、数据说明书用户、高级程序员编程编写程序程序高级程序员、初级程序员测试发现错误和排除错误测试报告另一独立的部门运行期运行与维护维护改进的系统用户、高级程序员瀑布模型特征从上一项活动接收该项活动的工作对象，作为输入;利用这一输入实施该项活动应完成的内容;给出该项活动的工作成果，作为输出传给下一项活动；对该项活动实施的工作进行评审，若其工作得到确认，则继续下一项活动，否则返回前项，甚至更前项的活动进行返工。瀑布模型各个阶段概述可行性分析：做还是不做需求分析：都有什么功能概要设计：供有多少子功能详细设计：子功能怎么实现编码：子功能实现了吗测试：功能完备吗部署：需要多少设备和软件的支持维护：软件运行的正常吗可行性分析可行性分析因素经济技术社会环境人才需求分析概要设计提供多少子功能面向对象分析（OOA）详细设计子功能如何实现面向对象设计（OOD）编码子功能是否实现？程序员严格按照规范编码；测试单元测试系统测试用户测试部署部署要求增强自动化程度，用ant等工具培训最终用户要有详细计划记录详细的过程数据及时反馈软件兼容性缺陷维护一般维护分三类：纠错性维护改正软件漏洞、发布补丁程序适应性维护使得软件在新的硬件、操作系统、编译器和解释器下运行完善性维护增加新功能、更改原有的设计等影响维护成本的因素非技术因素需求的复杂性开发人员的岗位稳定性软件的生命期外部环境的变化，例如财政政策影响财务软件技术因素软件运行环境编程语言编程风格测试工作的有效性文档的质量瀑布模型的优点通过设置里程碑，明确每阶段的任务与目标可为每阶段制定开发计划，进行成本预算，组织开发力量通过阶段评审，将开发过程纳入正确轨道严格的计划性保证软件产品的按时交付瀑布模型的缺点缺乏灵活性，不能适应用户需求的改变开始阶段的小错误被逐级放大，可能导致软件产品报废返回上一级的开发需要十分高昂的代价随着软件规模和复杂性的增加，软件产品成功的机率大幅下降演化模型可行性分析可行性分析需求分析需求分析概要设计概要设计详细设计详细设计编码编码测试测试部署部署维护维护软件团队软件团队Time可行性分析可行性分析需求分析需求分析概要设计概要设计详细设计详细设计编码编码测试测试部署部署维护维护软件团队软件团队可行性分析可行性分析需求分析需求分析概要设计概要设计详细设计详细设计编码编码测试测试部署部署维护维护软件团队软件团队版本版本1版本版本2版本版本3迭代模型可行性分析可行性分析需求分析需求分析v1概要设计概要设计v1详细设计详细设计v1编码编码v1测试测试v1部署部署维护维护软件团队软件团队概要设计概要设计v2详细设计详细设计v2 详细设计详细设计v3编码编码v2测试测试v2需求分析需求分析v2Time迭代模型continue迭代模型continue迭代的定义：迭代包括产生产品发布（稳定、可执行的产品版本）的全部开发活动和要使用该发布必需的所有其他外围元素。生命周期是基于对一个系统进行连续的扩充和精化，需要经历若干个开发周期，每个周期都需要经历分析、设计、实现和测试阶段。每个开发周期只针对比较小的一部分需求在某种程度上，开发迭代是一次完整地经过所有工作流程的过程：（至少包括）需求工作流程、分析设计工作流程、实施工作流程和测试工作流程;类似小型的瀑布式项目。RUP认为，所有的阶段（需求及其它）都可以细分为迭代。每一次的迭代都会产生一个可以发布的产品，这个产品是最终产品的一个子集。迭代的优点降低了在一个增量上的开支风险。如果开发人员重复某个迭代，那么损失只是这一个开发有误的迭代的花费。降低了产品无法按照既定进度进入市场的风险。通过在开发早期就确定风险，可以尽早来解决而不至于在开发后期匆匆忙忙。加快了整个开发工作的进度。因为开发人员清楚问题的焦点所在，他们的工作会更有效率。由于用户的需求并不能在一开始就作出完全的界定，它们通常是在后续阶段中不断细化的。因此，迭代过程这种模式使适应需求的变化会更容易些。迭代模型和瀑布模型的差别最大的差别在于风险的暴露时间上。任何项目都会涉及到一定的风险。如果能在生命周期中尽早确保避免了风险，那么计划自然会更趋精确。有许多风险直到已准备集成系统时才被发现。不管开发团队经验如何，都绝不可能预知所有的风险。迭代模型和瀑布模型的差别统一软件过程RUP模型RUP中的软件生命周期初始阶段(Inception)：目标是为系统建立商业案例并确定项目的边界。细化阶段(Elaboration)：目标是分析问题领域，建立健全的体系结构基础，编制项目计划，淘汰项目中最高风险的元素。构造阶段(Construction)：所有剩余的构件和应用程序功能被开发并集成为产品，所有的功能被详细测试。交付阶段(Transition)：重点是确保软件对最终用户是可用的。每个阶段结束于一个主要的里程碑(Major Milestones)；每个阶段本质上是两个里程碑之间的时间跨度。在每个阶段的结尾执行一次评估以确定这个阶段的目标是否已经满足。如果评估结果令人满意的话，可以允许项目进入下一个阶段。RUP模型的优缺点优点提高了团队生产力，在迭代的开发过程、需求管理、基于组件的体系结构、可视化软件建模、验证软件质量及控制软件变更等方面，针对所有关键的开发活动为每个开发成员提供了必要的准则、模板和工具指导，并确保全体成员共享相同的知识基础。建立了简洁和清晰的过程结构，为开发过程提供较大的通用性。缺点RUP只是一个开发过程，并没有涵盖软件过程的全部内容，例如它缺少关于软件运行和支持等方面的内容；没有支持多项目的开发结构，这在一定程度上降低了在开发组织内大范围实现重用的可能性。软件项目管理第二章本章要点项目管理一般原理Project2002中的项目管理概念用Project2002做项目计划关键路径、关键任务计算法则成功的软件项目有多少？16%53%31%成功成功实现实现失控失控取消取消为什么失败？项目失败的前项目失败的前5个原因个原因0%5%10%15%需求分析不完整需求分析不完整需求分析不完整需求分析不完整缺少用户参与缺少用户参与缺少用户参与缺少用户参与缺少资源缺少资源缺少资源缺少资源不现实的期望不现实的期望不现实的期望不现实的期望缺乏系统支持缺乏系统支持缺乏系统支持缺乏系统支持缺少项目管理缺少项目管理项目管理项目管理的定义项目管理分三个阶段：制定项目计划管理和跟踪项目结束项目项目管理三角形时间时间费用费用范围范围项目轮廓定义目标目标前提前提限制限制范围范围项目计划要素任务任务相关性工期成本资源资源任务相关性任务相关性任务相关性：两个链接任务之间的关系；通过完成日期和开始日期之间的相关性进行链接。有四种任务相关性类型：“完成-开始”(FS)、“开始-开始”(SS)、“完成-完成”(FF)、“开始-完成”(SF)。当关键任务完成或另一系列中的任务发生延迟时，关键路径就会更改。任务相关性任务相关性任务相关性描述例子完成-开始（FS）只有在任务 A 完成后任务 B 才能开始。地基要先建好才能盖房子 开始-开始（SS）只有在任务 A 开始后任务 B 才能开始。所有的人员都到齐后会议才能开始 完成-完成（FF）只有在任务 A 完成后任务 B 才能完成。所有的资料全部准备齐全后才能结案 开始-完成（SF）只有在任务 A 开始后任务 B 才能完成。站岗时，下一个站岗的人来了，原本站岗的人才能回去 工作分解结构项目摘要任务1摘要任务2任务3任务1.1任务1.2摘要任务2.1任务2.1.1任务2.1.2任务关系树型图任务关系树型图WBS代码列Project中创建项目计划文档新建项目文档定义常规工作时间添加分层任务读取来自Excel的资料添加资源给任务配备资源任务相关操作创建里程碑(0天)创建周期性任务创建和删除任务链接创建任务相关性设置任务限制工时计算公式工时=工期单位（资源工作分配单位）工期是完成任务所经历的实际时间工时是资源执行任务的工作时间单位是资源的分配量全职工作人员的单位一般是100%兼职工作人员的单位一般是50%详细甘特图关键路径是贯穿整个项目的一条路径，表明在限定的时间成功完成项目涉及的各任务间的依赖关系。调整关键路径上任务的时间进度将会影响整个项目的交付时间。关键路径方法（CRM）图是一种网络图，用于项目的进度控制和协调项目的活动和事件。最早/晚完成日期最早完成日期：根据前置任务和后续任务的最早完成日期、其他限制以及任何调配延迟，任务可能完成的最早日期。即任务在开始日期和预计工期的基础上能够最早完成的日期。最晚完成日期：在不延迟项目完成时间的情况下，任务可以完成的最晚日期。该日期基于任务最晚开始日期、前置任务和后续任务的最晚开始和完成日期及其他限制。即任务在不延迟项目完成时间的情况下能够最晚完成的日期。关键任务/时差关键任务是指一旦延迟就会影响项目完成日期的任务。时差：在不影响其他任务或项目完成日期的情况下，任务可以落后的时间量。可用时差是在不延迟其他任务的情况下，任务可以落后的时间量。总时差是在不延迟项目的情况下，任务可以落后的总时差。在典型的项目中，很多任务都有时差，因此即使延迟一小段时间也不会影响其他任务或项目完成日期。关键任务/时差continue当一项任务满足以下任何一个条件时，该任务即成为关键任务：该任务没有时差。该任务有“必须开始于”(MSO)或“必须完成于”(MFO)的日期限制（限制：对任务的开始日期或完成日期设置的限制。可以指定任务在特定日期开始，或者不晚于特定日期完成。限制可以是弹性的（未指定特定日期），也可以是非弹性的（指定了特定日期）。在一个从开始日期排定的项目中，该任务有“越晚越好”(ALAP)的限制。在一个从完成日期排定的项目中，该任务有“越早越好”(ASAP)的限制。该任务的完成日期等同于或超出期限（期限：表明希望完成任务的目标日期。如果期限日期已过而任务仍未完成，Project 就会显示一个标记。）日期。当一项任务标记为已完成时，就不再是关键任务，因为它不再影响后续任务的完成或项目完成日期。关键路径显示项目的内容关键路径显示项目的内容通过了解和跟踪项目的关键路径和分配给关键任务的资源，就可以确定哪些任务会影响项目的完成日期以及项目能否按时完成。任务节点表示任务节点任务链接最早开始时间持续时间持续时间最早结束时间任务标识号任务标识号时差时差最晚开始时间最晚结束时间=最早结束时间-最早开始时间=最晚结束时间-最晚开始时间=最晚结束时间-最早结束时间=最晚开始时间-最早开始时间工期549421263097167113037网络初始状态123569478计算工期5182123105206594477108因为举例子，所以直接填写工期因为举例子，所以直接填写工期计算最早开始时间和最早结束时间055158132512173131023517203763754295494971672310338计算最晚开始时间和最晚结束时间05510558132917512173517131023517271720376173737542937425494263097167303723103382737计算时差完成这些任务最多用42单位工期关键路径为13690551005581324917131023541727512173051754942126309716711303723103384273717203760173737542903742关键任务实例(1)此任务序列没有时差，因而会推动项目的完成日期尽早到来。此序列中的所有任务都在关键路径上，称为关键任务。在“详细甘特图”视图中，关键任务显示为红色。(2)此任务序列不会推动项目的完成日期尽早到来，因此不是关键任务。在“详细甘特图”视图中，非关键任务显示为蓝色。(3)总时差是指此任务序列在不影响项目的完成日期的条件下可跳过的时间量。在“详细甘特图”视图中，总时差显示为浅蓝绿色线。如果项目必须如期完成，应该密切关注关键路径上的任务以及为其分配的资源。这些要素将决定项目能否按时完成。如何缩短关键路径如何缩短关键路径冲击：在不更改任务关系的情况下缩短项目的总体工期。对项目进行冲击通常需要为任务分配额外的资源。缩短关键路径上任务的工期或工时。更改任务限制，以增加日程排定的灵活性。将关键任务分解成多个由不同资源同时进行的小任务。更改任务相关性，以增加日程排定的灵活性。在适用的相关任务间设置前置重叠时间。排定加班工时。为关键路径上的任务分配额外资源。MSF介绍第三章本章要点MSF内容组队模型过程管理模型应用程序模型什么是MSFMSF(MicrosoftSolutionFramework)是指微软解决方案框架。MSF描述了微软公司从众多大小软件产品研发实践中总结的管理软件开发过程管理软件开发过程的经验程序员眼中的MSF三个核心组队模型过程管理模型应用程序模型三种模型的关系组队模型组队模型应用程序模型应用程序模型过程管理过程管理资源配置资源配置功能划分功能划分过程模型过程模型组队原则清晰的责任，共同的职责赋予小组成员权力聚焦业务价值共同的项目设想保持灵活，预测变化推动开放式沟通关键概念同级小组以客户为中心产品理念体系零缺陷乐意学习有动力的小组有效率成功的做法小型的多学科小组一起工作全员参与设计组队模型开发开发开发开发程序管理程序管理程序管理程序管理产品经理产品经理产品经理产品经理用户体验用户体验用户体验用户体验发布经理发布经理发布经理发布经理测试测试测试测试交流！交流！角色与目标目标目标满足客户提高用户效率 根据规格说明创建解决方案 确保产品质量事宜被识别并处理 交付满足项目约束的解决方案 进行平滑的部署及日常运行 产品经理用户体验开发测试程序管理发布经理组队角色组队角色可合并角色表产品管理程序管理开发测试用户体验发布经理产品管理NNPPU程序管理NNUUP开发NNNNN测试PUNPP用户体验PUNPU发布经理UPNPU案例1：角色合并了的小团队开发开发开发开发程序管理程序管理程序管理程序管理发布经理发布经理发布经理发布经理测试测试测试测试产品管理产品管理产品管理产品管理用户体验用户体验用户体验用户体验案例2：大项目的功能团队领导领导领导领导团队团队团队团队开发开发开发开发经理经理经理经理测试测试测试测试经理经理经理经理团队团队团队团队程序程序程序程序经理经理经理经理产品产品产品产品管理管理管理管理用户用户用户用户体验体验体验体验发布经理发布经理发布经理发布经理经理经理经理经理客服客服客服客服团队团队团队团队开发开发开发开发测试测试测试测试程序程序程序程序经理经理经理经理预定预定预定预定团队团队团队团队开发开发开发开发测试测试测试测试程序程序程序程序经理经理经理经理计费计费计费计费团队团队团队团队开发开发开发开发测试测试测试测试程序程序程序程序管理管理管理管理专注的资源专注的资源案例3：一个微软的开发小组示例一个项目经理两个软件工程师两个软件测试工程师案例4：微软的项目产品组行政结构图产品单元经理团队程序经理程序经理组长程序经理软件开发经理软件开发组长软件开发人员测试经理测试组长测试人员过程模型构想构想阶段阶段设计设计阶段阶段开发开发阶段阶段稳定稳定阶段阶段组建项目团队组建项目团队前景前景/范围认可范围认可 项目设计认可项目设计认可 范围完成范围完成/第一次使用第一次使用 系统发布系统发布 构想阶段定义初步的商业需求（持续性工作）风险管理定义项目结构研究和收集设想进行初步的用户访问定义使用场合确立设计目标制定初步的解决方案概念制定初步的项目范围定义关键的成功因素定义衡量成功的标准定义主要的可交付结果（初步）确定构想/范围设计阶段创建功能描述开发计划测试计划用户培训计划后勤计划产品管理计划程序管理计划合并项目计划开发阶段迭代开发一到多次的内部发布版开发目标组件测试单个组件测试组装为整体的应用程序功能说明冻结最后的特性开发最后的后勤开发最后的性能支持开发稳定阶段发布一到多个测试版，包括 测试版和测试版收集错误改正高优先级的错误，发布无错误版进行最后的错误分类黄金发布版应用程序模型应用程序应用程序1应用程序应用程序2用户界面服务用户界面服务商业逻辑服务商业逻辑服务数据存取服务数据存取服务UML：系统结构第四章本章要点OOAD与UML用例图类图与类关系组件图、包和部署图分析、设计、编程面向对象分析面向对象分析(OOA)面向对象设计面向对象设计(OOD)面向对象编程面向对象编程(OOP)UML诞生面向对象分析和设计的结果需要统一符号来描述并记录。统一建模语言UML（UnifiedModelingLanguage）UML发展1996199619971997 2000 200020012001系统需求（学生注册）管理员按照学校计划预先设置课程学生可以通过该系统选择课程。学生选好课程以后财务系统可以发费用清单给学生。学生可以增删选择的课程。教授可以获得自己课程的名单。所有角色都必须经过登陆。用例图图元（角色）角色有两种符号表示。角色名称角色名称用例图图元（用例）用例实线椭圆表示用例，用例名称写在椭圆下面。用例名称用例名称用例图图元（系统边界）系统边界，系统边界可以省略系统名称箭头表示参与用例图学生登陆员教授维护选课计划维护课程表请求花名册财务系统学生注册系统用例之间的关系注册课程登陆验证维护课程表帐号密码验证登陆验证指纹验证数字签名验证发现类分两步先发现候选类然后净化候选类净化原则：摒弃冗余通过继承合并重组类提取接口或者抽象类重组类通过拆分类，保证类对应的概念清晰发现候选类应用专家需求说明原有系统同类系统候选类用例和角色类图RegistrationFormRegistrationManageraddStudent(Course,StudentInfo)CoursenamenumberCreditsStudentnamemajorCourseOfferinglocationopen()addStudent(StudentInfo)ProfessornametenureStatusScheduleAlgorithm类图类图由水平线分割为三个部分类名称属性方法Student-name:String-major:int+register(Lesson):void+showReg():void+表示public-表示private#表示protected关联关联分单向或双向RegistrationFormRegistrationManager10.*manageEmployee单向关联双向关联这也是关联中的特殊的一种，递归关联聚合StudentCourseOfferingProfessornamenumberCreditsmajorlocationopen()addStudent(StudentInfo)tenureStatusCourse继承学生和教授用学生注册管理系统的第一步要登陆。所以他们都有登录用户的含义StudentProfessornameRegistrationUser依赖关系RegistrationManagerScheduleAlgorithm依赖关系表达了概念之间的依赖性。比如类R中需要调用类S的算法，因此表现为依赖，表示方法虚箭头线。类关系图RegistrationFormRegistrationManagerCourseStudentCourseOfferingProfessoraddStudent(Course,StudentInfo)namenumberCreditsopen()addStudent(StudentInfo)majorlocationopen()addStudent(StudentInfo)tenureStatusScheduleAlgorithm10.*0.*1抽象类表示StudentProfessornameRegistrationUser接口表示接口名称MyThread+run():voidRunnable组件图CourseCourseOfferingStudentProfessorCourse.dllPeople.dllCourseUserRegister.exeBilling.exeBillingSystem部署图学生注册管理系统数据库图书馆宿舍教学楼UML：系统动态第五章本章要点动态模型序列图协作图状态图活动图UML图分类动态模型动态模型描述系统随时间演化细节描述系统动态的UML图有：交互图序列图协作图演化图状态图活动图交互图序列图描述了对象之间的交互，重点在于描述消息及其时间顺序协作图和序列图一样描述了对象之间的交互，但是重点在于描述消息及其实现交互图的关键消息对象之间的的信息传递就是所谓的消息发送消息就是对象调用另外一个对象的方法时所传递的参数发送者和接收者之间的箭头表示消息消息的类型l简单l同步l异步l计时消息l返回消息序列图元素角色类对象普通对象带有消息编号的先后消息对象的生存期序列图案例序列图组成两个方向的扩展消息穿梭在序列图中一系列对象消息编号绘制序列图相邻摆放生存期要精确顺序和编号系统运行时的微观图协作图元素角色类对象普通对象带有编号的消息传递协作图案例协作图组成对象节点消息链接网络布局消息编号绘制协作图重点描述消息网状的图两个对象之间的多条消息核心对象放在中间编号要准确演化图状态图描述某一对象的生命周期中需要关注的不同状态刺激状态转移的事件和对象采取的动作也要被描述活动图描述用例内部的活动或方法的流程多了对并行活动的描述以外它就是流程图Rose2002中活动图中可以增加对状态的描述演化图5个要素用例范围用例范围动作动作事件事件状态1状态2条件活动活动对象的方法调用事件类型有两种类型事件内部事件为从系统内部激发的事件，一个对象的动作通过事件激活另一个对象动作外部事件为从系统边界外的激发的事件状态和事件状态是某一时间段内对象所保持的稳定态一个对象的状态一般是有限的状态可以想象成对象演化当中的照片事件是来自对象外部的刺激事件是对象演化的动力事件可以想象成电击对象的行为状态图元素对象状态初始状态终结状态事件条件状态图案例状态图的组成初始状态终结状态生存期状态事件动作条件状态图绘制保证一个初始状态可以有多个终结状态状态是对象演化中的离散快照状态要表示对象的关键快照，有重要的实际意义事件和动作要明确活动图元素并行：条件：分支点：开始结束活动事件活动图案例活动图的组成开始活动和结束活动其他活动并行活动分支和循环活动事件条件活动图绘制一个开始活动和一到多个结束活动活动为中心并行活动和串行活动的分离分支逻辑和循环逻辑都可以表示分支和循环条件最好明确表示UML图分类结构动态模型管理设计模式第六章内容简介设计模式背景知识设计模式的种类FactoryMethodAbstractFactoryAdapter（Object）ObserverMVC设计模式背景知识模式的出现软件设计中的模式设计模式的定义模式的出现20世纪70年代Alexander建筑设计模式软件设计中的模式ErichGamma、RichardHelm、RalphJohnson、JohnVlissidesDesignPatternsElementsofReusableSoftwareGOF23设计模式的定义解决重复设计问题反复出现的设计问题的解决方案模式被用来在特定场景下解决一般设计问题的类和相互通信的对象的描述处理同一类软件分析结果的典型设计结构设计模式的种类类范畴创建型结构型行为型对象范畴创建型结构型行为型模式讲解思路模式提出模式案例模式原理分析FactoryMethod案例1FactoryMethod案例2FactoryMethod(工厂方法)对象创建型模式意图：定义一个用于创建对象的接口，让子类决定实例化哪一个类。使一个类的实例化延迟到其子类。别名：虚构造器动机：框架使用抽象类定义和维护定义和维护对象之间的关系，对象的创建由框架负责。但它只知道要创建的对象的抽象父类，而不知道具体哪一种子类将被创建。工厂方法：它将负责“生产”一个对象。本质：用一个virtualmethod完成创建过程。FactoryMethod(工厂方法)适用性：当一个类不知道它所必须创建的对象的类的时候；当一个类希望由它的子类来指定它所创建的具体对象的时候；FactoryMethod原理1FactoryMethod原理2FactoryMethod(工厂方法)参与者AbstractProduct定义工厂方法所创建的对象的接口RealProduct实现AbstractProduct接口ProductFactory声明工厂方法，该方法返回一个AbstractProduct类型的对象。RealProductFactory重定义工厂方法以返回一个RealProduct对象。FactoryMethod(工厂方法)协作过程ProductFactory依赖于它的子类来定义工厂方法，所以它返回一个适当的RealProduct对象。效果工厂方法不再将与特定应用有关的类绑定到代码中。代码仅处理AbstractProduct接口，因此它可以与用户定义的任何RealProduct一起使用。AbstractFactory案例AbstractFactory对象创建型模式意图：提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。别名：Kit动机：客户仅通过NotepadFactory接口创建Notepad的组件monitor/battery/cpu，它们并不知道哪些类创建了这些组件。即：客户仅与抽象类定义的接口交互，而不使用特定的具体类的接口。AbstractFactory适用性：一个系统要独立于它的产品的创建、组合和表示时；一个系统要有多个产品系列中的一个来配置时；当你要强调一系列相关的产品对象的设计以便进行联合使用时；当你要提供一个产品类库，而只想显示它们的接口而不是实现时。AbstractFactory原理AbstractFactory参与者AbstractFactory声明一个创建抽象产品对象的操作接口；RealFactory实现创建具体产品对象的操作；AbstractProduct为一类产品对象声明一个接口；RealProduct定义一个将被相应的具体工厂创建的产品对象；实现AbstractProduct接口；AbstractFactory协作过程通常在运行时刻创建一个RealFactory类的实例，这一具体的factory创建具有特定实现的产品对象。为创建不同的产品对象，客户应使用不同的具体工厂。AbstractFactory将产品对象的创建延迟到它的RealFactory子类。AbstractFactory效果它分离了具体的类；它使得易于交换产品系列；它有利于产品的一致性；难以支持新种类的产品；工厂方法及抽象工厂总结了解每一种模式的实质具体实现的时候可能会有变化情况，或者扩展，或者退化factorymethod是基础，abstractfactory是它的扩展factorymethod、abstractfactory都涉及到类层次结构中对象的创建过程，有所取舍factorymethod需要依附一个creator类abstractfactory需要一个平行的类层次根据应用的其他需求，以及语言提供的便利来决定使用哪种模式Adapter(Object)案例Adapter适配器意图：将一个类的接口转换为客户希望的另外一个接口。Adapter模式使原本由于接口不兼容而不能一起工作的类可以一起工作。动机：为复用而设计的工具箱类不能被复用的原因仅仅因为它的接口与专业应用领域所需要的接口不匹配。Adapter适配器适用性：你希望使用一个已经存在的类，而它的接口不符合你的需求。你想创建一个可以复用的类，该类可以与其他不相关的类或不可预见的类协同工作。Adapter(Object)原理Adapter(Object)参与者Target：定义客户端使用的与特定领域相关的接口。Adaptee：定义一个已经存在的接口，这个接口需要适配Adapter：对Adaptee的接口与Target接口进行适配。Adapter(Object)协作过程：客户端在Adapter实例上调用一些操作，接着适配器调用Adaptee的操作实现这个请求。Adapter(Object)效果（对象适配器）：允许一个Adapter与多个Adaptee即Adaptee本身以及它的所有子类同时工作。使得重定义Adaptee的行为比较困难。需要考虑的问题：Adapter的匹配程度：Adapter的工作量取决于Target接口与Adaptee接口的相似程度。Observer意图：定义对象间的一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并被自动更新。动机：需要维护相关对象间的一致性。且不希望为了维持一致性而使各类紧密耦合，这样会降低它们的可重用性。Observer案例 Observer案例Observer原理Observer原理Subject(目标)：目标知道它的观察者。可以有任意多个观察者观察同一个目标。提供注册和删除观察者对象的接口。Observer（观察者）为那些在目标发生改变时需获得通知的对象定义一个更新接口。ConcreteSubject（具体目标）将有关状态存入各ConcreteObserver对象。当它的状态发生改变时，向它的各个观察者发出通知。ConcreteObserver（具体观察者）维护一个指向ConcreteSubject对象的引用。存储有关状态，这些状态应与目标的状态保持一致。实现Observer的更新接口以使自身状态与目标状态保持一致。Observer协作过程：当ConcreteSubject发生任何可能导致其观察者与其本身状态不一致的改变时，它将通知它的各个观察者。在得到一个具体目标的改变通知时，ConcreteObserver对象可向目标对象查询信息，ConcreteObserver使用这些信息以使它的状态与目标对象的状态一致。Observer观察者模式序列图MVCModel模型View视图Controller控制器MVC模式原理图-MVC模式的UML类图MVC模式原理图-MVC模式的UML序列图MVC关系图对MVC关系图的理解Iterator(迭代器)意图：提供一种方法顺序访问一个聚合对象中的各个元素，而又不需暴露该对象的内部表示。动机：一个聚合对象（如list），应提供一种方法让别人可以访问其中的元素，又不需暴露其内部结构。针对不同的需要，可以不同的方式遍历这个列表。Iterator(迭代器)关键思想：将对列表的访问和遍历从列表对象中分离出来并放入一个迭代器迭代器(iterator)对象中。由迭代器定义一个访问该列表元素的接口。迭代器负责跟踪当前的元素，即：它知道哪些元素被遍历过了。Iterator(迭代器)案例不使用迭代器：for(inti=0;iImportModule选择本地目录Checkoutmodule目的是从项目空间中选择一个Module检出到工作空间中，以备后续修改Create-CheckoutmoduleCheckoutsettingsUpdateselection目的是将工作空间和项目空间中的配置项同步起来Updateselection原因Modify-UpdateselectionUpdatesettingsViewSelection目的是查看或修改工作空间中的配置项选择文件，点击鼠标右键，选择菜单ViewSelection修改文件保存文件GraphSelection目的是查看配置项的版本树Ctrl+G选择LogsettingsCommitselection目的是将配置项从工作空间检入到项目空间中鼠标右键点击配置项，选择“CommitSelection”CommitsettingsWinCVS高级版本控制技术标签的使用标签是给配置项贴的文字标记不同的配置项可以贴相同的标签版本分支版本分支是让配置项的版本树分叉的动作版本分支的目的是让配置项沿着不同的方向进化标签创建标签删除标签按标签检出版本分支创建分支按分支检出分支上的新版本软件测试第九章本章要点软件测试概述软件测试分类几种单元测试方法组织软件测试软件测试文档软件测试的定义n软件测试定义（1983，IEEE）：“使用人工或自动手段来进行或测定某个系统的过程，其目的在于检验它是否满足规定的需求或是弄清预期结果与实际结果之间的差别。软件测试以检验是否满足需求为目标”。n软件质量保证和软件测试不同 测试的目的n寻找缺陷。n发现新的缺陷。n不能保证没有缺陷。软件测试的原则n追溯根源n计划在先n从小到大n不能穷举正确认识软件测试软件测试不是程序测试测试心态测试的分量软件缺陷的来源编程错误软件复杂度沟通不断变更的需求时间的压力人员风险意识缺乏文档软件开发工具总体分