软件工程-课后小节.doc

第一章 本章简要阐述了软件开发的本质，即实现问题空间的概念和处理逻辑到解空间的概念和处理逻辑之间的映射。 在此基础上，概括地介绍了实现这一映射的基本途径，即系统建模。 所谓系统建模，是指运用所掌握的知识，通过抽象，给出该系统的一个结构一系统模型。因此，模型是一个抽象。该抽象是在意图所确定的角度和抽象层次对物理系统的一个描述，描述其中的成分和成分之间所具有的特定语义的关系，还包括对该系统边界的描述。 在软件开发领域，系统模型分为两大类，一类称为概念模型，描述了系统是什么;另一类统称为软件模型，描述了实现概念模型的软件解决方案。软件模型又可进一步分为设计模型、实现模型和部署模型等。 总之，正确认识软件开发的本质，认识建模的意义，了解模型概念以及模型分类，直接关系到对软件工程开发逻辑、开发途径有关知识的理解、掌握和正确应用。正如章首语所言:“正确认识软件开发，是从事软件开发实践和软件工程项目管理的思想基础。”第二章 本章首先介绍了需求的定义，即“一个需求是一个要予构造的陈述，描述了待开发产品(或项)功能上的能力、性能参数或者其他性质”，并指出了需求的5个必备的基本性质:必要的(Necessary)，即该需求是用户所要求的;无歧义的(Unambiguous )，即该需求只能用一种方式解释;可测的(Testable)，即该需求是可进行测试的;可跟踪的(Trace-able)，即该需求可从一个开发阶段跟踪到另一个阶段;可测量的(Measurable )，即该需求是可测量的。需求的5个基本性质可作为需求发现和评估的基础。 其次，为了更好地理解需求，介绍了需求的分类。软件需求可以分为功能、性能、外部接口、设计约束和质量属性，并把性能、外部接口、设计约束和质量属性这4类需求统称为非功能需求。除此之外，还给出了功能需求和非功能需求的基本关系。 然后，介绍了5种常用的需求发现技术:自悟(Introspection )、交谈(Individual in-terview )、观察(Observation )、小组会(Group session)和提炼( Extraction)，并指出采用系统化方法，例如，结构化方法和面向对象方法，可使发现的需求基本满足以上5个性质。 最后，详细地介绍了需求规约(SRS)。其中，不仅给出了需求规约的定义、需求规约的基本性质和需求规约的格式，而且还介绍了表达需求规约的3种风格:非形式化的规约、半形式化的规约和形式化的规约。 需求规约的作用可概括为以下4点:(1)需求规约是软件开发组织和用户之间一份事实上的技术合同书，是产品功能及其环境的体现。(2)对于项目的其余大多数工作，需求规约是一个管理控制点。(3)对于产品/系统的设计，需求规约是一个正式的、受控的起始点。(4)需求规约是创建产品验收测试计划和用户指南的基础。第三章 本章比较详细地介绍了结构化方法，包含结构化需求分析方法和结构化软件设计方法。一下面对结构化方法作一小结。 1)一般来说，分析是系统化地使用信息，对一个问题的估算。软件需求分析是这一概念的特化，即系统化地使用由“数据流，、“加工”、“数据存储”、“数据源”和“数据潭”等术语所表达的信息，对待建系统“是什么”给出一个估算系统概念模型，而“软件设计是定义满足需求所需要的结构”。结构化方法作为一种特定的软件开发方法学，是从事系统分析和软件设计的一种思想工具。 2)结构化方法的提出，是基于看待客观世界的基本观点，即一切信息系统都是由信息流构成的，每一信息流都有自己的起点一数据源，有自己的归宿一数据潭，有驱动信息流动的加工，所谓信息处理主要表现为信息的流动。3)人们解决问题的一般途径是，首先对那些非结构化和半结构化的问题，通常采用已掌握的知识，建造它们的模型定义问题;而后基于已定义的问题，给出相应的解决方案;最后采用一定的工具，实现这一解决方案，如图3-55所示。其中，使用数学作为工具，对一个特定的问题建造了一个模型：Y=x*x+5 结构化方法遵循了人们解决问题的一般途径，其中需求分析就是通过建造待开发系统/产品的概念模型，定义需要解决的问题当采用一定技术验证后，表明该模型是可用的情况下，就可进行总体设i和详细设计，给出求解软件的一种方案，进而采用一种程序设计工具实现。当表明该模型不可使用时，那么就需要修改模型，重新验证。4)所谓模型，简一单地说，就是对任意事物的一个抽象，特性以及所描述的各个方面。进一步说，其中包括系统的一些基本能模型是在特定意图下所确定的角度和抽象层，对一个物理系统的描述，给出系统内各模型元素以及它们之间的语义关系对该系统边界的描述。因此，采用结构化方法建立的系统功能模型，通常还包含力上求为目的，从系统行为的角度，在由“数据流”、“加工”、“数据存储”、“数据源”等术语所定义的需求层上，对待开发系统的描述，包括系统环境的描述。5)为了支持系统功能建模， 紧紧围绕“问题分离”、“过程抽象”、“数据抽象”等基本原则，结构化分析方法提出了5个概念，它们是数据源、数据潭、数据流、加工和数据存，并给出了相应的表示。其中，“数据流”和“数据存储”支持对系统数据的抽象，“加工”支持系统功能/过程的抽象；“数据源”、“数据谭”一级相关的数据流支持对系统环境的描述。应该说，这些概念对于规约软件系统的功能是完备的，即它们可以“覆盖”客观世界的一切事物，并且这些概念的语义还相当简单，容易理解和掌握。为了支持软件求解，紧紧围绕“功能/过程抽象”、“逐步求精”和“模块化”等基本软件设计原理或原则，给出了模块、模块调用等概念以及相应的表示，给出了模块结构图、PAD图、N-S图、伪码等设计工具，给出了自顶向下、功能分解的过程指导变换设计和事务设计，并给出了实现模块化的基本准则，以提高模块的独立性。 所谓模块化，是指按照“高内聚低藕合”的设计原则，形成一个相互独立但又有较少联系的模块结构的过程，使每个模块具有相对独立的功育歇过程。 所谓逐步求精，是指把要解决问题的过程分解为多个步骤或阶段，每一步是对上一步结果的精化，以接近问题的解法。逐步求精是人类解决复杂问题的基本途径之一。抽象和逐步求精是一对互补的概念，即抽象关注问题的主要方面，忽略其细节;而逐步求精关注底层细节的揭示。 可见，结构化方法为了支持系统建模和软件求解，基于一些软件设计原理或原则，给出了完备的符号集，给出了相应功能模型的表达工具，给出了自顶向下、逐层分解的过程指导，如图3-56所示。(6)依据5，我们可以认识到，“软件方法学是以软件方法为研究对象的学科。主要设计指导软件设计的原理和原则，以及基于这些原理、原则的方法和技术。侠义的软件方法学也指某种特定的软件设计指导原则和方法体系”。(7)从软件方法学研究的角度，结构化方法仍然存在一些问题，其中最主要的问题是仍然没有“摆脱”冯.诺依曼体系结构的影响，捕获的“功能”和“数据”恰恰是客观失误的易变性质，由此建造的系统结构很难与客观实际系统的结构保持一致。模块构造图及相关的数据结构，如图所示3-57所示。其中，模块B, G, C, H访问数据结构1，而模块L, I, D, J访问数据结构2。 显然，这样的模块结构一般不会保持客观系统的结构，并且也很难维护，这是因为数据是客观事物的易变属性，一旦数据发生变化，那么不但要修改相应的数据结构，很可能还需要修改相关的那些模块，甚至受这些模块修改的影响，还需要修改模块结构中的其他模块，从而为系统的验证和维护带来相当大的困难，甚至是“灾难性”的。在某种意义上来讲，就是这些问题促使了面向对象方法学的产生和发展。第四章(1)UML作为一种图形化语言，紧紧围绕“面向对象方法是一种以客体和客体关系来创建系统模型的系统化软件开发方法学”，给出了比较丰富的表达事物和事物关系的术语，并给出了表达模型的工具，其主要目的是支持软件开发人员从不同角度(静态、动态)、针对不同粒度(系统、子系统、类目等)，从不同抽象层来创建模型，并建立相应的文档。 (2)为了支持抽象分析和设计中的事物，UML给出了8个基本术语，即类、接口、协作、用况、主动类、构件、制品、结点，并给出了这些基本术语的一些变体。每个术语都体现着一定的软件设计原理，例如类体现了数据抽象、过程抽象、局部化以及信息隐藏原理；用况体现了问题分离、功能抽象等原理;接。体现了功能抽象等。当使用这些术语创建系统模型时，它们的语义就映射到相应的模型元素中。本章重点讲解了其中的类接口和用况，简单地说明了协作、主动类构件、制品和结点，在第s章中可能会使用它们。希望读者在需要时能参阅有关文献，以便对它们有更深人地了解并使用。 (3)为了表达模型元素之间的关系，UML给出了4个术语，即关联、泛化、细化和依赖，以及它们的一些变体。可以作为UMI.模型中的元素，用于表达各种事物之间的基本关系。这些术语都体现了结构抽象原理，特别是泛化概念的使用，可以有效地进行“一般/特殊”结构的抽象，支持设计的复用。为了进一步描述这些模型元素的语义，还给出一些特定的概念和表示，例如给出限定符这一概念，以便增强关联的语义。 4)为了组织以上两类模型元素，UMI给出了包这一术语，在实际应用中，可以把包作为控制信息复杂性的机制。 5)为了使创建的系统(或系统成分)模型清晰、易懂，UML给出了“注解”这一术语。 6)为了表达概念模型和软件模型，UML提供了13种图形化工具，它们是类图、对象图、构件图、包图、部署图、组合结构图，以及USE CASE图、状态图、顺序图、通信图、活动图、交互概观图，定序图。前6种图可用于概念模型和软件模型的静态结构方面;而后7种模型可用于概念模型和软件模型的动态结构方面。 本章比较详细地讲解了4种表达系统(或系统成分)模型的工具。其中，类图可用于创建系统的结构模型，表达构成系统各成分之间的静态关系，给出有关系统(或系统成分)的一些说明性信息;Use Case图可用于创建有关系统(或系统成分)的功能模型，表达系统(或系统成分)的功能结构，给出有关系统(或系统成分)在功能需求方面的信息;状态图可用于创建有关系统(或系统成分)的行为生存周期模型，表达有关系统(或系统成分)的一种动态结构，给出有关系统(或系统成分)在生存期间可有哪些阶段、每一阶段可从事的活动以及对外所呈现的特征等方面的信息;顺序图可用于创建有关系统(或系统成分)的交互模型，表达系统(或系统成分)中有关对象之间的交互结构，给出系统(或系统成分)中的一些对象如何协作的信息。 本章没有讲解的模型表示工具包括对象图、构件图、包图、部署图、组合结构图，以及活动图、通信图、交互概观图和定序图。希望读者在需要时能参阅有关文献，以便对它们有好了解并正确使用。 另外，尽管在有的内容中提及一点UML的“公共机制”，例如衍型，但没有详细地解。 作为一种软件开发方法学，为了支持软件开发活动，至少包括3方面的内容:一是给出定义不同抽象层的术语;二是应给出各抽象层的模型表达工具;三是应给出如何把各层模型映射为下一个抽象层的模型，即过程指导。UML仅包括前两方面的内容，因此，UML是一种可视化的建模语言，而不是一种特定的软件开发方法学。 尽管在讲述中提到一点有关UML的应用问题，例如类的用途以及相关策略，但那是为了更好地理解，为其应用提供了一些宏观上的指导。第”章将介绍面向对象方法学中的第3部分一一过程。第五章RUP是一种软件开发过程框架，基于面向对象符号体系给出了有关软件开发过程组织及实施的指导。该框架体现了3个突出特征，即以用况驱动、体系结构为中心以及迭代、增量式开发。 RUP和UML是一对“姐妹”，它们构成了一种特定的软件开发方法学。其中，UML作为一种可视化建模语言，给出了表达事物和事物之间关系的基本术语，给出了多种模型的表达工具;而RUP利用这些术语定义了需求获取层、系统分析层、设计层、实现层，并给出了实现各层模型之间映射的基本活动以及相关的指导。需求获取层的基本术语有:用况、参与者、用于表达用况参与者之间关系的关联、用于表达用况之间关系的包含和扩展、用于表达参与者之间关系的泛化。这些术语确定了系统用况模型的各种形态。系统分析层的基本术语有:分析类(包括边界类、控制类和实体类)、用况细化分析、分析包以及用于表达分析包之间关系的依赖、用于表达分析类之间关系的关联等。这些术语确定了系统分析模型的各种形态。 系统设计层的基本术语有:设计子系统、设计类、用况细化设计、接口，以及用于表达子系统之间关系的依赖、用于表达设计类之间关系的关联等。这些术语确定了系统设计模型的各种形态。 另外，在设计期间为了表达系统的分布计算，RUP提出了部署模型。系统的部署模型是一个对象模型。 其中，一个节点表达一个计算资源;节点的功能(或过程)是由部署在该节点上构件所定义的。节点之间的一些关系表示节点之间的通信手段。第六章本章主要讲解了软件测试及测试技术。首先介绍了软件测试概念，即“有规程地发现错误的过程”，其中错误(EITOL)是指“F所期望的设计之间的偏差，该偏差可能产生不期望的系统行为或失效”。而失效(Failure)是指“与所规约的系统执行之间的偏差”。失效是系统故障或错误的后果。而故障( Fault)是指“导致错误或失效的不正常的条件”。故障可以是偶然性的或是系统性的。在介绍了软件测试概念的基础上，给出了软件测试过程模型，并就其中的被测对象模型的建立、测试用例的设计以及测试执行讲解了两种主要技术白盒测试技术和黑盒测试技术。 白盒测试技术依据程序的逻辑结构，以控制流程图作为被测对象建模工具，其中涉及过程块、分支、节点、链以及路径，并针对测试完成，给出了4种覆盖策略:语句覆盖、分支覆盖、条件组合覆盖和路径覆盖，它们之间具有偏序关系，并且可根据项目需求给出其他覆盖策略。 黑盒测试技术依据软件行为的描述，主要讲解了事务流测试技术和等价类划分测试技术。事务流测试技术以事务流程图作为被测对象建模工具，在此基础上设计覆盖相应事务的测试用例并执行它。等价类划分测试技术以等价类表作为被测对象模型，在此基础上设计测试用例并执行它。软件测试不但在开发中使用，而且在验证和确认的动态分析中也经常使用。动态分析是指执行程序的分析，测试为动态分析提供了必要的信息。如章首所说，“错误是不可避免的，因此发现错误是保障软件过程质量和软件产品质量的基础”。因此，软件测试是保障软件过程质量和软件产品质量的一种重要的手段。第七章 本章讲解了软件工程的过程规划技术以及过程监控。主要内容包括: 1)软件工程需要做哪些工作，其中主要介绍了ISO/IEC系统与软件工程一软件生存周期过程12207-2008 )。 2)软件开发工作的组织，主要介绍了几个软件生存周期模型，包括瀑布模型、增量模型、演化模型、螺旋模型等，并简单分析了它们的产生背景、优缺点以及适用情况。3)软件项目的过程规划与监控，主要介绍了项目过程的建立以及有关监控问题。第八章以下通过7点对CMMI进行小结。 1)针对开发的CMMI是一个有关产品和服务的过程改善的成熟度模型，集成了3个源模型:软件CMM、系统工程CMM和集成产品开发CMMo 2)该模型基于过程途径思想，通过过程把软件质量的3个支撑点受训的人员、规程和方法、工具和设备进行集成，以开发所期望的系统/产品。为此，CMMI紧紧围绕开发、维护和运行，把经过证明的“最佳实践”放在一个结构中。该结构有助于指导组织确定其过程的改善优先次序;有助于指导这些改善的实施，以提高其过程能力和成熟度，并且还支持其他领域(如获取和服务)能力成熟度模型的开发。 3 ) CMMI提供了两种过程改善路径，一是称为能力等级的过程改善路径，该路径可使组织针对单一过程域，不断改善该过程域;二是称为成熟度等级的过程改善路径，该路径可使组织通过关注一组过程域，不断改善一组相关的过程域。 4)在第一种过程改善路径中，CMMI按不同的专用目标和共用目标，把一个过程域中“最佳实践”组织为6个不同的能力等级，分别称为: .0级:未完成级(Incomplete )。 .1级:已执行级(Performed )。 .2级:已管理级(Managed)o .3级:已定义级(Defined) o .4级:已定量管理级(Quantitatively Managed)。 .5级:持续优化级(Optimizing)。并按共用目标从“弱到强”，使这6个能力等级形成一个偏序。由此可见，能力等级是用来表征组织对一个过程域的改善。(5)在第二种过程改善路径中，CMMI基于ISO/IEC12207-2008等标准，首先把开发、维护、运行中的过程分为4个组。包含7个过程域，它们是配置管理、测量与分析、项目监控、项目规划、过程和产品质量保证、需求管理、提供方协议管理。 包含11个过程域，它们是决策分析与解决、集成项目管理、组织过程定义、组织过程关注、组织培训、产品集成、需求开发、风险管理、技术解决方案、验证、确认 包含两个过程域，它们是组织过程性能和定量项目管理。 包含两个过程域，它们是原因分析与解决和组织创新与部署。 而后按每一个过程域中的不同专用目标和共用目标，以及与这些目标相关联的“最佳实践”，组织为5个不同的成熟度等级，分别称为: .1级:初始级(Initial )(注:没有对应的过程组)。 .2级:已管理级(Managed )(注:对应第一组过程)。 .3级:已定义级(Defined )(注:对应第二组过程)。 .4级:己定量管理级(Quantitatively Managed)(注:对应第三组过程)。 .5级:持续优化级(Optimizing )(注:对应第四组过程)。 可见，CMMI按包含的过程域的多少以及相关共用目标的强弱，成一个偏序，以表征组织对所关注的一组过程域的改善。使这5个成熟度等级形成一个偏序，以表征组织对所关注的一组织过程域的改善。6)在编号越大，CMMI中，共用目标有6个，用于表征过程制度化的程度。目标的说明该过程的制度化程度就越高。但是，为了提高CMMI的可操作性，对于成熟度等级而言，4级和5级的过程域只要求达到公用目标3或更高。具体地说:如果一个组织期望达到成熟度2级(见图8-17 )，就必须使项目规划、配置管理、测量与分析、项目监控、过程和产品质量保证、需求管理、提供方协议管理这7个过程域均达到共用目标20如果一个组织期望达到成熟度3级(见图8-18 )，就要使2级所包含的过程域以及决策分析与解决、集成项目管理、组织过程定义、组织过程关注、组织培训、产品集成、需求开发、风险管理、技术解决方案、验证、确认过程域均达到共用目标3。如果一个组织期望达到成熟度4级，就要使2级和3级所包含的过程域以及组织过程性能、定鼠项,I管理这两个过程域均达到共用目标3或以上。如果一个组织期望达到成熟度5级，就要使2级、3级、4级包含的过程域一级原因分析与解决、组织创新与部署这两个过程域均达到公用目标3或以上。(7)为了支持CMMI的应用，在该标准中还给出了一个概念；目标轮廓(Target Profile)。一个目的轮廓定义了所有的需要予以关注的过程域，以及所针对的能力等级。通过以上7点小结可以看出，CMMI是一种过程改善模型。作为一个软件开发组织，只有具备有关过程规划与监控能力，并不断进行过程改进，才能实现章首语所说的“仅当对软件过程予以有效管理时，才能实现有效的软件工程。”