健身房管理系统UML建模中GoF Observer Pattern的实现疑问

架构合理性确认 #

我认为Graphic Controller直接与模型（实体）通信并不合适，如果这个观点有误，请帮忙指正。

观察者模式落地疑问 #

如果采用让Application Controller实现观察者模式的方案，当Exercise状态变更时，该如何有效通知负责GUI视图输入输出、通过bean类与Application Controller通信的Graphic Controller？

补充说明：Application Controller负责执行业务逻辑，它通过bean获取Graphic Controller的数据，可执行拒绝请求、移除Exercise等操作，同时也能通过DAO类从数据库获取数据（本示例暂不讨论bean与DAO类的细节）。

第三种建模思路的可行性疑问 #

我提出了三种建模思路并附对应UML图，这里重点说明第三种：
引入ExerciseInventory类，它继承ExerciseCatalogue的exList（用于存储数据库中所有Exercise），并额外拥有activeExerciseList（存储状态为active的Exercise）。该类作为Concrete Observer监控每个Exercise的状态变化，进而更新activeExerciseList。但传统Observer Pattern中Concrete Observer与Concrete Observable（即Exercise实体）的 multiplicity 为1..1，而我的场景中是1..N的关系，不确定此方案是否可行。

内容的提问来源于stack exchange，提问作者LuX