代理人導向的程式設計方法

作品

書籍

課程

程式集

小說集

論文集

散文集

影片集

編輯雜誌

程式人

電子書

JavaScript

計算語言學

微積分

Blender 動畫

C# 語言

系統程式

高等 C 語言

Java

Android

Verilog

Wikidot

R 統計軟體

機率統計

計算機數學

組合語言

人工智慧

開放原始碼

網路資源運用

計算機結構

相關訊息

常用工具

友站連結

在家教育

RSS

最新修改

網頁列表

簡體版

English

我相信對於『知識管理、累積、與活用』的能力是未來企業最重要的一個利器,我從進入中研院後就開始探索這個課題,因為、這樣的課題對於高科技業來說尤其重要(尤其是軟體產業),資訊科學系畢業的人如果有團隊合作的經驗的話,就會發現一件事情,程式設計絕對不是 1+1 = 2 的行業,對於絕大多數的公司來說 1+1<1 1+1+1«1,為何?

因為程式是一個與知識緊密相關的是數位體,與個人的知識、想法與創意緊密相關,如果離開了人,程式就是一個死的東西。

相信不少人在工作上曾經發現某人離職後它的東西再也沒有人碰過的情況,接手的人會說:

『他寫得很爛,我重寫一個比較快』

這是目前軟體公司的一大問題,無法克服此問題,生產力必然極低,即使 Microsoft 都無法做得好,然而、Linux所採取的 Open Source 的方法,開創了一個新的軟體模式,值得觀察,或許會是一條成功的道路。

另外、目前的 Software Development 有一個相當大的問題,傳統的結構化程式設計方法,由於資料與程式分離的結果,使得軟體無法抽離單獨運作,因此、導致下列狀況:

只有單純的程式 例如: sin(x)。$$
或者單純的資料 例如: 資料庫中的資料。
才能夠 reuse。

80-90 年代所興起的 Object Oriented Design/Programming,對軟體工程來說是一大進步,Algol68 與 Smalltalk 立下了一個良好的典範,使得 reuse 變的較為可行,然而、軟體即使可以 reuse ,仍然是一個死的東西,如何才能使軟體具有彈性,可以『活著』,是我這幾年一直在探索的問題,有 Object reuse 經驗的人,一定會發現 Object reuse 非常的不容易,即使你所reuse 的是
Microsoft 經過千錘百鍊的元件,仍然感到具有相當高的進入障礙,遑論是自己公司開發出來的『私用性』軟體。

Object reuse 不容易的原因是:

每個人必須完全瞭解 Object 的 member function 的功能、格式與參數才能使用一個 Object ,然而、單一的 Object 又通常不具備所有我們想要的功能,於是、必須是一整個 framework (例如:C++ 中的 STL,MFC) 等等,才具有 reuse 的價值, 然而、一整個 framework 的學習障礙將會非常的高 (想想你學習 MFC 或 OLE 時的經驗吧!)

因此、Object Oriented Programming 仍然亟待改進。

解決的辦法是甚麼呢?

數年前我開始思考 Agent Oriented Programming 時,開始有了一些進展,目前對 Agent 的看法實在是非常分歧,學術界亦是如此,一年前我在中研院報告過下列想法:

只有以『字串性溝通介面』互相溝通,具有 Plug & Play 特性的軟體,才是以 Agent Oriented Programming 方法發展的軟體。

以 Agent Oriented Programming 發展的軟體有何好處呢?

一個 Agent 所提供的介面只有兩個,以下以 C++ 為範例,提供解說:

   class agent  {
   public:
      string remember(string message) // 記住 message 所提供的訊息。
      string answer(string question)  // 回答 question 所詢問的問題。
   }

就這麼簡單嗎?是的!

Agent 的設計人員不應該假設 reuse 的人(user) 完全瞭解它的元件,而應該反過來,agent 要能夠懂得辨認 user 的要求,並回答 user 的問題,執行 user 所交付的任務,例如:

      mathAgent agent;
      cout << agent.answer("sin(Π/6) = ?") << endl;
      cout << agent.answer("請問 cos(Π/2) 是多少?") << endl;

上述程式將會輸出:

      0.5
      0

再舉一個例子:

      politicAgent agent
      agent.remember("李登輝是台灣現任總統!")
      agent.remember("李登輝是國民黨主席!")
      cout << agent.answer("李登輝是誰?") << endl;
      cout << agent.answer("1993 年的台灣總統是誰?") << endl;
      cout << agent.answer("連戰是誰?") << endl;

上述程式將會輸出:

2000年2月11日時他是台灣總統與國民黨主席!

我不知道1993 年的台灣總統是誰!但是 2000年2月11日的台灣總統是李登輝。
我不知道!

一旦我們這樣寫程式,那就可以將這些物件 Plug into a Software Blackboard,這個 software blackboard 只需要負責分派問題給具有回答該問題能力的 agent,然後整合答案後 feedback 給 user 或執行 user 所要求的動作即可!

如此、將造成軟體 reuse 上的極大方便,(想像 Microsoft 如果以這樣的方法設計程式,你將可以問 MSDN 的 HELP 系統,"請告訴我哪個元件可以用來抓取網頁?",此時 MSDN HELP 將會告訴你該 agent 的目錄與功能,然後你只要寫下:

  string yahooHtml = MicrosoftAgent.answer("幫我抓www.yahoo.com !)

他就會傳回該網頁的所有內容給你!

這可以提高多少的生產力,降低多少的學習成本呢? (注意:這會使得單一元件的設計成本提高!)

目前、我設計元件時,對於要 reuse 的元件,也常會採取這樣的方法!

這種設計方法一定要配合強大的自然語言處理能力嗎?其實也不盡然,因為針對每一個物件只要針對其所提供的能力預想問題的詢問方式即可,當然有正確的自然語言理解能力可以讓使用者更彈性的下指令。

Internet 的興起對 Agent Oriented Programming 有相當大的促進作用,HTML 本身就將我們從二進位的固定格式中解放出來,使整個 OS 平台的可讀性大增 (你可以想像寫一隻程式去讀 MS Word 的 doc 襠有多麻煩嗎?然而、 讀HTML 就簡單多了),目前、WWW Consortium 所制訂的 XML 更進一步解放了固定格式的問題,使得 Markup Language 有可能自行發展,RDF (Resource Description Format) 更企圖訂定各個行業能專用 tag 這使得 agent oriented programming 得以向前邁進,不必等自然語言處理的能力成熟。

Facebook

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-NonCommercial-ShareAlike 3.0 License