今天花了點時間看了物件導向分析與設計,看了前四章的感覺是,這本書花了很多時間在指導我們如何分析客戶的需求,如何寫出良好的 user cases ,當然對於程式的封裝也有稍微提及。
不過今天要介紹的是UML圖
UML
是系統分析以及設計的重要產物,也是實作以及測試的依據。
下面這張圖是 head first 物件導向分析與設計裡面的一個 sample,
使用者希望能有一個 Remote 能夠在按下按鈕的時候, DogDoor 會打開/關閉,
然後也希望家裡的狗 Bark 的時候, DogDoor 可以 Recognize 是自己家的狗然後開門。
上圖中 Remote -> DogDoor 之間的數字 1 代表著
Remote has 1 個 DogDoor
相同的 BarkRecognizer also has 1個 DogDoor
DogDoor has n 個 Bark 而DogDoor 可以在 allowedBarks的屬性裡儲存任意數量的Bark
看完了UML圖以及解釋之後接下來就是實作部分
Sample Code
Bark.java
public class Bark { /** * @param args */ private String sound; public Bark(String sound) { this.sound = sound; } public String getSound() { return sound; } public boolean equals(Bark bark) { if(bark.getSound().equals(this.sound)) return true; return false; } }
BarkRecognizer.java
public class BarkRecognizer { /** * @param args */ private DogDoor door; public BarkRecognizer(DogDoor door) { this.door = door; } public void recognize(Bark bark) { java.util.List<Bark> allowedBarks = door.getAllowedBarks(); for (Bark allowedBark : allowedBarks) { if(bark.equals(allowedBark)) { door.Open(); return; } } System.out.println("Door is not Open"); } }
DogDoor.java
public class DogDoor { /** * @param args */ private List<Bark> allowedBarks = new ArrayList<Bark>(); private boolean Open=false; public void Open() { System.out.println("Door Open"); final Timer timer = new Timer(); timer.schedule(new TimerTask(){ @Override public void run() { // TODO Auto-generated method stub Close(); timer.cancel(); } },5000); } public void Close() { System.out.println("Door Close"); } public boolean IsOpen() { return Open; } public void addAllowedBark(Bark bark) { allowedBarks.add(bark); } public List<Bark> getAllowedBarks() { return allowedBarks; } }
Remote.java
public class Remote { /** * @param args */ private DogDoor door; public Remote(DogDoor door) { this.door = door; } public void pressButton() { if(door.IsOpen()) door.Close(); door.Open(); } }
接著拿出head first 裡面所提供的測試檔案
Test
public static void main(String[] args) { // TODO Auto-generated method stub DogDoor door = new DogDoor(); door.addAllowedBark(new Bark("rowlf")); door.addAllowedBark(new Bark("rooowlf")); door.addAllowedBark(new Bark("rawlf")); door.addAllowedBark(new Bark("woof")); BarkRecognizer recognizer = new BarkRecognizer(door); Remote remote = new Remote(door); System.out.println("Bruce starts barking."); recognizer.recognize(new Bark("rowlf")); System.out.println("Bruce has gone outside..."); try{ Thread.currentThread().sleep(6000); }catch(InterruptedException ex) { } System.out.println("Bruce's all done..."); System.out.println("but he's stuck outside..."); Bark smallDogBark = new Bark("open the door"); System.out.println("A small dog starts barking."); recognizer.recognize(smallDogBark); System.out.println("Bruce starts barking"); recognizer.recognize(new Bark("rowlf")); System.out.println("Bruce's Back inside"); }
Result
Bruce starts barking.
Door Open
Bruce has gone outside...
Door Close
Bruce's all done...
but he's stuck outside...
A small dog starts barking.
Door is not Open
Bruce starts barking
Door Open
Bruce's Back inside
Door Close
結論
這次展示了如何從UML 到程式的coding
UML就有點像是蓋房子之前的藍圖,
有了藍圖就可以降低user想蓋巴黎鐵塔結果developer卻蓋出金字塔的問題。
我想這對user 來說應該也算是一大福音吧 XD
UML 適合大型系統, 而且重點做 UML 的人需要有決定權, 腦袋也要夠清楚, 不然也是一場災難
回覆刪除hmm...有道理
刪除不過...我是覺得UML可以當作RD之間溝通的工具,敏捷開發的時候總是會先討論出個架構,然後才下手,我覺得這個可以當粗稿