中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

　　1.前言

看過太多的稱得上“三無”的軟件，就是無需求、無設計、無注釋。嚴格的說來，他們的需求和設計其實還是有的，只是沒有用文檔記錄下來而已，但是注釋確實真的沒有。這些軟件從大到小都有，但是他們都有一個共同的特點，就是“難維護”。前幾天和同事聊天，聽說一個XAML的實現要重寫了，用本地協議代替，然后再去考慮和XAML兼容。雖然我沒有看過這個項目的代碼，但是我知道這個項目基本也是“三無”。當然這個情況也是三無的重大特征之一，就是前腳走人之后，后腳是“看不懂、下不了手”，結果是還不如重寫來得簡單。從員工角度，當然不會有什么不妥，但是從公司和產品的角度，則是屬于“無謂的損失”。

一個對自己有要求的程序員，應該保證自己不出產“三無”項目

“規范化”可以解決項目的“三無”問題。而且這個一直是我所推崇的，正好有網友開始了12306ng項目，所以也就拿這個例子過來，跟大家匯報一下我的設計思路，同時也作為我在公司開設此類課程的備課。

　　2.關于設計

軟件的設計過程其實也是一個推導的過程，這個過程的每一個步驟之間都有著各種關系：要么細化，要么印證，要么補充。我之前學習設計的時候，以為看著課本，依據什么“自頂向下”或“自底向上”就可以一步一步將系統設計出來，可是后來發現我錯了。相信正在學習設計的朋友也應該會有這樣的感受。

電腦和人腦相比，最大的區別是前者一個線性系統，而后者是一個非線性系統。所謂的非線性，通俗點講，就是顛三倒四，左右開弓，文藝點講，就是講究“螺旋式上升”，總之就是說“機械式”的“一蹴而就”動作，人腦是不擅長的，當然，天才除外。

設計也是如此，它本來就是人腦的處理結果，所以它的過程也必然是非線性的。一種設計方法，要想被人容易學習和接收，它本身就要是一種包含“螺旋式”改進的機制，也就是戴明環的PDCA過程(Plan-Do-Check-Adjust)，不過在設計過程中Plan的因素不明顯，主要是DCA的過程。

在做系統設計的過程中，最大的感受就是不要限制自己。記得當年我為了完成設計，滿足“自頂向下”的要求，刻意地限制自己不去深入地思考，結果當然是失敗。當然，“限制”不僅是剛談到的思考層次的限制，更重要的是突破工具的限制。所有的工具都會給思想甚至工作進度帶來限制。迄今為止，最好的設計工具依然是“帶橡皮頭的鉛筆”和“紙”，所以諸位要好好地利用它。

　　3.需求

12306是目前最著名的公認的人機交互體驗較差的網站，如何做出一個比它更好的系統呢?答案就是“更仔細地設計”。在“更仔細地”設計之前，我們需要“更仔細地”收集好需求。

軟件的需求就是軟件要實現的“目的”。各位千萬不要一提到“需求”就當作了“需求文檔”，文檔只是需求的一種表現形式而已，另外一種常見的表現形式就是程序員們大腦中的記憶。蹩腳的程序員經常通過嘴傳遞需求，他們寧可不厭其煩、一遍又一遍地說，也不愿意花一點時間一次性寫下來，他們無法忍受客戶的一次次需求變更，但卻不在意自己每次說出的同一個需求都有些走樣。

3.1.第一步：用例分層

這里我們用UML的用例圖(UseCase)來表示需求。

用例圖也是分層次描述的。所有系統最頂層的用例圖(零級用例)都差不多，都是一個圓圈圍繞著很多角色，區別就是角色有多少，以及圓圈里寫的字不一樣。這次我們的圓圈里寫的是“12306ng火車票訂票系統”，外圍的角色只有2個：用戶和管理員。

一級的用例圖就完全不一樣了。我把它分為了7個部分，一級用例名稱和其包含的二級用例名稱說明如下：

1. 用戶管理：注冊，登錄，退出，密碼找回，信息查看，信息修改，用戶驗證，用戶查詢

2. 查詢：時刻表，余票，聯程規劃，晚點

3. 訂單：下單，取消訂單，修改訂單，訂單查詢，預訂

4. 票務：訂票，取票，改簽，退票，車票查詢

5. 資金：付款，退款，查詢到帳，銀行對賬

6. 票池：入票，出票，查詢票池，修改票池

7. 維護：參數設置，詞典維護，拓撲管理，日志查詢，備份，恢復

以上直接列出是為了方便大家閱讀，實際上我也是用這樣提綱來思考的。然后補圖如下：

 

 

 

 

 

 

 

 

當然，以上的部分既不是最初的狀態，也不是最終的狀態，而是我經過多次調整和改進之后，到現在的狀態，未來還會根據分析的情況進一步調整。另外，大家一定要注意，一個系統的用例表示不是唯一的，不同的人給出的用例是不同的，但是理論上應該是等價的。

用例圖中的每一個部分，都必須是真實存在的，而且是可以面向客戶的東西，它所描述的最小單位應該是業務模塊。評判用例的標準是“具有業務意義”，所謂的“業務意義”就是指這個業務模塊完成之后，可以將整個業務或者業務流程向前推進，這個“推進”的結果應該包含了角色的轉變或者目標的變化。

從以上的定義來看，“資金.查詢到帳”和“票池.鎖票”可能就不是一個用例。直到寫本文的時候，我依然還在猶豫，但后來還是決定剔除，因為他們沒有外部關聯的actor，雖然確實這兩個用例能夠推動業務向前推進。從這里我還得到一個經驗，就是在一級和二級用例最好不要出現actor是內部模塊或系統的情況。

來源：http://www.cnblogs.com/BigTall/archive/2012/10/17/2727012.html

(未完待續)