1. 程式人生 > >python 面向對象終極進階之開發流程

python 面向對象終極進階之開發流程

wim 打印機 序列 cnblogs 學員 表示法 模型圖 統一 識別

  好了,你現在會了面向對象的各種語法了, 但是你會發現很多同學都是學會了面向對象的語法,卻依然寫不出面向對象的程序,原因是什麽呢?原因就是因為你還沒掌握一門面向對象設計利器, 此刻有經驗的人可能會想到瀑布模型、螺旋模型、叠代開發、敏捷、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 寫用例的技巧

三段法:NEA
1 正常處理(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 面向對象終極進階之開發流程