uml驗收,工程竣工驗收報告
在跟老孟取了很多經後驗收uml我還是出了很多的問題。但是不得不承認,我和老孟都對uml有了更多的感受。
一、使用者到底是誰。
這次開會後,我最大的感受是基本瞭解到底機房收費系統到底是給誰用的。
“你覺得機房收費系統是給誰用的呢?”
我不經大腦回答了“學生”。
“那你之前敲的學生資訊管理系統你覺得是給誰用的?”
我才慢慢反應過來,弱弱的說了一句是給“老師”用的。
“你去網吧的時候那個系統是給誰用的?”
當我回答是網管的時候我才有點明白原來機房收費系統應該主要是給老師或管理機房的人用。
無論是畫uml圖還是寫軟工文檔,我都出現一個很嚴重的錯誤就是沒有明確使用者到底是誰,有時候想的是老師,有時候想的是學生(有時候想的是給老師工作的學生=-=。)
二、什麼是系統邊界。
所謂邊界,也就是將這個系統看成一個黑盒子,和外界的互動。
例如:
"這,是一個黑色的立方體,長45厘米,寬23厘米,高3厘米,盒子的每個角都不尖銳,上方平坦,並有柔軟質感;下方在四角之處都有凹進去的螺絲口,可以接杆子,以作凳子用。"
這就是僅僅對其功用的描述,其目標是作凳子用。這可以看作是功能性需求,當然如果還有一些約束,例如:
"此立方體可以承受300斤胖人之重"。
這就可以看作是非功能性需求。但同樣還是在描述邊界。而對於其內部構造如何,在需求中不要描述,例如:
盒子是空心的還是實心的,材質用鋼板還是木頭。
這都不是需求,而是已經在設計了。
需求所描述的系統邊界,即系統包含的功能與系統不包含的功能之間的界限。用UML中的使用案例圖來表示是比較簡潔的。如:
三、不能孤立看圖
舉個例子說,使用案例圖、類圖和時序圖之間剛開始畫的時候我直接開了三個rose表單,每個都另存新檔一個地方,可是慢慢往後學就發現越來越不對勁,我以為時序圖裡面的對象都是自己重新設計的,訊息也是自己編寫的事實上不是這樣的。
在剛開始看很多人時序圖部落格的時候我就很奇怪為什麼有些部落格在對象上有很多差別。
比如:一般使用者這個符號為什麼是例圖中一般使用者的樣子,上機為什麼後面帶著冒號,細心一點還會發現傳遞的訊息為什麼和類圖中的方法一模一樣,到驗收的時候我才明白時序圖裡面無論是對象還是訊息都不是自己現編寫,它都是跟類圖和使用案例圖有著千絲萬縷的關係,這也是為什麼看很多部落格的時候會有很多差別。
四、總結
我覺得每個階段的學習只是自己一味的探索是遠遠不夠的,我的學習感覺更多的來自於老孟和師傅們的協助,所以,有問題的時候可以先和自己組的同學探討一下,說不定效果會更好。