專利名稱：面向?qū)ο蟮泥]遞服務(wù)器框架機(jī)構(gòu)的制作方法
本申請是中國專利申請第96121524.0號的分案申請。
本發(fā)明一般地說涉及數(shù)據(jù)處理，更具體地說是涉及面向?qū)ο蟮木幊滔到y(tǒng)和處理。
眾所周知的電子郵件，指的是從一個(gè)計(jì)算機(jī)用戶通過互聯(lián)的計(jì)算機(jī)網(wǎng)絡(luò)送到另一用戶的消息。支持電子郵件的計(jì)算機(jī)系統(tǒng)提供一種手段，用于制成消息、將它們從消息發(fā)出者傳送到接收者、通知接收者并在消息被接收時(shí)向發(fā)出者報(bào)告，并以適當(dāng)?shù)母袷椒胖孟⒁栽诰W(wǎng)絡(luò)上進(jìn)行傳送，從而便利了這種消息傳送。
早期的電子郵件系統(tǒng)包括在共同的計(jì)算機(jī)上的用戶之間或在采用共同的數(shù)據(jù)處理設(shè)備的不同的計(jì)算機(jī)上的終端—終端消息傳送。例如，某些早期的電子郵件系統(tǒng)采用了用于網(wǎng)絡(luò)內(nèi)通信的簡單的文件傳送協(xié)議，它規(guī)定了用相應(yīng)的網(wǎng)絡(luò)終端節(jié)點(diǎn)來標(biāo)明發(fā)出者和接收者的預(yù)定消息標(biāo)頭數(shù)據(jù)，其后是消息的內(nèi)容。很多現(xiàn)代的電子郵件系統(tǒng)支持包括ASCII文本、模擬傳真數(shù)據(jù)、數(shù)字傳真數(shù)據(jù)、數(shù)字語音數(shù)據(jù)、視頻文本和其他內(nèi)容的信息。
為滿足對計(jì)算機(jī)間網(wǎng)絡(luò)通信的需要，制定了很多通信協(xié)議，以定義更為通用的電子郵件消息系統(tǒng)。網(wǎng)絡(luò)通信協(xié)議的兩個(gè)例子，一是為按照國際商用機(jī)器公司(IBM公司)的系統(tǒng)網(wǎng)絡(luò)結(jié)構(gòu)規(guī)程(Systems NetworkArchitecture specification)進(jìn)行網(wǎng)絡(luò)通信所規(guī)定的系統(tǒng)網(wǎng)絡(luò)結(jié)構(gòu)分布服務(wù)(Systems Network architecture Distribution Services(SNADS))協(xié)議，二是所謂的簡單郵件傳送協(xié)議(Simple Mail Transfer Protocol(SMTP))。其他的網(wǎng)絡(luò)包括國際標(biāo)準(zhǔn)化組織(InternationalOrganization for Standardization(ISO))制定的面向?qū)ο蟮奈谋净Q系統(tǒng)(MOTIS)標(biāo)準(zhǔn)和—基于Unix的網(wǎng)絡(luò)協(xié)議USENET。
郵遞服務(wù)器系統(tǒng)方便地處理根據(jù)郵遞服務(wù)器系統(tǒng)的協(xié)議構(gòu)成的消息，該協(xié)議經(jīng)常被稱為“本機(jī)”(native)協(xié)議。以不同的協(xié)議通信的用戶之間的消息傳送，通常必須通過網(wǎng)絡(luò)網(wǎng)關(guān)處理器，后者將該消息由外部協(xié)議變換成本機(jī)協(xié)議。因此，用于互聯(lián)網(wǎng)絡(luò)中的消息傳送的網(wǎng)關(guān)，諸如在通常稱為“互聯(lián)網(wǎng)絡(luò)”的網(wǎng)絡(luò)上使用的網(wǎng)關(guān)，從另一個(gè)網(wǎng)關(guān)或從相聯(lián)的網(wǎng)絡(luò)接收電子郵件消息。在聯(lián)接的各網(wǎng)絡(luò)上的用戶可以經(jīng)過局域網(wǎng)絡(luò)(LAN)聯(lián)接而與該網(wǎng)關(guān)相聯(lián)。如果消息是來自另一網(wǎng)關(guān)，則進(jìn)行檢查以判定消息中標(biāo)明的接收者是否是本地的。即，接收者可能是在接收網(wǎng)關(guān)的LAN上的計(jì)算機(jī)用戶。如果該接收者對于該網(wǎng)關(guān)來說是本地的，則消息被傳送給網(wǎng)關(guān)網(wǎng)絡(luò)信箱或接收者能夠從中獲取消息的其他分送裝置。如果接收者不是本地的，則消息被送到另一網(wǎng)關(guān)。如果消息是來自發(fā)出者—即只產(chǎn)生該消息的網(wǎng)關(guān)LAN用戶，則檢查消息的格式和句法是否正確。該消息隨后被作為從另一網(wǎng)關(guān)接收的消息對待，意味著它是在被送往另一網(wǎng)絡(luò)的網(wǎng)關(guān)的途中。
因此，各個(gè)網(wǎng)關(guān)可以包括根據(jù)本機(jī)協(xié)議運(yùn)行的計(jì)算機(jī)網(wǎng)絡(luò)。各個(gè)網(wǎng)關(guān)都可能被要求識別從不同的協(xié)議產(chǎn)生的消息(并確定其適當(dāng)信息)。例如，一個(gè)SNADS協(xié)議網(wǎng)關(guān)可能接收到MOTIS標(biāo)準(zhǔn)消息。如果該SNADS網(wǎng)關(guān)要將消息送到其預(yù)定的接收者，該網(wǎng)關(guān)必須首先將該消息轉(zhuǎn)換或變換到SNADS協(xié)議，以使該消息能夠在SNADS網(wǎng)關(guān)網(wǎng)絡(luò)上行進(jìn)。接收該消息的網(wǎng)關(guān)可能需要進(jìn)行類似的轉(zhuǎn)換。協(xié)議之間的轉(zhuǎn)換，由于一個(gè)協(xié)議所支持的特征可能不為另一協(xié)議所知道，而可以變得非常困難。另外，一個(gè)協(xié)議可能基于與另一個(gè)協(xié)議不同的具體通信模型。例如，SNADS系統(tǒng)是基于通信會(huì)話的(帶有伴生的消息參數(shù))，而SMTP系統(tǒng)模型則不是基于會(huì)話的。
很多電子郵件系統(tǒng)不能有效地進(jìn)行所需的消息處理任務(wù)，以在不同的消息協(xié)議之間進(jìn)行轉(zhuǎn)換。另外，很多電子郵件系統(tǒng)在它們能夠支持并管理它們原來為之設(shè)計(jì)的協(xié)議以外的協(xié)議之前，需要大量的修正。因此，隨著新的協(xié)議的開發(fā)或系統(tǒng)用戶決定使用非本機(jī)的協(xié)議，這種系統(tǒng)將需要高的維護(hù)費(fèi)用。如果電子郵件系統(tǒng)網(wǎng)關(guān)能夠迅速而有效地支持和管理多個(gè)協(xié)議之間的消息處理并適應(yīng)新的協(xié)議，那將是有利的。
從以上的論述，可以看出需要一種電子郵件協(xié)議間的網(wǎng)關(guān)機(jī)構(gòu)，它能夠有效地按一種協(xié)議接收來自一發(fā)送地的電子郵件消息并按另一種協(xié)議將這種消息傳送到一目的地，且它能夠適應(yīng)新的協(xié)議，從而能夠接收和傳送按新協(xié)議的消息。本發(fā)明滿足了這種需要。
根據(jù)本發(fā)明，用于與面向?qū)ο蟮某绦蛟O(shè)計(jì)(OOP)系統(tǒng)一起使用的可再用面向?qū)ο?OO)結(jié)構(gòu)，提供了通用的消息處理系統(tǒng)結(jié)構(gòu)，它能夠被置于任何OOP平臺(tái)上并能夠得到適當(dāng)?shù)臉?gòu)成以支持任何電子郵件消息協(xié)議標(biāo)準(zhǔn)或具體的郵遞服務(wù)器功能。該消息處理系統(tǒng)結(jié)構(gòu)是基于一組確定的對象類，這些對象類形成了面向?qū)ο蟮目蚣?。該框架的用戶可以方便地對框架進(jìn)行剪裁，以適合它們的需要并提供郵遞服務(wù)器系統(tǒng)，從而減小與用戶/服務(wù)器電子郵件消息處理有關(guān)的開發(fā)和支持費(fèi)用?？蚣艿脑O(shè)計(jì)提供了用標(biāo)準(zhǔn)構(gòu)成部件定義消息的對象結(jié)構(gòu)，這些部件與OOP特征相一致并定義了屬性和行為。以此方式，消息處理能夠被分成一系列依次的步驟，或OOP對象方法，它處理消息的具體部分。
框架確定的一系列依次的步驟，代表著郵遞服務(wù)器系統(tǒng)的有組織的中性實(shí)施。該框架將電子郵件消息定義為若干個(gè)分立的對象，其每一個(gè)都包含描述消息的某一部分的信息。實(shí)施該框架的系統(tǒng)接收的所有消息，可在該核心對象結(jié)構(gòu)上得到定義。另一組對象和方法定義了郵遞服務(wù)器處理消息所需的處理步驟。消息被作為一類消息對象來接收，而這些對象被指定了一個(gè)消息類型，該類型確定了消息對象隨后所要經(jīng)受的處理步驟。例如，一個(gè)消息可被指定為SNADS類消息類型或SMTP類消息類型。當(dāng)處理消息時(shí)，它所包括的對象被改變，從而使消息處理能夠被中斷，且隨后得到恢復(fù)，而不損失或重復(fù)處理步驟。
由于郵遞服務(wù)器處理系統(tǒng)是以O(shè)OP框架的形式提供的，處理與具體的電子郵件協(xié)議對應(yīng)的消息對象的對象方法，能夠方便地被結(jié)合到框架的實(shí)施中，而不改變郵遞服務(wù)器系統(tǒng)?？蚣苡脩舻玫奖ＷC，在框架的類和次類結(jié)構(gòu)上定義的電子郵件功能對象方法將借助核心框架對象和方法進(jìn)行操作，以按照所希望的方式處理消息。以此方式，框架用戶能夠定義處理新電子郵件協(xié)議的對象方法，以根據(jù)它們的具體需要來裁剪郵遞服務(wù)器系統(tǒng)，而不改變整個(gè)系統(tǒng)，且不用對系統(tǒng)編程進(jìn)行重新組合。這減少了對電子郵件網(wǎng)關(guān)系統(tǒng)改變具體的郵遞服務(wù)器所需的時(shí)間和費(fèi)用。
從以下對最佳實(shí)施例(它們以舉例的方式顯示了本發(fā)明的原理)的描述，可以理解本發(fā)明的其他特征和優(yōu)點(diǎn)。


圖1是顯示了本發(fā)明的系統(tǒng)所實(shí)施的原理的動(dòng)物園管理框架的示意圖。
圖2、3、4、5、和6是用于圖1的動(dòng)物園管理框架的例子的類圖。
圖7是圖1至6的框架的例子的對象圖。
圖8是根據(jù)本發(fā)明構(gòu)成的計(jì)算機(jī)處理系統(tǒng)的功能框圖。
圖9、10和11是處理圖，它顯示了圖8的計(jì)算機(jī)處理系統(tǒng)所進(jìn)行的消息處理步驟。
圖12是表示圖8的計(jì)算機(jī)處理系統(tǒng)實(shí)施的面向?qū)ο蟮目蚣艿姆诸悎D。
圖13是圖8所示的計(jì)算機(jī)處理系統(tǒng)實(shí)施的消息中心類別和有關(guān)類的類圖。
圖14是表示圖8所示的計(jì)算機(jī)處理系統(tǒng)實(shí)施的消息類別的類圖。
圖15是表示圖8的計(jì)算機(jī)處理系統(tǒng)實(shí)施的發(fā)出者清單類別的類圖。
圖16是表示圖8所示的計(jì)算機(jī)處理系統(tǒng)所實(shí)施的信封清單類別的類圖。
圖17是表示圖8所示的計(jì)算機(jī)處理系統(tǒng)所實(shí)施的接收者清單類別的類圖。
圖18是表示圖8的計(jì)算機(jī)處理系統(tǒng)實(shí)施的附件訪問清單類別的類圖。
圖19是表示圖8的計(jì)算機(jī)處理系統(tǒng)實(shí)施的原始接收者清單類別的類圖。
圖20是表示圖8的計(jì)算機(jī)處理系統(tǒng)實(shí)施的回答對象清單類別的類圖。
圖21是表示圖8的計(jì)算機(jī)處理系統(tǒng)實(shí)施的報(bào)告對象清單類別的類22是表示圖8的計(jì)算機(jī)處理系統(tǒng)實(shí)施的報(bào)告內(nèi)容清單類別的類圖。
圖23是表示圖8的計(jì)算機(jī)處理系統(tǒng)實(shí)施的、屬于消息中心類別的地址產(chǎn)生器清單類的類圖。
圖24是表示屬于圖8的計(jì)算機(jī)處理系統(tǒng)實(shí)施的、屬于消息中心類別的信封產(chǎn)生器清單類的類圖。
圖25是表示屬于圖8的計(jì)算機(jī)處理系統(tǒng)實(shí)施的消息、屬于中心類別的附件訪問產(chǎn)生器清單類的類圖。
圖26是表示當(dāng)處理進(jìn)入的消息和產(chǎn)生消息對象時(shí)由圖8所示的主處理器執(zhí)行的處理步驟的對象圖。
圖27是表示當(dāng)產(chǎn)生地址對象時(shí)由圖8所示的主處理器執(zhí)行的處理步驟的對象圖。
圖28是表示當(dāng)產(chǎn)生信封對象時(shí)由圖8所示的主處理器執(zhí)行的處理步驟的對象圖。
圖29是表示當(dāng)產(chǎn)生附件對象時(shí)由圖8所示的主處理器執(zhí)行的處理步驟的對象圖。
圖30是表示當(dāng)處理消息對象時(shí)由圖8所示的主處理器執(zhí)行的處理步驟的對象圖。
圖31是表示當(dāng)擴(kuò)展消息對象的未分解的接收者清單的地址條目對象時(shí)由圖8的主處理器執(zhí)行的處理步驟的對象圖。
圖32是表示當(dāng)分解消息對象的未分解的接收者清單的地址條目對象時(shí)由圖8的主處理器執(zhí)行的處理步驟的對象圖。
圖33是對象圖，表示了當(dāng)處理消息的信封清單的信封對象時(shí)由圖8所示的主處理器執(zhí)行的處理步驟。
圖34是對象圖，顯示了當(dāng)處理消息的附件訪問清單的附件訪問對象時(shí)由圖8的主處理器執(zhí)行的處理步驟。
圖35是對象圖，顯示了當(dāng)進(jìn)行郵遞服務(wù)器系統(tǒng)的安全鑒別功能時(shí)由圖8所示的主處理器執(zhí)行的處理步驟。
圖36是對象圖，顯示了當(dāng)處理到達(dá)的消息以向本地(網(wǎng)絡(luò))分送時(shí)由圖8所示的主處理器執(zhí)行的處理步驟。
圖37是對象圖，顯示了當(dāng)處理到達(dá)的消息以送向另一網(wǎng)絡(luò)時(shí)由圖8所示的主處理器執(zhí)行的處理步驟。
圖38是對象圖，顯示了當(dāng)處理到達(dá)的消息以將該消息送回或報(bào)告其內(nèi)容時(shí)由圖8所示的主處理器執(zhí)行的處理步驟。
圖39是對象圖，顯示了當(dāng)處理消息的附件訪問清單中的任何附件訪問對象時(shí)，由圖8所示的主處理器執(zhí)行的處理步驟。
圖40是對象圖，顯示了當(dāng)進(jìn)行郵遞服務(wù)器系統(tǒng)的統(tǒng)計(jì)功能時(shí)由圖8所示的主處理器執(zhí)行的處理步驟。面向?qū)ο蠹夹g(shù)的概述如在概述部分中所述的，本發(fā)明是利用面向?qū)ο蟮目蚣芗夹g(shù)開發(fā)出來的。面向?qū)ο蟮目蚣芗夹g(shù)領(lǐng)域的人員可能希望進(jìn)行到本說明書的詳細(xì)描述部分。然而，對框架技術(shù)或一般的OO技術(shù)不那樣熟悉的人，應(yīng)該讀一下本概述部分，以對本發(fā)明的好處和優(yōu)點(diǎn)有最好的理解。面向?qū)ο蟮募夹g(shù)與過程技術(shù)雖然本發(fā)明涉及具體的面向?qū)ο蟮募夹g(shù)(即面向?qū)ο蟮目蚣芗夹g(shù))，讀者首先必須理解的是，一般地說OO技術(shù)明顯地不同于傳統(tǒng)的基于過程的技術(shù)(經(jīng)常被稱為過程技術(shù))。雖然兩種技術(shù)可被用來解決同一問題，但對問題的最終解決方案總是很不同的。這種不同來自于這一事實(shí)，即過程技術(shù)的設(shè)計(jì)焦點(diǎn)與OO技術(shù)的設(shè)計(jì)焦點(diǎn)完全不同?；谶^程的設(shè)計(jì)的焦點(diǎn)在于解決問題的總體過程；而OO設(shè)計(jì)的焦點(diǎn)在于如何將問題分成一系列獨(dú)立的實(shí)體，而這些實(shí)體能夠一起用于提供一個(gè)解決方案。OO技術(shù)的獨(dú)立實(shí)體被稱為對象。換言之，OO技術(shù)與過程技術(shù)顯著地不同，因?yàn)閱栴}被分解成了相關(guān)的對象組，而不是嵌套的計(jì)算機(jī)程序或步驟的結(jié)構(gòu)。即，過程技術(shù)以數(shù)據(jù)變量和過程函數(shù)來定義一個(gè)系統(tǒng)，而OO技術(shù)以對象和類來定義系統(tǒng)。術(shù)語“框架”已經(jīng)建立起了很多術(shù)語和短語，它們對本領(lǐng)域的技術(shù)人員具有特定的含意。然而，讀者應(yīng)該注意的是，OO領(lǐng)域中最不嚴(yán)格的一個(gè)定義就是詞“框架”的定義。詞“框架”對不同的人意味著不同的事物。因此，當(dāng)比較兩個(gè)假定的OOP框架的特性時(shí)，讀者應(yīng)該注意保證這種比較的確是“蘋果與蘋果”的比較。如在隨后的描述中將說明的，術(shù)語“框架”在本說明書中用于描述一種OO技術(shù)系統(tǒng)，該系統(tǒng)已被設(shè)計(jì)成具有核心功能和擴(kuò)展功能。其核心功能是不受框架購買者修正的框架部分。而擴(kuò)展功能是明確設(shè)計(jì)成可被框架購買者將其作為其實(shí)施的一部分而用戶化和擴(kuò)展的那部分框架。OO框架雖然一般地說OO框架能夠被適當(dāng)?shù)孛枋鰹閷幊虇栴}的一種OO解決方案，但在框架和基本的OO編程解決方案之間仍然有基本的不同。這種不同在于框架是以這樣的方式設(shè)計(jì)的，即允許并鼓勵(lì)OO解決方案的某些方面的用戶化和擴(kuò)展，而基本的OO解決方案則包括類和對象的具體集合或庫。換言之，框架提供了一個(gè)OO編程解決方案，它能夠得到用戶化和擴(kuò)展，以應(yīng)付隨時(shí)間改變的要求。當(dāng)然，框架的用戶化/擴(kuò)展性質(zhì)對于購買者(以下稱為框架用戶)是非常有用的，因?yàn)橛脩艋驍U(kuò)展框架的費(fèi)用遠(yuǎn)低于更換或重新設(shè)置已有編程解決方案的費(fèi)用。
因此，當(dāng)框架設(shè)計(jì)者要解決具體問題時(shí)，它們應(yīng)該不僅僅是設(shè)計(jì)單獨(dú)的對象并規(guī)定這些對象如何相互聯(lián)系。它們還應(yīng)該設(shè)計(jì)框架的核心功能(即框架中不受框架用戶的潛在用戶化和擴(kuò)展的部分)以及框架的擴(kuò)展功能(即框架中受到潛在的用戶化和擴(kuò)展的部分)。總之，框架的最終價(jià)值不僅在于對象的設(shè)計(jì)質(zhì)量，而且在于涉及框架的哪些方面代表核心功能且哪些方面代表擴(kuò)展功能的設(shè)計(jì)選擇。ZAF—框架的一個(gè)例子雖然本領(lǐng)域的技術(shù)人員明白框架設(shè)計(jì)一定是交錯(cuò)和迭代過程，在以下的描述中給出了用于簡單框架的設(shè)計(jì)選擇的一個(gè)例子。然而，應(yīng)該理解的是，這只是框架的一個(gè)例子，它在本說明書中被用來顯示并最佳地描述框架，以使讀者能夠?qū)Ρ景l(fā)明的利益和優(yōu)點(diǎn)有更好的理解。
框架設(shè)計(jì)者，通過從所謂的問題域中選出對象，而確定框架機(jī)構(gòu)所需的對象。問題域是所面臨的具體問題的抽象理解。為顯示框架而選擇的問題域的一個(gè)例子，即動(dòng)物園管理框架(ZAF)，它協(xié)助動(dòng)物園管理者看管和喂養(yǎng)動(dòng)物園的動(dòng)物。OO框架設(shè)計(jì)者將研究動(dòng)物園問題域并決定任何ZAF將必須涉及代表動(dòng)物園管理人員與動(dòng)物之間的關(guān)系(即代表動(dòng)物園工作人員如何管理動(dòng)物)的抽象?？蚣茉O(shè)計(jì)者還應(yīng)該認(rèn)識到動(dòng)物園動(dòng)物通常生活在籠子、水池等之中。因此，框架設(shè)計(jì)者還應(yīng)該從這樣的想法出發(fā)，即框架應(yīng)該涉及代表所有這些基本實(shí)體和關(guān)系的抽象和機(jī)構(gòu)。如何設(shè)計(jì)ZAF為了開始設(shè)計(jì)，框架設(shè)計(jì)者可能從所謂的類別圖開始。類別圖被用來在高層描述框架，并定義框架各組成部分彼此的關(guān)系。圖1是用于示例性的框架ZAF的類別圖。圖1以及本說明書的其他圖中的記號，將在本部分的結(jié)束處的記號部分中得到詳細(xì)描述。類別圖中的各個(gè)實(shí)體或圖符，代表執(zhí)行具體功能的數(shù)據(jù)對象的分組。為了說明，假定框架設(shè)計(jì)者決定ZAF應(yīng)該由四個(gè)部分組成，這些部分在高層描述中，將被稱為機(jī)構(gòu)動(dòng)物園管理機(jī)構(gòu)、動(dòng)物園工作人員機(jī)構(gòu)、動(dòng)物機(jī)構(gòu)、以及圈養(yǎng)單元機(jī)構(gòu)。
如圖1所示，動(dòng)物園管理機(jī)構(gòu)已設(shè)計(jì)成利用動(dòng)物園工作人員機(jī)構(gòu)管理動(dòng)物園。因而說動(dòng)物園管理機(jī)構(gòu)與動(dòng)物園工作人員機(jī)構(gòu)具有“利用”關(guān)系。(請參見本說明書的記號部分中對該關(guān)系和本說明書中使用的其他記號的說明)。
如上所述，動(dòng)物園管理機(jī)構(gòu)已經(jīng)設(shè)計(jì)成負(fù)責(zé)對ZAF進(jìn)行總體控制。相應(yīng)地，動(dòng)物園管理機(jī)構(gòu)負(fù)責(zé)建立動(dòng)物園工作人員機(jī)構(gòu)的運(yùn)行時(shí)間表。注意框架設(shè)計(jì)者還把動(dòng)物園管理機(jī)構(gòu)設(shè)計(jì)成ZAF的核心功能，這意味著它已經(jīng)設(shè)計(jì)成不受潛在的用戶化和擴(kuò)展。在用于動(dòng)物園管理機(jī)構(gòu)的類別框中的大寫字母C，表示了這種事實(shí)。注意動(dòng)物園管理機(jī)構(gòu)與動(dòng)物園工作人員機(jī)構(gòu)之間的“使用”關(guān)系也設(shè)計(jì)成核心功能，從而使它不受框架用戶的最終用戶化。
動(dòng)物園工作人員機(jī)構(gòu)被適當(dāng)?shù)卦O(shè)計(jì)成大體上負(fù)責(zé)動(dòng)物的照顧和喂養(yǎng)。因此，它采用了動(dòng)物和圈養(yǎng)單元機(jī)構(gòu)執(zhí)行其任務(wù)。然而，與動(dòng)物園管理機(jī)構(gòu)的設(shè)計(jì)不同，框架設(shè)計(jì)者已經(jīng)將動(dòng)物園工作人員機(jī)構(gòu)設(shè)計(jì)成一種可擴(kuò)展功能，這再次意味著動(dòng)物園工作人員機(jī)構(gòu)已經(jīng)被設(shè)計(jì)成可由框架用戶修正和/或擴(kuò)展的，以應(yīng)付將來的照顧和喂養(yǎng)要求。這一事實(shí)由動(dòng)物園工作人員機(jī)構(gòu)類別框中的大寫字母E表示。
框架設(shè)計(jì)者已經(jīng)設(shè)計(jì)了動(dòng)物機(jī)構(gòu)，以代表動(dòng)物園動(dòng)物與動(dòng)物園工作人員之間的相互作用中動(dòng)物一方。由于動(dòng)物園中的動(dòng)物數(shù)目是有規(guī)律地變化的，動(dòng)物機(jī)構(gòu)也被類似地設(shè)計(jì)成可擴(kuò)展功能。圈養(yǎng)單元機(jī)構(gòu)通過代表各個(gè)圈養(yǎng)單元(諸如圍欄、水池、和籠子)，而與動(dòng)物園工作人員機(jī)構(gòu)相互作用。象動(dòng)物機(jī)構(gòu)一樣，圈養(yǎng)單元機(jī)構(gòu)被設(shè)計(jì)成可擴(kuò)展功能，以使其能夠應(yīng)付將來的用戶化和擴(kuò)展要求。然而，應(yīng)該注意的是，即使動(dòng)物園工作人員、動(dòng)物園動(dòng)物和圈養(yǎng)單元機(jī)構(gòu)都被設(shè)計(jì)為可擴(kuò)展功能，但這些機(jī)構(gòu)之間的關(guān)系被設(shè)計(jì)成ZAF核心功能。換言之，即使希望在動(dòng)物園工作人員、動(dòng)物園動(dòng)物和圈養(yǎng)單元機(jī)構(gòu)方面給予ZAF用戶靈活性，但不希望使ZAF用戶改變這些機(jī)構(gòu)的相互關(guān)系。
框架設(shè)計(jì)者隨后設(shè)計(jì)構(gòu)成圖1的機(jī)構(gòu)的類和關(guān)系。類是一組類似的對象的定義。因此，類可被認(rèn)為是對象的抽象或一個(gè)類型的對象的定義。從計(jì)算機(jī)系統(tǒng)的觀點(diǎn)看，單個(gè)的對象代表封裝的數(shù)據(jù)組和由計(jì)算機(jī)系統(tǒng)對該數(shù)據(jù)進(jìn)行的操作或操作組。事實(shí)上，在安全計(jì)算機(jī)系統(tǒng)中，對對象所控制的信息的唯一存取，是通過對象本身。這就是為什么包含在對象中的信息被稱為被對象所封裝。
各個(gè)類定義包括定義由對象控制的信息的數(shù)據(jù)定義，和定義對象對各個(gè)對象控制的數(shù)據(jù)進(jìn)行的操作的操作定義。換言之，類定義通過定義對所定義的數(shù)據(jù)進(jìn)行的操作或操作組，來定義對象如何作用和反作用。(應(yīng)該注意的是操作也被稱為方法，方法程序，和/或成員功能)。當(dāng)聯(lián)系在一起時(shí)，所定義的操作和數(shù)據(jù)被稱為對象的行為。本質(zhì)上，類定義限定了其成員對象或?qū)ο蟮男袨椤?br> 圖2是OO類圖，它顯示了框架設(shè)計(jì)者為ZAF設(shè)計(jì)的框架的基本類。每個(gè)類表示，顯示了其與圖1所示的機(jī)構(gòu)的關(guān)系。例如，動(dòng)物園工作人員類被表示為來自動(dòng)物園工作人員機(jī)構(gòu)。ZAF的基本類包括動(dòng)物園管理者類，它是動(dòng)物園管理機(jī)構(gòu)的一部分；動(dòng)物園工作人員登記類，它也是動(dòng)物園管理機(jī)構(gòu)的一部分；動(dòng)物登記類，它是動(dòng)物園工作人員機(jī)構(gòu)的一部分；動(dòng)物園工作人員類，它也是動(dòng)物園工作人員機(jī)構(gòu)的一部分；圈養(yǎng)單元登記類，它也是動(dòng)物園工作人員機(jī)構(gòu)的一部分，動(dòng)物類，它是動(dòng)物機(jī)構(gòu)的一部分；以及圈養(yǎng)單元類，它是圈養(yǎng)單元機(jī)構(gòu)的一部分。應(yīng)該注意的是，類之間的關(guān)系，被設(shè)計(jì)成ZAF的核心功能，從而使它們不受ZAF用戶的最終修正。
動(dòng)物園管理類，是負(fù)責(zé)ZAF的總體控制的對象的定義。這里，OO類只定義進(jìn)行交互作用以提供對問題的解決方案的對象。然而，通過揭示類定義的特性，使我們能夠理解框架機(jī)構(gòu)的對象如何被設(shè)計(jì)成提供能被用戶化和/或擴(kuò)展以應(yīng)付將來要求的實(shí)際解決方案。
動(dòng)物園管理類得到適當(dāng)設(shè)計(jì)，以與動(dòng)物園工作人員登記具有“使用”關(guān)系。框架設(shè)計(jì)者將動(dòng)物園管理和動(dòng)物園登記類設(shè)計(jì)成ZAF的核心功能，因?yàn)樵O(shè)計(jì)者決定不讓ZAF的用戶修正作為這些類定義成員的對象的行為。動(dòng)物園工作人員登記—它與動(dòng)物園工作人員類具有所謂的“訪問包含關(guān)系”，只是定義一個(gè)對象的類，該對象包含了所有的動(dòng)物園工作人員對象。因此，動(dòng)物園工作人員登記包括用于list_zoo_keepers()操作的定義。如在后面所要描述的，該操作用于向請求該清單的其他對象提供動(dòng)物園工作人員對象的清單。
圖3顯示了動(dòng)物園管理者類的較低層面。由于動(dòng)物園管理者類的對象負(fù)責(zé)ZAF的總體控制，動(dòng)物園管理者類被設(shè)計(jì)成包括執(zhí)行面向動(dòng)物園管理的任務(wù)。該類定義包括以下五種操作5_minute_timer()、add_animal()、add_containment_unit()、add_zoo_keeper()、以及start_zoo_admin()。
start_zoo_admin()操作用于啟動(dòng)ZAF。即，用戶或系統(tǒng)管理者將與start_zoo_admin()操作相互作用，以開始通過ZAF對動(dòng)物園進(jìn)行管理。start_zoo_admin()操作用于啟動(dòng)5_minute_timer()操作，從而使5_minute_timer()每五分鐘就命令動(dòng)物園工作人員對象出來并檢查動(dòng)物園動(dòng)物。add/delete_zoo_keeper()操作用于與ZAF的用戶進(jìn)行相互作用，以定義增加的動(dòng)物園工作人員(即增加的動(dòng)物園工作人員類)，并加上增加的動(dòng)物園工作人員(即動(dòng)物園工作人員對象)，以及除去動(dòng)物園工作人員類和/或?qū)ο?。如從以下描述可見，各個(gè)動(dòng)物園工作人員對象用于執(zhí)行具體的動(dòng)物園任務(wù)。因此，ZAF的用戶自然很希望加上一個(gè)動(dòng)物園工作人員定義和對象，以處理附加的動(dòng)物園任務(wù)或除去不再需要的對象定義。ZAF框架設(shè)計(jì)者已經(jīng)通過將動(dòng)物園工作人員機(jī)構(gòu)設(shè)計(jì)成可擴(kuò)展功能來提供這種靈活性。
象add/delete_zoo_keeper()操作一樣，add/delete_animal()操作用于與用戶進(jìn)行相互作用，以定義增加的動(dòng)物園動(dòng)物類和對象，并除去不再需要的類和對象。同樣，動(dòng)物園需要加上和除去動(dòng)物也是很自然的。add/delete_containment_unit()操作用于定義新的圈養(yǎng)單元類和對象，并用于除去不再需要的類和/或?qū)ο?。同樣，框架設(shè)計(jì)者通過將動(dòng)物和圈養(yǎng)單元機(jī)構(gòu)設(shè)計(jì)成可擴(kuò)展功能，而提供了這種靈活性。
參見圖2，動(dòng)物園工作人員類定義同動(dòng)物登記、動(dòng)物、圈養(yǎng)單元登記、以及圈養(yǎng)單元類具有“使用”關(guān)系。由于通過使ZAF的用戶能夠用戶化和擴(kuò)展動(dòng)物園工作人員、動(dòng)物、和圈養(yǎng)單元類，從而增加了ZAF的價(jià)值，ZAF的框架設(shè)計(jì)者已經(jīng)將這些類設(shè)計(jì)為可擴(kuò)展功能。然而，改變動(dòng)物和圈養(yǎng)單元登記種類的行為，將破壞ZAF的基本操作。因此，框架設(shè)計(jì)者將這些種類設(shè)計(jì)成ZAF的核心功能。
圖4是動(dòng)物園工作人員類的類圖。然而，在描述圖4的細(xì)節(jié)之前，先應(yīng)該指出的是，圖4所示的類定義是按照所謂的類層次結(jié)構(gòu)的簡單順序排列的。代表類層次結(jié)構(gòu)中最一般/抽象類的類，象動(dòng)物園工作人員類，被稱為層次結(jié)構(gòu)的基本類。在類層次結(jié)構(gòu)中類的順序，從最一般至最不一般(即從一般至特殊)。不那樣一般的類(例如喂養(yǎng)者類)從更為一般的類(在此情況下即為動(dòng)物園工作人員類)繼承了特性。這樣，喂養(yǎng)者、獸醫(yī)、和溫度控制者類定義，被稱為動(dòng)物園工作人員類的子類。繼承機(jī)構(gòu)將結(jié)合圖5而得到更為詳細(xì)的描述。
如圖4所示，動(dòng)物園工作人員類定義包含單個(gè)操作定義，即check_animals()操作定義。讀者還應(yīng)該注意的是，動(dòng)物園工作人員類定義被標(biāo)為抽象類。抽象類沒有對象作為它們的成員，而是被用來定義用于它們的子類的公共接口/協(xié)議。當(dāng)一個(gè)類的至少一個(gè)操作定義是純虛擬操作定義時(shí)，該類被稱為抽象類。純虛擬操作定義只是為了定義該操作的子類定義的公共接口而設(shè)計(jì)的。換言之，實(shí)際行為(即數(shù)據(jù)和操作)的設(shè)計(jì)，留給了子類自己。在動(dòng)物園工作人員類定義的情況下，喂養(yǎng)者、獸醫(yī)和溫度控制者子類定義了純虛擬check_animals()操作定義的具體實(shí)施，該定義被包含在動(dòng)物園工作人員類中。當(dāng)一個(gè)操作被設(shè)定為等于0時(shí)，它被標(biāo)為純虛擬操作。
但重要的是要注意，純虛擬操作定義的公共接口必須被所有的子類所確認(rèn)，從而要求對象(稱為用戶對象)能夠在不需要知道服務(wù)器對象的具體子類的情況下使用子類成員對象(稱為服務(wù)器對象)。例如，每當(dāng)由動(dòng)物園動(dòng)物類定義的對象需要具體進(jìn)行的行動(dòng)時(shí)，它與動(dòng)物園工作人員對象相互作用。由于至這些對象的接口以動(dòng)物園工作人員抽象基本類定義并被保留在用于check_animals()操作的子類定義中，動(dòng)物園管理者對象不需要具體知道任何服務(wù)器對象的子類。這使得不需要在執(zhí)行行動(dòng)的過程中(即在動(dòng)物園管理者對象的部分上)進(jìn)行該行動(dòng)。利用了抽象類特性的設(shè)計(jì)(諸如ZAF設(shè)計(jì))被稱為多形的。
多形對于OO框架設(shè)計(jì)是非常重要的，因?yàn)樗试S某些事情進(jìn)行(稱為實(shí)施)的方式被改變或擴(kuò)展，而不影響依賴于行動(dòng)實(shí)際上完成的事實(shí)的機(jī)構(gòu)。換言之，用戶對象只需要理解某些對象執(zhí)行某些功能，而不是這些功能實(shí)際上是如何執(zhí)行的。這是適當(dāng)設(shè)計(jì)的OO框架可被容易得到用戶化和擴(kuò)展以滿足將來要求的一個(gè)方式。
如上所述，框架設(shè)計(jì)者適當(dāng)設(shè)計(jì)ZAF框架，從而使動(dòng)物園工作人員對象與動(dòng)物和圈養(yǎng)單元對象相互作用，以執(zhí)行它們各自的任務(wù)。圖5是類圖，顯示了動(dòng)物抽象類的類層次結(jié)構(gòu)。由于動(dòng)物類定義用于代表動(dòng)物園動(dòng)物的特性和行為，框架設(shè)計(jì)者以反映這種作用的方式設(shè)計(jì)動(dòng)物抽象類。如所示，示例性的動(dòng)物類定義包括數(shù)據(jù)定義feed freq、location、和temp_range以及操作定義get_temp_range()、feed()、needs_food()、needs_vet_visit()和vet_visit()。
為了概述這種框架，不需要解釋各個(gè)定義的細(xì)節(jié)。然而，temp_range數(shù)據(jù)定義和get_temp_range()及feed()操作定義是良好的框架設(shè)計(jì)選擇的例子。
feed()操作定義用于完成動(dòng)物的實(shí)際喂養(yǎng)(即通過具體的喂養(yǎng)設(shè)備，未顯示)。feed()操作是純虛擬操作。同樣，這意味著類的設(shè)計(jì)是這樣的，即執(zhí)行所需功能的實(shí)際機(jī)構(gòu)被留給子類來定義。在其中作為子類的成員而產(chǎn)生的對象具有特定的需要的情況下，要求子類定義是一種好的設(shè)計(jì)選擇。例如在ZAF框架中，各種動(dòng)物可能需要特定的喂養(yǎng)設(shè)備，這不僅使類屬feed()操作變得困難，而且無價(jià)值。
通過比較，框架設(shè)計(jì)者明確地設(shè)計(jì)了get_temp_range()操作，從而使它不是純虛擬操作定義。這意味著get_temp_range()被類屬地定義為缺省操作。這樣，它被認(rèn)為是虛擬操作。缺省操作被用來向子類提供類屬功能。子類可以簡單地使用該缺省操作，或者它們可以通過再定義來用戶化或擴(kuò)展缺省操作。缺省操作的再定義被稱為超越缺省操作。
哺乳動(dòng)物是動(dòng)物類的一個(gè)子類，且哺乳動(dòng)物類因而繼承了動(dòng)物類的所有特性。哺乳動(dòng)物類還被設(shè)計(jì)為抽象類，這再次意味著它未被設(shè)計(jì)成具有作為其成員而產(chǎn)生的對象，而是得到適當(dāng)設(shè)計(jì)以為其子類提供公共接口。哺乳動(dòng)物子類被進(jìn)一步分成食肉動(dòng)物類和食草動(dòng)物類。
由于feed()操作的定義被留給了子類，食肉動(dòng)物和食草動(dòng)物子類都具有它們自己的feed()操作定義。同樣，這是一個(gè)好的設(shè)計(jì)選擇，因?yàn)槭橙鈩?dòng)物具有與食草動(dòng)物不同的需要。
Temp_range是與具體動(dòng)物的自然習(xí)慣一致的溫度范圍的數(shù)據(jù)定義，且get_temp_range()操作定義是用于獲取具體動(dòng)物的temp_range并將其送回到請求的用戶對象。爬行動(dòng)物子類包含其自己的temp_range數(shù)據(jù)定義和自己的get_temp_range()操作定義。按此方式設(shè)計(jì)ZAF，以指出數(shù)據(jù)定義能象操作定義一樣被超越。由于很多爬行動(dòng)物生活在沙漠條件下，在那里夜間非常冷而白天非常熱，缺省的temp_range定義在爬行動(dòng)物類中被超越，以包括時(shí)間和溫度信息(在圖5中沒有明確顯示)。這是另一個(gè)好的設(shè)計(jì)選擇，因?yàn)樗沟肸AF能夠通過允許根據(jù)一天中的時(shí)間和圈養(yǎng)單元本身當(dāng)前的溫度來調(diào)節(jié)溫度，從而以不同于其他圈養(yǎng)單元的方式處理爬行動(dòng)物圈養(yǎng)單元。
圖6是類圖，顯示了圈養(yǎng)單元類的較低層面。該圈養(yǎng)單元類包含虛擬操作定義adjust_temp()。adjust_temp()定義限定了實(shí)際用于調(diào)節(jié)(即，經(jīng)過未顯示的加熱和冷卻裝置)動(dòng)物園的圈養(yǎng)單元溫度的接口和機(jī)構(gòu)。動(dòng)物園對象如何相互作用除了設(shè)計(jì)構(gòu)成解決具體的編程問題的對象之外，框架設(shè)計(jì)者還必須設(shè)計(jì)各個(gè)對象是如何相互作用的。換言之，對象必須以利用其設(shè)計(jì)方式的方式進(jìn)行相互作用。如上所述，為對象所定義操作在為對象所定義的數(shù)據(jù)上進(jìn)行操作的方式，被稱為對象的行為。雖然對象可以具有獨(dú)立實(shí)體的特征，但各個(gè)對象在與其他對象發(fā)生聯(lián)系時(shí)呈現(xiàn)一致的行為仍然是非常重要的。一致的行為是重要的，因?yàn)閷ο笠蕾嚻渌麑ο蟮囊恢滦袨?，以使它們自己能夠呈現(xiàn)出一致的行為。實(shí)際上，一致的行為是如此地重要，以致對象的行為經(jīng)常被稱為對象與其他對象具有的契約。當(dāng)對象不呈現(xiàn)出一致的行為時(shí)，稱它已經(jīng)侵犯了與其他對象的契約。
當(dāng)一個(gè)對象的操作需要對第二個(gè)對象控制的數(shù)據(jù)進(jìn)行存取時(shí)，就認(rèn)為它是第二對象的用戶。為了對第二對象控制的數(shù)據(jù)進(jìn)行存取，用戶的一個(gè)操作將調(diào)用或啟動(dòng)第二對象的一個(gè)操作，以獲得對該對象控制的數(shù)據(jù)的存取。被調(diào)用的對象的一個(gè)操作(在此情況下即為服務(wù)器操作)隨后得到執(zhí)行，以存取和/或操縱被所調(diào)用的對象控制的數(shù)據(jù)。
圖7是對象圖，顯示了ZAF的示例性對象是如何進(jìn)行作用以幫助動(dòng)物園工作人員管理動(dòng)物園的。為此概述的目的，不需要對所有ZAF對象的作用進(jìn)行詳細(xì)分析。然而，讀者應(yīng)該看看以下的簡單控制流程，以對OO環(huán)境中的對象如何相互作用來解決問題有初步的理解。
如上所述，對象是作為具體類的成員而產(chǎn)生的。因此，對象Zelda，即動(dòng)物園管理者706，是一個(gè)對象，它是動(dòng)物園管理者的一個(gè)成員(實(shí)際上是唯一的成員)。因此，對象Zelda負(fù)責(zé)ZAF的總體控制。所有的動(dòng)物園工作人員對象都由動(dòng)物園工作人員登記對象(對象700)進(jìn)行了登記。因此，對象Zelda通過調(diào)用動(dòng)物園管理者登記器對象的list_zoo_keepers()操作(步驟1)而獲得了現(xiàn)行動(dòng)物園工作人員的清單。該動(dòng)物園管理者登記器對象700是作為動(dòng)物園工作人員登記類的一個(gè)成員而產(chǎn)生的。為了說明，假定這作為Zelda的5_minute_timer()操作的一部分而每五分鐘發(fā)生一次。動(dòng)物園管理者登記器對象隨后以動(dòng)物園工作人員清單進(jìn)行響應(yīng)(步驟2)。動(dòng)物園工作人員清單包括溫度檢查員Tina(對象714)，獸醫(yī)Vince(對象740)，以及動(dòng)物喂養(yǎng)員Fred(對象752)。各個(gè)動(dòng)物園工作人員都作為動(dòng)物園工作人員類的成員而產(chǎn)生。特別地，對象溫度檢查員Tina、獸醫(yī)Vince、和動(dòng)物喂養(yǎng)員Fred分別是溫度控制者、獸醫(yī)和喂養(yǎng)者子類的成員。
一旦當(dāng)前動(dòng)物園工作人員的清單被送回到對象Zelda 706，對象Zelda通過調(diào)用各個(gè)動(dòng)物園工作人員對象的check_animals()操作，來命令清單中的各個(gè)動(dòng)物園工作人員檢查動(dòng)物。步驟3只顯示了對溫度檢查員Tina的調(diào)用。應(yīng)該注意的是，對象Zelda不需要明白動(dòng)物園工作人員清單中的動(dòng)物園工作人員的類型、清單中動(dòng)物園工作人員對象的數(shù)量、或任何一個(gè)動(dòng)物園工作人員對象的具體特性。對象Zelda利用同一接口(即check_animals()操作)與各個(gè)動(dòng)物園工作人員對象進(jìn)行通信。然后就由各個(gè)動(dòng)物園工作人員對象來執(zhí)行各自的任務(wù)，這些對象正是為完成這些任務(wù)而創(chuàng)立的。各個(gè)動(dòng)物園工作人員對象，通過使用其自己的check_animals()操作，來執(zhí)行其分配的任務(wù)。例如，對象Tina的check_animals()操作，通過調(diào)用Listanimals()操作(步驟4)，從動(dòng)物登記對象獲取當(dāng)前動(dòng)物的清單，并隨后通過調(diào)用List_cont_units()操作從圈養(yǎng)單元登記對象獲取圈養(yǎng)單元清單(步驟6)。通過檢驗(yàn)動(dòng)物清單，對象Tina的check_animals()操作確定在動(dòng)物園中當(dāng)前只登記了兩個(gè)動(dòng)物，蛇Sam(對象728)和獅子Simba(對象718)。
對象Tina的check_animals()操作隨后調(diào)用get_temp_range()操作，以從對象Sam和Simba得到溫度范圍。一旦溫度范圍已經(jīng)被送回，對象Tina的check_animals()操作確定各個(gè)動(dòng)物(即Simba和Sam)所在的圈養(yǎng)單元，并隨后調(diào)用適當(dāng)?shù)娜︷B(yǎng)單元(即在對象Simba的情況下為獅籠7，而在對象Sam的情況下為蛇坑3)的adjust_temp()操作，以調(diào)節(jié)圈養(yǎng)單元的溫度(步驟12和13)。
各個(gè)圈養(yǎng)單元的adjust_temp()操作隨后通過以適合于各個(gè)圈養(yǎng)單元中的動(dòng)物的方式調(diào)節(jié)溫度，而完成控制流程。(即，對于蛇坑3根據(jù)時(shí)間和溫度，對于獅籠7只根據(jù)時(shí)問未調(diào)節(jié)溫度)。讀者應(yīng)該注意的是，checkanimals()操作與adjust_temp()操作之間的關(guān)系是多形的。換言之，對象Tina 714的check_animals()操作不要求具體知道各個(gè)adjust_temp()操作是如何執(zhí)行其任務(wù)的。check_animals()操作只需要留在接口并調(diào)用adjust_temp()操作。在此之后，就由各個(gè)adjust_temp()操作來以適當(dāng)?shù)姆绞綀?zhí)行它們的任務(wù)。
在此處，需要再次指出的是，ZAF系統(tǒng)是一個(gè)非常簡單的框架，它只是用于使不熟悉的讀者理解框架的某些基本概念，以更好地理解本發(fā)明的好處和優(yōu)點(diǎn)。從以下的詳細(xì)描述，這些好處和優(yōu)點(diǎn)將變得顯而易見。詳細(xì)描述圖8是根據(jù)本發(fā)明構(gòu)成的計(jì)算機(jī)系統(tǒng)30的框圖。該計(jì)算機(jī)系統(tǒng)包括中央處理單元(CPU)32，它響應(yīng)操作指令而運(yùn)行，而這些指令是從操作/顯示接口34接收的，且計(jì)算機(jī)系統(tǒng)通過系統(tǒng)總線36與該接口相聯(lián)。該CPU還通過系統(tǒng)總線與一個(gè)主存儲(chǔ)器38相聯(lián)，而主存儲(chǔ)器38由各種數(shù)據(jù)結(jié)構(gòu)顯示，包括應(yīng)用程序40、對象42、數(shù)據(jù)44、和操作系統(tǒng)46。主存儲(chǔ)器38被顯示為單個(gè)的實(shí)體，但本領(lǐng)域的技術(shù)人員會(huì)理解，該主存儲(chǔ)器可以包括隨機(jī)存取存儲(chǔ)器(RAM)、硬盤驅(qū)動(dòng)器、光盤驅(qū)動(dòng)器和包含邏輯分段存儲(chǔ)單元的其他存儲(chǔ)裝置的組合。
操作系統(tǒng)46最好支持面向?qū)ο蟮某绦蛟O(shè)計(jì)環(huán)境，例如由C++程序設(shè)計(jì)語言提供的環(huán)境。應(yīng)用程序40由用戶通過操作/顯示接口34激活或調(diào)用。該應(yīng)用程序可以用包括C++在內(nèi)的各種語言寫成。對象42是面向?qū)ο蟮某绦蛟O(shè)計(jì)語言(諸如C++)的對象數(shù)據(jù)結(jié)構(gòu)。
計(jì)算機(jī)系統(tǒng)30還包括直接存取存儲(chǔ)裝置(DASD)接口48，它與系統(tǒng)總線36相聯(lián)，還與DASD 50相聯(lián)。本領(lǐng)域的技術(shù)人員會(huì)理解，DASD 50能夠接收并讀取包含于機(jī)器可讀存儲(chǔ)裝置52中的程序產(chǎn)品，諸如其上記錄有程序指令的磁介質(zhì)盤，而這些指令的執(zhí)行將實(shí)施本發(fā)明的框架。存儲(chǔ)裝置52還可包括諸如光盤介質(zhì)和其他機(jī)器可讀存儲(chǔ)裝置。計(jì)算機(jī)系統(tǒng)30還可包括網(wǎng)絡(luò)接口54，它使得CPU 32能夠通過網(wǎng)絡(luò)58與其他計(jì)算機(jī)系統(tǒng)56之間進(jìn)行通信。其他的計(jì)算機(jī)系統(tǒng)56可包括例如在構(gòu)造上與示例性的計(jì)算機(jī)系統(tǒng)30類似的計(jì)算機(jī)系統(tǒng)。以此方式，計(jì)算機(jī)系統(tǒng)30能夠在已經(jīng)用眾所周知的方法建立起計(jì)算機(jī)系統(tǒng)之間的通信之后，通過網(wǎng)絡(luò)58將數(shù)據(jù)接收到主存儲(chǔ)器38中，而這些眾所周知的方法是本領(lǐng)域的技術(shù)人員能夠理解的，不需要進(jìn)一步的說明。網(wǎng)絡(luò)接口54是這樣的裝置，即框架用戶借助它接收來自其他網(wǎng)絡(luò)用戶的消息并將消息傳送給其他網(wǎng)絡(luò)用戶。消息處理序列圖在描述面向?qū)ο蟮目蚣軝C(jī)構(gòu)之前，通過考慮圖8的計(jì)算機(jī)系統(tǒng)進(jìn)行的消息處理步驟序列，將能夠更好理解本發(fā)明的最佳實(shí)施例。圖9是處理圖，顯示了當(dāng)消息由圖8所示的系統(tǒng)處理時(shí)消息所受到的處理步驟。圖8的系統(tǒng)啟動(dòng)框架機(jī)構(gòu)，以從消息隊(duì)列獲取消息。該系統(tǒng)為接收者清單中的每一條目處理消息。因此，系統(tǒng)或者將消息提供給本地分送機(jī)構(gòu)，或把消息送到遠(yuǎn)程地址，或者指明消息無效或由于其他原因而不能被分送。在開始時(shí)，消息被接收到輸入隊(duì)列中，如圖9中的第一個(gè)圓圈所示，表明“排隊(duì)”狀態(tài)。當(dāng)從輸入隊(duì)列獲取到消息時(shí)，可以說進(jìn)入了“處理”階段，如圖9中的第二圓圈所示。最后，當(dāng)所有的處理都完成時(shí)，可以說消息進(jìn)入了“已經(jīng)處理”狀態(tài)，如圖9的第三個(gè)圓圈所示。通常，處理過的消息被簡單地從處理系統(tǒng)的輸入隊(duì)列中刪除。
圖10代表了操作步驟的更為詳細(xì)的顯示，這些步驟包括了消息的“處理”階段。這些操作步驟用四個(gè)圓圈表示。圖10顯示，在處理期間，消息首先受到尋址處理，隨后是由預(yù)分送步驟表征的步驟。消息至下一個(gè)目的地的實(shí)際傳送，由分送步驟表示。最后，在消息完成了分送處理步驟之后，處理階段以管理處理步驟結(jié)束。
對“處理”階段中的處理步驟的這種簡化表示，在圖11中得到了更為詳細(xì)的顯示；圖11代表在消息處理階段中進(jìn)行的處理步驟序列。在圖11中，從消息隊(duì)列中獲取消息被用“獲得消息”事件表示，該事件使消息經(jīng)歷清單擴(kuò)展(List Exp.)處理。在清單擴(kuò)展期間，系統(tǒng)重復(fù)地把接收者清單條目擴(kuò)展成目的地地址。該擴(kuò)展可以是一對一的—如其中接收者清單條目代表了單個(gè)的接收者，也可以是一對多個(gè)的—如其中接收者清單條目代表了多個(gè)接收者的分布清單。以此方式，接收者清單得到擴(kuò)展，從而識別一或多個(gè)電子郵件目的地地址。例如，一個(gè)電子郵件地址可以標(biāo)明傳統(tǒng)的互聯(lián)網(wǎng)絡(luò)地址，該地址包括域名和子領(lǐng)名。在最佳實(shí)施例中，電子郵件目的地地址定義了接收者的消息協(xié)議類型。只要有要處理的接收者清單條目，系統(tǒng)就繼續(xù)擴(kuò)展它們。在消息受到清單擴(kuò)展時(shí)，消息的內(nèi)容沒有改變。
圖11顯示，當(dāng)接收者清單已經(jīng)被完全處理成目的地地址清單且沒有等待識別的接收者時(shí)，消息受到地址分解(Address Resolution)處理。在地址分解中，系統(tǒng)將各個(gè)目的地地址分解成分送的方法，諸如SNADS協(xié)議、SMTP協(xié)議等等。圖11中的顯示為“分布清單改變”的、從地址分解處理圓圈向回指向清單擴(kuò)展處理圓圈的箭頭，表示地址分解處理可以造成接收者清單的改變。例如，可以在這樣的情況下出現(xiàn)，即在清單擴(kuò)展處理中識別出的目的地地址在地址分解期間被認(rèn)為需要一個(gè)消息路由，而該消息路由要求的目的地地址不同于清單擴(kuò)展所分配的地址。在此情況下，重復(fù)清單擴(kuò)展處理。例如，如果必須將消息送到并非接收者與之相聯(lián)的網(wǎng)絡(luò)網(wǎng)關(guān)時(shí)，就會(huì)出現(xiàn)這種重新分配路由的情況。
如果地址分解不產(chǎn)生改變分配清單事件，則它產(chǎn)生得到適當(dāng)尋址的消息。這意味著消息已經(jīng)被分配了目的地地址、消息協(xié)議類型和狀態(tài)。如圖11所示，這意味著消息已經(jīng)得到適當(dāng)尋址且消息隨后在信封處理階段得到處理。
在最佳實(shí)施例的電子郵件處理系統(tǒng)中，表示為文字串的消息內(nèi)容由系統(tǒng)“信封”所包裹，該信封表明協(xié)議、發(fā)出者、接收者等等。在信封處理期間，產(chǎn)生了適當(dāng)?shù)南到y(tǒng)信封并使它與消息聯(lián)系起來。圖11的信封處理圓圈對應(yīng)于圖10所示的“預(yù)分送”階段的開始。當(dāng)包封處理完成時(shí)，進(jìn)行附件轉(zhuǎn)換。在最佳實(shí)施例的圖8的系統(tǒng)中，消息的內(nèi)容被稱為附件。因此，消息被處理成信封和相聯(lián)系的附件。一個(gè)附件可以包含文本文字、語音、圖形、或視頻數(shù)據(jù)，或任何其他能夠以電子表示存儲(chǔ)并在計(jì)算機(jī)網(wǎng)絡(luò)上傳送的信息。
在附件轉(zhuǎn)換中，消息的文字串根據(jù)與各個(gè)接收者相聯(lián)系的電子郵件系統(tǒng)而得到處理。例如在一個(gè)電子郵件系統(tǒng)上的接收者可能要求文本用ASCII顯示字符表示，而在另一系統(tǒng)上的接收者可能要求文本用EBCDIC(擴(kuò)展二進(jìn)編碼十進(jìn)制互換碼)字符表示。附件轉(zhuǎn)換包括任何所需的文本轉(zhuǎn)換和用于目的地系統(tǒng)的其他的格式處理?？蚣苡脩艨梢灾付ㄓ糜诓煌瑓f(xié)議的這種消息處理，而不修正框架的對象類，以此方式能夠在初始系統(tǒng)組成之后方便地容納所加的協(xié)議。
在附件轉(zhuǎn)換之后，圖11顯示出消息處理移到安全和權(quán)限階段。在此階段，對消息進(jìn)行保密檢查。這種處理能夠根據(jù)這些保密檢查而改變分送狀態(tài)，從而影響消息的文本。例如，根據(jù)保密檢查，消息文本可能受到限制、掩碼或編碼。安全和權(quán)限完成了圖10所示的消息處理的“預(yù)分送”階段。下一個(gè)階段是“分送”階段。
為了分送消息，系統(tǒng)首先進(jìn)行本地分送檢查。即，如果消息具有“本地”狀態(tài)，則假定消息的接收者位于處理該消息的當(dāng)前系統(tǒng)上。因此，框架系統(tǒng)將消息送到一個(gè)本地消息分送處理器，以完成消息處理。完成至各個(gè)目的地的消息分送所需的具體處理，不是框架系統(tǒng)進(jìn)行的處理的一部分。
如果消息沒有“本地”狀態(tài)，則認(rèn)為不能完成本地分送，且如圖11所示，消息處理移到消息轉(zhuǎn)送階段。在消息轉(zhuǎn)送階段，檢查各個(gè)消息接收者的狀態(tài)。如果與接收者相聯(lián)系的狀態(tài)是“遠(yuǎn)程”狀態(tài)，則消息被從本地網(wǎng)絡(luò)移出且該消息被轉(zhuǎn)送到另一網(wǎng)絡(luò)供進(jìn)一步處理。以此方式，框架實(shí)施的系統(tǒng)起著網(wǎng)絡(luò)網(wǎng)關(guān)處理器的作用。
圖11中所示的下一個(gè)處理狀態(tài)，是未分送處理。在未分送處理中，檢查各個(gè)接收者的消息狀態(tài)。如果該狀態(tài)指出一個(gè)未分送事件，則任何具體的處理都完成。例如，如果消息不能被分送到具體的接收者，則一個(gè)未分送表示可以被立即送回到發(fā)出者。其他的事件，諸如通信故障，如果需要的話，也能夠得到顯示。同樣，框架用戶能夠方便地指定這種處理并能夠在框架的規(guī)定之內(nèi)方便地改變這種處理而不需要大的修正。
在未分送處理完成之后，圖11所示的消息處理進(jìn)行到附件管理階段。該處理對應(yīng)于圖10中所示的“管理”階段的開始。附件管理處理只在消息具有附件時(shí)進(jìn)行。圖11顯示消息隨后經(jīng)歷了會(huì)計(jì)處理。在這種會(huì)計(jì)處理中，消息的文本不改變。會(huì)計(jì)收費(fèi)、處理費(fèi)用等等能夠得到解決，且費(fèi)用被計(jì)帳或者產(chǎn)生帳單。另外，系統(tǒng)操作統(tǒng)計(jì)能夠得到累積或更新。當(dāng)會(huì)計(jì)狀態(tài)完成時(shí)，消息處理完成，且消息通常被從系統(tǒng)中刪除。于是，框架機(jī)構(gòu)操作完成，其他的系統(tǒng)處理能夠得到恢復(fù)。
本發(fā)明提供了一種面向?qū)ο蟮目蚣堋＠迷摽蚣馨l(fā)展的郵遞服務(wù)器系統(tǒng)的操作，可以借助圖9、10和11的狀態(tài)圖來理解。本領(lǐng)域的技術(shù)人員則理解框架對象和它們的關(guān)系，且它們的處理也以面向?qū)ο蟮某绦蛟O(shè)計(jì)表示得到了完全而準(zhǔn)確的描述。因此，下面將根據(jù)上述的郵遞服務(wù)器框架機(jī)構(gòu)類，采用與上述關(guān)于動(dòng)物園工作人員例子的圖1至7描述的圖件相類似的類圖和對象圖，描述最佳實(shí)施例的框架。類別/類12是圖8的計(jì)算機(jī)系統(tǒng)中實(shí)施的框架的類別圖。本領(lǐng)域的技術(shù)人員會(huì)理解的是，圖12中所示的類別代表包含數(shù)據(jù)屬性和行為并儲(chǔ)存在圖8的框圖所示主存儲(chǔ)器中的面向?qū)ο蟮某绦蛟O(shè)計(jì)(OOP)對象的集合。這種對象可在例如支持C++程序設(shè)計(jì)語言的計(jì)算機(jī)系統(tǒng)操作環(huán)境中實(shí)施。
圖12的類別圖的框架表示，顯示了框架的初級類類別成份或機(jī)構(gòu)。所有機(jī)構(gòu)都以它們相應(yīng)類類別框中的E標(biāo)出，以表示它們都是可擴(kuò)展的類類別，意味著它們的對象類和屬性能夠得到擴(kuò)展從而被框架用戶用戶化。被稱為消息中心的類類別包含框架所要產(chǎn)生和處理的消息。圖12顯示，消息中心類類別與稱為消息的類類別具有“使用”關(guān)系，消息包含對象清單形式的電子郵件消息信息，而該對象存儲(chǔ)的信息允許擴(kuò)展框架以處理消息中心的電子郵件消息。
從消息中心類別框至消息類別框的連接線所表示的“使用”關(guān)系，被標(biāo)為C，以表示它是框架用戶所不能改變的核心關(guān)系。該“使用”關(guān)系代表了這樣的聯(lián)系，即其中消息中心機(jī)構(gòu)處理或使用來自消息的消息。圖12顯示，消息類類別又與稱為原始接收者清單、接收者清單、信封清單、附件訪問清單、報(bào)告內(nèi)容清單、報(bào)告對象清單、發(fā)出者清單、和回答對象清單的類類別具有“使用”關(guān)系。這些類類別將在下面詳細(xì)描述。這些關(guān)系(連線)被標(biāo)為C，以表示它們不能由框架用戶改變。即，雖然類屬性和行為是可由用戶擴(kuò)展(改變)的，但類之間的關(guān)系結(jié)構(gòu)是不能改變的。
圖13是類圖，它表示了消息中心類類別的對象。在消息中心類別中的對象和這些對象之間的關(guān)系，被認(rèn)為是框架用戶所不能修正的“核心”特性。消息中心中的對象屬于消息中心類別，并用于啟動(dòng)初始產(chǎn)生所有消息成員對象的方法(也稱為操作)。在最佳實(shí)施例中，以C++程序設(shè)計(jì)語言實(shí)施，消息中心對象通過調(diào)用C++對象產(chǎn)生器方法，而產(chǎn)生消息對象?？蚣軐?shí)施的這種產(chǎn)生方法將依賴于實(shí)施框架的具體程序設(shè)計(jì)語言。
每一個(gè)消息中心對象包括一個(gè)handleIncomingMessage()方法，它產(chǎn)生所要處理的消息對象。這種方法以一個(gè)數(shù)據(jù)串作為其輸入，該數(shù)據(jù)串與相應(yīng)的產(chǎn)生者清單中的對象所標(biāo)明的產(chǎn)生方法一起使用，以產(chǎn)生消息對象的一個(gè)事例。消息中心對象的行為包括圖13所示的processMessage()方法。正是這種方法接收了所要處理的電子郵件消息的內(nèi)容，將其包含在消息對象中。即，該方法將消息的內(nèi)容分析成框架設(shè)計(jì)所期望的對象。
該框架沒有完全定義在消息內(nèi)容上進(jìn)行的處理。處理活動(dòng)的定義是用戶進(jìn)行的框架擴(kuò)展的一部分，該擴(kuò)展完成了作為框架定義的處理電子郵件步驟組的一部分而被調(diào)用的方法。當(dāng)框架的產(chǎn)生方法產(chǎn)生一個(gè)消息中心對象時(shí)，它還產(chǎn)生了稱為消息隊(duì)列的類和所示的三個(gè)產(chǎn)生器清單對象，包括信封產(chǎn)生器清單、附件訪問產(chǎn)生器清單和地址產(chǎn)生器清單。通常，只有一個(gè)單個(gè)的消息隊(duì)列對象，雖然可以有多個(gè)消息中心對象。processMessage()方法連續(xù)地從消息隊(duì)列中除去下一個(gè)消息對象，并調(diào)用該消息對象方法。
圖13顯示出，消息中心類別的消息中心類與消息隊(duì)列類之間的關(guān)系是“具有”關(guān)系，這意味著消息中心類中包含有消息隊(duì)列對象。消息隊(duì)列對象以先進(jìn)先出(FIFO)的方式得到維護(hù)。
消息中心利用消息隊(duì)列類中的對象，對消息對象進(jìn)行跟蹤。圖13顯示出，消息隊(duì)列類包括稱為add()和remove()的方法。add()方法由消息中心用于將對一個(gè)消息對象的引用加到(也稱為登記)消息隊(duì)列上，而remove()方法用于從消息隊(duì)列除去一個(gè)消息對象索引。該對象索引可包括例如一個(gè)消息指針或消息指標(biāo)。這種加和除去操作是用于程序設(shè)計(jì)框架的具體的面向?qū)ο蟮某绦蛟O(shè)計(jì)語言(諸如C++程序設(shè)計(jì)語言)的特征。
在產(chǎn)生了消息對象之后，消息中心利用add()方法將一個(gè)消息訪問加到消息隊(duì)列上，隨后用remove()方法除去FIFO隊(duì)列中的下一個(gè)訪問。在消息對象訪問被從隊(duì)列中除去之后，消息中心對象通過依次調(diào)用導(dǎo)致電子郵件處理的消息類方法，處理訪問的消息對象。這種電子郵件處理方法由框架用戶定義(如下面將進(jìn)一步描述的)并在框架擴(kuò)展時(shí)由用戶通過繼承而產(chǎn)生或?qū)嵤?br> 圖13還顯示出，被稱為消息隊(duì)列的類與被稱為消息的類的具有關(guān)系，從而使消息隊(duì)列“具有”多個(gè)消息對象。即，消息隊(duì)列包括消息對象的一個(gè)集合。一個(gè)消息隊(duì)列對象被消息中心用作特定的容器對象，以保持它已經(jīng)產(chǎn)生但還未處理的各消息對象的關(guān)系。
圖14是消息類的類圖。在該消息類中的對象和這些對象之間的關(guān)系，被認(rèn)為是不能由框架用戶修正的“核心”特性。消息對象具有關(guān)于一段電子郵件的、處理它所需的所有信息。圖14的類圖顯示了與稱為發(fā)出者清單、報(bào)告對象清單、原始接收者清單、附件訪問清單、信封清單、報(bào)告內(nèi)容清單、接收者清單和回答對象清單的類有“具有”關(guān)系的消息類。這些類中的每一個(gè)，都包含清單對象。將這種信息保持在核心類中，有利于對這種存取進(jìn)行組織和控制。以此方式，消息對象具有關(guān)于一段電子郵件的、在框架內(nèi)處理其所需的所有信息。每個(gè)清單對象包含被保存在核心對象中的信息，從而使信息能夠被框架的擴(kuò)展部分所存取。除了接收者清單對象之外，對于每一個(gè)消息對象，最多有一個(gè)唯一的清單對象。
圖14表明，消息類中的對象定義了若干方法。在最佳實(shí)施例中，這些方法包括(按照字母順序)accounting()、attachmentProcessing()、deliverLocal()、deliverRemote()、expandList()、handleNonDelivery()、manageAttachments()、processAuthorization()。這些方法每一個(gè)都包括系統(tǒng)的處理步驟。執(zhí)行這些方法的順序和與它們有關(guān)的處理行為，將在下面結(jié)合框架的對象圖進(jìn)行更為詳細(xì)的描述。選擇這些方法來提供系統(tǒng)所希望的靈活性，并提供增強(qiáng)的系統(tǒng)操作。
消息對象從圖14的發(fā)出者清單、報(bào)告對象清單、原始接收者清單、附件清單、信封清單、報(bào)告內(nèi)容清單、接收者清單和回答對象清單類獲取對象。在消息類中的對象能夠利用下面描述的適當(dāng)操作，從這些類獲取對象。下面將更詳細(xì)地描述所用的這些類和操作。
圖15是發(fā)出者清單的類圖。即，圖15顯示了構(gòu)成框架的發(fā)出者清單類的對象。所示的類與稱為地址的類具有“具有”關(guān)系。連線上的n表示多重地址類。在地址類中的對象與發(fā)出者清單類的關(guān)系，對于框架來說被認(rèn)為是“核心”或不可修正的?？梢杂腥魏螖?shù)目的發(fā)出者清單對象，但每一個(gè)都由唯一的消息對象使用或訪問。發(fā)出者清單對象包含特定電子郵件消息的發(fā)出地址?？蚣懿欢x電子郵件地址格式或它們的內(nèi)容。這種定義是框架用戶進(jìn)行的框架擴(kuò)展的一部分。發(fā)出者清單對象定義兩種方法當(dāng)把一個(gè)新地址加到發(fā)出者清單對象上時(shí)使用的addEntry()，以及當(dāng)存取消息對象的發(fā)出者清單條目中的一個(gè)條目時(shí)使用的retrieveEntry()。
在圖15中，地址類中的類裝飾，表明了它是抽象對象類型的。因此，這個(gè)對象必須作為擴(kuò)展框架的一部分而被子類，以支持特定的電子郵件地址形式，作為其用戶化的一部分。框架的實(shí)施者將需要以此方式來擴(kuò)展地址對象?？蚣茉试S任何數(shù)目的子類地址對象存在在同一框架中。認(rèn)為各個(gè)擴(kuò)展的地址類定義唯一的識別對象類型。對于什么類的地址對象可以處于給定消息的發(fā)出者清單中，沒有發(fā)出者清單對象要求。
在圖15中顯示了框架實(shí)施者可能進(jìn)行的兩種框架擴(kuò)展。一個(gè)地址子類或?qū)ο髷U(kuò)展包含電子郵件地址(在該圖中被顯示為SMTP地址)的互聯(lián)網(wǎng)絡(luò)(Internet)標(biāo)準(zhǔn)SMTP(簡單消息傳送協(xié)議)形式。另一地址子類保持電子郵件地址(在圖中被顯示為SNADS地址)的IBM公司SNADS/OfficeVision(Systems Network Architecture DistributionServices)形式。面向?qū)ο蟮募夹g(shù)允許這些擴(kuò)展的對象類進(jìn)一步定義它們自己的具體方法或?qū)傩?。這些具體子類不是框架定義的一部分，但可以是它們所支持的一部分，如框架實(shí)施者所要求的那樣。
圖16是類圖，顯示了構(gòu)成框架的信封清單類的對象。該類與稱為信封的類具有“具有”關(guān)系。信封類中的對象與信封清單類的關(guān)系，被認(rèn)為是“核心”，這意味著在框架方面它是不可修正的?？梢杂腥魏螖?shù)目的信封清單對象，但每一個(gè)都由單個(gè)的消息對象事例所使用或訪問。一個(gè)信封清單對象包含特定電子郵件消息的信封對象清單。一個(gè)信封對象由框架定義，以保持有關(guān)電子郵件消息的信息，諸如優(yōu)先權(quán)、標(biāo)題、主題等等。該信息也稱為電子郵件“標(biāo)頭”信息，因?yàn)樗蛳⒎?wù)描述了電子郵件消息的屬性，但不是消息的內(nèi)容。因此，有一個(gè)與電子郵件消息相聯(lián)系的信封對象，且信封對象有助于確定當(dāng)電子郵件消息被框架系統(tǒng)傳送到消息接收者時(shí)它將受到的處理。
本發(fā)明的框架不定義信封的格式或它們的內(nèi)容。其設(shè)計(jì)允許很多信封對象，它們是單個(gè)的電子郵件消息的信封清單的一部分。每一個(gè)都可以被產(chǎn)生，用以保持不同的信息或關(guān)于一段電子郵件的內(nèi)容相同但格式不同的信息。用具體例子說明的信封清單對象的實(shí)際內(nèi)容，可作為消息對象處理的一部分而被加上或改變。信封清單對象定義稱為add()(它在將新的信封加到信封清單上時(shí)使用)和retrieve()(它在存取消息對象的信封清單中的條目時(shí)使用)的方法。
稱為信封的類在圖16中被顯示為抽象基本類?？蚣艿脑O(shè)計(jì)假定，該類中的對象被再分類，作為擴(kuò)展框架以支持特定的電子郵件信封格式(或多個(gè)可能的格式)，作為其用戶化的一部分?？蚣艿膶?shí)施者必須以此方式擴(kuò)展信封對象?？蚣茉试S任何數(shù)目的子類信封對象存在于同一框架中。假定各個(gè)擴(kuò)展的信封類定義了唯一的識別對象類型。沒有如什么類的信封對象可能處于給定消息的信封清單中這樣的信封清單對象要求。
圖16顯示了框架實(shí)施者可能會(huì)作出的三種框架擴(kuò)展。一個(gè)信封對象擴(kuò)展設(shè)計(jì)成保持電子郵件消息屬性的SMTP形式(在圖中被示為SMTP信封)。另一個(gè)擴(kuò)展設(shè)計(jì)成保持電子郵件消息屬性的IBM公司SNADS/OfficeVision形式(在圖中被顯示為SNADS信封)。另一個(gè)擴(kuò)展保持電子郵件消息屬性的“通用”或非協(xié)議指定形式(在圖中被顯示為通用信封)。這些擴(kuò)展對象能夠進(jìn)一步定義具體的方法或?qū)傩?，這些是框架實(shí)施者確定的其所要求的支持的一部分。信封對象定義了兩個(gè)方法當(dāng)改變信封時(shí)使用的change()，和用于獲取信封的協(xié)議識別類型的type()。
圖17是類圖，顯示了構(gòu)成框架的接收者清單類的對象。接收者對象與接收者清單類的關(guān)系被認(rèn)為是“核心”或就框架方面不可修正的?？蚣芏x了一個(gè)接收者對象，以保持如電子郵件地址所指定的關(guān)于電子郵件消息的目的地的信息?？蚣懿欢x電子郵件地址形式或它們的內(nèi)容。該定義是框架實(shí)施者進(jìn)行的框架擴(kuò)展的一部分。框架允許增加、改變或更換接收者，作為消息處理的一部分。
接收者清單類被設(shè)計(jì)成支持框架的關(guān)鍵功能“分解”電子郵件地址。分解電子郵件地址意味著確定把電子郵件消息傳送到其接收者所需的一組特定的電子郵件服務(wù)和支持。這些服務(wù)和支持是用對象類方法實(shí)施的。分解電子郵件地址，使框架能夠具有靈活性，以支持多個(gè)類對象擴(kuò)展，這些擴(kuò)展的每一個(gè)都支持處理電子郵件消息的不同的要求?？蚣芸梢缘玫綌U(kuò)展，以支持子類方法中的多個(gè)特定的電子郵件功能組。這些組中的任何一個(gè)，或者也許它們?nèi)?，都可以作為單個(gè)的消息對象的處理的一部分而得到調(diào)用。在分解電子郵件地址時(shí)，消息的接收者清單得到處理，以產(chǎn)生由它們的框架類擴(kuò)展定義的單獨(dú)具體的對象。例如，包括SNADS地址的電子郵件消息接收者清單，被分解成SNADS接收者清單對象，該對象因而定義了一個(gè)SNADS協(xié)議接收者。
當(dāng)產(chǎn)生消息對象時(shí)，假定一段電子郵件的所有地址都處于未分解狀態(tài)。作為處理每一個(gè)消息對象的框架的一部分而調(diào)用的方法之一，是resolveAddresses()方法，它是針對消息對象而調(diào)用的。resolveAddresses()方法又使用了為接收者清單對象類定義的resolveAddresses()。這種方法對未分解的接收者清單對象進(jìn)行操作，該對象屬于接收者清單對象類的子類，并被預(yù)定義為框架的核心部分，如在其類云中的C所示?？蚣軓奈捶纸獾慕邮照咔鍐沃谐サ刂窏l目對象，并將它們加到已經(jīng)作為框架實(shí)施者的擴(kuò)展的一部分而定義的另一接收者清單類對象上。以此方式，框架實(shí)質(zhì)上把未分解的地址“引導(dǎo)”(或分解)到適當(dāng)?shù)慕邮照咔鍐螌ο箢愔小擃惥哂卸x的、用于處理具有該類接收者地址的方法。
當(dāng)各個(gè)具體的地址對象類型的地址對象存在于消息的未分解的接收者清單對象中時(shí)，該類型必須受到resolveAddresses()方法的支持。resolveAddresses()方法將來自未分解清單的地址對象重新劃分成適當(dāng)接收者類型的清單。因此，resolveAddresses()方法可以說是有助于地址借助該方法的功能來“分解自己”，并被從未分解的接收者清單中除去并被加到附在同一個(gè)消息事例上的另一個(gè)接收者清單對象中。圖17所示的接收者清單類是一個(gè)抽象基本類。框架設(shè)計(jì)假定在此類中的對象作為框架擴(kuò)展的一部分而得到再劃分，以支持具體的電子郵件附件接收者清單作為框架用戶的框架用戶化的一部分?？蚣艿挠脩粢源朔绞綌U(kuò)展接收者清單類。
圖17中顯示了框架用戶可能進(jìn)行的兩種示例性框架擴(kuò)展。一個(gè)接收者清單對象擴(kuò)展被設(shè)計(jì)成定義接收者的接收者清單對象類，它被標(biāo)明為被分解成電子郵件方法的互聯(lián)網(wǎng)絡(luò)標(biāo)準(zhǔn)SMTP形式(在圖中被顯示為SMTP接收者清單)。另一接收者清單對象擴(kuò)展被設(shè)計(jì)成定義接收者的接收者清單對象類，它被分解成電子郵件的IBM公司/OfficeVision形式(在圖中被顯示為SNADS接收者清單)。圖17顯示了擴(kuò)展的框架，從而使框架用戶能夠支持需要這兩種處理的消息。由于單個(gè)的消息可以具有多個(gè)接收者，所以在擴(kuò)展的框架處理每個(gè)消息時(shí)，地址可以被分解成這兩個(gè)接收者清單中的一個(gè)或兩個(gè)接收者清單。這些擴(kuò)展的對象可以進(jìn)一步定義具體的方法或?qū)傩?，它們被?shí)施者視為它們所需的支持的一部分。
圖17顯示出，接收者清單對象定義了以下方法當(dāng)把新的地址條目對象加到接收者清單上時(shí)使用的addEntry()方法，和expandAddresses()方法—它在當(dāng)把接收者清單地址條目對象由代表一系列電子郵件地址的單個(gè)電子郵件地址(如在命名分布清單中那樣)擴(kuò)展成多個(gè)地址條目對象時(shí)使用。另一方法是resolveAddresses()，它在當(dāng)處理未分解的接收者清單對象的地址條目對象時(shí)使用。當(dāng)接收者清單對象存取消息對象的接收者清單類型對象條目中的地址條目對象時(shí)，使用一個(gè)retrieveEntry()方法。當(dāng)從消息對象的接收者清單中除去地址條目對象時(shí)，使用一個(gè)removeEntry()方法。這是需要的，以實(shí)施“分解”功能，因?yàn)檫@意味著作為其分解的一部分從未分解的接收者清單除去了一個(gè)地址條目對象。最后，當(dāng)取代消息對象的接收者清單中的一個(gè)地址條目對象時(shí)，使用了一個(gè)replaceEntry()方法。這是需要的，以實(shí)施“取代”功能，因?yàn)檫@意味著從任何接收者清單中除去了一個(gè)地址條目對象并用另一地址條目對象取代。應(yīng)該注意的是，調(diào)用removeEntry()方法并隨后進(jìn)行addEntry()方法，可以代替replaceEntry()方法，但與這兩個(gè)方法的結(jié)合相比，在rplaceEntry()方法如何工作上具體有所不同，且具有單獨(dú)的方法使這些不同能夠存在于框架內(nèi)。
接收者清單類中的另一個(gè)對象是地址條目對象?？蚣芤笕魏卧賱澐值慕邮照咔鍐螌ο蟊仨氃L問地址條目對象。地址條目對象訪問稱為接收者數(shù)據(jù)的類的具體框架對象以及接收者的地址對象。接收者數(shù)據(jù)對象為電子郵件地址特定的屬性提供了一個(gè)開放區(qū)，這些屬性諸如其與接收者清單中的地址對象的每一事例有關(guān)的狀態(tài)(即本地、遠(yuǎn)程或未分送)。地址對象的類與上述的發(fā)出者清單對象部分中描述的相同。
圖18顯示類圖，顯示了框架的附件訪問清單的固有結(jié)構(gòu)。附件訪問對象與附件訪問清單類的關(guān)系，被認(rèn)為是“核心”的，或就框架來說是不可修正的?？蚣懿欢x電子郵件附件訪問格式或它們的內(nèi)容?？蚣艿脑O(shè)計(jì)假定(但不要求)附件通常是對可能是消息內(nèi)容的存儲(chǔ)單元的訪問。即，消息本體被作為附件。框架設(shè)計(jì)允許任何數(shù)目的附件處于消息對象的附件訪問清單中，并允許附件被增加或改變，以作為消息處理的一部分?？梢杂腥魏螖?shù)目的附件訪問清單對象，但每一個(gè)都被唯一的消息對象所使用或訪問?？蚣懿欢x也不限制一個(gè)電子郵件消息上的附件訪問對象對作為另一消息的同一物理附件訪問進(jìn)行訪問。一個(gè)附件清單包含消息的附件清單。由框架定義一個(gè)附件，用以保持關(guān)于電子郵件消息的內(nèi)容信息，它由作為附件清單條目的一部分的訪問確定。這也稱為電子郵件“本體”或“內(nèi)容”信息。
框架也不定義附件格式或它們的內(nèi)容。其設(shè)計(jì)允許很多附件對象，它們是單個(gè)的電子郵件消息的附件訪問清單的一部分。各個(gè)附件對象可以被產(chǎn)生，以保持關(guān)于一段電子郵件的不同的信息或相同的信息，但是具有各種的格式。一個(gè)附件可以被加上或改變，作為消息處理的一部分。完全沒有消息對象必須使用任何附件訪問清單對象的限制，象在其中電子郵件消息沒有附件的情況下那樣(象在分送報(bào)告中)。
如果框架實(shí)施者決定把電子郵件消息的消息內(nèi)容或本體作為附件訪問對象處理，則具有消息本體的電子郵件消息的每一消息對象都將包括一個(gè)附件訪問對象。或者，如果框架實(shí)施者決定僅為消息附件—諸如附在“回答”消息上的文本—使用附件訪問對象，則只在電子郵件消息包括消息附件時(shí)消息對象才包括附件訪問對象。在任何情況下，由于附件訪問清單類是抽象基本類且相關(guān)的對象是核心對象，框架實(shí)施者必須定義至少一個(gè)這樣的附件訪問對象和相關(guān)的處理方法。
附件訪問清單類的對象定義了以下方法當(dāng)把新的附件加到附件訪問清單上時(shí)使用的add()方法，以及當(dāng)存取消息對象的附件訪問清單條目中的條目時(shí)使用的retrieve()。附件訪問對象是抽象對象類型的?？蚣茉O(shè)計(jì)假定附件訪問對象必須被再劃分，以此作為擴(kuò)展框架的一部分以支持具體的電子郵件附件訪問格式的(作為其用戶化的一部分)?？蚣軐?shí)施者必須以此方式擴(kuò)展附件訪問對象?？蚣茉试S任何數(shù)目的再劃分的附件訪問對象存在。假定各個(gè)擴(kuò)展的附件訪問類定義了唯一的識別對象類型。至于在給定消息的附件訪問清單中可能有什么種類的附件，沒有對附件訪問清單對象提出任何要求。
圖18中顯示了框架可以進(jìn)行的兩種示例性框架擴(kuò)展。一個(gè)附件訪問對象擴(kuò)展定義了對互聯(lián)網(wǎng)絡(luò)標(biāo)準(zhǔn)SMTP(或MIME)形式的電子郵件附件(在圖中被顯示為SMTP附件訪問)的訪問。另一個(gè)對象擴(kuò)展定義了對IBM公司SNADS/OfficeVision形式的電子郵件消息附件(在圖中被顯示為SNADS附件訪問)的訪問。這些擴(kuò)展對象可進(jìn)一步定義具體的方法或?qū)傩?，它們被框架用戶視為其所需的支持的一部分。圖18顯示，附件訪問對象定義了稱為change()(它在改變附件訪問時(shí)使用)和用于獲取附件訪問的識別類型的type()的方法。
圖19是類圖，顯示了構(gòu)成框架的原始接收者清單的對象。原始接收者清單對象與原始接收者清單類的關(guān)系，被認(rèn)為是“核心”的，或在框架方面是不可修正的。接收者對象由框架定義，以保持由電子郵件地址指定的電子郵件消息目的地的信息。當(dāng)一個(gè)消息第一次被發(fā)出應(yīng)用程序產(chǎn)生時(shí)，一個(gè)原始接收者清單對象包含該消息原始的接收者清單。當(dāng)接收到電子郵件時(shí)，原始接收者清單條目允許接收者發(fā)現(xiàn)這一段電子郵件原來是由哪里發(fā)出的。
這種處理不同于接收者清單處理之處在于，當(dāng)郵遞服務(wù)處理消息時(shí)，原始接收者清單類中的對象被假定為保持相同。當(dāng)一段電子郵件的復(fù)本通過電子郵件網(wǎng)絡(luò)從一個(gè)系統(tǒng)傳送到另一系統(tǒng)時(shí)，接收者清單可被分成子組。假定原始接收者清單包含的接收者的原始清單不是被用于路由和轉(zhuǎn)送郵件，而是報(bào)告郵件最先是從哪里被送到這一段電子郵件的所有接收者的。框架不定義電子郵件地址格式或它們的內(nèi)容。這種定義必須是框架用戶進(jìn)行的框架擴(kuò)展的一部分。
圖19顯示出，原始接收者清單對象定義了稱為addEntry()(它是在將新的原始接收者清單條目對象加到原始接收者清單類上時(shí)使用的)和retrieveEntry()(它是在存取消息對象的原始接收者清單類中形成原始接收者清單條目時(shí)使用的)的方法。因此，原始接收者清單訪問原始接收者清單條目對象，且原始接收者清單條目對象訪問原始接收者的具體地址對象和分發(fā)類型對象。分發(fā)類型類中的對象使電子郵件消息的發(fā)出者能夠識別所送到的原始地址是否被指定為“to”、“cc(復(fù)本)”或“bcc”(盲復(fù)本)?？蚣芗俣ㄏ⑻幚韺⒏鶕?jù)用于這些說明的規(guī)定進(jìn)行，但不涉及這種處理包含的內(nèi)容。即，這些條目被包括在消息中這一信息被傳送，但不產(chǎn)生附加的、由框架系統(tǒng)進(jìn)行的處理步驟。地址對象與在發(fā)出者清單對象部分中描述的相同。
圖20是類圖，顯示了構(gòu)成框架的回答對象清單類的對象。地址對象至回答對象清單類的關(guān)系被認(rèn)為是“核心”關(guān)系，它是用戶不可修正的。可以有任何數(shù)目的回答對象清單對象，但每一個(gè)都由唯一的消息對象所使用或訪問。回答對象清單類包含電子郵件地址的清單，該地址應(yīng)該被復(fù)制在接收者(電子郵件目的地)對消息的回答中。電子郵件消息回答被假定為只由“接收”應(yīng)用程序產(chǎn)生?？蚣懿欢x電子郵件地址格式或它們的內(nèi)容。這種定義必須是框架用戶進(jìn)行的框架擴(kuò)展的一部分。
圖20顯示，回答對象清單對象定義了稱為addEntry()(它在將地址加到回答對象清單時(shí)使用)和retrieveEntry()—它在存取消息對象的回答對象清單條目中的條目時(shí)使用—的方法。這些地址對象與上述發(fā)出者清單對象部分中描述的相同。
圖21是類圖，顯示了構(gòu)成框架的回答對象清單類的對象。地址對象與報(bào)告對象清單類的關(guān)系被認(rèn)為是核心關(guān)系和不可修正的?？梢杂腥魏螖?shù)目的報(bào)告對象清單對象，但每一個(gè)都由唯一的消息對象所使用或訪問。報(bào)告對象清單類的對象包括由于電子郵件消息的分送、不分送或轉(zhuǎn)送而需要向其報(bào)告的電子郵件地址的清單。報(bào)告被假定為是由于任何擴(kuò)展的框架類方法或接收一段電子郵件的應(yīng)用程序所產(chǎn)生的?？蚣懿欢x電子郵件地址格式或它們的內(nèi)容。這種定義必須是框架用戶進(jìn)行的框架擴(kuò)展的一部分。
圖21顯示，報(bào)告對象清單對象定義了稱為addEntry()(它是當(dāng)把新的地址加到報(bào)告對象清單上時(shí)使用的)以及retrieveEntry()(它是當(dāng)存取消息對象的報(bào)告對象清單條目中的條目時(shí)使用的)的方法。地址對象與在上述發(fā)出者清單對象部分描述的相同。
圖22是類圖，顯示了組成框架的報(bào)告內(nèi)容清單類的對象。在框架方面，地址對象與報(bào)告內(nèi)容清單類的關(guān)系被認(rèn)為是核心和不可修正的。可以有任何數(shù)目的報(bào)告內(nèi)容清單對象，但每一個(gè)都由唯一的消息對象使用或訪問。報(bào)告內(nèi)容清單的對象包括在其上正在產(chǎn)生報(bào)告的電子郵件地址清單。在電子郵件消息是分送、不分送或轉(zhuǎn)送的報(bào)告的情況下，消息表示為其產(chǎn)生這種報(bào)告的接收者。假定報(bào)告是用任何擴(kuò)展的框架類方法產(chǎn)生的。框架不定義電子郵件地址格式或它們的內(nèi)容。這種定義必須是框架用戶進(jìn)行的框架擴(kuò)展的一部分。
圖22顯示，報(bào)告內(nèi)容清單對象定義了稱為addEntry()(它在將新地址加到報(bào)告內(nèi)容清單上時(shí)使用)以及retrieveEntry()(它是當(dāng)存取消息對象的報(bào)告內(nèi)容清單條目中的條目時(shí)使用的)的方法。報(bào)告內(nèi)容清單條目類中的對象訪問報(bào)告內(nèi)容清單條目對象。報(bào)告內(nèi)容清單條目對象訪問所報(bào)告的接收者的具體地址對象和報(bào)告指示器對象。報(bào)告指示器類中的對象包含關(guān)于所報(bào)告的內(nèi)容的信息，例如消息是分送的報(bào)告還是錯(cuò)誤，如果是錯(cuò)誤則給出錯(cuò)誤類型。地址對象與在上述的發(fā)出者清單對象部分中描述的相同。
圖23是類圖，顯示了組成框架的地址產(chǎn)生器清單類的對象。每一個(gè)消息中心對象都有一個(gè)地址產(chǎn)生器清單。地址產(chǎn)生器類的對象與地址產(chǎn)生器清單的對象的關(guān)系在框架方面被認(rèn)為是核心和不可修正的。地址產(chǎn)生器清單被消息中心用于每一個(gè)地址對象的構(gòu)成。注意地址被包含在很多其他的框架對象中。該框架不定義電子郵件地址格式或它們的內(nèi)容。這種定義必須是框架用戶進(jìn)行的框架擴(kuò)展的一部分。在此情況下，對框架的擴(kuò)展是通過再劃分地址產(chǎn)生器對象以產(chǎn)生新的、產(chǎn)生地址對象的具體類而進(jìn)行的。
圖23顯示出，地址產(chǎn)生器清單對象定義了被稱為addEntry()(它在把新的地址產(chǎn)生器加到地址產(chǎn)生器清單上時(shí)使用)以及removeEntry()(它在從地址產(chǎn)生器清單類中除去地址產(chǎn)生器對象時(shí)使用)的方法。地址產(chǎn)生器類的對象是抽象對象?？蚣茉O(shè)計(jì)假定，這種對象必須被再劃分，作為擴(kuò)展框架的一部分以支持作為其用戶化的一部分的具體的電子郵件地址格式?？蚣苡脩魧⒈仨氁源朔绞綌U(kuò)展地址產(chǎn)生器對象。在圖23中顯示了示例性的子類，其中地址產(chǎn)生器對象被再劃分以產(chǎn)生SMTP地址和SNADS地址對象。圖23顯示，地址產(chǎn)生器對象定義了稱為createAddress()的方法，它被框架用于產(chǎn)生地址對象。
圖24是類圖，顯示了組成框架的信封產(chǎn)生器清單類的對象。每一個(gè)消息中心對象都有一個(gè)信封產(chǎn)生器清單對象。信封產(chǎn)生器對象與信封產(chǎn)生器清單類的關(guān)系在框架方面被認(rèn)為是核心和不可修正的。信封產(chǎn)生器清單被消息中心用于構(gòu)成每一個(gè)信封對象?？蚣懿欢x電子郵件信封格式。這種定義是框架用戶進(jìn)行的框架擴(kuò)展的一部分。在此情況下，通過再劃分信封產(chǎn)生器對象來擴(kuò)展框架，以形成產(chǎn)生信封對象的新的具體類。
圖24顯示出，信封產(chǎn)生器清單對象定義了稱為addEntry()(它在把新的信封產(chǎn)生器加到信封產(chǎn)生器清單上時(shí)使用)和removeEntry()(它從信封產(chǎn)生器清單中除去信封產(chǎn)生器)的方法。信封產(chǎn)生器對象是抽象對象類型的?？蚣茉O(shè)計(jì)假定，這種對象作為框架用戶用戶化的一部分而得到再劃分，這種用戶化擴(kuò)展了框架，以支持具體的電子郵件信封格式。即，框架用戶必須以此方式擴(kuò)展信封產(chǎn)生器對象。圖24顯示了三種示例性的再劃分的信封產(chǎn)生器對象，它們產(chǎn)生稱為SMTP信封、SNADS信封和通用信封的類中的對象。在圖24顯示的示例性系統(tǒng)中，通用信封類方便地提供了一般的說明類，說明了消息能夠分成的類別。圖24顯示，信封產(chǎn)生器對象定義了稱為createEnvelope()的方法，它產(chǎn)生信封對象。
圖25是類圖，顯示了組成框架的附件訪問產(chǎn)生器清單類的對象。每一個(gè)消息中心對象有一個(gè)附件訪問產(chǎn)生器清單。在框架方面，附件訪問產(chǎn)生器對象與附件訪問產(chǎn)生器清單類的關(guān)系被認(rèn)為是核心和不可修正的。附件訪問產(chǎn)生器清單被消息中心用于構(gòu)成每一個(gè)附件訪問對象?？蚣懿欢x電子郵件附件，也不定義附件是如何被消息訪問的。這種定義是框架用戶進(jìn)行的框架擴(kuò)展的一部分。在此情況下，對框架的擴(kuò)展通過再劃分附件訪問產(chǎn)生器對象進(jìn)行，以產(chǎn)生新的能造成附件訪問對象的具體類。
圖25顯示，附件訪問產(chǎn)生器清單對象定義了稱為addEntry()(它將新的附件訪問產(chǎn)生器對象加到附件訪問產(chǎn)生器清單上)和removeEntry()(它從附件訪問產(chǎn)生器清單除去附件訪問產(chǎn)生器對象)的方法。圖25顯示出附件訪問產(chǎn)生器為抽象對象類型的?？蚣茉O(shè)計(jì)假定，這種對象被再劃分，作為框架用戶的擴(kuò)展的一部分，以支持具體的電子郵件附件訪問格式?？蚣苡脩舯仨氁源朔绞綌U(kuò)展附件訪問產(chǎn)生器對象。
圖25中顯示了這種擴(kuò)展的兩個(gè)例子。再劃分的附件訪問產(chǎn)生器對象產(chǎn)生SMTP附件訪問對象和SNADS附件訪問對象。實(shí)際上可能不會(huì)需要一種以上的訪問，因而文件名可被用于一種以上的電子郵件協(xié)議。附件訪問在框架之內(nèi)的抽象，使框架用戶能夠以此方式對其進(jìn)行擴(kuò)展。圖25顯示，附件訪問產(chǎn)生器對象定義了稱為createAddressRef()的方法，它產(chǎn)生附件訪問對象。概要圖參見對象圖，可以更好地理解由根據(jù)本發(fā)明構(gòu)成的郵遞服務(wù)器系統(tǒng)進(jìn)行的操作步驟；本領(lǐng)域的技術(shù)人員明白，這些圖顯示了面向?qū)ο蟮某绦蛟O(shè)計(jì)框架實(shí)施的處理。對象圖顯示了對象類如何相互作用以產(chǎn)生框架功能。這些對象圖隨后假定了由框架用戶對框架的某些擴(kuò)展。該概要使用了上述類定義中使用的示例性類擴(kuò)展?？蚣苡脩暨M(jìn)行的實(shí)際擴(kuò)展可以根據(jù)框架實(shí)施而變化。
圖26是圖8所示的計(jì)算機(jī)系統(tǒng)實(shí)施的框架的對象概要圖。圖26是概要圖，顯示了消息中心對象(由消息中心對象云表示)的開始是如何響應(yīng)以產(chǎn)生消息對象并開始對其進(jìn)行處理，從而接收包括電子郵件消息的信息的，這由從消息中心對象云向回至其自身的、標(biāo)為“1handleIncomingMessage()”的環(huán)線表示。
更具體地，handleIncomingMessage()方法得到調(diào)用，以處理進(jìn)入的信息并產(chǎn)生消息對象?？蚣芗俣?，該方法傳送一或多個(gè)參數(shù)—它用這些參數(shù)構(gòu)成消息對象。handleIncomingMessage()方法假定，這些參數(shù)中的一個(gè)是一個(gè)消息文本串。即，框架處理認(rèn)為該消息是分解成組成部分的文本串，而這些組成部分被映象到在上述類圖中描述的對象類上。消息文本串在圖26中被表示為文本串。文本串的內(nèi)容被用作至該概要的其他方法的輸入。
應(yīng)該注意的是，框架不規(guī)定用作輸入的文本串的句法，但作為框架實(shí)施的一部分而加上的方法將句法規(guī)則加到輸入的文本串上，因?yàn)樗鼈儗⒂盟鳛榻⒖蚣芩幚淼囊欢坞娮余]件的地址、信封和地址訪問的輸入?？蚣苡脩舻囊徊糠秩蝿?wù)，是考慮電子郵件消息的來源和要由郵遞服務(wù)器系統(tǒng)處理的電子郵件消息中所要接收的信息的形式(它可以在其他的對象中)。在此概要中所列的構(gòu)成方法，是能夠識別具有這些信息形式的信息的框架的擴(kuò)展。
圖26所示的下一個(gè)步驟，是對消息對象構(gòu)成器的調(diào)用，如從消息中心對象云至消息對象云的連線上的符號“2消息(文本串)”所表示的。因此，消息中心對象產(chǎn)生消息對象。消息對象構(gòu)成器以所述順序調(diào)用該概要中的所有其他方法。然后，必須建立消息處理所需的各種對象。下一個(gè)步驟是調(diào)用buildRecipientList()方法，以用消息文本串作為輸入來產(chǎn)生消息對象的接收者清單對象，它由消息對象云上的“3buildRecipientList()”表示。如上所述，信封處理消息對象都具有接收者清單。
雖然消息對象可以具有不只一個(gè)接收者清單對象，但通常的情況是這樣的，即在開始時(shí)所有的電子郵件接收者將被包含在一個(gè)未分解的接收者清單對象中。接收者清單對象包含各地址條目對象。各個(gè)地址條目對象由地址對象和接收者數(shù)據(jù)對象組成。createAddress()方法隨后得到調(diào)用，這由在從消息對象云至地址產(chǎn)生器清單對象云的連線上的符號“4createAddress()”表示，以建立地址對象。createAddress()方法得到調(diào)用，直到不再有要加到消息的接收者清單對象上的接收者地址對象。該方法將完成的接收者清單對象送回消息構(gòu)成器。
從buildOriginatorList()、buildReplyList()、buildReportToList()、buildReportOnList()、和buildOriginalRecipientList()調(diào)用createAddress()方法，因?yàn)樗羞@些對象都包含地址對象。從上述的相應(yīng)類圖可以看清楚這點(diǎn)。對createAddress()的相應(yīng)方法的調(diào)用沒有在圖中顯示，但它們是該概要的一部分。createAddress()方法處理將在下面得到更詳細(xì)的描述。
隨后的處理步驟是用文本串作為輸入，調(diào)用buildEnvelopeList()方法，以產(chǎn)生消息對象的信封清單對象。該步驟由消息對象云處的符號“5buildEnvelopeList()”表示。信封清單包含信封對象。createEnvelope()方法得到調(diào)用，以建立各個(gè)信封對象，如從消息對象云至信封產(chǎn)生器清單對象云的連線上的符號“6createEnvelope()”所表示的。該方法將在下面得到更詳細(xì)的描述。createEnvelope()方法得到調(diào)用，直到不再有要加到消息的信封清單對象上的信封。createEnvelope()方法將完成的信封清單對象送回到消息構(gòu)成器。
圖26的消息處理中的下一個(gè)步驟，是調(diào)用buildOriginatorList()方法，以利用文本串作為輸入產(chǎn)生消息對象的發(fā)出者清單對象，如消息對象云處的“7buildOriginatorList()”所表示的。每一個(gè)消息都具有發(fā)出者清單對象，它包含地址對象。作為該步驟的處理的一部分，createAddress()方法得到調(diào)用，以建立各個(gè)地址對象。createAddress()方法得到調(diào)用，直到不再有地址要被加到消息的發(fā)出者清單對象上。該方法將完成的發(fā)出者清單對象送回到消息構(gòu)造器。下一個(gè)步驟由消息對象云處的“8buildAttachmentRefList()”表示，它表示至buildAttachmentRefList()方法的調(diào)用，以利用文本串作為輸入，產(chǎn)生消息對象的附件訪問清單對象。附件訪問清單是消息對象的可選部分，且該方法可能不為給定的文本串產(chǎn)生一個(gè)，如果框架用戶這樣選擇的話。附件訪問清單對象包含附件訪問對象。下一個(gè)步驟是調(diào)用createAddressRef()方法，以建立各個(gè)附件訪問對象，如在從消息對象云至附件訪問產(chǎn)生器清單對象云的連線上的符號“9createAttachmentRef()”表示的。該方法的處理將在下面得到更詳細(xì)的描述。createAttachmentRef()方法得到調(diào)用，直到不再有附件訪問對象要加到消息的附件訪問清單對象上。該方法將完成的附件訪問清單對象送回到消息構(gòu)成器。
消息處理的下一個(gè)步驟是調(diào)用buildReplyToList()方法，以利用文本串作為輸入，產(chǎn)生消息對象的回答對象清單對象。該處理由消息對象云處的符號“10buildReplyToList()”表示?；卮饘ο笄鍐问窍ο蟮目蛇x部分，且該方法可能不為給定的文本串產(chǎn)生對象。回答對象清單包含地址對象。作為該步驟的處理的一部分，createAddress()方法得到調(diào)用，以建立各個(gè)地址對象。createAddress()方法得到調(diào)用，直到不再有地址要加到消息的回答對象清單對象上。該方法將完成的回答對象清單對象送回到消息構(gòu)成器。
圖26隨后的處理步驟由消息對象云處的“11buildReportToList()”表示，它是一個(gè)方法調(diào)用，以利用文本串作為輸入部分消息對象的報(bào)告對象清單對象。該報(bào)告對象清單對象是消息對象的可選部分，且該方法對于給定的文本串可能不產(chǎn)生一個(gè)對象。報(bào)告對象清單包含地址目標(biāo)。因此，該步驟的處理的一部分，是調(diào)用createAddress()方法，以建立各個(gè)地址對象。該createAddress()方法得到調(diào)用，直到不再有地址被加到消息的報(bào)告對象清單對象上。該方法將完成的報(bào)告對象清單對象送回到消息構(gòu)成器。
在產(chǎn)生了報(bào)告對象清單對象之后，下一個(gè)步驟由“12buildReportOnList()”表示，它是一個(gè)方法調(diào)用，用于利用文本串作為輸入產(chǎn)生消息對象的報(bào)告內(nèi)容清單對象。該報(bào)告內(nèi)容清單是消息對象的可選部分，且該方法對于給定的文本串可能不產(chǎn)生一個(gè)對象。報(bào)告內(nèi)容清單包含報(bào)告內(nèi)容清單條目對象，它由地址對象和報(bào)告指示器對象組成。該步驟的處理包括調(diào)用createAddress()方法，以建立地址對象。createAddress()方法得到調(diào)用，直到不再有地址被加到消息的報(bào)告內(nèi)容清單對象上。該方法將完成的報(bào)告內(nèi)容清單對象送回到消息構(gòu)成器。
下一個(gè)處理步驟由消息對象云處的“13buildOriginalRecipientList()”表示，它是一方法調(diào)用，用于利用文本串作為輸入，產(chǎn)生消息對象的原始接收者清單對象。原始接收者清單包含原始接收者清單條目對象，該對象由地址對象和分發(fā)類型對象組成。該步驟的處理包括調(diào)用ereateAddress()方法，以建立地址對象。ereateAddress()方法得到調(diào)用，直到不再有地址被加到消息的原始接收者清單條目對象上。該方法將完成的原始接收者清單對象送回到消息構(gòu)成器。
現(xiàn)在已經(jīng)構(gòu)成了消息對象。下一個(gè)步驟是將構(gòu)成好的消息對象加到消息中心的消息隊(duì)列對象上，在那里它將被保持到被proeessMessage()方法除去。將消息對象加上的步驟，在圖26中由從消息對象云至消息隊(duì)列對象云的連線上的“14add()”表示。processMessage()處理將在下面得到更詳細(xì)的描述。最后，所示的最后的步驟，是用從消息隊(duì)列對象云至隊(duì)列對象云的連線上的符號“15add”表示的add()調(diào)用，將現(xiàn)在已經(jīng)構(gòu)成的消息對象加到消息隊(duì)列的隊(duì)列對象上。
圖27顯示了用于buildRecipientList()的createAddress()方法處理，但它也類似地適用于buildOriginatorList()、buildReplyToList()、buildReportToList()、buildReportOnList()、和build Original RecipientList()，因?yàn)樗羞@些方法都涉及地址對象。createAddress()方法處理以所完成的地址對象被送回到正在建立的清單對象(接收者清單對象、發(fā)出者清單對象等等中的消息構(gòu)成器結(jié)束。必須可以將每一個(gè)有效的消息(由文本串指定)分解成至少一個(gè)發(fā)出者清單條目和一個(gè)接收者清單條目。因此，有效的消息應(yīng)該包括至少兩個(gè)這種地址對象。
圖27的處理從對createAddress()方法的buildRecipientList()方法調(diào)用開始，以建立與消息有關(guān)的所有接收者清單對象，由消息對象云處的“1buildRecipientList()”表示。在此情況下，假定有至少兩個(gè)地址產(chǎn)生器，一個(gè)是SNADS地址的，另一是SMTP地址的。下一個(gè)步驟由從消息對象至地址產(chǎn)生器清單云的“2createAddress()”表示，它是以正在作為地址對象而構(gòu)成的文本串調(diào)用地址產(chǎn)生器清單的方法調(diào)用，其中所述地址對象應(yīng)被加到正在為消息建立的接收者清單上。
隨后，createAddress()方法必須調(diào)用它所包含的各個(gè)地址產(chǎn)生器對象，直到它們中的一個(gè)送回了將被送回并加到接收者清單對象的地址對象。這由從地址產(chǎn)生器清單目標(biāo)云至SMTP地址產(chǎn)生器對象云的連線上的符號“3createAddress()”表示。下一個(gè)步驟是調(diào)用SMTP地址對象構(gòu)造者—由從SMTP地址產(chǎn)生器云至SMTP地址對象云的連線上的符號“4SMTP地址(文本串)”表示，將用作輸入的文本串傳送給它，以產(chǎn)生SMTP地址。圖27沒有顯示能由構(gòu)造器使用的其他的信息來產(chǎn)生SMTP地址對象。
當(dāng)SMTP地址產(chǎn)生器對象不識別文本串因而不產(chǎn)生SMTP地址對象時(shí)，作為這種情況的一部分，createAddress()方法再次得到調(diào)用。由于在此例中有地址產(chǎn)生器清單也知道的SNADS地址產(chǎn)生器對象，該對象將被調(diào)用，以進(jìn)行其自身的努力來識別文本串。該處理由至SNADS地址產(chǎn)生器對象云的、帶有符號“5createAddress()”和至SNADS地址對象云的、帶有符號“6SNADS地址(文本串)”的連線表示，并將用作輸入的文本串傳送給它，以產(chǎn)生SNADS地址對象。圖27沒有顯示能由構(gòu)造器用來產(chǎn)生SNADS地址對象的其他信息。createEnvelope()方法得到調(diào)用，以建立各個(gè)信封對象。createEavelope()方法得到調(diào)用，直到不再有信封被加到消息的信封清單對象上。這種情況以完成的信封對象被送回到正在建立的信封清單對象內(nèi)的消息構(gòu)成器結(jié)束。圖28顯示了createEnvelope()處理。
首先，buildEnvelopeList()方法將調(diào)用createEnvelope()方法，以建立與消息有關(guān)的所有信封清單對象。在此概要中，假定有至少兩個(gè)信封產(chǎn)生器。該步驟由消息對象云處的環(huán)上的“1buildEnvelopeList()”表示。隨后以將要被構(gòu)造為信封對象的文本串，對信封產(chǎn)生器清單調(diào)用createEnvelope()方法，而該信封對象將被加到正在為消息建立的信封清單上。這種處理由從消息云至信封產(chǎn)生器清單云的連線上的“2createEnvelope()”表示。
createEnvelope()方法必須調(diào)用它包含的各個(gè)信封產(chǎn)生器對象，直到它們中的一個(gè)送回了將要送回并加到信封清單對象上的一個(gè)信封對象。這種處理由至SMTP信封產(chǎn)生器云的連線上帶有符號“3createEnvelope()”的連線表示。然后，SMTPEnyelope()對象構(gòu)造器得到調(diào)用，將被用作輸入的文本串傳送給它，以產(chǎn)生SMTP信封。這由至SMTP信封云的連線上的符號“4SMTP信封(文本串)”表示。圖28的概要沒有顯示出會(huì)有其他的信息可以被構(gòu)造器用來產(chǎn)生SMTP信封對象。
當(dāng)SMTP信封產(chǎn)生器不識別文本串因而不產(chǎn)生SMTP信封對象時(shí)，作為該概要的一部分，createEnvelope()方法再次被調(diào)用。在此例中，由于還有信封產(chǎn)生器清單知道的SNADS信封產(chǎn)生器，所以它將被調(diào)用，以進(jìn)行其自己的努力來識別文本串，如從信封產(chǎn)生器清單云至SNADS信封產(chǎn)生器云的連線上的符號“5createEnvelope()”所表示的。然后，SNADS信封對象構(gòu)造器方法得到調(diào)用，并將被用作輸入以產(chǎn)生SNADS信封的文本串傳送給它，如符號“6SNADS信封(文本串)”所表示的。圖28的概要沒有顯示構(gòu)造者可以使用其他的信息來產(chǎn)生SNADS信封對象。
作為消息處理的一部分，必須建立附件訪問對象。為此，createAttachmentRef()方法得到調(diào)用，直到不再有附件訪問對象被加到消息的附件訪問清單對象上。該概要以完成的附件訪問對象被送回到正在建立的附件訪問清單對象內(nèi)的消息構(gòu)成器結(jié)束。
如圖29所示，AttachmentRef()處理以對buildAttachmentRefList()的調(diào)用為起點(diǎn)開始處理。buildAttachmentRefList()方法隨后調(diào)用createAttachmentRef()方法，以建立與消息有關(guān)的所有附件訪問清單對象。在此概要中，假定有至少兩個(gè)附件訪問產(chǎn)生器。這由消息類云處的環(huán)上的符號“1buildAttachmentRefList()”表示。然后，對附件訪問產(chǎn)生器清單對象調(diào)用createAttachmentRef()方法。該調(diào)用是對將被構(gòu)成為附件訪問對象的文本串進(jìn)行的，而該附件訪問對象將被加到為消息建立的附件訪問清單上。
createAttachmentRef()方法必須調(diào)用它包含的每一個(gè)附件訪問產(chǎn)生器對象，直到它們中的一個(gè)送回了被加到附件訪問清單對象上的附件訪問對象。圖29顯示了一個(gè)示例性概要，它具有兩個(gè)附件訪問產(chǎn)生器對象，其中調(diào)用的第一個(gè)附件訪問產(chǎn)生器是SMTP地址，由從附件訪問產(chǎn)生器清單對象云至帶有符號“3SMTP附件訪問產(chǎn)生器對象云的SMTP附件訪問產(chǎn)生器目標(biāo)云的連線表示。
隨后SMTPAttachmentRef()對象構(gòu)成器得到調(diào)用，將用作輸入以產(chǎn)生SMTP附件訪問的文本串傳送給它。該構(gòu)成器調(diào)用由從SMTP附件訪問產(chǎn)生器對象云至SMTP附件訪問對象云的連線上的符號“4SMTP附件訪問(文本串)”表示。圖29的概要沒有顯示會(huì)有其他的信息可由構(gòu)成器來產(chǎn)生SMTP附件訪問對象。
當(dāng)SMTPAttachmentRefCreator()方法沒有識別文本串因而不產(chǎn)生SMTP附件訪問對象時(shí)，作為該概要的一部分，createAttachmentRef()方法再次被調(diào)用。由于在此例中SNADS附件訪問產(chǎn)生器也為附件訪問產(chǎn)生器清單對象所知道，它將得到調(diào)用，以進(jìn)行其自己的努力來識別文本串。該處理由從地址產(chǎn)生器清單云至SNADS附件訪問產(chǎn)生器對象云的連線上形成符號“5createAttachmentRef()”表示。然后，SNADS附件訪問對象構(gòu)成器被產(chǎn)生者對象所調(diào)用，將用作輸入以產(chǎn)生SNADS附件訪問的文本串傳送給構(gòu)可由構(gòu)成器。該概要沒有顯示會(huì)有其他的信息可由構(gòu)成器來產(chǎn)生SNADS附件訪問對象。這最后的對象產(chǎn)生處理步驟由從SNADS附件訪問產(chǎn)生器云至SNADS附件訪問云的連線上的符號“6SNADS附件訪問(文本串)”表示。
每一個(gè)消息對象的處理都是利用processMessage()方法實(shí)現(xiàn)的。圖30顯示了框架對象進(jìn)行相互作用以控制處理的處理步驟，并顯示出處理是以processMessage()方法調(diào)用開始的。processMessage()方法得到調(diào)用，以命令消息中心對象處理各個(gè)電子郵件消息，對各個(gè)消息對象執(zhí)行框架的步驟組，并隨后從消息隊(duì)列中刪除該對象。在開始時(shí)調(diào)用processMessage()的步驟由從消息中心對象向回至其自己的環(huán)上的符號“1processMessage()”表示。該處理以對removeMessage()方法的呼叫繼續(xù)進(jìn)行，該方法經(jīng)過框架獲得消息對象以進(jìn)行處理。該處理由從消息中心至消息隊(duì)列的連線上的符號“2removeMessage()”表示。該方法將消息對象送回到消息中心。其余的方法隨后依次在消息對象上進(jìn)行，而該消息對象被從消息隊(duì)列除去，如下面描述。
隨后的除去消息對象的處理步驟，由符號“3expandList()”表示，它是消息對象上的expandList()方法調(diào)用。該方法將對消息的接收者清單進(jìn)行操作，以對它們進(jìn)行可能的擴(kuò)展。expandList()方法將在下面得到詳細(xì)描述。下一個(gè)處理步驟是調(diào)用消息對象上的resolveAddresses()方法。該方法將對消息的對象接收者清單進(jìn)行操作，以對未分解的接收者清單中的每一個(gè)條目進(jìn)行“分解”，從而當(dāng)該方法返回時(shí)，清單中不再有對象。該處理由從消息中心對象云至消息對象云的連線上的符號“4resolveAddresses()”表示。該方法的處理將在下文中更詳細(xì)描述。
在地址被分解之后，處理以對消息對象調(diào)用processEnveloDes()方法繼續(xù)進(jìn)行。該方法將支持對框架的任何具體擴(kuò)展，該擴(kuò)展在信封清單中的信封對象上進(jìn)行特定的功能(或使用)。該方法調(diào)用由符號“5processEnvelopes()”表示，將在下面得到更詳細(xì)的描述。然后，在消息對象上調(diào)用attachmentProcessing()方法。該方法將支持對框架的所有具體擴(kuò)展，以對(或使用)附件訪問清單中的附件訪問對象完成特定的功能。應(yīng)該注意的是，對任何給定的消息對象事例，可能沒有附件訪問清單對象。這種處理由“6attachmentProcessing()表示，并將在下面得到更詳細(xì)的描述。
圖30的處理的下一個(gè)步驟，是調(diào)用securityAuthority()方法。該securityAuthority()方法支持對框架的所有特定擴(kuò)展，該擴(kuò)展執(zhí)行關(guān)于安全或鑒別的特定功能?？蚣茉O(shè)計(jì)者必須決定這可以包括的功能以及什么消息對象的哪些部分可以為該方法所使用。該方法將在下面得到更詳細(xì)的描述，并在圖30中由符號“7secnrityAuthority()”表示。下一個(gè)處理步驟是調(diào)用消息對象上的deliverLocal()方法。deliverLocal()方法將支持對框架的所有具體擴(kuò)展，以執(zhí)行關(guān)于電子郵件消息內(nèi)容的本地分送的特定功能。同樣，框架設(shè)計(jì)者必須確定它可以包括什么功能以及消息對象的哪些部分可以為該方法所使用。這些功能不是框架的一部分。該方法的目的是復(fù)制消息對象的全部或部分信息。deliverLocal()方法處理將在下面得到更詳細(xì)的描述。
在完成了本地分送處理之后，下一個(gè)步驟是調(diào)用forwardMessage()方法，該方法支持對框架的特定擴(kuò)展，以執(zhí)行關(guān)于向網(wǎng)絡(luò)的其他部分轉(zhuǎn)送電子郵件消息內(nèi)容的功能?？蚣茉O(shè)計(jì)者必須決定這可能包括的功能，以及消息對象的哪些部分可以為該方法所使用。其目的是復(fù)制消息對象的部分或全部信息。該步驟由符號“9forwardMessage()”表示，并將在下面得到更詳細(xì)的描述。
在任何電子郵件消息轉(zhuǎn)送之后，下一個(gè)步驟是對消息目標(biāo)調(diào)用handleNonDelivery()方法。該方法支持框架的特定擴(kuò)展以執(zhí)行關(guān)于電子郵件消息內(nèi)容的送回或報(bào)告功能。同樣。框架設(shè)計(jì)者必須決定這可能包括什么功能，以及消息對象的哪些部分能夠?yàn)樵摲椒ㄋ褂?。且其目的是?fù)制消息對象的部分或全部信息(可能是通過產(chǎn)生一個(gè)新的“報(bào)告”消息對象)。handleNonDelivery()步驟由符號“10handleNonDelivery()”表示。
下一個(gè)步驟是對消息對象調(diào)用manageAttachments()方法。該方法支持框架的特定擴(kuò)展，以對(或使用)附件訪問清單中的附件訪問對象執(zhí)行特定功能。注意對于任何給定的消息對象，可能沒有附件訪問清單對象。該處理由“11manageAttachments()”表示。最后，最后的步驟是對消息對象調(diào)用accounting()方法。會(huì)計(jì)步驟支持對框架的特定擴(kuò)展—該擴(kuò)展執(zhí)行關(guān)于框架處理的電子郵件消息的會(huì)計(jì)的特定功能?？蚣茉O(shè)計(jì)者必須決定這可能包括什么功能，以及消息對象的什么部分可被該方法所使用。其目的是復(fù)制消息對象的必須得到會(huì)計(jì)處理的部分或全部信息。
如上所述，expandList()方法擴(kuò)展了消息的接收者清單。圖31顯示了這種處理。如圖31所示，expandList()方法對消息的未分解的接收者清單地址條目對象進(jìn)行操作，以在需要時(shí)擴(kuò)展它們。這種處理的開始由從消息云至未分解的接收者清單云的連線上的“1expandList()”表示，這表示對象調(diào)用未分解的接收者清單對象的expandList()方法。然后，expandList()方法為包含在未分解的接收者清單對象中的每一個(gè)地址條目調(diào)用expandAddress()方法，如從未分解的接收者清單云至地址條目云的連線上的“2expandAddress()”所表示的。
地址條目對象的每一個(gè)將對于它們的地址調(diào)用該擴(kuò)展方法。在此例的概要中，該由從地址條目對象至SMTP地址對象(框架實(shí)施者對框架進(jìn)行的一個(gè)擴(kuò)展)連線上的“3expand()”表示。如果SMTP地址對象確定它應(yīng)該被一個(gè)地址清單取代，它對于未分解的接收者清單對象調(diào)用replaceEntry()方法。該處理由從SMTP地址至未分解的接收者清單的連線上的“4replaceEntry()”表示。
當(dāng)expandList()方法已經(jīng)完成時(shí)，所有的未分解的接收者清單地址條目對象都有機(jī)會(huì)擴(kuò)展附于消息對象的電子郵件地址。注意框架實(shí)施者(或再劃分地址對象的任何人)能夠決定沒有能力擴(kuò)展這種地址對象，且在此情況下能夠?qū)嵤┮粋€(gè)送回給者的空方法。
應(yīng)該注意的是，在該概要圖中沒有顯示的是，由于expandAddresses()會(huì)導(dǎo)致未分解的接收者清單地址條目對象被取代，如果出現(xiàn)了這種情況，expandAddresses()方法把一個(gè)標(biāo)志送回到消息，以表示有新的未分解的接收者清單地址條目對象。這向消息目標(biāo)表明它必須再次調(diào)用在上述概要中描述的expandList()方法。只要新的條目被expandAddresses()方法加到未分解的接收者清單上，就繼續(xù)重復(fù)這些方法。
如上所述，resolveAddresses()方法對消息進(jìn)行操作，以分解消息的未分解的接收者清單中的各個(gè)地址條目對象。圖32詳細(xì)描述了這種處理。對于框架，地址條目對象的“分解”意味著地址條目對象被從未分解的接收者清單類中除去，并被放置在通過框架擴(kuò)展實(shí)施的另一個(gè)接收者清單對象類中。該分解過程涉及由消息的resolveAddresses()方法調(diào)用未分解的接收者清單對象的resolveAddresses()方法。這在圖32中由從消息對象至未分解的接收者清單對象云的連線“1resolveAddresses()”表示。
隨后，未分解的接收者清單對象的resolveAddresses()方法將為未分解的接收者清單對象中包含的每一個(gè)地址條目對象調(diào)用resolveAddresses()方法。該處理由“2resolveAddresses()”表示。然后，每一個(gè)地址條目對象將就其自己的地址調(diào)用resolve()方法。在此例的概要中，該處理由SMTP地址對象(該對象是框架實(shí)施者對其框架的擴(kuò)展)和從地址條目對象云至SMTP地址對象云的連線上的“3resolve()”表示。各個(gè)地址對象確定對于“分解”它應(yīng)該做什么。用什么標(biāo)準(zhǔn)來進(jìn)行分解判定，是resolve()方法的用戶實(shí)施的一部分，不由框架定義。如果SMTP地址通過變成SMTP接收者清單對象(該對象是框架用戶對框架的一個(gè)擴(kuò)展)的一部分而得到分解，它就未分解的接收者清單對象呼叫removeEntry()方法?；蛘撸刂穼ο蟮姆纸饪赡軐?dǎo)致其地址條目被一個(gè)不同的地址所取代。提供這種選擇以使電子郵件地址在切換接收者地址時(shí)能夠被“交換”或“切換”，作為實(shí)施電子郵件協(xié)議之間的網(wǎng)關(guān)或建立可能的電子郵件地址別名的一部分。在圖32中，這種替換處理由從SMTP地址至未分解的接收者清單的連線上的“4removeEntry()或replaceEntry()”表示。
在電子郵件地址分解之后，SMTP地址對象將調(diào)用addEntry()方法，以將其從未分解的接收者清單除去的地址清單條目加到SMTP接收者清單對象上。這完成了在此概要中所示的“分解”，并由從SMTP地址至SMTP接收者清單的連線上的“5addEntry()”表示。
當(dāng)完成resolveAddresses()時(shí)，在未分解的接收者清單種類中啟動(dòng)的所有地址條目對象都具有機(jī)會(huì)被“分解”成附于消息的其他接收者清單對象。注意框架用戶(或者再劃分地址對象的任何人)都能夠確定如果在resolveAddresses()方法返回到消息之前在未分解的接收者清單對象中包含有任何剩余的地址清單對象時(shí)，應(yīng)該未取什么行動(dòng)。對消息對象的其他改變(諸如增加或改變信封清單對象)能夠成為“分解”未分解的接收者清單地址條目的一部分。這取決于resolve()方法的框架用戶。這在該概要圖中沒有顯示。
應(yīng)該注意的是，在概要中沒有示出的一個(gè)這樣的事實(shí)，即由于resolveAddresses()方法能夠?qū)е挛捶纸獾慕邮照咔鍐蔚刂窏l目被取代，在發(fā)生了這種情況時(shí)resolveAddresses()方法將把一個(gè)標(biāo)志送回消息，表明有新的未分解的接收者清單地址條目對象。這向消息表明它必須再次調(diào)用在上述概要中描述的expandAddresses()方法并隨后必須再次調(diào)用在此概要中所示的resolveAddresses()。通過這些方法進(jìn)行的再循環(huán)將繼續(xù)，只要新的地址條目對象通過expandAddresses()或resolveAddresses()方法被加到未分解的接收者清單上。
每個(gè)消息包括一個(gè)信封對象。這些對象用在消息目標(biāo)上調(diào)用的processEnvelopes()方法進(jìn)行處理，如圖33所示。該方法支持對框架的任何特定擴(kuò)展—這些擴(kuò)展執(zhí)行(或使用)在信封清單中的信封對象上的功能。應(yīng)該注意的是，框架假定任何所希望的信封對象處理都是圍繞出現(xiàn)在電子郵件消息上的接收者電子郵件地址的類而設(shè)計(jì)的。這意味著processEnvelopes()方法是作為接收者清單框架對象的擴(kuò)展的一部分而實(shí)施的。當(dāng)考慮localDelivery()或messegeForwarding()方法時(shí)，該更容易理解。對于具有SMTP接收者的電子郵件消息和具有SNADS接收者的電子郵件消息(在SNADS接收者清單對象中有至少一個(gè)地址條目)來說，在消息對象的信息上進(jìn)行的功能可能是完全不同的。這些方法由框架用戶進(jìn)行的接收者清單對象的擴(kuò)展定義和實(shí)施。事實(shí)上，前述的所有概要都反映了框架的這種主要的設(shè)計(jì)假定，當(dāng)框架用戶設(shè)計(jì)和擴(kuò)展框架時(shí)他必須考慮這點(diǎn)。
首先，對于附于消息的每一個(gè)接收者清單對象，processEnyelopes()方法將調(diào)用processEnvelopes()方法。在此概要中，假定有兩個(gè)，即SMTP接收者清單和SNADS接收者清單。先對SMTP接收者清單調(diào)用該方法，如從消息對象云至SMTP接收者清單對象云的連線上的“1processEnvelopes()”所表示的。然后，processEnvelopes()方法將對消息對象的信封清單對象調(diào)用retrieve()或add()。這種處理由至信封清單的連線上的“2retrieve()或add()”表示。該概要假定尋找電子郵件消息的一個(gè)信封并可能將其作為執(zhí)行調(diào)用的一部分而加到processEnvelopes()方法上。processEnvelopes()方法的實(shí)施者將設(shè)計(jì)processEnvelopes()在電子郵件消息上實(shí)際執(zhí)行的功能。
隨后，消息的processEnvelopes()方法將調(diào)用附于該消息的下一個(gè)接收者清單對象的processEnyelopes()方法。圖33的處理顯示，對SNADS接收者清單，從消息對象云作出了調(diào)用“3processEnvelopes()”。象前面一樣，processEnvelopes()方法將對消息對象的信封清單調(diào)用retrieve()或add()方法，由“4retrieve()或add()”表示。該概要再次假定，作為對processEnvelopes()執(zhí)行調(diào)用的一部分，電子郵件消息的信封將被查看并可能被加上。
除了消息對象和信封對象處理，框架還實(shí)施附件處理。圖34顯示了這種處理。首先，對消息對象調(diào)用attachmentProcessing()方法。該方法支持對框架的任何特定擴(kuò)展—該擴(kuò)展在附件訪問清單中的附件訪問對象上執(zhí)行(或使用)特定的功能。注意對于任何給定的消息對象，可能沒有附件訪問清單。
在附件處理中，首先消息的attachmentProcessing()方法將調(diào)用附在消息上的每一個(gè)接收者清單對象的attachmentProcessing()方法。在此概要中，假定有兩個(gè)接收者清單，一個(gè)SMTP接收者清單和一個(gè)SNADS接收者清單。首先對SMTP接收者清單調(diào)用attachmentProcessing()方法，如從消息云至SMTP接收者清單云的連線上的“1attachmentProcessing()”所表示的。然后，processEnvelopes()方法將對消息對象的附件訪問清單調(diào)用retrieve()或add()方法。該概要假定，電子郵件消息被訪問的附件將被查看或可能作為對attachmentProcessing()執(zhí)行調(diào)用的一部分而被加上。attachmentProcessing()方法的實(shí)施者將設(shè)計(jì)attachmentProcessing()在電子郵件消息上將實(shí)際執(zhí)行的功能。該處理在圖34中由至附件訪問清單的線上的“2retrieve()或add()”表示。
下一個(gè)附件處理步驟，是由消息的attachmentProcessing()方法調(diào)用附在消息上的下一個(gè)接收者清單對象的attachmentProcessing()方法。圖34顯示了對SNADS接收者清單對象云正在進(jìn)行的調(diào)用“3attachmentProcessing()”。然后，attachmentProcessing()將對消息對象的附件訪問清單呼叫retrieve()或add()方法，如“4retrieve()或add()”所示。和前面一樣，該概要假定，電子郵件消息的被訪問的附件將被查看，或可能作為對attachmentProcessing()執(zhí)行調(diào)用的一部分而被加上。
在最佳實(shí)施例中，框架支持安全處理。這由圖35表示，它描述了securityAuthority()方法。該方法是在消息對象上調(diào)用的，并支持對框架的任何特定擴(kuò)展—該擴(kuò)展執(zhí)行有關(guān)安全或鑒別的特定功能。框架設(shè)計(jì)者必須決定這可能包括的功能和該方法所可能使用的消息對象部分。
在安全處理中，首先消息的securityAuthority()方法調(diào)用附在消息上的每一個(gè)接收者清單對象的securityAuthority()方法。在此概要中，有兩個(gè)接收者清單對象，一個(gè)SMTP接收者清單對象和SNADS接收者清單對象。首先對SMTP接收者清單調(diào)用securityAuthority()方法，這在圖35中由從消息至SMTP接收者清單的線上的“1securityAuthority()”表示。securityAuthority()方法的實(shí)施者必須設(shè)計(jì)出該方法提供什么類的安全或鑒別功能。在該概要中沒有顯示的還有可以獲取消息的任何對象(諸如發(fā)出者清單、信封清單或附件訪問清單)且可以在執(zhí)行安全或鑒別功能的過程中使用該對象。然后，消息的securityAuthority()方法將調(diào)用附在消息上的下一個(gè)接收者清單對象的securityAuthority()方法。圖35顯示了對SNADS接收者清單進(jìn)行的調(diào)用，由從消息至SNADS接收者清單的線上的“2securityAuthority()”表示。
某些消息將具有本地目的地，這意味著它們是送給與操作系統(tǒng)處于同一網(wǎng)絡(luò)上的接收者的。在此情況下，采用deliverLocal()方法。圖36顯示了這種方法的處理。deliverLocal()是在消息對象上被調(diào)用的，并支持對框架的任何特定擴(kuò)展—該擴(kuò)展執(zhí)行有關(guān)電子郵件消息內(nèi)容的本地分送功能?？蚣茉O(shè)計(jì)者必須決定這可以包括什么功能，以及消息對象的哪些部分可以被該方法使用。
圖36顯示出，在該處理中，首先將deliverLocal()應(yīng)用到消息對象上。該方法對附在消息上的每一個(gè)接收者清單調(diào)用deliverLocal()方法。在圖36的概要中，處理的第一個(gè)地址清單是SMTP接收者清單，如從消息至SMTP接收者清單的線上的“1deliverLoeal()”所示。該deliverLocal()方法被應(yīng)用到SMTP接收者清單對象上，以控制電子郵件消息至本地接收者的分送。該方法調(diào)用附件訪問清單上的retrieve()方法，以獲得與消息有關(guān)的附件訪問對象的清單，如“2retrieve()”所表示的。
一旦獲取了與消息有關(guān)的附件訪問對象，對信封清單類調(diào)用retrieve()方法，以獲取信封清單對象。這由至信封清單的線上的“3retrieve()”表示。一旦獲取到了附件訪問對象和信封對象，deliverLocal()方法準(zhǔn)備通過SMTP接收者清單來執(zhí)行基本的分送功能。這可以通過獲取SMTP接收者清單中的每一個(gè)地址條目并檢查接收者數(shù)據(jù)以確定電子郵件消息接收者是本地的還是遠(yuǎn)程的來實(shí)現(xiàn)。如果電子郵件接收者是本地的，則執(zhí)行分送所需的處理，如框架用戶所確定的。
隨后，deliverLocal()方法被應(yīng)用到SNADS接收者清單上。該方法是要控制至本地接收者的電子郵件消息分送，如從消息至SNADS接收者清單的線上的“4deliverLocal()”所表示的。該方法又調(diào)用附件訪問清單上的retrieve()方法，以獲得與消息有關(guān)的附件訪問對象清單。該處理由從SNADS接收者清單至附件訪問清單的線上的“5retrieve()”表示。一旦獲得了與消息有關(guān)的附件訪問對象，retrieve()方法對信封清單調(diào)用retrieve()方法，以獲取信封對象。這由至信封清單的線上的“6retrieve()”表示。一旦獲取了附件訪問和信封對象，deliverLocal()方法準(zhǔn)備通過SNADS接收者清單來執(zhí)行基本的分送功能。這可以通過獲取SNADS接收者清單中的各個(gè)地址條目并檢查接收者數(shù)據(jù)以判定電子郵件接收者是本地還是遠(yuǎn)程來進(jìn)行。如果電子郵件接收者是本地的，則如框架用戶所確定的那樣進(jìn)行分送消息所需的處理。
如果消息不是給本地電子郵件接收者的，則它必須被轉(zhuǎn)送到網(wǎng)絡(luò)的另一部分。在此情況下，不是框架組成部分的另一個(gè)處理程序?qū)㈦娮余]件消息內(nèi)容傳送到另一個(gè)系統(tǒng)。這種處理涉及圖36中所示的forwardMessage()方法。該forwardMessage()方法在消息對象上得到調(diào)用，并支持任何特定擴(kuò)展—該擴(kuò)展執(zhí)行與向網(wǎng)絡(luò)的另一部分轉(zhuǎn)送電子郵件消息的內(nèi)容有關(guān)的功能。框架設(shè)計(jì)者必須決定這可能包括的功能和該方法可以使用的消息對象部分。它的目的是復(fù)制消息對象的部分或全部消息。
圖37顯示，forwardMessage()方法被應(yīng)用到消息對象上，并對附在消息上的每一個(gè)接收者清單對象而得到調(diào)用。在此概要中，處理的第一個(gè)地址清單是SMTP接收者清單，如從消息至SMTP接收者清單的連線上的“1forwardMessage()”所表示的。該forwardMessage()方法被應(yīng)用到SMTP接收者清單上，以控制電子郵件消息至遠(yuǎn)程接收者的分送。該方法隨后在附件訪問清單上調(diào)用retrieve()方法，以獲得與消息有關(guān)的附件清單。該處理由“2retrieve()”表示。
一旦獲取了與消息有關(guān)的附件訪問對象，對信封清單調(diào)用retrieve()方法，以獲取信封清單。這由從SMTP接收者清單至信封清單的連線上的“3retrieve()”表示。在獲取了消息附件訪問和信封對象之后，forwardMessage()方法準(zhǔn)備通過SMTP接收者清單以執(zhí)行基本的分送功能。這是通過獲取SMTP接收者清單中的各個(gè)地址條目并檢查接收者數(shù)據(jù)以判定電子郵件接收者是本地還是遠(yuǎn)程來進(jìn)行的。如果電子郵件接收者是程的，則如框架用戶確定的那樣進(jìn)行分送消息所需的處理。
隨后，forwardMessage()被應(yīng)用到SNADS接收者清單上，如從消息至SNADS接收者清單的線上的“4forwardMessage()”所示。該方法控制至遠(yuǎn)程電子郵件接收者的電子郵件消息分送，并在附件訪問清單上調(diào)用retrieve()方法，以獲得與消息有關(guān)的附件訪問對象清單。該處理由至附件訪問清單的連線上的“ 5retrieve()”表示。一旦獲取了與消息有關(guān)的附件，對信封清單調(diào)用retrieve()方法，以獲取信封清單對象，如至信封清單的連線上的“6retrieve()”所示。一旦獲取了附件訪問和信封對象，forwardMessage()方法準(zhǔn)備通過SNADS接收者清單，以執(zhí)行基本的分送功能。這可通過獲取SNADS接收者清單中的各個(gè)地址條目并檢查接收者數(shù)據(jù)以判定電子郵件接收者是本地還是遠(yuǎn)程來進(jìn)行。如果電子郵件接收者是遠(yuǎn)程，則如框架用戶確定的那樣進(jìn)行轉(zhuǎn)送消息所示的處理。
當(dāng)電子郵件消息被送回或如果希望對電子郵件消息的報(bào)告時(shí)，發(fā)生一個(gè)未分送事件。這種事件涉及圖38所示的handleNonDelivery()方法。該方法在消息對象上得到調(diào)用，并支持任何框架的特定擴(kuò)展—該擴(kuò)展執(zhí)行有關(guān)電子郵件消息內(nèi)容的送回或報(bào)告的功能?？蚣茉O(shè)計(jì)者必須決定這可能包括的功能和該方法可以使用的消息對象部分。其目的是復(fù)制必須報(bào)告的消息對象信息的部分或全部(可能通過產(chǎn)生新的“報(bào)告”消息對象)。
圖38顯示，處理從handleNonDelivery()方法開始—該方法調(diào)用附在消息上的各個(gè)接收者清單對象的handleNonDelivery()方法。在此概要中，有兩個(gè)接收者清單，SMTP接收者清單和SNADS接收者清單。在圖38中，首先對SMTP接收者清單對象調(diào)用該方法，如從消息對象云至SMTP接收者清單對象云的連線上的“1handleNonDelivery()”所示。handleNonDelivery()方法的實(shí)施者必須決定該方法提供什么類的未分送功能。該方法隨后調(diào)用SNADS接收者清單，如從消息至SNADS接收者清單的連線上的“2handleNonDelivery()”所示。handleNonDelivery()方法的實(shí)施者必須決定該方法提供什么類的未分送功能。
在某些情況下，消息對象可以包括必須得到處理的附件訪問清單。這由圖39所示的manageAttachments()方法處理。該方法在消息對象上得到調(diào)用，并支持對框架的任何特定擴(kuò)展—該擴(kuò)展執(zhí)行(或使用)附件訪問清單中的附件訪問對象上的特定功能。注意對于給定的消息對象，可能沒有附件訪問清單。
圖39的處理以消息的manageAttachments()方法開始，該方法調(diào)用附在消息上的每一個(gè)接收者清單對象的manageAttachments()方法。在圖39的概要中，假定有兩個(gè)接收者清單，SMTP接收者清單和SNADS接收者清單。先對SMTP接收者清單調(diào)用該方法，如從消息至SMTP接收者清單的連線上的“1manageAttachments()”所示。然后，manageAttachments()方法將對消息對象的附件訪問清單調(diào)用retrieve()方法。該概要假定，電子郵件消息的被訪問的附件將被查看，并可能被作為執(zhí)行manageAttachments()調(diào)用的一部分。manageAttachments()方法的實(shí)施者將設(shè)計(jì)manageAttachments()實(shí)際對電子郵件消息將執(zhí)行什么功能。該處理步驟在圖39中用至附件訪問清單的線上的符號“2retrieve()”表示。
下一個(gè)處理，是由消息的manageAttachments()方法調(diào)用附在消息上的下一個(gè)接收者清單對象上的manageAttachments()方法。圖39顯示了對SNADS接收者清單進(jìn)行該調(diào)用，如“3manageAttachments()”所表示的。然后，接收者清單的manageAttachments()方法將對附件訪問清單調(diào)用retrieve()方法，如“4retrieve()”表示的。象前面一樣，該概要假定，作為對manageAttachments()的執(zhí)行調(diào)用的一部分，電子郵件消息被訪問的附件將被查看。
最后，框架提供了會(huì)計(jì)功能，以跟蹤對消息處理等的收費(fèi)。圖40所示的accounting()方法在消息對象上得到調(diào)用，并支持對框架的特定擴(kuò)展—該擴(kuò)展執(zhí)行與對框架處理的電子郵件消息的會(huì)計(jì)處理有關(guān)的特定功能?？蚣茉O(shè)計(jì)者必須決定這可能包括什么功能和消息對象的哪些部分可以被該方法首先，消息的accounting()方法調(diào)用附在消息上的每一個(gè)接收者清單對象的accounting()方法。在此概要中，假定有兩個(gè)接收者清單，SMTP接收者清單和SNADS接收者清單。在圖40中，首先對SMTP接收者清單調(diào)用該方法，如從消息對象云至SMTP接收者清單對象云的連線上的“1accounting()”所示。然后accounting()方法對消息對象的發(fā)出者清單呼叫retrieve()方法，如至發(fā)出者清單云的線上的“2retrieve()”所示。該概要假定，該會(huì)計(jì)處理方法尋找一段電子郵件的發(fā)出者地址，作為執(zhí)行對會(huì)計(jì)處理的調(diào)用的一部分。會(huì)計(jì)處理的實(shí)施者必須設(shè)計(jì)該方法提供什么類的會(huì)計(jì)處理功能。該概要沒有顯示消息的任何其他對象能夠被獲取(諸如接收者清單、信封清單或附件訪問清單)以及對象可被用于執(zhí)行會(huì)計(jì)處理功能。
在下一個(gè)處理步驟中，消息的accounting()方法在附于消息的下一個(gè)接收者清單對象上調(diào)用accounting()方法。圖40顯示了正在對SNADS接收者清單進(jìn)行的調(diào)用，如從消息目標(biāo)云至SNADS對象云的連線上的“3accounting()”所示。最后，accounting()方法處理對消息對象的發(fā)出者清單調(diào)用retrieve()方法，如從SNADS接收者清單至發(fā)出者清單的連線上的“4retrieve()”所示。同樣，該概要假定會(huì)計(jì)處理方法尋找一段電子郵件的發(fā)出者地址，作為執(zhí)行會(huì)計(jì)處理調(diào)用執(zhí)行的一部分。
這里給出的實(shí)施例和例子，是為了最好地說明本發(fā)明及其實(shí)際應(yīng)用，從而使本領(lǐng)域的技術(shù)人員能夠作出和使用本發(fā)明。然而，本領(lǐng)域的技術(shù)人員應(yīng)該理解，前述的描述和例子只是為了說明和舉例的。所給出的描述不是排他的，也不是要將本發(fā)明限制在公布的具體形式。在不脫離本發(fā)明的精神和范圍的前體下，借助以上的描述，可以進(jìn)行很多修正和變形。記號在交流面向?qū)ο蟮某绦蛟O(shè)計(jì)的思想方面，還沒有一致接受的記號。在本說明書中所用的記號，與程序設(shè)計(jì)領(lǐng)域中被稱為Booch記號(以GradyBooch命名)的非常類似。Booch先生是可從TheBenjamin/CummingsPublishing Company，Inc.獲得的Object-Oriented Analysis and DesignWith Applications，2d ed.(1994)一書的作者。在本說明書中使用Booch記號，不應(yīng)該被理解為本專利申請的發(fā)明者和/或受讓人與Booch先生或Booch先生的雇主之間有什么聯(lián)系。Booch先生所用的記號體系，在上述書的第5章(171-228頁)進(jìn)行了更為詳細(xì)的描述。下面將大體上描述這里采用的記號體系。這里采用的其他記號約定，將根據(jù)需要得到描述。
由面向?qū)ο蟮目蚣苣Ｐ突南到y(tǒng)，可以高度抽象地用稱為頂級類圖的圖來表示。圖1是頂類圖的一個(gè)例子，它包含代表模型化的系統(tǒng)的框。這些框以層級結(jié)構(gòu)排列，從而使代表與系統(tǒng)的物理部件接近的抽象的框處于圖中的較低級，而代表更抽象的功能部件的框更接近圖的頂部。在圖1中，這些框被標(biāo)有“機(jī)構(gòu)”，以表示這些抽象包括用于實(shí)施模型化的系統(tǒng)部件的裝置。這些框(機(jī)構(gòu))可被認(rèn)為是類別—它們包括按照面向?qū)ο蟮某绦蛟O(shè)計(jì)的概念定義的相似類組。圖1代表了動(dòng)物園管理模型，因而較低的層級結(jié)構(gòu)框包括被稱為動(dòng)物機(jī)構(gòu)的框—它代表在動(dòng)物園模型中的動(dòng)物，以及一個(gè)被稱為圈養(yǎng)單元機(jī)構(gòu)的框—它代表動(dòng)物圍欄和籠子。在圖1的最高級，被稱為動(dòng)物園管理的框代表包含由人執(zhí)行的各種管理任務(wù)的功能抽象。
在頂級類圖中的框，代表了提供系統(tǒng)行為的系統(tǒng)抽象。該系統(tǒng)抽象包括類和對象。各系統(tǒng)類的細(xì)節(jié)在類圖中提供，而該類圖被用來顯示類的類別并表示各類的關(guān)系和責(zé)任。類由形狀不規(guī)則的、虛線圖象表示，這些圖象通常被稱為云。例如，圖2顯示了被表示為云的幾個(gè)類。各個(gè)類由對于有關(guān)的類類別來說是唯一的名來標(biāo)明，且該名還表示了各個(gè)類與圖1所示的機(jī)構(gòu)之一的關(guān)系。在類圖象中，類名被列在屬性、操作或方法名的上方。隨后跟著的是圓括號和包括在括號中的限制。圖3更詳細(xì)地顯示了動(dòng)物園管理類。圖3表示，動(dòng)物園管理類包括多個(gè)操作，包括被稱為5_minute_timer()、add_animal()和add_containment_unit()的操作。操作名(和類屬性名)中的詞被分隔開，以便于閱讀。在圖5中所示的類Animals中的被稱為feedfreq和temp range的屬性，顯示了類屬性List的一個(gè)事例。
機(jī)構(gòu)(圖1)和類(圖2)之間的連線，表示了這些抽象之間的關(guān)系的性質(zhì)。因此，圖1中的框之間的聯(lián)接，代表了各種機(jī)構(gòu)之間的關(guān)系。例如，直的連線表示共享信息的簡單聯(lián)系。“使用”關(guān)系是簡單聯(lián)系的一個(gè)明確表達(dá)，在這種聯(lián)系中被稱為服務(wù)器或提供者的抽象向被稱為用戶的另一個(gè)抽象提供服務(wù)。這種關(guān)系由在簡單聯(lián)系線的一端的開放圓圈表示，該開放圓圈的端部指示“使用”有關(guān)的服務(wù)器的用戶。
兩個(gè)類之間的簡單聯(lián)系的另一個(gè)明確表達(dá)，是被稱為繼承關(guān)系的類型。繼承是類之間的一種關(guān)系，其中一個(gè)類分享與一個(gè)或多個(gè)其他類有關(guān)的結(jié)構(gòu)和/或行為。繼承聯(lián)系也被稱為“是一個(gè)”關(guān)系。因此，給定兩個(gè)類A和B，如果類A是B的一個(gè)例子，則A與類B有繼承關(guān)系；A被稱為是B的子類，且B被稱為是A的母類。即，A“是一個(gè)”B。繼承關(guān)系用一端帶有箭頭的連線表示，以表示一個(gè)子類，該子類從位于連線另一端的母類導(dǎo)出其特性。
類關(guān)系的另一個(gè)明確表達(dá)，被稱為聚集關(guān)系，它表示全部與其部分或?qū)傩灶愔g的聯(lián)系。在記號上，全部類與屬性類用聯(lián)系線相聯(lián)，且它們之間的聚集關(guān)系用在全部類端部的實(shí)圓圈表示，而屬性處于另一端。
類圖表示的另一種關(guān)系，是例示關(guān)系。例示關(guān)系代表類的一個(gè)事例，諸如由程序設(shè)計(jì)語言支持的類的一種具體實(shí)施。例如，稱為“動(dòng)物”的類可以具有多個(gè)例示，包括獅子、老虎和熊。類的例示用帶有箭頭的虛聯(lián)系線表示，箭頭從類的事例指向一般的類。
最后，被稱為亞類的類關(guān)系，表示這樣的關(guān)系，即其中類自身被當(dāng)作一個(gè)可被操縱的對象。即，亞類是這樣的類，即其事例本身也是類。某些計(jì)算機(jī)語言，諸如Small Talk，支持亞類概念。這種關(guān)系用帶有箭頭的陰影線表示，其中箭頭從亞類的事例指向總的亞類。
類可以被參數(shù)化，它表示其結(jié)構(gòu)和行為被與其形式類參數(shù)相獨(dú)立地得到定義的類組。參數(shù)化的類由云形的類圖象表示，其中矩形框被置于云部分的上方。參數(shù)清單在矩形框之內(nèi)命名。例示的類包括參數(shù)框—稱為裝飾，與用于一般類的虛線框形成對照。參數(shù)化類與其例示的類之間的例示關(guān)系，由指向參數(shù)化的類的虛線表示。通常，例示的類要求與另一實(shí)際類的“使用”關(guān)系，以被用作實(shí)際的參數(shù)。
類的性質(zhì)可用包含在類云圖象中的類裝飾表示。具體地，抽象類用位類的性質(zhì)可用包含在類云圖象中的類裝飾表示。具體地，抽象類用位于云中的三角內(nèi)的大寫“A”表示。抽象類是這樣的類，即對于它不能產(chǎn)生事例。即，它是類組成的類。其他的類裝飾是OO實(shí)施語言的功能。例如，C++語言允許特定的類資格，該資格將被給予特定的裝飾。靜態(tài)類由裝飾三角內(nèi)的大寫“S”表示，朋友類由裝飾三角內(nèi)的大寫“F”表示，且虛擬類由裝飾三角中的大寫“V”表示。
除了定義類，面向?qū)ο蟮某绦蛟O(shè)計(jì)系統(tǒng)的設(shè)計(jì)者必須定義對象(見Booch書的第136頁)。對象用實(shí)線云表示，在該云中對象屬性上方有對象名。對象是實(shí)際的實(shí)體，它呈現(xiàn)確定的行為。對象被用來表示實(shí)際系統(tǒng)的某些部分，這些部分由面向?qū)ο蟮某绦蛟O(shè)計(jì)表示。對象的特征在于狀態(tài)、行為和身份。對象可被認(rèn)為是類的一個(gè)事例。對象的行為是對對象在其狀態(tài)改變和其消息傳送方面如何行動(dòng)和反應(yīng)的表示。
對象和它們之間的關(guān)系被表示在對象圖中，該對象圖包括具有聯(lián)接線的對象圖象，這些聯(lián)接線表示了對象之間的同步。聯(lián)接線被依次編號，以表示操作流程。在兩個(gè)對象之間存在有聯(lián)接線，表明了它們對應(yīng)的類之間的聯(lián)系，并表示了它們之間的通信路徑。因此，兩個(gè)對象之間的聯(lián)接線，表明一個(gè)對象可以向另一個(gè)傳送消息。消息傳送的方向用在簡單的連線上加箭頭來表示，該箭頭從調(diào)用操作的對象(被稱為用戶)指向提供該操作的對象(稱為提供者)。對簡單的同步關(guān)系的這種代表，表示了最簡單形式的消息傳送。這種聯(lián)系可以表示例如操作的調(diào)用。操作參數(shù)可被表示在聯(lián)接線附近。
某些對象可以是主動(dòng)的，這意味著它們實(shí)現(xiàn)它們自己的控制線。即這種對象不只是順序性的。主動(dòng)對象可以具有各種當(dāng)前特性。如果對象具有多個(gè)控制線，則同步必須得到說明。消息同步化可以是同步的，這意味著用戶將等候，直到提供者接受消息。同步的同步化，用帶有箭頭的X表示。同步可包括阻止消息傳送，這意味著如果提供者不能立即給消息提供服務(wù)，用戶將放棄消息。阻止作用由指回到自身的箭頭表示。同步可以包括定時(shí)同步，這意味著如果提供者不能在指定的時(shí)間里給消息提供服務(wù)，用戶將放棄消息。定時(shí)同步用聯(lián)接線箭頭附近的時(shí)鐘來表示。最后，同步可將該消息排隊(duì)，且用戶隨后不等候提供者而繼續(xù)進(jìn)行操作。本領(lǐng)域的技術(shù)人員應(yīng)該理解的是，異步的消息同步與中斷處理類似。異步的消息同步用半箭頭表示。
應(yīng)該指出，Booch記號包括跟蹤對象和類的執(zhí)行的作用圖。作用圖基本上是重新組成的對象圖。即，作用圖與對象圖相比并沒有給出更多的信息，而只是以不同的形式提供了相同的信息。本說明書采用了對象圖而不是作用圖，但本領(lǐng)域的技術(shù)人員應(yīng)該理解它們是等價(jià)的，且應(yīng)該理解如何從一個(gè)轉(zhuǎn)換到另一個(gè)，而不用再作進(jìn)一步的說明。
例如，在圖7中，被稱為Zelda 706的對象，通過調(diào)用來自被稱為Zookeeper Register的對象的、被稱為List Zoo keepers的操作，而獲得了當(dāng)前動(dòng)物園工作人員的清單。在圖7中，第二個(gè)處理步驟，用Zoo keeperRegister對象表示—該對象通過將一個(gè)消息傳送到表示該動(dòng)物園工作人員清單的Zelda對象而響應(yīng)該操作調(diào)用。該動(dòng)物園工作人員對象包括被稱為Tina、Vince和Fred的Zoo keeper類的成員。該對象圖中表示的第三個(gè)步驟，是由對象Zelda將一個(gè)消息傳送給各個(gè)動(dòng)物園工作人員，通過調(diào)用各個(gè)動(dòng)物園工作人員對象的相應(yīng)Check Animals操作，命令它們檢查動(dòng)物。
權(quán)利要求
1.一種計(jì)算機(jī)系統(tǒng)，包括中央處理單元；用戶接口；網(wǎng)絡(luò)接口，通過它接收電子郵件消息；以及主存儲(chǔ)器，它具有支持面向?qū)ο蟮某绦蛟O(shè)計(jì)環(huán)境的操作系統(tǒng)，該環(huán)境包含一個(gè)框架，該框架定義了控制消息處理的消息中心對象；包含一組消息對象的消息類，這些消息對象定義了包含在接收的電子郵件消息中的發(fā)出者、接收者和消息內(nèi)容信息；以及一組對象方法，這些對象方法放消息中心對象用來根據(jù)電子郵件消息的消息處理協(xié)議而將包含在接收的電子郵件消息中的信息置于消息對象中并對其進(jìn)行相應(yīng)的處理。
2.根據(jù)權(quán)利要求1的計(jì)算機(jī)系統(tǒng)，其中消息對象包括屬于這樣的類的對象，這些類包括了標(biāo)明發(fā)出網(wǎng)絡(luò)用戶的網(wǎng)絡(luò)地址的消息發(fā)出者清單、標(biāo)明電子郵件消息的預(yù)期接收者的清單、以及包含消息協(xié)議的消息屬性信息的信封清單。
3.根據(jù)權(quán)利要求2的計(jì)算機(jī)系統(tǒng)，其中消息發(fā)出者清單類包括定義發(fā)出用戶網(wǎng)絡(luò)地址和消息協(xié)議類型的對象。
4.根據(jù)權(quán)利要求3的計(jì)算機(jī)系統(tǒng)，其中消息協(xié)議類型由發(fā)出用戶網(wǎng)絡(luò)地址對象定義。
5.根據(jù)權(quán)利要求2的計(jì)算機(jī)系統(tǒng)，其中接收者清單類包括由接收者用戶網(wǎng)絡(luò)地址和接收者地址消息協(xié)議類型定義的對象。
6.根據(jù)權(quán)利要求5的計(jì)算機(jī)系統(tǒng)，其中電子郵件消息的接收者清單對象指定了多個(gè)不同的消息協(xié)議類型。
7.根據(jù)權(quán)利要求2的計(jì)算機(jī)系統(tǒng)，其中信封清單類包括由消息協(xié)議類型定義的對象。
8.根據(jù)權(quán)利要求7的計(jì)算機(jī)系統(tǒng)，其中電子郵件消息的信封清單對象指定了多個(gè)不同的消息協(xié)議類型。
9.根據(jù)權(quán)利要求2的計(jì)算機(jī)系統(tǒng)，其中消息對象進(jìn)一步包括屬于一個(gè)附件訪問類的對象，該附件訪問類標(biāo)明了附在電子郵件消息上的信息。
10.根據(jù)權(quán)利要求9的計(jì)算機(jī)系統(tǒng)，其中附件訪問類對象指定了附在電子郵件消息上的信息的多個(gè)不同協(xié)議類型。
11.根據(jù)權(quán)利要求2的計(jì)算機(jī)系統(tǒng)，其中對象方法包括產(chǎn)生發(fā)出者清單對象的發(fā)出者清單產(chǎn)生方法、產(chǎn)生接收者清單對象的接收者清單產(chǎn)生方法、以及產(chǎn)生信封對象的信封清單產(chǎn)生方法。
12.根據(jù)權(quán)利要求2的計(jì)算機(jī)系統(tǒng)，其中對象方法包括信封清單產(chǎn)生方法，該產(chǎn)生方法確定消息協(xié)議類型并產(chǎn)生相應(yīng)的信封對象。
13.根據(jù)權(quán)利要求12的計(jì)算機(jī)系統(tǒng)，其中對象方法進(jìn)一步包括相加方法，該相加方法將電子郵件消息置于消息隊(duì)列中，以由消息中心對象進(jìn)行處理。
14.根據(jù)權(quán)利要求12的計(jì)算機(jī)系統(tǒng)，其中對象方法進(jìn)一步包括檢索方法，該檢索方法從消息隊(duì)列中檢索電子郵件消息，以由消息中心對象進(jìn)行處理。
15.根據(jù)權(quán)利要求2的計(jì)算機(jī)系統(tǒng)，其中對象方法包括一個(gè)地址分解方法，該方法為接收者清單類的每一個(gè)成員確定了一個(gè)接收者用戶網(wǎng)絡(luò)地址。
16.根據(jù)權(quán)利要求2的計(jì)算機(jī)系統(tǒng)，其中對象方法包括進(jìn)行電子郵件消息的消息安全檢查和核準(zhǔn)的安全核準(zhǔn)方法。
17.根據(jù)權(quán)利要求2的計(jì)算機(jī)系統(tǒng)，其中對象方法包括附件訪問清單方法，該方法產(chǎn)生包含附在電子郵件消息上的信息的附件清單對象。
18.根據(jù)權(quán)利要求2的計(jì)算機(jī)系統(tǒng)，其中消息對象進(jìn)一步包括屬于這樣一些類的對象—這些類包括消息發(fā)出者清單、原始接收者清單、接收者清單和信封清單。
19.根據(jù)權(quán)利要求18的計(jì)算機(jī)系統(tǒng)，其中原始接收者清單類包含一或多個(gè)條目對象，其每一個(gè)都包含由接收者用戶網(wǎng)絡(luò)地址和分發(fā)類型定義的一或多個(gè)對象。
20.根據(jù)權(quán)利要求19的計(jì)算機(jī)系統(tǒng)，其中接收者清單類包括由接收者用戶網(wǎng)絡(luò)地址和接收者地址消息協(xié)議類型定義的對象。
21.根據(jù)權(quán)利要求20的計(jì)算機(jī)系統(tǒng)，其中各個(gè)接收者用戶網(wǎng)絡(luò)地址指定了消息協(xié)議類型。
22.根據(jù)權(quán)利要求20的計(jì)算機(jī)系統(tǒng)，其中消息對象包括不同消息協(xié)議的多個(gè)接收者清單對象。
23.根據(jù)權(quán)利要求20的計(jì)算機(jī)系統(tǒng)，其中對象方法包括接收者清單分解方法，該方法從原始接收者清單條目對象產(chǎn)生接收者清單對象。
24.根據(jù)權(quán)利要求23的計(jì)算機(jī)系統(tǒng)，其中接收者清單分解方法在原始接收者清單條目對象上反復(fù)進(jìn)行操作，直到分發(fā)類型不再指定額外的目的地地址，從而使分發(fā)類型指定了與單個(gè)的原始接收者清單條目相對應(yīng)的一組目的地地址。
25.一種在與網(wǎng)絡(luò)聯(lián)接的計(jì)算機(jī)系統(tǒng)中使用的面向?qū)ο蟮目蚣?，該?jì)算機(jī)系統(tǒng)從發(fā)出電子郵件的消息的網(wǎng)絡(luò)用戶接收電子郵件消息并具有支持面向?qū)ο蟮某绦蛟O(shè)計(jì)環(huán)境的操作系統(tǒng)，該環(huán)境保持著控制電子郵件消息處理的消息中心對象；一個(gè)消息類，它包括一組消息對象，該消息對象包括在接收的電子郵件消息中所包含的發(fā)出者、接收者和消息內(nèi)容信息；以及，一組對象方法，這些對象方法被消息中心對象用來根據(jù)接收的電子郵件消息的消息處理協(xié)議而將接收的電子郵件消息的信息置入消息對象并對其進(jìn)行相應(yīng)的處理。
26.根據(jù)權(quán)利要求25的框架，其中消息類對象包括屬于這樣的類的對象—即這些類包括消息發(fā)出者清單，它標(biāo)明發(fā)出電子郵件消息的網(wǎng)絡(luò)用戶的網(wǎng)絡(luò)地址；接收者清單，它標(biāo)明電子郵件消息的預(yù)期接收者；以及，信封清單，它包含消息協(xié)議的消息屬性信息。
27.根據(jù)權(quán)利要求26的框架，其中消息發(fā)出者清單類包括定義發(fā)出電子郵件信息的用戶網(wǎng)絡(luò)地址和消息協(xié)議類型的對象。
28.根據(jù)權(quán)利要求27的框架，其中消息協(xié)議類型由發(fā)出電子郵件信息的用戶網(wǎng)絡(luò)地址對象定義。
29.根據(jù)權(quán)利要求26的框架，其中接收者清單類包括由接收者用戶網(wǎng)絡(luò)地址和接收者地址消息協(xié)議類型定義的對象。
30.根據(jù)權(quán)利要求29的框架，其中電子郵件消息的接收者清單對象指定了多個(gè)不同的消息協(xié)議類型。
31.根據(jù)權(quán)利要求26的框架，其中信封清單類包括由消息協(xié)議類型定義的對象。
32.根據(jù)權(quán)利要求31的框架，其中電子郵件消息的信封清單對象指定了多個(gè)不同的消息協(xié)議類型。
33.根據(jù)權(quán)利要求26的框架，其中消息對象進(jìn)一步包括屬于一個(gè)附件訪問類的對象，該附件訪問類標(biāo)明了附在電子郵件消息上的信息。
34.根據(jù)權(quán)利要求33的框架，其中附件訪問類對象指定了附在電子郵件消息上的信息的多個(gè)不同的協(xié)議類型。
35.根據(jù)權(quán)利要求26的框架，其中對象方法包括產(chǎn)生發(fā)出者清單對象的發(fā)出者清單產(chǎn)生方法、產(chǎn)生接收者清單對象的接收者清單產(chǎn)生方法、以及產(chǎn)生信封對象的信封清單產(chǎn)生方法。
36.根據(jù)權(quán)利要求26的框架，其中對象方法包括確定消息協(xié)議類型并產(chǎn)生相應(yīng)的信封對象的信封清單產(chǎn)生方法。
37.根據(jù)權(quán)利要求36的框架，其中對象方法進(jìn)一步包括一個(gè)相加方法，該相加方法將電子郵件消息置于消息隊(duì)列中以由消息中心對象進(jìn)行處理。
38.根據(jù)權(quán)利要求36的框架，其中對象方法進(jìn)一步包括檢索方法，該檢索方法從消息隊(duì)列檢索電子郵件消息，以由消息中心對象進(jìn)行處理。
39.根據(jù)權(quán)利要求26的框架，其中對象方法包括為接收者清單類的每一個(gè)成員確定接收者用戶網(wǎng)絡(luò)地址的地址分解方法。
40.根據(jù)權(quán)利要求26的框架，其中對象方法包括進(jìn)行電子郵件消息的消息安全檢查和核準(zhǔn)的安全核準(zhǔn)方法。
41.根據(jù)權(quán)利要求26的框架，其中對象方法包括一個(gè)附件訪問清單方法，該方法產(chǎn)生包含附在電子郵件消息上的信息的附件清單對象。
42.根據(jù)權(quán)利要求26的框架，其中消息對象進(jìn)一步包括屬于包括消息發(fā)出者清單、原始接收者清單、接收者清單和信封清單的類的對象。
43.根據(jù)權(quán)利要求42的框架，其中原始接收者清單類包含一或多個(gè)條目對象，其每一個(gè)都包含由接收者用戶網(wǎng)絡(luò)地址和分發(fā)類型定義的一或多個(gè)對象。
44.根據(jù)權(quán)利要求43的框架，其中接收者清單類包括由接收者用戶網(wǎng)絡(luò)地址和接收者地址消息協(xié)議類型定義的對象。
45.根據(jù)權(quán)利要求44的框架，其中各個(gè)接收者用戶網(wǎng)絡(luò)地址指定了消息協(xié)議類型。
46.根據(jù)權(quán)利要求44的框架，其中消息對象包括不同消息協(xié)議的多個(gè)接收者清單對象。
47.根據(jù)權(quán)利要求44的框架，其中對象方法包括接收者清單分解方法，該方法從原始接收者清單條目對象產(chǎn)生接收者清單對象。
48.根據(jù)權(quán)利要求47的框架，其中接收者清單分解方法反復(fù)在原始接收者清單條目對象上進(jìn)行操作，直到分發(fā)類型不再指定額外的目的地地址，從而使分發(fā)類型指定了與單個(gè)的原始接收者清單條目相對應(yīng)的一組目的地地址。
全文摘要
用于面向?qū)ο蟮木幊滔到y(tǒng)的框架提供了公共消息處理系統(tǒng)結(jié)構(gòu)，該結(jié)構(gòu)能夠被置于任何OOP平臺(tái)上并得到適當(dāng)配置以支持任何電子郵件消息協(xié)議標(biāo)準(zhǔn)或具體的郵遞服務(wù)器功能。該框架把電子郵件消息定義為若干不同的對象，這些對象每一個(gè)都包含描述消息的某一部分的信息。實(shí)施了該框架的系統(tǒng)所接收的所有消息，都被定義在其核心對象結(jié)構(gòu)上。另一組對象和方法定義了郵遞服務(wù)器處理消息所需的處理步驟。
文檔編號H04L29/08GK1405694SQ0214060
公開日2003年3月26日 申請日期1996年12月12日 優(yōu)先權(quán)日1995年12月19日
發(fā)明者弗蘭克·威廉姆·吉爾切斯特, 厄里克·奈爾斯·赫尼斯, 厄里克·H·簡尼, 約翰·克里斯托弗·里泊斯切, 喬治·詹姆斯·羅馬諾 申請人:國際商業(yè)機(jī)器公司