通过对2个主要用例进行语法分析，确认了潜在类。
然后分析这些类是否符合Coad和Yourdan提出的6个特性。派出了血糖仪，这里血糖仪作为外部接口接受血糖数据，
但由于不符合2，而且只有一个血糖信息，完全可以作为另一个类的属性。用户健康档案在本子系统不是必要需求， 故排除。血糖监测服务作为一个组织单元，完全可以通过血糖记录与其他类之间的合作实现，因此同样被排除。 由于血糖日记录、实时记录、月记录、周记录、血糖记录高度相似，这些潜在类只有时间与时间范围不同， 不符合多个属性的要求，故将这些记录类型合并，用函数参数来区分时间范围不失为更好的选择。
接下来通过定义属性与操作，绘制了一下UML的类图。运动管理子系统也是采用同样的流程。
| 潜在类 | 一般分类 | 适用的特征编号 |
|---|---|---|
| 子系统（血糖监测管理器**）* | 事物 | 接受：4不适用 |
| 病人 | 角色或外部实体 | 接受：1、3、6适用 |
| 实时血糖界面 | 外部实体 | 拒绝：1、3、4不适用 |
| 血糖记录界面 | 外部实体 | 接受：4不适用 |
| 血糖日记录 | 事物 | 拒绝：1、3、4不适用 |
| 血糖月记录 | 事物 | 拒绝：1、3、4不适用 |
| 血糖周记录 | 事物 | 拒绝：1、3、4不适用 |
| 血糖记录 | 事件 | 接受：都适用 |
| 血糖仪 | 外部实体 | 拒绝：1、6符合，2、3不符合 |
| 用户健康档案 | 事物 | 拒绝：6不适用 |
| 血糖监测服务 | 组织单元或外部实体 | 拒绝：6适用，但是1、2不符合 |
| 潜在类 | 一般分类 | 适用的特征编号 |
|---|---|---|
| 子系统(运动管理控制器) | 事物 | 接受，4不适用 |
| 用户健康档案 | 事物 | 接受，全部适用 |
| 运动记录 | 事件 | 接受，全部适用 |
| 运动方案 | 事物 | 接受，全部适用 |
| 运动历史界面 | 外部实体 | 接受，4不适用 |
| 运动方案界面 | 外部实体 | 接受，4不适用 |
| 发声警报（TODO） | 外部实体 | 接受，2、3、4、5、6适用 |
