架構(gòu)設(shè)計(jì)能夠滿足系統(tǒng)的品質(zhì)
系統(tǒng)的功能性是軟件構(gòu)架師通過(guò)組成體系架構(gòu)的多種元素之間的交互作用來(lái)支持的。然而,架構(gòu)設(shè)計(jì)的一個(gè)關(guān)鍵特性是,系統(tǒng)的品質(zhì)是通過(guò)某些手段來(lái)實(shí)現(xiàn)的。軟件的品質(zhì),例如性能,安全性和可維護(hù)性等,它們?cè)谌鄙俳y(tǒng)一的架構(gòu)設(shè)計(jì)視圖時(shí)是無(wú)法實(shí)現(xiàn)的,因?yàn)檫@些品質(zhì)并不是被限制在一個(gè)單一的架構(gòu)設(shè)計(jì)元素中,而是滲透在整個(gè)架構(gòu)設(shè)計(jì)體系中的。例如,為了滿足性能要求,可能需要考慮體系架構(gòu)中的每一個(gè)組件的實(shí)現(xiàn)時(shí)間,同時(shí)還要考慮各組件之間通訊所花費(fèi)的時(shí)間。同樣地,為了滿足安全性要求,可能需要考慮兩個(gè)組件之間自然的通訊,并且要在需要的特定的地方引入安全性提示組件。所有的這些關(guān)系都屬于體系架構(gòu),在上面的例子中,這些關(guān)系包括組件自身的和組件之間的。mda.com
一個(gè)和架構(gòu)設(shè)計(jì)相關(guān)的好處是,我們可以盡早的評(píng)估項(xiàng)目開(kāi)發(fā)周期中的這些品質(zhì)。架構(gòu)設(shè)計(jì)模型的建立,通常是為了明確的確定我們已經(jīng)滿足了這些品質(zhì)的要求。這是非常重要的,因?yàn)椴徽搶懺诩埳系捏w系架構(gòu)多么的完美,實(shí)現(xiàn)的軟件才是評(píng)價(jià)體系架構(gòu)是否達(dá)到這些品質(zhì)的要求的唯一標(biāo)準(zhǔn)。
架構(gòu)設(shè)計(jì)使我們達(dá)成一致的目標(biāo)
架構(gòu)設(shè)計(jì)的過(guò)程使得不同的涉眾達(dá)成一致的目標(biāo),因?yàn)榧軜?gòu)設(shè)計(jì)提供了一個(gè)辯論系統(tǒng)解決方案的媒體。為了支持這種辯論,體系架構(gòu)的過(guò)程需要確保架構(gòu)設(shè)計(jì)被清楚地傳達(dá)與理解。一個(gè)被有效傳達(dá)的體系架構(gòu)使得涉眾們可以辯論決議和權(quán)衡,反復(fù)討論,最終達(dá)成共識(shí)。相反,如果一個(gè)體系架構(gòu)沒(méi)有被有效的傳達(dá),那么這種辯論將不會(huì)發(fā)生。沒(méi)有了有效的傳達(dá),體系架構(gòu)所帶來(lái)的結(jié)果可能會(huì)是低品質(zhì)的。
在一條相關(guān)的說(shuō)明中,體系架構(gòu)可能會(huì)使構(gòu)架師之間或者新成員與老成員之間的辯論達(dá)成一致(以及他們之間的視圖)。我們需要再次強(qiáng)調(diào),只有體系架構(gòu)被有效傳達(dá),它所帶來(lái)的這個(gè)好處才能體現(xiàn)出來(lái)。清楚地了解他們正在做什么的開(kāi)發(fā)小組更可能按照需求完成產(chǎn)品的開(kāi)發(fā)。
為此,我再次強(qiáng)調(diào)恰當(dāng)?shù)奈臋n化體系架構(gòu)是非常重要的,這是軟件構(gòu)架師的主要職責(zé)。同樣的,一個(gè)架構(gòu)設(shè)計(jì)的概念證明是一個(gè)證明體系架構(gòu)是否滿足最初的需求的極好的方法。
架構(gòu)設(shè)計(jì)能夠支持計(jì)劃編制過(guò)程
架構(gòu)設(shè)計(jì)的過(guò)程支持一些步驟。很明顯,它支持設(shè)計(jì)和實(shí)現(xiàn)活動(dòng),因?yàn)轶w系架構(gòu)是直接使用到這些活動(dòng)中的。然而,在架構(gòu)設(shè)計(jì)過(guò)程所帶來(lái)的好處中,我們可以證明其中最主要的好處通常是那些和支持相關(guān)的,被提供給項(xiàng)目計(jì)劃和項(xiàng)目管理的活動(dòng),例如:細(xì)節(jié)化分,日程安排,工作分配,成本分析,風(fēng)險(xiǎn)管理和技能開(kāi)發(fā)等。架構(gòu)設(shè)計(jì)的過(guò)程可以支持所有這些相關(guān)內(nèi)容,這也正是軟件構(gòu)架師和項(xiàng)目經(jīng)理應(yīng)該擁有一種很密切關(guān)系的一個(gè)主要原因。這個(gè)支持的大部分來(lái)自于體系架構(gòu)確定的系統(tǒng)中重要的組件和它們之間關(guān)系的行為。請(qǐng)看圖1中的UML組件圖,它已經(jīng)為我們的討論作了簡(jiǎn)化。這個(gè)圖顯示了這四個(gè)組件之間的依賴性。
圖1:UML組件圖顯示了架構(gòu)設(shè)計(jì)中的重要元素
在日程安排方面,它們之間的依賴性暗示了每一個(gè)元素被考慮的順序。從一個(gè)實(shí)施透視圖來(lái)看,例如,依賴性告訴我們Error Log組件必須最先實(shí)現(xiàn),因?yàn)槠溆嗟乃薪M件都要使用它。Customer Management和Fulfillment組件可以同時(shí)實(shí)現(xiàn),因?yàn)樗鼈冎g不存在依賴關(guān)系。最后,一旦這兩個(gè)組件也被實(shí)現(xiàn)完了,那么Account Management組件就可以被實(shí)現(xiàn)了。通過(guò)這個(gè)信息,我們可以畫出甘特圖(項(xiàng)目經(jīng)理的一個(gè)主要計(jì)劃編制工具),如圖2所示。圖中顯示的每一個(gè)任務(wù)在實(shí)現(xiàn)時(shí)間時(shí)都需要一些思考,但是它們中的一部分可以于每一個(gè)架構(gòu)設(shè)計(jì)元素的復(fù)雜性。
圖2:基于架構(gòu)設(shè)計(jì)中重要元素之間依賴性的甘特圖
很明顯這是一個(gè)很多原因的總的簡(jiǎn)化。例如,所有這些元素都不可能作為一個(gè)單一的組件被實(shí)現(xiàn),但是這對(duì)于一個(gè)用例來(lái)說(shuō)太過(guò)復(fù)雜了。同樣,我們可以建立"存根的"或者部分的實(shí)現(xiàn),使得每一個(gè)元素的實(shí)現(xiàn)都能夠平行實(shí)現(xiàn)。我使用這個(gè)例子來(lái)簡(jiǎn)單的證明這個(gè)原理。
在工作分配中,體系架構(gòu)能夠再次幫助我們鑒別需要特定技能的區(qū)域,使得我們可以把工作分配給特定的資源(例如:人)。
構(gòu)架師還能協(xié)助估算項(xiàng)目成本。一個(gè)項(xiàng)目的成本來(lái)自多個(gè)方面。很明顯,任務(wù)的持續(xù)時(shí)間和分配給每一部分的資源將會(huì)決定勞動(dòng)力的成本。體系架構(gòu)同樣會(huì)幫助我們決定使用在交付的系統(tǒng)中的第三方組件的成本,以及支持開(kāi)發(fā)成果的所有工具的成本,因?yàn)闃?gòu)架師參與的活動(dòng)是一個(gè)經(jīng)過(guò)挑選的恰當(dāng)?shù)拈_(kāi)發(fā)環(huán)境,它允許設(shè)計(jì)人員,實(shí)現(xiàn)人員和其他小組成員使用同一個(gè)有效的方式一起工作。
構(gòu)架師的另外一個(gè)焦點(diǎn)是鑒別和管理項(xiàng)目的技術(shù)風(fēng)險(xiǎn)。技術(shù)風(fēng)險(xiǎn)的管理包括制定每一個(gè)風(fēng)險(xiǎn)的優(yōu)先次序,以及確定一個(gè)恰當(dāng)?shù)娘L(fēng)險(xiǎn)緩解策略。優(yōu)先權(quán)和風(fēng)險(xiǎn)緩解策略作為輸入部分提供給項(xiàng)目經(jīng)理。
最后,體系架構(gòu)確定離散組件的解決方案,它可以為項(xiàng)目提供所需的技術(shù)輸入。如果項(xiàng)目或者組織中沒(méi)有足夠可用的資源,那么它會(huì)明確的辨別出哪里需要技術(shù)支持。這可以通過(guò)現(xiàn)存的職員,或者外包,或者通過(guò)雇傭新職員來(lái)實(shí)現(xiàn)。