阅读以下关于互联网医院用例建模与顺序图的叙述，在答题纸上回答问题1-3。
【说明】
某医院拟建设互联网医院系统，支持患者在线问诊、医生远程接诊和后台基础资料维护。系统面向患者、医生和管理员三类用户。患者注册登录后，可选择医生、提交病情描述、查看问诊记录、查看处方并评价问诊；医生登录后，可维护个人信息，在线接诊，查看患者病情信息，与患者在线沟通，进行诊断处理，出具电子处方并编写医嘱；管理员负责用户、医生和药品等基础信息维护。项目组需要补全用例图中的参与者、用例及 include/extend 关系，并根据问诊顺序图识别边界类、控制类和实体类。
补充用例图中的主要参与者、用例和 include/extend 关系。
（1）处方开具
（2）看病 / 提出看病需求
（3）查看问诊记录
（4）医嘱
（5）诊断处理
（6）接诊信息编辑
（7）管理用户
（8）管理处方
（9）患者
（10）医生
（11）注册登录
（12）管理员
看病 include 问诊，查看问诊记录 extend 问诊，处方开具 extend 诊断处理，医嘱 extend 诊断处理
患者的功能包括：注册登录、进入问诊界面、查看问诊记录、看病，也就是在线提出看病需求。其中“看病”是患者发起问诊的核心用例，它通常必须进入“问诊”流程，所以可以理解为：
看病 include 问诊
也就是说，“看病”这个用例会包含“问诊”这个基础过程。
“查看问诊记录”不是每次问诊都必须发生。患者可以问诊，也可以不查看历史记录；只有在需要回看病情、处方、医嘱或者历史沟通内容时，才会触发这个功能。所以它更适合作为“问诊”的扩展用例：
查看问诊记录 extend 问诊
医生的功能包括：注册登录、进入接诊界面、完成接诊信息编辑页、处方开具、医嘱、诊断处理、诊断记录。这里最核心的是“诊断处理”。医生接诊以后，先根据患者信息进行诊断处理，在此基础上，可能开处方，也可能只给出医嘱，或者两者都有。因此，“处方开具”和“医嘱”不是每次诊断都必然发生，更适合作为“诊断处理”的扩展功能：
处方开具 extend 诊断处理，医嘱 extend 诊断处理
管理员的功能比较简单，题干明确说有“管理用户、管理处方”等用例，这类用例通常直接和管理员角色建立关联即可，不需要强行画 include 或 extend。