軟體工程導論/UML/介紹
軟體工程師使用一種有趣的語言，叫做統一建模語言，簡稱UML。就像音樂家必須學習樂譜才能彈鋼琴一樣，我們需要學習UML才能進行軟體工程。UML在軟體工程過程的許多部分都很有用，例如：規劃、架構、文件或逆向工程。因此，值得我們花時間去學習它。
設計軟體有點像為好萊塢電影寫劇本。角色的特徵、動作和互動，以及他們環境中的相關組成部分，都需要仔細規劃。作為一個入門示例，讓我們考慮我們的朋友比爾，他是一個顧客，正在餐廳吃飯。他的服務員是萊納斯，他負責點餐和送餐。廚房裡是拉里，廚師。史蒂夫是收銀員。這樣，我們就為餐廳的運作提供了有用且易於獲取的資訊。
用例模型是系統預期功能及其環境的表示。軟體工程師首先繪製用例圖。所有參與者都用小棍人表示，所有動作都用橢圓表示，並稱為用例。參與者和用例透過線連線。通常還會有一個或多個系統邊界。參與者通常不屬於系統，因此繪製在系統區域之外。
用例圖非常簡單，即使是經理也能理解。但它們對於理解要設計的系統非常有用。它們應該列出系統中涉及的所有方以及系統應該能夠執行的所有主要動作。它們最重要的方面是你不會遺漏任何東西，而細節程度則並不重要，因為我們還有其他型別的圖來描述細節。
接下來，我們將繪製活動圖。活動圖對給定的用例提供了更多細節，並且通常描繪資訊流，因此也稱為流程圖。用例圖沒有時間順序，而活動圖有起點和終點，並且還描繪了決策和重複。
如果用例圖命名了參與者併為我們提供了劇本中每個場景（用例）的標題，那麼活動圖則講述了每個場景背後的詳細故事。一些經理可能能夠理解活動圖，但不要指望所有人都會。
完成活動圖的繪製後，下一步細化就是時序圖。在這個圖中，我們水平地列出參與者或物件，然後用水平線描繪物件之間來回傳遞的訊息。在這個圖中，時間始終向下發展。
時序圖是面向物件分析和設計中稱為過程的重要步驟。該圖非常重要，因為它一方面識別了我們的物件/類，另一方面也提供了每個類的成員方法，因為每條訊息都變成了一個成員方法。時序圖可能會變得非常龐大，因為它們本質上描述了整個程式。確保你的時序圖涵蓋所有路徑，但儘量避免不必要的重複。經理很可能無法理解時序圖。
協作圖是幫助我們從時序圖過渡到類圖的中間步驟。它與時序圖類似，但佈局不同。我們不再關注時間軸，而是關注物件之間的互動。每個物件都用一個方框表示，物件之間的互動用箭頭表示。
該圖顯示了物件的職責。如果一個物件承擔了過多的職責，意味著有太多線條進出方框，那麼你的設計可能存在問題。通常情況下，你希望將一個方框拆分成兩個或多個更小的方框。在這個設計階段，這仍然很容易做到。嘗試在開始編碼時或更晚的時候進行拆分，否則會變成一場噩夢。
對於我們這些軟體工程師來說，至少對於面向物件的軟體工程師來說，類圖是最重要的一個。類圖由類和它們之間的線組成。類本身用方框繪製，並分成兩個部分，一個用於成員方法，另一個用於屬性。
從協作圖開始，你首先要做的是將所有方框都稱為類。接下來，不要用多條線連線物件，而是用一條線代替。但是，對於每條刪除的線，你都必須在類的成員方法部分新增一個成員方法條目。因此，在這個階段，類圖看起來與協作圖非常相似。
使類圖不同的因素是屬性，以及不僅僅有一種型別的線，而是幾種不同的型別。至於屬性，你必須仔細檢視每個類並確定該類正常執行所需的變數。如果該類只是一個數據容器，這很簡單。如果該類執行更復雜的操作，這可能並不容易。
至於線條，我們稱之為物件之間的關係，基本上有三種主要型別
- 關聯（擁有）：靜態關係，通常一個類是另一個類的屬性，或一個類使用另一個類
- 聚合（包含）：例如，一個訂單包含訂單明細
- 繼承（是）：描述類之間的層次結構
完成類圖後，你就可以放鬆一下了：如果你有一個好的UML建模工具，只需點選“生成程式碼”按鈕，它就會用你最喜歡的程式語言為所有類建立包含成員方法和屬性的存根。順便說一下，不要指望你的經理能理解類圖。