10軟件體系結構設計與構建

1、軟件體系結構設計與構建劉欽2013 秋1主要內(nèi)容體系結構設計體系結構構建 體系結構文檔化體系結構驗證2體系結構設計3體系結構設計過程（簡化版）邏輯設計.5.6.7.分析關鍵需求和項目約束；通過選擇體系結構風格；進行軟件體系結構邏輯（抽象）設計；依賴邏輯設計進行軟件體系結構（實現(xiàn)）設計；物理設計完善體系結構設計；添加構件接口； 迭代過程3-74體系結構設計過程.5.6.7.分析關鍵需求和項目約束；通過選擇體系結構風格；進行軟件體系結構邏輯（抽象）設計；依賴邏輯設計進行軟件體系結構（實現(xiàn)）設計； 完善體系結構設計；添加構件接口；迭代過程3-75體系結構需求簡單系統(tǒng)功能需

2、求非功能性需求質量性能約束接口項目約束復雜產(chǎn)品開發(fā)團隊市場大小項目預算項目進度項目風險開發(fā)環(huán)境開發(fā)技術商業(yè)產(chǎn)品6實踐案例1. 需求Use Case Mo. a) 概要功能需求:10 個功能 b) 非功能性需求 "$ 安全需求:Security13 約束:IC2 "$ 2. 項目約束 & a)開發(fā)技術:Java % #!b)時間較為緊張 c)開發(fā)人員:不熟悉 Web 技術7體系結構設計過程.5.6.7.分析關鍵需求和項目約束；通過選擇體系結構風格；進行軟件體系結構邏輯（抽象）設計；依賴邏輯設計進行軟件體系結構（實現(xiàn)）設計； 完善體系結構設計；添加構件接口

3、；迭代過程3-78實踐案例分層風格協(xié)議不變情況下易于修改能夠促進并行開發(fā)9體系結構設計過程1.2.3.分析關鍵需求和項目約束；通過選擇體系結構風格；進行軟件體系結構邏輯（抽象）設計；1.2.依據(jù)概要功能需求與體系結構風格建立初始設計使用非功能性需求與項目約束評價和改進初始設計.依賴邏輯設計進行軟件體系結構（實現(xiàn)）設計；完善體系結構設計； 添加構件接口；迭代過程3-710將需求分配到子系統(tǒng)和模塊考慮功能的相同性不同任務，但是相同功能考慮可復用性結構、數(shù)據(jù)、行為的可復用性11實踐案例Use Case Mo. 銷售與退貨 "$ 產(chǎn)品調(diào)整、入庫、出庫與庫存分析 "$

4、會員發(fā)展與禮品贈送 & % 銷售策略#! 12基本功能銷售庫存會員銷售策略用戶13銷售是否只用到Sale的數(shù)據(jù)14功能對應邏輯包銷售SalesUI, Sales, SalesData庫存CommodityUI, Commodity, CommodityData會員MemberUI, Member, MemberData銷售策略PromotionUI, Promotion, PromotionData調(diào)整用戶UserUI, User, UserData連鎖超市管理系統(tǒng)的改進概要功能設計15功能對應邏輯包銷售SalesUI, Sales, SalesData;Commodity, Comm

5、odityData; Member, MemberData; Promotion, PromotionData; User, UserData;庫存CommodityUI, Commodity, CommodityData Sales, SalesData會員MemberUI, Member, MemberData Sales, SalesDataCommodity, CommodityData銷售策略PromotionUI, Promotion, PromotionData調(diào)整用戶UserUI, User, UserData初步設計方案 一16初步設計方案二17體系結構設計過程1.2.3.分

6、析關鍵需求和項目約束；通過選擇體系結構風格；進行軟件體系結構邏輯（抽象）設計；1.2.依據(jù)概要功能需求與體系結構風格建立初始設計使用非功能性需求與項目約束評價和改進初始設計.依賴邏輯設計進行軟件體系結構（實現(xiàn)）設計；完善體系結構設計； 添加構件接口；迭代過程3-718初步設計的分析(1) 能夠滿足項目約束:分層風格能促進并行開發(fā),從而縮短開發(fā)時間;分層風格可以使用 Java 技術,而不使用 Web 技術。(2) 無法滿足安全需求(Security13)和網(wǎng)絡分布約束(IC2),所以需要改進:為使其滿足安全需求,可以增加用戶登錄與驗證功能,可以建立專門的三個模塊 (Presenta

7、tion、Logic、Data),也可以將該功能并入用戶管理功能, 即為 userui, user, userdata 三個模塊增加新的職責。為滿足網(wǎng)絡分布約束,需要將模塊分布到客戶端和服務器組成的網(wǎng)絡 上?？梢詫?Prensentation 層模塊部署在客戶端,將 Logic 層和 Data 層的模塊部署在服務器端。也可將 Prensentation 層和 Logic 層模塊部署在客戶端,將 Data 層的模塊部署在服務器端。一旦相鄰 兩層被部署到網(wǎng)絡兩端,那么它們之間的交互就無法通過程序調(diào)用來完成,可以考慮將簡單 的程序調(diào)用轉化為遠程方法調(diào)用 RMI。19連鎖超市管理系統(tǒng)最終的軟件體系結構

8、邏輯設計方案20體系結構設計過程.5.6.7.分析關鍵需求和項目約束；通過選擇體系結構風格；進行軟件體系結構邏輯（抽象）設計；邏輯設計物理包設計原則依賴邏輯設計進行軟件體系結構（實現(xiàn)）設計；完善體系結構設計； 添加構件接口；迭代過程3-7物理設計21Package Design PrinciplesReuse-Release Equivalency Principle Common Closure Principle Common Reuse PrincipleAcyclic Dependencies Principles Stable Dependencies Principl

9、esStable Abstractions PrinciplesCohesion Reuse && ChangeCoupling Compile &&Link22Reuse-Release Equivalency Principle (REP)重用發(fā)布等價原則The unit of reuse is the unit of release It is about reusing softwareReusable software is external software, you use it but somebody else maintains it.The

10、re is no difference between commercial and non-commercial external software for reuse.23REP in Project?Utility Package？ Tools Package？24REP SummaryGroup components (classes) for reusersSingle classes are usually not reusableSeveral collaborating classes make up a packageClasses in a package should f

11、orm a reusable and releasable moduleModule provides coherent functionalityReduces work for the reuser25Common Closure Principle (共同封閉原則)Classes which change together belong togetherMinimize the impact of change for the programmer.When a change is needed, it is good for the programmerif the change af

12、fects as few packages as possible, because of compile and link time and revalidation26in Project?接口數(shù)據(jù)傳遞對 象？數(shù)據(jù)持久化連接？27SummaryGroup classes with similar closure togetherpackage closed for anticipated changesConfines changes to a few packages Reduces package release frequencyReduces work for the progra

13、mmer28Common Reuse Principle (CRP)共同重用原則Classes in packages should be reused togetherPackages should be focused, users shoulduse all classes from a package29CRP SummaryGroup classes according to common reuseavoid unnecessary dependencies for usersFollowing the CRP often leads to splitting packagesGe

14、t more, smaller and more focused packagesReduces work for the reuser30Tradeoffs Betweenand CRPsimultaneously be satiThe CRP makes life easy for reusers, whereas the life easier for maintainers.makesThestrives to make packages as large as possible, whereasthe CRP tries to make packages very small.Ear

15、ly in a project, architects may set up the package structuresuch thatdominates and development and maintenance isaided. Later, as the architecture stabilizes, the architects mayrefactor the package structure to external reusers.ize CRP for the31The Acyclic Dependencies Principle (ACP)無環(huán)依賴原則The depen

16、dency structure for packages must be a Directed Acyclic Graph (DAG)Stabilize and release a project in piecesOrganize package dependencies in a top- down hierarchy32Dependencies are a DAG33Dependency Cycles Breaking a Cycle: 1st Way34Dependency Cycles Breaking a Cycle: 2nd Way35ACP in project?層次式風格和主

17、程序/子路徑風格通常不會發(fā)生面向對象式風格尤其要注意C/S的MVC風格可能會發(fā)生基于數(shù)據(jù)流、事件/消息、數(shù)據(jù)共享進行交互的體系結構風格通常不會發(fā)生36Stable Dependencies Principle (SDP)穩(wěn)定依賴原則Dependencies should point in the direction of stabilityStability:corresponds to effort required tochange a packageStable package: hard to change within the projectStability can be quan

18、tified37SDP Example38SDP in Project?39Stable Abstractions Principle (SAP)文檔抽象原則Stable packages should be abstract packages. Unstable packages should be concrete packages. Stable packages contain high level design.Making them abstract opens them for extension but closes them for modifications (OCP).S

19、ome flexibility is left in the stable hard-to- change packages.40包設計的過程迭代的過程先原則對把可能一同變化的類組織成包進行發(fā)布,隨著系統(tǒng)的不斷增長,我們開始關注創(chuàng)建可重用的元素,于是開始使用 CRP 和 REP 來指導包的組合。最后使用 ADP、SDP、SAP 對包圖進行度量，去掉不好的依賴。41SAP in Project?抽象接口包42體系結構設計過程.分析關鍵需求和項目約束；通過選擇體系結構風格；進行軟件體系結構邏輯（抽象）設計；依賴邏輯設計進行軟件體系結構（實現(xiàn)）設計；1.2.3.開發(fā)包(構件)設計運行時

20、的進程物理部署5.6.7.完善體系結構設計；添加構件接口； 迭代過程3-743初始物理包44(1) Presentation 層與 Logic 層被置于客戶端,Data 層被置于服務器端,那么 Logic 層的開發(fā)包依賴于 Data 層的開發(fā)包是不可能的。a) 可以考慮使用 RMI 技術,RMI 技術會將 Data 層開發(fā)包分解為置于客戶端的dataservice 接口包和置于服務器的 data 開發(fā)包。這樣一來,Logic 層開發(fā)包依賴于 dataservice 包,dataservice 和 data 層的開發(fā)包都依賴于 RMI 類庫包。(2) 所有的 Data 層開發(fā)包都需要進行數(shù)據(jù)持久

21、化(例如讀寫數(shù)據(jù)庫、讀寫文件等),所以它們會有一些重復代碼,可以將重復代碼獨立為新的開發(fā)包然后所有的Data 層開發(fā)包都依賴于databaseutility,databaseutility 會依賴于JDBC 類庫包或者 IO 類 庫包。細節(jié)考慮45(3) 所有的 Presentation 層開發(fā)包都需要使用圖形類型建立界面,都要依賴于圖形界 面類庫包。(4) 此外,Presentation 層實現(xiàn)時,由mainui 包負責整個頁面之間的跳轉邏輯。其它 各包負責各自頁面自身的功能。細節(jié)考慮465) 在分層風格的典型設計中,不希望高層直接依賴于低層,而是為低層建立接口包, 實現(xiàn)依賴倒置原則(參見1

22、5.2.3),所以應該調(diào)整為:各Prensentatin 層開發(fā)包(調(diào) 用)依賴于Logic 層接口包 businesslogicaservice 包,Logic 層開發(fā)包(實現(xiàn))依賴 于Logic 層接口包 businesslogicaservice 包。(6) 在分層風格的典型設計中,Presentation 層與 Logic 層之間、Logic 層與 Data 層之 間可能會傳遞復雜數(shù)據(jù)對象,那么相鄰兩層都需要使用數(shù)據(jù)對象聲明,所以需要將 數(shù)據(jù)對象聲明單獨獨立為開發(fā)包(VO 包與 PO 包),或者將數(shù)據(jù)對象聲明放入接口 包(VO 包放入 Logic 接口包,PO 包獨立)。細節(jié)考慮47(

23、7) 開發(fā)包的循環(huán)依賴現(xiàn)象需要消除,對此可以使用依賴倒置原則(參見 15.2.3) 將 循環(huán)依賴變?yōu)閱蜗蛞蕾?a) Sales與Commodity:將部分Commodity類抽象接口commodityInfoService置入Sales 包,這樣 Commodity 單向依賴于 Sales(實現(xiàn)接口+調(diào)用)。b) Sales 與 Member:將部分 Member 類抽象接口置入 Sales 包,這樣Member 單向依賴于 Sales(實現(xiàn)接口+調(diào)用)。(8) 在 Logic 層中,一些關于初始化和業(yè)務邏輯層上下文的工作被分配到 utilitybl包中去。細節(jié)考慮48連鎖超市管理系統(tǒng)開發(fā)包圖

24、(客戶端)49連鎖超市管理系統(tǒng)開發(fā)包圖(服務器端)50進程圖51部署圖52體系結構設計過程.5.分析關鍵需求和項目約束；通過選擇體系結構風格；進行軟件體系結構邏輯（抽象）設計；依賴邏輯設計進行軟件體系結構（實現(xiàn)）設計； 完善體系結構設計；1.2.完善軟件體系結構設計細化軟件體系結構設計6.7.添加構件接口；迭代過程3-753常見完善的方面：啟動、現(xiàn)場初始化、監(jiān) 控、環(huán)境建立與維護、清理現(xiàn)場完善啟動和網(wǎng)絡鏈接54細化salesbl模塊55數(shù)據(jù)定義接口的數(shù)據(jù)對象關鍵類的重要數(shù)據(jù)結構VO 、POJO56Java EntitiesAn entity is an object that r

25、epresents a persistent business entity such as an account or a customer.No logic / business methodsEntities must persist between the sessions or transactions that use them.Entities are stored in files or databases Entities are beansSimple or EJB.57POJO（Plain Old Java Objects）= Simple Java EntitiesEx

26、ample: AEntitypublic classextends Entity private String first; private String last;private Address address; private Phone phone;public Phone getPhone() return phone; public void setPhone(Phone p) phone = p; / etc.58Value ObjectsA value object holds the attributes of one or more entities in public fi

27、elds.Pass value objects, not entities, between layers.Implementation of Serializable should be consideredValue objects can update and create entities. Entities can create value objects.59Example:VOpublic classVO extends ValueObject public String first;public String last; public int addressOid; publi

28、c String street;public String apartment; public String city;public String state ; public String zip; public int phoneOid; public String phone; public void update(per) . () . publicmake60Address Book Entities61項目實踐VO :View層與Logic之間的數(shù)據(jù)傳遞Customer(VIP)VO、CommodityVO、SaleLineItemVO、PaymentVO、GiftVOPOJO：L

29、ogic與Data層之間的數(shù)據(jù)傳遞SalesPO、SaleLineItemPO、CustomerPO、CommodityPO、PaymentPO、GiftPO62持久化對象 UserPO的細化public class UserPO implements Serializable int id;String name; String password; UserRole role;public UserPO(int i, String n, String p, UserRole r) id = i; name = n; password = p; role = r;public String g

30、etName() return name;public int getID() return id;public String getPassword() return password; public UserRole getRole() return role;63數(shù)據(jù)持久化的細化64體系結構設計過程.5.6.7.分析關鍵需求和項目約束；通過選擇體系結構風格；進行軟件體系結構邏輯（抽象）設計；依賴邏輯設計進行軟件體系結構（實現(xiàn)）設計； 完善體系結構設計；添加構件接口；迭代過程3-765構件初步設計根據(jù)分配的需求確定模塊對外接口初步設計關鍵類編寫接口規(guī)范66確定模塊對外接口67

31、接口規(guī)范示例編寫接口規(guī)范68體系結構構件69體系結構構建包創(chuàng)建重要文件的創(chuàng)建定義構件之間的接口關鍵需求的實現(xiàn)70包的創(chuàng)建71重要文件的創(chuàng)建可選數(shù)據(jù)文件系統(tǒng)文件配置文件72文件列表73SalesBLService的定義public interface SalesBLService /銷售界面得到商品和商品促銷的信息public CommodityVO getCommodityByID(int id); public ArrayList<CommodityPromotionVO>getCommodityPromotionListByID(intcommodityID);/銷售界面得到會

32、員的信息public MemberVO getMember ();/銷售的步驟public ResultMessage addMember(int id);public ResultMessage addCommodity(int id, int quantity); public doublegetTotal(int mode);public double getChange(double payment); public void endSales();74關鍵需求的實現(xiàn)實現(xiàn)一些關鍵功能需求。比如連鎖超市系統(tǒng)中銷售用例就是 一個最關鍵的用例。它所覆蓋的面最廣,如果銷售用例可以實現(xiàn)的話,其它

33、用例的實現(xiàn)就比 較有信心了。而且這個需求需要做到端到端的實現(xiàn)。比如,連鎖超市系統(tǒng)中存在客戶端和服務器端。那么我們就需要在客戶端通過GUI 界面 發(fā)出指令,通過客戶端的業(yè)務邏輯處理,訪問服務器端的數(shù)據(jù),對數(shù)據(jù)進行修改。只有這樣 才能表明當前的體系結構可以勝任功能性需求。對原型的非功能性指標進行估算和驗證。如果出 現(xiàn)不符合非功能性需求和項目約束的情況,我們還需要重新對體系結構設計進行調(diào)整。比如,連鎖超市系統(tǒng)中我們用文件來保存數(shù)據(jù),而當數(shù)據(jù)越來越多,特別是銷售記 錄要 保存 1 年。這時候,客戶端跨網(wǎng)絡對服務器上文件的查找就比較慢,可能會使得我們不滿足 實時性的要求。這時候,可能我們就要調(diào)整體系結構

34、中數(shù)據(jù)存儲的方案,比如換成數(shù)據(jù)庫。 或者在客戶端的邏輯層和數(shù)據(jù)層之間,加設數(shù)據(jù)映射層。在客戶端運行初始化時,將數(shù)據(jù)從 服務器端載入到客戶端的內(nèi)存中去。75體系結構集成與測試76集成的策略當體系結構中原型各個模塊的代碼都編寫完成并經(jīng)過單元測試之后,需要將所有模塊組 合起來形成整個軟件原型系統(tǒng),這就是集成。集成的目的是為了逐步讓各個模塊合成為一個 系統(tǒng)來工作,從而驗證整個系統(tǒng)的功能、性能、可靠性等需求。對于被集成起來的系統(tǒng)一般 主要是通過其暴露出來的接口,偽裝一定的參數(shù)和輸入,進行黑盒測試。根據(jù)從模塊之間集成的先后順序,一般有下列幾種常見的集成策略:大爆炸式增量式自頂向下式自底向上式三明治式持續(xù)集

35、成77自頂向下集成的優(yōu)點:ll按深度優(yōu)先可以首先實現(xiàn)和驗證一個完整的功能需求;只需最頂端一個驅動(Driver);llll利于故障。自頂向下集成的缺點:llll樁的開發(fā)量大;底層驗證被推遲,且底層組件測試不充分。自頂向下78自底向上集成的優(yōu)點:是對底層組件行為較早驗證; 底層組件開發(fā)可以并行;樁的工作量少;利于故障。自底向上集成的缺點: 驅動的開發(fā)工作量大;對的驗證被推遲,設計上的錯誤不能被及時發(fā)現(xiàn)。自頂向下79持續(xù)集成一種增量集成方法,但它提倡盡早集成和頻繁集成。盡早集成是指不需要總是等待一個模塊開發(fā)完成才把它集成起來,而是在開發(fā)之初就利 用Stub 集成起來。頻繁集成是指開發(fā)者每次完成一些開發(fā)任