軟件工程3軟件設計

場景互動我們了解了系統(tǒng)構成單元（模塊）構建的原則，那么如何將其有效地組織在一起，以什么樣的方式組織在一起呢？第一頁，共四十八頁。1.軟件體系結構的設計體系結構三要素程序構件（模塊）的層次結構構件之間交互的方式數(shù)據(jù)的結構第二頁，共四十八頁。構建體系結構的目的簡潔建立一個相對小的、易于理解的掌握的模型，并描述了系統(tǒng)如何構成以及其構建如何一起工作。擴展在系統(tǒng)能夠保持結構的穩(wěn)定的前提下很容易地擴充功能和提升性能；重用系統(tǒng)能夠重用以前的代碼和設計，從而提高開發(fā)效率；第三頁，共四十八頁。體系結構風格（模型）根據(jù)各子系統(tǒng)如何共享數(shù)據(jù)、如何分布、如何相互交互，可開發(fā)更加特定的風格（模型）。第四頁，共四十八頁。CatalogueserverVodioserverPictureserverHypertextserverCatalogueFilmclipfilesDigitizedphotographsHypertextwebWide-bandwidthnetwork

Client1Client2Client3Client4Film&Picturelibrarysystem的體系結構（1）客戶機–

服務器模型（C/S）第五頁，共四十八頁。描述典型的分布式系統(tǒng)模型合作的雙方都會利用各自的計算能力負責一定的計算工作，從而提高整個系統(tǒng)的能力和效率。組成部分一組功能各自獨立的服務器為其他子系統(tǒng)提供服務。如打印服務器,文件服務器,編譯服務器等。一組客戶機并發(fā)訪問多個服務器提供的服務。或存在一些客戶機可并發(fā)執(zhí)行的客戶機程序。一個網(wǎng)絡使得客戶機能夠訪問服務器。（1）客戶機–

服務器模型（C/S）第六頁，共四十八頁。兩層客戶/服務器結構系統(tǒng)的邏輯分層分別實現(xiàn)在不同的物理層（物理機器）上，通常將這種物理層次上的劃分稱為客戶端程序和服務器端程序邏輯分層與物理分層的映射胖客戶端結構客戶端負責用戶界面和應用邏輯部分，工作繁重瘦客戶端結構服務器端負責應用邏輯和數(shù)據(jù)訪問部分，客戶端工作簡單常被稱為B/S結構介于兩者之間客戶端增加了對用戶請求的處理第七頁，共四十八頁。兩層客戶/服務器結構第八頁，共四十八頁。三層/多層應用模型多層模型是兩層C/S模型的擴展應用邏輯部分被分離出來成為單獨的一層（或多層）這些中間層由一些完成應用業(yè)務功能的分布式對象組建構成第九頁，共四十八頁。三層客戶/服務器結構第十頁，共四十八頁。多層客戶/服務器結構第十一頁，共四十八頁。（2）分層系統(tǒng)模型（抽象機模型）OSI模型第十二頁，共四十八頁。（2）分層系統(tǒng)模型（抽象機模型）描述也稱為按服務進行劃分。層是對模型中不同抽象層次上的邏輯結構進行分組的一種特定方式。系統(tǒng)按照層次結構組織，每一層向它的上一層提供服務，同時又是它的下層的客戶。系統(tǒng)內(nèi)的交互限定在鄰接層之間。除了鄰接層，一個內(nèi)部層次對于其他外部層次是隱藏的。鄰接層的關系并不嚴格。第十三頁，共四十八頁。使用層有助于解決的問題源碼的變更波及整個系統(tǒng)；應用邏輯與用戶界面交織在一起，無法復用于其他不同界面或分布到其他處理結點之上；潛在的一般性技術服務或業(yè)務邏輯與更特定于應用的邏輯交織在一起，無法被復用、分布到其他結點或方便地使用不同實現(xiàn)進行替換；不同關注領域之間高度耦合，難以為不同開發(fā)者清晰地界定和分配任務。第十四頁，共四十八頁。信息系統(tǒng)邏輯架構中常見的層第十五頁，共四十八頁。ApplicationRDBMS職責：頁面表示邏輯、業(yè)務邏輯、數(shù)據(jù)訪問邏輯職責：永久保存數(shù)據(jù)、保證數(shù)據(jù)完整性J2EE實現(xiàn)范式：JSP內(nèi)含Java和JDBC代碼J2EE應用體系結構的演進（2層）第十六頁，共四十八頁。J2EE應用體系結構的演進（3層）RDBMSBusinesslogicPresentationlogicJ2EE實現(xiàn)范式：SunModel1（JSP+JavaBean）職責：頁面顯示+頁面跳轉+應用控制邏輯職責：核心業(yè)務操作第十七頁，共四十八頁。J2EE應用體系結構的演進（4層）RDBMSBusinesslogicControllerViewJ2EE實現(xiàn)范式：SunModle2(Jsp+Servlet+JavaBean/EJB)職責：頁面顯示職責：頁面跳轉+應用控制邏輯第十八頁，共四十八頁。J2EE應用體系結構的演進（5層）RDBMSBusinesslogicDAOControllerView職責：數(shù)據(jù)的CRUD操作+對象關系映射職責：核心業(yè)務操作第十九頁，共四十八頁。J2EE應用體系結構的演進（6層）VCMMVCFrameworkStruts、JSF、TepestryO/RMapperORMMiddleware：Hibernate、JDO、ApacheOJBDAO模式RDBMSBusinesslogicDAOORMControllerView第二十頁，共四十八頁。功能劃分與層次劃分之間的關系層次劃分是對構架的橫向分解，功能劃分是對構架的縱向分解。它們之間的關系，如圖所示。第二十一頁，共四十八頁。歡迎短信（3）基于事件的隱式調(diào)用風格第二十二頁，共四十八頁。（3）基于事件的隱式調(diào)用風格描述其思想是構件不直接調(diào)用一個過程，而是觸發(fā)或廣播一個或多個事件。系統(tǒng)中的其它構件中的過程在一個或多個事件中注冊，當一個事件被觸發(fā)，系統(tǒng)自動調(diào)用在這個事件中注冊的所有過程，這樣，一個事件的觸發(fā)就導致了另一模塊中的過程的調(diào)用。第二十三頁，共四十八頁。（4）數(shù)據(jù)流體系結構（管道和過濾器模型）Unix的Shell程序命令：catfile|grepxyz|sort|uniq>out第二十四頁，共四十八頁。該體系結構被用于當輸入數(shù)據(jù)被通過一系列計算或操縱構件變換為輸出數(shù)據(jù)情形。（4）數(shù)據(jù)流體系結構（管道和過濾器模型）第二十五頁，共四十八頁。用戶注冊功能的實現(xiàn)（5）數(shù)據(jù)抽象和面向?qū)ο箫L格第二十六頁，共四十八頁。（5）數(shù)據(jù)抽象和面向?qū)ο箫L格描述這種風格建立在數(shù)據(jù)抽象和面向?qū)ο蟮幕A上，數(shù)據(jù)的表示方法和它們的相應操作封裝在一個抽象數(shù)據(jù)類型或?qū)ο笾?。第二十七頁，共四十八頁。?shù)據(jù)設計的層次業(yè)務級應用級程序構件級2.數(shù)據(jù)設計第二十八頁，共四十八頁。數(shù)據(jù)設計的內(nèi)容數(shù)據(jù)結構的設計文件的設計數(shù)據(jù)庫的設計第二十九頁，共四十八頁。數(shù)據(jù)設計的原則在數(shù)據(jù)設計中也可以使用自頂向下、逐步細化的方法。底層數(shù)據(jù)設計的決策應該推遲到設計過程的后期進行數(shù)據(jù)設計時應遵從信息隱藏原則要確定所有數(shù)據(jù)結構，以及在每種數(shù)據(jù)結構上實施的操作應當創(chuàng)建一個存放數(shù)據(jù)結構和相關操作的庫第三十頁，共四十八頁。（1）數(shù)據(jù)結構設計數(shù)據(jù)結構是計算機存儲、組織數(shù)據(jù)的方式。數(shù)據(jù)結構是指相互之間存在一種或多種特定關系的數(shù)據(jù)元素的集合。數(shù)據(jù)結構設原則盡量使用簡單的數(shù)據(jù)結構在設計數(shù)據(jù)結構時要注意數(shù)據(jù)之間的關系加強數(shù)據(jù)設計的可復用性，應該針對常用的數(shù)據(jù)結構和復雜的數(shù)據(jù)結構設計抽象類型盡量使用經(jīng)典數(shù)據(jù)結構在確定數(shù)據(jù)結構時一般先考慮靜態(tài)結構對于復雜數(shù)據(jù)結構，應給出圖形和文字描述，以便于理解第三十一頁，共四十八頁。（2）文件設計文件設計定義：指對數(shù)據(jù)存儲文件的設計。文件的邏輯設計整理必需的數(shù)據(jù)元素分析數(shù)據(jù)間的關系確定文件記錄的內(nèi)容文件的物理設計理解文件的特性確定文件物理組織結構確定文件的存儲介質(zhì)確定文件的記錄格式估計記錄的存取時間估計文件的存儲量第三十二頁，共四十八頁。（3）數(shù)據(jù)庫設計數(shù)據(jù)庫設計數(shù)據(jù)庫設計的基本步驟（1）數(shù)據(jù)庫的概念結構設計（2）數(shù)據(jù)庫的邏輯結構設計（3）數(shù)據(jù)庫的物理結構設計第三十三頁，共四十八頁。數(shù)據(jù)庫的概念結構設計概念結構設計應在系統(tǒng)分析階段進行。任務是根據(jù)用戶需求設計數(shù)據(jù)庫的概念數(shù)據(jù)模型(簡稱概念模型)。概念模型是從用戶角度看到的數(shù)據(jù)庫，它可用E-R模型表示。數(shù)據(jù)庫的邏輯結構設計邏輯結構設計是將概念結構設計階段完成的概念模型轉換成能被選定的數(shù)據(jù)庫管理系統(tǒng)(DBMS)支持的數(shù)據(jù)模型。目前常見的是關系模型。第三十四頁，共四十八頁。數(shù)據(jù)庫的物理結構設計物理結構設計是為數(shù)據(jù)模型在設備上選定合適的存儲結構和存取方法，以獲得數(shù)據(jù)庫的最佳存取效率。物理結構設計的主要內(nèi)容包括:①庫文件的組織形式。如選用順序文件組織形式、索引文件組織形式等。②存儲介質(zhì)的分配。例如將易變的、存取頻繁的數(shù)據(jù)存放在高速存儲器上，穩(wěn)定的、存取頻度小的數(shù)據(jù)存放在低速存儲器上。③存取路徑的選擇等。第三十五頁，共四十八頁。將E-R模型轉換為關系模型的一般規(guī)則（1）每一實體集對應于一個關系模式，實體名作為關系名，實體的屬性作為對應關系的屬性。（2）實體間的聯(lián)系一般對應一個關系，聯(lián)系名作為對應的關系名，不帶有屬性的聯(lián)系可以去掉。（3）實體和聯(lián)系中關鍵字對應的屬性在關系模式中仍作為關鍵字。第三十六頁，共四十八頁。重數(shù)數(shù)據(jù)庫操作一對一為每個對象分別創(chuàng)建一個表每個表中的主碼也是相關表中的外碼一對多為每個對象分別創(chuàng)建一個表關聯(lián)中“一”這一側表的主碼是“多”那一側表的外碼多對多為每個對象分別創(chuàng)建一個表創(chuàng)建一個附加的交叉表每個對象對應的表的主碼在交叉表中都定義為外碼交叉表的主碼可以是單獨的特定一列（自動生成的代主碼），或者也可能是來自其他表的兩個外鍵的組合再加上一個有含義的標識符（如角色、類型）將重數(shù)映射到數(shù)據(jù)庫操作第三十七頁，共四十八頁。根據(jù)規(guī)則，將上圖轉換成對應的關系數(shù)據(jù)模型①學生(學號，姓名，性別，出生日期，籍貫)②課程(課程編號，課程名，學時，學分，教材名稱)③教師(教師編號，教師姓名，性別，出生日期，職稱，學歷，工作時間)④學習(學號，課程編號，成績)⑤教學(教師編號，課程編號，效果)第三十八頁，共四十八頁。3.用戶界面設計界面設計設計用戶界面就是設計輸入輸出，這些輸入輸出是指為了執(zhí)行一個任務，用戶與計算機系統(tǒng)之間進行的交互。我們側重于人和計算機交互的界面設計，即人機交互界面。人機交互像是用戶與計算機之間的對話，因此也把用戶界面設計稱為對話設計。第三十九頁，共四十八頁。界面設計的過程用戶界面設計就是設計系統(tǒng)，應在設計過程中及早開始考慮用戶界面。遵循一組界面設計原則，設計任務需標識界面對象和動作，然后創(chuàng)建屏幕布局，形成用戶界面原型的基礎。第四十頁，共四十八頁。界面設計八項黃金規(guī)則盡量保持一致性為熟練用戶提供快捷鍵提供有效反饋設計完整的對話過程提供簡單的錯誤處理機制允許撤銷動作提供控制的內(nèi)部軌跡減少短期記憶負擔第四十一頁，共四十八頁。（1）盡量保持一致性MicrosoftOffice系列軟件的界面易于記憶，容易學習第四十二頁，共四十八頁。（2）為熟練用戶提供快捷鍵AdobePhotoshop中提供的快捷方式減少用戶交互步驟，提高工作效率第四十三頁，共四十八頁。（3）提供有效反饋當當網(wǎng)配送過程追蹤提供有效的信息反饋，增強用戶的自信感。第四十四頁，共四十八頁。（4）設計完整的