搜尋

< 返回

物件導向法程序手冊

1. 目的

本文件的目的是說明物件導向法的程序結構，及詳述在進行物件導向法規劃時所涉及的程序。

2. 範圍

本手冊的讀者對象是從事物件導向法計劃的工作人員。它是以物件導向法程序的各個階段作為文件的結構而編寫。就物件導向法每個階段的各個工作項目而編寫的文件，均會載列以下的資訊：

目的
描述
必要條件
成品
指引
技巧
細分工作項目

為方便參考，部分內容摘錄自手冊全文，並在下文加以概述。

3. 物件導向法概覽

物件導向法是一個系統發展方法，鼓勵和協助用戶把電腦系統的軟件組件再次使用。採用這個方法後，電腦系統能夠以組件作為基礎進行發展，有助用戶有效地把現有的組件再次使用，及協助把系統的組件與其他系統共用。採用物件導向法可提高生產力、減少維修費用和獲得更佳品質。

物件導向法生命周期由六個階段組成。這些階段計有：

業務規劃階段；
業務體系結構定義階段；
技術體系結構定義階段；
遞增交付規劃階段；
遞增設計和建設階段；及
設置階段。

3.1 業務規劃

在業務規劃階段，業務的管方和用戶通常會舉行一系列的會議和研討會。這些會議會制定彼此達成共識的目標、範圍和用戶需求，以及開始發展程序及評估發展計劃的可行性。

業務規劃的工作項目是：

（a）審查現有環境及制定目標

透過制定系統的目標，計劃推行小組成員和業務用戶可以清楚了解計劃的界限、範圍、相關費用和好處。透過審查以往的研究結果、現有系統和業務的使命，可制定業務方案的主要目標。

（b）確定整體需求

功能需求指系統將提供的功能。這些需求會編寫為需求目錄，編寫方式與在稍後的工作項目內用例載列需求詳情的高層次方式相同。

（c）業務程序模型

業務程序模型是與用戶共同發展的。這模型界定了業務範圍，而建議的業務方案會在這範圍內予以推行，最後投入運作。為與執行業務程序的有關人員舉辦用戶研討會，以討論、了解及編寫所涉及的事件及程序。業務程序模型會展示「將予採用」的程序模型。任何重新設計程序的工作，應該在執行目前這工作項目之前完成。

（d）分析用例

在組件和物件發展方面，用例是電腦系統發展的主要驅動工具。在業務程序模型所說明的程序界定了業務系統，但這些程序並沒有說明電腦系統需求。業務系統與電腦系統需求之間其實互有關連，因此，可能會有一個程序（通常是企業業務程序）是與用例有連結的。這種連結關係提供了電腦發展系統的記錄和結構方面的資料。

業務方案的功能需求會載列在用例內。每個用例說明了系統的一個能夠為用戶提供價值的使用方式。每項功能需求最少會作為一個用例或在最少一個用例內列出。此外，用例圖也會包含與用例業務方案有關的系統執行因素及系統活動者。

（e）開展業務類別模型

這工作項目最好在完成制定用例模型後才開始，因為系統分析人員在制定用例模型時會對計劃領域的知識大幅增加。

這方面的重點需放在於基本的業務類別，即與計劃領域有關的跟物件對應的類別，因為假設這些類別一般會成為資料模型的一個相關實體，並且因而能夠充當一個資料模型規模的基礎。這個資料模型可能包含更多的實體，例如：體現多方面之間的相互關係。

（f）確定可再次使用的組件

這工作項目會與上一個項目同時進行，可避免會對已經存在的現有組件制定類別模型。在這個階段擬定再次使用系統組件的計劃，是以組件為本進行發展的一個重要基礎。

（g）完成可行性研究

如採用結合可行性研究／系統分析和設計階段的方法，便無需進行這項工作。

這工作項目會按照預算的成本和推行的期間完成可行性研究。為資料庫規模的目的，在完成業務體系結構定義階段的「把業務類別與實體配對」的工作項目後，會制定一個所需系統邏輯資料模型。

3.2 業務體系結構定義

業務體系結構定義的重點在於加深了解用戶的需要，及界定一個會符合需要的方案。

在用例中指明的系統需求會予以分析。需用以達成系統功能的組件服務會加以確定。組件服務會透過業務類別的仔細設計和組件之間的合作得以提供。

為從以組件為本的發展中獲得好處，在可重用組件所獲得的服務和這些服務之間互相依賴的關係會加以確定。在進行上述活動時，可同時制定屏幕及報告的原型。

業務體系結構定義的工作項目是：

（a）檢討業務規劃成品

如在業務規劃階段後業務需求有所改變，便需進行這工作項目。可能出現的改變通常視乎業務規劃階段完結後和業務體系結構定義階段開始前的期間而定。這工作項目對於已進行可行性研究（或業務規劃階段）作為一個獨立階段的計劃尤其重要。

（b）原型用戶界面

屏幕原型是一種核實用例的簡報及相關資料輸入／輸出的出色技術，而用戶也會獲得鼓勵參與這項工作，令所完成的方案是一個彼此接受的方案。用戶研討會是一個發展原型的有效機制。

（c）確定待用組件

這工作項目是界定系統所包含的業務體系結構的元素。經確定的組件是邏輯業務組件，並會為此界定組件服務。

組件的確定將主要取決於與業務類別的（靜態）聯繫。待用組件需在較後的工作項目進行時由（動態）交互模型加以核實，因此不會在這個階段作出定論。

（d）組件交互模型

業務組件交互模型與制定原型的工作同時進行，並在確定待用組件之後完成。有關的組件服務會根據用例的功能界定。

這項工作需與「業務類別交互模型」的工作同時進行，因為可加深對組件功能的了解。

（e）業務類別交互模型

物件之間進行交互產生系統的職能。編製業務類別物件順序圖可界定業務類別的各項運作活動。有關的交互可協助分析人員分析業務類別的動態職能。在這個階段，制定模型的工作主要是制定組件內部的模型。

（f）把業務類別與實體配對

如果使用物件資料庫管理系統，類別模型結構和物件資料庫管理系統結構之間應該可直接進行配對，但對於關係資料庫而言則並不是這樣。例如，該類資料庫並不支援繼承結構。關係表格也需要基本和外在的關鍵碼，而類別模型則沒有提供這些關鍵碼。如使用物件資料庫管理系統，必須執行物件的關係轉換，以編製邏輯資料模型。

（g）完成交互模型

前兩個工作項目會產生大量的物件順序圖供計劃推行小組使用。該等物件順序圖的完整性、一貫性和詳細程度必須先予以查核，然後該模型才可進入遞增設計和建設階段。通常可在這階段加入更多的細節。

3.3 技術體系結構定義

技術體系結構定義的活動會與業務體系結構定義階段同時進行。業務體系結構定義的重點在於業務需求，而技術體系結構定義階段郤側重技術和體系結構兩方面。

技術體系結構定義的工作項目是：

（a）確認技術需求

新業務及技術需求既然已經確定，它們對現有系統的基礎建設的影響必須加以確定。如沒有該等基礎建設，則那些應由基礎建設提供的服務便須加以確定，分析和推行。

（b）選擇業界標準方案

就業務功能而言，由個別機構發展的應用系統可能是獨特的，但從技術體系結構的觀點來說，它們並非獨特的系統。要成功發展一個應用系統，關鍵之一是採用業界標準方案、架構和最佳作業實務（如可能）。要選擇正確，必須把對服務的技術需求作出比較；該等服務是由經考慮的體系結構的架構／方案所提供。在選擇過程中，應考慮機構採用的標準。

（c）說明技術系統體系結構

技術系統體系結構對工具、環境和支援應用系統的軟件方案加以界定。為使發展系統的人員有效地共同工作，所選擇的工具須能以整合及一致的方式支援所有不同的技術，而這些技術均是發展該類應用系統所需要的。這項活動集中於把適當的工具和操作平台進行配對；該等工具和操作平台均適合系統的技術需求和機構的標準。

（d）界定技術應用系統體系結構

在進行任何設計和發展活動前，最基本的需求是設立參考模型，供分析人員和開發人員作為方案／組件設計的基礎。技術應用系統體系結構界定如何按職責發展軟件，及對系統內各層職責提供清楚的區分。該等在體系結構層之內的職責稱為「版型」，代表該物件或技術的名稱和目的；「版型」的作用是推行具體的體系結構職責。此外，在推行前先了解將會使用那些技術以處理不同的版型（例如：EJB、Servlets及JSP等），這點亦非常重要。

（e）設計技術服務及模式

在技術系統體系結構的期間內，由於並非所有的技術需求均得到標準方案提供的服務處理，因此有需要設計自訂的技術服務，以應付尚未完成的需求及支援業務組件。

（f）技術體系結構原型

這工作項目包括一個有限的發展計劃，在結構上它是業務體系結構定義及設計和發展周期的總和，但主要差別在於其所支援的「業務」包括應用系統軟件。

（g）完成技術體系結構

在收到業務體系結構小組有關規模的資訊和概念驗證的檢討後，便需完成技術體系結構。

3.4 遞增交付規劃

每個遞增交付成品均包括多個完整的用例。由於每個用例都說明一個可用於系統的方法，因此在獲得調配時便能夠產生價值。基於在業務規劃階段內所發展的用例的優先排序，最重要的用例會首先交付給用戶。

遞增交付規劃的工作項目是：

（a）界定遞增交付成品及推行策略

遞增交付工作可透過編配用例及所需組件至建議的遞增交付成品而加以規劃。有關把具體的用例編配給遞增交付成品的決定，是根據編配給每個遞增交付成品的交付優先次序而作出。優先次序主要是由代表用例的業務價值來衡量。其他因素如用例的複雜性和組件之間的關係，亦應加以考慮。

（b）完成系統分析及設計

這工作項目會完成系統分析和設計的有關活動，並編製系統分析和設計的報告。

3.5 遞增設計和建設

本階段會以業務體系結構定義的最後成品作為出發點。有關組件及其類別會從技術體系結構定義向技術體系結構作出配對，及在其後按表現和可維修性等原因進行優化。

透過使用作為程式編製語言的一部分的類別概念，會令那些經優化的類別得以實現。程式將會接受測試，獲得用戶接受和隨時可供調配。

遞增設計和建設業務的工作項目是：

（a）鞏固體系結構

業務體系結構定義針對問題領域，並提供經界定的業務組件和組件服務，以支援系統的需求。技術體系結構定義則處理基本職責和適用的技術，及提供一套組件和軟件方案的使用模式和原則，以切合具體的技術需求。

（b）設計和發展方案程序

以組件為本的發展程序和模型會有兩方面，即左面（方案程序）和右面（業務組件）。
左面是關於發展在業務組件以外的用例。方案的物件順序圖顯示在程序管制人員左面的交互情況。它涉及確定和增加類別用戶（與用戶界面原型一致），然後發展用戶界面物件和管制物件（例如：程序及界面管制人員物件），及業務組件界面的使用。此外，它也界定進行交易的環境。

（c）設計和發展業務組件

以組件為本的發展程序和模型會有兩方面，即左面（方案程序）和右面（業務組件）。右面是關於發展在業務組件以內的業務組件；該組件是在物件順序圖的業務組件界面的右面。

（d）設計和發展資料服務

把資料庫接達服務「組件化」所具有的好處，與把業務服務「組件化」的好處相同。它有助工作人員在靜態界面工作，因此可在界面後面進行結構變化而不會對界面產生影響。

（e）測試遞增交付成品

為推行用例的職能而編製的代碼會進行測試，以確保它根據在用例中所指明的規格正確地執行。測試方法與測試一般概念的方法一致。

3.6 設置

遞增交付成品的設置可按業務性質、計劃的限制及所帶來的好處而加以採用。

設置的工作項目是：

（a）為培訓用戶作好準備

是否需要就整個系統或每個遞增交付成品對用戶進行培訓，實在非常取決於如何調配該等遞增交付成品。

如會設置每一個遞增交付成品，便須在第一個遞增交付成品的用戶測試前首先進行培訓。在用戶測試期間，終端用戶將須在設置遞增交付成品前操作該系統和收取培訓材料。