四川大学软件工程考点.doc

第一章软件工程介绍1. 一个包含过程(process)、一系列方法(methods)和工具(tools)的框架，我们称之为软件工程(software engineering)。2. 软件开发人员面临的问题： 软件开发时间长 软件开发成本居高不下 在软件交付给用户之前，我们无法找到所有的错误。 维护已有的程序花费高昂的时间和人力代价 软件开发和维护的过程难以度量。3. 软件的定义： 程序(program)：通过执行包含在程序中的指令可以满足预期的特征、功能和性能需求 数据结构(data structure)：使得程序充分利用信息。 文档(ducoment)：描述程序操作和使用。4. What is the difference between software and hardware? 软件是开发设计的，而不是生产制造的。 软件不会磨损(wear out)，但是会退化(deteriorate)。不断的变更是软件退化的根本原因。硬件会磨损，磨损的部分可以用备用的构件替换，而软件缺不存在备用构件。 虽然整个工业向着基于构件的构造模型发展，然而大多数的软件还是主要采用用户定制(custom buildt)的方式（Because off-the-shell software components are unavailable in many application domains）。在硬件设计中，构件复用是工程进程中通用的方法。而在软件设计中，大规模的复用还刚刚开始尝试。5. 软件的确定性（determinate）是指系统的输入、处理和输出的顺序及时间是可以预测的；软件的不确定性是指系统的输入、处理和输出的顺序及时间是无法提前预测的。6. 遗留软件(legacy software)旧的软件 生命周期长(longevity) 业务关键性(business criticality) 质量差(poor quality) 遗留软件发生系统演化的原因： 软件需要修改其适应性，从而可以满足新的计算环境或者技术的需求。 软件必须根据新的业务需求进行升级。 软件必须扩展以具有与更多现代系统和数据库协作的能力。 软件构架必须进行改建以适应多样化的网络环境。7. 软件演化（evolution） 变更(change)（通常称为软件维护）推动了软件演化，它通常是由以下情况引发的：程序纠错，调整软件以适应新的环境，满足用户新特性和功能的需求，以及对软件实施再工程以便在现代应用中发挥作用。8.软件危机 软件危机是指在计算机软件的开发和维护过程中遇到的一系列严重问题，如软件费用、软件可靠性、软件维护、软件生产、软件重用等。第二章过程综述1. 软件过程定义为一个建造高质量软件所需要完成的任务的框架（framework）。 软件生命周期：软件产品或软件系统从设计、投入使用到被淘汰的全过程。2. *软件工程的定义： 将系统化（systematic）、规范化（disciplined）、可量化（quantifiable）的方法应用于软件的开发、运行和维护，即将工程化方法应用于软件。 对中所述方法的研究。3. 软件工程是一种层次化的技术，软件工程层次图如下： 工具tools 方法 methods 过程 process 质量关注点 a quality focus软件工程的根基(bedrock)在于质量关注点。软件工程的基础(foundation)是过程层。软件过程将各个层次的技术结合在一起，并实施合理地、及时地开发计算机软件。并且过程定义一个框架。软件工程方法为建造软件提供技术上的解决方法，包括沟通、需求分析、设计建模、编程、测试和支持。软件工程工具：为过程和方法提供自动化或半自动化的支持。4. 过程框架定义了若干小的框架活动，为完整的软件开发建立了基础。 五个通用过程框架活动(generic process framework activity)：communication沟通planning策划modeling建模：包括分析（analysis）和设计（design）两个动作construction构建deployment部署 5. stakeholder（共利益者）就是可在项目成功中分享利益的人，包括业务经理、最终用户、软件工程师、支持人员等。6. 不同的项目需要不同的任务集(task set)，软件开发根据问题和项目的特点选择任务集。7. 软件工程的通用框架由很多普适性活动（umbrella activity）来实现，普适性活动贯穿于整个软件过程。(across/throughout the entire software process)尽管有很多种不同的软件工程过程模型，但它们都定义了：一组框架活动，完成每个活动所包含的任务集，任务完成所形成的工作产品，以及一组可以用于整个过程的普适性活动。8. 不同模型之间的区别： 活动和任务的总体流程，以及相互之间的关系 在框架中的每一个活动中任务细化的程度 对所需要提交的工作产品的定义 质量保证活动应用的方式 过程跟踪和控制活动应用的方式 过程描述的详细和严谨程度 客户和共享利益者对项目参与的深度 软件项目队伍所赋予的自主权 队伍组织和角色明确程度9. 能力成熟度模型（CMMI）能力成熟度模型集成，是一个过程元模型，定义了如何建立完整的软件过程，软件组织所应该具备的过程特征。分为不完全级、已执行级、已管理级、已定义级、已定量管理级、优化级。每个过程域的capability levels： 第0级：incomplete（不完全级） 第1级：performed(已执行级) 第2级：managed(已管理级) 第3级：defined(已定义级) 第4级：quantitatively managed(已定量管理级) 第5级：optimized(优化级)10. 软件过程可以定义为一系列模式（pattern）的组合，这些模式定义了一系列的软件开发中所需的活动、动作、工作任务、工作产品及相关的行为。 Pattern template provides a consistent means for describing a pattern。 11. formal techniques are available for assessing the software process： SCAMPI、CBI IPI、SPICE、ISO 9001 SCAMPI提供了五步的过程评估模型：启动（initiating）、诊断（diagnosing）、建立（establishing）、执行（acting）、学习（learning） SPICE和其他的标准定义了指导软件过程评估的要求，ISO对过程中的质量管理进行检查12. ISO 9001:2000采用“计划-实施-检查-行动”（plan-do-check-act）循环，将其应用于软件项目的质量管理环节。 A. 计划（plan）是为实现高质量的软件产品并最终提高用户满意度，建立必须的过程目标、活动和任务。 B. 实施是执行软件过程，包括框架活动和普适性活动。 C. 检查监督并测量过程，以保证所有为质量管理所建立的需求均已实现。 D. 行动启动软件过程改进活动，并持续地改进进程。 13. 个人过程模型PSP定义的五个框架活动：策划（planning）高层设计（high-level design）高层设计评审（high-level design review）开发（development）后验（postmortem）PSP强调对所犯的错误类型进行记录和分析，以便于制定避免错误的策略。14. 团队软件过程TSP定义的框架活动：项目启动（launch）高层设计（high-level design）实现（implementation）集成（integration）测试（test）后验（postmortem）个人和团队模型都强调了成功软件过程的关键因素：测量、计划、自我管理第3章 过程模型1. 惯例过程模型：惯例模型规定了一套过程元素框架活动、软件工程动作、任务、工作产品、质量保证以及每个项目的变更控制机制。每个过程还定义了工作流2. *瀑布模型waterfall model（经典生命周期classical life circle）、 是一种基于软件生存周期的线性（linear）开发模型。它提出了一个系统的、顺序（sequential）的软件开发方法，从用户需求规格说明开始，通过策划、建模、构件和部署的过程，最终提供一个完整的软件并提供持续的技术支持。 适用于需求定义清晰(requirements are fixed)且稳定的软件开发不足之处： 实际的项目很少遵守瀑布模型提出的顺序。 用户常难以清楚地描述所有的需求。 客户必须要有耐心，只有在项目接近尾声的时候，他们才能得到可执行的程序。3. *增量模型(incremental)：以迭代的方式运用瀑布模型，在每个阶段运用线性序列。这种模型把软件看作是一系列相互联系的增量，在开发过程的各次迭代中，每次完成其中的一个增量。 第一个增量是一个核心产品，每个增量都提交一个可以操作的产品。 如果在既定的商业要求之前不可能找到足够的开发人员，增量模型显得特别有用。4. RAD模型： 是一种侧重于短暂的开发周期的增量过程模型，为大型且必须在严格的时间内提交的项目而设计的。 是瀑布模型的高速变体，通过基于构件的构建方法实现快速开发。 是一种linear sequential model RAD的不足之处(drawbacks)： 对于大型的可伸缩项目，RAD需要大量的人力资源来创建多个相对独立的RAD团队。 如果没有为短时间内急速完成整个系统做好准备，RAD项目将会失败。 如果一个系统不能合理地模块化，RAD构建会有很多问题。 如果系统需求是高性能，不能采用RAD模型。 技术风险很高的时候，不宜采用RAD。演化过程模型(evolutionary process model)每次迭代产生软件的一个更完整的版本。5. 原型开发(prototyping)：用于需求很模糊的时候(requirements are fuzzy，cant define requirement clearly) *原型模型的思想是：先建立一个能够放映用户主要需求的原型，让用户实际看一下未来系统的面貌，以便判断哪些功能是符合需要的，哪些方面还需要改进，然后将原型反复改进，直至建立完全符合用户要求的新系统。6. 螺旋模型(spiral) 结合了原型的迭代（iterative）特性、瀑布模型的系统性（systematic）和可控性（controlled）特点。采用循环的方式逐步加深系统定义和实现的深度。 其他过程模型在软件交付之后就结束了，螺旋模型则不同，它应用在计算机软件的整个生命周期，从概念开发到维护。 把原型开发作为降低风险的机制，它依赖大量的风险评估专家来保证成功。If a major risk is not uncovered and managed ，problems will undoubtedly occur。7. 协同开发模型：适合于不同的工程团队开发的系统工程项目。8. 专用过程模型：应用较窄，只适合于某些特定的软件工程方法。 基于构件的开发：本质上是演化模型，需要以迭代方式构建软件。the process to apply when reuse is development objective。 形式化方法模型：主要活动是生成计算机软件形式化的数学规格说明，意义在于提供无缺陷的软件。 面向方面的软件开发(AOSD)：以用户跨越多个系统功能、特性和信息为关注点。9. 统一过程（UP）是一种增量模型，determined iterativelly，span more than one of the process。定义了五个阶段（phase）： 起始（inception）：包括客户沟通和策划活动，强调定义和细化用例，并将其作为主要模型 细化（elaboration）：包括用户沟通和建模活动，重点是创建分析和设计模型，强调类的定义和体系结构的表示 构建（construction）：细化设计模型，并将设计模型转化为软件构件实现 转换（translation）：将软件从开发人员传递给最终用户，并由用户完成Beta测试和验收测试 生产（production）：持续地监控软件的运行，并提供技术支持第4章 敏捷开发（agile process）1. 软件敏捷开发宣言（Manifesto） 个体和交互胜过过程和工具 可工作软件胜过宽泛的文档 用户合作胜过合同谈判 响应变化胜过遵循计划普遍存在的变化是敏捷的基本动力。所有敏捷方法都或多或少的遵循以上的原则。2. Agility is more than an effective response to change。 effective communication among stakeholders drawing the custom onto the team organizing a team so that its control of the work performedAgile alliance 的12条准则中，第一条是最优先要做的是通过尽早、持续交付valuable software来满足用户的要求敏捷可用于任何软件过程，实现要点是将软件过程设计为如下方式：允许项目团队调整并合理安排任务理解敏捷开发方法的易变性并制定计划精简并维持最基本的工作产品强调增量交付策略 3. 敏捷过程的三个假设（Assumption）： 提前预测哪些需求是稳定的和哪些需求会变化非常困难。 对许多软件来说，设计和构建是交错进行的。事实上，两种活动应顺序开展（tandem）以保证通过构建实施来验证设计模型，而在通过构建验证之前很难估计到应当设计到什么程度。 从制定计划的角度来看，设计、分析、构建和测试并不像我们所设想的那么容易预测。 以上说明敏捷过程必须具有自适应性（adaptable）。4. 软件开发团队及成员应具有的特点： competence common focus collaboration decision-making ability fuzzy problem-sloving ability mutual trust and respect self-organization 5. 极限编程XP XP使用面向对象方法作为推荐的开发范型 XP的四个框架活动：planning、design、coding、testing（计划、设计、编码和测试） Planning始于建立一系列描述待开发软件必要特征与功能的故事（story or user story）。项目速度是第一个发行版本中实现的用户故事个数。 XP design遵循kis原则（Keep-it-simple）；鼓励使用CRC作为有效机制；如果在某个故事设计中碰到困难，实现并评估原型；XP估计既是构建技术又是设计中的重构。 XP coding中的关键概念之一是结对编程（pair programming）。 在编码之前建立单元测试是XP方法的关键因素，XP验收测试（也称用户测试），由客户确定，根据用户故事得到的。6. 重构（ ）：是以不改变代码外部行为而进行改进其内部结构的方式来修改软件系统的过程。简而言之，重构是在编码完成之后改进代码设计。7. 自适应软件开发（ASD）强调human collaboration和team self-organization。 ASD的三个阶段：speculation（思考）collaboration learning8. 动态系统开发方法（DSDM） DSDM建议使用修改版Pareto原则。在这种情况下，如果交付整个应用系统需用100%时间，那么80%的应用系统可以用20%的时间交付。 像XP和ASD一样，DSDM建议使用迭代软件过程。9. Scrum（橄榄球） 每一个框架活动中，发生于一个过程模式中的工作任务称为一个冲刺。 每一个过程模式定义的一系列问题：待定项（backlog）、冲刺（sprint） 十五分钟例会回答的基本问题：A.上次例会之后做了什么B.遇到什么困难C.下次例会之前做些什么10. Crystal提倡一种机动性的软件开发方法。11. 特征驱动开发（FDD） 特征是可以在两周或更短的时间实现的具有客户价值的功能。 FDD更强调项目管理原则和技术。12. 敏捷建模（AM）认为对所有的系统都是有必要的。AM给实践者(practitioner)的分析和任务设计以非常有用的指导。13. 敏捷理念强调的四个关键问题： 具有控制力的自我组织团队对所开展工作的重要性 团队成员之间、开发参与者与客户之间的交流与合作 对变更代表机遇的认识 强调快速软件交付让客户满意第五章软件工程实践综述1. 软件工程实践的精髓： 理解问题（交流和分析） 计划解决方案（建模和软件设计） 实施计划（代码生成） 检查结果的精确度（测试和质量保证）2. David hooker提出的关注软件工程整体实践的核心原则： 存在价值 保持简洁 维护视图 生产者要让消费者理解 面向未来 计划复用 认真思考 3. 原则开发一个实际项目计划所必须提出和回答的问题是： 为什么要开发 要做什么东西 什么时候完成 功能由谁负责 组织位于哪里 怎样才能在工作中体现技术和管理 需要多少资源4. 在软件工程中，需要建立两类模型：分析建模（analysis ）和设计建模（design），建模的目的是加深对所要完成的工作的理解并为开发人员提供技术指导。 分析模型通过三个不同域描述来表达用户的需求：the information domain（信息域）、the functional domain（功能域）、the behavioral domain（行为域） 设计模型可以帮助开发者高效开发软件的特征：the architecture（构架）、the user interface（用户界面）、component-level detail（构件细节）5. 构造活动包括一系列编码和测试任务 最初的测试是构件级的，称为单元测试（unit test） 集成测试（integration test）在构建系统的时候进行 确认测试（validation test）是测试系统是否完全按照需求开发 验收测试（acceptance test）由用户检验系统是否按照需求实现了所有的功能6. 测试规则： 测试是一个以查找程序错误为目的的程序执行过程 一个好的测试（good test）用例能最大限度地找到尚未发现的错误 一个成功的测试（successful test）能找到那些尚未发现的错误7. 部署活动包括三个动作：交付（delivery）、支持（support）和反馈（feedback） 部署活动并不只是发生一次，而是在软件完全开发完成之前要进行许多次。8.叙述软件构造和软件部署的区别软件构建包括编码和测试，是在开发阶段由开发人员来完成；软件部署是将所完成的部分交付给客户，由客户对其进行评测和反馈意见，此时开发人员提供技术支持和维护。第6章 系统工程（System engineering）1. 计算机的系统：组织在一起通过处理信息来实现预定目标的要素集合或排列。2. 系统要素（system element）： software（软件） hardware（硬件） people（人员） database（数据库） documentation（文档） procedure（规程）宏要素是指基于计算机系统，它作为更大的基于计算机的系统的一部分。3. the system hierarchy：world viewdomain viewelement viewdetailed view4. 建立模型工程师要考虑的restraining factor： Assumption simplification limitation construction preferences5.业务过程工程（BPE） The goal of business process engineering is to define architectures that will enable a business to use information effectively。 BPE定义和开发的三种架构：data architecture、application architecture、technology architecture 业务过程工程层次：信息战略计划业务区域分析业务系统设计构建和集成 6. 产品工程 the goal of product engineering is to translate the customers desire for a set of defined capabilities into working product。（定义一个能有效利用信息进行业务活动的体系） 产品工程是从系统分析开始的系统工程，软件工程师确定用户需求。 产品工程给出构架的不同系统构件：software、hardware、database、people 产品工程层次图：需求工程构件工程分析和设计建模构建和集成7. 系统建模：每个基于计算机的系统都可按“输入-处理-输出”模板进行信息转换。8. Hatley-Pirbhai建模模板： user interface input system function and control output maintenance and self-test系统环境图a system context diagram（SCD）resides at the top level of the hierarchy。 9. Unified Modeling Language (UML) *统一建模语言，对软件进行可视化、规约、构造、文档化的一种语言。UML大量的图表表示法，用于在系统和软件层次分析和设计。涉及到的图： Deployment diagram（硬件）、activity diagram（软件）、class diagram（软件）、use-case diagram 第7章 需求工程（requirement engineering）1. RE is a software engineering action that can begins during the communication activity and continues into the modeling activity。是design和construction的桥梁。 目的：在设计和构造之间建立起联系的桥梁 任务：启始、导出、精化、协商、规格说明、确认和管理2. 需求工程通过执行7个不同的活动来完成： Inception（起始） A.establish basic problem requirements B.define overriding project constrains C.address major features and functions Elicitation （导出）：elicit requirements from all stakeholders ，在此阶段利用facilitate meetings、QFD、the development of user scenarios 来进行需求收集活动。 需求导出困难的原因： A. problem of scope B. problems of understanding C. problems of volatility（易变性） elaboration（细化）：create an analysis model that identifies data 、function and behavioral requirement。 negotiation（谈判）：agree on a deliverable system that is realistic for customer and developer specification（规格说明）：is the final work product produced by the requirement engineering，描述了一个基于计算机系统的功能和性能，以及那些将影响开发系统的约束。 规格说明的形式和格式随着待开发的规模和复杂度的不同而变化。 validation（确认）：检查规格查找内容或解释上的错误，以及可能进一步需要解释澄清的地方、丢失的信息，不一致性（consistency是重点）、冲突的需求或不显示的需求。以保证所有系统需求已被无歧义地说明。 management(管理)：需求管理是用于帮助项目组进展中标识、控制和跟踪需求以及变更需求的一组活动。3. 项目初始时的提问应该是context-free（与环境无关的）。The first set of context-free questions focuses on the customer and other stakeholder,overall goals,and benefits。需求工程师可能会问： who is behind the request for this work？ who will use the solution？ what will be economic benefit of a successful solution？ is there another source for the solution that you need？4. 质量功能部署（QFD）是一种将用户要求转化成软件技术需求的技术，QFD以最大限度地满足客户的方式来定义需求，贯穿于整个软件工程。QFD确认了三类需求： Normal requirement Expected requirement Exciting requirementQFD的三种deploymentfunction deploymentinformation deploymenttask deployment5. The scenarios，often call use-case，provide a description of how the system will be used。6. *Use-case：产生了一个参与者与系统的交互。从参与者的角度定义用例，用例从最后用户的角度描述了软件或系统。参与者（Actor）是人员或设备在和软件交互时所扮演的角色。Stakeholder可以访问每个用例而且可 以指定每个用例的相对优先级。 写一个完整的use-case：文字图 （P161）7. 精化阶段进一步把需求扩展为分析模型（analysis model） the intent of analysis model is to provide a description of the required information、functional、and behavioral domains for a computer-based system. Analysis model中用到的UMLdiagram：activity diagram（活动图）： 描述某个受限环境中处理过程的活动序列class diagram（类图）：列出传感器的属性和可以用于修改这些属性的操作uml state diagram （状态图）：一种表现系统行为的方法，该方法描绘系统状态以及导致系统改变状态的事件use-case diagram（用例图）：从用户的视角描述系统8.The best negotiation strive for a win-win (双赢)result。That is，the customer wins by getting the system or product that satisfies the majority of the customers needs（获得满足大多数需求的系统或产品），and the software team wins by working to realistic and achievable budgets and deadlines（按照实际情况，在可实现的预算和时间期限内完成工作）。 第八章创建分析模型1. Requirements analysis results in the specification of softwares operational characteristics indicates softwares interface with other system elements establish constrains that software must meet 2. 需求分析向软件设计者提供信息（information）、功能（function）和行为（behavior）的表示，这些表示可以被转化为结构（architectural）、接口（interface）和构件级（component-level）的设计3. 软件完成之后，analysis model和requirements specification 提供了a means for assessing quality。4. 分析模型是系统描述和系统设计模型之间的桥梁分析模型的三个主要目标（objective）：描述客户需要什么为软件设计奠定基础定义在软件完成后可以被确认的一组需求5. 域分析(domain analysis）是识别分析和详尽说明来自某个特定应用领域的公共需求（common requirements），特别是那些在应用领域内被多个项目重复使用的。6. 两种analysis model的approach结构化分析（structure analysis）：是一种考虑数据和处理的分析建模方法，数据作为独立的实体转换。数据对象建模定义了对象的属性和关系，操作数据对象的处理建模应表明当数据对象在系统内流动时处理如何转换数据。面向对象分析（objected-oriented analysis）：就是检查定义为一组用例的问题域，尽量提取定义问题的类。关注于定义类和影响客户需求的类之间的协作方式。UML和统一过程主要是面对对象的。7. Analysis modeling begin with data modeling（数据建模）data objects(数据对象)： A. 数据对象是任何必须被软件理解的复合信息的表示 B. 数据对象只（only）封装数据，在数据对象内没有任何对数据操作的引用。data attribute（数据属性）定义了数据对象的性质，可以用来： A. 为数据对象的实例（instance）命名 B. 描述这个实例（instance） C. 建立对另一个表中的另一个实例的引用relationship（关系）指明数据对象相互连接的方式Cardinality（基数）描述了一个对象的出现次数与另一个对象出现次数的关联，有三种 A. 1：1 B. 1：n C. m：n Modality（形态）A. 没有明确的必要性或关系是可选的，那么关系的形态是0 B如果关系必须出现一次，则形态是1ERD的三个元素：attributes、object、relationship。ERD主要目的是represent data objects and their relationships。8. 面对对象（object-oriented）分析 attributes ：a collection of data values that describe a class class：encapsulate the data and procedural abstraction required to describe the behaviour of some real word entity。 object：instance of a specific class。Objects inherit a classs attributes and operations。 operations：are objects procedures thatre invoke when an object receives a message。9. Scenario-based modeling analysis modeling with UML begins with the creation of scenarios in the form of use-case、activity diagram and swimlane diagrams。 use-case的概念：describe a specific usage scenario in straightforward language from the point of view of a defined actor。 一个UML activity diagram表现了实施某个功能时发生的活动和判定。 一个UML swimlane diagram表现了活动流和一些判定，并指明由哪个参与者实施。10. Flow-oriented modeling 数据流图DFD采取系统的输入-处理-输出观点，流入软件的数据对象，经过处理元素转换，最后以结果数据对象的形式流出软件。数据或控制对象（带标记的箭头label arrow），转换（圆圈bubble），外部实体（方框boxes） 第一个数据流模型从整体上表现系统，随后的数据流图改进环境图，提供每个后续层增加的细节。 Data flow modeling is a core modeling activity in structure analysis。 control flow model用到的地方：A. 一大类应用问题是事件驱动（driven by events）B. 这类问题产生控制信息（control information）C. 处理信息非常关注时间和性能11. Class-based model operation的大概分类（broad category）：A. Manipulate dataB. Perform a manipulationC.inquire about the sate of an objectD.monitor an object for the occurrence of a controlling event CRC(类、职责、协作者)可以用于定义类之间的联系，有三个部分：A.classB.responsibilityC.collaborator A package(分析包) involves the categorization of analysis model elements into useful groupings. A packet is used to assemble a collection of related classes。 如果某个类实现一个解决方案，那么这个类就是解决方案的一部分；如果某个类只需要说明一个解决方案，那么这个类就是问题空间的一部分。12. Behavioral model 系统状态可以表现特定的外部可观察（externally observable）行为。 类的状态可以表现当系统执行功能时的行为。13. 解释在面向对象系统中重要的特征： 封装（encapsulation）： 继承（inheritance）： 多态（polymorphism）：14. 类之间三种不同的通用联系： is-part-of（是的一部分） has-knowledge-of（有的知识） depends-upon（依赖）第9章 设计工程（design engineering）1. 四种设计： data/class design architectural design interface design component design2. 评价良好设计演化的三个特征： 设计必须实现所有包含在分析模型中的明确需求 对于代码生成人员、测试维护人员，设计必须是可读的、可理解的指南 设计必须提供软件的全貌，从实现的角度说明数据域、功能域和行为域3. 五个质量属性quality attributes（FURPS）功能性、易用性、可靠性、性能、可支持性 functionality usability reliability performance supportalility4. 集成成本与模块数成正比，工作量与模块数成反比 5. *信息隐藏（Information Hiding）：这是把系统分解为模块时的思想，即模块内部的数据与过程，应该对不需要了解这些数据与过程的模块隐藏起来。只有为了完成软件的总体功能而必须在模块间交换的信息，才允许在模块间进行传递。模块应该详细说明且精心设计以求在某个模块中包含的信息（算法和数据）不被不需要这些信息的其他模块访问。6. 内聚与耦合 cohesion：is a qualitative indication of the degree to which a module focus on just one thing。显示了某个模块相关功能的强度，a cohesion module should just do one thing。 The higher the level cohesion，the easier the component is to implement，test，and maintain。 coupling：is a qualitative indication of the degree to which a module is connected to other modules and to the outside world。显示了模块间的相互依赖性。 应当尽量高内聚、低耦合7. 组织良好的设计类的四个特征： 完整性与充分性 原始性 高内聚性 低耦合性8. data design creates a module and/or information that is represented at a high level of abstraction(the customer/users view of data)9. The architectural design for software is the equivalent to the floor plan （平面图）of the house。 10. The interface design for software is the equivalent to a set of detailed drawings for the doors、windows、and external utilities of a house。11. The component-level design for software is equivalent to a set