一种产品模型的增维形态和模型定义方法与流程

[0001]
本发明涉及的是工业软件领域，特别涉及一种产品模型的增维形态和模型定义方法。


背景技术：

[0002]
在工业软件领域，工业产品不仅仅指生产的产品，设备、生产线、系统等我们都统称为工业产品。针对这些工业产品所开发出来的软件我们称为工业软件。工业软件涉及工业产品的设计、制造，运维和管理全生命周期。工业软件的设计方法有很多种，我们主要采用的是模型驱动的工业软件方法，其中模型就是工业软件的载体。
[0003]
在工业软件领域，通常的模型都只包含对象或行为的单项，但产品模型是两者的组合，且两者自动关联。工业领域产品模型中产品和行为定义如下。两者关联是通过“产品属性中类型值”等于“行为属性中的产品类型值”实现。在计算机实现中，产品元元模型通过uml实现上述定义在计算机中的自动映射。在工业软件中的领域模型是指对工业领域内的概念类或现实世界中工业产品对象的可视化表示。传统的软件开发模式都是面向对象或者面向过程，但由于工业软件的复杂性，这些开发模式已经无法满足工业软件的需求。


技术实现要素：

[0004]
鉴于上述问题，提出了本发明以便提供一种克服上述问题或者至少部分地解决上述问题的一种一种产品模型的增维形态和模型定义方法。
[0005]
为了解决上述技术问题，本申请实施例公开了如下技术方案：
[0006]
一种产品模型的增维形态和模型定义方法，包括：
[0007]
s100.准备数据库文件，创建的数据库使用sqlite数据库作为数据的存储；
[0008]
s200.创建属性字典库，属性字典库记录了项目的基本属性、产品的属性和行为的属性；
[0009]
s300.将项目的基本属性、产品属性、行为属性和状态属性存储到属性字典库中；
[0010]
s400.创建产品字典库和产品结构字典库，产品字典库和产品结构字典库包含产品基本信息；
[0011]
s500.根据产品结构，在产品字典库中存入产品信息和向产品结构字典中存储产品结构；
[0012]
s600.创建行为字典库和行为流程字典库；
[0013]
s700.根据行为流程图，在行为字典库中存储行为信息和向行为流程字典中存储行为流程；
[0014]
s800.在产品结构中，对每个节点产品从属性字典库中选择添加需要的属性；在行为流行中，对每个节点行为从属性字典库中选择添加需要的输入参数属性；
[0015]
s900.创建状态字典库；
[0016]
s1000.将产品结构和行为流程赋值到模型中，并给模型添加基本属性；创建产品
的增维形态模型；
[0017]
s1100.根据配置的结构生成窗口视图，生成项目模板。
[0018]
进一步地，s200中，项目的基本属性包含属性的编号、名称、类型信息。
[0019]
进一步地，s400中，产品字典库中的产品是构建产品构型的基本元素，产品字典库可以储存每一种可以独立存在的产品元素,由产品名和产品属性等构成。
[0020]
进一步地，s600中，字典库和行为流程字典库包含行为的编号、名称、输入和输出信息。
[0021]
进一步地，s900中，状态字典库包含了字典的编号、名称、输入和输出信息。
[0022]
进一步地，s900中，s1000中，增维形态模型包含产品的结构和行为流程、表示产品模型结构和行为模型流程的管理方式的模型，是用户处理的基本模型。
[0023]
进一步地，s1100中，当项目模板生成后，最终用户根据项目模板创建和执行数据的输入和展示，根据模型行为流程执行行为，得到行为状态进行展示。
[0024]
进一步地，可以通过逻辑视图描述模型的静态结构和模型内部的动态协作关系。
[0025]
进一步地，模型的静态结构在逻辑视图中的类图和对象图中进行描述，模型动态结构在状态图、时序图、协作图和活动图中进行描述。
[0026]
本发明实施例提供的上述技术方案的有益效果至少包括：
[0027]
本发明公开的一种产品模型的增维形态和模型定义方法，提出了面向模型的开发方式，以模型为中心的软件开发框架性标准—模型驱动体系结构。本发明是对于从某一视角或某一点上看到的系统所做的简化描述，描述中涵盖了系统的某一特定方面，而省略了于此方面无关的实体。解决了软件架构文档过分强调软件开发的某一个方面，软件架构不能解决所有风险承担者所关注的问题。由于每个软件系统都有多个风险承担者：最终用户、开发人员、系统工程师、项目经理等。解决了软件工程师想要使用单张视图来捕捉所有的系统架构要点，在单一视图中表达超过其表达限度的蓝图的问题。使用多个并发的视图来组织软件架构的描述，每个视图仅用来描述一个特定的所关注的方面的问题集合。解决了现有的开发模式已经无法满足工业软件的需求的问题。
[0028]
下面通过附图和实施例，对本发明的技术方案做进一步的详细描述。
附图说明
[0029]
附图用来提供对本发明的进一步理解，并且构成说明书的一部分，与本发明的实施例一起用于解释本发明，并不构成对本发明的限制。在附图中：
[0030]
图1为本发明实施例1中，一种产品模型的增维形态和模型定义方法的流程图。
具体实施方式
[0031]
下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。
[0032]
为了解决现有技术中存在的现有开发模式已经无法满足工业软件的需求问题，本发明实施例提供一种产品模型的增维形态和模型定义方法。
[0033]
实施例1
[0034]
本实施例公开了一种产品模型的增维形态和模型定义方法，包括：
[0035]
s100.准备数据库文件，创建的数据库使用sqlite数据库作为数据的存储。
[0036]
s200.创建属性字典库，属性字典库记录了项目的基本属性、产品的属性和行为的属性；具体的，本实施例s200中，项目的基本属性包含属性的编号、名称、类型等信息。
[0037]
s300.将项目的基本属性、产品属性、行为属性和状态属性存储到属性字典库中。
[0038]
s400.创建产品字典库和产品结构字典库，产品字典库和产品结构字典库包含产品基本信息。
[0039]
本实施例s400中，产品字典库中的产品是构建产品构型的基本元素，产品字典库可以储存每一种可以独立存在的产品元素,由产品名和产品属性等构成。
[0040]
s500.根据产品结构，在产品字典库中存入产品信息和向产品结构字典中存储产品结构。
[0041]
s600.创建行为字典库和行为流程字典库；在本实施例s600中，字典库和行为流程字典库包含行为的编号、名称、输入和输出信息。
[0042]
s700.根据行为流程图，在行为字典库中存储行为信息和向行为流程字典中存储行为流程。
[0043]
s800.在产品结构中，对每个节点产品从属性字典库中选择添加需要的属性；在行为流行中，对每个节点行为从属性字典库中选择添加需要的输入参数属性。
[0044]
s900.创建状态字典库；在本实施例s900中，状态字典库包含了字典的编号、名称、输入和输出信息。
[0045]
s1000.将产品结构和行为流程赋值到模型中，并给模型添加基本属性；创建产品的增维形态模型；在本实施例s1000中，增维形态模型包含产品的结构和行为流程、表示产品模型结构和行为模型流程的管理方式的模型，是用户处理的基本模型。
[0046]
s1100.根据配置的结构生成窗口视图，生成项目模板。在本实施例的s1100中，当项目模板生成后，最终用户根据项目模板创建和执行数据的输入和展示，根据模型行为流程执行行为，得到行为状态进行展示。
[0047]
在本实施例中，可以通过逻辑视图描述模型的静态结构和模型内部的动态协作关系。模型的静态结构在逻辑视图中的类图和对象图中进行描述，模型动态结构在状态图、时序图、协作图和活动图中进行描述。
[0048]
具体的，类图(class diagram)是显示了模型的静态结构，特别是模型中存在的类、类的内部结构以及它们与其他类的关系等。类图不显示暂时性的信息。类图是面向对象建模的主要组成部分。它既用于应用程序的系统分类的一般概念建模，也用于详细建模，将模型转换成编程代码。类图也可用于数据建模。产品的模型包含产品的基本属性，基本属性记录的属性为所有产品共有属性，具体属性为从属性字典中选择获取新建立的属性。行为的模型包含产品的基本属性，基本属性记录的属性为所有行为共有属性，具体属性为从属性字典中选择获取新建立的属性。
[0049]
活动图(activity diagram)为了阐明了业务用例实现的工作流程。业务用例工作流程说明了业务为向所服务的业务主角提供其所需的价值而必须完成的工作。业务用例由一系列活动组成，它们共同为业务主角生成某些工件。工作流程通常包括一个基本工作流
程和一个或多个备选工作流程，工作流程的结构使用活动图来进行说明。
[0050]
序列图(sequence diagram)主要用于按照交互发生的一系列顺序，显示对象之间的这些交互。开发者一般认为序列图只对他们有意义。然而，一个组织的业务人员会发现，序列图显示不同的业务对象如何交互，对于交流当前业务如何进行很有用。除记录组织的当前事件外，一个业务级别的序列图能被当作一个需求文件使用，为实现一个未来系统传递需求。在项目的需求阶段，分析师能通过提供一个更加正式层次的表达，把用例带入下一层次。
[0051]
本实施例公开的一种产品模型的增维形态和模型定义方法，提出了面向模型的开发方式，以模型为中心的软件开发框架性标准—模型驱动体系结构。本发明是对于从某一视角或某一点上看到的系统所做的简化描述，描述中涵盖了系统的某一特定方面，而省略了于此方面无关的实体。软件架构文档过分强调软件开发的某一个方面。软件架构不能解决所有风险承担者所关注的问题。每个软件系统都有多个风险承担者：最终用户、开发人员、系统工程师、项目经理等。软件工程师想要使用单张视图来捕捉所有的系统架构要点，努力地在单一视图中表达超过其表达限度的蓝图。使用多个并发的视图来组织软件架构的描述，每个视图仅用来描述一个特定的所关注的方面的问题集合。解决了现有的开发模式已经无法满足工业软件的需求的问题。
[0052]
应该明白，公开的过程中的步骤的特定顺序或层次是示例性方法的实例。基于设计偏好，应该理解，过程中的步骤的特定顺序或层次可以在不脱离本公开的保护范围的情况下得到重新安排。所附的方法权利要求以示例性的顺序给出了各种步骤的要素，并且不是要限于所述的特定顺序或层次。
[0053]
在上述的详细描述中，各种特征一起组合在单个的实施方案中，以简化本公开。不应该将这种公开方法解释为反映了这样的意图，即，所要求保护的主题的实施方案需要清楚地在每个权利要求中所陈述的特征更多的特征。相反，如所附的权利要求书所反映的那样，本发明处于比所公开的单个实施方案的全部特征少的状态。因此，所附的权利要求书特此清楚地被并入详细描述中，其中每项权利要求独自作为本发明单独的优选实施方案。
[0054]
本领域技术人员还应当理解，结合本文的实施例描述的各种说明性的逻辑框、模块、电路和算法步骤均可以实现成电子硬件、计算机软件或其组合。为了清楚地说明硬件和软件之间的可交换性，上面对各种说明性的部件、框、模块、电路和步骤均围绕其功能进行了一般地描述。至于这种功能是实现成硬件还是实现成软件，取决于特定的应用和对整个系统所施加的设计约束条件。熟练的技术人员可以针对每个特定应用，以变通的方式实现所描述的功能，但是，这种实现决策不应解释为背离本公开的保护范围。
[0055]
结合本文的实施例所描述的方法或者算法的步骤可直接体现为硬件、由处理器执行的软件模块或其组合。软件模块可以位于ram存储器、闪存、rom存储器、eprom存储器、eeprom存储器、寄存器、硬盘、移动磁盘、cd-rom或者本领域熟知的任何其它形式的存储介质中。一种示例性的存储介质连接至处理器，从而使处理器能够从该存储介质读取信息，且可向该存储介质写入信息。当然，存储介质也可以是处理器的组成部分。处理器和存储介质可以位于asic中。该asic可以位于用户终端中。当然，处理器和存储介质也可以作为分立组件存在于用户终端中。
[0056]
对于软件实现，本申请中描述的技术可用执行本申请所述功能的模块(例如，过
程、函数等)来实现。这些软件代码可以存储在存储器单元并由处理器执行。存储器单元可以实现在处理器内，也可以实现在处理器外，在后一种情况下，它经由各种手段以通信方式耦合到处理器，这些都是本领域中所公知的。
[0057]
上文的描述包括一个或多个实施例的举例。当然，为了描述上述实施例而描述部件或方法的所有可能的结合是不可能的，但是本领域普通技术人员应该认识到，各个实施例可以做进一步的组合和排列。因此，本文中描述的实施例旨在涵盖落入所附权利要求书的保护范围内的所有这样的改变、修改和变型。此外，就说明书或权利要求书中使用的术语“包含”，该词的涵盖方式类似于术语“包括”，就如同“包括，”在权利要求中用作衔接词所解释的那样。此外，使用在权利要求书的说明书中的任何一个术语“或者”是要表示“非排它性的或者”。