分析及设计阶段-物件导向分析(OOA).pptVIP

第七章 分析與設計階段 – 物件導向分析(OOA) 軟體工程 -物件導向程式設計與UML系統分析實作 綱要 分析與設計 設計思維- SA/SD vs. Object-Oriented 分析設計的”方法” 物件導向分析階段 (OOA) 建立Use-Case模型 (Use-Case Modeling) 建立分析模型 (Conceptual Modeling) 另一種OOA技術 - CRC Cards 總結 一般的開發流程 規格文件的撰寫 比起需求文件，規格文件必須以更正式、更嚴謹、更有系統的方式來呈現： 避免任何不完整與矛盾的敘述 可能為雙方制訂契約時的重要參考文件 明確地描述出該產品所必須完成的事項 例如：為了滿足某項需求，系統或軟體本身必須達成哪些功能或滿足某些條件(如：效率)。 (Cont.) 重點在勾勒出需完成的事項，但不需涉及到如何完成這些事項的細節 (tell what, not how)。 通常基於特定之分析技術 分析階段相關技術 正規的方法 有限狀態機(Finite State Machine) Petri nets 半正規的方法(介於正規非正規之間) 實體關係模型 (Entity-Relationship Modeling) 結構化系統分析(Structured System Analysis) 物件導向分析(OOA) – 本書重點 非正規的方法 自然語言 (Cont.) 不同的技術直接反映了文件的呈現方式 正規的方法 精確度高 有利正確性(Correctness)的理論證明 較嚴謹 可降低後期開發成本 (錯誤率低!) 不易學習、難以使用 難以跟客戶端溝通 (Cont.) 非正規的方法 (自然語言) 易學易用 容易跟客戶端溝通 無法對規格文件有精確的描述，易造成文件的不完整、混淆以及矛盾等問題。 半正規的方法 比較折衷的技術，例如： 實體關係模型(ERM) 物件導向分析(OOA) 非物件導向不可? 答案是否定的！ 事實上，早期大多數成功的案例，皆採用了SA/SD技術(非物件導向)。 但隨著軟體規模的日益膨脹，早期的方法(SA/SD)似乎不再能應付日趨複雜的軟體需求?! 長久以來驗證的結果，物件導向技術似乎更適用於現今的軟體需求！ SA/SD vs. 物件導向(OOA/D) 根本差異：設計的思維~ SA/SD： 「資料」與「處理程序」分開思考 OOA/D： 「資料」與「處理程序」一起思考 資料與處理程序 資料：程式運作時所需之資料結構 區域變數、全域變數、動態資料、檔案…等 處理程序：程式運作(執行)之指令片段 通常稱為函式(Function); 同義詞：程序(Procedure/ Sub-Routine)、功能(Action)。 在物件導向的領域中則常稱為：操作(Operation)、行為(Behavior)、方法(Method)或成員函式(Member Function)。 SA/SD之基本思維 把「資料」與「處理程序」分開思考 SA/SD相關技術 資料導向技術： 設計的重心落在系統所需之資料結構 例如：常應用在關聯式資料庫之實體關係模型(ERM) 圖形表示法 + 正規化(Formalization) ? 資料模型 (Cont.) 程序導向技術： 著重於處理的程序 (以輸入/輸出為主體思考) 例如：早期普遍被使用之資料流分析技術(Data Flow Analysis) 1.分析資料流(輸入輸出) ? 形成高內聚力模組 2.微調模組間的相依性 ?降低模組間的耦合度 在1 2過後(理論上)：模組 ? “處理程序” 資料導向 vs.程序導向 何者為優？ 為達某種程度的模組化效果，兩者似乎都難以避開進一步的調整動作~ 何謂好的模組？ 模組內 - 高內聚力(Cohesion) 模組間 - 低耦合度(Coupling) 模組化的好處 易重複利用(More Reusable) 易維護 減少錯誤的發生 一個錯誤的發生不至於引發更多其他的錯誤 (i.e. Regression Faults) 容易Debug 易擴充 模組化的根本問題 減少相依性(Dependence) 尤其是「資料與程序之間」的相依性 SA/SD技術的罩門 在SA/SD技術下(資料或程序導向)，開發者將陷入疲於化解「資料與程序之間相依性」的窘境。 但由上例中，看起來似乎沒有想像中複雜？ 關鍵就在於：軟體需求的規模 軟體規模越大 ? 相依關係的複雜度將越高 OOA/D之基本思維 把「資料」與「處理程序」一起思考 減少模組化的負擔 “資料抽象化”以及”封裝”等特性使「程序與資料之間的相依關係」，盡可能侷限在個別物件的範圍內。 抽象化型別(Abstract Data Type)利於產生高內聚力的模組 物件之間有清楚的界線