图3映射到接口参考模型的典型应用

DL/T1080.1—2008表2 (续)业务功能业务子功能抽象组件工作起始工作设计工作成本估计设计与建设（CON)工作流程管理工作指令状态跟踪工作指令关闭财务控制工作任务计划工作班组管理维护与建设（MC)交通工具管理（参见DL/T1080.6）工作进度安排（SCHD）设备管理材料调配许可证管理工地设计工地检查结果工地记录与设计（FRD）工作班组进入时间（记录）实际材料 (消耗)现场状态跟踪工作分派（DSP）实时通信气象监视负荷预报潮流计算事故分析配网计算（NCLC)短路分析优化潮流网损计算配网规划（NE)（参见DLT1080.7）馈线电压分布基建费用基建监理（CSP)工作管理项目定义（PRJ）资金批准安全一致性一致性管理（CMPL）技术一致性规章一致性服务请求建立账单查询工作状态客户支持（CS）（参见DL/T1080.8）客户服务（CSRV）自身服务查询［Web、VRU（语音应答单元）]客户联系（客户服务的）投入、退出服务级别协议7

O/T1080.12008

O/T1080.12008

DL/T1080的本部分描述了集成分布在电力企业中的组件必需的对企业应用间软件基础架构需求， 所描述的服务和功能与底层的基于组件的软件基础架构无关。在以下的要求中，“事件”是信息交换的 单位，由它的信息源异步地发布（“推”）。“组件”是应用软件的模块，是集成总线的组件，可以作 为信息交换的发布者，也可以作为信息交换的订阅者（接收者）。 业务过程由标识所交换的信息和涉及的组件开始。典型的业务过程涉及一个拥有信息并发起该交换 的发布者过滤器标准，以及岑或多个要接收该信息的订阅者。 DL/T1080要求符合标准的企业应用间软件基础架构应： a）允许组件交换任意复杂的信息。 b） 能用多种形式的分布组件技术，例如CORBA（公用对象代理请求体系结构）、DCOM（分布式 组件对象模型）、消息代理、面向消息的中间件、关系数据库、面向对象的数据库或其他技术 实现。（见第5章） C） 提供信息交换模型工具（见第6章），用户使用该工具描述交换的信息。该工具为用户提供事 件模型和与模型相关的组件，并允许将新的交换添加到旧的中，这样可以建立起一个为企业特 定需要裁制的、综合性的公共交换模型，而不是一些独立模型的汇集。 d）： 在接口保持一致的前提下，允许系统管理员独立于其他组件部署发布者组件以及（或）订阅者 组件。

DL/T1080.1—2008e）在给定的事件类型发布后，确保可以再设置订阅者组件来接收这类事件，而不需在发布者组件上进行任何增加或修改。4.2需求分析方法为有助于电力企业部门和系统之间能有效地共享信息，需要通用的建模表示法或建模语言。建模语言用添加格式化的结构扩展自然语言，以达到减少交流中的歧义的目的。通过在企业内使用通用建模语言，企业可以更好地定义部门之间需要共享的信息。该建模语言应有足够丰富的内容以描述需求，它面向图形（可视图形），易于使用，可被广泛接受，并有价格合理的工具支持。这种方法已用于开发DL/T1080。关于它的更多信息可参见附录B。用于开发接口参考模型的用例将编入将来的DL/T1080标准。5接口协议集第5章按接口协议集组织的，如图4所示。5.1第3部分：组件5.1 第4部分：组件5.1第10部分：组件（配网运行）（台账与资产管理）5.2组件适配器5.2 组件适配器5.2 组件适配器5.3DL/T 1080.3DL/T 1080.45.3 DL/T 1080.10接口规范5.3接口规范接口规范5.4 中间件适配器5.4 中间件适配器5.4中间件适配器5.5中间件服务5.6 通信服务5.7 平台环境图4接口协议集与相应标准的条文编号接口协议集各部分的要求在5.15.7中说明。5.1组件组件间的信息交换可以是一块数据或是一个功能的执行结果（指该功能可以远方调用），称为服务交换。例如，组件可以是传统的过程性应用（也称为遗留应用），或用最新技术建立的完全面向对象的应用。而H，组件可以分布在网络上（局域网LAN、内部网、企业专用广域网WAN基至或是公用互联网）。这使采用电力企业范围ICT体系结构的DMS应用可以灵活部署。组件的范围是没有限制的，它可以完成配电管理要求的任何功能。第3章中的接口参考模型表示了这些功能的典型分类。组件可以是符合接口协议的，即它知道、理解并且满足服务要求；也可以是不符合接口协议的。为使不符合接口协议的组件能实现它在服务上的作用（见5.2），必须先使它符合接口协议。例如，现在DMS应用的厂"商可能有自已的应用体系结构、自已的API以及自已的应用与自已的其他产品接口的机制。这些现有的应用对这些服务可能起到重要的作用。但是不能要求这些厂商把它的所有现有应用修改为符合协议的新版本。甚至新的应用也不一定都与协议集符合，而用厂商现有的专用体系结构和应用接口。因此，在实施DL/T1080的早期阶段，不符合协议集的组件可能占大多数。随着DL/T1080的广泛使用，符合协议集的组件将会更多。对于这些组件，DL/T1080要求其应用应：10

DL/T1080.12008

DL/T1080接口规范的要求包括三部分：组件特定规范， 有关配电管理域的特定服务的要求 基于组件的分布计算环境中的通用服务的要求。各功能领域（见第3章，接口参考模型）的DL/

DL/T1080的中间件适配器是符合协议集的软件。它扩充现有的中间件服务，使企业应用 础架构支持需要的服务。从而，中间件适配器仅通过必要的扩充，就能使所用的中间件服务集 1080.3及以后基他部分中个或多个接口规范。在这样的环境下，中间件服务不只表现为单~

而是表现为为组件提供一组相应服务的接口集。 例如，厂商的每个组件可能在内部使用适合特定业务功能要求的任意的中间件（或不用中间件）。 因此，不能假设任意两个组件总以同一种方法来实现企业所用的中间件服务。所以，需要一个中间件适 配器作为中间件“网关”，将一个组件产生的符合DL/T1080的信息交换通过已实现的中间件服务传给 上层的其他组件（可能以其他中间件为基础）。 DL/T1080.3及以后的其他部分将定义所需要的服务。这些服务必须在组件能够依赖的体系结构整 体的实现中描述（见前面的条文）。然而，不同的中间件服务实现将提供服务的不同层次：不同的操作 环境可能隐含地提供一些属性，并要求中间件适配器增加其他属性。如中间件服务的实现不提供某种特 性，中间件适配器可以提供。不管服务是否在ORB内核中实现，对象实现上都可能访问它。否则，中 间件适配器必须在已实现的中间件服务之上将它实现。 注：这意味： 一对于提供这种服务的一个中间件服务实现而言，要求中间件适配器提供对它的映射。 一在DLT1080环境中使用不符合协议集的中间件服务实现时，至少有一个中间件适配器使中间件服务实现 符合DLT1080。也可能是这样的情况：使用多个中间件适配器，使一个中间件服务实现符合于DL/T1080 服务。（例如：对要的每个DL/T1080系列接口服务有一个中间件适配器。） 一对那些不符合协议集的中间件服务，每个中间件适配器是为特定中间件服务实现而定制的，因为它非常依 赖于中间件服务实现的体系的结构及实现。它也运行在特定的、可能是分布式的硬件/操作系统（HW/OS) 环境下。因此，中间件服务实现、中间件适配器（集）和HW/OS这三个要素完全互相依赖。 —对于运行在相同计算环境中的相同中间件服务实现上的DL/T1080多接口服务，中间件适配器在理论上是 可以重用的。 DL/T1080要求中间件适配器应提供DL/T1080特定的接口规范中规定的全部服务要求。中间件适 配器的实现可以通过将服务简单地映射到中间件服务实现来完成，也可以通过专门提供一个或多个 DL/T1080接口服务的附加的软件组件来完成。

为集成两个组件，需要在它们之间建立连接。由于网络不止一种，不同资源使用不同协议，如IIOP 知HTTP。要连接几个组件，集成系统必须以对组件透明的方式协调网络和协议的差异。 DL/T1080要求通信服务： a 激活通信服务后，应保证网络消息传送到它们的网络目的地。 b） 应当提供可靠传输，无论网络故障或变动，都要保证网络消息仅被确切地递达一次。 c） 无论网络是否发生故障或变动，都应当保证顺序消息按序发送。 d 如网络消息不能传送到网络目的地，应保证网络源端收到未将信息送达的信息。 e） 应为网络消息的优先级或通过特定网络途径的传送提供品质可选的服务。

由于服务以硬件和软件标准平台为基础，它必须适应来自不同厂商的不同硬件和操作系统平台。如 一个组件只能运行于一种特定的硬件环境（处理器、操作系统、语言和编译器），就不可能不经修改就 运行于另一种硬件环境。 DL/T1080的硬件环境（处理器、I/O、操作系统、地理用户接口GUI、编译器和工具）要求： a）应支持多个本地进程的并行运行，无论这是由单处理器还是多处理器硬件实现的。 b）应支持并行运行的进程之间的通信。 C 所有其他硬件环境的细节应被接口协议集的其他层屏蔽。

6.2与IEM管理有关的服务

DL/T1080要求符合标准的企业应用间软件基础架构应提供下列IEM生命周期服务： a）IEM数据定义和维护。这种服务应可以在信息模型控制的交换中动态地改变。如现有模型被改 动而组件接口未修改，组件不需要重新编程或重新编译。组件的新版本能使用改变或增加的信 息而不影响其他未改变的组件运行。 b）信息交换模型有效性检查。例如名字强制唯一、版本控制。 c）当IEM更新时，同步地更新组件，使它采用相同的IEM版本。

d）EM管理系统应包括生成易 易于理解的报告的方法。 e）IEM数据发现。这种工具应以机器可读的形式使IEM可被组件使用。 f）IEM管理系统可以通过已命名的数据集的组件提供动态的创建、修改和删除工具

DL/T1080对符合标准的企业应用间的软件基础架构的要求如下： 应提供可作为通用事件历史工具的组件，将所有或选定的信息交换保存在永久存储器中。 b）事件历史的模式应以信息交换模型（参见第6章）提供的元数据为基础。 c） 事件历史组件应记录有关组件发布每个事件的时间。 d 应支持事件信息模型版本和组件版本。（如需要，可将审计跟踪完整地保留，使历史可以准确 地重建） e） 应提供应用间监管组件，可分析连接到企业服务的应用组件接口的状态。它既能被激活也能被 禁用，并具有性能监视功能。这有助于进行统计，以标识瓶颈所在或将来要改进的地方。这些 信息可以帮助管理员配置在组件间交换的信息，并保证它们的可用性。 f 在不知接收组件的物理位置或连接状态的情况下，组件应该也能发送或请求信息。可能因为网 络问题而不能到达接收组件，或者像间歇式连接的移动用户的接收者那样，平时处于断开状态。 注1：因为组件出故障或只在某些时间运行，它有可能不可用。这时，如网络为可用的或已接受应用准备处理请求 时，必须传递等待信息。 注2：日志服务可能为可用的，用于显示在计算机和通信系统（即非电力系统）中发生的事件。日志服务应作为DL/T 1080持续交换服务的一个特例来实现

一般来说，在体系结构中的层次越高，它的操作越抽象。在这些层次上，有关失败的操作的细节较 出错信息中的细节也可以少些。这里的原则是出错信息与检测出错的层次的抽象程度相匹配。 出错报告应当包含如何处理出错的足够详细的信息。 注1：出错有三种类型： 整告：信息性消息，如消息队列级冲区即将全满。 一一般出错：可恢复的差错情况，不带重新初始化，例如数据完整性错误。 一致命出错：需要将一个或多个组件或服务重新初始化的出错情况。在恢复完成前，未受影响的组件和服 务可在有限的配置下继续运行。 注2：异常声明是功能特征的一部分。例如，在C++中，它包括关键字throw，写在参数列表后面，再后面是由圆括 号包括的类型列表。异常说明不描述应发生的事情，而描述可能发， 保证不发生的性

安全问题出现于系统通过通信或其他方式向外暴露的任何接口。一个安全的系统至少应在所有这些 暴露接口处进行验证。随着放松管制以及Web的应用和发展，必须保证采取适当安全措施，为此而制定 一些标准。 人员或组件作为一个用户而与组件交互。用户和组件之间的接口就是一个暴露的组件接口，系统可 能通过它遭受重大的安全事故。对于人员用户，请求组件有责任验证用户是否具有以下权限： 一可使用业务功能。 一可使用个别的服务基础上的服务。尽管这样的限制有助于安全，但被请求的远方组件服务还要 对发出服务请求的远方组件的权利进行强制验证

安全性威励包活： 违反授权：互相授权的双方试图实行未被对方授权的行动或功能。应对这种威胁的适当安全方 法是将互相验证和应用级的访问控制相结合。 窃听：通信包遭到系统入侵者监视。这种威胁影响到敏感信息的保密性，应对这种威胁的适当 安全方法是加密敏感信息。 信息泄露：信息泄露给未授权实体。这种威胁影响到敏感信息的保密性，然而，本标准所述的 安全性并不反对用网络通信作为传输信息的手段，应对这种威胁的适当安全方法是将互相验证 和应用级的访问控制相结合。 截获/改：通信包被入侵者截获。这些包内的信息被修改并继续传送到原来的应用目的地，这 种威胁使数据完整性发生问题，应对这种威胁的适当安全方法是加密。 伪装：这种威胁是一种典型的电子欺骗。入侵者假装为另一个实体，试图对系统访问。这种威 胁形成严重的控制和数据保密的风险，应对这种威胁的适当的安全方法是加强验证。 重播：通过窃听获取通信包，随后又将它再送到网络。如果那些通信包中有控制命令，可能产 生严重后果，这种威胁可以通过适当的加密结合动态密钥管理应对，如何实行密钥管理属本地 功能。

全性切能安求如下： 符合DL/T1080的系统由应用组件组成。这些组件采用被认可的企业策略，确定需要的安全性 及验证1的特征。这些特征包含以下内容是合理的： 限制未授权用户的访问。 一因为通信系统改变而自动产生的日志。 用户授权的自动管理。 通信地址2分配的自动管理。 记录级数据锁定工具。

）通信安全性包括保证应用所处理的及存储的信息的保密性、完整性和可用性的全部方法和控制。保密性可保证 向未被授权的人员、实体或过程透露信息。 ）地址提供识别各种信息传送的信息源和目的地（收信者）的通信手段。

支持名字和数据值的加密。 一自动检测和消除病毒的工具。 保护授权用户不受可能的拒绝服务的威胁。 以上特征可保证数据完整性以及通信接口对未授权访问数据和控制功能具有足够的抗扰度。中间件 机制负责安全和加密，包括需要时进行可靠的传输、识别、验证、访问控制和加密。 加密可由消息传送提供，或由调用过程中请求的增值消息处理过程提供。 b）应注意可能也用在其他地方的一些数据的安全等级和特性。即，符合DL/T1080的系统不应是 一个链条中的薄弱环节。

8.4完整性和安全性的管理

8.4完整性和安全性的管理

完整性是通信网络对偶然的或有意的干扰导致的数据传输出错的抗扰度。抗扰度分三个等级： 高级：出错漏检的概率小得可以忽略的数据传输，例如控制命令和系统的关键参数。 中级：固有余信息的传输，例如电力系统的量测和纯文本。 低级：例行更新信息的传输，其中偶然的出错仅是扰，例如话产通信

通信资源对偶然的或有意的未授权访问的抗扰度分为个等级： 一高级：限定预先规定和批准的组件访问。 中级：允许符合简单标准要求的组件访问。 低级：允许任何组件访问（这种资源常是只读的）。 最高的安全等级可包含数据源对接收者以及数据发详对佳输者的验证

维护是（系统）寿命期的一个重要部分，它处于很长的系统开发周期过程（包括系统的设计、实现、 使用）的末端。维护问题的等级将反映不同来源的集成组件的设计和实现的质量。不良的实现可能导致 可靠性减低，可执行文件容量增大，性能下降。其主要引起可测试性降低，可用性降低和可修改性降低， 其次引起连接时间增加，易读性降低和编译时间增加。

1）拒绝服务指使通信系统任何部分的正常操作失去作用的任何行为。一个用户如有修改信息或耗尽系统资源的 就能干扰系统的合法使用。例如，以下情况可导致拒绝服务：一个节点或一个应用偶然地或有意地使用系 通信网过载或阻止合法用户在重要的时间段里发送信息，妨碍应用进程。

DL/T1080.12008

其他组件设计解耦。也就是说，组件应尽量自我包含，减少组件间的相互依赖性。 DL/T1080要求符合标准的企业应用间的软件基础架构应： a）允许系统管理员部署订阅者组件，而与发布者组件或其他订阅者组件无关，其他订阅者组件的 数量可以很多。旦订阅者组件被部署，系统就知道该订阅者组件的注册，并向该组件传递所 有符合其注册的交换信息。 b）保证系统可用对组件透明的方式为组件定位，从而组件可被再部署于任何一个主机而无需改变 其代码。 c）提供初始化工具，该工具可用以下两种方式使组件的启动同步： 传递所有注册的最后值； 一传递从组件最近一次被激活以来已经发送的所有交换实例，这些交换实例可能已经传递过 了（如果这些实例存在于历史纪录中）。 d）提供组件注册功能。无论组件本身当时是否在运行，注册都应能激活组件。（因此，系统应能 掌握周期在线或偶尔在线的订阅者组件的信息，也应能掌握连续运行的、可能失效并已返回的 组件的信息。） e）允许组件执行失败并返回，而不需重新初始化其他组件。组件采用服务提供该能力。这种热启 动工具可以设想该组件接收到的它故障时的所有事件是可用的。每当组件从先前的已知（例如 被标记的）状态更新它的本地数据存储时，组件将因此能够继续在事件驱动模式下运行。 f 如符合DL/T1080的系统的故障时间长于它的存活期，或服务失效，或有任何其他原因，使事 件的信息流不可信，则通知所有注册的组件必须冷启动。这要求组件重新初始化，而不假设它 们已收到已注册的每个事件。 g） 确保发布者组件对于不能保证连续的事件流的任何事件类型，能够发出一个冷启动请求。 五 按照要为电力企业标准电网管理服务提供接口准备。 支持企业的符合DL/T1080系统的配置管理。应为同一企业系统内、同一组件的不同版本提供 管理和部署服务。

附录A （资料性附录） 配电管理域

在集成系统的描述中，了解以下术语的基本含义和它们如何使用是重要的： 一管理：有效的调整和指导； 自动化：无人参与的工作； 系统：一组用于支持特定活动的、有组织的操作。一般地说，在本部分的环境中，系统是一种 基于计算机的技术。 在集成系统的范围内，系统也是另外一个系统的一个子集。一个由许多子系统构成的系统可以用子 系统支持特定的活动，这比这些子系统彼此独立地运行要好。 可以通过一些实现的例子来了解包括数据交换的层次结构。图A.1中，具有特定功能的基本构件块 可以是程序、软件包或应用。组应用联合起来构成一个系统。可以要求几个系统以规定的职对一个 部门提供支持。这样，数据在应用之间、系统之间以及在部门之间就可以进行交换。最后，每个公司都 可以实现与它往来的其他公司的信息交换

图A.1一个系统环境中的层次结构

当集成和数据交换实现了自动化时，各系统自身合并成高一级的系统的子系统。这样，图A.1中的 系统111和系统112就成为部门11系统的子系统。在自动数据交换集成的上一层次上，部门11系统和 部门12系统等就成为公司1系统的子系统。 各个部门均有名字，而且某些部门或特定职贵已先于其他部门实现了自动化。这个事实导致 要以特殊的命名规则描述支持系统。要继续使用通常被接受的一般名字，指出系统的内容和限制， 以保持接口定义的连贯性。图A.2给出了电力企业环境内的一个典型结构，它有助于系统接口的 分类。 财务管理和人力资源管理等部门是企业内部的服务部门，而客户服务管理和电网管理部门是企业的 业务部门。应注意，配电企业有配电网，但输电和发电部分不是必需的。 表A.1给出了公司环境中的数据交换示例。由表A.1可看出，随着交换一方涉及的任务的复杂程度 增加，交换数据的结构也增大。更进一步，数据结构在系统中越深，数据交换对最终用户越不透明，例 如两个应用间的数据交换。

A.2一般的企业结构

表A.1公司环境中的数据交换示例

企业固定使用的数据类型（见表A.2）、用户范围以及数据提供者要求基本数据必须为个部门“所 有”，从而避免： 一多点数据输入引起差错： 一软件接口一致性低： 使用新的或升级的软件时改动费用很高； 不能总览授权的数据。

企业固定使用的数据类型（见表A.2）、用户 ”，从而避免： 多点数据输入引起差错； 软件接口一致性低： 使用新的或升级的软件时改动费用很高： 不能总览授权的数据。

数据标准化可使出错减少、数据输入时间减少以及过程控制得以改进。另一方面，随看标准化 在企业内必须执行全系统统一的规则，可以解决许多棘手的问题，如：

本附录概述了IECTC57WG14（国际电工委员会57技术委员会14工作组）的建模概念、工作步骤和可 交付的文件，阐明了它与国际电工委员会57技术委员会13工作组、EPRICCAPI和UCA的项目以及开放应 用组（OAG）之间协调工作的目的和方式。本附录仅为DLT1080标准的开发及应用提供总体的指导意见。

B.1.1企业中IEC61968的应用（见图B.1图

企业应用过程的步骤A（见图B.1～图B.4）是安装用于集成的合适的软件基础架构。企业应用过 程的步骤B～G则涉及对特定企业需求的分析，以制定一个详细的企业特定消息类型的规范。希望这些 规范像IEC61968那样以印刷的报告的形式提交。但是企业及其供应商也可以允许以合适的电子文本的 形式交换规范。例如，可通过可视建模工具制定规范。

图B.1过程1A：IECTC57WG14开发IEC61968将来部分的过程

IB：HECTC57WG14开发IEC61968将来部分

过程2A：DMS与外部系统的典型业务子功育

虚线表示应用产品提供商的职责。 图B.4过程2B：IEC61968标准的企业应用概况（续）

企业应用过程的步骤HN描述了这些企业特定消息类型的实施与部署。通常，希望应用系统的提 供者负责修改应用，以产生或说明该企业特定的消息类型。希望企业系统的集成者负责在该软件基础架 构下配置信息交换模型（IEM）。信息交换模型（IEM）可以支持全部或部分特定数据的自动配置，这些 数据来自应用产生的机器可理解的数据或来自步骤G产生的消息规范的电子拷贝。 本过程包括三部分： 接口的体系结构和主要抽象组件的规定； 描述动态变化的消息类型的接口规范的规定： 一提供说明哪些数据可以交换的公用方法的静态实体模型的规定。 静态实体模型和信息的开发是一个迭代过程。 图B.1～图B.4所示的两个过程图提出了以下两点的概貌： a）IECTC57WG14开发的IEC61968将来部分的工作过程； b）IEC61968标准的一个企业应用的概况。 第一个过程图显示的步骤在本附录的后面描述。

环保标准图R5DMS的主要业务功能的典型组件（1）

图B.6DMS的主要业务功能的典型组件（2)

为开发在IRM中定义的IEC61968第3～10部分的各种接口规范，要建立一些纵向的小组。小组工 作的一般过程描述如下。 每个小组要进行的工作有： a）规范性工作： ·消息类型表（例如：NewOmtaaeReco）

DL/T1080.12008

容包括：classname（类名），messagetypename（消息类型名），referencetousecase（s） （用例参考）： 消息类型定义，内容（消息中的类/属性对）参见将来的DL/T1080.11。 6） 资料性工作： ●集成场景（及用例参考），事件顺序图： 一描述（文字）； 一 一正规用法（例如：请求/回答、发布/订阅、订阅标题、安全级别）： 前置条件（用于消息类型）； 后置条件； 差错条件（仅限于应用级，不传送，不作为工作流程）。 一有关的公共信息模型（CIM）包。

各纵向小组要修改已有用例并开发新的用例。这些用例为小组的业务功能建立来目接口或反达主按 口的典型的信息交换要求。业务功能，IEC91968第3～10部分的各部分的接口参考模型（IRM)，是抽 良应用组件的组合。用例的目的是标识在这些组件之间交换的信息。步骤1中不需要定义信息的产生者 成使用者和消息类型的各列，这些将在本过程的步骤4进行。 EC91968第3～10部分的委员会草案阶段的目标是提交80%的最需要的信息交换的要求。 注：在IECTC57WG14当前工作计划中，未规定为IRM业务功能内部（即在纵向小组工作领域内部）的抽象组 件之间交换的信息编写标准。但是，如小组认为某些业务内部功能信息交换是普遮需要的，它可以定义这些信 息交换的消息炎型。在小组的工作过程中，它也应提出修改接口参考模型的建议，使接口参考模型更好地反映 电力工业的应用间集成的烯要。 在一个业务过程（用例）的本步骤完成时，应得到以下问题的答案： 一为什么需要信息交换，即，用例是什么？ 信息交换在哪里发生，即，典型环境是怎样的？ 谁是使用该系统或应用的参与者？ 用例模板见表B山。

UseCase:

项目管理、论文UseCase: 摘要：

参与者【［Actor（s)】]