《软件工程期末考试汇总.pdf》由会员分享，可在线阅读，更多相关《软件工程期末考试汇总.pdf（26页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、第一章软件和软件工程1.4 软件过程软件过程是工作产品构建时所执行的一系列活动、动作和任务的集合。在软件工程领域过程不是对如何构建计算机软件的严格规定，而是一种可适应性调整的方法，以便于工作人员可以挑选合适的工作和任务集合。个通用的软件工程过程框架通常包含以下5个活动：1、沟通。在技术工作开展之前，和客户的沟通与协作是非常重要的。2、策划。策划活动就是创建一个地图，以指导团队的项目旅程，它定义了和描述了软件工程工作包括需要执行的任务可能的风险、资源的需求和工作计划。3、建模。软件工程师利用模型来更好地理解软件需求并完成符合这些需求的软件设计。4、构建。它包括编码和测试以发现编码中的错误。5,部
2、署。软件交付到用户，用户对其进行评测并给出反馈意见。典型的普适性活动包括：软件项目跟踪和控制、风险管理、软件质量保证、技术评审、测量、软件配置管理、可复用管理、工作产品的准备和生产1.5 软件工程实践实践的精髓：理解问题（沟通分析）、计划解决方案（建模和软件设计）、实施计划（代码生成）、检查结果的正确性（测试和质量保证）一般 原 则（7个原则）：存在价值、保持简洁、保持愿景、关注使用者、面向未来、计划复用、认真思考第二章过程模型2.1 通用过程模型2.1.1 定义框架活动过程流描述了在执行顺序和执行时间上，如何组织框架中的活动、动作和任务。4种过程流：线性过程流（从沟通岛部署顺序执行五个框架活
3、动）、迭代过程流（在执行下一个活动前重复执行之前的一个或多个活动）、演化过程流（采用循环的方式执行各个活动）、并行过程流（将一个或是多个活动与其他活动并行执行）。个人负责的小型软件项目主要的动作是电话交流，主要的任务集有1、通过电话与利益相关者取得联系2、讨论需求并做记录3、将笔记整理成份简单的书面需求4、通过Email请利益相关者审阅并批准2.1.2 明确任务集每一个软件工程动作，都是山若干个任务集构成的，而每一个任务集都由软件工程工作任务、相关工作产品、质量保证点等部分组成，需要选择满足项目并适合开发团队特点的任务集。这就意味着软件工程动作可以根据软件项目的特定需要和开发队伍的特点做适当调
4、整。2.1.3 过程模式过程模式描述了软件工程工作中遇到的过程相关的问题、明确了问题环境并给出了针对该问题的一种或几种可证明的解决方案。通过模式组合，软件团队可以解决问题并定义最符合项目需求的开发过程。过程模式的描述模板：模式名称：能清楚地表述模式在软件过程中的含义驱动力：模式使用环境及主要问题类型：定义模式类型（步骤模式、任务模式、阶段模式）启动条件：它是模式应用的前提条件问题：描述模式要解决的具体问题解决办法：描述如何成功实现模式结束条件：描述模式成功之后的结果相关模式：以层次或其他图的方式列举与该模式直接相关的其他过程模式已知应用实例：说明该模式可应用的具体实例过程模式一旦建立起来，就可
5、以复用来定义各种过程变体，即软件开发队伍可以将模式作为过程模型的构建模块，定制特定的过程模型。2.3 惯用过程模型【会画】2.3.1 瀑布模型。又称为经典生命周期，它提出了一个系统的、顺序的软件开发方法，从用户需求规格说明开始，通过计划、建模、构建和部署的过程，最终提供一个完整的软件并提供持续的技术支持。2.3.2 增量过程模型。综合了线性过程流和并行过程流的特征。随着时间的推移，增量模型在每个阶段运用线性序列。每个线性序列以一种演化过程流生产增量类似的方式生产出一个软件的可交付增量。2.3.3 演化过程模型。是迭代的过程模型，使软件开发人员能够逐步开发出更完整的软件版本（演化过程模型中，每个
6、迭代产生软件的一个更完整的版本。）两种常用的演化过程模型：1、原型开发模型开始于沟通。软件开发人员和利益相关者进行会晤，定义软件的整体目标，明确已知的需求，然后迅速刻画一个原型开发迭代并进行建模。在原型系统不断调整以满足各种利益相关者需求的过程中。采用迭代技术，同时也使开发者逐步清楚用户的需求.2、螺旋模型是一种演进式软件过程模型。它结合了原型的迭代性质和瀑布模型的系统性和可控特点。螺旋模型是一种风险驱动型的过程模型生成器，对于软件集中的系统，它可以指导多个利益相关者的协同工作。它有两个显著的特点：一是采用循环的方式逐步加深系统定义和实现的深度，同时降低风险。二是确定一-系列里程碑，确保利益相
7、关者都支持可行的和令人满意的系统解决方案。2.3.4 协同模型协同开发模型（协同工程），它允许软件团队表达本章所描述的任何模型中的迭代和并发元素。协同模型定义了一系列事件，这些事件将触发软件工程活动、动作和任务的状态转换。它可以适用于所有类型的软件开发。2.3.5 演化模型的最终评述演化模型是采用迭代或者增量的方式开发高质量软件。她也可以做到强调灵活性、可延展性和开发速度。第三章敏捷开发3.3 敏捷过程是什么任何一个敏捷过程都可以由3个关键假设来识别：1、提前预测哪些需求是稳定的而哪些需求会变更非常困难。2、对很多软件来说，设计和构建是交错进行的。3、从制定计划的角度来看，分析、设计 构建和测
8、试并不像我们设想的那么容易预测。3.3.1 敏捷原则（12条）1.通过尽早、持续的交付有价值的软件来使客户满意2 .利用变更为客户创造竞争优势3 .经常交付可运行软件4 .在项目开发期间，业务人员和开发人员天天在一起工作5 .围绕有积极性的个人构建项目6.面对面交谈是最有效果的信息传递方法7 .可运行软件是进度的首要度量标准8 .敏捷过程倡导可持续的开发速度9 .不断关注优秀的技能1 0 .简单是必要的1 1 .最好的架构、需求和设计出自于自组织团队1 2 .每隔一定时间，团队反省如何做有效的工作3.3.3人的因素如果敏捷开发团队成员希望努力维护所使用的过程的特性,则该团队成员及团队本身必须具
9、备以下一些特点：基本能力、共同目标、精诚合作、决策能力、模糊问题解决能力、相互信任和尊重、自组织3.5 其他敏捷过程模型适应性软件开发强调人的合作和团队的组织，按思考、协作、和学习三个框架活动组织,A S D 使用迭代过程，该过程由自适应循环计划、相对严格的需求收集方法和个迭代开发循环构成，其中迭代开发循环包括客户焦点组合正式技术评审作为实时反馈机制。动态系统开发方法定义了三种不同的迭代循环：功能模型迭代、设计和构建迭代和实现迭代，另外前面还增加了可行性研究和业务研究两个传统的生命周期活动。动态系统开发方法倡导时间调度的使用，认为对每一个软件增量所需的必要工作仅仅是能够方便地进入下一次增量开发
10、。S c r um 强调一系列软件过程模式的使用，这些模式已被证实对时间紧迫、需求变化和业务重要的项目非常有效。每个过程模式定义系列开发任务并允许S c r um 团队以适应其项目的方式构建过程。动态系统开发方法是一种敏捷软件开发方法，该方法提供一种框架，使其 通过在可控项目环境中使用增量原型开发模式完全满足对时间有约束的系统的构建和维护C r y s t a l 是一系列敏捷过程模型可用于具有特定特征的项目。和其他敏捷方法类似，C r y s t a l 采用迭代策略，但可以调整过程的严格程度以适应不同规模和复杂度的项目。特征驱动开发某种程度上比其他敏捷方法更“形式化”，而且通过项目开发团队
11、专注于特征的开发来维持敏捷性。F D D 比其他敏捷方法更强调项目管理和质量管理。敏捷建模认为对于所有的系统都是必要的，但是模型的复杂度、类型和规模都必须根据所构建软件来调节。通过提出一系列核心和补充建模原则，AM给实践者的分析和设计任务以非常有用的指导。精益软件开发是在软件工程里适用于精益制造的原则。精益原则鼓励L S D 过程消除耗损、把质量体现于产品、创造知识、遵从承诺、快速交付、尊重成员以及整体优化。敏捷统一过程(A U P)采用了一个全局串行以及局部迭代的原理来构建基于计算机的系统。采用经典U P 阶跃性运动开始、加工、构建以及变迁，U P 提供了一系列覆盖，能够使团队为软件项目构想
12、出一个全面的过程流。3.5.7 敏捷建模(A M,A g i l e M o d e l i n g)独具特色的建模原则:有目的的模型、使用多个模型、轻装上阵、内容重于表述形式、理解模型及工具、适应本地需要。小结：软件工程的敏捷理念强调4个关键问题：自我组织团队对所开展工作具有控制力的重要性；团队成员之间以及开发参与者与客户之间的交流与合作；对“变更代表机遇”的认识;以及强调快速软件交付以让客户满意。敏捷过程模型能解决上述这些问题。第四章指导每个框架活动的原则4.2 核心原则4.2.1 指导过程的原则原 则1：敏捷。保持你的技术方法尽可能简单，保持你的工作产品尽可能简洁，无论何时尽可能根据具体
13、情况做出决定。原则2：每一步都关注质量。原则3：做好适应的准备。当需要的时候，就让你的方法适应于由问题、人员以及项目本身施加的限制。原则4：建立一个有效的团队。原则5：建立沟通和协调机制。原则6：管理变更。必须建立一种机制来管理变更要求的提出、变更的评估、变更的批准以及变更实施的方式。原则7：评估风险。原则8：创造能给别人带来价值的工作产品。4.2.2 指导实践的原则原 则1：分治策略（分割和攻克）。大问题分解为小问题。原则2：理解抽象的使用。在这一核心原则中，抽象就是对个系统中一些复杂元素的简单化，用以传达词组的含义。原则3：力求一致性。一致性原则建议熟悉的上下文使软件易于使用。原则4：关注
14、信息传送。这一原则的含义是必须特别注意界面的分析、设计、构建以及测试。原则5：构建能展示有效模块化的软件。原则6：寻找模式。原则7：在可能的时候，用大量不同的观点描述问题及其解决方法。这样就有可能获得更深刻的认识，发现错误和遗漏。原则8：记住：有人将要对软件进行维护。4.3 指导每个框架活动的原则4.3.1 沟通原则倾听；有准备的沟通（沟通前花时间理解问题）；需要有人推动（主持人）；最好当面沟通；记录所有决定；保持通力协作；把讨论集中在限定的范围内；如果某些东西很难表述清楚，采用图形表示；继续前进原则；协商不是场竞赛或者一场游戏，协商双赢忖才发挥了协商的最大价值。4.3.2 策划原则理解项目范
15、围；吸收利益相关者参与策划；要认识到计划的制定应按照迭代方式进行；基于已知估计；计划考虑风险；保持脚踏实地；调整计划粒度；制定计划确保质量；描述如何适应变化；经常跟踪并根据需要调整计戈上4.3.3 建模原则：软件团队的主要目标是构建软件而不是创建模型；轻装前进不需要创建你不需要的模型；尽量创建能描述问题利软件的最简单模型；用能适应模型改变的方式构建模型；明确描述创建每一个模型的目的；调整开发模型适应待开发系统；尽量构建有用的模型而不是完美的模型；对于模型的构造方法不要太死板；如果直觉告诉你模型很不妥当，尽管看上去很正确，那么你要仔细注意了；尽可能快的获得反馈。需求建模原则：必须描述并理解问题的
16、信息域；必须确定软件所要实现的功能；必须描述软件的行为（作为外部事件的结果）；描述信息、功能和行为的模型必须以一种能揭示分层（或者分级）细节的方式分解开来；分析任务应该从本质信息转向实现细节；设计建模原则：设计可追溯到分析模型；经常关注待建系统的架构；数据设计与功能设计同等重要；必须精心设计接口（包括内部接口和外部接口）；用户界面设计必须符合最终用户要求；构件级设计应是功能独立的；构件之间以及构建与外部环境之间松散耦合；设计表 述（模型）应该做到尽可能易于理解；设计应该迭代式进行，每一次迭代，设计者都应该尽力简化。4.3.4 构造原则（包括编码原则和测试原则）编码原则包括：准备原则、编程原则、
17、确认原则测试原则包括：所有测试都应该可以追溯到用户需求；测试计划应该在测试之前着手；将 Pareto原则应用于软件测试；测试从微观到宏观；穷举测试时不可能的。4.3.5部署原则客户对于软件的期望必须得到管理；完整的交付包应该经过安装和测试：技术支持必须在软件交付之前确定下来；必须为最终用户提供适当的说明材料；有缺陷的软件先改正后交付。第五章理解需求5.1 需求工程（RE）是指致力于不断理解需求的大量任务和技术。从软件过程的角度来看，需求工程是一个软件工程动作，开始于沟通活动，并持续到建模活动。它必须适用于过程、项目、产品、人员工作的需要。需求工程过程通过执行7 个不同的活动来实现：起始、导出、
18、精化、协商、规格说明、确认和管理起始：在项目起始阶段，要建立基本的理解，包括对问题、谁需要解决方案、所期望解决方案的性质、与项目利益相关者和开发人员达成初步交流合作的效果导出：1、范围问题：系统的边界不清楚、不必要的技术细节；2、理解问题：客户或用户并不能完全确定需要什么；3、易变问题：需求随时间变化精化：在起始和导出阶段获得的信息将在精化阶段进行扩展和提炼。协商：需求工程师必须通过协商过程来解决客户和用户的冲突规格说明：在基于计算机的系统的环境下，术语规格说明对不同的人有不同的含义，可以是一份写好的文档、一个形式化的数学模型、一组使用场景。确认：在确认这一步，将对需求工程的相关产品进行质量评
19、估需求管理：是用于帮助管理项目组在项目进展中标识、控制和跟踪需求以及需求变更的一组活动。5.5构建需求模型5.5.1 需求模型的元素基于场景的元素：使用此方法可以从用户的视角描述系统。基于类的元素：每个使用场景都暗示着当一个参与者和系统交互时所操作的一组对象，这些对象被分成类具有相似属性和共同行为的事物集合。行为元素：状态图是一种表现系统行为的方法，该方法描述系统状态以及导致系统改变状态的事件。需求分析模型必须提供描述行为的建模元素。面向数据流的元素：信息在基于计算机的系统中流动时会被转换，系统结构多种形式的输入；使用函数将其转换，生成多种形式的输出。5.5.2 分析模式分析模式在特定应用领域
20、内提供了一些解决方案（如类、功能、行为），在为许多应用项目建模时可以重复使用。第六章需求分析6.1需求分析需求分析产生软件工作特征的规格说明，指明软件和其它系统元素的接口，规定软件必须满足的约束。需求分析让软件工程师细化在前期需求工程的起始、导出、谈判任务中建立的基础需求。6.1.1 整体目标和原理分析模型必须实现三个主要目标：(1)描述客户需要什么；(2)为软件设计奠定基础:(3)定义在软件完成后可以被确认的一组需求。分析模型在系统级描述和软件设计的差距之间建立桥梁6.1.2.分析的经验原则：在创建分析模型时应该遵循这些经验原则(1)模型应关注在问题域或业务域内可见的需求，抽象的级别应该相对
21、高一些；(2)分析模型的每个元素都应能增加对软件需求的整体理解，并提供对信息域、功能和系统行为的深入理解；(3)关于基础结构和其他非功能的模型应推延到设计阶段再考虑；(4)最小化整个系统内的关联；(5)确认分析模型为所有共利益者带来价值；(6)尽可能保持模型简洁。6.1.3 域分析软件域分析是识别、分析和详细说明来自某个特定应用领域的公共需求，特别是那些在该应用领域内被多个项目重复使用的需求面向对象的域分析是在某个特定应用领域内，根据通用的对象、类、部件和框架，识别、分析和详细说明公共的、可复用的能力。域分析的目标：查找或创建那些分析类和(或)能够广泛应用的、共有的功能和特点，这样就可以复用。
22、6.1.4需求建模方法1 .结构化分析：考虑数据和处理的分析建模方法，其中数据作为独立实体转换。2 .面向对象的分析：这种方法关注于定义类和影响客户需求的类之间的协作方式。6.2 基于场景建模6.2.1 新建初始用例用例从某个特定参与者的角度出发，采用简明的语言描述个特定的使用场景，我们需要回答编写什么？写多少？编写说明应该多详细？如何组织说明？开发用例时，应列出特定参与者执行的功能和活动。这些可以从所需系统功能的列表通过与利益相关者交流，或通过评估活动图(作为需求建模中的一部分而开发)获得。6.2.2 细化初始用例主场景中的每个步骤将通过如下问题得到评估：在这一状态点,参与者能进行一些其他动
23、作吗？参与者有没有可能遇到一些错误条件？参与者有没有可能遇到些其他行为？这些问题的答案导致创建了一组次场景，次场景属于原始用例的一部分，但是表现了可供选择的行为。第七章需求建模：流程、行为、模式和W e b应用7.2面向数建模数据流图(D F D),D F D采取了系统的输入处理一输出的观点，也就是说，流入软件的数据对象，经由处理元素变换，最后以结果数据对象的形式流出软件。带标记的箭头表示数据对象，圆圈(也称作泡泡)表示转换。1.导出数据流图时一些有用而简单的指导原则：(1)第0层的数据流图应将软件或系统描述为一个泡泡；(2)应仔细标记主要的输入和输出(3)通过把选定的处理、数据对象和数据存储
24、分离为下一层表示而开始精化过程(4)应使用有意义的名称标记所有的箭头和泡泡(5)当从一个层转到另一个层时要保持信息流连续性(6)一次精化一个泡泡2.创建控制流模型有很多问题是事件驱动的而不是数据驱动的，这类问题产生控制信息而不是报告或显示信息，并且处理信息是非常关注时间和性能选择潜在候选事件，建议使用如下的指导原则：（1）列出所有被软件“读”的传感器（2）列出所有的中断条件（3）列出操作人员能够启动的所有的“开 关“（4）列出所有的数据条件（5）回顾对处理叙述所进行的名词的语法解析，考察所有可能作为控制规格说明输入输出的“控制项“（6）通过标示其状态描述系统的行为（7）关注可能的疏忽第八章设计
25、概念8.1 软件工程中的设计设计工程包括一套原理、概念和实践，可以指导高质量的系统或产品开发。设计工程的目标是创作出坚固、适用和赏心悦目的模型或设计表示。先实现多样化再进行聚合，即选择能够满足需求工程和分析模型所定义的需求的元素，进行聚合，使之成为构建的某种特定的配置，于是便得到最终的产品。软件设计是建模活动的最后一个软件工程活动。软件设计过程由基于场景的元素、基于类的元素、面向流的元素和行为元素所表明的分析模型是设计任务的输入，通过设计表示法和设计方法，将得到数据/类设计、体系结构设计、接口设计和构件设计。8.2 设计过程8.2.1 软件质量指导原则和属性1.设计过程和设计质量McGlaug
26、hlin提出了可以指导评价良好设计演化的三个特征：设计必须实现所有包含在分析模型中的明确需求，而且必须满足客户期望的所有隐含需求。对于那些生成代码的人和那些进行测试以及随后维护软件的人而言，设计必须是可读的、可理解的指南。设计必须提供软件的全貌，从现实角度说明数据域、功能域和行为域。2.质量指导原则1、设计应展示出这样一种结构：（a）已经使用可识别的体系结构或模式创建（b）由展示出良好设计特征的构建构成（c）能够以演化方式实现，从而便于实现和测试。2、设计应该模块化；也就是说软件应按照逻辑划分为元素或者子系统。3、设计应该包括数据、体系结构、接口和构建的清楚的表示。4、设计应导出数据结构，这些
27、数据结构适于要实现的类，并由可识别的数据模式提取。5、设计应导出显示独立功能特征的构建。6、设计应导出接口，这些接口降低了构件之间以及与外部环境连接的复杂性。7、设计的导出应根据软件需求分析过程中获取的信息采用可重复使用的方法进行。8、应使用能够有效传达其意义的表示法来表达设计。3.质量属性FURPS,其中个字母分别代表功能性（functionality）,易用性（usablity）,可靠性（reliablity）,性 能(performance),可支持性(supportablity)功能性评估程序的特征集和能力，所提交功能的普遍性以及整个系统的安全性。易用性通过考虑人为因素、整体美感、一致
28、性和文档来评估。可靠性通过测量故障的频率和严重性、输出结果的精确性、故障平均时间、故障恢复能力和程序的可预见性来评估。性能度量处理速度、响应时间、资源消耗、吞吐量和效率。可支持性综合了可扩展性、适应性和耐用性这三个方面的能力，此外还包括可测试性，兼容性，可配置性，系统安装的简易性和问题定位的简易性。实际上，设计概念强调了：1、抽象的必要性，它提供了一种创造可重用软件构件的方法；2、体系结构的重要性，它使得能够更好地理解系统整体结构；3、基于模式的工程的有益性，它是一项用于已证明能力的软件的设计技术；4、关注点分离和有效的模块化的价值,它们使得软件更容易理解、更容易测试以及更容易维护；5、信息隐
29、藏的直接作用，当错误发生时，它能够减少负面影响的传播；6、功能独立的影响，它是构造有效模块的标准；7、求精作为一种设计方法的作用；8、横切系统需求方面的考虑；9、重构的应用，它是为了优化己导出的设计；10、面向对象的类和与类相关特征的重要性。第九章体系结构设计进行体系结构设计(1)为计算机系统建造的软件也展示了众多体系结构风格的种。每种风格描述一种系统类别，包括：一组构件(比如：数据库、计算模块)完成系统需要的某种功能；一 组 连 接 器，他们能使构件间“通信、合作和协调”；约 束，定义构件如何集成为一个系统 语 义 模 型，它能使设计者通过分析系统的构成成分的性质来理解系统的整体性质。(2)
30、一种体系结构风格就是一种加在整个系统设计上的变换。目的为系统的所有构件建立 个 结 构。在对已有体系结构进行再工程时，强制采用一种体系结构风格会导致软件结构的根本性改变，包括对构件功能的再分配。(3)体系结构模式和体系结构风格一样，也对体系结构的设计施加一种变换。模式可以与体系结构风格结合起来，用于建立整个系统结构的外形。9.3.1 体系结构风格的简单分类：以数据为中心的体系结构；【数据存储驻留在这种体系结构的中心，其他构件会经常访问该数据存储，并对存储中的数据进行更新、增加、删除或修改；提升可集成性；客户构建独立地执行过程】数据流体系结构；【输入数据经过一系列的计算和操作构件的变化形成输出数
31、据】调用和返回体系结构；(包括：主程序/子程序体系结构、远程过程调用体系结构)向对象体系结构；【系统的构件封装了数据和必须应用到该数据上的操作，构件间通过信息传递进行通信与合作】层次体系结构；【核心层、实用程序层、应用程序层、用户界面层、构件；最外层，构件完成用户界面的操作；最内层，构件完成与操作系统的连接；中间层提供实用程序服务和应用软件功能。】9.6映射数据流到软件体系结构【重点】【变换流】输入流被描述为信息从外部形式变换为内部形式的途径，输出流是信息从内部形式变换为外部形式的路径，整个的数据流动以一种顺序的方式沿着一条或仅仅很少的几条“直线”路径进行，当一部分数据流图展现了这些特征时,表
32、明变换流的存在。【事务流】信息流经常被描述为单个数据项，即事务，他可以沿多条路径中的一条触发其他数据流。【变换映射】开发个软件的体系结构表示（或数据流图映射成体系结构模型）的七大步骤：步骤一：评审基本系统模型步骤二：评审和精化软件的数据流图步骤三：确定DFD是否含有变换流或事务流特征步骤四：通过确定输入流和输出流的边界，分离出变换中心步骤五：完 成“第一次分解”步骤六：完 成“第二次分解”步骤七：使用提高软件质量的设计启发式方法，精化第一次迭代得到的体系结构一般来说，体系结构设计需要4个不同步骤来完成。第一步，系统必须表示在相应的环境中，也就是说，设计人员应该定义与软件交互的外部实体及其交互性
33、质。一旦环境得到说明，设计人员就应该确定一系列的顶层抽象，称之为原型，该原型可以表示系统行为或者功能的关键元素。定义完抽象后，设计开始向实现移动。在支持构件的体系结构环境中识别和描述这些构件。最后，开发体系结构的特定实例，在真实世界中验证设计。第十章构件级设计什么是构件面向对象的观点在面向对象的软件工程环境中，构件包括一组协作的类。构件中的每个类都得到详细的阐释，包括所有的属性和与其实现相关的操作。传统观点在传统软件工程环境中，一个构件就是程序的一个功能要素，程序由处理逻辑及实现处理逻辑所需的内部数据结构以及能够保证构件被调用和实现数据传递的接口构成。传统构件也称为模块。作为软件体系结构的一部
34、分，它承担如下3个重要角色之一：1、控制构件，协调问题域中所有其他构件的调用；2、问题域构件，实现客户需要的全部功能或部分功能;3、基础设施构件，负责完成问题域中所需支持处理的功能。1 0.2设计基于类的构件1 0.2.1基本设计原则L i s k o v 替换原则；依赖倒置原则；接口分离原则；发布复用等价性原则；共同封装原则；共同复用原则。10.3实施构件级设计步 骤 1：标识出所有与问题域相对应的设计类。步骤2：确定所有与基础设施域相对应的设计类。步骤3：细化所有不能作为复用构件的设计类。步骤4：说明持久数据源并确定管理数据源所需要的类。步骤5：开发并且细化类或构件的行为表示。步骤6：细化
35、部署图以提供额外的实现细节。步骤7：考虑每一个构件级设计表示，并且时刻考虑其它选择。10.5设计传统构件【新内容】所有的程序都可以建立在组限定好的逻辑构造之上。（这一组逻辑构造强调了“对功能域的支持”，其中每一个逻辑构造有可预测的逻辑结构，从顶端进入，从底端退出，其过程流易理解）这些逻辑构造包括顺序型、条件型和重复型。顺序型实现了任何算法规格说明中的核心处理步骤；条件型允许根据逻辑情况选择处理的方式；重复型提供了循环。（这些逻辑构造是结构化编程的基础，而结构化编程是构件设计的一种重要技术）图形化设计表示：方框表示处理步骤，菱形表示逻辑条件，箭头表示控制流。顺序型由两个表示处理的方框以及连接两者
36、的控制线表示；条件型即if-th en-else结构，由一个菱形表示，并用两个方框表示e ls e 和 th e n 部分；重复型有do w h ile结 构 和 reapeat u n t i l 结构；选择型select-case,相当于 switch-case 结构。表格式设计表示：【了解】决策表分为四个部分，左上部列出了所有的条件，左下部列出了所有可能的动作，右半部构成了一个矩阵，表示条件的组合以及特定条件组合对应的动作。因此矩阵的每一列可以解释成一条处理规则。程序设计语言：程序设计语言（Program Design Language,PDL）也成为结构化的英语或伪代码。基本的 PDL
37、语言应包括用于定义构件的构造、接口描述、数据声明、块结构、条件结构、循环结构 和 I/O 构造。PDL包括多任务处理和（或）并发处理、中断处理、交互同步及其他特征关键字。第十一章用户界面设计11.1 黄金规则Theo Mandel在其关于界面设计的著作中提出了 3 条黄金规则：1、用户操纵控制设计原则：a、以不强迫用户进入不必要或者不希望的动作的方式来定义交互模式。b、提供灵活的交互。c、允许用户交可以互被中断和撤销。d、当技能级别增长时可以使交互流线化并允许定制交互。e、使用户和内部技术细节隔离开来。f、设计应允许用户与出现在屏幕上的对象直接交互。2、减轻用户的记忆负担设计原则：a、减少对短
38、期记忆的要求。b、建立有意义的缺省。c、定义直观的快捷方式。d、界面的视觉布局应该基于真实世界的特征。e、以不断进展的方式揭示信息。3、保持界面一致性设计原则：a、允许用户将当前任务放入有意义的环境中。b、在应用系统家族中保持一致性。c、如果过去的交互模式已经建立起了用户期望，除非不得已的理由，否则不要改变它。11.2 用户界面的分析与设计1、用户界面分析与设计模型分析和设计用户界面要考虑4 种模型：a、工程师建立用户模型（确立了系统最终用户的轮廓）。b、软件工程师创建设计模型（其中交互模式的选择要对用户进行分类）。c、最终在用户脑海里对界面产生的映像，称为用户的心里模型或系统感觉.d、系统的
39、实现者创建实现模型。2、用户界面分析与设计过程一般的这个过程是迭代的，包括4 个不同的框架活动：a、界面分析与建模（重点在于那些与系统交互的用户的心里模型）。b、界面设计（其目标是定义组界面对象和动作以及它们的屏幕显示）。c、界面构造（通常开始于创建可评估使用场景的原型）。d、界面确认（确认以下方面：界面正确实现每个用户任务的能力，适应所有任务变化的能力以及达到一般用户需求的能力；界面容易使用和学习的程度；用户将界面作为其工作中有用工具的接受程度。）11.3界面分析所有软件工程过程模型的一个重要原则就是：在试图设计一个解决方案之前，最好对问题有更好的理解。在用户界面设计中，理解问题就意味着了解
40、：1、通过界面和系统交互的人（最终用户）；2、最终用户为完成工作要执行的任务；3、作为界面的一部分而显示的内容；4、任务处理环境。11.3.1用户分析为了了解用户，可以利用各种途径获得的信息，这些途径包括：I、用户访谈：这是获取信息的最直接的方法。可以使一对一的会议方式，也可以是群体讨论的形式。2、销售输入：销售人员与用户定期会面，能够收集到有助于软件团队对用户进行分类和更好地理解用户需求的信息。3、市场输入：市场分析提供了对市场每个部分使用软件的细微差别的理解。4、支持输入：技术支持人员与用户交谈，使他们更容易获得“该做什么，不该做什么等等”。11.4界面设计步骤界面设计是一个迭代过程。每个
41、用户界面设计步骤都要进行很多次，每次细化和精化的信息都来源于前面的步骤。虽然有很多不同的用户界面设计模型,但都建议结合以下的步骤:1、使用界面分析中获得的信息，定义界面对象和动作（操作）八2、定义那些导致用户界面状态发生变化的事件（用户动作），并对行为建模。3、描述每个界面状态，就像最终用户实际看到的那样。4、简要说明用户如何从界面提供的界面信息来解释系统状态。1 1.4.1 应用界面设计步骤界 面 设 计 的 个重要步骤就是定义界面对象和作用于对象上的动作。一旦完成了对象和动作的定义及迭代细化，就可以将它们按类型分类。目标、源和应用对象都被标识出来。当设计者满意地认为已经定义了所有的重要对象
42、和动作（对一次设计迭代而言）时，开始进行屏幕布局。屏幕布局是一个交互过程。11.4.3设计问题在进行用户界面设计时，几乎总会遇到以下4 个问题：系统响应时间，用户帮助设施，错误信息处理和命令标记。响应时间：指从用户开始执行动作到软件以预期的输出和动作形式给出响应这段时间。系统响应时间包括两方面的属性：时间长度和可变性。系统时间的可变性是指相对于平均响应时间的偏差。即时响应时间比较长，响应时间的低可变性也有助于用户建立稳定的交互节奏。帮助设施：几乎所有计算机交互式系统的用户都时常需要帮助。错误处理：出差信息和警告是指出现问题时系统反馈给用户的“坏消息”。如果做得不好的话，出错信息和警告会给出无用
43、和误导的信息，反而增加了用户的沮丧感。菜单和命令标记:面向窗口的界面采用点击和选取方式，减少了用户对键入命令的依赖。但许多高级用户仍然喜欢面向命令的交互方式。在提供命令或菜单标签交互方式时，必须考虑“每个菜单选项是否都有对应的命令？”等问题。应用系统的可访问性：必须确保界面设计中包含使得有特殊要求的用户易于访问的机制。国际化：用户界面应该被设计成能够容纳需要交付给所有软件用户的核心功能。11.5 WebApp界面设计11.5.1 界面设计原则和指导方针预测：对 WebApp进行设计，使其能够预测出用户的下一个步骤；传达：界面应该能够传达由用户启动的任何活动的状态；一致：导航控制、菜单、图标和美
44、学风格的使用应该在整个WebApp中保持一致；自律：界面应该坚持使用已经为应用系统建立起来的导航习惯；效率:WebApp的设计和界面应该优化用户的工作效率；灵活性：界面应该足够灵活；关注点：WebApp界 面（及界面表示的内容）应该关注在用户正在完成的任务上；Fitt规则：“到达目标所用的时间是到达目标的距离和目标规模的函数”；人机界面对象：对 于 W ebApp,已经开发了大量可复用的人机界面对象库；缩短等待时间：WebApp不应该让用户等待内部操作的完成，而应该利用多任务处理方式，从而使用户继续他的处理工作；学习能力：将学习时间减到最少；隐喻：只要隐喻适合应用系统和用户，使用交互隐喻的界面
45、就更容易学习和使用；保持工作产品的完整性：工作产品必须自动保存，使得在有错误发生时数据不会丢失；易读性：界面展示的所有信息对于所有人都应该是易读的；跟踪状态：在合适的时候，应该跟踪和保存用户状态，使得用户能够退出系统，稍后返回系统时又能回到退出的地方；可见的导航：。11.5.2 WebApp的界面设计工作流基本工作流程：1、对需求模型中的信息进行评审，并根据需要进行优化。2、开发WebApp界面布局的草图。3、将用户目标映射到特定的界面行为。4、定义与每个行为相关的一组用户任务。5、为每个界面行为设计情节故事屏像。6、利用从美学设计中的输入来优化界面布局和情节故事板.7、明确实现界面功能的界面
46、对象。8、开发用户与界面交互的过程表示。9、开发界面的行为表示法。10、描述每种状态的界面布局。11、优化和评审界面设计模型。第十三章WebApp设计13.2 设计目标简单性；一致性；符合性；健壮性；导航性；视觉吸引；兼容性。13.3 WebApp设计金字塔整 一 件 设 t 十4麦 木1 3-2 W e b A p p i 殳 计 金:字 咯13.4 WebApp界面设计WebApp界面的目标是：1、建立一致性的窗口进入界面提供的内容和功能；2、通过一系列的与WebApp的交互指导用户；3、组织用户可用的导航选项和内容。13.5 美学设计13.5.1 布局问题一般的布局指导原则：不要担心留下
47、空白；重视内容；按照从左上到右下的顺序组织布局元素；在页面内按导航、内容和功能安排布局；不要通过滚动条扩展空间：在设计布局时，考虑分辨率和浏览器窗口的尺寸。第十四章质量概念14.2软件质量在最一般的意义匕软件质量可以这样定义：在一定程度上应用有效的软件过程，创造有用的产品，为生产者和使用者提供明显的价值0 1、有效的软件过程为生产高质量的软件产品奠定了基础。2、有用的产品是指交付最终用户要求的内容、功能和特征，最重要的是,以可靠、无误的方式交付这些东西。3、通过为软件产品的生产者和使用者增值，高质量软件为软件组织和最终用户群体带来了收益。14.2.1 Garvin的质量维度性能质量；特性质量；
48、可靠性；符合性；耐久性；适用性；审美；感知。14.2.3 I S 0 9 1 2 6 质量因素这个标准标识了 6 个关键质量属性：功能性；可靠性；易用性；效率；维护性；可移植性。第十五章评审技术1 5.6.3 评审指导原则最低限度的一组正式技术评审指导原则：1、评审工作产品，而不是评审开发人员。2、制定并遵守日程表。3、限制争论和辩驳。4、要阐明问题，但是不要试图解决所有记录的问题。5、做笔记。6、限制参与者人数，并坚持事先做准备。7、为每个将要评审的工作产品建立检查清单。8、为 FTR分配资源和时间。9、对所有评审员进行有意义的培训。10、评审以前所做的评审。小结：每次技术评审的目的都是找出
49、错误和发现可能对将要部署的软件产生负面影响的问题。越早发现并纠正错误，错误传播到其他软件工程产品并扩大，导致需要更多的工作来纠正的可能越小。第十六章软件质量保证16.2软件质量保证的要素软件质量保证涵盖了广泛的内容和活动，这些内容和活动侧重于软件质量管理，可以归纳如下：标准：软件质量保证的任务是要确保遵循所采用的标准，并保证所有的工作产品符合标准。评审和审核：技术评审是由软件工程师执行的质量控制活动，目的是发现错误。审核是一种由SQA人员执行的审核，意图是确保软件工程工作遵循质量准则。测试：软件测试是一种质量控制功能，它有一个基本目标发现错误。错误/缺陷的收集和分析：改进的唯一途径是衡量如何做
50、。变更管理：变更是对所有软件项目最具破坏性的一个方面。教育：每个软件组织都想改善其软件工程实践。供应商管理：通过建议供应商应遵循的具体的质量做法，并将质量要求作为与任何外部供应商签订合同的一部分，确保高质量的软件成果。安全管理：软件质量保证确保应用适当的过程和技术来实现软件安全。安全：软件质量保证可能负责评估软件失效的影响，并负责启动那些减少风险所必须的步骤。风险管理：软件质量保证组应确保风险管理活动适当进行，且已经建立风险相关的应急计划。16.3软件质量保证的任务、目标和度量16.3.1 软件质量保证任务软件质量保证组的行动纲领是帮助软件团队实现高品质的目标产品。执行一套质量保证活动，如下：