1、軟體工程綜觀為何需要軟體工程n軟體工程是如何開發軟體的方法n資訊硬體日新月異，人們需要高品質且多功能性的軟體有效發揮硬體效用。n軟體已從單一程式演變成複雜系統。n單打獨鬥的開發方式已無法應付此種變化。n軟體工程愈來愈受到重視。軟體工程的重要性n軟體架構工程師與程式設計員有差異。n軟體架構工程師了解、設計系統而程式設計員撰寫程式。n系統開發勿採用土法煉鋼的方式，要有工法。n實踐軟體工程要成本與人力，但值得(在維護階段)。軟體開發的生命周期n 軟體規格建立n 軟體的設計與建置n 軟體測試驗收n 軟體維護更新軟體規格的建立n 軟體系統開發之前需要先進行需求分析並訂定功能。n 事先未規劃好軟體的功能，
2、會導致需求無限擴張。n 影響整個開發時程、資源、資金與成功與否。n 分析需求後，軟體功能已確定，接著系統設計。n 對軟體功能提出解決方案，同時設計軟體架構。n 複雜系統的開發可以切割成多個子系統再進行開發。n 同時由不同的開發者進行開發，最後再進行整合。n 可縮短期程，避免在發生錯誤時影響整個系統。軟體規格的建立n 規格產出後需檢視其中各子系統的關連性與介面設計是否合適n 模糊的規格需再次定義。軟體規格的建立專案發展(Project development)n 專案發展的過程通稱為專案生命週期發展（Project Life Cycle Develpment），以後簡稱為PLCD。n PLCD定
3、義軟體開發的過程，使軟體開發過程有跡可循。循序專案開發過程(Sequential PLC)n SPLC軟體開發過程分為幾個階段:n 專案開始（Project Initiation）n 系統分析（System Analysis）n 系統設計（System Design）n 系統實作（System Implementation）需求工程(Requirements Engineering)n 此階段得到系統的功能，以及使用上的限制條件。n 需求工程產出軟體系統規格：1.需求即客戶需求2.需求規格就是系統的功能與性能與效能規格3.軟體系統的規格屬於技術性的規格，是後續設計及製作的基礎。4.軟體系統規格
4、與需求規格有對應關係5.軟體系統規格涵蓋大部分細節。需求獲得策略1.由上而下(top-down)：從企業的觀點出發，整合各部門需求。2.由下而上(bottom-up)：從作業層次與部門的觀點出發。成效快成本低但容易忽略整合性。應用系統的需求n 系統規格經過確證(Validation)後才可定案。n 應用系統的需求會隨時間或環境改變。n 需求改變會造成系統設計及製作上的變更。需求分析流程n 一定要有領域的專家參與。n 先收集需求，再分析文件。n 消除互相衝突的需求或合併類似的需求。分析方法n分析方法：例如資料流(Data-flow analysis)。n分析結果的表示：例如資料流程圖。n系統模型
5、的規範：系統模型有既定的規範，使系統開發人員有統一的溝通標準。n語意資料模型(Semantic data model)：描述資料的型態與資料之間的關係。n圖示說明:n矩形代表所描述的資料項目n相連的橢圓形代表資料項目的資料屬性n菱形代表所連接的資料項目的關係n1:M代表一對多的關係，例如一張訂單可能會產生多筆製造單。Semantic Data Mode1需求的定義n 軟體系統的需求分功能性的需求（Functional requirements）與非功能性的需求（Non-functional requirements）。n 功能性的需求與軟體系統必須提供的功能相關。n 非功能性的需求涵蓋了與功能
6、無關的其他需求。n 需求的定義要有觀念性描述與技術細節。n 需求規格為了避免誤解，要使用正規的方式描述。描述需求規格常見的方式n 需求規格語言：特定的語法及語意描述需求規格。n 圖形表示法：以圖形的方式來描述需求規格。n 結構化的自然語言：以結構化的定義加強自然語言的描述能力。n 數學表示法：以正規化的數學表示法描述需求的規格。n 類程式敘述表示法：使用類似於程式語言的語法與語意(Pseudo-code)定義系統的作業方式。需求決定方法nJAD(Joint Application Design)：分析師、使用者、管理者都參與，由系統分析師主導。nJAD參與的人多，每個人發言的機會少，發言可能傾
7、向某一類意見，有人可能完全不發言，都是JAD的潛在問題。nGSS(Group Support System)：嘗試克服JAD的缺點，例如讓參與者可匿名的表達意見。nCASE工具：運用在系統開發初期。包括規劃的工具、繪圖的工具與雛形化的工具。n雛形系統(Prototyping)：建立簡易雛形系統以體驗系統的初步功能。透過雛形可評估某些較無法確定的需求。專案開始及系統分析階段n 專案開始：可行性評估n 開發需要成本，開發前要確定開發價值。n 系統分析：軟體開發生命週期(SDLC,Software development life cycle)的第一步。n SDLC先進行系統分析找出系統需求、初步設
8、計使用者介面。系統設計與實作n 系統分析師定義系統需求，軟體工程師再根據系統需求把系統設計出來。n 系統設計建立嚴謹的系統規格(Specification)n 系統設計可分成幾個步驟：u概念化設計（Conceptual Design）：系統功能的初步設計。u系統架構設計（Architectural Design）：循序架構還是物件導向的架構。u系統實作：撰寫程式、單元測試、系統整合。系統模型(System Model)n 模型描述真實世界的一部分，模型建立過程稱為塑模(modeling)。n 系統模型將需求結構化，更清楚地描述一個軟體系統。邏輯模型與實體模型n 系統分析與設計的各種模型分為邏輯
9、模型(Logical model)與實體模型(Physical model)。n 邏輯模型描述系統本身與功能，跟系統如何實作出來無關。n 基於邏輯模型，系統用什麼方式實作都可。n 邏輯模型也稱概念模型(Conceptual Model)或業務模型(Business model)n 實體模型加上實作的方法與技術，進一步描述邏輯模型的內容。n 實體模型必須考量技術限制，又稱為實作模型(Implementation model)或是技術模型(Technical model)。處理(Process)的概念n 處理是軟體系統的基本組成。把系統的處理都找出就能拼湊出系統。n 處理描述業務事件(busine
10、ss events)，處理資料成資訊。n 處理的塑模過程，除了解其特性與功能外，還要確立與周圍環境、其他系統，以及其他處理的關係。n 系統本身就是一個處理。系統與環境透過輸入與輸出溝通。n 處理代表輸入或發生了事件進而完成的一件工作。n 處理塑模同樣有邏輯處理塑模(Logical process modeling)與實體處理塑模(Physical process modeling)之分。n 邏輯處理說明完成什麼工作，實體處理則說明如何完成。資料流程圖(Data Flow Diagram,DFD)n 處理塑模是傳統的軟體工程。n 資料流程圖描述系統資料的流向，及其處理。n 資料流程圖的圖示：1.
11、圓角方形代表處理(process)。2.方形代表外部實體(external agents)，如資料來源(source)或是資料去處(sink)。3.開放區域代表資料儲存(data store)，表示檔案或資料庫。4.帶箭頭的線段表示資料流(data flow)、輸入，或輸出。資料流程圖的表示法n DFD表示法採用Gane&Sarson的圖示，DeMarco&Yourdon也提出類似的表示方式。處理(process)實體(entity)資料儲存區(data store)資料流處理(data folw)資料流程圖繪製的規則n 繪製資料流程圖必須遵循一些規則1。0.0process不正確的畫法Dat
12、a flow0.0process 正確的畫法Data flowData flow規則:一個處理不能只有輸出處理邏輯描述n 資料流程圖表達系統的處理，並標示出處理之間關係。n 每個處理內部詳細的運作邏輯並沒有記錄，要靠邏輯塑模(logic modeling)說明。n 不必跟程式語言有關。n 工具包括純粹結構化的語言描述、決策表(Decision table)、決策樹(Decision tree)與狀態變化圖(State-transition diagram)等。Level-0 DFDn Process 0由其他的處理組成。n Level-0 DFD是系統最頂層的處理表示。n 系統分析師可以進一步
13、分析系統，繪出Level-0、Level-1、Level-n的DFD。n DFD是一種系統化與結構化的系統分析方法。n DFD未說明處理發生的時間、資料量或是資料流發生的頻率n 許多細節沒有交待，DFD僅描述邏輯概念的資料流程。資料塑模(Data modeling)n 資料塑模針對系統資料的特性進行分析。n 資料塑模是所有塑模技術中最重要的：1.資料是系統的核心，由多個處理共用。2.資料塑模建立了後續實作的基礎。資料塑模的方法n 物件導向的分析與設計透過劇情(scenarios)與使用案例(use case)了解系統需求並找出系統資料n ER模型，實體(entity)是首先要找出的n 物件導向
14、模型，則是先找出類別(class)。資料塑模常用的方法n使用者面談：溝通找出關鍵詞彙，並了解名稱與術語代表涵義。n面談：直接詢問使用者或客戶有那些資料需要處理、儲存或產生。n檢視現有表單或報表：找出需要定義與處理的資料。n運用CRC、腦力激盪等找出實體或類別n運用CASE工具與反向工程(Reverse engineering)技術從既有的資料庫反推資料模型。系統設計n 需求分析得到軟體系統的具體規格文件。n 軟體系統的設計是系統實作前的步驟。n 將規格化的需求轉換成具體的系統設計藍圖。n 設計流程(Design process)分成幾個不同階段的細部設計。n 設計的優劣對於軟體系統影響很大n
15、設計流程因開發者的技能、偏好與背景而異。設計的流程1.架構設計(Architectural design)：決定子系統之間的關係。2.抽象規格(Abstract specification)：建立子系統的抽象規格。(抽象指規格的表示不受限於工具或實作方式，是較高層次的設計)3.軟體規格(Software specification)：軟體規格確定系統各部分的功能。4.介面設計(Interface design)：GUI設計或子系統間的介面設計，例如API的設計。設計的流程5.元件設計(Component design)：子系統內元件及其交互作用的設計。對於子系統的描述更詳細。6.資料結構設計(
16、Data structure design)：資料結構定義系統的各種資料，是實作時需要的資料。9.(Algorithm design)：演算法描述處理的邏輯，。常見的系統模型n 資料流程模型（Data flow model）：描述資料的流程，資料在各子系統的進出狀況。n 實體關係模型（Entity-relationship model）：描述系統的實體(entity)及實體間的關係。n 實體的涵意很廣，系統的人、事、物，甚至抽象的觀念，都可以是實體。n 結構化模型（Structural model）：描述系統內的所有組件，及之間的交互作用。物件導向和軟體系統的設計n 物件導向的設計方法成熟，可
17、簡化設計。n 良好的系統設計必須易懂、易維護、有彈性，子系統間要能密切合作，且相依性越少越佳。函數導向的設計n 函數導向的設計適用於共用資料少的系統。n 函數導向的設計，函數內部的演算方式是獨立的一個單元。n 如果共用資料多，軟體系統的維護會變得很複雜。函數導向設計的基本觀念1f1f3f2f4f5f6共用資料共用資料函數導向設計的步驟1.資料流程(Data-flow)設計：以資料流程圖描述資料在系統中被處理的過程，並找出負責處理的函數。2.結構化分解(Structural decomposition)：函數再分解成副函數(Sub-function)。3.細部設計：描述函數與次函數的細節，包括資
18、料的定義與程式的控制結構(Program control structure)。資料流程圖轉換成函數n 輸入資料的轉換：輸入的處理分解成細部的副函數。n 輸出資料的轉換：輸出資料的格式化與準備等分解成細部的副函數。n 資料的處理：資料輸入與輸出的處理之外的任何處理分解成細部的副函數。軟體設計的實務n 物件導向設計透過類別之間的繼承關係提升程式碼與設計的複用性(reuse)。n 有穩固的觀念與豐富的開發經驗，熟悉新的開發工具時所花的時間也會比較短處理設計n 對輸入、輸出、使用者介面、資料庫、互動等系統的組成都進行設計。n 系統內部的設計叫做系統的處理設計(process design)，是系統的
19、內涵(system internals)。n 應詳細地描述，讓程式碼的撰寫有所依據。處理設計的指引n 怎樣才是好的處理設計？完成的系統容易了解、修改。n 處理設計的指引：1.系統要有分解結構(factored)：系統應該要適度的分割，但又具高度的結合性。2.模組控制範圍(span of control)：父模組不要包含太多的子模組，會增加系統的複雜度。3.模組的大小：一個模組的程式行數目約在50100行。4.模組的結合性(cohesion)：模組的功能應該單純，不要包括多種功能。5.模組的共用：子模組的功能盡量讓其他模組共用。耦合(Coupling)的種類n 耦合性，系統模組之間的相關性，越低
20、越好。n 常見的耦合性：1.資料耦合(data coupling)：模組之間因交換資料產生耦合，以資料做為模組的溝通媒介可降低模組的連動性不高。2.戳記耦合(stamp coupling)：模組之間因交換資料結構產生連結，缺點是讓系統變複雜了。3.控制耦合(control coupling)：模組之間因交換控制資訊而產生耦合。4.共用耦合(common coupling)：模組使用全域資料(global data)而產生耦合。5.內容耦合(content coupling)：模組可以直接引用其他模組內部的內容。模組內涵的設定n 模組的執行細節可採用二種方式來描述：1.類程式碼(pseudoco
21、de):跟程式碼類似，但不像程式語言要求嚴謹的語法。2.那西史奈德門圖(Nassi-Shneiderman diagram):以圖示表達程式的執行流程。有模型再寫程式是軟體開發的正常流程n 已有程式碼再試著去建立模型，是為了讓軟體系統好維護。n 有些模型可以用來自動產生程式碼，節省軟體撰碼成本軟體設計與開發流程1專案開始專案啟動與規劃Logicaldesign建造需求發展Physicaldesign維護處理設計(Process design)n 系統分析階段繪製資料流程圖(data flow diagran)了解系統的處理(process)。n 設計的結果影響整個系統的建造。處理設計的考量1.
22、如何得到好的設計：結構化系統設計可以採用模組化方法(modularization)。2.結合度(cohesion)：系統的每一個元件專注於一種功能。3.耦合性(coupling)：系統中不同元件間的相依性。結構圖(Structure charts)n 以階層(hierarchy)的方式表示系統的組成。n 描述系統及其組成之間的關係。n 從結構圖裡可看到系統如何分成多個組成的內部結構。結構圖的圖示n 結構圖中的模組透過參數的傳遞溝通，以資料鍵(data couple)或旗標(flag)表示。n 資料鍵代表兩個模組之間交換的資料，以有箭頭線段的空心小圓圈表示，箭頭的方向表示資料的流向。n 旗標代表
23、兩個模組之間交換的控制資料，以帶有箭頭線段的實心小圓圈表示。n 模組(module)是形成結構圖的基本單元結構圖的慣用表示圖案Read XOpen APQXflagerrordatacouple預先定義的模組預先定義的模組內嵌的模組條件式的呼叫從資料流程圖到結構圖n 結構圖從資料流程圖轉換過來，方法有兩種：轉換分析(transform analysis)與交易分析(transaction analysis)。1.以交易為主的系統(transaction-centered system)：系統的主要功能是將資料傳到適當的目的地。2.以轉換為主的系統(transform-centered syst
24、em)：系統的主要功能是從現有的資料產生新的資料。使用者介面設計n 使用者介面設計是以使用者為中心的設計活動。n 完成設計以後可以建立雛形，做為初步評估的基礎。n 物件導向技術有兩個主要的影響：應用系統的資料模型與應用系統的開發。n 資料模型的影響來自於新的資料庫應用。n 系統開發的影響來自於軟體工程及圖型化使用者介面(GUL Graphical User Interface)的進展。物件導向軟體工程物件導向軟體工程n 1990年代物件導向分析與設計開始發展n 1994年IBM正要導入物件導向技術，發展SOM(system object model)n Booch的OO大作。n 物件導向編程觀
25、念大約在1970年代就有了n 物件導向的分析與設計方法，1990年代才開始出現。n 要認識物件導向的分析與設計方法，值得一讀的文章:Fichman,R.G.er al.“Object-Oriented and Conventional Fichman,R.G.er al.“Object-Oriented and Conventional Analysis and Design Methodologies,”IEEE Computer,OctAnalysis and Design Methodologies,”IEEE Computer,Oct.1992,pp.22-391992,pp.22-3
26、9.物件導向軟體工程n 先描述問題與需求以及軟體系統的功能。n 分析(analysis)的工作強調問題的探討。n 設計(design)強調解決的方法。n 物件導向分析與設計(object-oriented analysis and design)強調從物件(objects)觀點看問題(problem domain)與解決的方法(logical solution)。物件導向軟體工程n物件導向程式語言利用物件間的交互作用描述應用系統行為。n物件代表系統的一部分，複雜的系統以物件分，結構清楚。n透過繼承，類別可以重復使用其他類別裡的定義，代表程式單元的再使用(Reuse)；n對軟體工程而言，類別組成
27、的類別庫(Class library)，是程式再使用的基礎OO基本概念n建立新物件：新物件擁有類別定義的屬性與行為。n類別的繼承關係：一個類別的定義來自數個類別，稱為多重繼承(Multiple inheritance)。u 透過物件導向技術達到的軟體再使用。u 物件導向模型對於應用系統的描述自然有彈性。u 物件導向應用在軟體工程上，是軟體元件(Software Component)的再使用。u 大型的系統，找出共通的成分，再利用分工以加速系統開發。OO基本觀念n 物件導向技術以類別(class)與物件(object)的觀念為基礎，描述真實世界的事物。n 類別有強大的抽象化描述能力n 物件有互動
28、與動態特性。n 系統分析與設計是物件導向技術應用的領域之一。OO基本概念n 物件(Object)描述事物，形容實體的物質，也能說明抽象的觀念。n 電腦作業系統的視窗(Windows)環境，是物件導向技術的一種應用。n 視窗的視覺化使用者介面，可以完全用物件導向的觀念來說明。OO基本概念n 物件導向技術應用最廣的領域是程式設計。n 節省系統開發的成本。物件導向程式設計n 物件導向程式設計（OOP,Object-Oriented Programming），整合物件導向與程式設計兩種技術。物件與類別n 物件描述世界的事物，類別把物件分類。n 類別之間有關聯，物件之間也會有各種關係與互動n 分類就會產
29、生架構。n 問題分析後得到的類別與物件就形成了物件導向模型。物件是什麼？n 三個主要的特徵：1.身份（Identity）：標示物件。2.狀態（State）：物件的特性與狀況。3.行為（Behavior）：代表功能。物件圖示1 透過物件的行為來暸解其狀態行為狀態行為狀態物件甲物件乙方法與屬性n 物件的狀態用資料或資料結構來表示，資料在值上的變化表示物件狀態的改變，物件的狀態則稱為屬性(Properties&Attributes)。n 物件的行為用處理(Procedure)來表示。n 代表行為的處理常被稱為物件的方法(Method)。類別是什麼？n類別將物件分類。n同一類別的物件具有很多相同的特徵
30、。n類別是鑄造物件的模子，物件則是類別的實例（Instance）。n透過繼承(inheritance)定義新類別。新類別和舊類別之間就產生了subclass與superclass的關係。n繼承的好處是再利用(Reuse)，軟體再利用可提升開發生產力。程式語言的物件與類別n 類別定義抽象描述。n 物件屬於同一類別，表現出類別的屬性與行為。n 屬性是內涵，行為則像外在的表現。n 在Java裡頭用程式變數(program variable)來定義屬性。n 行為用Java的方法(method)來定義。n 類別定義物件的對外介面，說明物件提供的服務。程式中的類別與物件觀念n 物件是類別的實例（insta
31、nce）。n 類別是建立物件的架構或模子。n Java 程式中擔當大任的是物件。n 物件的建立包括兩個主要的步驟：1.參照變數(reference variable)宣告(declaration)2.建立物件物件的建立n 參照變數宣告：Java採用物件參照(object reference)來指名某一個物件。n 建構物件：類別實例化(class instantiation)，利用建構子(constructor)來產生類別實例，也就是物件。n 關鍵字new會使得系統傳回一個類別所屬物件的參照。n 物件建構過程中，一些內部成員是因建構子的執行而建立的。n 宣告和實例化兩個步驟在語法上可合併。n J
32、ava，垃圾回收(garbage collection)，物件佔用的記憶體空間，最後能回收。物件的成員與類別的成員n 物件是類別的實例，擁有類別的屬性與方法，是物件成員(實例成員，instancemember)。n 物件的屬性成員的內容值，決定了物件的狀態。n 方法成員則是同一類別的物件都相同。n 類別可以有不屬於任何物件的屬性成員，叫做靜態成員(static member)。物件的成員與類別的成員1 實例成員(instance member)靜態成員(static member)Instance variable Instance method staticvariable static m
33、ethod物件成員類別成員當物件建立時開始存在由類別提供當類別載入時開始存在 由類別獨自所有 利用物件參照來存取利用物件參照來存取 利用類別名稱或物件參照來利用類別名稱或物件參照來存取存取 物件導向資料模型n 資料模型描述應用系統的資料世界。n 物件導向資料模型（Object-Oriented Data Model）以物件為基礎，有繼承（Inheritance）、封裝（Encapsulation）與多形（Polymorphism）等特性。n 可用類別（Class）與型態（Type）分類物件。n 物件由屬性（Attributes）與方法（Methods）所構成的。物件與類別之間的關係n根型態(r
34、oot type)可簡化系統設計。n型態(type)與類別(class)：type是抽象的定義，類別含有實作的部份。n類別與物件的關係：依類別的定義產生物件。程式語言的資料模型n 程式語言的資料模型亦可描述結構複雜的資料。n 物件導向模型比較容易和程式語言整合。n 關聯式資料模型則需要轉換。n 程式語言所描述的複雜資料若無法透過關聯式資料庫管理系統處理，稱為impedance mismatch。n 物件導向資料庫系統沒有Impedance mismatch問題。封裝(Encapsulation)n 狀態必須藉由介面與行為才能了解，狀態的改變決定於物件的行為。n 封裝提供安全性，因為物件的狀態無
35、法被外界直接存取。繼承(Inheritance)n 物件共通的狀態或是行為，歸納在同一個類別內，可以簡化物件的定義。n 類別是物件的規格，物件是類別的實例化。n 繼承是指把類別共通點抽出定義在新類別內。n 繼承的好處:再使用(Reuse)節省重新定義類別的成本。多載(override)n 多載：多元性，指名稱相同的物件行為但具有不同的功能。物件導向軟體開發分析分析(analysis)(analysis)設計設計(Design)Design)建造建造(constructionconstructionProblem domainProblem domain Logical solutionLogi
36、cal solution codecode物件導向分析n 物件導向分析從需求分析開始，接著是功能塑模(functional modeling)、結構塑模(structural modeling)與行為塑模(behavioral modeling)。n UML的圖示在功能塑模時會針對業務處理(business process)找出使用案例，畫出使用案例圖(use case diagram)。甚至建立活動圖(activity diagram)。n 結構塑模的目的：找出基本的類別、類別的屬性，以及類別之間的關係。n 行為塑模的目的：找出類別的行為，常會繪製合作圖(collaboration diag
37、ram)或是循序圖(sequence diagram)之類的互動圖(interaction diagram)。需求分析n 需求文件文法分析1.名詞與名詞片語通常會成為物件(objects)或是屬性(attributes)。2.動詞與動詞片語通常會成為方法(method)或關聯(association)。3.帶所有格名詞通常是屬性而非物件。n 分析後可以從中得到類別與物件的資訊，CRC卡可以在此時使用。使用案例塑模n 使用案例塑模(use case modeling)是物件導向分析階段重要的工作，一個使用案例代表一種系統的使用情境。n 使用案例模型有多種actorn 找尋使用案例的方法：1.藉由
38、圖形使用者介面尋找。2.從目前使用的系統尋找。領域模型(Domain model)n 領域模型在結構塑模的過程中建立，得到概念式的類別圖。文法分析與CRC卡可在這個階段使用。n 分析階段主要目標:了解系統的業務處理細節。使用案例n 分析工作從需求的了解開始，在過程中建立使用案例(use case)。n use case是對領域處理(domain process)的文字描述n UML提供了use case的圖形表示法。n use case描述使用者運用系統的方式n use case多，代表使用者和系統的互動多。物件導向設計n 物件導向設計（Object-oriented design）以物件為基
39、礎n 軟體系統是有交互作用的物件組成n 物件具有特定的功能。n 物件具有狀態(State)與介面（Interface）n 狀態是物件的資料屬性。n 介面定義物件的操作。n 透過介面可了解或改變物件的狀態。物件導向設計1介面介面 介面介面 介面介面 物件甲物件乙物件丙狀態狀態狀態Booch物件導向設計的4個步驟1.訂出類別與物件：從問題的描述找出可能的類別與物件。2.定義類別與物件的涵義：從系統的使用過程建立類別與物件的涵意。3.找出類別與物件的關係：了解類別的繼承關係與物件之間的互動關係。4.實作(Implement)類別與物件：建立類別與物件的細節。RDD(RDD(responsibilit
40、y-driven design)的六個步驟1.找尋類別：從需求規格中萃取名稱或名詞片語，找出可能的類別。2.找出responsibilities：從需求規格裡含有動作的部分找出class的responsibility。3.找出collaborations：檢視每個responsibility，看是否需要其他classes的collaborations。4.定義hierarchies：建立類別階層架構。5.定義subsystems：繪出系統的collaboration graph。6.定義protocols：定義出class、subsystem與contracts的內涵。OOA與OODn OOA
41、與OOD各有系統化的方法。n 分析的工作注重使用者的需求與問題。n 設計則把需求的實作藍圖繪出，在滿足成本、效能與品質的條件下。n OOA與OOD的工作很多交錯之處，都可對應到設計模型的某一部分。n 設計時，對需求有了更深入的了解，再回到分析進行調整。抽象類別與具體類別n 次類別(Subclass)由現有的類別衍生出。n 繼承關係形成類別階層架構(class hierarchy)，分成兩大類：1.抽象類別(Abstract class)：規範其他類別的定義。2.具體類別(Concrete class)：用於建立物件。抽象設計n 設計是由下而上還是由上而下，並不一定n 可能是雙向同時進行，直到結
42、果令人滿意。n 抽象設計(Abstract design)是從具體設計(Concrete design)萃取共通點。n 具體設計是抽象設計的再使用並加上潤飾。塑模(modeling)n 塑模(modeling)是抽象化(abstraction)的能力:思考問題、尋求解答。n 分析複雜的問題，讓人易於了解，是抽象化的目的。n 從不同的角度將所要建置的系統抽象化，做為系統的藍圖。n 塑模，利用工具，可以降低成本並提昇效率。n 開發專案成功的主因:嚴謹的表示法、有效的工具。視覺化塑模n 視覺化(Visualization)表示法，一圖表示千言萬語。n UML(Unified Modeling Lan
43、guage)整合了視覺化塑模和物件導向分析與設計。n 一種軟體開發的新標準。n Rational Rose是完整支援UML的軟體工具。UML的歷史n 物件導向分析與設計的理論衍生出各種方法。n Rumbaugh的OMTn Jacobson的OOSEn Booch的方法n 這些方法，經過融合，在多人努力下，UML結合各家優點。n UML V1.0版，1997年交付OMG(Object Management Group)，標準化的基礎。n UML的分析與設計表示法的標準化包括模型、語法和圖示n 接受UML的越來越多，開始出現UML的軟體工具。軟體的開發n 傳統的瀑布式傳統的瀑布式(Waterfal
44、l model)的開發處理的開發處理RequirementsDesignImplementationVerificationMaintenancen 瀑布模型的階段區隔清楚n 然而實際開發時有許多無法控制的因素，以致很難清楚劃分階段。n 所以發展出改良的開發流程軟體的開發n 漸進式的軟體開發流程漸進式的軟體開發流程分析初步需求後即進行系統設計開發、完成系統初版、測試與修改，直到最終版產出。似乎有很高的效率，但有管理盲點存在需視軟體特性選擇合適的開發流程軟體的開發nRUP(RationalRUP(Rational Unified Process)Unified Process)uRUP是物件導向
45、式的開發方法。u運用RUP需先確定開發模式與流程。uRUP專案有四個階段：1 開始階段(inception)：評估專案是否要進行下一階段。2 細化階段(elaboration)：發展USE CASES，並構思軟體系統架構。3 建造階段(construction phase)：編程以完成大部份功能。4 轉換階段(Transition phase)：軟體產品交付。Rational Unified ProcessRational Unified Processn敏捷性的開發方式敏捷性的開發方式(agile development)(agile development)uXP(Extreme Prog
46、ramming)、FDD(Feature Driven Development)、DSDM(Dynamic Systems Development Method)等。u特性:適調力大，對需求改變回應迅速。nXP(ExtremeXP(Extreme Programming)Programming)u特徵：成對(pair)編程與測試驅動。u3個原則：持續測試、開發者開發、與使用者密切溝通。敏捷性的開發方式敏捷性的開發方式WholeteamCollectiveDwnershipTest-DrivenDevelopmentCodingStandardPairProgrammingRefactoring
47、SimpleDesignContinuousintegrationCustomerTestsSustainablePacePlanningGameSmallReleasesXP PracticesFrom:WWW.XP軟體的開發XP開發模型開發程序的反覆性n開發程序(Development process)，通常是反覆性的(Iterative)步驟。n開發初期先試著解決高風險的問題使系統易維護與擴充n 軟體開發的階段，都含有各種抉擇、調適和求證的過程。n 有關於系統的記載夠詳實，能幫助在每個過程中做到最精確的管理與聯繫。n 使系統易維護與擴充正UML能提供的。Rational Rosen描述軟
48、體系統有多種方式n一種事物從不同的角度看會呈現不同的風貌。n軟體開發有不同的階段工作，過程中都需要系統藍圖。nRational Rose的系統塑模1.使用案例模型(Use case model)：描述系統的行為，讓使用者了解系統的運作方式，讓開發系統的人認識系統的功能。2.類別圖(Class diagram)：類別的內涵與類別之間的關係代表系統的組成。3.順序圖(Sequence diagram)：使用案例模型的具體化，將系統內的行為以循序圖表示。4.狀態變化圖(State transition diagram)：狀態變化圖描述系統的行為。n 元件圖、部署圖，Rational Rose都支援n
49、 Rational的4+1 view n PowerDesigner是以BPM-OOM-CDM-PDM的方式，將大部分UML的支援集中在OOM，與整個開發流程結合在一起。n 如何把UML圖形融入物件導向分析與設計的過程中，在那一個階段該使用那一種圖形要了解。Rational Rose類別可以依照特性進一步分類n 類別圖(Class diagram)表示類別和類別之間的關係。1.實體類別(Entity class)：資訊與相關的行為，通常對應實際的事物或觀念。2.邊界類別(Boundary class)：負責系統內外之間的溝通，可描述系統的介面。3.控制類別(Control class):系統的控制邏輯物件導向分析與設計1BPMUse casemodelingClassdiagramsConceptualClass diagramcomponentdiagramdeploymetdiagraminteractiondiagramanalysisdesignRobustness analysisOOM軟體專案管理n 專案計畫書、成本預估、專案規劃、時程規劃、專案監控與評核、參與人員選擇等。專案成功因素n系統開發者對問題的深入了解。n專案的規劃與管理。n系統效率、正確性、是否容易維護。參考資料1.顏春煌編著，軟體工程理論與實務應用，碁峰資訊股份有限公司。
