尽管区块链主要是因为加密货币而流行,但智能合约已经成为一个非常突出的区块链应用程序。智能合约类似于可以由区块链之外的客户机应用程序调用的类。因此,可以使用智能合约开发面向块链的软件(BOS)来实现区块链中的部分业务逻辑。目前,还没有对BOS进行建模的设计标准。由于建模是设计软件的一个重要部分,开发人员可能很难设计BOS。在本文中,我们展示了三种基于著名软件工程模型的互补建模方法,并将它们应用到一个BOS实例中。
由于加密货币的广泛采用,区块链最近变得非常流行。区块链为货币交互提供了一个平台,而不需要一个中央可信的权威机构,像比特币和以太这样的加密货币非常普遍。
简单地说,“区块链是一个全局共享的事务数据库”。虽然与传统数据库相去甚远,但是这个简单的定义可以提供一个关于区块链的良好视图。区块链数据库由分布式网络管理,所有网络节点存储数据库的完整副本。该数据库中的每条记录都是一个块,该块与前一条记录链接,形成一个序列。这些块是不可变的,因为不能修改或删除记录,所以可以增强信任。
尽管区块链技术主要是因为其加密货币而得到认可,但它也被用于其他应用。区块链的一个非常突出的应用是管理智能合约。智能合约是用图灵完备语言编写的程序,运行在区块链平台上。如果我们遵循区块链类似于数据库,那么智能合约就像存储过程,因为它们在区块链数据中执行过程性编程。然而,更好的类比是将智能合约看作类,因为它们由数据属性和函数组成。此外,智能合约可以通过继承扩展另一个合约,就像面向对象编程中的类一样。
一旦在区块链中部署了智能合约,它就可以与其他智能合约或客户机应用程序进行交互。客户机应用程序使用代理远程调用智能合约函数,就像调用任何其他对象一样。这种与智能合约交互的简单方式允许开发人员实现将标准开发与区块链相结合的应用程序。例如,当用户界面作为桌面或web应用程序实现时,我们可以在智能合约中实现所有业务逻辑。同样,我们也可以创建一个混合的区块链应用程序,其中只有部分业务逻辑使用区块链。然而,目前还没有设计或建模BOS的标准表示法。使用区块链的系统可能需要一个专门的符号来表示它。缺少专门的符号可能会使采用或迁移到BOS变得过于复杂,因为区块链和应用程序之间的交互没有得到适当的指定。在本文中,我们提出了三种基于以下建模标准的BOS互补建模方法:实体关系模型、统一建模语言、业务流程模型和符号。我们还使用一个简单的应用程序场景来说明我们的建模,以及描述每种建模方法的优缺点。我们的目标是开始讨论缺少指定BOS的特定建模符号,并为讨论和更好的符号提供一个起点。
我们将使用一个简单的BOS作为建模方法的示例。让我们假设一个商店想要创建一个保真点程序。该商店已经有一个web应用程序来管理和销售其产品。通过使用智能契约,客户之间可以自由交换保真点,而无需商店的参与。我们需要使用区块链帐户来提高契约的安全性,并将这些帐户链接到商店的常规客户机数据库。
由于区块链就像一个数据库,我们可以尝试对它进行建模,重点放在它的数据上。因此,我们可以使用一个用于概念和逻辑设计的ER模型来指定BOS中的数据。如果BOS在其应用程序中也使用关系数据库(一个常见的场景),那么我们可以使用区块链数据轻松地增强关系数据库的ER模型。
这种数据驱动建模方法的优点是易于理解、使用和捕获数据。由于ER建模是一个非常流行的标准,大多数软件工程师已经熟悉了它的设计。另一个优点是可以显式地为区块链和关系数据库之间的链接建模。其主要缺点是ER模型只能捕获数据,不能对功能结构和行为进行建模。智能合约的一个重要部分不仅是数据,而且是它的功能和行为。
例如,让我们使用ER模型对契约数据建模(图1)。在ER模型中,我们将列表建模为一对多关系,但在契约中,我们将其实现为映射,映射使用客户机区块链id(一个基本地址类型)作为访问这些点的键。我们还创建了区块链中的点与我们的私有客户机数据库之间的关系,以便跟踪我们的主应用程序。
当我们扩展ER模型的概念设计逻辑设计(图1),我们可以指定区块链的实现为每个实体和关系数据库工件。例如,我们可以指定实体的映射逻辑设计。我们也可以放置一个外键来实现点和客户之间的关系。因此,ER模型可以用来指定BOS中的数据。另一方面,我们可以看到大部分契约代码都是函数,很少用于数据。因此,ER模型不足以设计BOS的所有方面。
UML符号有六个图来建模面向对象系统的结构。由于智能合约与类非常相似,所以我们可以使用UML图,而不需要太多的调整。因此,我们可以使用UML对面向对象的应用程序及其区块链结构进行建模。使用UML结构图的一个优点是,我们可以很容易地在智能合约上建模和指定函数和数据属性。例如,我们将智能合约建模为UML类图(图2)。类图表示契约的内部结构。在这个例子中,我们还对一个类似于前面展示的ER模型的客户端实体类进行了建模(图1)。正如我们所看到的,客户端类和契约之间没有关系,因为类图不能将数据之间的链接捕获为ER模型。此外,类图关系(例如,聚合、组合等)可能会误导开发人员,使他们无法实现与区块链和区块链中多余的代码对象的交互。
在图2中,我们没有对其他类建模,以避免使图混乱。然而,如果我们在同一个图中建模更多的类和合约,那么我们将需要一个特殊的符号来区分它们,以便更好地进行可视化。例如,我们使用了更多的应用领域类来改进图表(图3),我们在合约图形表示中使用了一个小的“chain”图标作为符号,以便更容易地将其标识为区块链构件。
当我们处理BOS时,业务流程可能需要一个详细的规范来帮助开发人员和工程师实现它。BPMN是指定业务流程的适当符号。主要优点是我们可以很容易地指定流程行为。另一方面,我们无法使用BPMN对复杂数据建模。另一个缺点是,使用BPMN对软件的概述建模很困难,因为我们的重点是指定单个业务流程。例如,让我们考虑一个已经在我们的在线商店web应用程序中注册的客户的业务流程,该客户希望注册我们的区块链fidelity程序。我们可以使用BPMN来指定流程(图4)和泳道符号(即,命名的box容器也称为池)来指定与区块链的交互。我们还可以使用一个图标(类似于图2中使用的图标)来突出显示区块链任务。
curton 2019-12-2 20:52