软件工程笔记整理

软件工程概论
1、软件危机
1)、软件工程的目的：倡导以工程的原理、原则和方法进行软件开发，以解决当时出现的软件危机。

2)、软件危机：指在计算机软件开发和维护过程中所遇到的一系列问题。

A 、如何开发软件以满足对软件日益增长的需求。

B 、如何维护数量不断增长的已有软件。

3)、软件危机的主要表现形式
A 、软件开发成本高，研制进度无法准确估计，用户不满意。

B 、软件产品的可靠性得不到保证。

C 、软件产品难以维护。

D 、软件发展跟不上硬件的发展和用户的要求，硬件成本逐年下降，软件成本越来越昂贵。

2、软件工程概念
1)、软件：计算机系统中的程序及其文档。

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

细言之，软件有三层含义：
A 、个体含义：即指计算机系统中的程序及其文档。

B 、整体含义：即指在特定计算机系统中所有上述个体含义下的软件的总称。

C 、学科含义：即指在研究、开发、维护以及使用前述含义下的软件所涉及的理论、方法、技术所构成的学科。

2)、工程：将理论和所学的知识应用于实践的科学。

3)、软件工程：应用计算机科学、数学及管理科学等原理，开发软件的工程。

它借鉴传统工程的原则、方法，以提高质量，降低成本为目的。

其中，计算机科学、数学用于构造模型与算法，工程科学用于制定规范、设计范型、评估成本及确定权衡，管理科学用于计划、资源、质量、成本等管理。

3、软件工程框架(参见附图软件工程框架示意图)
1)、软件工程目标：生产具有正确性、可用性和开销合宜的产品。

A 、正确性：是指软件产品达到预期功能的程度。

B 、可用性：是指软件基本结构、实现以及文档为用户可用的程度。

C 、开销合宜：是指软件开发、运行的整个开销满足用户要求的程度。

2) 、软件开发活动：生产一个最终满足需求且达到工程目标的软件产品所需要的活动。

软件开发的基本活动包括：需求、设计、实现、确认、和支持。

A 、需求：就是定义问题。

B 、设计：在需求的基础上，给出被建系统的软件设计方案。

C 、实现：在软件设计的基础上，编码被建系统软件体系结构中的每一模块或构件。

D 、确认：需求复审、设计复审及程序测试。

E 、支持：为系统的运行提供纠错性维护和完善性维护。

3)、软件工程原则：围绕软件开发，提出了以下基本原则。

A、选取适宜的开发范型：在系统设计中，经常需要权衡软件需求、硬件需求以及其它因素之间的相互制约和影响，适应需求的易变性。

选用适宜的开发范型，以保证软件开发的可持续性，并使最终的软件产品满足客户的要求。

B 、采用好的设计方法：在软件设计中，通常需要考虑软件的模块化、信息隐蔽、局部化、一致性以及适应性等问题。

采用合适的设计方法，支持这些问题的解决和实现。

C、提供高质量的工程支持：如其它工程一样，需要提供高质量的工程支持，例如配置管理、质量保证等，才能按期交付高质量的软件产品。

D、有效的软件工程管理：软件工程的管理，直接影响可用资源的有效利用，提高软件组织的生产能力。

仅当对软件过程实施有效管理时，才能实现有效的软件工程。

4)、软件工程学科研究的内容：软件开发模型、软件开发方法、软件过程、软件工具、软件开发环境、计算机辅助软件工程以及软件经济学等。

5)、软件开发方法学：是一种已定义好的技术集和符号表示习惯，来组织软件开发的过程，一般表示为一系列步骤，包括结构化方法、面向对象方法、 Jackson 方法、 Warnier 方法、 PAM 方法、可视化方法等。

软件开发模型
1 、软件开发模型：软件开发全部过程、活动、任务的结构框架。

2、软件生存周期：软件产品从定义开始，经过开发、使用和维护，直到最后被淘汰的整个过程。

3、软件过程：是为了获得高质量的软件所需要完成的一系列任务的框架，它规定了完成各项任务的工作步骤。

4、瀑布模型(参见瀑布模型示意图)
1) 、概述：将软件生存周期的各项活动规定为依固定顺序连接的若干阶段工作，形如瀑布流水，最终得到软件产品，是一种线性模型。

2)、各阶段活动：提出系统需求、提出软件需求、需求分析、设计、编码、测试和运行。

3)、每一阶段的特征
A 、从上一阶段接受本阶段工作的对象，作为输入。

B 、对上述输入实施本阶段的活动。

C 、给出本阶段的工作成果，作为输出传入下一阶段。

D、对本阶段工作进行评审，若本阶段工作得到确认，则继续下阶段工作；否则返回前一阶段，甚至更前阶段。

4)、优缺点
A、优点：在支持结构化软件开发、控制软件开发的复杂性、促进软件开发工程化等方面起着显著作用。

B 、缺点：缺乏灵活性，无法通过开发活动澄清本来不够确切的软件需求。

5、演化模型(参见演化模型示意图)
1)、概述：演化模型主要针对事先不能完整定义需求的软件开发。

2)、开发过程：首先开发核心系统，当核心系统投入运行后，开发人员根据用户的反馈，实施开发的迭代过程。

每一迭代过程均由需求、设计、编码、测试、集成等阶段组成，直到软件开发结束。

3)、优点：一定程度上减少了软件开发活动的盲目性。

6、螺旋模型(参见螺旋模型示意图)
1) 、概述：在瀑布模型和演化模型的基础上，加入两者所忽略的风险分析所建立的一种软件开发模型。

2)、特点：沿螺旋模型顺时针方向，依次表达了四个方面的活动，制定计划、风险分析、实施工程、客户评估。

7 、喷泉模型：它体现了软件创建所固有的迭代和无间隙特征。

主要用于面向对象开发过程。

(参见喷泉模型示意图)
8、增量模型：在设计了软件系统整体体系结构之后，首先完整的开发系统的一个初始子集，继之，根据这一子集，建造一个更加精细的版本，如些不断地进行系统的增量开发。

(参见增量模型示意图)
9、各种模型之间的区别与联系
1)、瀑布模型、演化模型、螺旋模型之间的异同。

A 、相同点：都分为多个阶段。

B、不同点：瀑布模型一次完成软件；演化模型分为多次完成，每次迭代完成软件的一个部分；螺旋模型也分为多次完成，每次完成软件的一个新原型，并考虑风险分析。

2)、演化模型和增量模型的区别
A、演化模型：首先开发核心系统，每次迭代为系统增加一个子集，整个系统是增量开发和增量提交。

B 、增量模型：首先完整的开发系统的一个初始子集，然后不断的建造更精细的版本。

3)、需要完整定义需求的模型：瀑布模型、增量模型。

4)、属于迭代风范的模型：演化模型、增量模型、喷泉模型、螺旋模型。

第三章结构化需求分析
1、需求分析
1)、基本任务：准确定义未来系统的目标，确定为了满足用户的需要系统必须做什么。

2)、承担者：系统分析员。

3)、两个阶段：需求获取和需求规约。

2、需求获取
1) 、目的：清楚地理解所要解决的问题，完整地获取用户需求。

2) 、主要活动：通过学习、请教领域专家、向用户提问等。

3)、三大挑战：问题空间理解；人与人之间的通信；需求的不断变化。

4)、分类及内容
A、功能性需求：定义系统做什么。

B、非功能性需求：定义系统工作时的特性。

5)、原则
A、划分：捕获问题空间的“整体 /部分”关系。

B、抽象：捕获问题空间的“一般 /特殊”或“特例”关系。

C 、投影：捕获问题空间的多维“视图”。

6)、技术
A、一种好的需求获取技术应具备的基本特征。

①提供方便的通信；
②提供定义系统边界的方法；
③提供支持抽象的基本机制；
④鼓励分析员使用问题空间的术语思考问题，编写文档；
⑤为分析员提供多种可供选择的设计方案；
⑥适应需求的变化。

B、Jacobson 提出的用况法基本符合以上特征，详见“第五章面向对象方法”的“用况图”。

3、需求规约：对需求陈述进行分析，解决其中存在的二义性和不一致性，并以一种系统化的形式准确地表达用户的需求，形成所谓的需求规格说明书。

4、结构化方法：是一种系统化开发软件的方法，该方法基于模块化的思想，采用“自顶向下，逐步求精”的技术对系统进行划分，分解和抽象是它的两个基本手段，结构化方法是结构化分析、结构化设计和结构化编程的总称。

6、结构化分析
1)、基本步骤
A、通过对现实系统的了解和分析，或基于需求陈述，建立该系统的数据流图；
B、基于得到的数据流图，建立该系统的数据字典；
C、基于得到的数据流图，对最低层的加工给出其控制结构描述；
D、依据需求，建立人机接口和其他性能描述；
E、通过分析和验证，建立系统完整的需求规约。

2)、结构化分析模型：数据流图(DFD)是一种描述数据变换的图形工具，是结构化分析方法最普遍采用的表示手段，数据字典和小说明为数据流图提供了补充，并用以验证图形表示的正确性、一致性和完整性，以上三者构成了结构化分析的模型。

A、数据流图：是一种描述数据变换的图形工具，系统接受输入的数据，经过一系列的变换(或称加工)，最后输出结果数据。

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

①加工：是对数据进行处理的单元；用圆圈表示；顶层的加工名就是软件系统的名字，加工的名字最好使用动宾词组 (e.g.计算费用) ，也可用主谓词组 (e.g. 费用计算)，不要使用意义空洞的动词作为加工名(e.g.计算)。

②数据流：表示数据 (由一组数据项组成) 和数据流向 (三种流向：从加工流向加工；从数据源流向加工或从加工流向数据潭；从加工流向数据存储或从数据存储流向加工。

两个加工之间可以有多个数据流，这些数据流之间没有任何联系，数据流图不表明它们的先后次序) ；用箭头表示；用名词或名词词组命名，尽量选用现实系统中已有的名字。

③数据存储：表示信息的静态存储；用两条平行线表示；其命名方法同数据流。

④数据源：数据的来源；用矩形表示；
⑤数据潭：数据的最终目的地；用矩形表示。

B、数据字典：以一种准确的和无二义的方式定义所有被加工引用的数据流和数
据存储。

包括数据流条目、 数据存储条目、 数据项条目。

常用逻辑操作符： “= ” 等价于 (定义为) 、“+”与 (顺序结构) 、“{}”重复 (循环结构) 、“[|]” 或(选择结构)、“()”任选、“ m..n ”界域。

C 、小说明：用于描述底层加工，集中描述一个加工的输入数据和输出数据的逻 辑关系， 即加工逻辑， 并不描述具体的加工过程 。

一般用自然语言、结构化自然 语言、判定表和判定树等描述。

①结构化自然语言： 分为内外两层， 外层语法描述操作的控制结构， 内层语法用 自然语言描述。

如：在飞机票预订系统中
在旅游旺季的 7~9， 12 月
如果 订票超过 20 张
优惠票价的 15%
如果 订票 20 张以下
优惠票价的 5%
在旅游淡季的 1~6， 10， 11 月份
如果 订票超过 20 张
优惠 30%
如果 订票 20 张以下
优惠 20%
②判定表： 分四个区， 一区列出所有的条件类别， 二区列出所有的条件组合， 三 区列出所有的操作， 四区列出在相应的组合条件下某个操作是否执行或执行情 况。

如：
③判定树：用图形形式描述加工逻辑。

3)、建立结构化分析模型的步骤(附实例)
A 、确定系统边界，画出系统环境图(参见系统环境示意图)
B 、自顶向下，画出各层数据流图 ①功能分解(参见功能分解示意图)
②数据流的分派(参见数据流分派示意图)
③文件引入与精化(参见精化示意图)
④如果有必要， 从①开始对分解后的加工再次进行分解， 建立更下一层的数据流 图
C 、定义数据字典
D 、定义小说明
E 、汇总前面各步骤的结果 4)、注意事项
1~6， 10， 11 月
订票量
<=20
折扣量 7~9， 12 月 旅游时间
<=20 20% 30% 15% >20 >20 5%
A、模型平衡原则
①数据流图中所有的图形元素必须根据它们的用法规则正确使用；
②每个数据流和数据存储都要在数据字典中有定义，数据字典将包括各层数据流图中数据元素的定义；
③数据字典中的定义使用合法的逻辑构造符号；
④数据流图中最底层的加工必须在小说明中有定义；
⑤父图和子图必须平衡，即父图中某加工的输入输出 (数据流) 和分解这个加工的子图的输入输出(数据流)必须完全一致；
⑥小说明和数据流图的图形表示必须一致。

B、控制复杂性的一些规则
①上层数据流可以打包，上、下层数据流的对应关系用数据字典描述，同层的数据流也可编号对应在，包内流的性质(输入 /输出)必须一致；
②为便于理解，一幅图中的图元个数控制在7±2 以内；
③检查同每个加工相关的数据流，并寻找是否有其他可降低界面复杂性的划分方法；
④分析数据内容，确定是否所有输入信息都用于产生输出信息；相应地，由一个加工产生的所有信息是否都能由进入该加工的信息导出。

7 、需求验证：就是对软件需求规格说明书 (SRS) 加以验证，需要从以下方面进行：正确性，无二义性，完整性，可验证性，一致性，可理解性，可修改性，可被跟踪性，可跟踪性，设计无关性，注释。

8、需求规格说明书
1)、概述：是需求分析阶段产生的一份最重要的文档，它以一种一致的、无二义的方式准确的表达用户的需求。

2)、作用
A、作为软件开发机构和用户之间一份事实上的技术合同书；
B、作为软件开发机构下一步进行设计和编码的基础；
C 、作为测试和验收目标系统的依据。

3)、基本结构：引言、概述、数据流图与数据字典、接口、性能需求、属性、其他需求。

9、需求分析阶段的另外两份文档：初步测试计划和用户系统描述。

结构化设计
1、软件设计阶段：需求分析阶段的主要任务是确定系统必须“做什么”，形成软件的需求规格说明书，软件设计阶段主要任务是确定系统“怎么做”，从软件需求规格说明书出发，形成软件的具体设计方案，软件设计可以采用多种方法，如结构化设计方法、面向数据结构的设计方法、面向对象的设计方法等，结构化软件设计可以分为总体设计和详细设计两个阶段。

2、数据流图的类型
1)、变换型数据流图：具有较明显的输入、变换、输出界面的数据流图。

(参见变换型数据流图示意图)
2)、事务型数据流图：当数据到达一个处理 T 后，该处理 T 根据输入数据的类型或数据值，在其后的若干动作序列 (称为一个事务) 中选出一个来执行。

(参见事务型数据流图示意图)
3、设计类型(以上面两图为实例)
1)、变换设计：对应于变换型数据流图。

其步骤如下：
A、确定输入、变换、输出的边界：逻辑输入就是离物理输入端最远的，但仍被看作是系统输入的数据流；逻辑输出就是离物理输出端最远的，但仍被看作是系统输出的数据流。

B 、“第一级分解”-系统模块结构图顶层和第一层的设计：主模块位于最顶层，一般以所建系统的名字命名；输入模块部分，一般有几个不同的逻辑输入，就设计几个输入模块；变换模块部分；输出模块部分，一般有几个不同的逻辑输出，就设计几个输出模块。

(参见变换设计之第一级分解示意图)
C 、“第二级分解”- 自顶向下，逐步求精：输入模块部分，通常可分解为两个下属模块：一个是接收数据模块，另一个是把接收的数据变换成它的上级模块所需的数据的模块，继之，对下属的输入模块以同样方式进行分解，直到一个输入模块为物理输入为止；输出模块部分，通常也可分解为两个下属模块：一个将得到的数据向输出形式转换的模块，另一个将转换后的数据输出，对下属的模块以同样方式进行分解，直到一个输出模块为物理输出为止；中心变换模块，通常依据数据流图的具体情况，并以功能分解的原则，考虑如何对中心变换模块进行分解。

这样就得到了初始模块结构图。

(参见变换设计之第二级分解示意图)
D 、使用设计度量和启发式规则，对初始模块结构图进行精化。

(参见变换设计之精化示意图)
2)、事务设计：对应于事务型数据流图，其步骤如下：
A 、确定事务处理中心。

B 、“第一级分解”-系统模块结构图顶层和第一层的设计：首先为事务中心设计一个主模块；然后，为每一条活动路径设计一个事务处理模块；一般来说，事务型数据流图都有输入部分，对其输入部分设计一个输入模块；如果一个事务型数据流图的各活动路径又集中于一个加工，则为此设计一个输出模块；如果各活动路径是发散的，则在第一层设计中就不必为其设计输出模块。

(参见事务设计之第一级分解示意图)
C 、“第二级分解”- 自顶向下，逐步求精：关于输入模块、输出模块的细化，如同变换设计对输入模块、输出模块的细化。

关于各条活动路径的细化，则要根据具体情况进行。

D 、使用设计度量和启发式规则，对初始的模块结构图进行精化。

4、设计评价准则
1)、模块化：把一个待开发的软件分解成若干简单的模块，即为模块化。

2)、信息隐蔽：在自顶向下逐步求精时，其较低层的设计细节都被“隐蔽”起来，只给出模块的接口，这样不仅使功能的执行机制被隐蔽起来，而且控制流程的细节和一些数据也被隐蔽起来。

3) 、模块：是执行一个特殊任务或实现一个特殊的抽象数据类型的一组例程和数据结构。

通常由两部分组成：接口和实现模块功能的执行机制。

4)、评价软件设计的基本准则是“高内聚”、“低耦合”。

5) 、耦合：是对不同模块之间相互依赖程度的度量。

紧密耦合是指两个模块之间存在着很强的依赖关系；松散耦合是指两个模块之间存在一些依赖关系，但它们之间的连接比较弱；无耦合是指模块之间根本没有任何连接。

A、耦合的强度依赖的因素
①一个模块对另一个模块的引用。

②一个模块向另一个模块传递的数据量。

③一个模块施加到另一个模块的控制的数量。

④模块之间接口的复杂程度。

B、耦合从强到弱分类
①内容耦合：一个模块直接修改或操作另一个模块的数据，就发生了内容耦合，被修改的模块完全依赖于修改它的模块。

②公共耦合：两个以上的模块共同引用一个全局数据项就称为公共耦合，对全局数据项的修改作用于所有访问该数据项的模块，所以模块间的依赖关系依旧存在。

③控制耦合：一个模块在界面上传递一个信号控制另一个模块，接收信号的模块的动作根据信号值进行调整，称为控制耦合。

④标记耦合：若两个模块至少有一个通过界面传递的公共参数包含内部结构，则为标记耦合。

⑤数据耦合：模块间通过参数传递基本类型的数据。

C、原则：如果模块间必须存在耦合，就尽量使用数据耦合，少用控制耦合，限制公共耦合的范围，坚决避免使用内容耦合。

6)、内聚：度量的是一个模块内部各成分之间相互关联的强度。

A、从低到高分类
①偶然内聚：一个模块的各成分之间毫无关系。

②逻辑内聚：几个逻辑上相关的功能被放在同一模块中。

③时间内聚：如果一个模块完成的功能必须在同一时间内执行 (如初始化系统或一组变量)，但这些功能只是因为时间因素关联在一起。

④过程内聚：如果一个模块内部的处理成分是相关的，而且这些处理必须以特定的次序进行。

⑤通信内聚：如果一个模块的所有成分都操作同一数据集或生成同一数据集。

⑥顺序内聚：如果一个模块的各个成分和同一个功能密切相关，而且一个成分的输出作为另一个成分的输入，则称为顺序内聚。

⑦功能内聚：模块的所有成分对于完成单一的功能都是基本的。

5、启发式规则
1)、改进软件结构提高模块独立性。

2)、模块规模应该适中。

3)、深度、宽度、扇出和扇入应适中。

A 、深度：表示软件结构中控制的层数。

B 、宽度：软件结构同一个层次上的模块总数的最大值。

C 、扇出：一个模块直接控制(调用)的下级模块数目。

D 、扇入：表明有多少个上级模块直接调用它。

4)、模块的作用域应该在控制域之内。

A 、作用域：受该模块内一个判定影响的所有模块的集合。

B 、控制域：这个模块本身以及所有直接或间接从属于它的模块的集合。

5)、力争降低模块接口的复杂性。

6)、模块功能应该可以预测。

6、总体设计
1)、主要任务：把系统的功能需求分配给软件结构，形成软件的模块结构图( MSD) 。

2)、表示工具
A 、层次图：用来描绘软件的层次结构，很适合于在自顶向下设计软件的过程中使用。

B 、HIPO 图：由 H 图(层次图)和 IPO 图(输入/处理/输出图)两部分组成。

C、结构图：通常用带注释的箭头表示模块调用过程中来回传递的信息，尾部是空心圆表示传递的是数据，实心圆表示传递的是控制信息。

3)、方法：首先对需求规约所产生的 DFD 分类，然后将不同类型的 DFD，采用不同方法进行映射，将 DFD 转换为初始模块结构图，再根据基本的模块化设计原则 -“高内聚，低耦合”，精化初始模块结构图，使之成为最终可供详细设计使用的模块结构图。

7、结构化程序设计：结构化程序设计技术采用自顶向下逐步求精的设计方法和单入口单出口的控制结构，并且只包含顺序、选择和循环三种结构，结构化程序设计的目标之一是使程序的控制流程线性化，即程序的动态执行顺序符合静态书写结构，结构化程序设计的观点是要求设计好结构的程序。

8、详细设计
1)、目标：确定怎样具体实现所要求的系统。

2)、详细设计包含实现对应的总体设计的模块所需要的处理逻辑，主要有，详细的算法；数据表示和数据结构，实施的功能和使用的数据之间的关系。

3)、工具
A、程序流程图(程序框图，参见程序流程图示意图)
B 、盒图 (N-S 图，参见盒图示意图)
C 、PA
D 图(参见 PAD 图示意图)
D、类程序设计语言(PDL) (伪码)
9 、软件方法学：是以软件方法为研究对象的学科。

主要涉及指导软件设计的原理和原则，以及基于这些原理、原则的方法和技术。

狭义的软件方法学也指某种特定的软件设计指导原则和方法体系。

面向对象方法
1、构造模块的四种基本观点
1)、以“过程”或“函数”为基点，使每一模块实现一项功能；
2)、以一个“数据结构”为基点，使每一模块实现该数据结构上的操作功能；
3)、以“事件驱动”为基点，使每一模块识别一个事件并对该事件作出响应；
4)、以“问题域中的一个成分”为基点，使每一模块对应现实世界中的一个事物。

2、用况图
1) 、概述：就是由参与者、用况以及它们之间的关系所构成的图。

作用：主要用来明确需求；用来辅助分析；用来辅助设计，特别是用户界面的设计；用来指导测试。

2)、概念
A 、系统边界：一个系统所包含的所有系统成分与系统以外各种事物的分界线。

B、参与者：在系统边界以外，与系统进行交互的事物-人员、设备、外系统。

一个参与者定义了一组功能上密切相关的角色，当一个事物与系统交互时，该事物可以扮演这样的角色。

C 、用况：对参与者使用系统的一项功能时所进行的交互过程的描述。

3)、关系
A、参与者之间的关系
①泛化(继承)：如果一组参与者具有共同的性质，可以把这些性质抽取出来放在另一个参与者中，它们再从中继承。

B、用况之间的关系
①泛化(继承) ：子用况继承父用况的行为和含义；子用况可以增加或覆盖父用况的行为；子用况可以出现在父用况出现的任何位置。

②扩展：从用况A 到用况B 的扩展关系是指，用况B 的实例是可以被用况A 指定的行为扩充(服从于在扩展中指定的特定条件) ，行为被插入到由B 中的扩展点定义的位置。

③包含：从用况A 到用况B 的包含关系表明，用况A 的一个实例也包含了用况B 所指定的行为，在用况A 中定义的位置包含该行为。

④扩展与包含的异同
同：都是不完整的；都离不开基本用况；都可实现为子程序。

异：方向不同； 1 对多选包含关系；多对1 选扩展；包含处理一般的情况；扩展处理特殊的情况。

C、参与者与用况之间的关系
①关联：连接参与者与用况之间的线段，表示参与者实例与用况实例之间的交互。

4)、实例(参见用况图实例)
3、类图
1) 、概述：类图用以表示模型的静态结构，即表示静态元素及其之间各种静态关系。

为了控制信息组织的复杂性，可以把类图组织成包，但这并不表示对构成模型的基本元素的划分。

2)、概念
A 、类：是具有相同结构、行为和关系的一组对象的描述符。

B 、属性：是一些有着确定值的、用于描述对象状态信息的数据。

C 、服务：为了完成某一任务，一个对象所提供的、并体现其责任的操作。

D、对象：在系统分析和系统构造中，对象是对客观世界事物的一种抽象，是由数据 (属性) 和其上操作(行为)组成的封装体，是类的一个实例。

对象的特点：自治性，对象具有一定。