阅读下列说明和图，回答问题1至问题3，将解答填入答题纸的对应栏内。
说明:某高校图书馆欲建设一个图书馆管理系统，目前已经完成了需求分析阶段的工作。功能需求均使用用例进行描述，其中用例"借书（CheckOutBooks）"的详细描述如下。参与者：读者（Patron）。
典型事件流：
1.输入读者ID；
2．确认该读者能够借阅图书，并记录读者ID；
3．输入所要借阅的图书ID；
4．根据图书目录中的图书ID确认该书可以借阅，计算归还时间，生成借阅记录；
5．通知读者图书归还时间。重复步骤3～5，直到读者结束借阅图书。
备选事件流：
2a.若读者不能借阅图书，说明读者违反了图书馆的借书制度（例如，没有支付借书费用等）
①知读者不能借阅，并说明拒绝借阅的原因；
②用例结束。
4a.读者要借阅的书无法外借
①知读者本书无法借阅；
②到步骤3。
说明：图书的归还时间与读者的身份有关。如果读者是教师，图书可以借阅一年；如果是学生，则只能借阅3个月。读者ID中包含读者身份信息。现采用面向对象方法开发该系统，得到如图3-1所示的系统类模型（部分）；以及如图3-2所示的系统操作"checkOut（bookID）（借书）"的通信图（或协作图）。
问题1:根据说明中的描述，以及图3-1和图3-2，给出图3-1中C1～C4处所对应的类名（类名使用图3-1和图3-2中给出的英文词汇）。
问题2:根据说明中的描述，以及图3-1和图3-2，给出图3-2中M1～M4处所对应的方法名（方法名使用图3-1和图3-2中给出的英文词汇）。
问题3:用例"借书"的备选事件流4a中，根据借书制度来判定读者能否借阅图书。若图书馆的借书制度会不断地扩充，并需要根据图书馆的实际运行情况来调整具体使用哪些制度。为满足这一要求，在原有类设计的基础上，可以采用何种设计模式？简要说明原因。
参考答案：
问题1：C1：PatronC2：BookC3：CatalogC4：CheckoutSessionController
问题2：M1：getForCheckOutM2：isFacultyM3：circulatesM4：recordBookLoan
问题3：解答：策略模式。策略模式定义了一系列算法，并将每个算法封装起来，而且使它们可以相互替换。策略模式让算法独立于使用它们的客户而变化。适用于需要在不同情况下使用不同的策略（算法），或者策略还可能在未来用其他方式来实现
解析：
本题属于经典的考题，主要考查面向对象分析方法以及UML类图和通信图的相关知识。
问题1：说明中给出了一个具体用例的详细描述，给出了其中的一个系统操作"checkoutbookID）（借书）"的通信图，需要考生利用通信图中的信息来补充类图中缺失的部分。通信图（communicationdiagram）强调收发消息的对象的结构组织，在早期的版本中也被称作协作图。通信图强调参加交互的对象的组织。产生一张通信图，首先要将参加交互的对象作为图的顶点，然后把连接这些对象的链表示为图的弧，最后用对象发送和接收的消息来修饰这些链。这就提供了在协作对象的结构组织的语境中观察控制流的一个清晰的可视化轨迹。消息checkOut（bookID）的接收者是类CheckoutSessionController的对象，说明类CheckoutSessionController中应该包含这一方法，否则无法响应该条消息。由图3-1可知，C4处所代表的类应该是CheckoutSessionController。消息find（bookID）的接收者是类Book，同理，由图3-1可知，C2处对应的类应该是Book。根据用例描述，图书信息是包含在图书目录中，所以C3处对应的类应该是Catalog，C1处对应的就应该是Patron了。
问题2：图3-1填充完整之后，图3-2的空缺就比较容易填写了。在通信图中，对象之间传递的消息就对应着接收对象中的方法。M1对应的就是类Catalog中的方法，由图3-1可知，M1对应的是getForCheckOut。M3对应的应该是类Book中的方法。由图3-1可知，Book中有3个方法，find和checkOut已经出现在通信图上了，所以M3应该是circulates。M2和M4是类Patron中的方法。Patron中有2个方法。通信图中的消息是有序号的，这个序号表示了消息的时间顺序，也就是说发送M2的时间要早于消息M4，因此必须区分类Patron中两个方法使用的先后顺序。在用例描述中特别指出：图书的归还时间与读者的身份有关。计算还书及借书费用时，需先确定读者的身份，因此方法isFaculty应该先被调用，所以M2对应isFaculty，M4对应recordBookLoan。
问题3：本题在设计类时使用到了策略模式。策略模式定义了一系列的算法，把它们一个个封装起来，并且使它们可以相互替换。此模式使得算法可以独立于使用它们的客户而变化。策略模式的结构如下图所示。
其中：
●Strategy（策略）定义所有支持的算法的公共接口。Context使用这个接口来调用某ConcreteStrategy定义的算法。
●ConcreteStrategy（具体策略）以Strategy接口实现某具体算法。
●Context（上下文）用一个ConcreteStrategy对象来配置；维护一个对Strategy对象的引用；可定义一个接口来让Strategy访问它的数据。
Strategy模式适用于：
●许多相关的类仅仅是行为有异。"策略"提供了一种用多个行为中的一个行为来配置一个类的方法。
●需要使用一个算法的不同变体。例如，定义一些反应不同空间的空间／时间权衡的算法。当这些变体实现为一个算法的类层次时，可以使用策略模式。
●算法使用客户不应该知道的数据。可使用策略模式以避免暴露复杂的、与算法相关的数据结构。
●一个类定义了多种行为，并且这些行为在这个类的操作中以多个条件语句的形式出现，将相关的条件分支移入它们各自的Strategy类中，以代替这些条件语句。