2012年1月18日

壹週刊::身之外[袁瓊瓊]


(摘自壹周刊第555期2012.01.12)

我自己是一向對於人或世界有無數困惑,活到了現在,還是向問一大堆未甚麼。之所以成為寫作人,大有可能是在給自己解釋,透過說給自己聽,還世界以某種秩序。

...寫作不是「行為」,而是生命的印刻。...之所以要寫作,是為了透過書寫來品嘗讚嘆享受和回味生命。當初倉頡造字,據說是「天雨粟,鬼夜哭。」文字可能是人類唯一絕對原創之物,繪畫或雕塑,基本上都有個食物任其模仿。只有文字,橫空出世,既無所出,亦無所由。而被憑空創造出來的某個字,與物體和意念連結,就像把那些東西給凝固住了,成為比現實存在更為堅固之物,既抓住了具象又抓住了抽象,讓人類開始思想。是的,我認為人類是有了文字之後才會思想,字彙不夠的話,要如何描繪思想架構理論呢?或許連敘事都很貧乏吧。

層層疊疊的記憶像放在置物箱裡的舊文件,新的疊上舊的,一層一層,似乎是秩序和分明的,然而不堪攪動,一攪動變破碎了。

我的記憶不是迷宮,沒有任何秘密性可言,是紐約的棋盤大街,每一條路都能夠通往其他的路,每個轉角都很像,因此沒有地標。

這所以我從來不相信記憶,我對記憶唯一的信念便是「它不準」。有些資料性的事情,當然沒話說,有證件有文件有紀錄,但是寄託於那些資料的事實,至少,在我的人生中,不準確的可能性是很大的。它們混雜在一塊。事實上,是混雜使得這些記憶產生意義。在我們人生地圖上散落的那許多事件,獨立來看是乾枯的,沒有意義。要與人生裡其他事件相連,那或者發生在之前,或者發生在之後,或者發生在別人身上...拼圖湊齊之後,我們才能明白生命為我們呈現的畫面。

屋外頭在下雨。我老是覺得下雨聲像某個巨大獸在用舌頭一點一點舔食地面時,接觸又剝離的聲音。這印象或感受從來沒有過。或許當真有個隱形的獸在做這個舔食動作。在下雨的時候。

5.4-模擬CIM-3:定義系統範圍


寫給SA的UML/MDA實務手冊
----------
第5章-定義系統範圍


5.4-模擬CIM-3:定義系統範圍


根據首購流程的活動圖,系統分析師已經先繪製出如圖5-11和圖5-12的系統UC圖。



圖5-11:  理專套件下的系統UC圖



圖5-12:  主管套件下的系統UC圖


接下來,系統分析師想跟企業人員確認首購流程中的其他部分,模擬對話如下:


系統分析師問:在首購流程的現行作業中,投資人需要填寫紙本的風險容忍度測試表,系統需要保存這些紙本資料嗎?


企業人員答:關於這個部份,公司未來想取消紙本的測試表,改讓投資人直接看著電腦銀幕勾選測試表。


系統分析師說:好的。


系統分析師打開投資人套件下的系統UC圖,新增了一個名為「填寫風險容忍度測試表」系統UC,如圖5-13所示。



圖5-13:  投資人套件下的系統UC圖


系統分析師問:在首購流程中,理專會怎麼確認投資人是否已經在本行開設過綜存帳戶?


企業人員答:理專會要求投資人提供綜存帳戶的存摺,然後透過公司的綜存系統查詢帳戶情況。


系統分析師問:所以,在公司現行的綜存系統中,已經提供「查詢綜存帳戶」的功能了。


企業人員答:是的。不過,目前的作業其實很麻煩,理專必須登入綜存系統,才能查看到綜存帳戶的資料。可是,理專其實不需要完整的綜存資料,因為不是要做提存款的交易嘛!理專只是想看到投資人提供的綜存帳戶目前的使用狀態是否正常,餘額是否夠支付申購款。


系統分析師說:或許,我們可以讓基金系統提供一項「查詢綜存帳戶使用狀態」的服務供理專使用?
企業人員答:這樣最好了。


系統分析師打開理專套件下的系統UC圖,新增了一個名為「查詢綜存帳戶使用狀態」系統UC,並列出綜存系統做為支援者,如圖5-14所示。



圖5-14:  查詢綜存帳戶使用狀態


系統分析師問:在首購流程中,理專如果確認投資人未曾於本行開設過綜存帳戶的話,理專會使用基金系統來幫投資人開設綜存帳戶嗎?


企業人員答:不會,開設綜存帳戶是其他行員的工作,理專沒有這樣的權限。所以,通常理專會請行員過來,協助投資人開設綜存帳戶。


系統分析師問:針對這個部份,有需要基金系統提供什麼樣的服務嗎?
企業人員答:應該沒有了。



圖5-15:  分析首購流程所定義出的系統UC


針對首購流程的活動圖,系統分析師最後獲得如上圖5-15的系統UC,且於經過企業人員確認之後,開始分析一般流程的活動圖。根據一般流程的活動圖,系統分析師已經先繪製出如圖5-16和圖5-17的系統UC圖了。



圖5-16:  投資人套件下的系統UC圖



圖5-17:  理專套件下的系統UC圖


接下來,系統分析師想跟企業人員確認一般流程中的其他部分,模擬對話如下:


系統分析師問:在一般流程的現行作業中,客服每月會寄發投資對帳單給投資人。關於這個部份,可以跟我解釋的更清楚些,看看系統可以提供什麼樣的服務?


企業人員答:目前公司列印並郵寄紙本的投資對帳單給投資人。以後,理專針對來申辦網路下單功能的投資人,將詢問投資人接受電郵投資對帳單的意願。所以,電郵和郵寄的需求並存。


系統分析師問:對於列印及郵寄紙本投資對帳單這部份,目前的現行作業是怎麼做的?


企業人員答:公司有一套帳務系統會定時印出投資對帳單,客服會拿去郵寄。


系統分析師問:針對這個部分,有需要系統提供什麼資料或服務給帳務系統嗎?


企業人員答:目前沒有這個打算,基金系統只要處理電郵投資對帳單就可以了。


系統分析師答:好的。


系統分析師打開定時啟動者套件下的系統UC圖,新增了一個名為「電郵投資對帳單」系統UC。而且針對一般流程的活動圖,系統分析師最後獲得如圖5-18的系統UC,在跟企業人員確認之後,開始分析定期定額流程的活動圖。



圖5-18:  分析一般流程所定義出的系統UC


根據定期定額流程的活動圖,系統分析師已經先繪製出如圖5-19的系統UC圖了。



圖5-19:  定時啟動者套件下的系統UC圖


接下來,系統分析師想跟企業人員確認定期定額流程中的其他部分,模擬對話如下:
系統分析師問:在定期定額流程的現行作業中,公司會發送交易簡訊給投資人。關於這個部份,有需要電郵交易通知嗎?


企業人員答:系統上線之後就改發送電郵,不再傳送簡訊了。


系統分析師說:好的。


系統分析師打開定時啟動者套件下的系統UC圖,新增了一個名為「電郵交易通知」系統UC。而且針對定期定額流程的活動圖,系統分析師最後獲得如圖5-20的系統UC,並與企業人員確認之。



圖5-20:  分析定期定額流程所定義出的系統UC


分析完所有的活動圖之後,系統分析師彙總每一個啟動者套件下的系統UC,一方面與企業人員再度確認並撰寫系統UC簡述,另一方面查看可有遺漏。活動圖並未能確保找到所有系統UC,可能會有遺漏。


CIM-3的最終產出,如下所列:


1.投資人啟動的系統UC,如圖5-21所示。
2.理專啟動的系統UC,如圖5-22所示。
3.主管啟動的系統UC,如圖5-23所示。
4.定時自動啟動的系統UC,如圖5-24所示。



圖5-21:  投資人可啟動的系統UC











圖5-22:  理專可啟動的系統UC







圖5-23:  主管可啟動的系統UC







圖5-24:  定時自動啟動的系統UC








隨後,待專案經理及其他相關的決策人士從CIM-3中挑選出一批系統UC,做為首期釋放(Release)的系統UC。此外,系統分析師也將帶著這批中選的系統UC進入PIM-1,開始詳述每一個系統UC的細部規格。

2012年1月6日

5.3-備妥StarUML


寫給SA的UML/MDA實務手冊
----------
第5章-定義系統範圍


5.3-備妥StarUML


為了管理大量的系統UC,我們依啟動者設置多個「套件」(Package),並將該啟動者負責啟動的系統UC歸於同名套件中。系統分析師可以先會依據下列操作步驟,分別設置與投資人、理專、主管、定時啟動者同名的四個套件:


1. 在「CIM-3:分析系統流程」底下,新增四個套件(Add Package),並更名為「投資人」、「理專」、「主管」、「定時啟動者」,如圖5-8所示。



圖5-8:  新增套件


2. 新增了套件之後,在每個套件底下新增系統UC圖(Add Use Case Diagram),如圖5-9所示。



圖5-9:  新增UC圖


3. 隨後,可點選圖面上方的頁籤切換系統UC圖,如圖5-10所示。



圖5-10:  切換UC圖面

2012年1月5日

壹周刊::惡意[袁瓊瓊]

(摘自壹周刊第553期2011.12.29)


世間那些用「我說話很直」開頭的話,多半都是會讓人內傷的。而因為似乎不嚴重,因為似乎並沒有實質傷害,許多人聽了通常選擇把自己的不適感藏起來,說服自己那不算什麼,談不上惡意。


而當惡意不再被辨識之後,便會化成其他面貌,化身成善意,成玩笑,成某種奇妙的天經地義,甚至成了正義。



2012年1月4日

5.2-備妥CIM-2:活動圖


寫給SA的UML/MDA實務手冊
----------
第5章-定義系統範圍

5.2-備妥CIM-2:活動圖



在進入CIM-3時,系統分析師必須先備妥CIM-2產出的所有活動圖,做為訪談的基礎資料。請看圖5-6的企業UC圖,針對CIM-1中的「申購基金」企業UC,系統分析師將其流程分為三種情況,所以一共繪製了三張活動圖,分別為:上圖5-1的首購流程、上圖5-4的定期定額流程、圖5-7的一般流程。在本章的模擬對話中,我們僅就這三張活動圖分析定義出系統UC圖,以及撰寫相關的系統UC簡述。



圖5-6:  銀行UC圖


(請參照前圖5-1)
圖5-1  首購流程的活動圖


(請參照前圖5-4)
圖5-4  定期定額流程的活動圖



圖5-7:  一般流程的活動圖

2012年1月2日

5.1- CIM-3:定義系統範圍

寫給SA的UML/MDA實務手冊
----------
第5章-定義系統範圍

5.1- CIM-3:定義系統範圍

經過了CIM-1的定義企業流程,以及CIM-2的分析企業流程之後,終於進入到CIM-3這場壓軸戲了。CIM-1和CIM-2的產出文件,跟CIM-3的產出文件之間,有如下的關聯性:


1.CIM-2活動圖中的每一個行動,都可能成為CIM-3的系統UC。
2.CIM-1中的企業參與者,以及CIM-2中的行動負責人,都可能成為CIM-3的系統參與者(System Actor)。


在CIM-3中,系統分析師將分析CIM-2產出的所有活動圖,定義出一堆的系統UC。隨後,待專案經理及相關人士從中挑選出一批系統UC,做為首期釋放(Release)的系統UC。此外,系統分析師也將帶著這批中選的系統UC進入PIM-1,開始詳述每一個系統UC的細部規格。


在CIM-3的訪談中,系統分析師主要將產出下列UML文件:


1. 系統UC圖
2. 系統UC簡述


系統分析師在CIM-3產出系統UC簡述,其作用如同CIM-1的企業UC簡述,用來做為分辨系統UC之用。直到進入到PIM-1,系統分析師才會對每一個系統UC撰寫詳細的敘述,記錄細部的規格說明。


系統分析師在定義系統UC時,可以參考下列建議:


1. 每一個系統UC最好只有一個啟動者。


2. 系統UC執行期間如果有連線其他系統,將它們列為支援者。


3. 遇到定時啟動的系統UC,可以定義一個名為「定時啟動者(Timer)」的虛擬啟動者。



圖5-1:  首購流程的活動圖


啟動UC的參與者,特稱為「啟動者」(Initiator),其餘不具有啟動特質的參與者,可稱之為「支援者」(Support)。直接操作電腦的使用者,通常就是系統UC的啟動者。而且在系統UC執行期間,有時會需要連線其他系統以取得協助,這些連線系統就是支援者。


系統分析師可以先從「CIM-1的企業參與者」和「CIM-2的行動負責人」,這兩處先找尋啟動者。在基金模擬個案中,投資人在首次申購基金時,必需填寫風險容忍測試表,如上圖5-1所示。


請看圖5-2的系統UC圖,說明如下:


1.在現行流程中,投資人填寫紙本的風險容忍測試表,但是未來系統上線之後,銀行將不再提供紙本,而是要求投資人直接使用電腦勾選。在這樣的情況下,投資人原先僅扮演企業參與者,而現在因為有直接操作系統,所以投資人同時也扮演了啟動者的角色。


2.至於,理專和主管原先是申辦及審核基金帳戶的負責人,不過未來系統上線之後,這兩項工作都會自動化,他們將直接使用系統來執行這兩項作業。所以,理專和主管是CIM-2的行動負責人,此時也將扮演系統的啟動者。


3.此外,投資人首次申購基金時,理專會先詢問投資人是否擁有本行的綜存帳戶,如果投資人不確定時,理專可以透過基金系統查詢確認。不過,基金系統裡頭其實並沒有綜存帳戶的資料,必需連線到綜存系統才能查詢相關資料。雖然,綜存系統不具有啟動「查詢綜存帳戶使用狀態」系統UC的特質,可是它提供連線支援,所以綜存系統是很重要的支援者。



圖5-2:  啟動者與支援者


系統分析師在繪製系統UC圖時,可以採用下列幾項常見做法:


1.採用帶箭頭關係線,讓啟動者連線指向UC,UC連線指向支援者。這樣一來,從圖面上就可以明確分辨出啟動者與支援者。


2.一個UC通常只有一個啟動者,不過可能出現多個支援者。


3.如果有多個啟動者的情況,嘗試切割成一人一例(One User, One Session)。


4.有時不同使用者都具有啟動UC的特性,建議在圖面上繪出最重要或最主要的啟動者,其餘啟動者記錄在UC敘述裡,這樣可以降低圖面的複雜度。


在基金模擬個案中,投資人如果不會使用系統,理專可以代為操作填寫風險容忍測試表。換言之,投資人或理專兩者都可以啟動「填寫風險容忍測試表」系統UC,遇到這樣的情況,建議維持圖5-2的表示法,僅列出投資人作為啟動者,可於UC敘述中才記錄理專,降低圖面的複雜度。如果一定要同時列出兩位啟動者,記得使用虛線連接兩關係線並且標示{or},提醒兩位啟動者二擇一即可,如圖5-3所示。



圖5-3:  兩位啟動者二擇一


有些系統UC不需要由特定的使用者來啟動,而是定時啟動,遇到這樣的情況,可以定義一個虛擬的啟動者,標示出UC將定時啟動的特性。在基金模擬個案中,投資人約定定期定額申購基金之後,每月約定日到時,理專就會手動申購一筆定期交易,如圖5-4所示。



圖5-4:  定期定額流程的活動圖


日後待系統上線之後,理專便不需要再手動處理申購交易了,而是由系統定時自動啟動「扣款申購當期基金」系統UC,並於交易完畢之後自動啟動「電郵交易通知」系統UC電郵相關人士,如圖5-5所示。



圖5-5:  定時啟動者