282.軟件體系結構的風格與模式

時間 2019-11-20

標籤軟件體系結構風格模式简体版

原文原文鏈接

　　建築模式
　　Christopher Alexander, The Timeless Way of Building, p247, 1979
　　每一個模式是一個由三部分組成的規則，表達了特定環境、問題和解(solution)之間的關係。
　　做爲現實世界的一個成分，每一個模式表達了下列三者之間的一種關係：特定環境，在該環境中反覆出現的力(forces)的系統，以及協調這些力的某種空間排列。
　　做爲語言的一個成分，每一個模式是一條指令，展現了這種空間排列如何被一再重複使用，目的是協調同特定環境相關的力的系統。
　　簡單地說，模式既是存在於現實世界中的事物，又是告訴咱們如何以及什麼時候創造該事物的規則。模式既是過程，又是事物；既是活生生的事物的描述，又是創造該事物的過程的描述。
軟件體系結構的構建模式html

　　軟件體系結構的特色之一就是抽象出了不少常見的系統構建模式，這些模式（或者說結構風格）是系統設計人員多年工做經驗的總結。java

軟件體系結構風格和模式的概念
　　正則表達式

軟件體系結構風格(Architectural Style)
　　一種體系結構風格以結構組織模式定義了一個系統家族
　　關於構件和鏈接件類型的術語；一組約束對它們組合方式的規定；一個或多個語義模型，規定了如何從各成分的特性決定系統總體特性
　　歸納地說，一種軟件體系結構風格刻劃一個具備共享結構和語義的系統家族算法

軟件體系結構模式(Architectural Pattern)
　　一種軟件體系結構模式是對某個具體環境下問題的結構性解決方法數據庫

體系結構風格（模式系統中的詞彙）
　　目前尚不完善
　　每一個風格能夠視爲一組構件的集合，以及構件間的交互（鏈接器）
　　構件（Components）＋鏈接器（Connectors）
E.g. C/S結構中
構件： Client, Server
鏈接器： C/S間的通信協議瀏覽器

軟件體系結構的構建風格
　　風格分類：
1. 管道-過濾器風格
2. 面向對象風格
3. 事件驅動風格
4. 分層風格
5. 數據共享風格
6. 解釋器風格
7. 反饋控制環風格
8. 異構風格的集成安全

特別注意：體系結構風格不是對軟件進行分類的標準。它僅僅是表示描述軟件的不一樣角度而已
例如一個系統採用了分層風格，但這並不妨礙它用面向對象的方法來實現。同一個系統採用多種風格形成了所謂體系結構風格的異構組合。網絡

管道-過濾器風格
概述
　　在管道-過濾器風格下，每一個功能模塊都有一組輸入和輸出。功能模塊稱做過濾器（filters）；功能模塊間的鏈接能夠看做輸入、輸出數據流之間的通路，因此稱做管道（pipes）。
　　管道-過濾器風格的特性之一在於過濾器的相對獨立性，即過濾器獨立完成自身功能，相互之間無需進行狀態交互。數據結構

管道-過濾器風格特性
過濾器是獨立運行的構件
　　非臨近的過濾器之間不共享狀態
　　過濾器自身無狀態
過濾器對其處理上下鏈接的過濾器「無知」
　　對相鄰的過濾器不施加任何限制
結果的正確性不依賴於各個過濾器運行的前後次序
　　各過濾器在輸入具有後完成本身的計算。完整的計算過程包含在過濾器之間的拓撲結構中。併發

管道-過濾器風格
一個管道-過濾器風格的示意圖以下圖所示：

管道-過濾器風格
一個採用了嵌套的管道過濾器的系統示例：

管道-過濾器風格實例
Unix系統中的管道過濾器結構

ls –al | grep my

通信協議的信息封裝(e.g. SDH)

管道-過濾器風格優勢
設計者能夠將整個系統的輸入、輸出特性簡單的理解爲各個過濾器功能的合成。
設計人員將整個系統的輸入輸出行爲理解爲單個過濾器行爲的疊加與組合。這樣能夠將問題分解，化繁爲簡。將系統抽象成一個「黑箱」，其輸入是系統中第一個過濾器的輸入管道，輸出是系統中最後一個過濾器的輸出管道，而其內部各功能模塊的具體實現對用戶徹底透明。
管道-過濾器風格優勢

管道-過濾器風格支持功能模塊的複用
任何兩個過濾器，只要它們之間傳送的數據遵照共同的規約，就能夠相鏈接。每一個過濾器都有本身獨立的輸入輸出接口，若是過濾器間傳輸的數據遵照其規約，只要用管道將它們鏈接就能夠正常工做。
管道-過濾器風格優勢
基於管道-過濾器風格的系統具備較強的可維護性和可擴展性。
舊的過濾器能夠被替代，新的過濾器能夠添加到已有的系統上。軟件的易於維護和升級是衡量軟件系統質量的重要指標之一，在管道-過濾器模型中，只要遵照輸入輸出數據規約，任何一個過濾器均可以被另外一個新的過濾器代替，同時爲加強程序功能，能夠添加新的過濾器。這樣，系統的可維護性和可升級性獲得了保證。

管道-過濾器風格優勢

支持一些特定的分析，如吞吐量計算和死鎖檢測等。
利用管道-過濾器風格的視圖，能夠很容易的獲得系統的資源使用和請求的狀態圖。而後，根據操做系統原理等相關理論中的死鎖檢測方法就能夠分析出系統目前所處的狀態，是否存在死鎖可能及如何消除死鎖等問題。

管道-過濾器風格優勢
管道-過濾器風格具備併發性
每一個過濾器做爲一個單獨的執行任務，能夠與其它過濾器併發執行。過濾器的執行是獨立的，不依賴於其它過濾器的。在實際運行時，能夠將存在併發可能的多個過濾器看做多個併發的任務並行執行，從而大大提升系統的總體效率，加快處理速度。

管道-過濾器風格不足
交互式處理能力弱
管道-過濾器模型適於數據流的處理和變換，不適合爲與用戶交互頻繁的系統建模。在這種模型中，每一個過濾器都有本身的數據，這些數據或者是從磁盤存儲器中讀取來，或者是由另外一個過濾器的輸出導入進來，整個系統沒有一個共享的數據區。這樣，當用戶要操做某一項數據時，要涉及到多個過濾器對相應數據的操做，其實現較爲複雜。由以上的缺點，能夠對每一個過濾器增長相應的用戶控制接口，使得外部能夠對過濾器的執行進行控制。
管道-過濾器風格不足
管道-過濾器風格不足
管道-過濾器風格每每致使系統處理過程的成批操做。
設計者也許不得不花費精力協調兩個相對獨立但又存在某種關係的數據流之間的關係，例如多過濾器併發執行時數據流之間的同步問題等。
根據實際設計的須要，設計者也須要對數據傳輸進行特定的處理（如爲了防止數據泄漏而採起加密等手段），致使過濾器必須對輸入、輸出管道中的數據流進行解析或反解析，增長了過濾器具體實現的複雜性。

管道-過濾器風格實例——數字通訊系統
通訊的目的是傳遞消息。消息具備不一樣的形式，例如：符號、文字、語音、音樂、數據、圖片、圖像等等。於是，根據所傳遞消息的不一樣，目前通訊業務能夠分爲電報、電話、傳真、數據傳輸及可視電話等。對於基本的點對點通訊，是把發送端的消息傳遞到接收端。

管道-過濾器風格實例——數字通訊系統
將上圖發送端進一步細分爲信息源和發送設備，將接收端細分爲接收設備和受信者；同時，在通訊過程當中會有噪聲干擾，在模型中添加噪聲源可獲得圖所示的數字通訊系統粗略模型。

管道-過濾器風格實例——數字通訊系統
圖中各單元做用：
信息源把各類可能信息轉換成原始電信號；
發送設備對原始電信號完成某種變化，便於原始信號在信道中傳輸，而後再送入信道；
信道是指信號傳輸的通道，它既能夠當作是管道（由於它的目的並非爲了實現某種功能，僅僅是爲了信號的傳輸），也能夠從某種意義上看作是過濾器（由於信號通過信道後會產生一些變化，好比加入噪聲的影響，從而改變了發送設備發出的信號）。
接收設備從接收信號中恢復出相應的原始信號；
受信者（也稱爲信息宿或接收終端）是將復原的原始信號轉換成相應的消息。
噪聲源是信道中的噪聲以及分散在通訊系統其它各處的噪聲的集中體現，它使原信號受到了干擾，產生畸變。

管道-過濾器風格實例——數字通訊系統

在數字通訊中存在如下幾個突出的問題：
數字信號傳輸時，信道噪聲或干擾所形成的差錯，原則上均可以經過差錯控制編碼等手段來控制。爲此，在發送端須要增長一個編碼器，而在接收端相應的須要一個解碼器。
當須要保密時，能夠有效的對基帶信號進行加密，防止信息被竊取或通訊被破壞。此時，在接收端就須要進行解密。
因爲數字通訊傳輸的是一個接一個按節拍傳送的數字信號單元，即碼元，於是接收端必須與發送端按相同的節拍進行接收。否則，會因接收節拍不一致而形成混亂，使接收倒的數據所有無效。所以，數字通訊系統中必須有同步控制構件。
針對上述問題，可獲得數字通訊系統詳細模型（下圖）

管道-過濾器風格實例——數字通訊系統
數據源、數據接收端、管道介紹
Data Source （數據源）
input data stream to the system , for example
A file consisting of lines of text
A sensor delivering a sequence of numbers
data can be pushed or pulled into first processing stage
Pipes（管道）
connections between filters , between data source and the first filter , between the last filter and the data sink
synchronizes joined active filters , for example , by a FIFO ( first-in-first-out ) buffer
for passive filters , the pipes can be implemented by a direct call
Make the filter recombination harder
Data Sink （數據接收端）
consumes output data

管道-過濾器風格實例

管道-過濾器模式的體系結構是面向數據流的軟件體系結構。它最典型的應用是在編譯系統。一個普通的編譯系統包括詞法分析器，語法分析器，語義分析與中間代碼生成器，優化器，目標代碼生成器等一系列對源程序進行處理的過程。人們能夠將編譯系統看做一系列過濾器的鏈接體，按照管道&過濾器的體系結構進行設計。
需求描述：假設有一批實時的二維座標點數據須要變換（即對點的橫、縱座標進行縮放），並在屏幕上進行顯示，要求外部要能設置變換規則（如縮放倍數）和顯示規則（如顯示模式和顯示顏色）。
管道-過濾器風格實例

體系結構建模
這是一個對座標點的數據流進行順序處理的過程，能夠應用管道-過濾器體系結構建模。將這個系統分爲兩個過濾器，一個爲座標點數據流變換過濾器，另外一個爲座標點數據流實時顯示過濾器。其中，座標點數據流變換過濾器有一個外部控制接口對變換規則如縮放倍數進行設置，座標點數據流實時顯示過濾器有一個外部控制接口對顯示規則如顯示模式和顯示顏色進行設置。整個系統的體系結構如圖所示。
管道-過濾器風格實例

管道-過濾器風格實例
過濾器的設計
能夠將過濾器用狀態轉換圖表示。過濾器有以下狀態：中止狀態，工做狀態，等待狀態，休眠狀態。
中止狀態：表示過濾器處於待啓動狀態，當外部啓動過濾器後，過濾器處於處理狀態；
處理狀態：表示過濾器正在處理輸入數據隊列中的數據；
等待狀態：表示過濾器的輸入數據隊列爲空，此時過濾器等待，當有新的數據輸入時，過濾器處於處理狀態；
休眠狀態：表示過濾器已經啓動，但被掛起。掛起的緣由多是因爲外界用戶要設置過濾器的控制參數，這樣暫時將過濾器掛起但不停止它，當控制參數設置完畢後再將過濾器還原，繼續運行。這樣，實現了較高的效率。

管道-過濾器風格實例
過濾器介紹
過濾器的做用：對輸入數據的處理
enriches : computing and adding info
refines : concentrating or extracting info
transforms : delivering data into some other representation
被動式過濾器（Passive filter）
adjacent pipes pulls/pushes output/input data from/into the filter
active either as a function ( pull ) or as a procedure ( push )
主動式過濾器（Active filter）
filter is active in a loop , check the pipes for data
processing on its own as a separate program or thread

管道-過濾器風格的類型
類型
pipelines — linear sequences of filters
bounded pipes — limited amount of data on a pipe
typed pipes — data strongly typed
batch sequential — data streams are not incremental
管道和鏈接器風格的參考文獻
Maurice J. Bach. The Design of the UNIX Operating System, chap. 5, pp. 11-119. Software Series. Prentice Hall, 1986
Norman Delisle and David Garlan. Applying formal specification to industrial problems: A specification of an oscilloscope. IEEE Software, 7(5):29-37, Sept. 1990
J. C. Browne, M. Azam, and S. Sobek. Code: A unified approach to parallel programming. IEEE Software, July 1989.
G. Kahn. The semantics of a simple language for parallel programming. Information Processing, 1974
David Barstow and Alex Wolf. Design methods and software architectures track. In Proceedings of the 7th International Workshop in Software Specification and Design. IEEE Press, 1993
面向對象風格特徵
概述
面相對象模式集數據抽象、抽象數據類型、類繼承爲一體，使軟件工程公認的模塊化、信息隱藏、抽象、重用性等原則在面向對象風格下得以充分實現。
應用場合
面向對象的體系結構模式適用於數據和功能分離的系統中，一樣也適合於問題域模型比較明顯，或須要人機交互界面的系統。大多數應用事件驅動風格的系統也經常應用了面向對象風格
面向對象風格設計原則
面向對象風格系統設計時有下述幾條基本原則
將邏輯上的實體映射爲對象，實體之間的關係映射爲對象之間的應用關係。
對象利用應用關係來訪問對方公開的接口，完成某個特定任務；一組對象之間相互協做，完成整體目標。
面向對象風格
面向對象風格優勢
高度模塊性
數據與其相關操做被組織爲對象，成爲模塊組織的基本單位
封裝功能
一組功能和其實現細節被封裝在一個對象中，具備功能的接口被暴露出來
代碼共享
對象的相對獨立性可被反覆重用，經過拼裝造成不一樣的軟件系統
靈活性
對象在組織過程當中，相互關係能夠任意變化，只要接口兼容
易維護性
對象接近於人對問題和解決方案模型的思惟方式，易於理解和修改
面向對象風格實例——人事檔案管理系統
面向對象風格實例——人事檔案管理系統
系統功能介紹：
檔案管理根據高校人事檔案管理的特色，本模塊可經過錄入各種人事檔案信息，來構造檔案數據庫，編制各類目錄索檢。針對檔案材料錄入工做量較大，在該功能模塊中設置了多種方式快速錄入法，如對指定的部份內容可採用代碼錄入和菜單選項等輸入方法.
信息檢索該模塊主要是檢索有關的人事檔案信息，其檢索方式爲姓氏筆畫檢索目錄。在具體檢索中又可分爲精確查詢和模糊查詢，並可將檢索內容動態輸出，知足檔案查詢的須要。
檔案借閱該模塊主要是對檔案的借閱狀況、歸還狀況、利用登記等方面進行管理。它能爲研究如何更有效地利用人事檔案資料提供必要的信息。
面向對象風格實例——人事檔案管理系統
檔案轉遞該模塊包括人事檔案的轉進和轉出管理，編制清單，並能在檔案轉遞後，對已變動檔案數據庫進行相應地調整，以完成相應檔案的刪加。
統計報表該模塊主要用於統計庫存的各種人事檔案的實際數量，及每一年歸檔的各種檔案數量，並可完成相應的圖形繪製和報表打印。其中，在報表生成中，該模塊可根據管理人員對報表的自定義設置來生成相應的非範式報表。
系統維護因爲高校人事檔案的數據管理是一項很是重要的工做，尤爲是它的安全可靠性。所以，在進入本模塊操做以前，系統會提醒用戶輸入姓名、操做口令和權限級別。同時該功能模塊還包括操做員管理、口令修改、從新登陸、權限級別設置、系統日誌及系統初始化六個子模塊。
系統幫助本模塊提供了在線聯機幫助，可實現幫助主題的查詢，還提供了計算器、日記/日曆等系統工具和關於本系統的簡介。

面向對象風格實例——人事檔案管理系統
面向對象風格實例——人事檔案管理系統
面向對象風格
ODS系統中構件、鏈接器和配置的模型,以下圖所示：

面向對象風格實例

構件的描述方法:利用GUI體系結構框架自動生成工具，能夠完成下述幾點功能：
生成構件模型，包括構件的屬性、接口和實現；
創建鏈接器模型，包括協議、屬性和實現；
體系結構的抽象和封裝；
類型和類型檢查；
主動規範，提供設計嚮導；
多視圖模式，對不一樣層次的用戶顯示不一樣的內容；
生成實現，如將構件對應爲面向對象技術中的類；
將系統的修改動態映射到實現。

面向對象風格實例

面向對象風格實例
具備自適應穩定性的鏈接器模型
鏈接器中的通訊協議棧

面向對象風格不足

面向對象風格最大的不足在於若是一個對象須要調用另外一個對象，它就必須知道那個對象的標識（對象名或對象引用），這樣就無形之中加強了對象之間的依賴關係。若是一個對象改變了本身的標識，就必須通知系統中全部和它有調用關係的對象，不然系統就沒法正常運行。

事件驅動風格
特徵
事件驅動系統的基本觀點是一個系統對外部的表現能夠從它對事件的處理表徵出來。如圖示：

事件驅動風格特徵
事件驅動系統具備如下一些特色：
系統是由若干子系統或元素所組成的一個總體；
系統有必定的目標，各子系統在某一種消息機制的控制下，爲了這個目標而協調行動；
在某一種消息機制的控制下，系統做爲一個總體與環境相適應和協調；

事件驅動風格特徵

事件驅動系統具備如下一些特色（續）：
在一個系統的若干子系統中，一定有一個子系統起着主導做用，而其餘子系統則處於從屬地位；
任一系統和系統內的任一元素，都有1個事件收集機制和1個事件處理機制，經過這種機制與周圍環境發生做用和聯繫；

事件驅動風格特徵

下圖是一個基於事件驅動的軟件系統的示意圖：

事件驅動風格特徵
事件驅動風格系統設計時有下述幾條基本原則
從系統論的角度來看待描述的對象，合理分解子系統，保證各個子系統的獨立性和社會性；
不管系統多麼複雜，子系統性質的差別多麼大，任何子系統均可以按照有無子系統這一性質分爲2類：管理系統和執行系統。
爲了達到系統的目標，系統內的各個子系統經過傳遞消息和執行消息來協同操做。
爲了達到系統的目標，系統內的各個子系統經過傳遞消息和執行消息來協同操做。

事件驅動風格特徵

事件驅動風格系統設計時有下述幾條基本原則(續)
在一個完整系統中，必須有這樣一個子系統，它沒有上級，必須收集系統外的事件及下級發出的事件。
管理類型的子系統通常不執行具體操做，它的主要功能是按照本身的職能指揮下級完成任務，功能性操做通常由執行類型的子系統完成。
在通常狀況下，除最高級管理子系統外，子系統通常是「有問才答」，即便在必要的狀況下須要積極尋找事件時，也必須徵得上級系統得許可，保證了系統的控制流不會分散。
事件驅動風格基本結構

事件驅動系統具備某種意義上的遞歸性，造成了「部分－總體」的層次結構，能夠用屬性結構加以表示。一個簡單的表示方法是爲執行系統定義一些類，另外定義一些類做爲這些執行系統的容器類，也就是管理系統。

事件驅動風格
事件驅動風格的基本結構，以下圖:

事件驅動風格實例
Java中的button實現

事件驅動風格實例

private void initialize() { //窗口初始化代碼
…
//btnPress就是此次點擊操做中的事件源
Buttton btnPress = new JButton();
//向事件源btnPress植入偵聽器對象ButtonEventHandler
btnPress.addActionListener (new ButtonEventHandler(this));
…
}
class ButtonEventHandler implements ActionListener {
//窗體對象
private EventDemo form = null;
//經過構造體傳入窗體對象，
//做用在於讓偵聽器對象明白事件源處於
//哪一個窗體容器中
public ButtonEventHandler(EventDemo form) {

事件驅動風格實例
this.form = form;
}
//委託方法
public void actionPerformed(ActionEvent e) {
//該方法將會把事件的處理權交給窗體容器類的btnPress_Click方法處理。
this.form.btnPress_Click(e);
}
}

//真正的事件處理代碼片段：
private void btnPress_Click(ActionEvent e) {
String message = "你點擊的按鈕名叫:"
+ ((JButton) e.getSource()).getName();
this.txtMessage.setText(message);
}

事件驅動風格優勢

事件驅動風格很是適合於描述系統族，在屬於同一族的任何系統中，系統的高級管理子系統的描述是徹底相似的，便於重用；
因爲最高管理子系統緊緊的掌握着控制權，又由於各同級子系統通常不直接發生關係，所以容易實現併發處理和多任務操做；
基於事件驅動風格的系統具備良好的可擴展性，設計者只需爲某個對象註冊一個事件處理接口就能夠將該對象引入整個系統，同時並不影響其它的系統對象。
事件驅動風格優勢

定義了包含執行子系統和管理子系統的類層次結構；
簡化客戶代碼；
使整個系統的設計更具備通常化。

事件驅動風格不足

事件驅動風格最大的不足在於構件削弱了自身對系統計算的控制能力
事件驅動風格中存在的另外一個問題在於數據共享
系統中各個對象的邏輯關係變得更加複雜
事件驅動風格和麪向對象風格的關係
基於面向對象風格的系統由多個封裝起來的對象構成，對象之間經過消息傳遞實現通訊，而事件驅動正是對消息傳遞機制的一種實現。因此基於事件驅動風格的系統每每都是面向對象的。
事件驅動風格實例

事件驅動風格實例：JavaBean系統概述
事件從事件源到監聽者的傳遞是經過對目標監聽者對象的Java方法調用進行的。對每一個明確的事件的發生，都相應地定義一個明確的Java方法。這些方法都集中定義在事件監聽者（EventListener）接口中，這個接口要繼承java.util.EventListener。

事件驅動風格實例

JavaBean系統(續)
事件狀態對象
與事件發生有關的狀態信息通常都封裝在一個事件狀態對象中，這種對象是java.util.EventObject的子類。按設計習慣，這種事件狀態對象類的名應以Event結尾。
事件驅動風格實例
JavaBean系統(續)
事件監聽者接口（EventListener Interface）與事件監聽者
因爲Java事件模型是基於方法調用，於是須要一個定義並組織事件操縱方法的方式。JavaBean中，事件操縱方法都被定義在繼承了java.util.EventListener類的EventListener接口中，按規定，EventListener接口的命名要以Listener結尾。任何一個類若是想操縱在EventListener接口中定義的方法都必須以實現這個接口方式進行。這個類也就是事件監聽者。

事件驅動風格實例
JavaBean系統(續)
事件監聽者的註冊與註銷
爲了各類可能的事件監聽者把本身註冊入合適的事件源中，創建源與事件監聽者間的事件流，事件源必須爲事件監聽者提供註冊和註銷的方法。在前面的bound屬性介紹中已看到了這種使用過程，在實際中，事件監聽者的註冊和註銷要使用標準的設計格式：
public void add< ListenerType>（< ListenerType> listener）
public void remove< ListenerType>(< ListenerType> listener)
事件驅動風格實例
適配類
適配類是JavaBean事件模型中極其重要的一部分。在一些應用場合，事件從源到監聽者之間的傳遞要經過適配類來「轉發」。
適配類成爲了事件監聽者，事件源實際是把適配類做爲監聽者註冊入監聽者隊列中，而真正的事件響應者並未在監聽者隊列中，事件響應者應作的動做由適配類決定。
事件驅動風格實例
Turbo Vision
Borland公司開發的Turbo Pascal6.0中提供了一種面向對象的事件驅動程序設計的工具包Turbo Vision。Turbo Vision把各類屏幕上的可見對象概括爲2大類：一類爲執行對象，另外一類爲管理對象，分別稱爲TView和TGroup類對象。又由於TGroup和TView類有相同之處，故TGroup是從TView派生而得，在Turbo Vision中，TGroup類的對象通常不進行實際操做，不直接在屏幕上顯示本身，而是經過本身的下屬顯示本身，全部的實際操做都是經過TView類對象進行的。

事件驅動風格實例
Turbo Vision 很好地體現了面向對象方法和事件驅動程序設計方法的精髓，TApplication是一個能夠運行的交互式程序對象，除了啓動和退出以外，它不提供任何功能，使用Turbo Vision，就能高效和快速地開發出高質量地應用程序。

事件驅動風格實例
Turbo Vision
事件驅動風格實例
Turbo Vision
事件驅動風格實例
Turbo Vision
事件驅動風格實例
Turbo Vision
分層風格
特徵
一個分層系統採用層次化的組織方式構建，系統中的每一層都要承擔兩個角色。
首先，它要爲結構中的上層提供服務；
其次，它要做爲結構中下面層次的客戶，調用下層提供的功能函數。
分層風格特徵
一個概念上的分層模型以下圖所示：
分層風格優勢

分層風格具備一些系統設計者沒法抗拒的優點：
分層風格支持系統設計過程當中的逐級抽象
基於分層風格的系統具備較好的可擴展性
分層風格支持軟件複用
分層風格不足

並非全部的系統都適合用分層風格來描述的
對於抽象出來的功能具體應該放在哪一個層次上也是設計者頭疼的一個問題
分層風格實例
分層風格實例：計算機網絡的設計
概述
網絡協議設計者將計算機網絡中的各個部分按其功能劃分爲若干個層次（Layer），其中的每個層次均可以當作是一個相對獨立的黑箱、一個封閉的系統。用戶只關心每一層的外部特性，只須要定義每一層的輸入、數據處理和輸出等外部特性。
分層風格實例
ISO/OSI網絡體系結構
分層風格實例
ISO/OSI網絡體系結構
分層風格實例
ISO/OSI網絡體系結構
爲了理解ISO/OSI各層的功能，以運輸公司進行貨物運輸爲例來進行說明，也就是利用人們熟知的東西來理解陌生抽象的概念。其中，第1~3層3個層次至關於由運輸公司負責的貨物運輸過程當中的具體細節、具體操做方式；第4層至關於運輸公司與用戶之間的接口；第5~7層3個層次至關於由用戶公司負責的將貨物交去運輸所須要作的準備工做。
第1層是物理層（Physical Layer），它負責在物理信道上傳輸原始的數據bit流。它應該提供爲創建、維護和拆除物理鏈路鏈接所需的機械的、電氣的、功能和規程的特性，這相似於運輸車輛只須要負責將裝在車輛內的貨物（相似於bits）運送到某地就好了。

分層風格實例
第2層是數據鏈路層（Data Link Layer），它的主要功能是糾錯和流量控制，負責在可能出現差錯的物理線路中實現無差錯的數據傳送。它應該在物理層的基礎上，創建相鄰結點之間的數據鏈路，經過差錯控制提供數據幀（Frame）的無差錯傳輸，並進行數據流量控制。這相似於運輸公司的運輸管理和質量監督部門，須要負責在可能出現問題的運輸線路之中保質保量地完成運輸任務。
分層風格實例
第3層是網絡層（Network Layer），它的主要功能是路由控制（找路）、擁塞控制和數據打包。它應該爲其上一層傳輸層的數據傳輸提供創建、維護和終止網絡鏈接的手段，把上層傳來的數據分割成一個一個的數據包（Packet，也叫報文分組）在結點之間進行交換傳送，而且負責路由控制和擁塞控制。這相似於運輸公司須要將用戶發送的貨物進行分割打包，並在現有的交通網絡之中負責找出一條從源地址到目的地址的線路（即找路），在找路時須要考慮到可否到達、擁塞情況、安全可靠性、甚至交通費用等諸多方面的因素。
分層風格實例
第4層是傳輸層（Transport Layer），它的主要功能是在上層和下層之間起到一種接口的功能。它應該爲上層提供端到端（最終用戶到最終用戶）、的透明的、可靠的數據傳輸服務。所謂透明的傳輸是指在通訊過程當中上層能夠將下面各層看做是一個封閉的黑箱系統，傳輸層對上層屏蔽了傳輸系統的具體細節。這相似於運輸公司在各個地方設置的業務接洽處，它負責在用戶和公司之間創建起一個貨物交接的橋樑，使得用戶不用去管運輸公司將以什麼樣的方式將貨物運送到目的地，也就是說業務接洽處對用戶屏蔽了貨物運輸中的具體細節。

分層風格實例
第5層是會話層（Session Layer），它的主要功能是負責收發數據的交接工做、並組織和管理數據。它應該爲表示層提供創建、維護和結束會話鏈接的功能，並提供會話管理服務。這相似於用戶公司的貨物收發室，它負責與運輸公司打交道，完成用戶公司貨物的收發的交接工做、並組織管理公司內部要收發的貨物。
分層風格實例
第6層是表示層（Presentation Layer），它的主要功能是爲數據提供收發、存放的具體格式和規範。它應該爲應用層提供信息表示方式的服務，如數據格式的變換、文本壓縮、加密技術等。這相似於用戶公司的貨物收發員，它負責與用戶公司內部要收發貨物的部門或我的打交道，在收集要發送的貨物時告訴用戶應該怎樣填寫發貨資料，在向用戶發放貨物時告訴用戶應該完清哪些具體手續，等等。
分層風格實例
第7層是應用層（Application Layer），它的主要功能是爲數據提供各類可行的收發方式。它應該爲網絡用戶或應用程序提供各類應用服務，如文件傳輸、電子郵件（E-mail）、分佈式數據庫、網絡管理等。這相似於用戶公司內部的部門或我的在收發貨物時，都必須遵循用戶公司內部的有關規定，只能使用用戶公司所容許的方式來收發貨物。從另外一方面來講，用戶公司也要爲公司內部的部門或我的收發貨物提供各類可行的收發方式，讓用戶公司內部的部門或我的知道他們可以使用哪些方式來收發貨物。

分層風格

ISO/OSI層次分組關係 :有兩種分組方法
I第一種能夠從數據處理分工的角度，將ISO/OSI七個層次分爲三組：第一、2層解決有關網絡信道問題；第三、4層解決傳輸服務問題；第五、六、7層則處理對應用進程的訪問。
從數據傳輸控制的角度，將ISO/OSI七個層次分爲三組：下三層（一、二、3層）能夠看做是傳輸控制組，負責通訊子網的工做，解決網絡中的通訊問題；上三層（五、六、7層）爲應用控制組，負責有關資源子網的工做，解決應用進程之間的信息轉換問題；中間層（4層）則爲通訊子網和資源子網的接口，起到鏈接傳輸和應用的做用。
分層風格實例
.Net平臺也是一個明顯的分層系統：
分層風格實例
.Net 框架分層模圖
數據共享風格
特徵
採用數據共享風格構建的系統中一般有兩個大相徑庭的功能構件；
中央數據單元構件；
一些相對獨立的構件的集合。

數據共享風格特徵
數據共享風格的示意圖以下圖所示：

數據共享風格
信息交互方式的差別致使了控制策略的不一樣。主要的控制策略有兩種，正是依據這兩種不一樣的控制策略，基於數據共享風格的系統被分紅兩個子類：
基於傳統數據庫型數據共享風格的應用系統
基於黑板型數據共享風格的應用系統
下面主要介紹基於黑板型數據共享風格的應用系統

數據共享風格
一個典型的黑板型數據共享系統包括如下三個部分：
知識源：知識源中包含獨立的、與應用程序相關的知識，知識源之間不直接進行通信，它們之間的交互只經過黑板來完成。
黑板數據結構：黑板數據是按照與應用程序相關的層次來組織的解決問題的數據，知識源經過不斷地改變黑板數據來解決問題。
控制：控制徹底由黑板的狀態驅動，黑板狀態的改變決定使用的特定知識。
黑板模式對於無肯定性求解策略的問題比較有用，在專家系統中，這種模式應用的比較普遍。
數據共享風格優勢

解決問題的多方法性：
對於一個專家系統，針對於要解決的問題，若是在其領域中沒有獨立的方法存在，並且對解空間的徹底搜索也是不可行的，在黑板模式中能夠用多種不一樣的算法來進行試驗，而且也容許用不一樣的控制方法。
具備可更改性和可維護性：
由於在黑板模式中每一個知識源是獨立的，彼此之間的通訊經過黑板來完成，因此這使整個系統更具備可更改性和可維護性。
數據共享風格優勢

有可重用的知識源：
因爲每一個知識源在黑板系統中都是獨立的，若是知識源和所基於的黑板系統有理解相同的協議和數據，咱們就能夠重用知識源。
支持容錯性和健壯性：
在黑板模式中全部的結果都是假設的，而且只有那些被數據和其它假設強烈支持的纔可以生存。這對於噪聲數據和不肯定的結論有很強的容錯性。
數據共享風格缺點
測試困難：
因爲黑板模式的系統有中央數據構件來描述系統的體現系統的狀態，因此係統的執行沒有肯定的順序，其結果的可再現性比較差，難於測試。
不能保證有好的求解方案：
一個黑板模式的系統所提供給咱們的每每是所解決問題的一個百分比，而不是最佳的解決方案。
效率低：
黑板模式的系統在拒絕錯誤假設的時候要承受多餘的計算開銷，因此致使效率比較低。

數據共享風格缺點
開發成本高：
絕大部分黑板模式的系統須要用幾年的時間來進化，因此開發成本較高。
缺乏對並行機的支持：
黑板模式要求黑板上的中心數據同步併發訪問，因此缺乏對不併行機的支持。

數據共享風格實例
數據共享風格實例：專家系統（ES，Expert System）概述：
專家系統實質就是一組程序；
從功能上：可定義爲「一個在某領域具備專家水平解題能力的程序系統」，能像領域專家同樣工做，運用專家積累的工做經驗與專門知識，在很短期內對問題得出高水平的解答。
從結構上講：可定義爲「由一個專門領域的知識庫，以及一個能獲取和運用知識的機構構成的解題程序系統」。
數據共享風格實例
ES通常結構以下圖所示：

數據共享風格實例系統
IECRMAS知識生態系統
IECRMAS知識生態系統知識流
IECRMAS知識生態系統
信用評估知識庫的造成
IECRMAS知識生態系統
IECRMAPS知識生態系統中知識流動
個體知識進化圖
解釋器風格
特徵
基於解釋器風格的系統核心在於虛擬機。
一個基於解釋器風格的系統一般包括：正在被解釋執行的僞碼和解釋引擎；
僞碼：由須要被解釋執行的源代碼和解釋引擎分析所得的中間代碼組成；
解釋引擎包括：語法解釋器和解釋器當前的運行狀態
解釋器風格特徵
解釋器風格示意圖以下圖所示：

解釋器風格優勢
在文法規則比較簡單的狀況下，解釋器風格工做的很好；
易於改變和擴展文法。由於解釋器風格使用類來表示文法規則，用戶可使用繼承來改變和擴展文法。已有的表達式能夠採用增量的方式逐漸擴充，而新的表達式能夠定義爲舊錶達式的變體；
易於實現文法。
能夠用多種操做來「解釋」一個句子。
解釋器風格缺點

沒法解釋複雜的文法規則：對於比較簡單的文法規則，解釋器風格工做的很好，而對於複雜的文法規則，則因爲文法層次的龐大而難於管理；
應用範圍比較狹窄；
在文法規則比較複雜，則文法的層次變得沒法管理，系統中須要包含許多表示文法規則的類。
解釋器風格實例
解釋器風格實例：一個布爾表達式解釋器
目標：布爾表達式求值系統
現定義由以下文法定義的布爾正則表達式

編譯器(1)
系統的體系結構能夠隨技術的發展而發生變化
傳統的編譯器模型

具備共享符號表的傳統編譯器模型
編譯器(2)
隨着時間的推移，編譯技術變得更加複雜，更多的注意力轉移到程序在編譯過程的中間表示，例如屬性文法樹
典型的現代編譯器模型
解釋器風格實例
布爾表達式求值系統類圖，以下圖所示：
解釋器風格示例
布爾表達式抽象語法樹實例，以下圖所示：
解釋器風格實例
布爾表達式求值系統的優缺點：
在文法規則比較簡單的狀況下，解釋器風格工做的很好，但若是文法規則複雜，則文法的層次變得龐大而沒法管理，系統中須要包含許多表示文法規則的類。
最高效的解釋器一般不是經過直接解釋語法分析數實現的，而是首先將它們轉換成另外一種形式。
易於改變和擴展文法。
易於實現文法。
解釋器風格實例
布爾表達式求值系統中的角色:
BooleanExpression（抽象布爾表達式）
TerminalExpression（終結符表達式，如VariableExpresssion和Constant）
NonterminalExpression（非終結符表達式，如AndExpression、OrExpression和NotExpression）
Context（上下文，也就是「解釋引擎內部狀態」）
Client（客戶）

解釋器風格實例
布爾表達式求值系統的實現
在具體實現布爾表達式求值系統時還有許多細節的問題要處理，這些細節問題處理的好壞甚至會直接影響整個系統的性能。這些問題主要表如今如下幾個方面：
建立抽象語法樹
定義求值操做
共享終結符
解釋器風格示例

　解釋器風格定義了特定語言的文法表示和解釋該文法的解釋器。這種模式如同曲譜。其中，音階和它的持續時間能夠用五線譜上的符號表示。這些符號就是音樂語言。音樂家按照曲譜演奏，就能夠反覆重現一樣的音樂。
解釋器實例　
解釋器實例
解釋器實例
Javascript 語言解釋器JlBrowers
1. 詞法分析
以嵌入在html文本中的JS腳本程序爲輸入造成單詞鏈表，以便語法分析。單詞鏈表爲雙向鏈表。

2. 語法分析
以單鏈表爲輸入，依JS語言的語法規則造成中間數據結構。中間數據結構可以反映出程序語句描述的數據處理流程。

3. 解釋執行器
以中間數據結構爲輸入負責對語句解釋執行的控制。
解釋器實例

4. 語句解釋器
完成各種型控制語句的解釋執行，該模塊可能會調用解釋執行器而造成遞歸調用。
5. 表達式規約器
由語句解釋器來調用，它負責在語句解釋執行過程當中完成各種型表達式的運算和賦值語句的執行。

6. 與瀏覽器交互
完成在表達式運算過程當中對當前文檔對象和html 文本中各類控件對象的屬性值的修改並經過改變瀏覽器的輸出顯示錶現出來。

解釋器實例
Javascript 語言解釋器JlBrowers模塊圖

解釋器實例
AbstractExpression  (Expression)
聲明執行特定操做的接口。
TerminalExpression  ( ThousandExpression, HundredExpression, TenExpression, OneExpression )
實現一個與語法中終結符相關的解釋操做。
句子中的每個終結符都須要一個實例。
NonterminalExpression
語法中的每一個規則R ::= R1R2...Rn 都須要這樣的一個類。
管理從R1到Rn每個符號的AbstractExpression類型變量的實例。
實現語法中非終結符的解釋操做，在解釋中可能須要遞歸調用自身。
Context  (Context)
包含對於解釋器來講是全局的信息。
Client  (InterpreterApp)
創建（或者給定）一個抽象語法樹。抽象語法樹是由NonterminalExpression 和TerminalExpression類的實例組合而成。
調用解釋操做。

反饋控制環風格

概述
所謂對一個對象（或過程）進行控制，意味着設法使這個被控對象（或被控過程）的功能或特性有效的達到所指望的目標。
爲了成功設計一個控制系統，必須事先知道被控對象所具備的性質和特徵，同時還須瞭解和掌握這些性質和特徵隨環境等因素變化的狀況。

反饋控制環風格

控制工程是一個十分強調方法論的專業領域，所以控制工程方法徹底是獨立於各類應用領域的。
爲了將過程控制方法從單純的控制領域中抽象出來，咱們引入了動態系統的概念。
反饋控制環風格

動態系統表示信號處理和傳輸的一個功能單元（例如：信號能夠是能量、材料、信息、資金及其餘形式），其中系統的原由和由此引發的時間上的效果分別做爲系統的輸入量和輸出量來考慮。
如此定義的系統具備共同的特徵，即在其中必定存在有目標的做用、信息處理、閉環和開環控制過程，正如N.Wiener所提出的，以上概念能夠用控制論這個更高級的概念來總結。
控制論也能夠應用於軟件體系結構的建立。

反饋控制環風格描述手段

根據上述的動態系統的定義，在系統中必然存在信號的處理和傳輸。這時系統也可描述爲傳輸環節或傳輸系統。傳輸環節具備惟一的做用方向，這由輸入、輸出信號的箭頭方向給出。
單變量系統以下圖所示：

反饋控制環風格描述手段
多變量系統以下圖所示：

反饋控制環風格描述手段

除了用方框圖來表達動態系統之外，還能夠用信號流圖，以下圖所示：
反饋控制環風格開環與閉環控制
通常的動態系統描述框圖能夠分爲開環控制和閉環控制系統，但在實際應用中這兩種不一樣的動態系統每每很容易混淆在一塊兒，對它們之間的區別強調的不夠。
如今經過一個市內暖氣系統來指出這二者之間的不一樣和相同之處。
反饋控制環風格開環與閉環控制
開環控制圖以下圖所示：

反饋控制環風格開環與閉環控制
閉環控制圖以下圖所示：

反饋控制環風格開環與閉環控制

開環控制和閉環控制的差異：
閉環控制：
表示一個閉合的做用過程，（控制迴環）；
根據閉環做用原理可增長抗干擾性（負反饋）；
可能不穩定，也即被控量再也不衰減，而是增加到無窮大（理論上）。
反饋控制環風格開環與閉環控制

開環控制和閉環控制的差異(續）：
開環控制
表示一個開放的做用過程（控制序列）；
只能對抗指定由其處理的干擾，對於其餘一些干擾因素沒法消除；
只要被控制對象本身保持穩定，整個開環控制系統也就保持穩定。
反饋控制環風格基本結構

以閉環控制系統爲例分析過程控制環的基本結構；
一個自動控制系統包括以下4個主要組成部分：被控對象、測量環節、調節器和執行環節，以下圖所示：
反饋控制環風格-自適應
自適應反饋控制環須要包括如下3方面的工做：
辨識被控對象的特徵；
在辨識的基礎上做出控制決策；
在決策的基礎上實施修正動做.
按照構成自適應控制環的目的的不一樣可將其分爲兩種類型：
參數自適應控制環；
性能自適應控制環；
反饋控制環風格-自適應反饋控制環
參數自適應控制環
參數自適應控制環以下圖所示：
反饋控制環風格-自適應反饋控制環
性能自適應控制環
性能自適應控制環以下圖所示：
反饋控制環風格-自適應反饋控制環
在性能自適應控制環中，最典型的表明就是所謂模型參考自適應控制系統。
模型參考自適應控制系統按照其控制方式又可分爲兩種
A.直接法
B.間接法
反饋控制環風格-自適應反饋控制環
直接法模型以下圖所示：

間接法模型以下圖所示：

反饋控制環風格實例
鋼鐵燒結工藝控制體系結構
反饋控制環風格實例
鋼鐵燒結工藝控制體系結構
反饋控制環風格實例
鋼鐵燒結工藝控制體系結構
反饋控制環風格實例
鋼鐵燒結工藝控制體系結構
反饋控制環風格實例
鋼鐵燒結工藝控制體系結構
反饋控制環風格實例
鋼鐵燒結工藝控制體系結構
反饋控制環風格實例
鋼鐵燒結工藝控制體系結構
七種構建模式的比較
軟件體系結構的七種構建模式各有本身的特色、侷限、應用範圍和優缺點，比較各類構建模式的不一樣將有助於在實際的項目開發過程當中選擇適合項目的構建模式。七種構建模式的比較見下表所示：
七種構建模式的比較
七種構建模式的比較
異構風格的集成
概述
各類系統構建模式之間不只有聯繫，並且在不少狀況下它們每每是配合使用的。即面對一個實際系統，很難判斷它到底是A型，仍是B型，亦或者是C型，單純的把它歸到任何一型都是很勉強的。這樣的系統能夠稱爲複合型系統，這樣的系統構建模式就稱爲異構風格的集成。

異構風格的集成
做爲一個總體項目，能夠將足球隊類比爲一個軟件系統，球隊的比勝過程類比爲軟件系統的運行過程，而球隊完成教練（不管勝負）的戰術意圖類比爲系統實現了自身功能。
整個球隊的運做能夠用分層風格（Layered Pattern），面向對象風格（Object Oriented）和事件驅動（Event Driven）混合表示。
異構風格的集成
在通用足球戰術體系模型中：
分層風格是對整個球隊基本陣型的模擬；
面向對象風格是對球隊中的具體隊員的模擬；
事件驅動風格對應於比勝過程中隊員之間的相互通訊方式。下面會詳細解釋這幾種模式在通用足球戰術體系中的做用。
異構風格的集成
通用足球戰術體系中的通訊關係
在通用足球戰術體系中各層之間存在耦合，甚至在某些狀況下某個層次中的對象還會根據系統的狀態進行移動，這也是強調使用移動智能代理的根本緣由。由於球員具備智能，會根據整個戰局的變化自動應變，爲了儘量的模擬這種自適應性，必須使用移動智能代理.
通用足球戰術體系中各個移動智能代理之間的相互通訊方式和可能存在的層次躍遷，這也是整個體系結構中組成元素的基本運動方式。

異構風格的集成
通用足球戰術體系的運做方式
整個系統預先定義好不少事件，它們都是和足球比賽中特定的狀況或教練戰術意圖相聯繫的；
不一樣層次中移動智能代理在「戰術事件」的驅動之下而移動。
戰術事件的觸發驅動事件處理函數的調用，函數的調用致使操做的執行和新事件的觸發。如此環環相扣，構成了一個相互交織的事件網絡，從而驅動整個系統的不斷運行。

異構風格的集成
應用方法
在本模型的基礎之上，實際系統設計者應該肯定移動智能代理的實現和分佈（指定基本陣型），定義必須的戰術事件，給每一個移動智能代理定義相應的事件處理函數（指定戰術打法，是本模型的核心問題）。
在完成上述基本步驟後，模擬系統運行，修正最初的設計（甚至能夠爲每一個移動智能代理設計多個事件處理函數，在不一樣狀況下調用不一樣的函數，實現戰術打法的變化），最終構成一個實際可運行的足球戰術模擬系統。
小結
在管道-過濾器風格下，每一個功能模塊都有一組輸入和輸出。功能模塊從輸入集合讀入數據流，並在輸出集合產生輸出數據流，即功能模塊對輸入數據流進行增量計算獲得輸出數據流。在管道-過濾器風格下，功能模塊稱做過濾器（filters）；功能模塊間的鏈接能夠看做輸入、輸出數據流之間的通路，因此稱做管道（pipes）。
小結
面向對象風格集數據抽象、抽象數據類型、類繼承爲一體，使軟件工程公認的模塊化、信息隱藏、抽象、重用性等原則在面向對象風格下得以充分實現。面向對象風格設計的根本出發點是追求天然的刻劃和求解現實世界重的問題，即追求問題空間和軟件系統空間結構的一致性。
小結
在基於事件驅動風格的系統設計中，系統的每一個子系統在設計過程當中要考慮其完整性和相對獨立性，不絕對依賴於某一子系統，系統之間的協調和管理都是經過消息傳遞和收集來進行的。基於事件驅動風格的系統必須把系統內的各個子系統看做是個性和共性的對立統一體，即考慮到每一個子系統的「社會性」，也考慮到它的「獨立性」。
小結
一個分層系統採用層次化的組織方式構建，系統中的每一層都要承擔兩個角色。
首先，它要爲結構中的上層提供服務；
其次，它要做爲結構中下面層次的客戶，調用下層提供的功能函數。
分層系統中的各個組件在不一樣層次上造成了不一樣功能級別的虛擬機（Virtual Machine），各虛擬機之間經過系統設計時約定的協議進行通信，而不相鄰層之間的通信受到一些限制條件的束縛。
小結
採用數據共享風格構建的系統中一般有兩個大相徑庭的功能構件：
一個是中央數據單元構件，表明系統當前的各類狀態；
另外一個是一些相對獨立的組件的集合，這些組件對中央數據單元進行操做。
中央數據單元（也就是知識庫）和外部組件集合之間的信息交互就成爲基於數據共享風格的系統中相當重要的問題，隨着系統承擔的功能不一樣，這種信息交互的方式也存在很大差別。

小結
基於解釋器風格的系統核心在於虛擬機。
一個基於解釋器風格的系統一般包括正在被解釋執行的僞碼和解釋引擎，其中僞碼由須要被解釋執行的源代碼和解釋引擎分析所得的中間代碼組成；而解釋引擎包括語法解釋器和解釋器當前的運行狀態。
一個解釋器風格中就有4個基本的構成部分：一個完成解釋工做的解釋引擎、一個包含僞碼的數據存儲區、一個記錄解釋引擎當前工做狀態的數據結構和一個記錄源代碼被解釋執行的進度的數據結構。

小結
爲了成功設計一個控制系統，必須事先知道被控對象所具備的性質和特徵，同時還須瞭解和掌握這些性質和特徵隨環境等因素變化的狀況。
控制系統能夠在其運行的過程當中，經過自身不斷的測量被控對象的特性，從而「認識」或「掌握」被控對象，並根據所掌握的被控對象當前的特徵信息，控制系統作出控制決策，使系統的性能按所規定的標準達到最優或者接近最優。
小結
面對一個實際系統，很難判斷它到底是A型，仍是B型，亦或者是C型，單純的把它歸到任何一型都是很勉強的。這樣的系統能夠稱爲複合型系統，這樣的系統構建模式就稱爲異構風格的集成。

相關標籤/搜索

每日一句

每一个你不满意的现在，都有一个你没有努力的曾经。