可定制模式（精选七篇）
可定制模式 篇1
关键词：多承租,Portlet,协作,可订制
0 引 言
SaaS意味着一种全新的商业模式。这种商业模式的核心特征可概括为[1,2,3]:1) 软件部署为托管服务通过互联网访问,使得整个IT基础设施的管理和维护责任从客户转移到了外部供应商。2) 用户定制自己需要的服务模块,在用户层形成个性化差异,这种定制包括特定的界面、业务流程、数据结构等,对SaaS软件的开发提出了很高的要求。3) 通过租用的方式收取费用,企业用户根据选用的功能模块的不同和使用时间的长短采取租用的方式向SaaS服务提供商付费,彻底改变了传统软件的交付行为,客户和SaaS服务提供商达成租约,客户成为服务的租户。
在软件实现层面,SaaS对软件开发带来的改变在于其提出了“多租户”这一新的概念。两个公司(租户)租用同一个部署在服务运营商处的服务,租户对服务进行定制,形成自己看到的软件形态,不同租户公司内部的用户所看到的是不同的软件,彼此之间相互透明。在软件体系结构上对多租户支持的不同实现方法形成了SaaS软件成熟度模型[4]。如图1所示。
Level1成熟度相当于原来的ASP(Application Service Provider)模式,在实现层面上每个租户对应一个软件实例,每个实例根据租户的特性需求开发,彼此不同相互独立。Level2成熟度也是每个租户一个软件实例,但这些实例都是基于同一套相同的代码和数据结构,不需要根据每个用户的需求进行重新开发,在代码开发时充分考虑了可配置性,针对不同的租户采用灵活的配置来生成软件实例。Level3成熟度是指用一个软件实例满足所有租户的要求,除了可配置之外还增加了“多承租”特性,使同一实例能够承担多租户的请求,而租户的UI、流程、数据结构等都通过技术手段加以隔离。这就是SaaS模式下的多承租体系结构。Level4成熟度是在Level3的基础上加入了负载均衡,以便提高应用的性能和可扩展性。
Level3级别的多承租体系结构和技术是SaaS软件成功的关键,它降低了服务运营商的成本,最终使SaaS模式在商业上成为可能[5]。
以SaaS的方式提供Portal服务,不仅可以利用云计算等后台技术降低服务运营商的成本,而且其租用模式也大大降低了服务使用者的维护成本,这将使Portal产品更加具有市场竞争优势。Portal系统由若干Portlet组件构成[6],规范定义了Portlet间的协作方式。在SaaS模式下不同租户必然有自己特殊的协作需求,这就要求Portal系统提供租户可订制的Portlet协作方式,对现有规范所定义的协作模型提出了全新的挑战。
1 现有Portlet协作规范对多租户的支持
1.1 Portlet协作规范
JSR286规范是门户技术的核心,它完整地定义了Portlet组件的使用方法和接口,规范定义Portlet组件有两种专门的协作方式:
一是基于公共渲染参数的协作。可以定义在各Portlet间共享的公共渲染参数,在动作处理阶段组件可以设置该参数的值,在随后的Render阶段支持该共享参数的Portlet都能看到被设置的值,以此来达到协作的目的。
二是基于事件的协作。组件间还可以通过事件机制进行协作,在动作处理阶段组件发送定义好的事件,事件的发生会引起其它组件的被调用,在事件处理阶段组件仍然可以继续发送事件。如下配置片断所示:
<public-render-parameter>
<identifier>foo</identifier>
<qname xmlns:x=″http://example.com/params″>x:foo2</qname>
</public-render-parameter>
<event-definition>
<name>event1</name>
<value-type>java.lang.String</value-type>
</event-definition>
<portlet-name>portletA</portlet-name>
<supported-public-render-parameter>
<name>foo</name>
</supported-public-render-parameter>
<supported-publishing-event>
<name>event1<name>
</supported-publishing-event>
定义了公共渲染参数foo和事件event1,且PortletA声明了支持公共渲染参数foo并且可发送event1。
1.2 对多租户的支持
当Portal系统SaaS化时,不同的租户将定制自己需要的Portlet组件协作方式。但现有协作规范只能以Level1级别的方式来实现多租户对Portlet协作的定制,即为每个租户单独开发和部署其专有的Portlet组件。这种非“多承租”方式给Portal的SaaS化带来了极大的开发负担。
现有规范定义的协作模式无法区分不同租户对同一组件定义的不同的事件接收与发送集合,虽然在配制文件中不会造成冲突,但是由于不能区分不同租户的定制,会给容器带来混乱和极大的运行时开销。如图2(a)所示。
租户1定制了PortletA与PortletB以事件Event1进行协作,租户2则定制PortletA与PortletC以事件Event1进行协作,现有的组件模型规范下组件容器感知到的是如图2(b)中的样子,即PortletA以事件Event1同时和PortletB与PortletC进行协作。当事件Event1被触发时,容器同时调用组件PortletB与PortletC的事件处理方法。这种不能区分不同租户对同一组件所定义的事件接收集合与发送集合的弊端,将给协作带来流程的混乱并给容器实现带来极大的运行时开销。
本文对规范定义的协作模型进行扩展,使得扩展后的Portlet可以以单实例多租户的“Level3”级别的方式来实现多租户的定制。
2 支持多承租体系结构的Portlet协作模型
2.1 对协作配置的扩展
为了使单个Portlet组件可以感知不同租户所定制的不同的协作行为,首先扩展配置文件的表达能力,在配制文件中加入<Tenant>元素以表示租户信息。如下的配置片断所示:
<portlet-app>
<description>公司A</description>
<name>公司A</name>
<description>公司B</description>
<name>公司B</name>
定义了两个租户(公司A和公司B)。为了隔离不同租户对同一组件的协作行为增加<tenantspecific>元素,该元素为<supported-processing-event><supported-publishing-event><supported-public-render-parameter>元素的子元素,使得每一个被支持的公共渲染参数和事件都能关联到一个租户上,以此描述租户定义的协作范围,如下片断所示:
<portlet-name>portletA</portlet-name>
<supported-public-render-parameter>
<name>foo</name>
<tenantspecific>
<tenant-ref>公司A</tenant-ref>
</tenantspecific>
</supported-public-render-parameter>
<supported-publishing-event>
<name>event1<name>
<tenantspecific>
<tenant-ref>公司A</tenant-ref>
<tenant-ref>公司B</tenant-ref>
</tenantspecific>
</supported-publishing-event>
<portlet-name>portletB</portlet-name>
<supported-public-render-parameter>
<name>foo</name>
<tenantspecific>
<tenant-ref>公司A</tenant-ref>
<tenant-ref>公司B</tenant-ref>
</tenantspecific>
</supported-public-render-parameter>
<supported-processing-event>
<name>event1<name>
<tenantspecific>
<tenant-ref>公司A</tenant-ref>
</tenantspecific>
</supported-processing-event>
<portlet-name>portletC</portlet-name>
<supported-public-render-parameter>
<name>foo</name>
<tenantspecific>
<tenant-ref>公司B</tenant-ref>
</tenantspecific>
</supported-public-render-parameter>
<supported-processing-event>
<name>event1<name>
<tenantspecific>
<tenant-ref>公司B</tenant-ref>
</tenantspecific>
</supported-processing-event>
租户公司A定义了其共享参数和事件的协作范围为PortletA与PorteltB,而租户公司B定义了其共享参数的协作范围为PortletB与PortletC,事件的协作范围为PortletA与PorteltC,如图3所示。
这就使不同的租户间定制的共享参数和事件发送与接收的范围得到了隔离。
在运行时的隔离由组件容器来保证,容器必须把公共渲染参数发送到相同租户所定义的范围内且声明支持此参数的那些Portlet组件,组件容器必须仅在相同租户定制范围内的Portlet组件间共享此公共渲染参数。
事件的发送和接收也采用同样的原则,在一次请求处理间组件容器必须保证组件只能触发当前租户订制范围内的事件,对于触发的事件,组件容器只能调用当前租户订制范围内的且声明支持此事件处理的Portlet组件中的ProcessEvent方法。
对Portlet组件的配置和运行时语义做了上述修改后,组件可以识别租户的信息并有效地隔离不同租户对协作的定制,使组件可以用单实例的方式来满足多个租户的需求,满足了Level3级别的多承租体系结构的需求。
2.2 对访问接口的扩展
为了保证运行时租户定制的有效性必须在规范中增加新的接口并重新定义相关已有接口方法的语义。在规范中新增Tenant接口,租户信息由该接口得到,其包含方法为getDescription()和getName()。对已有接口的扩展如图4所示。
1) 在PortletConfig接口中新增getTenants()方法,该方法返回配制文件中所有定义的租户信息。新增getProcessingEventQNames(Tenant tenant)返回指定租户范围内该Portlet组件所有声明支持处理的事件的QName,如果没有与该租户相关的支持处理事件则返回一个空枚举对象。类似方法还有getPublicRenderParameterNames(Tenant tenant)和getPublishingEventQNames(Tenant tenant)。
2) 在PortletRequest接口中重新定义方法getPublicParameterMap(),该方法必须返回与此次请求相关联的租户定制的公共渲染参数的Map对象,如果没有与该租户相关联的公共渲染参数则返回一个空Map。该接口中一切与得到公共渲染参数相关的方法,如getParameter和getParameterMap,都应该遵守以上规则,当公共渲染参数对组件不可见时,该参数的返回值为NULL。
3) EventRequest接口中重新定义方法getEvent(),容器必须保证每次调用该方法所得到的事件为当前发起请求的租户所定制。
4) StateAwareResponse接口中重新定义方法 removePublicRenderParameter(java.lang.String name),当调用此方法时,如果被移除的公共渲染参数被当前租户所定制,则容器只移除该租户对该公共渲染参数的定制;如果该公共渲染参数不被当前租户所定制,则此调用不产生效果。setEvent和setRenderParameter方法也必须考虑当前发起请求的租户,只有当设置的事件和公共渲染参数在当前租户定制范围内时这些调用才发生效果。
5) EventResponse接口中重新定义方法setRenderParameters(EventRequest request),当被设置的是公共渲染参数时,容器必须保证只有当该公共渲染参数被当前请求所关联的租户定制的情况下此设置才发生效果。
6) BaseURL接口中的getParameterMap()方法和setParameter方法作同样的处理。PortletURL接口中的removePublicRenderParameter(java.lang.String name)方法与StateAwareResponse接口中的作同样的处理。
3 多承租可订制的Portlet协作的设计
为了实现对规范的扩展,必须对Portlet容器中portlet协作模块进行扩展,新增租户管理模块并对已有的协作实现流程进行扩展。
3.1 租户管理模块
在容器中加入租户管理模块(TenantManager),该模块提供对租户的管理,租户信息的获取和租户相关的信息过滤与隔离机制。模块主要的对外接口为:
getTenants:返回系统现有的所有租户信息,该信息可通过规范新增的Tenant接口访问。
isPublicRenderParameterAllowed:在一次请求期间,判断给定Portlet所要读取的公共渲染参数是否被某一租户所以定制。
isPublishEventAllowed:在一次请求期间,判断给定Portlet所要发布的事件是否被某一租户所定制。
isProcessPortletAllowed:在一次请求期间,判断给定事件的接收Portlet是否在某一租户的定制范围内。
3.2 基于租户的协作过滤
协作模块已经提供了两个接口来支持基于公共渲染参数的协作,在多租户模式下,每次调用setPublicRenderParameter和getPublicRenderParameter方法时,都要调用租户管理模块来进行基于租户的过滤。只有当被读取的公共渲染参数被当前的租户所定制时,此读取动作才发生效果,如图5所示。
公共渲染参数设置 Portlet在ActionProcessing或者EventProcessing阶段通过PortletResponse的setRenderParameter设定渲染参数,PortletResponse将调用协作模块的setPublicRenderParameter,该方法会调用租户管理模块的isPublicRenderParameter方法进行基于租户的过滤,如果过滤为真,则协作模块将该参数保存到共享空间中。
公共渲染参数获取 在Portal的渲染阶段,Portlet可以通过PortletRequest的getParameter等方法获取参数,该方法会调用协作模块的getPublicRenderParameter 方法取出参数,这里同样调用租户模块进行基于租户的过滤。
Portlet在动作处理时通过PortletResponse发布事件。容器已经实现了对事件的注册管理和注册事件的分发,在多租户模式下协作模块在事件注册时必须进行基于租户的过滤,只注册当前租户定制了的事件;在对注册的事件进行分发时,也必须对目标Portlet进行基于租户的过滤,只把事件分发给当前租户定制了的Portlet。图6描述了新的事件处理流程。
事件发布 Portlet在ActionProcessing或者EventProcessing阶段通过PortletResponse的setEvent可以发布事件。如果该事件是Portlet支持的发布事件,该事件会调用协作模块的registerEvent方法,在该方法种调用租户管理模块的isPublishEventAllowed方法进行基于的过滤,如果过滤结果为真,则该事件被注册到协作模块中。
事件分发 对于注册到协作模块中的事件,协作模块根据容器中Portlet的定义信息查找可以处理该事件的Portlet,并调用租户管理模块进行基于租户的过滤,然后请求容器对该Portlet发起事件请求。
3.3 在OncePortal系统中的实现
OncePortal[7]是由中科院软件所基于J2EE平台开发的门户中间件,目前最新版本支持JSR286规范。根据上面的设计思路,我们在OncePortal中实现了支持多租户可订制的Portlet协作模型。
在Portlet.xml文中新加入了两个元素,<tenant>元素是<portlet-app>的子元素,它用来表示租户信息。它包含两个子元素,<description>元素表示租户的描述信息;<name>元素表示租户的名称,该名称在Portlet-app范围内必须唯一,一般可使用租户的公司名称。扩展了<supported-processing-event>、<supported-publishing-event>和<supported-public-render-parameter>三个元素,在每个元素下增加了<tenantspecific>元素,该元素表示租户对事件和公共渲染参数的订制信息。它包含多个名为< tenant-ref >的子元素,该元素的内容为<tenant>元素中的<name>的值,以此表示该租户订制了该Portlet对某个协作参数的支持。
在OncePortal的Portlet容器中加入“租户管理模块(TenantManager)”。整个容器的模块结构变为如图7所示。
协作模块(CoordinationHandle)需要调用租户管理模块进行协作流程的过滤,具体方法已在3.2节中论述。应用注册模块(PortletAppRegistry)要根据新的Portlet.xml文件做修改,环境管理模块要负责提供加入租户信息的接口对象,以实现对规范定义的接口的扩展,实现细节不再赘述。
3.4 租户管理模块包结构
在容器中租户管理模块实现为租户管理服务(TenantManager),容器中的包结构如图8所示。
Service.TenantManager包中TenantManagerService类用于以服务的方式实现租户管理模块;om.tenant包中Tenant类用于实现租户数据结构,TenantInterface类用于实现租户数据接口。
4 应用案例
考虑一个以SaaS方式提供的旅行门户网站,其中一个Portlet负责输入对旅行的需求,如期望的日期、人数和地点等信息;另一Portlet(旅行定制Portlet)包装了旅行社提供的旅行定制服务,该服务可能通过Web Service的方式提供,对输入的旅行需求给出相关的旅行计划和费用。由于各大旅行社开放的Web Service接口的不同,开发了不同的旅行定制Portlet,如对中国国旅的包装(PortletForGL)和对中国青年旅行社的包装(PortletForQL)。负责输入的Portlet与旅行定制Portlet基于事件进行协作。在多租户模式下,公司A可能会选择PortletForGL来做自己的旅行规划,而公司B则选择PortletForQL来做自己的旅行规划。于是形成了租户对Portlet协作的定制。
在以前的模型下由于无法进行租户间协作范围的隔离,在系统被并发访问时很可能造成租户之间的影响,只能采取为不同的租户部署不同的应用实例的方法来满足需求,如图9(a)所示。
扩展后的模型由于有配置文件和运行时的支持可以以单实例的方式来部署系统,如图9(b)所示。不仅大大减少了系统部署和维护的开销,而且也免去了多次为不同租户定制Portlet组件的开发负担。
扩展后的协作模型并不影响程序员对Portlet组件的开发,一方面减低了Portlet组件开发的难度;另一方面也使得扩展后的接口保持与原规范的兼容,使以前的组件不必重新编译(需要改写配置文件)就可移植到新的SaaS环境中来。
5 结 语
以SaaS的方式提供Portal服务,不仅可以减少运营商的成本,而且也大大降低了购买者的维护费用,使Portal产品更具有市场竞争力。但SaaS模式的多承租架构要求软件具有更好的可订制型,以满足不同租户的个性化需求。本文通过扩展Portlet规范,增加新的配置元素以及扩展相关接口方法,给出了单实例多承租体系下支持多租户可订制的Portlet协作模型,使Portlet组件可以更好地满足SaaS下多承租体系的需求。
参考文献
[1]http://zh.wikipedia.org/wiki/SaaS.
[2]孙泠.SaaS中国模式突围[N].软件世界,2007-12-20.
[3]European Commission Information Society and Media.The Future ofCloud Computing,opportunities for European cloud computing beyond2010[R].Rapporteur for this report:Lutz Schubert[USTUTT-HLRS].
[4]Thao K T,Lam N L.A Software as a Service with Multi-tenancy Supportfor an Electronic Contract Management Application[C]//SCC’08:2008 IEEE International Conference on Services Computing.
[5]EECS Department,U C Berkeley.Above the clouds:A Berkeley Viewof cloud computing[R].2009-2-28.
[6]JSR286:Portlet Specification2.0[S].Java Community Process,2008.
可定制门户网站开发研究 篇2
对于一个门户网站, 除了要定期更新其内容外, 还经常面临着增加栏目, 更新版面等问题, 而这些问题的解决往往需要专业的网站开发人员来完成。而对于一般的单位, 门户网站的管理人员都不是专业的技术人员, 当遇到这类的问题时, 只能求助于当初开发门户网站的公司, 重新提需求, 进行二次开发。这样, 一方面增加了成本, 另一方面也会因为开发周期等问题而影响门户网站的正常使用。针对以上问题, 结合我们学院可定制门户网站的开发, 尝试在不影响系统应用的前提下, 快速高效地定制门户网站。
2 门户网站分析
通过对互联网中一些门户网站的调查, 对于一般的门户网站, 大多的网站页面由以下几部分构成:顶端是Logo, Logo的下面一般都有一个菜单, 底部为版权、备案和联系方式等信息, 中间是网页内容的呈现部分。
中间部分是一个网页的核心部分, 一般由两部分或三部分组成。无论是两部分还是三部分, 最大的部分主要显示两类内容:一是分成几块, 按信息发布时间显示各类信息的列表;二是显示某个信息的详细内容。而相对较小的部分一般用来显示以下几类内容:一是整个网站的信息或某类信息按时间排序的列表;二是整个网站的信息或某类信息按点击排行的列表;三是一些图片或文字链接。如图1所示, 显示了一个普通的门户网站的结构。
3 可定制门户网站的数据库设计
根据对门户网站的分析, 总结其布局特点和网页呈现方式, 形成了可定制门户网站的数据库。数据库由页面总体框架表 (Page Frame) 、中间部分详细设计表 (Page Detail) 、页面附加信息表 (Page Additional) 、菜单表 (Page Menu) 和菜单详细信息表 (Page Menu Item) 五个表组成。
3.1 Page Frame表
Page Frame表记录了门户网站中所有页面的布局参数, 包括以下信息: (1) 每个网页的标题、宽度、背景、字体; (2) 顶端的Logo图片地址及其高度; (3) 底部信息的内容、前景色、背景色、高度、字体、行高; (4) 网页是否有菜单, 如果有, 使用菜单表中的哪一个菜单; (5) 中间部分由哪些部分构成等信息。
包括主页面在内, 门户网站中有几个页面, 就会在此表中出现几条记录。
3.2 Page Detail表
Page Detail表记录了组成每一个页面中间部分的详细设计信息, 是可定制门户网站布局的关键表, 可以根据门户网站的具体需求而设计, 可变参数越多, 网站显示形式越丰富, 但后台管理也就越复杂。我们在设计时将网页的中间部分, 按照其显示的内容和形式, 分成了若干模块, 每个功能模块形成一条记录。
每个记录的Position字段决定了该模块在网页中间部分的位置 (左、中、右) ;Model Type字段决定了该模块显示信息的类型 (信息列表、详细信息、文字链接或图片链接) ;Position Order字段决定了该模块在与自己在同一Position上时的排列顺序, 比如, 在中间页面的左侧存在两个模块, 一个是最新信息列表, 一个是按点击排行列表, 那么Position Order值的大小就决定了这两个模块哪一个排在上面, 哪一个排在下面;Order Kind字段是在Model Type为信息列表时, 决定是按时间顺序显示信息还是按点击次数排序;Info Kind ID字段决定了显示哪一类信息。
除了上述的关键字段外, 每个模块还都有布局参数, 包括前景色、背景色或图片、字体、边距信息、行高、显示行数等字段。
3.3 Page Additional表
Page Detail表无法完成所有中间部分的描述, 比如文字链接需要显示的文字、图片链接的图片地址以及点击它们后跳转放链接等信息, 因此增加了Page Addition表。
在表中, Title字段保存文字链接需要显示的文字;Img Url字段保存图片存储的地址;Tip Text字段保存鼠标停留在文字或图片上时的提示信息;Show Order字段保存显示的顺序;Is Blank字段决定是否在新窗口中显示打开的链接;Url字段保存了链接直接跳转的网址, 比如友情链接的跳转地址;Content字段保存了直接显示的内容;Link Page Frame ID字段保存了网站内部的跳转链接。Url、Content和Link Page Frame ID字段对于一条记录只能有一个字段有值。
3.4 Page Menu表和Page Menu Item表
对于一般的网站, 菜单的层级一般不会超过三级, Page Menu表记录了每级菜单的link、hover、active和visited的前景颜色和背景颜色, 以及菜单的字体、宽度和高度等信息。
Page Menu Item记录了各级菜单每个菜单项的详细信息。包括:标题、链接、菜单级别、父菜单ID和在同级菜单中的显示顺序等信息。链接的处理方式与Page Additional表中的处理方式相同, 只是少了Content字段。
4 系统实现
我们学院在进行可定制门户网站开发时, 采用了ASP.NET MVC架构。
ASP.NET MVC是微软官方提供的以MVC模式为基础的ASP.NET Web应用程序框架, 将一个Web应用分解为Model (模型) 、View (视图) 和Controller (控制器) , 同时提供了对HTML、CSS和Java Script的完全控制。
结合ASP.NET MVC的特点, 我们将页面布局的数据模型建立在Model中, 使用Controller中的不同Action, 通过数据模型实现对数据库的查询等操作, 在View中, 使用查询得到的数据模型中的数据和View引擎Razor, 实现对门户网站的布局。
对于整个系统的后台管理, 同样使用ASP.NET MVC架构, 同样使用Action, 通过数据模型, 实现对数据库的增、删、改和查询操作, 在View中, 使用j Query Easy UI, 结合HTML实现后台管理界面的开发。使用j Query Easy UI可以使整个页面布局如同应用程序, 操作方便, 美观大方。
5 结语
在对可定制门户网站架构的设计和开发中, 数据库的设计是很关键的, 而且数据库的设计也不是统一的, 要根据门户网站的整体风格来设计;在实现的技术上, 建议采用MVC架构, MVC架构可以试开发者在不依赖业务逻辑的情况下专注于视图设计, 非常适合网站页面的定制开发。
文章对可定制门户网站的开发提供了一个相对完整的解决方案, 整体设计相对简单, 不可能完全满足各类门户网站的开发需求, 在这里我们只是抛砖引玉, 给门户网站的开发者提供一个思路, 供大家参考。
参考文献
[1]韩蓄, 张景, 李军怀.基于角色的个性化门户网站设计与实现[J].计算机工程与应用, 2005 (4) .
财务管理系统用户可定制性技术 篇3
目前, 不管在行政事业单位, 还是在生产企业单位, 财务管理系统是一个较典型的应用系统。在软件工程界, 很多软件组织在现有的开发环境下使用了各种可能的方法与途径进行过此方面应用系统的设计与实现, 但是还存在一些共同的问题, 主要表现在: (1) 按通用系统来进行设计, 把业务的主要逻辑或计算公式存放在数据库中, 除系统表以外, 大部分表采用自定义方式, 保证所开发的财务管理系统能用于所有学校或行政企业单位。 (2) 从界面和业务分离到分布式多层体系结构, 包括界面和业务的逻辑分离、界面与业务的物理分离、界面和业务的空间分离。 (3) 系统与其他系统的数据导入与导出的设计。 (4) 各种自定义报表的设计。 (5) 在创建型模式、结构型模式以及行为型模式系列中选择合式的模式运用到本系统中。 (6) 功能对象、协调对象以及数据对象的如何设计, 才能使系统性能达到最佳。 (7) 系统的安全性考虑, 如基于角色的访问控制管理问题等。
为使得财务管理系统具有用户可定制性, 以软件复用技术为设计理念, 利用面向对象程序设计思想, 充分使用组件开发、模式设计的思想、分布式多层体系结构等现代软件工程主流技术来设计并实现财务管理系统。模式的观念与设计中如何解决问题密切相关, 不断重现的具体形式为重复出现的问题提供了可行的解决方案。模式除了包括问题、解决方案和场景之外, 还包括重复性、可传授性和名称。模式在应用软件开发中发挥主要作用[1,2,3], 为人们提供一套简洁通用的设计、管理、组织方面的词汇, 便于人们在软件开发中的交流与沟通, 有助于实现应用程序的功能, 有助于建立一个复杂的架构。每个模式提供组件、作用以及相互关系的预定义集。
系统采用演进软件开发过程模型, 使用面向对象软件开发方法, 贯彻设计模式思想, 采用分布式多层体系结构与DCOM/COM+组件等技术[4,5,6,7]来实现财务管理系统的业务逻辑, 主要有对工资类、津贴类、福利类、加班类、奖励类以及其他类各项收入进行日常管理 (包括日常数据修改、查询及报表打印) , 能够按指定要求将六类收入汇总统计, 方便对各项数据进行财务分析;根据人事信息资料, 对各类人员的信息增加、修改、查询;根据财务核算要求任意添加、修改各大类明细项目;以工资号为主键, 通过手工修改、成批修改、公式修改待等方式方便、灵活地修改人各收入类数据, 降低数据集操作的工作量, 提高工作效率;根据各项指定条件 (单个条件或组合条件) , 方便、快捷地筛选数据;自定义报表输出, 根据业务需要, 将系统中的查询数据、汇总信息及变动信息实时打印或转换成Excel表的形式输出;在校园网环境中, 允许多用户同时登录系统;界面人性化设计, 充分考虑财务核算人员的操作思路, 直观反映财务管理要求, 方便人机信息交换。
2 财务管理系统架构用户可定制性技术
财务管理系统架构用户可定制性体现在:真正的软件复用和高度的互操作性[8], 开发者可利用它组合成不同的应用系统;接口的可靠性, 组件接口是不变的, 接口是稳定的;可扩充服务, 每个组件是自主的, 有其独自的功能, 只能通过接口与外界通信;具有强有力的基础设施, 为了组件有机地组织在一起;具有构建和组合组件的工具, 可以方便地增加和替换应用中的组件, 充分发挥可复用的优势, 实现客户应用程序的组装和升级。在开发盐城师范学院财务管理系统时, 采用了COM/DCOM组件技术。通过该系统可以对学院的教职的收入的六大组成部分 (工资、福利、津贴、加班、奖励和其它) 的信息进行输入、导入、导出、查询、统计、修改、打印和生成银行报盘。
系统采用三层结构, 客户端表示层由FORM窗体组成, 可实现COM组件的调用, 业务逻辑和数据访问由一组用Delphi实现的COM组件构成。为了便于维护、升级和实现分布式应用, 在实现过程中, 又将业务逻辑层和数据访问层分离开, 客户端不直接调用数据访问层, 而是通过业务逻辑层来调用数据库, 如图1所示。
中间层组件对所用到的数据库中的表示进行了封装, 形成了组件。通过接口为表现层提供服务。建立Remote Data Module业务逻辑, 确定应用程序服务器的名称、实例属性以及服务器所使用的线程模型等信息。然后向空白窗体中加入非可视化的VCL组件。本系统中主要ADOConection, ADOCommand, ata SetProvider, ADOData Set等组件, 如图2所示。
表现层的主要组件包括登录组件, 数据查询组件, 数据修改组件, 个人信息项目管理组件, 基本表管理组件, 银行报盘组件, 公式设置组件, 信息初始化组件, 生成汇总数据组件和报表打印组件等。
3 财务管理系统模块用户可定制性技术
3.1 数据库模块用户可定制性技术
为使本系统具有通用性, 后台可使用不同的数据库, 如Access数据库、SQL数据库等。而应用程序中提供用户访问数据库的某一专用的数据集对象往往难以胜任这种多变的需求。由于数据库的连接和访问机制比较复杂。如果将数据库连接方式写死在程序中, 将不利于今后的维护和复用。如果客户端能够创建一个通用的数据集对象创建方法来创建数据集对象, 就可以解决这个问题。这样, 对象的创建方法要与要创建的对象就可以分离开来, 达到去耦的效果。
如图3所示, 是一个用于数据库访问的工厂方法设计模式图, 图中的TData Factory和TData Set分别是工厂方法模式中的工厂类和产品类。它们都是抽象类, 负责维护工厂和新产品之间的关系, TData Factroy负责创建TData Set对象。
显然, 系统事先无法知道会使用何种类型的数据库以及使用何种数据库连接机制。只知道何时有一个新的数据集对象要被创建, 但不知道所要创建的是哪一种数据集对象。这就是说系统将实际创建工作委派到TDFactory类的派生中了。而这个抽象类TDFactory提供创建数据集对象的抽象方法Create Data Set, 它相当于一个虚构造子, 而具体工厂类创建具体产品的过程是通过多态来实现的。
3.2 系统界面模块用户可定制性技术
不同用户对系统界面的要求不同, 有的用户喜欢使用传统的按钮界面, 有的用户喜欢使用菜单界面。盐城师范学院财务部门的操作人员就有这两种不同的需求。本系统通过使用抽象工厂模式实现两种操作界面, 即按钮界面和菜单界面。
如图4所示, 是一个抽象工厂的设计模式。在这个例子中, 包含了命令按钮和菜单两种风格的窗体, 即两个产品系列。这样便于改变产品族, 维护产品的一致性。为了维护产品的一致性, 定义了一个抽象类TForm Maker, TFor Maker类声明一个接口来建立各种组件的原型。同时又由这些组件的抽象类及具体类负责产生组件的实例。TForm Maker的接口提供统一的操作为所有组件产生新的对象实例。客户端调用这些接口的操作来得到一个组件实例, 但却和具体实现相隔离, 因为客户端没有必须了解所用到的那些产生实例的具体类。
这里TForm Maker有许多派生类分别创建需要的组件, 每一个派生类都是一个实例具体产品生产的具体工厂, 由它们来实现创建不同风格的组件的操作。如在TForm Maker的派生类中有一个Create Button, 客户只需与TForm Maker这个抽象的接口Create Button沟通而不必理会到底是由哪一个具体类创建了按钮。TForm Maker同时强调具体类之间的依赖性, 这就是说不同的TForm Maker所产生的实例实际上是不同具体工厂的不同实例。
3.3 数据显示模块用户可定制性技术
在本系统的开发中, 用到大量的数据感知组件, 通过这些组件来显示数据表中的记录。为了适应不同数据库的连接要求, 使增加新的数据库和数据库存取标准而无须修改客户端的数据显示程序。因此在本系统中作为建造者的新产品也就有TTable、TADOTable等多种形态。如果将创建数据集对象的方法从其表现中分离开来, 由可抽象为以下的算法步骤:创建数据库的连接, 创建数据集对象, 激活并返回数据集对象。
在系统开发的过程中, 由于要涉及到多个表, 而对各个表的操作界面是完全相同的。用建造者模式能够简化程序的编写, 使程序界面简洁。而且有利于系统的扩充。工资数据表和津贴数据表关系如图5所示。
3.4 文件转换模块用户可定制性技术
在系统开发过程中, 我们开发一个通用的组件, 用于实现将数据库中符合条件的表的内容转换成Excel文件或文本文件。这样设计的好处是既可以在自己的本系统中使用这一组件, 也可在其它系统中使用该组件。在实际开发中需要用到这种转换的场合很多。另外如果以后要转换成其它格式的文件, 只要在适配器类中进行修改就可以了, 客户端的程序完全不用修改。
但在使用这一模式时, 也容易犯这样的错误, 在设计Adapter时不愿牺牲Adaptee对象的多余功能, 转换了过多的Adaptee接口并使接口变得复杂。在实际应用中往往是功能单一且通用、对其它条件依赖性较少的少数接口。所以在设计Adapter模式时要考虑为Adaptee找到一个窄接口, 即可用于匹配的最小操作集。系统中用于转换成类图如图6所示。
3.5 数据的显示、查询和修改模块用户可定制性技术
在系统开发中, 有很多的地方用到数据的显示、查询和修改。用到了“显示数据”——“数据对象”——“后台数据”就对应了“表现层” (界面) ——“逻辑层” (业务) ——“持久层” (数据库或其它文件) 。这是程序员在编程应用程序时应该遵循的Class-Type体系结构。通过这种结构, 应用程序会因为减少了内部的耦合性而显著提高程序的健壮性。如果用户接口层要获得信息, 则必须与业务层的对象交互, 然后再通过业务层对象从持久层获得存储在持久层中的对象。这样就能禁止用户层对象直接访问持久层对象中的数据。也就是说你可以改变对象的存储方式, 而不需改变你的应用程序界面和报表, 如图7所示。
3.6 数据的显示、查询和修改模块用户可定制性技术
在系统开发的过程中, 要涉及对多个表的操作, 如对表进行初始化。尽管对不同的表进行操作, 但对表的操作方法是一样的。如果让用户直接对表进行操作, 则会对表产生很大的依赖性, 如何增加一个门面层, 则会减少这种依赖关系, 可以提供子系统的独立性和可移植性。系统中对多个表进行定义的简化图
4 结束语
本文对“组件化软件设计方法与设计模式等技术”进行了实践, , 从用户可定制的角度设计应用系统, 保证所设计系统具有良好的适应性、可维护性:反映教职工基本数据可以由系统管理员随意定义, 并方便管理员增加或删除;所有报表结构可以动态定义, 可以根据单位需求的变化进行变动;设计了结构良好的数据导入与导出功能, 方便应用系统间的数据交互;采用了基于角色的访问控制方式, 由系统管理员定义多级角色, 再根据用户业务需要, 为每个用户分配不同的角色。这样保证系统具有良好的可管理性与安全性。
参考文献
[1]Jeffrey K.H.Mak, Precise Modeling of Design Patterns in UML.Proseeding of the26th International Conference on Software Engineering (ICSE2004) :101-120.
[2]Neelam Soundarajan and Jason D.Hallstrom, Responsibilites and Rrewards:Specifying Design Patterns.Proseeding of the26th International Conference on Software Engineering (ICSE2004) .
[3]王俊峰, 戚晓滨.设计模式和UML.计算机应用研究, 1998 (5) :27-29.
[4]Carma McClure.软件复用标准指南.北京:电子工业出版社, 2004.
[5]於长华.基于三层C/S模型的大型关系数据库应用系统优化设计技术.计算机工程与应用, 1999 (11) :90-92.
[6]蒋建平, 梁新元, 舒红平.基于组件和中间件的装配式软件系统模型.计算机工程与应用, 2004 (34) :137.
[7]Pressman R S.Software Engineering:A Practitioner's Approach[M].5thed, McGraw-Hill Companies Inc, 2000.
基于可定制工作流的OA系统设计 篇4
20世纪80-90年代, 办公自动化系统开始在世界各国得到较快发展[1]。
它的出现实现了日常办公由传统的纸上办公到电子化的转变, 使企业内部人员能够方便快捷地共享信息, 高效地协同工作。随着科学技术的发展, 基于工作流的办公产品也开始出现。
西安市人才服务中心是负责全市人才交流和人事代理的专业服务机构, 近年来, 人才流量大, 日常办公业务的信息量也随之不断增加, 许多业务流程随之也变得更加复杂, 以往的部分业务靠纸张填写, 人工处理的方式越来越不方便, 不仅浪费人力、资源、时间, 也不利于查询统计, 而且人为失误多, 工作效率低下;部分已经实现计算机化的业务也因为流程的变化, 不能根据现有需求对系统进行灵活变通, 对企事业单位的正常运转造成了很大影响。为此, 开发一套面向中心内部工作人员, 不限办公时间和办公地点, 采用工作流技术, 通过网络发布消息、提交文档、审核文件, 有利于日常办公维护和适应复杂多变业务流程的办公自动化系统己刻不容缓, 系统中的各个审批等业务需要各个部门的不同角色通力合作, 通过定制不同的流程来完成[2]。
1 工作流相关概念
工作流是实现日常工作具体业务的步骤和规则, 它被当作是业务流程的一个同义词。工作流就是一类能够完全或者部分由计算机自动执行的业务过程, 在此过程中, 文档、信息或任务按照预定的规则传递, 企业人员、应用软件之间协调工作, 以实现企业业务流程所要达到的整体目标[3]。工作流注重的是完成一项活动的过程, 它需要依靠工作流管理系统来实现[4]。
工作流管理联盟 (WfMC, Workflow Management Coalition) 给出的关于工作流管理系统的定义是[6]:工作流管理系统是一个软件系统, 它完成工作流的定义和管理, 并按照在计算机中预先定义好的工作流逻辑推进工作流实例的执行。这个软件通过它们的信息流来支持业务流程。换句话说, 工作流管理系统能够确保正确的信息, 在合适的时间传递给合适的人, 或者是在适当的时候提交正确的计算机应用程序[5]。因此, 工作流管理系统不需要实际执行任何一个过程中的任务。它的优点是软件通用, 因此可以在许多情况下使用;它的弱点是通常实际应用软件也需要。工作流管理系统已成为实现BRP的理想工具。
工作流管理系统都由以下3个模块组成[6]: (1) 建立流程模块, 通过该模块用户可以根据自己的业务流程处理需求来定义一个工作流程; (2) 执行流程模块, 该模块也简称为工作流引擎模块, 它的主要功能是根据用户定义的流程和用户操作产生的数据环境来执行流程; (3) 用户和工作流系统的交互模块。
2 可定制工作流设计
系统中有很多子系统都需要有审批的流程, 在调研过程中发现这些流程情况复杂, 以请销假为例, 请销假管理主要功能是实现请假、销假的电子化管理, 按照中心实际实施的《请销假制度》设计实施。主要功能包括: (1) 请假申请 (个人填写请假申请表单、起止时间、请假事由等等, 提交申请) ; (2) 请假审批 (系统根据审批流程转有审批权限的审批人进行审批) ; (3) 跨级审批 (当某一审批人不在时, 高一级领导人可代替其审批) ; (4) 销假 (员工请假归来必须进行销假, 填写实际请假起始时间) ; (5) 请假撤销 (请假已经审批通过, 但因某种原因不请假了) ; (6) 请假信息统计分析 (部长可以看到本部门的请假情况, 分管主任可以看到所分管的部门请假情况, 主任和人事代理部门的人员可以看到整个人才中心的请假情况, 以便于月统计或年统计) 。
根据请假人身份 (岗位职务) 的不同、请假事由 (病假、婚假、产假等等) 的不同、请假时间长短的不同等都会进入到不同的审批流程, 如图1所示。
如果把审批流程在程序中固定下来, 设计开发过程虽然可以省一些事, 但是一旦实际审批流程发生了变化, 或者有了新的情况, 则会出现问题。因此, 为了更好地适应将来可能出现的需求变化, 专门设计了审批工作流子系统来解决这个问题。具体的审批流程由系统管理员根据《请销假制度》通过审批工作流子系统制定。
审批工作流子系统的主要任务就是对各种审批操作流程进行定制管理, 管理员可以灵活自由地定制各种审批流程及各个环节的审批人, 可以将权限分配给部门或科室, 也可以具体到某一个岗位和人。
当请求者需要创建新的过程实例或者需要修改当前已有的过程实例时, 系统首先会对请求者的身份进行验证, 如果系统对此人分配了审批工作流子系统的权限, 则该请求者具有创建审批流程的权限。在了解了具体的业务流程之后, 确定该过程实例的每一步审批流程, 从而确定过程定义表。根据过程定义表实例化每一步办理步骤, 并为每一步骤选择具有审批权限的部门、岗位或者人员, 并设置工作流的流转条件, 为下一步的流程走向限定条件, 从而创建一条记录, 并将该条记录存储到审批工作流表中, 这条记录将贯穿于整个业务流程的始终, 用以描述活动的运行情况[7]。
3 可定制工作流实现
本系统用到工作流的子系统包括:请假申请、出差申请、出外勤申请、加班申请、会议室申请、车辆申请。请假申请是使用最频繁的, 以下以请销假申请为例。
3.1 过程定义表示
工作流过程定义是将日常实际业务流程按照一定的模型标准进行形式化描述的过程, 是实际工作流程中过程逻辑的表达[8]。
根据本系统的业务需求, 可将员工按照申请时间长短分为两天以上请假、两天以内请假、五天以上需主任审批的请假。不同类型的请假, 审批流程也是不一样的, 了解了具体的业务流程, 我们可通过分支语句来解决业务流程的变化, 从而确定该过程实例的每一步审批流程。将员工请假流程整体抽象为一个“过程定义”[9], 如图2所示。
3.2 流程定制
根据以上过程定义, 就可创建审批流程。可以看出, 申请文件由员工起草, 由各级领导进行审批, 再由员工进行销假, 根据工作流的定义, 可以预先定义申请审批的过程, 这些过程是相互独立又相互联系的任务节点, 通过为各个结点分配不同的用户角色, 实现不同部门不同用户之间的分工与合作。
如图3, 首先可以选择要创建的工作流过程实例所属的工作流类型, 输入流程名称, 选择该流程名称的前一流程, 由此可确定流程的走向, 并选择审批意见为同意, 设置具有权限审批此条流程的参与者, 即对哪些单位、岗位、员工可用。点击保存按钮, 完成创建之后就可在此表单前一流程这一栏看到已经添加好的流程名称, 如图4。在审批工作流查询中还可以对已经添加好的审批流程进行删除或修改。
3.3 审批
审批流程设置分为传统和比例计算两种审批模式。传统模式就是某个审批流程被指定的审批人通过之后, 才可走向下一环节。比例计算模式就是某个流程可被多个审批人审批, 只有这个审批人数不小于预先设定好的比例, 才可通过。本系统主要采用传统模式。
一般都是由用户触发来决定流程。用户申请请假, 首先填好表单提交申请, 系统会根据申请的起始时间判断该申请将进入哪项工作流, 此时每一步的审批流程和下一步走向也已经知晓。根据过程定义, 如果有审批权限的参与者登录系统, 将会在待办事务列表看到需要处理的任务, 点击任务名称将进入申请详情界面, 点击否决, 则终止该流程;点击同意, 则流程将继续导入下一个任务节点, 一级一级地往上审批传递, 直到工作流中的所有审批流程被执行完成才结束该过程实例。在执行过程中, 系统会给用户自动返回每一步的审批详情, 让用户或者企业高层能够及时了解审批动态。如图5所示。
4 结语
本方案可自行定制工作流流程, 适应了复杂多变的业务流程, 特别是专门设计的跨级审批, 为申请人和审批人提供了更多方便, 使系统的设计更人性化, 提高了工作效率。可定制工作流也在很大程度上提高了系统的可维护性和扩展性, 避免了二次开发, 成为企业成本控制的重要途径之一, 具有很好的实际意义。
参考文献
[1]段欣, 董蕾.办公自动化应用教程[M].北京:电子工业出版社, 2008.
[2]窦战伟.基于WorkFlow与MVC的OA系统设计与实现[D]:兰州:兰州大学, 2009.
[3][荷]阿斯特.工作流管理:模型、方法和系统[M].王建民, 译.北京:清华大学出版社, 2004.
[4]柳纯录.系统集成项目管理工程师教程[M].北京:清华大学出版社, 2009.
[5]WIL VAN DER AALST, KEES MAX VAN HEE.Workflow management:models, methods, and systems[M].Mit Press, 2002.
[6]范玉顺.工作流管理技术基础[M].北京:清华大学出版社, 2001.
[7]杨镒.自定义工作流在办公自动化中的应用研究[J].华南理工大学学报, 2012, 8 (2) :135-137.
[8]D E MAHLING, N CRAVEN, W B CROFT.From offie eautomation to intelligent workflow systems[J].IntelligentSystems, 1995, 10 (3) :41-47.
可定制模式 篇5
在基于web的信息系统中, 表单的设计一般都是基于数据库表中某些定义好的字段设计的, 这样设计出的表单是固定的。如果需求变化, 不仅需要更改底层数据表, 而且需要对表单重新编码, 系统维护工作量大。
在教室预约系统开发中, 为了满足系统灵活扩充的要求, 实现了根据自定义字段动态扩展的表单。
2 可定制扩展表单的实现
可定制扩展的表单是这样一种表单, 根据业务需求系统中增加新的字段时, 表单中新增的控件是由数据库表中新增字段及其配置文件基础上自动生成的。可定制扩展表单的实现如图1所示。系统开发环境为PHP+MYSQL。
可定制扩展表单是基于数据驱动生成的, 它需要解决数据库表字段的扩展和对应控件的动态生成。
2.1 数据库表字段的扩展
信息系统的可扩展性需要数据库的可扩展性设计。数据库表的字段扩展, 常采用增加元字段表的设计方案。这种方案扩展性强, 适用于不断变化的系统, 但查询时需要数据表连接, 影响查询效率。教室预约系统采用了SQL数据定义语句修改数据库模式以达到增加表字段的目的, 满足了系统需要。
图中字段配置管理模块用来实现对定制字段的管理。mysql数据库系统中, 字段元数据可通过INFORMATION_SCHEMA数据库中的COLUMNS表得到, 教室预约系统中定义了sql_field_info () 函数用于获取数据库表中所有字段的name、type、length等元数据。
2.2 表单中控件的动态生成
html控件有诸多属性。能从数据库实体表和COLUMN元数据表确定控件的value、name、type等几个属性, 还有一些公共属性如disabled, 及部分控件特有属性如textarea控件的rows, cols属性, select控件的options属性, 从图中的配置文件获取。
控件的动态生成, 实际上就是按控件的html语法规则, 把html控件的属性和其值绑定起来生成对应的html标签字符串。生成的控件html代码包含于div容器中, 以便于html中定位。
2.3 表单的构造
教室预约系统中采用了单列式布局。配置文件中定义了standard_fields[]全局变量数组, 存储了需要在表单中嵌入的控件对应的字段名。它有两个作用:一是区分定制字段, 二是调整对应的控件在表单中的排列顺序。教室预约系统中摒弃各个表单差异后的一般构造流程如图2所示。
图中, 系统调用sql_fields_info () 函数取得数据表中所有字段元数据信息, 经图中所示流程后定制字段存放于数组custom_fields[]中, edit_field_order[]数组存储了整个表单中控件对应的字段名。对edit_field_order[]每一个元素分别调用控件生成函数即完成表单的构建。
构建过程中, 通过传递的数据表查询参数$id获取了表单底层数据表中各对应字段的值并定义和字段同名的全局变量缓存以便函数内引用。表单中生成的控件和数据表中各个字段通过name属性形成一一对应的关系, 因此当用POST方法提交表单时, 保证了表单数据的在数据库中的正确保存。
3 主要函数代码
系统中sql_field_info () 函数定义于数据层文件mysql.inc中, 控件动态生成函数定义在包含文件control_gen.inc中, 配置文件为congfig.php。
config.php中定义了$is_private_field[]、$is_mandatory_field[]、$maxlength[]等对字段部分的配置数组, 其使用方法参见函数代码。
3.1 sql_field_info () 函数
sql_field_info () 函数中调用“SHOW COLUMNS FROM$table”数据库操作指令获取了指定表的所有列的元数据信息。系统映射数据库字段类型为“integer”、“character”和“real”三种中间形式, 字段长度用length表示。
3.2 动态控件生成函数
动态控件生成函数包括create_custom () 、create_checkbox () 、create_textarea () 、create_input () 等。除了生成输入控件外, 还在前面添加对控件说明的label标签。create_custom () 函数代码如下:
4 结语
在教室预约系统中, 通过系统后台字段配置管理模块和配置文件对新增字段简单配置后, 不需要对系统代码做其它的修改就可以达到表单中定制字段的动态扩展, 较好地解决了系统应用中对业务字段扩展的需求, 增强了系统的适应能力。
摘要：为了实现根据业务需求在表单中增加自定义字段的目的, 采用了动态扩展数据库字段并利用元数据库表和配置文件中字段信息生成表单中控件的方案。给出了表单构造的一般流程图, 并分析了关键函数的实现代码。
关键词：可扩展性设计,元数据,定制表单,PHP开发
参考文献
[1]马淑红.数据库设计的可扩展性案例研究[J].科技信息, 2009 (25) 45-58.
[2]列旭松.PHP核心技术与最佳实践[M].北京:机械工业出版社, 2012.
可定制模式 篇6
大规模定制集成大批量生产和客户个性化定制的特点, 是制造业一种重要的生产模式, 其个性化需求实现是以产品族结构标准物料清单和选择项完成的[1]。物料清单 (Bill of Material, BOM) 是制造业各个职能功能联系的重要纽带, 贯穿从客户需求、市场、销售、设计、工艺、制造、计划、采购、、财务以及售后服务等整个过程, 而每个职能和阶段对BOM管理需求不同, 许多制造企业在BOM数据表达不一致导致大规模定制在客户需求、设计、制造、采购以及售后服务、维修等节点上出差错, 影响大规模定制企业的竞争力[2~4]。
为此学者在针对BOM的管理演变过程、方法和配置与视图进行了研究, 提出不同解决方案和方法, 主要集中在BOM的多视图、从EBOM转化MBOM等数据管理和维修BOM数据来源和管理进行分析研究[5,6], 但对大规模定制的BOM全程管理分析研究比较少, 为此本文分析了大规模定制可配置BOM演变过程模型, 并研究每个阶段BOM信息模型, 并开发了BOM全程管理模块。
1 大规模定制可配置BOM演进过程
大规模定制可配BOM是在GBOM (Generic BOM) 基础上实现产品的多样化和系列化, 根据产品生命周期主要分为以下几个阶段:客户需求BOM (Requirement BOM, RBOM) 、功能描述 (Function BOM, FBOM) 、工程 (Engineering BOM, EBOM) 、工艺BOM (Process planning BOM, PBOM) 、制造BOM (Manufacturing BOM, MBOM) 、销售BOM (Sale BOM, SBOM) 、成本BOM (Cost BOM, CBOM) 、质量BOM (Quality B O M, Q B O M) 、维修B O M (R e p a i r m e n t, BOM) 。每个阶段BOM在数据和信息表现形式存在继承性和差异性, 其发展过程如图1所示。
GBOM在产品族通用物料清单和选择树来实现产品族结构的可配置管理, 是大规模定制的基础;每个阶段BOM的衍生都是在质量功能配置 (QFD) 基础上进行的, 客户需求BOM依据产品的市场定位和顾客要求确定顾客对产品的需求结构。产品功能BOM描述产品功能要求的, 设计BOM是确定产品的组成结构。工艺BOM是依据工艺装备特点, 编制产品的装配件、零部件和最终产品制造的工艺规程, 确定了零部件的加工设备、工装夹具、刀具、辅具等工艺信息。制造BOM是制造阶段组织和管理在实际制造与生产管理过程中生产某种产品所需的零部件BOM。QBOM、CBOM和BBOM用来管理产品质量、成本和采购的相关信息, 为SBOM提供各自的信息, 而SBOM是大规模定制为客户实现多样性和个性化服务的选择基础;维修BOM根据SBOM提供部件或零件生成的实例BOM, 每个产品都有实例BOM, BOM物料多和结构负载, 每个物料都有相关信息如供应商、材料信息、安装和维修历史等信息, 存储量大查找困难, 因此维修BOM只对关重件管理。
2 可配置BOM全程管理分析
2.1 BOM信息分析
BOM在产品生命周期表现多样复杂, 但分析其在不同阶段的本质特征分为两个部分:BOM本体和从体, BOM本体包括零部件与它们的关系, 从体即本身结构相关联的属性。BOM在底层数据结构表现为2种形式:单层和多层。在数据库表中单层BOM相同的结构关系只记录一次, 单层BOM表特点:更改简单, 数据库冗余少, 缺点不能完整精确描述产品的组成关系。多层BOM完整地记录了BOM的结构信息, 如在同一产品下相同的结构也需要多次详尽地记录。多层BOM优点:能完整描述产品的结构关系吗, 产品类结构关系互不影响, 产品内部部件结构关系也互不影响。缺点:数据冗余大, BOM配置时产品结构变换的互动性差。
根据不同阶段BOM的需求和单层与多层BOM的优缺点, 采取不同的表现形式。FBOM、EBOM和PBOM需要体现产品的整体结构, 采用多层BOM, 而关于MBOM和由MBOM转化而成的多视图BOM采用单层BOM, 只体现父子关系和层次结构, 便于使用。SBOM是为了便于客户参与定制满足需求, 通常管理产品的次级结构和部件编号、名称和规格等, 但不需要更详细的信息。维修BOM只对关重件进行处理, 只需管理关重件的维修方法和供应商等信息。
2.2 可配置BOM生成流程
大规模定制的可配置BOM在市场调研和客户需求的基础上利用现有产品实例进行配置和多样化选择, 其具体流程如图2所示。主要步骤如下:
1) 依据市场定位和客户需求 (价格、样式、包装等) 形成的RBOM, 按照质量屋 (the House of Quality) 工具的要求分析与计算, 确定出FBOM和产品特征参数。
2) 按照F B O M和产品特征参数, 建立出GBOM。GBOM抽象成GBOM= (M, R) , M表示节点, 即物料项, M={具体实物、虚拟件、虚拟物料项}, R表示节点之间关系, R={物料之间的父子关系、可选关系、虚构物料项与其代表的一组物料项之间的多选一关系}。
3) 部件相似性分析:FBOM确定参数特性数据进行相似性分析, 对形成的GBOM (M, R) 的节点和该节点的特定参数计算其相互距离如公式 (1) , 距离较近则归为一类。按照深度偏离的方法对两类BOM的所有节点都要进行计算其距离, 进行相似性比较分析。
d (x, y) 表示两个BOM某节点的距离
每个节点有p个相互比较的特征数
Sk2为两类GBOM在同一个节点参数的标准差
4) 通过相似性分析形成的GBOM寻找是否有实例产品, 如有实例产品以该物料编号检出EBOM和其多视图, 否则按照 (5) 。
5) 可配置BOM按照相应的参数和功能配置产品节点和相互关系, 即实例化GBOM部件和零件转化成EBOM, EBOM按照管理功能需要转化为MBOM、PBOM、BBOM、CBOM和QBOM。
6) 定制SBOM:客户个性化需求和功能要求选择MBOM部件和工艺要求、特定供应商提供的物料与包装等形成客户独特的SBOM
7) 维修BOM:是在SBOM的基础上只保留产品关重件物料的在BOM的节点和子项关系。
2.3 大规模定制可配置BOM多视图的映射转化分析
大规模定制BOM映射转化过程中由RBOM转化为FBOM和EBOM转化成MBOM比较关键。
2.3.1 基于QFD的RBOM转化成FBOM分析
质量屋是一种确定顾客需求和相应产品或服务性能之间联系的图示方法, 从7个方面顾客需求 (customer requirements) 、产品特性 (product features) 、顾客需求的重要性 (importance of customer requirements) 、计划矩阵 (planning matrix) 、顾客需求与产品特性之间的关系、特性与特性之间的关系、目标值着手, 如图3所示, 在QFD分析过程中顾客需求的重要性、特性与特性之间的关系存在相互之间比较, 形成判断矩阵并按照方根与求和法计算得出相互关系的重要, 把客户的需求RBOM转化为FBOM和特征参数。
2.3.2 大规模定制EBOM转化成MBOM、SBOM和维修BOM
1) 建立MBOM的前提条件分析
必须先要对物料的分类, 如自制件、外购件、虚拟件、中间件和原材料等。产品设计开发过程中利用物料分类查询, 制定每种物料的首选或优选原则, 用最少规格制作出众多性能的系列产品, 在SBOM实现产品定制。确定每种物料编码必须统一且唯一。
2) EBOM转化成MBOM的流程分析
(1) 设计BOM (EBOM) 的形成:EBOM是指按FBOM的功能采用项目管理的方式自顶向下进行产品设计生成的BOM, 主要包括主要部件和组成相互关系。
(2) 建立工艺BOM (PBOM) :PBOM建立在EBOM基础上, 添加上零部件在产品装配与制造过程的加工顺序, 如主要是增加工位号、加工顺序号、工装夹具辅料、工时定额等工艺信息等。
(3) 建立制造BOM (MBOM) :MBOM是在PBOM基础上多个部门合作得到的, 需要根据企业加工能力和制造确定自制件、中间件、外购件、虚拟件和原材料等。虚拟件在设计BOM中有记录、但在实际生产制造中并不存储的部件。中间件指在设计BOM中不出现、但在实际生产制造中又要存储的部件, 在EBOM中, 中间件实际上是几个零部件构成的集合, 标志时先为这个集合新建件号然后逐一将集合中的元素与该件号进行关联;外协件指部件本身及部件的下属所有零部件都外协加工的部件。自制件指在EBOM和MBOM中的装配关系一致的部件。
采用深度遍历的对PBOM每个物料属性进行分析, 如是物料属性是装配件/自制件只修改该物料加工顺序、加工工位、工时定额等存放在制造物料表内;如是外购件删除该节点和节点的子树, 添加到采购物料内;如是虚拟件修改该节点的子树的数据值, 并将该节点的子节点移植该节点父节点下和删除该虚拟节点, 添加到虚拟物料表内。如是中间件为建立一个物料编号, 修改其数量1, 并把是中间件的物料复制到新的物料件下数量不变同时删除复制的件号节点和数量;对所有节点的物料遍历完成就实现EBOM转化MBOM, 整个过程都采用人机对话的方式进行修改完善, 各个部门根据需要完成相应BOM的转化, 如QBOM、CBOM和BBOM, 如图。
3) 构建SBOM:
按照客户需求可以选择需要的部件或零件而形成BOM, 构成SBOM的物料需要满足特定的条件, 成本为依据确定出SBOM中物料的订单分离点, 选择性的物料有限, SBOM= (B, O, R) 。其中B表示基本的物料项, 必须包含;O表示可以选择的物料项, 该类物料项的功能相同但可以有多中配置但必须选择其中一项, R表示基本项物料与选择项之间, 或选择项相互之间必须满足特定的规则, 如规格和功能或其他限制, 如选择项物料为A则必须选择某种选项物料B, R的规则必须是有限的。
4) 维修B O M:
采用多层B O M, 需为每个产品构建特定的维修BOM, 才能更好的为客户服务, 因此维修BOM管理数据量大。BOM主体信息为物料数据、产品配置信息和节点之间的关系等, BOM丛体信息为:关键部件的供应商、维修人力、维修组织、维修角色、维修知识、维修历史数据与维修当前数据等。但对大规模定制维修BOM只针对SBOM中关重件进行管理, SBOM基本物料项其维修方法和知识是共同的。
3 结束语
大规模定制环境下, 从顾客需求、市场定位、产品设计、生产制造和售后服务整个过程都需快速反馈, BOM是该类企业管理的基础。本文分析了大规模定制的可配置BOM在GBOM基础上通过QFD把客户需求形成EBOM、EBOM转化为其他BOM并分析其他BOM的表现形式与管理内容, 为企业实现客户定制个性需求提供了有效途径。
摘要：针对大规模定制产品具有可配置需求满足需求个性化, 分析了可配置BOM管理过程, 在质量功能配置的基础上给出可配置BOM演化过程和步骤, 并对可配置BOM的多视图的信息相互转化进行研究, 为实现产品的定制需求。
关键词：大规模定制,物料清单,质量功能配置
参考文献
[1]祁国宁, 顾新建, 谭建荣, 等.大批量定制技术及其应用[M].北京:机械工业出版社, 2003.
[2]齐维毅, 申海, 丁言镁, 吴丽娟, 张闻雷, 陈忠菊.一种面向产品族的XBOM建模方法[J].小型微型计算机系统, 2009, 11:2301-2304.
[3]薄洪光, 刘晓冰, 吕艳霞.钢铁企业xBOM过程集成研究[J].工业工程与管.2009, 14 (4) 76-81.
[4]任艮全, 张君, 张力, 王建民.面向信息资源管理的维修BOM结构设计与分析[J].计算机集成制造系统, 2010, 16 (7) :1545-1551.
[5]刘明周, 葛茂根, 刘正琼, 等.基于约束的可定制产品配置模型[J].计算机辅助设计与图形学学报, 2006, 18 (2) :225-230.
可定制模式 篇7
为了提高训练信息化水平,某类军事训练需要专门系统来采集有关装备的工作数据。由于具体训练中的数据内容要求因参训装备类型和训练目的的不同而变化,而且这种变化还是无法预知的,因此如果采用传统的开发方案,按照当前已知的内容要求静态建模各装备工作数据,并据此实现系统,则随着新的训练任务的执行而需要频繁地改动数据模型及程序实现,这样开发的系统的适应性较差,相应的维护成本也较高。
目前,类似的困扰也出现在企业内容管理等领域,它们通过在相关系统中使用动态机制成功地解决了问题[1,2,3]。为此,某项目采用相同的开发思想,基于内容可定制的开发方案设计实现了所需的数据采集系统。该系统支持按照专门设计的内容定制信息模型定制具体装备工作数据的内容,能够动态初始化采集界面和针对性地管理具体数据,可在有效提高采集效率的同时实现不同结构数据的统一采集、传输、存储和管理。
该采集系统基于.NET 3.5平台实现,本文将对其总体设计和关键技术实现进行探讨。
1 系统总体设计
1.1 总体架构设计
为了支持装备工作数据内容的定制采集,同时适应实时/事后、在线/离线等多种采集方式,该采集系统被设计成一组功能相互配合、结构相对独立的软件部件及类库,其架构如图1所示,它通过内容定制信息控制装备工作数据的采集,同时支持以内容无关的方式传输、存储所采集的装备工作数据。
• 数据内容定制部件 用于在具体训练实施前定制所要采集的装备工作数据内容。由其生成的定制信息可被导入到手工采集部件和数据管理部件,以便它们据此控制具体数据内容的采集。
• 数据发送代理 以类库形式实现,提供数据发送功能,封装数据采集软件与采集服务器的交互细节,支持以内容无关的方式发送数据。
• 数据接收代理 以类库形式实现,提供数据接收功能,封装数据应用软件与采集服务器的交互细节,支持以内容无关的方式接收数据。
• 手工采集部件 用于数据的实时手工采集,支持根据内容定制信息采集和管理装备工作数据。它通过数据发送代理同采集服务器交互,可将所采集的数据实时上报给采集服务器。
• 采集服务器部件 是实时在线采集方式下的中心部件,以Windows服务的形式在后台运行。它接收各类采集部件上报的采集工作数据,然后再将其转发给各类数据应用软件。它同时提供数据下载服务以及对自身的监控服务。
• 采集服务器监控部件 用于监控采集服务器部件,是启用AJAX技术[4]的ASP.NET程序,部署在采集服务器部件所在的服务器上,允许用户通过其以B/S模式远程监控采集服务器部件的活动。
• 数据下载部件 用于从采集服务器下载数据。利用它下载的数据可被输出到专门格式的XML文件,该文件随后可被导入到数据管理部件的数据库中。
• 数据管理部件 用于数据的事后采集,支持根据内容定制信息采集和管理装备工作数据,允许从其它部件导入数据。
1.2 数据模型设计
该系统主要采集装备工作数据,此外为了管理需要也记录采集活动信息,它们统称采集工作数据,其中装备工作数据的内容需要定制。为此,该系统开发中基于SQL Server 2005设计了如图2所示的系统数据模型,它由内容定制信息子模型和采集工作数据子模型组成,图1中各软件部件按照分工涉及其中一个或全部子模型,部分软件部件还提供对应的本地存储。
• 内容定制信息模型 类似于关系数据库中的数据字典模型,描述具体装备工作数据的内容定制信息,包括表DataType和表ItemType。其中,表DataType描述具体装备工作数据的总体内容定制信息,其中字段Category标识具体数据为工作记录或观测数据;表ItemType描述具体装备工作数据的细节内容组成数据项的定制信息,包括数值类型、编辑控件类型、取值范围、取值选项等。该子模型为系统中内容定制信息的定义、分发和使用提供了统一的标准。
• 采集工作数据模型 包括表Collection和表Data。其中,表Collection描述采集活动信息,表Data统一描述各类装备工作数据。特别指出,表Data通过其中字段EquipmentModel和DataTypeId引用对应的定制信息,除起止时间之外的细节内容以XML字符串形式打包保存在字段Detail(其类型为XML)中,这种设计支持装备工作数据的统一表示和存储。
2 关键技术实现
2.1 定制采集实现
该系统的定制采集主要体现在手工采集部件和数据管理部件中装备工作数据的采集上,其实现的关键在于如何初始化各采集界面中装备工作数据的细节内容的编辑界面,以及如何生成和解析各类装备工作数据的细节内容字符串。
(1) 装备工作数据细节内容编辑界面初始化
手工采集部件和数据管理部件为装备工作数据的采集提供了多种采集界面,尽管具体界面布局不尽相同,但是它们都根据内容定制信息动态初始化装备工作数据的细节内容的编辑界面,具体流程如图3(a)、图3(b)所示。
对于工作记录的细节内容编辑界面,首先检索出由指定DataType和ItemType集合组成的定制信息(此时DataType的Category字段标示数据为工作记录),然后根据ItemType集合中信息循环生成一组文本框控件或组合框控件(这取决于ItemType中ControlType字段的取值)。对于观测数据的细节内容编辑界面,同样首先检索出定制信息(此时DataType的Category字段标示数据为观测数据),接着创建用于显示观测记录的数据网格视图控件以及用于临时保存细节内容的非类型化数据集(即ADO.NET中的DataSet)实例,然后再根据ItemType集合中信息循环生成相应的显示列和数据列,并将所创建数据集中的唯一数据表绑定到所创建的数据网格视图控件,当增加或修改观测记录时再显示观测记录采集界面,并按类似于图3(a)的流程初始化观测记录编辑界面。
以手工采集部件中持续工作记录的实时采集界面为例,按照流程图3(a)动态初始化其中细节内容编辑界面后形成的完整采集界面如图4所示。
(2) 装备工作数据细节内容字符串生成与解析
如数据模型所述,装备工作数据的细节内容以XML字符串的形式保存在Data表的Detail字段,当新增和修改装备工作数据时,系统代码根据内容定制信息生成XML字符串。其中,工作记录的细节内容是一组工作参数,它的字符串生成主要利用System.Xml命名空间中实现W3C文档对象模型(DOM)的类XmlDocument,具体方法是:首先在该类的实例中添加ItemType集合所描述的对应数据项,然后调用该实例的InnerXml属性获取如下所示的XML字符串:
而观测数据的细节内容是一组观测记录,它的字符串生成直接利用非类型化数据集的本身功能,具体方法是:通过编辑界面将观测记录录入完毕后,调用所创建数据集实例的GetXml方法获取如下所示的XML字符串:
当编辑和查看装备工作数据时,系统代码根据内容定制信息解析所获得的XML字符串。其中,对于工作记录的细节内容,它的字符串解析主要利用System.Xml.XPath命名空间中使用 XPath 数据模型[5]处理 XML 数据的类XPathDocument,具体方法是:首先通过其构造函数将字符串载入该类的实例,然后根据ItemType集合中的信息逐项提取所描述的工作参数;而对于观测数据的细节内容,它的字符串解析直接利用非类型化数据集的本身功能,具体方法是:通过调用其ReadXml方法将字符串读入界面初始化时创建的数据集实例,由该实例根据自身模式自动完成字符串的解析[6]。
2.2 部件交互实现
如图1所示,具体采集过程中,需要分发内容定制信息和传输采集工作数据。为了支持这些采集活动,该系统内部以及与外部系统之间需要以在线或离线的方式进行交互,如何协调这些交互也是该系统开发中需要解决的关键难题。
(1) 部件在线交互
实时在线采集时,各采集部件所采集的数据需要通过网络以内容无关的方式实时发送给外部的数据应用软件。为此,该系统中设计了以采集服务器部件为中心的实时采集软件包。为了协调该软件包内的在线交互,该系统中设计了4种采集服务器交互接口:
• 数据上报接口 数据采集软件通过其将所采集的数据及时上报给采集服务器。
• 数据接收接口 数据应用软件通过其及时接收经由采集服务器转发的数据。
• 数据下载接口 数据下载软件通过其下载和管理采集服务器上所存储的数据。
• 服务器监控接口 采集服务器监控部件通过其对采集服务器的运行进行监控。
这4种接口均按照专门设计的协议进行交互。对于前3种接口,为了确保传输的可靠性,它们均通过TCP协议通信,并且为了支持长度不定的装备工作数据的传输而统一采用了长度可变的报文格式,即发送方在实际报文字节流前面附加长度信息,接收方根据长度信息读取和解析所收到的报文字节流;而对于第4种接口,考虑到采集服务器部件与其监控部件间的通信是可靠的,因而它的报文通信采用了更为简单的命名管道,所有报文均以字符串的形式直接发送,前面不再附加长度信息。
按照分层实现原则,该系统开发中对这4种接口进行了专门封装,对应地实现了4组Agent和Proxy,由它们处理报文发送与接收、报文序列化与反序列化等琐碎细节。其中,4组Agent用于采集服务器的客户端,分别提供数据发送、数据接收、数据下载、服务器监控等功能;4组Proxy用于采集服务器端,代理各自客户,处理与它们的交互。为了提高系统的健壮性,所有Agent和Proxy实现都采用了缓冲机制,支持报文的异步收发。特别地,为了方便外部集成,其中的数据发送Agent和数据接收Agent被封装为独立的.NET类库。
具体数据采集时,首先使用采集服务器监控部件并通过其监控Agent启动后台运行的采集服务器部件,采集服务器部件启动后自动创建监控Proxy来接收监控命令。在根据监控命令启动具体服务后,采集服务器部件允许数据采集部件、数据应用软件和数据下载部件通过各自Agent登录服务器,为它们创建对应的Proxy。在各客户软件登录后,采集系统的各部分将按照“客户→Agent→Proxy→服务器→Proxy→Agent→客户”的顺序协作完成各种数据采集和系统管理任务。
(2) 部件离线交互
如图1所示,除了直接的在线交互,部分软件部件间还存在通过数据文件进行的离线交互。其中,数据内容定制部件通过内容定制信息文件将内容定制信息分发到所有需要解析装备工作数据细节内容的软件部件;数据管理部件通过采集工作数据文件从手工采集部件、数据下载部件等收集它们保存或下载的采集工作数据。
为了支持这种离线交互,该系统开发中采用了以类型化数据集为基础的数据文件处理方案,具体方法是:基于图2中的表DataType和ItemType以及表Collection和Data生成两种专门的类型化数据集,并且规定系统中所有软件部件中的数据文件导入、导出功能的实现均通过这两类数据集的读、写方法来完成。由于所生成的类型化数据集可以根据本身模式自动完成数据文件内容的生成和解析,这确保了同类数据文件的格式一致性,进而保证了这种交互的顺畅性。
3 结 语
为了满足某类军事训练中特殊的数据采集需求,某项目中基于内容可定制的开发方案设计实现了一种专门的数据采集系统。该采集系统已在多次军事训练中得到应用,数据采集人员使用它们以实时和事后的方式准确有效地采集了具体训练评估所需的各类装备工作数据。由于它具有较好的适应性,允许最终用户针对具体要求自主定制所要采集的数据内容而不用对系统的实现进行任何改动,使得最终用户在具体环境中使用该系统采集不同数据时所需的维护成本降到最低,在有效提高采集效率的同时实现了不同结构装备工作数据的统一采集、传输、存储和管理。另外,由于它支持根据定制信息生成更简洁、更具针对性的采集界面,使得数据采集操作大为简化,错误采集的机率明显降低。
参考文献
[1]曾春,张来峰,杨川.企业内容管理技术与应用[M].北京:电子工业出版社,2009:84-97.
[2]吴贺,及俊川,李新.基于XML的动态表单快速生成技术[J].计算机系统应用,2010,19(9):60-63.
[3]张佳强,王士同.信息管理系统动态表单技术的研究与实现[J].计算机应用与软件,2010,27(8):29-32.
[4]Bill Evjen,等.ASP.NET3.5高级编程[M].5版.北京:清华大学出版社,2008:849-881.
[5]David Hunter,等.XML入门经典[M].4版.北京:清华大学出版社,2009:202-232.