Step0 参与者、系统与需求
用例是一种描述需求的方法，用例描述了在不同的条件下，系统对参与者的请求做出的响应。用例通常通过一个参与者（Actor）（谁？）向系统做出请求，系统根据参与者的请求（要做什么？），在不同的条件下，执行某一行为序列（系统怎么满足？）。
系统：此次工程实践的主要内容是区块链架构的实现，因此所需实现的系统自然是一个区块链系统。
参与者：本次工程实践中的需要实现的是公链，即所有参与者是平等的，既是使用者也是维护者。
需求：对于一个最基本的区块链系统，存在如下的需求。
- 区块链系统需要允许用户完成交易
- 区块链系统需要允许用户验证交易
- 区块链系统需要允许用户生成钱包
- 区块链系统需要允许用户进行同步
Step1 从需求中抽取抽象用例（abstract use case）
用Step0中抽取除三个抽象用例即：
- 完成交易：区块链的本质是在一个分布式系统中对所有参与节点维护一个一致的账本，所谓的完成交易，主要是对用户对该账本进行修改操作的抽象。
- 打包交易：要想在分布式节点上实现一个一致的账本，就必须引入共识机制，打包交易即时对这一机制的抽象，即由部分充当维护者的用户抽取待打包的交易（待录入账本的修改）进行一系列工作证明后将对账本的更新上传并取得大部分节点的共识，以完成分布式系统中账本的更新。
- 生成钱包：钱包是对用户存储的公私钥对的抽象，在UTXO中，既是用于验证交易的密钥，也是用于完成交易及获取挖矿奖励的账户地址。因此区块链系统应该实现钱包的生成，维护，存储以及诸如可读化等扩展。
- 进行同步：由于区块链的本质是分布式系统中的一致账本，因此在系统中实现同步是系统一切功能的基础。
附：用例名用于标识一个用例，便于汇总和阅读，包括以下两条规则：（1）使用主动语态的动宾短语来描述。（2）以主参与者为对象进行描述。
Step2&3 关联用例及用例图绘制（use case diagram）
在这里推荐一个在线绘图网站：https://www.processon.com/
Step4 描述TUBCW与TUBEW（high level use case）
- 完成交易
(1) TUCBW：用户输入交易相关信息。
(2) TUCEW：用户从系统中查询到发布的交易信息。
- 打包交易
(1) TUCBW：用户发出同步请求
(2) TUCEW：用户从系统处得到发布的区块是否完成共识的信息
- 生成钱包
(1) TUCBW：用户发出生成钱包的请求
(2) TUCEW：用户从系统处得到新生成的钱包
- 进行同步
(1) TUCBW：用户发出同步请求
(2) TUCEW：用户从系统处得到相应数据
Step5 规范参与者和系统之间的交互（expanded use case）
上述三个用例中，最为核心的是打包交易，该用例既是系统实现的基础，也是当下区块链系统主要性能瓶颈的所在，下面对这一用例进行扩展用例分析：
|
参与者 |
区块链系统 |
|
1.TUCBW：用户发出同步请求 |
2.系统向用户返回当前最长区块链 |
|
3.用户向系统请求交易数据 |
4.系统返回维护的交易池 |
|
5.用户从返回的交易池中打捞交易，进行工作证明并将结果上传 |
6.系统同步 |
|
7.TUCEW：用户从系统处得到 |