1. 系統理(lǐ)論
根據波爾丁氏(Kenneth E. Boulding)的通用(yòng)系統理(lǐ)論：任何系統分(fēn)為(wèi)靜态結構系統、簡單動态系統、控制機構或自動操作(zuò)系統、開放系統、原生社會系統、動物(wù)系統、人類系統、人類社會層級及超越系統層級由内而外共九種層級；每一層級均有(yǒu)其特殊功能(néng)而且外層系統包含有(yǒu)其内層系統，而且具(jù)有(yǒu)内層所沒有(yǒu)的特性。
根據系統特性可(kě)區(qū)分(fēn)為(wèi)封閉系統與開放系統兩大類；各類系統都由靜态系統與動态系統均衡的關系組成，現代信息系統的進步都是架構在這些理(lǐ)論基礎上建立。
軟件工(gōng)程的研究與發展，從傳統的結構化系統分(fēn)析設計方法建置系統，演變到對象導向分(fēn)析設計建置系統。無疑的都是在嘗試與尋找，如何用(yòng)最有(yǒu)系統與最有(yǒu)效率的方法，在複雜的計算機邏輯運算世界與捉摸不定的使用(yòng)需求中(zhōng)，去建置一套應用(yòng)系統。
然而從軟件公(gōng)司所經驗的軟件開發過程中(zhōng)得知，軟件一直無法做到像硬件般，運用(yòng)模塊化設計，能(néng)夠利用(yòng)大量生産(chǎn)，帶來人力與時間成本降低。且軟件制作(zuò)内容，仍然過于偏重個人的設計技(jì )巧與藝術，軟件人才的去留，深深影響着軟件的生命。
一個共同推論是，硬件的制程技(jì )術觀念可(kě)引用(yòng)在軟件開發上，比照硬件零件組裝(zhuāng)之軟件工(gōng)廠概念已在技(jì )術的标準上，達到某種程度的成就。OMG組織所定義的CORBA軟件組件标準就是系統開發産(chǎn)出過程中(zhōng)零件與運作(zuò)平台的标準。引用(yòng)零件的觀念，再用(yòng)與組裝(zhuāng)的技(jì )術才能(néng)實現出它的成效。零件本身可(kě)以經由外包或采購(gòu)，達到半成品的再用(yòng)。在市場機制運作(zuò)下，您都可(kě)以用(yòng)最實惠的價格取得市場上曆煉後最優秀的軟件組件植入您的系統。透過有(yǒu)效的軟件組件組裝(zhuāng)制程技(jì )術，可(kě)以在最短的時間内開發出系統。且由于系統開發走向标準化，軟件人員的技(jì )術技(jì )巧，将大部份展現于軟件組件本身，系統結構本身則因标準化得以定型。爾後軟件的維護工(gōng)作(zuò)可(kě)能(néng)就如同修車(chē)般，隻需更換零件或維修配件即可(kě)。
本文(wén)主要目的即在闡述傳統結構式系統分(fēn)析與設計及組件式系統分(fēn)析設計與開發進行開發應用(yòng)系統過程中(zhōng)之标準與工(gōng)作(zuò)指引，使軟件組件在開發過程中(zhōng)有(yǒu)所依循，開發後得以在規則的模式下運作(zuò)。組件标準與組件運作(zuò)平台采Microsoft DCOM标準，系統采多(duō)層式架構設計同Microsoft DNA(Distributed interNet Applications Architecture)架構。
2. 傳統結構化軟件系統分(fēn)析與設計
2.1. 系統發展(Development)
系統發展分(fēn)為(wèi)規劃(Planning)、設計(Design)和實施(Implementation)。須考慮未來資料量增加、企業的成長(cháng)與擴充、科(kē)技(jì )的進步與系統整合性以便設計一個有(yǒu)彈性、可(kě)動态調整且易于維護的系統。
系統的三大基本要素：
1. 輸入(Input Data)
2. 處理(lǐ)與控制(Process Logic & Control)
3. 輸出(Output Information)
系統規劃通常采用(yòng)由上而下的作(zuò)業方式，其做法先從整體(tǐ)企業目标開始，探讨企業營運特性，企業組織建立關系，數據處理(lǐ)應用(yòng)邏輯，達到信息系統架構建立完成檔案設計工(gōng)作(zuò)。而信息管理(lǐ)的順序卻是與前相反由個别檔案資料的輸入一直到達成企業營運目标為(wèi)止。
2.1.1.系統規劃(Planning)：
系統要做什麽(What)?
初步研究：定義問題的範圍與建立系統可(kě)以解決問題、滿足需求、運用(yòng)新(xīn)科(kē)技(jì )、增加系統效能(néng)。
可(kě)行性研究：定義問題需求範圍、搜集資料、組織管理(lǐ)者與使用(yòng)者需求。訂立階段計劃、訂立組織人力計劃、訂立推動計劃、訂立維護管理(lǐ)計劃、訂立教育訓練計劃、訂立文(wén)件制作(zuò)計劃、訂立經費計劃、訂立其它配合措施。
2.1.2.系統分(fēn)析(System Analysis)
系統分(fēn)析，系利用(yòng)系統方法或技(jì )術，建立系統觀念性架構，探讨研究問題的特性，并提出具(jù)體(tǐ)和可(kě)行性方案的實際過程。廣義定義為(wèi)一種有(yǒu)組織的方式來解決問題，達成目的。是一門研究如何建立系統來解決問題的科(kē)學(xué)。
系統分(fēn)析的運作(zuò)結果，是由資料的輸入，經過組合與處理(lǐ)，而輸出有(yǒu)意義的信息，提供與輔助管理(lǐ)者進行決策。
良好系統具(jù)備的特性：整合性(Integertion)、使用(yòng)者易操作(zuò)性、管理(lǐ)能(néng)力強性、實用(yòng)性、資料量處理(lǐ)需求、符合組織風格、達成最大成本效益、考量使用(yòng)人員因素、結合外在科(kē)技(jì )、法規、經濟、社會等因素、彈性的組織變更及企業成長(cháng)需求。
系統分(fēn)析師(System Analyst)為(wèi)運用(yòng)各項分(fēn)析工(gōng)具(jù)，整理(lǐ)所獲得的信息，找出一個最适合的方法解決問題的人員。須具(jù)備專業知識的能(néng)力，對系統的輸、出入與處理(lǐ)的軟、硬件與對數據庫的特性知識深入了解，也具(jù)有(yǒu)程序設計撰寫的能(néng)力，同時要具(jù)有(yǒu)系統企業領域知識(如财務(wù)、貿易、生産(chǎn)制造等)。
在規劃中(zhōng)由需求訪談，可(kě)以獲得管理(lǐ)者與使用(yòng)者的各項企業行為(wèi)需求與組織問題的特征與本質(zhì)，了解決策者訊息需求的關鍵性信息及優先級。由企業診斷可(kě)以獲知現行系統的作(zuò)業程序與運作(zuò)狀況，找出現行系統不足所在及未來需求的擴充性，了解問題發生的原因與理(lǐ)由，進行企業的改造(BPR)。再由需求訪談與企業診斷結果進行提出各種可(kě)行性分(fēn)析與研究報告，提出改善現行系統方案與解決各項問題的處理(lǐ)方法。當然各種問題不一定完全可(kě)由計算機系統可(kě)以解決問題，某些部分(fēn)需要靠組織變革、組織章程變更及流程改造來解決問題。
2.1.3.可(kě)行性分(fēn)析
可(kě)行性分(fēn)析報告要獲得高層管理(lǐ)人員支持，定義明确的問題描述與确認的目标方向，講求實事求是的效果，正确的評估所需資源，最佳生産(chǎn)品質(zhì)，選擇适當的信息科(kē)技(jì )與設備。在可(kě)行性目标上還要對系統中(zhōng)要求彈性與可(kě)維護性(Flexibility & Maintainability)，時程與成本(Schedule & Cost)，效率(Efficiency)，實時響應(Quick Response)，整合性(Integration)，安(ān)全性(Security)，可(kě)靠性(Reliability)，簡易性(Simplicity)，兼容性(Compatibility)。
可(kě)行性研究建議案提出方式：
1. 提出最佳方案的二元建議方式(Binary recommendations)。
2. 提出多(duō)個方案進行假設不同與說明選擇的假設建議方式(Choose recommendations)。
3. 依據成本考量系統彈性反映速度維護容易等因素各與加權做量化分(fēn)數的價值建議方式(Value recommendations)
系統分(fēn)析工(gōng)具(jù)(一幅圖畫勝過千言萬語)。将系統所需處理(lǐ)步驟使用(yòng)流程圖(Flowchart)表現。
1. 流程圖(Flow Char)：以邏輯圖标處理(lǐ)過程，表示作(zuò)業每一個步驟以足以表示特性的符号來代表。繪制原則：由上而下，由左而右；圖标明确，工(gōng)作(zuò)起始确定明白，每一個步驟動作(zuò)描述清楚，排好各種工(gōng)作(zuò)順序，流程工(gōng)作(zuò)範圍清楚，分(fēn)支要用(yòng)連接符号表示，使用(yòng)标準的流程圖符号。
2. 系統流程圖(System Flow Chart)：繪制系統整體(tǐ)工(gōng)作(zuò)流程者稱之為(wèi)系統流程圖。
3. 功能(néng)流程圖(Functional Flow Diagrams)：繪制組織間各個作(zuò)業間資料流動的關系。
4. 數據流程圖(Data Flow Diagrams)：繪制數據間數據的儲存、轉換、流程與輸出、入。
5. 文(wén)件流程圖(Paperwork Flow Chart)：繪制系統中(zhōng)各類文(wén)件或表格産(chǎn)生及紀錄其流動的情形。
6. 程序流程圖(Process Flow Chart)：繪制一個系統中(zhōng)各個工(gōng)作(zuò)的程序與步驟。
7. 甘特圖(Gantt Chart)：用(yòng)以繪制表現工(gōng)作(zuò)排程進度，以時間做中(zhōng)心，一般用(yòng)于項目的規劃及階段性排程。
8. 組織圖(Organization Diagram)：用(yòng)以表現組織内各部門功能(néng)間的關系與各組織間從屬關系，包含組織的名(míng)稱與部門間關系與組織各成員信息。
9. 數據字典(Data Dictionary)：定義各種資料的說明，使得數據流程圖(DFD)更易于閱讀。
系統設計(System design)結合執行活動工(gōng)作(zuò)程序與設備資源來完成系統使用(yòng)者所要求的目标，可(kě)以令系統達到最大、最佳、與滿足需求的功能(néng)。考慮每一個獨立程序的随機關系-與其它程序間産(chǎn)生互動的關系、循序關系-各程序間的前後順序關系和時間關系-各程序在不同時間期間所存在的關系。
2.2. 系統設計(Design)
如何完成這一個系統(How)?
系統大體(tǐ)設計：依據系統需求、系統功能(néng)來定義系統的輸入、輸出與處理(lǐ)程序。
系統細部設計：依據大體(tǐ)設計定義輸入規格輸出規格與處理(lǐ)程序規格。
進行程序撰寫與設計。
進行程序的測試與正确性。
2.2.1.結構化設計(Structure Design)
結構化設計(Structure Design)采用(yòng)由上而下漸進且合乎邏輯思維的方式進行設計，建立起層次關系的結構，細分(fēn)各層的問題逐一探讨解決其問題的設計模式。
資料輸入方式的決定考量是采用(yòng)批次性輸入(Batch Input)，還是采用(yòng)實時性輸入(Online Input)，一般常态異動式日常作(zuò)業大都采用(yòng)實時性輸入方式，進行統計或結帳式作(zuò)業可(kě)采用(yòng)批次性輸入方式。
編碼設計：制定編碼原則，采用(yòng)數字、文(wén)字、文(wén)數字或符号；主鍵(Prime Key)唯一鍵值的規劃設計，采用(yòng)循序鍵或存取鍵，關聯鍵值的規劃設計，索引鍵值或複合索引鍵值(Index Key)的規劃設計，編碼長(cháng)度，避免混淆字形，同音異字等。
資料輸出的設計，精(jīng)确、時效與适切性，窗體(tǐ)的設計，考量用(yòng)紙大小(xiǎo)、份數、傳遞方式、顔色、字體(tǐ)大小(xiǎo)、主标題說明、次标題說明、編号方式、分(fēn)頁(yè)考量、頁(yè)首信息、頁(yè)尾信息、上下左右空間關系、複寫字段功能(néng)、打印機功能(néng)與格式。圖表的設計，圖形特性選擇、表現方式、顔色或條紋區(qū)隔、尺标刻度的計算、多(duō)維空間的建立、圖形标示及圖例說明。
成本效益評估：系統使用(yòng)環境考量，網際網絡、局域網絡、企業網絡、單機使用(yòng)等；使用(yòng)硬設備的成本考量，服務(wù)器、終端計算機、個人計算機、備份設備、安(ān)全機制與管理(lǐ)；軟件工(gōng)具(jù)的成本考量，工(gōng)具(jù)軟件、應用(yòng)軟件、數據庫軟件、操作(zuò)系統；維護管理(lǐ)的成本考量，訓練使用(yòng)、維護費用(yòng)、管理(lǐ)人員薪資、更新(xīn)版本費用(yòng)等等。透過計劃需求書(RFP Request for Proposal)提出所需系統的軟硬件信息需求，具(jù)備有(yǒu)功能(néng)需求規格，評估程序與建議，各項軟硬件及廠商(shāng)的介紹與說明。考量硬件的兼容性、成本、可(kě)靠度、普遍性；軟件的适用(yòng)性、成本、品質(zhì)；廠商(shāng)的經驗與規模、技(jì )術能(néng)力、人員素質(zhì)、财務(wù)狀況、教育與訓練、服務(wù)滿意度等等。分(fēn)析系統的顧問咨詢成本，期初建置成本，轉換成本，每期維護成本，後續發展成本，操作(zuò)使用(yòng)成本，教育訓練成本，初期評估成本等等。
2.3. 實施(Implementation)
系統安(ān)裝(zhuāng)與使用(yòng)訓練
系統實施
1. 系統環境安(ān)裝(zhuāng)
2. 使用(yòng)手冊
1. 系統簡介
2. 軟硬件配備要求。
3. 功能(néng)特色說明。
4. 功能(néng)畫面使用(yòng)指引與說明。
5. 常見應用(yòng)範例說明。
6. 常見問題回答(dá)。
3. 應用(yòng)系統建置
循序式檔案(Sequential files)、索引循序式檔案(Index Sequential files)、直接存取式檔案(Random access files/Direct access files)和
分(fēn)割式檔案(Partitioned files)。
4. 系統上線(xiàn)轉換
1. 直接轉換(Direct Conversion)或稱一次轉換：直接使用(yòng)新(xīn)系統。
2. 并行轉換(Parallel Conversion)：新(xīn)舊系統并行一段時間後，再更換成新(xīn)系統。
3. 模塊轉換(Modular Conversion)：依照模塊間關系逐個模塊進行替換成新(xīn)系統。
4. 漸層轉換(Phase in)：和模塊轉換很(hěn)像，但具(jù)有(yǒu)新(xīn)舊轉換接口同時承接舊系統信息，對新(xīn)系統而言增加許多(duō)負擔，但對于使用(yòng)者确可(kě)不間斷及變動舊有(yǒu)所有(yǒu)作(zuò)業。
3. 組件式軟件系統分(fēn)析與設計
3.1. 組件分(fēn)析方式
對象導向系統分(fēn)析設計方法是一套以重複使用(yòng)為(wèi)基礎的系統分(fēn)析、設計及程序制作(zuò)一氣呵成的方法，
對象導向技(jì )術的觀點來看，我們認為(wèi)所要模塑的真實世界是由對象所組成的，真實世界的運作(zuò)是由個對象成員之間的互動而成，因此先天上用(yòng)這樣方法去模塑真實世界将比用(yòng)結構化方法來的穩定，而且在與客戶交談時也比較容易得到客戶的認同，因為(wèi)我們所談的是客戶心中(zhōng)的真實世界，而抽象的方式就功能(néng)面來探讨模塑系統。
現今各式各樣的對象導向分(fēn)析(OOA)，目前較著名(míng)的方法理(lǐ)有(yǒu)Object Modeling、Technique、Booch Method、Function/Mellor Method及Use Case等等。這些方法除了Use Case以外，其它的方法大體(tǐ)上都是對象模型（Object Modeling）為(wèi)主，再輔以動态模型（Dynamic Model）及功能(néng)模型。其中(zhōng)對象模型是用(yòng)來述真實世界的靜态關系，所談的内容是對象．對象及對象之間的關系，如組成關系、繼丞關系或其它各式關系。
動态模型通常是描述系統動态行為(wèi)，所談的内容通常先用(yòng)腳本（Scenario）描述物(wù)作(zuò)對外界刺激的反應及各對象之間的動關系,并用(yòng)事件追蹤圖(Event Trace Diagram)追縱各個對象之間的動态行為(wèi)，或用(yòng)态圖描述單一對象對外界刺激的反應。功能(néng)模型則用(yòng)功能(néng)觀點來看系統，與傳統的結構化方法的DFD相同。
分(fēn)析階段描述系統要做什麽，設計階段考慮如何才能(néng)滿足客戶的需求。
第一階段是需求收集階段，我們利用(yòng)使用(yòng)個案進行需求搜集工(gōng)具(jù)。
第二階段是系統分(fēn)析階段，依據第一階段的使用(yòng)個案依據原則找出可(kě)能(néng)的類别，再用(yòng)一套篩選原則找出适合的原則，利用(yòng)對象圖進行系統的領域模型及應用(yòng)程序塑模工(gōng)作(zuò)，以使用(yòng)狀态圖來描素系統的動态行為(wèi)。
第三階段是系統架構設計，考慮整個架構設計，如何分(fēn)割系統，使用(yòng)整體(tǐ)運作(zuò)能(néng)夠顧慮到結構性、執行效率與擴充性等，此時可(kě)産(chǎn)出商(shāng)業對象(Business Object)、應用(yòng)程序對象與技(jì )術對象等。
第四階段為(wèi)設計階段，考慮如何設計系統接口，如何将對象圖對應到數據庫上，如何設計所需的算法，如何選用(yòng)可(kě)再用(yòng)的對象等等。
第五階段可(kě)依據第一階段的使用(yòng)個案進行程序測試個案制作(zuò)。
第六階段将使用(yòng)個案的測試結果結合系統架構設計可(kě)以編制成使用(yòng)手冊，符合再用(yòng)的需求。
運用(yòng)CASE工(gōng)具(jù)UML(Unify Modeling Language)，結合了Use Case，OMT和Booch Method三者的精(jīng)華成為(wèi)設計分(fēn)析更好的方法。
使用(yòng)組件再用(yòng)模版之優點
提供多(duō)樣化的客戶端選擇，如Internet BUI(Browser User Interface)或是Windows GUI(Graphics User Interface)。可(kě)透過Internet由遠(yuǎn)程使用(yòng)系統，使用(yòng)彈性度大，不受空間與時間限制；充份運用(yòng)Internet降低聯機成本；軟件組件同時提供ActiveX使系統執行于局域網絡，與DCOM版本使系統執行于廣域網絡；使用(yòng)者可(kě)透過參數化的系統設定，讓系統容易維護、調整與使用(yòng)；系統由組件組裝(zhuāng)而成，易于與其它組件化系統整合；進行跨地域性的信息整合，并且縮短信息撷取時程，提升企業競争力；資料維護方式，簡單易維護；報表查詢方式，迅速易調整；業務(wù)交易方式，彈性易擴增。組件再用(yòng)，軟件量産(chǎn)。
3.3. 組件化應用(yòng)系統架構
3.3.1.多(duō)層式組件化應用(yòng)軟件開發平台 (eMAX Framework)建構
應用(yòng)系統架構：為(wèi)支持組織特定功能(néng)之信息系統(OrgManager)，而應用(yòng)系統架構則為(wèi)協助提供組織所需信息之應用(yòng)系統模式，他(tā)顯示了應用(yòng)系統、資料與其相互關系，依據業務(wù)作(zuò)業模式界定出組織未來計算機作(zuò)業之功能(néng)與範圍，以作(zuò)為(wèi)設定系統發展優先級之基礎。應分(fēn)析現行信息系統之功能(néng)與數據文(wén)件，考慮應用(yòng)系統架構的可(kě)行性，以免重複開發應用(yòng)系統而浪費人力與物(wù)力。應用(yòng)系統建構要求：
1. 系統是屬于多(duō)層式軟件架構(Muti-Tier)，将軟件予以切割成展現層(View Layer)、網絡層(Net Layer)、處理(lǐ)層(Control Layer)、分(fēn)封層(Encapsulation Layer)與資料層(Data Layer)。
2. 系統可(kě)運作(zuò)于多(duō)層次(Muti-Tier)的硬件環境中(zhōng)，建置多(duō)形網絡結構如：展示層、控制層、資料層透過局域網絡連結。展示層透過網際網絡與控制層、資料層連結。展示層、控制層透過網際網絡與資料層連結。
3. 系統可(kě)于網際網絡(Internet)下運作(zuò)。
4. 系統是由軟件組件組裝(zhuāng)而成
5. 系統是開放性架構(Open System)提供業務(wù)組件随插即用(yòng)，窗口圖形使用(yòng)者接口(Graphic User Interface)與浏覽器接口(Browser)。View Manager是窗口畫面的編輯器，它内建的組件綱要信息(Meta Information)能(néng)力，可(kě)以讓所有(yǒu)産(chǎn)生的作(zuò)業畫面在不經過編譯(Compile)的情形下，随編即用(yòng)。
6. Web Manager是網頁(yè)畫面編輯器，則是透過數據庫的資料綱要機制，以最快速的方式自動産(chǎn)生ASP、XML、XSL等檔案，讓網頁(yè)可(kě)以很(hěn)容易的連結到應用(yòng)邏輯層中(zhōng)的作(zuò)業組件。
7. 其支持多(duō)國(guó)、多(duō)點、多(duō)公(gōng)司、多(duō)語言、多(duō)單位、多(duō)币别及多(duō)網域、多(duō)服務(wù)器等應用(yòng)系統在架構面及使用(yòng)面的複雜需求，同時也支持網際網絡B2B、B2C電(diàn)子商(shāng)務(wù)交易、異步資料更新(xīn)遠(yuǎn)程資料存取及工(gōng)作(zuò)流程(Work Flow)管理(lǐ)等應用(yòng)面的延伸需求，而在客戶導向的e世代裏如何面對快速變遷的使用(yòng)者需求，eMAX Framework提供了動态企業塑型(DEM Dynamic Enterprise Modeling)能(néng)力，讓使用(yòng)者可(kě)以很(hěn)容易的動态調整或産(chǎn)生報表、企業邏輯、操作(zuò)畫面及程序，甚至可(kě)以完全不必透過軟件商(shāng)廠，即完成客制化的目的。
3.3.2.eMAX Framework的驅動引擎：
eMAX Framework目前提供了三個可(kě)以同時并存的驅動引擎：
1. AcroFrame：
負責上述多(duō)層式組件化應用(yòng)系統架構的建置及運作(zuò)，應用(yòng)系統的激活程序是eMAX.exe。
2. AcroBrowser：
是一個可(kě)以從浏覽器下載并自動安(ān)裝(zhuāng)的組件，它取代了AcroFrame中(zhōng)的激活程序eMAX.exe。使用(yòng)者可(kě)以直接透過浏覽器執行在AcroFrame中(zhōng)設計好的應用(yòng)系統，無需再安(ān)裝(zhuāng)任何其它客戶端程序。
3. AcroWorkFlow：
是一個工(gōng)作(zuò)流程引擎，包括Server Agent、Worklist Agent、Instance Agent，可(kě)以将AcroFrame中(zhōng)的應用(yòng)作(zuò)業如訂單作(zuò)業循環、采購(gòu)作(zuò)業循環等由人工(gōng)驅動改為(wèi)流程驅動。由于是多(duō)層式組件化的應用(yòng)系統架構，無需因為(wèi)架設了工(gōng)作(zuò)流程引擎而重新(xīn)設計應用(yòng)程序。
3.3.3.領域分(fēn)析
領域工(gōng)程主要目的即在于可(kě)再用(yòng)性，包含了軟件設計架構的再用(yòng)、軟件開發流程的再用(yòng)、文(wén)件的再用(yòng)及領域知識的再用(yòng)。
随着軟件的應用(yòng)與企業的經營越來越緊密，為(wèi)了提身企業的競争力，必須可(kě)實時反映政府的法規，提供市場的需求服務(wù)性，增加企業的安(ān)全性，提供實時的多(duō)樣化的分(fēn)析，滿足企業集中(zhōng)式與多(duō)點多(duō)廠分(fēn)布式的管理(lǐ)需求，彈性功能(néng)增加即最小(xiǎo)變動達成功能(néng)的特性，随插即用(yòng)的技(jì )術成熟，以對象導向技(jì )術開發的軟件組件技(jì )術機制因此而生。
領域工(gōng)程方法進行領域分(fēn)析、制定領域架構規格、實做出領域組件、制定領域再用(yòng)程序規格、維護及修正擴充領域組件。
對象導向設計(OOP)的目的其實就是将對象導向分(fēn)析出來的對象與對象間的互動方式，用(yòng)程序設計出來，最重要的是将對象的類别(Class)撰寫出來，然後将個體(tǐ)間互動方式利用(yòng)對象及其方法撰寫出來，如此即可(kě)完成一個應用(yòng)系統。
eMAX領域範圍包含企業資源規劃系統(eERP)、電(diàn)子商(shāng)店(diàn)系統(eStore)、電(diàn)子商(shāng)城系統(eMall)以及電(diàn)子聯盟系統(eAlliance)等。eERP的應用(yòng)範圍包含配銷、生産(chǎn)、财務(wù)管理(lǐ)及企業決策等領域，其可(kě)滿足多(duō)組織企業内庫存、采購(gòu)(包含進口)、銷售(包含出口)、生産(chǎn)、物(wù)料需求、産(chǎn)能(néng)規劃、财務(wù)、會計以及主管決策等管理(lǐ)領域的需求。eStore和eMall則為(wèi)B2C最佳解決方案。至于eAlliance則可(kě)滿足企業B2B的需求。
依據業務(wù)需求進行可(kě)行性分(fēn)析
1. 技(jì )術可(kě)行性(Technical Feasibility)
2. 經濟可(kě)行性(Economic Feasibility)
3. 推動可(kě)行性(Motivational Feasibility)
4. 時程可(kě)行性(Schedule Feasibility)
5. 操作(zuò)可(kě)行性(Operation Feasibility)
應用(yòng)分(fēn)析項目
1. 響應時間
2. 危機時間(可(kě)容忍時間)
3. 使用(yòng)率
4. 使用(yòng)者數
5. 複雜度
6. 一緻性
資料實體(tǐ)分(fēn)析項目
1. 時效性
2. 分(fēn)割性
3. 必要性
4. 變動性
5. 共享性
6. 安(ān)全性(AuthorityManager)
3.3.4.應用(yòng)系統架構(Application Architecture)
為(wèi)了讓組件得以在一定的規則下運作(zuò)，特針對信息管理(lǐ)系統三大應用(yòng)範圍将組件運作(zuò)架構加以定義:
(1)基本資料維護類:統歸一般性基本資料如員工(gōng)，公(gōng)司，部門等資料之基本資料之新(xīn)增，删除，修改，查詢，停用(yòng)，複用(yòng)功能(néng)均規于此類。系統可(kě)開發DM(DataMaintenance)組件統籌基本資料維護工(gōng)作(zuò)，其中(zhōng)搭配Table Manager及DataDictionaryManager組件工(gōng)具(jù)負責掌握數據域位，型态，欄寬與多(duō)語言控制;搭配TM(TransactionManager)組件負責将SQL指令執行于指定的數據庫。數據維護邏輯：
1. 取得數據域位，型态，欄寬等綱要信息。
2. 顯示編輯窗口。
3. 使用(yòng)者由編輯窗口輸入資料，或以泛查輸入。
4. 系統檢視輸入資料。
5. 依作(zuò)業動作(zuò)取得SQL指令公(gōng)式，并鎖定資料。
6. 結合SQL指令公(gōng)式與輸入之資料取得完整SQL作(zuò)業指令。
7. 執行SQL作(zuò)業指令。
(2)業務(wù)交易類:統歸以填具(jù)單據進行數據庫異動交易者歸于此類。業務(wù)交易邏輯架構經分(fēn)析後可(kě)得，交易單據單頭與單身之數據域位，型态，欄寬。使用(yòng)者輸入單據資料。.将輸入單據資料包裝(zhuāng)成一單據參數封包。依作(zuò)業動作(zuò)取得相關子系統BSO組件。依事務(wù)交易代碼，呼叫相關BPE組件群，依序處理(lǐ)單據參數封包以完成事務(wù)交易。撰寫BPE訂定交易規則流程：
1. 取得單據單頭與單身之數據域位，型态，欄寬等綱要資料。
2. 顯示編輯窗口。
3. 使用(yòng)者輸入單據資料。
4. 系統檢視輸入單據資料。
5. 依作(zuò)業動作(zuò)處理(lǐ)單據參數以完成業務(wù)交易。
(3)報表查詢類:統歸以查詢條件取得數據庫資料以進行資料浏覽，報表打印或轉文(wén)件者均歸為(wèi)此類。系統可(kě)開發QM(QueryManager)組件統籌資料查詢工(gōng)作(zuò)，其中(zhōng)搭配ReportManager組件工(gōng)具(jù)進行報表查詢邏輯架構。設定報表查詢SQL：
1. 取得查詢項目之查詢條件數據域位，型态，欄寬等綱要資料。
2. 使用(yòng)者輸入查詢條件資料。
3. 系統檢視查詢條件資料。
4. 依查詢條件資料進行查詢。
5. 取得查詢結果并顯示。
3.4. 組件開發系統程序
以組件方式開發系統，其程序仍不跳脫需求分(fēn)析，系統分(fēn)析與系統設計三大步驟，隻是多(duō)引用(yòng)了對象導向系統分(fēn)析設計中(zhōng)之循環漸進(Spiral)觀念，随時修正分(fēn)析設計結果，并以各式模版原則組裝(zhuāng)組件以規範組件運作(zuò)。
項目之推行，建議先以開發共通組件，再以領域組件與使用(yòng)接口平行開發方式進行，較能(néng)獲得較佳之人力與時間成本掌控。關于項目的分(fēn)工(gōng)，會較以往容易。當組件規格與組裝(zhuāng)模版底定，組件的開發與使用(yòng)接口的開發便可(kě)分(fēn)頭并行，視适當時間會合組裝(zhuāng)成系統。
項目基本成員，建議以項目經理(lǐ)，系統分(fēn)析師，組件設計師，使用(yòng)界面設計師與數據庫管理(lǐ)師搭配進行。
3.4.1.需求分(fēn)析
領域分(fēn)析
了解與熟悉所開發系統之應用(yòng)範圍。
數據字典(DataDictionaryManager)專門用(yòng)語建立：建立系統開發過程中(zhōng)之标準用(yòng)詞，做為(wèi)爾後系統開發與設計過程中(zhōng)之标準用(yòng)語，此标準用(yòng)語另可(kě)作(zuò)為(wèi)數據庫字段，作(zuò)業畫面之标準用(yòng)詞語。
領域模型
收集與了解領域資料。
記錄專門用(yòng)語。
1.收集系統用(yòng)詞。
2.統一用(yòng)詞。
3.建立标準型别。
4.建立繼承字詞。
5.建立字詞，設定型别與繼承字詞。
6.建立字詞别名(míng)。
與使用(yòng)者訪談，了解所開發系統與相關環境關聯。
繪制領域模型。
使用(yòng)個案分(fēn)析(Use Case)
收集與記錄使用(yòng)者需求。根據使用(yòng)者或客戶之需求描述，使用(yòng)自然的語言來記錄使用(yòng)者期望的狀況，進而了解與分(fēn)析使用(yòng)者的真正需求。
1. 使用(yòng)者訪談。
2. 找出領域使用(yòng)個案。
3. 找出系統使用(yòng)個案。
4. 記錄領域使用(yòng)個案。
5. 記錄系統使用(yòng)個案。
6. 繪制使用(yòng)個案圖。
作(zuò)業畫面分(fēn)析
規範最終使用(yòng)接口之作(zuò)業畫面，以做為(wèi)與使用(yòng)者确認最終産(chǎn)出之依據。
1. 依使用(yòng)個案制作(zuò)作(zuò)業畫面初版。
2. 與使用(yòng)者訪談，搭配使用(yòng)個案，修訂作(zuò)業畫面。
3. 與使用(yòng)者确認作(zuò)業畫面。
3.4.2.系統分(fēn)析
數據庫分(fēn)析(Database)
建立系統數據庫，以儲存系統資料。産(chǎn)出數據庫關聯圖，數據庫，表格。
1. 分(fēn)析資料表格與資料表格關聯。
2. 建立實體(tǐ)數據庫。
3. 建立實體(tǐ)表格，定義字段。
4. 設定數據庫使用(yòng)者，表格使用(yòng)權限。
共通服務(wù)組件(CSO)分(fēn)析
找出系統會使用(yòng)到的共通服務(wù)，并歸納出相關負責組件。産(chǎn)出共通服務(wù)組件清單，共通服務(wù)組件建構管理(lǐ)
1.根據系統使用(yòng)個案，找出共通服務(wù)需求。
2.根據共通服務(wù)需求，依現行架構找出共通服務(wù)組件。
3.拟出共通服務(wù)組件清單。
4.拟出共通服務(wù)組件建構管理(lǐ)。
業務(wù)組件分(fēn)析(BSO Business Service Object，BPE Business Process Edit)
找出系統會使用(yòng)到的業務(wù)服務(wù)，并歸納出相關負責組件。服務(wù)接口由業務(wù)服務(wù)組件(Business Service Component)負責， 服務(wù)項目由業務(wù)處理(lǐ)組件(Business Process Component)提供。産(chǎn)出業務(wù)組件清單，業務(wù)組件建構管理(lǐ)
1. 依作(zuò)業畫面找出所有(yǒu)業務(wù)服務(wù)需求。
2. 依子系統區(qū)分(fēn)，定義業務(wù)服務(wù)組件(BSO)。
3. 依業務(wù)服務(wù)需求定義業務(wù)處理(lǐ)組件(BPE)。
4. 拟出業務(wù)組件清單。
5. 拟出業務(wù)組件建構管理(lǐ)。
3.4.3.系統設計
共通服務(wù)組件(CSO Command Service Object)設計
設計共通服務(wù)組件服務(wù)界面(interface)，産(chǎn)出共通服務(wù)組件技(jì )術規格。
1. 依需求設計共通服務(wù)組件服務(wù)界面。
2. 撰寫共通服務(wù)組件技(jì )術規格。
業務(wù)組件(BSO，BPE)設計
設計業務(wù)服務(wù)組件與業務(wù)處理(lǐ)組件服務(wù)界面(interface)，産(chǎn)出業務(wù)服務(wù)組件技(jì )術規格，業務(wù)處理(lǐ)組件技(jì )術規格。
1. 設計業務(wù)服務(wù)組件與業務(wù)處理(lǐ)組件組件服務(wù)界面
2. 撰寫業務(wù)服務(wù)組件與業務(wù)處理(lǐ)組件組件技(jì )術規格
3.4.4.系統建置
共通函式建置
規範共通函式建構所在，規定引用(yòng)路徑，以進行撰寫共通函式程序讓所有(yǒu)程序引用(yòng)。産(chǎn)出共通函式建置規範，共通函式使用(yòng)手冊。
1. 規定共通函式建構所在路徑。
2. 規定引用(yòng)原則與引用(yòng)設定程序。
3. 傳寫與發布共通函式建置規範。
4. 撰寫共通函式程序。
5. 共通函式測試。
6. 撰寫共通函式使用(yòng)手冊。
共通服務(wù)組件(CSO)建置
規範共通服務(wù)組件設計程序，命名(míng)原則以完成共通服務(wù)組件。産(chǎn)出共通服務(wù)組件發布規範。根據共通服務(wù)組件清單，建置規範與設計規格進行建置，發布共通服務(wù)組件。
業務(wù)組件(BSO，BPE) 建置
規範業務(wù)服務(wù)組件與業務(wù)處理(lǐ)組件設計程序，命名(míng)原則以完成業務(wù)服務(wù)組件與業務(wù)處理(lǐ)組件。産(chǎn)出業務(wù)服務(wù)組件與業務(wù)處理(lǐ)組件發布規範。根據業務(wù)服務(wù)組件與業務(wù)處理(lǐ)組件組件清單，建置規範與設計規格進行建置。發布業務(wù)服務(wù)組件與業務(wù)處理(lǐ)組件組件。
定義業務(wù)作(zuò)業(BPA-Business Process Action)是由那些業務(wù)處理(lǐ)組件(BPO- Business Process Object)的方法(Method)組合而成。自動産(chǎn)生編譯式業務(wù)處理(lǐ)組件的主體(tǐ)程序代碼，并支持直接于作(zuò)業編輯器上用(yòng)不同語言撰寫解譯式業務(wù)處理(lǐ)組件程序代碼。
協力廠商(shāng)組件安(ān)裝(zhuāng)(3rd Party Component)
規範管理(lǐ)所有(yǒu)外購(gòu)組件，讓系統所有(yǒu)程序引用(yòng)。産(chǎn)出外購(gòu)組件安(ān)裝(zhuāng)規定，外購(gòu)組件之合法使用(yòng)文(wén)件，規定外購(gòu)組件建構路徑，規定外購(gòu)組件安(ān)裝(zhuāng)引用(yòng)程序，保存外購(gòu)組件合法使用(yòng)文(wén)件。
主畫面模版建置(System Manager & View Manager)
規範系統主畫面功能(néng)布置與子窗口激活原則，以做為(wèi)程序設計人員依循。主畫面模版技(jì )術指引，決定主畫面運作(zuò)模式，決定主畫面畫面布置，決定子窗口激活方式，使用(yòng)共通服務(wù)組件開發模版窗口與程序叢集，撰寫主畫面模版技(jì )術指引。
GUI模版建置
規範系統内所有(yǒu)基本資料之操作(zuò)模式，所有(yǒu)交易操作(zuò)模式，以做為(wèi)程序設計人員依循。産(chǎn)出基本資料維護作(zuò)業模版技(jì )術指引，分(fēn)析基本資料維護作(zuò)業共通性質(zhì)，使用(yòng)共通服務(wù)組件開發模版窗口與程序叢集，撰寫基本資料維護作(zuò)業模版技(jì )術指引。業務(wù)交易作(zuò)業模版技(jì )術指引，分(fēn)析業務(wù)交易作(zuò)業共通性質(zhì)，使用(yòng)共通服務(wù)組件開發模版窗口與程序叢集，撰寫業務(wù)交易作(zuò)業模版技(jì )術指引。
WEB模版建置
規範系統内網頁(yè)之操作(zuò)模式，透過Web Manager是做網頁(yè)畫面編輯器，透過數據庫的資料綱要機制，自動産(chǎn)生ASP、XML、XSL等檔案。
報表查詢作(zuò)業模版建置
規範系統内所有(yǒu)查詢操作(zuò)模式，以做為(wèi)程序設計人員依循。産(chǎn)出查詢作(zuò)業模版技(jì )術指引，分(fēn)析查詢作(zuò)業共通性質(zhì)，使用(yòng)共通服務(wù)組件開發模版窗口與程序叢集，撰寫查詢作(zuò)業模版技(jì )術指引。
其它作(zuò)業模版建置
視應用(yòng)系統需要，規範系統内所需作(zuò)業之操作(zuò)模式，以做為(wèi)程序設計人員依循。産(chǎn)出其它作(zuò)業模版技(jì )術指引，分(fēn)析其它作(zuò)業共通性質(zhì)，使用(yòng)共通服務(wù)組件開發模版窗口與程序叢集，撰寫其它作(zuò)業模版技(jì )術指引。
3.4.5.系統分(fēn)發
将建置完成的系統，分(fēn)發至使用(yòng)者執行。
安(ān)裝(zhuāng)程序：将所需分(fēn)發的檔案包裝(zhuāng)成安(ān)裝(zhuāng)程序。
1. 測試數據庫是否連通
2. 設定系統參數Registry
3. 安(ān)裝(zhuāng)軟件組件
4. 安(ān)裝(zhuāng)系統主程序
使用(yòng)手冊：
1. 系統簡介
2. 軟硬件配備要求。
3. 功能(néng)特色說明。
4. 功能(néng)畫面使用(yòng)指引與說明。
5. 常見應用(yòng)範例說明。
6. 常見問題回答(dá)。
|
