所在位置:答疑 - 内容   
设备数据上报的类图
 

彡工鸟 2018-12-13 17:48

潘老师,有空帮忙点评一下,谢谢

UMLChina潘加宇:

彡工鸟:

参数类型 更多的是表示分组,而参数规格是用于参数校验的。。
数据上报的时候,可能与mi不是同一个时刻的,在可能在设备端收集后统一发上来,所以不能合并

UMLChina潘加宇:

再思考一下,分组是对规格分组还是对参数分组

彡工鸟:

参数名和参数值一开始是没有属性的,感觉怪怪我就加上去了。参数名和状态名都想表示不同时刻,可能拥有不同的值
对参数分组
状态是设备的状态,模组也可以理解为参数那边的分组,就是逻辑上划分

UMLChina潘加宇:

我的意思是我的意见很可能是对的,你再好好思考一下
类比:商品-商品规格-商品类型
特别是,设备直接连到事件类型,这个不会的。
规则是规则,游戏是游戏

就算有规则似乎是针对个体,其实也不是,仍然是针对群体。例如有一些特殊的规则适用于Xi总,那不是针对他个人,而是因为他的职位。只不过这个职位目前只有一个人。
你再仔细体会一下。

彡工鸟:

这个确实,我连的时候,也想了好久。。。

UMLChina潘加宇:

实在不行,你就当成是数据库建模 ,把你认为合适的数据库模型发上来

彡工鸟:

这种可以合并么?最开始通过用例分析的时候,分别是存在参数上报,状态上报,事件上报三个mi的,然后对应自己的mi明细。现在合并成一个数据上报,再添加上报类型的描述

UMLChina潘加宇:

如实描述。合并成一个,上报,关联到上报类型

彡工鸟:

谢谢,我再仔细体会一下,到时候同数据库建模一起发上来

彡工鸟:

潘老师,我重新再整理了一下,觉得这样应该更合理。同时附上了数据库模型,您再帮忙点评一下,谢谢!

UMLChina潘加宇:

彡工鸟:

1. 我是偷懒,所以直接用领域属性的做主键的,实际上会单独用ID
2. 适用那个,可以理解成同一型号的设备,都有这些参数和状态,之前是关联到具体设备,后来觉得应该是关联到设备型号
3. 右下角的事件,同样是设备上报的,事件差不多等同参数/状态

彡工鸟:

潘老师,这个还是需要设备ID吧,不然不知道是哪个设备

UMLChina潘加宇:

已经关联到上报了,又关联一次不是重复了吗

彡工鸟:

哦,那事件和状态也是一样处理才行
我想着这样便利一点呢

UMLChina潘加宇:

这几个类就够了

彡工鸟:


,我好好消化一下

彡工鸟:


不过数据项不需要跟设备,设备型号关联么?因为还有反过来,修改设备的数据项一说

换成这样?

UMLChina潘加宇: