【技术实现步骤摘要】
本专利技术属于机载软件架构，具体涉及一种服务化系统架构设计方法。
技术介绍
1、机载软件架构需要协同飞机上不同的机载设备，输入输出多，协议多，需要设计合理可靠的软件架构。目前传统的软件架构设计方法具有以下两种：
2、1、面向过程的设计
3、以过程为单位设计功能，一般通过基于用例的方法，这种方法虽然能保证逻辑的正确性和完整性，但难以站在功能对象的角度思考聚合成稳定的功能集合，因此过程为单位构成的功能集合大概率会存在功能特性不一致、功能内聚性不强、功能演进频率不一致等问题，导致其功能迭代维护成本过高，不适合当前环境下敏捷迭代、快速适应的需要。
4、2、面向对象的设计
5、以对象为单位设计功能，早期以分布式对象代表，当下演进到以微服务架构(msa)和面向服务(soa)为主流，这两种方法在敏捷迭代和架构完备互有侧重。这两种以服务对象为基础概念的方法都存在以服务对象设计为核心的碎块化设计思想，虽然能提升功能的迭代、迁移能力，但抽象出的对象优劣难以存在一个可量化的判定，导致其设计难度高、设计标准不一致，且由于从抽象对象入手，需要花费较长的时间优化才能保证逻辑正确性和完整性。
技术实现思路
1、本专利技术的目的：为了解决上述问题，本专利技术提供了一种服务化系统架构设计方法，通过一些设计机制糅合了面向过程与面向对象的设计方法，设计方法分为两个阶段：基于主干的细化和基于服务模型的固化。
2、本专利技术技术方案：
3、一种服务化系
4、步骤一，基于主干的细化：先形成系统的顶层功能主干，然后基于主干进行逻辑细化，逐渐生长出完整的系统架构模型雏形；具体将待设计的系统分解成若干顶层dot，按照逻辑顺序分解每个顶层dot，得到具备先后逻辑顺序关系的子dot；基于主干过程，进一步分析这些子dot，逐步分解出子dot、dot，再对分解出的dot进行内聚操作，将uml活动元素放入uml泳道元素；
5、步骤二，基于模型的固化：根据服务模型的规范补充上一阶段形成的模型元素雏形，形成最终的服务化系统架构模型，服务化系统架构模型包含服务、服务操作、服务接口、服务依赖、内部关联；将步骤一的uml泳道元素转化成服务模型元素，将uml活动元素转化成服务操作模型元素，将根据前面固化的服务操作/服务接口自然转化成服务依赖、内部关联等服务模型元素，调整服务操作模型元素的服务操作粒度，调整服务模型元素的服务粒度。
6、进一步的，步骤一中，dot具体为功能对象，具体表达了一个功能对象能做一件事。
7、进一步的，dot模型具体为：额外的包含数据元素，dot执行时需要数据输入，输入的数据一定是另一个dot的输出，dot能够延展出其他dot，一个dot只能有一个入口。
8、进一步的，步骤一中，基于主干过程，分析子dot，基于横向顺序分解和纵向关联扩展两种细化方式，在原则约束下，逐步分解出各个子dot，不断重复此步骤直至子dot无法分解；各个子dot之间具有不同的关系，这些关系包括强顺序型、弱顺序型、关联型和无关系，原则约束根据子dot之间不同的关系类型确定。
9、进一步的，强顺序型指dot间必须严格的按照时序顺序执行，弱顺序型指dot间应该按照非严格时序执行，关联型指dot间存在一定的影响但无顺序逻辑，无关系用于保证dot关系逻辑的完备性。
10、进一步的，原则约束包括：dot横向顺序分解出的子功能间的关系既可能是强顺序型，也可能是弱顺序型，但一定不是关联型；dot纵向关联扩展出的子dot间的关系一定是关联型关系；dot的纵向关联会随着dot的横向分解，转移到分解出的子dot上。
11、进一步的，将uml活动元素转化成服务操作模型元素，并定义服务操作的服务接口，具体的：跨服务的关联型线箭头处定义为发布订阅接口，或者，跨服务的强顺序型线箭头处定义为请求响应接口或者强顺序型线出口处定义为事件通知接口。
12、进一步的，将根据前面固化的服务操作/服务接口自然转化成服务依赖、内部关联等服务模型元素，具体的：服务模型元素基于uml活动元素转化的服务操作模型元素中的接口定义，线的另一端定义成具体服务依赖活动对象转化的服务操作模型元素服务内的线，关联型线定义为数据型关联，强顺序型线定义为控制型关联。
13、进一步的，调整活动对象转化的服务操作模型元素形成的服务操作粒度，包括合并、分解、删除服务操作等行为。
14、进一步的，调整uml泳道元素转化的服务模型元素过程形成的服务粒度，包括确定与更换服务操作与服务的绑定关系，新增、删除服务等行为。
15、本专利技术的有益效果：
16、1.本专利技术所述的服务化系统架构设计方法，对比现有的面向过程设计方法，完备了面向过程的前向分析过程，即基于主干的细化阶段，以dot模型为桥梁，使得后续面向过程的设计可追溯出其功能对象，便于后续面向对象的功能内聚。
17、2.本专利技术所述的服务化系统架构设计方法，对比现有的面向对象设计方法，其强调功能对象与过程的相互迭代逻辑，通过横向顺序分解和纵向关联扩展的方法不断细化功能对象，维系住了功能对象间的关系，提升了功能对象的逻辑正确性和完整性。
本文档来自技高网...【技术保护点】
1.一种服务化系统架构设计方法，其特征在于，包括以下步骤：
2.根据权利要求1所述的一种服务化系统架构设计方法，其特征在于，步骤一中，DOT具体为功能对象，具体表达了一个功能对象能做一件事。
3.根据权利要求2所述的一种服务化系统架构设计方法，其特征在于，DOT模型具体为：额外的包含数据元素，DOT执行时需要数据输入，输入的数据一定是另一个DOT的输出，DOT能够延展出其他DOT，一个DOT只能有一个入口。
4.根据权利要求1所述的一种服务化系统架构设计方法，其特征在于，步骤一中，基于主干过程，分析子DOT，基于横向顺序分解和纵向关联扩展两种细化方式，在原则约束下，逐步分解出各个子DOT，不断重复此步骤直至子DOT无法分解；各个子DOT之间具有不同的关系，这些关系包括强顺序型、弱顺序型、关联型和无关系，原则约束根据子DOT之间不同的关系类型确定。
5.根据权利要求4所述的一种服务化系统架构设计方法，其特征在于，强顺序型指DOT间必须严格的按照时序顺序执行，弱顺序型指DOT间应该按照非严格时序执行，关联型指DOT间存在一定的影响但无顺
6.根据权利要求4所述的一种服务化系统架构设计方法，其特征在于，原则约束包括：DOT横向顺序分解出的子功能间的关系既可能是强顺序型，也可能是弱顺序型，但一定不是关联型；DOT纵向关联扩展出的子DOT间的关系一定是关联型关系；DOT的纵向关联会随着DOT的横向分解，转移到分解出的子DOT上。
7.根据权利要求1所述的一种服务化系统架构设计方法，其特征在于，将UML活动元素转化成服务操作模型元素，并定义服务操作的服务接口，具体的：跨服务的关联型线箭头处定义为发布订阅接口，或者，跨服务的强顺序型线箭头处定义为请求响应接口或者强顺序型线出口处定义为事件通知接口。
8.根据权利要求1所述的一种服务化系统架构设计方法，其特征在于，将根据前面固化的服务操作/服务接口自然转化成服务依赖、内部关联等服务模型元素，具体的：服务模型元素基于UML活动元素转化的服务操作模型元素中的接口定义，线的另一端定义成具体服务依赖活动对象转化的服务操作模型元素服务内的线，关联型线定义为数据型关联，强顺序型线定义为控制型关联。
9.根据权利要求1所述的一种服务化系统架构设计方法，其特征在于，调整活动对象转化的服务操作模型元素形成的服务操作粒度，包括合并、分解、删除服务操作等行为。
10.根据权利要求1所述的一种服务化系统架构设计方法，其特征在于，调整UML泳道元素转化的服务模型元素过程形成的服务粒度，包括确定与更换服务操作与服务的绑定关系，新增、删除服务等行为。
...【技术特征摘要】
1.一种服务化系统架构设计方法，其特征在于，包括以下步骤：
2.根据权利要求1所述的一种服务化系统架构设计方法，其特征在于，步骤一中，dot具体为功能对象，具体表达了一个功能对象能做一件事。
3.根据权利要求2所述的一种服务化系统架构设计方法，其特征在于，dot模型具体为：额外的包含数据元素，dot执行时需要数据输入，输入的数据一定是另一个dot的输出，dot能够延展出其他dot，一个dot只能有一个入口。
4.根据权利要求1所述的一种服务化系统架构设计方法，其特征在于，步骤一中，基于主干过程，分析子dot，基于横向顺序分解和纵向关联扩展两种细化方式，在原则约束下，逐步分解出各个子dot，不断重复此步骤直至子dot无法分解；各个子dot之间具有不同的关系，这些关系包括强顺序型、弱顺序型、关联型和无关系，原则约束根据子dot之间不同的关系类型确定。
5.根据权利要求4所述的一种服务化系统架构设计方法，其特征在于，强顺序型指dot间必须严格的按照时序顺序执行，弱顺序型指dot间应该按照非严格时序执行，关联型指dot间存在一定的影响但无顺序逻辑，无关系用于保证dot关系逻辑的完备性。
6.根据权利要求4所述的一种服务化系统架构设计方法，其特征在于，原则约束包括：dot横向顺序分解出的子功能间的关系既可能...
【专利技术属性】
技术研发人员：韩旭，谢锋，解兴铭，陈名熙，赵文浩，张于可心，任洁，
申请(专利权)人：中国航空工业集团公司成都飞机设计研究所，
类型：发明
国别省市：
还没有人留言评论。发表了对其他浏览者有用的留言会获得科技券。