本发明涉及软件构架设计技术领域，尤其涉及一种基于扩展和插件方式的软件架构设计系统。
背景技术：
现有的实现软件架构设计的方案，主要包括以下两种：
方案一，所有代码都在一起，应用程序(APP)只有一个工程，所有开发者、开发团队都在该工程中并行开发，该方案的缺点，包括：
代码都在一起，依赖和耦合度高，任何人都可以改动到其他人的代码，软件的稳定性较差，且当团队规模较大时，协作效率较低。
方案二，一个主工程多个子工程，相互间有依赖和耦合，应用程序APP有一个主工程和多个子工程，不同的业务开发团队在指定的子工程上开发，该方案的缺点，包括：
虽然拆分了多个工程，物理上将不同开发者、开发团队隔离开，但实际上各个子工程相互之间有依赖，无法单独编译，开发者开发调试时还是需要所有的工程，效率较低，且当业务快速变化时无法快速拆分工程、去掉工程。
技术实现要素：
本发明提供一种基于扩展和插件方式的软件架构设计系统，用以解决现有技术的依赖和耦合度高，且当团队规模较大时，协作效率低的技术问题。
为解决上述技术问题，本发明提供一种基于扩展和插件方式的软件架构设计系统，包括：宿主、调度模块、插件、插件接入适配器、宿主接口实现者、宿主接口；
所述宿主向所述调度模块发起请求，索要所述插件，所述调度模块内部处理，将每个请求转给不同的所述插件接入适配器，所述插件接入适配器与所述插件本身交互，交换信息，按照所述宿主约定的接口生成所述宿主接口实现者，该所述宿主接口实现者分装了所述插件实体本身，并返回给所述宿主，所述宿主依赖于所述宿主接口，通过所述宿主接口约定的规则操作所述插件。
其中，所述宿主向所述调度模块发起请求，包括：
所述宿主根据extensionPointID，向所述调度模块发起请求。
其中，所述调度模块用于管理所述宿主和所述插件，当应用程序APP启动后，所述调度模块会将所述宿主的配置文件X.FTExtensionPoint.plist和所述插件的配置文件X.FTExtension.plist全部加在到内存中，并整理得到两个列表：宿主表和插件表。
其中，所述调度模块用于在系统运行时，将使用该整理得到的两个列表宿主表和插件表，来管理整个扩展-插件系统。
其中，所述宿主独立于所述插件，不依赖所述插件，对所述宿主来说所述插件不是必须的，所述宿主不能直接调用所述插件的接口和能力。
其中，所述插件依附于所述宿主，所述插件可以直接调用所述宿主的接口和能力。
其中，一个所述宿主支持多个所述插件。
其中，在所述宿主、所述插件之间引入一个抽象接口层，用于解决所述宿主和所述插件解耦合。
其中，定义所述宿主的配置文件X.FTExtensionPoint.plist和所述插件的配置文件X.FTExtension.plist，每个业务模块均有一个所述宿主的配置文件和一个所述插件的配置文件，每个所述宿主的配置文件可配置多个所述宿主的信息，每个所述插件的配置文件可配置多个所述插件的信息。
其中，extensionPointID代表所述宿主的识别码ID，extensionID代表所述插件的识别码ID，通过该配置文件可将所述宿主和所述插件关联起来；通过该配置文件将插件ID和对应的处理类关联起来，再结合所述宿主的配置文件，宿主表和插件表一起把所述宿主的识别码ID-所述插件的识别码ID-所述插件处理类连接贯穿。
本发明提供自然基于扩展和插件方式的软件架构设计系统，包括：宿主向调度模块发起请求，索要插件，调度模块内部处理，将每个请求转给不同的插件接入适配器，插件接入适配器与插件本身交互，交换信息，按照宿主约定的接口生成宿主接口实现者，该宿主接口实现者分装了插件实体本身，并返回给宿主，宿主依赖于宿主接口，通过宿主接口约定的规则操作插件，从而达到实现不仅在物理上将代码分隔开，让不同开发者、开发团队只在自己负责的子工程中开发，还在逻辑上将各工程的依赖、耦合解除，方便开发者只使用自己相关的一个或几个工程开发、调试，大大提升了开发效率。
附图说明
图1为本发明基于扩展和插件方式的软件架构设计系统的结构示意图。
具体实施方式
下面结合附图和实施例，对本发明作进一步的详细描述。特别指出的是，以下实施例仅用于说明本发明，但不对本发明的范围进行限定。同样的，以下实施例仅为本发明的部分实施例而非全部实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其它实施例，都属于本发明保护的范围。
应用程序APP，指iOS平台上的应用程序。
软件架构：指应用程序APP整体框架、关键结构。
Objective-C：指iOS平台上应用程序的开发语言。
工程：iOS平台应用程序开发过程中使用术语，一个应用程序APP可以包含1个或多个工程。
二进制：指软件被开发完后编译得到的可执行文件。
业务模块：指用程序中按照产品特性划分的诸多地位平等的功能。
宿主(Host)：指扩展-插件模式中的主体。
插件：指扩展-插件模式中的客体。
本发明提供一种基于扩展和插件方式的软件架构设计系统。
请参见图1，图1为本发明基于扩展和插件方式的软件架构设计系统的结构示意图，本发明基于扩展和插件方式的软件架构设计系统，包括：宿主101、调度模块102、插件103、插件接入适配器104、宿主接口实现者105、宿主接口106。
宿主101向调度模块102发起请求，索要插件103，调度模块102内部处理，将每个请求转给不同的插件接入适配器104，插件接入适配器104与插件103本身交互，交换信息，按照宿主101约定的接口生成宿主接口实现者105，该宿主接口实现者105分装了插件103实体本身，并返回给宿主101，宿主101依赖于宿主接口106，通过宿主接口106约定的规则操作插件103。
其中，宿主101向调度模块102发起请求，包括：
宿主101根据extensionPointID，向调度模块102发起请求。
其中，调度模块102用于管理宿主101和插件103，当应用程序APP启动后，调度模块102会将宿主101的配置文件X.FTExtensionPoint.plist和插件103的配置文件X.FTExtension.plist全部加在到内存中，并整理得到两个列表：宿主表和插件表。
其中，调度模块102用于在系统运行时，将使用该整理得到的两个列表宿主表和插件表，来管理整个扩展-插件系统。
其中，宿主101独立于插件103，不依赖插件103，对宿主101来说插件103不是必须的，宿主101不能直接调用插件103的接口和能力。
其中，插件103依附于宿主101，插件103可以直接调用宿主101的接口和能力。
其中，一个宿主101支持多个插件103。
其中，在宿主101、插件103之间引入一个抽象接口层，用于解决宿主101和插件103解耦合。
其中，定义宿主101的配置文件X.FTExtensionPoint.plist和插件103的配置文件X.FTExtension.plist，每个业务模块均有一个宿主101的配置文件和一个插件103的配置文件，每个宿主101的配置文件可配置多个宿主101的信息，每个插件103的配置文件可配置多个插件103的信息。
其中，extensionPointID代表宿主101的识别码ID，extensionID代表插件103的识别码ID，通过该配置文件可将宿主101和插件103关联起来；通过该配置文件将插件ID和对应的处理类关联起来，再结合宿主101的配置文件，宿主表和插件表一起把宿主101的识别码ID-插件103的识别码ID-插件103处理类连接贯穿。
每个宿主101都要根据各自使用场景的特点定义抽象接口规则，宿主101依赖于该抽象接口，插件103需要遵从宿主101定义的规则，即插件103来实现接口，这样宿主101和插件103之间就没有直接耦合了。
本发明提供的基于扩展和插件方式的软件架构设计系统，包括：宿主101、调度模块102、插件103、插件接入适配器104、宿主接口实现者105、宿主接口106；宿主101向调度模块102发起请求，索要插件103，调度模块102内部处理，将每个请求转给不同的插件接入适配器104，插件接入适配器104与插件103本身交互，交换信息，按照宿主101约定的接口生成宿主接口实现者105，该宿主接口实现者105分装了插件103实体本身，并返回给宿主101，宿主101依赖于宿主接口106，通过宿主接口106约定的规则操作插件103，从而达到实现不仅在物理上将代码分隔开，让不同开发者、开发团队只在自己负责的子工程中开发，还在逻辑上将各工程的依赖、耦合解除，方便开发者只使用自己相关的一个或几个工程开发、调试，大大提升了开发效率。
本发明提供的基于扩展和插件方式的软件架构设计系统，可以解除应用程序APP主体和业务模块的耦合，使应用程序APP可以灵活的拆分成多个业务模块，业务模块彼此间无耦合无依赖，方便大型项目跨团队开发，提升开发效率、降低团队协作成本。
本发明提供的基于扩展和插件方式的软件架构设计系统，宿主101与插件103的管理配置方式不限于上述提到的plist静态文件，也可以使用其他文件格式配置或动态配置；其中，扩展-插件架构不限于iOS平台应用程序APP的开发，其他客户端平台如Mac、Android、Windows同样适用该架构。
本发明提供的基于扩展和插件方式的软件架构设计系统，能有效的支持应用程序APP的开发、维护和使用，包含的主要业务模块可以有行情、交易、资讯、社交等，这些业务模块现均已使用该技术接入应用程序APP主体，且今后随着业务的扩张，新的产品特性也可以以此方案快速接入。
在本发明所提供的几个实施方式中，应该理解到，所揭露的系统，装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施方式仅仅是示意性的，例如，模块或单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施方式方案的目的。
另外，在本发明各个实施方式中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。
集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器(processor)执行本发明各个实施方式方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，RandomAccess Memory)、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述仅为本发明的部分实施例，并非因此限制本发明的保护范围，凡是利用本发明说明书及附图内容所作的等效装置或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本发明的专利保护范围内。