参考答案:
【问题1】
用例模型的参与者：仓库管理员、仓库经理、系统管理员、时间、温度、温度调节系统。
【问题2】
用例建模的主要工作是书写用例规约（use case specification），而不是画图。用例模板为一个给定项目的所有人员定义了用例规约的结果，其内容至少包括用例名、参与者、目标、前置条件、事件流（基本事件流和扩展事件流）和后置条件等，其他的还可以包括非功能需求和用例优先级等。
【问题3】
（1）用例之间的关系包括：包含关系、扩展关系、泛化关系。
（2）“出入库操作”与“登录”属于包含关系；
“查看统计报表”与“生成统计报表”属于扩展关系；
“用户注册”与“电话注册”、“邮件注册”与“电话注册”属于典型的泛化关系。
详细解析:
用例模型的参与者：仓库管理员、仓库经理、系统管理员、时间、温度、温度调节系统。
用例建模的主要工作是书写用例规约（use case specification），而不是画图。用例模板为一个给定项目的所有人员定义了用例规约的结果，其内容至少包括用例名、参与者、目标、前置条件、事件流（基本事件流和扩展事件流）和后置条件等，其他的还可以包括非功能需求和用例优先级等。
在建立了初步的用例模型后，还可以利用用例之间的关系来调整用例模型。用例之间的关系主要有包含、扩展和泛化，利用这些关系，把一些公共的信息抽取出来，以便于复用，使得用例模型更易于维护。
（1）包含关系。当可以从两个或两个以上的用例中提取公共行为时，应该使用包含关系来表示它们。其中这个提取出来的公共用例称为抽象用例，而把原始用例称为基本用例或基础用例。例如，图11-10中的“学习课程”和“课程测试”两个用例都需要检查学员的权限，为此，可以定义一个抽象用例“检查权限”。用例“学习课程”和“课程测试”与用例“检查权限”之间的关系就是包含关系，如图11-11所示。其中“<<include>>”是包含关系的构造型，箭头指向抽象用例。
图11-11 包含关系的例子
当多个用例需要使用同一段事件流时，抽象成为公共用例，可以避免在多个用例中重复地描述这段事件流，也可以防止这段事件流在不同用例中的描述出现不一致。当需要修改这段公共的需求时，也只要修改一个用例，避免同时修改多个用例而产生的不一致性和重复性工作。另外，当某个用例的事件流过于复杂时，为了简化用例的描述，也可以将某一段事件流抽象成为一个被包含的用例。
（2）扩展关系。如果一个用例明显地混合了两种或两种以上的不同场景，即根据情况可能发生多种分支，则可以将这个用例分为一个基本用例和一个或多个扩展用例，这样使描述可能更加清晰。例如，图11-10中的学员进行“课程测试”时，其测试的次数可能已超出系统规定的限额，这时就需要学员“充入学习币”。用例“课程测试”和“充入学习币”之间的关系就是扩展关系，如图11-12所示。其中“<<extend>>”是扩展关系的构造型，箭头指向基本用例。
图11-12 扩展关系的例子
（3）泛化关系。当多个用例共同拥有一种类似的结构和行为的时候，可以将它们的共性抽象成为父用例，其他的用例作为泛化关系中的子用例。在用例的泛化关系中，子用例是父用例的一种特殊形式，子用例继承了父用例所有的结构、行为和关系。例如，图11-10中学员进行课程注册时，假设既可以通过电话注册，也可以通过网上注册，则“注册课程”用例就是“电话注册”用例和“网上注册”用例的泛化，如图11-13所示。其中三角箭头指向父用例。
图11-13 泛化关系的例子
在本题中，“出入库操作”与“登录”属于包含关系；“查看统计报表”与“生成统计报表”属于扩展关系；“用户注册”与“邮件注册”和“电话注册”属于典型的泛化关系。