?? 請問use case圖和class圖有什么關系.txt
字號:
作者 內容
qsqwmy 請問Use Case圖和Class圖有什么關系?
http://www.shecn.com/best/g32/u1147405.htm
--------------------------------------------------------------------------------
是不是Class圖的設計由Use Case圖而來呢?
03/05/12 08:34 酷帖! 臭帖! 回復
酷帖評價: 臭帖評價:
返回頁首
gene_cn 基本上是先捕捉用例,也就是需求,然后才有CLASS,但也可以直接畫CLASS框圖,這要看你對系統的熟悉程度。
--------------------------------------------------------------------------------
03/05/12 08:50 酷帖! 臭帖! 回復
酷帖評價: 臭帖評價:
返回頁首
qsqwmy 回復: 基本上是先捕捉用例,也就是需求,然后才有CLASS,但也可以直接畫CLASS框圖,這要看你對系統的熟悉程度。
--------------------------------------------------------------------------------
那么用例決定類嗎?比如說由這個用例,我們可以得出我們需要某幾個類,由另外一個用例我們又得出另外需要幾個類。有這種層次的關系嗎?
03/05/12 08:57 酷帖! 臭帖! 回復
酷帖評價: 臭帖評價:
返回頁首
gene_cn 也可以這樣說,任何開發出來的軟件都必須滿足需求,CLASS是實現需求的一種元素。
--------------------------------------------------------------------------------
03/05/12 09:00 酷帖! 臭帖! 回復
酷帖評價: 臭帖評價:
返回頁首
qsqwmy 回復: 也可以這樣說,任何開發出來的軟件都必須滿足需求,CLASS是實現需求的一種元素。
--------------------------------------------------------------------------------
我就是在根據Use Cases圖設計Class這一方面找不到感覺,我感覺自己設計Class的時候好像是脫離了Use Case的。
03/05/12 09:09 酷帖! 臭帖! 回復
酷帖評價: 臭帖評價:
返回頁首
gene_cn 那你要一步一步來,先從業務用例圖和它的活動圖,然后系統用例和它的時序圖,協作圖,最后是類圖,數據庫結構圖,這樣認真做下去,你的感覺就會很好。
--------------------------------------------------------------------------------
03/05/12 09:14 酷帖! 臭帖! 回復
酷帖評價: 臭帖評價:
返回頁首
qsqwmy 回復: 那你要一步一步來,先從業務用例圖和它的活動圖,然后系統用例和它的時序圖,協作圖,最后是類圖,數據庫結構圖,這樣認真做下去,你的感覺就會很好。
--------------------------------------------------------------------------------
好的,繼續努力………………
多謝了??!
03/05/12 09:21 酷帖! 臭帖! 回復
酷帖評價: 臭帖評價:
返回頁首
xuf0000 回復: 請問Use Case圖和Class圖有什么關系?
--------------------------------------------------------------------------------
本質上其實Use Case只是幫助你搞清楚客戶究竟要做什么這個問題,以前我們主要是用文字來描述,如SRS,但輔以用例圖的話可能更清晰直觀,所以在做用例的時候(也就是在了解做什么)最好不要想到其它詳細的東西,至多考慮一下架構。類圖只是在對需求(用例)做分析時才使用的,如根據客戶的業務情況抽象出不同的類如實體,邊界,控制等。所以說Use Case diagram和Class diagram并不是非要有什么對應的關系,Use Case只是使用者的視圖,Class 則是實施者的視圖,唉,這其間的東西很難要語言來表達...多做幾年就理解了。
03/05/13 12:56 酷帖! 臭帖! 回復
酷帖評價: 臭帖評價:
返回頁首
qsqwmy 回復: 請問Use Case圖和Class圖有什么關系?
--------------------------------------------------------------------------------
終于明白了,多謝!!
03/05/13 13:07 酷帖! 臭帖! 回復
酷帖評價: 臭帖評價:
返回頁首
babituo Use Case從外部描述有哪些主角(Actor)提出哪些過程需求,Class從內部表達主角的所有過程請求靠怎樣設計的角色(Work)來協作完成。
--------------------------------------------------------------------------------
一個主外,一個主內;
從外到內,里應外合,完成需求到設計的過渡和保證一致性。
03/05/13 14:09 酷帖! 臭帖! 回復
酷帖評價: 臭帖評價:
返回頁首
qsqwmy 回復: Use Case從外部描述有哪些主角(Actor)提出哪些過程需求,Class從內部表達主角的所有過程請求靠怎樣設計的角色(Work)來協作完成。
--------------------------------------------------------------------------------
好理論的東西呀,這可比寫一個函數難多了,呵呵……
03/05/15 08:11 酷帖! 臭帖! 回復
酷帖評價: 臭帖評價:
返回頁首
babituo 為什么分析設計會難過編程?(跑點題)
--------------------------------------------------------------------------------
在某種意義上講,分析設計和編程完全是一回事:就是講清楚同一件可重復發生的事情的原尾。只不過用的語言符號不一樣而已。
我發現有些程序員往往使用編程語言來表達一個需求比用自然語言還來得快和準。就是與客戶交流起來困難。
編程語言是程序員慣用的思考語言,分析設計語言比編程語言更接近自然語言,也就是普通人的思考語言,應該比編程語言更容易學習和掌握。為什么在程序員看來用分析設計語言表達用戶的需求反而難過用編程語言呢?
有沒有大家是先學習編程語言,再學分析設計語言方面的原因?
可不可以適當地反過來?
計算機軟件的教育也許有入口錯誤。急于求成,急于讓學生盡快了解計算機的資源,而忘了從普通人的資源逐漸演變過去。
03/05/15 11:41 酷帖! 臭帖! 回復
酷帖評價: 臭帖評價:
返回頁首
qsqwmy 回復: 為什么分析設計會難過編程?(跑點題)
--------------------------------------------------------------------------------
說的有道理,可能是因為先學編程,再學分析的緣故,可是我覺得要是分析的話,有一定的編程經驗會更加有幫助才是。
03/05/15 12:03 酷帖! 臭帖! 回復
酷帖評價: 臭帖評價:
返回頁首
babituo 大家都這么說,我也不反對這種說法,可你知道這是為什么嗎?
--------------------------------------------------------------------------------
03/05/15 14:32 酷帖! 臭帖! 回復
酷帖評價: 臭帖評價:
返回頁首
qsqwmy 回復: 大家都這么說,我也不反對這種說法,可你知道這是為什么嗎?
--------------------------------------------------------------------------------
老實說,我也不知道為什么,愿聞其詳。
03/05/15 14:55 酷帖! 臭帖! 回復
酷帖評價: 臭帖評價:
返回頁首
snakerlee 你為什么要做軟件呢?因為要編出一堆代碼?
--------------------------------------------------------------------------------
03/05/15 16:44 酷帖! 臭帖! 回復
酷帖評價: 臭帖評價:
返回頁首
snakerlee 我倒是覺得應該有對應關系,但不是一一對應關系
--------------------------------------------------------------------------------
因為要修改、提煉、升華嘛
03/05/15 16:46 酷帖! 臭帖! 回復
酷帖評價: 臭帖評價:
返回頁首
gaojuntao 回復: 為什么分析設計會難過編程?(跑點題)
--------------------------------------------------------------------------------
分析設計的重點是從總體上把握系統,他們的職責在保障軟件各種質量屬性:
如,可擴展性、易維護性等。
程序員的重點是保障整個系統在局部上的質量。
一句話,一個把握宏觀,而另一個的工作焦點在局部。
03/05/15 17:03 酷帖! 臭帖! 回復
酷帖評價: 臭帖評價:
返回頁首
heyongbin 回復: 大家都這么說,我也不反對這種說法,可你知道這是為什么嗎?
--------------------------------------------------------------------------------
個人特質第一,后天學習第二,編碼與分析設計的差異還是挺大的。有些人是很難去做分析設計的,但也有計算機基礎差,卻很適合做分析設計。有一次我見到一個863專家,他的課題是數字(某?。赡軓膩頉]有寫過程序,但思路特好,可能與他長期做課題Leader 有關把。
03/05/15 18:14 酷帖! 臭帖! 回復
酷帖評價: 臭帖評價:
返回頁首
zhxb 回復: 請問Use Case圖和Class圖有什么關系?
--------------------------------------------------------------------------------
我認為:1、如果已經存在領域模型,則就可以產生Class圖;2、對于業務對象,并一定是從用例圖產生出來,可以通過其它方式來產生,這些業務對象可以直接產生的類圖。
其實,對于OMT來說,不一定需要用例來進行分析設計,通過短語分析從問題描述中取得類的信息(名稱、屬性、操作)。
03/05/15 19:51 酷帖! 臭帖! 回復
酷帖評價: 臭帖評價:
返回頁首
babituo 我也只是有自己的感覺.
--------------------------------------------------------------------------------
為什么做分析設計的人有編程經驗會更好,就好比搞建筑和結構設計的工程師有施工經驗會更好一樣。主要解決的是一個“實現”問題。即你發現的問題是否有可行的解決辦法,你設計的解決方案是否存在在經濟,技術,工藝上的實現手段。
這個問題很重要嗎?是很重要,如果發現的問題不可解決,設計的方案不可實現,那么項目必然失敗。
這個問題一定會出現嗎?也就是說,如果分析設計師沒有編程經驗,就一定會導致他的分析設計方案不可實現嗎?不見得。分析設計師其他方面的閱歷是可以降低這個風險的。比如他見過的失敗的方案足夠多,他有豐富的軟件使用經驗等等。
聞道有先后,術業有專攻,隔行如隔山。也許這才是分析設計難于編程的根本原因吧。
03/05/16 09:21 酷帖! 臭帖! 回復
酷帖評價: 臭帖評價:
返回頁首
qsqwmy 回復: 我也只是有自己的感覺.
--------------------------------------------------------------------------------
很有道理,贊同贊同………………
?? 快捷鍵說明
復制代碼
Ctrl + C
搜索代碼
Ctrl + F
全屏模式
F11
切換主題
Ctrl + Shift + D
顯示快捷鍵
?
增大字號
Ctrl + =
減小字號
Ctrl + -