系統分析員之路(1)－－論物件導向技術在呼叫中心開發的應用 (轉)

系統分析員之路(1)－－論物件導向技術在呼叫中心開發的應用 (轉)[@more@]

前言：本人在準備分析員考試中論文部分的習作，請大家打分（總分75分），並指出可取之處與不足之處，謝謝！

  論面向技術在呼叫中心開發的應用

摘要：呼叫中心產品是當前應用的一個熱點，透過該產品，客戶可以足不出戶的享受方便快捷的
語音與傳真等服務。對企業來說，建立呼叫中心對於提高客戶滿意度，爭取客戶乃至增長利潤都有
極大的意義。目前呼叫中心在各行各業特別是金融業得到了廣泛的應用。本文從筆者參與的銀行呼
叫中心專案開發的經歷出發，討論了採用物件導向技術的理由及過程。同時，討論了物件導向技術
在開發中的應用，如：物件導向設計原則、UML技術、設計等，使設計的系統擁有較好的可重
用性、易維護性。

正文：
  我所在的單位是把目標定位在金融領域開發IT應用的一家資訊科技公司。隨著金融電子化建
設的發展和商業銀行之間市場競爭的加劇，各主要商業銀行不斷透過資訊科技提供新的金融產品，
以期為客戶提供更好的服務並且整合市場渠道。比如各銀行紛紛推出呼叫中心，使客戶能夠足不出
戶地享受7×24×365的服務。本人作為公司呼叫中心專案組的一名技術骨幹，有幸參與了該產品的
研發、推廣、升級。

  選擇物件導向技術的原因。呼叫中心透過公用電話網為客戶提供語言與傳真等服務，主要由語音
（IVR）、傳真伺服器（Fax Server）、坐席端（CSR）等子系統組成。我們公司的第一代產
品主要採用結構化的方法進行分析、設計、編碼。此產品在全國多家銀行推廣使用。由於客戶的需求
不一樣，我們的產品需要客戶化，同時，由於客戶需要的規模不同，語音卡可能採用不同的廠家的不
同系列產品，這樣，隨著應用的推廣，結構化方法的弊端也逐漸顯現出來。首先是模組之間的耦合性
太強，程式碼不好理解、維護。經常出現“牽一髮而動全身”的情況，有時工程師進行維護的時候，局
部的改動也會影響到一大片。另外，模組複用性很差，在此背景下，公司組織技術骨幹進行討論，
以期找到一種理想的解決方案來改變這種局面。以往的開發使我感覺到物件導向技術比較適合於
此類應用系統的開發。於是我提出我的設想及初步方案，得到了大多數與會者的贊同。會後，我正式
寫出了技術改進方案，並應用原型法作出了一個簡單原型，向公司領導及其他技術人員演示了面
向物件開發的優點。技術改造建議書與原型得到了領導的讚許。為了降低風險，而且呼叫中心的各個
子系統相對獨立且在架構上有很多相似之處，於是，我考慮可以利用呼叫中心的一個子系統傳真服務
器作為試點進行開發，效果明顯的話再考慮其他子系統的改造。在這個改造的過程中，我使用了多種
措施來達到預期目的：
  1）物件導向設計原則的應用。在舊系統中，主要因為模組之間的耦合性太強，全域性變數太多，Case
語句太多而引起系統的重用性、維護性差。要解決這個問題，我們採用了面相物件中封裝的特性來實
現資訊隱藏。透過抽象，把系統分解為一些相互通訊的物件，這些物件向外隱藏實現細節，物件之間僅
僅知道對方的介面，這樣，他們的耦合性大大降低，為複用提供了可能。在物件導向設計中有一個重要
的設計原則：OCP原則（The Open Closed Principle),就是說設計物件時，要使它易於擴充，但擴充
的前提是不修改已有程式碼。這在結構化中簡直是不可思議，但我利用了物件導向的多型特性來實現
了這一原則。例如，這個子系統需要採用傳真卡，而傳真卡有數字卡與模擬卡，不同廠家提供的也
可能不一樣，在以往的結構化程式設計中，要麼一種板卡一套程式，要麼程式碼中充滿了switch...case語句。
我們利用了多型的特性，抽象出板卡之間的共性作為基類，而具體採用的板卡從這個基類上派生出子類
即可。這樣，不同的板卡，就是採用了不同的子類，維護性就大大增加了。
  2）UML（Unified Modeling Language)的採用。就像建築工程師需要畫出建築設計圖一樣，工
程師也需要一種建模工具，來進行設計、交流、寫文件。UML作為物件導向建模語言的標準，成為我的
設計首選。不少軟體工程師（包括以前的我）都有這樣的壞習慣：一坐下來就是開始寫程式碼，程式碼邊寫
邊改，有時到快寫完時才發現有嚴重的，從而導致質量、大打折扣。在UML中，我們可以透過
多種圖，從不同的角度來描述我們要設計的系統，在畫圖的過程中，我的思路就變得清晰起來，對系統
的理解也就越深。這樣就避免了重編碼、輕設計的弊端。由於UML是建模標準，透過在專案組內、公司
內的推廣學習，使開發人員之間的交流方式得到統一，也能使程式設計師準確地理解設計，避免二義性。在
這個專案中，我用 Visio2002畫出了類圖、序列圖、活動圖等，使我的設計思路逐漸清晰。
同時，這是公司第一個採用UML進行設計的專案，對公司的文件標準化程式也是一種有益的嘗試。
  3）設計模式的理解運用。設計模式是一些常見的設計問題的的優雅、巧妙的解決方案，透過“模仿”
設計模式，即使是物件導向設計的初學者，也可實現大師級的設計，從而擁有極好的靈活性、重用性。
在設計這個系統之前，我有幸拜讀了Erich Gamma等四人的著作《設計模式》，從中得到的設計靈感以
及設計原則使我受益頗深。比如：傳真伺服器設計中，只允許有一個訊息佇列，為了避免意外，採用了
Singleton（單件）模式，優美地解決了這個問題。另外，採用了Template模式，實現了業務流程的定
制等。設計模式對促進專案組內的技術交流有很大的幫助，一句“在這裡採用了Template模式”比畫
出幾個類圖、互動圖要有效許多。當然，前提是對方也知道Template模式。
  這個技術改造專案歷時一個多月，取得了理想的效果。改造後的系統執行在上，採用C++實現，
系統架構很清晰，這可以從UML的類圖與包圖看出來。程式碼重用性強，後來的這套系統移植到WinNT平臺，
除了跟Unix底層的機制有關的訊息佇列類、共享類要修改外，其他均實現了平滑移植。這個系統經
評審後，被認為成功的達到了預期目的，為其他子系統的改造提供了良好的基礎。
  物件導向技術的優越性明顯，但它的要求也較高，它需要設計者要對物件導向的思想有較深入的理
解，否則很容易用結構化的程式設計思想來寫物件導向的程式，這樣不但達不到預期目的，反而弄巧成拙。