詳細設計信息系統(tǒng)分析與設計

第11章

詳細設計本章內容先導案例概述11.1

數(shù)據庫設計11.2

用戶界面設計11.3

系統(tǒng)界面設計要點回顧閱讀章節(jié)要求2/5/2023211章詳細設計先導案例AviationElectronic的界面設計2/5/2023311章詳細設計概述UML模型向關系模型的映射。系統(tǒng)界面處理需要少量人員干預的輸入和輸出;用戶界面處理需要人員直接參與的輸入和輸出。設計指導原則有助于確保系統(tǒng)的可用性。2/5/2023411章詳細設計11.1數(shù)據庫設計11.1.1

主鍵的生成11.1.2

屬性類型到域的映射11.1.3

類的屬性到列的映射11.1.4

類到表的映射11.1.5

關聯(lián)關系的映射2/5/2023511章詳細設計11.1.1主鍵的生成1.將對象標識符映射為主鍵2.

將對象的某些屬性映射為主鍵2/5/2023611章詳細設計1.將對象標識符映射為主鍵在將UML中的類映射為RDB中的表時，每張表中都增加一個對象標識符列，該對象標識符列作為表的主鍵。在將UML模型中關聯(lián)關系映射為RDB中的關聯(lián)表時，關聯(lián)表的主鍵由與該關聯(lián)關系相關的類的標識符組成。缺點：在DB維護時很難看出基于對象標識符的主鍵具有什么內在的含義。2/5/2023711章詳細設計帶有關聯(lián)類的大學課程注冊類圖2/5/2023811章詳細設計2.將對象的某些屬性映射為主鍵將類的某些屬性映射為RDB中表的主鍵。該方法得到的主鍵具有一定的內在含義，從而為DB的調試和維護提供了方便。但這種主鍵的修改比較困難，它們的修改可能要涉及到許多外鍵的修改。2/5/2023911章詳細設計11.1.2屬性類型到域的映射屬性類型是UML術語，對應于DB的域。簡單域非常容易實現(xiàn)，只需定義相應的數(shù)據類型和大小。每個使用了域的屬性，在映射時可能需要為每個域約束加入一條SQL的Check查詢子句來表示在域上的約束(如限定域的取值范圍等)。簡單域例：名字(name)和電話號碼(phone-Number)。2/5/20231011章詳細設計11.1.3類的屬性到列的映射UML模型中類的屬性映射為RDB表中的零列或幾列。一般地，可將類的屬性直接映射成表的一個字段。注意兩種特殊情況：①并不是類中的所有屬性均是永久的(發(fā)票中的“合計”屬性)。②當UML類的一個屬性本身就是對象時要將它映射為DB表中的幾列(Customer中包含一個作為其屬性的Address對象)。2/5/20231111章詳細設計11.1.4類到表的映射1.所有的類均映射為DB中的表2.具有屬性的類映射為DB表3.將超類的屬性下移4.將子類的屬性上移2/5/20231211章詳細設計1.所有的類均映射為DB中的表為每個超類和子類都創(chuàng)建一張表，這些表共享一個公共的主鍵。2/5/20231311章詳細設計Pilot

flightRating

FlightAttendant

EmployeeNametaxpayerNumberFlightAttendanttableEmployeetablePilottableemployeeIDnametaxpayerNumberemployeeTypePilotID(referencesEmployee)flightRatingflightAttendantID(referencesEmployee)2/5/20231411章詳細設計2.具有屬性的類映射為DB表所有具有屬性的類才映射為DB表，無屬性的類不進行映射。與上一種方法相比，該方法減少了DB表的數(shù)量，其他方面與上一種方法大致相同。2/5/20231511章詳細設計employeeIDnametaxpayerNumberemployeeTypePilotflightRating

FlightAttendant

EmployeeNametaxpayerNumberEmployeetablePilotID(referencesEmployee)flightRatingPilottable2/5/20231611章詳細設計3.將超類的屬性下移每個子類對應的DB表中既包含該子類中的屬性，也包含該子類所繼承的屬性。超類不映射為DB表，減少DB表的數(shù)量。2/5/20231711章詳細設計PilotflightRating

FlightAttendant

EmployeeNametaxpayerNumberpilotIDnametaxpayerNumberflightRatingflightAttendantIDnametaxpayerNumberPilot

tableFlightAttendanttable2/5/20231811章詳細設計4.將子類的屬性上移將所有子類的屬性都存放在超類所對應的DB表中。一個完整的類層次結構只映射為一張DB表，而層次結構中所有類的所有屬性都存儲在這張DB表中。避免了將眾多的子類映射為DB表，從而減少DB表的數(shù)量。2/5/20231911章詳細設計PilotflightRating

FlightAttendant

EmployeeNametaxpayerNumberemployeeIDnametaxpayerNumberemployeeTypeflightRatingEmployeetable2/5/20232011章詳細設計11.1.5關聯(lián)關系的映射1.多對多關聯(lián)的實現(xiàn)2.一對多關聯(lián)的實現(xiàn)3.零或一對一關聯(lián)的實現(xiàn)4.一對一關聯(lián)的實現(xiàn)5.UML模型的映射實例2/5/20232111章詳細設計四種類間的關聯(lián)可選對可選(0..1:0..*)強制對可選(1:0..*)可選對強制(0..*:1)強制對強制(1..*:l..*)2/5/20232211章詳細設計1.多對多關聯(lián)的實現(xiàn)[可選對可選(0..1:

0..*)]引入關聯(lián)表。關聯(lián)表是一張獨立的表，它用于在RDB中維護兩張或多張表之間的關聯(lián)。在RDB中，關聯(lián)表中包含的屬性通常是關系中涉及到的表中的鍵的組合。關聯(lián)表的名字通常是它所關聯(lián)的表的名字的組合，或者是它實現(xiàn)的關聯(lián)的名字。2/5/20232311章詳細設計flightID…FlightAttendantID…Flight

FlightAttendant

0..*AttendantAssignment0..*flightID(referencesFlight)FlightAttendantID(referencesFlightAttendant)FlighttableFlightAttendanttableAttendantAssignmenttable2/5/20232411章詳細設計2.一對多關聯(lián)的實現(xiàn)[強制對可選(1:0..*)]可將外鍵放置在“多”的一方，角色作為外鍵屬性名的一部分。外鍵的空與非空由對1的強制性決定。也可用關聯(lián)表實現(xiàn)。使用關聯(lián)表可使DB應用程序具有更好的擴展性。但另一方面，關聯(lián)表增加了RDB中表的數(shù)目，并且它不能使一方的最小重復性強制為1。2/5/20232511章詳細設計FlightPilot10..*copilot外鍵放在“多”方flightID…copilot(referencesPilot)PilotID…PilottableFlighttable2/5/20232611章詳細設計使用關聯(lián)表flightID…PilotID…flightID(referencesFlight)copilot(referencesPilot)FlighttablePilottableFlight-copilottableFlightPilot10..*copilot2/5/20232711章詳細設計3.“零或一”對一關聯(lián)的實現(xiàn)[可選對強制

(0..*:

1)]可將外鍵放置在可選的一端該外鍵不能為空值2/5/20232811章詳細設計CompanyIDcompanyNamedataFounded0..11CompanyCompanyNamedateFoundedBoardOfDirectorsmaxBoardSizeCompanytableBoardOfDirectorstableboardOfDirectorIDmaxBoardSizeCompanyID(referencesCompany)2/5/20232911章詳細設計4.一到一關聯(lián)的實現(xiàn)[強制對強制(1..*:l..*)]在實現(xiàn)這種關聯(lián)時，可將外鍵放置在任意一邊，具體情況依賴于性能等因素。2/5/20233011章詳細設計5.UML模型的映射實例

航空公司的類圖

0..*PilotflightRating

FlightAttendant

EmployeeNametaxpayerNumber0..*1Copilotpilot

0..*0..*0..*0..*1ScheduleAttendantAssignment1EmployeeTypeFlightflightNumdateAirlineNamesymbol12/5/20233111章詳細設計航空公司的數(shù)據庫表AirlineAirlineIDNamesymbolFlightflightIDflightNumdateairlineIDpilotcopilotEmployeeEmployeeIDnametaxpayerNumberemployeeTypeairlineIDFlightAttendantflightAttendantIDPilotpilotIDflightRatingAttendantAssignmentflightIDflightAttendantID2/5/20233211章詳細設計CREATETABLEAirline(airlineIDintegerCONSTRAINTnn_airline1NOTNULL,nametext(40)CONSTRAINTnn_airline2NOTNULL,symboltext(10)CONSTRAINTnn_airline3NOTNULL,CONSTRAINTPrimaryKeyPRIMARYKEY(airlineID),CONSTRAINTuq_airline1UNIQUE(name),CONSTRAINTuq_airline2UNIQUE(symbol));CREATETABLEFlight(flightIDintegerCONSTRAINTnn_flight1NOTNULL,flightNumtext(10)CONSTRAINTnn_flight2NOTNULL,datedateTimeCONSTRAINTnn_flight3NOTNULL,airlineIDintegerCONSTRAINTnn_flight4NOTNULL,pilotintegerCONSTRAINTnn_flight5NOTNULL,copilotintegerCONSTRAINTnn_flight6NOTNULL,CONSTRAINTPrimaryKeyPRIMARYKEY(flightID));ALTERTABLEFlightADDCONSTRAINTfk_flight1FOREIGNKEY(airlineID)REFERENCESAirlineONDELETENOACTION;ALTERTABLEF1ightADDCONSTRAINTfk_flight2FOREIGNKEY(pilot)REFERENCESPilotONDELETENOACTION;ALTERTABLEFlightADDCONSTRAINTfk_flight3FOREIGNKEY(copilot)REFERENCESPilotONDELETENOACTION;CREATEINDEXindexflight1ONFlight(airlineID);CREATEINDEXindexflight2ONFlight(pilot);CREATEINDEXindexflight3ONF1ight(copilot);CREATETABLEEmployee(employeeIDintegerCONSTRAINTnn_employee1NOTNULL,nametext(40)CONSTRAINTnn_employee2NOTNULL,taxpayerNumbertext(20)CONSTRAINTnn_employee3NOTNULL,employeeTypetext(20)CONSTRAINTnn_employee4NOTNULL,airlineIDintegerCONSTRAINTnn_employee5NOTNULL,CONSTRAINTPrimaryKeyPRIMARYKEY(employeeID));ALTERTABLEEmployeeADDCONSTRAINTfk_employee1FOREIGNKEY(airlineID)REFERENCESAirlineONDELETENOACTION;CREATEINDEXindex_employee1ONEmployee(airlineID);CREATETABLEPilot(pilotIDintegerCONSTRAINTnn_pilot1NOTNULL,flightRatingtext(40),CONSTRAINTPrimaryKeyPRIMARYKEY(pilotID));ALTERTABLEPilotADDCONSTRAINTfk_pilot1FOREIGNKEY(pilotID)REFERENCESEmployeeONDELETECASCADE;CREATETABLEF1ightAttendant(flightAttendantIDintegerCONSTRAINTnn_flightAttendant1NOTNULL,CONSTRAINTPrimaryKeyPRIMARYKEY(flightAttendantID));ALTERTABLEFlightAttendantADDCONSTRAINTfk_flightAttendant1FOREIGNKEY(flightAttendantID)REFERENCESEmployeeONDELETECASCADE;CREATETABLEAttendantAssignment(flightIDintegerCONSTRAINTnn_attendantAssignment1NOTNULL,flightAttendantIDintegerCONSTRAINTnn_attendantAssignment2NOTNULL,CONSTRAINTPrimaryKeyPRIMARYKEY(flightID,flightAtten_dantID));ALTERTABLEAttendantAssignmentADDCONSTRAINTfk_attendantAssignment1FOREIGNKEY(flightID)REFERENCESFlightONDELETECASCADE;ALTERTABLEAttendantAssignmentADDCONSTRAINTfk_attendantAssignment2FOREIGNKEY(fliqhtAttendantID)REFERENCESFlightAttendantONDELETENOACTION;CREATEINDEXindex_attendantAssignment1ONAttendantAssignment(flightAttendantID);航空公司的數(shù)據庫表2/5/20233311章詳細設計遍歷航空公司UML類圖的表達式及相應SQL代碼表達式含義SQL代碼anAirline.Employee找出一條航線上的所有雇員SELECTemployeeIDFROMEmployeeWHEREairlineID=:anAirline；anAirline.E找出一條航線上所有雇員的名字SELECTnameFROMEmployeeWHEREairlineID=:anAirline;anAirline.Flight

[getMonth(date)=aMonth].pilot找出一條航線上指定月份內飛行的所有飛行員SELECTpilotID

FROMFlightWHEREairlineID=:anAirlineANDgetMonth(date)=:aMonth;anAirline.Flight[getMonth(date)==aMonth].pilot[flightRating==aFlightRating]找出一條航線上指定月份內飛行且達到指定飛行出勤率的所有飛行員SELECTP.pilotIDFROMFlightF，pilotPWHEREF.airlineID=:anAirline

ANDgetMonth(F.date)=:aMonthANDF.pilotID=P.pilotIDANDP.flightRating=:aFlightRating；AFlight.copilot:E找出一個班機的副駕駛員SELECTE.nameFROMFlightF,PilotP,EmployeeEWHEREF.flightID=:aFlightANDF.copilotID=P.pilotIDANDP.pilotID=E.employeeID;對象模型的遍歷表達式2/5/20233411章詳細設計對象模型的遍歷表達式使用UML對象約束語言OCL來說明。圓點(.)：表示從一個對象定位到另一個對象，或表示從對象定位到屬性；方括號([])：說明對象集合上的過濾條件；冒號(:)：表示泛化關系的遍歷。程序變量以冒號開頭。2/5/20233511章詳細設計11.2

用戶界面設計11.2.1

輸入和輸出的識別與分類11.2.2

理解用戶界面11.2.3

界面設計指導原則11.2.4

對話設計文檔化11.2.5

窗體設計指導原則11.2.6

網站設計指導原則2/5/20233611章詳細設計11.2.1輸入和輸出的識別與分類1.傳統(tǒng)和OO的輸入和輸出2.用戶界面與系統(tǒng)界面2/5/20233711章詳細設計1.傳統(tǒng)和OO的輸入和輸出傳統(tǒng)方法中，在關聯(lián)圖、DFD片斷和細節(jié)DFD中的數(shù)據流中有I/O。在列出所有數(shù)據元素的數(shù)據流定義中詳細描述每一項I/O。設計階段，當決定設計方案時系統(tǒng)分析員根據所做出的決定會增加更多有關數(shù)據流的細節(jié)。2/5/20233811章詳細設計RMO訂單子系統(tǒng)的關聯(lián)圖2/5/20233911章詳細設計課程注冊系統(tǒng)的DFD片段2/5/20234011章詳細設計OO方法中I/O被定義為進入和離開系統(tǒng)的消息。I/O分別對應于事件表中事件的觸發(fā)器和響應。一個場景中交換的消息詳細定義I/O，且隨每一場景設計越發(fā)細化，消息的內容也越加確定。交互圖、設計類圖的方法和狀態(tài)圖表中。

2/5/20234111章詳細設計RMO客戶支持系統(tǒng)的完整事件表2/5/20234211章詳細設計完成的查詢對象有效性的三層設計2/5/20234311章詳細設計“查詢可用條目”的協(xié)作圖2/5/20234411章詳細設計Order類的方法

Order-orderID:intrger-orderDate:date-prioityCode:string-shipping&Handling:float-tax:float-grandTotal:float+createOrder(accountNo)+addItem(catalogID，prodID，size，quantity):orderItem+completeOrder():float+makePayment(ccInformation)2/5/20234511章詳細設計2.用戶界面與系統(tǒng)界面無論傳統(tǒng)設計還是OO設計方法中，系統(tǒng)設計的一個關鍵步驟是將每一事件的I/O分類劃分到系統(tǒng)界面或用戶界面中。將二者的設計分開，是因為兩種設計需要不同的專業(yè)知識和技術。

⑴系統(tǒng)界面

⑵用戶界面2/5/20234611章詳細設計⑴系統(tǒng)界面系統(tǒng)中包含最少量人員干預的I/O部分。

輸入：由特定的輸入設備(如掃描儀)來自動捕獲的輸入數(shù)據或者來自其他系統(tǒng)的電子消息，或是來自其他系統(tǒng)的批處理編譯過程。輸出：主要是向其他系統(tǒng)發(fā)送消息或信息，或者它們是在無人員干預的情況下為外部代理或角色生成報告、陳述或文檔等內容。2/5/20234711章詳細設計⑵用戶界面IS中需要用戶交互的I/O部分。需要系統(tǒng)用戶更直接干預的I/O。一個用戶界面能夠使用戶通過與計算機進行交互而記錄一個事務。2/5/20234811章詳細設計例如：一個客戶服務代表為一位RMO顧客記錄一份電話訂單。有時候，在用戶交互之后產生輸出，例如，在用戶查詢訂單狀態(tài)后相關信息會被顯示出來。在基于Web的系統(tǒng)中，一個客戶可直接與系統(tǒng)進行交互從而得到信息、下達訂單或查詢訂單狀態(tài)等。2/5/20234911章詳細設計11.2.2理解用戶界面0.人-機交互(HCI)

1.用戶界面的物理特征2.用戶界面的感知特征3.用戶界面的概念特征4.以用戶為中心的設計技術5.人-機界面研究領域6.有關HCI的隱喻2/5/20235011章詳細設計0.人-機交互(HCI)對最終用戶及其與計算機交互的研究。對系統(tǒng)的最終用戶來講，用戶界面就代表了系統(tǒng)本身。設計用戶界面就是設計系統(tǒng)。2/5/20235111章詳細設計用戶界面的物理、感知和概念特征

2/5/20235211章詳細設計1.用戶界面的物理特征包括：用戶實際接觸到的設備，即鍵盤、鼠標、觸摸屏或數(shù)字鍵盤，但界面的其他物理部分包括參考手冊、打印文檔、數(shù)據輸入窗體等一些用戶利用計算機完成任務時所涉及的內容。桌面空間、文檔、照明，以及計算機的終端硬件即組成了這位終端用戶的物理界面。2/5/20235311章詳細設計2.用戶界面的感知特征包括：用戶看到、聽到、觸摸到的所有東西(物理設備除外)。能見到的包括：顯示在屏幕上的所有數(shù)據和指令，如圖形、線條、數(shù)字和文字。能依賴于系統(tǒng)合成的聲音，即使是用于表示擊鍵和確認功能選擇的蜂鳴聲和咔嗒聲。2/5/20235411章詳細設計3.用戶界面的概念特征包括：用戶了解的有關系統(tǒng)使用的所有內容，即用戶正在操作的系統(tǒng)中所有問題域中的“事物”，系統(tǒng)所執(zhí)行的操作以及隨后的操作實施過程。用戶模型：用戶對所使用系統(tǒng)了解的內容，包括用戶正在操縱的問題域“事物”、系統(tǒng)所執(zhí)行的操作，以及隨后的任務實施過程。2/5/20235511章詳細設計4.以用戶為中心的設計技術將用戶放在開發(fā)過程中心地位的技術集合。該設計技術強調三個原則：及早關注用戶及其工作多次評價系統(tǒng)設計以確保其可用性使用迭代開發(fā)方法2/5/20235611章詳細設計可用性學習和使用系統(tǒng)的容易程度。自解釋型的系統(tǒng)：擁有大量表單、對話框、廣泛提示信息和指導信息的基于菜單的應用程序。適用于那些用戶并不經常使用的系統(tǒng)。但如果是辦公室職員整天都在使用的系統(tǒng)，設計的重點應該放在界面的快速切換和靈活性方面，應該有包括快捷鍵、熱鍵、大信息量屏幕顯示等方面的設計。2/5/20235711章詳細設計5.人-機界面研究領域人為因素工程(人體工程學)：對人與機器的交互作用的一般研究。用戶界面設計技術和HCI的研究領域起源于人為因素工程或人體工程學。對人為因素的正式研究始于二戰(zhàn)期間，即宇航工程師研究戰(zhàn)斗機駕駛艙控制器的不同排列方式對飛行員影響的時候。飛行員出錯即是宇航工程師所認為的“人為因素”。

2/5/20235811章詳細設計6.有關HCI的隱喻有關HCI的看法，通常稱為隱喻或類比。每一個隱喻都是對不同的概念給出一個類比，都是對用戶界面的設計給出暗示。

⑴直接操縱隱喻

⑵桌面隱喻

⑶文檔隱喻

⑷對話隱喻2/5/20235911章詳細設計⑴直接操縱隱喻

告訴我們用戶能直接與顯示屏幕上的對象進行交互。與用戶交互的對象在屏幕上是可見的，用戶可以用鼠標或方向鍵指向并操縱他們。2/5/20236011章詳細設計⑵桌面隱喻一種直接操作方法，在那里顯示屏幕，包括通用的桌面對象的排列。

顯示屏幕上排列著眾多的通用桌面對象(筆記本、日歷、計算機和文件夾)。現(xiàn)在許多桌面中還包含了電話、自動應答錄音電話機、CD播放機，甚至還有視頻監(jiān)視器。用戶與任何這些對象進行交互就像是與他們所代表的現(xiàn)實世界對象進行交互一樣?，F(xiàn)在最終用戶期望包括業(yè)務IS在內的所有應用程序都能夠像在桌面上的對象一樣自然靈活。2/5/20236111章詳細設計⑶文檔隱喻

HCI的比喻說法，實現(xiàn)了電子文檔瀏覽和錄入數(shù)據的人-機交互。超文本：超文本允許用戶單擊某一鏈接并且跳轉到該文檔的另一部分或者另一文檔。超媒體：對超文本進行擴展的技術，包括諸如圖形、視頻、音頻等多媒體內容。2/5/20236211章詳細設計⑷對話隱喻人-機交互更像是進行交談或對話。

對話隱喻以系統(tǒng)的OO觀點為基礎，因為通信是將一個對象的消息傳遞給另一個對象。2/5/20236311章詳細設計11.2.3界面設計指導原則界面設計標準：某機構所開發(fā)的所有系統(tǒng)的界面設計都必須遵循的一般原理和規(guī)則。

1.可視性和可供性

2.八條黃金規(guī)則2/5/20236411章詳細設計1.可視性和可供性可視性：HCI的關鍵原則，規(guī)定所有控件必須是可見的，并且提供反饋信息指示控件對用戶動作的響應?？晒┬裕篐CI的關鍵原則，規(guī)定所有控件的外觀都應該體現(xiàn)和反映控件所實現(xiàn)的功能。原則既適用于人-機交互，又適用于任何其他設備。2/5/20236511章詳細設計2.八條黃金規(guī)則⑴盡量保持一致性⑵為老用戶提供快捷鍵⑶提供反饋信息⑷設計完整的對話過程⑸提供簡單的錯誤處理機制⑹允許撤銷動作⑺提供控制的內部軌跡⑻減輕短期記憶負擔2/5/20236611章詳細設計11.2.4

對話設計文檔化1.事件、子系統(tǒng)和菜單層次2.對話與故事腳本3.用UML圖表實現(xiàn)對話文檔編制2/5/20236711章詳細設計1.事件、子系統(tǒng)和菜單層次需要交互方式獲取的輸入項都需要進行對話設計。用戶所需所有輸出項也都需要對話設計。在分析過程中記錄的事件是每一對話的基礎，它可劃分為用戶界面而非系統(tǒng)界面。2/5/20236811章詳細設計對話設計必須與其他設計活動同時進行。子系統(tǒng)結構圖(事務分析)包括系統(tǒng)交互部分的菜單結構的細節(jié)內容。在OO方法的設計過程中也在較早階段關注對話設計，甚至在分析任務階段。順序圖和協(xié)作圖表中包含了對話涉及的細節(jié)內容。2/5/20236911章詳細設計從用戶立場出發(fā)的完備系統(tǒng)結構可以用菜單來反映。每一菜單包含一個選項層次，其中的選項往往根據子系統(tǒng)或對象行為來排列。有時需要根據不同的用戶類型提供多種菜單版本。2/5/20237011章詳細設計RMO

客戶支持系統(tǒng)全部菜單層次2/5/20237111章詳細設計2.對話與故事腳本一旦明確了所有用戶需求的對話，就可以采用多種手段來編制對話設計的文檔，目前還不存在事實標準。一種方法是列舉對話中的關鍵步驟并附帶每一步驟中用戶和計算機交互內容的文字描述。故事腳本技術：一種編制對話設計文檔的技術，顯示一系列的屏幕概略圖。2/5/20237211章詳細設計3.用UML圖表實現(xiàn)對話文檔編制OO方法提供特定的UML圖表用于人-機對話的建模。用例圖：用例的詳細描述中的步驟都遵循人與系統(tǒng)的交互方式進行?；顒訄D：把人-機之間的使用案例存為對話文檔。兩種圖在每一對話中都提供了人-機交互需求模型。2/5/20237311章詳細設計用于RMO“查詢可用條目”對話的順序圖用例控制器與問題域對象通訊2/5/20237411章詳細設計構成條目搜索窗體的界面類的類圖框架類代表包含其他界面對象的基本結構。菜單條類與框架相連，菜單條包含多個菜單，每個菜單中又包含多個菜單項?？蚣苓€包括：表類、按鈕類和標簽類。2/5/20237511章詳細設計特定界面對象Product-QueryForm的順序圖進一步擴展的順序圖；該模型強調窗體設計的細節(jié);問題域細節(jié)可忽略不計。2/5/20237611章詳細設計順序圖可用于對用戶和構造窗體的特定對象間的消息傳遞建模，而且也包括界面對象彼此間的消息傳遞。順序圖中問題域對象間交互部分不做變動。界面對象僅僅是簡單插到問題域對象和參與者之間。2/5/20237711章詳細設計11.2.5窗體設計指導原則1.窗體2.設計指導原則2/5/20237811章詳細設計1.窗體標準窗體：利用完全特征性的程序設計語言編制出的窗體。瀏覽器窗體：利用符合互聯(lián)網規(guī)范的HTML或腳本語言編程的窗體。窗體種類：

⑴輸入窗體

⑵

I/O窗體

⑶輸出窗體2/5/20237911章詳細設計⑴輸入窗體主要是用于記錄事務或輸入數(shù)據，雖然窗體的某些部分可能包含某些來自于系統(tǒng)內部的信息顯示。2/5/20238011章詳細設計⑵

I/O窗體一般用于更新已有信息。這種窗體顯示與某單一實體相關的信息，例如顧客信息，并且允許用戶鍵入新信息，以及更新已有信息。輸入窗體和I/O窗體關系密切，并且使用相似的設計原理。2/5/20238111章詳細設計⑶輸出窗體主要用于顯示信息。這種輸出窗體的設計原則與報表設計原則是一致的。2/5/20238211章詳細設計2.設計指導原則⑴窗體布局與格式化⑵數(shù)據的鍵控與輸入⑶導航與支持控件⑷幫助支持2/5/20238311章詳細設計⑴窗體布局與格式化主要關注窗體的整體外觀和感覺。設計輸入窗體時，應該考慮：一致性；標題、標簽和徽標；字體大小、亮度對比和顏色。2/5/20238411章詳細設計⑵數(shù)據的鍵控與輸入輸入窗體核心任務是新數(shù)據的輸入。主要目的：盡可能地減少輸入數(shù)據量，任何計算機已有信息或者由計算機生成的信息應該不必重新輸入。數(shù)據輸入控件：文本框、列表框、微調框、組合框、無線按鈕(或單選按鈕)、復選框。2/5/20238511章詳細設計⑶導航與支持控件標準Windows界面提供用于導航和窗口操縱的控件。包括：窗體右上角的最小化、最大化和關閉按鈕，水平和垂直滾動條，位于左側面板上的記錄選擇條和窗體底部的記錄導航箭頭等。為維護系統(tǒng)一致性，要求盡可能地利用這些導航控件來實現(xiàn)界面設計。2/5/20238611章詳細設計⑷幫助支持三種通用類型的幫助信息：①與窗體的使用流程相關的指導信息；②幫助主題的索引列表；③上下文相關的幫助信息。2/5/20238711章詳細設計11.2.6網站設計指導原則1.網頁設計中的十種好的做法2.網站設計原則2/5/20238811章詳細設計1.網頁設計中的十種好的做法⑴將機構名稱和徽標放置在所有網頁上，并建立徽標與主頁的鏈接。⑵網頁數(shù)量若超過100，應提拱搜索功能。⑶書寫簡潔的標題行和頁面標題。⑷構造頁面的原則是便于讀者瀏覽并幫助讀者忽略大塊而在匆匆一瞥中找到關鍵內容。2/5/20238911章詳細設計⑸不要將有關某一產品或某一主題的所有內容擁擠地塞滿單一頁面，而應使用超文本來構造內容空間。⑹可以使用產品照片，但要避免在產品系統(tǒng)頁面上混亂而繁雜地堆滿照片，主要產品頁面必須做到迅速地加載和執(zhí)行功能，所以其中內容應該短小精悍。2/5/20239011章詳細設計⑺頁面上準備放置小的照片和圖像時要利用相關增強圖像縮影功能，實現(xiàn)在原始圖像縮影時不是簡單地縮小成看不清楚的小東西，而是在剪切圖片、縮小尺寸的同時放大相關細節(jié)。2/5/20239111章詳細設計⑻利用鏈接標題為用戶提供鏈接內容預覽信息。⑼要保證所有重要的頁面都能被殘障用戶訪問到，特別是視力不好的學生。⑽工作方式應與一般人一致，如果某個大網站按照特定的方式工作，用戶往往因為不習慣新的方式而將注意力轉向其他的網站。2/5/20239211章詳細設計2.網站設計原則網站設計的三個方面：⑴計算機媒體設計原則⑵設計整個網站原則⑶為用戶設計原則2/5/20239311章詳細設計⑴計算機媒體設計原則精心設計網頁外觀及感觀以充分利用媒體介質。由于要保證其在相當廣的技術范圍內的可訪問性，因此要使得設計具有可移植性。要考慮低帶寬，因為用戶不會有耐心去等待網頁加載。規(guī)劃好網頁的展示，盡可能易于訪問，以便用戶能夠在網站中輕松瀏覽。若在線展示的信息來自其他站點資源，需要對這些信息重新格式化。2/5/20239411章詳細設計⑵設計整個網站原則精心設計網頁的外觀和感觀以便和設計者想要表達的理念一致。網頁之間創(chuàng)建平滑的過渡，以便用戶能清楚的知道自己所處的位置。用網格線來設計每個網頁以便為相關的信息組提供可視化的結構。在信息組之間的每個網頁上，合理預留一定數(shù)量的空白。2/5/20239511章詳細設計⑶為用戶設計原則設計網站的交互性，因為網站用戶往往期望網站是交互和動態(tài)的。使網頁上的信息能吸引用戶的眼睛。保持淺層次的分層結構，使用戶不用嵌入太深就可發(fā)現(xiàn)詳細的信息。利用超文本使用戶能在網頁中瀏覽。每頁網頁的內容多少可根據用戶的特征決定，但不要把網頁弄得很凌亂。為不同群體的用戶設計網頁，包括殘疾人。2/5/20239611章詳細設計11.3

系統(tǒng)界面設計11.3.1

確定系統(tǒng)界面11.3.2

系統(tǒng)輸入設計11.3.3

系統(tǒng)輸出設計2/5/20239711章詳細設計11.3.1確定系統(tǒng)界面系統(tǒng)界面輸出：賬單、報表、打印表格，以及流向其他自動化系統(tǒng)的電子輸出。系統(tǒng)界面輸入：自動化輸入和來自于非用戶界面設備的輸入。2/5/20239811章詳細設計系統(tǒng)界面能處理輸入，與其他系統(tǒng)進行實時交互，并且需要最少人員干預地分發(fā)輸出。例如，來自于自動掃描儀、條形碼閱讀器、光字符識別設備，以及作為系統(tǒng)界面組成部分的其他計算機系統(tǒng)的輸入。2/5/20239911章詳細設計IS中完整的I/O2/5/202310011章詳細設計系統(tǒng)界面種類①來自于其他系統(tǒng)的輸入；(EDI)②高度自動化輸入；(掃描儀)③來自于外部數(shù)據庫的輸入；④流向外部數(shù)據庫的輸出；⑤具有極少人-機交互(HCI)的輸出；⑥流向其他系統(tǒng)的輸出；⑦實時連接(I/O)。2/5/202310111章詳細設計11.3.2系統(tǒng)輸入設計1.確定輸入設備和機制2.定義系統(tǒng)輸入細節(jié)

2/5/202310211章詳細設計1.確定輸入設備和機制任何數(shù)據輸入表單的主要目的是向系統(tǒng)輸入新的、無差錯的數(shù)據或無差錯地更新數(shù)據信息。最重要的是不要出現(xiàn)差錯。2/5/202310311章詳細設計減少輸入錯誤的方法獲取的數(shù)據盡可能與原始數(shù)據接近；盡可能使用電子設備和自動輸入；盡可能避免人工干涉；如果信息可從某個電子表單得到，則使用電子表單而不要重新輸入這些信息；在輸入信息時，對數(shù)據進行檢驗和更正。2/5/202310411章詳細設計普遍使用的輸入設備磁卡片閱讀器；條形碼閱讀器；光電字符識別閱讀器和掃描儀；觸摸屏設備；電子筆和書寫板；數(shù)字化儀，如數(shù)字照相機和數(shù)字音頻設備。2/5/202310511章詳細設計2.定義系統(tǒng)輸入細節(jié)目標：確保設計者已確定所有必要的系統(tǒng)輸入并對它們進行正確說明?；痉椒ǎ捍_定穿越系統(tǒng)邊界的所有信息流。

⑴使用結構化的模型

⑵使用OO模型2/5/202310611章詳細設計⑴使用結構化的模型①定義自動化邊界②通過分析每個DFD片段來確定必要的輸入③從DFD片段得到輸入列表④分析結構圖中的每個模塊、數(shù)據耦合，并列出每個數(shù)據耦合的數(shù)據字段。2/5/202310711章詳細設計系統(tǒng)級

DFD

的自動化邊界部分輸入、輸出的過程程序邊界穿越邊界的數(shù)據流是I/O系統(tǒng)自動化邊界時間卡稅率表雇員檔案更新2/5/202310811章詳細設計DFD上穿越邊界的輸入數(shù)據流對應事件表中的外部事件的觸發(fā)。帶自動化邊界的創(chuàng)建新訂單DFD

2/5/202310911章詳細設計客戶支持系統(tǒng)的輸入列表2/5/202311011章詳細設計創(chuàng)建新訂單的結構圖2/5/202311111章詳細設計組成輸入的數(shù)據流、數(shù)據耦合和數(shù)據元素表中數(shù)據耦合列所列出由終端用戶確定作為輸入的每一項將成為電子輸入數(shù)據表單或I/O表單的一部分。2/5/202311211章詳細設計⑵使用OO模型OO方法確定用戶和系統(tǒng)輸入的任務與利用結構化方法一樣。不同之處在于使用順序圖和設計類圖。2/5/202311311章詳細設計薪金IS用例的部分順序圖輸入時間卡信息:雇員ID號,日期,時間更新稅率信息:稅率ID號,稅率信息更新雇員信息:雇員ID號,雇員信息2/5/202311411章詳細設計創(chuàng)建訂單向訂單中添加條目完成訂單執(zhí)行支付

返回確認

創(chuàng)建新訂單的系統(tǒng)順序圖2/5/202311511章詳細設計RMO系統(tǒng)順序圖的輸入消息和數(shù)據參數(shù)表顯示了與每個輸入相聯(lián)系的數(shù)據。與用戶界面相聯(lián)系的消息在設計用戶界面時被精確定義。該例中，只有系統(tǒng)輸入被放置在列表中。詳細的表格有助于更精確地定義輸入參數(shù)。詳細信息常被傳送到順序圖中，從而使得順序圖更加充實。2/5/202311611章詳細設計11.3.3系統(tǒng)輸出設計系統(tǒng)輸出的主要目的是在正確的時間和地點，為正確的人提供相關信息。輸出設計任務要求實現(xiàn)的目標：確定每個輸出類型；為應用設計所要求的特定輸出做一個列表；提供必要的控制來保護輸出中提供的信息；設計和規(guī)范報表布局。特定報表：程序員沒有預先定義而在需要時由用戶設計的報表。

2/5/202311711章詳細設計

1.定義系統(tǒng)輸出的細節(jié)2.設計報表、聲明和返回文檔3.報表的規(guī)范化2/5/202311811章詳細設計1.定義系統(tǒng)輸出的細節(jié)定義系統(tǒng)輸出細節(jié)的目的是確保設計者已經確認和定義了系統(tǒng)中每一個必要的輸出。基本方法與系統(tǒng)輸入的設計很相似。基于模型的方法利用事件表和其他模型來確定和定義輸出的詳細內容。

⑴使用結構化模型

⑵使用OO模型2/5/202311911章詳細設計⑴使用結構化模型確定輸出的過程和從穿過系統(tǒng)邊界的數(shù)據流建立輸入列表清單的過程一樣。2/5/202312011章詳細設計系統(tǒng)級

DFD

的自動化邊界

部分輸入、輸出的過程程序邊界穿越邊界的數(shù)據流是I/O系統(tǒng)自動化邊界員工的薪金支票、年終稅詳細報告

、批處理報告。2/5/202312111章詳細設計DFD上穿越邊界的輸入數(shù)據流對應于事件表中的外部事件的觸發(fā)。帶自動化邊界的創(chuàng)建新訂單DFD

2/5/202312211章詳細設計基于傳統(tǒng)結構化方法的系統(tǒng)輸出表建立DFD輸出、報表定義和數(shù)據域的表格時，增加兩列內容：①產生報表所需的數(shù)據存儲或文件；②產生報表的記錄個數(shù)，即是單記錄還是記錄集。2/5/202312311章詳細設計⑵使用OO模型在OO的順序圖中，輸出消息表示輸出，即消息來自于一個系統(tǒng)內部對象而目的地是一個外部參與者。對于所有順序圖所生成的全部輸出消息進行檢查是為分析階段活動所確定的必要輸出提供了一致性審核。

基于單個對象(或記錄)的輸出消息通常是對象類方法的一部分。用報表表示一個類中所有對象，使用類的方法。類方法工作于整個對象類，而不僅僅是單個對象。

2/5/202312411章詳細設計創(chuàng)建新訂單的系統(tǒng)順序圖2/5/202312511章詳細設計基于OO消息的系統(tǒng)輸出表該表是由“創(chuàng)建新訂單”這一單一用例派生出來的，所以表中未包含諸如發(fā)貨消息等出現(xiàn)在其他用例中的其他消息。2/5/202312611章詳細設計2.設計報表、聲明和返回文檔⑴報表類型⑵內部和外部輸出⑶電子報表⑷圖形和多媒體表示2/5/202312711章詳細設計⑴報表類型①詳細報表②匯總報表③異常報表④決策報表2/5/202312811章詳細設計①詳細報表包含詳細交易或記錄的報表。用來記錄每天的商業(yè)處理過程。包含商業(yè)交易中的詳細信息。目的是給公司人員提供工作文檔。2/5/202312911章詳細設計②匯總報表對一段時間內或某些種類的信息細節(jié)進行摘要或匯總的報表。通常用來對階段性活動進行扼要重述。例：對每天