No standard modeling technique exists for Requirements Engineering (RE) and Organizational Modeling (OM) within Blockchain-Oriented Software Engineering. This paper aims to provide preliminary advices through the study of two modeling frameworks when representing blockchain-supported processes in Supply Chain (SC) Management (SCM), namely the i* framework and the Unified Modeling Language (UML) Use Case and Sequence Diagrams. This paper illustrates findings on a real life case study called 'Farm-to-Fork'. The case study provides a blockchain solution for the SC of farm animals. The modeling techniques are applied to uncover their pros and cons in this context. The paper points to the use of (extended) i* representations and the aforementioned UML diagrams in a complementary way because of the various perspectives they provide to develop a blockchain: while i* fits during early RE/OM phases to understand the 'why' of the SC processes, UML better fits the late RE/OM and design stages by offering concrete diagrams to understand the 'what' and 'how'.
depend on each other for goals to be achieved, tasks to be performed, and resources to
be furnished [
Legend:
Actor
Actor Boundary
Goal Task
Resource Softgoal
D Dependency Link
Some +
Contribution Link Decomposition Link
Means-ends Link
UML Use Case Diagrams are well known to describe the cases in which a system can be used. UML Sequence Diagrams are a more widely known model that allows to describe the interactions between the different actors and a central system. This is useful for blockchain in SC Requirements Engineering (RE) because the Sequence Diagram can depict a specific order of system operations, which corresponds very well to the nature of the SC flow. This similarity makes Sequence Diagrams a well-established candidate to model blockchain initiatives in the SC domain.
While previous literature has touched upon the adoption of BT for SCM, it has
failed to conceptually model these processes for software engineering. For example,
Niranjanamurthy et al. [
This paper extends on previous research by Ben Hamadi et al. [
Research Paradigm. The research presented here takes roots in the Design Science
paradigm [
Research Question. Are extended i* models and UML Use Case/Sequence Diagrams appropriate modeling techniques to visualize the organizational structure of blockchain ecosystems and how do these two frameworks compare?
Research Methodology. To answer the research question, a case study is required
[
A first interview was conducted in February 2020 with Interviewee 1 (I1) a blockchain consultant who has worked on, among others, blockchain projects for the Belgian government. A second interview was conducted in April 2020 with Interviewee 2 (I2) another blockchain expert working at the same company. He provided some additional insights. Out of the information gathered from the interviews, we have elaborated several conceptual models using both i* and UML techniques. A third, final validation session was organized in May 2020 with I2; the latter then validated and confirmed the case study description as well as the associated representations. After applying both modeling techniques to the case study, a summary of their pros and cons is provided. Comparing both techniques is useful to determine their shortcomings. 3
The case study, called Farm-to-Fork concerns a blockchain solution made to track farm animals throughout the SC process, from “their birth to your plate”. The solution also includes an easy to use app that gives an overview of the stages of the SC process, including QR-codes to track animals. Every participant in the network, and therefore every node in the SC, can quickly check the origin of the animal, the quality and the different previous steps that the animal has gone through. 3.1
The Farm-to-Fork prototype was created to meet the increasing expectation levels for improved transparency in the food industry. This solution provides an answer to many of those struggles. I2 suggests that the most important benefits of this implementation are the traceability and the liability aspects. Traceability ensures the ability for the SC participants to closely monitor the animals and allows them to know the exact state and quality of the animal (product). Therefore, it becomes much easier to detect contaminated batches, and to identify any such batches before they can reach the final SC node (such as supermarkets) where they may create a health hazard to unknowing consumers. This also helps to reduce waste. Additionally, I2 remarks that, even if a contaminated product manages to get to consumers, it is much easier to trace down the specific faulty batches, since all product information is meticulously and individually stored in the blockchain. Therefore, in case a contaminated batch would still reach the end-consumers, the health associated consequences will be much less severe.
The liability aspect that I2 mentions refers to knowing all the actions of the SC nodes, including their consequences. For example, fragile chicken eggs that are transported from node to node throughout the SC can break at any stage. However, disputes can arise between the participants of the SC network about who is responsible for this. With blockchain, these disputes can be settled very quickly as the database can tell when and where every individual egg broke. Furthermore, the advantages do not only apply to the producers, but also to the consumers, since the idea is also to expose a part of the blockchain to them. Consumers can view information about a specific animal product in the supermarket by scanning a QR-code. This enables consumers to verify the origin and all the process steps that the animal has gone through.
However, it is important to mention that consumers should only have access to restricted, but relevant information. If a consumer would also be able to see exactly how many chicken eggs they’ve bought from a specific farmer, they might want to skip some parts of the SC cycle and go straight to that farmer for eggs, leaving the rest of the SC nodes redundant and unprofitable. I2 underlines the importance to carefully assign specific access rights to each participant.
More information about the case study – the type of blockchain and the used raft consensus – can be found in Appendix I3. 3.2
The Farm-to-Fork solution is used in a context of farm animals that go through the SC. For this paper, the case study takes an in depth look at the logistic flow of chicken meat from farmer to consumer.
The possible participants for the blockchain project, their respective roles within the SC and their minimum required input into the blockchain are listed in Table 1 (the detail is available in Appendix II). This represents a generic model of how the solution works in this context. More (or less) participants could be involved, depending on the needs and context of each specific SC’s structure. 4 4.1
Two types of extensions of i* are proposed in this paper: privacy and laws and norms. 3 All appendices are available at: http://dx.doi.org/10.17632/zkygycmz2t.1
Bashir [
Next to the privacy issues, I1 also stresses the importance of regulations. As blockchain
is still a relatively young technology, new regulations that limit the working of the
blockchain and/or smart contracts might become applicable. The legal binding of smart
contracts in a court of law is often a subject for debate [
Figure 2 provides an overview of all suggested extensions, including their proposed graphical notations. The i* extensions for privacy concepts and for laws and norms are taken over from the literature.
Concept
Graphical notation Access control
Privacy accountability Confidentiality Anonymity Norms
AC
PA C Norm
L
L Source
Actor
Privacy
Access to data in the chain is restricted
to certain nodes.
This notation can be used on data elements. The annotation allows to specify who has access or who doesn’t.
The notation is used on a data element
and allows to make third parties accountable for data manipulation under
privacy requirements.
The data-owner can hide certain data from the other nodes. This notation can
be used on data elements.
An actor wants to anonymize his data
partially or completely.
The notation is used on an actor element and allows to specify what data
should be anonymized.
Laws and norms
An actor should be compliant with a certain norm. This norm also has a source (e.g. EU).
Ben Hamadi
(2020) Ben Hamadi
(2020) Ben Hamadi
(2020) Ben Hamadi
(2020) Siena et al. (2008, 2009) It should be apparent that, in case of a blockchain adoption for the Farm-to-Fork process, all actors will become connected to each other through the blockchain system. To visualize such a process, the blockchain system itself should also be represented as an actor, alongside the other participants in the network. The relationship between the nodes in the SC and the blockchain is indeed a dependent one. The blockchain network depends on the farmer, the catcher, the transporters, the butcher, the packager and the supermarket for data. The data is validated and saved into the blockchain. Certain nodes, like the transporter, can depend on the use of IoT devices to automatically capture and send data to the blockchain. For the transporter, this data can include the transportation conditions such as the humidity and the temperature. Based on this data, the blockchain system can also verify whether the contractual terms are fulfilled. The (execution of the) smart contracts therefore depend(s) on the data in the blockchain database. The system can automatically execute the contract through these smart contracts. Because these smart contracts depend on the input data of the SC nodes in the blockchain database, they are also represented as an actor.
Additionally, the blockchain depends on the supermarket to specify the attributes that must be collected by the various stakeholders as input for the blockchain database. On the other hand, the supermarket node also depends on the blockchain data itself, to permit an analysis of the optimal quality requirements (via business intelligence techniques on this data). After the optimal conditions are estimated by the supermarket, the smart contracts need this list of quality requirements to adjust the contract specifications. Moreover, consumers can check the product’s history and origin by (partially) viewing the blockchain’s data. The SD model of such a SC process is shown in Fig. 3.
Consumers can
onlysee limitedparts of the Blockchain
Nodes can only see the requirements of themselves, not of other nodes
Smart contract D Execute contracts
D
D
D The SR model focuses more on the internal rationale or reasoning of all the nodes, related to the dependencies between actors.
In addition to the interaction between the different SC participants, the supermarket’s ability to specify the quality requirements for each stakeholder is also important and is therefore depicted with the SR model in Figure 4. This model focuses on the interdependencies between the supermarket, the blockchain, the smarts contracts and the consumer. The supermarket is an especially important node as the final product arrives here and is sold to consumers. Hence, the chicken meat must be of the best quality in order to sell it to consumers. It is likely that most benefits of the blockchain adoption are experienced in this stage of the SC: no more wastage because of higher quality and avoidance of contaminated products, contaminated products can no longer get into the hands of consumers which limits health risks, and consumer awareness is higher because they can scan the QR-code on the packaging of the chicken meat to check the history of the product. Given these four important actors (the supermarket, the blockchain, the smart contracts and the consumer), the SR model can understand the ‘why’ of interdependencies.
5.1
The Use Case diagram is depicted in Figure 5. All network nodes can input, store and verify data. The verification of data can only be fulfilled when a leader is appointed in the Raft consensus mechanism (see Appendix I), although every node will double check the verification of the leader (I2). Additionally, the supermarket can provide quality specifications that must be adhered to by all parties. Here, smart contracts are shown as an actor even though they are an integrated part of the blockchain system. This is done to show the possible actions of the smart contracts (i.e. checking whether contractual terms are fulfilled or not and automatically executing the smart contracts). Moreover, consumers can check the history and origin of products by scanning a QR-code.
Farmer The Sequence Diagram is modeled because it shows the order in which the activities occur. As already mentioned previously, this is especially useful for SC processes. The Farm-to-Fork Sequence Diagram is depicted in Figure 6.
With every blockchain return message ‘Verification of data’, an alternative fragment should take place, which defines what happens if the verification is successful and what happens if it isn’t. However, for simplicity reasons in Figure 6, this alternative (or alt-) fragment is only explicitly modeled for the first occurrence where the blockchain wants to verify data (i.e. at the farmer’s data entry). Thus, although not explicitly modeled, this alt-fragment takes place every time the blockchain wants to verify data.
As mentioned before, the transporter can use an IoT device to automatically save and send transportation data to the blockchain. This proposed IoT device is also included in the Sequence Diagram to show the effects of the implementation. Finally, at the bottom, a loop is included. This represents the quality requirement updates that the supermarket can repeatedly implement whenever a new (local or global) optimum is found for the process conditions (e.g. by using business intelligence tools). More illustrations of sequence diagrams in the context of blockchain use cases (on the raft consensus and customer access) can be found in Appendix III. 6
This section compares the pros and cons of the SD and SR models (i* framework)
versus the Use Cases and Sequence Diagrams (UML) as modeling techniques for BOSE.
First, a set of the criteria to compare both models is defined. The criteria are based on
three intakes: generic modeling criteria based on existing literature [
As can be seen in Table 2, the two frameworks distinguish themselves by their different purpose: while i* is social-focused, the UML Use Case and Sequence Diagrams are system-oriented. Both techniques are complementary. Therefore, we recommend to use the i* framework during the early phases of RE. This enables system developers to understand the ‘why’ of the SC process, giving a clear overview of the interdependencies and the goals of all nodes in the blockchain network, as this is the core of the blockchain’s decentralized system. During later phases, UML diagrams can be applied to design the system’s interactions with the different actors of the SC in more detail. 7
After applying both modeling languages to the case, a comparative evaluation between
both approaches was performed. A set of assessment criteria was established and we
conclude on the complementarity of the approaches. The in-depth comparison between
both has revealed that they also lack some elements to model BOSE in SCM to its full
extent. Hence, new graphical concepts are proposed to enhance the models. First, in line
with Ben Hamadi et al. [
The present study combined with Ben Hamadi et al. lead us conclude that i* and its
refinements are relevant for each BOSE development in SCM. Future work includes (i)
the application of the enhances i* framework in other domains, (ii) the application of
other frameworks line notable the business use case model together with BPMN (see
[