[全程建模]類圖與時序圖作用的對比討論

Normal 0 7.8 磅 0 2 false false false EN-US ZH-CN X-NONE一個十多年做技術的朋友  13:37:42

在？

青潤  13:54:43

在。

一個十多年做技術的朋友  13:55:18

有沒有什麼工具可以直接把時序圖程式碼生成出來？

青潤  13:56:22

時序圖是沒有程式碼的，只有類圖才實際關聯程式碼。

時序圖只是幫助把類圖中的方法呼叫關係展現出來，輔助完成類圖開發的作用。

一個十多年做技術的朋友  13:56:46

流程圖呢？

一個十多年做技術的朋友  13:57:09

我最關注的是流程圖、時序圖、狀態圖

青潤  13:57:34

流程圖——狀態活動圖是用於繪製使用者業務細節或者類內部複雜演算法表現的，在設計模型中就是輔助進行微程式碼開發和設計的時候使用。

一個十多年做技術的朋友  13:58:03

 能直接生成程式碼不？

青潤  13:58:20

不能，只有類圖才是實際關聯程式碼生成的。

一個十多年做技術的朋友  13:58:30

好的，謝謝

青潤  13:58:38

不客氣，呵呵。

一個十多年做技術的朋友  14:02:58

只生成類圖作用不大啊

青潤  14:09:35

類圖是核心，它串連了所有的設計模型相關的東西，通過類圖可以直接把時序圖和協作圖推匯出來的。

一個十多年做技術的朋友  14:10:07

那地方不容易出錯

青潤  14:10:22

不容易出錯？哪地方？

一個十多年做技術的朋友  14:10:27

類定義

一個十多年做技術的朋友  14:10:34

容易出錯的是邏輯程式碼

一個十多年做技術的朋友  14:10:50

我在考慮自己生成時序圖的程式碼

一個十多年做技術的朋友  14:11:09

看上去可以把單元測試程式碼也生成出來

青潤  14:11:27

其實類圖如果定義清楚了，通過時序圖或者協作圖開發過程中對類圖的細化，就可以實現類圖中所有邏輯關係的清晰表達。

單元測試用例和程式碼都可以通過這個自動生成的。

青潤  14:11:52

時序圖生成的程式碼也是類圖生成的，時序圖自身就是類圖的一個衍生物，或者表達方式而已。

一個十多年做技術的朋友  14:11:54

結合mock

一個十多年做技術的朋友  14:12:00

不一樣的

青潤  14:12:15

這一點，你肯定搞錯了。

一個十多年做技術的朋友  14:17:31

類圖只描述類之間的關係

一個十多年做技術的朋友  14:17:57

不能描述邏輯

青潤  14:19:58

其實邏輯關係是隱藏在裡面的。

你如何才能考慮清楚這些類間的關係，都是通過時序圖和協作圖才能獲得的。這兩者是相輔相成的，但是核心就是類圖。

類間關係中已經包含了全部的時序圖的內容——這一點是很久以前就被證明的事情。

一個十多年做技術的朋友  14:20:40

類圖如何描述呼叫順序？

青潤  14:21:35

類圖不直接描述呼叫順序。

那你說，你寫的程式碼如何描述呼叫順序的？

一個十多年做技術的朋友  14:21:51

時序圖可以描述

青潤  14:22:10

類間關係中已經包含了全部的時序圖的內容——這一點是很久以前就被證明的事情。

一個十多年做技術的朋友  14:22:21

但我提的這點沒有被包含

青潤  14:22:48

你非要分離的看待類圖和時序圖，你是不是也要完全分離的看待你的設計和業務流程呢？

青潤  14:23:07

你的程式碼和最後的軟體包是不是也是完全獨立的？、

青潤  14:23:15

沒有了類，哪兒來的時序圖？

青潤  14:23:24

時序圖中每一個物件是什麼？

青潤  14:23:37

設計模型中的時序圖。

青潤  14:23:52

不是有些人把時序圖放在需求分析中的使用方式。

一個十多年做技術的朋友  14:24:13

你的意思是時序圖是類圖的補充

青潤  14:24:58

這句話裡面我已經說過這個意思了。

青潤  14:19:58

其實邏輯關係是隱藏在裡面的。

你如何才能考慮清楚這些類間的關係，都是通過時序圖和協作圖才能獲得的。這兩者是相輔相成的，但是核心就是類圖。

 

一個十多年做技術的朋友  14:25:34

但我現在關注的是這個補充部分，如何自動生成程式碼

一個十多年做技術的朋友  14:25:46

單元測試也需要對函式的呼叫順序進行測試

青潤  14:25:54

我說了，只有類圖才對應生成程式碼。

一個十多年做技術的朋友  14:26:10

所以我才來請教啊

青潤  14:26:25

暈倒。

一個十多年做技術的朋友  14:26:32

我在考慮通過時序圖生成程式碼的可行性

青潤  14:26:49

時序圖本身沒有基礎，它就是類物件之間關係的表達。

青潤  14:27:34

如果你自己做一個工具，也可以，程式導向的方式，可以通過關係生成程式碼來實現你的業務目標。

那你的分析目標就不是類，而是過程。這當然沒問題，也可以解決實際的業務問題。

一個十多年做技術的朋友  14:28:29

對於是不是物件導向我不是很關注

一個十多年做技術的朋友  14:28:57

物件導向只是程式碼組織的一種方式

一個十多年做技術的朋友  14:29:14

和字典一樣，可以按筆畫排序，也可以按拼音排序

一個十多年做技術的朋友  14:30:24

如果能把程式碼組織好，我願意選擇程式導向，因為它思想簡單，容易上手

青潤  14:33:27

我並沒有說程式導向不好。

我只是說，如果你要這樣做，那就應該用這樣的思考方式和實現方式來實現。

目前所有的此類工具都是oo的工具，他們都不能通過sequence diagram生成程式碼，如果要做，就只能你自己來做一個這樣的工具了。

一個十多年做技術的朋友  14:33:48

嗯

一個十多年做技術的朋友  14:33:55

我關注文件和程式碼的一致性

一個十多年做技術的朋友  14:34:05

否則在這個上面要花費很多的精力

一個十多年做技術的朋友  14:34:22

最好文件就能直接生成程式碼

青潤  14:36:27

如果你要做程式碼文件的一致性，你應該看一下我書中從需求到程式碼之間影射關係的那部分文字。

可以說，我現在完全可以做一個工具實現需求的任何一個變動直接對程式碼產生影響。

而且需求按照我定義的文件規則編寫後，可以直接對映出有多少個物件，這些物件有多少主要的方法——在一定的架構模式下就可以實現，對於不同的架構模式也可以通過分析獲得不同的實現方法數量和型別。

一個十多年做技術的朋友  14:37:50

是，先要設計好軟體框架

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/257598/viewspace-713573/，如需轉載，請註明出處，否則將追究法律責任。