分析与设计阶段-–-物件导向分析(OOA)概要.ppt

分析與設計階段物件導向分析(OOA),綱要,分析與設計設計思維-SA/SDvs.Object-Oriented分析設計的”方法”物件導向分析階段(OOA)建立Use-Case模型(Use-CaseModeling)建立分析模型(ConceptualModeling)另一種OOA技術-CRCCards總結,一般的開發流程,文件的演進：由高階到低階(巨觀到微觀)分析階段的重點：規格文件的建置(通常基於特定技術),規格文件的撰寫,比起需求文件，規格文件必須以更正式、更嚴謹、更有系統的方式來呈現：避免任何不完整與矛盾的敘述可能為雙方制訂契約時的重要參考文件明確地描述出該產品所必須完成的事項例如：為了滿足某項需求，系統或軟體本身必須達成哪些功能或滿足某些條件(如：效率)。,(Cont.),重點在勾勒出需完成的事項，但不需涉及到如何完成這些事項的細節(tellwhat,nothow)。通常基於特定之分析技術,不論是結構化分析設計(StructuredAnalysis同義詞：程序(Procedure/Sub-Routine)、功能(Action)。在物件導向的領域中則常稱為：操作(Operation)、行為(Behavior)、方法(Method)或成員函式(MemberFunction)。,SA/SD之基本思維,把資料與處理程序分開思考,SA/SD相關技術,資料導向技術：設計的重心落在系統所需之資料結構例如：常應用在關聯式資料庫之實體關係模型(ERM)圖形表示法+正規化(Formalization)資料模型,(Cont.),程序導向技術：著重於處理的程序(以輸入/輸出為主體思考)例如：早期普遍被使用之資料流分析技術(DataFlowAnalysis)1.分析資料流(輸入輸出)形成高內聚力模組2.微調模組間的相依性降低模組間的耦合度在1&2過後(理論上)：模組“處理程序”,資料導向vs.程序導向,何者為優？為達某種程度的模組化效果，兩者似乎都難以避開進一步的調整動作何謂好的模組？模組內-高內聚力(Cohesion)模組間-低耦合度(Coupling),模組化的好處,易重複利用(MoreReusable)易維護減少錯誤的發生一個錯誤的發生不至於引發更多其他的錯誤(i.e.RegressionFaults)容易Debug易擴充,模組化的根本問題,減少相依性(Dependence)尤其是資料與程序之間的相依性,SA/SD技術的罩門,在SA/SD技術下(資料或程序導向)，開發者將陷入疲於化解資料與程序之間相依性的窘境。但由上例中，看起來似乎沒有想像中複雜？關鍵就在於：軟體需求的規模軟體規模越大相依關係的複雜度將越高,OOA/D之基本思維,把資料與處理程序一起思考,減少模組化的負擔,“資料抽象化”以及”封裝”等特性使程序與資料之間的相依關係，盡可能侷限在個別物件的範圍內。抽象化型別(AbstractDataType)利於產生高內聚力的模組物件之間有清楚的界線利於產生低耦合度模組,SA/SDvs.OOA/D,在過去的許多開發案例顯示，傳統的SA/SD技術在開發初期會比物件導向開發方式快很多，可是愈往後期階段，傳統開發方式往往會因為棘手的維護、修改或需求變更等問題，愈顯窒礙難行，最後終不及物件導向的方式。,分析與設計的”方法”,非正式方法沒有一定規則或形式(經驗導向)正式的方法俗稱“方法論(Methodology)”例如：OMT(ObjectModelingTechnique)OOSE(ObjectOrientedSoftwareEngineering)RUP(RationalUnifiedProcess),方法(論)之基本要素,表示法(Notation)：用來描述分析階段、設計階段，乃至於實作階段中的靜態結構(如：類別關係)或動態行為(如：物件互動關係)。例如：UML程序(Process)：即軟體生命週期模型(SoftwareLifeCycleModel)規範了各個階段所需完成的事項，以及各個事項完成的先後次序(涉及經驗法則)。,(Cont.),其他：方法論也可能搭配特定工具的使用。方法的好壞?各方評價不一(主觀因素居多),Note:本書並不針對特定之物件導向方法論或OOA/D技術做細部描述，而是根據OOA/D常見之步驟，整理出一套基本的流程以供參考。,物件導向之分析設計程序,表示法：UML回饋(Feedback)重覆往返檢視(IterativeProcess),分析階段(OOA)StepbyStep,建立Use-Case模型(Use-CaseModeling)(1)繪出Use-Case圖(亦稱為FunctionalRequirement)(2)撰寫相關的腳本(Scenarios)(3)建構活動圖(ActivityDiagram)建立分析模型(ConceptualModeling)建立初步的類別/物件圖(亦稱為Class/ObjectModeling),使用案例：飯店訂房系統,Case-Study：Use-Case模型,UseCases:訂房取消訂房Check-inCheck-out,訂房腳本,正常流程(Normal/MainFlow)：1.顧客以房型、時間範圍(起始時間和結束時間)向櫃臺人員要求訂房2.櫃臺人員查詢符合條件且為空房狀態之房間3.如果沒有符合條件之房間(A1)4.顯示符合條件之房間與價格5.顧客選擇要訂之房間並提供姓名、身份證號碼6.櫃臺人員設定該房間狀態為預定狀態7.如果顧客的基本資料未建檔(A2)8.櫃臺人員替顧客新增一筆訂房資訊(訂單)，以紀錄訂房日期和被訂之房間,訂房腳本(Cont.),替代流程1(AlternativeFlows)：A1.回到正常流程(步驟1)或放棄訂房A2.櫃臺人員以姓名、身份證號碼等個人基本資料進行建檔,取消訂房腳本,正常流程(Normal/MainFlow)：1.顧客以姓名和身份證號碼向櫃臺人員取消訂房2.櫃臺人員查詢該顧客之訂房資訊3.顯示訂房資訊4.顧客選擇要取消之訂房資訊5.櫃臺人員刪除該訂房資訊,Check-in腳本,正常流程(Normal/MainFlow)：1.顧客以姓名和身份證號碼向櫃臺人員要求Check-in2.櫃臺人員查詢該顧客之訂房資訊3.如果不存在訂房資訊(A1)4.顯示訂房資訊5.顧客選擇要入住之訂房資訊6.櫃臺人員查詢顧客之基本資料7.如果顧客的基本資料未建檔(A2)8.櫃臺人員顯示房間號碼並提供房間鑰匙9.櫃臺人員紀錄登記(Check-in)該房間的顧客,Check-in腳本(Cont.),10.櫃臺人員把該房間加到顧客的帳單上11.櫃臺人員設定該房間狀態為住房狀態替代流程1(AlternativeFlows)：A1.回到正常流程(步驟1)或取消Check-inA2.櫃臺人員以姓名、身份證號碼等個人基本資料進行建檔,Check-out腳本,正常流程(Normal/MainFlow)：1.顧客交還房間鑰匙要求Check-out2.櫃臺人員以房間鑰匙上之房間號碼查詢登記的顧客3.櫃臺人員查詢該顧客之帳單4.如果帳單顯示未付款(A1)5.櫃臺人員設定該房間狀態為空房狀態替代流程1(AlternativeFlows)：A1.顯示總額，要求顧客結帳後，修改帳單的付款狀態為已付款,活動圖(ActivityDiagram),在分析階段，活動圖常用來描述：(1)單一UseCase內部的流程(2)橫跨多個UseCases的流程活動圖並非絕對必要(扮演了輔助的角色)大部分的系統流程在UseCase腳本中就可以呈現出來。,針對訂房程序所繪之活動圖：,建立分析模型(ConceptualModeling),目標：決定系統初步的資料模型重點：捕捉核心概念(KeyConcept)選課系統中的”課程”訂房系統中的”房間”,(Cont.),可以UML的類別圖(ClassDiagram)/物件圖(ObjectDiagram)來呈現分析模型：類別與屬性主要來自問題領域中的”核心概念”(不包括設計階段所需之類別，如：特定的資料結構)類別之間的關係由UML所定義之連結關係(Association)來描述類似實體關係圖(Entity-RelationshipDiagram)決定出類別之間的繼承關係(如果有的話),建構流程,Note：通常客戶端不能夠理解的類別，便不該出現在此模型中。,A.整理輸入文件,輸入的文件可以是：原始的需求文件重整(Formalized)過的文件Use-Case的腳本,B.捕捉候選類別,名詞擷取法(NounExtraction)以(需求)文件中的名詞來擷取類別的方法名詞擷取法的優點簡單易用不需要特別技術或特定領域的專門知識(DomainKnowledge)適合經驗不足的初學者,名詞擷取步驟,(1)決定輸入文件建議採用UseCase腳本(2)從文件識別出相關的”名詞”或”詞組”為方便識別，通常會把名詞改成不同的字體(3)去掉重複的部分，形成一組名詞集合這些名詞(項目)便是潛在的類別或屬性(4)過濾程序排除不必要之名詞(如：同義詞、輔助詞),C.決定類別關係,簡易處理步驟：(1)列出所有的候選類別。(2)選定(固定)一個類別，考慮該類別與其他類別之間的關係，若有關係，則建立兩類別間之連結關係(Association)，包括多重性(如：一對多、多對一、多對多.等關係)。(3)重複步驟2，直到所有類別都考慮過了。Note:可一併決定類別間的繼承關係(如果有的話)。,D.檢視程序,目的：進一步檢視候選類別的完整性主要工作：再次詳細檢視，並補足遺漏的類別需求文件中所規範的相關條件或限制(Constraints)可一併考慮進來。決定名詞項目為類別或屬性？基本上，之前收集到的名詞項目均被定義成獨立的類別。不過，有時名詞項目也適合充當屬性。,(Cont.),Note：名詞項目該歸為類別?屬性？通常，除非能確定該名詞項目所代表的只是單一的數值或字串，否則最好還是讓該名詞項目當成類別。,Case-Study：建立分析模型,A.以Use-Case腳本當作輸入文件B.名詞擷取：以訂房腳本為例，把擷取到的名詞部分以粗體表示(表見下頁)。整理後(去掉重複部分)可得名詞項目：顧客、房型、時間範圍、起始時間、結束時間、櫃臺人員、條件、空房狀態、房間、價格、基本資料、訂房日期、訂房資訊、訂單、房間狀態、預定狀態、正常流程、姓名、身份證號碼。,訂房腳本,正常流程(Normal/MainFlow)：1.顧客以房型、時間範圍(起始時間和結束時間)向櫃臺人員要求訂房2.櫃臺人員查詢符合條件且為空房狀態之房間3.如果沒有符合條件之房間(A1)4.顯示符合條件之房間與價格5.顧客選擇要訂之房間並提供姓名、身份證號碼6.櫃臺人員設定該房間狀態為預定狀態7.如果顧客的基本資料未建檔(A2)8.櫃臺人員替顧客新增一筆訂房資訊(訂單)，以紀錄訂房日期和被訂之房間,訂房腳本(Cont.),替代流程1(AlternativeFlows)：A1.回到正常流程(步驟1)或放棄訂房A2.櫃臺人員以姓名、身份證號碼等個人基本資料進行建檔,(Cont.),以此同樣手法套用在其他三組腳本，整理後可得名詞項目：顧客、房型、時間範圍、起始時間、結束時間、櫃臺人員、條件、空房狀態、房間、價格、基本資料、訂房日期、訂房資訊、訂單、房間狀態、預定狀態、正常流程、姓名、身份證號碼、房間號碼、房間鑰匙、帳單、住房狀態、總額、付款狀態。(名詞擷取後的相關腳本如下黑色粗體為去掉項目),取消訂房腳本,正常流程(Normal/MainFlow)：1.顧客以姓名和身份證號碼向櫃臺人員取消訂房2.櫃臺人員查詢該顧客之訂房資訊3.顯示訂房資訊4.顧客選擇要取消之訂房資訊5.櫃臺人員刪除該訂房資訊,Check-in腳本,正常流程(Normal/MainFlow)：1.顧客以姓名和身份證號碼向櫃臺人員要求Check-in2.櫃臺人員查詢該顧客之訂房資訊3.如果不存在訂房資訊(A1)4.顯示訂房資訊5.顧客選擇要入住之訂房資訊6.櫃臺人員查詢顧客之基本資料7.如果顧客的基本資料未建檔(A2)8.櫃臺人員顯示房間號碼並提供房間鑰匙9.櫃臺人員紀錄登記(Check-in)該房間的顧客,Check-in腳本(Cont.),10.櫃臺人員把該房間加到顧客的帳單上11.櫃臺人員設定該房間狀態為住房狀態替代流程1(AlternativeFlows)：A1.回到正常流程(步驟1)或取消Check-inA2.櫃臺人員以姓名、身份證號碼等個人基本資料進行建檔,Check-out腳本,正常流程(Normal/MainFlow)：1.顧客交還房間鑰匙要求Check-out2.櫃臺人員以房間鑰匙上之房間號碼查詢登記的顧客3.櫃臺人員查詢該顧客之帳單4.如果帳單顯示未付款(A1)5.櫃臺人員設定該房間狀態為空房狀態替代流程1(AlternativeFlows)：A1.顯示總額，要求顧客結帳後，修改帳單的付款狀態為已付款,過濾程序,在過濾程序中去除掉的名詞項目有：櫃臺人員(為系統參與者-actor，系統中並沒有實體存在)條件、正常流程(語言描述之輔助用語)空房狀態、預定狀態、住房狀態(都是用來表示房間狀態)基本資料(與顧客同義)訂單(與訂房資訊同義)房間鑰匙(不在此軟體系統中)剩下的名詞項目(候選類別)如下：顧客、房型、時間範圍、起始時間、結束時間、房間、價格、訂房日期、訂房資訊、房間狀態、姓名、身份證號碼、房間號碼、帳單、總額、付款狀態,C.初步的候選類別以及類別之間的關聯性,D.檢視程序,把需求文件中不包含在腳本的相關條件跟限制(Constraints)一併考慮進來：(1)考慮需求文件中有關房間型態(房型)的資訊價格住房人數：單人房、雙人房、四人房景觀：山景、海景(2)考慮需求文件中有關顧客的基本資料姓名、身份證號碼、性別、電話、住址、出生日期(3)考慮需求文件中有關房間狀態房間狀態：空房狀態(初始狀態)、預定狀態、住房狀態(4)考慮需求文件中有關帳單資訊總額、付款狀態、房間(Check-in的房間),(Cont.),檢視過程中發現了遺漏之名詞項目：住房人數、景觀、性別、電話、住址、出生日期至目前為止捕捉到的所有名詞項目有：顧客、房型、時間範圍、起始時間、結束時間、房間、價格、訂房日期、訂房資訊、房間狀態、姓名、身份證號碼、房間號碼、帳單、總額、付款狀態、住房人數、景觀、性別、電話、住址、出生日期,(Cont.),考慮以下名詞項目為類別屬性：起始時間、結束時間、價格、訂房日期、房間狀態、姓名、身份證號碼、房間號碼、總額、付款狀態、住房人數、景觀、性別、電話、住址、出生日期剩下來的(核心)類別：顧客、房型、時間範圍、房間、訂房資訊、帳單,類別模型(第二次整理),再次提醒,往返檢視的過程無所不在！回饋(Feedback)再一次的檢視:由訂房腳本及Check-in腳本中可以發現到，兩者均具備替顧客基本資料建檔的程序。考慮新增一個建立顧客基本資料的Use-Case,訂房系統Use-Case模型(第二次整理),另一種OOA技術-CRCCards,類別-責任-協同合作卡Class-Responsibility-Collaboration(CRC)Cards透過”集體研討”的過程來捕捉類別、類別關係，進而建構出類別模型。,How?,Step1:在分析的過程中，準備