We present an application of the BOSE and ABCDE development methodology to build a DApp system for managing real world contracts for temporary workers so that, by design, agreements, commitments and rules are respected for the speci c domain and employment sector and so that employers and employees are safeguarded by design. This includes the possibility to provide access from public regulatory bodies to all the information and employment history. Ethereum Solidity Smart Contracts are designed to manage all the steps and to keep track of all Commitments and Agreements, of Employers and Employees and of job history. We built a working prototype of application where the system management is automated by mean of an easy to use web interface acting as a front-end interacting with the blockchain back-end.
Blockchain applications are blooming in the most disparate sectors aside from the cryptocurrency original start. The introduction of the Ethereum platform solicited developers to produce decentralized applications that nowadays constitute the Ethereum DApp ecosystem. Despite such exponential increase of interest most DApp still lack of organized software development methodologies and even when the domain of application may seem interesting such un-organized DApp development does not guaranty security in sensitive applications neither grants that constraints and rules from the application domain are respected.
This is especially critical when Smart Contracts are meant to substantiate real life contracts, such as in the domain of employment. Contractors who want to recur to automated and self enforcing Smart Contracts to respect agreements and to ful ll commitments must be secure by design that some domain speci c constraints are respected and the software code does not fail to ful ll the agreed rules.
In this work we present a case study where temporary employments are managed by a
blockchain software system designed according to the Blockchain Oriented Software Engineering
(BOSE) [
In this speci c case study the advantages of using a blockchain DApp system rather than a traditional software system are multiples.
First, the nature of the relationships between the employer and the employees in the speci c case of temporary workers is controversial. In fact the rst usually wants to optimize earnings and minimize costs, and usually the power of bargaining between the parties is unbalanced, since the the temporary workers need to quickly nd a job and are exposed to a competition with o ers to downside for the salary in order to get the job. Using blockchain all data are recorded and accessible to anyone so that any o er to downside became transparent. Workers have access to information regarding average salaries and can ask for a pay comparable to the average. Public bodies can access to salaries and can verify if minimal Union salaries rules are ful lled in the agreements.
Second, given the unbalance between each single temporary worker and a big company, the latter can take advantage of its position of power to delay or reduce payments, counting on the low probability of being suited from a temporary worker. Using Smart Contracts payments amounts and deadlines are automatically respected by the execution of the smart contract code.
Third, the employer can automate checks and steps needed to pay the workers and by automatic execution of smart contract code can verify if the workers completely ful lled the agreed duties before any payment is executed.
Fourth, and most important, in this case study the application of BOSE and ABCDE methodology helps to simplify the system and the smart contract con guration and to clarify to all involved gures the actor roles and duties, so that anyone can easily understand conditions, agreements and duties.
We do not further bother the reader describing and discussing here the other well known
and general advantages carried on by the use of a blockchain system in this speci c case such
as immutability, privacy, traceability and so on, that are easily understood for a blockchain
system. For a comprehensive discussion about these aspects we remand to the conceptual
proposal presented in [
The target of our design is to simplify the temporary employment procedure, to provide traceability of the procedure, to protect both employer and employee against misbehavior, to prevent out of law agreements, to provide public bodies devoted to controls and checks with an easy to use system, to render public and secure the ecosystem, to provide an easy to use and practical interface for the interaction between employer and employees.
Most importantly, we apply the BOSE and ABCDE methodology to devise the overall system's architecture showing how these approaches help to de ne actores, roles, constraints, functionalities and requirements for a speci c domain.
The ABCDE methodology starts with the subdivision of the system in out-of-chain and in-chain components using the diagrams as prescribed by BOSE. This requires also to identify the system's actors.
We design the system so that there are two actors typologies, three human actors and two actors which are system components, for a total of ve main actors.
The rst typology, the human actors, are:
The employer : it creates the work activity, it announces the request for one or more workers, it describes the job, the pay, the duties, the worker features, the time period for the request, and so on.
The worker : it typically applies for a job, provides his CV, if possible examines and chooses among di erent job o ers.
The work inspector : he can access the employer's data and check how many hours he has registered for each worker. He will be able to compare these data with the results of any workplace inspection.
The web platform: a simpli ed web platform with an interface allowing to post new job o ers, to insert job candidacies, to access information about the posted jobs. The blockchain infrastructure: it records smart contracts and transactions for the various job contracts, it allows to manage direct payments, it grants security and privacy The blockchain infrastructure has the role of master ledger but also the role of protecting both parties against misbehavior and scams. In order to make concrete our system we used the most popular blockchain at the moment, namely the Ethereum blockchain, since it provides a nice environment to write smart contracts, compilers and debuggers are available, testnets for trials are free and working properly, and nally a complete environment for interacting with the blockchain from a web interface is provided by the web3.js library. Ethereum in fact provides a well tested ecosystem where many examples are available to use standard procedures and datatypes for developing decentralized applications. Ethereum smart contracts, implemented in Solidity, are well suited for the application of BOSE and ABCDE methodology and procedures for data recording and transaction managing are easily implemented. Furthermore the Ether cryptocurrency holds a true value in the market, since exchanges deal it in large amounts aganst at currency, and so it can be used to implement real money transfers and payments. In this speci c contest public regulatory bodies are usually involved but nowadays the market of temporary jobs is setting the traditional system into a sort of crisis, especially because multinational rms can hire workers behind the protection of di erent legislative systems where regulatory bodies nd it hard to intervene. The blockchain can be an alternative where contract conditions are directly guaranteed by the technology itself. 3
The initial system state is idle. This means that the system still has to receive an input deposit in order to create a new job o er from an employer which initially does not contain any information about the employer or the employee. This deposit will grant the workers that there is some initial amount of money to pay for the job. This must be considered as a set up before starting.
The rst event is the creation of a new job o er where the employer uses the webApp to complete the procedure for inserting the o er with all the information needed. Each job o er has several properties, such as: a name, an id, a description, the working hours, the pay, the deadline. All the transitions could be represented by a state diagram according to UML representation which can be adapted to the blockchain speci c features.
After this step the employer can create the announcement where the salary is limited to a maximum according to what deposited. At the end of the procedure the system automatically creates and sends to the blockchain various messages which include all the information needed to create the set of smart contracts for managing the job, this will be discussed later.
After created the o er the system's state changes passing to a waiting state for the candidates workers. The system is con gured in order to accept, at this point, the workers applications for the job. Each worker sends a message to a speci c Smart Contract for registering his/her candidature. Once a candidate is selected for a job the hiring event is launched. The employer obtains the id and the data of the applicant and sends a message to the blockchain to announce the start of the working period. From this moment on, the worker can verify its working situation: the worked hours can automatically be certi ed according to di erent schemes and agreements but in any case the employer must certify the worked hours with a message sent to the appropriate smart contract. Once the amount of agreed working hours is reached the smart contract ends the job and sends the pay. During this event the system moves the salary deposited at the beginning to the employee account concluding the relationship. The worker, since everything is recorded, will be able to recover all the data history for any job performed. 3.1
We implemented two Smart Contracts typologies using the ERC721 token that we call JobOfferManager and Employment which are already registered and ready in the webApp. The platform can customize the Smart contracts by the data inserted from the employer according to the previous section. Once the event of creation of a new job o er is launched the two Smart Contracts are created, con gured according to the information inserted by the employer, and deployed into the blockchain, linked to each other. The JobO erManager implements various functions, such as the insertion of the deposit in ETH, the creation of a new job o er, the hiring and the payment. The Employment Smart Contracts contains all the information related to candidates. It also allows to the employer to increase and certify the working hours as worked by the employee, to end the job once the working hours are completed. The worker can apply to di erent job o ers, withdraw a candidacy, send a request for a job. The features of the two Smart Contracts are described by user stories which are reported as a list or according to the diagram shown in g. 1
The user stories are:
Announce: the employer sets a new job o er with description and features.
Hour registering request: the employee send a request to the employer to record and certify all worked hours up to that day.
Con rm: the employer examines the request and can decide to asseverate the worked hours.
Announcements Visualization: the employer visualizes the job o ers he/she created Candidacy Visualization: the applicant visualizes the job o ers he/she applied to Work Visualization: the employee visualizes the job he/she is working on.
O ers Visualization: any user visualizes all job o ers (expired or active)
Current O ers Visualization: any user visualizes all job o ers not yet expired For each user story we implemented a corresponding web page in the prototype.
Once the use case diagram for actors has been designed it is easy to proceed to the design of the Smart Contracts. According to what reported above, we implemented into the JobO erManager Smart Contracts the following state variables:
- address owner: address of contract's creator - uint32 lastid: token holding the number of created o ers - struct jobO er (data representing one job o er) uint256 expirationDate: the expiration day address payable worker: Ethereum employee's account address address employer: Ethereum employer's account address string name: o er's name string info: o er's description uint8 workhours: working hours to be worked uint salary: salary o ered - struct Jobs: { uint32[] jobs: array holding all the job o ers created - struct OnGoingJobs { uint32[] onGoingJobs: array holding all the jobs a speci c worker is working on at the moment
- mapping(address => uint256) internal depositOf : mapping returning the ETH deposited in the Smart Contract by a speci c address (associated to an employer)
- mapping(address => Jobs) internal o ersBy: mapping returning the job o ers created by a speci c address
- mapping(address => OnGoingJobs) private hiredinjobs: mapping associating the employee address to all the job he/she is actually working on
- mapping(uint32 => jobO er) private jobs: mapping returning the description of a job o er given the o er id
- mapping(uint32 => bool) public moneyIsReturn: mapping returning a boolean stating if the deposit has been withdrawn given an o er id.
The ABI interface is reported below according to the user stories diagram devised above. -Constructor -getNumberOfO ers(): outputs the number of o ers created -getName(uint32): outputs the o er's name -getExpirationDate(uint32): outputs the expiration date -getSalary(uint32): outputs the o er's salary -getAddressWorker (uint32): outputs the employee's address -getAddressEmployer (uint32): outputs the employer's address -getInfo(uint32): outputs the o er's description -getAmountHours(uint32): outputs the number of minutes to be worked for a job -getJobO er(uint32): outputs all the features of a job o er -getArrayActiveO er (): outputs all non expired o ers -getDepositedAmount(): outputs the amount deposited in the contract from a given address -getO ersBy (address): outputs the o ers created by a give address -getApplicantOf (address): outputs an array containing all the jobs a worker is hired for -getTokenId(): outputs the token's actual value -getBalance(): outputs the amount deposited in wei -getIsActiveO er(uint32): veri es if an o er is expired or not -getIsMoneyIsReturn (uint32): outputs if, given a job o er, the deposit has been withdrawn -newJob(uint256, string memory, string memory, uint8, uint): creates a new job o er with all the details
-hireWorker(address payable, uint32): starts the work relationship. It is called by the employer to hire the employee for a given job o er
-payment(uint32): once the job duties are completed this function is called by the employer to pay the employee.
-moneyReturnsEemployer(uint32): it reimburses the employer once a job o er has expired without any worker hired.
Next we report as well the state variables for the Employment Smart Contract: -address owner: address of contract's creator -address payable scJobO erManager: address referring to the Smart Contract managing the job o ers -struct Applicant : |{address[] applicant: array containing all candidacies -struct JobDone |{uint32[] jobsDone: array containing all the jobs done by a worker -struct RequestHours (data realted to the hours requested by a worker) |- uint32[] idO er: array containing all id of job o ers without requests of adding hours |- uint[] numberHours: array containing the number of requested work hours -mapping (uint32 => uint) internal workhours: mapping providing the number of hours worked by an employee given the o er id
-mapping (uint32 => Applicant ) internal applicantsOf: mapping providing the candidates of an o er given its id
-mapping (uint32 => uint ) internal requestHours: mapping providing the number of hours requested for being added given the o er id
-mapping (address => RequestHours ) internal requestHoursForEmployer: mapping providing the o er id and the number of requested hours given the employer's address -mapping (address => JobDone ) internal jobsDone: mapping providing the work concluded given the worker's address
Finally we report the ABI Interface for the Smart Contract Employment -Constructor -setJobO erAddress(address payable): the function for setting the address of JobO erManager Smart Contract -getJobO erAddress(): outputs the address of JobO erManager contract -getIsSetJobO erAddress(): returns if the address of JobO erManager contract has been set or not
-getIsEqualToJobO erAddress(address payable): veri es if the value of variable scJobO erManager matches the address of the contract provided in input (the contract Employment can refer only to one single contract managing the job o ers) -getApplicantOf(uint32): outputs the array containing candidates for an o er -getJobsDone(): outputs the array containing all concluded jobs -getRequestHours(uint32): outputs the number of hours required for an o er -getRequestHoursForEmplyer(): outputs two arrays containing the o ers' ids and the number of hours requested by each o er
-getHoursDone(uint32): outputs the number of hours worked up to that moment by an employee -getHourMissing(unit32): outputs the number of remaining working hours to be completed -jobCompleted(uint32): veri es if the work has been executed and performs the payment -addWorkdays(uint32, uint): it is called by the employer to update the hours worked by an employee and activates the payment procedure (calling jobCompleted) once if the number of working hours agreed has been reached
-requestAdditionalHours(uint32, uint): is called by the employee to ask for adding the worked hours -workerApplies(uint32): called by a user to apply for a job o er -withdrawCandidacy(uint32): called by a user to withdraw from a job o er 3.2
Solidity allows to de ne Smart Contract in a way very similar to how classes are de ned in Object Oriented (OO) programming languages. It supports inheritance, it includes a Constructor to deploy the Smart Contract on the blockchain, it supports interactions among contracts by means of transactions messages, so that a contract can call and activate functions of another one, it supports events managing. According to BOSE and ABCDE methodology it's convenient to develop diagrams for Smart Contracts design and interaction which adopt the same schemes used in OO Software Engineering such as UML diagrams. We already presented the diagrams for Blockchain Software Engineering for users stories and for state diagrams in the previous section. In this section we describe the devised Smart Contracts and their interaction using the Contracts Diagram. Figures 2, 3 and 4 show the Smart Contracts diagrams and the relationships among them. These are described as in the usual UML diagrams, with similar meanings and with the use of stereotypes to characterize speci c aspects of blockchain software. In particular the use of data structures and of libraries is easily described and allows for a clear and fast development of the smart contract software code in Solidity acting as a guide for developers. Fig. 2 also shows how it is possible to represent the interaction among in-chain and out-of-chain components. 3.3
In order to de ne and analyze the dynamic behavior of the system we designed the activity diagrams for the employer and for the employee. This is particularly important in Blockchain Software Engineering since the activity ow correspond to dynamic behaviours on the blockchain as well for the messages ow. In fact activities can match transactions in the blockchain which may occur between smart contracts. On the other hand, for activities that are performed internally to a single smart contract there is the possibility of generating the events related to these activities (this is typical in solidity). Thus in the design phase the activity diagrams provide a useful analysis tool to understand which operations need to be executed by means of blockchain transactions and which operations need to be recorded and tracked by means of events. The various activities in the diagram in general correspond to code execution or message employer.png calls. In gures 5 6 we report the activity diagram for the employer and for the employee. The diagrams provide useful insights for identifying blocks and pieces of working software code for the in and out of blockchain components. 3.4
In the diagram 7 we represent the sequence of operations that the actors and the system perform to add work hours for a given job until the completion of the agreed number of hours. The worker accesses the workers' web interface and adds work hours to a job. He provides the job id. The web interface collects the request and calls the function "requestAdditionalHours (id, n)" of the employment smart contract which veri es that the worker (the sender of the request) is actually registered as a worker of the given job (with a given id) and the job is active. If so, it adds the N work hours as requested. The employer can check the amount of work hours to be con rmed calling the function viewHours() of the employers' web interface. The web interface loops in the job created by the employer and requests the employment smart contract to return the work hours waiting to be con rmed. Once data are collected, the web interface shows the list to the employer. The employer can now certify the work hours of a worker, given a job id. He accesses the employers' web interface and calls the function "selectJobO er" to request worker.png the validation of the requested work hours. The interface calls the function "addWorkdays" for a given id and an amount N . If the id is valid, the work hours are validated. Now, if the contractual limit of work hours is reached, the system calls the jobCompleted function which runs the "payment" function of the jobO erManager contract. 4
Based on the application of all principles and methods adopted from BOSE and ABCDE methodologies we developed the Solidity code for the Smart Contracts (not reported here) and built the DApp system which provides the users with a user friendly web interface enabling the implementation of all the features described. In g. 8 we report as an example the web interface providing the functionality for the insertion of a new job o er by the employer. The web interface uses \metamask", a bridge to run Ethereum DApps right in your browser without running a full Ethereum node, for providing the communication channel between DApp and blockchain. The web interface allows the various actors of the system to interact with the blockchain through the DApp so that no actor needs to understand or to know the working principles of the blockchain system. Every feature is provided by a user friendly web page were input and output data can be inserted and read and events and function calls can be managed. We devised various interfaces to provide speci c features depending on the users roles with menus adapted to the di erent roles. We deployed the Smart Contracts on the Ropsten test net in order to test our prototype under all working conditions. 5
In recent years, the research on the blockchain application in hiring management and work
management is slowly expanding. In 2018, Oink et al. [
More recently, Peisl and Shah [
The design of blockchain based system for recruitment is the topic of the work of
WonYong and Min [
All these works present two weakness. They focus only on the creation of the contractual relationship and does not include a speci c automation in payment when work is completed nor provide additional protection to the worker or they do it only marginally. 6
In this case study we applied the BOSE and ABCDE methodology to devise a DApp for managing temporary employments so that by design the employers and the employees are able to easily identify roles, constraints, commitments in the speci c domain. This approach allows to build a DApp software product in which all the requirements and features are determined and recovered by the diagrams adopted by the methodology so that Smart Contracts variables and ABI are quickly and precisely identi ed. The approach reduces risks of failure since inchain and out-of-chain components are identi ed by design since the very beginning, and smart contract structure and interactions are well de ned before the software development. We show how the approach successfully guided us to produce a working prototype for managing the case study of the temporary employments.