軟體隱喻
人們都有幻想的能力，這種幻想帶有聯絡性，如果你具有模擬和推理能力，這將是奇妙的。
我們做一件事情的時候，總是希望乙個結果，這個結果我們可以把它設想成種種事物。
用之於軟體，我們稱之為隱喻。
比如以前我做web應用，往往充斥著使用者的各種各樣的需求，這些需求堆積起來就在腦海中有了圖紙，我把他們適配於各種模組，潛意識裡就把這個過程想象成組裝電腦的隱喻。
當然組裝好了難免要進行除錯，或許它「滴滴」的會報警，這時候可以根據警報的聲音，長度啊大小的去診斷錯誤的所在，在程式中，往往表現為功能的不通或不爽。
調通之後，機器會正常執行，這時候程式就可以上線了，交給客戶，當然客戶還會提出這樣那樣的完善性需求。於是，我就會給機器加螢幕保護儀、攝像頭、掃瞄器、印表機之類的輔助裝置。
當然這種隱喻對於大型軟體的構建並不是十分的可取，或許只是一種瞎想。
有一種隱喻對於絕大部分軟體的構建都是成功的，就是把整個過程想象為建造乙個建築物，建築物需要各種材質，各種格調的適配，各種色彩的搭配，以及給觀賞者帶來的感覺（使用者體驗）等。
初期構建，要考慮到成本，需要的材料，人員數量，角色搭配，工期長度。
中期建設，要考慮到施工進度，如何巧妙的節省材料，增加穩定度和優秀度。
後期完善，要考慮到裝飾裝潢，給使用者帶來的感覺。
這三部就如同小學生學寫作文時候的「大三段」一樣，只是個初級考慮，裡面的細節可能錯綜複雜，但無論如何，腦海中有個形象的東西總比概念化要好的多。
建模
對於很多開發人員甚至設計人員來說,uml是比較困惑的東西,在一些專案的開發中,我們往往不能夠正確的使用uml.
在乙個專案中,我把使用uml的過程放在了專案早期需求挖掘分析的位置上從而得到了一些好的收效,所以把一點體會與大家分享一下.
1.盡可能使用最簡單的工具幫助你理解業務.
uml可以是一張白紙上的塗塗畫畫,也可以的開發組的若干個成員在白板上的智慧型的結晶,用於分析或**解決方案的複雜部分,總之只要是能清晰地或接近清晰地描述業務,那你的uml就是有意義的.
2.珍惜你的頭腦風暴
uml不是文件也不能把它作為文件的作用來使用,它只是你在理解業務的過程中頭腦裡的快照而已,由於頭腦風暴的緣故,專案早期開發人員對業務的理解過程是有連續性的,所以你最好用uml把你的理解記錄下來.
3.把握恰當的時機
專案的早期uml作為草圖,並不用於大範圍的設計,只是處理一些棘手,困難,不常見,較為複雜的業務問題,而一些簡單的設計問題,可以推延到程式設計階段由開發人員去完成它.
4.迭代過程中的uml
這時的uml作為藍圖,主要用於設計和編碼的實現,它與開發人員的關係更親切些,從有利於理解業務到有利於編碼實現業務過渡,這種實現是奇妙的.
5.總結
從一定意義上來說,uml能夠很大程度的幫助我們分析問題,取得對需求的最大程度理解,而這種分析正是取得與客戶理想軟體的最大一致性的可靠保障.無論你採用迭代式開發還是進化式分析,uml總能夠很好的幫助你梳理業務.
附上usecase用例模板:
《需求工程 軟體建模與分析》04
一 需求捕獲過程 一 需求內容 1 需求。主要表現為使用者對系統的期望及目標，在獲取中體現為涉眾的問題 期望 觀點 看法和態度等。2 問題與描述。主要用於承載和解釋需求的問題域特性，表現為現實世界的業務運 況。3 環境與約束。這屬於一種特殊的問題域特性，其主要 於涉眾的描述和對應用環境的觀察。1 涉...
軟體建模與分析 G002 185 03
電腦科學與工程學院實驗報告 首頁 課程名稱 軟體需求分析與建模 班級 18軟體工程5班 實驗名稱 三個應用系統與專案分析 教導教師 董瑞生 組員 鄭遠曦 吳光華 日期 2020 10.25 系統的功能與我組功能差異 我組在匹配施工隊時，訂單的選擇權力在施工隊這邊，施工隊可以選擇接單，使用者只能被動接...
《需求工程 軟體建模與分析》01
一 滿足需求就是解決問題 問題解決的 兩個方面 問題域與解系統 首先，我們需要簡要了解這兩點的概念。第一，問題域是需求的背景，要理解需求就必須先理解問題域。問題域的背景資訊又被稱為問題域特性 problem domain feature 與需求相區別的是，問題域是自治的，它有自己的執行規律，而且這些...