摘要:
本文结合我于2004年在某市级自来水公司开发的水务综合管理系统,介绍了在项目中采用基于构件技术开发的经历与心得。在系统的开发中我结合项目的实际情况,将其分成三个阶段来完成。(1)构件体系结构与接口的设计,为系统的完成打下的基础;(2)基于领域工程的应用构件的开发,重点介绍了构件的提取、适应性修改及新构件的开发过程;(3)运用开发完成的领域构件组装软件系统,这也是系统开发的最终目的。通过采用构件技术为系统的开发积累了大量的可复用资产,为组装式的软件开发提供了现实的基础,在本文的最后一部分也对系统中存在的不足之处进行了简要的总结。
正文:
本人所在的某市级自来水公司经过多年的信息化建设,已经形成了数个应用系统如客户报装业扩系统、营业收费系统、抄表计量系统、人事管理系统及生产调度系统等。由于各系统都是以部门或各分公司为主导建设的,因当时技术条件所限及业务需求的“局部性”等原因,虽然系统从一定程序上解决了业务自动化与效率的问题,但并没有解决各部门与人员之间的协作问题,也不能很好的共享信息,已经成为公司发展的一种桎梏。
针对以上问题,公司领导经过深入的调研分析后,决定于2004年由公司技术部自主开发一套能够较好的解决上述问题的水务综合管理系统。我作为技术部的负责人及主要技术骨干,主持并参与了系统的方案选型、需求分析、设计与开发过程。水务综合管理系统涉及公司从生产到客户服务的几乎所有业务,主要包括客户用水报装工程、抄表计量、费用计算与收取、欠费催收、用水报障、生产调度及客户服务等子系统。
水务综合管理系统不仅需要满足总公司的日常业务需求,而且还要布署到市属所有镇区的自来水分公司。由于各分公司的日常业务流程并不一样,如同样对于客户水费的计算有的是直接由前后两期水表行度相减得到,而有的则要加调表底用水再加公摊水量得到。其它的业务处理也大同小异,如何在有限的资源条件及项目周期内,开发完成适合各企业的水务管理系统成为系统设计的首要目标,做到系统的灵活性与适用性的最佳平衡。
为此,我们需要一种能够利用已经开发过的系统组件搭建新的软件系统的技术,开发其中不存在的业务组件,而不是从头开发,以达到积累和固化开发人员知识财富的作用。在经过对多种开发技术的分析比较后,我决定在系统的开发中引入基于构件的软件开发技术,但因技术部相关开发人员对其不熟,同时,技术部人手也不多(总共7人,除去日常系统维护的可实际投入开发的就4~5人)。为了增强开发人员的信心,我将系统的开发任务分成三个阶段。
首先,通过定义完善的系统体系结构为领域工程中的应用构件开发提供支持。目前支持构件体系结构开发较成熟的模型有CORBA、COM/DCOM及J2EE三大技术体系。它们各有长处如J2EE提供了平台无关性,一次开发多处运行等特点,使其已成为企业级应用的首选平台。而COM/DCOM则是微软提供的在Windows下分布式组件模型,具有开发、布署容易,支持多种程序语言等优点。另外,我司的原有业务都是基于Windows的,经过反复考虑,我们决定采用COM/DCOM体系结构,使新开发的系统具有良好的兼容性与可扩展性。我们还将系统划分成各个独立的层,各层构件独立工作又相互协调的完成系统的功能。有利于系统的维护与升级,而且可以并行的开发这些组件,互不影响。
系统的体系结构如下图所示:
稳定的接口定义为基于构件的开发提供了保障。在基于构件的软件开发中,由于系统是依靠预制的或独立运行的组件协同工作来完成系统的功能。各构件对信息的交换就成为必然。而要完成此工作则必须定义一组能用的信息交换接口。在我们的系统中采用一组服务来完成,上层或需用方通过以XML定义的服务接口向提供者请求服务,系统中的各构件也是利用XML定义的接口发布和请求服务的。这保证了各构件间的相互协作,也为第三方的开发提供了可能。
其次,与构件基础结构对应的是创建可复用资产和可复用的领域构件。可复用构件是领域内通用性较好的对象,在领域构件的开发过程中我们主要采取了以下步骤:
通过对以前的可复用资产进行整理为领域构件的开发打下基础。将原来开发的系统的设计结构、数据流图、业务逻辑规则及所有的文档资料都做一次全面的梳理。将存在的源代码与文档进行统一的标识管理,以便在进行构件开发时可以直接引用相关的数据结构或算法。在上述工作的基础上,对原来系统中一些好的业务流程、效率高、质量好的组件分别从源代码或流程中提取出来,并放入构件库内,详细记录其使用的环境、开发语言、接口定义等资料,为下一步的复用做好准备。
对登记入库的“原始”组件进行适应性修改以满足构件体系结构的要求。在修改的过程中,我们主要从系统的功能出发,在构件库查找到最接近要求的组件,然后按照接口定义进行修改。如对于抄表计量业务构件的开发就是在原来算法的基础上,根据各分公司的计算特点,抽取各家的共性生成一个抽象的处理构件,再对其中特殊的地方(有些存在表底数、公摊、水损等)进行子类化或参数化处理。这样就形成了满足要求的合格组件。
对于没法通过适应性修改得到的构件,我们就根据业务需求全新开发它。在开发时注意了构件的应用环境与不同分公司在业务上的差异性,以使开发出来的应用构件具有较高的复用价值。如对于用户用水工程的业务流程,有的分公司的处理为:申报→安装→交费→开通用水;而有的分公司则为:申报→勘查→工程预算→审批→交费→施工→验收→结算→开通用水。各分公司并不统一,为此我们并不是分别开发,而是根据业务最复杂的流程开发,完成后再根据各分公司的实际情况进行裁剪以满足各自的要求。这样既使开发工作量减到最小,在业务需求与系统开发之间取得较好的平衡,保证了系统各阶段的工作产品按时上线运行,其它的构件如语音查询、实时扣款构件等也如此开发完成。
最后,通过XML定义的接口将各层构件连接到一起形成满足业务要求的软件。从上图中可见系统是通过各层构件相互配合完成任务的,在层与层或构件与构件之间是通过其接口描述文件来进行连接的,并由系统核心的基础件将各构件最终加载到系统中。构件组装人员可以根据业务的需要从构件库中选取合格的构件进行装配以形成可用的应用软件。一方面可以很好的满足业务需求的变化,另一方面也为类似软件的开发积累了大量可复用的资产。
本系统于2005年初投入使用,由于采用构件技术大大缩短了开发的时间,同时也达到了系统的设计目标,培养了开发人员的可复用意识,也使自己的软件分析与设计水平得到了提高。另外,因系统采用的是自定义的软件构件接口,难于与第三方软件交互,这也是系统中存在的不足之处,为此我们打算在第二阶段以Web Services来对系统进行改造,以加强系统的开放性与可集成性。当前IT技术发展日新月异,如面向服务架构(SOA)、面向方面开发(AOP)及中间件技术的发展都为基于构件的开发提供了新的方向,也将使得我的软件分析与设计工作进入到更宽广的领域。
摘要:
本文结合我于2004年在某市级自来水公司开发的水务综合管理系统,介绍了在项目中采用基于构件技术开发的经历与心得。在系统的开发中我结合项目的实际情况,将其分成三个阶段来完成。(1)构件体系结构与接口的设计,为系统的完成打下的基础;(2)基于领域工程的应用构件的开发,重点介绍了构件的提取、适应性修改及新构件的开发过程;(3)运用开发完成的领域构件组装软件系统,这也是系统开发的最终目的。通过采用构件技术为系统的开发积累了大量的可复用资产,为组装式的软件开发提供了现实的基础,在本文的最后一部分也对系统中存在的不足之处进行了简要的总结。
正文:
本人所在的某市级自来水公司经过多年的信息化建设,已经形成了数个应用系统如客户报装业扩系统、营业收费系统、抄表计量系统、人事管理系统及生产调度系统等。由于各系统都是以部门或各分公司为主导建设的,因当时技术条件所限及业务需求的“局部性”等原因,虽然系统从一定程序上解决了业务自动化与效率的问题,但并没有解决各部门与人员之间的协作问题,也不能很好的共享信息,已经成为公司发展的一种桎梏。
针对以上问题,公司领导经过深入的调研分析后,决定于2004年由公司技术部自主开发一套能够较好的解决上述问题的水务综合管理系统。我作为技术部的负责人及主要技术骨干,主持并参与了系统的方案选型、需求分析、设计与开发过程。水务综合管理系统涉及公司从生产到客户服务的几乎所有业务,主要包括客户用水报装工程、抄表计量、费用计算与收取、欠费催收、用水报障、生产调度及客户服务等子系统。
水务综合管理系统不仅需要满足总公司的日常业务需求,而且还要布署到市属所有镇区的自来水分公司。由于各分公司的日常业务流程并不一样,如同样对于客户水费的计算有的是直接由前后两期水表行度相减得到,而有的则要加调表底用水再加公摊水量得到。其它的业务处理也大同小异,如何在有限的资源条件及项目周期内,开发完成适合各企业的水务管理系统成为系统设计的首要目标,做到系统的灵活性与适用性的最佳平衡。
为此,我们需要一种能够利用已经开发过的系统组件搭建新的软件系统的技术,开发其中不存在的业务组件,而不是从头开发,以达到积累和固化开发人员知识财富的作用。在经过对多种开发技术的分析比较后,我决定在系统的开发中引入基于构件的软件开发技术,但因技术部相关开发人员对其不熟,同时,技术部人手也不多(总共7人,除去日常系统维护的可实际投入开发的就4~5人)。为了增强开发人员的信心,我将系统的开发任务分成三个阶段。
首先,通过定义完善的系统体系结构为领域工程中的应用构件开发提供支持。目前支持构件体系结构开发较成熟的模型有CORBA、COM/DCOM及J2EE三大技术体系。它们各有长处如J2EE提供了平台无关性,一次开发多处运行等特点,使其已成为企业级应用的首选平台。而COM/DCOM则是微软提供的在Windows下分布式组件模型,具有开发、布署容易,支持多种程序语言等优点。另外,我司的原有业务都是基于Windows的,经过反复考虑,我们决定采用COM/DCOM体系结构,使新开发的系统具有良好的兼容性与可扩展性。我们还将系统划分成各个独立的层,各层构件独立工作又相互协调的完成系统的功能。有利于系统的维护与升级,而且可以并行的开发这些组件,互不影响。
系统的体系结构如下图所示:
稳定的接口定义为基于构件的开发提供了保障。在基于构件的软件开发中,由于系统是依靠预制的或独立运行的组件协同工作来完成系统的功能。各构件对信息的交换就成为必然。而要完成此工作则必须定义一组能用的信息交换接口。在我们的系统中采用一组服务来完成,上层或需用方通过以XML定义的服务接口向提供者请求服务,系统中的各构件也是利用XML定义的接口发布和请求服务的。这保证了各构件间的相互协作,也为第三方的开发提供了可能。
其次,与构件基础结构对应的是创建可复用资产和可复用的领域构件。可复用构件是领域内通用性较好的对象,在领域构件的开发过程中我们主要采取了以下步骤:
通过对以前的可复用资产进行整理为领域构件的开发打下基础。将原来开发的系统的设计结构、数据流图、业务逻辑规则及所有的文档资料都做一次全面的梳理。将存在的源代码与文档进行统一的标识管理,以便在进行构件开发时可以直接引用相关的数据结构或算法。在上述工作的基础上,对原来系统中一些好的业务流程、效率高、质量好的组件分别从源代码或流程中提取出来,并放入构件库内,详细记录其使用的环境、开发语言、接口定义等资料,为下一步的复用做好准备。
对登记入库的“原始”组件进行适应性修改以满足构件体系结构的要求。在修改的过程中,我们主要从系统的功能出发,在构件库查找到最接近要求的组件,然后按照接口定义进行修改。如对于抄表计量业务构件的开发就是在原来算法的基础上,根据各分公司的计算特点,抽取各家的共性生成一个抽象的处理构件,再对其中特殊的地方(有些存在表底数、公摊、水损等)进行子类化或参数化处理。这样就形成了满足要求的合格组件。
对于没法通过适应性修改得到的构件,我们就根据业务需求全新开发它。在开发时注意了构件的应用环境与不同分公司在业务上的差异性,以使开发出来的应用构件具有较高的复用价值。如对于用户用水工程的业务流程,有的分公司的处理为:申报→安装→交费→开通用水;而有的分公司则为:申报→勘查→工程预算→审批→交费→施工→验收→结算→开通用水。各分公司并不统一,为此我们并不是分别开发,而是根据业务最复杂的流程开发,完成后再根据各分公司的实际情况进行裁剪以满足各自的要求。这样既使开发工作量减到最小,在业务需求与系统开发之间取得较好的平衡,保证了系统各阶段的工作产品按时上线运行,其它的构件如语音查询、实时扣款构件等也如此开发完成。
最后,通过XML定义的接口将各层构件连接到一起形成满足业务要求的软件。从上图中可见系统是通过各层构件相互配合完成任务的,在层与层或构件与构件之间是通过其接口描述文件来进行连接的,并由系统核心的基础件将各构件最终加载到系统中。构件组装人员可以根据业务的需要从构件库中选取合格的构件进行装配以形成可用的应用软件。一方面可以很好的满足业务需求的变化,另一方面也为类似软件的开发积累了大量可复用的资产。
本系统于2005年初投入使用,由于采用构件技术大大缩短了开发的时间,同时也达到了系统的设计目标,培养了开发人员的可复用意识,也使自己的软件分析与设计水平得到了提高。另外,因系统采用的是自定义的软件构件接口,难于与第三方软件交互,这也是系统中存在的不足之处,为此我们打算在第二阶段以Web Services来对系统进行改造,以加强系统的开放性与可集成性。当前IT技术发展日新月异,如面向服务架构(SOA)、面向方面开发(AOP)及中间件技术的发展都为基于构件的开发提供了新的方向,也将使得我的软件分析与设计工作进入到更宽广的领域。
每一个童年的梦想都值得用青春去捍卫!