這本書主要的精神, 是用一個 MP3 recorder 這樣的案例來說明 UML 要如何表現出這樣的設計. 至於程式的框架, 則是用 System C 來表示. 這邊說到框架的意思, 就是不會有完整的 source code, 只是大概地描述了 class 和 header file 的長相而已.
UML 已經是一個成熟的標準, System C 亦然. 在此我先忽略 System C, 專注在 UML 的介紹. 因為這本書的重點也是如此. System C 的官網在: http://www.systemc.org.UML 的官網在: http://www.omg.org 的最上面的一排 logo 的正中央.
接觸過 UML 的人, 一定不會忘記它有很多圖. 所以本書的第一章先講 UML + System C 在 IC 設計上有多大多大的好處, 第二章就把主要的 UML 圖形都瀏覽一遍. 對 UML 毫無概念的人看到這裡, 應該只會眼花撩亂…總括來說, 這本書要介紹的分別是活動圖, 組合結構圖, 通訊圖, 類別圖與案例圖. 並且在每介紹完一章圖之後, 就會以 MP3 recorder 的例子, 用 StartUML 這個免費軟體畫一遍. 說到畫 UML 的軟體, 大家應該不會忘記超強的 Rational Rose. 不過這朵玫瑰被 IBM 吃了之後, 價錢應該又更上一層樓了, 我們還是用免費軟體就好.
System C 的主要元素
模組 (module) : 系統或是子系統. 裡面的組成元素包括: 進程, 通道, 端口. 寫成程式當然也包括資料, 子模組 (sub-module), 建構式 (constructor), 解構式 (deconstructor). 為什麼沒有講到介面呢 ? 因為介面是端口的實現方式.
進程 (process) : System C 提供 3 種進程: SC_THREAD, SC_METHOD, SC_CTHREAD. 裡面特別的地方是, 這三個 process 都不帶參數, 因為它相關於硬體的設計. 硬體做事的時候, 並不需要輸出入參數.一般 pthread 就是指 POSIX 相容的 thread, cthread 就是指 non-POSIX 的 thread.
進程之間不能直接溝通, 必須要透過事件 (event), 或者是呼叫函數 (function).
通道 (channel) : 進程之間可以透過 event 或是 function 互動, 但是它們不能互傳資料. 通道就是用來傳資料的. 除了共用通道之外, 也可以共用資料.
端口 (port) : 如果是跨 modeule 與 module 的溝通, 就需要透過 port.
介面 (interface) : 輸出介面, 輸入介面等等. 例如有時候端口是透過輸出介面與另一個端口連接.
活動圖 (activity diagram)
活動圖可能是表示多個進程 (process, 這年頭書的翻譯都大陸化了) 並行的情況, 或是單一的進程的程式.
既然是一個活動, 就會有起點和終點. 在附圖中, 起點在左邊, 終點在右邊. 而那兩條直直的線也不是畫好看的, 它代表多個進程 (sub-activity state) 是可以並行的. 既然是並行, 就要同步. 這兩條就是同步 (synchronization) 的線. 至於那個 object flow state, 在這個例子中是實現一個 buffer, 此時它就是一種 channel.注意, channel 本身沒有 transition 可以連到起點和終點.
在 StarUML 裡面, 起點, 終點, state, 同步線都是用 transition 來連接, 不過這條線不好畫, 只要不是從一個東西的中心點連到另一個東西的中心點, 它經常會抱怨, 畫面跳出一個視窗 “connect elements exactly", 不客氣地擋掉這個操作. 不過畫習慣之後就沒問題了!
這裡的 sub-activity 自然可以再往下細畫出子活動圖, 但是子活動圖就沒有同步線了. 因為裡面的行為並沒有說會同步. 一個典型的子活動圖大概長這樣:
活動圖可以告訴我們系統一共執行哪些工作. 例如上圖的 Activity1, signal accept state, signal send state 都是 event, 只有 object flow state2 是 channel.它也可以有 if else 的判斷部分, 一樣是用一個菱形方塊來表示.
組合結構圖 (composite structure diagram)
組合結構圖據說是 SOC 設計中最重要的一張圖了, 若是 programmer 應該會選類別圖 (class diagram) 吧! 總之, 它和活動圖一樣是階層式的. 最頂端的一層叫做 “結構類別‘ (structure classifier). 我個人覺得把 class 翻成和 classifier 一樣不太合理. 不如翻成結構劃分. 結構的內部包含部件 (part), part 可能是小模組或是小物件歐. 和活動圖一樣, 進程和通道有一樣的地位, 它們都可以是 part.
外部的那個圓圈表示一個介面 (interface), 它用 dependency 的關係線連到 port.內部的圓圈也是一個介面, 但是它不和 port 相關, 因為 port 是要和別的 module 相連的. 在這張組合結構圖裡面, 它是 part Output (channel) 的實現. 所以用 realize 的關係線連接 output 與 output interface. 有趣的是, 當我們用 dependency 連接 interface 和 part 的時候, 圓球就變成了一隻張開的手, 可想而知, 這表示 input!
一隻手可以接球, 那可不可以兩隻手接球呢? 答案是可以的. sc_fifo 就是一隻手和一顆球的組合. sc_signal 就是一顆球和多隻手的組合, 一個訊號當然可以送給很多個 port.
至於 part 與 part 之間的連接, 不是 dependency 也不是 realize, 而是 connector 線.
組合結構圖大致描述了系統裡面有哪些 module, 這些 module 彼此的 input, output 關係. 但是我們看不出它們之間是如何互動的? 想要看出互動關係, 就要靠通訊圖.
通訊圖 (collaboration diagram) / 循序圖 (sequence diagram)
一個典型的通訊圖, 不像是活動圖一樣把 event 當作主角. 相反地, 它用物件當作主角. 在物件與物件之間, 可以用 event (send), 也可以用 function (call), 就像下面這張圖.
有趣的是, StarUML 可以把通訊圖自動轉為循序圖, 後者就像是設計通訊系統 MAC 時用的 message sequence chart.
在此有個地方沒有表示出來, 那就是 public 和 private 的觀念. 在 port 或 interface 上, 可以註明 +xxx, -yyy, 分別表示 public 和 private. 書上說, 選擇連接線的端點, 就可以輸入此訊息. 不過我點不太出來, 而是用畫面右下角的視窗.
在書上的第八章, 通道的可以被封裝, 也就是兩個端口直接溝通. 這種 port 叫做 export.
類別圖 (class diagram)
類別和物件的關係, 就像是概念與實體. 類別圖也是用來表示模組 (module) 或是類別 (class).事實上, 類別圖裡面的 class 和組合結構圖裡面的 class 完全是同一個符號, 只不過在組合結構圖裡面, class 的屬性 (attribute) 和操作 (operation) 被隱藏起來而已. 一個完全不隱藏內容的 class 長得像這樣. 下圖的 Memory 右邊按藍色加 attrib, 按紅色加 operation.同樣地, + 表示 public, – 表示 private, 用下圖 Memory 左邊的那個 icon 點選.
至於結合 memory 與 record 的那一條組合關係的線, 它有兩個結合端 (association end), 其中一邊有個鑽石頭 (像 poker 的 diamond), 表示底層屬於上層的一部份的意思. 結合端的屬性 aggregation = none 的那一端沒有記號, aggregation = composite 的那一端就是鑽石頭. 端點旁邊的數字 1 表示 1 個個體, 1…2 表示有兩個個體.此處就等於有兩塊記憶體模組.
類別圖也可以和 port 結合, 並與 interface 結合.這樣就更可以和組合結構圖聯想在一起.
案例圖 (use case)
案例圖就簡單了, 左邊就是一個使用者, icon 也就是這個小黃人. 右邊的框就是 system boundary. 裡面的兩個圈圈就是 use case. User 和 use case 用 directed association 連起來. 當然這意味著會有普通, 無方向的 association.
最後, 要提一下這個書的 bug, 表示我真的有在看. Page 5-4 作者說這一章的活動圖和上一章不一樣是版本的關係, 要我們比較上一章的圖 4-21 和本章的圖 5-6. 不過很抱歉! 上一章沒有圖 4-21, 應該是和圖 4-13 比才對喔.
Cash Chou's Blog 