架構(gòu)師的職責(zé)及工作描述

1、架構(gòu)師的職責(zé)及工作描述什么叫架構(gòu)師系統(tǒng)分析員屬于Analyst角色組合，與其相比，架構(gòu)師則是屬于Developer角色組里的 一個(gè)角色，一個(gè)非常重要的角色。架構(gòu)師的職責(zé)及工作描述The software architect role is responsible for the software architecture, which includes the key technical decisions that constrain the overall design and implementation for the project.負(fù)責(zé)在整個(gè)項(xiàng)目中對(duì)技術(shù)活動(dòng)和工件進(jìn)行領(lǐng)導(dǎo)和協(xié)調(diào)。構(gòu)

2、架設(shè)計(jì)師要確立每個(gè)構(gòu)架視圖的整 體結(jié)構(gòu)：視圖的詳細(xì)組織結(jié)構(gòu)、元素的分組以及這些主要分組之間的接口。因此，與其他角 色相比，構(gòu)架設(shè)計(jì)師的見解重在廣度，而不是深度。架構(gòu)師負(fù)責(zé)理解系統(tǒng)的業(yè)務(wù)需求，并創(chuàng)建合理、完善的系統(tǒng)體系架構(gòu)。架構(gòu)師也負(fù)責(zé)通過 軟件架構(gòu)來決定主要的技術(shù)選擇。這典型的包括識(shí)別和文檔化系統(tǒng)的重要架構(gòu)方面，包括系 統(tǒng)的需求、設(shè)計(jì)、實(shí)現(xiàn)和部署視圖。The software architect has overall responsibility for driving the major technical decisions, expressed as the software arch

3、itecture. This typically includes identifying and documenting the architecturally significant aspects of the system, including requirements, design, implementation, and deployment views of the system.The architect is also responsible for providing rationale for these decisions, balancing the concern

4、s of the various stakeholders,:注：這就是說架構(gòu)師要在大家意見不統(tǒng)一的時(shí)候給出一個(gè)基本的并且這些人都比較能接受 的基本意見，這就是要求架構(gòu)師要有一定的判斷力和決定能力以及體現(xiàn)核心作用、核心力量 和支柱的這樣一種領(lǐng)導(dǎo)力。driving down technical risks, and ensuring that decisions are effectively communicated, validated, and adhered to.:注：架構(gòu)師一定要具備降低風(fēng)險(xiǎn)（當(dāng)然主要是技術(shù)方面）的能力，以及他的這種架構(gòu)思 想切實(shí)得到貫徹和落實(shí)的能力。建模軟件應(yīng)用和方

5、案，并創(chuàng)建和管理可重用的模式和模型；維護(hù)在我們的軟件系統(tǒng)中的系統(tǒng) 組件和他們的接口。建模信息架構(gòu)，創(chuàng)建和維護(hù)組織技術(shù)設(shè)施的布局，并提供滿足業(yè)務(wù)需求的技術(shù)觀點(diǎn)和遠(yuǎn)景。 架構(gòu)師的技能要求和能力素養(yǎng)In summary, the software architect must be well-rounded, posses maturity, vision, and a depth of experience that allows for grasping issues quickly and making educated, critical judgment in the absence of

6、 complete information. More specifically, the software architect, or members of the architecture team, must combine these skills:構(gòu)架設(shè)計(jì)師必須多才多藝、成熟練達(dá)、洞察力強(qiáng)、經(jīng)驗(yàn)豐富。這樣，他才能在無法獲得完整 信息的情況下迅速領(lǐng)會(huì)問題并根據(jù)經(jīng)驗(yàn)作出審慎的判斷。更準(zhǔn)確地說，構(gòu)架設(shè)計(jì)師（或者構(gòu) 架團(tuán)隊(duì)的成員）必須兼具以下技能：Experience in both the problem domain, through a thorough understanding o

7、f the requirements, and the software engineering domain. If there is a team, these qualities can be spread across the team members, but at least one software architect must provide the global vision for the project.-經(jīng)驗(yàn)：既包括在問題領(lǐng)域的經(jīng)驗(yàn)（通過徹底了解需求），也包 括在軟件工程領(lǐng)域的經(jīng)驗(yàn)。對(duì)于一個(gè)構(gòu)架團(tuán)隊(duì)，這些素質(zhì)要求可由各團(tuán)隊(duì)成員來分別承擔(dān)， 但其中至少要有一名構(gòu)架設(shè)計(jì)師能

8、夠把握項(xiàng)目的全局。Leadership in order to drive the technical effort across the various teams, and to make critical decisions under pressure and make those decisions stick. To be effective, the software architect and the project manager must work closely together, with the software architect leading the techn

9、ical issues and the project manager leading the administrative issues. The software architect must have the authority to make technical decisions.-領(lǐng)導(dǎo) 才能：能夠推動(dòng)各個(gè)團(tuán)隊(duì)的技術(shù)進(jìn)展，并能在壓力下作出關(guān)鍵性的決策然后將其貫徹到底。 要提高效率，構(gòu)架設(shè)計(jì)師和項(xiàng)目經(jīng)理必須緊密協(xié)作。構(gòu)架設(shè)計(jì)師主要負(fù)責(zé)解決技術(shù)問題，項(xiàng) 目經(jīng)理主要負(fù)責(zé)解決行政管理問題。構(gòu)架設(shè)計(jì)師必須有權(quán)在技術(shù)問題上作出決定。Communication to earn trust, to

10、persuade, to motivate, and to mentor. The software architect cannot lead by decree, only by the consent of the rest of the project. In order to be effective, the software architect must earn the respect of the project team, the project manager, the customer, and the user community, as well as the ma

11、nagement team.-溝 通：能夠贏得他人的信任，以對(duì)其進(jìn)行說服、激勵(lì)和指導(dǎo)。構(gòu)架設(shè)計(jì)師不能靠命令進(jìn)行領(lǐng)導(dǎo)， 而必須要贏得項(xiàng)目中其他人員的贊同。為了提高效率，構(gòu)架設(shè)計(jì)師必須贏得項(xiàng)目團(tuán)隊(duì)、項(xiàng)目 經(jīng)理、客戶、用戶群體以及管理團(tuán)隊(duì)的尊敬。Goal-orientation and Pro-activity with a relentless focus on results. The software architect is the technical driving force behind the project, not a visionary or dreamer. The care

12、er of a successful software architect is a long series of sub-optimal decisions made in uncertainty and under pressure. Only those who can focus on doing what needs to be done will be successful in this environment of the project.-以目標(biāo)為中心、積極主動(dòng)，不懈 地追求成效。構(gòu)架設(shè)計(jì)師是推動(dòng)項(xiàng)目發(fā)展的技術(shù)動(dòng)力，而不是空想家。在其職業(yè)生涯中，成 功的構(gòu)架設(shè)計(jì)師一直都要在捉

13、摸不定和承受壓力的情況下作出折衷決定。構(gòu)架設(shè)計(jì)師只有將 注意力集中在該做的事情上，才能在項(xiàng)目中取得成功。從專業(yè)角度看，構(gòu)架設(shè)計(jì)師必須具備系統(tǒng)設(shè)計(jì)員（designer）的所有能力。但是：However, unlike the designer, the software architect:tends to be a generalist rather than a specialist, knowing many technologies at a high level rather than a few technologies at the detail levelmakes broade

14、r technical decisions, and therefore broad knowlege and experience, as well as communication and leadership skills, are key.注：此處兩點(diǎn)，一語道破架構(gòu)師和設(shè)計(jì)師的本職區(qū)別。請(qǐng)認(rèn)真體會(huì)，側(cè)重點(diǎn)是不同的。 架構(gòu)師應(yīng)該能夠：理解企業(yè)應(yīng)用的體系結(jié)構(gòu)，能夠?qū)Ψ植际狡髽I(yè)應(yīng)用系統(tǒng)體系結(jié)構(gòu)、面 向服務(wù)的應(yīng)用系統(tǒng)體系結(jié)構(gòu)的設(shè)計(jì)要點(diǎn)給出指導(dǎo)性建議的。團(tuán)隊(duì)里架構(gòu)師配備的方法和指導(dǎo)原則If the project is large enough to warrant an architectur

15、e team, the goal is to have a good mix of talents, covering a wide spectrum of experience and sharing a common understanding of software engineering process. The architecture team need not be a committee of representatives from various teams, domains or contractors. Software architecture is a full-t

16、ime function, with staff permanently dedicated to it.如果項(xiàng)目較大，需要組建一個(gè)構(gòu)架團(tuán)隊(duì)，則應(yīng)盡量廣聚賢才，使該團(tuán)隊(duì)既擁有廣泛的經(jīng)驗(yàn)， 又對(duì)軟件工程流程具有一致的認(rèn)識(shí)。構(gòu)架團(tuán)隊(duì)不應(yīng)該是由各團(tuán)隊(duì)、領(lǐng)域或承包商的代表組成 的委員會(huì)。軟件構(gòu)架設(shè)計(jì)是一項(xiàng)長(zhǎng)期的工作，始終都需要配備專職人員。For smaller projects, a single person may act as both project manager and software architect. However, if at all possible, it is bett

17、er to have these roles performed by separate people, in order to ensure that time pressure on one role doesnt cause the other role to be neglected.注：小型項(xiàng)目架構(gòu)師可以兼做項(xiàng)目經(jīng)理。但是不要因?yàn)闀r(shí)間安排問題導(dǎo)致兩種角色互有影 響。架構(gòu)師需要對(duì)此有很好的調(diào)節(jié)能力和全局安排、協(xié)調(diào)處理、解決能力。軟件架構(gòu)模型（4+1） 架構(gòu)模型軟件架構(gòu)用來處理軟件高層次結(jié)構(gòu)的設(shè)計(jì)和實(shí)施。它以精心選擇的形式將若干結(jié)構(gòu)元素進(jìn) 行裝配，從而滿足系統(tǒng)主要功能和性能需求，并滿足其

18、他非功能性需求，如可靠性、可伸縮 性、可移植性和可用性。Perry和Wolfe使用一個(gè)精確的公式來表達(dá)，該公式由Boehm 做了進(jìn)一步修改：軟件架構(gòu)=元素，形式，關(guān)系/約束軟件架構(gòu)涉及到抽象、分解和組合、風(fēng)格和美學(xué)。我們用由多個(gè)視圖或視角組成的模型來描 述它。為了最終處理大型的、富有挑戰(zhàn)性的架構(gòu)，該模型包含五個(gè)主要的視圖(請(qǐng)對(duì)照?qǐng)D1): 邏輯視圖(Logical View)，設(shè)計(jì)的對(duì)象模型(使用面向?qū)ο蟮脑O(shè)計(jì)方法時(shí))。過程視圖(Process View)，捕捉設(shè)計(jì)的并發(fā)和同步特征。物理視圖(Physical View)，描述了軟件到硬件的映射，反映了分布式特性。開發(fā)視圖(Development

19、 View)，描述了在開發(fā)環(huán)境中軟件的靜態(tài)組織結(jié)構(gòu)。架構(gòu)的描述，即所做的各種決定，可以圍繞著這四個(gè)視圖來組織，然后由一些用例(use cases)或場(chǎng)景(scenarios)來說明，從而形成了第五個(gè)視圖。正如將看到的，實(shí)際上軟件架 構(gòu)部分從這些場(chǎng)景演進(jìn)而來，將在下文中討論。圖1 4+1視圖模型注：請(qǐng)?zhí)貏e留意這四個(gè)view的各自主要使用對(duì)象。比如Development View，主要是 programmers看到的系統(tǒng)架構(gòu)圖。我們?cè)诿總€(gè)視圖上均獨(dú)立地應(yīng)用Perry & Wolf的公式，即定義一個(gè)所使用的元素集合(組 件、容器、連接符)，捕獲工作形式和模式，并且捕獲關(guān)系及約束，將架構(gòu)與某些需求連接

20、 起來。每種視圖使用自身所特有的表示法一藍(lán)圖(blueprint)來描述，并且架構(gòu)師可以對(duì) 每種視圖選用特定的架構(gòu)風(fēng)格(architectural style)，從而允許系統(tǒng)中多種風(fēng)格并存。我們將輪流的觀察這五種視圖，展現(xiàn)各個(gè)視圖的目標(biāo)：即視圖的所關(guān)注的問題，相應(yīng)的架 構(gòu)藍(lán)圖的標(biāo)記方式，描述和管理藍(lán)圖的工具。并以非常簡(jiǎn)單的形式。4+1”視圖模型具有相 當(dāng)?shù)摹逼毡樾浴保虼丝梢允褂闷渌臉?biāo)注方法和工具，也可以采用其他的設(shè)計(jì)方法，特別是 對(duì)于邏輯和過程的分解。但文中指出的這些方法都已經(jīng)成功的在實(shí)踐中運(yùn)用過。邏輯結(jié)構(gòu)一面向?qū)ο蟮姆纸膺壿嫾軜?gòu)主要支持功能性需求一一即在為用戶提供服務(wù)方面系統(tǒng)所應(yīng)該提供的

21、功能。系統(tǒng) 分解為一系列的關(guān)鍵抽象，(大多數(shù))來自于問題域，表現(xiàn)為對(duì)象或?qū)ο箢惖男问健Ｋ鼈?采用抽象、封裝和繼承的原理。分解并不僅僅是為了功能分析，而且用來識(shí)別遍布系統(tǒng)各個(gè) 部分的通用機(jī)制和設(shè)計(jì)元素。進(jìn)程架構(gòu)一過程分解進(jìn)程架構(gòu)考慮一些非功能性的需求，如性能和可用性。它解決并發(fā)性、分布性、系統(tǒng)完整性、 容錯(cuò)性的問題，以及邏輯視圖的主要抽象如何與進(jìn)程結(jié)構(gòu)相配合在一起一即在哪個(gè)控制線程 上，對(duì)象的操作被實(shí)際執(zhí)行。進(jìn)程架構(gòu)可以在幾種層次的抽象上進(jìn)行描述，每個(gè)層次針對(duì)不同的問題。在最高的層次上， 進(jìn)程架構(gòu)可以視為一組獨(dú)立執(zhí)行的通信程序(叫作processes)的邏輯網(wǎng)絡(luò)，它們分布在 整個(gè)一組硬件資源上，

22、這些資源通過LAN或者WAN連接起來。多個(gè)邏輯網(wǎng)絡(luò)可能同時(shí) 并存，共享相同的物理資源。例如，獨(dú)立的邏輯網(wǎng)絡(luò)可能用于支持離線系統(tǒng)與在線系統(tǒng)的分 離，或者支持軟件的模擬版本和測(cè)試版本的共存。進(jìn)程是構(gòu)成可執(zhí)行單元任務(wù)的分組。進(jìn)程代表了可以進(jìn)行策略控制過程架構(gòu)的層次（即：開 始、恢復(fù)、重新配置及關(guān)閉）。另外，進(jìn)程可以就處理負(fù)載的分布式增強(qiáng)或可用性的提高而 不斷地被重復(fù)。軟件被劃分為一系列單獨(dú)的任務(wù)。任務(wù)是獨(dú)立的控制線程，可以在處理節(jié)點(diǎn)上單獨(dú)地被調(diào)度。開發(fā)架構(gòu)一子系統(tǒng)分解開發(fā)架構(gòu)關(guān)注軟件開發(fā)環(huán)境下實(shí)際模塊的組織。軟件打包成小的程序塊（程序庫或子系統(tǒng)）， 它們可以由一位或幾位開發(fā)人員來開發(fā)。子系統(tǒng)可以組織

23、成分層結(jié)構(gòu)，每個(gè)層為上一層提供 良好定義的接口。系統(tǒng)的開發(fā)架構(gòu)用模塊和子系統(tǒng)圖來表達(dá)，顯示了輸出和輸入關(guān)系。完整的開發(fā)架構(gòu)只 有當(dāng)所有軟件元素被識(shí)別后才能加以描述。但是，可以列出控制開發(fā)架構(gòu)的規(guī)則：分塊、分 組和可見性。大部分情況下，開發(fā)架構(gòu)考慮的內(nèi)部需求與以下幾項(xiàng)因素有關(guān)：開發(fā)難度、軟件管理、重用 性和通用性及由工具集、編程語言所帶來的限制。開發(fā)架構(gòu)視圖是各種活動(dòng)的基礎(chǔ)，如： 需求分配、團(tuán)隊(duì)工作的分配（或團(tuán)隊(duì)機(jī)構(gòu)）、成本評(píng)估和計(jì)劃、項(xiàng)目進(jìn)度的監(jiān)控、軟件重用 性、移植性和安全性。它是建立產(chǎn)品線的基礎(chǔ)。物理架構(gòu)一軟件至硬件的映射物 理架構(gòu)主要關(guān)注系統(tǒng)非功能性的需求，如可用性、可靠性（容錯(cuò)性），性

24、能（吞吐量） 和可伸縮性。軟件在計(jì)算機(jī)網(wǎng)絡(luò)或處理節(jié)點(diǎn)上運(yùn)行，被識(shí)別的各種元素（網(wǎng)絡(luò)、過程、任 務(wù)和對(duì)象），需要被映射至不同的節(jié)點(diǎn)；我們希望使用不同的物理配置：一些用于開發(fā)和測(cè) 試，另外一些則用于不同地點(diǎn)和不同客戶的部署。因此軟件至節(jié)點(diǎn)的映射需要高度的靈活 性及對(duì)源代碼產(chǎn)生最小的影響。場(chǎng)景一綜合所有的視圖四種視圖的元素通過數(shù)量比較少的一組重要場(chǎng)景（更常見的是用例）進(jìn)行無縫協(xié)同工作，我 們?yōu)閳?chǎng)景描述相應(yīng)的腳本（對(duì)象之間和過程之間的交互序列）。在某種意義上場(chǎng)景是最重要的需求抽象，它們的設(shè)計(jì)使用對(duì)象場(chǎng)景圖和對(duì)象交互圖來表示。該視圖是其他視圖的冗余（因此+1），但它起到了兩個(gè)作用：作為一項(xiàng)驅(qū)動(dòng)因素來發(fā)現(xiàn)

25、架構(gòu)設(shè)計(jì)過程中的架構(gòu)元素，這一點(diǎn)將在下文中討論。作為架構(gòu)設(shè)計(jì)結(jié)束后的一項(xiàng)驗(yàn)證和說明功能，既以視圖的角度來說明又作為架構(gòu)原型測(cè)試的 出發(fā)點(diǎn)。視圖之間的對(duì)應(yīng)性各種視圖并不是完全是正交的或獨(dú)立的。視圖的元素根據(jù)某種設(shè)計(jì)規(guī)則 和啟發(fā)式方法與其他視圖中的元素相關(guān)聯(lián)。模型的剪裁并不是所有的軟件架構(gòu)都需要4+1視圖。無用的視圖可以從架構(gòu)描述中省略，比如：只 有一個(gè)處理器，則可以省略物理視圖；而如果僅有一個(gè)進(jìn)程或程序，則可以省略過程視圖。 對(duì)于非常小型的系統(tǒng)，甚至可能邏輯視圖與開發(fā)視圖非常相似，而不需要分開的描述。場(chǎng)景 對(duì)于所有的情況均適用。迭代過程Witt等人為設(shè)計(jì)和架構(gòu)指出了 4個(gè)階段：勾畫草圖、組織、具體化和優(yōu)化，分成了 12個(gè) 步驟7。他們還指出需要某種程度的反向工程。而我們認(rèn)為對(duì)于大型的項(xiàng)目，該方法大，線 性化了。在4個(gè)階段的末尾，可用于驗(yàn)證架構(gòu)的內(nèi)容太少。我們提倡一種更具有迭代性 質(zhì)的方法，即架構(gòu)先被原形化、測(cè)試、估量、分析，然后在一系列的迭代過程中被細(xì)化。該 方法除了減少與架構(gòu)相關(guān)的風(fēng)險(xiǎn)之外，對(duì)于項(xiàng)目而言還有其他優(yōu)點(diǎn)：團(tuán)隊(duì)合作、培訓(xùn)，加深 對(duì)架構(gòu)的理解，深入程序和工具等等（此處提及的是演進(jìn)的原形，逐漸發(fā)展成為系統(tǒng)，而 不是一次性的試驗(yàn)性的原形）。這