自考软件工程及应用02333备考资料王立福版.docx

自考软件工程及应用02333备考资料王立福版.docx

《自考软件工程及应用02333备考资料王立福版.docx》由会员分享，可在线阅读，更多相关《自考软件工程及应用02333备考资料王立福版.docx（29页珍藏版）》请在冰豆网上搜索。

自考软件工程及应用02333备考资料王立福版

第一章绪论（知识点摘要）

（1）软件工程：

软件工程是应用计算机科学理论和技术以及工程管理原则和方法，按预算和进度实现满足用户要求的软件产品的工程，或以此为研究对象的学科。

P15

（2）软件危机：

软件生产率、软件质量远远满足不了社会发展的需求，成为社会，经济发展的制约因素，人们通常把这一现象称为“软件危机”。

（3）软件工程发展的两个时期：

1、主要围绕软件项目、开展了有关开发模型、开发方法和支持工具的研究。

2、围绕对软件工程过程的支持，开展了一系列有关软件生产技术，特别是软件复用技术和软件生产管理的研究与实践。

（4）计算机软件：

一般是指计算机系统中的程序及其文档。

程序是计算机任务的处理对象和处理规则的描述；文档是为了理解程序所需的阐述性资料。

（5）软件开发的本质：

软件开发的本质就是实现问题空间的概念和处理逻辑到解空间的概念和处理逻辑之间的映射。

（6）软件开发涉及两个方面的问题：

一是如何实现这样的映射（技术）；二是如何管理这样的映射（管理）。

（7）简述软件开发所涉及的两大类技术：

一是求解软件的开发逻辑，二是求解软件的开发手段。

（8）简述实施软件开发的基本途径：

是系统建模。

所谓系统建模，是指运用所掌握的知识，通过抽象，给出该系统的一个结构——系统模型。

（9）简述何谓模型以及软件开发中所涉及的模型：

模型是一个抽象。

该抽象是在意图所确定的角度和抽象层次对物理系统的一个描述，描述其中的成分和成分之间所具有的特定语义的关系，还包括对该系统边界的描述。

软件开发中所涉及的模型可分为两大类，一类称为概念模型，描述了系统是什么；另一类统称为软件模型，描述了实现概念模型的软件解决方案。

（10）软件开发中所涉及的模型可分为两大类：

一类称为概念模型，另一类统称为软件模型，软件模型又包括设计模型、实现模型和部署模型等。

（11）软件工程需要解决的问题：

软件的费用，可靠性，可维护性，软件生产率和软件的重用。

（12）软件工程的目标：

付出较低开发成本；达到要求的功能；取得较好的性能；开发的软件易于移植；只需较低的维护费用；能按时完成开发任务，及时交付使用；开发的软件可靠性高。

第二章软件需求与软件需求规约

（1）软件需求：

以一种技术形式，描述了一个产品/系统应该具有的功能、性能和其它性质。

（2）软件需求的性质：

1、必要的，该需求是用户所要求的。

2、无歧义的，该需求只能用一种方式解释。

3、可测的，该需求是可进行测试的。

4、可跟踪的，该需求可从一个开发阶段跟踪到另一个阶段。

5、可测量的，该需求是可测量的。

（3）需求的分类：

两大类：

一类是功能需求，一类是非功能需求，而非功能需求可分为性能需求，外部接口需求、设计约束和质量属性需求。

（4）功能需求：

规约了系统或系统构件必须执行的功能。

（5）非功能需求：

是性能、外部接口、设计约束和质量属性这4类需求的统称。

（6）功能需求和非功能需求之间的基本关系：

功能需求是整个需求的主体，即没有功能需求，就没有派生的其他功能需求，就没有性能、外部接口、设计约束和质量属性等非功能性需求。

一个非功能需求可作用于一个或多个功能需求。

（7）非功能需求：

性能需求、外部接口需求（如用户接口、硬件接口、软件接口、通信接口、内存约束、运行和地点需求）、设计约束（如法规政策、硬件限制、与其他应用的接口、并发操作、审计功能、控制功能、高级语言需求、握手协议）和质量属性（可靠性、存活性、可维护性和用户友好性）这4类需求。

（8）需求发现技术：

自悟、交谈、观察、小组会和提炼。

（9）需求规约是一个软件项目/产品/系统所有需求陈述的正式文档，它表达了一个软件产品/系统的概念模型。

（10）需求规约的基本性质：

1、重要性和稳定性程度：

按需求的重要性和稳定性，对需求进行分级。

2、可修改的：

在不过多地影响其他需求的前提下，可以容易地修改一个单一需求。

3、完整的：

没有被遗漏的需求。

4、一致的：

不存在互斥的需求。

（11）简述需求规约的3种基本形式：

1、非形式化的需求规约。

非形式化的需求规约即以一种自然语言来表达需求规约，如同使用一种自然语言写了一篇文章。

2、半形式化的需求规约。

半形式化的需求规约即以半形式化符号体系（包括术语表、标准化的表达格式等）来表达需求规约。

3、形式化的需求规约。

形式化的需求规约即以一种基于良构数学概念的符号体系来编制需求规约，一般往往伴有解释性注释的支持。

（12）软件需求规约的作用：

1、需求规约是软件开发组织和用户之间一份事实上的技术合同书，是产品功能及其环境的体现。

2、对于项目的其余大多数工作，需求规约是一个管理控制点。

3、对于产品/系统的设计，需求规约是一个正式的、受控的起始点。

4、需求规约是创建产品验收测试计划和用户指南的基础，即基于需求规约一般还会产生另外两个文档---初始测试计划和用户系统操作描述。

（13）简述需求规约和项目需求的不同：

需求规约和项目需求是两个不同的概念。

需求规约是软件开发组织和用户之间一份事实上的技术合同书，即关注产品需求，回答“交付给客户的产品/系统是什么”；而项目需求是客户和开发者之间有关技术合同——产品/系统需求的理解，应记录在工作陈述中或其他某一项目文档中，即关注项目工作与管理，回答“开发组要做的是什么”。

第三章结构化方法

（1）需求分析工作面临的三大挑战：

1、问题空间理解；2、人与人这间的通信；3、需求的变化性。

（2）一种好的需求技术就具有以下基本特征：

1、提供方便的通信的机制；2、鼓励需求分析人员使用问题空间的术语思考问题，编写文档；3、提供定义系统边界的方法；4、提供支持抽象的基本机制；5、为需求分析人员提供多种可供选择的方案；6、提供特定的技术，适应需求的变化。

（3）任何一种软件分析方法包括：

1、要给出一些基本术语，支持表达分析中所需要使用的信息；2、要给出表达系统模型的工具，支持表达系统功能；3、给出过程指导，支持如何系统化地使用相关信息来建造系统模型。

（4）结构化方法基本术语：

数据流、加工、数据存储、数据源和数据潭。

（5）数据流图：

表达功能模型的工具，即数据流图（DataflowDiagram）简称DFD图，简单的说，DFD图是一种描述数据变换的图形化工具，其中包括的元素可以是数据流、数据存储、加工、数据源和数据潭等。

（6）结构化方法的建模过程：

1、建立系统环境图，确定系统语境，一般为系统的顶层数据流图；2、自顶向下，逐步求精，建立系统的层次数据流图；3、定义数据字典，用于表达系统中的数据结构；4、描述加工，用于表达每个加工输入和输出之间的逻辑关系；5、需求验证。

（7）父DFD图生成子DFD图的步骤：

1、将“父图”的每一加工按其功能分解为若干个子加工；2、将“父图”的输入流和输出流分派到相关的子加工；3、在各个加工之间建立合理的关联，必要是引入数据存储，使之形成一个有机的整体。

（8）数据字典（DD）：

用来定义数据库流图中的各个成分的具体含义。

有以下三类条目：

数据流条目，数据项条目，数据存储条目。

（9）数据字典中定义数据结构的符号：

1、“=”表定义为；2、“+”表顺序；3、[|]表选择；4、{}表重复；5、m..n表子界。

（10）描述加工的工具：

1、结构化自然语言；2、判定表；3判定树。

[这一部分的内容请参照后面的相关习题]

（11）结构化分析方法总结：

（12）需求阶段的主要任务：

是完整地定义问题，确定系统的功能和能力。

为此，该阶段的主要任务一般包括需求发现、需求分析和需求验证，最终形成系统的软件需求规格说明书。

（13）需求验证：

应验证需求规格说明书中的每一单一需求是否满足5个性质，即必要性、无歧义性、可测性、可跟踪性、可测量性；验证需求规格说明书是否满足4个性质，即重要性和稳定程序、可修改性、完整性和一致性。

（14）结构化设计的主要任务：

在需求分析的基础上，定义满足需求所需要的软件结构，即针对给定的问题，给出该项问题的软件解决方案，研究“怎么做”的问题。

（15）结构化设计分为：

总体设计和详细设计。

（16）总体设计阶段的基本任务：

是把系统的功能需求分配到一个特定的软件体系结构中，即把需求分析所得到的系统DFD图映射为设计层面上的模块和模块调用。

（17）总体设计引入的两个基本概念：

1、模块，即指软件中具有特定标识的独立成分，即执行一个特殊任务的一个过程以及相关的数据结构，包括接口和模块体两部分；2、模块调用，即指模块之间的一种使用关系。

（18）软件体系结构图主要有三种：

1、模块结构图（MSD图）；2、层次图；3、HIPO图。

（19）HIPO图是由H图和IPO图两部分组成，H图就是层次图，IPO即为模块的输入/处理/输出。

（20）总体设计的步骤：

1、初始设计：

首先将系统的DFD图转化为初始的模块结构图；2、精华设计：

基于“高内聚低耦合”的原则，通过模块化，将初始的模块结构图转化为最终的、可供详细设计使用的模块结构图（MSD）；3、复审阶段：

对MSD图进行复审。

（21）数据流图分为：

变换型数据流图和事务型数据流图。

（22）变换型数据流图：

具有较明显的输入部分和变换（主加工）部分之间的界面变换部分和输出部分之间界面的数据流图。

（23）事务型数据流图：

数据到达一个加工T，该加工T根据输入数据的值，在其后的若干动作序列中选出一个来执行。

（24）变换设计的步骤：

1、设计准备—复审并精化系统模型；2、确定输入、变换、输出这三部分之间的边界；3、第一级分解—系统模块结构图顶层和第一层的设计；4、第二级分解---自顶向下，逐步求精。

（25）变换型数据流图对应的软件结构包括：

1、主控模块；2、输入模块部分；3、变换模块部分；4、输出模块部分。

（26）事务设计的步骤：

1、设计准备—复审并精化系统模型；2、确定事务处理中心；3、第一级分解—系统模块结构图顶层和第一层的设计；4、第二级分解---自顶向下，逐步求精。

（27）模块耦合：

是不同模块之间相互依赖程序的度量。

（28）模块耦合的类型：

1、内容耦合：

当一个模块直接修改或操作另一个模块的数据，或一个模块不通过正常入口而转入到另一个模块时；2、公共耦合：

两个或两个以上的模块共同引用一个全局数据项；3、控制耦合一个模块通过接口向另一个模块传递一个控制信息，接收信号的模块根据信号值进行适当的动作；4、标记耦合：

若一个模块A通过接口向两个模块B和C传递一个公共参数；5、数据耦合：

模块之间通过参数来传递数据。

（29）模块内聚：

指一个模块内部各成分之间相互关联程度的度量。

（30）模块内聚的类型：

1、偶然内聚：

一个模块的各成分之间基本不存在任何关系；2、逻辑内聚：

几个逻辑上相关的功能被放在同一个模块中；3、时间内聚：

一个模块完成的功能必须在同一时间内执行，但这些功能只是因为时间因素关联在一起；4、过程内聚：

一个模块内部的处理成分是相关的，而且这些处理必须以特定的次序执行；5、通信内聚：

一个模块的所有成分都操作同一数据集或生成同一数据集；6、顺序内聚：

一个模块的各个成分和同一个功能密切相关，而且一个成分的输出作为另一个成分的输入；7、功能内聚：

最理想的内聚，模块的所有成分对于完成单一的功能都是基本的。

（31）启发式规则：

1、改进软件结构，提高模块独立性；2、力求模块结构适中；3、力求深度、宽度、扇出和扇入适中；4、尽力使模块的作用域在其控制域之内。

5、尽力降低模块接口的复杂程序；6、力求模块功能可以预测。

（32）控制域：

模块本身以及所有直接或间接从属于它的模块的集合。

作用域：

受该模块内的一个判定所影响的所有模块的影响。

（33）详细设计：

具体描述模块结构图中的每一模块，即给出实现模块功能的实施机制，包括一组例程和数据结构，从而精确地定义了满足需求所规约的结构。

（34）详细设计工具：

1、程序流程图；2、盒图（N-S图）；3、PAD图。

（35）程序流程图的主要缺点：

1、不是一种逐步求精的工具；2、所表达的控制流，往往不受任何约束可随意转移，从而会影响甚至破坏好的系统结构；3、不易表达数据结构。

（35）自顶向下、逐步求精方法的优点：

1、自顶向下、逐步求精方法符合人们解决复杂问题的普遍规律，可提高软件开发的成功率和生产率；2、用先全局后局部、先整体后细节、先抽象后具体的逐步求精的过程开发出来的程序具有清晰的层次结构；3、程序自顶向下，逐步细化，分解成树形结构；4、程序清晰和模块化，使得在修改和重新设计一个软件时，可复用的代码最大；5、程序的逻辑结构清晰，有利于程序正确性证明；6、每一步工作仅在上层结点的基础上做不多的设计扩展，便于检查；7、有利于设计的分工和组织工作。

（36）N—S图有以下几个特点：

1、图中每个矩形框都是明确定义了的功能域，以图形表示，清晰可见；2、它的控制转移不能任意规定，必须遵守结构化程序设计的要求；3、很容易确定局部数据和全局数据作用域；4、很容易表现嵌套关系。

第四章面向对象方法UML

（1）UML是一种可视化的语言，可用于规约系统的制品，构造系统的制品、建立系统制品的文档。

这意味着UML可作为软件需求规约、设计和实现的工具。

（2）UML表达事件的术语：

类与对象，接口，协作，用况，主动类，构件，制品和结点。

（3）UML表达关系的术语：

关联、泛化、实现和依赖。

（4）类：

是一组具有相同属性、操作、关系和语义的对象的描述，包括一组属性的操作。

（5）类在建模中的用途：

1、模型化问题域中的概念；2、建立系统的职责分布模型；3、模型化建模中使用的基本类型。

（6）接口：

是操作的一个集合，其中每个操作描述了类、构件或子系统的一个服务。

（7）在建立模型中，接口对系统模型化应注意的问题：

1、接口只可以被其他类目使用，而本身不能访问其他类目；2、接口描述类的外部可见操作，通常是该类的一个特定有限行为；3、接口不描述其中操作的实现，也没有属性和状态；4、接口之间没有关联、泛化、实现和依赖。

（8）协作，是一个交互，涉及交互的三要素：

交互各方、交互方式、交互方式以及交互内容。

（9）用况：

是对一组动作序列的描述，系统执行这些动作应产生对特定参与者有值的、可观察的结果。

（10）主动类：

是一种至少具有一个进程或线程的类。

（11）构件：

是系统设计中的一种模块化部件，通过外部接口隐藏了它的内部实现。

（12）制品：

是系统中包含物理信息的，可代替的物理部件。

（13）结点：

是在运行那个时存在的物理元素，通常表示一种具有记忆能力和处理能力的计算机资源。

（14）关联：

是对一组具有相同结构、相同链的描述。

（15）为了表达关联的语义，UML采用以下途径：

1、关联名2、导航3、角色4、可见性5、多重性6、限定符7、聚合8、组合9、关联类10、约束。

（16）泛化：

是一般性类目和它的较为特殊性类目之间的一种关系，有事称为“is-a-kind-of”关系。

（17）进一步表达泛化的语义，UML给出4个约束：

1、完整2、不完整3、互斥4、重叠。

（18）细化：

是类目之间的语义联系，其中一个类目规约了保证另一个类目执行的契约。

（19）依赖：

是一种使用关系，用于描述一个类目使用另一类目的信息和服务。

（20）UML图形化工具分两类：

1、结构图，用于表达系统或系统成分的静态结构模型，给出系统或系统成分的一些说明性信息；2、行为图，用于表达系统或系统成分的动态结构模型，给出系统或系统成分的一些行为信息。

（21）软件开发中4中建模工具：

类图、用况图、状态图、顺序图。

（22）类图：

是可视化地表达系统静态结构模型的工具，通常包含类、接口、关联、泛化和依赖关系等。

（23）用况图：

对行为进行抽象，给出行为结构，给出系统的动态性描述。

包括6个模型元素：

主题、用况、参与者、关联、泛化、依赖。

（24）状态图：

是现实一个状态机的图，其中强调了从一个状态到另一个状态的控制流。

UML把状态分3类：

初态、终态和通常状态。

（25）状态图包含的内容：

（1）状态：

名字，进入/退出效应，do动作或活动，被延迟事件

（2）事件：

信号事件，调用事件，时间事件，变化事件（3）状态转移：

源状态、转移触发器、监护条件、效应、目标状态。

（26）顺序图：

是一种交互图，由一组对象以及按时序组织的对象之间的关系组成，其中还包含这些对象之间所发送的消息。

（27）顺序图的构成：

（1）消息

（2）对象生命线（3）聚焦控制。

控制操作子：

选择执行操作子，条件执行操作子，并发执行操作子，迭代执行操作子。

（28）结构良好的类的条件：

（1）明确抽象了问题域或解域中某个有型事物或概念

（2）包含了一个小的、明确定义的职责集，并能很好的实现（3）清晰的分离了抽象和现实。

（29）组合：

如果在一个时间段内，整体类的实例中至少包含一个部分类的实例，并且该整体类的实例负责创建和消除部分类的实例，特别是整体类的实例和部分类的实例具有相同的生命周期。

（30）聚合：

一个类目是另一个类目的一部分，但整体与部分具有不同的生命用期，表达的是一种“整体/部分”的关系。

（31）包：

UML提供的组织信息的一种通用机制，目的是为了控制信息的复杂性。

包之间存在两种关系：

引入和访问。

（32）认识行为的有效算途径：

1、从功能的视角；2、从交互的视角；3、从生存周期的视角。

在UML中用况图支持系统功能的建模，交互图支持系统交互的建模，状态图支持系统生存周期的建模。

（33）用况之间的3种关系：

泛化，扩展和包含。

（34）状态图的作用：

1、创建一个系统的动态模型，包括有各种类型对象、各种系统结构的以事件为序的行为；2、创建一个场景的模型，其主要途径是为用况给出相应的状态图。

（35）状态机：

是一种行为，规约了一个对象在其中生存期间因响应时间并作出响应而经历的状态。

（36）作为一种软件开发方法学，为了支持软件开发活动，至少包括3个方面的内容：

一是给出定义不同抽象层的术语；二是应给出各抽象层的模型表达工具；三是应给出如何把各层模型映射为下一个抽象层的模型，即过程指导。

UML仅包括前两方面的内容，因此，UML是一个可视化的建模语言，而不是一种特定的软件开发方法学。

RUP给出的是一种过程指导，与UML一起才称得上是一种软件开发方法学。

第五章面向对象方法RUP

（1）RUP：

是基于UML的一种过程框架，为软件开发，即为进行不同抽象层之间“映射”安排其开发活动的次序，指定任务和需要开发的制品，提供了指导；并为对项目中的制品和活动进行监控与度量，提供了相应的准则。

（2）RUP的特点：

以用况驱动；以体系结构为中心；迭代、增量式开发。

（3）RUP规定的4个开发阶段：

初始阶段；精化阶段；构造阶段；移交阶段。

（4）简述RUP的4个开发阶段的基本目标：

初始阶段：

获得与特定腹部和平台无关的系统体系结构轮廓，以此建立产品功能范围;编制实例业务实例，从业务角度指出该项目的价值，减少项目主要的错误风险；精化阶段：

通过捕获并描述系统的大部分需求，建立系统体系结构基线的第一个版本，主要包括用况模型和分析模型，减少次要的错误风险，到该阶段未，就能够估算成本、进步，并能详细地规划构造阶段；构造阶段：

通过演化，形成最终的系统体系结构基线，开发完整的系统，确保产品可以开始向客户交付，即具有初始操作能力；移交阶段：

确保有一个实在的产品发布给用户群。

期间培训用户如何使用该软件。

（5）RUP与UML之间关系：

RUP与UML是一对“姐妹”，它们构成了一种特定的软件开发方法学。

其中，UML作为一种可视化建模语言，给出了表达事物和事物之间关系的基本术语，给出了多种模型的表达工具;而RUP利用这些术语定义了需求获取层、系统分析层、设计层、实现层，并给出了实现各层模型之间映射的基本活动以及相关指导。

（6）核心工作流：

需求获取；分析；设计；实现；测试。

（7）需求获取目标：

使用UML中的用况、参与者以及依赖等术语来抽象客观实际问题，形成系统的需求获取模型。

（8）需求获取开展的工作包括：

1、列出候选的需求；2、理解系统语境；3、捕获功能需求；4、捕获非功能需求。

（9）系统语境：

包括领域模型（一般用类图表示）或业务模型（业务用况模型和业务对象模型）。

（10）建造一个系统需求获取模型的活动和任务，以及各活动的输入和输出？

1、发现描述参与者和用况，输入：

业务模型或领域模型，补充需求，特征表;输出：

用况模型[概述]，术语表；2、赋予用况优先级：

输入：

用况模型[概述]，补充需求，术语表;输出：

体系结构描述[用况模型视角]；3、精化用况：

输入：

用况模型[概述]，补充需求，术语表;输出：

用况[精化]；4、构造人机接口原型：

输入：

用况[精华]，用况模型[概述]，补充需求，术语表;输出：

人机接口原理；5、用况模型结构化：

输入：

用况[精华]，用况模型[概述]，补充需求，术语表;输出：

用况模型[精化]。

（11）如何描述系统的参与者和用况？

参与者：

发现参与者与描述参与者：

1）之前已经存在业务用况模型，可依据业务模型直接发现一些候选参与者，2）没有业务用况模型，即使存在领域模型，也需要系统分析人员与客户一起来标识系统参与者

用况是系统向它的参与者提供结果（值）的功能块，表达参与者使用系统的方式，因此一个用况可用于规约系统可执行的、与参与者进行交互的一个动作序列，包括其中一些可选动作序列，并且用况还有自己的属性。

（12）需求分析的目标：

在系统用况模型的基础上，创建系统分析模型以及在该分析模型视角下的体系结构描述，系统分析模型是系统的一种概念模型，解决系统用况模型中存在的二义性和不一致性问题，并以一种系统化的形式准确地表达用户的需求。

（13）需求分析阶段的3个术语：

分析包、分析类和用况细化。

（14）分析类：

是类的一种衍型，很少有操作和特征标记，而用责任来定义其行为，并且其属性和关系也是概念性的，包括：

边界类、实体类、控制类

（15）用况细化：

是一个针对一个用况，其行为可用多个分析类之间的相互作用来细化，并记为用况细化[分析]

（16）分析包：

分析包是一种控制信息组织复杂性的机制，提供了分析制品的一种组织手段，形成了一些可管理的部分。

（17）建造一个系统需求分析模型的活动和任务，以及各活动的输入和输出？

1、体系结构分析：

输入：

用况模型、补充需求、业务模型或领域模型、体系结构描述[用况模型];输出：

分析包[概述]、分析类[概述]、体系结构描述[分析]；2、细化用况：

输入：

用况模型、补充需求、业务模型或领域模型、体系结构描述[分析];输出：

用况细化[分析]、分析类[概述]；3、对类分析：

输入：

用况细化[分析]、分析类[概述]输出：

分析类[完成]；4、对包进行分析：

输入：

系统体系结构描述[分析]、分析包[概述]输出：

分析类[完成]。

（18）创建系统的分析模型，一般应进行体系结构分析、用况分析、类的分析以及包的分析4项活动。

（19）用况分析[分析]的目标：

1、标识那些在用况事件流执行中所需要的分析类和对象；2、将用况的行为，分布到参与交互的各个分析对象；3、捕获用况细化上的特定需求。

（20）用况分析[分析]开展的活动包括：

1、标识分析类，标识在细化一个用况中所需要的实体类、控制类和边界类，给出它们的名字、责任、属性和关系；2、描述分析（类）对象之间的交互，通常使用交互图来描述。

（21）类的分析[分析]的目标：

1、标识并维护分析类的责任；2、基于它们在用况细化中的角色，标识并维护分析类的属性和关系；3、捕获分析类细化中的特定需求。

（22）类的分析[分析]开展的活动包括：

1、标识责任；2、标识属性；3标识关联与聚合；

（23）需求分析模型对以后开发工作的影响？

1、对设计中子系统的影响。

分析包一般将影响设计子系统的结构；2、对设计类的影响。

分析包可以作为类设计时的规格说明；3、对用况细化[设计]的影响。

用况细分[分析]对用况细化[设计]有两方面影响，一个是它们有乃至于为用况创建更精确的规格说明，另一个是当对用况进行设计时，