軟件體系結(jié)構(gòu)是構(gòu)建計算機軟件實踐的基礎(chǔ)。與建筑師設(shè)定建筑項目的設(shè)計原則和目標(biāo),作為繪圖員畫圖的基礎(chǔ)一樣,一個軟件架構(gòu)師或者系統(tǒng)架構(gòu)師陳述軟件構(gòu)架以作為滿足不同客戶需求的實際系統(tǒng)設(shè)計方案的基礎(chǔ)。
軟件構(gòu)架是一個容易理解的概念,多數(shù)工程師(尤其是經(jīng)驗不多的工程師)會從直覺上來認(rèn)識它,但要給出精確的定義很困難。特別是,很難明確地區(qū)分設(shè)計和構(gòu)架:構(gòu)架屬于設(shè)計的一方面,它集中于某些具體的特征。
在“軟件構(gòu)架簡介”中,David Garlan 和 Mary Shaw 認(rèn)為軟件構(gòu)架是有關(guān)如下問題的設(shè)計層次:“在計算的算法和數(shù)據(jù)結(jié)構(gòu)之外,設(shè)計并確定系統(tǒng)整體結(jié)構(gòu)成為了新的問題。結(jié)構(gòu)問題包括總體組織結(jié)構(gòu)和全局控制結(jié)構(gòu);通信、同步和數(shù)據(jù)訪問的協(xié)議;設(shè)計元素的功能分配;物理分布;設(shè)計元素的組成;定標(biāo)與性能;備選設(shè)計的選擇。”[GS93]
但構(gòu)架不僅是結(jié)構(gòu);IEEE Working Group on Architecture 把其定義為“系統(tǒng)在其環(huán)境中的最高層概念”[IEEE98]。構(gòu)架還包括“符合”系統(tǒng)完整性、經(jīng)濟約束條件、審美需求和樣式。它并不僅注重對內(nèi)部的考慮,而且還在系統(tǒng)的用戶環(huán)境和開發(fā)環(huán)境中對系統(tǒng)進行整體考慮,即同時注重對外部的考慮。
在 Rational Unified Process 中,軟件系統(tǒng)的構(gòu)架(在某一給定點)是指系統(tǒng)重要構(gòu)件的組織或結(jié)構(gòu),這些重要構(gòu)件通過接口與不斷減小的構(gòu)件與接口所組成的構(gòu)件進行交互。
從和目的、主題、材料和結(jié)構(gòu)的聯(lián)系上來說,軟件架構(gòu)可以和建筑物的架構(gòu)相比擬。一個軟件架構(gòu)師需要有廣泛的軟件理論知識和相應(yīng)的經(jīng)驗來事實和管理軟件產(chǎn)品的高級設(shè)計。軟件架構(gòu)師定義和設(shè)計軟件的模塊化,模塊之間的交互,用戶界面風(fēng)格,對外接口方法,創(chuàng)新的設(shè)計特性,以及高層事物的對象操作、邏輯和流程。
是一般而言,軟件系統(tǒng)的架構(gòu)(Architecture)有兩個要素:
·它是一個軟件系統(tǒng)從整體到部分的最高層次的劃分。
一個系統(tǒng)通常是由元件組成的,而這些元件如何形成、相互之間如何發(fā)生作用,則是關(guān)于這個系統(tǒng)本身結(jié)構(gòu)的重要信息。
詳細地說,就是要包括架構(gòu)元件(Architecture Component)、聯(lián)結(jié)器(Connector)、任務(wù)流(Task-flow)。所謂架構(gòu)元素,也就是組成系統(tǒng)的核心"磚瓦",而聯(lián)結(jié)器則描述這些元件之間通訊的路徑、通訊的機制、通訊的預(yù)期結(jié)果,任務(wù)流則描述系統(tǒng)如何使用這些元件和聯(lián)結(jié)器完成某一項需求。
·建造一個系統(tǒng)所作出的最高層次的、以后難以更改的,商業(yè)的和技術(shù)的決定。
在建造一個系統(tǒng)之前會有很多的重要決定需要事先作出,而一旦系統(tǒng)開始進行詳細設(shè)計甚至建造,這些決定就很難更改甚至無法更改。顯然,這樣的決定必定是有關(guān)系統(tǒng)設(shè)計成敗的最重要決定,必須經(jīng)過非常慎重的研究和考察。
歷史
早在1960年代,諸如E·W·戴克斯特拉就已經(jīng)涉及軟件架構(gòu)這個概念了。自1990年代以來,部分由于在 Rational Software Corporation 和Microsoft內(nèi)部的相關(guān)活動,軟件架構(gòu)這個概念開始越來越流行起來。
卡內(nèi)基梅隆大學(xué)和加州大學(xué)埃爾文分校在這個領(lǐng)域作了很多研究。卡內(nèi)基·梅隆大學(xué)的Mary Shaw和David Garlan于1996年寫了一本叫做 Software Architecture perspective on an emerging discipline的書,提出了軟件架構(gòu)中的很多概念,例如軟件組件、連接器、風(fēng)格等等。 加州大學(xué)埃爾文分校的軟件研究院所做的工作則主要集中于架構(gòu)風(fēng)格、架構(gòu)描述語言以及動態(tài)架構(gòu)。
計算機軟件的歷史開始于五十年代,歷史非常短暫,而相比之下建筑工程則從石器時代就開始了,人類在幾千年的建筑設(shè)計實踐中積累了大量的經(jīng)驗和教訓(xùn)。建筑設(shè)計基本上包含兩點,一是建筑風(fēng)格,二是建筑模式。獨特的建筑風(fēng)格和恰當(dāng)選擇的建筑模式,可以使一個獨一無二。
下面的照片顯示了中美洲古代瑪雅建筑,Chichen-Itza大金字塔,九個巨大的石級堆壘而上,九十一級臺階(象征著四季的天數(shù))奪路而出,塔頂?shù)纳竦盥柸朐铺臁K械臄?shù)字都如日歷般嚴(yán)謹(jǐn),風(fēng)格雄渾。難以想象這是石器時代的建筑物。
圖1、位于墨西哥Chichen-Itza(在瑪雅語中chi意為嘴chen意為井)的古瑪雅建筑。(攝影:作者)
軟件與人類的關(guān)系是架構(gòu)師必須面對的核心問題,也是自從軟件進入歷史舞臺之后就出現(xiàn)的問題。與此類似地,自從有了建筑以來,建筑與人類的關(guān)系就一直是建筑設(shè)計師必須面對的核心問題。英國首相丘吉爾說,我們構(gòu)造建筑物,然后建筑物構(gòu)造我們(We shape our buildings, and afterwards our buildings shape us)。英國下議院的會議廳較狹窄,無法使所有的下議院議員面向同一個方向入座,而必須分成兩側(cè)入座。丘吉爾認(rèn)為,議員們?nèi)胱臅r候自然會選擇與自己政見相同的人同時入座,而這就是英國政黨制的起源。Party這個詞的原意就是"方"、"面"。政黨起源的關(guān)鍵就是建筑物對人的影響。
在軟件設(shè)計界曾經(jīng)有很多人認(rèn)為功能是最為重要的,形式必須服從功能。與此類似地,在建筑學(xué)界,現(xiàn)代主義建筑流派的開創(chuàng)人之一Louis Sullivan也認(rèn)為形式應(yīng)當(dāng)服從于功能(Forms follows function)。
幾乎所有的軟件設(shè)計理念都可以在浩如煙海的建筑學(xué)歷史中找到更為遙遠的歷史回響。最為著名的,當(dāng)然就是模式理論和XP理論。
架構(gòu)的目標(biāo)是什么
正如同軟件本身有其要達到的目標(biāo)一樣,架構(gòu)設(shè)計要達到的目標(biāo)是什么呢?一般而言,軟件架構(gòu)設(shè)計要達到如下的目標(biāo):
·可靠性(Reliable)。軟件系統(tǒng)對于用戶的商業(yè)經(jīng)營和管理來說極為重要,因此軟件系統(tǒng)必須非常可靠。
·安全行(Secure)。軟件系統(tǒng)所承擔(dān)的交易的商業(yè)價值極高,系統(tǒng)的安全性非常重要。
·可擴展性(Scalable)。軟件必須能夠在用戶的使用率、用戶的數(shù)目增加很快的情況下,保持合理的性能。只有這樣,才能適應(yīng)用戶的市場擴展得可能性。
·可定制化(Customizable)。同樣的一套軟件,可以根據(jù)客戶群的不同和市場需求的變化進行調(diào)整。
·可擴展性(Extensible)。在新技術(shù)出現(xiàn)的時候,一個軟件系統(tǒng)應(yīng)當(dāng)允許導(dǎo)入新技術(shù),從而對現(xiàn)有系統(tǒng)進行功能和性能的擴展
·可維護性(Maintainable)。軟件系統(tǒng)的維護包括兩方面,一是排除現(xiàn)有的錯誤,二是將新的軟件需求反映到現(xiàn)有系統(tǒng)中去。一個易于維護的系統(tǒng)可以有效地降低技術(shù)支持的花費
·客戶體驗(Customer Experience)。軟件系統(tǒng)必須易于使用。
·市場時機(Time to Market)。軟件用戶要面臨同業(yè)競爭,軟件提供商也要面臨同業(yè)競爭。以最快的速度爭奪市場先機非常重要。
架構(gòu)的種類
根據(jù)我們關(guān)注的角度不同,可以將架構(gòu)分成三種:
·邏輯架構(gòu)、軟件系統(tǒng)中元件之間的關(guān)系,比如用戶界面,數(shù)據(jù)庫,外部系統(tǒng)接口,商業(yè)邏輯元件,等等。
比如下面就是筆者親身經(jīng)歷過的一個軟件系統(tǒng)的邏輯架構(gòu)圖
圖2、一個邏輯架構(gòu)的例子
從上面這張圖中可以看出,此系統(tǒng)被劃分成三個邏輯層次,即表象層次,商業(yè)層次和數(shù)據(jù)持久層次。每一個層次都含有多個邏輯元件。比如WEB服務(wù)器層次中有HTML服務(wù)元件、Session服務(wù)元件、安全服務(wù)元件、系統(tǒng)管理元件等。
·物理架構(gòu)、軟件元件是怎樣放到硬件上的。
比如下面這張物理架構(gòu)圖描述了一個分布于北京和上海的分布式系統(tǒng)的物理架構(gòu),圖中所有的元件都是物理設(shè)備,包括網(wǎng)絡(luò)分流器、代理服務(wù)器、WEB服務(wù)器、應(yīng)用服務(wù)器、報表服務(wù)器、整合服務(wù)器、存儲服務(wù)器、主機等等。
圖3、一個物理架構(gòu)的例子
·系統(tǒng)架構(gòu)、系統(tǒng)的非功能性特征,如可擴展性、可靠性、強壯性、靈活性、性能等。
系統(tǒng)架構(gòu)的設(shè)計要求架構(gòu)師具備軟件和硬件的功能和性能的過硬知識,這一工作無疑是架構(gòu)設(shè)計工作中最為困難的工作。
此外,從每一個角度上看,都可以看到架構(gòu)的兩要素:元件劃分和設(shè)計決定。
首先,一個軟件系統(tǒng)中的元件首先是邏輯元件。這些邏輯元件如何放到硬件上,以及這些元件如何為整個系統(tǒng)的可擴展性、可靠性、強壯性、靈活性、性能等做出貢獻,是非常重要的信息。
其次,進行軟件設(shè)計需要做出的決定中,必然會包括邏輯結(jié)構(gòu)、物理結(jié)構(gòu),以及它們?nèi)绾斡绊懙较到y(tǒng)的所有非功能性特征。這些決定中會有很多是一旦作出,就很難更改的。
根據(jù)作者的經(jīng)驗,一個基于數(shù)據(jù)庫的系統(tǒng)架構(gòu),有多少個數(shù)據(jù)表,就會有多少頁的架構(gòu)設(shè)計文檔。比如一個中等的數(shù)據(jù)庫應(yīng)用系統(tǒng)通常含有一百個左右的數(shù)據(jù)表,這樣的一個系統(tǒng)設(shè)計通常需要有一百頁左右的架構(gòu)設(shè)計文檔。
構(gòu)架描述
為了討論和分析軟件構(gòu)架,必須首先定義構(gòu)架表示方式,即描述構(gòu)架重要方面的方式。在 Rational Unified Process 中,軟件構(gòu)架文檔記錄有這種描述。
構(gòu)架視圖
我們決定以多種構(gòu)架視圖來表示軟件構(gòu)架。每種構(gòu)架視圖針對于開發(fā)流程中的涉眾(例如最終用戶、設(shè)計人員、管理人員、系統(tǒng)工程師、維護人員等)所關(guān)注的特定方面。
構(gòu)架視圖顯示了軟件構(gòu)架如何分解為構(gòu)件,以及構(gòu)件如何由連接器連接來產(chǎn)生有用的形式 [PW92],由此記錄主要的結(jié)構(gòu)設(shè)計決策。這些設(shè)計決策必須基于需求以及功能、補充和其他方面的約束。而這些決策又會在較低層次上為需求和將來的設(shè)計決策施加進一步的約束。
典型的構(gòu)架視圖集
構(gòu)架由許多不同的構(gòu)架視圖來表示,這些視圖本質(zhì)上是以圖形方式來摘要說明“在構(gòu)架方面具有重要意義”的模型元素。在 Rational Unified Process 中,您將從一個典型的視圖集開始,該視圖集稱為“4+1 視圖模型”[KRU95]。它包括:
用例視圖:包括用例和場景,這些用例和場景包括在構(gòu)架方面具有重要意義的行為、類或技術(shù)風(fēng)險。它是用例模型的子集。
邏輯視圖:包括最重要的設(shè)計類、從這些設(shè)計類到包和子系統(tǒng)的組織形式,以及從這些包和子系統(tǒng)到層的組織形式。它還包括一些用例實現(xiàn)。它是設(shè)計模型的子集。
實施視圖:包括實施模型及其從模塊到包和層的組織形式的概覽。 同時還描述了將邏輯視圖中的包和類向?qū)嵤┮晥D中的包和模塊分配的情況。它是實施模型的子集。
進程視圖:包括所涉及任務(wù)(進程和線程)的描述,它們的交互和配置,以及將設(shè)計對象和類向任務(wù)的分配情況。只有在系統(tǒng)具有很高程度的并行時,才需要該視圖。在 Rational Unified Process 中,它是設(shè)計模型的子集。
配置視圖:包括對最典型的平臺配置的各種物理節(jié)點的描述以及將任務(wù)(來自進程視圖)向物理節(jié)點分配的情況。只有在分布式系統(tǒng)中才需要該視圖。它是部署模型的一個子集。
構(gòu)架視圖記錄在軟件構(gòu)架文檔中。您可以構(gòu)建其他視圖來表達需要特別關(guān)注的不同方面:用戶界面視圖、安全視圖、數(shù)據(jù)視圖等等。對于簡單系統(tǒng),可以省略 4+1 視圖模型中的一些視圖。
構(gòu)架重點
雖然以上視圖可以表示系統(tǒng)的整體設(shè)計,但構(gòu)架只同以下幾個具體方面相關(guān):
模型的結(jié)構(gòu),即組織模式,例如分層。
基本元素,即關(guān)鍵用例、主類、常用機制等,它們與模型中的各元素相對。
幾個關(guān)鍵場景,它們表示了整個系統(tǒng)的主要控制流程。
記錄模塊度、可選特征、產(chǎn)品線狀況的服務(wù)。
構(gòu)架視圖在本質(zhì)上是整體設(shè)計的抽象或簡化,它們通過舍棄具體細節(jié)來突出重要的特征。在考慮以下方面時,這些特征非常重要:
系統(tǒng)演進,即進入下一個開發(fā)周期。
在產(chǎn)品線環(huán)境下復(fù)用構(gòu)架或構(gòu)架的一部分。
評估補充質(zhì)量,例如性能、可用性、可移植性和安全性。
向團隊或分包商分配開發(fā)工作。
決定是否包括市售構(gòu)件。
插入范圍更廣的系統(tǒng)。
構(gòu)架模式
構(gòu)架模式是解決復(fù)發(fā)構(gòu)架問題的現(xiàn)成形式。構(gòu)架框架或構(gòu)架基礎(chǔ)設(shè)施(中間件)是可以在其上構(gòu)建某種構(gòu)架的構(gòu)件集。許多主要的構(gòu)架困難應(yīng)在框架或基礎(chǔ)設(shè)施中進行解決,而且通常針對于特定的領(lǐng)域:命令和控制、MIS、控制系統(tǒng)等等。
構(gòu)架模式示例
[BUS96] 根據(jù)構(gòu)架模式最適用的系統(tǒng)的特征將其分類,其中一個類別處理更普遍的結(jié)構(gòu)問題。下表顯示了 [BUS96] 中所提供的類別和這些類別所包含的模式。
類別 | 模式 |
結(jié)構(gòu) | 層 |
管道和過濾器 | |
黑板 | |
分布式系統(tǒng) | 代理 |
交互系統(tǒng) | 模型-視圖-控制器 |
表示-抽象-控制 | |
自適應(yīng)系統(tǒng) | 反射 |
微核 |
軟件構(gòu)架是一個容易理解的概念,多數(shù)工程師(尤其是經(jīng)驗不多的工程師)會從直覺上來認(rèn)識它,但要給出精確的定義很困難。特別是,很難明確地區(qū)分設(shè)計和構(gòu)架:構(gòu)架屬于設(shè)計的一方面,它集中于某些具體的特征。
在“軟件構(gòu)架簡介”中,David Garlan 和 Mary Shaw 認(rèn)為軟件構(gòu)架是有關(guān)如下問題的設(shè)計層次:“在計算的算法和數(shù)據(jù)結(jié)構(gòu)之外,設(shè)計并確定系統(tǒng)整體結(jié)構(gòu)成為了新的問題。結(jié)構(gòu)問題包括總體組織結(jié)構(gòu)和全局控制結(jié)構(gòu);通信、同步和數(shù)據(jù)訪問的協(xié)議;設(shè)計元素的功能分配;物理分布;設(shè)計元素的組成;定標(biāo)與性能;備選設(shè)計的選擇。”[GS93]
但構(gòu)架不僅是結(jié)構(gòu);IEEE Working Group on Architecture 把其定義為“系統(tǒng)在其環(huán)境中的最高層概念”[IEEE98]。構(gòu)架還包括“符合”系統(tǒng)完整性、經(jīng)濟約束條件、審美需求和樣式。它并不僅注重對內(nèi)部的考慮,而且還在系統(tǒng)的用戶環(huán)境和開發(fā)環(huán)境中對系統(tǒng)進行整體考慮,即同時注重對外部的考慮。
在 Rational Unified Process 中,軟件系統(tǒng)的構(gòu)架(在某一給定點)是指系統(tǒng)重要構(gòu)件的組織或結(jié)構(gòu),這些重要構(gòu)件通過接口與不斷減小的構(gòu)件與接口所組成的構(gòu)件進行交互。
為闡明其含義,下面將詳述其中的兩個;完整說明請參見 [BUS96]。模式以下列廣泛使用的形式來表示:
模式名
環(huán)境
問題
影響,描述應(yīng)考慮的不同問題方面
解決方案
基本原理
結(jié)果環(huán)境
示例
模式名
層
環(huán)境
需要進行結(jié)構(gòu)分解的大系統(tǒng)。
問題
必須處理不同抽象層次的問題的系統(tǒng)。例如:硬件控制問題、常見服務(wù)問題和針對于不同領(lǐng)域的問題。最好不要編寫垂直構(gòu)件來處理所有抽象層次的問題。否則要在不同的構(gòu)件中多次處理相同的問題(可能會不一致)。
影響
系統(tǒng)的某些部分應(yīng)當(dāng)是可替換的
構(gòu)件中的變化不應(yīng)波動
相似的責(zé)任應(yīng)歸為一組
構(gòu)件大小 -- 復(fù)雜構(gòu)件可能要進行分解
解決辦法
將系統(tǒng)分成構(gòu)件組,并使構(gòu)件組形成層疊結(jié)構(gòu)。使上層只使用下層(決不使用上層)提供的服務(wù)。盡量不使用非緊鄰下層提供的服務(wù)(不跳層使用服務(wù),除非中間層只添加通過構(gòu)件)。
示例:
1. 通用層
嚴(yán)格的分層構(gòu)架規(guī)定設(shè)計元素(類、構(gòu)件、包、子系統(tǒng))只能使用下層提供的服務(wù), 服務(wù)可以包括事件處理、錯誤處理、數(shù)據(jù)庫訪問等等。 相對于記錄在底層的原始操作系統(tǒng)級調(diào)用,它包括更明顯的機制。
2. 業(yè)務(wù)系統(tǒng)層
上圖顯示了另一個分層示例,其中有垂直特定應(yīng)用層、水平層和基礎(chǔ)設(shè)施層。注意:此處的目標(biāo)是采用非常短的業(yè)務(wù)“煙囪”并實現(xiàn)各種應(yīng)用程序間的通用性。 否則,就可能有多個人解決同一問題,從而導(dǎo)致潛在的分歧。
有關(guān)該模式的深入討論,請參見指南:分層。
模式名
黑板
環(huán)境
沒有解決問題的確定方法(算法)或方法不可行的領(lǐng)域。例如 AI 系統(tǒng)、語音識別和監(jiān)視系統(tǒng)。
問題
多個問題解決顧問(知識顧問)必須通過協(xié)作來解決他們無法單獨解決的問題。各顧問的工作結(jié)果必須可以供所有其他顧問訪問,使他們可以評估自己是否可以參與解決方案的查找并發(fā)布其工作結(jié)果。
影響
知識顧問參與解決問題的順序不是確定的,這可能取決于問題解決策略
不同顧問的輸入(結(jié)果或部分解決方案)可能有不同的表示方式
各顧問并不直接知道對方的存在,但可以評估對方發(fā)布的工作
解決辦法
多名知識顧問都可訪問一個稱為“黑板”的共享數(shù)據(jù)庫。黑板提供監(jiān)測和更新其內(nèi)容的接口。控制模塊/對象激活遵循某種策略的顧問。激活后,顧問查看黑板,以確定它是否能參與解決問題。如果顧問決定它可以參與,控制對象就可以允許顧問將其部分(或最終)解決方案放置于黑板上。
示例:
以上顯示了使用 UML 建模的結(jié)構(gòu)或靜態(tài)視圖。 它將成為參數(shù)化協(xié)作的一部分,然后會綁定到實參上對模式進行實例化。
構(gòu)架風(fēng)格
軟件構(gòu)架(或僅是構(gòu)架視圖)可以具有名為構(gòu)架風(fēng)格的屬性,該屬性減少了可選的形式,并使構(gòu)架具有一定程度的一致性。樣式可以通過一組模式或通過選擇特定構(gòu)件或連接器作為基本構(gòu)件來定義。對給定系統(tǒng),某些樣式可作為構(gòu)架描述的一部分記錄在構(gòu)架風(fēng)格指南(Rational Unified Process 中設(shè)計指南文檔的一部分)中。樣式在構(gòu)架的可理解性與完整性方面起著主要的作用。
構(gòu)架設(shè)計圖
構(gòu)架視圖的圖形描述稱為構(gòu)架設(shè)計圖。對于以上描述的各種視圖,設(shè)計圖由以下統(tǒng)一建模語言圖組成 [UML99]:
邏輯視圖:類圖、狀態(tài)機和對象圖。
進程視圖:類圖與對象圖(包括任務(wù) - 進程與線程)。
實施視圖:構(gòu)件圖。
部署視圖:配置圖。
用例視圖:用例圖描述用例、主角和普通設(shè)計類;順序圖描述設(shè)計對象及其協(xié)作關(guān)系。
構(gòu)架設(shè)計流程
在 Rational Unified Process 中,構(gòu)架主要是分析設(shè)計工作流程的結(jié)果。當(dāng)項目再次進行此工作流程時,構(gòu)架將在一次又一次迭代中不斷演化、改進、精煉。由于每次迭代都包括集成和測試,所以在交付產(chǎn)品時,構(gòu)架就相當(dāng)強壯了。構(gòu)架是精化階段各次迭代的重點,構(gòu)架的基線通常會在此階段結(jié)束時確定。
架構(gòu)師
軟體設(shè)計師中有一些技術(shù)水平較高、經(jīng)驗較為豐富的人,他們需要承擔(dān)軟件系統(tǒng)的架構(gòu)設(shè)計,也就是需要設(shè)計系統(tǒng)的元件如何劃分、元件之間如何發(fā)生相互作用,以及系統(tǒng)中邏輯的、物理的、系統(tǒng)的重要決定的作出。
這樣的人就是所謂的架構(gòu)師(Architect)。在很多公司中,架構(gòu)師不是一個專門的和正式的職務(wù)。通常在一個開發(fā)小組中,最有經(jīng)驗的程序員會負責(zé)一些架構(gòu)方面的工作。在一個部門中,最有經(jīng)驗的項目經(jīng)理會負責(zé)一些架構(gòu)方面的工作。
但是,越來越多的公司體認(rèn)到架構(gòu)工作的重要性,并且在不同的組織層次上設(shè)置專門的架構(gòu)師位置,由他們負責(zé)不同層次上的邏輯架構(gòu)、物理架構(gòu)、系統(tǒng)架構(gòu)的設(shè)計、配置、維護等工作。
jwebee
我的個人網(wǎng)站