2014年9月12日 星期五

CodeIgniter PHP Framework

    CodeIgniter是一套小巧但功能强大的 PHP 框架,它有完整且清楚的使用說明、使用族群眾多、有完善的社群與討論支援、不需安裝(解壓到網站目錄下即可)、執行速度快效率高、具有標準的MVC架構等等,相當適合個人及中小企業在開發時使用;我推薦它的主要原因有三點:一是安裝容易、二是它的學習門檻低,三是它的架構相當清楚,這三項優點對於剛接觸PHP的新手或正在找尋適用的PHP框架人員來說,是相當值得列入考慮的。
  我在本文將介紹怎麼設置Codeigniter的開發環境,如何與Bootstrap進行整合,並且怎麼樣利用一些免費的Bootstrap樣版,快速製作出適用於手持裝置及PC的跨平台網站。

PHP是目前最流行的伺服端語言

  PHP是目前最流行的後端網頁開發語言,大多數初跨入IT領域的人若是想要學習後端開發立刻聯想到的語言就是PHP,這個語言看似歷史悠久,但其實它也算是年輕的程式語言,約20年前1995年的時候,由丹麥程式設計師由勒多夫(Rasmus Lerdorf)所開發,它屬於開源的程式碼,使用PHP完全是免費的。
  依據w3techs.com最新的統計資料顯示(2014年八月),全球有高達82.2%的網站是使用PHP開發,其次為ASP.NET,再依次為JAVA與ColdFusion。
  但是這個統計並不是嚴格的統計,因為只要網站有一部份使用到了PHP語法,便會歸到PHP,而實際上,大部份的Linux web伺服器在預設安裝時便已把PHP作為預設安裝選項了,因此這個統計值可能包含了很多架設於Linux web server的純HTML的網站,所以比例會偏高。另一個比較客觀的比例應該是PHP與ASP.NET的比例約在2:1左右(來源:http://trends.builtwith.com/framework
  我在開頭指出PHP使用比例特高的原因,並不在於強調PHP有多麼流行,而在於說明PHP作為一個普遍廣為使用的網頁語言,它不僅適用於剛入門的程式開發者,也適用於個人、團體及至於企業的網站用途;大陸知名的網站掏寶網於2003年成立時,就是用$2000美元購買了一套PHPAuction的網站樣本加以修改後推出的,這個LAMP架構的掏寶網站系統(Linux+Apache+mySQL+PHP)用到2004年初,商品累積到四百多萬、每日的PageView四千多萬、註冊會員人數400萬個、成交金額達10億人民幣後,mySQL因逐漸支撐不住才改換為Oracle Database,而當時的後端開發語言則一併由PHP更改為JSP;另外,下表的資料來自於維基百科,是一些知名網站所使用的前端與後端及資料庫的統計表(http://en.wikipedia.org/wiki/Programming_languages_used_in_most_popular_websites),其中Facebook一開始是單純的PHP網站,後來才加入其它開發語言的支援。
JavaScript
Hack, PHP, C++, Java, Python, Erlang, D,[5] Xhp[6]
Flash, JavaScript
C/C++, Python, Java[8]
MySQL, BigTable
JavaScript
PHP
JavaScript
JavaScript
ASP.NET
Microsoft SQL Server
JavaScript
PHP
MySQL, MariaDB[10]
JavaScript
Python
BigTable
JavaScript
ASP.NET
Microsoft SQL Server
JavaScript
MySQL[12]
JavaScript
PHP
MySQL
JavaScript
Java, J2EE, C++, Perl

JavaScript
Java[13]
JavaScript
Java, Scala, JavaScript (Node.js)

JavaScript

CODEIGNITER環境設置

    在開始之前,請先準備好一個可以執行mySQL 和 PHP的環境,如果您有Linux平台,那麼應該知道怎麼去安裝設定一個LAMP的環境,如果您是使用Windows的系統,您也可以下載安裝這些已包裝好且容易安裝設定的Windwos版LAMP軟體,如WAMPWinLampEasyPHP等等。
  1. 下載CodeIgniter並解壓縮

  CodeIgniter的網站在https://ellislab.com/codeigniter,中文版的位址在http://www.codeigniter.org.tw/,在其下載頁面目前最新的版本是2.2.0;下載之後解壓縮,將全部的檔案放置於我們網站的根目錄之下(如下圖,我們將CodeIgniter_2.2.0目錄下的檔案除了user_guide和license.txt用不到以外,全部皆放到C:\Apache2\htdocs\的預設網站目錄下的myNewWebsite這個新增的資料夾)。

  1. 在mysql新增資料

請開啟phpMyAdmin(在您使用LAMP程式安裝後,此網頁版的資料庫工具應該也會一併安裝),我們先建立一個稱為myweb的資料庫,再於其下建立一個名稱為users的資料表。
users這個表格共有四個欄位,您可以參考下方的圖示來手動建立,或者直接執行下方的SQL程式碼來產生。





    users資料表產後後,我們輸入二筆資料,當然,您也可以複製下方的SQL碼來執行:
    或者執行下方的SQL也可以新增此兩筆資料。




  1. 設定Codeigniter的開發環境

剛下載的CodeIgniter檔案,我們只需要更改二個檔案的內容,就完成了CodeIgniter環境的設定,可以開始使用了。
    1. 編輯C:\Apache2\htdocs\myNewWebsite\application\config\ config.php,修改$config['base_url']的內容如下:
$config['base_url']    = 'http://localhost/myNewWebsite/';
    1. 編輯C:\Apache2\htdocs\myNewWebsite\application\config\ database.php,將相關資料庫的資訊輸入,如此一來,我們在操作DB時便可直接在程式中呼叫,CodeIgniter會替我們處理其餘的動作:
    基本上,作完上述步驟,CodeIgniter的基本環境便已經完成了,可說是相當的簡單;我們作個測試,在瀏覽器輸入http://localhost/myNewWebsite/網址後,就應該出現如下圖的頁面,這是CodeIgniter成功運作的預設畫面:

CODEIGNITER是如何運作的?

  在下方我將介紹CodeIgniter的資料夾配置及運作方式和流程,有了這基本概念後,您就會對於如何在CodeIgniter環境下撰寫PHP程式有初步的概念。

  1. Codeigniter的檔案配置

    在剛剛解壓後的目錄下,您應該會發現C:\Apache2\htdocs\myNewWebsite的根目錄下有一個index.php,另外,我們比較關心的還有在application目錄下的controllersmodels、views等三個目錄,它們分別代表了MVC架構(Model / View / Controller)的三個目錄,也是我們程式以及頁面主要放置的地方。
  1. Codeigniter的運作流程

  下圖是CodeIgniter運作的流程,下面我會說明這些主要的步驟,但是您不需要完全瞭解,只需要知道CodeIgniter在接收到使用者需求並回傳網頁之前,會替您作這些動作。
  1. 當使用者存取網站時,最上層的index.php這個網頁是CodeIgniter最前端的控制器,它會啟始化所需的資源並執行CodeIgniter。
  2. CodeIgniter的Routing程序(C:\Apache2\htdocs\myNewWebsite\application\config\routes.php)檢查使用者呼叫的網址,決定如何處理或導向。
  3. 如果在Cache(快取)中有被呼叫的檔案,則直接回傳給使用者,不需要往後傳送。
  4. CodeIgniter security檢查機制:在往後傳送給CodeIgniter Controller前,會先針對該HTTP Rrequest以上傳的檔案(如果有的話)進行檢查。
  5. CodeIgniter Controller載入model(資料庫)、core libraries pluginshelper以及其它與該HTTP Request相關的資源。
  6. 最後產生的View(html頁面)會傳送給使用者端,如果有啟用cache功能,則會將該頁面保留在cache中。
  1. Codeigniter的MVC流程

請參考下方的流程圖:
      1. 最左方的BROWSER代表使用者,他發出了一個HTTP Request,此Request會先由Controller來接收。
      2. 若有需要資料的提供,Controller會發出請求請Model執行,Model執行後將結果回傳給Controller
      3. Controller收到Model提供的資料後傳給VIEW,VIEW產生所需的頁面並將相關的資訊放入,再將此頁面回傳給Controller。
      4. Controller收到VIEW製作好的頁面,將此頁面傳給使用者觀看。

http://bernard-very.com/wp-content/uploads/2012/08/mvc-architecture.gif
我們會發現,Controller是整個MVC流程的核心所在,所有的動作都是由Controller發出,而Model與View這兩者之間並不會直接聯繫,都必須透過Controller;另外,我們必須留意到,CodeIgniter所需要的網址格式是由Controller的名稱加上功能名稱及參數組合而成;例如,一個標準的CodeIgniter網址是:
http://example.com/class/function/ID
   第一段代表的是控制器(controller)啟動的類別(class)
   第二段代表的是類別(class)函數(function) 或者是 method 被呼叫使用。
   第三段之後,代表的是 ID 或是任何變數準備要傳遞給控制器(controller)所使用。
在稍後進行的範例中,您就會看到我們使用的網址格式。

CODEIGNITER與Bootstrap的整合

將BootStrap整合到CodeIgniter之後,我們就可以套用眾多的BootStrap樣版主題或者利用相關的cssjavascript等等資源,快速的將網站的外觀進行美化。

  1. 整合Bootstrap

    1. 下載Bootstrap檔案並解壓:
      1. 首先到http://getbootstrap.com/下載最新版本的Bootstrap(目前為v3.2)
      2. 解壓後有三個目錄,直接放在網站的根目錄(C:\Apache2\htdocs\myNewWebsite)下。
      1. 修改網站根目錄下.htaccess的內容:如果沒有此檔案請新增一個,檔案內容如下



為什麼我們要作這個更改?
RewriteRule ^(.*)$ index.php/$1 [L,QSA] 
index.php這個檔案從URL中隱藏,讓網站網址更簡捷且更安全,例如,原先的網址如果為http://localhost/myNewWebsite/index.php/update_pwd,就可以縮短為http://localhost/myNewWebsite/ update_pwd
RewriteCond $1 !^(index\.php|images|css|js|fonts|robots\.txt|$)
在縮短了網址之後,CodeIgniter可能會找不到原先放置於根目錄下的css, js, fonts等等目錄(會跑到controller下找),所以我們必須加入此行以宣告這檔案或目錄不受影響。
  1. 套用Bootstrap網站主題樣本

  提供Bootstrap樣本主題的網站有很多,有些是免費有些則是收費的;我們先到http://startbootstrap.com/這個網站下載一個免費樣本來試試。
在這裏我先選擇中間那個主題樣本,按下Preview&Download,我們發現Bootstrap的主題樣本就是一個完整的網站,包含了整個網站所需的Bootstrap、JQuery、css等相關檔案。
  1. 我們依照前述的整合BootStrap的方式,將整個樣本的目錄放到網站根目錄之下。
  1. 您還記得上個章節中我們有修改.htaccess這個檔案嗎?由於這個我們在根目錄下除了css、fonts之外,還多了font-awesome-4.1.0、img這兩個資料夾,因此,我們必須再將這兩個資料夾名稱,放在RewriteCond中,以避免CodeIgniter找不到。



  1. 複製網站樣本的index.html內容到C:\Apache2\htdocs\myNewWebsite\application\views\ welcome_message.php
  2. 測試,輸入網址http://localhost/myNewWebsite/,會發現網站成功的套用了樣本內容。
  1. 將BootStrap範本拆分為三大部份

  接下來,我們將此網頁拆分為headercontent、footer三大部份,content是我們主要的、會變動的內容,header與footer為不會變動的固定內容用include的方式自動引入,這樣的好處是,我們只要更改content相關的網頁,footer與header由於都是固定不變的內容,只要用引入的方式就可以了,可以大大減少網頁的體積,並且讓整體架構更清楚簡單。
      1. 在C:\Apache2\htdocs\myNewWebsite\application\views下新增一個pages資料夾,並在此資料夾下新增2個檔案:header.php與footer.php
      2. 用文字編輯軟體打開C:\Apache2\htdocs\myNewWebsite\application\views\ welcome_message.php,找到<body>標籤,將此標籤(含)剪下放置到header.php中。(如下圖紅框部份)
    1. 繼續針對welcome_message.php操刀,找到<footer>標籤,從此標籤(含)一直到最後全部剪下放置到footer.php中。(如下圖紅框部份)
    1. 用文字編輯軟體打開C:\Apache2\htdocs\myNewWebsite\application\controllers\welcome.php,將index() function的內容,再增加兩行來引入header.php 和 footer.php。(紅色部份)





    1. 改好後,我們再試看看,應該會出現同樣的畫面,只是這個畫面是由三個部份組合而成的。

呼叫MODEL取得資料

  直到目前,雖然網站可以運作了,但是只有Controller與View在工作,我們還沒有使用到Model的功能;現在,我們打算讓網站從資料庫中抓出使用者的姓名,並顯示在主頁上。
  1. 我們在model的目錄下(C:\Apache2\htdocs\myNewWebsite\application\models),新增一個名稱為user_model.php的檔案,內容如下:















get_users這個function會替我們抓出資料庫的users這個表格中所有的資料,如果有傳入account的值,則僅會抓出這筆account的資料。
  1. 接下來,我們要在Controller中去呼叫這個model,請打開welcome.php這個檔案(C:\Apache2\htdocs\myNewWebsite\application\controllers\welcome.php),修改index()這個function的內容如下:(紅色為增加的部份)














首先,我們先宣告了要使用user_model,當controller載入頁面時(index()為預設會觸發的頁面),會呼叫user_model得到資料,然後放到$data[‘users’]變數中。
$this->load->view('welcome_message',$data);
表示當controller從view要載入welcome_message.php時,則把放有資料的$data傳過去。
  1. 最後,我們要來處理view下的welcome_message.php這個檔案以便接收Controller傳過來的資料,請找到<div class="intro-message">標籤,參考下方紅字部份進行修改:




  有一點要特別注意的是,我們從Controller那邊丟過來的資料變數名稱是$data,但是在View接收時,data這層要移除(因為$data是默認的),因此,如果我們從Controller那邊定義的是$data['title'] = 'MODEL測試,那麼在View這邊接收時,只要用$title就可以了,同理,我們在Controller那邊將Model所傳回的資料以陣列Array的形式都放在$data['users'],所以我們在View要使用時,就要用$users[1]['realname'];來取得第二筆,欄位為realname的資料。(您可以用print_r($users) 這個function來檢視全部array的內容)。
  執行結果如下,我們可以看到,

最後

    如果您有依照上述的步驟來進行練習,您會發現我所示範的順序是:
解壓CodeIgniter到網站目錄下 → 將BootStrap檔案整合到CodeIgniter → Controller透過Model讀取資料並經由View顯示。
如果仔細觀察的話,您會發現在示範中的Controller名稱是welcome.php,那麼,您應該會有一個疑問(如果您有仔細閱讀的話),依照http://example.com/class/function/ID這樣格式的定義,我們輸入的網址不是應該為http://localhost/myNewWebsite/welcome才能呼叫welcome.php這個controller才對不是嗎?但我們在示範中使用的卻都是http://localhost/myNewWebsite/沒有Controller class名稱的網址?
其實祕密叫在CodeIgniter的config資料夾下面的routes.php檔案中,請把這個檔案打開來看,您會看到下面這行:
$route['default_controller'] = "welcome";
    這行的功用就是,告訴CodeIgniter網址中若沒有指定的Controller,預設就載入welcome controller,所以這是為什麼我們只要輸入http://localhost/myNewWebsite/ 就會直接開啟welcome.php的原因了!而且當CodeIgniter載入welcome.php之後,它預設就會開啟index()這個function,而我們已經在index() function當中定義了要先透過model取得資料,再將資料丟到view去顯示(請參考第18頁),所以這是CodeIgniter route的功用之一哦,它可以縮短並簡化網址。
        $this->load->view('pages/footer');
    }

2014年9月5日 星期五

UML & Use case

UML & Use case

  本文重點在於UML的基本觀念介紹以及Use Case使用案例圖的說明;UML總共有多達十三種圖形,但其中最簡易且同時適合IT與非IT背景同仁學習的以Use Case莫屬,因此每位同仁其實都可以看懂甚至於自行繪製Use Case圖形。http://upload.wikimedia.org/wikipedia/en/thumb/2/2d/UML_logo.gif/220px-UML_logo.gif
  我最近看了幾本UML相關書籍以及網路文章,並試著將當中Use Case的學習重點記錄下來,因此本文可以說是自己的Use Case學習筆記,在文章中我試著將這些重點再藉由自己的言語表達出來,希望能用一種很白話且簡單直接的方式,讓大家看過就能瞭解什麼是UML,並且能夠觀看並開始繪製基本的Use Case案例圖。

一)UML是什麼?

    UML是Unified Modeling Language的縮寫,直接翻譯成中文就是「統一模組化語言」,所以,從字面上我們大致可以猜出,UML是一種語言、用來建構模型、而且是一種統一的標準;但是這個名稱看起來還是太深奧了,它為什麼需要冠上Modeling動詞和Unified這樣的形容詞?而且程式語言一般都有著其取向與目的,像古老的COBOL是商業設計專用的語言、BASH SHELL常用在Linux系統程式、Javascript大量運用於前端(使用者端)網頁,那麼UML是用來作什麼的?它可以寫出什麼樣的程式?
  實際上,UML是一種具有特殊目的與用途的圖形化語言,它的「Language語言」是由各種形狀不一代表著不同功能的圖形組合而成,「Modeling模組化」則是指將腦海構思中的系統架構透過這些圖形表示出來,「Unified統一」指的是這些UML圖形和組合方式有著統一的標準規格,不同的開發者和使用者們都能理解並看得懂。
  所以,你知道了嗎?UML是一套描述系統架構的語言,就像大樓的建築師們有一套標準的圖形與構圖設計方法,軟體系統也有類似的作法,就是UML,它的產出是一張張不同類型及目的的圖形,可以協助軟體開發者瞭解客戶的需求、讓客戶知道軟體開發人員所架構出的系統是否符合所需、也可以讓軟體開發團隊們在溝通協調彼此所進行的系統時更為順暢,所以,我們也可以這麼說,UML是一套客戶與開發者團隊之間共用的標準語言,它的功用就是加強開發者與客戶需求以及開發團隊彼此之間的瞭解,最終目的是加快軟體開發效率

二)UML的類型

    既然你已經知道了UML的用途,那麼,你可能也會懷疑它的產出是什麼?像PHP或ASP.NET是把程式碼放在網頁伺服器上執行嗎?還是像C一樣得經過Complier,或者甚至於跟JAVA一樣需要在一個虛擬機器的環境下才能執行?
  其實都不是,正如在上段所提的,UML中的Modeling這個字,代表了它是一種將虛擬的軟體系統給模形化出來,讓你我都能瞭解這個系統的用途及目的,所以它是一種描述性語言,它最終的產出是一張張各式的圖表及流程圖,種類約有十三種,而我們可再將這些產出圖形依其特性再分為二大類,分別是Structure Diagram結構式圖形與Behavior Diagram行為式圖形。
  • Structure Diagram結構式圖形
    • Class Diagram類別圖
    • Object Diagram物件圖
    • Component Diagram元件圖
    • Deployment Diagram佈署圖
    • Package Diagram套件圖
    • Composite Structure Diagram 組合結構圖
  • Behavior Diagram行為式圖形
    • Activity Diagram活動圖
    • State Machine Diagram狀態機圖
    • Sequence Diagram循序圖
    • Communication Diagram 通訊圖
    • Use Case Diagram時用案例圖
    • Timing Diagram時序圖
    • Interaction Overview Diagram 互動概觀圖
  上述的結構圖和行為圖兩者最大的分野,在於前者描述的是系統的「靜態」的結構,例如使用元件、如何佈署等等,而後者描述的是系統內「動態」的行為,像是流程、過程、互動等。看到了UML有這麼多類型的圖表,你會不會心裏一驚後悔正準備要一探UML的領域?但其實在這些UML圖形中,經常使用的只有下面六種:
  • Structure Diagram結構式圖形
    • Class Diagram類別圖                  經常使用,可表達系統的靜態結構,但是需要   物件導向分析的能力
    • Component Diagram元件圖       
    • Deployment Diagram佈署圖        經常使用,元件圖與佈署圖多用於分析IT基礎架構、軟體架構等,但是需要具備IT相關的Knowhow
  • Behavior Diagram行為式圖形
    • Activity Diagram活動圖       
    • Sequence Diagram循序圖              經常使用,可用於表達系統的動態行為;活動圖類似流程圖的概念,因此很容易掌握製作方法,且適用於大部份的業務流程分析;其最大的優點則在於能夠清晰的表達過程中所參與的角色、角色之間的關係、以及各角色是如何參與)
    • Use Case Diagram使用案例圖        經常使用,可表現該系統的對外功能是什麼;我們透過使用案例圖可表達出是什麼角色透過系統來作什麼事情,大部份都將此圖用於說明並表達使用者/系統的絕大部份需求。
而在這經常使用的四種圖形當中,使用案例圖類別圖循序圖這三者的重要性排名前三大。因此我們只要學習並透過這三種圖形,便可以很快的呈現資訊系統的對外功能、靜態結構和動態行為。

三)需求分析

    介紹完了UML的基本概念,那我們可以直接開始學習如何製作UML圖形了嗎?先別急,你知道為什麼需要畫這個UML圖嗎?是不是要規劃並製作一套系統?那麼又為什麼要製作這套統,應該不是沒事找事作,而是來自使用者的需求吧?而既然這是一套使用者需要的系統,那麼,我們就必須提醒自己,釐清使用者並且確切滿足使用者的需要對於手上這件正要開發的系統是一件事非常重要的事,我們千萬不可以一開始就肓目的埋頭苦幹,否則最終下場肯定是如同下方的圖形一樣:不符使用者真正需求且糾紛不斷。http://files.dotblogs.com.tw/jimmyyu/0909/RA_1375B/image_thumb.png

重點1:瞭解使用者的需求是持續進化的

  事實上,需求分析可能是整個系統開發過程中最困難的一個階段,它遠比我們正要學習的UML更具挑戰與不確定性,主要原因是:
  1. 需求分析必須從事大量的溝通工作
  2. 用戶對系統的需求經常敘述不清
  3. 缺乏自動化工具支援
  4. 使用者需求經常隨時間或想法而改變
  由於上述這些因素,導致使用者需求經常在變動,使得開發者也因無可遵循而導致最終產品不符使用者真正的需求;但其實我們只要把握一個原則,就是認知到雖然使用者的想法總是在變化,但整體而言這種需求變化是呈現螺旋前進的,這樣的需求變化是一種持續進化的現象,因此我們不應對此有任何的抱怨。
  此外,系統開發期間的使用者需求變更其實並不是壞事,說明了使用者對於自己的需求有了更進一步的瞭解,而開發人員若對此需求變動會感到不適應,反而代表了他們對於需求瞭解的進步程度不如使用者。

重點2:系統持續產生問題其實是一種良性的現象

      假設某系統已經上線了,出現以下三種情況,你會更喜歡那一種情況呢?
  1. 使用者一直沒有提出過任何問題。
  2. 使用者開始提了一些問題,但很快就沒有其它問題了。
  3. 客戶一直在提問題,開發人員解決了這些問題後,新的問題又來了,如此不斷重複。
  我們先看看A現象,這代表使用者幾乎或很少在使用這套系統,所以沒有提出什麼問題。
  再來是B現象,有兩種可能,第一種是使用者在試用一段時間後,由於某些原因而不再使用該系統了;第二種可能,是使用者曾經提出過很多問題,但開發人員無法順利的解決這些問題,因此最終使用者乾脆不再使用了。
  而最後的C現象可能是很多開發人員與使用者經常碰到也最討厭的現象,因為每天都會發現新的小問題或者被這些小問題所糾纏,但其實這是相當理想的良性狀況,代表了使用者持續的在使用該系統,因此問題一開始會比較多,而開發人員一開始的問題解決速度也低於問題的產生速度,但持續到後來,問題會逐漸減少直到完全消失。

重點3: UML可協助進行使用者需求分析

  開發人員經常只看到使用者所開出的「需求規格」,並且往往僅侷限在這個層面進行各項的系統開發工作,但事實上,所謂的「需求規格」代表的是使用者一種很表面的需求要項,它其實並不是使用者的「需要」,使用者的需要是必須透過挖掘與分析而得到的,真正的需求分析是能夠「透視」這些表面的「需求規格」而挖掘出使用者的需要,而UML這個工具就可以協助進行「透視」的工作
    那麼UML如何協助進行「透視」的工作呢?原因就在於它可以:
  1. 弄清楚系統的目標和範圍
  2. 找出系統的所有關鍵人物,並列出所有解決的問題
  3. 分析業務,確認問題,發掘真正的問題
  4. 針對問題,提出系統的特性
  5. 針對特性,提出系統的用例,並細化功能需求和非功能需求
  而UML的兩大類圖形:結構圖行為圖就是協助上述的問題而產生的,透過這些圖形可讓開發人員更進一步的瞭解使用者業務以及業務流程,以及瞭解並挖掘使用者的需求。

重點4: 利用UML來協助使用者發掘需求

  下圖是一種很常見的狀況,它表示了一個正在開發中的系統,隨著時間發展,使用者和開發人員對於需求瞭解程度的上升趨勢;在時間=0時,使用者對於需求是有一定認知的,所以會有該系統的需求產生,所以並不是從零開始,而開發人員對該系統的需求瞭解一開始就不如使用者。
  隨著時間的發展,雙方對於需求的瞭解愈來愈強,但開發人員對需求的認識總是落後於使用者,這樣的現象造成整體系統的開發工作陷於被使用者牽著走的被動局面,且雙方很容易產生相互責怪的現象(使用者責怪開發人員水準太差,開發人員責怪使用者的需求變來變去)。   
  要打破這現象,開發人員必須能夠做到如下圖的效果:比使用者更瞭解系統的需求,並引領他們挖掘真正的需求,如此,才能開發出真正符合使用者所需的系統。
  

四)Usecase diagram使用案例圖的目的

    一般初接觸UML的系統開發人員對於使用案例圖並不習慣,甚至於沒有好感或嗤之以鼻,因為那看起來只是幾個幾何圖形配上個小人,外加少許的文字與箭頭這麼簡單的流程圖形,和系統開發者素來以功能面為出發點的系統流程圖差異甚大,使得很多人懷疑這樣的案例圖真的能改善工作嗎?使用它的真正目的到底是什麼?
對於系統開發者來說,「使用案例圖」最主要的功用是轉變思考的角度!
  舉個例子來說,如果我們打算做個考勤系統,傳統上我們會先怎麼思考呢?我們是不是先想到要用什麼語言開發?可以使用什麼Database?需要提供那些功能?可能會使用到那些子系統?每項功能的流程和其它系統的關聯?... 你有沒有發覺我們都是從功能面為出發點來構思整個系統?
  但是比較好的方式,應該是從人的角度來思考,什麼人會使用這個系統?然後逐一思考不同的人對系統有什麼需求。所以,首先我們可以估計到一般員工、主層主管、總機、財務等都會用這個系統:
      • 對於一般員工來說,除了打卡之外,他還關心什麼?
      • 高層主管使用這個系統的目的是不是想檢視大家的出勤狀況?
      • 對於總機來說,她是不是需要做一些考勤的統計?
      • 財務人員是不是要根據考勤情況來調整員工薪金?
有沒有發覺,透過這樣的思考方式,會讓我們更容易全面發掘系統的需求?
  在「使用案例圖」中,人就是角色,當我們思考某系統的需求時,「使用案例圖」就給予我們啟示,告訴我們可從不同角色的角度來思考,因此,其實「使用案例圖」的最終目的是:
    A)讓雙方有共通的語言:「使用案例圖」的特點主要在於:
  1. 清晰扼要的描述系統行為。
  2. 不涉及專業術語或技術議題。
  3. 讓使用者與開發者雙方都能看得懂並確認需求目的
B)「使用案例圖」可以回答:
  1. 這個系統有誰在用?
  2. 這些人透過系統能夠做什麼事?

五)開始使用「使用案例圖」

    在對於UML有了基本的認識,並瞭解了「使用案例圖」的功能與目的後,下面我們可以開始來學習如何繪製「使用案例圖」了。

    A)繪製原則

邱郁惠小姐是目前產業界相當知名的UML實務專家,她寫過相當多的UML相關書籍,也開過很多的訓練課程,在「SA前進UML專案現場」一書中,她提到IKEA創辦人Ingvar Kamprad常把「簡單是一種美德」這句話掛在嘴邊,Ingvar Kamprad經常訓誡大家,只有平庸的人,才會提出複雜的解決方案。
同樣的,邱小姐受其影響在UML的傳授上也是提倡極簡的風格,她認為保持簡單使用UML是一項值得讚許的美德,只有平庸的團隊,才會把UML用得既複雜又困難,因此要求開發團隊成員應使用最少量的UML概念和圖示才能減少習習與溝通成本,以加快開發的步調。
我本人也頗為讚同這種精簡的理念(當然囉,能夠少學一點何樂而不為呢?)因此,雖然UML的每種圖形都包含有數十種的圖示,在下面我將僅介紹四種圖示,實際上只要使用這四種圖示,便可應付所有的場合了。

    B)使用案例圖示介紹

1. Actor
  此圖為大字上面君個圓圈,就像一個人形狀,英文名稱Actor,中文直接翻譯的話是演員、行動者的意思,一般在國內的UML書籍則解釋為「執行者」或「參與者」
  當我們針對某系統的使用者進行分類後,可以整理出該系統擁有哪幾種角色,不同的角色有不同的工作責任,所以他們需要使用的系統功能也會不一樣;利用角色的觀點,給予了我們一個啟示,當我們思考某系統的需求時,可以從不同角色的角度來思考。
  在繪製時,我們需要注意,角色這個圖形可以代表多個實際的人,而且同一個人也可以扮演多個不同的角色,因此實際應用時,我們通常會將某些職位或部門抽象為角色,但有的時候,這個角色也可能不是由人或職務扮演,而是另外一個系統,因為該系統會去與另一個系統互動,所以這種情況下,我們可將另一個系統畫為執行者。
2. Use Case
  Use Case字面翻譯是「使用案例」,它代表的是系統的各項功能,也就是這個系統能夠作什麼事情。
  請注意,在UML使用案例圖中的所謂Use Case,一定要能表達出"動詞+名詞"這樣的結構,例如,"觀看影片"、"查看自己的考勤記錄"、"登入系統"...等等,這樣一個動詞結合名詞的語句才能算是一個完整的Use Case情況,之後我們才可以將此Use Case連到某個會與其產生互動的角色上。
  要檢視使用案例圖畫得是否合適,我們可以按此順序來讀這個圖:先讀出執行者的名字,然後讀出使用案例中的文字;按照這樣的讀法,我們可以得到兩個完整的句子:
  1. 一般員工觀看創新TV節目
  2. 一般員工推薦創新TV節目
如此才是一個完整的使用案例;另外要注意的是,一個使用案例不一定只能連到一個執行者,它也可以同時連到多個不同的執行者,這代表某個功能是被多個使用者所使用。
3. Association
 我們使用線條將角色與使用案例連接起來,代表某某執行者能夠執行什麼使用案例,因此該直線代表的是兩者之間的關聯。
    一般我們會使用三種直線:無箭頭的、指向用案例的、指向執行者這三種,而當中的箭頭代表的意義可以是下列其中一種:
  1. "資料流向":指執行者與使用案例的互動過程中資料的流向,如果箭頭指向使用案例,就說明使用者需向系統輸入資料,如果箭頭指向執行者,則說明系統輸出資料給執行者,而沒有箭頭的線條,代表沒有明確的資料流向。
例:系統B輸出資料給系統B
  1. "誰啟動誰":當箭頭由執行者指向使用案例,則表示由使用者啟動系統,這是大部份的情況;有極少的情況是由使用案例指向執行者,代表的意思是指系統導出資料到系統B(系統B為執行者)。
例:系統A啟動"從系統A導入資料"的使用案例
由於箭頭本身及方向代表了不同的意義,若沒有加上額外說明或其它文件(例如:使用案例表)的輔助,可能會增加雙方認知的麻煩,因此,有部份的UML專家建議並不一定要非要畫出箭頭,因為使用案例中已經有定義出"動詞"了,只要繪出的案例圖能夠讓人瞭解,有沒有箭頭並不是那麼重要。
4. Include & extend
  與上述的使用於執行者和使用案例之間的"Association"不同,Include(包含)與Extend(延伸)代表的是使用案例之間的關係。
4.1 Include
  從上圖我們可以看到,"管理預設節目"這個使用案例包含了四個子使用案例,分別是"增加",修改"刪除","瀏覽","刪除"(此四種功能在MIS有一個術語稱為CRUD:Create/Read/Update/Delete)。
  我們把這四個案例抽離出來成為Include的子案例,好處在於它可以同時被其它的案例所使用,例如"增加","瀏覽","刪除"這三個功能可被一般員工的"點播"功能使用,所以此三個案例亦成為"點播"的子案例,我們可以畫成如下的圖表:
4.2 Extend
  Extend有延伸、擴充之意,我們可以把它看成在某使用案例的基礎上,還能做什麼事情;箭頭的方向表示誰擴充了誰。我們先看看下方的圖表:
  上圖表示一般員工可以在觀看創新TV節目的時候進行"推薦"或"轉寄"該節目的功能,換句話說,也就是一般員工在觀看創新TV節目的基礎上可以選擇"推薦"和"轉寄"。
4.3 Include & Extend
  另外我們必須注意到的一個重點是,Extend和Include除了箭頭方向相反之外,它們之間有一個很大的差異是:對於Include來說,若缺少了任一個子使用案例會不完整,亦即對母案例來說,所有的include子案例都是必要的、缺一不可的,以上述Include說明中的例子"管理預設節目"來說,"增加",修改"刪除","瀏覽","刪除"這四個功能是管理節目表的必要項目,缺一不可,少了任何一個都無法達到"管理預設節目"的目的。
  但是對於使用Extend的母案例來說,子案例並不是必要而是選擇性的,也就是說,若沒有了"推薦"或"轉寄"功能,一般員工還是能夠執行觀看創新TV,但有了的話可能會更好甚至可以增加使用者體驗。

4.4 Extend & UX
  Include和Extend其實不難理解,相信你讀過便能馬上領會,此外,你有沒有發現到,其實Extend的設計與良好的使用者體驗有著密切的關係哦!
  如果我們把上面的"觀看創新TV"的例子改成如下,那麼使用者體驗會變成如何?變成員工看到一部不錯的節目,他必須另外回到主畫面上,點選推薦或轉寄的按鈕,再從一串節目單中選擇剛剛想要推薦的那個節目,這樣使用者體驗是不是很差?因此一個好的案例關係設計,通常能給使用者帶來更好的使用者體驗

六)最後

    除了上述的這四種圖,其實還有其它的圖例像是繼承(Inheritance)與系統邊界(System Boundary)等我並沒有介紹,首先,並不是所有的案例圖都需要畫出系統邊界,如果在每個使用案例圖的案例中都畫出系統邊界將會顯得很累贅,我們只要在最外層的使用案例圖畫出系統邊界就可以了。另外在繼承圖例的使用上,"繼承"這個概念對於非IT背景的同仁來說經常比較難以理解,尤其它很容易與Include及Extend造成混淆,因為那個被繼承的父使用案例,往往是一個抽象、無法被實際執行的使用案例,它必須被繼承後才能夠由使用者來執行,對於沒有軟體開發經驗和物件導向設計經驗的同仁和使用者來說,要去理解這種"抽象類別"會有些困難。
    在本文中,我大致介紹了UML及UML圖形Use Case(使用案例圖)的繪製,並以創新TV為範例示範怎麼使用其中最常用的四種圖例,相信您只要利用這四個圖例便可看懂UML並應付部份的系統開發需求了。你要試看看瞭解多少了嗎?下圖是我在網路上找到的一個網路訂書的Use Case,僅用到本文所介紹的四種基本圖例,請試看看是否能夠領略。