ARIS方法3－说明层次

2.3 说明层次

如前所述，ARIS 资源视图的结构布局是根据信息系统的说明层次的生命周期概念而形成的。

生命周期模型的主要形式即层次或阶段概念，这种模型说明了一个信息系统的生命周期。然而，ARIS生命周期模型没有流程模型那样的重要性，流程模型是用于开发独立的说明对象的。它仅在它们与信息技术的近似性的基础上，对不同的说明层次进行了定义。

这种区别在ARIS **模型，图2.3-1：信息系统的说明层次 中有明确的表达。（见Scheer, 《集成信息系统体系结构》 1992, p. 16 f.）.

整个系统的开发过程始于对业务操作问题的分析。这种分析基本上包含了整个被说明的业务过程，这一过程在这里是以用户目标和用户所使用的语言为导向的。这一过程把信息技术技术选择进行合并，以用来支持业务流程与决策。因此，只有半正式的说明语言被用来描述业务问题。由于这种方法缺乏足够的细节，以及语言的高度专业化，所以在实施阶段不能被用作正式的说明方法。

需求定义必须要把业务程序用正式的说明语言进行说明，这样才能使这一步成为需求定义到信息技术的一致转换过程的出发点。这一过程也是建立（语义）模型的过程。需求定义与问题说明之间的联系是非常紧密的，这一点在图2.3-1: 信息系统的说明层次 中有着很好的表述。

当需求定义的概念环境完成了向IT导向的转变时，就达到了设计规范层。这里，模块（或是说用户事务）是用来执行被定义功能功能的，而并不是功能本身。也可以认为这一层在信息技术说明的总体方法中，是另一种形式的需求定义。因此，需求定义和设计规范之间的联系是较为松懈的。这意味着设计规范可以在不影响需求定义的情况下做一些变动。然而，这并不意味着需求定义和设计规范可以在彼此分离的情况下被制定出来。在完成需求定义之后，把它的内容按照业务管理用这种方法来确定下来时非常重要的，这样外部面向IT的事项（比如信息系统执行）对主题的内容就不会造成太大的影响了。

在实施描述层，设计规范已经被转换成为具体的软硬件组件。由此，与信息技术之间的物理连接就完成了。

每个独立的说明层是以不同的更新周期来标识的。更新频度最高达到实施描述层，最低达到需求定义层。

实施描述层与信息技术的开发过程联系非常紧密，并且由于信息技术的创新周期较短，往往会用于进行修订。

需求定义层有着特殊的重要性，因为它既是长期业务应用的贮藏室，同时也是更进一步的开发实施描述的开始点。需求定义的生命周期是最长的，而且由于它与业务问题说明之间的密切关系，能够说明信息系统对企业的最大的好处。由于这一原因，需求定义（或是语义模型）的开发t的优先级是最高的。语义模型使用户和他们的初始应用IT相关语言来说明业务问题的过程之间建立了联系。

图2.3-1: 信息系统的说明层次

视图和说明层次的创造，以及初始业务问题的解决，构成了整个ARIS体系。如图2.3-2 ARIS体系结构所示，每一个说明视图都含有这三个层次，需求定义层，设计规范层，以及实施描述层。

图 2.3-2: ARIS 体系结构

随着ARIS 体系结构的发展，以说明性的视图及层次来定义的说明视图也随之而固定下来。作为一切分析的开始点，它们包含有十三个组成部分，这在说明每一个体系块的过程中，对选择和描述适当的说明方法是非常必要的。

选择这些方法的标准： (见 Scheer, 《业务过程工程》1994, p. 18)

· 说明方法是否简单易懂，

· 特定的主题内容表达是否适当，

· 是否能对所有被说明应用软件均采用一致的说明方法，

· 对这种方法的使用是否熟悉，

· 说明方法与信息通讯技术的技术开发过程之间是否具有独立性。

在说明视图中使用的各种方法将在以后章节中详加说明。

1. 过程链分析

2. 业务问题的说明

在能对ARIS 体系中的单个结构块（说明性的视图和层次）建立模型之前，语义上的初始业务处理，比如，业务问题，必须是已经存在的。在这种情况下，考虑到对业务过程的支持和所设计的系统的目标概念的本质内容，就需要对所使用的信息系统的弱点进行说明。如此发现的弱点也反映了新的信息系统必须达到的目标。

因此，表达这个问题说明的模型必须从视图的数据，功能，组织结构以及存在与它们之间的内部关系中覆盖尽可能多的业务过程。不仅如此，这一模型必须对目标概念进行说明，而这种说明要能够成为其他建模过程的基础。所以，需求定义的过程就触发了对应于ARIS体系的视图的划分.

由于这种要求，对初始业务状况的描述必须是容易理解的，而已存在的信息系统的弱点也必须以一种紧密的形式表现出来。这样，就限制了对一般建模方法的使用。由于它们的主要分析特点集中在不同的方面上，这些建模方法一般被用于对各个视图建立模型。

这种内部关系以一种紧密的形式进行了登记，比如过程链表 (PCDs) ，这也对被检测的信息系统给出了一个总体的概貌。(见 Scheer, 《高效信息管理的原则》1990, p. 39 f.).

3. 过程链表 (PCDs)

在过程链表中，一个过程链被表示为一个闭环。因此，业务过程中的独立视图（组织视图，数据视图，功能视图，和资源视图）以及它们之间的内部关系就能够更加清晰的被表示出来。

图 3.2‑1: 过程链表示例

第一栏和第二栏表明了业务过程的发生时间顺序。为了达到这一目的，过程中的独立功能在第二栏中列示出来，并与触发和引起这些功能的事件建立了连接。功能与事件用点线箭头连接起来，用以准确说明哪一个事件触发了哪一个功能，以及哪一个事件是由哪一个功能引起的。也就是说，这些箭头对功能之间的控制流进行了定义。在这一示例中，“输入订单”功能就是由事件“已收到订单”所触发引起的。由最终事件“输入订单” 引起的这一功能又引起了下一个功能：“处理订单”。事件与功能之间的这一关系构成了功能的过程顺序，这种按时间排列的过程顺序就叫做过程链。控制流的可能的分支点和循环的逻辑内部相关性可以用连接操作者的方法来表达出来。

功能要求有数据的输入及输出，这些数据在下一栏中以数据群的形式显示出来。“处理订单”功能要求的数据输入就是“订单数据”和“客户控制”，所产生的数据输出就是“客户订单”。并不仅仅只有信息对象本身可以用数据来表达，同样的方法也可以应用到承载信息的信息载体（媒体）上。比如说，这种载体可以是一份文件，一张清单，一张手写的收条，或是像硬盘之类的存储介质。

负责执行单个功能的组织单元（部门）在最后一栏里做了说明。

“过程类型”和“应用系统”栏（对话，批，手动）提供了一些关于某一特定功能的IT支持等级的附加信息。所使用的应用系统或应用系统的单个组成部分登记在“应用系统”栏里。关于功能是如何执行的，是交互式处理，批处理，或是手动操作的，这些信息都包括在“过程类型”栏里。

在一个说明现实情况的过程链表中分析业务过程时，解决问题的现行方案的不足之处就会凸显出来。这些不足之处有可能是IT关联的处理与手工处理之间的媒体分裂，或者是组织分裂（例如，主管的部门/组织单元频频变动）。这一分析尤其能发现数据冗余问题，同一过程的多重入口和时间滞后问题，这就能对被定义的目标过程作更多的改进。

创造过程链表是为了说明初始情况，但对它的理解相对是较难的。它们首先被用于显示所有ARIS组成部分之间的交互关系，但在ARIS控制视图里也作为一种表现方法。 (见第四章第四小节) 在控制视图里，不仅用到了过程链表，同时也用到了事件驱动过程链(EPCs) (见第四章第四小节，1.2.1)。就建模而论，事件驱动过程链和过程链表（PCDs）一样，都是非常有用的；EPCs中唯一的不同是不一定要放在预先定义的栏里。如果流程模型只能由一种图(PCD 或 EPC)来说明，目标过程也可以用EPC来显示。