IDEF0方法.docx
《IDEF0方法.docx》由会员分享，可在线阅读，更多相关《IDEF0方法.docx（11页珍藏版）》请在冰豆网上搜索。
IDEF0方法
IDEF0方法
IDEF是ICAMDEFinitionmethod的缩写,是美国空军在70年代末80年代初ICAM（IntegratedComputerAidedManufacturing）工程在结构化分析和设计方法基础上发展的一套系统分析和设计方法。
IDEF0方法是其中的一个内容,在ICAM中用来建立加工制造业的体系结构模型,其基本内容是SADT（SystemAnalysisandDesignTechnology）的活动模型方法。
它是由Softech公司发展起来的。
IDEF0的基本思想是结构化分析方法，来源于SADT方法。
它具有以下一组基本特色，这些特色形成一种思维规则，适用于从计划阶段到设计阶段的各种工作。
一、全面地描述系统，通过建立模型来理解一个系统
一般地说，一个系统可以被认为是由对象物体（用数据表示）和活动（由人、机器和软件来执行）以及它们之间的联系组成，那至多只反映了一个侧面，这样的技术很难说明系统的全貌。
IDEF0能同时表达系统的活动（用盒子表示）和数据流（用箭头表示）以及它们之间的联系。
所以IDEF0模型能使人们全面描述系统。
对于新的系统来说，IDEF0能描述新系统的功能及需求，进而表达一个能符合需求及能完成功能的实现。
对已有系统来说，IDEF0能分析应用系统的工作目的，完成的功能及记录实现的机制。
在这两种情况下都是通过建立一种IDEF0模型来体现。
所谓模型就是系统的一种书面描述。
它不一定必须用某种数学公式表示，可以是图形，甚至可以是文字叙述。
因而可以说：
“不管何种形式，只要M能回答有关实际对象A的所要研究的问题，就可以说M是A的模型”。
对于有关复杂的企业对象或其他系统，由于用自然语言无法精确又无二义性地表示分析及设计结果，所以这里采用一种图形语言来表示IDEF模型。
这种图形语言能做到：
·有控制地逐步展开细节。
·精确性及准确性。
·注意模型的接口。
·提供一套强有力的分析和设计词汇。
一个模型由图形、文字说明、词汇表及相互的交叉引用表组成。
其中图形是主要成分。
IDEF0图形中同时考虑活动、信息及接口条件。
它把方盒作为活动，用箭头表示数据及接口。
因此在表示一种当前的操作，表示功能说明或设计时，总是由一个活动模型、一个信息模型及一个用户接口模型组成。
工程界对系统开发过程一般可安排几个阶段：
分析（确定系统将做什么）、设计（定义子系统及其接口）、实现（独立地创建子系统）、集成（把子系统联接成一个整体）、测试（证明系统能工作）、安装（使系统能运行）和运行（使用系统）。
我们介绍IDEF方法的目的，在于强调科学地进行复杂系统的分析和设计的重要性。
一般来说，在分析或设计阶段造成的错误，在后续阶段可能花2倍时间去找到、花5倍时间去纠正。
或者如人们所说的：
分析阶段的一个错误未被纠正，在设计阶段要花2倍时间，测试阶段要花10倍时间，运行或维修阶段要花100倍的时间才能纠正。
二、目的与观点（PurposeandViewpoint）
由于模型是一个书面说明，因此象一切技术文件一样，每一个模型都有一个目的与一个观点。
目的是指建模的意义，为什么要建立模型。
观点是指从哪个角度去反映问题或者站在什么人的立场上来分析问题。
功能模型是为了要进一步做好需求分析，要实现预定的技术要求（不论是对已有系统的改造还是新建系统），所以要明确是对功能活动进行分析（逐步分解），而不是对组织机构的分解。
一个活动可能由某个职能部门来完成，但活动功能不等于组织，因此必须避免画成组织模型的分解过程。
模型描述的内容反映各种用户的要求，从单一角度描述问题是困难的，也是不可能的。
如：
物资管理人员——仓库管理员关心收、发、存；计划人员关心什么时候物料从库存点到采购点；厂长关心哪一个工程项目节约用料，加快进度。
因此要求所有的用户，有同样重要而且相同的需求是不可能的，不切实际的。
IDEF0要求在画出整个系统的功能模型时，具有明确的目的与观点。
譬如对一个企业的CIM系统，必须有明确的站在厂长（或经理）的位置上建模的观点，所有不同层次的作者都要以全局的观点来进行建模工作，或者说就是为厂长而建模。
这样才能保证是从全企业的高度来揭示各部分之间的相互联系和相互制约的关系。
否则有的人强调设计处的利益，有的人突出供销处的要求，甚至有的可以只为某个岗位的操作人员的要求来建立各功能模块之间的联系，那就整个乱套了。
三、区别“什么”（What）和“如何”（How）
“什么”是指一个系统必须完成的是“什么”功能，“如何”是指系统为完成指定功能而应“如何”建立。
就是说，在一个模型中应能明确地区别出功能与实现间的差别。
IDEF0首先建立功能模型。
把表示“这个问题是什么”的分析阶段，与“这个问题是如何处理与实现”的设计阶段仔细地区别开来。
这样，在决定解法的细节之前，保证能完整而清晰地理解问题。
这是系统成功开发的关键所在。
在设计阶段，要逐渐识别各种能用来实现所需功能的机制，识别选择适当机制的依据是设计经验及对性能约束的知识。
根据不同模型，机制可以是很抽象，也可以是很具体的。
重要的是，机制指出了“什么”是“如何”地实现的。
IDEF0提供了一种记号，来表示在功能模型中如何提供一个机制来实现一个功能，及单个机制如何能在功能模型的几个不同地方完成有关功能。
有时机制相当复杂，以致机制本身需要进行功能分解。
四、自顶向下分解
用严格的自顶向下地逐层分解的方式来构造模型，使其主要功能在顶层说明，然后分解得到逐层有明确范围的细节表示，每个模型在内部是完全一致的。
IDEF0在建模一开始，先定义系统的内外关系，来龙去脉。
用一个盒子及其接口箭头来表示，确定了系统范围，如图1。
由于在顶层的单个方盒代表了整个系统，所以写在方盒中的说明性短语是比较一般的，抽象的。
同样，接口箭头代表了整个系统对外界的全部接口。
所以写在箭头旁边的标记也是一般的，抽象的。
然后，把这个将系统当作单一模块的盒子分解成另一张图形。
这张图形上有几个盒子，盒子间用箭头连接。
这就是单个父模块所相对的各个子模块。
这些分解得到的子模块，也是由盒子表示，其边界由接口箭头来确定。
每一个子模块可以同样地细分得到更详细的细节。
如图2。
IDEF0提供的规则，保证了如何通过分解得到人们所需要的具体信息。
一个模块在向下分解时，分解成不少于3个、不多于6个的子模块。
上界6，保证了采用递阶层次来描述复杂事物时，同一层次中的模块数不会太多，以致不适宜于人的认识规律。
下界3，保证了分解有意义的。
但是，原始的SADT方法，规定一张图上的盒子数为2～7个，故我们也不作很硬性的限制。
模型中一个图形与其他图形间的精确关系，则用互相连接的箭头来表示。
当一个模块被分解成几个子模块时，用箭头表示各子模块之间的接口。
每个子模块的名字加上带标签的接口，确定了一个范围，规定了子模块细节的内容。
在所有情况下，子模块忠实地代表了父模块，以既不增加也不减少的方式反映着各自父模块所包含的信息。
五、严格的人员关系，评审手续及文档管理办法
（1）人员：
IDEF0适合于研究分析一个大而复杂的系统，因此要求有一个技术上熟练、而且能相互协调的集体来一起工作。
这个集体应有各方面的人员组成。
通常，将人员分成以下几类：
·作者（authors）:
研究需求及限制条件，分析系统功能，建立IDEF0模型。
·评审员（commentors）：
也可以是其它图的作者。
主要是进行复审，并写出对其他人所作工作的书面意见。
是广义的读者。
·读者（reader）：
读IDEF0图，口头上提出意见。
没有提书面意见的义务，读图的目的主要是为了互相了解，互相协调。
·专家（experts）：
作者对专家进行访问，了解需求、限制条件等专门信息。
·技术委员会（technicalcommittee）:
对每个主要分解阶段进行复查，并对项目管理作技术决策，仲裁作者和读者间不能协商一致的分歧。
·项目资料员（projectlibrarian）：
维护文件，复制分配材料及记录。
·项目负责人（projectmanager）：
负有分析及设计系统的技术责任，也是技术委员会的主席。
（2）评审手续：
建模活动每前进一步，IDEF方法都要求这个集体成员交换见解，用以互相检查工作的结果，有名的作者/读者循环就体现了这个工作程序。
作者访问专家，画出系统的IDEF0图。
由资料员编成文件存档，分发给评审员及读者。
评审员把加上意见的材料退还给作者，同时由资料员存档。
作者根据意见修改图形，反复循环，直至这一层问题全部解决，再送给作者准备下一步的分解。
第一个作者可以是下一层的某个作者或较低层的评审员。
最后由技术委员会来解决必要的技术问题及技术分歧。
（3）文档：
无论是作者的模型，还是评审员的评论，都要以书面的形式反映出来。
每次修改意见都要保存，一面工作，一面把文档建立起来。
以上几个方面构成了IDEF0方法的基础。
它们相互补充，失去其中任一个都会降低IDEF0方法的效用。
IDEF0
IDEF0是以结构化分析和设计技术（StructuredAnalysisandDesignTechnique,SADT）为基础所发展出来的一种系统菜单达的工具。
藉由图形化及结构化的方式，清楚严谨的将一个系统当中的功能、以及功能彼此之间的限制、关系、相关信息与对象表达出来。
藉由如此的表达方式，让使用者得以藉由图形便可清楚知道系统的运作方式以及功能所需的各项资源，并且提供建构者与使用者在进行相互沟通与讨论时，一种标准化与一致性的语言（方国定，民90）。
Kusiak,Larson&Wang（1994）指出IDEF0可说是以结构化的方法、阶层式表现系统功能（Function）、信息（Information）及对象（Object）三者彼此相关性的方法。
IDEF是ICAMDEFinitionmethod的缩写,是美国空军在70年代末80年代初ICAM（IntegratedComputerAidedManufacturing）工程在结构化分析和设计方法基础上发展的一套系统分析和设计方法。
IDEF0方法是其中的一个内容,在ICAM中用来建立加工制造业的体系结构模型,其基本内容是SADT（SystemAnalysisandDesignTechnology）的活动模型方法。
它是由Softech公司发展起来的。
IDEF0的基本思想是结构化分析方法，来源于SADT方法。
它具有以下一组基本特色，这些特色形成一种思维规则，适用于从计划阶段到设计阶段的各种工作。
一、IDEF0之基本组件
IDEF0模式的建立主要是由方块（Boxes）及箭号（Arrows）这两种基本组件所组成的。
当中的每一个方块代表的是系统的功能，功能可能是一种行动（Action）、作业（Operation）或是过程（Processes）。
箭号代表方块中所需的信息，例如：
输入、输出、控制、机制以及呼叫等。
IDEF0图形中将各项作业分为输入（Input）、输出（Ouput）、控制（Control）及机制（Mechanism），并将功能之间彼此相关联性加以分解，因此可以正确的获取及传达流程与描述系统的功能。
而往后本研究当中也将利用IDEF0之图形来定义出产品开发知识管理系统之功能。
至于IDEF0之基本组件图如图2-1所示。
资料来源：
FederalInformationProcessingStandardsPublication,1993,IntegrationDefinitionForFunctionModeling（IDEF0）.
图2-1中IDEF0之基本组件图当中的长方形图称之为功能（Function），其为对某些特定对象进行某特定目的之活动（Activity），而这些活动有可能是一种行动（Actions）、作业（Operations）或是程序（Process），而有这些功能的目的在于产生不同于前的结果。
至于活动必需要由输入（Input）、输出（Ouput）、控制（Control）、机制（Mechanism）及呼叫（Call）等五项来构成，输入（Input）、控制（Control）、输出（Ouput）、机制（Mechanism）四者的缩写就是IDEF0语法当中的ICOM，称为IDEF0中的四种资源。
至于IDEF0中这些功能（Function）的命名主要是以动词或动词词组为主。
而呼叫（Call）则是比较特殊的一种接口，它可以由功能再呼叫下一个更为详细的模式来解释目前的功能，因此，其主要用在庞大的系统分工时，做为将来系统整合的接口（FederalInformationProcessingStandardsPublication,1993）。
二、IDEF0之系统功能展开
图2-2所示为一个IDEF0之系统功能展开的模式范例，藉由该图说明此系统的作用和范围，图中以阶层式的往下展开各作业程序。
而其中方格代表系统中的功能或是活动，箭号则是代表方格中的活动与外界联系的四种接口。
其中左端为输入的资料、信息对象等，右端为输出的信息、对象或是资料，而上方为控制方格运作的条件、下方为支持作业方格的机制，以上四种接口来表达系统架构中功能执行时的所有变化以及所需的环境，而活动与活动间之箭号流向可为物料流及信息流之展现。
A-0：
于此阶层当中清楚地定义该模型的主题和范围，并且也是该模型的最高层级。
A0：
将A-0层级更进一步的展开，并且将A-0的主题和范围明显地描述出建构者所要表达的观点。
A3：
对A0所展开的某一项作业程序，做出更详细的分解，使此模型的目标被更充分的描述。
A31：
对A3所展开的某一项作业程序，做出更详细的分解，使此模型的目标被更充分的描述。
图2-2 IDEF0模式范例
资料来源：
Kusiak.A,Larson.N&Wang.J,1994,”ReengineeringofDesignandManufacturingProcesses”,ComputersandIndustrialEngineering,Vol.26,No.3,pp.521-536.
三、IDEF0之优缺点
IDEF0其主要的功能是在于以结构化的方式来表达出系统功能环境，以及各个功能之间的关系。
系统分析人员藉由IDEF0来做为分析工具时，可以很清楚的表达出系统架构，而程序设计师也可藉由IDEF0的模型图明白的了解系统的需求，也因此降低了系统分析师与程序设计师的认知差距。
同时IDEF0又可以与IDEF家族当中的其它成员相结合，也因此增添了许多的便利性。
虽说IDEF0是如此的好用，但目前仍是有些情形是无法做到的。
兹将IDEF0之优缺点列于下表2-1当中。
表2-1 IDEF0优缺点比较表
优点
缺点
共同语法规定与批注功能的关联性
缺乏功能范围及问题的定义
提供组织的细部功能分工模式，协助决策者制定决策
可能由于分工过细，导致一般人无法实际参与整个模式的运作
活动透过层级的分解可将问题清楚的表达，有助于组织内部及外部的沟通
模式当中没有清楚地列出活动顺序，因此常被误解为一连串的活动
具有良好的弹性与良好的逻辑性
以自然的语法表达各活动，有助于功能细部的分工
可以与IDEF家族当中的其它分析工具相整合
四、全面地描述系统，通过建立模型来理解一个系统
一般地说，一个系统可以被认为是由对象物体（用数据表示）和活动（由人、机器和软件来执行）以及它们之间的联系组成，那至多只反映了一个侧面，这样的技术很难说明系统的全貌。
IDEF0能同时表达系统的活动（用盒子表示）和数据流（用箭头表示）以及它们之间的联系。
所以IDEF0模型能使人们全面描述系统。
对于新的系统来说，IDEF0能描述新系统的功能及需求，进而表达一个能符合需求及能完成功能的实现。
对已有系统来说，IDEF0能分析应用系统的工作目的，完成的功能及记录实现的机制。
在这两种情况下都是通过建立一种IDEF0模型来体现。
所谓模型就是系统的一种书面描述。
它不一定必须用某种数学公式表示，可以是图形，甚至可以是文字叙述。
因而可以说：
“不管何种形式，只要M能回答有关实际对象A的所要研究的问题，就可以说M是A的模型”。
对于有关复杂的企业对象或其他系统，由于用自然语言无法精确又无二义性地表示分析及设计结果，所以这里采用一种图形语言来表示IDEF模型。
这种图形语言能做到：
·有控制地逐步展开细节。
·精确性及准确性。
·注意模型的接口。
·提供一套强有力的分析和设计词汇。
一个模型由图形、文字说明、词汇表及相互的交叉引用表组成。
其中图形是主要成分。
IDEF0图形中同时考虑活动、信息及接口条件。
它把方盒作为活动，用箭头表示数据及接口。
因此在表示一种当前的操作，表示功能说明或设计时，总是由一个活动模型、一个信息模型及一个用户接口模型组成。
工程界对系统开发过程一般可安排几个阶段：
分析（确定系统将做什么）、设计（定义子系统及其接口）、实现（独立地创建子系统）、集成（把子系统联接成一个整体）、测试（证明系统能工作）、安装（使系统能运行）和运行（使用系统）。
我们介绍IDEF方法的目的，在于强调科学地进行复杂系统的分析和设计的重要性。
一般来说，在分析或设计阶段造成的错误，在后续阶段可能花2倍时间去找到、花5倍时间去纠正。
或者如人们所说的：
分析阶段的一个错误未被纠正，在设计阶段要花2倍时间，测试阶段要花10倍时间，运行或维修阶段要花100倍的时间才能纠正。
五、目的与观点（Purpose and Viewpoint）
由于模型是一个书面说明，因此象一切技术文件一样，每一个模型都有一个目的与一个观点。
目的是指建模的意义，为什么要建立模型。
观点是指从哪个角度去反映问题或者站在什么人的立场上来分析问题。
功能模型是为了要进一步做好需求分析，要实现预定的技术要求（不论是对已有系统的改造还是新建系统），所以要明确是对功能活动进行分析（逐步分解），而不是对组织机构的分解。
一个活动可能由某个职能部门来完成，但活动功能不等于组织，因此必须避免画成组织模型的分解过程。
模型描述的内容反映各种用户的要求，从单一角度描述问题是困难的，也是不可能的。
如：
物资管理人员——仓库管理员关心收、发、存；计划人员关心什么时候物料从库存点到采购点；厂长关心哪一个工程项目节约用料，加快进度。
因此要求所有的用户，有同样重要而且相同的需求是不可能的，不切实际的。
IDEF0要求在画出整个系统的功能模型时，具有明确的目的与观点。
譬如对一个企业的CIM系统，必须有明确的站在厂长（或经理）的位置上建模的观点，所有不同层次的作者都要以全局的观点来进行建模工作，或者说就是为厂长而建模。
这样才能保证是从全企业的高度来揭示各部分之间的相互联系和相互制约的关系。
否则有的人强调设计处的利益，有的人突出供销处的要求，甚至有的可以只为某个岗位的操作人员的要求来建立各功能模块之间的联系，那就整个乱套了。
六、区别“什么”（What）和“如何”（How）
“什么”是指一个系统必须完成的是“什么”功能，“如何”是指系统为完成指定功能而应“如何”建立。
就是说，在一个模型中应能明确地区别出功能与实现间的差别。
IDEF0首先建立功能模型。
把表示“这个问题是什么”的分析阶段，与“这个问题是如何处理与实现”的设计阶段仔细地区别开来。
这样，在决定解法的细节之前，保证能完整而清晰地理解问题。
这是系统成功开发的关键所在。
在设计阶段，要逐渐识别各种能用来实现所需功能的机制，识别选择适当机制的依据是设计经验及对性能约束的知识。
根据不同模型，机制可以是很抽象，也可以是很具体的。
重要的是，机制指出了“什么”是“如何”地实现的。
IDEF0提供了一种记号，来表示在功能模型中如何提供一个机制来实现一个功能，及单个机制如何能在功能模型的几个不同地方完成有关功能。
有时机制相当复杂，以致机制本身需要进行功能分解。
七、自顶向下分解
用严格的自顶向下地逐层分解的方式来构造模型，使其主要功能在顶层说明，然后分解得到逐层有明确范围的细节表示，每个模型在内部是完全一致的。
IDEF0在建模一开始，先定义系统的内外关系，来龙去脉。
用一个盒子及其接口箭头来表示，确定了系统范围，如图1。
由于在顶层的单个方盒代表了整个系统，所以写在方盒中的说明性短语是比较一般的，抽象的。
同样，接口箭头代表了整个系统对外界的全部接口。
所以写在箭头旁边的标记也是一般的，抽象的。
然后，把这个将系统当作单一模块的盒子分解成另一张图形。
这张图形上有几个盒子，盒子间用箭头连接。
这就是单个父模块所相对的各个子模块。
这些分解得到的子模块，也是由盒子表示，其边界由接口箭头来确定。
每一个子模块可以同样地细分得到更详细的细节。
如图2。
IDEF0提供的规则，保证了如何通过分解得到人们所需要的具体信息。
一个模块在向下分解时，分解成不少于3个、不多于6个的子模块。
上界6，保证了采用递阶层次来描述复杂事物时，同一层次中的模块数不会太多，以致不适宜于人的认识规律。
下界3，保证了分解有意义的。
但是，原始的SADT方法，规定一张图上的盒子数为2～7个，故我们也不作很硬性的限制。
模型中一个图形与其他图形间的精确关系，则用互相连接的箭头来表示。
当一个模块被分解成几个子模块时，用箭头表示各子模块之间的接口。
每个子模块的名字加上带标签的接口，确定了一个范围，规定了子模块细节的内容。
在所有情况下，子模块忠实地代表了父模块，以既不增加也不减少的方式反映着各自父模块所包含的信息。
八、严格的人员关系，评审手续及文档管理办法
（1） 人员：
IDEF0适合于研究分析一个大而复杂的系统，因此要求有一个技术上熟练、而且能相互协调的集体来一起工作。
这个集体应有各方面的人员组成。
通常，将人员分成以下几类：
·作者（authors）:
研究需求及限制条件，分析系统功能，建立IDEF0模型。
·评审员（commentors）：
也可以是其它图的作者。
主要是进行复审，并写出对其他人所作工作的书面意见。
是广义的读者。
·读者（reader）：
读IDEF0图，口头上提出意见。
没有提书面意见的义务，读图的目的主要是为了互相了解，互相协调。
·专家（experts）：
作者对专家进行访问，了解需求、限制条件等专门信息。
·技术委员会（technicalcommittee）:
对每个主要分解阶段进行复查，并对项目管理作技术决策，仲裁作者和读者间不能协商一致的分歧。
·项目资料员（project librarian）：
维护文件，复制分配材料及记录。
·项目负责人（project manager）：
负有分析及设计系统的技术责任，也是技术委员会的主席。
（2） 评审手续：
建模活动每前进一步，IDEF方法都要求这个集体成员交换见解，用以互相检查工作的结果，有名的作者/读者循环就体现了这个工作程序。
作者访问专家，画出系统的IDEF0图。
由资料员编成文件存档，分发给评审员及读者。
评审员把加上意见的材料退还给作者，同时由资料员存档。
作者根据意见修改图形，反复循环，直至这一层问题全部解决，再送给作者准备下一步的分解。
第一个作者可以是下一层的某个作者或较低层的评审员。
最后由技术委员会来解决必要的技术问题及技术分歧。
（3） 文档：
无论是作者的模型，还是评审员的评论，都要以书面的形式反映出来。
每次修改意见都要保存，一面工作，一面把文档建立起
升级会员 