软件架构设计之十一：软件设计论文样例一

论软件产品线技术

摘要

         本人在通信行业的一家国有企业软件开发部门工作，从2010年初开始，我陆续参加了多个电信网网络管理软件开发项目，这些项目都具有很强的行业特征，其开发方向和应用范围都非常相似。根据部门软件系统开发的需要，我们在软件开发过程中引入了软件产品线技术，成立了基于软件产品线的项目组。本人有幸参加了该项目，并在其中担任软件分析与设计、软件产品线核心资源开发的工作。

         在软件产品线的开发过程中，我们使用了ROSE建模工具，有效地完成了产品线中核心资源和产品的建模分析与设计实现；我们使用了国际标准NMS、EMS数据模型框架，有效地解决了数据的多样性与扩展性，实现了统一开发的电信网数据访问系统；建立了统一的可扩展的电信网拓扑图绘制组件和统一公用的数据处理模块。最终我们圆满的完成了部门产品线的建立和各子系统的开发。

 

正文

         我公司是通信行业内设备制造商，主要从事通信设备研发和制造、电信网网络管理软件的研发工作，在公司内部已经开发了多套网络管理系统，其中包括传输网网络管理软件、接入网网络管理软件、通信设备管理软件、网络监控和采集系统、网络性能查询和告警上报系统，分别由多个项目组分别开发。

         其中，传输网网络管理软件主要完成传输网业务的配置、修改、下载和查询，管理传输网的电信业务。接入网网络管理软件主要完成接入网的业务的配置、修改、下载和查询，管理接入网的电信业务。通信设备管理软件主要完成单个的通信设备管理，通过命令行下发命令到设备，并且接收设备的消息反馈。网络监控和采集系统主要完成业务配置之后的处理，针对的是单个通信设备，包括对网络各通信设备运行情况的实时监控、通信设备数据的实时采集和显示。网络性能查询和告警上报系统主要完成业务配置之后的处理，针对的是电信业务，包括对电信业务的当前性能和历史性能的查询，将电信业务的当前告警和历史告警的上报给电信运营商。

         以上的软件系统具有很强的行业特征，有些系统的开发方向和应用范围都十分相似，表现出了许多共性特征。比如在数据管理方面，都使用了数据库存储，传输网、接入网管理软件和通信设备管理软件，三者中都使用了通信设备的基础数据；数据表现方面，传输网和接入网管理软件都使用了拓扑图，图中有通信设备和它们之间的光纤连接，并且可以查看通信设备的属性，光纤是否断开；数据处理方面，网络监控和采集系统、网络性能和告警查询系统都需要实时绘制图形，都需要根据数据库里的数据绘制历史图形，都需要导出报表。当然，各个软件系统都表现出各自的一些个性特征，如对于实时性较高的网络监控和采集系统，采用了文件系统提高性能。传输网的电信业务种类较多，因此传输网管理软件提供了各层次业务的关系图表，通道层业务路由图表等许多分析工具，其集成的功能要强于接入网管理软件。但是我认为这些软件系统更多地表现为一致性。

         公司针对这些项目组织了相关人员的集体讨论，我提议实施软件产品线技术。主要原因如下：1、本部门长期承接电信网络管理软件开发，开发范围清楚，在多个连续项目中一直存在共性开发。实施产品线可以有效节省人力、物力和财力，避免重复开发的弊端。2、目前这些软件系统都是层次架构，80%采用C/S模式，主要运用在传输网、接入网的业务处理上，其余采用B/S模式或两种组合进行简单数据查询和处理结果显示，有利于产品线架构设计。3、由于行业特点，开发的软件很难适合所有地方电信运营商的需求，因此同一个项目可能出现多种软件版本，如马来西亚版，就要重点处理64k窄路电信业务，其他地方又不需要此功能，采用软件产品线可以方便解决这些问题。4、同时，通信行业中，设备的更新换代速度较快，加入新的设备后，以上所有的软件系统都需要统一改变，采用软件产品线可以实现这种扩展性。

         在软件产品线正式立项后，我参与了项目组的决策，由于公司的设备类型很多，以上软件系统在实际工程中使用的十分广泛，为了是产品线方法的实施风险降到最小，我们决定以演化的方式建立产品线。在基于现有产品架构设计的基础上，将特定产品的构件逐步地、越来越多的转化为产品线的公用构件，从基于产品的方法“慢慢地”转化为基于产品线的软件开发。

         在具体实施过程中，我们采用了SEI模型，即核心资源开发、产品开发和管理。我们首先进行了领域分析，这里分为两路人员，一路分析现有软件系统的架构，一路请公司内部的行业专家和技术专家从大局规划上进行行业分析，对行业分析结果与部门的规划进行整合；在领域分析基础上，进行领域设计，重点是核心资源库的设计，从现有的软件系统中提取共性的模块作为产品线的可复用的构件，以及现有软件系统如何直接复用这些构件。在领域实现时，核心资源库主要构成包括两种具体的产品线架构，一种用于网络电信业务管理的架构，另一种用于网络监控、采集、查询；数据库访问构件组，主要用于业务数据、设备数据、采集数据、告警数据等的存储和访问；电信网络绘制构件组，主要用于传输网和接入网拓扑图的通信设备的绘制、链路绘制等；报表输出构件组，提供excel格式，文本格式，html格式的表格输出；远程进程通信构件组，用于C/S架构和B/S架构的通信中间件。SEI模型中，产品开发，即应用工程，是与核心资源开发互相协作的，没有先后之分，所以我们同时也在根据核心资源库的基础上改造现有的产品，在改造过程中，如果有公共的功能需求，则考虑是否在核心资源库中增加构件，如此循环重复。项目经理负责管理，协调整个产品线开发过程的各个活动，对产品线的成本负责。

         在项目实施过程中，我们也遇到了一些问题：1、由于经验不足，人员分工与组织不合理，核心构件与应用系统开发分界不清，导致了开发设计的反复，工期延迟。2、部分核心资源设计不合理，直接修改构件满足新项目，则使老项目的维护和更新无法与新项目配套，存在一段时间内维护了多个版本构件的情况。3、资源管理不力，因为产品线实施需要非常强大的构件管理和配置管理，此产品线针对联通、电信、移动生成了多个软件产品，维护还包括了核心资源维护和应用系统维护，实施前期经常出现管理不善带来的负面影响。

         到目前，我们通过加强人才培训、资源管理和组织管理来解决这些问题。资源管理上，我们主要通过自动化工具来解决，在系统分析设计和建模上采用Rational的ROSE，软件配置管理采用CVS。在人才培训方面，主要加强抽象建模知识的学习，架构设计知识的学习，是开发人员能从不同需求中抽象出相同部分。

         产品线技术在本部门不断扩充和发展，到目前为止，形成了业务管理、监控采集、性能告警查询、报表报告生成等多方面的产品线架构和构件库，利用这些资源，可方便地快速组装一个网络管理软件系统。通过实施软件产品线，本部门的软件开发模式逐渐规范，不同项目复用同一个或多个产品线架构，做到组件复用的最大化，实施工期明显缩短，极大提高了产品开发过程和产品质量。虽然有了几年的技术和资源的积累，我认为本部门的产品线开发商还存在一些不足，如领域工程方面，缺乏具备深厚行业经验的领域分析人员，需要在不断的实践过程中培养。构件的组装上，还是采用人工代码的方式，缺少智能组装工具。整个产品线开发团队还需要更好的管理和更多的时间磨合。