系統規劃與分析

跨網站單一登入(Single Sign On)的作法概念

topcat — Thu, 03 Apr 2008 08:13:00 GMT

當我們開發了許多的Web應用系統後，如果使用者同時擁有多個Web應用程式的使用權限，而每個Web應用程式都有自己的登入帳號密碼，那麼對於使用者來說，有點麻煩，尤其是剛好設定的密碼又不同。

為了方便使用者的使用，因此會有【單一登入】的需求出現，只要登入一個應用程式後，要跳到別的Web應用程式，不需要再次輸入帳號密碼，可以直接就進行登入。但是為了考量安全性，還是要考量一下怎麼設計才能夠兼顧安全與便利。

小喵的方式是透過SQL來當作媒介，假設小喵要從WebA跳到WebB。
首先要準備一個兩個應用程式都能夠存取的資料庫。然後設計一個資料表來處理。這個資料表有以下幾個欄位

GUID:由NewId()產生出來類似【504B1790-E93A-4445-B262-E73A113BF336】這樣格式的資料
UserId:WebB的帳號，當然WebA與WebB可以用相通的帳號，或者是透過員工代號取得WebB的帳號
TimeOut:過期時間，產生該筆資料的時間+2分種。也就是從WebA到WebB的過程，小喵估計不會超過2分鐘，時間過期後該筆資料就沒用了。

接著就是運作的方式

步驟如下

WebA點選轉入WebB
寫入1筆過程資料，例如：5ED095B8-350D-42C3-953B-9C53DED54AFD,topcat,20080402165823
WebA Submit GUID給 WebB
WebB承接到GUID取回資料，並判斷現在時間沒有大於20080402165823
如果4.找不到，顯示錯誤並拒絕登入
如果4找到，進行登入程序
刪除該GUID資料

這過程中的時間，過期時間拉得越長越不安全。太短又容易失敗，所以大家自己斟酌。

由於GUID發生碰撞的機會很低，並且在加上過期時間的保護，小喵覺得應該還算安全，大家覺得怎麼樣再請大家給小喵一些建議

^_^

文字型態的資料要用什麼樣的格式儲存?char, varchar, nchar, nvarchar??

topcat — Thu, 06 Sep 2007 08:39:00 GMT

使用資料庫儲存文字的資料，在資料庫中會有以下這些的型態可以設定
char, varchar, nchar, nvarchar
那麼到底要用哪種型態比較適合，這些型態之間有何差異呢??

意義與差異

從這些字眼上來看，都是有char，差別在var與n這兩個字眼，那麼就先來簡單介紹一下這兩個字眼代表的意義：

var：不定長度→有多長存多長

n：Unicode→無論英文、數字、中文、日文、...每個字都占2Byte。

說明一下：

char與nchar宣告的是固定的長度，因此如果宣告char(5)，但是只放a這個字，那麼就會補另外4個空白，會補空白補滿是他的特性，而nchar(5)也是會放滿5個字，但是每個字無論中英數都會用2個Bytes來存放

varchar與nvarchar都是不定長度，因此如果宣告varchar(5)，但是只放a這個字，那麼就會放一個a，不會補空白。而如果宣告nvarhcar(5)那還是只放a這個字，但是會用2Bytes來存放。如果放了【中】這個中文字，在varchar會占用2個位子，但是nvarchar指占用1個位子。

舉個例子來看

假設有四個欄位，分別放入【a1中】這樣的字串，比較一下這些的差異如下：

資料類型	內容	占位數	Byte數
char(10)	a1中+6個空白	10	10
varchar(10)	a1中	4	1+1+2=4
nchar(10)	a1中+7個空白	10	20
nvarchar(10)	a1中	3	2*3=6

再來一個比較char(10)與nchar(10)

	1	2	3	4	5	6	7	8	9	10
char(10)	a	1	中
				2位

	1		2		3		4		5		6	7	8	9	10
nchar(10)	a		1		中

因此在規畫上，只要存放的資料有可能有中文，小喵就會加n。而除非確定資料固定會是幾位不變，不然資料長度不特定就會宣告加上var。

N-Tiers開發方式(為何使用COM+元件的撰寫商業邏輯層)

topcat — Wed, 09 Aug 2006 16:00:00 GMT

在上一篇N-Tier方式開發(系統分析) 提到了商業邏輯層的開發，為何會選用COM+來處理，主要有兩個原因：

確保交易的完整性：可交由COM+支援Transaction的機制處理
Web App切換身分執行元件

一、確保交易的完整性：

在確保交易的完整性，可以透過COM+對於Transaction的支援，讓拆解各功能的時候，不必特意的去考量Transation異動的部份，可交由COM+來處理

當一個商業邏輯中有了資料的維護，在邏輯的過程中可能會維護了超過兩個以上的資料表在不同的功能上。

舉個例子來說，例如：產生交易資料、扣除在庫資料，如果將這兩個動作處理在兩個元件上，我們分別稱作【COMA(產生交易資料)】與【COMB(扣除在庫資料)】，將此兩個動作分別放在不同的元件上，可以讓其他的功能來呼叫，而兩個動作，又必須完整的完成了，才能夠算是一個成功的交易過程，如果COMA或者COMB的程式運作過程中，有了什麼狀況(例如無在庫資料，無法扣除時)，那麼在這過程中維護的資料必須還原→此時這樣的還原動作可交給COM+自動完成

假設COMA中需要維護4個資料表，而COMB需要維護3個資料表，程式流程是

COMA COMB TBLA1--TBLA2--TBLA3-----→TBLB1--TBLB2--TBLB3┐ TBLB4←------------------------┘

在COMA執行的過程中，維護了3個資料表(A1、A2、A3)時，呼叫COMB又維護了兩個(B1、B2)
此時要維護B3時出了問題，那嚜剛剛維護的(A1、A2、A3、B1、B2)資料通通要還原

只需將COMA與COMB包在一個交易中，那麼當過程中有其中一個失敗了，就會還原回去

如果又有另外一個元件COMC也會呼叫COMB的相同Function，那麼也只需將COMC與COMB包成一個交易，那麼就能夠當有問題的時候也自動還原回去

二、Web App切換身分執行元件

在Web App運作的過程中，透過IIS來使用應用程式，主要是透過【IUSER】這樣的使用者來運作，而IUSER這樣的使用者基本上在權限上是限制很多的，因此如果要存取非IIS的資料夾、存取資料庫，都不適合將權限開放給IUSER來使用，以免網路上的駭客透過IUSER竄進來做一些壞事。

然而系統又有時候必須讓Web的使用者在Server上執行一些特別的功能(例如資料庫的存取)，此時就可以透過COM+的Package來設定特別的識別帳號，然後開放這樣的帳號相關資料表的權限。這樣就能夠更靈活的設計我們的程式

三、介面與商業邏輯分離→資料庫轉換介面層可沿用

當介面與商業邏輯分離時，在ASP.NET中所設計的與資料庫之間的溝通是透過商業邏輯的元件，只需要元件的名稱不變、呼叫的函數不變、傳遞的參數不變，那麼假使要轉換不同的資料庫(例如Access轉成SQL)，介面層的相關程式都不需要修改，只需要修改商業邏輯的元件即可。

更進一步的，如果商業邏輯層中，把商業邏輯運算與資料庫存取也分開了，那麼要轉換資料庫的時候，也只需要把資料庫存取的相關元件修改後，就能夠快速的切換過去，不需要修改商業邏輯的運算部分。這讓整體系統在未來的擴充、轉換上有更大的彈性。

因為有這樣的特性，所以小喵才會以COM+元件來當作商業邏輯的開發。

N-Tier開發方式(系統分析)

topcat — Wed, 09 Aug 2006 15:25:00 GMT

當小喵在開發一個較為大型的系統時，會做以下的分析過程

系統需求分析：
1. 與使用者詳談，訪問使用者須要的是什麼
2. 條列需求：將訪談後的需求加以整理，並加以條列
3. 需求確認：將整理條列出的需求，給使用者逐條加以確認，如有不足，追加並確認之
功能分析：
1. 條列功能：將使用者以確認之條列需求，轉換為系統功能並條列之
2. 功能、需求確認：將條列之功能與條列之需求逐一比對，確認使用者需求都有滿足
3. 功能整併：將條列之功能，有類似、相關之功能，加以整併→合併撰寫
4. 功能歸類：將條列之功能，加以分類整理
5. 需求、功能再確認：將整併、歸類之功能，與需求再次確認，務必滿足每一個需求。
資料分析：
1. 依據各需求所需的資料欄位、型態、加以條列
2. 正規化資料：依據正規劃原則，將條列的欄位、型態、加以分類並正規劃
3. 資料庫設計：依據結論，設計資料庫、資料表、欄位、型態、關聯等
畫面功能分析：
1. 畫面規劃：依據需求分析與功能分析結果，規劃使用介面，畫面欄位、按鈕
2. 功能樹狀圖、網頁地圖：依據各功能分類與畫面，歸類相關功能，做出畫面分類樹狀圖、網頁地圖
3. 使用者再確認：依照功能樹狀圖、網頁地圖，在此與使用者討論，並依照需求條列逐一比對各需求與畫面關係→依使用者需求修改→再確認。直到確認無誤。
程式與撰寫規劃：
1. 依照【畫面分析】、【資料分析】、【功能分析】規劃出各相關程式於N-Tiers中
  1. 畫面分析：介面層，處理各功能的介面、資料存取的介面
  2. 資料分析：資料層，處理資料庫的存取
  3. 功能分析：商業邏輯層，處理各功能所需運算、資料交換，並與介面曾、資料曾溝通
2. 程式命名、Function命名、參數命名：
  1. 依據介面層、資料層、商業邏輯層條列出各程式名稱、Function名稱、以及所需傳遞的參數、型態名稱
  2. 各程式間的相互關係，並做出各程式間的相互關係圖
3. 程式分配：依現有人力狀況，分組並分派相關人員各程式，並條列出各程式的時程規劃於各組Leader，由各組Leader安排程式完成時程
4. 依據程式分配與時程，安排交叉測試時程

在這樣的分析過程中，分析完後的各程式可交由多人共同完成，只需將定義好的資料庫狀況、欄位、以及所需撰寫的程式名稱、參數說明給各分配到的程式設計師，就可開始分工的撰寫程式

其中介面層，小喵多數以Web作為介面，應用ASP/ASP.NET來開發；商業邏輯層、資料庫層則是透過COM+的元件來處理。

而介面層與商業邏輯層如何將之串聯起來呢，主要是透過以下的這樣方式來做

ASP.NET--------------------------------COM+-----------------------------MS-SQL Controls--ObjectDataSource------COM+元件------COM+元件-----------COM+元件--資料庫 ( 介面層 ) ( 商業邏輯層 ) ( 資料層 )

如何透過Email的超鏈結登入系統並直接進入指定的畫面

topcat — Tue, 11 Jul 2006 10:47:00 GMT

我們的系統中可能會需要讓某些特定的使用者(通常是高位者)為了操作上的【便利性】，讓使用者可以直接點【超鏈結】就直接的【進入系統】，並到達某特定的【網頁(文件)】

一般的做法可能是將【帳號密碼存於Cookie】的方式進行，但是這樣的方式不是很恰當，其次再給予超鏈結的時候，也會將要導回哪些畫面的資訊直接放在超鏈結中，這樣容易讓使用者知道您的程式會處理哪些欄位的資訊，造成使用者透過嘗試更改超鏈結資訊方式瀏覽到使用者不該瀏覽的資料。

例如：http://www.blueshop.com.tw/doc.asp?docid=1234

有心的駭客看到這樣的資訊，可能就會嘗試著把1234改成1233或者1235來查看，程式上一不小心就會讓使用者看到不該看的東西

而且將帳號密碼存於Cookie中，容易讓【木馬程式】透過【收集Cookie】的方式得知帳號密碼

所以如果要能夠比較安全的方式，小喵提供以下這個方式給大家參考

1. 超鏈結中帶的QueryString是一組GUID1(公鑰)
例如：http://www.blueshop.com.tw/abc.asp?GID=405CACB3-F658-4DD5-82E5-D1DA7DDFDB7E

2. 進入系統後，從資料庫中找到此組【GUID1公鑰】提供給哪個【使用者】使用、以及哪些【文件超鏈結資料】

3. 透過2.的【使用者】，在【TA】驗證該【使用者】存於Cookie中的【GUID2私鑰】以及限定的IP，讓只有【限定的IP】並且擁有【GUID2私鑰】的人才可以開啟，否則將拒絕進入

4. GUID2私鑰給予的方式：使用者登入後，檢查資料庫中是否有設定該【使用者】與【IP】有授權可以擁有【GUID2私鑰】→如果有→產生【GUID2私鑰】存放於資料庫中，並產生Cookie存放【GUID2私鑰】

首先會用的兩個資料表：

使用者私鑰管理表(TA)：

PK	UserId	使用者帳號
PK	IP	使用者電腦IP
	GUID2	私鑰

超鏈結公鑰管理表(TB)：

PK	GUID1	公鑰
PK	UserId	使用者帳號
	URLInfo	超鏈結資訊

使用者點選超鏈結後，首先從取得的【GUID1公鑰】透過【TB】取得這份文件是允許哪些【使用者】可以瀏覽，接著將此【使用者】透過【TA】取得該使用者允許在哪台電腦【IP】並且需要擁有哪個【GUID2私鑰】才能看。

換言之，需要【GUID1(公鑰)+允許的電腦IP+GUID2(私鑰)】三個條件缺一不可，才能夠進入該網頁(文件)

要實現以上的方式，需要有三個公用程式

1. 正常登入後【產生私鑰】

2. 產生Email中超鏈結時，【產生公鑰】

3. 鏈結回來後【驗證3要件】

這樣的設定方式，適用於一個人擁有多個電腦，也適用於各系統自行運用。

FAQ：

Q1：請問如果使用者擁有多台電腦，是否適用

A1：可以適用，因為TA中的主索引為UserId + IP，所以一個使用者可以設定多台電腦，各每台電腦各自擁有各自的私鑰

Q2：請問如果一個網頁(文件)需指定三人可瀏覽，是否適用

A2：可以適用，因為TB中主索引為GUID1 + UserId，所以一份文件可以指定多人瀏覽

Q3：請問如果信件被別人攔截，是否可以直接點選超鏈結就進入系統

A3：不會。信件中的超鏈結中是公鑰，必須加上【GUID2私鑰】及【IP】兩個條件都符合才能進入

Q4：請問，如果使用者借用別人的電腦登入，會不會在別人電腦中儲存【GUID2私鑰】

A4：不會，儲存私鑰必須符合【正常登入】【符合限制IP】才會儲存，如果會擔心，可將儲存的動作作成按紐讓使用者按下【在這台電腦儲存私鑰】的按鈕後才儲存【私鑰】

[轉載]生活中的ERP

topcat — Thu, 02 Mar 2006 09:36:00 GMT

一篇粉生活化的解釋出ERP的精髓....

ERP (Enterprise Resource Planning)企業資源計畫，指的是具有品質管理、現場服務、維修管理、配銷、行銷和供應商管理等額外能力的系統。

還是不懂嗎？沒關係，看了這篇文章就懂了~~^^"

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊
＊＊＊＊

一天中午，丈夫在外給家裏打電話：「親愛的老婆，晚上我想帶幾個同事回家吃飯
可以嗎？」（訂貨意向）

妻子：「當然可以，來幾個人，幾點來，想吃什麼菜？」

丈夫：「6個人，我們7點左右回來，準備些酒、烤鴨、番茄炒蛋、涼菜、蛋花
湯……你看可以嗎？」（商務溝通）

妻子：「沒問題，我會準備好的，」（訂單確認）

妻子記錄下需要做的功能表（MPS計劃），

具體要準備的菜：鴨酒番茄雞蛋調料──（BOM物料清單），

發現需要：1只鴨，5瓶酒，4個番茄，──（BOM展開），

炒蛋需要6個雞蛋，蛋花湯需要4個雞蛋（共用物料）。

打開冰箱一看（庫房），只剩下2個雞蛋（缺料）。

來到自由市場，妻子：「請問雞蛋怎麼賣？」（採購詢價）

小販：「1個1元，半打5元，1打9.5元。」

妻子：「我只需要8個，但這次買1打。」（經濟批量採購）

妻子：「這有一個壞的，換一個。」（驗收，退料，換料）

回到家中，準備洗菜、切菜、炒菜──（工藝路線），

廚房中有燃氣、微波爐、電飯堡──（工作中心）。

妻子發現拔鴨毛最費時間（瓶頸工序，關鍵工藝路線），

用微波爐自己做烤鴨可能就來不及（產能不足），

於是決定在樓下的餐廳裏買現成的（產品委外）。

下午4點，電話鈴又響：「媽媽，晚上幾個同學想來家裏吃飯，你幫準備一下。」
（緊急訂單）

「好的，兒子，你們想吃什麼，爸爸晚上也有客人，你願意和他們一起吃嗎？」

「菜你看著辦吧，但一定要有番茄炒雞蛋。我們不和大人一起吃，6：30左右回
來。」（呵呵，不能併單處理）

「好的，肯定讓你們滿意。」（訂單確認）

雞蛋又不夠了，打電話叫小販送來。（緊急採購）

6：30，一切準備就緒，可烤鴨還沒送來，急忙打電話詢問：「我是李太太，怎麼
訂的烤鴨還沒送來。」（採購委外單跟催）

「不好意思，送貨的人已經走了，可能是堵車吧，馬上就會到的。」門鈴響了，
「李太，這是您要的烤鴨。請在單上簽一個字。」（驗收、入庫、轉應付帳款）

6：45，女兒的電話：「媽媽，我想現在帶幾個朋友回家吃飯可以嗎？」（呵呵，
又是緊急訂購意向，要求現貨）

「不行呀，女兒，今天媽媽已經需要準備兩桌飯了，時間實在是來不及，真的非常
抱歉，下次早點說，一定給你們準備好。」（哈哈，這就是ERP的使用侷限，要有
穩定的外部環境，要有一個起碼的提前期）

送走了所有客人，疲憊的妻子坐在沙發上對丈夫說：「親愛的，現在咱們家請客的
頻率非常高，應該要買些廚房用品了（設備採購），最好能再雇個小保姆（連人力
資源系統也有介面了）。」

丈夫：「家裏你做主，需要什麼你就去辦吧。」（通過審核）

妻子：「還有，最近家裏花銷太大，用你的私房錢來補貼一下，好嗎？」（哈哈哈
哈，最後就是應收貨款的催要。還可再加上成本核算，總帳，決策分析等等）。

例如……送走了所有客人，妻子拿著計算器，準確地算出了今天的各項成本（成本
核算）和節餘原材料（車間退料），並計入了日記帳（總帳），把結果念給丈夫聽
（給領導報表），丈夫說道「值得，花了145.49元，請了好幾個朋友，感情儲蓄帳
戶增加了若干」（經濟效益分析）。