日期: 2008 年 6 月 26 日

我的第十堂日文課

拖欠已久的第十堂課的筆記終於開始寫了! 因為下了這堂課, 第二天就殺到美國度假, 這中間忙著玩, 也不一定有網路, 所以就沒有把這堂課的筆記記上. 總之,拖太久, 都快忘光了!

 

這一課的題目叫做 “甲子園へ 行きますか“,重點在於用甚麼手段, 到甚麼地方去. 首先我們看到目的地後面加了一個へ字, 唸法是 e 不是 he, 這就表示前面的那個名詞, 就是我們的動詞所連結的地點. 至於方向動詞, 一共有三個: 來, 去, 回來.

 

去: いきます (五) — 原形為　行く

來:　きます (カ) — 原形為　くる

回來:　かえります(五,例外) — 原形為　かえる

 

去比來多一個音節,可見得去得地方遠, 來的地方近. 遠就長一點, 近就短一點,我是這樣分辨的.動詞變化用紅色字分類. 五就是五段,カ是カ段.

如果說到用甚麼工具到那個地方? 我們會用助詞 で.

 

然而這個助詞有 8~10 種用法, 本課講到其中的兩種. 一個是指工具, 另一個是指量的總稱.

 

あるいて　(=步いて), 步行也是一種交通工具

ひとりで    (=一人で), 一個人也是一種數量

若是一句話裡面, 有以前學過的時間,有這課教的地點,交通工具, 那麼大家擺放的順序是怎樣咧?

時間に + 交通工具で + 地點へ + 動詞

附帶一提, 講到に, 它有 18 種用法.

 

大家要知道, 這是我們日文入門班的最後一堂課了. 所以老師把驚人的數字都一起揭露出來. 我們倒底會是因此而勤學上進去續班上初級日文, 還是嚇得打退堂鼓呢? 以有意願續班的同學數目來看, 大約是一半一半.

で 當作工具用的助詞用的時候, 前面都是接名詞. 當我們想要把一個動詞混作名詞用怎麼辦呢? 就像前面講過的步行.

 

步行 = あるく

把他變成名詞就是成 あるいて…嗯…動名詞了, 這是我說的, 開開玩笑, 但它真的是動詞當名詞用.

變化規則是把前一個 る 去掉, 換成  つ / ん 加 た ; 或是 し / い加 て. 上例 “步“就是去る加いて!

 

<<參考てた動詞變化, 待續>>

 

動詞若是當工具用, 後面多會以て或で結尾 (當助詞).. 若是純名詞, 只會是で結尾 (當助詞).

一緒に的用法

我們在 WII 裡面還蠻容易聽到這個字的, 就是一起來的意思.

如果我們要說:

 

 我和周先生一起去學校

 

直譯成日文會長成這樣:

 

 私は  と 周さん 一緒に 學校へ 行きます

 

 (當然, 前面已經講過動詞/時態在最後面, 就不白目地說行學校了)

 

但日本人不喜歡說到自己, 所以私は會消失

 

然後 と 要往後搬到 周さん 後面, 不然第一個字成了助詞, 就不合基本用法:

 

周さん と 一緒に 學校へ 行きます

 

接著  と 一緒に 可以合併成 と , 因為 周さん 絕對是和主詞 私 的 一起去的, 不然不會省略.

最後這句就變成:

 

周さん と 學校へ 行きます

 

或曰, と 不是連接 A 和 B 嗎? 此處會不會混淆成 周さん 和 學校へ 一起去.

文法上 A,B 兩者詞性不同, 是不會混淆. 口語上, 倒是要聽清楚一點.

如果強調是一個人, 用法如下:

 

私は  一人で 　行きます

 

回顧 “何時" 這個用法, 它的讀音有兩個:

 

1.    なんじ　表示何時, 回答時通常有助詞　に.

 

2.    いつ　表示甚麼時候? 回答通常是幾月幾日. 例如:

　　いつ　きますか　　= 甚麼時候回來呢?

 

答句的話, 因為問句沒有　に, 所以不一定要精確地回答.

 

よる　きます     = 晚上回來

くじに　きます    = 9 點回來

兩者皆可

這一課是搭電車要去甲子園, 首先在買票的時候有點學問. 如果我們要買票到甲子園, 賣票的人想知道的是你的目的地, 而不是你想要坐車到哪個方向. 因此這一句是:
 

 甲子園まで　いくらですか

 

而不是

 

 甲子園へ　いくらですか

在 Q&A 練習中, 主要的句型就是問: 要去哪裡? 怎麼去? 何時去? 和誰去?

 

あなたは　どこへ　いきますか

あなたは　なんで　かいしゃへ　いきますか

あなたは　いつ　くにへ　かえりますか

あなたは　だれと　にほんへ　きました

全面肯定與全面否定

 

全面肯定的句型是:

 W? + でも　(即使的意思) + 肯定

 

全面否定的句型是:

 W? +  も　+ 否定

 

例如: 我哪裡也沒去 =どこも　いきませでした

　W? 就是表 5W 1H

答句的時候, 有時候可以省掉一些話.

 

Q: いつ　USAへ　きますか

 

來週です or

來週 行きます

由於這一課上得比較趕, 所以內容大致就是這樣了. 老師說續班的話, 她會帶大家複習. 不過因為總總因素, 我跑到美國去玩了, 回來還有時差, 加上感覺教室燈光對我的眼睛不太好, 所以就放棄續班了. 如果大家有看到第十一堂課, 或是續集的話, 表示我找到新班了.

 

畢竟在清大上的這些課中, 我只有和老師有點互動 (因為我坐最前面). 但是和同學就沒有互動可言, 我在想, 如果回公司上課, 不知道會不會感覺更好? 當然! 我覺得曾昭子老師教得不錯, 我本來甚麼都不會的, 現在差不多可以看懂 WII 的 menu 的幾句了 (不是看漢字亂猜那種), 呵!

 

我讀 «UML-System C 系統設計實務»

這本書主要的精神, 是用一個 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 比才對喔.