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