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


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


   
中央研究院計算中心通訊
中央研究院計算中心發行
2006年第3期   民國95年8月3日
簡訊
PNC 2006年韓國年會暨PRDLA、ECAI聯合會議8/15-18舉行

 太平洋鄰里協會(Pacific Neighborhood Consortium)2006年年會暨太平洋數位圖書館聯盟(Pacific Rim Digital Library Association)、文化地圖協會(Electronic Cultural Atlas Initiative)聯合會議訂於本(8)月15日至18日假韓國首爾國立大學(Seoul National University)Hoam Faculty House舉行。其中,太平洋數位圖書館聯盟會議將於8/15舉行、太平洋鄰里協會年度會議將於8/16至8/18舉行。

 本次年會由太平洋鄰里協會及首爾國立大學圖書館共同主辦、太平洋數位圖書館聯盟與文化地圖協會共同協辦;由本院曾志朗副院長率同院內外相關研究同仁及會議承辦人員前往。會議討論主題包括:文化地理圖誌(Cultural Atlases)、Biographical Aspects of Cultural Atlases、數位檔案(Digital Archive)、數位典藏(Digital Collections)、數位博物館(Digital Museum)、Digital Preservation, Digitization Projects, 遠距教學(e-Learning)、數位出版品(e-Publishing)、e-Science、地名學(Gazetteers)、地理資訊系統(GIS)、Humanity GIS toward New Paradigm及韓國文化(Korean Culture)等,邀請來自美、加、英、澳、德、日、港、泰、韓、俄及台灣等十餘國代表參加;議程內容除專題講演及學術研究發表外,另有成果示範及海報區。

 有關本次大會相關資訊暨說明,請逕至太平洋鄰里協會網站查閱參考。

Top

本院台北GigaPoP光纖纜線忠孝東路段將於8月上旬完成遷移

 因配合政府重大公共工程施工,本院台北GigaPoP光纖纜線於忠孝東路七段附近,因採臨時附掛方式佈設容易遭受損壞,導致連線服務中斷;為提升線路穩定及連線服務品質,計算中心規劃遷移方案,並於上(7)月5日與捷運局、養工處等單位辦理會勘,建議將本院光纖遷移至捷運局工程下水道內,預估可使用到明(97)年1月。

 本案安排於本(8)月上旬進行施作,完成後,將可解決本段光纖不容易維護的問題。

Top

完成本院環變中心新辦公室網路建置
 配合本院環變中心搬遷至人文館11樓時程,計算中心為新辦公室提供區域網路及無線網路建置服務。本案採用CAT6結構化網路佈線系統,以單模光纖及CAT6雙絞線達成雙骨幹架構。經測試後,已於上(7)月29日完成驗收。
Top

網路影音服務新增兩項視訊內容

 本院網站上之“影音服務”近期新增兩項影音視訊內容,包括於3月25日假國立台南一中舉行的「院士學思歷程講座」,分別由李遠哲院長、賴明詔副院長、楊祥發院士主講,講題為“領略大師風範、傳承智慧火炬 (片長:2小時50分16秒)”、以及於5月27日假本院物理所1樓演講廳舉行的「朱家驊院長講座」,由劉翠溶副院長主持、化學研究所研究員陶雨臺所長主講“ 一層分子的奈米科技應用
(片長:1小時40分5秒)”。

 上述影音內容歡迎有興趣同仁連線至本院影音服務網觀賞精彩講座實況。

Top

資訊活動訊息--「台北電腦應用展」8/3-7世貿一館展出

 由外貿協會暨台北市電腦公會主辦的「台北電腦應用展」於本(8)月3日至7日於台北世貿中心展覽一館展出。本次展覽共規劃7大產品展示區,包括:電腦系統產品區、週邊設備區、資訊軟體服務區、數位影音產品區、網路應用服務區、育樂多媒體區及資訊文化區等,計有200家廠商使用全館1,400個攤位;展覽時間為每天上午10時到下午6時(最後一天延長至晚間7時),開展當日(8/3)上午10時至12時免費入場;展覽期間行經世貿展場公車將加開班次,另於捷運市府站3號出口亦提供免費接駁公車往返展場。

 今年電腦展亦規劃兩大主題區:「U-Life悠遊數位生活館」展出數位家庭、數位監控、數位醫療及車用多媒體等四大主軸;「國家數位典藏文化館」乃係數位典藏國家型計畫為了讓國人認識數位典藏、瞭解如何運用數位典藏豐碩的資源,特別於現場展示數位典藏內容及成果。對上述內容有興趣之同仁可逕行前往參觀;更多相關訊息說明亦請逕參閱電腦應用展網站

Top

資訊安全
個人電腦安全之防護

前言

  隨著個人電腦與網際網路的發展,原本資訊交換時所需之媒介,如光碟片、磁片等儲存裝置,在網路日益普及之後,已使得資訊不必再完全依賴這類媒體而得以快速交換。雖然知識的傳遞藉由網路可以更加快速,但伴隨而來的卻是病毒、廣告軟體、間諜軟體(Spy ware)、網路釣魚(Phishing)【註1】、木馬程式(Trojan Horse)、後門程式(Backdoor)等不良軟體或程式的散佈。

  在過去,電腦病毒或是具有惡意的軟體在散播時,受限於傳遞的不便,電腦病毒所帶來的災害也往往侷限於小部份的公司行號或個人,災情有限;不過現在電腦病毒可以方便地透過普及的網路傳播,受害對象擴大到可以說全球連接上網路的使用者皆有受到感染的可能。因此,如何做好電腦安全的防護不僅是資訊人員所必須注意的工作,對於一般個人使用者而言,也是極為重要且不可忽視的課題。

網路通訊協定
       
  一般而言,使用者只需要設定好個人電腦的IP與相關設定,即可連上網際網路,之所以可以透過網路交換資訊,其所遵循的乃是相同的網路通訊協定TCP/IP。

  有關網際網路的發展可溯及1960年代,當然美國政府機構為了應付戰爭危機的需求,希望可以在戰時仍能連接各個離散的網路系統,因此委託DARPA(Defense Advanced Research Project Agency)推動ARPANET(Advanced Research Project Agency NETwork),ARPANET的構想與原理所發展出的通訊技術相當成功,也就奠定了今日網際網路的模式;而其電腦通訊細節的網路標準即是TCP/IP網際網路協定。目前,TCP/IP技術主要由INTERNIC(Internet Network Information Center)維護與發展,標準大部份都以Request For Comment(RFC)技術報告的型式公開。RFC文件包含了所有TCP/IP協定標準以及其最新版本。

  TCP/IP協定架構主要可以分為四層,如【表1】所示;資料傳遞的路徑則約略如【圖1】所示。

表1 TCP/IP協定架構

應用層 Application Layer

傳輸層 Transport Layer

網際網路層 Internet Layer

網路介面層 Network Interface Layer

 

圖1 資料傳遞路徑

   其中,「傳輸層」主要提供傳輸控制協定(Transmission Control Protocol, TCP)與使用者資料流協定(User Datagram Protocol, UDP);而「應用層」則是提供應用程式間的溝通。

電腦防護介紹

  針對個人電腦的防護而言,主要就是在「傳輸層」、「應用層」這兩層架構中做處理;防護的方式約略可以分成使用「防火牆」與「防毒軟體」兩種【註2】。

  個人電腦實際在操作時,是以不同的連接埠(Port)進行資料的傳遞。舉例來說,當使用者連結到中央研究院的網站時,其實就是使用者透過使用瀏覽器,啟動一個連接埠,連結到中央研究院網站主機提供網頁的連接埠(通常為Port 80),藉由建立起的連線進行資料的傳遞。

  由於網際網路開放的特性,此時,使用者則需要如防火牆以及防毒軟體等的防護措施,才能安心地遨遊於網路世界。防火牆的運作如【圖2】所示,使用者可以透過防火牆的設定,讓允許的程式或是Port開放連線,而其他不被允許的軟體或是Port則封鎖住,以避免網路上一些奇怪的嘗試甚至是入侵。

圖2 有防火牆網路連線模式

  防火牆的功能即是可以藉由設定,達到管控個人電腦與外界網際網路連線的建立。舉例來說,原本個人電腦在沒有安裝任何防火牆的情況下一旦連上網際網路,則網路上其他的使用者皆可以嘗試與您的個人電腦建立連線,如【圖3】所示;如果此時您的電腦有安全上的漏洞,就非常可能被有心人士入侵。 

圖3 無防火牆網路連線模式

  而「防毒軟體」主要則是針對檔案或資料進行掃瞄,如果檔案或程式受到病毒、木馬程式、間諜軟體的感染時,可以進行解毒、隔離或是刪除等的處理。以一般民眾最常使用的網路服務 - 收發電子郵件為例,當使用者從郵件主機收取或發送信件時,透過防毒軟體得以檢查所收取或發信的信件是否含有病毒之類的惡意程式,如【圖4】所示。


 

圖4 裝有防毒軟體電腦收發信件的模式

  同理,以現今相當流行的即時通軟體(Internet Messenger, IM)為例,現在的防毒軟體也可以同時檢查傳送的檔案是否含有病毒。

相關軟體介紹

  目前市面上所販售的防毒軟體或是防火牆種類相當繁多,筆者整理出幾種比較常見的軟體及其相關的網址資訊,請參見【表2】。

表2 國內常見防毒、防火牆軟體

軟體名稱

相關網址

賽門鐵克(Symantec http://www.symantec.com
趨勢科技(Trend http://www.trendmicro.com
卡巴斯基(Kaspersky http://www.kaspersky.com.tw
Mcafee http://www.mcafee.com
Panda http://www.pandasoftware.com.tw
‧‧‧ ‧‧‧

  【表2】所列的軟體大多是商業軟體需要付費購買,不過也是有少部份有提供個人使用者免費使用,使用者可以多加嘗試,以選擇適合自己的軟體。

軟體舉例使用說明

  以本院為例,多數的使用者皆是使用賽門鐵克的軟體,因此筆者以賽門鐵克所出品的Norton AntiVirus 2005為例,並以此軟體做說明。此一軟體不僅有防毒軟體的服務,同時兼具有簡易防火牆的功能。

  一般而言,當該軟體安裝完畢同時更新之後,其執行畫面應該類似【圖5】。

 圖5 Norton AntiVirus 2005執行畫面

  由於現在的軟體顯示界面都非常的人性化,這套Norton AntiVirus 2005也不例外。當軟體有任何問題時(譬如病毒碼太舊,或是有些服務沒有啟動),其程式執行的畫面皆會有不同的顏色顯示以提醒使用者注意;除此之外,在有安全疑慮的地方程式也加以註釋說明。舉例來說,如果您安裝好軟體卻沒有設定自動啟動防毒軟體的服務,則當您點選該程式時,畫面會顯示相關需要注意的資訊(如【圖6】所示),同時也會有建議的選擇供使用者作決定。

 圖6 Norton AntiVirus 2005未執行自動防護功能

  使用者在使用此套軟體時,最基本的就是要注意該軟體執行後所顯示的相關資訊是否正常,最好的情況應該是在「安全掃瞄功能」與「線上更新服務」兩大部份的狀態都是顯示綠色打勾的情形(如【圖五】所示);如果有任何一項有顯示驚嘆號的情況(如【圖6】所示),使用者都應該注意相關解決的訊息,以期系統與防毒軟體等程式保持在最新的狀態。

  除了上述基本的使用功能之外,此套軟體有提供簡易的防火牆功能,在此也概略說明。

圖7 Norton AntiVirus 2005 Internet病毒防護

  在Norton AntiVirus 2005的功能中,其防火牆的選項是「Internet病毒防護」如【圖7】所示。該軟體提供有幾項不同的管控方法,一般的使用者大概接受預設的規則即可;如果有需要特別的要求,可以針對不同的方法進行設定。譬如使用者在個人電腦上需要使用某一特定軟體,並利用該軟體透過網路進行資料傳遞,則該程式在開始執行之初應該會出現防火牆的警示訊息(如【圖8】所示),使用者可以針對自己不同的需求,進行「允許」、「攔截」或是「手動設定Internet連線」等設定。

 圖8 防火牆設定訊息

  「允許」、「攔截」兩個選擇,文字意義及相當明顯,使用者不至於迷惑,筆者在此針對「手動設定Internet連線」作說明。在選擇「手動設定Internet連線」並按下確認後,會出現如【圖9】的訊息,表示使用者需要針對此一程式新增防火牆規則;而新增的規則有「允許」、「攔截」兩種,其設定的步驟相當類似,只是設定好的結果是相反,因此筆者以「允許」的規則為例進一步說明。

 圖9 防火牆新增規則

  在選擇「允許」之後,會出現如【圖10】的畫面,此處即是設定允許哪些電腦可以使用此程式所產生的連線;如果是選擇「只限定下列的電腦與網站」,即表示只有在列表中的顯示的主機可以連線。

圖10 防火牆新增規則

  接著點選「下一步」,會出現如【圖11】的畫面,此處則是設定允許哪些通訊協定或是允許哪些通訊類型或通訊埠,使用者可以根據不同軟體所使用的連接埠進行設定。

圖11 防火牆新增規則

  之後按照指示進行相關設定,到最後會出現如【圖12】的畫面,該畫面即顯示使用者所新增規則完成的畫面。

 圖12 防火牆新增規則完成的畫面

  以上是針對特定軟體需要開放設定的說明,如果使用者因為某些需求,需要開放特定的Port(譬如架設網站需要開放Port 80),其相關設定的步驟大同小異,使用者可根據個人需求狀況,仿前述步驟加以設定。

結論

  電腦安全的防護不僅僅是資訊人員的工作,一般使用者也需注意相關基本的防護知識,否則在這寬頻普及的環境中若您的電腦不幸中毒或者被入侵,受害的將不僅僅只是您自己的電腦而已,而是所有連結在這個網路上的使用者,不可不慎。

  最後筆者建議「二要、二不要」原則供使用者參考:

二要:

  1. 要常更新:更新系統漏洞(譬如Windows的Windows Update),更新病毒碼。
  2. 要定期掃毒:藉由防毒軟體所提供的排程功能,定期掃毒。

二不要:

  1. 不要隨意下載檔案:對於網路上有許多來路不明的東西,不要隨便下載,因為這些東西都很可能含有惡意的程式或是受到電腦病毒的感染。
  2. 不要執行不瞭解的軟體:在瀏覽網站時,有些有問題的網站會要求使用者安裝軟體,此時您必須注意網站所要求安裝的軟體是否是合法沒有問題的檔案;如果不清楚的話,則最好不要隨便執行安裝那些軟體。

附註

【註1】:網路釣魚的目的是在騙取受害者在網路上的帳號密碼(譬如線上遊戲或網路銀行的帳號密碼)、信用卡資料等個人隱私的資訊,在騙取得到資料之後,直接偷取遊戲虛擬寶物或是將網路銀行帳戶的資金轉帳偷竊走,甚至利用竊取得到的個人資料進行不法的行為。

【註2】:目前許多公司所出品的防毒軟體同時也會整合防火牆的功能,因此防毒軟體與防火牆產品的區隔已經愈來愈不明顯。

Top

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

(文續第2006年第2期)

設計樣式語言封裝(Encapsulating Pattern Languages)

1.什麼是封裝?

 封裝(Encapsulation),這一個名詞,在筆者的概念裡面,應該比較偏向包裝的意思,雖然在『軟體工廠』一書以及一般字典裡面的解釋之中,封裝的主要概念是:將不必要的細節給隱藏起來,但是筆者比較喜歡偏向包裝的意思;不過,有關於這一點的概念,則是見仁見智了。『軟體工廠』一書對於封裝的解釋是:「將不必要的細節給隱藏起來」。這一個解釋又好像有點類似先前提過的抽象化(abstraction),因此在這裡,我們需要針對這一點重新做解釋。針對封裝這一個名詞,該書中的內容是做了這樣的解釋:「封裝把一些細節給忽略,並利用另一套新的詞彙來表示」

 以先前在文章中所提過的,一個城市的大眾運輸系統的網路圖為例,除了捷運路線的簡化是抽象化的代表之外,公車的路線圖則是利用了封裝這一個概念,回顧一下『軟體工廠』一書的解釋:封裝將某些細節給忽略,並利用另外的語彙來解釋。公車路線圖的內容,公車路線名稱、公車停靠站名稱,都是利用封裝的概念產生的。因為如果我們用道路的名稱來表示某條公車路線的話,將讓使該公車路線名稱變的非常冗長,所以一般的公車路線名稱都是利用代號的方式,例如:101-內湖。最近我們可以看到台北的捷運接駁公車路線,就變得更加簡潔;而公車路線上的每一個停靠站則是該停靠站區域的簡稱,或是代表性名稱,例如:台大醫院站等。所以,我們可以看到經過封裝這一個動作,公車路線被重新定義了,包括公車路線中的字彙;另外經過封裝這一個動作,我們也可以針對被封裝的對象,定義其新字彙間的文法。簡單地說,就是我們利用另外一種方式、語彙文法來表達原本複雜的東西,這與抽象化單純的簡化的概念是不相同的。以上是該書
對於封裝的基本解釋。

 而筆者將封裝比喻成包裝的感覺,也是類似這樣的概念。一個喜餅如果沒有經過包裝,我們只會認為他是一般的餅而已;如果經過包裝之後,我們對於它是喜餅的感覺就會增加,原本是屬於一般餅的細節被忽略掉,它被重新定義為喜事用的餅。經過以上的說明,我們可以將封裝解釋為:「忽略不重要的細節、描述,將原本要表達的資訊壓縮為一組與原來的字彙不同的新字彙,並利用另外一套簡潔的方式來表達需要的概念」。

2.定義封裝語言(Defining Language with Encapsulation)

 依據Cleaveland的觀察【註1】,他認為封裝將軟體開發區分為兩個部份,第一部份是軟體規格(specification),第二部份是軟體實作(implementation)。軟體規格定義了軟體中應該存在的元素,但是並沒有告訴我們該如何做。軟體實作則是將軟體規格中所描述的內容實作出來,軟體實作提供了軟體規格中所描述的如何做的知識。就如同我們先前提過的公車路線圖,如果我們要利用公車路線圖來進行我們的旅遊計畫,例如:從101到台北車站的旅遊計畫,我們可以利用公車站牌來做為我們每一個中途停站點的資訊,在我們的腦子之中,公車站牌就會自動映對成實際的道路街名或是該街墎。

 經由這樣的方式,我們可以用比較簡潔以及比較有效率的描述方式來表達。也就是說,軟體規格是比軟體實作更為抽象化的一種描述,軟體規格所忽略的細節正式軟體實作中的細節。軟體規格也是一種比較通用型的描述,利用通用型的描述來表示軟體規格有什麼好處呢?一般來說,我們會說軟體的實作會是比較客製化的,經過客製化後的產品通常是不容易更改、變動的;而用通用性的描述可以讓我們有比較多的彈性存在,就好像我們依據我們的公車路線旅遊計畫來走,如果從A地到B地,公車路線在實際狀況中,可能就會有不同的實際行走路線。也就是說,軟體規格並沒有辦法被直接被實作出來,為了要完成軟體規格所描述的內容,我們必須藉著轉換(translate)將軟體規格變成實作。所以換句話說,封裝就是將軟體規格中的如何分離出來,以及擷取藉由轉換過程中所獲得的重用經驗,變成實作資訊。

 不過在此我們可能會產生一個問題,那就是:為何要另外產生一套語言?筆者簡單地說明如下:「因為一般的程式語言的目的是在操縱電腦,雖然我們在程式語言的內容之中用了許多我們人類的語彙,但是這些語彙大多是邏輯的陳述,與我們一般的概念與語言的邏輯還是不大一樣;軟體規格可以提供比實作更有效率的描述,這效率就是為何我們需要另外產生的一組語言的原因。這一組語言,我們通常稱之為描述軟體規格語言」。最近流行的描述性語言(script language)就是一個很明顯的例子,或許它沒有一般的程式語言的嚴謹度,但是在使用上卻是符合我們的直覺想法,這也是為何流行的原因。

 依據該書中的內容說明,描述軟體規格語言,注重的是效率(efficiency);效率的另外一個同義詞就是power。有關於power這一個名詞,使用中文解釋,例如:力量、威力,可能不大合適,所以筆者只用原文來表示。更有效率的軟體規格描述語言也就代表更有powerful;有效率的語言可以描述更為特定的邏輯與內容,就像我們的公車路線一樣。台北市以前曾經推動過文化公車路線,文化公車路線的內容對於想探訪台北市文化古蹟的人是非常有用的,但是對於一般人來說,效用就不大。就像一般的街道圖,目的是一般化的,可以運用的範圍也比較廣大,但是要針對某些特定目的的使用來說,就比較沒有效率了。依據上面的說明,我們可以歸納出下列的特點:「一個有效率的語言可以在相同的表達模式中間傳達更多的資訊,一個更powerful的軟體語言可以支援更有效率的溝通,達成更多期望的目的」

 從上面的說明,我們可以瞭解為何要定義封裝語言,因為我們無法只用一個語言,就可以從需求轉換成解決方案,從軟體規格變成軟體實作。所以,我們需要另外一組語言來描述,這就是定義封裝語言的原因。

3.正規化設計樣式語言(Formalizing Pattern Language)

 首先我們來解釋formalize這一個動詞的意思,formalize的中文意思是正規化、模式化或是公式化,在此我們採用第一個中文解釋應用在後續的內容中。

(1) 為何要正規化設計樣式語言呢?

 定義了封裝語言之後,我們為了要有一個共通的標準,所以我們需要將封裝的語言給正規化。在上一期的內容之中,我們曾經提過樣式(pattern)的名字就是組成樣式語言的摘要;而且『軟體工廠』一書的作者也曾經暗示我們,一個正規語言是藉著封裝樣式的規格而定義出來的,所以我們可以先回想一下,我們曾經提過,封裝的目的就是產先一組新的描述(軟體規格)來取代實作的描述,我們也曾經提過軟體規格是利用一組新的語言來描述,這一組新的語言的組程式經由封裝的程序流程而完成,而這一組新的語言可以與原先進行實作的語言產生映對(mapping),這也是為何我們產生這一組語言的目的。因此,我們可以在由樣式語言所定義的抽象化的基礎上,利用封裝產生一組新的正規化語言。例如:我們不要利用標準的J2EE Design Pattern Language來達成與Java原始碼的映對,我們利用中間一層的正規化語言,像是某某controller、某某View Dispatcher、某某Business Delegate、某某Session Facade和某某Service Locator等等。利用這樣的語言,利用這些抽象化的樣式,我們可以將一個以J2EE為基礎的應用系統明確地制訂、實作出來。利用這一種方式所產生的軟體應用系統架構,是可以被實用於我們產生的軟體規格之中。

(2) 正規化語言的好處

 將軟體規格語言的好處有什麼呢?正規化軟體規格語言除了有一個共同的標準可以遵循這一個好處之外,第二個好處,依據『軟體工廠』一書中的內容:「這樣的架構是很容易被修改的,也許只需要改變應用系統的樣式就可以適應設計上的改變,或是選擇對於樣式的不同實作策略就可以滿足需求上的改變,或是滿足未來新系統可能遭遇狀況的假設」。換句話說,第二個好處就是利用正規化語言的優勢就是彈性,不管以後程式語言的變動,或是應用程式架構的變動,我們都可以依據其變動的原因做出彈性的調整。

  以上應用正規化語言的兩個好處,並不是應用了就馬上會直接獲得這樣的好處。應用正規化語言的重點在於:「從正規化語言到Java等程式語言原始碼的映對,必須由樣式語言來提供,也就是說這些樣式語言必須提供足夠的資訊來進行實作,提供從軟體規格轉換到實作的相關資訊」。如果沒有這些資訊,那麼我們使用正規化語言就沒有優勢存在了,反而會徒增困擾。

  經過以上的說明,為何需要正規化軟體規格語言呢?其實提供正規化的軟體規格語言的目的很簡單,就是為了要完成軟體規格與實作之間的中間階段的銜接,也就是強化模式語言的功能【註2】。

什麼是模式?

  首先,我們先引用『軟體工廠』一書中的內容:「模式語言就是用來建造模式用的(Modeling language are used to build models)」。為了要完全的瞭解模式語言,我們必須先瞭解什麼是模式。雖然該書在先前已經多次提到模式這一個名詞,但是都沒有明確地定義模式的概念為何?在此,我們也是先用一些比較不正式的定義來描述模式。請接著觀看以下的內容,希望經由這一些非正式的定義的說明之後,我們可以對模式有更加一步的瞭解。

1. 模式就是抽象化(Models as Abstractions)

 還記得『軟體工廠』一書在先前的針對模式的說明嗎?它說:「模式就是軟體的抽象化的描述。隱藏某些軟體的觀點、面向的資訊,將其他沒有被隱藏的觀點、面向的資訊簡單地表現出來」。因此模式可以利用統一樣式語言(UML)中的物件圖就描述出來,例如一個簡單的付款系統,如【圖1】所示。

 
圖1  一個Business entity model的範例圖資料來源:【註3】

 付款系統的物件圖只是簡單地描述了這一個系統擁有那些軟體物件,以及這些軟體物件間的相互關係。這是屬於一般化的描述,所以我們在實作的時候並不會侷限於必須利用那一種程式語言,這也是模式的優點之一。

 另外,我們可以回想一下:軟體的抽象化是將軟體的概念給區分為不同的觀點、面向來處理。所以,模式可以將軟體應用系統中的資訊區隔出來,有些模式可能是描述他的物件的架構,而有些模式可能是描述介面操作的流程,例如:business model、user interface model等。有關於利用不同的模式呈現一個軟體應用系統的全貌的細節內容,將於後續內容中作詳細說明。

2. 模式的可視化(Model Visualization)

 通常來說,我們讀了統一樣式語言的內容之後,我們會把模式認為就是一種利用圖形表示的方法而已,其實模式的表示方式並不侷限於圖形表示法而已。雖然說圖形表示的方法對我們而言,是比較容易理解的,但是圖形表示的方法在實際應用上來說,還是有其不足的地方。因此,模式常常利用文字的模式來協助模式內容的相關說明,例如:屬性等。該書中提到對於模式理解的重點在於:「我們必須瞭解到,明確分辨出由模式中所得出的詮釋資料(metadata)與詮釋資料的可視化是不一樣的」。

 圖形的可視化並不需要將綱要性的內容附載於圖上,而且圖形表示的方法,也不可能完全記錄所有的綱要資訊,這一點是我們必須要瞭解的,這就是圖形表示方法的缺陷。因此,就像我們剛剛所說的,我們可以利用很多不同觀點、面向的模式去表達一個軟體應用系統。

 同理而言,一個模式的內容,我們也可以利用很多不同的方式來表示,例如:目前的都很成熟的開發工具,利用了可視化的使用者介面,並包裝成了相關的的積木模組(widget),例如:精靈(wizard)、對話框(dialogue)、表單(form)與編輯器(editor)等。所以,有關於模式的詮釋資料,可以說是種類繁多、內容繁雜的;也因為這樣的特性,軟體開發人員本身要去維護,也是一項困難的任務。這一類比較簡單的、可以利用程式處理的工作,在目前軟體開發的發展流程中,都會想要利用自動化開發來完成。也因此,模式中有關於詮釋資料的相關紀錄,因為是記錄在文字介面的檔案之中,將可以讓我們利用工具程式去讀取相關的資訊,進行判別與動作,進而達成軟體的自動化開發的目標。

3. 模式就是詮釋資料(Models as Metadata)

 就像我們剛剛提過的,我們必須明確分辨出由模式所擷取出來的資訊與資訊的可視化差異。因為軟體工廠可以實用的關鍵因素在於軟體工廠是依據在模式的基礎上的,利用模式所提供的相關資訊,軟體工廠才可以在不同的觀點、面向上進行自動化的工作。就好像我們一般在寫程式的時候,也需要對我們程式碼進行註解一樣。一個正式的模式是一個可以擷取由人類或是利用軟體工具所產生的詮釋資料的階段性成品、成果。例如:Web Services的標準中的WSDL檔案【註4】。

4. 模式就是軟體發展的階段性成品、成果(Models as Development Artifacts)

 對於詮釋資料於自動化發展的更進一步或是更廣泛的應用是,快速應用軟體發展(rapid application development, RAD)的品質證明(hallmark)。快速應用軟體發展的工具就是基於正式的模式而產生的,但是這些工具並不是完全用來維持一個已經存在的模式,這些工具建立模式的方式是藉由從軟體發展的階段性成品、成果中擷取相關的資訊,例如:從原始碼的檔案中,利用這些資訊轉變成自動化發展的基礎。但是有些部份軟體快速發展工具仍然需要去維護一些存在的模式,例如:相關的設定檔、製造軟體的操作手冊,以及相關的專案檔案等,這些部份需要被維護,大多是因為這些檔案無法從其他的軟體發展階段性成品、成果中被擷取出來。

  接下來我們來討論這些無法自動擷取資訊所產生的問題。

(1) 模式的分割(Model Partitioning)

 模式如果要可以做為軟體的階段性成品、成果的話,就是要將模式的表達內容,利用檔案的方式呈現出來,如此一來,才可以讓軟體開發工具容易存取,進而達成自動化的目標。一個UML的模式所涵蓋的範圍就是一整個系統,所以一個模式傾向於將模式的描述區分為不同的檔案;但是如何分割,在目前並沒有一個共通的標準或是定論,因此,依據書中的描述是:「希望的模式是一個經過良好的組成的流程或編輯單元(a well-formed unit of processing or compilation)」

(2) 模式的參照(Model References)

 既然同一個模式區分為不同的檔案,也就是代表:一個模式中的元素一定要可以與另外模式中的元素進行參照(refer);但是模式之中如何進行參照,在程式語言中已經有這樣的例子。以JSP應用JavaBean為例,我們利用JavaBean來模擬軟體的元件,並且在JSP的頁面程式中宣告我們引用這一個JavaBean,然後頁面程式就會自動地進行參照。所以說,利用程式語言這樣的特性,在軟體原始碼中間,利用以名稱為基礎的參照方式來達成參照的目的。那麼,在模式的敘述上面,我們也可以利用XML檔案的描述方式來進行對於模式的參照的描述。要達成這樣的目標,我們必須進行下列幾項動作:

  • 每一個模式的元素必須要有一個名稱;
  • 每一個模式元素必須定義在名稱空間(namespace)下的範圍(scope)之中;
  • 每一個模式元素必須在其內容中存在一個可以完成經過驗證的名稱,這一個名稱是可以給其他模式參照的時候解析用的。

  以上就是簡單的模式參照的解決方案。

(3) 模式的版本(Model Versions)

 在知道如何有效分割模式,將模式存放在檔案中,並且解決、維護不同檔案間的相互參照問題之後,我們也必須知道,如何有效地管理模式的版本,以利我們在團隊工作時可以有效率的進行軟體開發,以下有幾個我們必須考量的議題:

 第一個議題就是模式的相容性,我們應該如何判斷模式前後版本的差異,在模式中處理的模式的相容性有幾個方法:

  • 直接在模式名稱上依據模式版本來命名;
  • 加入一些地區化的因素考量,例如:英文版與簡體中文版等;
  • 加入其他相容性內容的說明。

 第二個議題就是我們在參照模式時,可以正確地參照到正確版本的內容,處理此議題的方式很簡單,我們只需要在模式的描述內容裡加入可以辨別的模式版本資訊即可。

 第三個議題就是我們在參照模式的時候,如何確認該版本模式的內容還是正確無誤的?在此我們需要產生一個可以信任的機制。有關於版本正確的信任機制,有賴於軟體開發工具中稽核機制的設計。以.NET而言,該語言的軟體開發工具已經支援這樣的需求;而以Java而言,除了一般商業化的軟體開發工具有相關的支援之外,我們也可以尋找是否有類似的開放原始碼的相關專案,來協助我們處理這一個議題。

5.建模或是程式設計?(Modeling or Programming?)

 一般來說,我們會對於建造模式(build model = modeling,建模)與程式設計產生混淆,也不容易瞭解建模的重要性,雖然我們曾經提過模式的特性在於他的詮釋資料很齊全,可以供工具來進行自動化發展之用,所以有人會利用註解(notation)的有無,來判斷他是模式語言還是程式語言。但是事實上卻不是如此,原因如下:

(1) 一般的程式語言都允許在原始碼檔案中間,進行相關的文字註解工作(textual notation),所以就常常會被誤認為程式語言一定是文字的,但是事實上以圖形為主的程式語言的例子也是存在很多的例子,例如:Lego Mindstorms,一個用來建造機器人的圖形程式語言。圖形程式語言定義了圖形元素來表示圖形的程序與操作流程,文字結構的語言並不一定是程式語言,就好像XML是一個大家都知道的文字結構語言,但是它卻不是程式語言。

(2) 模式語言除了文字的內容之外,它還是可以利用圖形化的註解方式來呈現,所以也形成了這樣的誤解:模式語言一定要用圖形表示的方法;也因為利用圖形表示方式的模式語言並沒有辦法有效完整地表達整個軟體應用系統,所以也造成了一般人的誤解,程式語言無法利用圖形表示的方法來呈現。其實模式語言可以利用很多種方式來呈現,就如同我們先前所提過的模式的特性,模式是需要經由不同的表示方式來呈現整個軟體系統的全貌。

 因此,利用軟體規格的形式來判斷是否為模式語言或是程式語言的方式,並不是處在一個合理的推論基礎上。也就是說,我們依據簡單的幾項因素來判斷該語言是屬於模式語言或是程式語言是不合理的,也是不需要的。瞭解模式語言的重要性在於,模式語言與程式語言都是軟體規格的描述,對於軟體開發人員來說,都
是重要的,因此除了基本的程式語言之外,可以協助我們快速發展的模式語言同樣也是重要的因素。

 因為模式語言容易與程式語言混淆,因此Czarnecki將其稱之為GPL(general purpose language,針對一般化的抽象化)與DSL(domain specific language,針對特殊領域的抽象化)【註5】。

  經過以上的說明,希望對讀者而言,可以增加對於樣式與模式這兩個名詞的瞭解,下一期的內容之中我們將進行到如何利用模式語言來進行模式驅動的軟體開發(model-driven development)。(待續)

參考資料與文獻

【註1】:Cleaveland, "Program Generators with XML and Java", Prentice Hall, 2001, ASIN:0130258784。

【註2】:大多數的正規化語言的目的就是將大量使用於低階軟體語言的慣例,這些慣例我們通常稱之為樣式語言或是程式的片語(programming idiom),也就是將這一些慣例編碼成另外一組我們比較懂的語言。

【註3】:本圖來源修改自為『軟體工廠』一書內頁第213頁圖6.8,有興趣的讀者可以參閱原文。

【註4】:Web Service Definition Language (WSDL),定義Web Services的語言,內容記錄於由XML文件中,請參考W3.org的定義,available at URL <http://www.w3.org/TR/wsdl>

     另外,以可以參考在Wikipedia中,對於WSDL的中文解釋,WSDL – Wikipedia,available at URL < http://zh.wikipedia.org/wiki/WSDL>

【註5】:請參閱原書中的內容,K. Czarnecki and U. Eisenecker, "Generative Programming: Methods, Tools, and applications", Addison-Wesley, 2000。

Top

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


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

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