第 1 部分 - 物件導向的分析與設計
1. 物件導向的思維
物件導向思維是物件導向建模的基礎，這是本文的核心內容。它涉及透過將問題和概念分解為組成部分並將這些部分視為物件來理解問題和概念。
- 定義：物件導向思考意味著將各種元素視為離散的物件。例如，在軟體系統中，一則推文、一個使用者或一個產品都可以被視為物件。
- 屬性與行為：
- 屬性：物件的屬性或特徵（例如人名、年齡、身高）。
- 行為：物件可以執行的操作（例如，裝置開機或關閉、使用者登入）。
- 好處：
- 組織：物件封裝了資料和行為，將相關的細節和功能保存在一起。
- 靈活性：可以獨立於其他物件對物件的屬性或行為進行變更。
- 可重用性：物件可以在程式的不同部分甚至不同程式中重複使用，減少需要編寫和維護的程式碼量。
2. 軟體流程設計
設計階段在軟體開發生命週期中至關重要。它確保最終產品滿足用戶要求並按預期運行。
- 軟體開發過程：軟體開發過程是迭代的，涉及幾個關鍵階段：
- 需求收集：了解客戶或使用者對軟體的需求。
- 概念設計：發展高階設計輪廓與模型。
- 技術設計：為每個組件建立詳細規格。
- 實作：依照設計寫實際程式碼。
- 測試：驗證軟體是否正常運作並滿足要求。
- 部署：發佈軟體以供使用。
- 維護：持續更新和錯誤修復。
- 設計的重要性：跳過或不充分地解決設計階段可能會導致專案失敗。堅實的設計基礎可確保軟體開發在正確的軌道上開始，並降低以後進行代價高昂的變更的風險。
三、要求
需求收集是專案成功的基礎。它涉及了解客戶或用戶對軟體的需求。
- 定義：需求是軟體必須滿足的條件或功能。
- 啟發：
- 客戶訪談：與客戶直接討論，以了解他們的願景和需求。
- 問捲和調查：從潛在使用者或利害關係人收集結構化資訊。
- 觀察：觀察使用者如何與目前系統交互，以確定需求和痛點。
- 研討會：與利害關係人舉行協作會議，收集需求並確定優先順序。
- 權衡：客戶可能需要平衡不同的需求和限制。例如，他們可能需要在更多功能或更快交付之間進行選擇。
範例：設計房屋時，建築師透過詢問有關房主對房間大小、佈局和特定功能的偏好的詳細問題來收集要求。這有助於防止施工過程中發生代價高昂的變更。
4. 設計
軟體開發中的設計涉及創建指導實施階段的概念和技術藍圖。
- 概念設計：
- 定義：軟體主要組件及其職責的高階概述。
- 模型和線框圖：在詳細工作開始之前幫助利害關係人理解和批准設計的視覺表示。
- 職責：定義軟體每個元件該做什麼。
- 範例：
- 模型：使用者介面的視覺佈局，顯示螢幕的外觀和功能。
- 線框圖：顯示組件佈局的簡單草圖或圖表，沒有詳細的設計元素。
- 重要性：確保所有利害關係人對軟體的高階結構有清晰的理解和一致性。
範例：在建造房屋時，概念設計概述了房間的整體佈局及其連接，但尚未詳細說明管道或佈線。
- 技術設計：
- 定義：每個組件的詳細規範，包括它們如何建構和互動。
- 技術圖表：詳細繪圖顯示組件如何組合在一起以及資料如何在它們之間流動。
- 組件分解：進一步將高階組件分解為較小的、可管理的部分，直到每個部分都可以實現。
- 範例：
- 類別圖：顯示類別的結構、屬性、方法和關係。
- 序列圖：說明物件如何在特定事件序列中互動。
- 組件圖：描述組件之間的組織和依賴關係。
- 重要性：為開發人員提供有效編寫程式碼所需的詳細信息，並確保整個開發團隊的一致性。
範例：在房屋建造中，技術設計指定了牆壁、地板和屋頂的確切材料，以及管道和電氣系統的詳細計劃。
5. 需求和設計的妥協
在整個設計過程中，通常需要做出妥協，以平衡客戶需求和專案限制。
- 溝通：與客戶的持續回饋循環對於確保設計與他們的願景和約束保持一致至關重要。
- 迭代審核：依照客戶的意見定期審核和完善設計。
- 原型設計：建構元件的早期版本，以與客戶一起測試和驗證想法。
- 返工：如果不符合要求或證明不可行，概念設計和技術設計都可能需要修改。
- 靈活性：隨著新資訊的出現或需求的發展，對變化和調整持開放態度。
- 影響分析：評估變更對整個專案的潛在影響，以做出明智的決策。
範例：如果客戶想要一個開放式廚房，但結構需要需要支撐梁，建築師和客戶必須找到一個折衷方案，既能保持結構完整性，又能滿足客戶的審美偏好。
6. 品質屬性設計
設計軟體涉及平衡各種品質屬性，以滿足功能和非功能要求。
- 品質屬性：影響軟體效能、可用性和可維護性的特性。
- 效能：軟體執行任務的速度和效率。
- 安全性：為保護軟體免受威脅和漏洞而採取的措施。
- 可擴充性：軟體處理增加的負載或使用量的能力。
- 可維護性：軟體更新或修改的容易程度。
- 可用性：使用者學習和使用軟體的難易度。
- 權衡：平衡這些屬性通常涉及權衡，因為最佳化一個屬性可能會影響其他屬性。
- 效能與安全性：增強安全措施有時會降低效能。
- 可擴充性與可用性：新增功能以提高可擴充性可能會使使用者介面複雜化。
- 上下文：軟體的特定上下文會影響這些屬性的平衡方式。
- 關鍵系統：將可靠性和安全性置於其他屬性之上。
- 消費性應用：強調可用性和效能，以提高使用者滿意度。
範例：設計前門時，平衡安全性（堅固的鎖）和便利性（易於進入）至關重要。鎖太多，門安全但不方便，鎖太少，方便但不安全。
7. 班級責任合作者 (CRC) 卡
CRC 卡是一種用於在設計過程中識別和組織類別、其職責和協作者的工具。
- 定義：CRC 卡有助於視覺化和組織不同類別的職責以及它們之間的互動方式。
- 類別：代表系統中的一個物件或概念。
- 職責：定義類別知道什麼和做什麼。
- 協作者：與該類別互動的其他類別。
- 用法：
- 腦力激盪：幫助團隊集思廣益並確定必要的類別及其角色。
- 設計會議：促進有關班級職責和互動的討論。
- 文件：用作捕獲設計決策的文檔工具。
- 流程：
- 辨識類別：列出系統中涉及的所有潛在類別。
- 定義職責：寫下每個類別的主要職責。
- 識別協作者：確定每個類別需要與哪些類別互動以履行其職責。
- 好處：
- 清晰度：提供清晰簡潔的方式來組織和傳達設計理念。
- 靈活性：隨著設計的發展，易於更新和修改。
- 協作：透過輕鬆討論和完善設計決策來增強團隊協作。
範例：在銀行應用程式中，「帳戶」類別的CRC 卡可能會列出「管理餘額」和「追蹤交易」等職責，以及「客戶」和「交易」類等協作者.
8. 原型設計與仿真
原型設計和模擬技術用於在流程的早期測試和完善設計，有助於在全面開發之前識別和解決問題。
- 原型製作：
- 低保真原型：軟體或特定組件的簡單、粗糙版本，通常使用紙張或基本數位工具創建。
- 高保真原型：與最終產品非常相似的更詳細和互動版本。
- 目的：驗證設計概念、收集使用者回饋並識別可用性問題。
- 方法：
- 紙質原型：建立使用者介面和互動的手繪草圖。
- 數位原型：使用軟體工具建立互動模型和類比。
- 模擬：
- 定義：運行模型來測試設計在各種條件下的行為和表現。
- 用例：評估系統效能、負載測試和驗證設計決策。
- 好處：
- 早期驗證：在全面開發之前識別潛在問題。
- 具有成本效益：透過及早解決問題來降低代價高昂的變更風險。
- 使用者回饋：允許使用者與原型互動並提供有關功能和可用性的回饋。
- 工具：各種軟體工具和平台可用於建立原型和運行模擬。
範例：在最終確定房屋設計之前，建築師可能會建造一個小型模型或使用軟體模擬來視覺化佈局並識別空間利用和設計的潛在問題。
以上是物件導向設計注意事項|部分-的詳細內容。更多資訊請關注PHP中文網其他相關文章！
