系統開發 IV
系統開發 part IV
程式寫作
寫軟體程式，經常夾雜著個人的情緒，跟講話一樣。今天高興，程式寫的特別快，寫的天馬行空，寫的不知所云，因為等著下班趕快跟親愛的去約會。今天如果不高興，寫的程式就會變得思慮不周詳，這裡錯那裡錯，怪東怪西。
我們沒辦法控制程式人員的心情，只能期待他們每天都很穩定的工作，然後 趕快把進度趕完 。
How? 阿貝講到勞資雙方的心聲了嗎？
系統分析，軟體工程，的確還是有它的重要性，如果照前幾章的作法，至少可以減少錯誤率的發生，各部門把程式結合起來的問題也就減低很多。
阿貝碰過很多講了一口好技術的人，滿嘴的專有名詞，我只能望嘴興嘆，還是老老實實的做我的苦工吧，就如同第一章節所講的，我們肖年仔被老闆問了一堆 Agile, Scrum, , ,回來問阿貝，我只能雙手一攤，我不會。系統分析，軟體工程是很重要，GANTT & PERT 也很方便，但是試問真有公司每次都照表抄課嗎？上 ISO 9000 的每一家，執行作業程序都一樣嗎？所以我的建議是 系統分析多學習，多加揣摩，不要太拘泥在哪一個系統工程上。
我們開始來做一個範例，其實是阿貝早就寫好的程式。我們就假定是某一個程式設計人員PC寫的。
範例是在 command 底下寫好所有的需求，PC寫的程式，目的是要給其他的程式 ( 不在 command 裡面 )，傳回 obd 的指令，至於要不要執行 obd 指令，那就是 MiTronics 該做的事情，而 obd 底下，也同樣先寫好該執行什麼指令，要不要被執行，也是 MiTronics 的事情。 啊，看不懂？ 阿貝畫給你看。
關聯圖
OK, 稍微解釋一下下，我們現在看到的是 6 個模組 ( package ) 外加一個 resource property，主控模組是 MiTronics，由它來掌控所有的介面，由線路 1 .. 6 可以得到我們想要的答案，也就是說假定程式人員PC 撰寫 command 模組，那他就不要理會其他的模組，安安心心的寫他的那一部分，當主控端 MiTronics 跟他要資料時，他就負責回傳資料就可以了。
那問題來了，他怎知道要哪些資料?哪種規格？這個就是 properties 的設定。在 properties 這些檔案裡面，大家討論好 資料規格 就可以了，有需要就到裡面去拿。
例如有一個檔案叫 obd.properties，裡面有
obdReset=ATZ
Mitronics 下達指令，請 command 傳給我 odbReset 的 code ，然後 command 就回傳 ATZ，接著 Mitronics 在下達 Obd 去執行 ATZ，然後 Obd 就回傳結果給 Mitronics，主控端再來決定送出資料到 GUI 或是 Output。
好啦，我知道你有兩個問題 (至少)，
- 為什麼 Mitronics 不直接下 ATZ 就好？ 回答你，請看 系統開發 II 簡單化 Simplicity 。
- 為什麼 Obd 不直接被 command 呼叫就好了？ 可以，軟體系統工程跟企業結構很類似，看你要扁平化架構還是金字塔架構，隨你高興。阿貝知道越大的系統，形成金字塔結構的機率越高，相對之下，付出的成本越重。 debug 的時間越長。如果架構如上圖，當 command 有問題時，只要在這個模組裡面 debug 所有的程式就可以，這樣抓出問題來更快。 分類法則 Methodology 。
過兩天就分享程式出來，不要急。還是那句話，前面系統沒做好，後面程式就會亂寫一通，最後交差了事，萬一你老闆是箇中高手，你就會被 K 的滿頭包。
待續....
留言
張貼留言