论软件设计模式的应用
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
本人在2012年参加XXX集团综合计划管理系统项目建设,人在项目组中担任开发组长,主要负责系统分析、关键模块设计、开发工作组织和协调以及系统实施指导。项目建设目的是规范XXX集团公司综合计划管理流程,提高集团公司总部以及下属单位综合计划编制效率,促进各类业务信息有效利用,为集团公司重大经营决策提供及时准确的分析数据和决策依据。我们在开发过程中,运用工厂模式解决了不同类型组织创建的问题,运用策略模式实现指标汇总功能。我们还运用适配器模式解决综合计划管理系统与其它系统接口的集成,运用代理模式解决客户端与服务端通信问题,运用中介模式解决多个业务逻辑类相互耦合的问题。设计模式是我们简化并加快设计,降低技术风险,节省项目开发时间,提高软件质量,同时方便开发人员之间通信。为项目成功实施奠定了坚实基础。
本人在2012年参加XXX集团综合计划管理系统项目建设,该项目共有15名成员,为了明确人员工作角色,方便团队协作,项目组分为四个小组:需求组、开发组、测试组、实施组。本人在项目组中担任开发组长,主要负责系统分析、关键模块设计、开发工作组织和协调以及系统实施指导。项目建设目的是规范XXX集团公司综合计划管理流程,提高集团公司总部以及下属单位综合计划编制效率,促进各类业务信息有效利用,为集团公司重大经营决策提供及时准确的分析数据和决策依据。
XXX集团是一个特大型央企,主要业务领域是电力,下属单位分布在全国各地。系统使用范围不但需要覆盖集团总部规划计划部和各专业部门,还要覆盖各二、三级单位。因此,要求系统具有分布式访问能力。XXX集团第一次建设类似的系统,即使同行业其它电力集团也没有类似的系统可供参考和学习,给系统建设带来一定挑战。通过我们对业务原型的分析,系统功能模块包括系统首页,指标填报、计划编制与平衡、计划汇总、计划版本管理、
计划分解与下达、计划调整、计划跟踪与分析、计划考核等功能。系统急需要解决:综合计划编制状态和流程基本不可控;指标勾稽关系复杂,填报工作量大,综合计划编制效率低下;数据填报格式能随意修改,数据汇总难度大。数据的采集、传输、存储、管理、利用流程贯穿系统整个体系结构。系统架构设计要求具有良好灵活性和扩展性,适应集团公司每年对综合计划管理办法修订和经营战略调整。根据项目业务背景和招标书要求,系统采用B/S架构,系统后端采用J2EE平台,前端采用AJAX技术进行展现,应用服务器采用WEBLOGIC11G,数据库服务器采用ORALCE11G,采用集中式部署,即一级部署。
设计模式是前人经验的总结,它使人们可以方便地复用成功的设计和体系结构。设计模式共23种,主要分为三种类型:创建型、结构型和行为型。在综合计划管理系统开发过程中,我们主要应用了工厂、单例、中介、代理、策略、状态、适配器等模式。
综合计划管理系统需要管理多种类型组织机构,例如火电企业、水电企业、风电企业等,这些组织机构的属性基本相似,但是不同应用场景表现的行为不一样。火电企业、水电企业都有名称、法人代表、单位地址、资本金构成等信息,但火电企业计算发电量、营业收入和利润的方法与水电企业不同。并且不同类型的组织机构关联的指标也不一样,火电企业有供电煤耗指标,而水电企业没有。但是每种企业类型的综合计划编制流程是一样,都需要经历编制、审核、上报、分解等过程。经过我们对业务逻辑的分析,解决不同的用户类型使用匹配的组织机构对象来编制综合计划,我们使用工厂模式来处理组织机构对象的创建。
首先定义一个组织机构抽象类,包含所有类型组织机构必须具备的属性,例如名称、所属省份、地址、编码等信息,定义综合计划编制、审核、上报、分解等抽象方法,把具体实现交给子类去完成。接着继承组织机构抽象类,定义具体组织机构类,在这些子类中根据自身业务逻辑的要求,实现父类的抽象方法。再接着定义一个工厂类,负责子类对象的实例,能够根据电力类型,自动创建匹配的实例,工厂方法返回值是组织机构父类的对象。
通过采用工厂模式,当新增加一种组织机构类型的时候,只需要扩展工厂方法即可,我们不用修改综合计划编制流程,一些通用的方法可以继承,降低开发工作量。同时,组织结构对象实例能够集中维护,提高了代码质量。
综合计划管理系统还需要实现按不同条件,不同层级要求,动态组合不同指标数据进行汇总计算。例如发电量可以按企业从属关系汇总、还可以按区域省份进行汇总或者只汇总火电企业,且需要按照区域省份隶属关系汇总。经过我们的分析,指标数据汇总主要分为两个部分:维度数据组织即指标属性信息组织和指标数据处理与计算。相同的指标不同的汇总的方式,维度数据和指标数据的数据源是相同的,只是数据加工方式不同。为了使数据组织的算法与汇总控制类进行分离,我们采用了策略模式。
首先我们为维度数据和指标数据分别定义了一个汇总策略接口,在接口中定义数据组织的通用方法;接着在不同的子类中实现不同条件下维度信息层级组织以及指标数据汇总计算;最后根据不同输入条件,实例化维度策略实例和指标数据汇总实例,传递到汇总控制类。汇总控制类只与接口进行关联,不依赖具体的子类。汇总控制类负责执行具体汇总策略,并把汇总后的指标数据匹配到对应维度的信息上。
在实现指标汇总功能的时候,我们起初没有应用策略模式,而是采用传统方式,每种汇总方式对应一个类来实现。随着项目的推进,客户不断提出新汇总需求,而这些新需求都是几种基础汇总方式组合以后实现,导致系统出现大量重复代码,程序可维护性越来越差,工作量也越来越来大。经过研究和分析,我们采用了策略模式,不但解决指标汇总功能的实现,而且大大降低后续开发的工作量。
在项目开发过程中,我们还运用适配器模式解决综合计划管理系统与其它系统接口的集成,运用代理模式解决客户端与服务端通信问题,运用中介模式解决多个业务逻辑类相互耦合的问题。设计模式是我们简化并加快设计,降低技术风险,同时方便开发人员之间通信。
设计模式节省了项目开发时间,提高了软件质量,为项目成功实施奠定了坚实基础。综合计划管理系统在2013年5月,通过了XXX集团公司验收。系统各项功能都满足项目招标书要求,取得用户一致好评。但是由于项目时间和资源的限制,仍然还有一些地方做的不够。我们系统中有些功能模块对性能要求比较高,为了快速解决客户的问题,又能提高代码的质量,我们过于强调设计模式的实现,而忽略其它质量属性,导致模块的性能参数达不到最佳水平。我们需要在设计模式和反模式之间找到恰当平衡点,满足项目实际需要。同时自己应该加强专业技术学习,认真捕获经验教训,在未来的信息化建设项目更好地贡献自己的一份力量。