对网管软件开发的一点感悟

  本文主要面向具有一定网管开发经验的读者。

  本人在毕业后不长的工作时间里，大多数时间从事的都是电信网管软件的开发，期间经历了大小不同的公司，也有幸从头到尾做过一些大型的网管软件的开发，甚至还不自量力的要去做一些网管开发平台。

  我个人的背景，主要是在EMS（网元管理层）网管的开发，对NMS层有一些接触，对设备的开发也有些接触，但都属于隔靴骚痒，看着别人爽，文中提到的方法和思路，虽然多为通用的，但具体的一些方法对于其他类型的软件未必适合。
 
  传统的TMN里，EMS网管只是其中一小块，借用TMN的方法论，就EMS网管本身，用接口划分的方式，网管有如下三个大的接口：

  G接口：为网管提供给操作运维人员的人机界面(MMI)，一般有基于BS技术的Web形态，基于CS技术的Java Swing, Delphi，基于命令行的CLI也是一种人机界面，这个G字可能需要再广义一点。

  F接口：为网管内部接口，主要在网管的服务器和各类客户端之间的接口，网管一般采用集中部署的模式，网管服务器对设备一般充当了Manager的角色，它的客户端有多种形态，包括各种G接口的实现，甚至可以将网管与上级网管之间的北向接口也作为一种客户端，F接口就是这些客户端和服务器之间的接口。

  Q接口：为网管和被管设备之间的接口，它是一种机机接口

  G接口代表了网管的管理需求(Managing Requirements)，Q接口代表了网管的被管需求(Managed Requirements)，而F接口代表了网管的开发需求(Development Requirements)。

  在我从事的很多网管项目的开发，由于团队中开发的角色较多，对网管的认识不足，产生了一些误区，概括的来讲，就是：
  1、从F接口入手：因为在开发人员占主导，或者具有较深开发背景的占主导的团队中，大家往往最能想清楚的就是开发的这么点破事，所以，最容易先抓住F接口不放，设计各种模型，服务；

  2、忽视Q接口：忽视Q接口的理由很多，有设备方面的问题，诸如设备没有定稿，设备不在自己掌握范围之内，设备接口不规范，总是能找到一大堆理由，但忽视了Q接口这一点很致命，一个网管，如果在开发过程的始终都没有搞清楚自己管的东西，如何成为一个"正确"的网管，如果连正确都做不到，这个产品或者项目就免谈成功了.

  3、随意指定G接口：G接口的随意化，也是有多种原因
  首先就是需求管理的不严格，不规范，国内现在很多软件公司，呆在家里三言两拍就可以为用户想好需求，随后设计界面和交互流程（就是G接口）；
  其次也有现在项目团队组成过于复杂的原因，从用户到产品经理、系统工程师，设计人员、开发人员，各种测试人员，实施人员，一个原始的需求，经过若干个部门和流程上的环节，传导到真正开发这里的时候，已经是面目全非，时间也滞后了很多。

  实际上，以上的三个接口有其各自的特点：
  G接口：形态多样化，需求变化较快，虽然网管的界面需求变化赶不上业务系统的变化，但由于这个接口是面向具体的人，其需求的变化是最难以琢磨的，但各种界面元素、流程其中的可复用度又是非常之高。
  F接口：实现技术多样(WebServcie, Java RMI, Corba...可以列举一大堆)，实现方式多样(各种设计模式都可以在这里一展身手)，弹性十足，高水平的网管和低水平的网管，其F接口的设计和实现很容易有云泥高下之分。
  Q接口：相比较为稳定，无论从接口信息本身，还是从接口的实现技术(Snmp,TL1,Q3,Corba,各大厂商的私有协议...)，往往都比较稳定。

  而我以上所提到的错误的网管开发思路，其主要错误就在于一开始抓住的是一个具有多种实现方案，不该被固化的F接口，而忽略了一个可以被“固化”的Q接口，随后而来对G接口的开发的错误也自然而然，甚至有一些更错误的方式是先定义G接口上各种界面，而后为每个界面定义一套F接口上的服务和模型，在我看来，这更像是一种过程式的开发思路。

  写了这么多，好的方法在哪里？我个人认为，好的步骤是：
  1、深挖Q接口，整理出其中的信息模型和接口、主要业务流程
  2、详列G接口，将所有的界面都预先通过Screen Design(界面设计)，Interactive Process Design(交互流程设计)的方式列举出来，找出其中共用的界面组件、交互流程。
  3、归纳F接口，F接口本质上是为G接口服务的，当G接口被详细列举之后，其中共用或者类似的组件，流程，所调用的F接口往往都是类似的，这些接口就是可归纳的，而不需要每个模块，每个对象都重新定义一套模型和服务。