架構師的職責及工作描述

1、架構師的職責及工作描述什么叫架構師系統(tǒng)分析員屬于Analyst角色組合，與其相比，架構師則是屬于Developer角色組里的一個角色，一個非常重要的角色。架構師的職責及工作描述Thesoftwarearchitectroleisresponsibleforthesoftwarearchitecture,whichineludesthekeytechnicaldecisionsthatconstraintheoveralldesignandimplementationfortheproject.負責在整個項目中對技術活動和工件進行領導和協(xié)調。構架設計師要確立每個構架視圖的整體結構：視圖的詳細組織

2、結構、元素的分組以及這些主要分組之間的接口。因此，與其他角色相比，構架設計師的見解重在廣度，而不是深度。架構師負責理解系統(tǒng)的業(yè)務需求，并創(chuàng)建合理、完善的系統(tǒng)體系架構。架構師也負責通過軟件架構來決定主要的技術選擇。這典型的包括識別和文檔化系統(tǒng)的重要架構方面，包括系統(tǒng)的需求、設計、實現(xiàn)和部署視圖。Thesoftwarearchitecthasoverallresponsibilityfordrivingthemajortechnicaldecisions,expressedasthesoftwarearchitecture.Thistypicallyincludesidentifyinganddo

3、cumentingthearchitecturallysignificantaspectsofthesystem,includingrequirements,design,implementation,anddeploymentviewsofthesystem.Thearchitectisalsoresponsibleforprovidingrationaleforthesedecisions,balancingtheconcernsofthevariousstakeholders,:注：這就是說架構師要在大家意見不統(tǒng)一的時候給出一個基本的并且這些人都比較能接受的基本意見，這就是要求架構師要有

4、一定的判斷力和決定能力以及體現(xiàn)核心作用、核心力量和支柱的這樣一種領導力。drivingdowntechnicalrisks,andensuringthatdecisionsareeffectivelycommunicated,validated,andadheredto.:注：架構師一定要具備降低風險（當然主要是技術方面）的能力，以及他的這種架構思想切實得到貫徹和落實的能力。建模軟件應用和方案，并創(chuàng)建和管理可重用的模式和模型；維護在我們的軟件系統(tǒng)中的系統(tǒng)組件和他們的接口。建模信息架構，創(chuàng)建和維護組織技術設施的布局，并提供滿足業(yè)務需求的技術觀點和遠景。架構師的技能要求和能力素養(yǎng)Insummary

5、,thesoftwarearchitectmustbewell-rounded,possesmaturity,vision,andadepthofexperieneethatallowsforgraspingissuesquicklyandmakingeducated,criticaljudgmentintheabseneeofcompleteinformation.Morespecifically,thesoftwarearchitect,ormembersofthearchitectureteam,mustcombinetheseskills:構架設計師必須多才多藝、成熟練達、洞察力強、經

6、驗豐富。這樣，他才能在無法獲得完整信息的情況下迅速領會問題并根據(jù)經驗作出審慎的判斷。更準確地說，構架設計師（或者構架團隊的成員）必須兼具以下技能：Experieneeinboththeproblemdomain,throughathoroughunderstandingoftherequirements,andthesoftwareengineeringdomain.Ifthereisateam,thesequalitiescanbespreadacrosstheteammembers,butatleastonesoftwarearchitectmustprovidetheglobalvisi

7、onfortheproject.經驗：既包括在問題領域的經驗（通過徹底了解需求），也包括在軟件工程領域的經驗。對于一個構架團隊，這些素質要求可由各團隊成員來分別承擔，但其中至少要有一名構架設計師能夠把握項目的全局。Leadershipinordertodrivethetechnicaleffortacrossthevariousteams,andtomakecriticaldecisionsunderpressureandmakethosedecisionsstick.Tobeeffective,thesoftwarearchitectandtheprojectmanagermustworkc

8、loselytogether,withthesoftwarearchitectleadingthetechnicalissuesandtheprojectmanagerleadingtheadministrativeissues.Thesoftwarearchitectmusthavetheauthoritytomaketechnicaldecisions.領導才能：能夠推動各個團隊的技術進展，并能在壓力下作出關鍵性的決策然后將其貫徹到底。要提高效率，構架設計師和項目經理必須緊密協(xié)作。構架設計師主要負責解決技術問題，項目經理主要負責解決行政管理問題。構架設計師必須有權在技術問題上作出決定。Co

9、mmunicationtoearntrust,topersuade,tomotivate,andtomentor.Thesoftwarearchitectcannotleadbydecree,onlybytheconsentoftherestoftheproject.Inordertobeeffective,thesoftwarearchitectmustearntherespectoftheprojectteam,theprojectmanager,thecustomer,andtheusercommunity,aswellasthemanagementteam.溝通：能夠贏得他人的信任，以

10、對其進行說服、激勵和指導。構架設計師不能靠命令進行領導，而必須要贏得項目中其他人員的贊同。為了提高效率，構架設計師必須贏得項目團隊、項目經理、客戶、用戶群體以及管理團隊的尊敬。Goal-orientationandPro-activitywitharelentlessfocusonresults.Thesoftwarearchitectisthetechnicaldrivingforcebehindtheproject,notavisionaryordreamer.Thecareerofasuccessfulsoftwarearchitectisalongseriesofsub-optimal

11、decisionsmadeinuncertaintyandunderpressure.OnlythosewhocanfocusondoingwhatneedstobedonewillbesuccessfuIinthisenvironmentoftheproject.*以目標為中心、積極主動，不懈地追求成效。構架設計師是推動項目發(fā)展的技術動力，而不是空想家。在其職業(yè)生涯中，成功的構架設計師一直都要在捉摸不定和承受壓力的情況下作出折衷決定。構架設計師只有將注意力集中在該做的事情上，才能在項目中取得成功。從專業(yè)角度看，構架設計師必須具備系統(tǒng)設計員（designer）的所有能力。但是：However,

12、unlikethedesigner,thesoftwarearchitect:tendstobeageneralistratherthanaspecialist,knowingmanytechnologiesatahighlevelratherthanafewtechnologiesatthedetaillevelmakesbroadertechnicaldecisions,andthereforebroadknowlegeandexperienee,aswellascommunicationandleadershipskills,arekey.注：此處兩點，一語道破架構師和設計師的本職區(qū)別。

13、請認真體會，側重點是不同的。架構師應該能夠：理解企業(yè)應用的體系結構，能夠對分布式企業(yè)應用系統(tǒng)體系結構、面向服務的應用系統(tǒng)體系結構的設計要點給出指導性建議的。團隊里架構師配備的方法和指導原則Iftheprojectislargeenoughtowarrantanarchitectureteam,thegoalistohaveagoodmixoftalents,coveringawidespectrumofexperieneeandsharingacommonunderstandingofsoftwareengineeringprocess.Thearchitectureteamneednotbe

14、acommitteeofrepresentativesfromvariousteams,domainsorcontractors.Softwarearchitectureisafull-timefunction,withstaffpermanentlydedicatedtoit.如果項目較大，需要組建一個構架團隊，則應盡量廣聚賢才，使該團隊既擁有廣泛的經驗，又對軟件工程流程具有一致的認識。構架團隊不應該是由各團隊、領域或承包商的代表組成的委員會。軟件構架設計是一項長期的工作，始終都需要配備專職人員。Forsmallerprojects,asinglepersonmayactasbothproj

15、ectmanagerandsoftwarearchitect.However,ifatallpossible,itisbettertohavetheserolesperformedbyseparatepeople,inordertoensurethattimepressureononeroledoesntcausetheotherroletobeneglected.注：小型項目架構師可以兼做項目經理。但是不要因為時間安排問題導致兩種角色互有影響。架構師需要對此有很好的調節(jié)能力和全局安排、協(xié)調處理、解決能力。軟件架構模型（4+1）架構模型軟件架構用來處理軟件高層次結構的設計和實施。它以精心選擇的

16、形式將若干結構元素進行裝配，從而滿足系統(tǒng)主要功能和性能需求，并滿足其他非功能性需求，如可靠性、可伸縮性、可移植性和可用性。Perry和Wolfe使用一個精確的公式來表達，該公式由Boehm做了進一步修改：軟件架構=元素，形式，關系/約束軟件架構涉及到抽象、分解和組合、風格和美學。我們用由多個視圖或視角組成的模型來描述它。為了最終處理大型的、富有挑戰(zhàn)性的架構，該模型包含五個主要的視圖(請對照圖1):邏輯視圖(LogicalView)，設計的對象模型(使用面向對象的設計方法時)。過程視圖(ProcessView)，捕捉設計的并發(fā)和同步特征。物理視圖(PhysicalView)，描述了軟件到硬件的映

17、射，反映了分布式特性。開發(fā)視圖(DevelopmentView)，描述了在開發(fā)環(huán)境中軟件的靜態(tài)組織結構。架構的描述，即所做的各種決定，可以圍繞著這四個視圖來組織，然后由一些用例(usecases)或場景(scenarios)來說明，從而形成了第五個視圖。正如將看到的，實際上軟件架構部分從這些場景演進而來，將在下文中討論。圖14+1視圖模型注：請?zhí)貏e留意這四個view的各自主要使用對象。比如DevelopmentView，主要是programmers看到的系統(tǒng)架構圖。我們在每個視圖上均獨立地應用Perry&Wolf的公式，即定義一個所使用的元素集合(組件、容器、連接符)，捕獲工作形式和模式，并且

18、捕獲關系及約束，將架構與某些需求連接起來。每種視圖使用自身所特有的表示法一藍圖(blueprint)來描述，并且架構師可以對每種視圖選用特定的架構風格(architecturalstyle)，從而允許系統(tǒng)中多種風格并存。我們將輪流的觀察這五種視圖，展現(xiàn)各個視圖的目標：即視圖的所關注的問題，相應的架構藍圖的標記方式，描述和管理藍圖的工具。并以非常簡單的形式?！?+1視圖模型具有相當?shù)钠毡樾?，因此可以使用其他的標注方法和工具，也可以采用其他的設計方法，特別是對于邏輯和過程的分解。但文中指出的這些方法都已經成功的在實踐中運用過。邏輯結構面向對象的分解邏輯架構主要支持功能性需求即在為用戶提供服務方面系

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

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

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

22、在計算機網(wǎng)絡或處理節(jié)點上運行，被識別的各種元素（網(wǎng)絡、過程、任務和對象），需要被映射至不同的節(jié)點；我們希望使用不同的物理配置：一些用于開發(fā)和測試，另外一些則用于不同地點和不同客戶的部署。因此軟件至節(jié)點的映射需要高度的靈活性及對源代碼產生最小的影響。場景綜合所有的視圖四種視圖的元素通過數(shù)量比較少的一組重要場景（更常見的是用例）進行無縫協(xié)同工作，我們?yōu)閳鼍懊枋鱿鄳哪_本（對象之間和過程之間的交互序列）。在某種意義上場景是最重要的需求抽象，它們的設計使用對象場景圖和對象交互圖來表示。該視圖是其他視圖的冗余（因此+1）,但它起到了兩個作用：作為一項驅動因素來發(fā)現(xiàn)架構設計過程中的架構元素，這一點將在下文

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