這一周是忙碌的。
需求分析基本完成了，use-case圖幾經(jīng)修改，我們在繪制use-case之前進行過多次的討論，試圖完全明確所有的功能，然后再繪制use-case，企圖一次成功，現(xiàn)在回過頭看這個想法太天真了。不過經(jīng)過充分的討論，第一版的use-case已經(jīng)基本符合要求了。大概是我們對use-case認識還不是十分明確，做出來的圖比較簡單，主要體現(xiàn)在各個用例之間似乎沒有多大的聯(lián)系，當(dāng)然也可能是這個系統(tǒng)本身太簡單的緣故。其實在剛做完use-case時，我們都以為這只是應(yīng)付老師的一個圖表罷了，對于項目過程而言沒有多大的幫助作用，我仍然記得繪制圖表的原則：只繪制對今后有用的圖表。然而后面的分析設(shè)計中，這個use-case圖卻真正成為了我們的工作準則。因為這是一個經(jīng)過充分討論的成果，得到了所有人的認可，在后面的分析設(shè)計中，碰到過一些有爭議的地方，一切符合use-case成為了事實的標準，然而這多少成為了一種約束，當(dāng)然這種約束可能是有益的和必需的。不得不承認的是，這個use-case終究還是有一些遺漏的功能，然而我們后來在分析設(shè)計時發(fā)現(xiàn)之后，大家都不愿意再修改use-case了，因為相關(guān)的文檔已經(jīng)完成，加上時間緊迫，于是只能去掉那些可要可不要的功能，我們的借口就是：要符合use-case。這樣做，我們事實上還是在采用瀑布模型，如果按照迭代的方法，這里是應(yīng)當(dāng)對需求分析進行修改的。幸好我們沒有真正的客戶，否則顯然不能這么糊過去。自然的，我們失去了一次訓(xùn)練需求變更的機會，有些遺憾。反思為什么會這樣：可能可以歸結(jié)為時間不足，進一步考慮大概是因為進度表制定的不合理，再進一步考慮原因也許在于系統(tǒng)的范圍還是定得太大了一點，使得我們的訓(xùn)練廣度是保證了，然而精度不夠。看來學(xué)生項目出于訓(xùn)練的目的，范圍應(yīng)當(dāng)盡可能的小，甚至是一個HelloWorld都可以接受，因為項目的目的是盡可能熟悉和掌握軟件工程的各個環(huán)節(jié)，軟件本身不用很強大，想起一句話：麻雀雖小，五臟俱全。一個小的軟件已經(jīng)足以訓(xùn)練大部分的內(nèi)容了。
需求文檔也完成得很順利，有了use-case一切都變得簡單。對每一個use-case要做一個specification，也就是對它的一些簡要說明、這個功能的輸入輸出、前置后置條件等等，這費了很大的功夫，犯過許多錯誤。一個典型的：我們需要將一部分信息組織成一個記錄寫入數(shù)據(jù)庫，這個功能的輸出（outputs）以及目的地（destination）是什么：起初的考慮是輸出為信息，目的地是記錄。然而后來發(fā)現(xiàn)這樣似乎是有些荒唐的，因為輸入也是信息，難道輸入和輸出不經(jīng)修改是一樣的，那這個功能還做了什么事情。后來改為了輸出為記錄，目的地為數(shù)據(jù)庫，這是大家比較容易接受的結(jié)果，盡管我們也不很確定究竟怎么才算準確。想起以前和老師討論一些問題時老師的一句話：當(dāng)碰到兩難時，選擇那種符合大多數(shù)人習(xí)慣，能讓大多數(shù)人接受的方案。我想這里是適用的。
之后想起來應(yīng)當(dāng)做一份glossary（詞匯表，或稱為數(shù)據(jù)詞典吧），就是對需求分析中用到的一些詞加以解釋，這些詞可能貫穿于整個開發(fā)過程中，有這樣一份詞典后面看文檔的人碰到陌生的用語時有據(jù)可查。這份文檔做得晚了，我就被一件事情困擾過。我們做需求分析的組員對于“續(xù)住”這個功能（還記得我們做的是酒店管理系統(tǒng)嗎）用的英文單詞是continue，這倒無妨，只是我看文檔時對著這個單詞琢磨了半天也不能參透這個功能的意義，后來和她交流才知道是續(xù)住的意思，試想如果當(dāng)時就有g(shù)lossary將省多少事。更可怕的，如果我誤解了后果將很嚴重（其實我起初的理解是由登錄窗口進入主窗口，叫做continue，呵呵，幸好和她有一個交流）。
這些工作做完之后，我們認為需求分析的文檔就基本成形了，于是我們舉行了一次評審，這是一次審查（Inspection），由所有組員參與，評審對象就是需求文檔。我們提前兩天將文檔打印分發(fā)給每個人回去瀏覽準備，一個小插曲是打印和復(fù)印的費用花去了我們第一筆集資經(jīng)費（50元）的一半，讓我們吃了一驚，后面要勒緊褲腰帶省點用了，畢竟大家都還是學(xué)生，花的是自己的伙食費。其實我本來以為這次評審將是失敗的，因為大家以前沒有過經(jīng)驗，而且這段時間大家都比較忙，可能不會太認真的去閱讀文檔和找出瑕疵。然而事實讓我吃了一驚，每個人都做了充分的準備工作，人均花費了兩個小時閱讀文檔，這已經(jīng)足夠了。我們的評審相當(dāng)順利，問題接二連三地被提出來。當(dāng)然有一點遺憾是評審的時間沒有把握好，有點拖沓了，不是因為問題太多，而是花了一些時間在如何解決上。按照各種書籍的觀點，評審會議應(yīng)當(dāng)著重發(fā)現(xiàn)問題而不是解決問題，我們不經(jīng)意的犯了這個錯誤。然而這樣做是有道理的，因為在完成需求文檔時，犯的一些錯誤多半是對這個問題不理解，而不是不知道該怎么解決，也就是說不是很清楚what，一旦明白了what，那么how可能是比較容易的。所以我們有必要及時指出問題是什么，指出問題的本質(zhì)，這樣長遠的看是節(jié)省時間的，減少返工的次數(shù)。為什么大家會愿意去花寶貴的時間閱讀文檔和找出瑕疵，我想一個直接的原因是因為打印這些文檔的開支比較大，大家都很心疼錢，所以不忍浪費，于是才會認真地閱讀文檔。挺好的。
起初是我們的“首席架構(gòu)師”完成系統(tǒng)結(jié)構(gòu)的設(shè)計，為了節(jié)省時間我們試圖同時完成系統(tǒng)架構(gòu)的設(shè)計和模塊的細節(jié)設(shè)計，于是碰到了問題，功能上有點不統(tǒng)一，直接原因是對需求沒有做很好的回顧和了解，仍然比較模糊，于是，原型系統(tǒng)發(fā)揮作用了。我在拿到需求文檔之后，花了一個晚上做了一個原型系統(tǒng)，只有簡單的界面，示意一下，這大概也是原型系統(tǒng)的初衷之一吧，原型系統(tǒng)本來是為客戶服務(wù)的，與客戶有一個基本的交流對象。我當(dāng)時的本意是直接做正式的界面（這個天真的想法是很不合適的，然而我當(dāng)時相當(dāng)自信，認為沒有問題），而不是做原型系統(tǒng)，后來我們的“評審經(jīng)理”提醒我說你現(xiàn)在做的應(yīng)當(dāng)是一個原型系統(tǒng)，用一下就拋棄的，我才察覺到險些犯了一個巨大的錯誤。慶幸的，這個系統(tǒng)正好可以被用作原型系統(tǒng)，為我們的分析設(shè)計做了很好的鋪墊。我們的設(shè)計師不是很愿意閱讀需求文檔，更愿意直接看原型系統(tǒng)來發(fā)掘設(shè)計思路和要求，幸好這個原型是比較完善的，至少沒有遺漏一些功能表示。
然而，第一個設(shè)計是失敗的，原因之一是對RMI（遠程方法調(diào)用）沒有很好的了解，RMI是這個系統(tǒng)的底層實現(xiàn)，這是我的要求，我的另一個要求是力爭符合MVC的標準，或者向著它努力，以它為原則。然而我們的設(shè)計師之前沒有RMI和MVC的基礎(chǔ)知識，就直接進行了設(shè)計，顯然是不合適的。我們否決之后重新閱讀了書籍，建立了第二個架構(gòu)，模塊分得也比較仔細和合適了，基本可以接受，然而整個系統(tǒng)結(jié)構(gòu)顯得有些冗余和不清晰，問題出在MVC中的M。我們的理解中，V就是界面，對應(yīng)于分析類中的boundary方面的內(nèi)容；C毫無疑問就是主控器了；然而M，都知道是模型Model的意思，起初的思路是尋找系統(tǒng)中的名詞，找到之后形成類，也就形成了相應(yīng)的M。于是，系統(tǒng)中充斥著M。去掉一些不必要的，還是有很多，我隱約的覺得有些不必要。我花了一個下午推翻了重做，建立的設(shè)計方案中幾乎沒有M，或者說實體（Entity）類，這樣的方案是簡單的：界面發(fā)出事件請求，相應(yīng)的控制器進行響應(yīng)，然后更新界面并反饋信息，沒有實體什么事。這或許不是一個面向?qū)ο蟮南到y(tǒng)，因為乍一看找不到對象。然而這樣的系統(tǒng)實現(xiàn)起來相當(dāng)簡單和直接，難道是設(shè)計的倒退嗎，還是或者根本沒有弄清楚面向?qū)ο蟮膶嵸|(zhì)。我們的設(shè)想是，所有的名詞（實體對象）都通過數(shù)據(jù)庫持久性存儲起來了，訪問或者更改的時候直接查庫，然后直接把查詢結(jié)果以ResultSet（結(jié)果集）的形式交給界面去更新就可以了，何必假惺惺的封裝起來再給界面，然后界面那邊又要解封裝，似乎多此一舉。我們沒有找到這樣設(shè)計的大缺陷，盡管我們知道這可能是不合適的，比如不利于擴展，不利于代碼重用等等。另一個重要的缺陷是，界面部分也要完成一些業(yè)務(wù)邏輯，比如對結(jié)果集信息的提取，這顯然是不符合MVC要求的。然而鑒于我們現(xiàn)在的編程水平，易于實現(xiàn)是相當(dāng)重要的。于是，這個方案被接受了，這是一種妥協(xié)，更像是一種失敗的妥協(xié)，或者說這樣的設(shè)計更像是一種失敗的設(shè)計。可能后面還會返工，適當(dāng)?shù)脑黾右恍㎝的部分，比如至少不能把ResultSet交給界面吧。呵呵，偶爾想起來太荒唐了。
界面設(shè)計方面，仍然存在很大的爭議，因為可以參考的系統(tǒng)很多，很難達成一致。這部分工作正在做，我把我的初始意見形成草案分發(fā)了出去，大家討論之后試圖在五一前達成一致，因為一旦放假，溝通將變得困難。一個合適的考慮是五一期間基本完成編碼，當(dāng)然前提是大家都對各自要做什么相當(dāng)清楚，接口的定義要一致和清晰，這部分我們還比較弱，設(shè)計還是粗粒度的。我們渴望接下來的幾天能夠提速，現(xiàn)在也正在提速。盡管我們落后進度將近一周，不過通過加快設(shè)計并形成良好的設(shè)計方案，我們的編碼能夠節(jié)省很多時間，測試也是一樣，大家對按時完成充滿了信心。當(dāng)然，沒必要也不可能五個人都參與編碼，可能直接編碼的只有兩三個人，我負責(zé)界面，另外一個數(shù)據(jù)庫編程的高手，其他的適時而定，編碼方面絕對不是人多了時間就短的，絕對不能用人月除以人數(shù)得到月份，我覺得對這樣的學(xué)生系統(tǒng)，一兩個人寫代碼就足夠了。
最后用一句話總結(jié)這一周：緊張而充滿希望。
本站僅提供存儲服務(wù)，所有內(nèi)容均由用戶發(fā)布，如發(fā)現(xiàn)有害或侵權(quán)內(nèi)容，請
點擊舉報。
