1 引用
Rocha H, Ducasse S. Preliminary steps towards modeling blockchain oriented software[C]//2018 IEEE/ACM 1st International Workshop on Emerging Trends in Software Engineering for Blockchain (WETSEB). IEEE, 2018： 52-57.
2 摘要
儘管區塊鏈主要是因為加密貨幣而流行，但智能合約已經成為一個非常突出的區塊鏈應用程序。智能合約類似於可以由區塊鏈之外的客戶機應用程序調用的類。因此，可以使用智能合約開發面向塊鏈的軟件(BOS)來實現區塊鏈中的部分業務邏輯。目前，還沒有對BOS進行建模的設計標準。由於建模是設計軟件的一個重要部分，開發人員可能很難設計BOS。在本文中，我們展示了三種基於著名軟件工程模型的互補建模方法，並將它們應用到一個BOS實例中。
3 技術介紹
由於加密貨幣的廣泛採用，區塊鏈最近變得非常流行。區塊鏈為貨幣交互提供了一個平臺，而不需要一箇中央可信的權威機構，像比特幣和以太這樣的加密貨幣非常普遍。
簡單地說，“區塊鏈是一個全局共享的事務數據庫”。雖然與傳統數據庫相去甚遠，但是這個簡單的定義可以提供一個關於區塊鏈的良好視圖。區塊鏈數據庫由分佈式網絡管理，所有網絡節點存儲數據庫的完整副本。該數據庫中的每條記錄都是一個塊，該塊與前一條記錄鏈接，形成一個序列。這些塊是不可變的，因為不能修改或刪除記錄，所以可以增強信任。
儘管區塊鏈技術主要是因為其加密貨幣而得到認可，但它也被用於其他應用。區塊鏈的一個非常突出的應用是管理智能合約。智能合約是用圖靈完備語言編寫的程序，運行在區塊鏈平臺上。如果我們遵循區塊鏈類似於數據庫，那麼智能合約就像存儲過程，因為它們在區塊鏈數據中執行過程性編程。然而，更好的類比是將智能合約看作類，因為它們由數據屬性和函數組成。此外，智能合約可以通過繼承擴展另一個合約，就像面向對象編程中的類一樣。
一旦在區塊鏈中部署了智能合約，它就可以與其他智能合約或客戶機應用程序進行交互。客戶機應用程序使用代理遠程調用智能合約函數，就像調用任何其他對象一樣。這種與智能合約交互的簡單方式允許開發人員實現將標準開發與區塊鏈相結合的應用程序。例如，當用戶界面作為桌面或web應用程序實現時，我們可以在智能合約中實現所有業務邏輯。同樣，我們也可以創建一個混合的區塊鏈應用程序，其中只有部分業務邏輯使用區塊鏈。然而，目前還沒有設計或建模BOS的標準表示法。使用區塊鏈的系統可能需要一個專門的符號來表示它。缺少專門的符號可能會使採用或遷移到BOS變得過於複雜，因為區塊鏈和應用程序之間的交互沒有得到適當的指定。在本文中，我們提出了三種基於以下建模標準的BOS互補建模方法：實體關係模型、統一建模語言、業務流程模型和符號。我們還使用一個簡單的應用程序場景來說明我們的建模，以及描述每種建模方法的優缺點。我們的目標是開始討論缺少指定BOS的特定建模符號，併為討論和更好的符號提供一個起點。
我們將使用一個簡單的BOS作為建模方法的示例。讓我們假設一個商店想要創建一個保真點程序。該商店已經有一個web應用程序來管理和銷售其產品。通過使用智能契約，客戶之間可以自由交換保真點，而無需商店的參與。我們需要使用區塊鏈帳戶來提高契約的安全性，並將這些帳戶鏈接到商店的常規客戶機數據庫。
由於區塊鏈就像一個數據庫，我們可以嘗試對它進行建模，重點放在它的數據上。因此，我們可以使用一個用於概念和邏輯設計的ER模型來指定BOS中的數據。如果BOS在其應用程序中也使用關係數據庫(一個常見的場景)，那麼我們可以使用區塊鏈數據輕鬆地增強關係數據庫的ER模型。
這種數據驅動建模方法的優點是易於理解、使用和捕獲數據。由於ER建模是一個非常流行的標準，大多數軟件工程師已經熟悉了它的設計。另一個優點是可以顯式地為區塊鏈和關係數據庫之間的鏈接建模。其主要缺點是ER模型只能捕獲數據，不能對功能結構和行為進行建模。智能合約的一個重要部分不僅是數據，而且是它的功能和行為。
例如，讓我們使用ER模型對契約數據建模(圖1)。在ER模型中，我們將列表建模為一對多關係，但在契約中，我們將其實現為映射，映射使用客戶機區塊鏈id(一個基本地址類型)作為訪問這些點的鍵。我們還創建了區塊鏈中的點與我們的私有客戶機數據庫之間的關係，以便跟蹤我們的主應用程序。
當我們擴展ER模型的概念設計邏輯設計(圖1),我們可以指定區塊鏈的實現為每個實體和關係數據庫工件。例如,我們可以指定實體的映射邏輯設計。我們也可以放置一個外鍵來實現點和客戶之間的關係。因此，ER模型可以用來指定BOS中的數據。另一方面，我們可以看到大部分契約代碼都是函數，很少用於數據。因此，ER模型不足以設計BOS的所有方面。
1 引用
Rocha H, Ducasse S. Preliminary steps towards modeling blockchain oriented software[C]//2018 IEEE/ACM 1st International Workshop on Emerging Trends in Software Engineering for Blockchain (WETSEB). IEEE, 2018： 52-57.
2 摘要
儘管區塊鏈主要是因為加密貨幣而流行，但智能合約已經成為一個非常突出的區塊鏈應用程序。智能合約類似於可以由區塊鏈之外的客戶機應用程序調用的類。因此，可以使用智能合約開發面向塊鏈的軟件(BOS)來實現區塊鏈中的部分業務邏輯。目前，還沒有對BOS進行建模的設計標準。由於建模是設計軟件的一個重要部分，開發人員可能很難設計BOS。在本文中，我們展示了三種基於著名軟件工程模型的互補建模方法，並將它們應用到一個BOS實例中。
3 技術介紹
由於加密貨幣的廣泛採用，區塊鏈最近變得非常流行。區塊鏈為貨幣交互提供了一個平臺，而不需要一箇中央可信的權威機構，像比特幣和以太這樣的加密貨幣非常普遍。
簡單地說，“區塊鏈是一個全局共享的事務數據庫”。雖然與傳統數據庫相去甚遠，但是這個簡單的定義可以提供一個關於區塊鏈的良好視圖。區塊鏈數據庫由分佈式網絡管理，所有網絡節點存儲數據庫的完整副本。該數據庫中的每條記錄都是一個塊，該塊與前一條記錄鏈接，形成一個序列。這些塊是不可變的，因為不能修改或刪除記錄，所以可以增強信任。
儘管區塊鏈技術主要是因為其加密貨幣而得到認可，但它也被用於其他應用。區塊鏈的一個非常突出的應用是管理智能合約。智能合約是用圖靈完備語言編寫的程序，運行在區塊鏈平臺上。如果我們遵循區塊鏈類似於數據庫，那麼智能合約就像存儲過程，因為它們在區塊鏈數據中執行過程性編程。然而，更好的類比是將智能合約看作類，因為它們由數據屬性和函數組成。此外，智能合約可以通過繼承擴展另一個合約，就像面向對象編程中的類一樣。
一旦在區塊鏈中部署了智能合約，它就可以與其他智能合約或客戶機應用程序進行交互。客戶機應用程序使用代理遠程調用智能合約函數，就像調用任何其他對象一樣。這種與智能合約交互的簡單方式允許開發人員實現將標準開發與區塊鏈相結合的應用程序。例如，當用戶界面作為桌面或web應用程序實現時，我們可以在智能合約中實現所有業務邏輯。同樣，我們也可以創建一個混合的區塊鏈應用程序，其中只有部分業務邏輯使用區塊鏈。然而，目前還沒有設計或建模BOS的標準表示法。使用區塊鏈的系統可能需要一個專門的符號來表示它。缺少專門的符號可能會使採用或遷移到BOS變得過於複雜，因為區塊鏈和應用程序之間的交互沒有得到適當的指定。在本文中，我們提出了三種基於以下建模標準的BOS互補建模方法：實體關係模型、統一建模語言、業務流程模型和符號。我們還使用一個簡單的應用程序場景來說明我們的建模，以及描述每種建模方法的優缺點。我們的目標是開始討論缺少指定BOS的特定建模符號，併為討論和更好的符號提供一個起點。
我們將使用一個簡單的BOS作為建模方法的示例。讓我們假設一個商店想要創建一個保真點程序。該商店已經有一個web應用程序來管理和銷售其產品。通過使用智能契約，客戶之間可以自由交換保真點，而無需商店的參與。我們需要使用區塊鏈帳戶來提高契約的安全性，並將這些帳戶鏈接到商店的常規客戶機數據庫。
由於區塊鏈就像一個數據庫，我們可以嘗試對它進行建模，重點放在它的數據上。因此，我們可以使用一個用於概念和邏輯設計的ER模型來指定BOS中的數據。如果BOS在其應用程序中也使用關係數據庫(一個常見的場景)，那麼我們可以使用區塊鏈數據輕鬆地增強關係數據庫的ER模型。
這種數據驅動建模方法的優點是易於理解、使用和捕獲數據。由於ER建模是一個非常流行的標準，大多數軟件工程師已經熟悉了它的設計。另一個優點是可以顯式地為區塊鏈和關係數據庫之間的鏈接建模。其主要缺點是ER模型只能捕獲數據，不能對功能結構和行為進行建模。智能合約的一個重要部分不僅是數據，而且是它的功能和行為。
例如，讓我們使用ER模型對契約數據建模(圖1)。在ER模型中，我們將列表建模為一對多關係，但在契約中，我們將其實現為映射，映射使用客戶機區塊鏈id(一個基本地址類型)作為訪問這些點的鍵。我們還創建了區塊鏈中的點與我們的私有客戶機數據庫之間的關係，以便跟蹤我們的主應用程序。
當我們擴展ER模型的概念設計邏輯設計(圖1),我們可以指定區塊鏈的實現為每個實體和關係數據庫工件。例如,我們可以指定實體的映射邏輯設計。我們也可以放置一個外鍵來實現點和客戶之間的關係。因此，ER模型可以用來指定BOS中的數據。另一方面，我們可以看到大部分契約代碼都是函數，很少用於數據。因此，ER模型不足以設計BOS的所有方面。
圖1 存儲點合約ER模型實例
UML符號有六個圖來建模面向對象系統的結構。由於智能合約與類非常相似，所以我們可以使用UML圖，而不需要太多的調整。因此，我們可以使用UML對面向對象的應用程序及其區塊鏈結構進行建模。使用UML結構圖的一個優點是，我們可以很容易地在智能合約上建模和指定函數和數據屬性。例如，我們將智能合約建模為UML類圖(圖2)。類圖表示契約的內部結構。在這個例子中，我們還對一個類似於前面展示的ER模型的客戶端實體類進行了建模(圖1)。正如我們所看到的，客戶端類和契約之間沒有關係，因為類圖不能將數據之間的鏈接捕獲為ER模型。此外，類圖關係(例如，聚合、組合等)可能會誤導開發人員，使他們無法實現與區塊鏈和區塊鏈中多餘的代碼對象的交互。
1 引用
Rocha H, Ducasse S. Preliminary steps towards modeling blockchain oriented software[C]//2018 IEEE/ACM 1st International Workshop on Emerging Trends in Software Engineering for Blockchain (WETSEB). IEEE, 2018： 52-57.
2 摘要
儘管區塊鏈主要是因為加密貨幣而流行，但智能合約已經成為一個非常突出的區塊鏈應用程序。智能合約類似於可以由區塊鏈之外的客戶機應用程序調用的類。因此，可以使用智能合約開發面向塊鏈的軟件(BOS)來實現區塊鏈中的部分業務邏輯。目前，還沒有對BOS進行建模的設計標準。由於建模是設計軟件的一個重要部分，開發人員可能很難設計BOS。在本文中，我們展示了三種基於著名軟件工程模型的互補建模方法，並將它們應用到一個BOS實例中。
3 技術介紹
由於加密貨幣的廣泛採用，區塊鏈最近變得非常流行。區塊鏈為貨幣交互提供了一個平臺，而不需要一箇中央可信的權威機構，像比特幣和以太這樣的加密貨幣非常普遍。
簡單地說，“區塊鏈是一個全局共享的事務數據庫”。雖然與傳統數據庫相去甚遠，但是這個簡單的定義可以提供一個關於區塊鏈的良好視圖。區塊鏈數據庫由分佈式網絡管理，所有網絡節點存儲數據庫的完整副本。該數據庫中的每條記錄都是一個塊，該塊與前一條記錄鏈接，形成一個序列。這些塊是不可變的，因為不能修改或刪除記錄，所以可以增強信任。
儘管區塊鏈技術主要是因為其加密貨幣而得到認可，但它也被用於其他應用。區塊鏈的一個非常突出的應用是管理智能合約。智能合約是用圖靈完備語言編寫的程序，運行在區塊鏈平臺上。如果我們遵循區塊鏈類似於數據庫，那麼智能合約就像存儲過程，因為它們在區塊鏈數據中執行過程性編程。然而，更好的類比是將智能合約看作類，因為它們由數據屬性和函數組成。此外，智能合約可以通過繼承擴展另一個合約，就像面向對象編程中的類一樣。
一旦在區塊鏈中部署了智能合約，它就可以與其他智能合約或客戶機應用程序進行交互。客戶機應用程序使用代理遠程調用智能合約函數，就像調用任何其他對象一樣。這種與智能合約交互的簡單方式允許開發人員實現將標準開發與區塊鏈相結合的應用程序。例如，當用戶界面作為桌面或web應用程序實現時，我們可以在智能合約中實現所有業務邏輯。同樣，我們也可以創建一個混合的區塊鏈應用程序，其中只有部分業務邏輯使用區塊鏈。然而，目前還沒有設計或建模BOS的標準表示法。使用區塊鏈的系統可能需要一個專門的符號來表示它。缺少專門的符號可能會使採用或遷移到BOS變得過於複雜，因為區塊鏈和應用程序之間的交互沒有得到適當的指定。在本文中，我們提出了三種基於以下建模標準的BOS互補建模方法：實體關係模型、統一建模語言、業務流程模型和符號。我們還使用一個簡單的應用程序場景來說明我們的建模，以及描述每種建模方法的優缺點。我們的目標是開始討論缺少指定BOS的特定建模符號，併為討論和更好的符號提供一個起點。
我們將使用一個簡單的BOS作為建模方法的示例。讓我們假設一個商店想要創建一個保真點程序。該商店已經有一個web應用程序來管理和銷售其產品。通過使用智能契約，客戶之間可以自由交換保真點，而無需商店的參與。我們需要使用區塊鏈帳戶來提高契約的安全性，並將這些帳戶鏈接到商店的常規客戶機數據庫。
由於區塊鏈就像一個數據庫，我們可以嘗試對它進行建模，重點放在它的數據上。因此，我們可以使用一個用於概念和邏輯設計的ER模型來指定BOS中的數據。如果BOS在其應用程序中也使用關係數據庫(一個常見的場景)，那麼我們可以使用區塊鏈數據輕鬆地增強關係數據庫的ER模型。
這種數據驅動建模方法的優點是易於理解、使用和捕獲數據。由於ER建模是一個非常流行的標準，大多數軟件工程師已經熟悉了它的設計。另一個優點是可以顯式地為區塊鏈和關係數據庫之間的鏈接建模。其主要缺點是ER模型只能捕獲數據，不能對功能結構和行為進行建模。智能合約的一個重要部分不僅是數據，而且是它的功能和行為。
例如，讓我們使用ER模型對契約數據建模(圖1)。在ER模型中，我們將列表建模為一對多關係，但在契約中，我們將其實現為映射，映射使用客戶機區塊鏈id(一個基本地址類型)作為訪問這些點的鍵。我們還創建了區塊鏈中的點與我們的私有客戶機數據庫之間的關係，以便跟蹤我們的主應用程序。
當我們擴展ER模型的概念設計邏輯設計(圖1),我們可以指定區塊鏈的實現為每個實體和關係數據庫工件。例如,我們可以指定實體的映射邏輯設計。我們也可以放置一個外鍵來實現點和客戶之間的關係。因此，ER模型可以用來指定BOS中的數據。另一方面，我們可以看到大部分契約代碼都是函數，很少用於數據。因此，ER模型不足以設計BOS的所有方面。
圖1 存儲點合約ER模型實例
UML符號有六個圖來建模面向對象系統的結構。由於智能合約與類非常相似，所以我們可以使用UML圖，而不需要太多的調整。因此，我們可以使用UML對面向對象的應用程序及其區塊鏈結構進行建模。使用UML結構圖的一個優點是，我們可以很容易地在智能合約上建模和指定函數和數據屬性。例如，我們將智能合約建模為UML類圖(圖2)。類圖表示契約的內部結構。在這個例子中，我們還對一個類似於前面展示的ER模型的客戶端實體類進行了建模(圖1)。正如我們所看到的，客戶端類和契約之間沒有關係，因為類圖不能將數據之間的鏈接捕獲為ER模型。此外，類圖關係(例如，聚合、組合等)可能會誤導開發人員，使他們無法實現與區塊鏈和區塊鏈中多餘的代碼對象的交互。
圖2 存儲點合約和客戶端類圖示例
在圖2中，我們沒有對其他類建模，以避免使圖混亂。然而，如果我們在同一個圖中建模更多的類和合約，那麼我們將需要一個特殊的符號來區分它們，以便更好地進行可視化。例如，我們使用了更多的應用領域類來改進圖表(圖3)，我們在合約圖形表示中使用了一個小的“chain”圖標作為符號，以便更容易地將其標識為區塊鏈構件。
1 引用
Rocha H, Ducasse S. Preliminary steps towards modeling blockchain oriented software[C]//2018 IEEE/ACM 1st International Workshop on Emerging Trends in Software Engineering for Blockchain (WETSEB). IEEE, 2018： 52-57.
2 摘要
儘管區塊鏈主要是因為加密貨幣而流行，但智能合約已經成為一個非常突出的區塊鏈應用程序。智能合約類似於可以由區塊鏈之外的客戶機應用程序調用的類。因此，可以使用智能合約開發面向塊鏈的軟件(BOS)來實現區塊鏈中的部分業務邏輯。目前，還沒有對BOS進行建模的設計標準。由於建模是設計軟件的一個重要部分，開發人員可能很難設計BOS。在本文中，我們展示了三種基於著名軟件工程模型的互補建模方法，並將它們應用到一個BOS實例中。
3 技術介紹
由於加密貨幣的廣泛採用，區塊鏈最近變得非常流行。區塊鏈為貨幣交互提供了一個平臺，而不需要一箇中央可信的權威機構，像比特幣和以太這樣的加密貨幣非常普遍。
簡單地說，“區塊鏈是一個全局共享的事務數據庫”。雖然與傳統數據庫相去甚遠，但是這個簡單的定義可以提供一個關於區塊鏈的良好視圖。區塊鏈數據庫由分佈式網絡管理，所有網絡節點存儲數據庫的完整副本。該數據庫中的每條記錄都是一個塊，該塊與前一條記錄鏈接，形成一個序列。這些塊是不可變的，因為不能修改或刪除記錄，所以可以增強信任。
儘管區塊鏈技術主要是因為其加密貨幣而得到認可，但它也被用於其他應用。區塊鏈的一個非常突出的應用是管理智能合約。智能合約是用圖靈完備語言編寫的程序，運行在區塊鏈平臺上。如果我們遵循區塊鏈類似於數據庫，那麼智能合約就像存儲過程，因為它們在區塊鏈數據中執行過程性編程。然而，更好的類比是將智能合約看作類，因為它們由數據屬性和函數組成。此外，智能合約可以通過繼承擴展另一個合約，就像面向對象編程中的類一樣。
一旦在區塊鏈中部署了智能合約，它就可以與其他智能合約或客戶機應用程序進行交互。客戶機應用程序使用代理遠程調用智能合約函數，就像調用任何其他對象一樣。這種與智能合約交互的簡單方式允許開發人員實現將標準開發與區塊鏈相結合的應用程序。例如，當用戶界面作為桌面或web應用程序實現時，我們可以在智能合約中實現所有業務邏輯。同樣，我們也可以創建一個混合的區塊鏈應用程序，其中只有部分業務邏輯使用區塊鏈。然而，目前還沒有設計或建模BOS的標準表示法。使用區塊鏈的系統可能需要一個專門的符號來表示它。缺少專門的符號可能會使採用或遷移到BOS變得過於複雜，因為區塊鏈和應用程序之間的交互沒有得到適當的指定。在本文中，我們提出了三種基於以下建模標準的BOS互補建模方法：實體關係模型、統一建模語言、業務流程模型和符號。我們還使用一個簡單的應用程序場景來說明我們的建模，以及描述每種建模方法的優缺點。我們的目標是開始討論缺少指定BOS的特定建模符號，併為討論和更好的符號提供一個起點。
我們將使用一個簡單的BOS作為建模方法的示例。讓我們假設一個商店想要創建一個保真點程序。該商店已經有一個web應用程序來管理和銷售其產品。通過使用智能契約，客戶之間可以自由交換保真點，而無需商店的參與。我們需要使用區塊鏈帳戶來提高契約的安全性，並將這些帳戶鏈接到商店的常規客戶機數據庫。
由於區塊鏈就像一個數據庫，我們可以嘗試對它進行建模，重點放在它的數據上。因此，我們可以使用一個用於概念和邏輯設計的ER模型來指定BOS中的數據。如果BOS在其應用程序中也使用關係數據庫(一個常見的場景)，那麼我們可以使用區塊鏈數據輕鬆地增強關係數據庫的ER模型。
這種數據驅動建模方法的優點是易於理解、使用和捕獲數據。由於ER建模是一個非常流行的標準，大多數軟件工程師已經熟悉了它的設計。另一個優點是可以顯式地為區塊鏈和關係數據庫之間的鏈接建模。其主要缺點是ER模型只能捕獲數據，不能對功能結構和行為進行建模。智能合約的一個重要部分不僅是數據，而且是它的功能和行為。
例如，讓我們使用ER模型對契約數據建模(圖1)。在ER模型中，我們將列表建模為一對多關係，但在契約中，我們將其實現為映射，映射使用客戶機區塊鏈id(一個基本地址類型)作為訪問這些點的鍵。我們還創建了區塊鏈中的點與我們的私有客戶機數據庫之間的關係，以便跟蹤我們的主應用程序。
當我們擴展ER模型的概念設計邏輯設計(圖1),我們可以指定區塊鏈的實現為每個實體和關係數據庫工件。例如,我們可以指定實體的映射邏輯設計。我們也可以放置一個外鍵來實現點和客戶之間的關係。因此，ER模型可以用來指定BOS中的數據。另一方面，我們可以看到大部分契約代碼都是函數，很少用於數據。因此，ER模型不足以設計BOS的所有方面。
圖1 存儲點合約ER模型實例
UML符號有六個圖來建模面向對象系統的結構。由於智能合約與類非常相似，所以我們可以使用UML圖，而不需要太多的調整。因此，我們可以使用UML對面向對象的應用程序及其區塊鏈結構進行建模。使用UML結構圖的一個優點是，我們可以很容易地在智能合約上建模和指定函數和數據屬性。例如，我們將智能合約建模為UML類圖(圖2)。類圖表示契約的內部結構。在這個例子中，我們還對一個類似於前面展示的ER模型的客戶端實體類進行了建模(圖1)。正如我們所看到的，客戶端類和契約之間沒有關係，因為類圖不能將數據之間的鏈接捕獲為ER模型。此外，類圖關係(例如，聚合、組合等)可能會誤導開發人員，使他們無法實現與區塊鏈和區塊鏈中多餘的代碼對象的交互。
圖2 存儲點合約和客戶端類圖示例
在圖2中，我們沒有對其他類建模，以避免使圖混亂。然而，如果我們在同一個圖中建模更多的類和合約，那麼我們將需要一個特殊的符號來區分它們，以便更好地進行可視化。例如，我們使用了更多的應用領域類來改進圖表(圖3)，我們在合約圖形表示中使用了一個小的“chain”圖標作為符號，以便更容易地將其標識為區塊鏈構件。
圖3 用特殊的區塊鏈符號增強的合約和客戶端類圖示例
當我們處理BOS時，業務流程可能需要一個詳細的規範來幫助開發人員和工程師實現它。BPMN是指定業務流程的適當符號。主要優點是我們可以很容易地指定流程行為。另一方面，我們無法使用BPMN對複雜數據建模。另一個缺點是，使用BPMN對軟件的概述建模很困難，因為我們的重點是指定單個業務流程。例如，讓我們考慮一個已經在我們的在線商店web應用程序中註冊的客戶的業務流程，該客戶希望註冊我們的區塊鏈fidelity程序。我們可以使用BPMN來指定流程(圖4)和泳道符號(即，命名的box容器也稱為池)來指定與區塊鏈的交互。我們還可以使用一個圖標(類似於圖2中使用的圖標)來突出顯示區塊鏈任務。
4 本文主要貢獻
加密貨幣的普及使得區塊鏈成為普通人、從業者、開發人員和研究人員的熱門話題。另一個突出的區塊鏈應用程序是智能合約。通過使用智能合約，我們可以開發在區塊鏈中維護其部分數據或邏輯的軟件。對於這種類型的軟件，我們使用術語塊鏈面向軟件(BOS)。對於BOS示例，我們採用了三種建模方法，每種方法都關注一個特定的方面：數據驅動、結構驅動和流程驅動。對於數據驅動，我們創建了一個ER模型，它主要用於在關係數據庫中指定數據。對於結構驅動，我們在所有6個UML結構圖中選擇類圖作為我們的模型。對於流程驅動，我們使用BPMN表示法。每種方法都有其優點和缺點，需要一個專門的BOS符號來正確地設計它。我們在本文中的目標不是提出一個通用的解決方案，而是開始討論並提高對BOS缺乏建模符號的認識。我們正致力於以下方向的未來工作：(i)使用一個真正的BOS軟件開發，對其設計過程進行建模和文檔化；(ii)驗證行為和交互UML圖是否也需要適配以正確指定BOS；(iii)創建對BOS建模的工具支持，以及將代碼反向工程到模型中，並使用模型自動生成代碼。
致謝
本文由南京大學軟件工程系2018碩士生喬力翻譯轉述