没有单一的真理或一种你“应该”做的方式。我会给你我的方法，基于统一过程。
用例技术主要用于描述人类用户（参与者）和应用程序之间的对话。它被建模为一个椭圆，并进一步指定为一个活动图或只是一个步骤列表：1 参与者执行 A，2 系统执行 B，3 参与者执行 C 等等。在这种方法中，应用程序被视为黑色盒子。
“用例实现”描述了系统如何执行其步骤（白盒），例如在协作组件方面，对用户透明。
有所谓的业务用例是可能的，但不太常见。在这种情况下，“系统”代表企业或业务单位。在您的情况下，它将是图书馆。“参与者”代表外部人员或组织，例如客户或供应商。在你的情况下，这将是一个客户。对于业务用例，库被视为一个黑盒子。这些步骤仍然采用“actor 执行 A；system 执行 B”的格式，但这里没有指定库的哪些操作由人类执行，哪些由应用程序执行。系统是与外部参与者交互的组织，无论是由员工还是由应用程序实现。
“业务用例实现”指定系统如何执行其步骤（白框）并指定哪些部分由员工完成，哪些部分由机器完成。
现在，让我一一回答你的问题。
问题 1。
如果您将您的用例描述为一个业务用例，并且在如此高的抽象层次上，客户端-图书馆员交互的步骤与客户端-机器交互的步骤相同，那么您将拥有一个业务用例”借书”和此业务用例的两个业务用例实现。
但是，更常见的做法是仅使用用户与应用程序交互的用例。如果客户与系统交互的方式与图书馆员代表客户的方式相同，那么您将只有一个用例“借书”，参与者为“人”。这个演员有两个专业：“客户”和“图书管理员”。每个用例只有一个用例实现。
否则，您将有一个用例“在线借书”描述当客户端直接与应用程序交互时的事件流，连接到参与者“客户端”和另一个用例“为客户端借书”描述事件流图书馆员在与客户交谈时与应用程序进行交互。后一个用例将“图书管理员”作为其参与者。同样，每个用例只有一个用例实现。
根据模型的目的，您可以选择单独或根本不为客户-图书馆员交互建模。
问题2。
让我们以用例“在线借书”为例。对于此用例，您可能有两种用例实现：一种用于键盘机器，另一种用于触摸屏机器。如果这些用例实现非常相似，那么我将只制作一个用例实现并描述在该单个实现中存在两种可能的输入设备的事实。
问题 3。
对于业务用例实现，我会使用 BPMN 2.0 或 UML 活动图。这些非常适合业务工作流规范。
对于正常的用例实现，我通常会制作一个序列图，其中这些图中的生命线是指在通用组件图中定义的组件。在序列图的左边空白处，我通常将用例的步骤写在 UML 注释符号中。序列图关注组件之间的交互，使用它们的接口。这很好地概述了特定用例上下文中组件之间的协作。
有关更多信息，请参阅我的白皮书我们应该制作哪些 UML 模型？. 第 19 页描述了用例实现。
UML 与方法无关。即使没有选择，也有不同的建模方法，例如：
同样，对于您的问题，您可以考虑使用不同的替代模型，或者一个具有不同替代方案的模型分组在不同的包中（以避免命名冲突）。就个人而言，我会选择后者，因为不同的替代方案不应该过于详细。但归根结底，这是您所在环境中的成本和收益问题。
顺便说一句，Ivar Jacobson 的书，对象优势将 OO 建模技术应用于业务流程设计。所以 UML 非常适合人类解决方案。只是所考虑的系统不再是一个 IT 系统，而是一个更广泛的组织系统，其中 IT 代表了一些组件。
UML 具有显示不同实现的协作元素。用例是锚，因为参与者的附加值不会改变。但是，您可以通过不同的方式实现这些用例。这就是合作发挥作用的地方。协作看起来像一个用例，但有一个虚线边框。并且你从一个或多个协作中得出一个实现关系到一个用例。在协作中，您将展示不同实现的类如何协作（因此得名）。
UML 2.5 的 P.213 第11.7 段协作：
Collaborations 的主要目的是解释沟通元素系统如何共同完成特定任务或一组任务，而不必包含与解释无关的细节。协作是 UML 可用于捕获设计模式的一种方式。
CollaborationUse 表示将 Collaboration 描述的模式应用于特定情况，涉及特定元素扮演其协作角色。