彡工鸟 2018-12-13 17:48

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

UMLChina潘加宇:

彡工鸟:

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

UMLChina潘加宇:

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

彡工鸟:

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

UMLChina潘加宇:

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

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

彡工鸟:

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

UMLChina潘加宇:

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

彡工鸟:

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

UMLChina潘加宇:

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

彡工鸟:

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

彡工鸟:

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

UMLChina潘加宇:

彡工鸟:

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

彡工鸟:

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

UMLChina潘加宇:

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

彡工鸟:

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

UMLChina潘加宇:

这几个类就够了

彡工鸟:

，我好好消化一下

彡工鸟:

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

换成这样？

UMLChina潘加宇: