軟體工程書摘與心得 Part 2：物件導向軟體工程之另類思考

延續上篇，當我們有完整的需求分析後，接下來就是要實作程式碼。這部分我跳過很多，直接把我認為重要的拿出來。當類別圖畫好後，接下來就是要畫出序列圖（Sequence Diagram），之後對使用者案例進行健全性分析，最後連接上對於該程式的領域模型，之後軟體內類別和類別的關係大抵上就確定了。

物件導向的另類思考流程圖

至於什麼是序列圖？就是在一個動作中，列出參與該動作的物件，隨著動作進行時，找出物件和物件之間的交互子動作，直接看例子：

Sequence_diagram_for_handling_a_browser_request_using_the_Model_View_Controller_MVC_pattern

上圖中顯示要「處理來自瀏覽器的請求」時，所需要做的動作和參與的對象，隨著動作開始進行，首先Browser會發出HTTP GET Request()給Tomcat，之後就持續做一連串的動作，直到整個流程被完成。序列圖的好處是(1)知道參與者有哪些，(2)子動作其實會對應到所實作的函數，能很直覺地反映出程式該怎麼寫。

另外還有一個是健全性分析（Robust Analysis），他是把「分析的模型轉換成設計的模型」。依據使用案例模型，輸入使用案例、使用案例的情況（Scenarios）、使用案例對應的活動圖（Activity Digram），以及領域模型，輸出成以UML表示的合作圖（Collaboration Diagram）來記載，裏頭會有3種主要的設計成員：

1. 邊界物件（Boundary Objects）：用來描述系統與角色之間的互動
2. 實體物件（Entity Objects）：用來描述系統中經常存在的資訊（Persistent Information）
3. 控制物件（Control Objects）：用來描述對於其他物件的控制、安排，或是協調

使用健全性分析是幫助釐清目前定義的類別是否足夠、角色定義是否明確，可能在進行健全性分析的過程中會發現更多的物件或是新的屬性類別，然後用來重新繪製序列圖，所以序列圖的建立不是一次就完成的，是需要經過多次迭代的。

我覺得最厲害的還是序列圖，他可以直接讓我知道怎麼寫程式，同時又能了解物件的互動，真的很值得學習。

下一篇要介紹當軟體完成時怎麼做系統組態的管理與維護，如何讓軟體能適時地反映使用者的成長

軟體工程書摘與心得 Part 1：為何需要軟體工程＆軟體工程之簡介

最近閒來無事去看了Livecoding.tv上程式設計師表演打code，就覺得怪了為何你腦袋能源源不絕想出接下來要做什麼，從這頁面又跳到下個頁面，雖然我也能看懂你在做啥，可是自己就不一定能這樣行雲流水般地打code（苦笑）。後來想想應該是我缺乏軟體工程上的訓練。

不然別人是怎麼會想說這邊要用這個protocol？下一個地方要用這個函數銜接？在軟體工程中我從這本書找到了答案：

根據書中解釋，1960年代末期由北約召集科學家探討「軟體危機」的問題，討論如何有更好的軟體開發方法來提升開發的效率、節省開發成本，同時獲得良好的軟體系統品質，因而催生了軟體工程的發展。對我來說寫軟體就如同建造房子，從畫藍圖、打樑樁等都有一套步驟和分析的方法，都需要投入大量的精力來完成。

而這也是會和有些人能把程式寫得穩健、可靠、可擴充，就是有進行完整的系統分析、需求了解、介面設計等才能達到一定品質。隨著軟體漸趨複雜，光是作業系統就可高達上千萬行程式碼，如何做好軟體開發就需要系統工程的幫忙，並借助軟體系統開發方法論，然後選擇軟體開發程序：

1. 傳統階梯式的軟體開發程序：做好需求分析後，設計系統與軟體的架構，之後進行系統製作與局部測試，最後整合測試後就可上線使用還有維護
2. 漸進式的軟體開發：透過需求分析後快速產生原型，之後陸續迭代產生新產品
3. 需求規格化的軟體開發程序：將軟體系統的規格以數學模型來表示，之後自動轉成程式碼
4. 組合式的軟體開發程序：分別完成系統內的各個元件，之後再組合起來

而隨著物件導向的盛行，也陸續產生新的開發方法（其實也很久的東西了）：

1. RUP (Rational Unified Process)：結合螺旋式、反覆式及漸進式的開發方法，主要分成「開始階段」、「細化階段」、「建置階段」、「轉換階段」四種
2. 敏捷開發：像是XP（Extreme Programming）、Scrum等

方法演進後手上的工具也不能輸人啊！因此就有電腦輔助軟體工具（CASE, Computer-Aided Software Engineering）的出現，早期CASE工具出現時人們的期望很高，認為可以大幅下降軟體開發成本，但當時的CASE工具並不成熟，沈寂了一段時間後大家才開始陸續使用，大家常用的IDE就是一個典型例子。

仔細回想起來，目前有很多火紅程式教學的網站，大家都用得開心，可是真的要開發一套系統就只能坐在電腦前打不出任何東西，一部分可能是程式技巧不足，另一部分就可能是缺乏軟體工程的訓練。當了解軟體工程時，就能超越一般的程式設計師成為軟體工程師，就像是從一位工人進化到建築師，從只會寫程式變成能洞悉大局、了解如何規劃與參與軟體開發的各個階段的「高級程序員（猿）」。

下一篇將會介紹軟體系統的需求工程，如何找到需求並把需求轉成軟體架構、規格就需要這篇啦～

The Pragmatic Programmer : from journeyman to master 書摘

我們，採集的只是石頭，卻必須時時刻刻展望未來的大教堂。

                                                                                                                —採石工人的信條

1. 第一章：注重時效的哲學
• 負責你的代碼，不要找蹩腳的藉口
• 不要容忍破窗戶：有問題就及時修改，別累積技術債
• 做團隊裡「做變化的催化劑」：提供大家改變的契機，讓大家追隨你而改變
• 永遠記住大目標，要見樹並見林
• 使質量成為需求問題：讓你的用戶參與權衡
• 定期為你的知識資產做投資
• 批判地分析你讀到的和聽到的
• 你說什麼和你怎麼說同樣重要：交流、知道你要說什麼、瞭解聽眾、選擇文件的風格和美觀
2. 第二章：注重實效的途徑
• 不要重複你自己：和重用（Reuse）差別在，重複（Repeat）在於你做了同樣的事情，你應該只做一次卻做了很多次，造成時間和成本浪費；而重用則是再次利用優秀的程式碼來達到效率上的精進。
• 讓重用變得容易（Make It Easy to Reuse）
• 消除無關事物之間的影響：提升系統各組件的正交性（即降低耦合性）
• 有正交性的好處：提高生產率、降低風險、項目團隊、設計
• 編碼：讓代碼解藕、避免使用全域變數、避免相似的函數
• 可撤銷性：不要存在最終決策，你的產品隨時隨地都有可能砍掉重練
• 使用曳光彈來幫助你找到目標：和原型製作的差異在於曳光彈代碼是完整的，之後會構成最終系統的骨架的一部分
• 用戶能及早看到能工作的東西
• 開發者建構了一個他們能在其中工作的結構
• 有了集成的平台
• 為了學習而製作原型：原型所具備的元素有
• 正確性
• 完整性
• 健壯性
• 風格
• 靠近問題領域編寫程式（Program Close to the Problem domain）：選擇特定語言或是編寫特別定義過的程式來解決問題
• 估算以免發生意外
• 理解提問內容
• 建立系統的模型
• 把模型分解為組件
• 給參數指定值
• 估算項目進度
3. 第三章：基本工具
• 用純文本保存知識（Keep Knowledge in Plain Text）
• 利用命列Shell的威力（Use the Power of Command Shells）
• 用好一款編輯器：好的編輯器應該具有以下特性
• 可配置：可高度客製化
• 可擴展性
• 可編程性
• 總是使用原始碼控制工具
• 要修正問題，而不是發出指責
• 不要恐慌
• 將你的數據視覺化
• 跟蹤
• 使用橡皮鴨：向別人解釋你的程式碼，讓別人像鴨子一樣一直點頭，直到問題出現
• 消除過程
• Select沒有問題
• 不要假定，要證明
• 學習一種文本操縱語言
• 撰寫能撰寫程式碼的工具
4. 第四章：注意時效的偏執
• 你不可能寫出完美的軟體
• 使用DBC按照合約設計：
• 前條件
• 後條件
• 類別不變項

（未完.....）