OOP帶來的主要的優點及便利性
- 透過parent class以及 child class之間的關係(繼承)，來分享主要的物件屬性或特徵，這也是一個OOP的特色可以用來縮短開發時間以及更精確的進行coding。
- 物件設計時，是以責任區分方式進行設計(responsible for the object role)，所以可以避免不當的物件資訊被引用。
- 設計出適當的物件類別，將可以方便的把物件類別分享出來，給其他的系統使用，達成reusable的需要。
- 基於物件化觀念，我們可以自行設計出屬於自己想要的資料結構格式。
在OOAD的過程中，什麼叫做Object ?
- 其實object就是把資訊做一個群組化，把需要被保存或有特定操作方式的內涵給"抽象化"，將這些內容整併到一個物件類別中，做為與其他外部物件或者其他系統溝通的一個橋樑。
Project lifecycle
- Primary phase
- Analysis
- Requirement Analysis-這裡以個人經驗除了要做好需求管理及訪談內容以外，更重要的是要能一併進行系統測試驗證的準備，必須能很清楚知道到底設計出來的功能是否能滿足需求。
- System-Context Analysis-透過Use Case 與情境描述來勾勒出系統環境(system context)，對於系統外部的動作、訊息傳遞都要被好好定義下來。
- Model Analysis-modeling 不只是說明基本的物件類別設計圖，更是要依循不同的觀點來繪製相關圖表(ex, sd,collaboration,...etc)
- Design
- Architectural Design-定義最重要的系統架構設計決定-也是Design pattern最被廣泛使用的地方，在實體化架構設計上，我們通常會使用deployment diagram來描述，而軟體設計元件部分則使用component diagram，若要整體同時體現出這兩者則是以class diagram來定義出主要的活動物件。在所謂的設計階段中，最重要的就是設計這件事情本身是與"軟體"、"硬體"有高度相關的耦合程度在，就像我們不會拿weblogic來開發asp.net一樣，在這裡是最需要著墨的，也就是說每個系統設計師必須在真的進行coding之前，就該對即將使用的軟體或平台作一深刻的了解，不能半桶水一招半式闖天下，這樣只會讓問題更難解決。
- Mechanistic Design-顧名思義"機理"，在這階段的設計主要是要去描述或定義出物件之間的交互合作的行為，這些資訊一般可從class 定義可以看出端倪，並進而繪製Sequence Diagram or Collaborative Diagram。
- Detailed Design-定義最精確明細的物件行為以及物件結構(資料結構)，並透過Activity Diagram來完成描繪行為內容，通常也可搭配notations來輔助說明，Activity Diagram通常比較適合用於表達企業活動的工作流程關係，也適合表達細部程式的程序性結構。
- Development-像是在這階段去開發一些class, db definition, messaging system... etc.
- Implement
- Unit Testing-最基礎不過的單元測試，主要測試物件的內部結構以及功能運作是否正常。
- Integration Testing-整合測試，在多樣化的元件環境中併同其他相關功能一起測試，
- Validation Testing-驗證測試，驗證程式的功能以及規格是否符合原需求，並如同測試計畫的預期結果一樣。
- System Delivered-上線並提交相關手冊以及教育訓練。
- Analysis
- 知名的RUP分析方法定義了幾種專案運作階段，並明確的標示出實際的起始、結束時間以及相對應的產物，在每個階段當中都彙把專案團隊聚焦在相關的里程碑上。
- Inception-關注於專案範疇
- Elaboration-在這階段結束前，要盡可能的把需求內容定義完成
- Construction-軟體設計開發完成
- Transition-軟體提交與使用者
- RUP的精神講述現在的系統開發是以一種迭代(iterative)型式在進行的，同時也是強調sa,sd,coding是並行的一組開發組合，就像是一個framework一樣，整套一起跑，而專案經理在這時候最重要的關切點是"發行產品的日期"，所以其間所規劃的各項計畫時程安排，都必須考量到可度量的工作內容、彈性，對於專案成員也必須明確定義各自的責任與工作內容。(這部分可能要額外再找機會看了..內容太龐大)
沒有留言:
張貼留言