系統開發 II

系統開發 part II

接上次的章節，我們繼續給他操下去，首先阿貝要講明，這個不是上課，只是紀錄阿貝曾經做過的工作，再加上最近一些小鬼(這些陪著阿貝修車就開始的大學生，現在都退伍上班一陣子了)開始上班後遇到的瓶頸，我把它拿出來給他們看的，盡量用淺顯的文句寫給大家看。
上一章節，我們已經有了 初步 的 作業流程圖，也就是說在做系統分析前，最好習慣，先了解作業流程，系統分析的目的就是要 "強化，改變" 舊有的東東，不是嗎？
OK, 繼續看下去，概略分類子系統 經由兩個 PM 研究結果，決定中介介面採用 OBD 的晶片，其實 OBD 晶片內部也是寫好的韌體，公司也能自己開發，可是兩個 PM 盤算 Cost 的結果，認為買來還比較划算，而且不需要買整塊板子，只要買晶片就好了，然後晶片可以 boundle 綁在我們自己設計的板子上就可以了。

簡單化 Simplicity

注意，分析是簡單化，不是簡化 (abbreviation) ，簡單化是不可或缺的思考邏輯 (indispensable)，現在好像在讀英文書一樣，離提了，把腦袋轉回來！也就是說，如果 OBD 晶片不能滿足我們的需求，那該怎麼辦？ 這就好像 Java 程式裡面所設計的 "例外"，除了有 checked exception 還有 unchecked exception 啊。不要把你的小腦袋瓜搞的那麼複雜，前一陣子，阿貝家附近的肖年仔在問 Agile, Scrum, Waterfall, Kanban, 嗯，arguably，無庸至於，沒有一個是我懂的。

分門別類 Classification

現在開始重點來了，怎麼分類？

開始分類

src
	main
		java
			MiTronics
				command	(UI)
				gui	(GUI)
				obd	(interface)
				port	(uart usb)
				output	(print out)
				fault	(err msg)
		resources	(properties)
	test
		java
			MiTronics
				command
				obd
				port
				output
				fault
		resources

系統分析 System Analysis

我拿 Java 的馬糞 ( maven ) 做範例，我們分成 main 區 & test 區，這種系統設計跟以前其實沒兩樣， JAVA 多了 test 區， 通常是採用 JUNIT 或是 TESTNG 之類的測試環境 ( framework )。不是我們現在要討論的主題。

分類法則 Methodology

偷偷告訴你，沒有準則，只有經驗，日劇醫龍看過沒？ "教科書寫的，在真正的實例裡面很多是不會出現的"。以本範例 obd diagnose device，MiTronics 是我們的產品名稱也是主程式，斜體字 則是分類 package，() 內的粗體字 則是各個程式人員負責該小專案的負責範圍。

分工合作 Interoperability

簡單口語化一點，obd 是跟真正的 obd(elm介面) 接觸的 package 程式，port 做 obd 及 command / output 之間的溝通，gui 就是 gui，有任何問題就往 fault 丟。
那為什麼不直接就省略 obd package？用 port 就好。 省略 command / output package 直接就用 gui。 省略 fault 直接在程式裡面 print exception 就好。 自己想，我不會回答你 。我們繼續....
對於一個程式人員來說，他被配給到寫 port package，他只要專心寫作有關 port 這個 package 裡面的 classes 群組，要設想如何被 MiTronics 主程式呼叫，如何與 obd 溝通。 所以腦袋裡面應該存在著 class，而不是 instance，也就是至少會有以下的 classes

• Configuration
• ConnectObd
• SendCommand
• ReceiveData
• FaultMessage

所以可以去跟寫 obd package 的程式人員溝通一下，這時用 interface 就有用處了，如果你沒有用過 interface 就當我沒講。
待續....