4.2 系統實作案例

(1)

第4章系統實作及範例展示

4.1 系統架構與開發工具

一、實作系統架構

本研究欲實作未調整功能點識別規則之演算法，透過 0 所陳述由 ER-DFD 之識別計算未調整功能點所需之各個要項及其相關複雜度。

實作環境使用 Microsoft Windows 2000 Server SP4 作業系統下，採用 Borland

Delphi 7.0 作為實作開發平台，並使用 Borland Delphi 提供之 XMLDocument 元件進行 XML 檔案的解析。實作系統架構如圖 4-1 所示：

資料來源：本研究整理圖 4-1 本研究之實作系統架構圖

實作系統架構規劃出三個主要單元：

第四章系統實作與範例展示

(2)

1. 輸出／入介面：提供使用者輸入「欲估算未調整功能點之系統名稱」及「該系統之 ER-DFD 設計規格所轉化之 XML 檔案」。

2. 資料蒐集單元：蒐集 XML 檔案內各個標籤所需資訊，並暫存於本研究所規劃之類別所宣告之物件陣列內。

3. 資料辨識單元：以[3]所提出之識別規則為基礎，對資料蒐集單元進行未調整功能點各個要項及複雜度辨識，並輸出辨識結果。

二、實作系統類別

為了便於將所解析出 XML 檔案資料進行暫存、分類所需，透過繼承 delphi 7

TObject 類別自訂出 9 個類別，各個類別之屬性、方法如圖 4-2 所示：

圖 4-2 本研究識別功能點要項所自訂之類別

4. TXMLApplication 類別：儲存 XML 檔案辨識內部系統、外部系統所需資料。

5. TEnity、TSubEntity、TSpecialization 類別：儲存識別紀錄(RET)所需資料。

(3)

6. TILF、TILFRef 類別：儲存識別內部邏輯檔案(ILF)所需資料。

7. TEI 類別：儲存識別外部輸入(EI)所需資料

8. TEQEO 類別：儲存識別外部查詢(EQ)、外部輸出(EO)所需資料。

9. TStringList 類別：將所蒐集之 XML 檔案內容資訊以字串陣列之方式存入所規劃類別之宣告之物件，並透過其物件方法對所儲存之字串進行操作處理。

運用物件導向語言於軟體專案系統之開發在國內已被程式開發者奉為圭臬。本研究以物件導向語言重新詮釋[3]所提出之識別規則，以期能引入更多的先進對此系統進行修改，擴大本研究系統之適用範圍，並喚起國內對軟體規模度量之重視。

4.2 系統實作案例

本研究透過[2]所展示的人力資源系統案例，做為實作系統之範例說明，除此之外，本研究也對[6]所展示的 5 個系統及[7]所展示之運動用品銷售系統進行未調整功能點之計算，以驗證本實作演算法之有效性。

根據[2]所列出人力資源系統相關實體即屬性如，本研究依據[3]也將關聯所需之外

部鍵標示所應歸屬的實體內。如表 4-1：

實體關係圖中的元素屬性

1.Employee ssn(key)、name、n_dep、type_code,loc_name(foreign key)、

currency_location(foreign key)

2.Salaried_Emp ssn(foreign key),supervisory_level

3.Hourly_Emp ssn(foreign key),、collective_bargaining_unit_number、

(4)

standard_hourly_rate、US_hourly_rate

4.Dependent dep_ssn(key)、dep_name、dep_birth,ssn(foreign key) 5.Job name、job_number(key)、pay_grade、description

6.Job_assignment job_number(foreign key)、ssn(foreign key)、effective_date、

salary、performance_rating、Status_Inactive,System_Date 7.Location loc_name(key)、country、state、city、address、zip 8.conversion_rate currency_location(key)、base_currency、

conv_rate_to_base_currency、date_of_rate 表 4-1 人力資源系統相關實體及屬性

另外，[2]所規劃出 16 個單一程序(Elementary Process,EP)，如表 4-2。

1. 關於員工(employee)部分：

(1) 新增員工資訊 (2) 修改員工資訊 (3) 刪除員工資訊 (4) 查詢員工資訊

(5) 產生員工報表資訊。

2. 關於工作(job)部分：

(1) 新增工作資訊 (2) 修改工作資訊 (3) 刪除工作資訊 (4) 查詢工作資訊 (5) 產生工作報表資訊

3. 關於工作分派(job_assignment)部分 (1) 新增工作分派資訊

(2) 修改工作分派資訊 (3) 刪除工作分派資訊 (4) 查詢工作分派資訊 (5) 產生工作分派資訊報表

4. 關於員工工作位置(location)部分 (1) 查詢員工工作地區

表 4-2 人力資源系統之 16 個單一程序

根據表 4-1 可描繪出如圖 4-3 之實體關係圖。該實體關係圖標示出系統界線，其中X為內部系統，YZ[為外部系統，而[也代表操作系統之使用者。各個實體均標示出主鍵、外部鍵及實體間之關聯性與關聯基數(cardinality)，

(5)

圖 4-3 人力資源系統之實體關係圖 1. 本研究針對具程序，進行細部說明：

(1) 新增員工資訊：新增員工資訊並包含新增其員工家屬資訊。

(2) 刪除員工資訊：透過員工編號刪除該員工資訊，包含刪除屬於該員工之工作分派資訊。

(3) 查詢員工資訊：透過員工編號查詢員工所有資訊。

(4) 產出員工報表資訊：除了產出員工所有資訊外，並計算出該報表內員工資訊總人數。

(5) 新增工作資訊：根據 user 所提估之屬性進行新增工作相關資訊。

(6) 新增工作分派資訊：新增工作分派即將某一工作分派至某一員工。

(7) 刪除工作分派，透過員工編號、工作代碼將該工作分派刪除

(6)

4.3 XML 架構

一、XML DTD

本研究將人力資源系統之 ER-DFD 設計規格圖示轉化為 XML 檔案，如附錄

2，該 XML 檔案之架構及自訂標籤特性均透過 XML DTD(Data Type Definition)呈現如附錄 3。相關 DTD 所定義之標籤說明如下：以<application>標籤標示 ER-DFD 內之各個系統。<application>標籤內之元素是由<entity>標籤(含<subentity>)所構成的集合、<relation>標籤所構成的集合及<process>標籤所構成的集合組成。各個

<entity>、<relation>分別由<key>、<foriegnkey>、及<field>標籤及技術性欄位,<techfield>,標籤所構成。父實體與子實體之間的關係則以<specialization>標籤表示。<dataflow>標籤則表示系統之資料流，其 src 與 dest 屬性標示了資料流之方向。<errorflow>標籤則表示系統回應訊息，方向也透過 src 與 dest 屬性決定。

二、使用者執行程序

透過<dataflow>標籤之 src 屬性設定為 user，dest 屬性設定為程序，則表示使

用者傳遞<field>標籤至指定程序(表 4-3 之

X

)，每個程序各自擁其唯一的處理邏輯(process logic)，以處理使用者傳遞過來之資訊。

三、維護(maintain)及參考(reference)

檔案功能類型可能被程序所維護，也可能被程序所參考。若被某一程序所維

護，如表 4-3 之

Y，

則在<dataflow>標籤內之 src 屬性為一程序；dest 屬性則為

Z，

(7)

為一程序。

四、系統回應訊息(system response message)

透過<errorflow>標籤之 src 屬性設定為程序，dest 屬性設定為 user，表示程序處理

過程可能發生之回應訊息，如表 4-3 之

[

4.4 解析 XML 檔案

一、 <application>標籤相關資訊

XML 檔案內可能涵蓋除欲估算系統以外的其它外部系統，這些系統內部元素均定義於

<application>標籤內，以 name 屬性標示各個不同系統之名稱。如表

4-4 定義了四個系統，系統名稱分別為 hr、user、fixed_assets 及

currency。系統內所具備之實體集合、關聯集合及程序集合均以

<entityset>標籤、<relationset>標籤、<processset>標籤表示。

由於功能點分析法利用應用程式界線(application boundary)的概念區隔出內部系統及外部系統，內部系統即是未調整功能點所要估算的對象。因此，本研究表 4-3 XML 檔案呈現方式

Y X

Z

[

(8)

辨識 XML 檔案何者系統屬於內部系統所採取的方式為：比對使用者在程式介面所輸入之系統名稱與與<application>標籤之 name 屬性決定出內部系統；其它則屬於外部系統。本研究於所定義的自訂類別 TXMLApplication(如圖 4-2)透過一自訂屬性,Inside,設定為 True，以辨識出內部系統。

表 4-4 內部系統與外部系統以 XML 呈現方式

另外，搜尋各個系統內的組成元素資訊並進行暫存，以利後續辨識資料功能類別及交易功能類別，搜尋方式如下：

1. 搜尋<application>標籤，並將該標籤之 name 屬性值存入自行宣告之 TXMLApplication 類別的 XMLApplication 陣列物件之 name 屬性內。各個

<application>標籤之 name 屬性值均會存入該物件陣列所定義之屬性之不同索引空間內。

2. 若步驟 1.之 Name 屬性值等於使用者所輸入的系統名稱，則判定為內部系統，

(9)

Inside 屬性值設為 False。

3. 蒐集<Application>標籤下的子標籤資訊，<processset>標籤、<entityset>標籤、

<subentityset>標籤、<relationset>標籤，以利透過這些資訊進行判定資料功能類型與檔案功能類型所需的資料比對。如辨識某一實體是否存於在某個

<application>標籤之<entityset>子標籤內，以決定記錄個數應歸屬於內部系統或者外部系統。

二、蒐集<entity>、<relation>、<specialization>、<errorflow>標籤相關資訊

1. 蒐集<entity>標籤資訊

(1) 搜尋<entity>標籤名稱，並將其標籤之 name 屬性值存入自行宣告之 TEntity 類別的 Entity 物件陣列之 name 屬性內。各個<entity>標籤之 name 屬性值均會存入該物件陣列所定義之屬性之不同索引空間內。

(2) 搜尋<entity>標籤之子標籤資訊，如<key>標籤、<foreignkey>標籤及<field>

標籤，以利進行資料功能類型之複雜度計算。如外部介面檔案資料項個數及內部邏輯檔案之紀錄個數計算。

2. 蒐集<relation>標籤資訊

(1) 搜尋<relation>標籤，並將其標籤之 name 屬性值存入自行宣告之 TRelation 類別的 Relation 物件陣列之 Name 屬性內。各個<relation>標籤之 name 屬性值均會存入該物件陣列所定義之屬性之不同索引空間內。

(2) 搜尋<relation>標籤之子標籤,<field>,資訊，以利進行資料功能類型之資料

(10)

項個數計算。如內部邏輯檔案之記錄個數計算。

3. 蒐集<specialization>標籤資訊

搜尋<specialization>標籤之子標籤資訊，如<parent>、<child>，以利進行資料功能類型之紀錄個數之計算。如內部邏輯檔案之記錄數計算。

4. 蒐集<errorflow>標籤資訊

搜尋<errorflow>標籤名稱，並將其標籤之 src 屬性值存入自行宣告之

ErrorFlowSrc 之字串陣列內，以利辨識出交易功能類型應計算之資料項個數。

三、蒐集<dataflow>標籤及其子標籤資訊

為了日後能夠對內部邏輯檔案、外部介面檔案進行辨識及交易功能類型之資料項、檔案參考之辨識，對<dataflow>標籤的 src 屬性值與 dest 屬性值進行蒐集，

在此先針對以下兩種情況進行蒐集：

為了日後能夠對檔案功能類別進行辨識及交易功能類別之資料項、檔案參考之辨識，對<dataflow>標籤的 src 屬性值與 dest 屬性值進行蒐集，在此先針對以下兩種情況進行蒐集：

1. 蒐集具有「維護」及「外部參考」特性之<dataflow>標籤及其子標籤

(1) 當 src=內部系統的程序，dest=內部系統的實體，表示有一資料流從程序到實體，可知其符合「維護」性質，參考圖 3-12 從 ER-DFD 識別外部輸入示意圖

(2)當 src=外部系統的實體，dest=內部系統的程序，可知其符合「外部參考」性質，圖 3-9 從 ER-DFD 識別外部介面檔案示意圖

(11)

參考表 4-5，關於(1)與(2)之儲存方式為以「逗號」做為「分隔符號」存入自行宣告之 ILFCode 字串陣列中，並以「ILF」、「EIF」字串區別該<dataflow>標籤是具有維護性質或是外部參考性質。

如(1)的附加字串是「ILF」，表示該標籤具備維護性質(如表 4-5 的Z)。

而(2)的附加字串是「EIF」，表示該標籤具備外部參考性質(如表 4-5 的[)。

由存入資訊可知，ILFCode 字串陣列已存入了三項資訊，即<dataflow>標籤的 src

屬性、dest 屬性及「區隔字串」分別如表 4-5 之X、Y及Z[。

三者以如下方式存放於字串陣列 ILFCode 內：

ILFCode.Strings[i]：{add_emp，employee，ILF，name，ssn，...}

ILFCode.Strings[i+1]：{add_emp,convertion_rate,EIF,conv_rate_to_base_currency}

X.src 屬性值。

Y.dest 屬性值。

Z.區隔字串：區分<dataflow>標籤是否具有 ILF 性質或 EIF 性質。

[.區隔字串之後為<dataflow>子標籤,<field>,資訊，以利計算 ILF 資料項。

表 4-5 <dataflow>標籤資訊以字串陣列儲存之方式

另外，對圖 4-4 之<dataflow>子標籤,<field>標籤,之蒐集方式為附加在「區隔字串」

之後，存入 ILFCode 之結果如表 4-5。

圖 4-4 <dataflow>標籤的子標籤,<field>

2. 蒐集具有「內部參考」特性之<dataflow>標籤

具有內部參考特性之<dataflow>標籤相關資訊存入 ILFRef 物件陣列內。根據「參

X Y Z

Z

[

(12)

考」之識別規則，「若內部系統之單一程序參考(reference)到內部邏輯檔案之部分 集合，即可視為一個檔案參考」由此可知，「參考」不同於「維護」，相異在於「參考」並不需要參考內部邏輯檔案內的所有元素，即可列入檔案參考個數計算，而

「維護」則需要維護內部邏輯檔案之所有元素才能列入檔案參考個數計算。故

ILFRef 可能為 ILF 之子集合。

程序在對實體進行參考(reference)時，由於上述之內部參考特性，即使參考同一個內部邏輯檔案內多個實體，均識別為參考同一個內部邏輯檔案。因此，必須進行如圖 4-5 之處理，才能夠完成此判斷。圖 4-5 為圖 4-6 存入陣列之示意圖。

圖 4-5 將圖 4-6 存入陣列之示意圖

圖 4-6 未來於計算交易功能類型之檔案類型參考個數時，會先進行將 mark 屬性由

1 變為 0 之設定，同一個內部邏輯檔案之實體集合僅能有一個實體之 mark 屬性為 1，因此可透過比對 mark 屬性是否為 1 來達到是否參考不同內部邏輯檔案個數，

陣列索引

變為 0

(13)

以利正確計算出交易功能類型之檔案參考個數。

註：ILF 如下：

ILF：{order、orderRow}

emitInvoice 參考到 ILF 集合內所有實體，{order、orderRow}。

圖 4-6 被 Process 所參考到的元素集合視為一個檔案參考示意圖

註：ILF 如下：

ILF 1：{employee、salaried_emp、hourly_emp、dependent}。

add_job_assignment 僅參考到 employee 實體。

ILF 2：{job}。add_job_assignment 參考 job 實體。

圖 4-7 內部參考示意圖

圖 4-6emitInvoice 程序參考了內部邏輯檔案的所有個實體，視為對該內部邏輯檔案進行參考。而圖 4-7add_job_assignment 程序參考了內部邏輯檔案之部分實體

{employee}，也視為對該內部邏輯檔案進行參考。

1. 由於本研究採取判斷 ILFRef[i].mark 屬性值被設定為「1」之個數以決定該程序內部參考個數，因此將符合 ILFRef 特徵之<dataflow>標籤之 src、dest 值分別存至 ILFRef 物件陣列所規劃之 src、dest 屬性，並將 mark 屬性值預設為「1」。預先假設「所有被 process 參考到的實體，個別都視為一個 FTR。」以圖 4-6 之Z[

Z ^兩者隸屬

同一 ILF

X [

將Z與[視為 1 個 FTR

X Y

(14)

為例：order 及 orderRow 被識別為對兩個內部邏輯檔案進行參考，事實上 order 及 orderRow 僅參考一個內部邏輯檔案。

2. 陣列索引值加 1(即 ILRef[i+1])，進行下一個<dataflow>標籤之 src、dest 及 mark 屬性值之處理如下：

(1)比對目前<dataflow>標籤的 dest 屬性值(如圖 4-6 之[)與上一個<dataflow>標籤的 dest 屬性值(如圖 4-6 之Z)，相同否？以利 process 之 FTR 個數累計。

<1>. 若成立，表示同一個 process 參考相同內部邏輯檔案一個以上的實體，

因此必須將所參考到的實體(也就是<dataflow>標籤之 src 屬性值)及 mark 屬性值存至「索引值減 1 (即 ILFRef[i+1-1])」的陣列空間內，目的在步驟 2.已先將陣列索引值加 1，故在此必須將索引值減 1，才能將相關資訊儲存到原先的陣列空間內。

<2>. 若不成立，則表示同一個 process 之 ILFRef 類型之<dataflow>標籤已經處理完畢(例如可能已經處理至圖 4-6 之X)。透過後續交易功能類別對 mark 屬性值之修改，以達到正確辨識內部參考之檔案參考個數。

4.5 進行檔案功能類型之識別

本研究已將辨識資料功能類型所需資訊存入 ILFCode 陣列內，因此進行對

ILFCode 陣列內容進行字串分割，將所需資訊存入自訂之 TILF 類別所宣告之 ILF 物件陣列相關屬性內，以利進行識別。以表 4-5 為例，將表 4-5 之資訊進行如下之儲存：

(15)

1.ILF[i].src=add_emp 2.ILF[i].dest

2.1.ILF[i].dest.strings[j]=employee 3.ILF[i].ModuleType=ILF

4.ILF[i].field

4.1.ILF[i].field.strings[j]=name

4.2.ILF[i].field.strings[j+1]=ssn 一、內部邏輯檔案之識別規則實作

找出對檔案集合進行「維護」之程序，換句話說，對 ILF[i].src 與 ILF[i].dest 進行辨識。在人力資源系統中，共有 9 個外部輸入維護實體集合，總計可以形成

9 個(如附錄 2 的X～`)實體集合，必須辨識此 9 個實體集合中的哪些實體集合符合[3]所定義之內部邏輯檔案之識別規則。尚未辨識之前，每一個實體集合均為「候選內部邏輯檔案」。必須要去除「重複」及「被包含」的檔案集合，才能識別為內部邏輯檔案個數。附錄 2 的X～`有下列以下狀況

¾ X和Y這兩個檔案集合重複、

¾ [和\這兩個檔案集合重複、

¾ ^_`這三個檔案集合重複。

¾ Z和]則是檔案集合包含了另一個檔案集合之狀況。

去除「重複」及「被包含」的檔案集合，本研究採如下步驟：

(16)

1. 根據單一程序所維護檔案集合內元素個數之多寡，以遞增方式進行排序

將陣列內元素以遞增方式進行排序，本研究提出之解決方案為「進行 ILF 陣列索引『序列化』之前置步驟」。所謂「序列化」即是將陣列內容進行排序後，

陣列索引值仍能保持未排序前之「有序(order)」之方式。請對照表 4-6 及表 4-7 排序後之陣列索引差異。表 4-6 為排序後，陣列索引值未序列化之情況。表 4-7 為排序後陣列索引值序列化之情況，其中 ILFRadix[i]為另一自行宣告之陣列，存放表 4-6 相對應 ILF[i]陣列之索引值，而 ILF[i].Dest.Count 為紀錄存放<dataflow>

標籤之相同 Src 屬性而不同 Dest 屬性之實體之個數。表 4-8 為序列化之演算法。

序列化之目的是為了能夠符合程式語言 for 迴圈之「迴圈計次值」規則性遞

增之特性，以利陣列內容可透過迴圈方式取出。

排序前 排序後(未將陣列索引序列化)

ILF[0].Dest.Count=7 ILF[1].Dest.Count=1 ILF[2].Dest.Count=1 ILF[3].Dest.Count=7 ILF[4].Dest.Count=1 ILF[5].Dest.Count=1 ILF[6].Dest.Count=2 ILF[7].Dest.Count=8 ILF[8].Dest.Count=2 ILF[9].Dest.Count=1 ILF[10].Dest.Count=3

ILF[1].Dest.Count=1 ILF[2].Dest.Count=1 ILF[4].Dest.Count=1 ILF[5].Dest.Count=1 ILF[9].Dest.Count=1 ILF[6].Dest.Count=2 ILF[8].Dest.Count=2 ILF[10].Dest.Count=3 ILF[0].Dest.Count=7 ILF[3].Dest.Count=7 ILF[7].Dest.Count=8 表 4-6 ILF[i].Dest.Count 排序前後

排序前 排序後(已將陣列索引序列化)

ILF[0].Dest.Count=7 ILF[1].Dest.Count=1 ILF[2].Dest.Count=1 ILF[3].Dest.Count=7 ILF[4].Dest.Count=1

ILF[ILFRadix[0]].Dest.Count=1 ILF[ILFRadix[1]].Dest.Count=1 ILF[ILFRadix[2]].Dest.Count=1 ILF[ILFRadix[3]].Dest.Count=1 ILF[ILFRadix[4]].Dest.Count=1

(17)

ILF[6].Dest.Count=2 ILF[7].Dest.Count=8 ILF[8].Dest.Count=2 ILF[9].Dest.Count=1 ILF[10].Dest.Count=3

ILF[ILFRadix[6]].Dest.Count=2 ILF[ILFRadix[7]].Dest.Count=3 ILF[ILFRadix[8]].Dest.Count=7 ILF[ILFRadix[9]].Dest.Count=7 ILF[ILFRadix[10]].Dest.Count=8 表 4-7 ILF[i].Dest.Count 排序前後

MaxCount:=GetMaxCount(DestCount)//找出 process 所維護檔案集合之元素個數之最大值

Count:=0;RadixNum:=1;//RadixNum 為分類的基準範圍，由 1 到 MaxCount for i:=0 to MaxCount-1 do

begin

//所有「疑似 ILF」之元素個數都要與基準範圍進行比對

//人力資源系統檔案集合之元素個數最小為 1，最大(MaxCount)為 8 for j:=0 to ILFCount-1 do

begin

//將檔案集合之元素個數符合基準範圍之 ILF 索引值,j,存入 ILFRadix 陣列 if(ILF[j].Dest.Count=RadixNum) then

begin

ILFRadix[count]:=j;

Count:=Count+1; //

end;

end; //end for j:=0 to ILFCount-1

//透過累加來更改元素個數比對之基準範圍，RadixNum 最大值為 MaxCount。

RadixNum=RadixNum+1;

end; //end for i:=0 to MaxCount-1 表 4-8 陣列索引序列化之演算法

透過表 4-8 之演算法，所得到最後之結果如表 4-9。

ILFRadix[0]=1 ILFRadix[1]=2 ILFRadix[2]=4 ILFRadix[3]=5 ILFRadix[4]=9 ILFRadix[5]=6

ILFRadix[6]=8 ILFRadix[7]=10 ILFRadix[8]=0 ILFRadix[9]=3 ILFRadix[10]=7 表 4-9 ILFRadix 陣列對應 ILF 陣列索引值一覽表

2. 標示「實體集合內包含其它實體集合」

「標示」即是將 TILF 類別所宣告之 ILF 物件之 IsRealILF 屬性進行 true 或 false 之設定。透過「序列化」步驟後，即可對每一個疑似 ILF 之檔案集合進行「重複」

及「包含」之識別，也就是針對以下觀點進行識別：

(18)

若有兩個集合 S 及 S’，元素個數分別為 M 及 N，M>=N，S 集合內 M 個元 素是否包含 S’集合內 N 個元素。

若 S 檔案集合包含 S’檔案集合內所有元素，則將 S 之 IsRealILF 屬性標示為 false 表示 S 不滿足內部邏輯檔案之識別規則。IsRealILF 預設值為 true。。

將個別檔案集合進行兩兩比對，若該檔案之 IsRealILF 已被設定為 false，則不對該檔案集合進行比對，示意圖如圖 4-8。

3. 計算實體集合包含其它實體集合之個數

完成標示「實體集合內包含其它實體集合」之步驟後，即可識別哪些實體集合符合內部邏輯檔案之識別規則，此步驟要計算出「不符合內部邏輯檔案識別規則之實體集合」包含「符合內部邏輯檔案之識別規則之實體集合」之個數，並指定給該 ILF[i].count 屬性。count 屬性初值為 0，若兩個實體集合相等，則 count 為 1；

其它狀況，則 count 即為所包含「符合內部邏輯檔案資格之實體集合」個數(例如人力資源系統之 delete_emp 程序所維護之實體集合包含兩個「內部邏輯檔案」，

則 ILF[i].count 即為 2)。示意圖如圖 4-9，其中 ILF[i].Count 屬性為紀錄第 i 個 ILF 包含其它 ILF 之數目。

二、外部介面檔案識別規則實作

找出對外部實體進行「參考」之程序：在人力資源系統中共有 5 個單一程序對外部檔案進行參考，故形成 5 個檔案集合。由於本研究已假設所參考之外部檔案必定符合其所屬系統之內部邏輯檔案識別規則，故不須進行否符合內部邏輯檔

(19)

案之是識別規則驗證，只須識別出個別外部檔案被哪些單一程序參考？例如：

¾ conversion_rate 被 add_emp、change_emp、inquire_emp、report_emp 所參考。

¾ location 被 add_emp、change_emp、inquire_location 所參考。

本研究已於 ILFCode 陣列歸納出程序所參考的外部檔案並已使用「區隔字串」標示為 EIF(如表 4-5 之[)，也於本節進行字串分割將分隔字串存入

ILF[i].ModuleType，因此只要將取出 ILF[i].ModuleType=’EIF’之 ILF[i].src 即可得出外部介面檔案。

(20)

圖 4-8 標示「檔案集合內包含其它檔案集合類型」之示意圖

1.依元素個數進行遞增排列。2.進行比對，當「包含」成立，將候選「ILF」之 IsRealILF 屬性設為 False。3.數字代表被標示的先後順序。

(21)

圖 4-9 計算「候選 ILF」集合包含「ILF」集合之個數計算示意圖。

前三個為以識別之「ILF」之後為「候選 ILF」，透過兩者進行內部實體的比對，可以計算出候選 ILF 包含 ILF 之個數。

(22)

4.6 進行檔案功能類型複雜度計算

一、資料項(DET)之識別

1. 內部邏輯檔案之資料項識別

內部邏輯檔案之資料項數應為程序所傳遞之欄位之聯集(union)。透過計算每一個程序於資料流所傳遞至該內部邏輯檔案之欄位總數，即為該內部邏輯檔案之資料項個數。

2. 外部介面檔案資料項之識別

外部介面檔案資料項之識別規則同內部邏輯檔案資料項之識別規則，也是採取被目前系統所使用的欄位，而其它未在此系統所使用的欄位，則不予列入計算。

二、內部邏輯檔案紀錄之識別

表 3-12 為本研究對內部邏輯檔案紀錄之識別規則。紀錄識別即是對每一個已辨識為「內部邏輯檔案」進行紀錄之辨識，每一個內部邏輯檔案內之實體的集合，

可能存在三種類型：

1.該實體存在子實體(如圖 4-10)；

2.該實體為關聯實體(如圖 4-14)；

3.該實體屬於一般實體(如圖 4-12 的 dependent 實體)。

若識別出某實體存在於<parent>標籤(如圖 4-10 之Y)，則該 entity 紀錄個數即為子實體個數(即<child>標籤個數)。

由於關聯實體本身具備可對該關聯進行描述之屬性，故[3]將其視為實體並計

(23)

算為一個記錄。

一般實體，計算為一個記錄。因此內部邏輯檔案之記錄識別過程如下：

1. 辨識該內部邏輯檔案內之實體是否具有<specialization>標籤：如圖 4-10，

employee 實體位於<parent>標籤，故知 employee 具備<specialization>特性，故將<child>標籤個數，列入紀錄計算。

2. 辨識該內部邏輯檔案之實體是否具有關聯實體特性：如圖 4-14，job_assignment 若存在於<relation>標籤，且<field>標籤個數大於 0，則判定為關聯實體，列入紀錄計算。

3. 若非以上情況，則為一般實體，列入紀錄計算。

圖 4-10 employee 實體存在兩個子實體(sub-entity)

圖 4-11 一般實體與具有子實體之實體示意圖 Y

Z

單一程序維護之元素所形成之檔案集合

子實體,此兩實體為子實體該實體不存在子實體(一般實體) 父實體，該實體存在子實體

> X

(24)

圖 4-12 為圖 4-13 各個實體之詳細屬性

圖 4-14 關聯實體(associative entity)實例—job_assignment 三、關於外部介面檔案紀錄個數計算

根據參考(reference)的定義，外部介面檔案必為實體所組成。故比對

<dataflow>標籤的 src 的屬性值(如圖 4-15 左方)若存在於外部系統之<entityset>標籤當中(如圖 4-15 右方)，則列入外部介面檔案之紀錄計算。

圖 4-15 外部介面檔案紀錄示意圖

關聯實體

外部系統 1

外部系統 2

(25)

4.7 進行交易功能類型之識別

外部輸入(EI)、外部查詢(EQ)及外部輸出(EO)三者合稱交易功能類型，在人力資源系統中，交易功能類型轉化為 XML 檔案如圖 4-16 之(1)(2)(3)。由 XML 檔案得知：

一、EI、EQ 及 EO 之共同特徵：均以<dataflow src=”user” dest=”程序”>型式作為

EI、EQ 及 EO 起始標籤(如圖 4-16 之(1)的X)。

二、EQ 與 EO 兩者共同特徵分別參照圖 4-16 之(2)的XYZ與圖 4-16 之(3)的 XYZ，說明如下：

1. EQ 及 EO 均以<dataflow src=”user” dest=”程序”>標籤型式為起始，以

<dataflow src=”程序” dest=”user”>標籤型式為結束。可利用此兩者性質作為

「是否進入 EQ 或 EO 區塊」的判斷以及「結束 EQ 或 EO 區塊」的判斷。

2. EQ 及 EO 位於起始與結束標籤之間的標籤(如圖 4-16 (2)(3)的Y)為

<dataflow src=”實體” dest=”程序”>標籤型式，表示 EQ 及 EO 之資料擷取區塊。

三、EQ 與 EO 在 ER-DFD 之差異在於 EO 具備衍生欄位，此欄位是經由邏輯運算所產生(如圖 4-16 (3)之[)，而 EQ 則不具備此欄位。

綜合以上資訊，本研究於所給定之 XML 檔案採取如下步驟識別 EI、EQ 以及 EO：

一、擷取 XML 檔案內<dataflow>標籤的 src 及 dest 屬性值。

二、步驟一所擷取之「src 屬性值」等於”user”成立，則進入 EI、EQ、EO 判斷模式。將旗標變數 Found 設為 true。此旗標變數之目的為「紀錄可能是 EI 或

(26)

EQ 或 EO 之起始標籤」。

三、若步驟一所擷取的「dest 屬性值」(如圖 4-16 (1)之X)等於 XML 檔案內所表 示之「ILF[i].src 屬性值」成立，則符合 EI 之識別規則，表示此 EI 已維護該 檔案集合。將旗標變數 FoundEI 設為 true，表示已找到系統內其中一個 EI，並將 EI 之 dest 存入 EI 陣列 EI[EICount]當中(如表 4-10)。旗標變數 FoundEI 之功能為是否要進行 EQ、EO 條件判斷。此步驟 FoundEI=true，則已經確定為 EI，所以不需進行 EQ、EO 之判斷。

(27)

圖 4-16 EI、EQ、EO 特徵示意圖

陣列名稱

陣列索引

屬性名稱

EI 來源屬性值

屬性名稱

EI 目的屬性值 EI [0] Src = user Dest = add_emp EI [1] Src = user Dest = change_emp EI [2] Src = user Dest = delete_emp EI [3] Src = user Dest = add_job EI [4] Src = user Dest = change_job EI [5] Src = user Dest = delete_job

EI [6] Src = user Dest = add_job_assignment EI [7] Src = user Dest = delete_job_assignment 表 4-10 EI 陣列.Dest 屬性內容

外部輸出(EO) (1)

(2) Z

Z

Y

X X

X

[

ILF 集合之 src

EI 之 dest

(3)

EQ 之 dest

\

\ 外部輸入(EI)

結束標籤起始標籤

Y 結束

標籤起始標籤

EO 之 dest

外部查詢(EQ)

(28)

四、儲存步驟三進行處理之<dataflow>標籤之子標籤(即<field>標籤)，以利後續進行 EI DET 計數。

五、若步驟三不成立，則 FoundEI 仍為預設值 false。因此進行 EQ、EO 之辨識

－若於步驟二之旗標變數 Found 已被設為 true，表示已進入 EQ 或 EO 區塊(如圖 4-16 (2)(3)之X)。

－在旗標變數 FoundEI 為 false 的條件下，若於步驟一所擷取<dataflow>標籤之 dest 屬性為 user，則表示目前處理標籤為 EQ 或 EO 的結束標籤(如圖 4-16

(2)(3)之Z)。

六、當 FoundEI 為 false 的條件下，Found 為 true 成立，若於步驟一所擷取

<dataflow>標籤之 dest 屬性不為”user’，表示該標籤並非結束標籤，表示目前正在識別之<dataflow>標籤可能為圖 4-16 (2)(3)之Y的任何一個此外，並於 EQEO 物件陣列之 name 屬性紀錄該 EQ 或 EO 之名稱。陣列內容如表 4-11。

陣列名稱陣列索引屬性名稱 EQ 或 EO 名稱 EQEO [0] Name = inquire_emp EQEO [1] Name = report_emp EQEO [2] Name = inquire_job EQEO [3] Name = report_job

EQEO [4] Name = inquire_job_assignment EQEO [5] Name = report_job_assignment EQEO [6] Name = inquire_location 表 4-11 EQEO 陣列.Name 屬性內容

七、從 EQ 及 EO 的<field>標籤資訊，辨識衍生欄位(derived data)做為區別 EQ 及

EO 的重要資訊。EO 的衍生欄位出現的位置如圖 4-16 的[，即出現在 EO 的

(29)

八、根據 EQ 之定義：

(1) 本研究將 EQ 及 EO 區塊再細分成兩個子區塊，本文區塊(BodyField)(圖 4-16 (2)(3)之Y)及底層區塊(BottomField)(圖 4-16(2)(3)之Z)。

(2) BodyField 目的是要儲存該區塊所有的子標籤,<field>,以利辨識是否符合 EQ 之特性。

(3) BottomField 目的是要儲存底層區塊所有的子標籤,<field>,以利辨識是否符合 EO 之衍生欄位特性。

(4) 標示<errorflow>標籤，以利後續計算交易功能類型之複雜度。

(5) 根據 IFPUG 對 EQ 的定義：「離開內部系統到外部之資料流所傳遞的所有屬性必須要存在於指向單一程序的資料流所傳遞的欄位。」，圖 4-17 之 XYZ之重複屬性為 a1 及 a3，移除重複屬性後，將最後結果存於 BodyField 陣列內；將[之欄位資訊存於 BottomField 陣列內。

(6) 比對每一個 BottomField 與 BodyField 資料，若 BottomField 所有欄位均存在於 BodyField 欄位內，則判定為 EQ，將該 EQEO[i].ModuleType 屬性設為 EQ。

(7) 若 BottomField 存在至少一欄位內容不存在 BodyField 欄位內，則視為衍生欄位，則判定為 EO，即將該 EQEO[i].ModuleType 屬性設為 EO。

九、判斷 MoudleType 屬性即可辨識交易功能類型屬於 EI、EQ 或 EO。

(30)

圖 4-17 EQEO 欄位移除示意圖

4.8 進行交易功能類型複雜度之計算

一、外部輸入(EI)複雜度計算：

1. 資料項(DET)：根據外部輸入資料項之識別規則，計算圖 4-18 之X欄位個數。計算<dataflow>標籤之 src 屬性為 user，dest 屬性為屬於 EI 程序之子標籤為<field>標籤個數即可。

圖 4-18 EI DET 示意圖

2. 檔案類型參考(FTR)：由程序與檔案之互動共可區分出三種類型均識別為檔案類型參考：1.程序所維護之內部邏輯檔案(如圖 4-19 之X、圖 4-20 之

User EQ

a1,a2

a1,a3,a4

a3,a5,a6 a1,a2,a3,a4,a5,a6

[

X Y

Z

XYZ經過移除重複的屬性後，存於 BodyField 內。

[屬性資訊是存於 BottomField 內

X

(31)

部介面檔案(如圖 4-19 之YZ)。，

圖 4-19 程序所維護 ILF 及參考之 EIF

圖 4-20 程序所維護之 ILF

圖 4-21 程序所參考之 ILF

同一個 ILF 之實體集合僅能有一個實體之 mark 屬性為 1，其餘均變更為 0，透過比對 mark 屬性為 1，即可辨識出程序是否參考不同之內部邏輯檔案，以利計算該程序所參考之 FTR 個數。

圖 4-22 add_emp、change_jobassignment 之 ILFRef 之 mark 屬性變更示意圖

(1) add_emp 維護所識別之內部邏輯檔案(圖 4-19 之X)，計算為 1 個 FTR。另外，

程序也可能維護多個內部邏輯檔案之情況，delete_emp 維護所識別之 2 個內部邏輯檔案,{job_assignment}及{employee,salaried_emp,hourly_emp,dependent},(如圖 4-20 之 [\)共計算為 2 個檔案型態參考。

(2) add_emp 參考本研究所識別之 2 個外部介面檔案(圖 4-19 之YZ)，共計算為 2 X

Z Y

[

\

ILFRef[0] ]

ILFRef[1]

^

變更為 0 add_job

(32)

個檔案型態參考。

(3) change_jobassignment 參考 2 個不同內部邏輯檔案內之實體集合，分別為 {employee、dependent}及{job}(如圖 4-21 之]^)共計算為 2 個檔案型態參考。。

本研究透過如下方式識別出之外部輸入之檔案參考類型個數：

1. 針對圖 4-19 之X、圖 4-20 之[\，比對附錄 5 每一個 ILF[j].Src 屬性值與表 4-10 每一個 EI[i].Dest 屬性值，若兩者相等，表示該外部輸入維護該內部邏輯檔案，

依照所維護之內部邏輯檔案個數，則累計至該外部輸入之檔案型態參考個數。

2. 針對圖 4-19 之YZ，比對附錄 5 之 ILF[j].ModuleType 屬性值為 EIF 的每一個 ILF[j].Dest 屬性值與表 4-10 EI[i].Dest 屬性值比對，若兩者相等，表示該外部輸入參考該外部介面檔案，則累計至該外部輸入之檔案參考個數。

3. 針對圖 4-21]^，根據所蒐集之 ILFRef 相關資訊，本研究欲透過修改 4.8 節之 ILFRef[j].mark.strings[k]屬性之預設值來達到正確辨識外部輸入之檔案型態參考個數，圖 4-22 為圖 4-21]^之 ILFRef[j].mark.strings[k]示意圖。

(1) 比對圖 4-22 ILFRef[0].src.strings[0]之值與附錄 5 之 ILF[i].isRealILF 為 true 之 ILF[0].dest.strings[1]之值，兩者相等，則將旗標變數 Found 設為 true。

(2) 比對 ILFRef[0].Src.strings[1]之值與 ILF[0].dest.strings[0]之值，兩者相等，旗標變數 Found 已被設為 true 則表示 add_emp 參考了屬於同一個 ILF 內不同元素,employee 與 dependent，因此將 ILFRef[0].mark.strings[1]之值由預設值「1」

變更為「0」

(33)

(3) 比對 ILFRef[1].dest.strings[0]與 ILF[1].dest.strings[0]比對，兩者相等，將其標變數 Found 設為 true。至此已將所有 ILFRef 物件陣列比對完畢。換句話說，

每一個 mark.strings[k]屬性為預設值 1 之元素均代表不同之 ILF。

(4) 透過步驟(2)(3)將 ILFRef[j].mark.strings[k]屬性設定完畢後，將表 4-10 之 EI[i].Dest 的每一個值與附錄 7 之 ILFRef[j].Dest 比對，若兩者相等，便檢查 ILFRef[j].mark.strings[k]的每一個屬性值(因為該 EI 可能不只參考一個實體)，若為 1，則累加該外部輸入 FTR 個數。

(5) 將「維護」、「外部參考」、「內部參考」所得 FTR 累加，即為該 EI FTR 個數。

二、外部查詢(EQ)、外部輸出(EO)之 FTR 個數計算：

由程序與檔案之互動共可區分出兩種類型，較 EI 少一種類型：即所參考之

FTR(如圖 4-23 之Y圖 4-24 之Y)及所參考之 EIF(如圖 4-23 之Z圖 4-24 之Z)，均識別為 FTR。

圖 4-23 外部查詢所參考之 ILF 與 EIF 圖 4-24 外部輸出所參考之 ILF 與 EIF 此兩種類型之比對與 EI 之作法相同，仍說明如下：

1. 針對Z，比對附錄 5 之 ILF[j].ModuleType 屬性值為 EIF 的每一個 ILF[j].Dest 屬性值與表 4-10 EQEO[i].Dest 屬性值比對，若兩者相等，表示該 EQ 或 EO 參考該 EIF，則累計至該 EQ 或 EO 之 FTR 個數。

2. 針對Y，由於每一個 EQ 及 EO 均對 ILF 進行參考，故所參考之資訊也記錄於

Y Y

Z Z

(34)

ILFRef 物件陣列內，透過如上所述，變更個別 EQ 及 EO 所參考的不同 ILF 之每一元素的 mark 屬性(如圖 4-25 示意圖)完成後，只要比對附錄 7 與每一個

EQEO[i].dest 屬性，若兩者相同，且 mark 屬性為 1，即列入該 EQ 或 EO 之 FTR 個數之累加。

同一個 ILF 之實體集合僅能有一個實體之 mark 屬性為 1，其餘均變更為 0，透過比對 mark 屬性為 1，即可辨識出程序是否參考不同之內部邏輯檔案，以利計算該程序所參考之 FTR 個數。

圖 4-25 inquire_emp 之 ILFRef 之 mark 屬性變更示意圖

4.9 小結

透過以人力資源系統之 ER-DFD 所產出之 XML 檔案進行功能點分析法所定義之「維護」、「外部參考」、「內部參考」之解析，並將解析後之資訊暫存於本研究所宣告之自訂類別所產生物件之相關屬性內，透過將識別規則轉化為演算過程，識別出各個估算要項之未調整功能點。最後將每一要項之未調整功能點進行加總即可得出整個系統之未調整功能點。本實作識別之結果，如附錄 11；本實作系統採[2]之 ER-DFD 識別結果，如附錄 12；[2]實作系統識別結果如附錄 13。

本研究於人力資源系統進行自動化未調整功能點之估算與[2]之實作系統有三個要項產生差異，分述如下：

一、內部邏輯檔案組成元素之識別產生差異

變更為 0

(35)

[dependent salaried_emp hourly_emp employee]

[dependent empl_conv_rate empl_dep empl_loc employee salaried_emp hourly_emp]

表 4-12 本研究(左)與[2](右)識別 ILF 組成元素之差異

造成如表 4-12 差異之原因在於兩者對於內部邏輯檔案之組成元素定義不同所致，內部邏輯檔案組成元素之定義請參考表 3-3。

二、外部介面檔案之資料項個數之識別產生差異

EIF U.F.P DET count RET count Complexity conversion_rate 5 2 1 low

本系統

location 5 6 1 low

conversion_rate 5 4 1 low

[2]之系統

location 5 6 1 low

表 4-13 本研究識別外部介面檔案之資料項與[2]之差異

外部介面檔案資料項計數方式，應決定於目前估算系統內被程序所使用為主，並非該實體之屬性總數。故[2]在內部邏輯檔案及外部介面檔案關於資料項之識別規則未符合標準。

三、外部查詢與外部輸出之檔案參考個數之識別產生差異

E.P. Type U.F.P. DET count FTR count Complexity 本系統 inquire_emp EQ 4 13 2 average [2]之系統 inquire_emp EQ 3 13 1 low 本系統 report_emp EO 5 14 2 average [2]之系統 report_emp EO 4 14 1 low 表 4-14 本研究與[2]識別 EQ、EO 之 FTR 差異

本研究發現[2]之 Inquire_Emp(如附錄 10 之○² )，參考了 employee 實體不存在之屬性,conv_rate_to_base_currency，故應修正為對 conversion_rate 進行參考。

關聯

(36)

如附錄 9 之○² 及○⁵ ，並將所參考之外部介面檔案列入檔案參考類型計算。

Report_Emp 之差異同 Inquire_Emp。故[2]於實體被參考的欄位定義未符合標準。本研究列出估算人力資源系統總未調整功能點結果如表 4-15，差異之原因已

於前述。

未調整功能點計算所花費時間

本實作系統 97 0.251 秒

[2]實作系統 95 8.852 秒

表 4-15 本系統與[2]所估算之未調整功能點之結果

本實作系統較[2]多了兩個功能點，這兩個功能點分別來自對 inquire_emp 及

report_emp 之 FTR 計算之差異，如表 4-14 所示。

另外，本實作系統於相同之環境下之計算效率較[2]為佳。

4.10 其它系統的驗證

本研究除對[2]所提供的人力資源系統進行自動化未調整功能點計算外，也針對[6]

所提出之五個不同的系統及[7]所提出的之系統，合計六個系統進行未調整功能點之估算，茲將驗證後之結果進行說明：

系統 [6]估算結果

[2]估算結果

以本系統之 ER-DFD 未調整功能點估算結果

W 77 77 77

M 40 40 40

C 49 49 49

LC 56 56 56 LS 31 31 26 Supspo N/A 254 254 表 4-16 實作結果

其中，W、M、C、LC、LS 來自於[6]；Supspo 來自於[7]。

(37)

在總未調整功能點，三者所產出之結果相同，但細部結果仍有差異(唯有 ls 系統因依照 IFPUG 標準進行系統界線延伸因而總未調整功能點產生差異)，這是因為功能點分析法允許各個估算要項之複雜度存在誤差，誤差範圍可參考表 2-1～表

2-5。但若是因為在識別規則的採用或是在設計規格的表示上未遵守 IFPUG 標準而造成之誤差，則此誤差應是可以避免，雖然於本研究所試驗之系統案例未有顯著差別，但仍存在因不同實作系統對估算相同設計規格圖示，造成不同估算結果的潛在威脅性。故本研究對於此種類型所造成在功能點分析法上五大要項及其複雜度估算的誤差，仍予以探討。

壹、 W 系統：

一. [6]以人工計算之方式識別出 3 個內部邏輯檔案，分別為{customer} , {item}

及{place}。[6]對於 W 系統的檔案功能類型於實體關係圖的呈現及交易功能類型對檔案功能類型進行「維護」、「參考」的描述均符合[3]之標準，即「程序維護關聯即是維護關聯所歸屬之實體」。

二. 而本實作研究所採行之 ER-DFD 標準同[3]，並進行未調整功能點計算，

所得到之各個要項結果與[6]相同。

三. 本實作系統採[2]對 W 系統所描述之 ER-DFD 進行未調整功能點計算結

果在部分要項識別產生差異。

{item} {item owns

stored_at}

{item}

表 4-17 本研之 ER-DFD 表 4-18 [2]之 ER-DFD 表 4-19 [6]所識別 W 系統

(38)

ILF 組成元素 (1) 內部邏輯檔案組成元素差異：

如表 4-17、表 4-18、表 4-19 之差異。[2]並未遵照[3]對 ILF 之定義(如表 3-3)，造成[2]在進行實體集合維護時，將資料流指向關聯，而非依照標準將資料流指向關聯所歸屬的實體。潛在的影響即是對外部輸出之 FTR 個數之辨識產生差異，如表

4-20。

(2) 檔案參考個數：表 4-20 列出兩種不同之實體關係圖及專家對於 change_cust 程序，所識別之外部輸入之檔案參考(FTR)個數：

編號

單一程序程序類型

未調整功能點個數

資料項個數

檔案參考個數

程序複雜度 1 本研究結果 change_cust 外部

輸入

3 4 2 low

2 採用[2]之 ERD 結果

change_cust 外部輸入

3 4 1 low

3 [6]計算結果 change_cust 外部輸入

3 4 2 low

表 4-20 不同 ERD 及專家對 W 系統檔案參考個數計算結果之差異透過圖 4-26 進行 FTR 個數計算結果差異原因分析：

{customer}可被識別為 ILF，而{owns}無法被識別為不同之 ILF，故{customer、owns}

被識別為包含{customer}之實體集合，故該實體集合僅能識別為 1 個 ILF，因此

{customer}、{item}分別被識別為不同之 ILF，故{customer,item}被識別為含有兩個 ILF 之實體集合。因此 change_cust 之檔案參考個數即為 2。

(39)

change_cust 之檔案參考個數即為 1。

圖 4-26 不同 ERD 對 W 系統之 change_cust 維護相關元素示意圖

圖 4-26(左)change_cust 程序維護之元素集合為{customer,owns}，發現該集合僅包含{customer} ILF，故該 ER-DFD 圖之 change_cust 程序之 FTR 個數為 1。

而圖 4-26(右)為本研究所採用之 ER-DFD，change_cust 程序維護之元素集合為{customer,item}，該集合包含{customer} , {item}兩個不同之 ILF，故該

change_cust 程序之 FTR 個數為 2，同[6]計算結果。

所有外部輸入對 W 系統所維護之實體集合參考附錄 14、附錄 15。

本研究於 C、LC 及 Supspo 系統也因內部邏輯檔案組成元素之差異而造成部分程序之檔案參考個數之識別造成差異。

贰、M 系統：與 W 系統不同之處為，其不包括 customer 實體，由 M 系統內的程序與資料的互動，共識別出 2 個 ILF 分別為{item}與{place}，下表僅列出不同實

體關係圖與專家三者對於內部邏輯檔案組成元素有差異者：

{item} {item stored_at}

{item}

表 4-21 本研究之 ER-DFD

表 4-22 [2]之 ER-DFD 表 4-23 [6]識別 M 系統 ILF 組成元素

本研究對於此系統之內部邏輯檔案{Item}所識別出之資料項個數為 5，與[2][6]

所識別出之資料項為 6 有差異，原因在於 M 系統 item 某一個屬性是提供給 W 系統所使用，並未於於 M 系統內對該屬性進行使用，故依照[3]對資料項之識別規則不應列入計算。示意圖如圖 3-10。，此種情況也於 C 系統發生。

M 系統所有程序所維護之實體集合均可完整被識別為內部邏輯檔案，而未出現實

(40)

體集合之子集合包含其它內部邏輯檔案另外剩餘之實體未能識別為內部邏輯檔案之情況。故未有程序之檔案參考個數之識別產生誤差。

當[2]之 ER-DFD 發生上述狀況，而本研究所使用之 ER-DFD 卻無此情況時，

兩者外部輸入之檔案參考個數集會產生差異(如圖 4-26)。這是因為自動化估算系統使用官方標準之識別規則會將[2]之 ER-DFD 之關聯(relationship)視為實體(但

IFPUG 標準對關聯之定義為：關聯應為實體之屬性)。在自動化計算系統採用官方之識別規則下將[2]之 ER-DFD 之關聯視為獨立實體所致。若該關聯無法如同標準 ER-DFD 之實體被識別為另一個不同之內部邏輯檔案(ILF)，則對外部輸入之檔案參考(FTR)個數即會造成影響。

叁、LS 系統

LS 系統：[6]與[2]將 LS 系統之 item 視為外部介面檔案。故系統共識別出 1 個 ILF(即{place})。而本研究依照[3]之標準(如圖 4-28)進行系統界線延伸將 item 視為內部邏輯檔案。

[6]將 LS 系統之 item 視為外部介面檔案採如下觀點：

1.LS

系統並不維護

item

檔案，但系統存在某些程序參考

item

檔案。

而[6]對 LS 系統之 change_place 程序之描述，必須要進行以下動作(如圖 4-27)：

2.

當

change_place

程序更新

Place

，若該

Location

屬性改變，則所有

item

之

location

屬性也要隨之更新。

上述觀點 2 意味著 change_place 必須對 item 之外部鍵(即 location)進行維護，與觀

(41)

點 1 矛盾，同時也與[2]對外部介面檔案之定義產生衝突，IFPUG CPM 建議應調整系統界線，將 Item 視為內部邏輯檔案。

圖 4-27 LS 系統 change_place 程序示意圖

根據[3]對於兩個系統之間之共用資料計數(Counting Data Shared Between

Systems)所提出之未調整功能點計算原則(如圖 4-28)：當 File X 位於系統界線 (system boundary)外時，而又必須對 File X 進行維護，此時則必須將系統界線進行延伸(Boundary Extendend)以包含 File X。原因為僅位於系統界線內之檔案才能進行維護。換句話說，透過界線延伸可將 File X 轉化為 ILF。本研究根據以上觀點，認為 LS 系統之系統界線應延伸如圖 4-29：

圖 4-28 兩系統更新共用資料示意圖

item stored_at place

description pallets value storage_date location

location space

change_place

location,space location

EIF ILF

(42)

圖 4-29 LS 系統界線延伸示意圖

本研究將 Item 視為內部邏輯檔案，與[6][2]之差異在於外部介面檔案所差異之 5 個功能點，另外，若有程序(如 change_place、delete_place 及 query_stored_items) 對外部介面檔案進行參考所需計算之檔案參考(FTR)個數，本研究由於將 item 視為內部邏輯檔案，因此針對以上程序(change_place、delete_place 及

query_stored_items)之檔案參考個數均會減少 1 個。

使用本研究之 ER-DFD 進行未調整功能點之計算，首先必須按照 IFPUG CPM

4.2.1 之建議進行外部鍵歸屬，外部鍵歸屬前後最大之差異為將某個關聯歸屬於某個特定之實體，導致而必須將原本指向該關聯之資料流必須將資料流變更為指向該關聯所歸屬之實體，若該實體已被識別為 ILF，則原程序之 FTR 個數在歸屬前後便會產生差異。這也代表著，進行外部鍵之歸屬可以提高預估該系統之未調整功能點之準確性，原因為日後進行於資料庫進行實際表格建立也必須明確地將外部鍵歸屬於所屬之資料庫表格。

item stored_at place

description pallets

value storage_date name

location

location space