1- PAGE 22 EMBED Designer \s \* MERGEFORMAT
SEQ kap \c \* MERGEFORMAT 0 - PAGE 5
4集成信息系统体系结构（ARIS）层次及视图建模
功能视图
需求定义
建模方法通常显示与来自其他描述集成信息系统体系结构（ARIS)体系结构（ARIS)视图的对象相关联的功能。数据和功能之间的关系通过，比如经过输入输出功能数据详细列明一个功能的变化过程，来说明。
另一方面，集成信息系统体系结构（ARIS)体系结构（ARIS)结构严格分散着不同的视图。 (见Scheer，集成信息系统体系结构（ARIS)体系结构（ARIS)体系结构1992, p. 63).在功能视图中，应用到的仅是阐述功能间关系的具有代表性的视图。 比如功能和数据间的关系在集成信息系统体系结构（ARIS)体系结构（ARIS)体系结构功能视图中得以描述。
定义： 功能是一项技术任务，或者一种执行某种用来支持一个或多个公司目标的对象的操作。XE "Function" (见 Scheer, 集成信息系统体系结构（ARIS)体系结构（ARIS)体系结构 1992, p. 63).
功能显示在圆角矩形中：
图 1:“消费需求验证”功能表示
通常，建立一个功能的标准是一个信息对象，诸如一个消费者调查或产品定单。这种标准也可在功能的描述中得出。如图-21， 消费者调查定义了对象，验证说明了对象须执行的任务。更多地抽象为一个名词来描述功能（例如获得后勤学，生产，销售）。.
功能树
可以在不同的压缩的程度说明功能。以业务过程或过程链形式存在的复杂功能处在最高的压缩的程度。XE "Process chain". 这方面的一个例是一个消费定单从消费者质询到发货的处理。这样一个如此说明复杂功能的业务过程可被分为子过程，从而减少其复杂性。 因此，功能术语可用在所有结构层次。其他更多地用描述性的方法的术语一般也用于说明各层次：事物处理，过程，子功能段的基本功能。
分划的功能可包括几个层次。在语义功能树上基本功能说明最低层次。
定义: 基本功能是相对于业务过程分析的目标不能更深一步细分的功能。
功能树或层次结构图用来说明此子结构(见图 2).
图 2:功能树（部分视图）
在一个功能树上可以使用不同的标准组合功能群(见 Brombacher/Bungert, Praxis der Unternehmensmodellierung 1992)。 经常用于此用途的标准包括：相同对象的处理（面向对象的）， 属于同一过程（面向过程）或包括同一操作（面向操作）。
图 -3显示了一个面向对象细分的例子。 高级功能生产定单处理 细分为 制作生产定单，批准生产定单，校正生产定单，取消生产定单，发布生产定单，监控生产定单 功能。 这些功能描述了不同的操作（制作，校正，取消，等等），这些操作在这个生产过程案例中执行同一个目标。.
图 -3:面向对象的功能树
如果要功能树显示通过业务过程建模得到的结论，那么面向过程的功能树成为选择的方法。
图 -4 面向过程功能细分项目的示例显示
接受消费者定单，校验消费者定单，制作消费者数据库，检验消费者信贷价值 ，查证产品实用性 和 批准消费者定单 功能属于处理消费者定单业务流程。不同于一个面向对象的细分，这里的操作执行不同的对象 (用户订单，产品实用性)。
图 -4: 面向过程功能树
面向过程分组即将所有对不同信息对象执行同一程序的功能（检验，创制，删除）组合在一起。XE "Function tree: Process-oriented"例如图 -5所示的修改功能。这些功能可以属于不同的过程也可包括在不同对象的处理中。然而它们对单个对象的执行的程序类型通常是一样的。.
图 -5:面向执行功能树
一方面，在功能树上说明功能减少复杂性，但是另一方面，它只是一个静态表示法。除了这种静态表示作用，它也许对按时间顺序了解功能程序序列有用处。XE "Procedural sequence: Chronological" 事件驱动过程链用来描述按时间顺序排列的程序序列。XE "Event-driven process chain (EPC)"它们由事件和功能组成——同时事件在功能间形成链。事件属于集成信息系统体系结构（ARIS)体系结构（ARIS)数据视图。事件驱动过程链记述在继承信息系统控制视图中——符合集成信息系统体系结构（ARIS)体系结构（ARIS)的分离原则（见Chapter ）.
从主题相关的观点角度说明功能，不仅涉及到功能能被细分为其要素的特性，其他功能特性也是有用的。这一点对参加业务过程设计的特性尤为正确。
因此，每一份功能草案应该包括信息，不管这种信息需要顾客输入或是其能自动运行。所以，合适的，执行起来不受用户干扰的功能，可以作为一批来捆扎和处理（批运行）。编制业务过程的另一方向角度提供关于功能数量基础（例如，一天调查程序数目）和功能执行的合计周期的信息。合计周期本身由单个的时间要素组成（准备时间，处理时间和等待时间）。集成信息系统体系结构（ARIS) 把这些信息按功能对象类型保存。在这个手册的附录你可以找到所有的归结类型。
Y 图
Y 图以高度集中的程度说明一个企业的功能（任务）。.这里，我们处理主要的功能领域，诸如生产设计，材料管理，维护。. Y通讯接口模块形式的结构说明(见Scheer, A.-W.:业务过程再设计 1994, p. 87)细分为逐个的功能。XE "Y-CIM model"Y左边分支包括生产计划和控制的主要业务管理的计划功能。然而右边的包含了关于生产计划和实现的面向技术上的功能。计划功能安排在Y的高一些的部分，控制和实现功能在较低的部分。.
从而，Y-CIM模型描绘了把一个企业在生产方面涉及到的所有功能分类的一个框架。
在集成信息系统体系结构（ARIS）里，对于交叉引用模型，这种图类型被作为面向功能的方法，。被说明的对象属于功能对象类型。若按一定的层次排序，这种对象类型可被连结到例如功能树和扩展的实际关系模型图类型。
在图 -6.显示一例
图 -6: Y图表
SAP 应用图
对于SAP R/3 应用模型的实施，SAP 应用图允许面向SAP R/3应用系统模块的方法。在R/3 应用模型中，过程选择矩阵分配到这种图类型的每一个对象。在单独的R/3模块和程序某一段中，它列举了可以这样解释的主要有用程序。XE "Process scenarios"
SAP R/3 系统的SAP应用图表如图 -7显示
图 -7: SAP应用图表
目标图
在开始建模、分析或优化业务过程前，你应该定义公司业务过程建模目标。
在目标图上你可以——在其他事情中——定义（公司）目标和构建目标结构层次。
定义: 目标是公司未来目的，在成功要素和清楚的业务过
程支持下实现。
可以列举有助于目标的可能的成功要素，把他们按一定的层次排列，并分配到他们所支持的目标中。
定义: 为达到公司特定的目标，成功要素列示了需要考虑的方方面面。在目标图上把它们分配给公司目标。
这种图类型利用功能对象类型同需求定义的其它图类型连接。对于每个目标，你可以列举出能导致实现这个目标的功能（业务过程）。在业务过程的建模和优化阶段， 说明过程模型时，你应该考虑在对象和分配的功能中定义的优先权。
图 -8显示目标图的一个例子
图 -8: 目标图实例
设计规范— 应用系统类型图
功能视图的设计规范包括应用系统和模块类型，应用系统类型的模块结构，单独事务处理步骤的草图和输入输出图的定义的规范。
说明功能视图设计规范要回答的中心问题是：
利用应用系统，模块类型或设计功能怎样支持被定义的功能？
应用系统类型和模块类型按模块式怎样创建？
执行一个功能需要哪些表列和修饰？
使用应用类型和模块类型需要创建哪些表列，哪些修饰用到应用类型和模块类型？
一个应用系统的技术基础（操作系统，用户接口和管理系统数据库）是什么？
在使用某个单独应用系统类型前追求什么业务目标？
在功能视图的设计概念中，中心对象类型从而是应用系统类型。
对照在功能视图的实施层次中应该首先考虑的、并且说明一单独的可确认的应用系统的、具体的应用系统，例如公司的许可号码，应用系统由代表所有严格共享相同技术基础的应用系统构建。
定义: 应用系统类型揭示了完全基于同种技术的一类应用系统。
例如：集成信息系统体系结构（ARIS)工具箱。译文 说明了一个应用系统类型。 从这种应用系统类型中，可以获得一些许可和一些这样的单独应用程序。
下面的图表显示了一个应用系统类型：
图 -1:一个应用系统类型的图形表示
应用系统类型通常作为模块来设计。应用系统类型图能帮助举例说明这种模块化设计。应用系统类型的单个基础是各个模块类型。如图 -2所示一例：
图 -2:应用系统的模块化设计
在上面的例子中， ARIS工具箱译文 由ARIS简单设计，ARIS 作业成本管理方法 和 ARIS 仿真模块化类型组成。和应用系统类型一样，模块类型用于代表严格共享统一技术基础的各个单独模块。模块化类型是应用系统类型的基础。他们是能够独立运行的成分。
定义: 模块化类型是应用系统的一个元素，它能独立运行。模块化类型代表那些都完全基于同一技术基础的单独的应用系统。
在层次结构上可以自由组合应用系统类型和模块化类型。模块化结构可以被分为最低层次的设计功能类型。
定义: 从事务处理的意义上来说，设计功能类型是模块化类型的最小单元。它们利用单独的程序元素实现运行，处理单任务步骤一般必须完全执行它们。
图 -3: 设计功能的图形表示
应用系统类型图也允许你说明需求定义的功能，需求定义是被定义过的应用系统类型和模块化类型支持。这种安置由此组成了功能视图的需求定义和定义规范间的链。 图 -4是这方面的例子
图 -4:应用系统的功能分配
为了完全地定义应用系统类型和模块化类型的技术基础，它们也可用尽可能的用户接口，管理信息系统数据库和操作系统类型分配，和执行它们的编程语言一样，凭借这些运行。因为这些是类型并且没有具体例子，这完全有可能存在多从关系。因此，Windows 和 Windows NT 用户接口可被配置到一种应用系统类型，这意味着这种应用系统译文可在这两种用户界面运行，在功能试图的是程度中，如果用户接口被分配一个具体的例子（例，一个应用系统），则仅仅需要唯一一个的关系。 这准确说明了公司购买的，单独的应用系统许可的配置。
图 -5显示在应用系统类型图中可能配置的例子：.
图 -5: 应用系统类型配置
利用一个应用系统编辑一个特定主体导致不同界面修饰的应用和，特定应用系统提供的不同表列的创造和使用。为了解释这个主题，表列和修饰对象是可利用的，它们可配置到特定主体功能，或应用系统类型，或模块化类型中。
如果在没有具体应用系统类型的引用下需要首先定义普通过程链，则草图列表和草图修饰对象可以用来定义被需求的修饰和表列。一般地，在没有创建一个应用系统的突变和修饰的一个具体参考条件下，两种对象首先指定了使用什么类型的表列和修饰（例如，对于用户数据的登录）随后，这种草表和修饰可以被附在具体表列和修饰后。配置定义了可得到的实施可能性。. 图 -6 给出一例：
图 -6：修饰和表列的配置
在应用系统类型图表中对象类型的全部列表和它们的可能关系可在附录中查找。
实施——应用系统类型图
在应用系统图中，现行的应用系统和模块可被配置到在设计规范中被说明的应用系统和模块类型。例如，在一个公司存在这些应用系统类型实例，其能唯一地被他们的许可号鉴别。
定义: 一个应用系统（模块）是一个应用系统类型（模块化类型）的一个单独的实例，其例如，能被他的许可号码唯一地鉴别。
应用系统和模块将在图-1用图显示
图-1：应用系统和模块的图形表示
因为在一个公司中可能存在一个应用系统类型（模块化类型）的几个号码，所以遵循在应用系统图中，几个应用系统（模块）可以分配到一个应用系统类型（模块化类型）。如图 -2所示：
图 -2：应用系统分配给应用系统类型
应用系统图说明了应用系统的实际模块结构。然而，设计规范指出了应用系统类型所有可能的模块成分。现在，每一个应用许可得到了说明，这意味着每一个单独的许可的模块成分能被唯一地鉴定。在一个公司，应用系统类型可以有几个拥有完全不同模块结构的应用系统。（见 图-3）
图-3：统一类型的两个应用系统的不同结构
除了说明实际存在的应用系统和模块，实施程度也允许定义以单独程序文件形式的，应用系统的程序技术（物理）的转换。
为此目的，应用系统图可以说明使用哪些程序模块类型实现一个应用系统类型或模块化类型。
定义: 每一个通过购买一个许可在硬盘上可得到的程序文件是一个程序模块。通过决定完全基于相同技术的程序模块类型开发一个程序模块类型。
图 -4 显示应用系统模块类型分配给应用系统类型，同单独的程序模块分配给程序模块类型一样。
图 -4： 应用系统类型，程序元素类型和程序元素的分配
除了其他程序模块类型，集成信息系统体系结构（ARIS）工具箱译文应用系统由, , 和 程序模块类型组成。由于几个许可的购买或备份复印件的建立，在一个公司里，对每个程序模块，可能存在着几个实例（程序模块）。
程序元素类型和程序元素可在在层次结构上自由组合。为了用技术主体详细说明程序，程序模块类型对程序库的访问可以在应用系统图上得到说明。
附录包含存在于应用系统图的中的对象类型和关系的概述。
SEQ Kap \r4 \h 数据视图
需求定义
数据视图的需求定义包含即将被检验的字段的语义数据模型的说明。依照集成信息系统体系结构（ARIS)体系结构的划分原则，这种描述包含两种制定过程链的开始和结束事件的对象，同过程链的相关环境的状态描述一样。
当比较功能和数据的建模时，就相关的方法来说，后者要求显著苛刻。在功能视图中，仅检验过的对象是功能。在功能间的相互关系方面，仅高级和次要的得到说明。
对于语义数据模型，Chen的实体关系模型 (ERM) 时最普遍的设计方法 (见 Chen,实体关系模型 1976)。这种缄默方法甬道多种术语，诸如，实体类型，关系类型，属性等等。存在于那些对象彼此间的关系是无数的，并且——当比较与功能建模时——是非常难于分类的。.
在以后的纪录中介绍实体关系模型(ERM)的建模方法。首先说明Chen的原始模型的对象及相互关系。在以后的章节，对原始模型将添加一些运算符。
基本的ER模型
原始模型分辨实体，属性和关系。一般地，类型层可分辨取值层。
定义: 实体是一个公司任务已知特定部分的重要性的真实或抽象的对象。
例如，这种体系块可能是业务过程。依照集成信息系统体系结构（ARIS)体系结构的结构模型，重要性的数据对象是环境和目标指定的事件的对象。 在处理消费者订单 中，我们可能发现如下实体：
消费者1235,
商品4711,
订单11.
通过某特定属性（特性）更准确地说明实体。这意味着一个消费者通过，例如他的名字、姓和地址被更准确地说明
定义: 如果同一类型的实体被聚合成一批，则被称为实体类型。实体类型的取值是实体。
同一类型的实体可被同一属性说明。因此，消费者Smith 和消费者 Miller 合起来形成实体类型消费者 ，商品（article） 4710和商品（article） 4712一起形成实体类型 商品 （Article）。实体类型显示在如矩形的ER模型 (见图 1：实体类型举例). 在以后的原文中，实体类型以大写显示。
图 1：实体类型举例
定义: 特征是描述实体类型的特性。
属性取值是分配于单个实体的属性的实际取值。例如，消费者1235可用属性取值Smith,John,New York，等等描述。各自属性称作名字、姓和城市。
通常用一个圆或椭圆来代表属性，在下面文章中，用椭圆表示属性。图 2：消费者实体类型属性举例 .
图 2：消费者实体类型属性举例
实体类型和属性间的差异一般很难区分，并且仅仅有时能依据建模的程序的上下文决定，例如，消费者地址 理解为实体而不是消费者属性。在这种情况下，新实体类型 地址 将被确定，它和消费者之间有它自己的关系。当说明不论你处理的是一实体类型或一属性时，事实是实体过程属性是一个有用的标准。属性，另一方面，不包含多个属性。因此，如果在一个假定后来被更多属性描述的ER模型中，创建一个属性，则它就成为了一个实体类型。 无论一个对象是否同其它实体类型分配有相互关系都是另一个有益的问题。如果能肯定地回答它，这个正被讨论的对象也是实体类型。
定义: 关系是实体间的一个逻辑链。.
因此，关系的存在直接依赖实体的存在。
定义: 如果同一种类的关系组合成批，则称他们为关系类型。
供应者 和零件 之间的一个关系类型是供应。在以后的文中，关系类型也设置成大写字母。在一个ER模型中，关系类型以菱形显示并且通过连线连接实体类型。见图图 3：关系类型举例)。
图 3：关系类型举例
通常，为了有意义按链的方向顺序仅仅能看到一个关系类型。在以上的例子中，假定表达供应者供应零件关系。从右到左则成为零件供应供应者，这是没有意义的。如果没有唯一地规定正确的方向，则必须通过选择方便的术语，可能在更抽象的程度，去避免这种难点。
我们区分很多关系类型。在此文中，一方面，他们连接的实体类型的数目，另一方面，关系的复杂程度，充当区分标准。
根据它们连接的实体类型的数目区分实体类型，如，一元，二元或n 元关系。
定义: 复杂程度或集的容量显示一个实体类型的多少实体归属为另一个实体类型的一个实体。
这样出现的不同类型说明在 图 4：两种实体类型建的关系的集的容量 (见 Scheer, 工程业务过程1994, p. 34).
四种不同的关系类型可区分如下（集的容量）：
1:1关系。
1:n 关系。
n:1 关系。
n:m 关系。
在一个 1:1 关系类型中，第二者中的一个实体严密对应于第一者中的每一个实体。在一个
1：n的关系中，第二类的一个实体严格对应于第一类中的每一个实体 ，但是第一类有n个实体对应于第二类的每一个实体。n:1表达相反的顺序的相同情形。在一个n:m关系中，第二类中的n个实体对应于第一类中的一个实体而不是全部。
图 4：两种实体类型建的关系的集的容量
这种关系类型的集的容量（属性类型复杂度）显示在实体类型图的连接中（见图 5：在ER模型中说明集的容量 ）。
图 5：在ER模型中说明集的容量
集的容量指出了一确定类型的关系的最大量，一特定实体类型的一个实体能够加入其中。意思是对于在图 5：在ER模型中说明集的容量 说明过的n:1关系，如果公司开有不同的车间，实体类型公司中一个公司可以以不同的分配关系出现。然而，一特别的车间也许仅仅参加了一个分配关系——它仅对应于一个公司。
然而，应该注意的是，Chen 的原始著作以不同的方法说明集的容量。当说明两个以上类型之间的关系时，这部手册用的这种符号允许更清楚独特的公式。为了避免不必要的混淆，我们不去讨论Chen的原始工作的更多的细节。
由于实体类型的实体之间也存在有关系的事实，实体类型和关系类型也可用俩种平行的关系连接。为了区分这两种关系，可以给定他们任务分配。回归关系的一个例子显示在图 6：材料单的 ER模型。高级零件由不同的次级零件组成。另一方面，次级零件也可以作为构件用在不同的高级零件。
图 6：材料单的 ER模型
不仅实体类型能通过特征描述，关系类型的应用也能同样(见 图 -7： 在ER模型中的属性分配)。
定义: 属性的值域称为定义域。
定义域的元素对实体或关系类型的元素的分配也描述关系。可被属性名字标注的关系代表。
定义: 在实体类型和至少一个定义域间，一定存在1:1 关系。定义域中的值能唯一地指定一个实体。因此，称他们为实体类型的关键属性。.
在 图 -7： 在ER模型中的属性分配 (见 Scheer, 工程业务过程1994, p. 33) 所显示得力之中，个别实体 消费者 被关键属性消费者号码唯一地指定。
通过合并连接的实体的关键属性区别关系。从而，关系类型 居住 的关键属性是消费者号码和地址号码。
相关数据对象的描述性的属性被来源于同实体或关系类型有1：n关系的定义域的值定义。
图 -7： 在ER模型中的属性分配
扩展的 ER模型 — eERM
在最近的几年内，Chen的原始模型得到了充分的扩展。此书仅讨论那些对集成信息系统体系结构（ARIS)体系结构结构的数据视图建模有意义的扩展模型。
在设计运算符帮助下的扩展模型
在创建数据模型的过程中设计运算符提供正式支持。它们的用途保证了系统程序的安全，并且提供给阅读器一个用以洞察其设计过程的现有的数据结构。从现有概念的运用上，新的概念在设计运算符帮助下产生。 设计过程很大程度上是在业务管理知识层次上被执行的智力程序。从他们的数据结构视图观点来说，业务条件的调查报告帮助设计者或者构建共知的基于新观点的条件，或者创建至今为止没有考虑过的新的观点。
从众多的多样的扩展ER模型的方法中，确定了四种基本的设计运算符： (见 Scheer,工程业务过程 1994, p. 35 ff.):
分类xe "Classification",
一般化
聚合
分组
分类xe "Classification"
定义: 通过分类，同一类型的对象（实体）被识别和分配给一个概念（实体类型）。一个对象等同被同样的特性（属性）描述的另外一个对象。
从而，分类导致了实体类型的以上描述过的标识(见 图 -8：消费者的分类)。
图 -8：消费者的分类
一般化/特殊化
定义: 一般地，相似的对象类型被聚合到高级对象类型下。
如 图 9:一般化/特殊化，实体类型消费者 和实体类型供应者 被归纳到一般概念业务伙伴 下。两种对象的共同特性（被属性描述）被转换成一般对象类型。从而，只有那些对于原先的对象类型个别的的属性留下待描述。用一三角形图形表示新实体类型业务伙伴 的形成，也称作一个is-a 关系。.
定义: 通过特殊化，我们知道一般化的概念被细分为子概念。业务伙伴分为消费者 和 供应者
特殊化是一般化的相反形式（例：特殊对象继承一般化对象的性质）。除了那些继承的外，特殊对象类型也拥有他们自己的属性。用图形表示 ，特殊化和一般化用同种方式。
因此，在图例中的连接线没有用指示方向的箭头。
图 9:一般化/特殊化
首先，特殊化支持由上而下构造数据库的方法用来创建数据模型，一般化用的是由下至上的方法。
在特殊化的结构里，发展中的子集的完成和分解（可选择的）在被创建时能被详细说明。
当一个对象的取值可能是两个子集的一部分时，我们就要谈到未分解的子集。.适合于前面已给的例子，意即一个消费者同时可以是一个供应者。如果一个取值仅仅分配给正好一个子集，这些子集是可分解的。 Fo
当可能支持一个特殊化标准的所有特殊化对象类型用于列示一个一般化对象类型时，我们就要谈到完全的特殊化。取实体类型人类为例：它可被分为实体类型男人和女人 (见 图 10: 完成的特殊化). 至于被考虑的特殊化标准性别，特殊化应已被完全说明。
图 10: 完成的特殊化
.为了更准确的说明一个一般化/特殊化，把这些标准结果和以下已确定的四总取值结合起来。
分解的/完成的
分解的/未完成的
未分解的/完成的
未分解的/未完成的
聚合xe "Aggregation"
定义: 聚合通过联合现有的对象类型说明新的对象类型的形成。在此文中，新的对象类型可能是新的属性的知识库。
聚合通过关系类型的形成在ER模型中被说明xe "Relationship type:Formation" (见 图 11: 一个聚合举例). 实体类型聚合生产顺序和行程安排创建新的对象顺序安排。
图 11: 一个聚合举例
然而，聚合运算符也可运用在关系上。一个现行的关系类型作为一个实体类型对待，并且本身从而能成为创建一个新的关系的出发点。在图 12:关于重新解释的关系类型的聚合 例中说明这些。
一个初始的聚合一般形成来源于生产顺序和行程安排的关系类型顺序安排。关键属性生产顺序号(PONO)和行程安排号(RNO)形成顺序安排的复杂属性。目前，多种运算符能被分配于顺序安排。因此，关系顺序操作在关系类型顺序安排和操作间形成。 因为关系只能在实体类型间产生，原始关系类型顺序操作需要作为一个实体类型说明。在 图 12:关于重新解释的关系类型的聚合 中，这点通过一个盒状菱形说明。 然后，这些重新解释的关系类型作为实体类型对待。从参加关系类型旁到菱形点划一条连接线 ，通过表达这种发展说明这种程序。不是通向盒状菱形，而是，从重新解释的关系类型形成新关系的连接线通向环绕它的矩形的边沿。
尽管通过分配一个简单关键简化一个复杂的关键是可能的——基本上， 自从它们把数据模型的创建处理成可追踪，复杂的关键将被包括。
图 12:关于重新解释的关系类型的聚合
在一个 ER模型中，一个复杂的结构单元被分成为一个清楚的结构。 因为全部的概念的联系可能变得模糊，引进以数据簇形式存在的复杂对象。
定义: 一个数据簇说明了这样的逻辑视图，它建立在一个在复杂对象中需要的数据模型的大量实体和关系类型之上。
数据簇不仅由关系类型组成，而且也由数据簇组成。不象实体和关系类型，数据簇可在一个层次上自由组合，从而在一个数据模型的创造过程中，主要支持从上到下的数据结构方法。在一个从下到上的方法中，对于结合和巩固子模型，数据簇的形成也非常有用。
图 13:数据簇（图表特征） 以图表的形式说明了一个数据簇。如图 14: 建立在多种对象上的数据簇视图, 一个数据簇说明了建立在大量实体和关系类型上的逻辑视图。为了说明复杂对象消费者定单，.需要实体和关系类型消费者、时间、定单头、商品和定单内容。
图 13:数据簇（图表特征）
图 14: 建立在多种对象上的数据簇视图
分组xe "Grouping"
定义: 通过分组,来自一个实体集的元素形成组。
在图 图 15:举例，所有套设备合成了一个设备组。设备组是一个独立的对象，这个独立的对象被在单独的成套设备中没有的额外的属性（设备组的名字，成套设备的数目）更准确的说明。 其它例有工作站分组成部门或订单连接项目的联合分组成订单。
图 15:分组
扩展的集的容量
但我们谈到大量集的容量时，至今为止我们仅仅提到以上可允许的关系取值的界限。在图 16: 指出一个工程可分配给以最大数量的职员，一个职员可参与一最大数量的工程。
图 16: 上/下界限（1）
除了上界限，下界限对说明关系取值的最小数量有用。为此目的，技术可用两个字母代表（a,b）,例如， (见 Scheer, 工业业务过程). 在 图 27:上/下界限 (2) 指出每一个工程能参与至少a1和至多b1的引入类型的关系取值。表示每一个工程可被分配至少a1和至多b1职员。两字母（a2,b2）显示一个职员能参与至少a2和至多b2工程。
图 27:上/下界限 (2)
从而，每一个关系通过两个复杂度（最小和最大）表达。通常分配下限值0和1，上限值的范围定义为1 ( max ( * (*是一个通配符)。
下限 min = 0表示一个实体可以参与一个关系，但这并不是强制的。下限min = 1表示一个实体必须参与至少一个关系，但这不是强制的。
在图 38: 上/下限 (3)中的下限表示一个职员能参与一个关系但并不是必须的(min=0)，而一个工程必须参与至少一个关系（min=1）.这里的意思是职员根本不必参与每一个工程。相反，一个工程至少分配一个职员。.
图 38: 上/下限 (3)
如果下限值仅0或1和上限值1或 *时可取的，下面（min,max）符号的四种情况是可能的： (1,1), (1,m), (0,1) 和 (0,m)对于这些下面的缩写是常见的(见 Schlageter/Stucky, Datenbanksysteme 1983, p. 51)：:
1 (对应(1,1)),
c (对应(0,1)),
m (对应(1,m)),
cm (对应(0,m)), (此处c = choice 和 m = multiple).
图 49:上/下限 (4) 显示图 38: 上/下限 (3)。
图 49:上/下限 (4)
标识和存在的相关性
由于通过指定下限和上限扩展集的容量，如在 中讨论的一样， 数据对象建的相关依赖现在可以定义。
通过定义，由于关于关系类型和重新解释的关系类型的实体类型的存在，关系类型和重新解释的关系类型存在，从而，他们不能孤立地存在。这意味着他们相关地以标示的形式依赖于实体类型。
另外，有真正地拥有一个关键属性并且依然依赖于其它实体的存在的实体类型。例如，这种依赖的类型通过分组运算符产生。从而，如图 20: 相关依赖性相关依赖性 ，一个部门至少包含有一个工作站才有意义，以此类推，一个工作站的定义只有分属于一个部门才有意义。 如图 20: 相关依赖性相关依赖性 ，这种相关的依赖性通过复杂度表示。在一个（min,max）符号中，这些通过(1,1) 和 (1,*)说明。在数据模型里相关依赖的定义导致关于参考数据的完整性执行靠后的情况。简单地说，这的意思是遵守这些条件将会保证数据库内容的一致性被保持——甚至在一定处理已经被执行后。在下面例子中，这意味着当属于一个部门的所有的工作站也被删除时，这个工作站才能被删除。
图 20: 相关依赖性
公司技术术语的建模——技术术语模型
在建模中，尤其在数据建模中，我们不得不处理经常发生的困难。在大的公司定义信息对象的术语是多变的。 在采购部门对术语 定购 的理解完全不同于在生产部门人们理解的意思。对一个公司及其部门，通过使用一致性术语，指定信息的可接受性能得到提高。由于这些原因，集成信息系统体系结构（ARIS)体系结构的方法批含有的所谓的技术术语模型不仅允许管理在同义词管理方面的不同术语，而且，允许保持数据模型对象（实体类型，关系来信，等等）间的关系，同被公司指定的技术术语一样。
为了解释这些关系的目的，介绍对象类型技术术语。目前，多样的技术术语能被分配于数据模型的每一个信息对象。.在图 21: 技术术语举例说明这些.
图 21: 技术术语
在一个层次结构上技术术语能是关联的和可以结合的。
在技术术语模型中定义的技术术语也能用在其它包含信息对象的图表中，例如，在说明一个输入输出功能的过程链中。
扩展的实体关系模型属性分配图
以仅仅说明实体模型和关系类型形式的数据模型通常拥有一个非常复杂的结构。如果实体关系模型属性被包括在这些图表中，他们就不再清楚。
利用扩展的实体关系模型分配图，你能以单独的图把实体关系模型属性分配分配给每一个实体和关系类型。扩展的实体关系模型的对象类型（实体类型或关系类型）以一个取值副本的形式能被包括在这个图中。从而， 实体关系模型属性（ERM）的关系可被模仿。对于连接的实体关系模型属性，在一个关键属性，外部的或一个被描述的属性间能建立差别。.在 图 22:一个实体类型的实体关系模型属性的分配 中举例说明这些。
图 22:一个实体类型的实体关系模型属性的分配
除了显示和分配单独的实体关系模型属性，在这种图表类型中你也能显示属性类型群以及它们的分配。
定义: 一个属性的类型群代表一个实体关系类型（ERM）的一群语义上叙述接近的实体关系模型属性， 例如，这些允许包含所有一起来自一个次要的关键的实体关系模型的一个属性群的创建。
属性类型群说明如下：
图 23: 一个属性类型群的标示
在这个手册的附录，你可找到一个实体关系模型分配图的所有可能关系的摘要。
选择窗口的表示
SAP –结构化实体关系模型（SERM）
在此书中除了一个描述过的，其它ER模型表示也通常使用。 经常地，关系类型不作为单独对象说明，而是，它们被作为实体类型建的联系说明。拥有他们自己属性的关系类型于是作为（弱的）实体类型被介绍 。
这种表示形式的一个例子是被Sinz (见Sinz, 实体关系模型1990)提出的结构化实体关系模型（SERM ）方法。通过使用方向图表形象化主要的和依赖的数据对象及从左（强的实体类型）到右（弱的实体类型和关系类型）组合模型的对象，数据结构的发展方向变成了透明的。从而，至今为止，在结构化实体关系（SER）和基于扩展的实体关系模型（eERM）已描述方法上的模型间的主要差异依赖于图形表示法。
SAP AG in Walldorf/Germany在关于它的信息建模技术的框架中发展的建模技巧连接了结构化实体关系（SER）和在此书中介绍的扩展的实体关系模型（eERM）方法（见see Keller/Hechler, 信息模型1991）。
在此文中，对象形成期间在实体类型和关系类型之间没有图表差别被虚构。信息对象间的依赖关系通过箭头标示的交叉引用说明。然而，在层次形式，聚合和参考关系间产生了一个差别。 (见 图 24: 扩展的实体关系模型和SAP实体关系模型的表示)
层次形式关系表达了在信息对象间单方面有关存在相关性。
聚合关系对应于基于扩展的实体关系模型方法上的关系类型的形成。
参考关系描述了重新解释的实体类型和经过扩展的实体关系模型（eERM）方法例证的主要实体类型间的逻辑相关性。
特殊化用一个三角形表现，以此类推扩展的ER模型。
为了传达一个建模技巧的概念，图 24: 扩展的实体关系模型和SAP实体关系模型的表示 说明了关于扩展的实体关系模型和来自SAP-ER模型(见: Seubert, SAP-Datenmodell 1991, p. 94)的特征的一个例子。
这清楚地指出，基础的主体内容能被没有任何信息损失地转成这种表示形式。
在一个数据模型的创造程序被完成之后，SAP-ER模型是描述它的一种形式。由于在SAP-ER模型中的信息对象的面向图表的排列，在更复杂的数据模型中显著地需要提供更快的导航和定位。
图 24: 扩展的实体关系模型和SAP实体关系模型的表示
IE 数据模型
恰如SAP实体关系模型符号，对于实体类型间的关系的表示IE符号不提供对象类型。
下面的 图 15:在IE表示中的数据模型 给除了在IE表示中的一个数据模型的一个例子。
图 15:在IE表示中的数据模型
SeDaM模型
SeDaM (语义数据模型)数据模型符号是一个BASF AG 的符号。
这种符号对于实体类型间的关系的表示也不提供对象类型。
实体类型不因而从左到右组合(见 SAP结构化实体关系模型符号)
对象类型数据簇 和一般化类型 也是可利用的
图 16: 在SeDaM符号中的数据模型说明了一个在SeDaM符号中的一个数据模型的例子。.
图 16: 在SeDaM符号中的数据模型
在此书的附录，你会发现SeDaM 模型的所有可能关系的一个摘要。
可扩展的实体关系模型（eERM）的大部分重要概念和表示形式的摘要
来自可扩展的实体关系模型(eERM)的基本结构元素和设计运算符的概念和表示形式在图 1: 可扩展的实体关系模型概念和表示形式被总结。(见 Scheer,工业业务过程 1994, p. 45)。
图 2:可扩展的实体关系模型概念和表示形式
物流建模— 物流图
为了在过程模型中说明物流(具有物流扩展的事件驱动链（Eepc），具有物流的过程链图（ PCD）xe "PCD with material flow" xe "Material flow:PCD")，物流以输入输出功能的形式分配给业务过程单独的功能。 相似于信息对象对功能（信息的转换通过功能说明）的分配，这种分配描绘了输入物流类型到输出物流类型的转换。
在物料图中你可以定义物料类型，把它们按层次形式组合，按物料类分类。
定义: 一个物料类型说明严密地具有相同物料特征的单独的物料的代表。
定义: 相似的物料类型能被结合起来形成一个物料层。为这样做，相似的问题依据不同的分类标准能被定义。换句话说，一个物料类型能分配于几个物料层。
物料类能分配给物料包装类型。这指出特定的物料类型仅能以独特的物料包装类型形式被传送。
物料包装也能被定义，按层次形式组合和分类。这可举例说明，例如，复杂包装交易单元的结构和限制.。
定义: 一个物料包装对象描绘了严密的具有同种特征（例如，物料特征）的单独物料包装的代表。
定义: 相似的物料包装类型能被结合起来形成一个物料包装层。为这样做，相似的问题依据不同的分类标准能被定义。一个物料包装类型能分配于几个物料层。
图 18: 一个物料图举例 指出了包含其结构层次和分类的物料图。.
图 18: 一个物料图举例
基于活动的成本计算数据模型
CD 图
CD（成本点图） 图的应用范围是基于活动的成本计算(见集成信息系统体系结构（ARIS)体系结构作业成本计算（ ARIS ABC）)。成本点的层次结构在CD图中说明。
www定义: 一个成本点对于估算一具体过程的成本是度量/参考值的一个有意义的单元。参考值应是一个可操作值，这个操作值简单地起源于可得到的信息资源和成比例的成本估价残余。.
因此，成本点仅对于绩效的数量变量或诱导过程能被定义。成本点对于绩效不确定性过程不能被定义 ，例如，“管理部门”。成本点的一个例子将是关于“一个街道柏油路”“街道的长度”的过程。 .
成本点的层次结构在CD图中通过直接连接“测定关于某某的成本量”类型得以说明。.“CD关系分子“和”CD关系分母”属性在这种关系上必须被保持，它被假定为值1。两种属性的份额决定了关于过程计算的两种成本点间的数量关系。.
在图 19: 一个CD图举例给定一个例子。它显示了两个成本点“汽车号码（豪华轿车）”和“门号码”。为了指出每一辆豪华轿车拥有四扇门，在“汽车号码（豪华轿车）”成本点对“门号码”成本点关系上“CD关系分子”属性必须设定为“4”。
图 29: 一个CD图举例
成本点分配于过程视图中的单独处理。在处理中对于每个功能的用法要素能从成本点层次结构自动地被决定。
成本分类图
成本分类图的应用范围是基于活动的成本计算(ARIS 作业成本管理xe "ARIS: ABC")。成本分类的层次结构在成本分类图中说明。
定义: 成本分类用于构建所有起于成本点（履行）创建和估价的成本。问题是：引起那种成本？
例如，材料成本是用于材料和记录资产减少量的折旧的成本类。
总成本能依据不同的标准构建。如果成本依据常用的生产要素划分，这导致一个人工成本（例如，薪水，佣金），材料成本（例如，原材料成本，机器折旧），资本成本，第三社会服务提供者的成本（例如，运输费，电费）和税款，费用和捐款的构建。成本类能依据重要的操作功能更深一步地划分，诸如采购成本，库存成本，生产成本，管理成本和销售成本。两种结构都能被更深一层地精确。
成本类的层次结构通过“是最高级”类型的直接连线说明。.
成本类的一个重要属性是“绩效评价“。它说明了利用其度量成本类的单元（例如，工资小时和房间的平方米成本）。
图 30:成本类图举例给出了一个对应于以上提过具有一个人工成本子结构的应用常用生产要素分类的构建的成本类图。
图 30:成本类图举例
在集成信息系统体系结构（ARIS)体系结构作业成本管理中（ ARIS ABC），xe "ARIS: ABC" 一个成本分类图能被分配于一个基于活动的成本计算实例中。一个成本中心视图列出了所有在基于活动的成本计算实例中将要被分析的成本中心。对于每一个成本中心和必须的值集（每一个依据计算方法，成本比率，成本量和/或成本中心绩效），能定义几个成本类。在成本分类表中，通过一个成本中心视图，对于每个成本中心能描述其它事实。
项目管理数据模型
信息载体图
信息载体图是具有集成信息系统体系结构（ARIS)工具库（ARIS Toolset）项目管理的一个可选择成分。它被分配于数据视图的定义规范中并且以文档，日志，和集成信息系统体系结构（ARIS)体系结构图集成信息系统体系结构（ARIS)体系结构图集成信息系统体系结构（ARIS)体系结构图集成信息系统体系结构（ARIS）体系结构图的形式记录引入和引出的数据。
作为一个取值簇的分配，集成信息系统体系结构（ARIS）体系结构模型能在PPCxe "PPC" (项目过程链， 见过程视图的需求定义xe "Project process chain")得到描绘。结果，数据在联合簇中通常能被详细说明。通过属性链1到链3，集成信息系统体系结构（ARIS）工具库显示和访问实际上必须的文档，例如，一个单词的处理文件，。
图 31: 信息载体图
设计规范
关系图，属性分配图
在设计规范里，在需求定一种设计的逻辑数据结构被转换成一种描述形式，即靠这种描述形式具体的数据库系统被建立。在此文中，集成信息系统体系结构（ARIS)体系结构（ARIS）引用关系模型的概念。
关系图和属性分配图对于定义现有的关系和属性以及它们对在需求定义中介绍的信息对象的关系是可利用的。
在关系图中，首先，必须的关系可被详细说明。
定义: 一个关系通过它本身的属性说明一个实体类型。它是单独属性的值域的所有可能结合的一个子集。
下面的图说明一个关系：
图 1: 一个关系的表示
输入ER模型的每一个实体立即在关系模型中组成一个关系。当转换关系模型的关系类型时，在决定对一个特殊的关系类型是否应创建一个适当的关系中，集的容量是一个非常重要的方面。
对于每一个简单关系，关系图能指出那个可扩展的实体关系模型 （eER）的实体或关系类型被说明。
除此之外，一个关系通过列示它的属性能被更进一步说明。不管一个确定的属性是否充当关键属性，外部的关键属性或者描述性属性也许通过选择一个特别的连接关系和其属性的连线被定义。另一方面，每一个简单的属性对来自需求定义的ER模型属性的关系能被确定那一个映射它。
图 2: 需求定义的属性和数据对象的分配
为了减少表示的复杂性，每一个关系的属性能在关系本身的的属性分配图中定义。在图 3: 属性分配图 举例说明这些。
图 3: 属性分配图
在设计规范里，需求定义的数据簇通过适当的对象类型实现。基于数据簇定义的视图定义成如下：
定义: 通过一个视图我们来了解建立在大量关系上的逻辑视图。
属于一个视图的关系也能在一个关系图中说明。在图 4: 视图定义.中举例显示。
图 4: 视图定义
在通过适当的关系的关系图中没有映射在ER模型中的1:n关系。通过结合高级实体的关键属性到次级实体类型的关系映射关系。在这过程中，最初的关键属性成为关系的外键。
关系模型中映射ER模型中关系类型的属性，也能通过在关系图中的连线来表现(见 图 5:一个ERM 关系类型对一个属性的分配 ).
图 5:一个ERM 关系类型对一个属性的分配
在这个手册的附录你会找到关系模型的所有对象和关系类型的一个列表。
系统接口模型的建模—— 系统属性，系统属性域
图类型系统属性主要设计成去执行来自ARIS 工具库的面向出口任务的数据。 这种图类型允许在一个层次结构上组织实体类型，事件，技术术语，功能，信息载体，组织单元和人员，并且依据它们的数据处理需求唯一和完全地说明他们。根据惯常的数据库需求，你能区别下面的类型：原始和外键，描述性和强制性的字段。为了确定这些数据对象的域类型，你可以分配图类型系统属性域（见如下）。
对照ERM 属性，系统属性的主要特点是面向接口数据的表示和管理，系统属性对象包含两个能充满相关信息的值域。
下面的例子指出了，关于一个项目——在ARIS 工具库中定义过的，的报头定义的一个摘录——针对于一个项目管理系统的传送。
图 1:一个系统属性模型举例l
图类型系统属性域 根据数据类型定义了系统属性对象，比如，它指出了域类型char, int, date和域长度。当数据输出到外部的系统时,它主要用于提供信息。
图 2:系统属性域
实施描述——表格图
一个数据库系统的表和字段能在表格图中得到描述。xe "Model:Table diagram" xe "Implementation: Data view" xe "Data view: Implementation" xe "Table diagram"
图 -1: 表和字段的表示 以图的形式说明了表和字段。
图 -1: 表和字段的表示
对于每个表，能描述分配过的字段。对于更一步的说明，一个分类索引和它的域能分配于每一个单独字段。在 图 2: 多个字段的分配 举例说明这些。.
图 2: 多个字段的分配
因为在一个1：1 基础上（例如，对于数据库执行的前提），关系的模型的关系没有必要转换成表和字段，表和关系或者实体类型间的多种关系可能发生。通过选择各自的连线，在表格图中能说明这些关系。利用对象视图（物理的）在表格图中说明在需求定中决定了的数据簇或在关系的模型中定义过的视图。xe "View:Physical".
数据库用在公司中的表格和字段的转换和文件不必绕道定义一个关系的配置。这就是为什么实现关系类型不仅能在关系（或属性）和表（或字段）间，而且在实体类型（或ER模型属性）和表（或字段）间得到说明的原因。.
它用来显示哪种关系和类型得到执行或者——不考虑关系的定义——哪种实体类型，关系类型和ERM属性通过图解的表格和字段映射。图 3:需求定义和设计规范的对象分配 给出了这两种表示形式的例子。
图 3:需求定义和设计规范的对象分配
为了确定某几个表和字段在公司里的准确位置，必须尽可能地定义一个表的每一个单独的范例。假定当组织单元假定对某几个表和字段拥有访问特许权时，同样地要求如此。早期介绍的对象类型 表 确定了在类型层次上一个物理表和字段的逻辑结构。每一个这样定义的多种范例也许可利用——贮藏在不同的媒体上——在一个公司的不同位置。作为说明这个论据的一个方法，介绍对象类型表（范例）和字段（范例）。.
由于这些对象，能准确地确定计算一个表或一个字段的范例。在图 4:一个表的范例 范例说明了这种连接。
图 4:一个表的范例
在这个手册的附录，你会发现表格图的所有对象和关系类型的一个列表。.
SEQ Kap \r4 \h组织视图
需求定义
组织业务环境
企业是一个能简单地被分成多个单元的复杂的社会建筑。为了处理这样的一个联合体，确立了一定的模式以及建立了标准，xe "Requirements definition: Organization view" xe "Organization view: Requirements definition" xe "Architecture of integrated Information Systems (ARIS): Organization view – Requirements definition"这个过程的结果产生了组织。直到最近，作为开发信息系统一个方面的组织分析，它的任务已很少成为被研究的对象xe "Organization" 。更新的商业概念，例如精益生产、精益管理xe "Lean Management" ，或者紧密依赖于自己独立检测领域的计算机集成制造，甚至组织方面，受到了关注。因而，ARIS体系为组织结构提供了一个独立的描述视图。
在企业的结构组织中，我们要把组织结构和程序组织区别开来。
组织结构包含了一些标准，通过这些标准，企业能被平稳地构建。程序组织包含了那些用于完成企业任务的标准，从任务执行者的分配功能这个意义上来说，有关的任务结构能在ARIS体系结构的控制视图中表现出来。简单地说，组织视图是允许组织结构分析的构件。
着眼于减少企业内部调和的理想的企业组织设计需要一个对它的业务环境和目标的最小依赖。因此， 普遍地，有效而理想的组织结构，在涉及结构的这个意义上来说，不能被定义。
如何正确地构建组织单元可能依赖于各种各样的标准。
功能结构是非常共通的。这儿，一个部门功能（采购、生产、筹资与核算、销售）负责所有的产品和销售范围。雇员高度熟练的优势被信息上的巨大需求和功能领域间的协调的劣势平衡了。
信息系统的设计和使用已长久地被导向于企业的功能分解。然而，在这种类型的一个结构中当通过处理同一类型的互相连接的数据对象来分析整体过程链时，独立功能间的相互关系很难确定。
因此，集成数据处理的论述导致了一个相容数据库的需求，该数据库将支持不同的功能。 然而，功能集成的目的实质上是消除我们在功能结构上固有的目标来简化复杂性。xe "Function: Integration"
为此，当处理功能集成的目标时，其它组织细类的标准会被频繁地使用。这些标准可能就存在于销售领域和产品的组织细类。图-1:就产品而言的组织分解 展示了组织细类。(见 Scheer, Wirt schaftsinformatik 1994, p. 26 f).
一个基于区域的组织结构的组织单元按照这个特殊企业或企业部门的局部分配被指定。 这种结构由于其特殊领域方面，显然适合于销售功能。
图 1:基于产品的组织分解
一个面向产品的组织结构为每一个产品和/或产品组定义了组织单元，尽可能多的功能是相关的，因为产品组是集成的。程序的目标是减少对功能结构固有联系上的需求，然而，这致使必须在基于产品组的子系统间进行协调。
为了抵消这些影响，要频繁地使用混合的组织窗体。 图-2:混合的组织窗体显示了一个购买的例子。(见 Scheer, Wirt schaftsinformatik 1994, p. 26 f)
图 -2: 混合的组织窗体
使用纯粹的功能结构意味着中心购买要对所有的产品组负责。在这个组织窗体里，出现于产品间的协和作用能被体现了出来；但是一个基于所有子功能的单独的购买程序将导致许多的调和问题。购买功能根据各种各样的产品组被分解，必须为每一个产品组确立单独的采购部门以执行所有的采购功能。 例如，当选择卖主或者谈判框架协议时，调和作用只能在经过了大量的调和工作的情况下获得。
如图 -2: ：那些期望得到高度协调作用的购买功能在同一功能水平上被分离，也就是，它们被中心购买单元所执行。必须阐述个别计划组的特殊需求和限制的功能根据那些计划组以一种面向对象的方式被分开。因此这些功能能立即以个别计划组的处理程序集成。这意味着这些过程能在分开的单元中被有效的处理，当这些单元之间的相互联系得到上级和中心调和水平注意的时候。
这些灵活的组织窗体由于它们面向过程的方法在ARIS体系结构中被给予了特殊的重视。高度面向会计的方法（例如利润中心概念）需要组织结构的形成，在这些组织结构中各种各样的分离标准同时被分析。
组织图表
组织图表是一种典型的表示组织结构的表。这类图标反映了组织单元（如任务执行者）和它们相互间的联系，它依赖于所选择的结构标准。
定义: 组织单元是为完成业务目标而完成必须要完成的任务的任务执行者。
关联是组织之间的链接。一个例子对此做了说明，如图 3 ：组织图表
我们区分链接组织单元的各种连接类型是为了更好地说明上级/下级的联系。在这篇文章中，连接可能是下面几种意思中的一个：
技术上优先
训练有素上优先
是…的构件
然而功能职责在方框中已被表现出来，组织图表举例说明了业务任务的分配
图 3:组织图表
为了给企业内个别的工作提供一个适当的工作描述，一个独立的对象类型职位是可利用的。如例图 4：组织图表，这个对象类型被表示为职位和员工的配置。一个组织单元能被指定为多种职位。在组织单元间，连接的意思与此相符。
职位和组织单元能被指派给那些有能力占据有争论的职位的人。ARIS 也包含了一些为员工而分离的对象，这些对象也在图 4：职位和员工分配的组织图表 中被举例描述。对组织单元的人员委派表示这个人是一个被指派的组织单元的雇员。另一方面，与独立职位的联系定义了目前企业内的工作覆盖面。一个例子可以说明，如图 4：职位和员工分配的组织图表.
图 4: 职位和员工分配的组织图表
组织单元及个人也能被指定为一个类型。因此，无论组织单元是一个部门，一个主要部门或者是一个组，他都能被定义。例如，雇员能被指派为部门主管，组的领导者，或者是计划的管理人。
这些类型的分配可以用组织单元和人员类型对象举例说明。 图 5:：展示了一个组织单元和人员类型指派的例子。
图 5:职位类型
使用这些对象类型允许创建一个具有一般业务标准的抽象的画面，该画面有着具体的公司组织单元或雇员。例如，在过程链中，能指定仅某种人员类型被允许执行一种特别的功能或者访问一个特别的信息对象。
企业的组织结构的模拟是网络拓扑的起点，该网络拓扑以设计规范水平定义，以及被假定为用最可能的方式支持组织结构。位于企业内指定位置的网络连接和网络节点是网络拓扑的大部分基础。因此，组织单元的位置是需求定义和设计规范之间的最重要的链接。所以，每一个组织单元都能容易地在需求定义水平上被指定适当的位置。 关于此的例子，如图 6：位置分配
图 6: 位置分配
位置能设定在同一层次的任何地方。位置可能是一个完整的生产车间，一幢特殊的建筑物或者—当执行一个详细的分析时— 一个独立的办公室，甚至是一间大房间里的一个独立的工作站。例如，在设计规范中，指派一个组织单元的独立工作站的网络节点是可能的；定义102室内三个网络节点必须时可利用的，这也是可能的。
图 7: 描述了一个位置层次的例子。
图 7:位置层次
轮换表
轮换表能被分派给人力和物料资源，也能指定一项可得到的资源。
轮换表被分派给组织图表或eEPC中的资源。轮换表基本上能被分派给任何人力或物料资源如果有一个人力资源层次，所用的轮换表将总是在最低层次水平被发现的一个表。
轮换表是一个多重水平对象的模型。在最低水平上，是中断 类型对象。中断是在轮换期内的日常时间间隔，中断期内不干任何工作。中断通过与其有关的中断开始及中断持续时间来定义，由此，相关的开始点总是涉及到中断被分配给哪个轮换。例如，如果轮换在上午8:00开始，中断有2小时的相对开始，那么中断在上午10:00开始。
下层水平包含了轮换 类型对象。轮换是日常时间间隔，在该间隔内需要工作。轮换通过与其相关的轮换开始点和轮换持续时间来确定。轮换可能有一个以上的中断。中断的相关开始时间必须处于轮换期内。
轮换的典型例子是早晨，正午，夜晚和白天的轮换。每个轮换隔24小时重复一次。一个轮换周期是一周的时间间隔或几天的时间间隔，在间隔期内工作被履行。轮换周期决定某种轮换运行或不运行的天数。轮换被与其相关的周期起点以及周期持续时间所确定。如果一个轮换周期将要被不断地重复，这能用周期重复属性 来定义。另外，周期属性 决定了一个周期通常如何被重复。
轮换周期常常需要一或二周的时间。因而雇员一周能拥有一个早晨轮换周期，以及接下的一周有一个正午轮换周期。这个次序能通过轮换周期不断重复。
根据上述的例子，两个轮换周期可以如下被定义。
1. 轮换周期： 相关周期起点 = 0
(早晨轮换) 周期持续时间 = 5 天
循环重复 = 是
周期 = 14 天
2. 轮换周期： 相关周期起点 = 7 天
(正午轮换) 周期持续时间 = 5 天
循环重复 = 是
周期 = 14 天
个别轮换以14天的节奏被重复，因而周期相当于2周。如果同一雇员每4周在星期六将要工作一个早晨轮换，那么第三个轮换周期能被如下定义：
3. 轮换周期： 相关周期起点 = 20 天
(早晨轮换) 周期持续时间 = 1 天
循环重复 = 是
周期 = 28 天
如下，你将通过一个1:n的轮换及轮换周期分配的模型再次了解这个例子。
图 8:轮换表案例
轮换计划是一整套的描述资源工作小时的轮换和轮换周期。该描述只包含周期性地被重复的那部分，管理假期，病假，节日，或其他不工作的日子等特殊规定则不包括在这里面
轮换计划对象类型包括计划起点和计划持续时间属性。这些属性指定了时间结构，在此时间结构内，轮换是有效的。循环重复及周期属性也为轮换计划而存在。
设计规范— 网络拓扑
企业的组织结构正如组织图表所反映的一样能支持使用通讯和信息系统. 这些信息系统的结构需求一般能在网络拓扑帮助下的设计规范里定义。
起始，网络拓扑图表可能包含各种各样的网络图形。
定义: 网络类型描绘了所有完全基于相同技术的独立的网络实例
图-1：一个网络类型的图形显示 展示了一个网络实例。
图 1:网络类型的图形显示
网络能互相连接，同时，因为他们是逻辑结构，所以他们也能被置于同一个层次上。
每一个网络类型都能被指定可能的网络节点和网络连接类型。因此，为企业选择一个特殊网络的技术限制能被立即发现。每个网络连接类型可以包括以某网络节点为结束的节点类型信息。
当谈到硬件构件类型，这可能既指实现已定义的网络结构的网络构件，也指能连接到网络节点类型的硬件构件。
与操作系统或网落类型相似，硬件构件类型并不表示能被识别的单块硬件构件（例如，企业指定的存货编号），相反，它们表示基于相同技术的所有硬件构件。硬件构件类型能置于同一层次上的所有地方。
定义: 硬件构件类型表示所有完全基于相同技术的独立的硬件构件。
与网络节点和连接类型一起，网络拓扑的一种参考模型也能被创建。它显示哪一种硬件构件能被用于实现某种网络连接或节点类型。连接类型的一个例子可能是网络电缆的一种特殊类型。除此，显示哪种硬件构件能被连接到何种网络节点类型上也是可能的。而且，硬件构件类型可能与其它需要创建节点类型的硬件构件类型有联系。图 2: 网络拓扑 描述了关于这样的一个例子。
图 2: 网络拓扑
网络拓扑和需求定义对象间的链接通过两种构造建立。
一方面，组织单元或对每个硬件构件类型负责的职位能指定。
另一方面，定义在企业的什么位置上可能找到一个特定的网络类型、网络节点类型、连接类型、硬件构件类型是可能的。因此，位置是组织视图的需求定义和它的设计规范之间的中心链接。
在这本手册的附录内，你会找到网络拓扑图的所有对象和联系类型。
实施描述
网络图
网络图用于举例说明设计规范所确定的网络拓扑的实现。
通过对象网络，企业的具体网络被注册。网络节点和连接能被每一个网络所确定。
企业内的每一个网络、网络节点和连接的准确位置都能模拟。在全文中, 位置可能是一个完整的生产车间，一幢特别的建筑物，一间独立的办公室或者一个独立的工作站。
图 1: 分配位置的网络图
每个网络连接和节点描绘的硬件构件都能注册。除此以外，也有可能举例描述每个硬件构件的结构设计。 一方面，硬件构件服务于网络连接和节点的实现；另一方面，它们也能被网络节点链接。这种联系也能在网络图内被举例描述。在设计规范水准上为了每一个独立对象，各个对象之间的相互联系能够被模拟。因而它能显示出Zeppelinstr 工厂的网络是版类型的网络。
图 2:硬件构件和位置分配的网络图
在网络图中，两种链接已被建立起来：首先，把网络和设计规范相链接的配置；其次，把网络构件、具体位置和需求定义相链接的配置。
在这本手册的附录里，有将会一系列网络图的对象和联系类型。
物流建模 — 技术资源
为了阐明在过程模型（具有物流的eEPC ，具有物流的PCD ）中的物流，物流被分派给功能输入、输出窗体内的业务过程的独立的功能。类似于功能信息对象（功能所描绘信息的转换）的分派，这种分派反映了输入物料类型到输出物料类型的转换。另外，过程链允许包括物料所需的技术资源信息。在全文中我们区别出操作资源，仓库设备，传输系统以及技术操作提供。
在图表类型技术资源 又可以把这些资源安排在同一层次上，指派一种类型给它们，同时给它们分类。下面的对象类型时可得到的：
xe "Operating resource"定义:
定义: 操作资源是一个企业可得到的并用其完成企业任务的不同的操作资源类型的实例。操作资源通常被指定的库存编号识别出来（例如，生产车间的编号）。
操作资源类型xe "Definition:"
定义: 操作资源类型表示完全有着相同技术基础的独立的操作资源。
xe "Operating resource class:Definition"操作资源类
定义: 相似的操作资源类型能和病而组成一个操作资源类。如此，根据不同的分类标准，类似的问题就能被定义。因此，一个操作资源类型也能被指派给几个操作资源类。
xe "Warehouse equipment: Definition"仓库设备
定义: 仓库设备表示企业在完成其任务时可得到的各种仓库设备类型的实例。 操作资源通常被分派的库存编号识别（例如，生产设备的编号）。
xe "Warehouse equipment type: Definition"仓库设备类型
定义: 操作资源类型表示典型的完全有着相同的技术基础的单独的仓库设备单元。
xe "Warehouse equipment class: Definition"仓库设备类
定义: 类似的仓库设备类型参合并而组成一个仓库设备类。如此，根据不同的分类标准，相似的问题就能被定义。因此，仓库设备类型也能被指定给几个仓库设备类。
技术操作支持
定义： 技术操作支持是技术操作支持类型的实例。一般地，它能通过库存编号鉴别出来。
xe "Technical operating supply type: Definition"技术操作支持类型
定义: 技术操作支持类型表示典型的完全有着相同的技术基础的独立的技术操作支持
技术操作支持类
定义: 类似的技术操作支持类型能合并而组成一个技术操作支持类。如此，根据不同的分类标准，相似的问题就能被定义。因此，技术操作支持类型也能被指定给几个技术操作支持类。
xe "Transport system: Definition"传输系统
定义: 传输系统一个传输系统类型的实例。一般地，通过库存编号或者车间数它能够被识别出来。
xe "Transport system type: Definition"传输系统类型
定义: 传输系统类型表示典型的完全有着相同的技术基础的独立的传输系统。
xe "Transport system class: Definition"传输系统类
定义: 类似的传输系统类型能合并而组成一个传输系统类。如此，根据不同的分类标准，相似的问题就能被定义。因此，传输系统类型也能被指定给几个传输系统类。
在同一层次上安排技术资源图类型的不同的可能性能够使你描述出复杂技术车间的结构。例如，这允许显示一个复杂生产车间的构件以及它们之间的联系。
除了可能性以外，就模拟而言—上面所描述的—你也能为技术资源定义位置分配和组织职责。你从组织图表类型所知道的对象类型位置、组织单元、组、职位和人员都是可得到的。这些对象类型能链接到操作资源、仓库设备、技术操作支持和传输系统对象类型。
一个“技术资源”图类型的实例如图-3所示：
图 3:技术操作图实例
过程视图SEQ Kap \r4 \h/控制视图
必要说明
数据视图对象、组织视图和功能视图之间的相互联系在控制/处理视图中进行检查。xe "Process view: Requirements definition" xe "Process view" 我们想检查的相互联系引起了各视图之间的联系，如图： 2.
首先，检查两种视图之间的相互联系。 这遵循图表，它说明了三种视图之间的相互联系。
组织联合功能 — eEPC, 功能/组织层次图表
功能视图间的链接xe "Function:View" xe "Function/organization level diagram" xe "Model: Function/organization level diagram"和分配功能为目的的组织视图服务在功能树的组织表中定义给任务执行者（组织单位）。 这个任务为它分配的功能定义了组织单位的责任和决策力xe "Decision-making power" 。看着组织分配在过程链(交易过程)中的综合功能xe "Function: Degree of integration" 的描述，例如；交易过程的功能步骤由组织单位来处理。
图 1 说明了一个为组织单位分配功能的例子。在图中，放在左手边的功能被指定组织单位对执行过程负责任。 功能的层次位置已在功能视图（功能树）中阐明，组织单位之间的相互联系已在组织视图（组织表）中被说明。这样，在这里就不须详细说明它们。
图 1：组织单位功能分配
数据联合功能
事件控制 – 事件-驱动程序链(EPC)
xe "Model: eEPC (event-driven process chain)"功能的程序顺序在交易处理中以过程链的形式来表达那里每一个功能的启动和终止事件都会被详细描述。启动和终止事件 xe "Start and end events" 给予每一个功能。事件xe "Event" 不仅引发功能而且以功能为结果。
解说: 通过事件xe "Event" 我们知道一个事实，信息对象具有相关交易状态，它控制或影响交易过程中更深层次的程序。事件引发功能并以功能为结果。与功能相比，它 In contrast to a function, which is a time-consuming occurrence, an event is limited to one point in time.
信息对象变化的状态可以参考第一次发生的对象(例如：接受订单)或者利用不同属性(例如：引用不合格品)表达状态修改。 信息对象和属性在ARIS数据视图中描述，过程链的事件驱动表示方法是数据视图和功能视图之间的链接。因此，它属于 ARIS 控制视图xe "Process view: ARIS"。
事件 xe "Event: Graphic representation"用图表示成六角形。这种描述不仅包括信息对象本身 (订单) 而且包括它的状态修改 (收到的)。 图 2 说明事件
图 2: 事件 (图解表示法)
解说: 事件引起功能并以功能为结果。以一定顺序排列事件和功能的联合，因此被叫做事件驱动过程链的创立 (EPCs)xe "Event-driven:Process chain" xe "Process chain:Event-driven" xe "EPC"。依靠事件驱动过程链(EPC)，交易过程程序xe "Event-driven process chain (EPC)"被描述为事件逻辑链。
EPC 的实例显示在 图 3中。 因为事件决定哪个状态或联系会引发功能哪个状态会定义功能的结束，EPC的开始和结束节点总被事件排列。几种功能会同时从一个事件中引发，反之，一种功能也会由几个事件引发。这些分支和处理循环在EPCxe "Branch:Of event-driven process chain" 中使用一个循环型连线来表示xe "Operator" (see 图 3)。然而，这些联系不仅 作为图表连线服务而且在连接对象间定义了逻辑链接。
图 3: EPC 实例
图 4: 规则实例
在第一个启动事件的例子里 图 4，由AND操作来链接。这意味着程序发布操作 只有行程安排被建立起来和必要资源被核实后才启。换句话说，程序开始前事件必须发生。第二个实例说明了一个唯一的OR操作xe "Operator: Either/Or" xe "Operator: And" xe "Operator: Or" xe "Operator: OR" xe "Operator: XOR" xe "XOR operator" xe "OR operator" xe "And operator" xe "Either/Or operator" xe "Or operator" xe "Operator: Rules" xe "Rule: Operator".。检查厂商报价功能可以导致接受或拒绝报价。然而，两种结果，不可能同时产生。 除了这两个案例和唯一的OR操作以外，还可以想到更复杂的关系。通过上下文，一个一般规则xe "General rule:Operators"可以在EPC中表示出来，这在后面会以规则图表的形式被详细描述。
因此，我们主要区别两种操作类型的不同之处：
事件操作xe "Event: Operator" xe "Operator: Event" 和
功能操作xe "Function: Operator" xe "Operator: Function".
你会在中图 5发现所有可能的事件和功能操作 (see Hoffmann, Kirsch, Scheer, Modellierung mit Ereignisgesteuerten Prozeßketten 1993, p. 13)。
图 5:链接操作
联系上下文，特别的关注必须付于存有功能操作的约束。由于事件不能做出决策（而功能可以），引发事件不能使用OR或XOR操作来链接。
下面，使用案例来说明可能的操作。
1. 链接引发事件：
a. AND 操作
图 6: AND 引发事件的操作
所有的事件发生后功能才能被启动。
b. OR 操作
图 7: 引起事件的OR操作
至少有一个事件发生后功能被执行。
c. XOR 操作 (Either/Or操作)
图Figure 8:引发事件的 XOR操作
恰好有一个事件（只能有一个）发生之后，功能及被启动。
2. 创立事件的链接
a. AND 操作
图 9:AND创立事件操作
功能导致所有事件的发生
b. OR 操作
图 10: OR创建事件操作
执行功能至少引起一个事件发生。
c. XOR操作 (Either/Or 操作)
图 11: XOR创建事件操作
执行功能导致一个最大量的事件发生。.
3.与创建事件功能链接.
a. AND 操作
图 12: 创建事件功能的AND 操作
只用所有功能执行后事件才发生。.
b. OR 操作
图 13: 创建事件功能的OR操作
至少有一个功能执行后事件才发生。.
c. XOR操作 (Either/Or 操作)
图 14: 创建事件功能的XOR操作
恰好有一个（只能有一个）功能被执行后事件才发生。
4. 引发事件的功能链接
a. AND 操作
图 15: 引发事件功能的AND 操作
事件引发所有功能
b. OR 操作
事件没有决策力! 操作不能建立!
c. XOR 操作
事件没有决策力! 操作不能建立!
除了在事件驱动过程链中被描述外这些操作还在过程链图表中的事件和功能列（见第三章）中以图表形式被表述。因为功能既而在过程链图表中被定制，分支和处理循环会以混乱的方式被表述出来。
功能分配图表 (I/O)
除了 xe "Model: Function allocation diagram"表达在中解释过的事件控制之外，输入数据到输出数据的转化和数据流在功能之间的表示法是ARIS机构体系中数据视图和功能视图可能的操作类型。输入数据到输出数据的转换可以在如此称呼的功能分配图表(I/O)中描述，它与在其他模型中使用的单纯的输入/输出图表xe "Input/out put diagram"基本上相符。 一个功能分配图表(I/O)的实例在 图 16中显示。输入决定发送日期 功能的数据是零件数据，存货数据，物料数据清单和运送数据。 检查数据检查输入和输出的数据。功能分配图表(I/O) 从而包括功能视图和数据视图信息对象的功能。箭头决定信息对象是专门服务为输入数据，输出数据还是输入/输出数据。 更多详细的描述是可能的，显示实例为一个特别的功能已经创建或删除一个信息对象。 信息对象成为数据串(看 图 16)，标题或关系类型甚至是数据视图的属性，依赖于详细的程度。
图 16: 功能分配图表(I/O)实例
上面的实例阐明了功能分配图表实际的对象是代表了功能的输入/输出数据。
除了包括一个功能的输入/输出数据和事件外，所有其他对象都是可用的它们可以被分配到eEPC中的个别功能。 用户这样可以在eEPC图表中限制过程链模型到事件或功能，还可用所有关于个别功能的附加关系分配功能分配图表(I/O)。 这确保交易过程被描述的更清楚—也可以解释模型类型的新名称。 在功能分配图表中一个更为详细描述的实例会在图 17中显示。
图 17 功能分配图表
除了单独表达数据转换为功能分配图表(I/O)之外，信息还可以包含在 EPC中。这在图 18 中说明。这里，功能和信息对象间的操作者与功能分配图表(I/O)中的操作者具有一样的重要性。 如果它们包括在多个分支的过程链中，那么，会产生相对混乱的描述结果。
图 18: 带有输入/输出数据的EPC
在 PCD (过程链图表)中，对象按照列所描述的来编排。 EPC 描述允许随意安排对象。然而，添加输入/输出数据会引起模型混乱。因此我们推荐 PCD 描述尤其对于交易过程按照顺序执行。 下图将带有输入/输出数据的EPC图 18显示为 PCD (看第 章).
图 19: 带有输入/输出数据的PCD
信息流图表
信息流图表xe "Model: Information flow diagram" 如前面所提及的适合于说明功能间的数据流。. 为此，两个功能可以在信息流图表中被一个数据流对象联结起来。这个对象表示有一个数据流从来源功能流向目标功能。为了更准确地说明所显示功能之间的数据对象流，数据流对象可以一定的层次来设置，允许依次分配数据模型到对象中。这一数据模型表示被在功能间转换的信息对象。信息对象可以是数据串，实体类型或ERM属性，取决于被检查功能描述的程度。这种描述类型的实例显示在图 20中。
图 20:带有开放分配的信息流图表
事件图表
事件xe "Event diagram" 说明信息状态已经转变。这样，每一个事件涉及到数据模型的特殊信息对象并及时说明了给定点下信息对象的状态。
首先，事件在一个由顶向下的操作过程(例如：客户订单)中被粗略的描述。下面的过程模型层包括更详细描述过的事件说明。如果它们被结合在某一情形下，事件会出现在粗略的描述层中。例如，发生事件如客户数据检查，订单标题注册，订单项目注册，和可行性检查的总数可以说明客户订单的状况。
你可以使用事件图表在粗略或详细描述模型层显示这些事件的相互关系。为此，你可以在粗略层中（层次）分配一个事件图表到事件中，它能够在详细描述层(也是依靠规则操作者)中按顺序显示事件和它们之间的操作者。此外，你可以包括在图表类型中的数据模型的信息对象并将它们链接到事件中。这样你可详细说明描述给定信息对象的状态变化的事件。 图 21 显示了一个实例。
图 21:事件图表实例
功能—组织—数据
eEPC/PCD
在 eEPCsxe "Model: eEPC (extended event-driven process chain)" 和 PCDsxe "Model: PCD (process chain diagram)"中表达了相同的事件。
到这里我们只处理了两种视图，现在介绍第三个。这意味着过程链部分视图xe "Process chain"再次从全部视图中组合出来，所有ARIS结构元件的交互作用会被检查。 我们最初着手的过程链再次被详细的显示出来。然而，检查不是集中于为各自对象从单独视图中摘取的细节而是这些对象之间的操作者。
22 表示一个过程链xe "Process chain" 包括所有视图。代表数据视图对象的事件被放在第一栏。箭头终止于第二栏包括过程链功能。这样，第一和第二栏定义了事件控制xe "Event:Control"。数据对象在第三栏描述了个别功能之间的关系。第二和第三栏的 PCDxe "PCD: Columns" 定义了过程链的数据流。与第章节所介绍的PCD相比需求定义过程链图表没有列来定义处理类型和IT系统。这些事实需要取得公司的实际情况xe "Actual:Situation"，不过它们不是交易过程相关主题描述的部分。 对执行过程链个别功能与责任的组织视图的组织单位xe "Organization:View" 在第四栏定义。
图 22中描述的过程链也可以表达为 EPC (见 图 23)。
图 22:过程链实例 (必要的说明)
图 23:带有功能，数据，组织单位和事件的 eEPC
价值附加链图表
首先，价值附加链图表xe "Model: Value added chain diagram"服务于识别公司中的功能的目的，它直接包括在公司附加值的创造中。这些功能可以通过创造功能顺序联结起来形成价值附加链。价值附加链的实例见图 24.
.
图 24: 价值附加链
在价值附加链图表中功能可以分层安排，类似于功能树。这种表达总是包括 the process-oriented super- and subordinations.
价值附加图表不仅允许表达 super- 或 subordination 功能，和可以显示组织单位和信息对象的功能操作者。当分配组织单位到功能中时，我们区分----相似过程链----在功能的主题关系责任中，它的IT责任和真实的执行。
在手册的附录里你会发现一张在价值附加图表中可用的附加关系的清单。
规则图表
在过程链中，你可以像操作者一样使用规则去说明事件和功能操作者。通常，这些规则表示法所显示的合理的操作者十分复杂—特别是你操作规则的例子。为避免由于这种表示法而使过程链太复杂，你可以使用eEPC或PCD中的普通规则操作者。 你可以联结这些普通规则操作者到规则图表xe "Model: Rule diagram" (层次!) 它可以按顺序描述复杂规则的所有细节。
图 25:规则图表中复杂操作的说明
通信图表
大的参考模型包括大量的过程模型。包括深入过程模型的组织视图元素，阐明了元件在处理过程中与其它的交流。通信图表xe "Model: Communications diagram"允许依照组织单位之间的通信分组所有过程。
因此，通信图表显示了所有组织单位彼此之间的交流。组织单位销售，例如，通过通信对象类型联结到组织单位。通信类型对象可以被分层说明。它们可以被联结到处理选择矩阵图表类型。处理选择矩阵显示了所有得过程在这里面销售部门与客户沟通。
分类图表
xe "Classification diagram"分类图表xe "Model: Classification diagram"提供机会通过分配功能到对象类型等级来区分功能。分类可以依照不同的分类标准来说明。为了说明分类标准，你可以把对象类型对象类型分类和对象类型分类标准联结在一起。
输入/输出图表
输入/输出图表xe "Model: Input/output diagram" xe "Input/output diagram" 提供总体视图表达引入的和流出的数据及信息运送者。为这个模型，每个图表格中只能放一个符号，例如，在用线与其他区域分开的区域里。 顶行包括由特殊功能（输出）创建的数据或信息运送者。同样，左栏的模型数据或信息运送者符号引入了特别的功能（输入）。如果功能需要几个输入/输出符号，它们会以出现的复制来创建。
看不见的关系 (含蓄的) 提供输入和创建输出 会在功能和输入/输出图表的数据或信息运送者符号xe "Information carrier symbol"创建的过程中自动建立起来。
下面是一个输入/输出图表的简单的例子。
图 26:输入/输出 图表
目标导向建模
分类图表
xe "Model: Class diagram"对象—导向延伸的 ARIS 概念允许分配分类功能给信息对象。这意味着在数据视图中可以被描述的所有信息对象能够通过分配分类功能（方法）和描述属性（数据内容）给它们而获得分类特征。这种分配在分类图表中完成。当分配一个分类图表到一个信息对象时，你分配给这个信息对象一个分配功能。
分类图表被唯一的分配到个别信息对象中包括以下要素 (在ARIS结构中对象类型的图解符号)：
分类描述的信息对象
分配到等级里的属性清单
因为特殊分类状况而发生事件的清单
分配到等级和引发或被引发事件的功能视图的功能清单
图 27 显示了客户订单分类说明实例。
图 27: 客户订单分类的分配图表
过程变量
过程选择矩阵
过程选择矩阵xe "Process selection matrix" xe "Model: Process selection matrix" 通过分配主要过程到个别情节来显示不同的过程情节。
然后，你可以测定哪一个情节过程功能会在企业中发生。为此，应用程序系统的所有主要功能（情节功能）或参考的工业模型都要包括在内。
下面的图解符号类型是建造过程选择矩阵模型可用到的。
情节
过程
主要过程
定义: 情节表示选择矩阵中的情节过程，它成批安排不同的主要过程。
定义: 过程表示情节过程的功能，它在参考模型中用过程模型更为详细的描述。
定义: 主要过程表示功能树里的主要功能，过程（来自于情节过程的功能）被分配到它里面。
28 显示处理选择矩阵实例
图 28: 处理选择矩阵 (SAP R/3 参考模型的部分视图)
物流建模
你可以使用过程模型 xe "Modeling: Material flow"(eEPC and PCD)来描述信息流xe "Information flow"，和物料转换。要在交易过程中表示物流，ARIS 提供给你单独的图表类型 (带有物流的eEPC)xe "eEPC: With material flow"，它是eEPC图表类型的延伸。
带有物料流的eEPC
除了 xe "eEPC: With material flow" xe "PCD: With material flow" eEPC 对象类型，下面的对象类型也可以适用于带有物流的 eEPC xe "Model: eEPC with material flow"。
物料类型
包装材料类型
操作资源类型
操作资源
技术操作供给类型
技术操作供给
仓库设备类型
仓库设备
运输系统类型
运输系统
物料类型对象类型可以通过引入或流出关系而被联结到功能对象类型。对于引入关系，物料被定义，它是功能输入必须的。通过上下文，你可以选择相关的关系类型定义功能消耗了部分、全部还是没有消耗物料。流出关系说明了功能创建的物料类型。
技术资源对于物料转换是必须的。在过程链中，你可以联结它们到功能对象类型。要说明可选的可能有用的资源，除了提供需要关系类型外还有需要选择关系类型。
如果物料在功能中要包装，就会需要某一材料类型。为了说明相关的包装材料类型，你可以在功能和需要的包装材料类型之间建立一个关系模型。
29 显示带有物流的 eEPC 和相关的技术资源类型和包装材料类型。
图 29:带有物流的 eEPC (局部视图)
物流图表
你可以使用物流图表xe "Model: Material flow diagram"描述功能之间的物流。在建模过程中它们和信息流图表被相同对待。 在物流图表中，你可以通过物流关系联结两个功能。这种关系表示物料从资源功能流向目标功能。如果你想更详细的说明所显示功能间的物流，可以通过为关系建立层次的方法将物料图表分配到物流关系中。物料图表说明物料或物料类型在功能间的转换。
eEPC 列/行显示
下面的描述类似于eEPC – 行描述xe "Model: eEPC as row display" xe "eEPC as row display"。
给予eEPC的大多数描述同样适用于 eEPC – 列描述 xe "Model: eEPC as column/row display" xe "eEPC: As column/row Display" 图表类型，所不同的是，模型中的所有符号被分配到不同的栏内。好处是这种表示法更易于说明 eEPC。组织xe "Organization: Element" 和应用程序系统元素xe "Application system: Element" xe "Element: Application system" xe "Element: Organizational" 被放在图表的标题。所有其它的符号被放在每一栏的第二行。
所有swimlane模型的特性xe "Swimlane model" xe "Swimlane model: eEPC as column display"，例如，以栏和/或行建立的模型，是自动建立看不见（含蓄的）的关系。例如：当建立应用程序系统和功能时，含蓄的关系 xe "Implicit relationship" xe "Relationship: Implicit"支持 会在eEPC -列显示的默认栏内自动创建。执行关系会在组织元素和功能之间暗自建立。使用者也可以添加下面的附加栏，它们按照含蓄关系来命名。
捐献给
决定
对….负IT责任
技术上对…负责
取消时必须要被通知
必须通知…的结果
必须被通知….
接受
担任咨询角色
下图显示了eEPC列显示器实例。
图 30: eEPC – 列显示
eEPC – 列显示和 eEPC – 行显示的不同在于建模导向。在 eEPC –列显示中建模由顶向下，在eEPC – 行显示中则是由左至右。
SAP ALE 模型
SAP ALE 类型模型(SAP应用连接授权) 用于建立功能与应用之间联系的模型。
SAP ALE 过滤器模型
根据系统（应用）中不止一次被用到的功能类型， SAP ALE 过滤器显示出标准。按照这一点来说，过滤对象类型在分配模型中充当一个分离标准。
SAP ALE消息流模型
The SAP ALE 消息流模型用消息流对象类表示消息流。报国系统与功能之间的方向。
SAP ALE 消息类型模型
SAP ALE消息类型模型凭借所涉及的数据和交易用消息类型划分在分配系统中交换的消息。
其他模型
业务控制图
业务控制图显示了一个过程或功能以及他们控制的潜在危险。
定义: 风险意味着不能达到预期过程目标过程的潜在危险。
定义: 风险控制是减轻或消除风险的一种普遍方式。
定义: 风险解决意味着执行关于风险的风险控制。
业务控制图的外观设计相当于一个矩阵或表格。横坐标显示了潜在的过程风险，纵坐标表示可能的风险控制。风险解决作为一个风险与风险控制之间的运算符被插入。此外，组织单位（从用户需求的角度）和文献可能被加到模型中，他们也支持执行关于一个风险的风险控制。
图 31: 交易控制图表实例
这个图的类型一般被用于描述SAP标准过程。这个模型显示了关于被监测过程的SAP的风险和风险控制。 .
构造模型
构造模型一般用于表示实际的层次或系统化（实际的特殊性或一般性）。
定义: 结构元素表示一个实际（内在系统的方向）。.
关于实际的模型可以分配给实际层次的结构元素。
结构模型最常用于质量管理，尤其是认证的目的。构造模型在它的单个组件中显示了它的规格，帮助达到质量标准的模型被指定给单个结构元素。
图 32:结构模型实例 ( Norm VDA 部分视图)
用报表，这些事实能够横统一的被估价，或用于文件的目的。
工业过程或办公过程
工业过程和办公过程图表类型基本上和eEPC图表类型（或具有物流的eEPC）相同。然而这两种图表类型仅提供了在图示形式下的有限的对象和符号。
这种图示表示方式有其优势，它能够让不同的操作部门的职员不经过培训就能够掌握并且自己就能够调整和发展它们。例如，让每个人见到三个人的符号表示一个群是很容易的。然而在抽象的符号论中，就不那么显然了。（带有双框的卵型）所以，这两种图表类型的目的是引进操作建模，操作最优化，操作利用给操作部门。
为了保持和符号论最大的统一，有两种处理方式（图表类型）：工业过程，它绘制了制造过程（创建物料货物和产品），以及办公过程，它绘制了办公的过程（创建了非物料货物/服务）。.
图 33用 eEPCxe "eEPC: Symbols" (or 带有物流的eEPC)符号比较工业过程符号和办公过程符号。.
对象类型
可能的图表类型符号
eEPC
工业过程
办公室过程
事件
功能
规则
应用程序
系统类型
位置
组织单位
团体
职位
个人类型
人
知识类别
文档化的知识
信息载体
物料类型
-
运输系统类型
-
操作资源类型
-
技术操作
供给类型
-
包装材料类型
-
仓储设备类型
-
图 33: eEPC图表比较，工业过程，办公过程图表类型.
通过拷贝一个图表类型的内容到另一个图表类型中去，你可以交换三个图表类型之间的表示类型（提供存在于相应图表类型的对象）。 ARIS在拷贝中自动转换符号。 34 是用eEPC，工业过程，办公过程表示同一个事实的例子。
图 34:在eEPC，工业过程，和办工过程图表类型 中被表述的事件实例
计划过程链(PPC)
PPC 模型类形是ARIS工具箱与MS计划之间的关联连接。ARIS工具箱是表示通过使用事件驱动过程链（eEPC）在业务过程意义上的功能的程序顺序。抽象层对于计划的容量和时间编制计划是不充分的。实际事件和功能实例应当被监测和详细规定。PPC通过发生层上自己的对象而不是事件和功能对象类型满足这一需求。
定义: 时间是历史之发生在实际过程实例的事件。事件实例可以被估计，例如，它可以被决定是对或错。xe "Event instance" xe "Function instance"
定义: 功能是历史之发生在实际过程实例上的功能。人们可以制定给他一个唯一的开始和结束时间，也可以附加属性。
计划结构元素（功能实例，时间实例，规则和联系）用于表示计划按年代排列的顺序。PPC包含了人员（内在的/外在的），操作资源，一般的操作资源对象。它们用于数据和容量计划。xe "General resource"
定义: 一般资源是指一种资源不能被详细表述，并且自重资源既不是一个人也不是一种操作资源。一般资源是用于执行程序的。
你也可以在PPC中用数据簇实例规定功能实例。
定义: 数据促使历史数据簇/数据模型对象的实例。他表示数据对象或结构的数据簇的逻辑视图。
PPC 用数据促实例代表功能实例和数据之间的联系。信息载体图模型类型（建数据视图的需求定义）可以被指定给数据簇实例对象类型。这表明了存储数据的信息载体。 以下的这个图形表示通过转换eEPC创建计划过程的实例。.
图 35:由转换eEPC创建的PPC
上面实例中的XOR 运算符表明在这个位置上所发生的可转换的eEPC的分支。它必须被认为是可选择的路径并且被唯一制定给计划。具有制定模型的对象在底框处与黑点保持一致。在上面的实例中，概念，质量保证（计划方针）对象以及需求定义，B部分（数据簇实例）都是具有制定模型的对象。
PPC 页可被用户直接在ARIS工具箱中建模。
过程实例化模型
一个动态模型的主要方面是在动态程序中的过程程序的分析。在开始的事件中例示（启动或产生）将要分析的过程。依照各自的领域用户必须能够决定他们自己什么时候和多长时间应该例示过程。另外，必须能够优化过程，例如，能够考虑到必须的处理。
通过维持开始事件的模拟属性类型群的优先权属性，并且通过传递这个优先权到所有相应的开始事件的例示的过程中，集成信息系统体系结构方法实现优先顺序。
过程实例化模型履行描述过的需求。这将作为多层对象模型进行开发。实例间隔 对象在最低层次。这样的一个间隔含有相应的间隔开始，间隔持续时间，过程实例过程树目，和分配状态，循环往复 和周期 属性。为了及时地传达特定点，允许一个0间隔持续时间。当间隔描述一系列短期的时间时，过程实例重复一系列间隔。例如，一天可被四个不同的间隔模型化，这对于完整的模拟时间周期（例如，一周）作为一个周期重复，也可把模拟时间周期分成几个周期（例如，工作日和休息日），每一个周期可包含几个不同的间隔。一个过程实例化计划可包含一个或几个周期。下面的例子说明这样的对象模型。I:
一个过程模型作为一个具有一个开始事件的eEPC 存在。下面的例外适应于这种过程：在每个工作日的开端，50 过程在工作日（周一到周五）的8：00am 开始，从8：00am到中午12：00和从1：00pm到5：00pm 一样，20过程以同样的分配开始：从中午12：00到1：00，相同于工作小时以外的时间周期，没有将要开始的过程。在周六，60过程从9：00am到3：00pm 以一个三角形的分配形式开始。一般地，在周日没有开始过程。这种每周一次的节奏适用于从一月到十二月，除了从七月到八月的假期这段时间。在这段时间内，没有人在周六工作。 基于以上的描述我们可以产生以下的模型。
图 36:过程实例化模型
RAMSxe "Model: RAMS" xe "RAMS: Requirements analysis for manufacturing systems" (制造系统的需求分析)由数字设备开发的公司分析方式。
RAMS是一个程序（或模型），它是用于视图和评估信息技术的综合潜能，以及开发信息系统需求的解决方案假定。其结果就是一种需求规定，他保证公司目标，业务过程，信息流，和信息系统之间的协调性。
模型代表了所有的部门，活动，和存在与对角线上被考虑的应用。这个对角线通过单个功能单位之间最重要的信息流被补充。如果是可应用的，重要的货物，货币货物流应当被添加。
图 37: RAMS图表实例
RAMS研究的转换模型：
第一步xe "RAMS:Transaction model"： 第一步是定义预期研究的结果，包括共享者的命名和初始的时间进度表。
第二步： 第二阶段以选择个别部门、行为和在研究中会被检查的现有的应用程序来开始。它们在对角线矩阵中被表达，在里面个别功能单位间的重要信息流会显示出来。如果可用，重要的货物、资金和物流不得不被添加而且很明显。另外，部门和功能必须被详细说明为此还需要有详细的需求分析。
第三步： 定义了研究范围之后，被选的部门或功能组会根据交易目标和过程以及它们的任务和在第三步中要用的有关信息进行详细分析。制图和说明的创造性使用可以帮助理解复杂的过程或程序。通常，会使用初始的交易窗体、报告或屏幕使事情更加清楚。这一分析的一个重要任务是在信息流和现有行为和系统的交易程序中关系发现可能的不规则。提高现有行为和系统的潜能也会被检查。在分析难题、疑问和建议时，会出现最好的可能的解决办法。信息会按照交易行为中的起因和结果来详细组织和检查。如果提高潜能形成，它们会被纪录它们的有效性会被估价。
第四步： 详细的现状分析结果现在作为下面需求说明书的基础。问题范围现在划分得很清楚新想法和可选的解决方案可以发展。保留所有建议的解决方法很重要----从复杂系统延伸到简单的过程变化----与先前纪录的初始情况密切相关。 这一与初始情况的比较必须在相关范围内对所有的功能和行为都执行。研究结果可以从一般解决办法的功能性延伸到创建和比较使用者的需求。
第五步; 在每一步分析中收集的结果会在最后的需求说明书的表达中做一统一。在研究过程中执行的所有信息，详细的检查和建议会被总结为最后的报告并形成将来系统需求的基础。为实现规定的解决办法，下一步由一个功能系统说明书组成。
图案描述
访问方式描述图
以下部分描述了单独的对象和其他视图中的图案中的对象之间的相互关系。这些相互关系可包括在控制视图的访问方式描述图中。为了使这些描述更加透明，单独的双重关系独立处理。
组合功能和数据
作为第一项方法，应用系统，模块类型或者IT功能之间的数据流都可得以详细说明。为达这个目的，数据流被放置在独立的应用系统或模块类型之间。通过链接数据流和eERM 图表，可以更加精确的描述的数据对象系统类型之间传递的关系图表或表格图。这样，数据流对象可以被放置在必须定义层，图案描述层或执行描述层。
图-1列出了一个例子。
图 1: 应用系统类型间的数据流
除了数据流之外，每一个应用系统类型，模块类型和IT功能类型的输入输出数据也可表达为必须定义的或图案定义的数据对象。箭头的方向指示了数据流的方向，也就是说，这样我们可以处理这些输入输出数据。
-2中列出了一个例子。
图 2:图案描述层上的输入输出数据
组合组织和数据
在图案描述层上链接数据和组织之前要完成两项任务。一方面，要详细说明哪一个组织单元是对公司独立的数据对象负责的——另一方面，在大体水平上详细说明在公司中哪一个组织单元被允许访问特定的数据对象也是非常重要的。
这样建立起来的相互关系链接了组织视图于主体相关的对象（组织单元，位置，人力资源类型，人力资源等）和图案描述层的关系图表数据对象（关系，属性，视图）。因此，这些相互关系被分配给控制视图的图案描述层。
为了定义关系或独立字段的访问权，可以指定相关的数据对象的位置和人力资源类型。这样做不仅可以保证一个确定的位置访问特定的字段。通过分配人力资源类型，可以定义一些商业规则，例如该字段只可以被部门领导访问。图-3中阐述了一个例子。
图 0 3: 访问权
除访问权以外，对于字段或一个完整的关系的内容的责任进行准确的定义也是同样重要的。因此，从组织单元和关系图表的数据对象之间可以提出一项次要的关联，称之为对谁负责。当访问权被放置在多个职位时，对数据对象的责任往往仅被分配给公司中的一个职位。在此，通过指定人力资源类型可以定义类似于上面提及的商业规则。这些规则和数据对象的责任相关。
图-4阐述了一个例子。
图 0 4: 责任定义
组合组织和功能
组织各方面和在图案描述层上已经定义的功能各方面相连接的事实基本上可以回答以下问题：
谁(组织单元，职位，人力资源等)负责功能视图中在图案描述层上描述的应用性同类型和模块类型，以及谁使用这些系统?
公司中的哪些部分（组织视图）使用哪些应用系统类型或模块类型？
公司中的哪一个平台 (硬件元件类型 (组织视图)) 适合于运行应用程序系统类型？
要回答第一个问题，关系可以在访问表中的组织制表的组织单位（组织单位，职位和人力资源）或应用系统图表（应用程序系统类型，模块类型，IT功能等）对象之间绘制。做这一个重要的关联时可以描述的更加准确。我们比较下面的例子：
组织单位对应用系统类型负责也与所讲主题方面相关。
组织单位可以对应用程序系统类型的发展负责。
组织单位也许是应用程序系统类型的使用者。
位置问题可以被分派到从组织视图到应用系统类型，模块类型和功能类型的位置中。
在设计规范中，我们不以单独的许可证单独处理应用程序系统而是应用系统类型。这样，依靠这些关联，无真正应用程序系统的位置被说明(这种分配在执行描述层中被实现)，但是对应用程序系统类型可能有的特别的位置会指出来。
公司里有用的硬件元件类型在组织视图设计规范中描述。在控制视图中，这些硬件元件类型和应用程序系统类型的关系被确立起来。这样，硬件平台决定下来可以运行特定的应用程序系统类型，模块类型或IT功能类型。在这个阶段，包括在功能视图中的桌面类型，操作系统类型和DBMS类型也可以被分派。
在指南的附录 (第 8章) 你会发现所有可能发生在访问表中的关系清单。
图 5 表示关系实例
图 5: 访问方式描述图（摘录）
程序组织图
在访问方式描述图中，你可以在组织视图和数据视图的对象类型和在应用系统类型描述图（见）中已描述的应用系统类型，模块类型以及IT功能类型之间建立联系。在这个描述图类型中，你不可以直接阐述必须定义的功能的分配。这种分配在应用系统类型描述图中实现。同样的，应用系统类型，模块类型以及IT功能类型的逻辑事件链也不可以直接阐述。严格按照ARIS 体系机构，你仅仅可以通过察看一系列图表类型来追溯这些链接。
在系统图案的某些部分中特别建立了某些描述图类型（例如程序组织计划PSP(PF),见143页）这些描述图类型使你能够完整的看到所有的系统图案标准。
这就是为什么ARIS包含了程序组织图表的原因。这样就可以模拟器它ARIS描绘图类型所提供的应用系统类型，模块类型以及IT功能类型之间的所有关系，而不用考虑ARIS分区。此外，你可以显示所提及的对象类型的逻辑事件链。为达到这个目的，在这个描述图类型中也可提供事件。就像Eepc中的分配功能和事件，你可以在程序组织图表中定义模块顺序。在这种情况下，事件应当被理解为一个板机，引起模块类型或应用系统类型。要阐述分支，你可以利用EPC部分中已经介绍的链接操作。与EPC不同的是，你可以不用介绍其他的事件而定义程序组织图表中程序上的顺序。
程序流图表（PF）
程序流图表描述了程序中的程序上的顺序。程序的顺序由对象间的关系来描述。这个图表没有描述任何数据。
下面的图形显示了一个简化的自动讲述器的程序顺序。从程序顺序的描述当中可以得到清晰的执行指示。
图 6: 程序流图表（PF）举例
界面图
界面图是用来描述软件中的界面图表的。它的目的是从界面图的发展中自动引出界面图表。
因此，界面图显示了组织并在某种程度上显示了界面图表的功能性。以下这些是需要考虑在内的：界面图的组织从左至右从上至下，都要符合所描述的几何界面。
中枢的符号是屏幕；用Windows的属于来说叫窗口。这个窗口包括了好几个制表符（页码符号）。总体上来说，可以利用表格格式化（截面符号代表行，柱状物符号代表列）将界面地理上分成若干个区域。界面符号和柱状物符号可以嵌套使用来建立复杂的界面。你可以在街面上使用表格（界面表格符号），文本条目对话框（COT属性符号）和图形（位图符号）以及文本描述（文本符号）。使用版面设计符号你可以给界面，页码，截面，柱状物，界面表格，COT属性和文本对象指派显示道具。
还可以使用其它的符号来描述界面。
图-7显示了一个界面图的例子 图-8显示了一个从此得出的界面图
图 7: 界面图举例
图 8: 从图-7中衍生出的界面
执行描述——访问方式描述图（物理的）
在控制视图的图案描述中被考虑的问题在执行描述层上也存在。相比较图案描述层，我们没有检查对象类型而是检查了对象本身。我们着眼于例如具体应用程序和组织单元之间的联系，而不是应用系统类型和组织单元之间的联系。
以下篇幅所阐述的联系在访问方式描述图（物理的）中得以模拟。
组合功能和数据
要得知应用程序中出现的是哪些数据流，可以在功能视图的应用系统对象中插入数据流对象。于图案描述层相比较，这些应用系统对象并不等同于应用系统类型，而是相当于具体的独立的应用次同许可。这就意味着应用系统，模块和程序元素类型都可以通过数据流对象连接。让我们假定以下部分都已在图案描述层定义：数据可以被传递给模块类型销售和分销SD 和物资管理MM 。在描述层是这样描述的：数据是在自动安装的模块SD,许可证1234号和MM，许可2352号MM，许可证34234号。所有的模型都是物资管理MM 模块类型的。图-1举出了这样一个例子。
图 1: 数据流
通过链接数据流对象和数据窗口中各自的数据类型，系统中传递的数据可以得到更为详细的说明。
除应用系统中的数据流之外，每个应用系统的输入输出数据也可加以描述。描述访问方式描述图（物理的）中的关系有两个原因。首先，数据对象是执行定义层的数据视图中表格描述图（表格，字段，视图（物理的））的对象。这些数据对象可以通过相关的输入输出数据链接到图案描述层或执行定义层的应用系统对象中。其次，应用系统对象是具体的应用系统或与独立的数据视图对象相连接的执行定义层的模块。
这样，便建立了以下通用规则：
如果从独立视图的执行定义层提取一个分享输入输出关系的对象类型，控制视图中的关系也在执行定义层（访问方式描述图（物理的））中描述。
图-2中阐述了这一点。
图 2: 输入输出关系
组合组织和数据
如同前面一样，我们现在考虑的是在图案描述中已经解决的相同的问题：
组织中的哪个单元对数据对象负责？
按个人被授权访问哪个数据对象？
哪个数据对象包含哪些硬件内容？
与图案描述中不同的是，现在已经建立起与数据视图的执行定义层中显示出来的数据对象之间的联系。
这就是收对数据对象的责任不再是为了联系图表中的联系和属性而定义，而是为了一些物理的结构，例如表格，字段以及它们的范例（表格（范例），字段（范例））.
为了描述这种依赖关系，在组织视图（组织单元，岗位，人力资源等）的对象和早先在访问方式描述图（物理的）中提及的表格图对象（表格，字段，是图（物理的）等）之间建立起联系。
在组织单元和表格以及字段间建立联系时每一个相互联系都必须单独定义。对…负责意味着这个特殊的组织单元对各自的表格或字段内容负责；访问表示这个特殊的岗位或人力资源被授权对所显示出的数据对象进行访问。
除了访问授权和职责之外，你可以利用硬件元件对象（组织视图/执行）在已经存在的硬件元件上或者通过详细目录号码可以唯一定义的硬件元件上进行定义，例如-将公司的确定信息对象定位。为达到这个目的，硬件元件对象可以被链接到执行描述层（表格，字段等），图案描述层（联系，属性）或访问方式描述图（物理的）中必须定义层（实体类型，数据束等）的信息对象。
图-3阐明了这一点。
图 3 硬件构件配置
组合组织和功能
由于在访问方式描述图（物理的）中定义了组织视图对象和功能视图对象之间的相互关系，以下的问题得以回答：
哪些应用系统已经在哪些硬件元件上运行以及哪些应用系统可以在这些硬件元件上运行?
为了阐述这些依赖关系，可以在组织视图的对象类型硬件元件和执行定义层（应用系统，模块，程序元素等）或图案描述层（应用系统类型，模块类型等）的应用系统对象之间建立是…的平台和可以作为…的平台两个相互关系。
图-4举出了一个例子
图 4: 硬件元件作为平台
哪些组织单元利用哪些具体应用系统？
当我们在图案描述层描述正在访问某一应用系统类型的用户时，我们可以具体应用系统（独立许可权）的执行定义层定义这种联系。这样在一个公司中可以得到多个不同构造的应用系统类型ARIS工具栏版本的许可权。通过访问方式描述图（物理的）可以显示谁在使用哪个许可权。伟大这个目的，组织单元，岗位和人员对象类型性可以通过使用关联与应用系统和模块对象类型链接。图-5中阐述了这样一个例子。
图 5: 用户和应用系统
哪些应用系统安装在公司的那个位置？
在图案描述中，应用系统类型和位置之间的相互关系可以用来定义哪些应用系统类型可以放置在公司的那些特定位置。为了确切的描述一个必须应用系统类型的独立许可权在公司中的那些位置使用，可以在访问方式描述图（物理的）中链结位置和对象类型应用系统，模块和IT功能。
图-6阐明了这一点。
图 6: 位置分配
目录中总结了访问方式描述图（物理的）中所有可以利用的相互关系。
SEQ Kap \r4 \h执行模拟
产品/服务交易图表
产品/服务交易图表用来描述产品/服务在公司中的产生和变化。执行可以是一个产品也可以是一项服务并且用相应的符号来描述。产品可以是物资类型，操作资源类型，技术操作供给类型以及/或者包装物资类型，例如eEPC中的物资流。输入和/或输出的函数的执行可以和这些函数的启动和结束事件相连接。
可以以有益的方式运用商业函数之间的产品/服务交换，这种方式处于附有一系列图表的数值和eEPC之间并从中提炼出来。如果从功能的角度来看交换关系，执行的交换关系可以从结构的角度来阐述。从这个目标出发，产品/服务交换图表也提供了若干建模选项。
表 1: 显示一个产品/服务交换图表的例子
表 1: 从软件库中抽取产品/服务交换的样本
产品/服务树
执行可以从不同的提取水平来观看。因此模型中包括这些关联是有用的，在模型中组成一个完整执行的各个执行部分都被加以描述。静态的方面用产品/服务数来描述。例如，一个完整的产品包括了许多不同的模块，每一个模块都有不同的组成部分。每一个元素都可以作为一个执行来理解。
在产品/服务树中，对其他执行的取代关系例如（潜在的）替代产品或服务也同样加以描述。
在静态模型中，执行和（公司）目标之间的关联也加以描述。
表-2产品/服务树显示了一个产品/服务树的例子。
表 2: 产品/服务树
产品分配图
除了属于具体模型的一般产品/服务表以外，产品模型可以提供一个更为抽象的描述。产品分配图用来分析公共管理中的产品制造。与产品/服务交换图表相似，这种模型类型显示出哪个结构单元提供或使用了哪个产品，哪个函数为生产产品所需，产品为哪些函数提供一个输入。此外，每一个产品的（合理的）顺序基础都在此得到显示。不同产品的不同目标同样得到描述。In addition, the (legal) order basis of each respective product is shown here. The objectives to be accomplished with the various products can be represented as well.
表-3：显示部分公共服务的产品分配表
表 3:产品分配表抽样
产品树
产品树的作用是分析产品在公共管理中的作用。这个模型本质上有产品/服务树构成，因此有可能模拟替代产品。This model consists essentially of the product/service tree, whereby the possibility of modeling replacement products is dispensed with.
表-4显示了一个产品树
表 4: 用产品树划分“公民”和“公民身份问题”的产品群Classification of the "Citizens' and Citizenship matters" product group using a product tree
产品选集矩阵Product Selection Matrix
产品选集矩阵的重点在于结构单元和责任下的产品。这些产品可以被分配给它们所必需的函数。该模型是进入结构图，产品树和与产生产品相关联的过程的起点。表-5社会（福利）办事处产品选 集矩阵中例出了产品树的一个例子。
表 5:社会（福利）办事处产品选集矩阵
竟争模型
这个模型支持的是对公司所处的竞争环境的分析和评价。行业结构对公司战略有极大的影响，而战略对公司是非常有用的。
该模型可描述公司，产成品和服务以及市场合伙人之间的关系。也可描述哪个顾客使用了那项执行，哪项执行可以使用，竞争者已提供了哪些替代产品/服务。这样会出现一个关于公司竞争处境的窗口。
表-6运动车市场的竞争显示了一个竞争模型Figure 6: Competition in the Sports Car Market shows an example of a competitive model.
表 6: 运动车市场中的竞争
EMBED
ARIS Toolset
???
ARIS
Methods
图 错误！文档中没有指定样式的文字。 1: 具有物流的扩展的事件驱动链（ eEPC） （部分视图）
体商品接收
产品
