標籤:9.png 設計模型 專註 社會 識別 相容性 展現 inux 資料庫
好了,你現在會了物件導向的各種文法了, 但是你會發現很多同學都是學會了物件導向的文法,卻依然寫不出物件導向的程式,原因是什麼呢?原因就是因為你還沒掌握一門物件導向設計利器, 此刻有經驗的人可能會想到瀑布模型、螺旋模型、反覆式開發法、敏捷、RUP等一堆軟體工程相關的軟體開發流程,但對於大部分人來說這些流程僅僅只是專案管理上的流程.
本節我們就來瞭解下,作為一名程式員基於物件導向開發程式的開發流程:
需求模型->領域模型->設計模型->實現模型
一,需求模型
1. 需求VS功能
需求:客戶想要的效果,對客戶有價值的事情功能:系統為了實現客戶的價值而提供的能力/功能舉例: 汽車:駕駛是需求,刹車、加速、轉彎是功能 印表機:列印是需求,進紙、設定、與電腦串連等是功能 pos機:買單是需求,商品掃描、金額匯總、收銀等是功能
2. 需求的重要性
1/3的項目失敗或陷入困境是因為需求原因導致的garbage in,garbage out垃圾上了生產餅乾的流水線,最後產出的是像拉吉一樣的餅乾
修複需求錯誤的問題成本極高
1 編碼階段修複發現一個錯誤耗費人類是1個單位2 測試階段修複需求錯誤的成本是5-10倍3 維護階段(產品上線後),修複需求錯誤成本是20倍ps:在需求階段修複錯誤,成本只需要0.1-0.2即可結論:需求錯了,幾乎要把軟體項目重做一遍
3. 需求分析的目的
1 記錄員,記錄客戶的需求2 分析員,和客戶一起分析,完善需求3 引導員,能夠引導客戶的需求
4. 需求分析的方法
需求分析518方法,簡稱我要發,具體就是5w1h8c
5w + 1h屬於功能屬性 8c屬於品質屬性 5w:
when:使用者想在什麼時間用,例如半夜備份的任務,很明顯我們得知該需求需要自動化執行where:使用者想在什麼地方用,例如垃圾桶室內和室外的區別,同樣的事物放到不同地方用肯定不一樣who:使用者想讓誰來用,不僅是人,也可以是一個系統what:使用者想要我們程式的輸出結果是什麼,片,文檔,系統why:問一問使用者為什麼要這麼做,(你不問,他基本不說),包括客戶所有覺得不爽的事情ps:why是核心
1h:how
8c:8個constraint約束
效能performance 效能是系統提供相應服務的效率。主要包括回應時間、輸送量 效能是很多系統架構設計的關鍵約束條件之一 例如,同樣一個web網站,雖然都是提供資訊給使用者流量,設計一個日訪問量1w的網站與日訪問量10億的網站,二者的設計截然不同成本cost 成本指為了實現系統而需要付出的代價 成本也是很多系統架構設計的關鍵約束之一 例如客戶只願意花100w,而我們卻設計了一個耗費1000w的系統時間time 指客戶要求什麼時候交付可靠性reliability 指系統長時間正確啟動並執行能力,銀行、證券、電信這些公司,對宕機時間要求很嚴格安全security指對資訊安全的保護能力,涉及到錢、身份證、社會保險號等需求對這個要求很高合規性compliance 指滿足各種行業標準、法律法規、規範等,例如3C、SOX、3GPP,ITUT技術性technology 有的客戶可能要求我們採用某種技術 例如客戶現在都是windows伺服器,要求我們基於windows平台開發相容性compatibility指我們的產品與客戶其他已有的產品或系統的相容能力,要知道現在很少有產品是孤立啟動並執行,特別是在大企業、大公司中,多個系統都是相互互動、互相配合的。新的系統必須能夠和已有的系統配合,否則將無法運行
5,需求模型之用例的寫法
5.1 寫用例的技巧
三段法:NEA1 正常處理(normal):分析正常流程2 異常處理(exception):分析每一步異常情況和對應的處理3 替代處理(alternative):分析每一步是否有其他替代方法,以及如何做
5.2用例的書寫格式
#1. 用例名稱一般情況下,用例名稱即需求名稱#2. 情境情境即用例發生的環境,正好對應5w中的:when,where,who#3. 用例描述描述詳細的用例內容,對應5w中的what和how即使用者應該怎樣做,以及每個步驟中的輸出,但不要求每個步驟都有一定的輸出,可以有也可以沒有,也可以有多個#4. 用例價值描述用例對應的客戶價值,對應5w中的why#5. 約束和限制即真箇需求流程中相關的約束和限制條件,對應518方法中的8C
5.3 用例編寫案例
#用例名 答題系統#情境: when:8.10開始 where:西安 who:linux學院,網路客戶#用例描述:linux學院提供50道題每個客戶無需輸入任何個人資訊就可以參與答題,隨機播放20道題,給客戶回答,每道題5分, 3.答題結束後,輸入手機號,提交,算總分60分參與抽獎,<60分贈送基礎視頻#使用者價值: 答題有獎,答題提交時輸入自己的手機號擷取成績,獲得潛在客戶的連絡方式,為後期將客戶轉成學員做準備#約束: 暫無
二,領域模型
需求分析階段不區分物件導向還是面向過程
領域模型是完成從需求分析到物件導向設計的一座橋樑
領域模型定義:
領域模型是對領域內的概念或現實世界中對象的可視化表示,又稱為觀念模型,領域物件模型,分析物件模型 它專註於分析問題領域本身,發掘重要的業務領域概念,並建立業務領域概念之間的關係
領域模型主要兩個作用:
1 發掘重要的業務領域概念2 建立業務領域概念之間的關係
歸納領域建模的方法:
1 從用例中找名詞(找完後需要刪除不是領域對象的名詞,具體刪除什麼,與不同領域有關,沒有統一標準,靠經驗)2 加屬性(有些屬性並沒有在用例中明確給出,靠行業經驗自己添加)3 連關係(畫UML圖)
三,設計模型
物件導向類設計的具體步驟 第一步:領域類映射(不是全盤拷貝) 類篩選:並不是每個領域類都會出現在軟體中 名稱映射:對應 屬性對應:對應,照搬 提煉方法:領域類中並沒有方法,在用例中找動詞 第二步:應用設計原則和設計模式 第三步:拆分輔助類(領域類可以在實現階段拆分為幾個類)
四,實現模型
選取一種支援物件導向的語言實現我們的設計,比如c++,java,python
五,答題系統案例第一步,需求分析(寫用例)
#用例名 答題系統#情境: when:8.10開始 where:西安 who:linux學院,網路客戶#用例描述:linux學院提供50道題每個客戶無需輸入任何個人資訊就可以參與答題,隨機播放20道題,給客戶回答,每道題5分, 3.答題結束後,輸入手機號,提交,算總分60分參與抽獎,<60分贈送基礎視頻#使用者價值: 答題有獎,答題提交時輸入自己的手機號擷取成績,獲得潛在客戶的連絡方式,為後期將客戶轉成學員做準備#約束: 暫無
第二步:領域模型(找名詞,加屬性,連關係===》出圖
2.1 找名詞:
找名詞:linux學院,題,客戶,得分,獎,視頻#篩選:去掉與領域無關的名詞。視頻應該算作一種獎品linux學院,題,客戶,得分,獎
2.2 加屬性:
#加屬性加屬性名稱詞 屬性 備忘linux學院 NA 對於答題系統來說,並不需要linux學院的屬性,因此在領域模型中,linux學院是沒有屬性的題 題目編號,題目類型,題目描述,答題選項,正確答案,分數客戶 客戶編碼,姓名,性別,年齡,手機號答題記錄 記錄編號,客戶編碼,題目編號清單,總分數,時間 通過答題記錄就可以知道使用者是誰,以及使用者答過的題目獎品 獎品編號,獎品名字
2.3 連關係:
#連關係:畫圖1:答題記錄是客戶與題的關係類,而客戶與獎品之間可以建一個關係類,這樣以後單查關係類就可以知道誰得了什麼獎品2:找動詞: 建立題目 隨機播放題目 答題 提交 算總分 抽獎
2.4 出圖
第三步:設計模型
第四步:實現模型
連結: https://pan.baidu.com/s/1jHYFKWI 密碼: wimc
六,UML圖 UML-Unified Model Language 整合模組化語言,又稱標準建模語言。是用來對軟體密集系統進行可視化建模的一種語言。UML的定義包括UML語義和UML標記法兩個元素。 UML是在開發階段,說明、可視化、構建和書寫一個物件導向軟體密集系統的製品的開放方法。最佳的應用是工程實踐,對大規模,複雜系統進行建模方面,特別是在軟體架構層次,已經被驗證有效。整合模組化語言(UML)是一種模型化語言。模型大多以圖表的方式表現出來。一份典型的建模圖表通常包含幾個塊或框,連接線和作為模型附加資訊之用的文本。這些雖簡單卻非常重要,在UML規則中相互聯絡和擴充。主要模型
在UML系統開發中有三個主要的模型:UML圖功能模型 從使用者的角度展示系統的功能,包括使用案例圖。UML圖物件模型 採用對象、屬性、操作、關聯等概念展示系統的結構和基礎,包括類圖、對象圖、包圖。UML圖動態模型 展現系統的內部行為。 包括順序圖表、活動圖表、狀態圖。
圖的功能
綜述 UML是資料庫設計過程中,在E-R圖(實體-聯絡圖)的設計後的進一步建模。要瞭解一下UML設計中有的圖例及基本作用。首先對UML中的各個圖的功用做一個簡單介紹:使用案例圖 描述角色以及角色與用例之間的串連關係。說明的是誰要使用系統,以及他們使用該系統可以做些什麼。一個使用案例圖包含了多個模型元素,如系統、參與者和用例,並且顯示了這些元素之間的各種關係,如泛化、關聯和依賴。類圖 類圖是描述系統中的類,以及各個類之間的關係的靜態視圖。能夠讓我們在正確編寫代碼以前對系統有一個全面的認識。類圖是一種模型類型,確切的說,是一種靜態模型類型。類圖表示類、介面和它們之間的協作關係。對象圖 與類圖極為相似,它是類圖的執行個體,對象圖顯示類的多個對象執行個體,而不是實際的類。它描述的不是類之間的關係,而是對象之間的關係。包圖 包圖用於描述系統的分層結構,由包或類組成,表示包與包之間的關係。活動圖表 描述用例要求所要進行的活動,以及活動間的約束關係,有利於識別並行活動。能夠示範出系統中哪些地方存在功能,以及這些功能和系統中其他組件的功能如何共同滿足前面使用使用案例圖建模的商務需求。狀態圖 描述類的對象所有可能的狀態,以及事件發生時狀態的轉移條件。可以捕獲對象、子系統和系統的生命週期。他們可以告知一個對象可以擁有的狀態,並且事件(如訊息的接收、時間的流逝、錯誤、條件變為真等)會怎麼隨著時間的推移來影響這些狀態。一個狀態圖應該串連到所有具有清晰的可標識狀態和複雜行為的類;該圖可以確定類的行為,以及該行為如何根據當前的狀態變化,也可以展示哪些事件將會改變類的對象的狀態。狀態圖是對類圖的補充。順序圖表(順序圖) 順序圖表是用來顯示你的參與者如何以一系列順序的步驟與系統的對象互動的模型。順序圖可以用來展示對象之間是如何進行互動的。順序圖將顯示的重點放在訊息序列上,即強調訊息是如何在對象之間被發送和接收的。共同作業圖表 和順序圖表相似,顯示對象間的動態合作關係。可以看成是類圖和順序圖的交集,共同作業圖表建模對象或者角色,以及它們彼此之間是如何通訊的。如果強調時間和順序,則使用順序圖表;如果強調上下級關係,則選擇共同作業圖表;這兩種圖合稱為互動圖。構件圖(元件圖表) 描述代碼構件的物理結構以及各種構建之間的依賴關係。用來建模軟體的組件及其相互之間的關係,這些圖由構件標記符和構件之間的關係構成。在元件圖表中,構件是軟體單個組成部分,它可以是一個檔案,產品、可執行檔和指令碼等。部署圖(配置圖) 是用來建模系統的物理部署。例如電腦和裝置,以及它們之間是如何串連的。部署圖的使用者是開發人員、系統整合人員和測試人員。部署圖用於表示一組物理結點的集合及結點間的相互關係,從而建立了系統物理層面的模型。
一:這十種模型圖各有側重
1:使用案例圖側重描述使用者需求,
2:類圖側重描述系統具體實現;
二:描述的方面都不相同
1:類圖描述的是系統的結構,
2:順序圖表描述的是系統的行為;
三:抽象的層次也不同
1:構件圖描述系統的模組結構,抽象層次較高,
2:類圖是描述具體模組的結構,抽象層次一般,
3:對象圖描述了具體的模組實現,抽象層次較低。
在有的文獻書籍中,將這九種模型圖分為三大類:
結構分類、動態行為和模型管理:
1:結構分類包括使用案例圖、類圖、對象圖、構件圖和部署圖,
2:動態行為包括狀態圖、活動圖表、順序圖和共同作業圖表,
3:模型管理則包含類圖。
類圖中通過加號(+)來表示 public 通過減號(-)表示 private通過井號(#)表示 protected
七,作業練習
詳細請看:http://www.cnblogs.com/wj-1314/p/8707772.html
python 物件導向終極進階之開發流程