軟件系統(tǒng)概念結(jié)構(gòu)的立體分析法

因此，對于一個軟件系統(tǒng)，我們應(yīng)該有著一種立體景象。自然的，我們也應(yīng)該從立體的

視角，順著垂直與水平兩個構(gòu)造緯度，構(gòu)造或者分析軟件系統(tǒng)。構(gòu)造或者分析從認(rèn)識的角度

在內(nèi)容上并無根本區(qū)別，只不過二者獲取內(nèi)容的過程是相反的。

2.1分類和層次

在認(rèn)識，分析，設(shè)計軟件系統(tǒng)的過程中，我們的頭腦里會出現(xiàn)一系列的概念，比如模塊，

類，函數(shù)，變量等等。這些概念以及相互之間的關(guān)系需要得到反思。

分類是對軟件概念的最基本的反思。分類的過程是將若干軟件概念歸為一些集合的過

程。因為觀察角度的不同，同一個概念可能被劃分到不同的集合中。但是相互正交的分類卻

是值得我們要追求的一種狀態(tài)。因為那樣意味著清晰和簡明，雖然這往往是做不到的。

分類的最重要結(jié)果是形成了原有概念的集合，這個集合本身將作為一個新的概念出現(xiàn)在

我們的概念結(jié)構(gòu)中。事實上這種將現(xiàn)有概念進(jìn)行分類，并得到若干作為新概念的集合的過程

就是抽象過程。抽象是軟件工程中最重要的設(shè)計活動之一。

分類和抽象在概念之間建立了一種層次結(jié)構(gòu)。這是一種多對一的，有序的垂直結(jié)構(gòu)。我

們將集合標(biāo)簽稱為上層，而分類里的元素稱作下層。如下圖所示

的集合，而各自的集合標(biāo)簽就是一種最自然的區(qū)分。但是這種區(qū)分往往不能讓我們對系統(tǒng)結(jié)

構(gòu)里的理解更加深入，比如一個函數(shù)使用了一個全局變量，而函數(shù)與變量通常是屬于不同的

類，而如果我們將這個變量和這個函數(shù)劃分在某一個集合時就可能讓我們對結(jié)構(gòu)有著更好的

理解。這里就使我們有下面分伙和交織的闡述。

2.2分伙和交織

分類的依據(jù)是因為在若干個元素之間存在的共同的操作，性質(zhì)等因素，而分伙是因為在

這些元素之間存在這功能上的關(guān)聯(lián)，也就是性質(zhì)，狀態(tài)等因素的互動。也就是說如果一個元

素的某個性質(zhì)或者狀態(tài)的變動會導(dǎo)致另外一個元素的性質(zhì)或者狀態(tài)的變動，那么我們就往往

將他們分成一伙。

當(dāng)然分伙的依據(jù)總是有些混雜的，因為一個元素可能同若干個元素存在互動，而一些元

素又通過若干個元素達(dá)成間接互動，這些現(xiàn)象在軟件系統(tǒng)中都是普遍存在的。但是分伙跟分

類存在同樣的效果，也就是形成一個集合。

但是這個集合標(biāo)簽與元素之間的關(guān)系通常是被忽略的，至少是不像如分類那樣形成一種

明顯的垂直關(guān)系。分伙的效果主要是突出了在集合的元素之間互動以及不同或伙之間的互

動。這使我們對系統(tǒng)的認(rèn)識得到了簡化，歸結(jié)，因為這時對系統(tǒng)的研究將主要是對不同伙之

間互動的研究，而伙的數(shù)量顯然常常比原有系統(tǒng)中個體的數(shù)量少了許多。分伙體現(xiàn)的是系

統(tǒng)狀態(tài)變化上不同個體間的交織，這是一個平面的解析。如下圖

2.3概念結(jié)點

我們在系統(tǒng)的觀點下來研究軟件系統(tǒng)的結(jié)構(gòu)，也就是將系統(tǒng)看作各種結(jié)點的網(wǎng)絡(luò)，并且

我選擇成熟的圖理論作為深入研究的工具。

圖中最基本的?個方面就是結(jié)點，就我們而言就是概念結(jié)構(gòu)。前面我們已經(jīng)對概念結(jié)構(gòu)

有了初步的認(rèn)識，在這一節(jié)我們將軟件系統(tǒng)中概念結(jié)構(gòu)的具體形式進(jìn)行分析，這里的順序是

從大概念到小概念。

概念結(jié)點在水平分析下是被看作其它概念結(jié)點通過合作構(gòu)造動力交織起來的。同時抽象

構(gòu)造動力又將概念結(jié)點形成了一種有順序的層次。綜合這兩種分析，我們將概念結(jié)點區(qū)分為

6層，每層都是更下層實體的交織。

2.3.1自治系統(tǒng)

自治系統(tǒng)是能夠獨立的完整某項功能，自主掌握硬件資源的集成的,是被解析出的系統(tǒng)部

分的最粗粒度。

比如一臺電腦主機。

2.3.2可執(zhí)行程序和服務(wù)

是操作系統(tǒng)內(nèi)一道被調(diào)度來使用系統(tǒng)資源為完成某個任務(wù)的運行的實體。這包括二進(jìn)制

形式與文本形式。

2.3.3組件和模塊

是可被用來作為一個部件被加入到其它程序中，能夠完成某個專業(yè)功能的實體。比如一

個web服務(wù)或者封裝了一個相關(guān)函數(shù)（或者數(shù)據(jù)）集合的模塊。這包括二進(jìn)制形式與文本

形式。

2.3.4算法和函數(shù)

是提供輸入輸出介面的一個實現(xiàn)。這包括二進(jìn)制形式與文本形式。如c語言中的函數(shù)。

2.3.5基塊

是指具有唯一出口與入口的順序執(zhí)行的指令序列。這包括二進(jìn)制形式與文本形式。例如

下面給出了一種用中間代碼形式表示的兩個基塊序列。

a=f(2);

D.1708=2;

goto<D.1709>;

<D.1709>:

returnD.1708;

2.3.6指令和數(shù)據(jù)

是指機器的一條指令或者機器所能識別的一個原始數(shù)據(jù)，比如一個寄存器所表示的整數(shù)

或者標(biāo)準(zhǔn)的浮點數(shù)據(jù)。這包括二進(jìn)制形式與文本形式。

這是在軟件系統(tǒng)中所能水平解析的最底層概念結(jié)點。

2.3.7總結(jié)

在立體的分析法下，概念結(jié)點被解析出垂直構(gòu)造中的6個層次。這6個層次是其它分析

的工場，也就是其它分析活動所在的場所。通常我們關(guān)注于第3、4層。因為第5、6層中概

念結(jié)點數(shù)目將非常龐大，而其中的相互交織關(guān)聯(lián)卻是直接簡單的。

［軟件世界、

自治系統(tǒng)

程序和服務(wù)

OOO

組件和模塊

O

算法和函數(shù)

ooo

基塊

指令和數(shù)據(jù)

ooo

24交織關(guān)聯(lián)

正如一般圖中類似，邊是用來表示結(jié)點之間關(guān)系的。一般的邊是用來表示同級結(jié)點之間

的關(guān)系。相應(yīng)于前面6個層面的概念結(jié)點，每個層面內(nèi)的概念結(jié)點的關(guān)聯(lián)都存在著特有的關(guān)

聯(lián)內(nèi)涵，而且我們認(rèn)為不同層面之間不存在交織關(guān)聯(lián)。這與我們認(rèn)為交織關(guān)聯(lián)是一種水平性

質(zhì)相符。

2.4.1網(wǎng)絡(luò)互聯(lián)

這是在自治系統(tǒng)工場層交織關(guān)聯(lián)。在這一層不同的自治系統(tǒng)通過著名的通信協(xié)議來實現(xiàn)

相互的合作和共享。比如在互聯(lián)網(wǎng)中，各個主機使用TCP/IP協(xié)議互聯(lián)的進(jìn)行互聯(lián)。這種關(guān)

聯(lián)對各個系統(tǒng)的影響一般不具有強制性，所以每個自治系統(tǒng)都能在一定程度上保證自己的獨

立。

2.4.2進(jìn)程和線程通信

這是在程序和服務(wù)工場層的交織關(guān)聯(lián)。這種關(guān)聯(lián)可以通過多種方式來實現(xiàn)，這其實基本

上也是進(jìn)程通信的內(nèi)容。多數(shù)系統(tǒng)支持文件，信號，消息隊列，管道，消息來實現(xiàn)進(jìn)程通信。

2.4.3模塊介面

這是在模塊和組件工場層的交織關(guān)聯(lián)。模塊之間通過模塊介面實現(xiàn)通信，這里經(jīng)常需要

區(qū)分兩種介面。一種是使用介面，也就是具有這個模塊介面的模塊需要另外一個模塊來發(fā)揮

功能，這時這個模塊就這個介面進(jìn)行規(guī)定。另一種是提供介面，也就是一個模塊可以向系統(tǒng)

中其它模塊提供服務(wù)，這時此模塊在此模塊介面中對自己所能提供的服務(wù)進(jìn)行規(guī)定。

2.4.4過程和函數(shù)調(diào)用

這是在算法和函數(shù)工場層的交織關(guān)聯(lián)。算法本身具有輸入輸出的天然連接，但在實際的

軟件系統(tǒng)中算法，或者說函數(shù)，之間的關(guān)聯(lián)也就是調(diào)用存在多種具體形式。比較著名的有傳

值調(diào)用，引用調(diào)用，地址調(diào)用，抄寫-恢復(fù)調(diào)用。

2.4.5控制流

這是在基塊工場層的交織關(guān)聯(lián)?；鶋K是順序計算的基本單位，一個算法的基塊通過控制

流的相互連接實現(xiàn)計算銜接。

控制流的關(guān)聯(lián)有兩種形式，一種是有條件跳躍，另一種是無條件跳躍。

2.4.6數(shù)據(jù)依賴

這是在指令和數(shù)據(jù)工場層的交織關(guān)聯(lián)。軟件系統(tǒng)的計算中，一條指令往往引用了另外一

條指令的數(shù)據(jù)或者其它信息而導(dǎo)致在這兩條指令之間存在一種有序的關(guān)系，這種關(guān)系一般稱

之為依賴。

這種依賴關(guān)聯(lián)可以分為數(shù)據(jù)依賴和控制依賴。數(shù)據(jù)依賴又分為真依賴，反依賴，和輸出

依賴。

2.5圖形表示

軟件結(jié)構(gòu)圖是對軟件系統(tǒng)的抽象，抽象的工具與表達(dá)形式就前面述及的圖。軟件結(jié)構(gòu)圖

是用來表達(dá)軟件系統(tǒng)的，自然這里的圖的內(nèi)涵也就是結(jié)點與邊有著自己的內(nèi)容。

難點

O

2.5.1結(jié)點

用立方體表示概念結(jié)點。有時使用菱臺形表示結(jié)點是整個系統(tǒng)變化的源動力或者肇始。

用菱形來表示媒介結(jié)點.雖然媒介本質(zhì)是關(guān)聯(lián)的，但我們總是將媒介本身作為一種實體

存在來表示。這也是我們的圖形表示中的一個特點。

2.5.2關(guān)聯(lián)

用箭頭表示一種關(guān)聯(lián)。關(guān)聯(lián)的基本涵義是信息的流動。

2.5.3從屬系統(tǒng)

用一個虛線邊界的圓形表示被考慮系統(tǒng)中的從屬系統(tǒng)，通常是同質(zhì)結(jié)點的匯集。

2.5.4業(yè)務(wù)

線

使用一條紅色的粗線表示一個具體業(yè)務(wù)的信息流動。這是對系統(tǒng)的動態(tài)特征的一種表

達(dá)。動態(tài)表達(dá)總是成為系統(tǒng)的圖形表示中的難題。

2.6典型拓?fù)錁?gòu)形

概念結(jié)構(gòu)的圖形表示有幾種常見拓?fù)錁?gòu)形，這些構(gòu)形中往往成為應(yīng)用中存在的主要構(gòu)

形。因為這些構(gòu)形有著非常強大的表現(xiàn)能力。

2.6.1線狀

所有的被考慮概念結(jié)點形成一種單線狀構(gòu)形，也就是每個概念結(jié)點至多有兩個關(guān)聯(lián)概念

結(jié)點。這種構(gòu)形簡單，容易實現(xiàn)和管理。因此總是成為系統(tǒng)構(gòu)造和理解的首要選擇。

2.6.2樹狀

所有被考慮的概念結(jié)點之間或者存在一種直接的有序的歸結(jié)關(guān)系,或者是通過間接歸結(jié)

形成關(guān)聯(lián)，并且存在一個稱之為根的概念結(jié)點。

2.6.3網(wǎng)狀

所有被考慮的概念結(jié)點存在間一種復(fù)雜的錯綜關(guān)聯(lián)。通常這為人們所避免，而盡可量用

規(guī)則的網(wǎng)狀，如星形，立方體等構(gòu)形來滿足應(yīng)用。

3設(shè)計模式

3.1概述

設(shè)計模式是發(fā)生在軟件設(shè)計中通常發(fā)生的問題的可復(fù)用的解決方案。設(shè)計模式不是能夠被直

接變成代碼的完成了的設(shè)計。它是關(guān)于一個能夠用在許多不同情況下的如果解決問題的描述

或者模板。設(shè)計模式起源于一種建筑學(xué)上的概念ChristopherAlexander(1977/79),在1987

年，KentBeck與WardCunningham開始試驗將模式應(yīng)用到編程中的想法并將他們的結(jié)果提

交在拿年的OOPSLA會議上。在隨后幾年，Beck,Cunningham跟其它人在這個工作上跟隨。

設(shè)計模式在計算機科學(xué)中獲得流行是在一本名為DesignPatterns:Elementsof

ReusableObject-OrientedSoftware的書在1994年被叫做"GangofFour"(Gamma等人)

的作者出版之后。那同一年，第一次PatternLanguagesofProgramming會議召開，而后

一年P(guān)ortlandPatternRepository被建立為設(shè)計模式的檔案但術(shù)語的范圍任何是件有爭議

的事情。

物體-導(dǎo)向的設(shè)計模式典型的說明在類之間或者物體之間的關(guān)系和介面，而不規(guī)定涉及

的最終應(yīng)用類或者物體。許多模式隱含物體導(dǎo)向或者更一般的可更改狀態(tài)，且因此不可應(yīng)在

函數(shù)式編程語言中，在那里數(shù)據(jù)是不可更改的或者類似對待。

有許多哦類型的設(shè)計模式，主要有算法策略模式的論述關(guān)注點相關(guān)于描述如何開發(fā)在一種計

算平臺上的應(yīng)用特征的高級策略。計算上的設(shè)計模式的論述關(guān)注點是相關(guān)于關(guān)鍵計算識別。

執(zhí)行模式關(guān)注相關(guān)于支持應(yīng)用執(zhí)行，包括咋任務(wù)的執(zhí)行流里面的策略跟建造塊來執(zhí)行任務(wù)同

步。實現(xiàn)策略模式的論題關(guān)注相關(guān)于實現(xiàn)源代碼來支持程序組織以及特定于并行編程的通用

數(shù)據(jù)結(jié)構(gòu)。結(jié)構(gòu)設(shè)計模式所論述的東西關(guān)注相關(guān)與正被開發(fā)的應(yīng)用的高級結(jié)構(gòu)。在范圍上比

設(shè)計模式更大的是建筑模式，通常描述為整個系統(tǒng)跟隨的整體模式。

下面我們將用我們的觀點詳細(xì)分析23中經(jīng)典設(shè)計模式，這23中設(shè)計模式被歸為三類。

每種模式的分析通過三部分組成：

首先，我們講述該模式的總體概念，并給出立體分析法的圖示；然后，我們在業(yè)務(wù)線一

節(jié)描述系統(tǒng)中動態(tài)變化和相互作用；最后，我們對這個系統(tǒng)的特點進(jìn)行簡要評價。

3.2創(chuàng)建類模式

處理對象創(chuàng)建機制的設(shè)計模式，嘗試以適合實際情況的方式來創(chuàng)建對象。物體創(chuàng)建的基

本形式能夠?qū)е略O(shè)計問題或者添加復(fù)雜型到設(shè)計中。創(chuàng)建的設(shè)計模式通過以某種方式控制這

個物體的創(chuàng)建來解決此問題。創(chuàng)建設(shè)計模式進(jìn)一步被歸類成物體創(chuàng)建模式跟類創(chuàng)建模式，旗

子物體創(chuàng)建模式處理物體創(chuàng)建而類創(chuàng)建模式處理列的實例化。

3.2.1抽象工廠模式(AbstractFactoryPattern)

為一個產(chǎn)品族提供統(tǒng)一的建造介面。當(dāng)需要這個產(chǎn)品族的某一系列的時候，這可以從抽

象工廠中選擇相應(yīng)的系列來創(chuàng)建一個具體的工廠類。

基礎(chǔ)結(jié)構(gòu)

抽象工程模式從軟件結(jié)構(gòu)分析的角度有5個結(jié)點族:

工廠介面

1、用戶（1-1）

2、產(chǎn)品介面（2-1）是抽象工廠和用戶之間的契約，用戶通過此介面從抽象工廠獲得

自己需要的產(chǎn)品。

3、抽象工廠（1-2）向用戶提供符合產(chǎn)品介面規(guī)定的產(chǎn)品，而實質(zhì)的構(gòu)造可能來自各

種具體的生產(chǎn)廠家。

4、工廠介面（2-2）

是抽象工廠和生產(chǎn)工廠之間的契約，可保證抽象工廠通過此介面獲得符合要求

的產(chǎn)品。

5、生產(chǎn)工廠（2-3）生產(chǎn)最終實體產(chǎn)品，也就是用戶需要的產(chǎn)品的源頭廠家。它必須有

生產(chǎn)工廠介面所規(guī)定的產(chǎn)品并提供給抽象工廠的能力。

業(yè)務(wù)線

存在一條可用產(chǎn)品的獲取過程通路。也就是用戶向抽象工廠發(fā)出請求，然后抽象工廠向

生產(chǎn)工廠獲取，并最終按原路返回，將產(chǎn)品提交給用戶。

編碼是（<1,1>,<2,1>,<1,2>,<2,2>,<2,3>,<2,2>,<1,2>,<2,1>,<1,1>）。

評述

在軟件開發(fā)里，工廠是代碼中物象被構(gòu)造的地方。抽象工廠模式將一個物體集合的實現(xiàn)細(xì)

節(jié)跟彳巨俚的一般用途分類開來?這使得互換具體類而不影響改變彳巨俚的代碼即使是在運行時。

這種跟類似的模式，導(dǎo)致初始代碼中不必要的復(fù)雜型以及額外的工。正確使用“額外”工作

在應(yīng)用工廠的第二個實例里得到補償。

3.2.2建造師模式(BuilderPattern)

基礎(chǔ)結(jié)構(gòu)

從結(jié)構(gòu)觀點看，建造師模式的結(jié)構(gòu)中有如下五個結(jié)點：1、

用戶〈1,1〉

對物象提出請求。2、

取用介面<2,1>

3、總管<1,2>回應(yīng)用戶的請求，根據(jù)用戶的請求組織物象創(chuàng)造的各種工序，

實際的工序

被提供給分務(wù)承造者。

4、吩咐介面連接統(tǒng)管跟分務(wù)承造者，讓分務(wù)承擔(dān)者按照統(tǒng)管的要求行動。

5、分務(wù)承擔(dān)者完成總管一個產(chǎn)品提出的每一具體的任務(wù)。

業(yè)務(wù)線

<1,1X2,1>?1,2X2,1X1,3?*<2,1X1,1>

實現(xiàn)一個復(fù)雜物象的創(chuàng)造。

評述

建造者模式關(guān)注于一步一步的來創(chuàng)建一個復(fù)雜的物象，并且將這個復(fù)雜的步

驟(工序)專門抽象出來，這就是總歸的工作，從而實現(xiàn)用戶與復(fù)雜性分隔。

3.2.3工廠方法模式(FactoryMethodPattern)

定義一個介面用于創(chuàng)建對象，但是讓子類決定初始化那個類。工廠方法將一個類的初

始化下放到子類中。

基礎(chǔ)結(jié)構(gòu)

工廠方法在結(jié)構(gòu)觀點下有三個結(jié)點:

1、用戶

提出物象的需求。

2、獲取介面連接用戶跟工廠，將用戶的需求提交個工廠，并將工廠生產(chǎn)出

的產(chǎn)品(物

象)送達(dá)用戶。

3、工廠

禍據(jù)用戶的需求生產(chǎn)出物象，而具體的方法和細(xì)節(jié)對用戶來說是被屏蔽

這不結(jié)構(gòu)如下圖所示：

業(yè)務(wù)線

從用戶經(jīng)過獲取介面向工廠傳遞需求信息，并從工廠經(jīng)過獲取介面向用戶傳遞產(chǎn)品。

編碼為<1,1x2,1><1,2>|卜

評述

工廠方法將用戶和自己的需求的詳細(xì)描述與實現(xiàn)隔離開來，這些復(fù)雜任務(wù)被

交給工廠，而用戶的知識只需要是獲取介面。正如［1］中所說工廠方法模式的本

質(zhì)是“為創(chuàng)建象而定義一個介面，但讓衍生類來判斷要實例化哪種類。工廠方法

讓類可推延實例事務(wù)給衍生類?！?/p>

3.2.4.原型模式(PrototypePattern)

從軟件結(jié)構(gòu)的觀點看來，原型模式講的是一個結(jié)構(gòu)中結(jié)點的所具有的操作方法。這是一

種仿造的操作，象通過仿造來生成一種新象。

基礎(chǔ)結(jié)構(gòu)

仿造

象甲

評述仿造信息流通提供了一種直截了當(dāng)?shù)脑煜蠓椒ǎ苊饬藰?biāo)準(zhǔn)方法的成本，也避免了

在客

戶應(yīng)用中需要了解特定的衍生類細(xì)節(jié)。

3.2.5獨象(SingletonPattern)

從結(jié)構(gòu)的觀點，就一個系統(tǒng)中結(jié)點的數(shù)目進(jìn)行現(xiàn)在，對系統(tǒng)的引入操作不會添加新的結(jié)

點。

有契約引入

基礎(chǔ)結(jié)構(gòu)

在系統(tǒng)的一個分伙中，限定了象的數(shù)目。典型的是一個。這通過一個分伙圖示中畫出一

個單獨的象來表示。

獨象

業(yè)務(wù)線評-

述

獨象模式有時在協(xié)調(diào)跨系統(tǒng)的行動是有用的，但會在系統(tǒng)中引入全局狀態(tài)，妨礙系統(tǒng)的

并行。

3.3結(jié)構(gòu)類模式

結(jié)構(gòu)設(shè)計模式是通過識別出一種簡單的途徑來實現(xiàn)實體間關(guān)系來松弛設(shè)計的一個設(shè)計模

式。

3.3.1適配器模式(AdapterPattern)

將某個類的介面裝換成領(lǐng)一個介面表示。界面模式可以消除介面不匹配所造成的兼容

性問題。

適配器模式是關(guān)于創(chuàng)建一個轉(zhuǎn)換，或者映射，就部件到系統(tǒng)的中介抽象的。從軟件結(jié)

構(gòu)的觀點，適配器存在5個結(jié)點：

1、用戶

系統(tǒng)中提出功能需求的部件，觸發(fā)系統(tǒng)狀態(tài)變化的源頭。

2、新介面

連接用戶和配接器，將用戶的功能需求傳遞給配接器。

3、配接器

接受用戶的功能需求，進(jìn)行初步處理，而將任務(wù)中實質(zhì)性的部分通過舊介面?zhèn)鬟f給功能

提供者。

4,舊界面

連接配接器跟原先功能提供者，使得原有系統(tǒng)部件能夠按照自己的方式工作。

5、原先功能提供者通過自己固有的方式工作的舊的

功能性部件。評述

適配器充當(dāng)一個已經(jīng)存在的類的包裝或者修飾者?？梢蕴峁┙o那個類一個不同的或者變

換過的視圖。

3.3.2橋連模式(BridgePattern)橋連模式要達(dá)到的效果是將一

個抽象與其實現(xiàn)解耦，以使二者可以獨立變化。從軟件概念結(jié)構(gòu)的觀點看來，

橋連模式含有5個基本結(jié)點

基礎(chǔ)結(jié)構(gòu)

1、用戶

觸發(fā)系統(tǒng)狀態(tài)變化，采取行動的源頭。

2、抽象介面連接用戶和需求相應(yīng)者，將用戶的需求直接傳遞給需求響應(yīng)者。

3、需求響應(yīng)者

4、實現(xiàn)介面

5、需求實現(xiàn)者業(yè)務(wù)

線

<1,1>

評述

橋連模式通過將一個需求介面分解為抽象介面和實現(xiàn)介面,致使這兩方面在軟件的進(jìn)化

中可以獨立變化，而保證系統(tǒng)得到最大復(fù)用。

3.3.3組合模式(CompositePattem)

把多個對象組成樹狀結(jié)構(gòu)來表示局部與整體,這樣用戶可以同樣的對待個別對象與對象

的組合。

從軟件概念結(jié)構(gòu)的觀點看來，組合模式分析如下。

基礎(chǔ)結(jié)構(gòu)

組合模式的概念結(jié)構(gòu)視圖中包含有5個結(jié)點，四條邊。

2、一致介面一

3、響應(yīng)整體

4^一致介面二

5、相應(yīng)個體業(yè)務(wù)

線

評論

組合模式組合各個象到一個樹結(jié)構(gòu)里，從而表示出了部分-整體的層次結(jié)構(gòu)。并且

由于中間的兩個間接結(jié)點是相同的（都是一致介面），這使得用戶可以一致的對待

個體跟組合體。

3.3.4修飾模式(DecoratorPattern)

向某個對象動態(tài)的添加更多的功能。修飾模式是除類繼承外另外一種擴展功能的方

法。

從軟件概念結(jié)構(gòu)的觀點出發(fā)，我們在下面對修飾模式作出如此解析。

基礎(chǔ)結(jié)構(gòu)

業(yè)務(wù)線評

論

修飾模式使得在運行時拓展（修飾）一個特定象的功用變得可能，而獨立于相同類

的其它實例，在假定設(shè)計時已經(jīng)完成了一些打底工作。用戶因此既可以通過原有的簡樸

介面跟修飾著交往，也可以使用修飾介面跟修飾者交往，而修飾者充分利用了原本的功

用。

3.3.5外墻模式(FagadePattern)

這個名字的由來是類比與建筑上的外墻。外墻是到一個更大的代碼體，比如一個類庫，

的簡化后介面的物體。

外墻能夠：使得一個軟件庫更加容易使用，理解和測試，因為外墻對于通常的任務(wù)有著

方便的方法；基于同樣的原因，使得使用此庫的代碼更加易讀；減少外部代碼對庫的內(nèi)部工

作機制的依賴，因為多數(shù)代碼使用此外墻，因此允許在開發(fā)此系統(tǒng)中的伸縮性；用一個良好

設(shè)計的API包裝一個糟糕設(shè)計的API集合。

為子系統(tǒng)中的以群介面提供一個統(tǒng)一的介面，外觀模式定義了一個高層介面，這個介

面使得這以子系統(tǒng)更加容易使用。

從軟件概念結(jié)構(gòu)的觀點出發(fā)，我們在下面對修飾模式作出如此解析。

框架

業(yè)務(wù)線

評論

外墻模式為交往巨大的代碼集提供了一種簡化的介面?？梢允沟密浖斓氖褂酶?/p>

容易使用，理解，和測試，也使得使用此庫的代碼容易讀懂，并減少了庫外部代碼對這個

庫的依賴，也能為設(shè)計上糟糕的API集合提供一個單獨的有著良好設(shè)計的APL

適配器模式用于包裝體需要遵守一個特別的介面且必須支持一種多態(tài)行為時。另一方

面，外墻用在想要有一個更容易或者更加簡單的介面來使用。

3.3.6輕便模式(FlyweightPattern)

輕便體是通過跟其它類似的物象共享盡可能多的數(shù)據(jù)來最小化內(nèi)存使用的物象;這是在

一種簡單重復(fù)的表示將會使用不可接受數(shù)量的內(nèi)存時大量使用物象的一種途徑。這個術(shù)語來

源于拳擊運動中的輕量級。

通過共享以便有效的支持大量細(xì)粒度對象。從軟件概念結(jié)構(gòu)的觀點出發(fā)，我們在下面對

修飾模式作出如此解析。

區(qū)別是應(yīng)求者的做事方式或者算法。從軟件概念結(jié)構(gòu)的觀點出發(fā)，我們在下面

對修飾模式作出如此解析。

評論

通常對象狀態(tài)的某些部分可以共享且將它們放入外部的數(shù)據(jù)結(jié)構(gòu)并且在他們被使用

時將這些外部數(shù)據(jù)臨時傳入這些輕便對象是很普遍的。

在其它場合共享等同數(shù)據(jù)結(jié)構(gòu)的想法被叫做散列控制臺操作(hashconsing)o

3.3.7代理模式(ProxyPattern)

代理，在最一般的形式下，是充當(dāng)?shù)侥撤N其它東西的介面的類。代理可以介面到任何其

它東西上：一個網(wǎng)絡(luò)連接，內(nèi)存中的一個大對象，一個文件，或者其它對于復(fù)制是昂貴或者

不可能的資源。

為其它獨享提供一個代理來控制對這個對象的交往。

框架

以減少應(yīng)用的內(nèi)存印跡。

3.4行為型模式

行為模式是識別在對象之間共同的通信模式跟實現(xiàn)這些模式的設(shè)計模式。通過這樣做,

這些模式增加了執(zhí)行這種通信的韌性。

3.4.1責(zé)任鏈模式(ChainofresponsibilityPattern)

為解除請求的發(fā)送者與接受者間的耦合，而使多個對象都有機會處理這個請求。將這

些對象連成一條鏈，并沿著這條鏈傳遞該請求，直到有一個對象處理它。

3.4.2命令模式(CommandPattern)

將一個請求封裝為一個對象，從而你可用不同的請求對客戶進(jìn)行參數(shù)化；對請求排隊或

記錄請求日志，以及支持可取消的操作。這些信息包括方法名字，擁有此方法的對象跟用

于方法參數(shù)的值。

框架

客戶實例化命令對象，并提供在后面使喚此方法所要求的信息。

召喚者決定此方法什么時候應(yīng)該被使喚。

接收者是包含此方法的代碼的一個實例。

評論使用命令模式使得構(gòu)造在選擇的時候需要委托,安排順序或者執(zhí)行方法的一般部件

而不

需要知道此方法或者方法參數(shù)的擁有者的一般部件更加容易。

3.4.3解釋器模式(InterpreterPattern)

給定一個語言，定義它的文法的一種表示，并定義一個解釋器，該解釋器使用^表示來

解釋^言中的句子。

解釋器模式規(guī)定如何求值語言里的句子?；鞠敕ㄊ菍τ谠谝粋€特殊的計算語言里的

每個符號（終結(jié)符或者非終結(jié)符）都有一個類。

框架

3.4.4迭代器模式(IteratorPattern)

提供一種方法順序訪問一個聚合對象中各個元素，而又不需暴露該對象的內(nèi)部表示。

迭代器被用于遍歷一個容器并交往容器的元素。迭代其模式將算法從容器解耦了出來。（在

一些情況下，算法必須是容器規(guī)定的且因此不能被解耦）。c類語言中指針就是一種迭代器。

3.4.5媒介器模式(MediatorPattern)

通常一個程序由許多（有時很巨大）個類組成。因此邏輯跟計算都被分布在這些類之間。

然而，由于更多類是在程序里開發(fā)的，特別是維護(hù)跟/或者再構(gòu)期間，這些類之間的通信問

題可能就變得更加復(fù)雜。這使得程序更加難以閱讀和維護(hù)。進(jìn)一步，這可能變成變更程序的

困難，因為任何的變動都可能給影響在幾個其它類里面的代碼。

在媒介器模式下，對象間的通信被用一個媒介器對象來封裝。對象不再跟每個其它對象

直接通信，但是代之以通過媒介器來通信。這減少了在通信對象間的依賴，因此降低了偶爾。

框架

3.4.6備忘錄模式(MementoPattern)

備忘錄模式由兩者來使用：發(fā)起者跟看管者。發(fā)起者是有一種內(nèi)部狀態(tài)的某種對象?？?/p>

管者打算為發(fā)起者做些事情，但想要能夠撤銷這種狀態(tài)。看管者首先向發(fā)起者請求一個備忘

體。然后做它所要求的任何操作（或者操作序列）。為了回滾到此操作之前的狀態(tài)，看管者

返回一個備忘體給發(fā)起者。備忘體自身是一個不透明物體（看管者不能，也不應(yīng)該，改變的

東西）。

框架

3.4.7觀察者模式(ObserverPattern)

在對象間定義一個對多個的聯(lián)系，由此當(dāng)一個對象改變了狀態(tài)，所有其他相關(guān)的對象

會被通知并自動刷新。

在這里，一個被叫做主題的對象，維護(hù)著彳巨俚的依賴冊子，被叫做觀察者，并自動通

知彳巨俚任何狀態(tài)的變動，通常是通過使喚彳巨俚的方法之一。這主要用于實現(xiàn)分布式的時間處

理系統(tǒng)。

框架

3.4.8狀態(tài)模式(statepattern)

這個模式用在表示一個對象狀態(tài)的程序里。這是在運行時部分改變彳巨的類型的一種干凈

途徑。

框架

3.4.9策略模式(StrategyPattern)

策略模式意圖提供一種方法來定義一族算法，封裝每個成為一個對象，并使得它們可以

相互改變。策略模式使得算法獨立于使用彳巨俚的客戶。

編程語言里的本質(zhì)需求是存儲引用在數(shù)據(jù)結(jié)構(gòu)里某些代碼并取出它的能力。框

架

3.4.10模板方法模式(Templatemethodpattern)

在一個操作中定義算法的骨架，將其中某些步驟托付個子類實現(xiàn)。模板方法讓子類定

義算法中的某些步驟而不修改算法的結(jié)構(gòu)。

模板方法定義了一個算法的程序骨架。這些算法步驟的一個或者多個可被子類疊騎，

以此在確保中心算法仍然被服務(wù)的情況下允許不同的行為。

框架

算法—抽象數(shù)據(jù)

評論

模板方法模式強相關(guān)到非虛介面(NVI模式。NVI模式認(rèn)識到召喚從屬抽象方法的非抽

象方法的利益。這種間接層次允許相關(guān)于抽象操作的預(yù)先操作以及后續(xù)操作能夠立即發(fā)生,

并且允許將來不可預(yù)見的變動。NVI模式能夠用非常少的軟件產(chǎn)品跟運行時成本來開發(fā).

3.4.11訪問者模式(vistorpattern)

訪問者模式是分隔算法跟彳巨所操作的物體結(jié)構(gòu)的途徑。這種分隔的實踐效果是添加新

的操作到已經(jīng)存在的物體結(jié)構(gòu)而不修改那些結(jié)構(gòu)的能力。本質(zhì)上，訪問者模式允許添加新的

虛函數(shù)到一個類族而不修改那些類彳巨俚自家；替代的，可以創(chuàng)建一個實現(xiàn)所有這個虛函數(shù)的

素顏恰當(dāng)?shù)膶ｉT的訪問者類。訪問者采用這個實例引用作為輸入，并通過雙重派遣實現(xiàn)這個

目標(biāo)。

框架

評論

在能力上，訪問者模式比傳統(tǒng)的虛函數(shù)更受限制。為沒有在每類里面添加一個小回派方

法的類創(chuàng)建訪問者是不可能的。在原生的實現(xiàn)中，每個類的回派方法是不可繼承的。雙重

派遣是多重派遣的特殊形式，是將一個函數(shù)調(diào)用依賴與在此調(diào)用中被召喚的兩個物體的

運行時類型派發(fā)到不同的具體函數(shù)的機制，在代碼中從一個函數(shù)里被調(diào)用的具體函數(shù)依賴于

一個單獨物體的動態(tài)類型，因此彳巨俚被稱作單獨派遣調(diào)用，或者簡單虛函數(shù)調(diào)用。

3.5并發(fā)模式

并發(fā)模式是處理多線程編程范式的設(shè)計模式。

3.6總結(jié)

設(shè)計模式研究的是一種比較微觀的結(jié)構(gòu)現(xiàn)象。所以這些現(xiàn)象在軟件結(jié)構(gòu)領(lǐng)域普遍的存

在。這些現(xiàn)象有兩條非常顯著的東西。

一是發(fā)生關(guān)聯(lián)的結(jié)點之間往往通過一種強制性的契約來約束和規(guī)范雙方的關(guān)聯(lián)。二是

結(jié)點之間的關(guān)聯(lián)往往經(jīng)過第三方媒介，媒介的存在將雙方的相互依賴性減弱了，并

且經(jīng)常出現(xiàn)一種專業(yè)的實體性的媒介。

4軟件建筑

軟件建筑學(xué)科集中于通過抽象和關(guān)注分隔來減少復(fù)雜性。軟件建筑的概念首先是

在EdsgerDijkstra于1968年和DavidParnas于1970年代早期的研究工作中認(rèn)明的。這

些人著重軟件系統(tǒng)的結(jié)構(gòu)并認(rèn)為正確獲取結(jié)構(gòu)是關(guān)鍵的。由于在1990年代人們對建筑風(fēng)格

（模式），建筑描述語言，建筑檔案跟形式方法等作了大量研究，軟件建筑這一領(lǐng)域就變得

流行起來。

雖然迄今在軟件建筑上做了許多的研究和發(fā)展，但是對“軟件建筑”這一術(shù)語的精確定

義上人們?nèi)匀粵]能達(dá)成一致。因為在通往建造一個系統(tǒng)的正確道路上并沒有清晰規(guī)則，設(shè)計

軟件建筑仍然是藝術(shù)和科學(xué)的混合。但不管怎樣，軟件建筑仍然可以指導(dǎo)軟件相關(guān)人員如何

采取步驟，如何進(jìn)行任務(wù)。

我們將在這一章從軟件概念結(jié)構(gòu)的觀點出發(fā),運用我們的表示方法來分析幾種著名的軟

件建筑風(fēng)格。軟件中概念結(jié)構(gòu)里的一些基本原理將再一次發(fā)現(xiàn)，也證明了我們的分析方法是

行之有效的。

4.1層次型

層次風(fēng)格的建筑中最重要的概念是抽象層（或者抽象級）。在軟件概念結(jié)構(gòu)的分析中，

這就是結(jié)點。抽象層是隱藏特定功能集的實現(xiàn)細(xì)節(jié)的途徑。是一個模型或者算法的概括，遠(yuǎn)

離任何具體的實現(xiàn)。這些概括來自寬廣的類似事物，通過表示出現(xiàn)在各種具體實現(xiàn)里面的類

似特性的模型封裝起來。好的的抽象層所提供的簡明性使得通過提煉一個有用的概念或者象

征讓復(fù)用變得容易，這種適用的場景能夠被快速識別。多個抽象層通常按照線性結(jié)構(gòu)組合成

一個抽象級別的等級體系。

框架

2、層介面

業(yè)務(wù)線

評論

層是具有相同的對其它模塊的鏈依賴集的類組。換句話說，層是在類似的環(huán)境中能夠復(fù)用

的組件的群組。編程語言里，這通常表示為軟件模塊之間的"import"依賴。

4.2管線與過濾器型

管線由一個處理元素（進(jìn)程，線程，協(xié)同程序，等…）鏈構(gòu)成，被安排得使得每個元素

的輸出是下一個元素的輸入。通常有一定量的緩沖被放在連續(xù)的元素之間。在管線里流動的

信息經(jīng)常是記錄，字節(jié)或者比特流。

框架

業(yè)務(wù)線評

論

4.3黑板型

在黑板型建筑中，有一個共用的知識基地一一“黑板”，它會被一個成分多樣的專業(yè)知

識源迭代更新，從一個問題說明開始，以一個解答結(jié)束。每個知識源在其內(nèi)部約束匹配黑板

的狀態(tài)時用一個部分解來更新黑。通過這種方式，專家們合作來解決問題。這種建筑最初是

設(shè)計為處理復(fù)雜，病態(tài)定義問題的一種求解方式，在那種情況下解總是它個各個部分之和。

框架

黑板型系統(tǒng)應(yīng)用有三個主要部件構(gòu)成：

1.軟件專家模塊，這也被叫做知識源(KSs).每個知識源提供應(yīng)用所需要的特殊專業(yè)

知識。

2.黑板，這是一個共享的問題、部分解、建議跟貢獻(xiàn)出的信息的貯存庫。黑板也可被

認(rèn)為是最近被其它知識源“提出”過的對當(dāng)前問題的貢獻(xiàn)的一個動態(tài)庫。

3.控制殼，控制系統(tǒng)中問題解決的活動流。為防止軟件專家的相互干擾，KSs需要一

種機制最有效和凝聚的形式來組織軟件專家的使用，而這由控制客提供。

評論黑板系統(tǒng)中支持在不同知識源之間的交互和協(xié)作為設(shè)計和維護(hù)應(yīng)用提供了巨

大的彈

性。因為技術(shù)發(fā)展的步伐在加快，在軟件模塊過時情況下能夠被替換是非常重要的。

4.4基于事件隱匿召喚

在這種建筑里面系統(tǒng)的結(jié)構(gòu)是圍繞事件處理的，使用回派的形式。這密切相關(guān)域控制反

轉(zhuǎn)的原則。

“暗中召喚后面的想法是取代直接召喚一個過程，一個組件能夠宣布(或者廣播)一個或者

更多的事件。系統(tǒng)里的其它部件能夠通過關(guān)聯(lián)一個過程到這個事件上來在注那個事件里注冊

一個意向。當(dāng)這個事件被公布時系統(tǒng)自家就召喚所有己經(jīng)為此事件注冊過的過程。因此一個

事件宣布暗中會導(dǎo)致在其它模塊里過程的召喚。”

框架

4.5以數(shù)據(jù)為中心的建筑

數(shù)據(jù)庫中心的建筑或者數(shù)據(jù)為中心的建筑有幾種不同的意思，一般是相關(guān)那種數(shù)據(jù)庫在

其中扮演了一個至關(guān)重要角色的軟件建筑。經(jīng)常這種描述意味著與其它可選方法的一種對

比。例如，“數(shù)據(jù)庫中心”的建造可以是如下幾種的組合：

（1）使用一個標(biāo)準(zhǔn)的，一般用途的關(guān)系數(shù)據(jù)庫管理系統(tǒng)，相對于定制的記器里或者基于

文件的數(shù)據(jù)結(jié)構(gòu)跟交往方法。

（2）使用動態(tài)的，表驅(qū)動的邏輯，相對于在之前編譯過的程序里的邏輯。

（3）使用運行在數(shù)據(jù)庫服務(wù)器上的存儲過程，跟更加依賴與運行在多層建造里的中間

件應(yīng)用服務(wù)器上的邏輯。

（4）使用一個共享的數(shù)據(jù)庫作為在分布式計算應(yīng)用里的并行進(jìn)程間的通信基礎(chǔ)，相對

于經(jīng)由消息傳遞函數(shù)跟消息導(dǎo)向的中間件的直接進(jìn)程間通信。

框架

評論

表驅(qū)動的邏輯可以使得程序更簡單和更有彈性。數(shù)據(jù)庫為中心的建筑使得軟件

更容易開發(fā)和維護(hù)。在分布式應(yīng)用中通過利用DBMS提供的事物處理和索引可以達(dá)

到高程度的可靠，性能。

4.6面向服務(wù)的建筑(SOA)

是計算里面系統(tǒng)開發(fā)和集成結(jié)點一些設(shè)計原則的有彈性集合?；赟OA的系統(tǒng)將功能

打包成能在多個，分隔的來自兒個商業(yè)領(lǐng)域的系統(tǒng)里使用的可互操作的套裝。

SOA一般也為服務(wù)的顧客，比如基于WEB的應(yīng)用，提供途徑來覺察到可用的基于SOA

的服務(wù)。而XML通常被用來作為SOA服務(wù)之間進(jìn)行交接，盡管這并不被要求。SOA定義

如果如何廣泛的來為WEB環(huán)境和使用多個實現(xiàn)平臺來集成分割著的應(yīng)用。不是定義API,

SOA是根據(jù)協(xié)議和功能來定義介面。

框架

評論

服務(wù)導(dǎo)向的建筑要求服務(wù)跟操作系統(tǒng)，以及其它潛伏在應(yīng)用下面的技術(shù)有著松散耦合的

關(guān)系。SOA將功能分隔成不同的單元，或者服務(wù)，而這些東西開發(fā)者能夠在網(wǎng)絡(luò)上可與之

交往，從而允許用戶在應(yīng)用的產(chǎn)品中組合或者復(fù)用它們。這些服務(wù)跟彳巨俚相應(yīng)的顧客通過按

良好定義的，共享的格式傳遞數(shù)據(jù)來通信，或者通過在多個服務(wù)之間協(xié)調(diào)一個活動。

4.7三層模型

三層(Three-tier)模型是用戶介面，功能處理邏輯(“業(yè)務(wù)規(guī)則”)，計算機數(shù)據(jù)存

儲與數(shù)據(jù)交往被作為獨立模塊來開發(fā)和維護(hù)，最經(jīng)常存在于分離的平臺上，的一種客戶-服

務(wù)器建筑。是JohnJ.Donovan在OpenEnvironmentCorporation(OEC)開發(fā)出來的。客

戶-服務(wù)器特征描述了應(yīng)用中程序間的合作關(guān)系。服務(wù)器部件提供對一個或者多個客戶的功

能或者服務(wù)，可發(fā)起對這樣的服務(wù)的請求。

框架

1、提交層

顯式相關(guān)比如瀏覽商品，購買，跟購物車內(nèi)容的信息。彳巨通過輸出結(jié)構(gòu)到瀏覽器/

客戶層來跟其它層進(jìn)行通信。

2、業(yè)務(wù)處理介面連接提交層與應(yīng)用層，向應(yīng)用層傳遞各種命令以及向提交層回送

各種處理結(jié)果。

3、應(yīng)用層

這一結(jié)點是從提交層中拔出來的，也被稱為業(yè)務(wù)邏輯，邏輯層，數(shù)據(jù)交往層或者中

間層。它通過執(zhí)行細(xì)瑣的處理來控制應(yīng)用的功能。

4、數(shù)據(jù)服務(wù)介面連接應(yīng)用層與數(shù)據(jù)層，回應(yīng)應(yīng)用層的數(shù)據(jù)查詢和存儲以及

數(shù)據(jù)獲取請求。

5、數(shù)據(jù)層

這一結(jié)點構(gòu)成整個系統(tǒng)中的數(shù)據(jù)服務(wù)器。信息在此被存儲和獲取。這結(jié)點還保持?jǐn)?shù)

據(jù)中立和獨立于應(yīng)用服務(wù)器或者業(yè)務(wù)邏輯。

業(yè)務(wù)線

評論

跟有著良好設(shè)計的模塊化的軟件的通常優(yōu)點不同，三層建筑意圖允許三層中的任一個都

可隨著需求或者技術(shù)變動而被更新或者替換。

4.8總結(jié)

相比設(shè)計模式，軟件建筑關(guān)注的結(jié)構(gòu)層次更加粗略和寬廣。軟件建筑中強調(diào)概念結(jié)構(gòu)圖

中每個結(jié)點的功能完整性，也就是一定程度的獨立和提供服務(wù)的能力。

這里媒介之類的細(xì)節(jié)沒有如設(shè)計模式中那么受重視,取而代之的是分解和積聚成為軟件

建筑中的核心關(guān)注。

5.結(jié)論和展望

前面我們已經(jīng)對軟件概念結(jié)構(gòu)所要研究的對象有了基本的認(rèn)識，并且通過對設(shè)計模式和

軟件建筑進(jìn)行概念結(jié)構(gòu)分析，這一認(rèn)識得到深入和佐證。

這一章，我們將在更高的抽象層次上總結(jié)和論證軟件系統(tǒng)中的基本原理，這是對各種軟

件系統(tǒng)中的各種結(jié)構(gòu)現(xiàn)象做的概括。最后我們據(jù)此分析了軟件工程里眾所周知的通用的工程

方法。

5.1基本結(jié)構(gòu)原理

結(jié)構(gòu)這一詞的意義是部分組成整體，部件造成系統(tǒng)的一種固化后的成果所帶來的外部觀

感和內(nèi)在的道理。

結(jié)構(gòu)分析是認(rèn)識，分析事物的重要方面，籍此我們可以對事物的整體和部分，全體和個

體的方方面面的關(guān)系作出詳盡解釋。結(jié)構(gòu)分析也是我們進(jìn)行制造，創(chuàng)建的基本工序。任何制

造和創(chuàng)建都可以看作是拆分，裁剪，組合，搭配的過程，而這寫過程和步驟都在基于結(jié)構(gòu)分

析所獲得認(rèn)識的指引和約束下進(jìn)行。

結(jié)構(gòu)在軟件工程領(lǐng)域更有著突出的作用.軟件工程實踐中形成的概念，比如過程，模塊,

接口，介面，封裝，架構(gòu)等等概念都直接是結(jié)構(gòu)的內(nèi)容，因為軟件正是許許多多的代碼文本,

各種庫，多樣的運行時環(huán)境的精心組合才生成出來的。

我們將在一節(jié)對結(jié)構(gòu)中的四大基本原理做一些論述。這四大基本原理是分解，積聚，契

約，媒介。

5.1.1分解

系統(tǒng)總是可以分解的，這是我們對系統(tǒng)的基本預(yù)設(shè)。當(dāng)然，分解的進(jìn)行總是在一定的層

面上進(jìn)行的。分解的層面是指系統(tǒng)分解出來的單元，部分的類屬。

分解單元如果屬于己知類屬，則是一種很好的分解，因為這樣我們能夠利用已知的知識

進(jìn)行進(jìn)一步的分析，并且這樣會比較完整，而不是零散。

分解是為了認(rèn)識上的方便，也就是說分解使得我們可以深入的理解系統(tǒng)，了解系統(tǒng)所表

現(xiàn)出來的復(fù)雜的，甚至是難以捉摸的性質(zhì)。如果分解不能達(dá)成這個效果，那么分解是失敗的。

成功的分解應(yīng)該給出系統(tǒng)運行的一目了然的視圖。

分解出來的單元的規(guī)模和復(fù)雜度是分解的細(xì)致量。細(xì)致量應(yīng)該按照需求來決定，過細(xì)和

過粗都不會達(dá)成方便我們認(rèn)識系統(tǒng)的目的。

分解本身是一個遞歸的過程，這是內(nèi)在規(guī)定的。因為我們認(rèn)為系統(tǒng)是可分解的，并且認(rèn)

為分解出的單元也系統(tǒng)，那么我們就必然認(rèn)同這點。當(dāng)然我們的認(rèn)識要求總是受到各種方面

的限制，這也就是決定了分解實際上并非是一個無限的遞歸過程，是有限的，通常只是在一

兩步后就終止。分解遞歸中的迭代次數(shù)就是分解的深度。

5.1.2積聚

積聚是分解的反面，分解將一個大系統(tǒng)拆散為多個小系統(tǒng)，而積聚將多個小系統(tǒng)組織成

一個大系統(tǒng)。積聚的進(jìn)行也受到環(huán)境的容量和這些公組織的單元系統(tǒng)的聚合能力決定。

積聚的規(guī)模是對參與積聚的單元的數(shù)量的衡量。系統(tǒng)的積聚規(guī)模應(yīng)該受到理性自覺的控

制。過小的積聚可能不能實現(xiàn)系統(tǒng)目標(biāo)，而過大的積聚也因為積聚引發(fā)的問題而使得最終的

系統(tǒng)同樣不能達(dá)成目標(biāo)。

積聚的進(jìn)行應(yīng)該不能讓系統(tǒng)的復(fù)雜度變得難以控制，這種復(fù)雜性常常體現(xiàn)在積聚單元的

關(guān)聯(lián)。這些關(guān)聯(lián)的度量就是系統(tǒng)的耦合度。復(fù)雜的積聚不僅難以進(jìn)行，而且構(gòu)造出的系統(tǒng)也

更加脆弱，和不可靠。

5.1.3契約

在分析的觀點下，可看到部分之間的關(guān)聯(lián)。關(guān)聯(lián)是系統(tǒng)的本質(zhì)。系統(tǒng)中關(guān)聯(lián)的特征很大

程度上決定了系統(tǒng)的特征。

在工程中系統(tǒng)總有容錯，可靠，可移植等目標(biāo)，這些都要求在系統(tǒng)的關(guān)聯(lián)中體現(xiàn)。在程

序中不同部分的關(guān)聯(lián)，最簡單的是通過各種元素數(shù)據(jù)，常常是變量的直接牽扯。這種關(guān)聯(lián)雖

然總是很直接，方便，但是卻將系統(tǒng)變得復(fù)雜和難以管理。

工程經(jīng)驗告訴我們系統(tǒng)不同部分之間的關(guān)聯(lián)應(yīng)該通過相對穩(wěn)定的，相對正式的接口來表

達(dá)。這種接口介面實際上就體現(xiàn)了一種契約關(guān)系。

契約是不同部分之間的共識，是相對成熟，經(jīng)得住考驗的合同。當(dāng)系統(tǒng)的不同部分之間

通過契約來關(guān)聯(lián)時，他們之間的相互依賴和相互耦合程度就降低了。因為他們之間不再需要

深入對方，了解對方的全部細(xì)節(jié)，而只需要掌握共同的契約所規(guī)定的內(nèi)容。

因此，通過契約來建立系統(tǒng)的部分之間的關(guān)聯(lián)是構(gòu)造系統(tǒng)的一條重要準(zhǔn)則。

5.1.4媒介

媒介是關(guān)聯(lián)在系統(tǒng)里面的進(jìn)一步突出。相比于契約，媒介更加穩(wěn)定，而且變動可以動態(tài)

變化，而不影響所聯(lián)結(jié)雙方的關(guān)聯(lián)。

通過媒介關(guān)聯(lián)的兩部分之間的耦合程度被降到最低。如果要實現(xiàn)兩部分之間的松散耦

合，那么媒介就是一種很有用的機制。

5.2工程原則和方法

根據(jù)對軟件系統(tǒng)概念結(jié)構(gòu)的系統(tǒng)分析方法，我們自然的提出軟件工程里系統(tǒng)構(gòu)造的四個

一般步驟，也就是概念抽象，結(jié)構(gòu)分析，部件連接，總體綜合。這四個一般步驟的內(nèi)容在下

面得到相應(yīng)論述。

5.2.1概念抽象

立體分析法將軟件系統(tǒng)的概念構(gòu)造分為通過抽象形成的垂直構(gòu)造和通過交織形成的水

平構(gòu)造，所以很自然的概念抽象是軟件系統(tǒng)構(gòu)造過程一般步驟中的第一個步驟。概念抽象其

實就是從大量的事物中概括共同的東西。

概念抽象步驟有三個基本議題。第一個議題是通過概念抽象來描述需求，并使用概念抽

象來解決需求。這項議題在軟件

開發(fā)中一般有語言本身內(nèi)在規(guī)定。比如在C++中，描述復(fù)雜的數(shù)據(jù)對象必須使用類等抽象。

以抽象概念為原型，構(gòu)造實例的，運行的對象是使得軟件開發(fā)走向通用的基本途徑。

第二個議題是通過抽象來復(fù)用代碼，避免系統(tǒng)中的重復(fù)以及因重復(fù)帶來的種種問題。這

也是所謂的“抽象原則”所表達(dá)的主要內(nèi)容。抽象原則是減少程序中信息重復(fù)（通常意味著

著重代碼重復(fù)）的基本格言。人們一般是利用編程語言或者軟件庫所提供的抽象來達(dá)到的。

這個原則有時會被表達(dá)為對程序員的一個建議，但是有時也被表達(dá)為編程語言的要求，假定

為什么要求使用抽象的原因是自理解的。但對于程序員而言，抽象原則可以概括為“不要重

復(fù)你自己”原則，這項建議一般避免了信息的重復(fù)，也避免了軟件開發(fā)過程中人力的重復(fù)。

程序中每個有意義的功能片應(yīng)該只被實現(xiàn)一次。在類似的函數(shù)被不同的代碼片來執(zhí)行的地

方，通過從各個部分抽象出將它們組合成一個通常是有益的。

第三個議題是概念抽象應(yīng)該關(guān)注開發(fā)/封閉原則所關(guān)注的內(nèi)容。在物體-導(dǎo)向的編程中，

開發(fā)/封閉原則認(rèn)為“軟件實體（類，模塊，函數(shù)等等）應(yīng)該對于擴展開發(fā)，但是對于修改要封閉”；

也就是實體能夠允許它的行為被修改而不用改動它的源代碼。這項原則在產(chǎn)品環(huán)境中尤其

有價值，因為對源代碼的改動可能必需代碼復(fù)審，單元測試，以及其它類似的過程來驗證

它可用在產(chǎn)品中，而遵循了這種原則的代碼在它被擴展時就不需要改變，且因而不需要這

樣的一些努力。

開放/封閉原則存在兩種解讀途徑，一種Meyer的開放/封閉原則，另一種是多態(tài)式開放

/封閉原則。這兩種解讀途徑都使用繼承來解析外在的困難，但是其中所包含的目標(biāo)，技術(shù)，

和結(jié)果是卻不同的。

Meyer的開放/封閉原則的想法是某個類一旦完工，它的實現(xiàn)就只能被修改來糾正錯誤，

新的或者改變后的特征都要求創(chuàng)建一個不同的類。而這個不同的類通過繼承來復(fù)用原來類的

代碼。派生的子類可以有也可以沒有跟原來類相同的介面。Meyer的定義提倡的是實現(xiàn)方式

的繼承。實現(xiàn)方式的能夠通過繼承來復(fù)用，而介面規(guī)定彳巨不需要是。已經(jīng)存在的實現(xiàn)方式對

于修改是封閉的，而新的實現(xiàn)方式不需要己經(jīng)存在的介面。

1990年代開發(fā)/封閉原則被重新定義為抽象介面的使用，實現(xiàn)能夠被改變而多種實現(xiàn)能

夠被創(chuàng)建且可多態(tài)的為其它的所替換，這就是多態(tài)式開放/封閉原則。與Meyer的解讀途徑

相對比，這種定義提倡的是對抽象基類的繼承。介面規(guī)定能夠通過繼承來復(fù)用但是實現(xiàn)不需

要。已經(jīng)存在的介面對修改是封閉的而新的實現(xiàn)必須，至少是，實現(xiàn)那個要修改的介面。

5.2.2結(jié)構(gòu)分解

軟件系統(tǒng)構(gòu)造中第二個一般步驟是結(jié)構(gòu)分解,也就是將根據(jù)系統(tǒng)的功能特點或者其它考

慮，將系統(tǒng)分成若干個有著更小復(fù)雜度的結(jié)構(gòu)的小系統(tǒng)的方法。在我們的立體分析方法中這

相應(yīng)與在交織構(gòu)造中獲取結(jié)構(gòu)圖的結(jié)點。

這一步驟有兩個基本議題。一個基本議題是關(guān)注點的分離

（SoC）?

關(guān)注點分離就是將系統(tǒng)分隔成在功能上盡可能少重疊的有著不同特征的部分。關(guān)注是程

序中意向或者聚焦的任何一個片塊。典型的，關(guān)注是特征或者行為的同義詞。在通往關(guān)注點

分離的過程中，傳統(tǒng)上是以編程的模塊化跟封裝（或者操作的透明）以及在信息因此的幫助

下來達(dá)成目標(biāo)的。分層的設(shè)計經(jīng)常也是基于關(guān)注點的分離（例如提交層、業(yè)務(wù)邏輯層、和數(shù)

據(jù)交往層、數(shù)據(jù)庫層）。

事實上，關(guān)注點分離在許多其它領(lǐng)域同樣是一條重要的設(shè)計原則，比如城市規(guī)劃、建筑

和信息設(shè)計。目標(biāo)是將系統(tǒng)設(shè)計得功能能夠最優(yōu)的獨立于其它功能，因此一個功能的失敗不

會導(dǎo)致其它功能也失敗，并且一般使得系統(tǒng)更加容易理解，設(shè)計和關(guān)聯(lián)復(fù)雜的相互依賴的系

統(tǒng)。

方面導(dǎo)向的軟件開發(fā)（AOSD）是這一議題的解決問題的特殊方法。它尋求系統(tǒng)的新的

模塊化以從主程序的事務(wù)邏輯中孤立出輔助的或者支持性的功能。AOSD還允許多個關(guān)注

點被分開來表達(dá)并自動將它們統(tǒng)一成工作系統(tǒng)。典型的，一個方面（aspect）是一系列啰嗦

或者糾結(jié)代碼，這使得它難以理解和維護(hù)。

第二個基本議題是模塊的內(nèi)聚。結(jié)構(gòu)分解出的結(jié)點，包括模塊之類，存在質(zhì)量上的要求,

這種質(zhì)量要求中內(nèi)聚是最重要

的指標(biāo)之一。內(nèi)聚是指軟件模塊的源代碼所表達(dá)的功能之間關(guān)聯(lián)的強度。它是一個有序的測

量數(shù)量，在談?wù)撝型ǔ１磉_(dá)為高內(nèi)聚、低內(nèi)聚等。人們更喜愛有著高內(nèi)聚的模塊，因為這樣

的模塊通常跟一些軟件系統(tǒng)所要追求的特征，包括健壯、可信賴、可復(fù)用和可理解，聯(lián)系在

一起，而低內(nèi)聚往往跟不軟件系統(tǒng)不想要的特征比如難維護(hù)、難測試、難復(fù)用、和相當(dāng)難理

解等特征聯(lián)系在一起。

人們將內(nèi)聚的類型或者說級別，按從最壞到最好的，做了如下劃分：

1、巧合內(nèi)聚（最壞）模塊的各個部分被隨意成組，部分之間唯一的關(guān)系就是他們被分

在了一起（例如一個“工具”類）。

2、邏輯內(nèi)聚模塊的各個部分被成組是因為他們在邏輯上被分類為相同的東西，即使

根據(jù)特征來說是它們不同的（例如所有的鼠標(biāo)跟鍵盤輸入處理工段成組）。

3、臨時內(nèi)聚模塊的各個部分在被處理的時侯成組一一在程序執(zhí)行的特定時刻被處理

（例如一個在捕捉到錯誤例外后被使喚的打開文件，創(chuàng)建一個錯誤記載并通知用

戶的函數(shù)）。

4、過程內(nèi)聚一個模塊的各個部分被分組是因為跟隨著執(zhí)行的一個特定序列（例如一

個檢查文件許可并然后打開此文件的函數(shù)）。

5、通信內(nèi)聚模塊的各個部分被群集是因為他們操作相同的數(shù)據(jù)（例如一個操作相同

信息記錄的模塊）。

6、順序內(nèi)聚模塊的各個部分被群集是因為來自一個部分的輸出像一個組裝線一樣輸

入到另外一部分（例如一個從文件讀取數(shù)據(jù)并處理該數(shù)據(jù)的函數(shù)）。功能內(nèi)聚（最

好）

7、功能內(nèi)聚是模塊的各個部分被一組是因為都貢獻(xiàn)給模塊的單獨的良好定義了的任

務(wù)（例如義元化一個XML的字串）。

內(nèi)聚級別名稱內(nèi)聚級別

巧合內(nèi)聚1

邏輯內(nèi)聚2

臨時內(nèi)聚3

過程內(nèi)聚4

通信內(nèi)聚5

順序內(nèi)聚6

功能內(nèi)聚7

盡管功能內(nèi)聚是系統(tǒng)結(jié)點所要追求的最高級別，但可能是不可達(dá)到的。在這種情況下，

通信內(nèi)聚往往是我們所能夠達(dá)到的最好級別。

5.2.3部件連接

軟件系統(tǒng)構(gòu)造中第三個一般步驟是部件連接，也就是使用一定的手段和工具將已經(jīng)具有

連接能力的部件連接起來，使得連接后的部件在總體上初步成為一個能夠完成需求所規(guī)定的

功能的完整系統(tǒng)。

部件在接連后與連接前存在本質(zhì)的區(qū)別。相互連接的部件之間存在一種特殊的信息交

換，雖然形式上可能有多變，并且這種連接的方式對系統(tǒng)作為整體運行的可靠，效率等各方

面有著根本的影響。所以部件連接是個需要審慎關(guān)注的主題。

耦合或者依賴就是一個用來研究部件連接的概念，它指每個模塊依賴于其它模塊的程

度。耦合通常與內(nèi)聚形成對比。低耦合經(jīng)常與高內(nèi)聚關(guān)聯(lián)，且反之亦然。低耦合是具有良好

結(jié)構(gòu)化計算機系統(tǒng)和良好設(shè)計一個跡象，當(dāng)與具有高內(nèi)聚的組合時，則大大的有利于達(dá)成高

可讀性和可維護(hù)性的目標(biāo)。

耦合是有大小的量，人們將耦合根據(jù)不同形式按找從大到小的順序做了如下劃分：

1、內(nèi)容耦合（高）一個模塊會修改或者依賴于另外一個模塊的內(nèi)部工作機制（交往

另外一個模塊的本地數(shù)據(jù)），因此改變第二個模塊的數(shù)據(jù)（位置，類型，時序）

就會導(dǎo)致要改變依賴模塊。

2、普通耦合兩個模塊共享相同的全域數(shù)據(jù)（例如一個全域變數(shù)），因此改變共享資源

就會暗含改變所有使用這個共享資源的模塊。

3、外露耦合兩個模塊共享一個外部施加的數(shù)據(jù)格式、通信協(xié)議、或者設(shè)計介面。

4、控制耦合一個模塊通過傳遞給另外一個模塊它要做什么事情的信息，例如傳遞一

個做什么的旗子，來控制另外一個模塊的流。

5、數(shù)據(jù)結(jié)構(gòu)耦合模塊共享一個組合的數(shù)據(jù)結(jié)構(gòu)并只使用它的一個部分，可能是一不

相同的部分（例如傳遞一個記錄給一個函數(shù)并只使用它的一個域）。這就可能導(dǎo)致

要改變一個模塊讀取一個記錄，只是因為這個模塊不需要的域已經(jīng)被修改過。

6、數(shù)據(jù)耦合模塊通過數(shù)據(jù)來進(jìn)行耦合，例如參數(shù)。每個數(shù)據(jù)是一個基本片塊，并且

這些是唯一的被共享數(shù)據(jù)（例如，傳遞一個整數(shù)給計算平方根的函數(shù)）。

7、消息耦合（低）這是最松弛的耦合類型，可以通過狀態(tài)分散（如在物體里面）來達(dá)

至IJ,而通信通過參數(shù)或者消息傳遞來完成。

8、無耦合兩個模塊之間不存在耦合。

耦合級別名稱耦合級別

無耦合0

消息耦合1

數(shù)據(jù)耦合2

數(shù)據(jù)結(jié)構(gòu)耦合3

控制耦合4

外露耦合5

普通耦合6

內(nèi)容耦合7

雖然耦合似乎是評價系統(tǒng)的一個反比例的量，也就是耦合量值越大，則系統(tǒng)越差。但是

事情總是存在另外一面，系統(tǒng)的低耦合在現(xiàn)實中的實現(xiàn)過程往往意味著更高的計算負(fù)荷以及

更低的性能。因為低耦合往往意味這存在以下幾方面的額外計算：

(1)消息創(chuàng)建；

(2)消息傳遞；

(3)消息翻譯；

(4)消息解釋。所以部件連接這一步驟的核心議題是耦合，但耦合需要折衷考慮。

5.2.4總體綜合

經(jīng)過概念抽象，結(jié)構(gòu)分解，部件連接這三個一般步驟，系統(tǒng)的構(gòu)造在概念上就己經(jīng)初具

雛形，這時我們應(yīng)該再進(jìn)行一個總體綜合的步驟來完善和調(diào)節(jié)系統(tǒng)的構(gòu)造，使得系統(tǒng)能夠在

一種最佳的整體配置參數(shù)下運行。

在這一階段，我們可以參照i般職責(zé)指派軟件原則來檢查已經(jīng)完成的系統(tǒng)構(gòu)造。--般

職責(zé)指派原則，縮寫為GRASP,由在物體-導(dǎo)向的設(shè)計中指定職責(zé)到類跟對象的

諸多要領(lǐng)構(gòu)成。GRASP中的這些要領(lǐng)包括：信息專家，創(chuàng)建者，控制者，低耦合，高內(nèi)聚，

多態(tài)，純編造，間接，有保護(hù)變動。事實上所有這些要領(lǐng)都回答了一些軟件問題，并且?guī)缀?/p>

在每種情況下這些問題在幾乎每個軟件開發(fā)項目中都是共有的。這些技術(shù)并非被發(fā)明來創(chuàng)建

新的工作方法，而只是對物體導(dǎo)向設(shè)計中老舊的，嘗試并測試過的編程原則進(jìn)行更好的歸檔

與標(biāo)準(zhǔn)化。

5.3總結(jié)

我們在這篇論文里從各個層面，各個領(lǐng)域?qū)浖到y(tǒng)的構(gòu)成做了許多分析，提出了我們

對軟件系統(tǒng)的認(rèn)識上的基本觀點。然后用此觀點重點考察了模式設(shè)計與軟件建筑的中的一些

著名實例，從此見證了軟件系統(tǒng)對結(jié)構(gòu)的基本要求和基本方法。

在第二章，我們了解到了我們所要研究的領(lǐng)域中的基本對象和他們的一般性質(zhì)，接下來

在第三