流程：
“對象”是由描述其屬性的數據，及可以對這些數據施加的操作（即服務），封裝在一起構成的獨立單元。
一、抽象出對象和對象之間的關聯
二、畫靜態模型
1、畫出關聯圖
2、划分主題
3、為關聯圖中的對象添加屬性
4、識別繼承關系
5、反復修改，比如把關聯時傳遞的動作信息進行對象化
三、畫動態模型
建立動態模型的第一步，是編寫典型交互行為的腳本。雖然腳本中不可能包括每個偶然事件，但是，至少必須保證不遺漏常見的交互行為。
接下來從腳本中提取出事件，確定觸發每個事件的動作對象以及接受事件的目標對象。
第三步，排列事件發生的次序，確定每個對象可能有的狀態及狀態間的轉換關系，並用狀態圖描繪它們。
1、編寫典型交互行為的腳本，腳本是指系統在某一執行期間內出現的一系列事件。雖然腳本中不可能包括每個偶然事件，但是，至少必須保證不遺漏常見的交互行為。
2、應該仔細分析每個腳本，確定觸發每個事件的動作對象以及接受事件的目標對象。
3、分析每個事件的處理過程，畫事件跟蹤圖
4、排列事件發生的次序，確定每個對象可能有的狀態及狀態間的轉換關系，畫狀態圖
4、如果有需要，可以畫時序圖
四、畫功能模型
1、畫出基本系統模型圖
2、得到功能級數據流圖（把基本系統模型中單一的處理框分解成若干個處理框，以描述系統加工、變換數據的基本功能）
一、定義使用場景
OOA過程並不是從考慮對象開始，而是從理解系統的使用方式開始，
如果系統是人機交互的，則考慮被人使用的方式；
如果是設計過程控制的，則考慮被機器使用的方式；
如果是系統協調和控制應用，則考慮被其他程序使用的方式
面向對象分析（通常縮寫為OOA）的關鍵，是識別出問題域內的對象，並分析它們相互間的關系，最終建立起問題域的簡潔、精確、可理解的正確模型。
面向對象分析，就是抽取和整理用戶需求並建立問題域精確模型的過程。
三個子模型與五個層次
面向對象建模得到的模型包含對象的三個要素，即靜態結構（對象模型），交互次序（動態模型）和數據變換（功能模型）。
解決的問題不同，這三個子模型的重要程度也不同：
幾乎解決任何一個問題，都需要從客觀世界實體及實體間相互關系抽象出極有價值的對象模型；
當問題涉及交互作用和時序時（例如，用戶界面及過程控制等），動態模型是重要的；
解決運算量很大的問題（例如，高級語言編譯、科學與工程計算等），則涉及重要的功能模型。
動態l模型和功能模型中都包含了對象模型中的操作（即服務或方法）。
復雜問題（大型系統）的對象模型由下述五個層次組成：主題層（也稱為范疇層）、類一＆一對象層、結構層、屬性層和服務層。
面向對象分析大體上按照下列順序進行：尋找類一＆一對象，識別結構，識別主題，定義屬性，建立動態模型，建立功能模型，定義服務。
但是，正如前面已經多次強調指出過的，分析不可能嚴格地按照預定順序進行，大型、復雜系統的模型需要反復構造多遍才能建成。
通常，先構造出模型的子集，然后再逐漸擴充，直到完全、充分地理解了整個問題，才能最終把模型建立起來。
通常，需求陳述的內容包括：問題范圍，功能需求，性能需求，應用環境及假設條件等。總之，需求陳述應該闡明“做什么”而不是“怎樣做”。
如圖所示的自動取款機（ATM）系統，是講述面向對象分析和面向對象設計時使用的一個實例。
下面陳述對ATM系統的需求：
某銀行擬開發一個自動取款機系統，它是一個由自動取款機、中央計算機、分行計算機及櫃員終端組成的網絡系統。
ATM和中央計算機由總行投資購買。總行擁有多台 ATM，分別設在全市各主要街道上。分行負責提供分行計算機和櫃員終端。
櫃員終端設在分行營業廳及分行下屬的各個儲蓄所內。該系統的軟件開發成本由各個分行分攤。
銀行櫃員使用櫃員終端處理儲戶提交的儲蓄事務。儲戶可以用現金或支票向自己擁有的某個賬戶內存款或開新賬戶。
儲戶也可以從自己的賬戶中取款。通常，一個儲戶可能擁有多個賬戶。
櫃員負責把儲戶提交的存款或取款事務輸進櫃員終端，接收儲戶交來的現金或支票，或付給儲戶現金。
櫃員終端與相應的分行計算機通信，分行計算機具體處理針對某個賬戶的事務並且維護賬戶。
擁有銀行賬戶的儲戶有權申請領取現金兌換卡。使用現金兌換卡可以通過ATM訪問自己的賬戶。
目前僅限於用現金兌換卡在ATM上提取現金（即取款），或查詢有關自己賬戶的信息（例如，某個指定賬戶上的余額）。
將來可能還要求使用ATM辦理轉賬、存款等事務。
所謂現金兌換卡就是一張特制的磁卡，上面有分行代碼和卡號。
分行代碼唯一標識總行下屬的一個分行，卡號確定了這張卡可以訪問哪些賬戶。
通常，一張卡可以訪問儲戶的若干個賬戶，但是不一定能訪問這個儲戶的全部賬戶。
每張現金兌換卡僅屬於一個儲戶所有，但是，同一張卡可能有多個副本，因此，必須考慮同時在若干台ATM上使用同樣的現金兌換卡的可能性。
也就是說，系統應該能夠處理並發的訪問。
當用戶把現金兌換卡插入ATM之后，ATM就與用戶交互，以獲取有關這次事務的信息，並與中央計算機交換關於事務的信息。
首先，ATM要求用戶輸入密碼，接下來ATM把從這張卡上讀到的信息以及用戶輸入的密碼傳給中央計算機，請求中央計算機核對這些信息並處理這次事務。
中央計算機根據卡上的分行代碼確定這次事務與分行的對應關系，並且委托相應的分行計算機驗證用戶密碼。
如果用戶輸入的密碼是正確的，ATM就要求用戶選擇事務類型（取款、查詢等）。
當用戶選擇取款時，ATM請求用戶輸入取款額。最后，ATM從現金出口吐出現金，並且打印出賬單交給用戶。
建立對象摸型
對象模型通常有五個層次。
典型的工作步驟是，
首先確定對象類和關聯（因為它們影響系統整體結構和解決問題的方法），對於大型復雜問題還要進一步划分出若干個主題；
然后給類和關聯增添屬性，以進一步描述它們；
接下來利用適當的繼承關系進一步合並和組織類。
而對類中操作的最后確定，則需等到建立了動態模型和功能模型之后，因為這兩個子模型更准確地描述了對類中提供的服務的需求。
什么是對象？什么可以抽象為對象？
什么都可以。
通常，
對象是對問題域中有意義的事物的抽象，它們既可能是物理實體，也可能是抽象概念。·具體地說，大多數客觀事物可分為下述五類
（1）可感知的物理實體，例如，飛機、汽車、書、房屋等等。
（2）人或組織的角色，例如，醫生、教師、雇主、雇員、計算機系、財務處等等。
（3）應該記憶的事件，例如，飛行、演出、訪問、交通事故等等。
（4）兩個或多個對象的相互作用，通常具有交易或接觸的性質，例如，購買、納稅、結婚等等。
（5）需要說明的概念，例如，政策、保險政策、版權法等等。
另一種更簡單的分析方法，是所謂的非正式分析。這種分析方法以用自然語言書寫的 需求陳述為依據，把陳述中的名詞作為類一＆一對象的候選者，用形容詞作為確定屬性的線索，把動詞作為服務（操作）的候選者。
認真閱讀上面給出的需求陳述，從陳述中找出下列名詞，可以把它們作為類一＆－一對象的初步的候選者：
銀行，自動取款機（ATM），系統，中央計算機，分行計算機，櫃員終端，網絡，總行，分行，軟件，成本，市，街道，營業廳，儲蓄所，櫃員，儲戶，現金，支票，賬戶，事務，現金兌換卡，余額，磁卡，分行代碼，卡號，用戶，副本，信息，密碼，類型，取款額，賬單，訪問。
2．篩選出正確的類一＆一對象
接下來應該嚴格考察每個候選對象，從中去掉不正確的或不必要的，僅保留確實應該記錄其信息或需要其提供服務的那些對象。
篩選時主要依據下列標准，刪除不正確或不必要的類一＆一對象：
（l）冗余
如果兩個類表達了同樣的信息，則應該保留在此問題域中最富於描述力的名稱。
以ATM系統為例，應該去掉“用戶”、“磁卡”、“副
本”等冗余的類，僅保留“儲戶”和“現金兌換卡”這兩個類。
（2）無關
僅需要把與本問題密切相關的類一＆一對象放進目標系統中。
以ATM系統為例，因此，應該去掉候選類“成本”、“市”、“街道”、“營業廳”和“儲蓄所”。
（3）籠統
在需求陳述中常常使用一些籠統的、泛指的名詞，雖然在初步分析時把它們作為候選的類一＆一對象列出來了，但是，要么系統無須記憶有關它們的信息，要么在需求陳述中有更明確更具體的名詞對應它們所暗示的事務，因此，通常把這些籠統的或模糊的類去掉。
以ATM系統為例，應該去掉“銀行”、“網絡”、“系統”、“軟件”、“信息”、“訪問”等候選類。
（4）屬性
在需求陳述中有些名詞實際上描述的是其他對象的屬性，應該把這些名詞從候選類一＆一對象中去掉。
在ATM系統的例子中，“現金”、“支票”、“取款額”、“賬單”、“余額”、“分行代碼”、“卡號”、“密碼”、“類型”等，實際上都應該作為屬性對待。
（5）操作
在需求陳述中有時可能使用一些既可作為名詞，又可作為動詞的詞，應該慎重考慮它們在本問題中的含義，以便正確地決定把它們作為類還是作為類中定義的操作。
（6）實現
在分析階段不應該過早地考慮怎樣實現目標系統。因此，應該去掉僅和實現有關的候選的類一＆一對象。
在ATM系統的例子中，應該暫時去掉“事務日志”和“通信鏈路”這兩個類，在設計或實現時再考慮它們。
3.3． 2 確定關聯
多數人習慣於在初步分析確定了問題域中的類一＆一對象之后，接下來就分析確定類一＆一對象之間存在的關聯關系。
兩個或多個對象之間的相互依賴、相互作用的關系就是關聯。分析確定關聯，能促使分析員考慮問題域的邊緣情況，有助於發現那些尚未被發現的類一&一對象。
1．初步確定關聯
在需求陳述中使用的描述性動詞或動詞詞組，通常表示關聯關系。因此，在初步確定關聯時，大多數關聯可以通過直接提取需求陳述中的動詞詞組而得出。通過分析需求陳述，還能發現一些在陳述中隱含的關聯。
以ATM系統為例，經過分析初步確定出下列關聯：
（l）直接提取動詞短語得出的關聯
·ATM、中央計算機、分行計算機及櫃員終端組成網絡。
·總行擁有多台ATM。
·ATM設在主要街道上。
·分行提供分行計算機和櫃員終端。
·櫃員終端設在分行營業廳及儲蓄所內。
·分行分攤軟件開發成本。
·儲戶擁有賬戶。
·分行計算機處理針對賬戶的事務。
·分行計算機維護賬戶。
·櫃員終端與分行計算機通信。
·櫃員輸入針對賬戶的事務。
· ATM與中央計算機交換關於事務的信息。
·中央計算機確定事務與分行的對應關系。
· ATM讀現金兌換卡。
·ATM與用戶交互。
·ATM吐出現金。
. ATM打印賬單。
·系統處理並發的訪問。
（2）需求陳述中隱含的關聯
·總行由各個分行組成。
·分行保管賬戶。
·總行擁有中央計算機。
·系統維護事務日志。
·系統提供必要的安全性。
·儲戶擁有現金兌換卡。
（3）根據問題域知識得出的關聯
·現金兌換卡訪問賬戶。
·分行雇用櫃員。
2．篩選
經初步分析得出的關聯只能作為候選的關聯，還需經過進一步篩選，以去掉不正確的或不必要的關聯。篩選時主要根據下述標准刪除候選的關聯：
（1）已刪去的類之間的關聯。
如果在分析確定類一＆一對象的過程中已經測掉了某個候選類，則與這個類有關的關聯也應該刪去。
以ATM系統為例，由於已經刪去了“系統”、“網絡”、“市”、“街道”、“成本”、“軟件”、“事務日志”、“現金”、“營業廳”、“儲蓄所”、“賬單”等候選類，因此，與這些類有關的下列入個關聯也應該刪去：
①ATM、中央計算機、分行計算機及櫃員終端組成網絡。
②ATM設在主要街道上。
③分行分攤軟件開發成本。
④系統提供必要的安全性。
⑤系統維護事務日志。
⑥ ATM吐出現金。
⑦ATM打印賬單。
⑧櫃員終端設在分行營業廳及儲蓄所內。
（2）與問題無關的或應在實現階段考慮的關聯
應該把處在本問題域之外的關聯或與實現密切相關的關聯刪去。
例如，在ATM系統的例子中，“系統處理並發的訪問”並沒有標明對象之間的新關聯，它只不過提醒我們在實現階段需要使用實現並發訪問的算法，以處理並發事務。
（3）瞬時事件
關聯應該描述問題域的靜態結構，而不應該是一個瞬時事件。
以ATM系統為例，“ATM讀現金兌換卡”描述了ATM與用戶交互周期中的一個動作，它並不是ATM與現金兌換卡之間的固有關系，因此應該刪去。類似地，還應該刪去“ATM與用戶交互”這個候選的關聯。
（4）三元關聯
三個或三個以上對象之間的關聯，大多可以分解為二元關聯或用詞組描述成限定的關聯。
在ATM系統的例子中，“櫃員輸入針對賬戶的事務”可以分解成“櫃員輸人事務”和“事務修改賬戶”這樣兩個二元關聯。
（5）派生關聯
應該去掉那些可以用其他關聯定義的冗余關聯。
例如，在ATM系統的例子中，“總行擁有多台 ATM”實質上是“總行擁有中央計算機”和“ATM與中央計算機通信”這兩個關聯組合的結果。而“分行計算機維護賬戶”的實際含義是，“分行保管賬戶”和“事務修改賬戶”。
派生關聯是理解業務出現錯誤的原因之一。
3．進一步完善
應該進一步完善經篩選后余下的關聯，通常從下述幾個方面進行改進：
（1）正名
好的名字是幫助讀者理解的關鍵因素之一。因此，應該仔細選擇含義更明確的名字作為關聯名。
（2）分解
為了能夠適用於不同的關聯，必要時應該分解以前確定的類一＆一對象。
例如，在ATM系統中，應該把“事務”分解成“遠程事務”和“櫃員事務”。
（3）補充
發現了遺漏的關聯就應該及時補上。
例如，在ATM系統中把“事務”分解成上述兩類之后，需要補充“櫃員輸入櫃員事務”、“櫃員事務輸進櫃員終端”、“在ATM上輸入遠程事務”和“遠程事務由現金兌換卡授權”等關聯。
（4）標明階數
應該初步判定各個關聯的類型，並粗略地確定關聯的階數。
3.3．3 划分主題
在開發大型、復雜系統的過程中，為了降低復雜程度，人們習慣於把系統再進一步划分成幾個不同的主題，也就是在概念上把系統包含的內容分解成若干個范疇。
應該按問題領域而不是用功能分解方法來確定主題。此外，應該按照使不同主題內的對象相互間依賴和交互最少的原則來確定主題。
以ATM系統為例，我們可以把它划分成“總行”、“分行”和“ATM”等三個主題，這三個主題的編號分別是l、2和3。
3.3 ．4 確定屬性
屬性是對象的性質，藉助於屬性我們能對類一＆一對象和結構有更深入更具體的認識。注意，在分析階段不要用屬性來表示對象間的關系，使用關聯能夠表示兩個對象間的任何關系，而且把關系表示得更清晰、更醒目。
一般說來，確定屬性的過程包括分析和選擇兩個步驟。
1．分析
屬性的確定既與問題域有關，也和目標系統的任務有關。應該僅考慮與具體應用直接相關的屬性，不要考慮那些超出所要解決的問題范圍的屬性。在分析階段不要考慮那些純粹用於實現的屬性。
2．選擇
認真考察經初步分析而確定下來的那些屬性，從中刪掉不正確的或不必要的屬性。通常有以下幾種常見情況：
（l）誤把對象當作屬性
如果某個實體的獨立存在比它的值更重要，則應把它作為一個對象而不是對象的屬性。例如，在郵政目錄中，“城市”是一個屬性，而在人口普查中卻應該把“城市”當作對象。
（2）把鏈屬性誤作為屬性
如果某個性質依賴於某個關聯鏈的存在，則該性質是鏈屬性，在分析階段不應該把它作為對象的屬性。
（3）把限定誤當成屬性
限定是一種特殊的鏈屬性。
在ATM系統的例子中，“分行代碼”、“賬號”、“雇員號”、“站號”等都是限定詞。
（4）誤把內部狀態當成了屬性
如果某個性質是對象的非公開的內部狀態，則應該從對象模型中規掉這個屬性。
（5）過於細化
在分析階段應該忽略那些對大多數操作都沒有影響的屬性。
（6）存在不一致的屬性
類應該是簡單而且一致的。如果得出一些看起來與其他屬性毫不相關的屬性，則應該考慮把該類分解成兩個不同的類。
經過篩選之后，得到ATM系統中各個類的屬性，如圖3.5所示。
我的理解是：如果某個屬性下面有其他子屬性，那么這個屬性就可以單獨拿出來當個對象。
3.3．5 識別繼承關系
可以使用兩種方式建立繼承（即歸納）關系：
（1）自底向上：抽象出現有類的共同性質泛化出父類。例如，在ATM系統中，“遠程事務”和“櫃員事務”是類似的，可以泛化出父類“事務”；
（2）自須向下：把現有類細化成更具體的子類；
3.3．6 反復修改
僅僅經過一次建模過程很難得到完全正確的對象模型。事實上，軟件開發過程就是一個多次反復修改、逐步完善的過程。在建模的任何一個步驟中，如果發現了模型的缺陷，都必須返回到前期階段進行修改。
下面以ATM系統為例，討論可能做的修改：
1．分解“現金兌換卡”類
把“現金兌換卡”類分解為“卡權限”和“現金兌換卡’兩個類，將使每個類的功能更單一；
2．“事務”由“更新”組成
“更新”雖然代表一個動作，但是它有自己的屬性（類型、金額等），應該獨立存在，因此應該把它作為類一＆一對象。
3．把“分行”與“分行計算機”合並
應該合並“分行”與“分行計算機”， “總行”和“中央計算機”
對於僅存儲靜態數據的系統（例如數據庫）來說，動態模型並沒有什么意義。然而在開發交互式系統時，動態模型卻起着很重要的作用。如果收集輸入信息是目標系統的一項主要工作，則在開發這類應用系統時建立正確的動態模型是至關重要的。
建立動態模型的第一步，是編寫典型交互行為的腳本。雖然腳本中不可能包括每個偶然事件，但是，至少必須保證不遺漏常見的交互行為。
接下來從腳本中提取出事件，確定觸發每個事件的動作對象以及接受事件的目標對象。
第三步，排列事件發生的次序，確定每個對象可能有的狀態及狀態間的轉換關系，並用狀態圖描繪它們。
最后，比較各個對象的狀態圖，檢查它們之間的一致性，確保事件之間的匹配。
3.4．1 編寫腳本
在建立動態模型的過程中，腳本是指系統在某一執行期間內出現的一系列事件。腳本描述用戶（或其他外部設備）與目標系統之間的一個或多個典型的交互過程，以便對目標系統的行為有更具體的認識。編寫腳本的目的，是保證不遺漏重要的交互步驟，它有助於確保整個交互過程的正確性的和清晰性。
腳本描寫的范圍並不是固定的，既可以包括系統中發生的全部事件，也可以只包括由某些特定對象觸發的事件。腳本描寫的范圍主要由編寫腳本的具體目的決定。
編寫腳本時，首先編寫正常情況的腳本。然后，考慮特殊情況，最后，考慮出錯情況。
對於每個事件，都應該指明觸發該事件的動作對象（例如，系統、用戶或其他外部事物）、接受事件的目標對象以及該事件的參數。
3.4．2 設想用戶界面
大多數交互行為都可以分為應用邏輯和用戶界面兩部分。通常，系統分析員首先集中精力考慮系統的信息流和控制流，而不是首先考慮用戶界面。應用邏輯是內在的、本質的內容，用戶界面是外在的表現形式。動態模型着重表示應用系統的控制邏輯。
但是，用戶界面的美觀程度、方便程度、易學程度以及效率等等，是用戶使用系統時最先感受到的，用戶對系統的“第一印象”往往從界面得來，用戶界面的好壞往往對用戶是否喜歡、是否
接受一個系統起很重要的作用。因此，在分析階段也不能完全忽略用戶界面。
3.4．3 畫事件跟蹤圖
為了有助於建立動態模型，通常在畫狀態圖之前先畫出事件跟蹤圖。為此首先需要進一步明確事件及事件與對象的關系。
1．確定事件
應該仔細分析每個腳本，以便從中提取出所有外部事件。事件包括系統與用戶（或外部設備）交互的所有信號、輸入、輸出、中斷、動作等等。
傳遞信息的對象的動作也是事件。例如，儲戶插入現金兌換卡、儲戶輸入密碼、ATM吐出現金等都是事件。大多數對象到對象的交互行為都對應着事件。
應該把對控制流產生相同效果的那些事件組合在一起作為一類事件，並給它們取一個唯一的名字。例如，“吐出現金”是一個事件類。
2．畫出事件跟蹤圖
從腳本中提取出各類事件並確定了每類事件的發送對象和接受對象之后，就可以用事件跟蹤圖把事件序列以及事件與對象的關系，形象、清晰地表示出來。事件跟蹤圖實質上是擴充的腳本。
在事件跟蹤圖中，一條豎線代表一個類一＆一對象，每個事件用一條水平的箭頭線表示，箭頭方向從事件的發送對象指向接受對象。時間從上向下遞增。
3.4．4 畫狀態圖
狀態圖描繪事件與對象狀態的關系。當對象接受了一個事件以后，它的下個狀態取決 於當前狀態及所接受的事件。由事件引起的狀態改變稱為“轉換”。如果一個事件並不引起當前狀態發生轉換，則可忽略這個事件。
通常，用一張狀態圖描繪一類對象的行為，它確定了由事件序列引出的狀態序列。 考慮完正常事件之后再考慮邊界情況和特殊情況，其中包括在不適當時候發生的事件（例如，系統正在處理某個事務時，用戶要求取消該事務）。
3.4．5 審查動態模型
各個類的狀態圖通過共享事件合並起來，構成了系統的動態模型。在完成了每個具有重要交互行為的類的狀態圖之后，應該檢查系統級的完整性和一致性。
應該審查每個事件，跟蹤它對系統中各個對象所產生的效果，以保證它們與每個腳本都匹配。
3.5 建立功能摸型
功能模型表明了系統中數據之間的依賴關系，以及有關的數據處理功能，它由一組數據流圖組成。
通常在建立了對象模型和動態模型之后再建立功能模型。
3.5．1 畫出基本系統模型圖
基本系統模型由若干個數據源點／終點，及一個處理框組成，這個處理框代表了系統加工、變換數據的整體功能。基本系統模型指明了目標系統的邊界。由數據源點輸入的數據和輸出到數據終點的數據，是系統與外部世界之間的交互事件的參數。
3.5．2 畫出功能級數據流圖
把基本系統模型中單一的處理框分解成若干個處理框，以描述系統加工、變換數據的基本功能，就得到功能級數據流圖。
3.5．3 描述處理框功能
把數據流圖分解細化到一定程度之后，就應該描述圖中各個處理框的功能。
“對象”是由描述其屬性的數據，及可以對這些數據施加的操作（即服務），封裝在一起構成的獨立單元。因此，為建立完整的對象模型，既要確定類中應該定義的屬性，又要確定類中應該定義的服務。前面已經指出，需要等到建立了動態模型和功能模型之后，才能最終確定類中應有的服務，因為這兩個子模型更明確地描述了每個類中應該提供哪些服務。
3.6．1 常規行為
在分析階段可以認為，類中定義的每個屬性都是可以訪問的。
3.6．2 從事件導出的操作
狀態圖中發往對象的事件也就是該對象接收到的消息，因此該對象必須有由消息選擇符指定的操作，這個操作修改對象狀態（即屬性值）並啟動相應的服務。
3.6．3 與數據流目中處理框對應的操作
數據流圖中的每個處理框都與一個對象（也可能是若干個對象）上的操作相對應。
3.6．4 利用繼承減少冗余操作
應該盡量利用繼承機制以減少所需定義的服務數目。
