HOME 回資訊服務處首頁 Login
ITs通訊
搜尋電子報


含詳全文
訂閱電子報
請輸入E-Mail
 
 
2006.08.17 2006年第4期 設為首頁 | 加入最愛 | RSS 訂閱
最新電子報 | 上一期 | 下一期 | 各期電子報


   
中央研究院計算中心通訊
中央研究院計算中心發行
2006年第4期   民國95年8月17日
簡訊
本院最佳網站評獎活動開始收件

 為鼓勵建構資訊豐富完整的網站並促進互相觀摩交流,特別舉辦本(95)年度本院最佳網站的評獎活動。收件日期從即日起至下(9)月30日止,歡迎院內各單位踴躍參與本項活動。

 本次活動為首次辦理,將只針對名單中41個單位的入口網站,進行評獎。請各參與單位填寫網站基本資料及自評表,並附上必要之書面說明文件,由院內傳遞方式寄交計算中心評獎工作組;詳細資料請逕上網站評獎活動網頁,若有疑問請電2789-9244洽詢。

Top

本院「第4次資訊業務協調會議」訂9/20召開

 本院「第4次資訊業務協調會議」訂於下(9)月20日(週三)下午二時假學術活動中心2樓第1會議室召開,相關之會議通知及議程已送達各所,敬請各單位資訊業務連絡人踴躍出席,提供您寶貴的意見,提案單請於本(8)月28日以前,傳真至2789-9949或E-mail至liaison@sinica.edu.tw

 此乃依據今(95)年1月4日所召開之第三次資訊業務連絡人聯席會議紀錄辦理,包括通過將本院「資訊業務連絡人」會議名稱修改為本院「資訊業務協調」會議,並決議往後每年舉辦兩次協調會議,召開月份則由本中心會後進行調查;經中心調查結果,在38個單位中有29個單位回覆同意在每年3、4月及9、10月間各舉辦一次。

 如有其他相關建議事項,請逕洽本案連絡人周靜怡、梁怡華小姐相關決議或會議紀錄說明等亦請逕連線至資訊業務連絡人網站查閱參考。

Top

影音服務新增「知識饗宴」講座

 本院網站上“影音服務”近期新增一場「知識饗宴」,由李遠哲院長主持、語言學研究所特聘研究員兼所長鄭錦全院士主講,講題為:『語言數位典藏的內容與應用』。本項講座活動於上(7)月28日晚上6時假本院學術活動中心2樓第1會議室(片長:1時59分18秒),歡迎有興趣同仁連線至本院影音服務網觀賞此一精彩講座實況。 

 另,本院8月份之「知識饗宴」主題係由中心、人社及史語所合作之「地理資訊系統聯合實驗室」於8月30日(週三)晚上6時假本院學術活動中心2樓第1會議室舉行之演講。該場演講由李遠哲院長主持、本院歷史語言研究所范毅軍研究員主講「走進時光隧道GIS與時空資訊的整合」,報名方式請連線至http://db1.sinica.edu.tw/~textdb/test/gatenews/showpost.php?rid=487查閱;或逕電(02)27899872洽詢本院總辦事處 秘書組 公關科。

Top

課程異動公告

 近期即將舉行之中心教育訓練課程中,部份課程配合需求調動上課日期,已報名或有興趣參與研習之同仁請特別留意訊息內容。更動情形如下:

  • 影像處理-Photoshop 7基礎:改為8/30、8/31(下午);課程目標:活用photoshop的基本能力,介紹數位平面影像的基本原理,學習並判斷影像製作及創意的可行性,選擇工具編輯以達到想要的結果,計劃處理影像的步驟,另闢蹊徑;課程大綱:數位平面影像應用概念解說、圖檔拼貼與遮罩、色頻原理應用實作、修飾相片提高相片品質、形狀圖層的應用、濾鏡應用繪圖模式應用;先修課程/適合對象:對影像處理有興趣或需求者。
  • 影像處理-Photoshop 7進階:改為9/07、9/08(下午);課程目標:本課程以基本數位平面影像媒體的操作及實例應用為主軸,透過電腦排版與製作,為電子或平面媒體的方式有效展現。建立美術設計及數位軟體操作技巧,能在週遭擷取各類事物的美感;課程大綱:路徑選取創造虛擬環境、色頻原理應用實作、色頻選取創造虛擬環境、影像的合成、修飾相片與轉換色彩、濾鏡應用上機實做、繪圖模式應用與輸出作業;先修課程/適合對象:具影像處理基礎者。
  • 網頁建置-FondPage 2003:改為10/24-27、10/31(下午);課程目標:製作個人精美的網頁;課程大綱:建立網頁快速入門、網頁美化及編修、超連結技巧完整解析、基本表格設計及表格排版、框架的運用、活潑的特殊效果、CSS樣式表的運用、動態網頁效果、網站發佈與管理、互動式表單建立與管理;先修課程/適合對象:具Windows基礎者。

 上述課程之上課地點假生命科學圖書館三樓第二視聽教室舉行;上課通知於開課前除以書面通知外,並公告於中心教育訓練網站上供查詢,請報名同仁準時到堂上課,並確實遵守相關規定;如因故無法前來者,請事先來電告知,以利安排其他候補人員上課。相關訊息亦請同仁逕行連線至教育訓練推廣課程公告網頁查閱,如有任何疑問,請逕來電2789-9253或email:train@sinica.edu.tw洽詢。

Top

試用資料庫訊息-資訊所圖書室新購中央社譯名檔資料庫
 本院資訊所自今(95)年8月1日起新增購中央社譯名檔資料庫一年份(使用期限至明(96)年7月31日止),歡迎全院同仁有需求同仁善加利用。該資料庫網址為http://client.cna.com.tw/name/;限院內IP連線,帳號:27883799、密碼:1202。如有任何使用疑問,請逕洽詢該所圖書館。
Top

資源要覽
本院ADSL服務1-6月份統計數據分析

  本院ADSL服務主要任務,在於協助院內同仁下班後回到家中,若尚需使用相關網際網路服務繼續進行研究或處理公務,可使用此優質且快速之網路連網服務,且延伸本院的網路服務範圍並提供便利的服務。

  ADSL服務頻寬自今(95)年2月由原45Mbps提升至155Mbps後,大幅舒緩院內使用者於尖峰時刻之網路連線頻寬擁塞問題。依【圖1】資訊顯示,一般使用時段主要約集中於當日18:00至翌日3:00與4:00間。假日分為兩部份:週六主要使用時段約集中於當日9:00至翌日3:00間;週日則主要集中於當日9:00至翌日3:00,所有使用流量皆於凌晨達到最高峰。

圖1  ADSL原始流量統計圖

  【圖1】綠色部份為ADSL使用者上傳的資料流量,藍色部份為ADSL使用者下傳之資料流量統計,比例約為1:3;最大下載流量可達到76Mbps,平均流量亦可達到39Mbps;上傳流量最大可達到22Mbps,平均流量亦可達到13Mbps。

表1 ADSL服務連網人數統計

   月份

單月平均連網人數

單月可用頻寬(Mbps)

1

   729

  45

2

   602

  45

3

   875

155

4

1,240

155

5

1,250

155

6

1,230

155

  【表1】為單月份連網人數統計。此處的連網人數乃由每5分鐘統計當時的連線人數,最後再統計1個月的平均人數得來。由【表1】可知,大約自3月份頻寬升級完成後,ADSL連網人數大幅增加,推論應與連線品質的改善有相當大的關係。目前全院已完成裝機人數共有1,936位,與連網人數資料相比,由1月的38%、3月的46%到5月的65%,比例逐漸增加,可見電腦常掛在網上的使用人口佔相當大的比例。另外由於2月份適逢年假期間,故使用人數相較1、3月不增反減,形成此表的特殊現象。

 
圖2 ADSL服務頻寬升級與連網人數成長趨勢分析

  【圖2】為【表1】之數據資料圖示,更可以清楚看出在頻寬成長後,連網使用者數目也隨之成長的趨勢。

  【圖3】為同時上網人數原始統計資訊。由【圖3】可知,最大同一時間內連網人數可以達到1,546位,平均連網人數亦可達到1,260位。


圖3 ADSL服務同時連線人數原始統計資訊

表2 ADSL服務流量統計 

月份

單月總流量(IN), TByte

單月總流量(OUT), TByte

單月平均流量(IN), Mbps

單月平均流量(OUT), Mbps

單月尖峰流量, Mbps

1

4.04

10.38

12.67

32.50

40

2

3.92

10.25

13.60

35.54

68

3

4.52

12.29

14.16

38.48

71

4

4.14

11.88

13.39

38.45

73

5

4.18

12.07

13.08

37.79

76

6

3.75

11.04

12.12

35.73

73

  【表2】為ADSL流量統計資訊,有單月總流量、單月平均流量及單月最大流量資料。由此表來看,使用者主要的使用習慣仍以下載資料為主,相當符合目前ADSL服務所提供的功能。另外,在頻寬升級後,對於總流量的影響不大,在平均流量的部份增加也不是那麼明顯,因為ADSL服務的使用仍以下班時間的使用量為主;然而在尖峰流量的部份,約增加70%,由40Mbps增加到76Mbps,故頻寬升級對於尖峰時段的
使用品質改善效果較顯著。

 
圖4 ADSL服務各式流量比較分析圖

  【圖4】明顯可以發現,在2月ADSL線路頻寬完成升級後,尖峰流量大幅度增加的比例,相較其他流量統計資訊顯著。

  因中華電信最後一哩(last mile)的基礎建設對於高速ADSL線路的支援仍未能全面推展,現階段本院ADSL連線速率最高仍僅提供2Mbps/512Kbps。本院目前承辦ADSL服務的速率選擇仍以1M/64K為最多,其次為2M/256K,再來則為2M/512K。速率與使用人數分佈資料請參考【表3】。

表3 連線速率與使用人數分佈表 

ADSL連線速率(bps)

使用人數

百分比(%)

256K/64K

     78

  3.9

   1M/64K

1,003

50.3

   2M/256K

   799

40.1

   2M/512K

   113

  5.7

 
圖5 各所申請ADSL服務人數分佈

  另外就院內各所申請人數統計,可以取得【圖5】,由【圖5】中可以發現,生醫所使用人數居全院各所使用人數第1位,其次為分生所及資訊所,而所內申請人數超過100人以上的所處則有7所。

Top

資訊話題
細說「軟體工廠」概念(十六)

(文續第2006年第3期)

利用模型、模式進行程式設計(Programming with Models)

  本期摘錄『軟體工廠』書中第七章的內容:利用模型、模式進行程式設計(Programming with Models)。一開始,我們先重新釐清Model的中文解釋。對於Model這一個名詞的中文解釋,可以稱之為模式(本系列前幾期的中文說明),也可以稱之為模型。因此,我們從本期起,將Model的中文解釋,稱之為模式、模型。

  有關於模式、模型的概念,從前期的內容中,我們概略性的瞭解了其基本的概念,『軟體工廠』第七章的內容主要是闡述如何利用模式、模型來進行程式設計,也就是軟體應用系統的開發。本章的第一部份為介紹模式驅動的發展(Model-Driven Development),其內容包括:利用從模式、模型中所獲得的詮釋資料(metadata),加以解析,可以自動完成軟體應用系統的開發流程中的每一個工作、任務(task)。首先會先介紹詮釋資料如何被使用來協助自動化的流程,包括那些應用;接下來繼續介紹那些工作、任務可
以全部地(fully)或是部份(partially)地自動化,例如:樣式應用(pattern application)、重構(refactoring)、軟體應用系統的建立(build)、軟體應用系統的部署(deployment)、軟體應用系統的測試(testing)與軟體應用系統的除錯(debugging)。

  書中本章的第二部份,討論觀點(viewpoint)對於軟體應用系統開發的影響以及觀點,是如何被使用來辨別不同的軟體產品的面向(aspect,【註1】),然後被模式、模型化,以及不同觀點間的相互關係。而第三部份則是討論到如何將模式、模型給架構出來,從不同的面向去觀察軟體應用系統。我們可以發現不同的方式來將軟體應用系統模式、模型化,以及是否有需要將這些建模的過程給自動化。第四部份則是概略的討論到領域特定語言的內容,以及目前發展的現況、未來的趨勢等等。最後,第五部份則是簡短的討論一下利用模型、模式進行程式設計的下一步為何。

1.模式驅動的發展(Model-Driven Development)

 模式、模型如何被使用來將軟體發展自動化,就是模式驅動發展的主要課題,也就是說:「軟體驅動發展的內容就是要使用模式、模型來自動化軟體的發展」。所以,模式驅動發展就是利用模型、模式進行程式設計。

 而為什麼模式驅動發展可以自動化呢?書中歸納了四個面向來討論,分別為:「完全的自動化、部份的自動化、整合不同的實作技術與跨實作技術的特性」。所謂的完全地(fully)自動化,就是某些軟體的原始碼,可以透過另外一個軟體發展的階段性成果、成品(artifact)中間的內容或是詮釋資料產生。這一部份的工作、任務的特性就是大多皆屬例行性(routine)的工作、任務;而所謂的部份地(partially)自動化,主要的內容就是分析(resolving)軟體發展的階段性成果、成品(artifact)。這一部份的工作需要軟
體開發人員經過設定之後,自動化程式才能依據其設定進行分析自動產生相對應的內容。例如:一個資料庫表格(table)的內容要呈現在一個表單(form)程式中,軟體開發人員必須針對需要呈現的的欄位與屬性進行設定,表單中的內容才會隨之呈現。模式、模型也可以被用來整合不相容(incompatible)的實作技術。書中以Adapter、以Web Service wrapper為例,說明其可以從模式、模型中自動產生,來橋接(bridge)實作技術上的差異。這樣的方式也可以被應用在reflection、protocol configuration and other adaptive integration mechanisms上面【註1】。最後,模式、模型也可以被使用來將軟體移植進不同的實作技術中,也就是說,有了模式、模型,就可以在不同的程式語言中間實作出來,並且有了模式、模型,一旦需求有改變的時候,也可以經由模式的變更,產生出快速與正確的回應(response)。

 從上面的四個面向觀之,並參考書中的內容,我們歸納對於模式驅動發展的必要特徵(essential feature)說明如下:

  • 使用領域特定語言來撰寫軟體的規格(specification),而這一類的規格是以計算型式的格式(computational form)獲得的軟體開發人員的軟體設計意圖(intent)。
  • 可以分離(isolating)及封裝(encapsulating)差異點(variability),所以許多軟體行為的變異(behavior variations)可以藉由設定、組裝的方式被達成(be achieved)。
  • 使用模式驅動發展的環境可以促進(facilitate)軟體的範例(instantiation)、參數化(parameterization)、軟體元件的組裝(assembly of components)以及可以從軟體規格中,自動化的產生完全或是部份的軟體實作。
  • 利用模式驅動發展的相關工具,例如:編譯器、除錯器或是其他形式(form)的自動化工具,開發、利用這些從軟體規格中間獲得的軟體開發意圖的表達方式(exploit the expressions)。

 筆者的觀點:利用模式、模型的概念大家應該都可以接受,但是實作方面到目前為止還沒有一個很實用的工具出現,因此只能經由概念去瞭解。除了模式驅動發展的特徵之外,模式驅動發展的內容還包括了幾項任務,分別說明如下:

(1) 產生軟體(Generating Software)

 參考書中的內容:「自動化最重要的工作就是軟體意圖的規格描述之中,可以產生實作」。也就是,我們需要知道的重點,在於那一個機制如何產生,而且,那個機制是彈性的嗎?回想先前的系列文章【註2】我們曾經提過的,軟體規格描述的是我需要的是什麼東西,而沒有說明那一個東西該怎麼做,而實作就是藉著將軟體規格中的什麼(what)做出來的過程,實作並瞭解軟體規格中所描寫的內容。中間的機制就是:「如何將規格描述的內容做出來?」這一個如何構成了整個模式驅動發展的核心。我們以Web Services的WSDL檔案為例,回顧筆者以前所寫過的Web Services內容【註3】,WSDL檔案利用設定的方式,描述了可以實例化的類別(class)與方法(method)的內容,和利用這些類別與方法的行為。換句話說,筆者所理解的中間的機制,就是所謂的設計。所謂的設計,就是那一個如何的過程;如何的過程並不是單一的,Web Services中的WSDL檔案的作法是一種方法,其他的開發工具、程式開發語言中也可以擁有屬於自己的設計的方法【註4】。

 接下來我們回顧一下什麼是軟體開發的意圖【註2】。如果軟體開發的意圖沒有被正式的紀錄下來的話,那麼未來不論是修改或是實作成另外的技術,例如:從PHP轉換成JSP,都不容易去理解原來的軟體設計的內容。因此,軟體開發意圖亟需工具的協助;如果有了工具的協助,軟體的設計不會再是一個文件,而是一個可以通用於不同平台、不同程式語言與不同開發工具的檔案。所以說這一個檔案應該是一個XML檔案,符合上述的需求,並且可以利用設定的方式達成自動分析、轉換為軟體應用程式的目的。

 書中以微軟的開發工具為例,不論是在類別的建模(Class Modeling)上或是程式碼產生(Code Generation)的機制上,都可以很容易的達成。筆者比較關心的:是開放原始碼的組織中,是否有類似這樣的工具存在?

(2) 自動化樣式(Automating Patterns)

 同樣地,工具的協助也可以應用在樣式上。工具可以協助樣式的制訂者在創造(create)、包裝(package)與發佈(publish)上,也可以協助樣式的使用者在發現(find)、管理(manage)、應用(apply)與評估(evaluate)上。應用樣式可以使軟體應用系統的結構是大家容易理解的;如果大家容易理解,軟體開發人員也就容易修改與維護。所以依據書中的說法,如果樣式應用得當,也就是達成模式驅動發展的目標。

 是否採用樣式的決定,是在使用者的手裡還是由工具來協助。如果仍由使用者處理的話,是可以達成省力(labor – saving)的目標;就像是一般的編輯工具中間,可以協助自動完成的功能,這時候的自由度比較高。如果採用樣式的決定是由工具來協助的話,則目前的軟體工具會因為太少的條件的原因,而使得這樣的方法並沒有具有多大的效果存在。

 如果還是想要達成樣式自動化的目標,則需要一套詳細的架構與工具來協助,包括:建立樣式的引擎(Pattern Engine)、樣式也需要規格化(Pattern Specification)、樣式應用(Pattern Application)與樣式的評估(Pattern Evaluation),有興趣的人可以先參考IBM Rational XDE Developer【註5】。有關於自動化樣式這一個議題,筆者在下期會再補充介紹。

(3) 自動化重構(Automating Refactoring)

 有關於重構(Refactoring,【註6】)這一個議題,簡單地說,就是將原始碼原始的程式碼的架構重新調整過,但是在軟體應用系統的外觀與使用上並不會讓使用者感覺到差異。原本重構的目的在於整理已經寫好的原始碼,讓該原始碼的架構變成一個大家都可以理解的架構。在模式驅動發展中,自動化重構的目的就是利用建立好的模式、模型,轉換為程式原始碼的架構;依據此架構建立相關的原始碼。如果模式、模型有轉換的時候,也可以利用重構的工具同步的修正原始碼的內容。

(4) 自動化建造(Automating Build)

 談到自動化建造,最熟悉的就是軟體開發工具中的相關協助功能。以往軟體開發人員在撰寫系統的時候,必須將該軟體應用系統中的每一個檔案,一個一個利用編輯工具手動完成;這樣的方式除了大量重複性的工作之外,最重要的是每一個檔案之間的相互關聯與一致性,必須透過軟體開發人員非常專注地檢查。現在,這樣的工作我們都透過開發工具來協助。以Java的開放原始碼開發工具eclipse為例,我們只要開啟一個專案(project),便可以建立起有關於此專案相關的檔案,並且在開發的同時,利用同步化工具同時調整需要變動的相關檔案中的原始碼。

(5) 自動化部署(Automating Deployment)

 自動化部署的目標與自動化建造的目的差不多,但是目的不一樣。有關於這一部份發展的最為成熟的,就是Java中的Ant專案【註7】。

(6) 自動化測試(Automating Testing)

 從重構的觀點來觀察,重構除了重新調整程式的原始碼架構之外,並可以經由重構後經過結構化後的原始碼架構,同時建立出相關的測試架構。這一個流程與先前我們提到利用模式、模型可以完全地產生自動化的流程是相同的。有關於自動化測試的相關議題,讀者可以再參考【註8】的相關文章。

(7) 自動化除錯(Automating Debugging)

 自動化除錯就是利用經過設計好的架構分析程式,分析架構與程式的原始碼,利用這程式工具來分析原始碼中間的結構,評估是否違反程式工具中所預定的規則,並進而達到自動化除錯的目標。在此部份的發展,在一般的開發工具中間,除錯工具已經發展多年,但是有時候仍需要軟體開發人員親自修正;雖然距離達到自動化的目標還有一段距離,還沒有達到盡善盡美的地步,但是以成熟度來說,自動化除錯算是已經發展的蠻成熟的部份。

(8) 小結

 經過以上的說明,我們可以歸納出模式驅動架構的內容。簡單地說,就是利用模式、模型來產生軟體應用系統(generating software),其中包括自動建立可以重複使用的樣式(patterns),以及軟體開發流程中的不同需求:已完成的原始碼的重構、整個軟體的建造計畫、部署策略與方法,以及相關的測試與除錯計畫。在此我們要深刻體會的是:利用模式驅動的重點不是要產生程式碼,而是要明確地產生軟體設計的模式、模型出來;也可以簡單的說,就是要產生「軟體設計」。以「軟體設計」這一個名詞來代表模式、模型是較為一般性的說法;掌握這一個重點之後,我們也可以瞭解模式驅動發展的關鍵,就是如何利用一套好的方法在說明什麼(what)的時候,也可以將如何(how)做說明清楚。接下來,該書提到了以視點(view)、觀點(viewpoint)來描述一個軟體應用系統,請看接下來的說明。

2.利用多重視點(Using Multiple Views)

 該書針對模式、模型的重點提出了這樣的觀點:「一個模式、模型必須專注於軟體應用系統的某一個面向
(A model must focus on a specific aspect of the software.)」。
軟體應用系統中的每一個結構想要瞭解的內容都不一樣,書中提了這樣的例子:「以資料庫管理人員(Database Administrator)來說,他們想要知道的一定是有關於這一個軟體應用系統中所會用到的資料庫中的表格(table)是什麼,以及有關於此表格的設計綱要(schema);而網頁的開發人員(Develop)則是會對使用者的操作介面感興趣」。所以說,要有一個好的軟體設定,就必須針對不同的階層與不同的角度來試圖完整的描述整個軟體應用系統。

(1) 軟體架構的描述(Architectural Description)

 「軟體架構的描述原則可以應用在模式驅動發展中」。如果單從軟體設計的面向來說,軟體架構的描述原則就好像模式、模型中的詮釋資料,所以書中才會認為兩者是可以通用的。從先前的系列文章的內容之中,我們會知道軟體架構的描述是屬於整個軟體應用系統的,其包括的範圍較大,甚至將硬體的內容皆包含進來;而有關以軟體架構為基礎的軟體開發發展流程,在軟體工程學中也是一個大門派,但是軟體架構描述的發展最為人詬病的就是過於複雜,學習曲線太高,加上一般業界沒有大眾化的工具支持,以致於「有行無市【註9】」的情況出現。不過,軟體架構描述的概念對於軟體開發流程是正確的、正面的,也對模式驅動發展產生影響。

(2) 領域的特殊化(Domain specificity)

 每一個軟體系統的應用領域,都會有所不同,所以需要去特殊化。當然,我們可以使用一般化的工具建構,但是絕對沒有辦法構建出一個最符合該領域的使用者需求的軟體應用系統,也就是無法達成客製化(customize)的目標。因此,每一個領域都需要專門的領域特定語言,再輔以一般化的領域特定語言,就可達成上述客製化的目標。另一方面,有關於規格的詳細等級,也是在軟體工程學研究中,常常討論的一個議題,這也是之前的系列文章提過的,由於沒有一定的標準出現,所以軟體規格究竟要描述到多詳細,就變成了所謂浮動的狀態。『軟體工廠』一書在此部份說得很含糊,以筆者的觀點,在統一模式語言(UML)與Web Services普及後,筆者相信這一個情況會慢慢改善。

(3) 面向建模(Modeling Aspects)

 除了以架構觀點的角度之外,另外一個我們曾經提過的角度就是面向(Aspect),如何將面向建模,其步驟分別為:解構、組合與框架建立,分別說明如下:

(a) 面向的解構(Aspectual Decomposition)

 面向的觀點,是將原本的程序性、功能性的程式運作流程,以橫切面的角度觀之(又稱之為Crosscutting)。所以很多在不同的程序、流程與功能之中會應用到的概念,我們可以分解抽離出來,將偏功能性的,變成功能性元件(functional component a, functional component b, etc);將偏於面向的,變成面向元件(aspecta, aspect b, etc)。

(b) 面向的組合(Aspectual Composition)

 將面向解構之後,就可以根據不同的需要,重新組合為新的軟體元件(tangled component a, tangle component b, etc)等。

(c) 面向框架(Aspect Frameworks)

 經過重新組合之後,這些重新組合的軟體元件可以組合為可供利用的面向框架(aspect frameworks);這一些重新組合的軟體元件與面向框架也可納入模式驅動發展的流程中,作為其可以利用的相關資產(assets)。

(d) 面向導向的重要性與日俱增

 軟體架構大師Martin Fowler【註10】對於程序性的程式語言的重構功力,我們從其專書「Refactoring(註11)」一書中即可窺知一二;不過對於面向這一個角度的重構方法仍在發展之中,仍屬於學術討論的階段(實作的方法與語言也已經有很多出現了,例如:AspectJ,請參閱【註12】),有興趣者可以參觀Aspect-Oriented Software Association這一個組織及其舉辦的研討會內容【註13】。

(4) 小結

 在還沒有一個標準出現之前,筆者相信有關於利用多重視點來描述軟體的議題討論是不會停止的,也是軟體工程發展的重要方向。

3.如何將模式、模型建構出來(How to Model Software)

 模式、模型裡面的內容是詮釋資料,所以我們需要對於這一些資料、資訊的種類、形式作瞭解,模式、模型是否有表現出行為的流程?這些詮釋資料是否有表現出軟體應用系統的結構?以及如何產出階段性成果、成品。再來討論抽象化的層級應該到那一個層次?最後討論軟體規格應該以何種形式存在?

(1) 模式、模型資訊的種類、形式(Types of Information)

 有關於模式、模型的種類形式,包括該如何描述行為?如何表示結構?以及如何產生階段性成果、成品?

(a) 行為(behavior)

 有關於行為的描述和如何產生,以目前的方法我們可以利用統一模式語言來表示,或是利用流程圖的方式來完成。以微軟的解決方案而言,他們發展一套軟體工具:BizTalk來進行行為流程的描述【註14】。軟體工廠一書則是提到彩色派翠網路被廣泛地使用在商業流程的建模上【註15】。

(b) 結構(Structure)

 有關於結構的描述,在目前的開發工具中,皆可以透過圖形化介面將軟體應用系統的結構給描述出來,並且將這一些資訊儲存在XML等可以流通的檔案中。

(c) 階段性成果、成品(artifact)

 這一部份利用軟體開發工具就可以依據模式、模型建立出來,不過這需要軟體開發工具的協助,才能完成這樣的需求。

(2) 抽象化的層級(Level of Abstraction)

 有關於抽象化的層級與前述軟體架構描述一樣,也是軟體工程學的重要議題。在此筆者的結論就是:在還沒有標準化之前,抽象化層次會因為軟體開發團隊的不同而有所差異。有關於抽象化層級的描述的規則的訓練,建議讀者多參考Refoactoring這一本書【註11】,可以強化抽象化層級的掌握與軟體設計功力。

(3) 軟體規格的形式(Style of Specification)

 軟體規格的形式,主要區分為兩類,第一類為命令式的(imperative),主要的目的在表現行為的觀點(Behavior Views);第二類為宣告式的(declarative),適用於除了行為觀點外的所有觀點。宣告式的軟體規格,主要是說明該軟體規格的屬性,主要著重在什麼(what),而非如何(how);而命令式的軟體規格,則是著重在如何(how),而非什麼(what)。以上這兩類的軟體規格形式是互補的
(complementary);而在模式、模型中,如何將這些程式碼加到模式、模型之中呢?一般來說,大多是宣告式的模式、模型會被附加到命令式的程式碼之中。

4.領域特定語言(Domain Specific Language)

(1) 領域特定語言的概念

 到底什麼是領域特定語言,我們可以透過這樣的方式去想像:「領域特定語言是一個經過抽象化與封裝的過程之後,所得出的新語言」。因為經過抽象化與封裝,所以描述該領域的內容,不會用一般對話或是文章中所使用的動詞,而是經過分析之後該領域所常使用的動詞。例如:我們以資料庫查詢語言,又稱為結構化查詢語言(Structured Query Language,SQL,請參閱【註16】)為例,它的動詞就是select、delete、insert、update,這幾個動詞雖然也是我們熟悉的動詞,但是卻大大省略了我們如果使用一般的語言動詞所產生的複雜程度。所以,領域特定語言的第一個難題就是:如何形成正確又有效率的領域特定語言?在目前的開發工具實作中,我們還沒有辦法看到比較成熟的作法。此外,領域特定語言的另一項難題就是:除了利用文字描述的方式之外,如何利用圖像表達的方式來呈現領域特定語言呢?

 領域特定語言如何建立?首先要有一個很好的物件導向觀念,套用物件導向觀念時,就是希望可以將物件抽象化到一個程度,我們以很多物件導向的書中皆曾提過的例子:什麼是物件?物件就是一個東西的抽象化代表,就好像是汽車,有關於他的特徵,我們都可以不用經過清楚描述(四個輪子等特徵)後,就可以直接知道是一台汽車。所以,抽象化一個很重要的重點就是:關注在該對象的本身,而非瞭解該對象所使用的媒介;要建立模式特定語言的原則也是在此。相信讀者看了也還是會蠻模糊的,這也是目前領域特定語言還無法成熟的原因。

5.下一步(Next Step)

 該書中希望領域特定語言可以發展成熟,促使模式驅動發展可以更加順利與成熟,這一部份還需要業界與軟體工程學者多加努力。

6.結論

 從本章的內容我們可以發現一件事情:許多的概念我們在先前已經重複的說明過很多次,目的就是希望加深印象;為何要加深印象呢?因為這一個概念實在是太抽象了。所以,如果要依據模式驅動發展的概念,將這些技術融合在開發工具之中,以目前的一些大廠的開發工具而言,有些部份是可以達成的,但是有些部份仍然不成熟。所以總體來說,以模式驅動發展來開發軟體應用系統,仍無法達到百分之百的程度;另外一個重點在於:對於一般小的軟體開發公司或是個人工作室,在其軟體開發流程的協助上,究竟有沒有實質上的幫助呢?畢竟,小型的軟體開發公司與個人工作室可能沒有足夠的經費來支付大廠的軟體開發工具。如果沒有開發工具,是否有相關的方法論或是簡單的開放原始碼工具,可以協助進行模式驅動發展的流程進行?

  最後,我們要記得運用模式驅動發展的方式的關鍵在於,不管軟體再怎麼可以自動化,其關鍵因素一定還是在軟體開發人員對於該軟體的設計內容;唯有好的設計內容,才能架構出一個好的軟體應用系統。在下期的內容中,我們將討論目前的軟體語言的結構,不同的結構可以給軟體應用系統開發何種的協助以及目的(待續)。

參考文獻資料:

【註1】:「reflection、protocol configuration and other adaptive integration mechanisms」應該可以翻譯成反映、協定的設定與其他調整性的整合機制,但是筆者認為就算翻成中文後,依然不大合乎原文的意思,因此筆者選用原文於文章中。

【註2】:請參閱前兩期內容,分別為2006年第2期與第3期。Available at URL
<http://newsletter.ascc.sinica.edu.tw/#article_1090>
<http://newsletter.ascc.sinica.edu.tw/news/read_news.php?nid=1078>

【註3】:請參閱《計算中心通訊》第2025期,Web Services技術介紹(二),其中有關於WSDL檔案內容的介紹,available at URL
<http://www.ascc.sinica.edu.tw/nl/93/2025/02.txt>

【註4】:設計(design)與設計決策(design decision)是否有差異?以筆者的理解而言,筆者將設計認定為偏實作開發面;而將設計決策歸納為軟體需求分析面。

【註5】:有關於IBM Rational XDE Developer的簡介,讀者可以先參考IBM的產品介紹,available at URL <http://www-900.ibm.com/cn/software/rational/products/xde_developer/index.shtml>

【註6】:有關於重構這一個名詞於Wikipedia中的解釋,available at URL
<http://zh.wikipedia.org/wiki/%E8%BD%AF%E4%BB%B6%E9%87%8D%E6%9E%84>

【註7】:Ant專案的官方網址,available at URL
<http://ant.apache.org/>

利用 Ant 和 JUnit 進行增量開發,available at URL
<http://www-128.ibm.com/developerworks/cn/java/j-ant/>

JavaWorld論壇中,有關於Ant入門的文章,此篇文章為該入門的第一篇文章,
接下來相關的系列可以於該論壇的列表中尋得,available at URL
<http://www.javaworld.com.tw/jute/post/view?bid=11&id=48098&sty=3>

【註8】:自動化測試工具的相關文章,有關於自動化測試的相關工具,使用Rational Robot實現自動化測試,available at URL
<http://www-128.ibm.com/developerworks/cn/rational/r-autotest/index.html>

以RUP原則執行軟體自動化測試 第一部份,available at URL
<http://www-128.ibm.com/developerworks/tw/library/r-rup-test1/>

以RUP原則執行軟體自動化測試 第二部份,available at URL
<http://www-128.ibm.com/developerworks/tw/library/r-rup-test2/>

【註9】:「有行無市」的成語解釋,available at URL
<http://www.gotop.idv.tw/scripts/word/what1.asp>

【註10】:Martin Fowler的官方網站,available at URL
<http://www.martinfowler.com/>

【註11】:Amazon上面有關於本書的相關說明,available at URL
<http://www.amazon.com/gp/product/0201485672/103-0877675-4899828?v=glance&n=283155>

【註12】:AspectJ的官方網址,available at URL
<http://www.eclipse.org/aspectj/>

Wikipedia有關於AspectJ的解釋,英文,available at URL
< http://en.wikipedia.org/wiki/AspectJ>

日本有關AspectJ的相關介紹,日文,available at URL
< http://www.02.246.ne.jp/~torutk/aspectj/ >

【註13】:ASOD官方網址,available at URL <http://aosd.net>

【註14】:有關於微軟的BizTalk的產品內容說明,available at URL
<http://www.microsoft.com/taiwan/biztalk/default.mspx>

【註15】:彩色派翠網路(Colored Petri Net),是由派翠網路(Petri Net)理論發展出的方法。派翠網路是一種推論的機制,彩色派翠網路加強了派翠網路的應用面,也可以應用在流程的制訂上。Available at URL <http://www.weco.net/blog/?p=115>

【註16】:有關於結構化查詢語言於Wikipedia上面的解釋,英文,available at URL
<http://en.wikipedia.org/wiki/SQL>

Top

創刊日期:74年10月15日
發行人 :廖弘源
總編輯 :曾士熊
編輯小組:林翠娟、謝娟娟
網站技術:張錦堂
出版日期:民國95年8月17日


服務專線:(02)2789-8872
E-mail:publish@gate.sinica.edu.tw
訂閱與取消訂閱 | 各期計算中心通訊 | 中研院計算中心 | 中央研究院

本電子報所有文字、圖片版權為中央研究院所有,未經許可請勿轉載。
如對本報有任何意見,請與我們聯繫。
   
 
 本電子報所有文字、圖片版權為中央研究院所有 。 電子報出版系統由中央研究院資訊服務處開發。