一种积木式软件系统架构的开发方法、存储介质及设备

技术领域

本申请涉及地图定位技术领域，具体涉及一种积木式软件系统架构的开发方法、存储介质及设备。

背景技术

通常我们将软件工程分为上游设计和下游开发，最终目的当然是要完成实现交付。软件系统架构是指软件的结构，架构的定义可以概况为：为了达到某个目标，将产品分解为一系列组件、模块和交互。

如图1所示，在整个软件生命周期中，系统架构覆盖了部分需求分析和概要设计的内容，它是完成上游设计，进入下游工程的关键衔接，是将用户需求进行抽象再在系统中具象的过程，从而帮助我们进入编码实现的阶段。系统架构设计就是将需求抽象再具象，从而进入实现层面的过程。

在软件系统的开发过程中，大量的中小企业都采用传统的烟囱式开发模式，从上游设计到下游开发，通常只考虑单一业务场景的需求开发。对于业务场景较单一的企业来说，这种开发模式在一定程度上是有优势的。但对于业务场景较多、复杂的情况下，软件管理混乱、难以灵活调用、运维成本高昂等问题。

因此，如何在现有的软件系统架构的基础上进行改进，以提高软件的复用率，实现实现可复用、可配置、易调用、快速迭代的软件开发逻辑，是亟需解决的技术问题。

发明内容

本申请的目的在于解决现有技术中，针对业务场景复杂的软件系统开发，软件管理混乱、难以灵活调用、运维成本高昂等问题，为此，本申请提供一种积木式软件系统架构的开发方法、存储介质及设备。

为解决上述技术问题，本发明提供一种积木式软件系统架构的开发方法，开发方法用于实现软件系统的灵活调用，开发方法的步骤包括：

基于业务场景定义业务模块和组件，其中，业务模块包括多个组件；

对组件进行开发后形成组件包，并将组件包上传至组件库中；

创建应用，从组件库中引用组件包，使用积木式拼装技术拼装组件包；

构建平台，确定构成平台的应用；

部署平台，将平台引用的组件包部署到服务器上，完成软件系统架构的开发。

在其他实施例中，基于业务场景定义业务模块和组件的步骤包括：

基于业务场景完成需求分析，以形成产品方案；

基于产品方案定义业务模块和组件。

在其他实施例中，定义业务模块和组件的步骤包括：

定义多个不同的业务模块，每个业务模块包括一后端服务组件和一前端页面组件；

其中，前端页面组件包括网页页面组件和APP页面组件。

在其他实施例中，对组件进行开发后形成组件包的步骤包括：

对后端服务组件进行开发，形成后端组件包；

对网页页面组件进行开发，形成网页组件包；

对APP页面组件进行开发，形成APP组件包；

将后端组件包、网页组件包和网页组件包上传至组件库中进行统一管理。

在其他实施例中，使用积木式拼装技术拼装组件包的步骤包括：

使用积木式拼装技术，将引用的组件包进行拼装，得到软件安装包。

在其他实施例中，确定构成平台的应用的步骤包括：

定义平台的框架；

在框架中选择需要的应用。

在其他实施例中，部署平台还包括：

部署多个平台，引用相同或者不同的组件包，部署到服务器上。

本发明还提供一种存储介质，存储前述的积木式软件系统架构的开发方法。

本发明还提供一种计算机设备，包括存储介质和处理器；

所述存储介质，存储有计算机指令；

处理器，配置为执行计算机指令以使计算机设备实现前述的积木式软件系统架构的开发方法。

有益效果：本发明公开了一种积木式软件系统架构的开发方法、存储介质及设备，该开发方法采用积木式的系统架构方法，根据业务场景定义多个具有可扩展性、支持灵活配置调用的业务组件。按业务组件进行产品功能设计与开发形成组件包，将组件包上传组件库，并统一管理所有上传的组件包，在组件库中灵活选取所需的组件包进行拼装，类似利用积木片拼搭积木的方法，完成应用的开发。用于实现软件系统的灵活调用，既能提升软件开发的效率、代码复用率，也能降低运维管理成本，降低系统开发人员的后期维护工作量，改善了系统应用体验。

附图说明

图1为软件生命周期的结构示意图；

图2为现有技术的软件系统开发过程的流程示意图；

图3为本发明的积木式软件系统架构的开发方法一实施例的流程示意图；

图4为本发明的计算机设备一实施例的结构示意图。

具体实施方式

为更进一步阐述本申请为达成预定申请目的所采取的技术手段及功效，以下结合附图及较佳实施例，对本申请详细说明如下。

需要说明的是，本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

在本申请中，术语“上”、“下”、“左”、“右”、“前”、“后”、“顶”、“底”、“内”、“外”、“中”、“竖直”、“水平”、“横向”、“纵向”等指示的方位或位置关系为基于附图所示的方位或位置关系。这些术语主要是为了更好地描述本申请及其实施例，并非用于限定所指示的装置、元件或组成部分必须具有特定方位，或以特定方位进行构造和操作。

并且，上述部分术语除了可以用于表示方位或位置关系以外，还可能用于表示其他含义，例如术语“上”在某些情况下也可能用于表示某种依附关系或连接关系。对于本领域普通技术人员而言，可以根据具体情况理解这些术语在本申请中的具体含义。

此外，术语“安装”、“设置”、“设有”、“连接”、“相连”、“套接”应做广义理解。例如，可以是固定连接，可拆卸连接，或整体式构造；可以是机械连接，或电连接；可以是直接相连，或者是通过中间媒介间接相连，又或者是两个装置、元件或组成部分之间内部的连通。对于本领域普通技术人员而言，可以根据具体情况理解上述术语在本申请中的具体含义。

需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。通过具体实施方式的说明,当可对本申请为达成预定目的所采取的技术手段及效果得以更加深入且具体的了解，然而所附图式仅是提供参考与说明之用，并非用来对本申请加以限制。

实施例一

现有的软件系统架构的开发方法，通常采用事件驱动架构，事件驱动架构包括事件队列(event queue)、分发器(event mediator)、事件通道(event channel)和事件处理器(event processor)，事件队列是接收事件的入口，分发器是将不同的事件分发到不同的业务逻辑单元，事件通道是分发器与处理器之间的联系渠道，事件处理器是实现业务逻辑，处理完成后会发出事件，触发下一步操作。对于简单的项目，事件队列、分发器和事件通道，可以合为一体，整个软件就分成事件代理和事件处理器两部分。常见的事件驱动架构的开发方法，如图2所示，即是基于当前业务场景进行分析，并基于该场景分析设计业务流程，然后进行产品功能的设计，之后再进行前端与后端的代码的开发，代码开发完成后部署到服务器，通过软件测试后即可发布上线。虽然该开发方法的实用性广，各种类型的项目都可以使用，性能也较好，业务场景单一，软件不容易发生堵塞。但是，对于业务场景较多、复杂的情况下，可能会造成管理混乱、重复开发、运维成本高昂等问题。

基于此，有些企业采用微服务架构的开发方法，微服务架构的每一个服务就是一个独立的部署单元。这些单元都是分布式的，互相解耦，通过远程通信协议(比如REST、SOAP)联系。微服务架构在一定程度上优化了软件系统开发的流程，应用上更多体现在后端服务的架构优化，一定程度上打通了后端服务之间的壁垒，提升的代码复用率。但是，由于强调部署单元之间互相独立和低耦合，服务可能会拆分得很细。这导致系统依赖大量的微服务，变得很凌乱和笨重，性能也会不佳。一旦服务之间需要通信(即一个服务要用到另一个服务)，整个架构就会变得复杂。典型的例子就是一些通用的Utility类，一种解决方案是把它们拷贝到每一个服务中去，用冗余换取架构的简单性。

当下的技术方案，更多的是基于传统的软件开发活动过程，在一些环节进行技术优化，仍然无法更大程度地提升软件系统开发效率、提供软件代码复用率、降低运维管理成本等。

因此，基于现有的软件开发基础，本发明提供一种积木式软件系统架构的开发方法，如图3所示，图3为本发明的积木式软件系统架构的开发方法的流程示意图，开发方法的步骤包括：

步骤S1:基于业务场景定义业务模块和组件，其中，业务模块包括多个组件。

步骤S2:对组件进行开发后形成组件包，并将组件包上传至组件库中。

步骤S3:创建应用，从组件库中引用组件包，使用积木式拼装技术拼装组件包。

步骤S4:构建平台，确定构成平台的应用。

步骤S5:部署平台，将平台引用的组件包部署到服务器上，完成软件系统架构的开发。

基于业务场景进行需求分析，不止是基于当前业务场景，而是基于企业内更多的业务场景及未来可能发生的业务场景进行分析，进行业务场景的抽象和拆分，定义多个具有可扩展性、支持灵活配置调用的业务组件。例如，对于物业管理系统，可能包括住宅管理平台、商铺管理平台、写字楼管理平台和公寓管理平台等多个业务平台，其中，每个平台都可设置WEB应用和APP应用，每个应用又包括多个业务模块。在需求分析阶段，尽可能将平台当前所需或者将来所需的业务场景进行分析，比如，住宅管理平台可包括登录业务、投诉业务、门禁授权业务等。每个业务定义多个具有可扩展性、支持灵活配置调用的业务组件，按组件进行产品功能设计与开发。

定义多个不同的业务模块，每个业务模块包括一后端服务组件和一前端页面组件；其中，前端页面组件包括网页页面组件和APP页面组件。后端服务组件包括该业务模块的后端服务代码组件，网页页面组件包括该业务模块的前端页面代码组件，APP页面组件包括该业务模块的前端页面代码组件。在实际应用中，每个业务模块可包括一后端服务组件和一网页页面组件，或者包括一后端服务组件、一网页页面组件和一APP页面组件。

完成业务分析后，输出完整的产品方案，基于产品方案，开发人员开始对各个场景业务的组件进行开发，即是代码编写。对后端服务组件进行代码编写，代码编辑完成后将代码进行打包，形成后端组件包；对网页页面组件进行代码编写，代码编辑完成后将代码进行打包，形成网页组件包；对APP页面组件进行代码编写，代码编辑完成后将代码进行打包，形成APP组件包；每一个组件包类似积木块，组件开发的过程即是积木块生产的过程。

组件开发完成后，将后端组件包、网页组件包和网页组件包上传至组件库中进行统一管理。组件库相当于是一个组件仓库，所有上传至组件库的组件包都是仓库里的资源，组件仓库会对所有组件包进行统一分类管理。例如所有业务模块的后端服务组件的组件包统一存放在后端组件库中，所有业务模块的前端页面组件的网页组件包统一存放在前端网页组件库中，所有业务模块的前端页面服务组件的APP组件包统一存放在前端APP组件库中。

上传至组件库的组件包越多，资源越丰富。比如可能还有登录业务的组件包，门禁授权类的组件包、车辆通行功能的组件包等，组件包越多，后期组装应用的功能越丰富。

同时，组件包支持功能升级迭代，所有的组件迭代都将按版本号进行留痕管理，所有历史版本可查。即组件包需要升级，在组件库中获取对应的组件包，进行二次开发，形成升级包，上传至组件库中。

创建应用，从组件库中引用组件包，使用积木式拼装技术拼装组件包。根据业务需求，从组件库中选择合适的组件包，构建成应用系统。例如，要建设一个物业管理系统，该物业管理系统需要实现门禁授权、投诉管理的功能。则创建并定义好该应用后，从组件库去勾选该应用所需要的组件包，即门禁授权的后端组件包、前端组件包，投诉管理的后端组件包、前端组件包，且可任选版本。

若要建设一个商铺运营管理系统，该应用系统需要实现商铺管理、投诉管理的功能。若组件库中的投诉业务组件，功能能满足该商铺运营系统的需求，则可同理从组件库勾选所需的招商类组件包、投诉类组件包。组件包的选择可以根据实际需求进行选择。若要实现更多功能，则从组件库中选择相应的组件包，将选择的组件包采用积木式拼装技术将组件包进行拼装。

其中，投诉类组件包是组件库中的公共资源，只要该组件包实现的功能逻辑能满足系统的需求，则可以被任何应用系统引用。同理，组件库中的任意公共组件包，可被任意应用系统引用，由此，实现代码复用，降低组件库的存储容量，通过灵活调用组件，可降低运维管理成本，降低系统开发人员的后期维护工作量。

在其他实施例中，使用积木式拼装技术拼装组件包的步骤包括：

使用积木式拼装技术，将引用的组件包进行拼装，得到软件安装包。上一步只完成了组件包的选择，即某应用选用了整个组件库中的一部分组件包。还需进行应用编排，即选用的这些组件包如何构成一个完整的应用系统。例如，物业管理系统，在菜单排序上，门禁授权功能在前，还是投诉功能在前，可进行编排，和各个功能的业务跳转顺序进行编排，完成一个完整应用的构建和编排。当投诉组件进行了功能升级，在组件库发布了组件包新版本后，该应用系统也可根据需要选择更新版本的组件包，进行功能升级。若无需求也可不升级继续使用旧版本组件。

完成应用系统的开发后，构建平台，确定构成平台的应用。

在其他实施例中，确定构成平台的应用包括：

定义平台的框架；

在框架中选择需要的应用。

根据系统的应用领域设定基础界面，在本实施例中，根据物业管理系统设定其基础界面。设置系统架构和功能模块，确认该平台由哪几个应用共同形成，即在系统里增加登录模块、投诉模块、门禁授权模块等常用功能。对应的，在组件库中选择对应功能业务的组件包，以形成完善的系统应用。

在其他实施例中，部署平台还包括：

部署多个平台，引用相同或者不同的组件包，部署到服务器上。

完成应用和平台的构建后，可进行平台的部署。比如，部署住宅管理平台，借助部署工具，自动将该平台引用的所有组件包，下发部署到服务器上。若部署商铺管理平台，借助部署工具，自动将该平台引用的所有组件包，下发部署到服务器上。两个平台可能引用了不同的组件包，也可能引用了相同的组件包。但其各自部署运行，互不干扰，即使选择相同的组件包，不同的平台也能正常运行。即组件包是共享资源，可以根据需求，在实际运用中，灵活选用，灵活拼装，实现代码复用，统一管理组件包，能够降低维护成本。

有益效果：本发明公开了一种积木式软件系统架构的开发方法、存储介质及设备，该开发方法采用积木式的系统架构方法，根据业务场景定义多个具有可扩展性、支持灵活配置调用的业务组件。按业务组件进行产品功能设计与开发形成组件包，将组件包上传组件库，并统一管理所有上传的组件包，在组件库中灵活选取所需的组件包进行拼装，类似利用积木片拼搭积木的方法，完成应用的开发。用于实现软件系统的灵活调用，既能提升软件开发的效率、代码复用率，也能降低运维管理成本，降低系统开发人员的后期维护工作量，改善了系统应用体验。

实施例二

本发明还提供一种存储介质，存储前述的积木式软件系统架构的开发方法。

实施例三

本发明还提供一种计算机设备，包括用以执行如前述的积木式软件系统架构的开发方法的软件与软件配合的硬件。

请参阅图4，图4为本发明的计算机设备一实施例的结构示意图。

结合图3描述的根据本发明实施例提供的积木式软件系统架构的开发方法可以由设备来实现。图4是示出根据发明实施例的设备的硬件结构示意图。

该设备可以包括处理器401以及存储有计算机程序指令的计算机存储介质402。

具体地，上述处理器401可以包括中央处理器(Central Processing Unit，CPU)，或者特定集成电路(Application Specific Integrated Circuit，ASIC)，或者可以被配置成实施本发明实施例的一个或多个集成电路。

计算机存储介质402可以包括用于数据或指令的大容量计算机存储介质。举例来说而非限制，计算机存储介质402可包括硬盘驱动器(Hard Disk Drive，HDD)、软盘驱动器、闪存、光盘、磁光盘、磁带或通用串行总线(Universal Serial Bus，USB)驱动器或者两个或更多个以上这些的组合。在一个实例中，计算机存储介质402可以包括可移除或不可移除(或固定)的介质，或者计算机存储介质402是非易失性固态计算机存储介质。计算机存储介质402可在综合网关容灾设备的内部或外部。

在一个实例中，计算机存储介质402可以是只读计算机存储介质(Read OnlyMemory，ROM)。在一个实例中，该ROM可以是掩模编程的ROM、可编程ROM(PROM)、可擦除PROM(EPROM)、电可擦除PROM(EEPROM)、电可改写ROM(EAROM)或闪存或者两个或更多个以上这些的组合。

处理器401通过读取并执行计算机存储介质402中存储的计算机程序指令，以实现图3所示实施例中的方法，并达到图3所示实例执行其方法/步骤达到的相应技术效果，为简洁描述在此不再赘述。

在一个示例中，设备还可包括输入/输出接口403、通信接口404和总线405。其中，如图4所示，处理器401、计算机存储介质402、输入/输出接口403和通信接口404通过总线405连接并完成相互间的通信。

输入/输出接口403用于连接输入/输出模块，以实现信息输入及输出。输入输出/模块可以作为组件配置在设备中(图中未示出)，也可以外接于设备以提供相应功能。其中输入设备可以包括键盘、鼠标、触摸屏、麦克风、各类传感器等，输出设备可以包括显示器、扬声器、振动器、指示灯等。

通信接口404，主要用于实现本发明实施例中各模块、装置、单元和/或设备之间的通信。

总线405包括硬件、软件或两者，将在线数据流量计费设备的部件彼此耦接在一起。举例来说而非限制，总线可包括加速图形端口(Accelerated Graphics Port，AGP)或其他图形总线、增强工业标准架构(Extended Industry Standard Architecture，EISA)总线、前端总线(Front Side Bus，FSB)、超传输(Hyper Transport，HT)互连、工业标准架构(Industry Standard Architecture，ISA)总线、无限带宽互连、低引脚数(LPC)总线、计算机存储介质总线、微信道架构(MCA)总线、外围组件互连(PCI)总线、PCI-Express(PCI-X)总线、串行高级技术附件(SATA)总线、视频电子标准协会局部(VLB)总线或其他合适的总线或者两个或更多个以上这些的组合。在合适的情况下，总线405可包括一个或多个总线。尽管本发明实施例描述和示出了特定的总线，但本发明考虑任何合适的总线或互连。

还需要说明的是，本发明中提及的示例性实施例，基于一系列的步骤或者装置描述一些方法或系统。但是，本发明不局限于上述步骤的顺序，也就是说，可以按照实施例中提及的顺序执行步骤，也可以不同于实施例中的顺序，或者若干步骤同时执行。

上面参考根据本公开的实施例的方法、装置(系统)和计算机程序产品的流程图和/或框图描述了本公开的各方面。应当理解，流程图和/或框图中的每个方框以及流程图和/或框图中各方框的组合可以由计算机程序指令实现。这些计算机程序指令可被提供给通用计算机、专用计算机、或其它可编程数据处理装置的处理器，以产生一种机器，使得经由计算机或其它可编程数据处理装置的处理器执行的这些指令使能对流程图和/或框图的一个或多个方框中指定的功能/动作的实现。这种处理器可以是但不限于是通用处理器、专用处理器、特殊应用处理器或者现场可编程逻辑电路。还可理解，框图和/或流程图中的每个方框以及框图和/或流程图中的方框的组合，也可以由执行指定的功能或动作的专用硬件来实现，或可由专用硬件和计算机指令的组合来实现。

以上所述，仅为本发明的具体实施方式，所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，上述描述的系统、模块和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。应理解，本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到各种等效的修改或替换，这些修改或替换都应涵盖在本发明的保护范围之内。

以上所述，仅是本申请的较佳实施例而已，并非对本申请作任何形式上的限制，虽然本申请已以较佳实施例揭露如上，然而并非用以限定本申请,任何熟悉本专业的技术人员，在不脱离本申请技术方案范围内,当可利用上述揭示的技术内容作出些许更动或修饰为等同变化的等效实施例,但凡是未脱离本申请技术方案内容，依据本申请的技术实质对以上实施例所作的任何简单修改、等同变化与修饰,均仍属于本申请技术方案的范围内。