彡工鳥 2018-12-13 17:48
潘老師，有空幫忙點評一下，謝謝
UMLChina潘加宇:
彡工鳥:
參數類型 更多的是表示分組，而參數規格是用于參數校驗的。。
資料上報的時候，可能與mi不是同一個時刻的，在可能在裝置端收集後統一發上來，是以不能合并
UMLChina潘加宇:
再思考一下，分組是對規格分組還是對參數分組
彡工鳥:
參數名和參數值一開始是沒有屬性的，感覺怪怪我就加上去了。參數名和狀态名都想表示不同時刻，可能擁有不同的值
對參數分組
狀态是裝置的狀态，模組也可以了解為參數那邊的分組，就是邏輯上劃分
UMLChina潘加宇:
我的意思是我的意見很可能是對的，你再好好思考一下
類比：商品-商品規格-商品類型
特别是，裝置直接連到事件類型，這個不會的。
規則是規則，遊戲是遊戲
就算有規則似乎是針對個體，其實也不是，仍然是針對群體。例如有一些特殊的規則适用于Xi總，那不是針對他個人，而是因為他的職位。隻不過這個職位目前隻有一個人。
你再仔細體會一下。
彡工鳥:
這個确實，我連的時候，也想了好久。。。
UMLChina潘加宇:
實在不行，你就當成是資料庫模組化 ，把你認為合适的資料庫模型發上來
彡工鳥:
這種可以合并麼？最開始通過用例分析的時候，分别是存在參數上報，狀态上報，事件上報三個mi的，然後對應自己的mi明細。現在合并成一個資料上報，再添加上報類型的描述
UMLChina潘加宇:
如實描述。合并成一個，上報，關聯到上報類型
彡工鳥:
謝謝，我再仔細體會一下，到時候同資料庫模組化一起發上來
彡工鳥:
潘老師，我重新再整理了一下，覺得這樣應該更合理。同時附上了資料庫模型，您再幫忙點評一下，謝謝！
UMLChina潘加宇:
彡工鳥:
1. 我是偷懶，是以直接用領域屬性的做主鍵的，實際上會單獨用ID
2. 适用那個，可以了解成同一型号的裝置，都有這些參數和狀态，之前是關聯到具體裝置，後來覺得應該是關聯到裝置型号
3. 右下角的事件，同樣是裝置上報的，事件差不多等同參數/狀态
彡工鳥:
潘老師，這個還是需要裝置ID吧，不然不知道是哪個裝置
UMLChina潘加宇:
已經關聯到上報了，又關聯一次不是重複了嗎
彡工鳥:
哦，那事件和狀态也是一樣處理才行
我想着這樣便利一點呢
UMLChina潘加宇:
這幾個類就夠了
彡工鳥:
，我好好消化一下
彡工鳥:
不過資料項不需要跟裝置，裝置型号關聯麼？因為還有反過來，修改裝置的資料項一說
換成這樣？
UMLChina潘加宇: