CN102364440A - 一种用于建立软件需求模型的系统及建立软件需求模型的方法 - Google Patents
一种用于建立软件需求模型的系统及建立软件需求模型的方法 Download PDFInfo
- Publication number
- CN102364440A CN102364440A CN2011103235537A CN201110323553A CN102364440A CN 102364440 A CN102364440 A CN 102364440A CN 2011103235537 A CN2011103235537 A CN 2011103235537A CN 201110323553 A CN201110323553 A CN 201110323553A CN 102364440 A CN102364440 A CN 102364440A
- Authority
- CN
- China
- Prior art keywords
- viewpoint
- behavior
- scene
- model
- software
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Abstract
本发明涉及一种用于建立软件需求模型的系统及建立软件需求模型的方法，用于建立软件需求模型的系统包括一个独立的或是计算机内部建立的软件需求信息处理器，还有输入设备和输出接口；所述软件需求信息处理器包括：一个软件需求信息单元，一个建立场景单元，一个建立行为模型单元，一个软件需求模型检测、修改和输出单元。建立软件需求模型的方法步骤为：A、输入软件需求信息；B、建立场景；C、建立行为模型；D、检测、修改和输出软件需求模型。本发明优点在于，通过使用场景和视点技术，能够为复杂软件系统的建立高质量的需求模型，自动检测软件系统的需求是否正确和完整，能兼容一些其它的建模方法和技术，还能减少研究成本，提高研究效率。
Description
技术领域
本发明涉及一种用于建立软件需求模型的系统及建立软件需求模型的方法，属于软件开发技术和工具领域。
背景技术
随着计算机应用的不断发展和深入，人们需要收集和处理的信息规模急剧增大，其中计算机软件在信息收集和处理中起着至关重要的作用。由于软件已成为信息基础设施并具备密集型特点，使得软件一方面日益成为人们生活中的一部分，如电子政府、电子商务和手机等，人们也日益依赖软件。另一方面，一些高尖端技术领域，如航空航天、国防军事等领域，对软件的质量提出了很高的要求。然而，软件开发的开发状况和质量远未达到人们的期望和要求，例如大部分软件产品不能在预期计划和预算经费内完成以及软件的质量低下等。虽然产生上述问题的原因有很多，但软件需求问题可以说是其中的一个最大原因，许多的研究已经发现，当软件开发项目失败时，软件需求问题通常正是核心问题。因此，在软件开发过程中，必须极早和有效地发现和解决与软件需求相关的问题。
需求建模在软件需求分析中是十分重要的工作。需求建模主要是根据待开发软件系统的需求利用某种建模方法建立该系统的逻辑模型（也称需求模型），以明确待开发软件系统“做什么”的问题。所谓模型就是为了理解事物而对事物做出的一种抽象，是对事物的一种无歧义的书面描述。软件需求模型则是对软件系统需求的抽象描述，并由文本、图形符号或数学符号以及组织这些符号的规则形成。在软件的实际开发中，为了更好地理解需求，特别是复杂的软件系统的需求，软件开发人员应从不同的角度分析待开发软件系统的需求信息，使用精确的方法构造系统的模型，验证模型是否满足用户的需求，并在设计过程中逐渐把与实现相关的细节加进模型，直至最终用程序实现模型。对于相当复杂而又难于理解的系统，特别需要进行需求建模。
为了建立软件系统的需求模型，软件开发人员使用了许多的建模方法。在目前的需求建模方法中，需求建模方法大部分是用图形符号来描述需求模型，如统一建模语言（UML：Unified Modeling Language）等。虽然图形的含义比较直观和易理解，但其只能是一种半形式化的方法，缺乏严格的语义，并且存在随意性等问题。另一方面，形式化的需求建模方法主要用严格的数学知识和符号来构造系统的需求模型，使得需求模型更加严密、无二义性和易于推理。但不足之处是概念符号过于抽象，需要具有较好的数学基础和严格地专门训练后才能掌握和使用，而且可能会增加软件开发费用。作为形式化需求描述语言的典型代表作有Z方法和B方法等。因此，在上述需求建模方法的基础上有必要研究和实现将文本表示的需求和由图形或数学符号表示的需求模型结合起来，建立待开发软件系统的需求模型，以检测其需求中存在的问题。
发明内容
本发明目的是针对现有技术的不足，提供一种用于建立软件需求模型的系统及建立软件需求模型的方法。通过使用场景和视点技术，能够为复杂软件系统建立高质量的需求模型，为自动检测软件系统的需求是否正确和完整奠定了良好的基础，而且能够兼容一些其它的建模方法和技术，能通过需求模型分析和检测软件需求中存在的问题，从而降低待开发的复杂软件需求建模的难度，减少研究成本，提高研究效率，最终获得高质量的软件，实现软件开发的最佳技术和经济的综合效益。
本发明的用于建立软件需求模型的系统技术方案是：
一种用于建立软件需求模型的系统，它包括一个独立的或是计算机内部建立的软件需求信息处理器，还有输入设备和输出接口；所述软件需求信息处理器包括：
一个软件需求信息单元：用于存储和确定待开发软件的问题域的边界和范围，包括问题子单元，视点子单元和场景子单元；视点子单元有视点模板，该视点模板用于规定视点的描述内容，且一个视点模板由若干信息槽组成；所述视点是根据问题域进行标识和定义，视点是一个视点源根据其关注点和问题域而提出的需求信息的集合；
一个场景建立单元：用于根据对每一个与待开发软件系统相关的视点建立视点场景；
一个行为模型建立单元：所述行为模型包括视点行为模型和场景行为模型；用于分析有效行为间的执行关系，将所得的所有有效行为按其间的执行关系构成有序的行为系列，从而构建出视点中的场景；所述执行关系为顺序、并行、确定选择或非确定选择；视点中的每一个场景，用行为描述语言将其中的每个有效行为描述为原子行为，最终构成场景行为模型；视点行为模型由若干场景行为模型联接而成，所有视点行为模型构成初始的软件需求模型；
一个软件需求模型检测、修改和输出单元：用于检测、修改每个视点中所有场景的原子行为定义的正确性和检测场景行为表达式的合法性，以及场景内所有原子行为之间的连续性和同一视点内场景行为模型间行为输入/出的一致性；综合所有视点行为模型得到最终的软件需求模型并输出。
在上述技术方案基础上更进一步的技术方案是：
所述用于建立软件需求模型的系统，所述原子行为，即设某个场景中包含n个有效行为，描述所得n个原子行为表达为：
原子行为标识1： 原子行为定义1；
原子行为标识2： 原子行为定义2；
……
原子行为标识n： 原子行为定义n；
所述用于建立软件需求模型的系统，所述场景行为模型，即设某个场景中包含n个有效行为，场景行为表达式＝ 场景中所有的n个原子行为及其原子行为间的关系。
所述用于建立软件需求模型的系统，其信息槽记录的是与视点相关的基本信息，包括视点名称、视点创建时间和用户名，以及记录与该视点相关的用户需求信息，包括用自然语言描述的该视点中的需求和场景、用行为描述语言描述的视点行为模型和该视点内所有场景行为模型。
所述用于建立软件需求模型的系统，所述软件需求模型为M：
M＝（V，R0，R1，R2）
其中V表示与待开发软件系统相关的视点的集合，且V中每个视点对应一个视点行为模型，R0、R1、R2分别表示V中视点间的重叠、顺序和无关关系；视点行为模型表示为M1 = （B，+，If，||，;）,
其中B表示视点内所有场景行为表达式的集合； +，If，||，; 分别表示B中场景间的非确定、确定选择、并行和顺序关系。
所述用于建立软件需求模型的系统，所述输入设备为计算机键盘，和/或外接输入设备；外接输入设备选自联网计算机，和/或通讯设备，和/或声、像设备。
本发明一种使用上述任何一个用于建立软件需求模型的系统来建立软件需求模型的方法的技术方案，它包括下述步骤：
A、输入软件需求信息：
向软件需求信息单元输入软件需求信息，具体步骤如下：
A1、依据用户的需求分析并确定出问题域中存在的需求源作为视点源；
A2、确定每个视点源对问题域的关注点；
A3、根据关注点输入并创建视点；
B、建立场景：
通过场景建立单元建立场景，即为步骤A中定义的每一个与待开发软件相关的视点建立视点场景，具体步骤如下：
B1、提取用户用自然语言描述的需求并收录到视点中，分析用自然语言描述的需求，确定其中的所有动作和动作的主客体，然后将动作及相应的主客体一起视为待开发软件需求系统中的行为；
B2、分析步骤B1所得的所有行为，通过计算机从中筛选出与待开发软件系统密切相关的有效行为；
B3、分析有效行为间的执行关系，执行关系为顺序、并行、确定选择或非确定选择；
B4、将步骤B2所得的所有有效行为按其间的执行关系构成有序的行为系列，从而构建出视点场景；
C、建立行为模型：
通过行为模型建立单元 建立与确认有效行为，建立行为模型，具体步骤如下：
C1、对于视点中的每一个场景，用行为描述语言将其中的每个有效行为描述为原子行为；
C2、根据场景中有效行为间的关系，用行为描述语言将场景中所有原子行为联接成场景行为表达式，从而构成场景行为模型；即设某个场景中包含n个有效行为，场景行为表达式＝场景中所有的n个原子行为及其原子行为间的关系；
C3、对于每一个视点，根据视点中所有场景间的关系，将视点中所有场景行为模型联结成视点行为表达式，从而构成视点行为模型，视点行为表达式＝视点中所有场景行为表达式及其场景间的关系；所有视点行为模型构成初始的软件需求模型；
本步骤中不采用自然语言，而利用行为描述语言（BDL，Behaviors Description Language）表达行为模型；行为描述语言对行为、场景到视点的描述表达都给出了表现形式，即设某个场景中包含n个有效行为，描述所得n个原子行为表达为：
原子行为标识1： 原子行为定义1；
原子行为标识2： 原子行为定义2；
……
原子行为标识n： 原子行为定义n；
场景行为表达式 =场景中所有的n个原子行为及其原子行为间的关系；
视点行为表达式 =视点中所有场景行为表达式及其场景间的关系；
D、检测、修改和输出软件需求模型：
通过软件需求模型检测、修改和输出单元检测、修改和输出软件需求模型，具体步骤如下：
D1、检测每个视点中所有场景的原子行为定义的正确性；
D2、检测场景行为表达式的合法性，以及场景内所有原子行为之间的连续性和同一视点内场景行为模型间行为输入/输出的一致性；
D3、检测每个视点行为表达式的合法性和所有视点行为模型间行为输入/输出的一致性；
D4 、显示检测结果；若检测结果为发现问题则修改相应的场景行为模型或视点行为模型，并返回重复步骤D1～步骤D3的检测，直到每个视点都检测结果通过；若检测结果为通过，则综合所有视点行为模型得到最终的软件需求模型并通过输出接口输出。
在上述建立软件需求模型的方法技术方案的基础上更进一步技术方案是：
所述建立软件需求模型的方法，在进行步骤A时，根据问题域的逻辑特性和问题域内部各成分间的逻辑关系，将问题域划分成一个以上子问题域；步骤A2中，每个视点源对问题域的关注点包括每个视点源对所有子问题域的关注点。
所述建立软件需求模型的方法，在步骤A3中创建视点是以视点模板的形式实现；视点模板规定了视点的描述内容，且一个视点模板由若干信息槽组成；这些信息槽用于记录与该视点相关的基本信息，还记录与该视点相关的用户需求信息，包括用自然语言描述的该视点中的需求和场景、用行为描述语言描述的视点行为模型和该视点内所有场景行为模型。
本发明具有以下主要的显著有益效果：
其一.针对软件系统的特点，本方法使用场景和视点技术，提供适合于复杂软件系统的需求建模技术方案。并且通过划分子问题域，进一步降低复杂软件系统需求建模难度。
其二.本方法能将用户使用自然语言表达的需求转化为场景及行为表达式，从而能实现从自然语言到半形式化，然后到形式化的需求描述，为自动检测软件系统的需求是否正确和完整奠定了良好的基础。
其三.软件行为的正确与否决定了软件能否满足用户需求，并且软件系统的特性如可信特性也是通过软件行为来验证的。在需求分析阶段通过分析待开发软件的需求信息和行为，并建立严格地描述基于软件行为的需求模型，这将有助于检测待开发软件的许多特性。
其四.本方法所提供的行为描述语言可用于表达一些其他建模技术和符号，如状态图、工作流图和数据流图等一些半形式化的、基于图形的需求建模技术。通过转换工具自动转化为用行为描述语言描述的形式化需求模型。使得本方法能兼容一些其它的建模方法和技术，从而具有较好的广泛性和实用性。
其五.软件行为有利于从形式化的角度建立和检测软件需求模型，从而获得高质量的软件需求。
附图说明
图1 为本发明用于建立软件需求模型的系统结构框图；
图2 为使用本发明的用于建立软件需求模型的系统来建立软件需求模型的方法流程图；
图3 为本发明具体实施例的示意图。
具体实施方式
结合附图和实施例对本发明用于建立软件需求模型的系统作进一步说明如下：
实施例1：
如图1所示，一种用于建立软件需求模型的系统，它包括一个独立的或是计算机1内部建立的软件需求信息处理器2，还有输入设备3和输出接口4；图1所示本实施例软件需求信息处理器2是与计算机1相联接的外接的软件需求信息处理器2；还有实施例的软件需求信息处理器2是在计算机1的存储器及处理器空间中建立的软件需求信息处理器；输入设备3是计算机1的键盘，和/或外接输入设备；外接输入设备选自联网计算机，和/或通讯设备，和/或声、像设备；本实施例输入设备3是计算机1的键盘和联网计算机；所述软件需求信息处理器2包括：
一个软件需求信息单元2.1：用于存储和确定待开发软件的问题域的边界和范围，包括问题子单元2.11，视点子单元2.12和场景子单元2.13；视点子单元2.12有视点模板，该视点模板用于规定视点的描述内容，且一个视点模板由若干信息槽组成；所述视点是根据问题域进行标识和定义，视点是一个视点源根据其关注点和问题域而提出的需求信息的集合；
一个场景建立单元2.2：用于根据对每一个与待开发软件系统相关的视点建立视点场景；
一个行为模型建立单元2.3：所述行为模型包括视点行为模型和场景行为模型；用于分析有效行为间的执行关系，将所得的所有有效行为按其间的执行关系构成有序的行为系列，从而构建出视点中的场景；所述执行关系为顺序、并行、确定选择或非确定选择；视点中的每一个场景，用行为描述语言将其中的每个有效行为描述为原子行为，最终构成场景行为模型；视点行为模型由若干场景行为模型联接而成，所有视点行为模型构成初始的软件需求模型；
一个软件需求模型检测、修改和输出单元2.4：用于检测、修改每个视点中所有场景的原子行为定义的正确性和检测场景行为表达式的合法性，以及场景内所有原子行为之间的连续性和同一视点内场景行为模型间行为输入/出的一致性；综合所有视点行为模型得到最终的软件需求模型并输出。
所述原子行为，即设某个场景中包含n个有效行为，描述所得n个原子行为表达为：
原子行为标识1： 原子行为定义1；
原子行为标识2： 原子行为定义2；
……
原子行为标识n： 原子行为定义n；
所述场景行为模型即：设某个场景中包含n个有效行为，场景行为表达式＝ 场景中所有的n个原子行为及其原子行为间的关系。
所述信息槽记录的是与视点相关的基本信息，包括视点名称、视点创建时间和用户名，以及记录与该视点相关的用户需求信息，包括用自然语言描述的该视点中的需求和场景、用行为描述语言描述的视点行为模型和该视点内所有场景行为模型。
所述软件需求模型为M：
M＝（V，R0，R1，R2）
其中V表示与待开发软件系统相关的视点的集合，且V中每个视点对应一个视点行为模型，R0、R1、R2分别表示V中视点间的重叠、顺序和无关关系；视点行为模型表示为M1 = （B，+，If，||，;）,
其中B表示视点内所有场景行为表达式的集合； +，If，||，; 分别表示B中场景间的非确定、确定选择、并行和顺序关系。
所述输入设备3为计算机键盘，和/或联网计算机，和/或通讯设备，和/或声、像设备；本实施例输入设备3为计算机键盘和联网计算机。
结合附图和实施例对使用本发明用于建立软件需求模型的系统来建立软件需求模型的方法作进一步说明如下：
实施例2：
如图2所示，使用本发明用于建立软件需求模型的系统来建立软件需求模型的方法，其步骤为：
A、输入软件需求信息：
通过输入设备3向软件需求信息单元2.1输入软件需求信息，具体步骤如下：
A1、依据用户的需求分析并确定出问题域中存在的需求源作为视点源；
A2、确定每个视点源对问题域的关注点；
A3、根据关注点输入并创建视点；
所谓问题域是指与问题相关的部分现实世界。所谓视点是一个视点源根据其关注点和某个问题域而提出的需求信息的集合。根据相应的问题域，从中找出所有的视点源及其关注点，并将它们标识为视点。对于复杂的待开发软件系统，直接从其中标识视点可能有些困难，本发明提出进一步技术方案，首先根据问题域的逻辑特性和问题域内部各成分间的逻辑关系，将复杂的问题域分解为多个子问题域，然后根据视点源确定在每个子问题上的关注点，每个视点源对问题域的关注点包括每个视点源对所有子问题域的关注点。可见本发明特别适合于对较复杂和规模较大的软件系统实现需求建模。待开发软件系统并不很复杂时，则无需进行子问题域划分。
具体实施时可以采用视点模板形式：视点模板规定了视点的描述内容，且一个视点模板由多个信息槽组成；这些信息槽不仅用于记录与该视点相关的基本信息，包括视点名称、视点创建时间和用户名，而且也用于记录与该视点相关的用户需求信息，包括用自然语言描述的该视点中的需求和场景、用行为描述语言描述的视点行为模型和该视点内所有场景行为模型。创建视点后，即为该视点生成视点模板，然后可以由计算机自动生成或者人工编写填入视点基本信息；用户需求信息中，自然语言描述的需求可以从客户提供的需求文本中直接提取或者人工输入，视点模板中在后续步骤得到其它相关信息是以自然语言描述的需求为原始依据，并可自动或半自动填入模板，例如执行步骤B4后得到自然语言描述的场景。模板化处理视点可以方便管理和修改。本发明提供了实施例的视点模板所含信息槽列表如下：
| 信息槽 | 详细说明 |
| 创建时间 | 标识视点是何时创建的 |
| 最近修改时间 | 标识视点最后一次的修改时间 |
| 标识视点 | 唯一标识一个视点的符号 |
| 视点名称 | 标识视点的名字 |
| 视点责任人 | 视点需求的责任人 |
| 问题域 | 视点所属的问题域。 |
| 视点源 | 视点中需求的来源。可把视点源限制为三种类型：人，其他软件系统和外部硬件设备等 |
| 关注点 | 视点在其所属问题域中所关注的方面 |
| 需求描述 | 视点中需求的自然语言的描述 |
| 场景描述 | 视点中场景的自然语言的描述 |
| 相关视点 | 与本视点有关联的其它视点 |
| 行为模型 | 以行为描述语言描述的行为模型 |
| 其他模型 | 其它建模方法的描述 |
B、建立场景：
通过场景建立单元2.2建立场景，即为步骤A中定义的每一个与待开发软件相关的视点建立视点场景，具体步骤如下：
B1、提取用户用自然语言描述的需求并收录到视点中，分析用自然语言描述的需求，确定其中的所有动作和动作的主客体，然后将动作及相应的主客体一起视为待开发软件需求系统中的行为；
B2、分析步骤B1所得的所有行为，通过计算机 1从中筛选出与待开发软件系统密切相关的有效行为；
B3、分析有效行为间的执行关系，执行关系为顺序、并行、确定选择或非确定选择；
B4、将步骤B2所得的所有有效行为按其间的执行关系构成有序的行为系列，从而构建出视点场景；
一个场景是软件系统的用户能感受到的软件系统的一个完整功能；通过分析视点中用自然语言描述的需求，并从中归纳出场景的描述内容。因为视点中用自然语言描述需求，因此场景的描述也主要用自然语言。本发明利用场景技术实现从自然语言描述的用户需求到形式化的系统需求模型的过渡，使得该方法易于使用。
C、建立行为模型：
通过行为模型建立单元2.3建立与确认有效行为，建立行为模型，具体步骤如下：
C1、对于视点中的每一个场景，用行为描述语言将其中的每个有效行为描述为原子行为；
C2、根据场景中有效行为间的关系，用行为描述语言将场景中所有原子行为联接成场景行为表达式，从而构成场景行为模型；即设某个场景中包含n个有效行为，场景行为表达式＝场景中所有的n个原子行为及其原子行为间的关系；
C3、对于每一个视点，根据视点中所有场景间的关系，将视点中所有场景行为模型联结成视点行为表达式，从而构成视点行为模型，视点行为表达式＝视点中所有场景行为表达式及其场景间的关系；所有视点行为模型构成初始的软件需求模型；
该步骤中不采用自然语言，而利用行为描述语言（BDL，Behaviors Description Language）表达行为模型。本发明采用行为描述语言这种形式化语言作为描述手段之一，其主要用于严格地描述待开发软件系统的行为模型，可以为以后自动检验待开发软件系统的各种特性奠定良好的基础；行为描述语言对行为、场景到视点的描述表达都给出了严格的表现形式，即设某个场景中包含n个有效行为，描述所得n个原子行为表达为：
原子行为标识1： 原子行为定义1；
原子行为标识2： 原子行为定义2；
……
原子行为标识n： 原子行为定义n；
场景行为表达式 =场景中所有的n个原子行为及其原子行为间的关系；
视点行为表达式 =视点中所有场景行为表达式及其场景间的关系。
具体实施时，按照这种确定的行为描述语言语法，计算机可以自动完成从自然语言描述的需求到建立初始系统需求模型的全过程，然后通过修改和检测最终形成正确的系统需求模型。
为了便于管理，本发明进一步提供了模型表达方式：系统行为模型可以表示为 M =（V，R0，R1，R2），其中V表示与待开发软件系统相关的视点的集合，且V中每个视点对应一个视点行为模型，R0、R1、R2分别表示V中视点间的重叠、顺序和无关关系；视点行为模型表示为M1 = （B，+，If，||，;）,其中B表示视点内所有场景行为表达式的集合。 +，If，||，; 分别表示B中场景间的非确定、确定选择、并行和顺序关系；这种形式化表示，可以保证视点行为模型和系统行为模型在表达方面的正确性，以及防止视点间需求信息可能会发生重叠从而导致行为模型间出现行为冲突和不一致；
本发明还提供了实施例在此步骤形成的行为描述语言文本以供参考：
令ABehID为原子行为标识，BehID为行为标识。
（1）原子行为：
1)原子行为表达式：
ABehID：f（ sub ，obj)
[When 前置条件]
[INFrom ( ID )（u1,…..,un)]
[ OUTTo ( ID )（v1,…..,vm) ].
其中：f为主体sub施用于客体obj的服务、操作或动作。When，INFrom和OUTTo分别为行为执行的前置条件，行为的输入和输出。
2）空动作： ABehID： Idel.
3）复合行为结束动作： ABehID：Return (ABehID ) 或Return ( ).
其中：Return ( ) 表示正常退出系统。
（2）简单行为： |— ABehID; （原子行为构成简单行为）
（3）复合行为：
1） 顺序行为： （a） 
(b) 
2）未确定选择行为： 
3）确定选择行为： 
4）并行行为： 
（4）系统行为模型的结构如下：
系统名：
视点ID1的行为模型；
……..
视点IDn的行为模型。
（5） 视点行为模型的结构如下：
视点ID：
VPBEGIN
[视点内共享数据存储池ID；]
场景ID1 的行为模型
……..
场景IDn的行为模型
VPBehID = 视点行为表达式
= 场景的BehID 场景间关系符 场景的BehID [场景间关系符 场景的BehID ……]
VPEND
（6）场景行为模型的结构如下：
场景ID [，场景ID]： （符号“[ ]”表示其中的内容是可选的）
BEGIN
[ ABEH：:
ABehID:：原子行为1；
……..
ABehID:：原子行为n；]
BEH：
BehID = 场景行为表达式；
[BehID = 子行为表达式1 ]；
…….
[BehID = 子行为表达式m ]；
END
D、检测、修改和输出软件需求模型：
为保证视点行为模型和场景行为模型符合行为描述语言的语法，以及为以后检验软件系统的需求奠定基础，有必要从语法的角度检测所有的视点行为模型和场景行为模型，从而检测视点内行为表达式的合法性，也就是检测是否符合步骤C所用的规定表达方式。并且检测行为连续性、行为间输入/出的一致性。通过循环检测修改，保证所有视点行为模型正确后，才得最终软件需求模型；
通过软件需求模型检测、修改和输出单元2.4检测、修改和输出软件需求模型，具体步骤如下：
D1、检测每个视点中所有场景的原子行为定义的正确性；
D2、检测场景行为表达式的合法性，以及场景内所有原子行为之间的连续性和同一视点内场景行为模型间行为输入/输出的一致性；
D3、检测每个视点行为表达式的合法性和所有视点行为模型间行为输入/输出的一致性；
D4 、显示检测结果；若检测结果为发现问题则修改相应的场景行为模型或视点行为模型，并返回重复步骤D1～步骤D3的检测，直到每个视点都检测结果通过；若检测结果为通过，则综合所有视点行为模型得到最终的软件需求模型并通过输出接口2.4输出。
在进行步骤A时，根据问题域的逻辑特性和问题域内部各成分间的逻辑关系，将问题域划分成一个以上子问题域；步骤A2中，每个视点源对问题域的关注点包括每个视点源对所有子问题域的关注点。在步骤A3中创建视点是以视点模板的形式实现；视点模板规定了视点的描述内容，且一个视点模板由若干信息槽组成；这些信息槽用于记录与该视点相关的基本信息，还记录与该视点相关的用户需求信息，包括用自然语言描述的该视点中的需求和场景、用行为描述语言描述的视点行为模型和该视点内所有场景行为模型。
实施例3：
本发明应用广泛，为了便于本领域技术人员更清晰地理解本发明技术方案，在此选择了一个具体实例应用方式进行详细说明：
如图3所示，采用本发明对银行自动取款机系统（ATM）建立需求模型。关于ATM系统的需求用自然语言陈述如下：
（a）某银行拟开发一个自动取款机系统，它是一个由ATM、中央计算机、分行计算机及柜员终端组成的网络系统。ATM和中央计算机由总行投资购买。总行拥有多台ATM，分别设在全市各主要街道上。分行负责提供分行计算机和柜员终端。柜员终端设在分行营业厅及分行下属的各个储蓄所内。该系统的软件开发成本由各个分行分摊。
（b）银行柜员使用柜员终端处理储户提交的储蓄事务。柜员负责把储户提交的存款或取款事务输进柜员终端，接收储户交来的现金或支票，或付给储户现金。柜员终端与相应的分行计算机通信，分行计算机具体处理针对某个账户的事务并且维护账户。
（c）储户可以用现金或支票向自己拥有的某个账户内存款或开设新账户。储户也可以从自己拥有的账户取款。通常，一个储户可能拥有多个账户。拥有银行账户的储户有权申请领取银行卡。使用银行卡可以通过ATM访问自己的账户，或用银行卡在ATM上提取现金（即取款），或查询有关自己账户的信息（例如，某个指定账户上的余额）。
（d）所谓银行卡就是一张特制的磁卡，上面有分行代码和卡号。分行代码唯一标识总行下属的一个分行，卡号确定了这张卡可以访问哪些账户。每张银行卡仅属于一个储户所有，但同一张卡可能有多个副本。因此，必须考虑同时在若干台ATM上使用同样的银行卡的可能性。也就是说，系统应该能够处理并发的访问。
（e）当用户把银行卡插入ATM之后，ATM就与用户交互，以获取有关这次事务的信息，并与中央计算机交换关于事务的信息。首先，ATM要求用户输入密码，接下来ATM把从这张卡上读到的信息以及用户输入的密码传给中央计算机，请求中央计算机核对这些信息并处理这次事务。中央计算机根据卡上的分行代码确定这次事务与分行的对应关系，并且委托相应的分行计算机验证用户密码。如果用户输入的密码是正确的，ATM就要求用户选择事务类型（取款、查询等）。当用户选择取款时，ATM请求用户输入取款额。最后，ATM从现金出口吐出现金，并且打印出账单交给用户。
该实例的需求建模过程如下：
1、划分问题域：
明确了ATM系统的范围和边界后，将该系统划分成3个子问题域，即总行，ATM机和分行。
2、标识视点：
根据以上划分出的子问题域，首先分析并确定出这些子问题域中存在的需求源即视点源和每个视点源对子问题域的关注点。在本实例中，可针对以上3个子问题域各自建立1个视点，并生成如图2所示的视点模板。然后，在各自的视点模板中填写相应的视点基本信息：视点名称，视点标识、视点责任人，相关的子问题域，关注点，视点源和视点创建时间。
3、描述用自然语言表达的需求：
对于已标识出的视点，在各自视点模板的槽“需求描述”中填入用自然语言表达的用户需求，即用文字表达的（a）～（e）部分。
4、建立场景：
在本实例中，场景是指在各视点的范围内按顺序描述用自然语言表达的需求中出现的一系列行为。建立场景的简单方法是首先从自然语言描述的需求中提取出描述场景的动作和主客体，即可根据自然语言描述中主+谓+宾结构得出组成场景的动作和动作的主客体，例如“用户输入密码”、“用户选择事务”等等。然后，再提取某些隐含的动作，得出组成场景的动作，例如，“分行请总行验证”，从中可以提取出隐含动作“发送验证请求”等。最后将各视点内的所有的动作按执行时间的顺序排列，以形成各视点内的场景。一个视点可拥有多个场景。以下是ATM系统3个视点中的场景：
1）ATM视点中的场景：
ATM在显示屏上显示问候信息：
顾客将磁卡插入ATM；
ATM读出磁卡上的代码，并检索该卡能否使用；
如果磁卡能使用，ATM要求顾客输入密码。
ATM等待密码输入；
顾客输入密码；
ATM请求中央计算机核对信息
如果密码正确，ＡＴＭ请求顾客选择事务处理类型。
ATM等待输入事务类型；
顾客选择取现金事务，并输入取出的数量；
ATM请求中央计算机处理事务；
ATM与中央计算机交换关于事务的信息；
ATM做好取现金的准备，
ATM吐出相应的纸币；
ATM向顾客返还磁卡。
ATM打印并输出收付款说明书。
2）总行视点中的场景：
总行拥有多台ATM
总行由各个分行组成
总行拥有中央计算机
中央计算机接受卡的信息
中央计算机根据卡上的分行代码确定这次事务与分行的对应关系
中央计算机委托相应的分行计算机验证用户密码
中央计算机接受事务处理类型
中央计算机委托相应的分行处理事务
3）分行视点中的场景 （由分行场景和柜员终端场景组成）：
a) 分行场景：
分行负责提供分行计算机和柜员终端
分行计算机维护账户
分行接受用户密码
分行计算机验证用户密码
分行接受事务处理类型
分行计算机处理针对某个账户的事务
b)柜员终端场景：
柜员终端接受用户请求
用户请求柜员终端建立新账户
用户请求柜员终端建立新卡
用户请求柜员终端建立处理事务（如存取款，查询等）
柜员终端与相应的分行计算机通信
柜员终端从分行计算机获取各种处理信息；
柜员终端处理各种请求
柜员终端向用户提交处理后的结果
所有建立的场景均被填写入相应视点模板的槽“ 场景描述”中。
5、用行为描述语言建立视点行为模型：
对于每一个视点，可根据视点中已建立的场景用行为描述语言建立视点行为模型。例如，总行视点的行为模型可表示如下：
HeadBank： //总行场景
VPBEGIN
ABEH:
Hbank1: 拥有（总行，多台ATM）
Hbank2: 组成（多个分行，总行）
Hidel : idel() ; //idel 一直等待ATM请求或分行回答
//总行接收ATM请求或分行回答
Hreceive: 响应（总行，ATM请求或分行回答）
OUTTo (VPdatacell) (响应类型)
//接收ATM验证请求
Hresponse: 接收（总行，ATM）
OUTTo (VPdatacell) (ATM号)
//中央计算机接收第i个ATM传来的卡信息和密码
Hreceive1: 接收（总行，第i个ATM）
When ATM号= i
INFrom (VPdatacell) (卡信息, 密码)
//根据卡信息,判断分行号
Discern: 判断（中央计算机， 卡信息）
OUTTo(VPdatacell) (分行号(值));
//*中央计算机将卡信息、密码及验证卡信息请求发送给相应分行验证；
TranRequest1：传递（总行，第j个分行）
When 分行号= j
INFrom (VPdatacell) (分行号)
OUTTo (#LocalBank) (卡信息, 密码)
//中央计算机接收第j个分行传来的验证结果
RecRespon1: 接收（总行，第j个分行）
When 分行号= j
INFrom (VPdatacell) (验证结果);
//*中央计算机将验证结果发送到ATM机
Tranresult1: 传递（总行，第i个ATM）
When ATM号= i and分行号= j
INFrom (VPdatacell) (ATM号, 分行号)
OUTTo (#ATM) (验证结果);
//*中央计算机接收ATM传来的事务请求
Hreceive2: 接收（总行，第i个ATM）
When ATM号= i
INFrom (VPdatacell) (事务类型，事务信息)
TranRequest2：传递（总行，第j个分行）
When 分行号= j
INFrom (VPdatacell) (分行号)
OUTTo (#LocalBank) (卡信息,事务类型，事务信息)；
//中央计算机将分行答复发送到ATM机
RecRespon2: 接收（总行，第j个分行）
When 分行号= j
INFrom (VPdatacell) (事务处理结果);
//*中央计算机将返回结果发送到ATM机
Tranresult2: 传递（总行，第i个ATM）
When ATM号= i and分行号= j
INFrom (VPdatacell) (ATM号, 分行号)
OUTTo (#ATM) (事务处理结果);
Returnto: Return(Hidel);
BEH:
BEHHeadBank =
Hbank1;
Hbank2;
Hidel;
If响应类型 = ATM请求
Then Behhbank1;
Else Behhbank2;
Fi
Returnto；
Behhbank1=
Hresponse；
If 验证请求
Then Hreceive1；
Discern；
TranRequest1；
Else //中央计算机接收ATM传来的事务请求
Hreceive2；
TranRequest2；
Fi；
Behhbank2=
If 回答验证请求
Then //中央计算机将验证结果发送到ATM机
RecRespon1；
Tranresult1；
Else //中央计算机将分行答复发送到ATM机
RecRespon2；
Tranresult2；
Fi；
VPEND
（ATM机和分行的视点行为模型与总行类似，从略）
所有建立的视点行为模型均被填写入相应视点模板的槽“行为模型”中。
6、检测所有的视点
此步主要是根据行为描述语言的语法检测在第五步中建立的3个视点行为模型，以保证各视点内所有行为表达的合法性。由于每个场景行为模型和视点行为模型分别对应于一个行为表达式，故首先需要检测视点内所有原子行为表达的合法性。然后，在所有原子行为表达的合法性检测已通过的基础之上，进一步检测各视点内多个原子行为和多个场景间输入和输出的表达一致性，以及场景行为表达式和视点行为表达式表达的合法性。最后，检测3个视点间输入和输出的表达一致性。
7、形成系统的行为模型，即系统需求模型
当3个视点被检测通过后，按行为描述语言文本的第（4）部分规定的系统行为模型的结构将所有的视点行为模型综合到一起，最终可形成ATM系统的系统需求模型。此后，可依据ATM系统的系统需求模型使用不同的检测方法检测ATM系统的特性，如系统的可信性，需求的一致性和系统的安全性等。
本发明权利要求保护范围不限于上述实施例。
Claims (9)
1.一种用于建立软件需求模型的系统，其特征在于，它包括一个独立的或是计算机内部建立的软件需求信息处理器，还有输入设备和输出接口；所述软件需求信息处理器包括：
一个软件需求信息单元：用于存储和确定待开发软件的问题域的边界和范围，包括问题子单元，视点子单元和场景子单元；视点子单元有视点模板，该视点模板用于规定视点的描述内容，且一个视点模板由若干信息槽组成；所述视点是根据问题域进行标识和定义，视点是一个视点源根据其关注点和问题域而提出的需求信息的集合；
一个场景建立单元：用于根据对每一个与待开发软件系统相关的视点建立视点场景；
一个行为模型建立单元：所述行为模型包括视点行为模型和场景行为模型；用于分析有效行为间的执行关系，将所得的所有有效行为按其间的执行关系构成有序的行为系列，从而构建出视点中的场景；所述执行关系为顺序、并行、确定选择或非确定选择；视点中的每一个场景，用行为描述语言将其中的每个有效行为描述为原子行为，最终构成场景行为模型；视点行为模型由若干场景行为模型联接而成，所有视点行为模型构成初始的软件需求模型；
一个软件需求模型检测、修改和输出单元：用于检测、修改每个视点中所有场景的原子行为定义的正确性和检测场景行为表达式的合法性，以及场景内所有原子行为之间的连续性和同一视点内场景行为模型间行为输入/出的一致性；综合所有视点行为模型得到最终的软件需求模型并输出。
2.根据权利要求1所述用于建立软件需求模型的系统，其特征在于，所述原子行为，即设某个场景中包含n个有效行为，描述所得n个原子行为表达为：
原子行为标识1： 原子行为定义1；
原子行为标识2： 原子行为定义2；
……
原子行为标识n： 原子行为定义n。
3.根据权利要求1或2所述用于建立待开发软件需求模型的系统，其特征在于，所述场景行为模型，即设某个场景中包含n个有效行为，场景行为表达式＝ 场景中所有的n个原子行为及其原子行为间的关系。
4.根据权利要求1所述用于建立软件需求模型的系统，其特征在于，信息槽记录的是与视点相关的基本信息，包括视点名称、视点创建时间和用户名，以及记录与该视点相关的用户需求信息，包括用自然语言描述的该视点中的需求和场景、用行为描述语言描述的视点行为模型和该视点内所有场景行为模型。
5.根据权利要求1所述用于建立软件需求模型的系统，其特征在于，所述软件需求模型为M：
M＝（V，R0，R1，R2）
其中V表示与待开发软件系统相关的视点的集合，且V中每个视点对应一个视点行为模型，R0、R1、R2分别表示V中视点间的重叠、顺序和无关关系；视点行为模型表示为M1 = （B，+，If，||，;）,其中B表示视点内所有场景行为表达式的集合，+，If，||，; 分别表示B中场景间的非确定、确定选择、并行和顺序关系。
6.根据权利要求1所述用于建立软件需求模型的系统，其特征在于，所述输入设备为计算机键盘，和/或外接输入设备；外接输入设备选自联网计算机，和/或通讯设备，和/或声、像设备。
7.一种使用上述任何一个权利要求所述的用于建立软件需求模型的系统来建立软件需求模型的方法，其特征在于，它包括下述步骤：
A、输入软件需求信息：
通过输入设备向软件需求信息单元输入软件需求信息，具体步骤如下：
A1、依据用户的需求分析并确定出问题域中存在的需求源作为视点源；
A2、确定每个视点源对问题域的关注点；
A3、根据关注点输入并创建视点；
B、建立场景：
通过场景建立单元建立场景，即为步骤A中定义的每一个与待开发软件相关的视点建立视点场景，具体步骤如下：
B1、提取用户用自然语言描述的需求并收录到视点中，分析用自然语言描述的需求，确定其中的所有动作和动作的主客体，然后将动作及相应的主客体一起视为待开发软件需求系统中的行为；
B2、分析步骤B1所得的所有行为，通过计算机从中筛选出与待开发软件系统密切相关的有效行为；
B3、分析有效行为间的执行关系，执行关系为顺序、并行、确定选择或非确定选择；
B4、将步骤B2所得的所有有效行为按其间的执行关系构成有序的行为系列，从而构建出视点场景；
C、建立行为模型：
通过行为模型建立单元建立与确认有效行为，建立行为模型，具体步骤如下：
C1、对于视点中的每一个场景，用行为描述语言将其中的每个有效行为描述为原子行为；
C2、根据场景中有效行为间的关系，用行为描述语言将场景中所有原子行为联接成场景行为表达式，从而构成场景行为模型；即设某个场景中包含n个有效行为，场景行为表达式＝场景中所有的n个原子行为及其原子行为间的关系；
C3、对于每一个视点，根据视点中所有场景间的关系，将视点中所有场景行为模型联结成视点行为表达式，从而构成视点行为模型，视点行为表达式＝视点中所有场景行为表达式及其场景间的关系；所有视点行为模型构成初始的软件需求模型；
本步骤中不采用自然语言，而利用行为描述语言（BDL，Behaviors Description Language）表达行为模型；行为描述语言对行为、场景到视点的描述表达都给出了表现形式，即设某个场景中包含n个有效行为，描述所得n个原子行为表达为：
原子行为标识1： 原子行为定义1；
原子行为标识2： 原子行为定义2；
……
原子行为标识n： 原子行为定义n；
场景行为表达式 =场景中所有的n个原子行为及其原子行为间的关系；
视点行为表达式 =视点中所有场景行为表达式及其场景间的关系；
D、检测、修改和输出软件需求模型：
通过软件需求模型检测、修改和输出单元检测、修改和输出软件需求模型，具体步骤如下：
D1、检测每个视点中所有场景的原子行为定义的正确性；
D2、检测场景行为表达式的合法性，以及场景内所有原子行为之间的连续性和同一视点内场景行为模型间行为输入/输出的一致性；
D3、检测每个视点行为表达式的合法性和所有视点行为模型间行为输入/输出的一致性；
D4 、显示检测结果；若检测结果为发现问题则修改相应的场景行为模型或视点行为模型，并返回重复步骤D1～步骤D3的检测，直到每个视点都检测结果通过；若检测结果为通过，则综合所有视点行为模型得到最终的系统需求模型并通过输出接口输出。
8.根据权利要求7所述建立软件需求模型的方法，其特征在于，进行步骤A时，根据问题域的逻辑特性和问题域内部各成分间的逻辑关系，将问题域划分成一个以上子问题域；步骤A2中，每个视点源对问题域的关注点包括每个视点源对所有子问题域的关注点。
9.根据权利要求7或8所述建立软件需求模型的方法，其特征在于，步骤A3中创建视点是以视点模板的形式实现；视点模板规定了视点的描述内容，且一个视点模板由若干信息槽组成；这些信息槽用于记录与该视点相关的基本信息，还记录与该视点相关的用户需求信息，包括用自然语言描述的该视点中的需求和场景、用行为描述语言描述的视点行为模型和该视点内所有场景行为模型。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN2011103235537A CN102364440A (zh) | 2011-10-23 | 2011-10-23 | 一种用于建立软件需求模型的系统及建立软件需求模型的方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN2011103235537A CN102364440A (zh) | 2011-10-23 | 2011-10-23 | 一种用于建立软件需求模型的系统及建立软件需求模型的方法 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN102364440A true CN102364440A (zh) | 2012-02-29 |
Family
ID=45691006
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN2011103235537A Pending CN102364440A (zh) | 2011-10-23 | 2011-10-23 | 一种用于建立软件需求模型的系统及建立软件需求模型的方法 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN102364440A (zh) |
Cited By (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103294475A (zh) * | 2013-06-08 | 2013-09-11 | 北京邮电大学 | 基于图形化业务场景和领域模板的业务自动生成系统和方法 |
| CN104216703A (zh) * | 2014-06-23 | 2014-12-17 | 武汉大学深圳研究院 | 嵌入式软件系统程序的开发方法 |
| WO2015042987A1 (en) * | 2013-09-30 | 2015-04-02 | Hewlett-Packard Development Company, L.P. | Record and replay of operations on graphical objects |
| CN108932118A (zh) * | 2018-04-20 | 2018-12-04 | 北京航空航天大学 | 一种基于卡牌的需求获取模型建立方法 |
| CN109815131A (zh) * | 2018-12-27 | 2019-05-28 | 卡斯柯信号有限公司 | 轨道交通车载软件半形式化需求用的静态检查系统及方法 |
| CN111309288A (zh) * | 2020-01-20 | 2020-06-19 | 北京国舜科技股份有限公司 | 适用于银行业务的软件需求规格文件的分析方法及装置 |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2009104336A (ja) * | 2007-10-22 | 2009-05-14 | Nippon Telegr & Teleph Corp <Ntt> | ソフトウェア成果物管理システム、方法及びそのプログラム |
| CN101464796A (zh) * | 2008-12-29 | 2009-06-24 | 武汉大学 | 一种建立软件需求模型的方法 |
| CN101872322A (zh) * | 2009-04-27 | 2010-10-27 | 武汉大学 | 一种基于需求模型的软件特性检测方法 |
-
2011
- 2011-10-23 CN CN2011103235537A patent/CN102364440A/zh active Pending
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2009104336A (ja) * | 2007-10-22 | 2009-05-14 | Nippon Telegr & Teleph Corp <Ntt> | ソフトウェア成果物管理システム、方法及びそのプログラム |
| CN101464796A (zh) * | 2008-12-29 | 2009-06-24 | 武汉大学 | 一种建立软件需求模型的方法 |
| CN101872322A (zh) * | 2009-04-27 | 2010-10-27 | 武汉大学 | 一种基于需求模型的软件特性检测方法 |
Cited By (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103294475A (zh) * | 2013-06-08 | 2013-09-11 | 北京邮电大学 | 基于图形化业务场景和领域模板的业务自动生成系统和方法 |
| CN103294475B (zh) * | 2013-06-08 | 2016-01-13 | 北京邮电大学 | 基于图形化业务场景和领域模板的业务自动生成系统和方法 |
| WO2015042987A1 (en) * | 2013-09-30 | 2015-04-02 | Hewlett-Packard Development Company, L.P. | Record and replay of operations on graphical objects |
| CN105593904A (zh) * | 2013-09-30 | 2016-05-18 | 惠普发展公司，有限责任合伙企业 | 对图形对象操作的记录和重放 |
| CN104216703A (zh) * | 2014-06-23 | 2014-12-17 | 武汉大学深圳研究院 | 嵌入式软件系统程序的开发方法 |
| CN108932118A (zh) * | 2018-04-20 | 2018-12-04 | 北京航空航天大学 | 一种基于卡牌的需求获取模型建立方法 |
| CN108932118B (zh) * | 2018-04-20 | 2020-07-03 | 北京航空航天大学 | 一种基于卡牌的需求获取模型建立方法 |
| CN109815131A (zh) * | 2018-12-27 | 2019-05-28 | 卡斯柯信号有限公司 | 轨道交通车载软件半形式化需求用的静态检查系统及方法 |
| CN111309288A (zh) * | 2020-01-20 | 2020-06-19 | 北京国舜科技股份有限公司 | 适用于银行业务的软件需求规格文件的分析方法及装置 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN106530088B (zh) | 基于区块链安全节点对证券产品进行交易的方法 | |
| CN101464796A (zh) | 一种建立软件需求模型的方法 | |
| Li et al. | Does outward FDI generate higher productivity for emerging economy MNEs?–Micro-level evidence from Chinese manufacturing firms | |
| CN106228446B (zh) | 基于私有区块链的资产交易平台系统及方法 | |
| CN106250987B (zh) | 一种机器学习方法、装置及大数据平台 | |
| CN102622294B (zh) | 生成用于不同测试类型的测试用例的方法和装置 | |
| CN104217362B (zh) | 基于互联网通讯的清分系统及线下交易、在线即时分账的方法 | |
| CN102364440A (zh) | 一种用于建立软件需求模型的系统及建立软件需求模型的方法 | |
| CN101872322A (zh) | 一种基于需求模型的软件特性检测方法 | |
| CN109409892A (zh) | 风险评估方法和系统 | |
| CN102508645B (zh) | 一种面向行为的软件需求模型可视化方法 | |
| CN111680098A (zh) | 数据采集、数据标注、ai模型训练和验证的区块链系统 | |
| CN109816532A (zh) | 一种基于区块链技术的资产数字化锚定系统 | |
| CN110263145A (zh) | 一种电子合同签署方法及电子合同签署设备 | |
| CN106650495A (zh) | 一种文件验证方法及装置 | |
| CN106815725A (zh) | 一种交易验证方法和装置 | |
| Zhang et al. | A node selection algorithm with a genetic method based on PBFT in consortium blockchains | |
| Jnr et al. | A Framework for Standardization of Distributed Ledger Technologies for Interoperable Data Integration and Alignment in Sustainable Smart Cities | |
| CN112435127A (zh) | 一种基于区块链的合同签署方法、装置、设备和存储介质 | |
| Jacob et al. | An Analytical approach on DFD to UML model transformation techniques | |
| Osterland et al. | On the implementation of business process logic in DLT nodes | |
| Cai et al. | A CPN-based Software Testing Approach. | |
| CN110362981A (zh) | 基于可信设备指纹判断异常行为的方法及系统 | |
| Alm et al. | Toward a framework for assessing meaningful differences between blockchain platforms | |
| Roy | Blockchain development for finance projects: building next-generation financial applications using Ethereum, Hyperledger Fabric, and Stellar |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| C02 | Deemed withdrawal of patent application after publication (patent law 2001) | ||
| WD01 | Invention patent application deemed withdrawn after publication |
Application publication date: 20120229 |