第一講 什么是軟件體系結構

1、第一講什么是軟件架構中培教育-中國信息化培訓中心2011高級系統(tǒng)架構師培訓班（）1第一部分 引言2狗窩、架構和建模的故事我們在用建狗窩的方法建設軟件的摩天大樓1.13狗窩的架構設計 一個人就能搭建需要：設計方案（構思）在建造者的腦子里簡單的過程：邊建造邊構思簡單的工具4別墅的架構設計由一個團隊，必須有效且高效地建造，需要有設計，要建模良好定義的過程強大的工具5樓群的架構設計怎么建設？6討論：Booch所述現(xiàn)象的含義7要點2：建模和實現(xiàn)要點1：局部與整體故事寓意：重視軟件架構設計8在諸如建筑和計算機硬件設計中，體系結構是指整個系統(tǒng)構成的基本和主體形態(tài)，在一個發(fā)展成熟的領域中，這種結構成為建立和考

2、察系統(tǒng)的總體指導或基本出發(fā)點。例如：橋梁的形態(tài)具有拱形、板式支撐、吊索、斜拉式等。計算機的主體結構形態(tài)具有單處理器、多處理器、并行計算、網絡計算等。軟件體系結構是軟件在設計構成上的基本、可供設計選擇的形態(tài)和總體結構。具體說，就人們現(xiàn)今已經熟悉的軟件概念看，軟件設計中可供選擇的結構形態(tài)有：過程（procedure)、包（package)、對象（object）、客戶/服務器（client/sever）、分布式（distributed)、可視控件（visual controls）、部件（component）、解釋器（interpreter）、瀏覽器（browser）等。軟件的結構9軟件結構中，每一個

3、結構概念都傳達了領域的特定設計問題、解決問題的特定方法、方法的實現(xiàn)構成和它們之間的關系、結構的性能和優(yōu)缺點、考察結構性能的方法等。除了功能要素之外，軟件性能決定結構形態(tài)軟件變更決定結構形態(tài)軟件結構分析要素10隨著計算機硬件技術的飛速發(fā)展，對計算機軟件的功能、結構和復雜性提出了更高的需求，隨著軟件復雜性的不斷增加，在軟件的設計中，軟件的局部和整體系統(tǒng)結構方面，已經越來越顯出其重要性，甚至超過了軟件算法和數(shù)據結構這些常規(guī)軟件設計的概念。軟件體系結構定義了軟件的局部和總計算機部件的構成，以及這些部件之間的相互作用關系。部件包括諸如客戶、服務器、數(shù)據庫、過濾器、程序包、過程、子程序等一切軟件的組成成分

4、。相互作用關系包括諸如過程調用、共享變量訪問、消息傳遞等、相互作用也包括具有十分復雜的語義和構成的關系，諸如客戶/服務器的訪問協(xié)議軟件的局部和整體11除了描述系統(tǒng)的構成和結構關系外，在系統(tǒng)的功能需求方面，體系結構還表達了系統(tǒng)需求和構成之間的關系，這為系統(tǒng)的設計提供了分析和評價的依據。在系統(tǒng)宏觀層面上，人們所關心的是系統(tǒng)的非功能需求方面的內容，諸如容量、數(shù)據吞吐量、一致性、兼容性、安全性、可靠性等，這些在體系結構中也都表達了出來。軟件的功能和性能12一般的說，體系結構清楚的表達了系統(tǒng)的構成部件以及它們之間的作用關系和語義。這些部件又可以用來構成更大的、更復雜的部件或系統(tǒng)。在理想的情況下，體系結構

5、描述的各個組成成分都是被獨立定義的，因此，可以在不同的場合中得到重用，體系結構將為它們建立結構和功能規(guī)范，經過進一步完善，可以將它們組成更大，更復雜的系統(tǒng)，并且是可以運行的軟件系統(tǒng)。由于系統(tǒng)每一層次和每一部分的組成結構是明確規(guī)范了的，因此為整個系統(tǒng)的功能和非功能特性的分析提供了全面的和具體的根據。軟件結構的復合關系13服務于軟件開發(fā)的不同階段，依照層次和細節(jié)程度，體系結構可分為概略型、需求型和設計型。概略型是上層宏觀結構的描述，反應系統(tǒng)最上層的部件和鏈接關系。需求型是對概略型體系結構的深入表達，以滿足用戶功能和非功能需求的表達為主，通常需要對概略層得部件和鏈接進行深層的描述。設計型體系結構是從

6、設計實現(xiàn)的角度對需求結構的更深層的描述表達。在此類型的結構中，需要從不同的側面/視圖，采用各種表達圖示和說明，設計系統(tǒng)各個層面得各個部件和鏈接的結構。改層面的體系結構將直接服務于系統(tǒng)的實現(xiàn)和性能分析。類別14總的來看，軟件體系結構是由結構和功能各異，相互作用的部件集合，按照層次構成的。它包含了系統(tǒng)基礎構成單元、它們之間的作用關系、在構成系統(tǒng)時它們的合成方法以及對合成約束的描述。小結151617181920從小例子看架構1.221例子1：MVC例子組件：Model、View和 Controller交互：View創(chuàng)建Controller Controller根據用戶交互調用Model相應的服務 M

7、odel將自身的改變通知View View讀取Model的信息以更新自身 構架=組件+交互2223需求描述（軟件架構師的理解）把握設備調試系統(tǒng)應完成的全局目標：作為設備調試系統(tǒng)，其主要功能是實時顯示設備狀態(tài)，以及支持用戶發(fā)送調試命令；另外，由于是為硬件產品配套的軟件系統(tǒng)，所以它必須容易被測試，否則是硬件故障還是軟件故障將很難區(qū)分：再就是必須具有很高的性能，具體性能指標為“每秒鐘能夠別新 5 次設備狀態(tài)的顯示，并同時支持一個完整命令字的發(fā)送”。例子2：“設備調試”例子構架=一系列層次性決策24設備調試例子主要目標組成部分桌面應用的分解對職責層層分解，依次決策考慮性能要求早期考慮的是技術無關的決策

8、25一個軟件系統(tǒng)的架構定義了組成系統(tǒng)的計算構件和構件之間相互作用的關系軟件架構層次的設計主要包括以下方面： 組成系統(tǒng)的構件描述 構件之間的交互 指導構件交互的模式，以及 施加在模式上的約束Garlan和Shawn，1996軟件架構是一組關于下述問題的重要決定，軟件系統(tǒng)的組織構成系統(tǒng)的結構化元素和它們接口的選擇這些模型元素之間的協(xié)作所描述的行為這些結構化和行為元素的組裝，以形成更大的子系統(tǒng)指導這種組織（靜態(tài)和動態(tài)元素，以及它們的接口、協(xié)作和組裝）的架構風格軟件架構不僅關注結構和行為，也關注使用、功能、性能、彈性、復用、可理解性、經濟和技術約束與折衷、審美考慮Booch、Rumbaugh和Jaco

9、bson，1999結論：什么是軟件架構？26架構產生的原因1.327討論：構架產生的原因軟件危機的原因用戶需求不明確 缺乏正確的理論指導軟件規(guī)模越來越大軟件復雜度越來越高軟件復雜度越來越高 軟件不僅僅是在規(guī)模上快速地發(fā)展擴大，而且其復雜性也急劇地增加。軟件產品的特殊性和人類智力的局限性，導致人們無力處理“復雜問題”。所謂“復雜問題”的概念是相對的，一旦人們采用先進的組織形式、開發(fā)方法和工具提高了軟件開發(fā)效率和能力，新的、更大的、更復雜的問題又擺在人們的面前軟件規(guī)模越來越大 隨著軟件應用范圍的增廣，軟件規(guī)模愈來愈大。大型軟件項目需要組織一定的人力共同完成，而多數(shù)管理人員缺乏開發(fā)大型軟件系統(tǒng)的經驗

10、，而多數(shù)軟件開發(fā)人員又缺乏管理方面的經驗。各類人員的信息交流不及時、不準確、有時還會產生誤解。軟件項目開發(fā)人員不能有效地、獨立自主地處理大型軟件的全部關系和各個分支，因此容易產生疏漏和錯誤。 28軟件復雜性二維圖Walker Royce29軟件設計復雜性的根本原因在于：變化技術平臺的變化開發(fā)團隊的變化市場環(huán)境的變化小問題：軟件設計復雜的根本原因？30如何克服軟件危機 如何克服軟件危機 人們面臨的不光是技術問題，更重要的是管理問題。管理不善必然導致失敗 。要提高軟件開發(fā)效率，提高軟件產品質量，必須采用工程化的開發(fā)方法與工業(yè)化的生產技術。在技術上，應該采用基于復用的軟件生產技術；在管理上，應該采用

11、多維的工程管理模式。誕生了軟件工程用工程、科學和數(shù)學的原則和方法研制、維護計算機軟件的有關技術及管理方法方法：“如何做”的技術手段工具：為方法提供的自動或者半自動的軟件支撐環(huán)境過程：將軟件工程的方法和共計綜合起來以達到合理、及時地進行計算機軟件開發(fā)地目的軟件架構是軟件工程學科的分支31軟件復用的方法(1)高級語言出現(xiàn)了結構的公共基本單元復用語言命令模式：函數(shù)、類庫、模板庫.設計和代碼挖掘出現(xiàn)了高層設計需要巨大的時間/精力投入收益不可預知源代碼構件出現(xiàn)了軟件的基本結構專為復用開發(fā)的構件成功用于小的、易于理解的領域通用構件庫傾向于不實用軟件模式出現(xiàn)了公共的軟件結構使用抽象的算法和數(shù)據結構，而非源代

12、碼在高于代碼的抽象層次上形式化規(guī)約可能因為太復雜而難以定位、理解和使用32軟件復用的方法(2)應用系統(tǒng)生成器出現(xiàn)了領域架構類似于程序語言編譯器，但適用于較窄的領域應用于非常高層、專用的抽象不適用于廣泛的應用甚高級語言和轉換系統(tǒng)出現(xiàn)了結構的自動生成使用“可執(zhí)行的規(guī)約語言”典型的數(shù)學抽象，例如，集合論更通用的應用，但不像生成器功能強大（人工引導）從規(guī)約到實現(xiàn)的轉換軟件架構出現(xiàn)了.33結論：軟件架構控制軟件的復雜度軟件系統(tǒng)天生是復雜的，某些復雜性是可控的提高開發(fā)人員的抽象層次努力同開發(fā)人員的思維模式相匹配針對上述問題，出現(xiàn)的特定技術描述軟件系統(tǒng)的符號體系（？）從可復用的、粗粒度的構造塊搭建系統(tǒng)的技術

13、和工具（？）關注于整體系統(tǒng)結構（？） “ 還有很長的路要走！”34第二部分 軟件架構的概念和原理35什么是構架？2.136架構的發(fā)展過程“無架構”設計階段萌芽階段以匯編語言進行小規(guī)模應用程序開發(fā)為特征以描述系統(tǒng)的高層抽象結構為中心，不關心具體的建模細節(jié)，劃分了架構模型與傳統(tǒng)軟件結構的界限，該階段以Kruchten提出的“4+1”模型為標志出現(xiàn)了從不同側面描述系統(tǒng)的結構模型，以UML為典型代表。出現(xiàn)了程序結構設計主題，以控制流圖和數(shù)據流圖構成軟件結構為特征高級階段初期階段37一個軟件系統(tǒng)的架構定義了組成系統(tǒng)的計算構件和構件之間相互作用的關系軟件架構層次的設計主要包括以下方面： 組成系統(tǒng)的構件描述

14、 構件之間的交互 指導構件交互的模式，以及 施加在模式上的約束Garlan和Shawn，1996軟件架構是一組關于下述問題的重要決定，軟件系統(tǒng)的組織構成系統(tǒng)的結構化元素和它們接口的選擇這些模型元素之間的協(xié)作所描述的行為這些結構化和行為元素的組裝，以形成更大的子系統(tǒng)指導這種組織（靜態(tài)和動態(tài)元素，以及它們的接口、協(xié)作和組裝）的架構風格軟件架構不僅關注結構和行為，也關注使用、功能、性能、彈性、復用、可理解性、經濟和技術約束與折衷、審美考慮Booch、Rumbaugh和Jacobson，1999回顧：什么是軟件架構？38定義1組成派：關注于架構的客體（物），關注于構架的高度抽象按建模的觀點看待構架的內

15、在本職定義2決策派：關注于構架的實踐主體（人的決策）歸納了構架的外在表現(xiàn)形式分析：39軟件體系結構的定義Design viewDeployment viewImplementation viewProcess viewUse caseviewvocabularyfunctionalitysystem assemblyconfiguration managementsystem topologydistributiondeliveryinstallationperformancescalabilitythroughputbehavior采用UML進行軟件體系結構建模40體系結構的4W41Perr

16、y and Wolf, 1992軟件體系結構（元素，形態(tài)，基本理論）軟件體系結構是一組具有特定形式的設計元素。這里的設計元素被分為三類：處理元素 (processing elements)、數(shù)據元素 (data elements)和連接元素(connection elements)Kruchten, 1994軟件體系結構涉及軟件高層結構的設計和實現(xiàn),通過組裝一定數(shù)量的具有良好形態(tài)的元素，以滿足主要的功能和性能需求，例如，可擴展性和可用性涉及抽象、分解/組裝、風格/審美Bass, Clements, and Kazman, 1997軟件體系結構是一個系統(tǒng)的結構，包括軟件構件、構件的外部可見屬性、

17、以及構件關系這里，“外部可見”屬性指的是其他構件可以對該構件所做的假定，比如它提供的服務、性能特性、錯誤處理、共享資源的使用等討論：構架的定義正確嗎？42一個軟件系統(tǒng)的體系結構定義了組成系統(tǒng)的 構件（components）， 連接件（connectors），和 它們之間的匹配（配置configurations ）這里，構件用于實施計算和保存狀態(tài)，連接件用于表達構件之間的關系，構件和連接件之間的匹配表示了系統(tǒng)的拓撲結構。答案要點：A2A1A3B1B243構件構件是計算或數(shù)據儲存的單元Perry & Wolf定義中的處理元素和數(shù)據元素構件是計算和狀態(tài)的場所客戶(clients)服務器(server

18、s)數(shù)據庫(databases)過濾器(filters)層次(layers)抽象數(shù)據類型(ADTs)構件可以是簡單的或復合的復合構件描述了一個（子）系統(tǒng)44連接件連接件是對以下內容進行建模的體系結構元素構件之間的交互指導這些交互的規(guī)則簡單交互過程調用共享變量訪問復雜和語義豐富的交互客戶/服務器協(xié)議數(shù)據庫訪問協(xié)議異步事件廣播管道數(shù)據流45連接件傳統(tǒng)方法中，構件之間的連接關系通常并不獨立存在，而是從屬于構件，且表達能力較弱由于以下原因，表達構件之間關系的連接件應該從中分離出來，作為同構件平等的第一類實體：連接件可能要表達構件之間相當復雜的關系語義，需要詳細的定義和復雜的規(guī)約復雜連接件的定義應當局部

19、化，而不是分散定義在多個構件中，以保證系統(tǒng)具有良好的結構構件之間的關系并非是固定不變的，有可能隨著系統(tǒng)的運行需要動態(tài)改變，這種改變應封裝在連接件中 連接件和構件一樣，都應該是獨立的和各有分工的。構件應該只定義它的能力（包括功能和非功能兩個方面）；連接件應該規(guī)定構件之間的交互 系統(tǒng)開發(fā)時常常復用已有的連接件，例如過濾器、客戶服務器協(xié)議、數(shù)據庫訪問協(xié)議等46配置/拓撲體系結構的配置或拓撲是構件和連接件的連接圖(connected graph)，描述了系統(tǒng)結構 適當?shù)倪B接并發(fā)和分布特性符合設計啟發(fā)式規(guī)則和風格規(guī)則復合構件本身就是配置47構架圖實例展示：教學系統(tǒng)48構架展示：微軟 e-Gov 架構49

20、構架展示：應用系統(tǒng)架構Operational ManagementSecurityCommunicationUI ComponentsUI Process ComponentsData Access ComponentsBusiness WorkflowsBusiness ComponentsUsersBusiness EntitiesService AgentsService InterfacesData SourcesServicesPatterns & PracticesCachingData Format & exchange50程序架構VS .NET Solution52房屋銷售數(shù)據

21、，包括已售、待售、在建、規(guī)劃中等參數(shù)，希望用直方圖、餅圖等多種形式的統(tǒng)計表現(xiàn)，如何設計他們的體系結構？練習：分析以下問題的結構53將一個類的接口轉換成客戶希望的另一個接口。Adapter模式使得原本由于接口不兼容而不能一起工作的那些類可以一起工作?；蛘呤且粋€類Adaptee 在發(fā)生不可預見變化的時候，僅僅影響Adaper而不影響Client練習提示：適配器Adaper模式54粒度最小的單元通常是“類”幾個類緊密協(xié)作形成“模塊” ；完成相對獨立的功能的多個模塊構成了“子系統(tǒng)”多個子系統(tǒng)相互配合才能滿足一個完整應用的，從而構成了軟件“系統(tǒng)”個大型企業(yè)往往使用多套系統(tǒng)，多套系統(tǒng)通過互操作形成集成系統(tǒng)

22、,辨析：子系統(tǒng)和架構55所謂系統(tǒng)，是指由多個元素組成的邏輯實體，它完成組特定的目標或擔負一定職責。系統(tǒng)可以僅包含軟件，也可以僅包含硬件，或者是兩者都包含。子系統(tǒng)是特殊的系統(tǒng)只不過在特定的上下文中，這個系統(tǒng)作為更大的系統(tǒng)的一部分系統(tǒng)需要架構設計，而子系統(tǒng)如果足夠復雜，則也需要架構設計。子系統(tǒng)作為特殊的系統(tǒng)，它也是由多個元素組成的整體，而架構確定了它是如何劃分為多個部分的，以及規(guī)定了多個部分之間的交互機制和交互接口。辨析：子系統(tǒng)也有架構56辨析：框架和架構57框架決定了應用系統(tǒng)的架構一個框架可以被實例化成為多個應用系統(tǒng)，每個應用系統(tǒng)具有特定的架構，因此框架從框架使用的角度來看，框架和架構之間存在著

23、1對多(1:N)的關系從框架開發(fā)的角度來看，框架反映了一個領域的架構（DSSA），它是DSSA的一個實例，因此，DSSA和框架之間同樣存在著1對多(1:N)的關系從在軟件開發(fā)過程中所起的作用而言，架構是軟件的高層設計抽象，它有助于系統(tǒng)開發(fā)團隊之間的交流DSSA是可以視為“參考”架構，對于領域內應用系統(tǒng)架構的設計具有指導意義而開發(fā)框架最重要的目的則是針對特定領域的設計和代碼復用框架58多視角看構架2.259程序員說：軟件架構就是要決定需要編寫哪些類、使用那些現(xiàn)成的框架程序經理笑了；程序經理說：軟件構架就是模塊的劃分和結構定義系統(tǒng)分析員笑了；系統(tǒng)分析員說：軟件構架就是為業(yè)務領域對象的關系建模。 配

24、置管理員笑了；配置管理員說：軟件構架就是開發(fā)出來的以及編譯過后的軟件到底是個啥結構數(shù)據庫工程師笑了；數(shù)據庫工程師說：軟件結構規(guī)定了持久化的結構，其他一切只不過是對數(shù)據的操作而已部署工程師笑了；部署工程師說：軟件架構規(guī)定了軟件部署到硬件的策略用戶笑了用戶說：軟件架構就是決定一個個功能子系統(tǒng)如何劃分程序員又笑了；大家想了想說，這些構架視圖好像我們都需呀軟件構架師哭了。架構的喜?。憾夹α?0采用UML進行架構建模Design viewDeployment viewImplementation viewProcess viewUse caseviewvocabularyfunctionalitysys

25、tem assemblyconfiguration managementsystem topologydistributiondeliveryinstallationperformancescalabilitythroughputbehavior采用UML進行軟件架構建模61軟件架構的分類62軟件架構的層次63示例64July 7, 202265Zachman 架構模型Row 1 ScopeExternal Requirements and DriversBusiness Function ModelingZachman FrameworkRow 2 Enterprise ModelBusin

26、ess Process ModelsRow 3 System ModelLogical ModelsRequirements DefinitionRow 4 Technology ModelPhysical ModelsSolution Definition and DevelopmentRow 5 As BuiltAs BuiltDeploymentRow 6 Functioning EnterpriseFunctioning EnterpriseEvaluation123456ContextualConceptualLogicalPhysicalAs BuiltFunctioningCon

27、textualConceptualLogicalPhysicalAs BuiltFunctioningWhyWhyWhoWhoWhenWhenWhereWhereWhatWhatHowHow66Rule 1: Columns have no order July 7, 202267Framework RulesContextualConceptualLogicalPhysicalAs BuiltFunctioningContextualConceptualLogicalPhysicalAs BuiltFunctioningWhyWhyWhoWhoWhenWhenWhereWhereWhatWh

28、atHowHowRule 2: Each column has a simple, basic model Rule 3: Basic model of each column is unique Rule 4: Each row represents a distinct view Rule 5: Each cell is unique Rule 6: Combining the cells in one row forms a complete description from that viewBasic Model = Entities and RelationshipsEntityR

29、elationshipEntityMotivation/WhyBusiness goals, objectives and performancemeasures related to each function July 7, 202268Zachman Framework Row 1Scope/Planners ViewExternal Requirements and DriversBusiness Function ModelingFunction/HowHigh-level business functionsData/WhatHigh-level data classes rela

30、ted to eachfunctionPeople/WhoStakeholders related to each functionNetwork/WhereVA locations related to each functionTime/WhenCycles and events related to eachfunction1ContextualConceptualLogicalPhysicalAs BuiltFunctioningContextualConceptualLogicalPhysicalAs BuiltFunctioningWhyWhyWhoWhoWhenWhenWhere

31、WhereWhatWhatHowHowMotivation/WhyPolicies, procedures and standards for eachprocess July 7, 202269Zachman Framework Row 2Enterprise Model/Designers ViewBusiness Process ModelsBusiness Function AllocationElimination of Function Overlap and AmbiguityFunction/HowBusiness processesData/WhatBusiness data

32、People/WhoVA roles and responsibilities in eachprocessNetwork/WhereVA locations related to each processTime/WhenEvents for each process and sequencingof integration and process improvements2ContextualConceptualLogicalPhysicalAs BuiltFunctioningContextualConceptualLogicalPhysicalAs BuiltFunctioningWh

33、yWhyWhoWhoWhenWhenWhereWhereWhatWhatHowHowMotivation/WhyVA policies, standards and proceduresassociated with a business rule model July 7, 202270Zachman Framework Row 3System Model/Designers ViewLogical ModelsProject ManagementRequirements Definition Function/HowLogical representation of information

34、systems and their relationships Data/WhatLogical data models of data and datarelationships underlying VA information People/WhoLogical representation of access privilegesconstrained by roles and responsibilitiesNetwork/WhereLogical representation of the distributedsystem architecture for VA location

35、sTime/WhenLogical events and their triggered responses constrained by business events and their responses 3ContextualConceptualLogicalPhysicalAs BuiltFunctioningContextualConceptualLogicalPhysicalAs BuiltFunctioningWhyWhyWhoWhoWhenWhenWhereWhereWhatWhatHowHowMotivation/WhyVA business rules constrain

36、ed by informationsystems standards July 7, 202271Zachman Framework Row 4Technology Model/Builders ViewPhysical ModelsTechnology ManagementSolution Definition and Development Function/HowSpecifications of applications that operateon particular technology platforms Data/WhatDatabase management system

37、(DBMS) typerequirements constrained by logical data models People/WhoSpecification of access privileges tospecific platforms and technologies Network/WhereSpecification of network devices and theirrelationships within physical boundaries Time/WhenSpecification of triggers to respond to systemevents

38、on specific platforms and technologies 4ContextualConceptualLogicalPhysicalAs BuiltFunctioningContextualConceptualLogicalPhysicalAs BuiltFunctioningWhyWhyWhoWhoWhenWhenWhereWhereWhatWhatHowHowMotivation/WhyVA business rules constrained by specific technology standards July 7, 202272Zachman Framework

39、 Row 5As Built/Integrators ViewAs BuiltConfiguration ManagementDeployment Function/HowPrograms coded to operate on specific technology platforms Data/WhatData definitions constrained by physical data models People/WhoAccess privileges coded to control access to specific platforms and technologies Ne

40、twork/WhereNetwork devices configured to conform to node specifications Time/WhenTiming definitions coded to sequence activities on specific platforms and technologies 5ContextualConceptualLogicalPhysicalAs BuiltFunctioningContextualConceptualLogicalPhysicalAs BuiltFunctioningWhyWhyWhoWhoWhenWhenWhe

41、reWhereWhatWhatHowHowMotivation/WhyOperating characteristics of specific technologies constrained by standards July 7, 202273Zachman Framework Row 6Functioning Enterprise/Users ViewFunctioning EnterpriseOperations ManagementEvaluation Function/HowFunctioning computer instructions Data/WhatData value

42、s stored in actual databases People/WhoVA personnel and key stakeholders working within their roles and responsibilities Network/WhereSending and receiving messages Time/WhenTiming definitions operating to sequence activities 6ContextualConceptualLogicalPhysicalIntegratedFunctioningContextualConcept

43、ualLogicalPhysicalIntegratedFunctioningWhyWhyWhoWhoWhenWhenWhereWhereWhatWhatHowHowVA Zachman Framework Portal747576構架縱橫談2.377架構的焦點和范圍軟件架構是一個軟件系統(tǒng)的設計圖(blueprint)解決復雜性問題提高復用和構件市場的潛力包含形式化方法兩個主要焦點系統(tǒng)結構需求和實現(xiàn)之間的對應 構件 + 組裝規(guī)則 + 行為規(guī)則理解系統(tǒng)級關注的框架全局流動率，通訊模式，執(zhí)行控制機構，可升級性，系統(tǒng)演化路徑，容量，吞吐量，一致性，構件兼容性，等78構架設計的定位79處于軟件系統(tǒng)建設

44、的上游需要全面考慮多方面的因素對于同一個問題，可以有多種設計結果是在各種制約條件下取得的較好折衷方案科學+ 經驗+ 藝術“系統(tǒng)架構”往往被濫用軟件架構設計的特點80有步驟、分層次地演進系統(tǒng)構架。將軟件需求逐漸轉變?yōu)檐浖脑O計方案。保障軟件的設計方案能夠適應實施環(huán)境。軟件建模的實踐過程參與建模的人員主要分成兩類角色： 系統(tǒng)構架師 設計師81構架設計： 職責分配及其協(xié)作發(fā)現(xiàn)職責分配職責維護職責82第三部分 架構師83William H. Gates is chairperson and chief software architect of Microsoft Corporation, the w

45、orldwide leader in software services and Internet technologies for personal and business computing. 全世界最知名的構架師84IT 行業(yè)的人才結構架構師Architect需求分析師BA項目經理PM系統(tǒng)工程師SE資深程序員軟件藍領PG系統(tǒng)維護、DBA優(yōu)秀的幾乎很難找到有，但數(shù)量不夠供求基本平衡，漸漸開始過剩有經驗的仍然缺缺！85IT 行業(yè)不同職業(yè)的差別架構師Architect需求分析師BA,項目經理PM系統(tǒng)工程師SE資深程序員軟件藍領PG系統(tǒng)維護、DBA發(fā)現(xiàn)問題發(fā)現(xiàn)解決方案了解問題進一步設計解決方案

46、知道問題實現(xiàn)解決方案知道解決方案86一個朝陽的職業(yè)崗位重要性日益提升、崗位供不應求知識體系正在不斷發(fā)展和成熟過程中基本上沒有正式的大學課程，研究生開始開設獨立的一門課程，但是以理論學習為主目前構架師的來源：只能接受培訓或自我摸索 干這一行的主要由IT 行業(yè)中的資深專家組成軟件架構師全世界最知名的構架師是誰？87思考、思考、再思考深入理解、準確把握所建系統(tǒng)的業(yè)務需求分析所有可見的問題、障礙、風險充分參考已有的成功方案，降低風險交流、討論、博弈、質疑對構思中的方案不斷提出質疑，避免漏洞廣泛聽取各層面的意見，開拓思路反復質疑、逐步完善已有的設計構思在動工建設之前驗證設計方案的正確性軟件架構師在干什么

47、？88架構師面對的群體89基礎知識最好要有系統(tǒng)開發(fā)全過程經驗對IT 建設生命周期各個環(huán)節(jié)有深入了解，包括：系統(tǒng)/模塊邏輯設計、物理設計、代碼開發(fā)、項目管理、測試、發(fā)布、運行維護、等深入掌握1-2種主流技術平臺上開發(fā)系統(tǒng)的方法了解多種應用系統(tǒng)的結構了解架構設計領域的主要理論、流派、框架特殊知識深入了解系統(tǒng)建設的業(yè)務需求了解系統(tǒng)的非功能需求和運行維護需求了解企業(yè)IT 公共設施、網絡環(huán)境、外部系統(tǒng)軟件架構師的知識結構90基于框架的思維架構設計的層次（Enterprise, Application, etc）IT 的生命周期（What, Why, Where, How, When, etc）成功經驗以

48、及方法論的指導合理把握技術細節(jié)把握各個層次應有的內容合理忽略不應有的技術細節(jié)風險管理意識采用成功經驗、避免不應有的風險多方位的開放思維多維度、多方向、包容性、避免排他性分析、質疑、抽象、歸納沒有絕對好的架構設計，只有相對優(yōu)秀的方案軟件架構師的思維方式91軟件架構 巨大的知識海洋門檻相對較高、職業(yè)生涯非常長相對獨立于技術的新陳代謝適合于喜歡學習的人斷學習、增加積累、注重經驗注意學習方法論、框架不斷增加各種系統(tǒng)架構的知識經驗積累非常重要在與高手和同行合作中提高水平與高手的合作是最佳途徑同行之間的交流也非常有效在每一個項目中進行創(chuàng)新成為軟件架構師的途徑92系統(tǒng)構架師負責領導和協(xié)調整個項目中的技術活動

49、。在個人綜合素養(yǎng)方面，系統(tǒng)構架師應該具有領導才能，能夠在壓力下作出關鍵性的決策并善始善終；能夠贏得項目經理、客戶、用戶群體以及管理團隊的認同和尊敬，尤其要善于和項目經理緊密協(xié)作；在各個方面都能展現(xiàn)出面向目標的實干作風。在專業(yè)技能方面，與其他角色相比，系統(tǒng)構架師通常具有全方位的技能，其見解重在廣度，而不是深度。系統(tǒng)架構師職責（1）93系統(tǒng)構架師不僅需要具備設計師的各項技能，而且應該具有問題領域和軟件工程領域的實踐經驗，從而有能力在無法獲得完整信息的情況下迅速領會問題并根據經驗作出審慎的判斷。如果項目較大，系統(tǒng)構架師將是一個團隊，上述的關鍵素質要求可由團隊成員來分擔，但其中要有一名系統(tǒng)構架師具有足

50、夠的權威。系統(tǒng)架構師職責（2）94設計師的工作對象通常是系統(tǒng)的局部或者細節(jié)。設計師應該掌握的技能包括：理解以Use Case建模技術捕獲和描述的軟件需求；在系統(tǒng)構架師的統(tǒng)一協(xié)調下，應用UML進行局部的面向對象分析和設計；了解主流的實施技術(程序設計語言和開發(fā)環(huán)境)。對比：設計師職責95例子1：中華英才網招聘“構架師”961) 分析掌握公司核心技術；2) 設計公司移動通訊基礎平臺架構；3) 與產品部配合研發(fā)新應用，并調整產品架構；4) 配合產品部與客戶或合作伙伴討論技術問題；5) 重大項目投標技術負責人；6) 領導系統(tǒng)工程師完成接口、協(xié)議、規(guī)范分析；7) 監(jiān)督指導系統(tǒng)工程師完成需求分析；8) 監(jiān)

51、督指導系統(tǒng)工程師完成產品技術白皮書；9) 參與評審其他相關技術文檔；10) 競爭對手分析；11) 新技術方向預研。工作職責971、四年以上移動通訊領域工作經驗，最近兩年從事系統(tǒng)架構設計。2、有大型電信軟件系統(tǒng)設計經驗或有大型數(shù)據挖掘軟件系統(tǒng)設計經驗3、有與運營商或國外專家技術交流經驗4、精通以下領域之一：移動通訊網絡/移動通訊增值業(yè)務/移動終端軟件。5、具有良好的系統(tǒng)方案設計能力6、具有良好的競爭對手分析能力7、具有行業(yè)技術發(fā)展方向預測把握能力8、能夠踏實工作，注重團隊協(xié)作9、具有良好的溝通協(xié)調能力10、英語口語流利，能夠用英文進行技術文檔的寫作任職要求98例子2：中華英才網招聘“構架師”99

52、The Technology Architect role is key to the future success in this area. Providing architectural vision for the future and helping ensure that developments in progress are fit-for-purpose, fit with system architecture directives and have a technical evolution plan to support future requirements. The

53、 Technology Architect also influences and reviews incoming requirements and actively participate in all stages of development particularly design review.Key Job Responsibilities（1）:100This position is within the Generic Applications and OS Services group and reports to the Engineering Manager in Bei

54、jing. Your role will contribute to the ongoing development and delivery of the Symbian OS, in particular within the Text and Internationalisation technology. Currently the team comprises of a team of Engineers, Architects, Project Managers and Engineering Managers. With the expansion into Beijing th

55、e team is now requires high caliber Engineers, a Project Manager and Technical Architect to ensure the continued success of the System Libraries team.Key Job Responsibilities（2）:101Working with the Strategic Product Managers and Engineering Manager to define the Roadmaps for the technology Technical

56、 owner of the this technology areaChampioning the technology (internally and externally) and attending relevant meetings, conferences and forumsCoaching and Mentoring engineersWorking with customers to define functional and non-functional requirementsArchitectural integrity and design quality of the

57、 componentsTake overall responsibility for the quality of the sub systemEnsuring subsystem product documentation is producedInvolvement with the development sub-projects to participate in reviews, advise upon estimates and support the Project ManagerAssessing Change RequestsMembership of the Core Te

58、am for the Technologies and also Technology Architects TeamKey Job Responsibilities（3）:102Bachelor/Master Degree in Computer Science, Software Engineering or Telecom related discipline.3+ years proven experience as a Software Architect for a technology area or product8+ years proven commercial exper

59、ience in the Software industry.The ability to demonstrate excellent practical and theoretical knowledge of C+Sound technical judgment and cost benefit analysis skills.Good influencing skills and people skills.Good understanding of software engineering and associated methods and practices.Proven expe

60、rience in all aspects of the Software Development Lifecycle from a known/established methodology.Liaising with both external and internal customers.Development of Technology Roadmaps inline with Customer and Business expectations.Solid software estimation/impact analysis skillsExcellent written and