CN116594707A - 一种基于依赖关系分析的城市服务组件组装系统 - Google Patents

Abstract

本发明涉及一种基于依赖关系分析的城市服务组件组装系统，包括组件开发模块，组件管理模块，组装方案生成模块，组装方案执行模块，传输与运行模块五个模块。本发明将各平台提供的多种多样的面向城市场景的生活服务规范化处理为城市服务组件，根据用户需求组装为一个完整的系统，通过网络传输到用户的客户机上，由客户运行并使用。本发明能够成功解决当前城市服务访问途径不明确、方案方式复杂、单项服务功能单一难以满足用户需求的问题，通过多项服务间的配合、联动，综合实现更复杂的功能，满足用户更高级的个性化需求。

Description

一种基于依赖关系分析的城市服务组件组装系统

技术领域

本发明涉及一种基于依赖关系分析的城市服务组件组装系统，属于信息技术领域。

背景技术

随着信息化、智能化在我国的深入进行和城市化水平的不断提高，越来越多面向普通市民的服务系统、服务平台相继在我国各大、中、小型城市出现并逐步得到了广泛的应用和推广。如今，城市居民可以通过网络享受许多与日常生活密切相关的、便捷的信息服务：访问本地地铁服务号，查询地铁运营时刻表；登陆小区服务平台，查看物业公告，缴纳水电费，与物业、其他业主沟通交流；在行车途中收听交通路况播报，避开拥堵路段，避免通勤中的堵车。这些现代化的城市服务，及时、准确地为用户提供日常生活必不可少的信息，带来了极大的便捷和更高的效率，但也存在功能不全面、不完善，接口更新换代过快且不能及时通知用户，或无法完全满足用户实际需求的情况。

在此背景下，将各平台提供的多种多样的面向城市场景的生活服务规范化处理为城市服务组件，根据用户需求组装为一个完整的系统，通过网络传输到用户的客户机上，由客户运行并使用，能够有效解决上述问题，更好地服务广大用户。这种方法能够成功解决当前城市服务访问途径不明确、方案方式复杂、单项服务功能单一难以满足用户需求的问题，通过多项服务间的配合、联动，综合实现更复杂的功能，满足用户更高级的个性化需求。

在组件组装方面，现有的组装方法一般分为如下步骤：获取用户功能需求；分析用户功能需求，提取目标功能及对应的组件领域；获取这些领域中所有组件的信息；根据目标功能，按需选择合适的组件，确定各个组件之间的接口连接方案；将组件连接方案解释为XML文件，根据此XML文件生成一定格式的组装运行脚本；从相应领域的组件库中提取组件，执行组装运行脚本，完成组件的组装；将组装出的系统发送给用户运行使用。这种方法主要存在两方面的不足：一方面，用户常常无法用准确、科学的语言描述自己需要的功能，描述中也可能存在错误，导致很难从用户描述中准确提取到可用的用户真实需求。这将进一步导致提取出误差较大的目标功能和对应的组件领域。另一方面，确定各个组件之间的接口连接方案，不仅需要对组件技术有所了解，还需要考虑到整体系统的接口匹配、执行逻辑、业务流程等问题。显然，这些要求不适用于非计算机领域从业者，限制了广大普通用户在没有协助的情况下实现组件组装，来获取满足自己功能需求的系统。

发明内容

因此，本发明硏究一种基于依赖关系分析的城市服务组件组装系统。本系统将各平台提供的多种多样的面向城市场景的生活服务规范化处理为城市服务组件，将各种组件实现的功能展现在用户面前，由用户自主选择；定义了组件自描述文件用以描述组件间的依赖关系，定义了功能-组件描述文件用以描述功能模块与组件之间的关系，定义了组装描述文件用以描述组件组装方式，在此基础上最终实现了根据组件间的依赖关系，自动将组件组装为完整系统。用户只需要将组装完成的系统部署运行,就能获取满足需求的组件系统。

在此基础上，本发明提供了一种基于依赖关系分析的城市服务组件组装系统，该系统分为五个模块：组件开发模块，组件管理模块，组装方案生成模块，组装方案执行模块，传输与运行模块。

另一方面，本发明的核心功能是基于依赖关系分析对城市服务组件进行组装，因此，还提出一种组装方法：第一步，需要将各项城市服务采用组件化的方式进行开发，规范化为城市服务组件；第二步，对城市服务组件进行管理，核心是对组件依赖关系进行定义和描述；第三步，提取用户需求，按照需求组装组件，获得组装方案；第四步，执行组装方案，将组件组装为一个完整的系统；第五步，将组装出的系统通过网络传输给用户。

进一步，组件开发模块，将各项城市服务采用组件化的方式进行开发，规范化为城市服务组件。在组件开发模块中，本发明借鉴软件系统开发领域的功能模块化、模块组件化设计思想，将组件分为程序组件、非程序组件两类。本发明定义了组件、组件匹配队列，并分类别详细定义了组件之间的依赖关系，并用组件自描述文件描述组件间的依赖关系。在组件依赖关系的基础上，本模块定义了组件依赖函数、组件依赖图、直接依赖与间接依赖、组件可用性、组件激活与冻结，并给出了组件依赖函数值计算算法。最后，本模块定义了功能-组件模型与子依赖关系。

本发明将组件定义为由组件自描述文件和组件主体的组成的结构，以文件夹的形式存储。组件自描述文件是描述组件主体属性及其依赖关系的文件。组件自描述文件中的元素需要与组件定义中的元素保持一致。组件自描述文件可以用XMLSchema描述。组件主体是本发明的组装对象，可以为任意文件格式，可调用其他组件主体或者被其他组件主体调用。

进一步，组件管理模块对城市服务组件进行管理，核心是对组件依赖关系进行定义和描述，和确定功能-组件间的对应关系。组件开发模块开发出的用于后续组装的组件，要实现某项具体的功能，有时会不可避免地依赖于其他组件所实现的功能，或着与其他模块行使功能涉及同一项数据。而当某组件由于文件损坏或结构不完整等原因导致不可用时，依赖于这个组件的其他组件是不可被选择、不可被组装的。显然，组件之间的依赖关系会对组件组装产生重要的影响。

本模块通过组件依赖关系算法实现通过运算求岀所有满足组件匹配函数的组件的列表，分为三个子算法。第一个子算法的功能是搜索给定组件的子依赖，并根据组件自身状态以及组件匹配函数是否被满足以判断组件的可用性，将满足组件匹配函数的可用子依赖构建为组件依赖树。组件依赖树由组件所有满足组件匹配函数的子依赖组成。第二个子算法对组件匹配函数进行运算。在搜索满足组件匹配函数的组件的算法构建组件依赖树后，依赖关系求解算法需要求解满足组件匹配函数的所有组件的列表，以便于软件组装。因此需要对组件依赖树进行遍历,求解组件依赖树中所有以来的节点,存入组件依赖列表中。第三个算法为组件依赖树遍历的算法。

进一步，组装方案生成模块基于组件依赖进行组件组装，通过解析功能-组件描述文件，获取所需功能对应的组件，进而生成组件组装方案。本发明用组装描述文件描述对应具体功能的组件系统的组装方法。

进一步，组装方案执行模块执行组装方案，将组件组装为一个完整的系统。本模块执行组件组装方案，解析组装描述文件，将组装描述文件中设定的文件或目录拷贝至程序包指定日录下，在此基础上生成系统，同时以包括表在内的多种形式保存组装出的系统。本模块执行程序主要类包括ModuleController、ModuleService、ModuleDao、Module以及Component。除此之外软件组装工具中的类还包括Xmlreader和Fileutils两个工具类。

进一步，传输与运行模块将组装出的系统通过网络传输给用户。本模块运用数据库技术、批处理技术、网络通信技术，将由组件组装而来的系统通过网络远程传输、安装到用户的客户机上，并通过运行驱动在客户机上运行。

由上可知，本发明提出了一种基于依赖关系分析的城市服务组件组装系统，将各平台提供的多种多样的面向城市场景的生活服务规范化处理为城市服务组件，根据用户需求组装为一个完整的系统，通过网络传输到用户的客户机上，由客户运行并使用。本发明能够成功解决当前城市服务访问途径不明确、方案方式复杂、单项服务功能单一难以满足用户需求的问题，通过多项服务间的配合、联动，综合实现更复杂的功能，满足用户更高级的个性化需求。另一方面，本发明基于已有城市服务组件，在将由不同主体提供的城市场景下的不同服务功能规范化为城市服务组件和实例化组件的基础上，进行组件组装并生成具备用户友好的可视化界面的完整的城市服务组装实例；该组装实例具备用户友好的可视化界面、符合常规人机交互逻辑的可操作控件，能够与不同城市服务平台进行良好的交互，工作流程流转灵活，能够满足用户整体需求；随后，将组装结果与组装实例、即满足用户总的需求、具备良好可视化界面的完整组装实例传输到用户的客户机上，在客户机上运行该组装实例并提供给用户操作和使用，从而解决用户难以根据需求寻找到对应城市服务的问题，和单个城市服务功能难以满足用户需求、多个城市服务功能难以彼此协调配合的问题。

附图说明

图1为本发明整体逻辑架构图；

图2为本发明中组件依赖关系算法子算法一流程图；

图3为本发明中组件依赖关系算法子算法二流程图；

图4为本发明中组件依赖关系算法子算法三流程图；

图5为本发明中组件组装方法流程图；

图6为本发明中组装方案执行流程图；

图7为本发明中运行驱动架构图。

具体实施方式

下文中，将参考附图详细描述本公开的示例性实施方式，以使本领域技术人员可容易地实现它们。此外，为了清楚起见，在附图中省略了与描述示例性实施方式无关的部分。

本发明实现的基于依赖关系分析的城市服务组件组装系统的逻辑架构如图1所示。该系统包括组件开发模块，组件管理模块，组装方案生成模块，组装方案执行模块，传输与运行模块五个模块。其中，组件开发模块和组件管理模块共同构成组件仓库，组装方案生成模块和组装方案执行模块共同构成组件组装工具。

组件仓库还包括Maven仓库和组件组装数据库。组件仓库用于存储用户可选的功能信息，功能对应的组件信息，以及物理形态的组件。具体的功能信息、功能对应的组件信息存储在组件组装数据库中，物理形态的组件，包括程序组件和非程序组件，存储在Maven仓库中。存储在Maven仓库中的组件，其组件自描述文件中的groupID、ID、version和packaging与在Maven基础上开发组件的POM文件中的groupID、ID、version和packaging一致，从而实现了组件仓库中Maven仓库和组件组装数据库之间的数据同步。这种同步是为了便于在组件存储至Maven仓库的同时将功能信息、功能对应的组件信息以及功能-组件之间的对应关系保存至组件组装数据库，在从Maven仓库中清除组件的同时将功能信息、功能对应的组件信息以及功能-组件之间的对应关系从组件组装数据库中清除。

下面结合附图对本发明各模块的具体实施方式作进一步说明：

(一)组件生成模块

本模块将各项城市服务采用组件化的方式进行开发，规范化为城市服务组件。本发明借鉴软件系统开发领域的功能模块化、模块组件化设计思想，将组件分为程序组件、非程序组件两类。

①程序组件是对属性、方法的简单封装，其中属性指对程序组件数据的简单访问，方法指程序组件可实现的功能。

②非程序组件是程序组件之外的其他系统组件，主要包括数据库脚本、用户手册、系统文档等。

本发明定义了组件、组件匹配队列、组件依赖关系，并用组件自描述文件描述组件间的依赖关系。

定义1组件：以多元组r＝(P,S,e,l)表示一个组件。

(1)P＝(groupID,ID,version,packaging,name,description)是组件属性的集合。组件属性是组件所有特点以及能力的抽象描述，是不同组件的本质区别。其中，groupID是组件所在组的编号，ID是组件的编号，version是组件的版本，packaging是组件的输出格式，name是组件的中文名，description是组件的详细描述，包括实现功能等。组件属性中的groupID、ID、version、packaging共同决定了组件的唯一性。

(2)S是组件匹配队列，定义详见定义2。

(3)e是组件自身的有效或无效状态，用布尔值1和0表示。其中，1代表组件为可使用的有效组件，0代表组件为不可使用的无效组件。

(4)l是组件依赖函数，定义详见定义3。

定义2组件匹配队列：对于组件r，用三元组s＝(f,r')表示一个能与它匹配的组件，用S＝{s₁,s₂,…,s_i,…}表示能与组件r匹配的组件的集合，即组件r的组件匹配队列。

(1)f是组件匹配函数，描述组件r对所需组件的匹配条件。

(2)r'是满足组件匹配函数f的、可以跟r绑定的组件。

(3)组件可能通过组件槽绑定多个组件，也可能不绑定组件。

本模块对组件之间的依赖关系进行定义，并将组件间的依赖关系运用到组件的开发和组装过程中。组件之间的依赖关系，按程度由高到低可以分为以下三种情况：

①组件之间存在行为耦合。这种组件实现自有功能，依赖于其他组件实现的功能。例如，实现访问数据库功能的Mybatis相关组件依赖于MYSQL相关组件，实现单点登录功能的CAS相关组件依赖于Shiro相关组件。

②组件之间不存在行为耦合，但存在数据耦合。这种组件能够独立实现自有功能，但其功能涉及的数据与其他组件相同。例如，组件A调用MYSQL相关组件对MYSQL数据库中的数据进行更新，组件B调用MYSQL相关组件对MYSQL数据库中的数据进行新增或删除。组件A、组件B的功能不需要对方的支持，但处理相同的数据，即不存在行为耦合，但存在数据耦合。

③组件之间不存在行为耦合，也不存在数据耦合。在这种情况下，虽然组成软件系统不同功能模块的组件之间不存在依赖关系，但实现某项具体功能的组件之间存在有依赖关系。

定义3组件依赖函数：组件依赖函数l是定义在组件r的组件匹配队列S＝{s₁，s₂，…，s_i，…}上的布尔表达式，描述了匹配组件之间的逻辑关系。

(1)组件匹配关系存在且匹配组件可用时，则s_i＝1，否则s_i＝0。

(2)当即该组件的组建匹配队列为空时，组件依赖函数l的布尔值为1。

(3)组件依赖函数可以根据实际情况灵活构造。例如，组件r₁依赖于组件r₂、r₃、r₄，分别构成s₁₂＝(f₁₂，r₂)、s₁₃＝(f₁₃，r₃)、s₁₄＝(f₁₄，r₄)。如果r₂、r₃、r₄必须同时处于有效状态，则l＝s₁₂·s₁₃·s₁₄。如果r₂、r₃中其一有效且r₄有效即可，则l＝(s₁₂+s₁₃)·s₁₄。

定义4组件依赖关系：对于两个组件r_i和r_j，将组件r_i绑定到组件r_j的组件槽s上，则r_i和r_j之间的依赖关系为r_i依赖于r_j，记为r_i→r_j。组件依赖关系具有传递性，如果组件r_i，r_j，r_k间存在r_i→r_j，r_j→r_k的依赖关系，则一定还存在r_i→r_k的依赖关系。

定义5组件依赖图：组件依赖图是根据组件间依赖关系而形成的有向超图，记为RDH＝<R，C>。其中，R＝{r₁，r₂，…，r_i，…}是超图中的节点，代表组件，C＝{c₁，c₂，…，c_j，…}是超图中的边，代表组件间的依赖关系。

定义6直接依赖与间接依赖：在组件关系模型中，组件r_i→r_j。在组件依赖图中，如果没有其他组件节点存在于r_i和r_j之间，则组件r_i直接依赖于组件r_j；如果有其他组件节点存在于r_i和r_j之间，则组件r_i间接依赖于组件r_j。

定义7组件可用性：对于组件r＝(P，S，e，l)，其组件可用性是组件自身的有效状态值与组件依赖函数值间的布尔积运算，表示为A(r)＝e·l。当A(r)＝1时，组件可用；当A(r)＝0时，组件不可用。

定义8组件激活与冻结：对于组件r＝(P，S，e，l)，激活是将组件从自身无效状态e＝0变为自身有效状态e＝1。冻结是将组件从自身有效状态e＝1变为自身无效状态e＝0。

在定义组件可用性的基础上，本发明提出了组件依赖函数值计算算法，用于确定某组件是否可用，其步骤如下所示。

步骤1：初始化空资源集合L，将组件r加入集合L中；

步骤2：循环进行步骤3-5，直到L为空：

步骤3：弹出L队首的组件r_i；

步骤4：如果组件r_i的组件匹配队列为空，则设置组件r_i的状态项status＝true，并将所有依赖于组件r_i的组件加入到L中；

步骤5：如果组件r_i的组件匹配队列不为空，那么，对于组件r_i的组件匹配队列S＝{s₁，s₂，…，s_i，…}，如果存在一个组件匹配s_j＝(f，r_j)，组件r_j是激活的，且资源依赖函数中对应t_j＝true，则设置组件r_i的状态项status＝true，否则，设置组件r_i的状态项status＝false。

定义9功能-组件模型：用Model＝(name，description，R)描述功能于组件间的对应关系，其中，name是功能的名称，description是对功能的描述，R＝(r₁，r₂，…，r_i，…)是能满足此功能的组件的集合。

定义10子依赖关系：对于组件r＝(P，S，e，l)，如果存在组件集合R＝(r₁，r₂，…，r_i，…)，集合R中的任意一个组件r_i∈R，都有r→r_i，那么，定义组件r与组件集合R之间的树形依赖关系为组件r的子依赖。

本发明将组件定义为由组件自描述文件和组件主体的组成的结构，以文件夹的形式存储。

组件自描述文件是描述组件主体属性及其依赖关系的文件。组件自描述文件中的元素需要与组件定义中的元素保持一致。组件自描述文件可以用XML Schema描述，具体内容包含componentDescriptor、groupID、ID、version、packaging、name、description、stats、dependencyFunction、slots等元素。其中，componentDescriptor是根元素，groupID是组件所在组的编号，ID是组件的ID，version是组件的版本，packaging是组件的输出格式，name是组件的名称，description是对组件的描述，status是组件的状态，dependencyFunction是组件的资源依赖函数，slots是组件依赖队列。这些元素的simpleType描述方式一致，例如，groupID的simpleType限定groupID字符串的最小长度为1，最大长度为100。

组件主体是本发明的组装对象，可以为任意文件格式，可调用其他组件主体或者被其他组件主体调用。无论是程序组件还是非程序组件，组件主体均包括通用属性信息和专有属性信息。其中通用属性信息包括：组件名称、组件提供者、主要功能、更新日期与版本、当前状态、组件结构、组件属性、管理要求、管理表、类名、命名空间、界面分组、入口参数、DLL文件、代码文件等等。相关的表均包括为：组件基础表、组件控件表、组件SQL表。其中，组件基础表存储组件的核心属性，组件生成时自动获得一个唯一的组件编号；组件控件表存储组件控件信息，组件SQL表存储相关的表结构数据。

(二)组件管理模块

组件管理模块的核心是确定组件间的依赖关系，和功能-组件间的对应关系。在软件工程领域，组件依赖指两个对象模型元素之间的语义连接关系，如果被依赖的模型元素发生变化，一定会对另一个模型元素产生影响。组件开发模块开发出的用于后续组装的组件，要实现某项具体的功能，有时会不可避免地依赖于其他组件所实现的功能，或着与其他模块行使功能涉及同一项数据。而当某组件由于文件损坏或结构不完整等原因导致不可用时，依赖于这个组件的其他组件是不可被选择、不可被组装的。显然，组件之间的依赖关系会对组件组装产生重要的影响。

本模块通过组件依赖关系算法实现通过运算求岀所有满足组件匹配函数的组件的列表，分为三个子算法。

第一个子算法的功能是搜索给定组件的子依赖，并根据组件自身状态以及组件匹配函数是否被满足以判断组件的可用性，将满足组件匹配函数的可用子依赖构建为组件依赖树。组件依赖树由组件所有满足组件匹配函数的子依赖组成，具体步骤如下，图2为对应的算法流程图。

步骤1：判断组件自身状态是否有效。若无效，则组件不可用；若有效，则执行步骤2。

步骤2：判断组件是否依赖其他组件。如果否，则组件可用，执行步骤5；若是，则执行步骤3。

步骤3：检查组件依赖函数中各组件的可用性，并对组件依赖函数进行运算。

步骤4：判断依赖函数的运算结果。如果结果为假，则当前组件不可用，否则当前组件可用，执行步骤5。

步骤5：将组件加入组件依赖树。

第二个子算法对组件匹配函数进行运算，具体步骤如下，图3为对应的算法流程图。

步骤1：将组件匹配函数转为后缀表达式，将后缀表达式元素存入运算元素，后缀表达式的运算符存入运算符栈；

步骤2，判断运算元素栈的元素数量是否大于1。如果否，则直接返回运算元素栈的唯一元素的可用性，反之进入步骤3；

步骤3：运算元素栈弹出栈顶的两个元素，元素A和元素B；

步骤4：判断元素A和元素B的可用性；

步骤5：运算符栈弹出运算符a；

步骤6：以元素A和元素B的可用性作为运算的前项和后项进行运算符a所表示的运算，产生元素C；

步骤7：将元素C压入运算元素栈，执行第二步。

在搜索满足组件匹配函数的组件的算法构建组件依赖树后，依赖关系求解算法需要求解满足组件匹配函数的所有组件的列表，以便于软件组装。因此需要对组件依赖树进行遍历,求解组件依赖树中所有以来的节点,存入组件依赖列表中。

第三个算法组件依赖树遍历的算法如图4所示，具体步骤如下。

步骤1：创建组件遍历栈。组件遍历栈是存放还未被遍历的组件的一种栈，初始条件下为空；

步骤2：将组件压入组件遍历栈；

步骤3：判断组件遍历栈是否为空，若为空，则组件遍历完毕，返回组件依赖列表，反之，继续执行步骤4；

步骤4：从组件遍历栈中弹出一种组件，组件A；

步骤5：组件A加入组件搜索列表；

步骤6：根据组件依赖树上是否存在子节点，如果否，则当前组件为组件依赖树上的叶子节点，执行步骤3，反之，则将组件的所有子节点压入组件遍历栈。

功能-组件描述文件可以用XMLSchema描述。功能-组件描述文件中的元素包括moduleDescriptor、name、description、components等元素。其中，moduleDescriptor是根元素，name是功能模块的名称，description是对功能模块的描述，components是组成功能模块的组件集合。这些元素的simpleType描述方式一致，例如name的simpleType限定name字符串的最小长度为1，最大长度为50。

(三)组装方案生成模块

本模块基于组件依赖进行组件组装，通过解析功能-组件描述文件，获取所需功能对应的组件，进而生成组件组装方案。本模块进行组件组装方面此过程具体流程如图5所示。

步骤1：将组件组装数据库中存储的功能信息以列表的形式展现给用户，供用户选择；

步骤2：用户以选择功能关键词的方式进行功能需求描述；

步骤3：分析用户总的功能需求，确定功能点；

步骤4，解析功能-组件描述文件，从中获取功能对应组件的列表；

步骤5，从功能对应组件的列表中依次取出组件；

步骤6，判断取出的组件是否可用。如果组件可用，执行步骤7，否则执行步骤10；

步骤7，将取出的组件加入组成功能的组件列表中；

步骤8，判断功能对应的组件的列表是否取完。如果已取完，执行步骤9，否则执行步骤5；

步骤9，组装成功，输岀满足功能的组件的列表，流程结束；

步骤10，组装失败，流程结朿。

本发明用组装描述文件描述对应具体功能的组件系统的组装方法。组装描述文件可以用XML Schema描述，包含有assemblyDescriptor、format、fileSets、files等元素。其中，assemblyDescriptor是根元素，format是系统格式，fileSets是系统中所包含的文件组，files是系统包含的文件。以上元素的simpleType描述方式一致，例如，以format的simpleType限定系统格式字符串的最小长度为1，最大长度为50。

(四)组装方案执行模块

本模块负责执行组件组装方案，解析组装描述文件，将组装描述文件中设定的文件或目录拷贝至程序包指定日录下，在此基础上生成系统，同时以包括表在内的多种形式保存组装出的系统。本模块执行程序主要类图如图6所示，主要类包括ModuleController、ModuleService、ModuleDao、Module以及Component。除此之外软件组装工具中的类还包括Xmlreader和Fileutils两个工具类。

(五)传输与运行模块

传输与运行模块运用数据库技术、批处理技术、网络通信技术，将由组件组装而来的系统通过网络远程传输、安装到用户的客户机上，并通过运行驱动在客户机上运行。传输与运行模块的具体工作步骤如下：

步骤1：获取用户编号USER_ID和组装流程编号FLOW_ID；

步骤2：根据用户编号USER_ID和组装流程编号FLOW_ID，确定远程生成机服务器组件组装结果与组装实例所在目录，包括可视化组件组装表(VIS_ASSE)、工作流组件组装表(WORK_ASSE)、组装说明文档(DOCU_ASSE)等；

步骤3：运用脚本代码从生成机服务器目录下载组装出的系统到客户机；

步骤4：从生成机服务器目录特定目录下载运行驱动到客户机；

步骤5：运行运行驱动，使用组装出的系统。

如图7所示的运行驱动是本发明实现的用于在远端客户机运行组装出的系统的功能程序，具有综合考虑用户需求、软硬件环境、业务逻辑、数据处理要求、友好界面等因素设计的多层次体系结构。其中，系统层基于客户机环境(一般为Windows操作系统)，为该驱动的正常运行提供底层环境支持，并基于TCP/IP通信协议实现与远端生成机服务器的远距离可靠信息传递；数据层是系统层和业务层的沟通媒介，通过数据库实现数据的存储、处理、缓存等操作和系统层、业务层之间的数据传递；业务层是该驱动体系结构的核心，负责完成在远端客户机上运行组装出的城市服务组装实例的核心功能；应用层面向用户，通过构建用户友好的可视化界面，为用户清晰地展示所实现的城市服务组装实例的全貌和使用方式，帮助用户使用该组装实例；前端UI层负责在应用层提供的可视化界面的基础上与用户进行交互。

以上所述，仅为本发明部分具体实施方式，但本发明的保护范围并不局限于此。本发明的范围由所附权利要求限定。不脱离本发明的精神和原理而做出的各种等同替换和修改，均应涵盖在本发明的范围之内。

Claims (7)

1.一种基于依赖关系分析的城市服务组件组装系统，其特征在于，包括五个模块：组件开发模块，组件管理模块，组装方案生成模块，组装方案执行模块，传输与运行模块；所述组装系统将各平台提供的面向城市场景的生活服务规范化处理为城市服务组件，根据用户需求组装为一个完整的系统，通过网络传输到用户的客户机上，由客户运行并使用；所述组件开发模块将各项城市服务采用组件化的方式进行开发，规范化为城市服务组件，所述组件管理模块对城市服务组件进行管理，核心是对组件依赖关系进行定义和描述，和确定功能-组件间的对应关系，所述组装方案生成模块基于组件依赖关系进行组件组装，通过解析功能-组件描述文件，获取所需功能对应的组件，进而生成组件组装方案，所述组装方案执行模块执行组装方案，将组件组装为一个完整的系统，所述传输与运行模块将组装出的系统通过网络传输给用户。

2.根据权利要求1所述的一种基于依赖关系分析的城市服务组件组装系统，其特征在于，所述组件开发模块具有如下特征：

在组件开发模块中，将组件分为程序组件、非程序组件两类，该组装系统定义了组件、组件匹配队列，并分类别定义了组件之间的依赖关系，并用组件自描述文件描述组件间的依赖关系，在组件依赖关系的基础上，所述组件开发模块定义了组件依赖函数、组件依赖图、直接依赖与间接依赖、组件可用性、组件激活与冻结，并给出了组件依赖函数值计算算法，最后，所述组件开发模块定义了功能-组件模型与子依赖关系；

组件定义为由组件自描述文件和组件主体组成，以文件夹的形式存储，组件自描述文件是描述组件主体属性及其依赖关系的文件，组件自描述文件中的元素需要与组件定义中的元素保持一致，组件自描述文件用XMLSchema描述，组件主体是组装对象，为任意文件格式，能够调用其他组件主体或者被其他组件主体调用。

3.根据权利要求1所述的一种基于依赖关系分析的城市服务组件组装系统，其特征在于，所述组件管理模块具有如下特征：

所述组件管理模块通过组件依赖关系算法实现，通过运算求岀所有满足组件匹配函数的组件的列表，所述依赖关系算法分为三个子算法，第一个子算法的功能是搜索给定组件的子依赖，并根据组件自身状态以及组件匹配函数是否被满足以判断组件的可用性，将满足组件匹配函数的可用子依赖构建为组件依赖树，组件依赖树由组件所有满足组件匹配函数的子依赖组成，第二个子算法对组件匹配函数进行运算，在搜索满足组件匹配函数的组件的算法构建组件依赖树后，依赖关系求解算法需要求解满足组件匹配函数的所有组件的列表，以便于软件组装，因此需要对组件依赖树进行遍历,求解组件依赖树中所有以来的节点,存入组件依赖列表中，第三个算法为组件依赖树遍历的算法。

4.根据权利要求1所述的一种基于依赖关系分析的城市服务组件组装系统，其特征在于，所述组装方案生成模块具有如下特征：

所述组装系统用组装描述文件描述对应具体功能的组件系统的组装方法。

5.根据权利要求1所述的一种基于依赖关系分析的城市服务组件组装系统，其特征在于，所述组装方案执行模块具有如下特征：

所述组装方案执行模块执行组件组装方案，解析组装描述文件，将组装描述文件中设定的文件或目录拷贝至程序包指定日录下，在此基础上生成系统，同时以包括表在内的多种形式保存组装出的系统，所述组装方案执行模块的执行程序主要类包括ModuleController、ModuleService、ModuleDao、Module以及Component，除此之外软件组装工具中的类还包括Xmlreader和Fileutils两个工具类。

6.根据权利要求1所述的一种基于依赖关系分析的城市服务组件组装系统，其特征在于，所述传输与运行模块具有如下特征：

所述传输与运行模块运用数据库技术、批处理技术、网络通信技术，将由组件组装而来的系统通过网络远程传输、安装到用户的客户机上，并通过运行驱动在客户机上运行。

7.一种根据权利要求1-6任一项所述的基于依赖关系分析的城市服务组件组装系统的组装方法，其特征在于，第一步，需要将各项城市服务采用组件化的方式进行开发，规范化为城市服务组件；第二步，对城市服务组件进行管理，核心是对组件依赖关系进行定义和描述；第三步，提取用户需求，按照需求组装组件，获得组装方案；第四步，执行组装方案，将组件组装为一个完整的系统；第五步，将组装出的系统通过网络传输给用户。