为了提高数字电视软件开发过程中对软件需求变化的适应性，综合地使用MVC模式、抽象工厂模式、观察者模式、模板模式和策略模式，从对象层建立、消息驱动和行为扩展三个方面实现了一种软件架构设计，有效地降低了系统耦合性，提高了开发效率。
1 引言
目前，在数字电视机顶盒的设计过程中，对软件部分的需求变化日益增高。这些变化集中体现在用户界面、数字电视协议、业务功能、系统平台这四个方面。一般的业务功能除了搜台、播放、节目电子指南基本功能之外，还需要节目预约、前端检测等特定功能。每种功能的实现不仅需要基于特定的数字电视协议，包括欧洲的DVB、美国的ATSC、日本的ISDB等，也需要依赖特定的系统平台，根据客户的需求来设计不同的数据呈现方式和交互方式。
为了迅速地应对这种需求变化，一般采用敏捷式开发模型，通过阶段性的迭代式开发，进行功能的扩展。在每个迭代过程中，为了实现软件的可修改性和软件模块的复用，提高软件开发效率，减少出错，本文综合地应用了几种基本的软件设计模式，针对用户交互、业务组织和数据解析等常见需求变化，实现了一种软件架构设计。
2 软件架构总体设计
如图1所示，软件架构中所涉及的静态类包括几个类别，分别是：视图类(View)、控制器类(Controller)、模型类(DVBFilter)、业务类(DVBEpg)、工厂类(DVBFactory)、消息中心类(Notificaction)和算法类(ConcreteStrategy)。这几种类的具体职能体现了以下基本设计模式的综合运用。
3 MVC模式
MVC是一种复合设计模式，可以由几种基本设计模式组成，实现方式因应用场景各异，例如WEB应用、APP应用等。它的设计原则是将应用程序划分为三个层次：视图层、控制器层和模型层，并规定层次之间通信的方式，将数据从视图中分离出来，使得界面和数据可以单独开发，让表现不依赖数据。在架构设计中View会响应输入设备的操作，并描画自身(Draw())。
由于某些视图类对描画性能有要求，所以可以直接缓存需要的数据(CacheViewData);DVBFilter响应数据设备的请求，对得到的设备数据进行处理;Controller可以直接管理视图类和模型类，控制它们的生命周期和通信，也可以通过工厂类和业务类间接维护。由于视图类和模型类需要响应系统事件，所以对平台的依赖较大。因此，尽可能将逻辑处理放在控制类，便于重用。
4 观察者模式
MVC模式的设计重点之一就是三种类之间的信息交互。控制类观察视图、模型的状态，对感兴趣的数据、状态变化进行处理。借鉴观察者模式的特点，本文提出一种更为灵活的消息驱动方式。消息中心可以分为两大类：应用层消息中心(Notifaction)和系统层消息中心(OSNotifaction)。后者又可以细分为两个子类：输入设备消息中心(InputNotifaction)和数据设备消息中心(DemuxNotifaction)。系统层消息中心依附于独立线程(threadID)，获取系统的事件(GetInfoFromOS())。
视图类依据自身的特点需要关心某些外部输入设备的状态，例如鼠标或者触摸屏的点击;模型类则一般需要关心外部数据设备的状态，例如媒体流设备数据的就绪。因此，二者分别需要将自己作为观察者注册到对应的消息中心(AddObserver())。当有系统事件发生的时候，消息中心分别通过(NotifyWithEventType())和(NotifyWithTableType())进行通知，使得View可以执行(InputEventProcess())，DVBFilter可以执行(DataEventProcess())。在处理事件的过程中，如果需要对行为进行扩展，则需要向应用层消息中心发送特定消息(NotifyWithMessage())，让其观察者即控制类进行处理(BehaviourFunctionForView())、(BehaviourFunctionForModel())，完成视图类和模型类之间的通信;通过(DataSourceFromModel())完成其间的数据转化。
5 抽象工厂模式
控制类负责对业务进行建模，根据不同的协议创建不同的功能模块，它属于两个维度的变化。可以选择抽象工厂模式构建业务对象层次。抽象工厂模式用于创建两个维度的产品线。抽象工厂代表了特定的协议类型，(DVBabstractFactory)制定具体工厂(DVBFactory)可以生产的DVB协议产品类型。(CreateDemuxNotifaction())创建该协议的数据设备消息中心(DVBDemuxNotifaction)，(CreateEpg())创建该协议的EPG业务类(DVBEpg)。业务类则负责各种模型类的建立和维护。
控制类根据应用对协议的选择，创建具体工厂，一种协议只有一个工厂，遵循单例模式。具体工厂实现每个具体产品的创建。产品的创建细节和工厂方法绑定。具体产品的协议特性由抽象产品决定(DVBabstractProduct)。这种设计让具体工厂和具体产品紧耦合，工厂方法的个数和具体产品数目相同 ，但是为了遵循开闭原则，一般适用于产品类型固定的情况。
6 模板模式和策略模式
工厂类完成业务功能的创建。业务功能的创建过程中指定需要收取哪些数据，即创建哪些模型。由于机顶盒厂商对应用的需求不同，即使在同一种协议标准下，对数据的格式定义也不尽相同，例如某些自定义私有数据，自定义私有描述符。为了解决上述问题，提供良好的扩展性，将模板模式和策略模式相结合，达到在统一的解析架构之中对可变的部分进行分离的效果。模型类DVBFilter由业务类DVBEpg创建并维护，负责数据的收集和解析。一种业务类可以包括多个模型类，去收集数据格式特定的表。模型类通过(ProcessData())对数据中心获取的原生表数据(TableData)进行解析，形成视图类需要的数据(ViewNeedData)。解析的过程包括解析头部(ParseHead())和描述符(DescriptorProcess())两个固定部分，是一个算法模板函数。不同的模型类由于数据格式的迥异，对这两个部分的实现可能都不一样，所以具体模型可以根据需要重载这些方法。(Filter4e)就是解析DVB协议中数据格式为4e的EIT表。
对于同一种模型类，头部解析是固定的，描述符的解析是可变的。这种变化体现在描述符的种类和数目不同，但是解析的骨架结构固定。因此，可以设计有限个策略算法(StrategyA和StrategyB)，每个策略都会解析一定类型的描述符(DescriptorProcess())。如果解析的类型需要改变，可以通过具体策略算法重载(ConcreteStrategy)。
7 架构对需求变化的处理
由于软件需求变化的要求不同，对架构的修改程度也不同。表1是对需求变化的假设和架构相应做出的修改方案。从修改结果可以看出，按照对架构内容的修改程度的不同，由低到高可以分为函数和类两个层次。不难看出这种软件架构可以让因需求变化而作出的修改尽可能遵循开闭原则，所修改的内容耦合性底，使得功能扩展具备插件化，降低每次修改对整个软件维护的影响，提高了迭代开发的效率。
7 结语
这种以基本设计模式组织起来的架构使得各个模块可以依据接口独立开发，并在需求改变时分别增加功能而互不影响。除此之外，由于模块功能的耦合性低，功能较为集中，可以编写一个程序对模块间的联系进行自动处理，进而将模块变为可视化控件，达到对软件进行可视化编程的目的，从而提高整个软件开发的灵活性和敏捷性。
作者：王津津 来源：电子技术与软件工程 2015年1期
