CN101158973A - 命令输入辅助方法和设备 - Google Patents

Abstract

本发明实施例公开了一种命令输入辅助方法，包括：接收输入的命令，根据所述输入命令以及获取到的业务逻辑关系描述文件中记录的业务逻辑关系，联想出下一步将要输入的命令。本发明实施例同时公开了一种命令输入辅助设备。应用本发明实施例所述的方法和设备，能够灵活方便地联想出操作员所要执行的命令。

Description

命令输入辅助方法和设备

技术领域

本发明涉及命令控制技术，特别涉及电信系统中的命令输入辅助方法和设备。

背景技术

正确的数据配置是电信系统能够正常运行的前提。电信运营商需要在开局时，对设备数据、用户数据以及业务数据进行配置，在设备的日常维护、业务维护以及升级过程中也会对数据进行频繁地调整和修改。随着电信系统复杂度的不断提高，各种数据配置命令越来越多，因此对系统操作人员的要求也越来越高。系统操作员只有了解各电信运营商设备、熟悉系统的所有命令和业务逻辑后，才能比较快速而正确地配置好电信系统。

传统的数据配置接口包括：基于命令行的输入方式，如传统的人机语言(MML，Man Machine Language)命令行输入，以及基于图形界面的输入方式，如图形用户接口(GUI，Graphic User Interface)等。其中，由于图像界面的输入方式具有不能完全显示配置的数据之间的逻辑结构、很难进行命令行方式的批处理数据脚本配置，以及处理速度比较慢等缺点，在通常的数据配置过程中，多采用基于命令行的输入方式。

一条MML命令通常由操作码、操作对象以及附加参数三部分组成。其中，操作码表示操作动作，如增加、删除、修改、查询以及激活等；操作对象表示需要进行数据配置的对象；附加参数表示需要进行数据配置的对象的一些具体属性信息。如，ADD OBJ ATTR1＝1，ATTR2＝“Name”，就是一条典型的MML命令。

由于电信系统中存在较多的操作对象和附加参数，所以系统中总的MML命令数量也较多，这样，如何帮助操作员方便有效地输入命令，以进行数据配置，就成为衡量一个电信系统操作维护性能好坏的重要指标。现有电信系统中会通过提供一些辅助方案来辅助操作员进行命令输入，比如，最大匹配方式。这种方式的实现思想为：根据操作员的输入，在系统中按照预先设定的规则联想操作员所需的命令，当操作员输入的信息能够唯一定位一条命令后，即可通过某个辅助键将操作员还未输入完成的命令补充完整，或者系统自动补充完整。

举例说明：一电信设备自身的命令集文件中存储有两条MML命令，ADD ABCDEF和ADD ABCDDF。这里所提到的命令集文件是指用于记录系统能够下发的所有命令的文件。当操作员输入ADD AB时，系统会在自身命令集文件的所有命令中查找与“ADD AB”相符的命令字符串，假设找到了ADD ABCDEF和ADD ABCDDF；由于此时系统还不能确定操作员要输入的到底是ADD ABCDEF还是ADD ABCDDF，因此系统只会显示ADDABCD，等待操作员的进一步输入；当操作员输入到ADD ABCDE后，系统即能够唯一地确定一条命令ADD ABCDEF，因此操作员无需输入余下的命令，系统会自动联想出ADD ABCDEF的命令串；之后，操作员可通过触发某一功能键来达到自动补充的目的。

可见，现有技术中的电信系统已经能够通过提供一定的辅助方案，来提高操作员输入命令的速度。但是，现有的辅助方案多是利用一些预先设定的固定规则，通过一种固定的扩展方式来对操作员输入的命令进行补充，而不能根据操作员的实际操作情况，灵活调整联想出的命令。比如，操作员希望系统能够根据当前输入的命令以及配置的数据之间的业务逻辑关系，联想出操作员下一步将要输入的命令。可是，现有技术还无法满足操作员的需求。

发明内容

本发明实施例提供一种命令输入辅助方法，能够方便地联想出下一步将要输入的命令。

本发明实施例提供一种命令输入辅助设备，能够方便地联想出下一步将要输入的命令。

本发明实施例的技术方案是这样实现的：

一种命令输入辅助方法，包括：

接收输入的命令；

根据所述输入的命令以及获取到的业务逻辑关系描述文件中记录的业务逻辑关系，联想出下一步将要输入的命令。

一种命令输入辅助设备，包括：信息交互模块以及智能数据分析模块；

所述信息交互模块，用于接收输入的命令，并显示联想出的命令；

所述智能数据分析模块，用于根据所述输入命令以及获取到的业务逻辑关系描述文件中记录的业务逻辑关系，联想出下一步将要输入的命令。

可见，采用本发明实施例的技术方案，根据接收到的命令以及业务逻辑关系描述文件中记录的业务逻辑关系，自动联想出在当前命令之后下一步要输入的命令。也就是说，与现有技术相比，本发明实施例所述方案能够根据前后命令之间的业务逻辑关系，灵活方便地联想出下一步将要输入的命令。

附图说明

图1本发明系统实施例的组成结构示意图。

图2为本发明实施例中客户端获取配置数据的流程图。

图3为本发明实施例中选择联想规则的流程图。

图4为本发明实施例中客户端进行命令联想以及参数联想的流程图。

图5为本发明实施例中客户端进行命令联想的具体流程图。

图6为本发明实施例中业务逻辑树的构成示意图。

图7为本发明实施例中操作员体验效果示意图。

具体实施方式

为使本发明的目的、技术方案及优点更加清楚明白，以下参照附图并举实施例，对本发明作进一步地详细说明。

为解决现有技术中存在的问题，本发明实施例中希望提供一种辅助操作员进行命令输入的方式，能够根据操作员的输入习惯以及配置的数据之间的业务逻辑关系等信息，智能联想出操作员要执行的命令。

本发明实施方式中，接收输入的命令，根据该输入的命令以及获取到的操作员历史行为保存文件和业务逻辑关系描述文件，按照预先选择的联想规则，包括：根据业务逻辑关系进行联想的方式以及根据操作员历史行为进行联想的方式等，联想出所需的命令。在实际应用中，上述功能的具体执行设备可以是电信系统操作员所使用的客户端。

本发明实施方式中，接收输入的命令之前，进一步包括：操作员所在客户端向服务端请求并获取操作员历史行为保存文件以及该操作员预先选择的联想规则，并对获取到的操作员历史行为保存文件、选择的联想规则以及保存在本地的业务逻辑关系描述文件进行初始化。需要说明的是，业务逻辑关系描述文件可以保存在客户端本地，也可以保存在服务端。如果保存在服务端，当操作员使用某一客户端登录服务端后，可以从服务端下载该文件。

其中，业务逻辑关系描述文件中包括一个以上的被管理对象；每一个被管理对象的内容可具体包括：对象类ID、对象类名称、父对象类ID、子对象类ID、依赖对象类ID，以及被依赖对象类ID等。这里所提到的依赖和被依赖对象类只指不能以父子关系描述，但相互之间又存在依赖关系的对象类。操作员历史行为保存文件中包括一个以上的历史(history)标签；每一个history标签的内容具体包括：命令名称、命令码、下发接口、终端信息、命令下发时间、命令结束时间、命令所属网元ID、操作结果码、操作结果描述信息，以及操作描述信息等。

之后，客户端即可根据输入的命令、操作员历史行为保存文件和业务逻辑关系描述文件，以及选择的联想规则，联想出操作员所需的命令，具体实现可以是：客户端接收操作员输入的命令；根据操作员历史行为保存文件和业务逻辑关系描述文件，按照选择的联想规则进行联想分析：若选择的联想规则为根据业务逻辑关系进行联想的方式，则客户端获取与该方式对应的业务逻辑关系描述文件，根据当前输入的命令以及业务逻辑关系，联想出操作员下一步将要输入的命令；若选择的联想规则为根据操作员历史行为进行联想的方式，则客户端获取与该方式对应的操作员历史行为保存文件，根据当前输入的命令以及记录的操作员历史行为中不同命令的使用频度，将与输入的命令相符的命令中使用频度最高的命令作为联想出的命令。

联想出相应的命令后，客户端还需要将其显示给操作员，由操作员进一步确认联想出来的命令是否正确，如果正确，则操作员可通过快捷键直接确认命令；如果不正确，操作员可通过手工方式进行修改，将其修改为自己所要的命令，然后再通过快捷键确认命令。

客户端接收到确认命令，得知操作员要执行的命令已经确定。按现有技术的处理方式，后续操作员还需要输入与该命令相关的所有参数，进而执行该命令及参数。但在本发明的实施方式中，一旦确定了某一条命令后，后续即可由客户端联想出与该命令相关的参数，具体联想方式可以是根据操作员历史行为保存文件中保存的操作员历史行为中该命令对应的不同参数的执行频度，将执行频度最高的参数作为联想出的参数。关于命令联想以及参数联想的具体实现，后续有对应的实施例进行说明，此处不作详细介绍。

然后，客户端将联想出的命令和参数发送至服务端；服务端根据接收到的命令和参数进行业务处理，并在业务处理成功后，更新自身保存的操作员历史行为保存文件，并同步更新客户端的操作员历史行为保存文件。

需要说明的是，本发明实施例中的联想规则并不限定于根据业务逻辑关系进行联想的方式以及根据操作员历史行为进行联想的方式，还可以根据需要进一步包括其它联想规则，比如，还可以进一步包括根据字母顺序进行联想的方式等，其它可能的方式不再一一列举。

上述方案可基于图1所示系统实现，如图1所示，图1为本发明系统实施例的组成结构示意图，该系统包括：客户端11以及服务端12；其中：

客户端11，用于接收输入的命令，根据输入的命令以及向服务端12请求的操作员历史行为保存文件和保存在本地的业务逻辑关系描述文件，按照从服务端12请求到的预先选择的联想规则，联想出所需的命令；服务端12，用于向客户端11传送操作员历史行为保存文件以及所述预先选择的联想规则。如果业务逻辑关系描述文件保存在服务端12中，则本实施例中的服务端12还将用于，向客户端11传送业务逻辑关系描述文件。

其中，客户端11具体包括：信息交互模块111以及智能数据分析模块112：

信息交互模块111，用于接收操作员输入的命令，并显示联想出的命令；

智能数据分析模块112，用于根据该输入命令以及操作员历史行为保存文件和保存在本地的业务逻辑关系描述文件，按照从服务端12请求到的该操作员预先选择的联想规则，联想出所需的命令；根据操作员所选择的联想规则的不同，智能数据分析模块112实现联想的方式也不相同，比如，如果联想规则为根据业务逻辑关系进行联想的方式，那么智能数据分析模块112获取与该方式对应的业务逻辑关系描述文件，根据当前输入的命令以及业务逻辑关系，联想出操作员下一步将要输入的命令；如果联想规则为根据操作员历史行为进行联想的方式，那么智能数据分析模块112获取与该方式对应的操作员历史行为保存文件，根据当前输入的命令以及操作员历史行为中不同命令的使用频度，联想出所需的命令。

该智能数据分析模块112可进一步用于，联想出与联想出的命令相关的参数。信息交互模块111将联想出的命令和参数发送至服务端12进行业务处理，并接收服务端12回送的业务处理响应消息。

服务端12具体包括：接入模块121以及智能数据处理模块122：

接入模块121，用于根据客户端11的请求，向智能数据处理模块122请求并向客户端11下发操作员历史行为保存文件以及操作员选择的联想规则；智能数据处理模块122，用于向接入模块121发送操作员历史行为保存文件以及操作员选择的联想规则。

如果业务逻辑关系描述文件保存在服务端12中，则本实施例中的服务端122还将用于，向接入模块121传送业务逻辑关系描述文件；接入模块121进而将该业务逻辑关系描述文件下发给客户端11。

此外，服务端12还可进一步包括：业务处理模块123，用于通过接入模块121接收客户端11联想出的命令和参数，根据该命令和参数进行业务处理；业务处理成功后，智能数据处理模块122更新操作员历史行为保存文件。

可见，与现有传统的电信系统相比，本发明实施例所述系统对现有电信系统的客户端和服务端进行了扩展，在客户端和服务端各增加了一个模块：在客户端增加智能数据分析模块；在服务端增加智能数据处理模块，而且，还需要在服务端以用户为单位创建不同的操作员历史行为保存文件，如图1所示，用户Tom和Marry分别对应一个操作员历史行为保存文件，用于记录他们曾经执行过的操作信息，包括命令和参数以及其它相关信息等。本发明实施例中之所以将操作员历史行为保存文件保存在服务端，是因为操作员可以使用不同的客户端登录到相同的服务端，只有将这些操作员历史行为保存文件保存到服务端，才能保证同一操作员无论使用哪个客户端，只要登录到同一服务端，即可记录并后续为该操作员提供自己的历史数据。

下面通过具体实施例对本发明所述方案作进一步地详细说明：

图2为本发明实施例中客户端获取配置数据的流程图。图2所示实施例以及后续实施例均可依据图1所示系统实现。如图2所示，包括以下步骤：

步骤21～22：操作员从一个客户端登录到服务端，并通过服务端的接入模块向智能数据处理模块请求与自身相关的操作员历史行为保存文件以及自身预先选择的联想规则。

当然，本实施例中所提到的联想规则可以是操作员预先选择的，也可以是操作员在登录之后再选择的，或者，还可以是在登录后的某一时刻根据需要进行修改的。对于最后这种情况，服务端可以在接受修改的联想规则后，要求客户端退出重新登录，然后再使用修改后的联想规则进行联想；也可以是在服务端接受修改后的联想规则后，反向刷新客户端使用的联想规则，后续客户端即可根据修改后的联想规则进行联想。假设本实施例中的联想规则为预先选择的。

步骤23～24：智能数据处理模块接收到请求后，将与该操作员对应的操作员历史行为保存文件以及联想规则通过接入模块发送到发出请求的客户端。

步骤25：发出请求的客户端中的智能数据分析模块接收到下载到本地的操作员历史行为保存文件以及所选择的联想规则后，对该操作员历史行为保存文件、所选择的联想规则以及保存在本地的业务逻辑关系描述文件进行初始化，比如将文件读到内存中等。

本步骤中，智能数据分析模块进行初始化的数据包括操作员历史行为保存文件、操作员所选择的联想规则以及业务逻辑关系描述文件。其中，业务逻辑关系描述文件为预先配置的，可以保存在客户端，也可以保存在服务端。如果保存在服务端，当操作员使用某一客户端登录服务端后，可以从服务端下载该文件。假设本发明实施例中，业务逻辑关系描述文件一直保存在本地，如某个指定的目录下。

通过表一可以看出业务逻辑关系描述文件与操作员历史行为保存文件的区别：

输入	来源	文件格式	状态
				业务逻辑关系描述文件	一直保存在本地	XML	固定不变，只有在升级场景下才可能发生变更
操作员历史行为保存文件	从服务端下载	XML	动态变化

表一  业务逻辑关系描述文件与操作员历史行为保存文件对比

从表一可以看出，业务逻辑关系描述文件的状态通常是固定不变的，只有在升级，比如业务逻辑关系发生改变的情况下，才可能发生变更，而操作员历史行为保存文件的状态则根据操作员执行的操作进行动态变化。

本发明实施例中的业务逻辑关系描述文件以及操作员历史行为保存文件均采用可扩展标记语言(XML，Extensible Markup Language)的格式进行存放，这样处理的好处在于：1)便于初始化时的数据传输，如将数据存储到数据库时的入库、出库等数据操作，以及将数据写入文件的操作等；2)便于智能数据分析模块使用通用的解析算法进行快速的查找。

下面通过具体的实例，对本发明实施例中的业务逻辑关系描述文件以及操作员历史行为保存文件的构成进行进一步地说明：

1)业务逻辑关系描述文件

本发明实施例中的业务逻辑关系描述文件中包括一个以上的管理对象，每个管理对象记录的内容包括：对象类ID、对象类名称、父对象类ID、子对象类ID、依赖对象类ID，以及被依赖对象类ID。其中，父对象和子对象类是指存在包含关系的对象类；依赖和被依赖对象类只指不能以父子关系描述，但相互之间又存在依赖关系的对象类。下面以机架(Rack)为例，说明业务逻辑关系描述文件是如何来描述上述信息的。

每个被管对象由一个对象类信息(classInformation)标签、多个属性(attributes)标签、多个操作(operations)标签以及一个子对象(childrens)标签组成。

其中，classInformation中记录了此被管对象类的一些基本信息，如被管对象名称、被管对象ID、显示名称、是否可见对象等，具体记录方式如下：

<classInformation>

   <name>RACK</name>//被管对象名称

    <！--MOC ID-->

    <id>1062577</id>  //被管对象ID

    <！--User label-->

    <userLabel language＝″en″>Rack</userLabel>//显示名称

    <！--Is visible or not-->  //是否可见对象

   <isVisible>1</isVisible>

</classInformation>

由于一个被管对象会包含很多属性，因此使用多个Attributes分别记录被管对象的所有属性，如属性名称、属性描述、属性显示名称、属性的数据类型、是否只读属性、是否可见属性等信息，具体记录方式如下：

        <attribute>

            <！--Attribute name-->  //属性名称

            <name>RN</name>

            <sDescription>This parameter identifies a unique rack.The number of the integrated

         configuration rack is 0.A maximum of 20 racks can be configured with the number ranging

         from 0 to 19.</sDescription>  //属性描述

             <！--Attribute display name-->  //属性显示名称

             <userLabellanguage＝″en″>Rack number</userLabel>

             <！--Data type ofAttribute-->    //属性的数据类型

             <dataType>

                  <dataTypeInteger minInclusive＝″0″  maxInclusive＝″19″/>

             </dataType>

             <！--Is naming attribute or not-->

             <isNaming defValue＝″1″defValDescription＝″The Attribute is naming

attribute″>1</isNaming>

             <！--Is readonly attribute or not-->  //是否只读属性

             <isReadonly>0</isReadonly>

              <！--Is visible attribute or not-->    //是否可见属性

              <isVisible>1</isVisible>

        </attribute>

由于一个被管对象也可能存在多个操作，因此使用多个operations分别记录被管对象的所有操作，如操作名称、操作的命令码、是否类操作、是否可见操作以及操作参数的相关信息等，具体记录方式如下：

  <！--The list of MOC operations-->

 <operation>

     <！--Operation name-->  //操作名称

     <name>ADD RACK</name>

     <！--Operation code-->//操作命令码

     <operationCode>12288</operationCode>

     <！--Operation display name-->  //操作显示名称

     <userLabel language＝″en″>Add Rack</userLabel>

     <！--Is class operation or not-->  //是否类操作

     <forClass>1</forClass>

<！--Is visible operation or not--> //是否可见操作

<isVisible>0</isVisible>

<！--The description of operation parameters-->  //操作参数的相关信息

<parameters>

    <parameter>

        <！--Operation parameter name-->

        <name>RN</name>

        <！--Data type of Attribute-->

        <dataType>

            <dataTypeInteger minInclusive＝″0″  maxInclusive＝″19″/>

        </dataType>

        <！--Is must give parameter or not-->

        <isNecessary>1</isNecessary>

        <！--Is fixed attribute or not value＝always/selector -->

        <occurrenceType>

          <occurrenceTypeForAll>always</occurrenceTypeForAll>

        </occurrenceType>

     </parameter>

  <parameter>

  ...

  ...

        </parameter>

</operation>

Childrens用于记录被管对象的所有子对象信息以及优先级信息，如机架有两个子对象SUBRACK和RMU，其中SUBRACK的优先级高于RMU，则用下面的方式来表达：

<childrens>

   <！--Sub MOC name and ID-->

      <childManagedObjectClass>

       <name>SUBRACK</name>      //子对象SUBRACK

       <priority>1</priority>    //优先级为1

     </childManagedObjectClass>

     <childManagedObjectClass>

         <name>RMU</name>          //子对象RMU

         <priority>2</priority>    //优先级为2

      </childManagedObjectClass>

</childrens>

2)操作员历史行为保存文件

文件名可以使用“用户名称_用户ID_log.xml”格式，如“admin 99_log.xml”。

历史行为文件中包括多个history标签，每个history标签记录的内容包括：命令名称、命令码、下发接口、终端信息、命令下发时间、命令结束时间、命令所属网元ID、操作结果码、操作结果描述信息、操作的详细描述等信息，具体记录方式如下：

<history>

   <cmdname>ADD RACK</cmdname>           //命令名称

   <cmdcode>1062577</cmdcode>            //命令码

   <interface>LMT</interface>             //下发接口

   <terminate>10.85.160.11</terminate>    //终端信息

   <starttime>2007-06-1412:47:52.045</starttime>//命令下发时间

   <endtime>2007-06-1412:48:53.045</endtime>  //命令结束时间

   <MEID>0</MEID>    //命令所属网元ID

   <returncode>0</returncode>    //操作结果码

   <resultdesc>Succeeded</resultdesc>    //操作结果描述信息

   <detail>ADD RACK:RN＝0，LTITLE＝″0″，POSNUM＝0，ROWNUM＝0，

COLNUM＝0</detail>    //操作的详细描述信息

  </history>

图2所示实施例中的服务端中保存的联想规则为该操作员首次登录到该服务端时选择并记录下的联想规则。如图3所示。图3为本发明实施例中选择联想规则的流程图。假设本实施例中提供了三种可选的联想规则，包括：根据业务逻辑关系进行联想的方式、根据操作员历史行为进行联想的方式以及根据字母顺序进行联想的传统方式。如图3所示，包括以下步骤：

步骤31：操作员通过一客户端登录到服务端。

步骤32～34：操作员选择根据业务逻辑关系进行联想的联想规则；客户端中的智能数据分析模块将此信息发送到服务端，服务端对该信息进行记录，并通过智能数据分析模块向操作员返回定制结果。

步骤35～37以及步骤38～310的实现过程与步骤32～34类似，不再赘述。

本实施例中，操作员可根据自身的需要，选择联想规则，比如，在进行初始环境搭建时，可选择根据业务逻辑关系进行联想的方式；在进行日常维护时，可以按不同的习惯选择根据操作员历史行为进行联想的方式或者根据字母顺序进行联想的传统方式。

完成图2所示流程以后，即可进行本发明所述方案的核心部分，即进行命令联想和参数联想。图4为本发明实施例中客户端进行命令联想以及参数联想的流程图。假设本实施例中操作员选择的联想规则为根据业务逻辑关系进行联想的方式。如图4所示，包括以下步骤：

步骤41：操作员在客户端输入MML命令。

步骤42：在操作员输入MML命令的同时，客户端的智能数据分析模块对操作员要输入的命令进行分析预测，由于本实施例中采用的联想规则为根据业务逻辑关系进行联想的方式，因此客户端分析的资源是业务逻辑关系描述文件。具体联想过程将在随后的实施例中进行详细说明。

步骤43：智能数据分析模块将联想出的命令显示到MML命令的输入窗口。

步骤44：操作员确认联想出来的命令是否正确，如果正确，则直接通过快捷键确认命令；如果不正确，则通过手工修改方式，将联想出的命令修改为所需的命令，然后再通过快捷键确认命令。

步骤45：经过确认后的命令再次发送到智能数据分析模块，此时要执行的命令已经确定。在传统的电信系统中，操作员还需要输入与该命令相关的所有参数，以下发执行最终的命令。但在本发明的实施例中，操作员一旦确认了执行某一命令，智能数据分析模块能够自动进行与该命令相关的参数联想。

本步骤中，智能数据分析模块按照操作员使用某一命令的习惯，联想出一些默认的参数。这种联想方式一是与系统的配置信息相关；二是与操作员所关心的对象以及对象属性相关。比如，系统中配置了OBJB对象，那么某一操作员可能会经常使用DSP OBJB命令，来查看OBJB对象的属性，并且在使用此命令时，经常以某一属性值为过滤条件。本实施例中的参数联想，可以根据不同属性的使用频度，找出使用频度最高的属性作为联想出的参数，从而减少操作员的输入操作。即使操作员本次不想以惯有的属性值作为过滤条件，也可以通过修改属性值来变更参数。

步骤46：将联想出的参数显示到MML命令的输入窗口。

步骤47：操作员根据需要，对联想出的参数进行调整。

步骤48：向服务端下发最终的命令和参数。

步骤49：服务端的接入模块将接收到的命令和参数分发到业务处理模块。

步骤410：业务处理模块进行业务处理。

本步骤中，业务处理模块如何进行业务处理的过程为现有技术，此处不再赘述。

步骤411：业务处理模块向接入模块返回业务处理结果。

步骤412：业务处理成功，接入模块将此次操作的命令和参数及相关信息通过智能数据处理模块记录到与该操作员对应的操作员历史行为保存文件中。

步骤413：智能数据处理模块向接入模块返回文件更新结果。

步骤414：接入模块同步历史数据到客户端的智能数据分析模块。

步骤415～416：智能数据分析模块更新本地的数据资源，并向接入模块返回数据同步结果。

步骤417：接入模块向客户端返回最终的业务处理成功结果。

需要说明的是，本实施例中为便于描述，省略了图1中所示的信息交互模块111。

通过上面的介绍可以看出，图4所示流程完成的工作主要包括：命令联想、参数联想、业务处理以及历史数据更新。其中业务处理和历史数据更新的实现相对比较简单，下面结合具体的实例对联想过程进行说明：

图5为本发明实施例中客户端进行命令联想的具体流程图。如图5所示，包括以下步骤：

步骤51：操作员在客户端的命令行逐字输入字母。

比如操作员要输入的命令为ADD RACK，那么本步骤中，操作员按照A、D、D......的顺序输入字母。

步骤52：由于之前客户端的内存中已经记录了操作员所选择的联想规则，所以本步骤中，客户端中的智能数据分析模块首先去自身的“联想规则记录文件”中查找当前的联想规则。

如果操作员预先没有选择使用哪种联想规则，那么客户端使用默认的联想规则，如“根据字母顺序进行联想的方式”。假设本实施例中操作员预先选择的联想规则为根据业务逻辑关系进行联想的方式。

步骤53：确定联想规则之后，智能数据分析模块根据确定的联想规则找到对应的文件。

当确定的联想规则为根据业务逻辑关系进行联想的方式时，智能数据分析模块找到的对应文件为业务逻辑关系描述文件；当确定的联想规则为根据操作员历史行为进行联想的方式时，智能数据分析模块找到的对应文件为与输入命令的操作员对应的操作员历史行为保存文件；当确定的联想规则为根据字母顺序进行联想的方式时，智能数据分析模块找到的对应文件为命令集文件。其中，命令集文件为现有电信系统中具有的文件，用于记录系统能够下发的所有命令。

步骤54：根据指定的联想规则以及对应的文件进行联想。

步骤55：显示联想结果到客户端。

基于图4和图5所示流程，即可实现在操作员输入命令的过程中，客户端辅助进行命令联想以及参数联想，从而加快操作员的输入速度，并避免操作员重复输入相同的命令和参数。下面通过具体实例说明本发明实施例所述三种联想规则的联想效果：

1)根据业务逻辑关系进行联想的方式：

第一步：在客户端的人机界面输入ADD RACK命令以及对应的参数：

ADD RACK:RN＝0，LTITLE＝″0″，POSNUM＝0，ROWNUM＝0，COLNUM＝0。

第二步：执行ADD RACK命令。

第三步：执行成功后，根据业务逻辑关系描述文件中记录的业务逻辑关系，联想出ADD SUBRACK命令，并且对应的参数如下：

ADD SUBRACK:RN＝0；

用户补充全ADD SUBRACK的全部参数，如下：

ADD SUBRACK:RN＝0，PN＝0，SBRN＝0，SBRNNM＝″Sbrack0-0″。

第四步：执行被联想出的ADD SUBRACK命令以参数。

此范例中机架(RACK)和机框(SUBRACK)之间是父对象和子对象的关系，SUBRACK引用了RACK的属性RN。因此，在ADD RACK执行成功后所联想出来的是ADD SUBRACK命令，并且联想出来的ADD SUBRACK命令的RN参数就是上次执行ADD RACK时添加的机架号RN＝0。

2)根据操作员历史行为进行联想的方式：

假设系统中历史记录为空，即没有人执行过任何命令。

A、不同命令不同参数：

第一步：在人机界面输入LST RACK命令及对应参数，执行5次如下：

LST RACK:RN＝0，POSNUM＝0，ROWNUM＝0，COLNUM＝0；

查询0机架号、0场地号、0行、0列的机架信息，执行结果成功。

第二步：在人机界面输入LST SUBRACK命令及对应参数，执行3次如下：

LST SUBRACK:RN＝0，PN＝0，SBRN＝0；

查询0机架、0位置、0号机框的信息，执行结果成功。

第三步：第8次执行命令成功后，根据用户的历史行为信息联想出的命令和对应的参数为：

LST RACK:RN＝0，POSNUM＝0，ROWNUM＝0，COLNUM＝0；

此范例中的LST RACK为查询机架命令，LST SUBRACK为查询机框命令，分别执行LST RACK命令5次和LST SUBRACK命令3次，之后根据操作员的历史行为信息，联想出来的是LST RACK命令并且附带联想对应的参数，即：LST RACK:RN＝0，POSNUM＝0，ROWNUM＝0，COLNUM＝0；。

B、相同命令不同参数：

第一步：在人机界面输入LST RACK命令及对应参数，执行5次如下：

LST RACK:RN＝0，POSNUM＝0，ROWNUM＝0，COLNUM＝0；

查询0机架号、0场地号、0行、0列的机架信息，执行结果成功。

第二步：在人机界面输入LST RACK命令及对应参数，执行3次如下：

LST RACK:RN＝0；

查询0机架号的机架信息，执行结果成功。

第三步：第8次执行LST RACK命令成功后，根据用户的历史行为信息联想出的命令和对应的参数为：

LST RACK:RN＝0，POSNUM＝0，ROWNUM＝0，COLNUM＝0；。

此范例中的LST RACK为查询机架命令，将附带不同参数的命令分别执行5次和3次，之后根据操作员的历史行为信息，联想出来的LST RACK命令为执行5次的那条命令所对应的参数。

3)根据字母顺序进行联想的方式：

在人机界面输入“LST”，系统会根据字典序，即字母顺序，联想出对应的命令：

假设系统中只有两条LST命令LST ADDR和LST RACK，那么输入“LST”+“空格”之后，联想出来的便是LST ADDR命令，而不是LST RACK，因为按照字母顺序，字母A排在字母R前面。

假设系统中只有两条LST命令LST ADDRIP和LST ADDRPT，那么输入LST ADDR之后，联想出来的便是LST ADDRIP，因为按照字母顺序，字母I在字母P前面。

下面再结合具体的实例，说明一下在实际操作中，客户端是如何根据业务逻辑关系描述文件以及操作员历史行为保存文件进行联想分析，从而联想出所需的命令及其相关参数的。结合联想效果中“根据业务逻辑关系进行联想的方式”的范例进行说明：

1)用户输入ADD RACK命令，并执行成功，更新服务端的智能数据处理模块中的操作员历史行为保存文件(history.xml)和客户端的智能数据分析模块中的内存数据。

2)智能数据分析模块从刚刚执行成功的ADD RACK操作中，取出对象名称RACK。

3)智能数据分析模块在业务逻辑关系描述文件(logical.xml)中找到对象RACK对应的<childManagedObjectClass>数据段，分析其子对象信息和优先级；再根据其子对象，分析其子对象的子对象信息和优先级，RACK对应的子对象信息如下：

<childrens>

   <！--Sub MOC name and ID-->

       <childManagedObjectClass>

       <name>SUBRACK</name>       //子对象SUBRACK

       <priority>1</priority>    //优先级为1

     </childManagedObj ectClass>

   <childManagedObj ectClass>

       <name>RMU</name>           //子对象RMU

       <priority>2</priority>    //优先级为2

       </childManagedObjectClass>

</childrens>

4)根据步骤3)的分析结果恢复出业务逻辑树。

假设RACK有子对象SUBRACK和RMU，SUBRACK优先级高于RMU；SUBRACK有子对象BRD；RMU有子对象SRMU，则恢复出的业务逻辑树如图6所示。

5)智能数据分析模块从刚刚执行成功的ADD RACK操作中，取出对象的操作名称ADD，加上从步骤4)的业务逻辑树中找到的优先级最高的子对象SUBRACK，得到操作名称ADD SUBRACK。

6)得到ADD SUBRACK命令后，智能数据分析模块到logical.xml文件的<operation>段中查找ADD SUBRACK对应的参数，并且根据<isFatherAttribute>判断参数是否是父对象的属性。

举例如下：ADD SUBRACK有参数RN，RN为父对象的属性

“<isFatherAttribute>1</isFatherAttribute>”：

 <operation>

    <！--Operation name-->  //操作名称

    <name>ADD SUBRACK</name>

    <！--Operation code-->    //操作命令码

    <operationCode>1 2288</operationCode>

    <！--Operation display name-->  //操作显示名称

    <userLabel language＝″en″>Add Rack</userLabel>

    <！--Is class operation or not-->  //是否类操作

    <forClass>1</forClass>

    <！--Is visible operation or not-->  //是否可见操作

    <isVisible>0</isVisible>

    <！--The description of operation parameters-->    //操作参数的相关信息

    <parameters>

        <parameter>

            <！--Operation parameter name-->

            <name>RN</name>

            <！--Data type of Attribute-->

            <dataType>

                <dataTypeInteger minInclusive＝″0″  maxInclusive＝″19″/>

            </dataType>

            <！--Is must give parameter or not-->

            <isNecessary>1</isNecessary>

                <isFatherAttribute>1</isFatherAttribute>  //是否父对象属性

                <！--Is fixed attribute or not value＝always/selector-->

                <occurrenceType>

                    <occurrenceTypeForAll>always</occurrenceTypeForAll>

                </occurrenceType>

           </parameter>

          <parameter>

          ...

          ...

            </parameter>

   </operation>

7)现在已经有命令名称ADD SUBRACK，并且知道ADD SUBRACK有一个参数RN，RN为父对象RACK的一个属性。之后，到history.xml文件中查找最近一次执行ADD RACK时，RN的值。本范例中的ADD RACK对应的RN＝0，因此联想结果为ADD SUBRACK:RN＝0；。

需要说明的是，对于图6所示业务逻辑树是采用深度优先遍历还是广度优先遍历，可以直接配置在配置文件，即业务逻辑关系描述文件中，如用“0”表示采用深度优先遍历，用“1”表示采用广度优先遍历，也可以采用命令修改的方式，不作具体限定。

上述实施例中，涉及到多处在history.xml以及logical.xml文件中进行查找的过程，为提高效率，可预先将文件内容读入到内存中。本实施例中的描述方式只是为了便于理解。

可见，采用本发明实施例所述方案，通过分析电信系统数据之间的业务逻辑关系，以及通过分析操作员的历史行为，如下发的历史命令的频度、命令的使用习惯等，智能调整联想命令的内容以及命令的缺省参数值，从而既可起到配置向导的作用，又可使操作员无需花费大量的精力学习、熟悉复杂的系统配置，同时避免了操作员输入相同的命令和参数，节省了劳动。

具体来说，本发明实施例所述方案的优势主要体现在以下三点：

1)能够基于业务逻辑关系来分析操作员的下一步输入，可以引导操作员进行数据配置。比如，操作员第一次增加了一块单板对象，那么其下一步操作很可能是为增加的单板添加一个子对象，应用本发明实施例所述方案后，系统通过应用业务逻辑分析能力，即可联想出操作员下一步要执行的操作，并将联想结果显示到命令行界面。如果操作员确实是要增加这个对象，则可直接执行；如果要增加的不是这个对象，那么系统还会根据操作员的进一步输入再次进行深入分析。

2)能够基于操作员对不同命令的使用频率联想出操作员要输入的命令，可以避免操作员多次输入相同的命令，而不是每次都按照固定的规则联想出命令。比如：操作员要经常执行DSP OBJA命令，来查询OBJA对象的属性，当操作员再次输入DSP时，系统会自动联想出操作员使用次数最多的DSP命令，如果是DSP OBJA，那么将联想出此命令；如果还有比此命令使用频率更高的DSP命令，则联想出那个使用次数最多的DSP命令。

3)能够按照操作员使用某一命令的习惯，联想出一些默认参数。比如：系统中预先配置了OBJB对象，那么操作员可能会经常使用DSP OBJB命令，来查询OBJB对象的属性，并且在使用此命令时，经常以某一属性值为过滤条件。此时，这种基于操作员命令使用习惯分析的辅助参数提示输入方式便显示出其优势，给操作员的使用感受如同系统了解用户的心理一般，方便的帮助其联想出通常要输入的参数。即使操作员本次不想以惯有的属性值为过滤条件，也可通过修改属性值来变更参数。此方式避免了操作员每次执行相同命令时还要反复输入相同属性值的烦恼。

总之，采用本发明实施例所述方案，能够灵活方便地联想出操作员所要执行的命令和参数，为操作员带来如图7所示的体验效果，并提高了电信系统的可用性和可维护性，降低了运营商为系统付出的操作维护成本。

综上所述，以上仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (11)

1.一种命令输入辅助方法，其特征在于，该方法包括：

接收输入的命令；

根据所述输入命令以及获取到的业务逻辑关系描述文件中记录的业务逻辑关系，联想出下一步将要输入的命令。

2.根据权利要求1所述的方法，其特征在于，所述接收输入的命令之前，进一步包括：

操作员所在客户端对所述获取到的业务逻辑关系描述文件进行初始化。

3.根据权利要求1或2所述的方法，其特征在于，所述业务逻辑关系描述文件采用可扩展标记语言XML的格式进行存放。

4.根据权利要求1或2所述的方法，其特征在于，所述业务逻辑关系描述文件中包括一个以上的被管理对象；所述被管理对象的内容包括：对象类ID、对象类名称；或者进一步包括：父对象类ID、子对象类ID、依赖对象类ID，以及被依赖对象类ID中的一种或组合。

5.根据权利要求1所述的方法，其特征在于，所述联想出下一步将要输入的命令之后，进一步包括：

所述客户端显示联想出的供确认的命令。

6.根据权利要求1所述的方法，其特征在于，所述联想出下一步将要输入的命令之后，进一步包括：

所述客户端将记录的所述联想出的命令对应的不同参数中，执行频度最高的参数作为联想出的所述命令的参数；

所述联想出的命令对应的不同参数记录在从服务端获取到的操作员历史行为保存文件中。

7.根据权利要求6所述的方法，其特征在于，所述将执行频度最高的参数作为联想出的所述命令的参数之后，进一步包括：

所述客户端将联想出的命令和参数发送至所述服务端；所述服务端根据所述命令和参数进行业务处理。

8.根据权利要求7所述的方法，其特征在于，所述服务端根据所述命令和参数进行业务处理之后，进一步包括：

所述服务端更新自身保存的所述操作员历史行为保存文件，并同步更新所述客户端的操作员历史行为保存文件。

9.一种命令输入辅助设备，其特征在于，该设备包括：信息交互模块以及智能数据分析模块；

所述信息交互模块，用于接收输入的命令，并显示联想出的命令；

所述智能数据分析模块，用于根据所述输入的命令以及获取到的业务逻辑关系描述文件中记录的业务逻辑关系，联想出下一步将要输入的命令。

10.根据权利要求9所述的设备，其特征在于，所述智能数据分析模块进一步用于，将记录的所述联想出的命令对应的不同参数中，执行频度最高的参数作为联想出的所述命令的参数；所述联想出的命令对应的不同参数记录在从服务端获取到的操作员历史行为保存文件中。

11.根据权利要求10所述的设备，其特征在于，所述信息交互模块进一步用于，将所述联想出的命令和参数发送至服务端进行业务处理，并接收所述服务端回送的业务处理响应消息。

Images