第一篇：基于UML的學生頂崗實習管理系統(tǒng)分析與設計(投電腦知識與技術定稿)
基于UML的學生頂崗實習管理系統(tǒng)分析與設計
馬先波
（日照職業(yè)技術學院，山東 日照 276826）
摘要：頂崗實習是高職院校重要的實踐教學環(huán)節(jié)，要實現(xiàn)對頂崗實習的有效管理，需要借助網(wǎng)絡技術搭建管理平臺，實現(xiàn)對參與實習師生的管理與指導。該文在對頂崗實習流程及實習任務分析基礎上，運用UML建模方法對系統(tǒng)進行分析建模與設計建模，并提出了系統(tǒng)框架與解決方案。
關鍵詞:頂崗實習;UML;建模;系統(tǒng)分析;系統(tǒng)設計;管理系統(tǒng)
中圖分類號：TP31
5Analysis and Design of The Students Internship
Management System Based on UML
MA Xian-bo
(Rizhao Polytechnic, Rizhao, 276826, China)
Abstract: Internship is important practical teaching in Higher Vocational Colleges, the Internship in order to achieve effective management of the need to build management platform with network technology to realize the management of teachers and students involved in internships and guidance.Internship in the paper in the process and practical tasks based on the analysis, the use of UML modeling method to analyze the system modeling and design modeling, and the system framework and solutions.Key words：Internship;uml;modeling;Systems Analysis;Systems design
1引 言
頂崗實習是高職院校在探索工學結合、校企合作辦學模式中重要的實踐教學環(huán)節(jié)，在培養(yǎng)高技能人才過程中具有非常重要的作用，是完善“職場體驗→實境訓練→頂崗歷練”人才培養(yǎng)模式的重要舉措。頂崗實習期間學生作為學生同時又是企業(yè)員工，接受學校和企業(yè)的雙重管理，學生實習比較分散而且遠離學校，教師不能與實習學生直接交流，學生在心理、工作、人際關系處理、畢業(yè)設計、畢業(yè)論文等方面產(chǎn)生的問題教師不能及時幫助解決，甚至存在與企業(yè)的溝通協(xié)調不夠，管理不到位、實習生放任自流的現(xiàn)象。頂崗實習管理系統(tǒng)的開發(fā)和運用可有效解決以上問題，補充完善頂崗實習管理體系，有效提高頂崗實習管理效率和水平。
2系統(tǒng)需求分析與建模
軟件系統(tǒng)的需求分析，通過深入描述頂崗實習目標系統(tǒng)的功能和性能，定義軟件的功能和性能需求。頂崗實習管理系統(tǒng)的開發(fā)，以實習學生、指導教師、企業(yè)為核心，以實習工作流程和實習任務為內容，采用基于UML的面向對象的方法進行建模。
頂崗實習系統(tǒng)的使用者有系統(tǒng)管理員、院部管理員、企業(yè)管理員、學校實習指導教師、企業(yè)實習指導教師、學生等六個用戶，系統(tǒng)能夠實現(xiàn)對參加實習的學生、指導教師、合作企業(yè)進行管理，并可以實現(xiàn)實習指導教師的分配、實習崗位的分配等內容。系統(tǒng)實現(xiàn)頂崗實習的日常管理，主要包括學生提交頂崗實習申請、填寫實習工作計劃日程表、填寫實習日志、提交實習總結報告、師生交流論壇等，并可以實現(xiàn)指導教師和學生的相互評價。系統(tǒng)另一主要功能是實現(xiàn)對畢業(yè)設計和畢業(yè)實習的管理，主要包括提交畢業(yè)設計和畢業(yè)論文題目、填寫畢業(yè)設計和畢業(yè)論文計劃、提交畢業(yè)論文
并組織答辯，并能夠和指導教師實現(xiàn)及時信息交互。實習學生可以通過系統(tǒng)提交畢業(yè)論文答辯申請，并提交畢業(yè)設計和畢業(yè)論文，指導教師審核通過后，組織答辯并錄入答辯記錄和答辯成績。企業(yè)指導教師可以進行實習崗位分配、實習測評管理、意見反饋，并填寫實習指導記錄。院部管理員可以通過系統(tǒng)進行實習情況統(tǒng)計，對申請實習的學生安排實習指導教師和實習企業(yè)，統(tǒng)計實習測評情況、統(tǒng)計論文答辯情況、分析實習成績和論文成績等，指導教師可以對所指導的學生進行實習情況統(tǒng)計、統(tǒng)計論文答辯情況和成績報送等。系統(tǒng)還要實現(xiàn)對用戶的管理、權限設置、工作流程設置等。
對系統(tǒng)需求分析歸納總結，識別參與者并以參與者的角度歸納系統(tǒng)需求特性。對需求特性進行合并歸納，得到系統(tǒng)用例模型如圖1所示。用例模型的描述需要進
提交畢業(yè)論文題目和計劃
實習教師/崗位分配合作企業(yè)管理
論文答辯統(tǒng)計
制定實習計劃
圖1 系統(tǒng)用例圖
一步對每一個用例進行詳細的用例規(guī)約描
述，包括用例名稱、前置條件、后置條件、基本事件流、擴展事件流等，并形成文檔。
3系統(tǒng)設計與建模
系統(tǒng)設計的目的是建立一個完整的解決方案，并能夠比較容易地轉換成代碼。本系統(tǒng)采用MVC架構下的三層結構體系，對分析階段的模型進行細化，并且定義除實體類之外的邊界類和控制類，共同構建系統(tǒng)模型。
在系統(tǒng)分析建模中，重點分析了與問題描述域和系統(tǒng)功能相關的對象，在系統(tǒng)設計過程中把系統(tǒng)的類對象分為實習管理和畢業(yè)設計管理兩大類，利用動名詞的方法發(fā)現(xiàn)類，然后決定候選類，并分析得到系統(tǒng)類如下：學生類（I_Student）、實習指導教師類（I_Teacher）、實習計劃（I_Plan）、實習日志（I_Log）、實習報告(I_Report)、實習指導記錄(I_ GuidingRecords)、實習情況表(I_T_S_List)、實習崗位（I_ Post）、實習成績（I_Score）、畢業(yè)設計(G_Design)、畢業(yè)論文(G_ Paper)、畢業(yè)論文成績（G_Score）等。
這些類之間我們可以用關聯(lián)關系作簡要表達，對每個類的職責進行簡要的分析得到系統(tǒng)類圖如圖2所示。在圖中每條有直接多重性關聯(lián)的線上已標示出多重性，這為以后編程中提供了更好的關聯(lián)參考價值，并為
類在整個開發(fā)中的統(tǒng)一性奠定基礎。圖2 系統(tǒng)類圖
在完成系統(tǒng)對象和對性之間的靜態(tài)結
構后，下一步重點描述系統(tǒng)對象及其關系的變化情況，這些情況可以使用UML的動態(tài)模型中的交互圖進行描述。在系統(tǒng)的動態(tài)建模過程中，系統(tǒng)中對象之間通過消息機制來進行交互，交互圖是指實現(xiàn)某個目標，而在一組對象之間進行交互的一組消息所表示的行為。交互圖可以應用在分析模型和設計模型中，在分析模型中交互圖側重于分析類的職責分配和交互路程，而設計模型中交互圖側重
于設計類的引入和實際方法的調用與流程控制。系統(tǒng)以指導教師評價學生實習情況為例進行交互圖建模，首先確定交互的對象有指導教師、登錄頁面、實習日志、實習報告、成績錄入存儲等，然后確定各對象之間的消息交互流程，并可選擇性地利用交互片段、迭代及監(jiān)護條件等來表示循環(huán)和分支，建立起系統(tǒng)動態(tài)視圖，如圖3所示。
:
4基于B/S模式的系統(tǒng)結構
在完成頂崗實習系統(tǒng)的分析與設計后，基本上形成了系統(tǒng)的邏輯數(shù)據(jù)處理流程，系統(tǒng)總體上對數(shù)據(jù)進行獲取、處理及存儲操作，需要按照三層體系結構進行架構，分為瀏覽器層、邏輯處理層、數(shù)據(jù)管理層。系統(tǒng)開發(fā)建議采用基于JAVA的面向對象技術，底層數(shù)據(jù)管理采用安全性較好、穩(wěn)定的MS SQL數(shù)據(jù)庫管理系統(tǒng)，通過JAVABEAN對象組件完成對后臺數(shù)據(jù)庫服務的訪問。
基于UML的頂崗實習系統(tǒng)的開發(fā)過程，對
圖3 指導教師實習評價順序圖
系統(tǒng)的實用性、先進性和可復用性都有很大的提高，使系統(tǒng)具有良好的可靠性、可維護性和擴展性，對規(guī)范頂崗實習管理，提高管理水平和效率具有重要的意義。
[1] 張美忠, 謝洪.高職學生頂崗實習的探索與實踐[J] ,北京:職業(yè)與教育,2009.164-165.[2] 俞校明, 張紅.高職生頂崗實習過程設計與質量控制研究[J], 吉林:職業(yè)技術教育，2009.66-67.[3] 徐峰, 陳喧.UML面向對象建?；A[M], 北京:中國水利水電出版社，2006.
第二篇：UML食堂售飯系統(tǒng)分析與設計
食堂售飯系統(tǒng)分析與設計
目錄
1.需求分析與描述.............................................................................1 1.1 需求分析.................................................................................1 1.2 用例分析.................................................................................1 1.3 用例模型圖.............................................................................3 1.4 用例事件流描述.....................................................................4 2.領域模型分析...................................................................................7 3.工作流程分析...................................................................................8
食堂售飯系統(tǒng)分析與設計
1.需求分析與描述
1.1 需求分析
? 持卡人：辦理新飯卡，給飯卡充值，注銷飯卡，掛失/撤銷掛失飯卡，補辦新卡，退還飯卡，使用飯卡消費，查看個人消費的明細。? 管理部門：通過計算機系統(tǒng)具體實現(xiàn)持卡人需求中的項目。
? 食堂工作人員：通過自動售飯機輸入飯菜的金額，通過計算機系統(tǒng)對當天的營業(yè)情況進行匯總統(tǒng)計。
1.2 用例分析
1)系統(tǒng)的邊界
對于系統(tǒng)邊界，系統(tǒng)首先會包含需求分析中所需要軟件實現(xiàn)的各項功能，此外還須確定食堂售飯系統(tǒng)是否包括管理部門和食堂工作人員。
就食堂售飯系統(tǒng)而言，其主要功能是讓用戶（即持卡人）享受服務（即用飯卡使購買飯菜的過程繞過了付款及找零的環(huán)節(jié)，提高了服務效率），而管理部門和食堂工作人員的作用都是為了使用戶免于對系統(tǒng)的直接操作而設置的，因而此兩者應歸為食堂售飯系統(tǒng)的內部，相當于用戶和具體的計算機軟硬件系統(tǒng)之間的接口。
2)系統(tǒng)的執(zhí)行者
持卡人需要通過食堂售飯系統(tǒng)來使用其所持有飯卡買飯，因而是整個系統(tǒng)的執(zhí)行者；
管理部門根據(jù)持卡人的需求操作計算機系統(tǒng)從而實現(xiàn)與飯卡相關信息的管理，相當于其中飯卡信息管理子系統(tǒng)的使用者，是位于食堂售飯系統(tǒng)內部的執(zhí)行者；
食堂工作人員同樣通過操作計算機系統(tǒng)來實現(xiàn)購買飯菜過程中的扣費
食堂售飯系統(tǒng)分析與設計
功能以及對營業(yè)情況進行的匯總統(tǒng)計的功能，相當于其中消費處理與統(tǒng)計子系統(tǒng)的使用者，也是位于食堂售飯系統(tǒng)內部的執(zhí)行者。
這樣得到了系統(tǒng)中的執(zhí)行者： ? 持卡人 ? 管理部門 ? 食堂工作人員
3)系統(tǒng)的用例
根據(jù)用戶需求及執(zhí)行者的分析，得到系統(tǒng)的用例如下： ? 辦理新飯卡 ? 飯卡充值 ? 注銷飯卡
? 掛失/撤銷掛失飯卡 ? 補辦飯卡 ? 退還飯卡
? 查看個人消費的明細
? 扣除飯卡費用（對應于持卡人使用飯卡消費）? 匯總統(tǒng)計
食堂售飯系統(tǒng)分析與設計
1.3 用例模型圖
根據(jù)前面的分析，可以得到系統(tǒng)的用例模型圖，如上圖所示。對其中3個執(zhí)行者和8個用例的簡單描述如下：
執(zhí)行者：
? 持卡人：飯卡的持有者，通過食堂工作人員的操作直接使用飯卡進行消費，并通過管理部門對其飯卡進行管理。
? 管理部門：負責根據(jù)持卡人的需求操作計算機系統(tǒng)，從而實現(xiàn)辦新卡、充值、注銷、掛失/撤銷掛失，補卡、退卡、查看消費明細等功能。? 食堂工作人員：負責根據(jù)飯菜的金額操作自動售飯機實現(xiàn)扣費功能，沒隔一段時間對營業(yè)情況進行匯總統(tǒng)計并打印出相關文檔。
食堂售飯系統(tǒng)分析與設計
用例：
? 辦理新飯卡：管理部門人員負責在用戶申請新卡時替用戶辦理新飯卡。? 飯卡充值：管理部門人員負責根據(jù)持卡人所給的金額向飯卡中追加存款金額。
? 注銷飯卡：管理部門人員負責在持卡人補辦新卡或退卡時注銷其原有飯卡。
? 掛失/撤銷掛失飯卡：管理部門人員負責在持卡人因飯卡遺失申請掛失時進行掛失飯卡操作，在其找回飯卡時撤銷對飯卡的掛失。
? 補辦飯卡：管理部門人員負責在持卡人確認飯卡丟失或者損壞時替其補辦飯卡，更改飯卡版本號，并實現(xiàn)只能使用最新版本號的飯卡。? 退還飯卡：管理部門人員負責在持卡人申請退卡時清除卡內信息，退還剩余金額和押金。
? 查看個人消費的明細：管理部門人員負責在持卡人申請查看其消費明細時執(zhí)行次操作。
? 扣除飯卡費用：食堂工作人員負責在持卡人持卡消費時根據(jù)飯菜的價格對飯卡進行扣費操作。
? 匯總統(tǒng)計：食堂工作人員負責在每天營業(yè)結束后對營業(yè)情況進行匯總統(tǒng)計并打印相關報表。
1.4 用例事件流描述
1.辦理新飯卡
? 基本流
1.用戶申請辦理新飯卡
2.管理部門收取其押金和存款，記錄持卡人相關信息 3.管理部門創(chuàng)建新飯卡的相關信息 4.用戶領取新飯卡 ? 備選流
無
食堂售飯系統(tǒng)分析與設計
2.飯卡充值
? 基本流
1.持卡人申請對飯卡充值 2.管理部門向持卡人收取現(xiàn)金
3.管理部門根據(jù)持卡人要求向飯卡中充值 ? 備選流
3.a 如果收取現(xiàn)金金額大于充值額度，管理部門向持卡人找零
3.注銷飯卡
? 基本流
1.持卡人申請注銷飯卡 2.管理部門注銷飯卡 ? 備選流
無
4.掛失/撤銷掛失飯卡
? 基本流
1.持卡人申請掛失/撤銷掛失飯卡 2.管理部門執(zhí)行相應操作 ? 備選流
無
5.補辦新卡
? 基本流
1.持卡人申請補辦新卡
2.管理部門注銷持卡人原有飯卡，讀出余額，清除卡內信息 3.管理部門創(chuàng)建新飯卡的相關信息 4.管理部門更新持卡人的相關信息
食堂售飯系統(tǒng)分析與設計
5.持卡人領取新飯卡 ? 備選流
無
6.退還飯卡
? 基本流
1.持卡人申請退還飯卡 2.管理部門收回飯卡
3.管理部門將押金退還持卡人并清除卡內信息 ? 備選流
2.a 如果卡內有剩余金額，管理部門想持卡人退還相應金額
7.查看個人消費的明細
? 基本流
1.持卡人申請查看個人消費的明細 2.管理部門讓持卡人輸入飯卡密碼 3.持卡人查看其消費的明細 ? 備選流
2.a 如果飯卡密碼錯誤，給出提示，結束
8.扣除飯卡費用（對應于持卡人使用飯卡消費）
? 基本流
1.持卡人購買飯菜，將飯卡放到自動售飯機上 2.食堂工作人員在自動售飯機上輸入飯菜的金額 3.自動售飯機查詢飯卡余額 4.卡內金額扣除 ? 備選流
3.a 如果卡中金額不夠用，給出提示，結束 4.a 如果卡內金額低于底線，給出提示，結束
食堂售飯系統(tǒng)分析與設計
9.匯總統(tǒng)計
? 基本流
1.食堂工作人員按需求對營業(yè)情況進行匯總統(tǒng)計 2.打印相關報表 ? 備選流
無
2.領域模型分析
食堂售飯系統(tǒng)分析與設計
3.工作流程分析
辦理新卡
飯卡充值
食堂售飯系統(tǒng)分析與設計
掛失/撤銷掛失飯卡
補辦飯卡
食堂售飯系統(tǒng)分析與設計
查看個人信息明細
注銷飯卡
食堂售飯系統(tǒng)分析與設計
退還飯卡
扣除金額
食堂售飯系統(tǒng)分析與設計
匯總統(tǒng)計
第三篇：軟件系統(tǒng)分析與設計
第1章
軟件工程基礎知識 1.1軟件工程知識體系
? 軟件需求（Software Requirements）? 軟件設計（Software Design）
? 軟件構造（Software Construction）? 軟件測試（Software Testing）? 軟件維護（Software Maintenance）
? 軟件配置管理（Software Configuration Management）? 軟件工程管理（Software Engineering Management）? 軟件工程過程（Software Engineering Process）
? 軟件工程工具和方法（Software Engineering Tools and Methods）? 軟件質量（Software Quality）
1.2軟件生存周期與軟件開發(fā)模型
? 1.2.1 軟件生存周期
? Boehm定義的軟件生存周期模型
? GB 8566-1988定義的軟件生存周期模型
? GB/T 8566-1995定義的軟件生存周期過程模型 ? GB/T 8566-2001定義的軟件生存周期過程模型 ? UP定義的軟件生存周期模型
? 1.2.2 軟件開發(fā)模型
? 瀑布模型（waterfall model）
? 快速原型模型（rapid prototype model）? 演化模型（evolutionary model）? 增量模型（incremental model）? 螺旋模型（spiral model）
? 噴泉模型（water fountain model）
1.3軟件質量模型與軟件質量管理
? 1.3.1 軟件質量模型
? 軟件產(chǎn)品的內部質量、外部質量和使用質量 ? 質量特性、質量子特性和度量
? 功能性：適宜性、準確性、互用性、依從性、安全性 ? 可靠性：成熟性、容錯性、可恢復性 ? 可用性：可理解性、易學性、可操作性 ? 效率：時間特性、資源特性
? 可維護性：可分析性、可修改性、穩(wěn)定性、可測試性 ? 可移植性：適應性、易安裝性、一致性、可替換性
? 1.3.2 軟件質量管理
? 質量需求分析 ? 質量計劃 ? 質量保證 ? 質量控制 ? 質量改進
? 軟件質量管理體系
? ? ? ? ? ? ? ? ? ?
? ?
? ? ? ? ? ? ? ? ? ? ? ? ?
? ? ?
1.4軟件配置管理
? 1.4.1 軟件配置項與基線
計算機軟件配置項（CSCI）基線（baseline）
功能基線（functional baseline）指派基線（allocated baseline）產(chǎn)品基線（product baseline）
? 1.4.2 軟件配置管理過程
對象標識 版本控制 變化控制 配置審計 配置報告
1.5軟件過程管理
? 1.5.1 軟件能力成熟度模型（CMM）
CMM的5個等級：初始級、可重復級、已定義級、已管理級、優(yōu)化級 CMM的關鍵過程域（KPA）：需求管理、軟件項目計劃、軟件項目跟蹤和監(jiān)控、軟件子合同管理、軟件質量保證、軟件配置管理、組織級過程焦點、組織級過程定義、培訓大綱、集成軟件管理、軟件產(chǎn)品工程、組間協(xié)調、同行評審、定量過程管理、軟件質量管理、缺陷預防、技術變更管理、過程變更管理
? 1.5.2 軟件過程與軟件能力成熟度評估
第一步，建立評估組 第二步，填寫提問單 第三步，響應分析 第四步，現(xiàn)場考察
第五步，提出調查發(fā)現(xiàn)清單
第六步，制作關鍵過程域（KPA）剖面圖
? 1.5.3 軟件過程改進
第一步，比較“目標狀態(tài)”與“目前狀態(tài)”，找出所有差距 第二步，確定改進目標 第三步，制定改進計劃 第四步，執(zhí)行改進計劃
第五步，總結本輪改進經(jīng)驗，開始下一輪改進
1.6
小節(jié)
軟件工程學是研究如何有效地組織和管理軟件開發(fā)的工程學科。
軟件產(chǎn)品所要經(jīng)歷的計劃、分析、設計、編程、測試、維護直至被淘汰這樣一個全過程被稱為軟件生存周期。用不同的方式將軟件生命周期中的所有開發(fā)活動組織起來，可以形成不同的軟件開發(fā)模型。
軟件質量就是軟件與明確地和隱含地定義的需求相一致的程度。軟件質量管理是指軟件開發(fā)機構為保證軟件項目滿足客戶需求所要實施的質量活動。軟件配置管理是在軟件的整個生命期內管理變化的一組活動，目標是使變化更正確且更容易被適應。
軟件過程是指人們用于開發(fā)和維護軟件及其相關產(chǎn)品的一系列活動，包括軟件工程過程和軟件管理過程。軟件過程管理的目的就是提升軟件組織的提高軟件開發(fā)能力。
? 1.? 1.? ? ? ? ?
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
第2章
項目管理基礎知識 2.1項目與項目管理 ? 2.1.1 項目
項目是在特定條件下、具有特定目標的一次性任務，是在一定時間內、滿足一系列特定目標的多項相關工作的總和。項目的臨時性 項目的獨特性 項目的漸進性
2.1.2 項目管理
項目管理就是將各種知識、技能、工具和技術應用于項目之中，以達到項目的要求。項目范圍 項目時間 項目成本 項目質量
2.2項目管理過程與過程組 ? 2.2.1 過程與過程組
過程就是一組為了完成一系列事先指定的產(chǎn)品、服務或成果而需執(zhí)行的互相聯(lián)系的行動和活動。軟件項目管理過程可歸納為五個過程組。啟動過程組（initiating process group）規(guī)劃過程組（planning process group）實施過程組（executing process group）
監(jiān)控過程組（monitoring and controlling process group）收尾過程組（closing process group）
? 2.2.2 項目管理過程的交互作用
項目管理過程并不是互不相干的一次性事件
項目管理過程組之間是一種前后銜接、承前啟后的關系
項目管理過程組之間有時又是一種時間交錯、空間并行的關系 項目管理過程組之間還是一種信息收集、存儲、處理和傳遞的關系 某些過程組的關聯(lián)具有重復迭代性
規(guī)劃過程組、執(zhí)行過程組和監(jiān)控過程組之間形成一種閉環(huán)的關系 過程組的交互作用往往還會跨越項目階段 項目階段和過程之間有相互聯(lián)系
? 2.2.3 項目管理過程的裁剪
不同類型的軟件項目應選用不同的項目管理過程 不同階段的軟件項目應選用不同的項目管理過程 不同軟件項目的管理過程會有不同的具體過程 不同軟件項目的管理過程會有不同的具體過程順序 不同軟件項目的管理過程會有不同的條件與約束 不同軟件項目的管理過程會有不同的簡化程度 不同軟件項目的管理過程需要不同的集成程度 項目變更會使項目管理過程隨之變化
2.3項目管理知識體系
項目綜合管理 項目范圍管理
? ? ? ? ? ? ? ? ? ? 項目時間管理 項目成本管理 項目質量管理 項目人力資源管理 項目溝通管理 項目風險管理 項目采購管理
2.4小節(jié)
項目管理就是將項目管理知識、技能、工具和技術應用于項目活動之中，可以將軟件項目管理活動視做一系列相互聯(lián)系的過程。
項目管理過程可歸納為5個過程組：啟動過程組、規(guī)劃過程組、實施過程組、監(jiān)控過程組與收尾過程組。
項目管理包括9個知識領域：項目綜合管理、項目范圍管理、項目時間管理、項目成本管理、項目質量管理、項目人力資源管理、項目溝通管理、項目風險管理與項目采購管理。
第3章
軟件開發(fā)技術 3.1軟件開發(fā)平臺
? 3.1.1 Microsoft.NET平臺
Microsoft.NET Framework：.NET CLR（通用語言運行環(huán)境）；.NET BCL（基礎類庫）；ASP.NET；ADO.NET。
Microsoft Visual Studio.NET：ADO.NET組件；XML數(shù)據(jù)組件；Windows表單組件；ASP.NET應用服務；ASP.NET Web表單；Web服務支持。
? 3.1.2 J2EE平臺
組件-容器：搭建體系架構平臺標準服務 多層應用模型
3.1.3 Microsoft.NET與J2EE的異同
類似的平臺基礎構造 相同的三層/多層體系 不同的移植、性能和擴展 在Web支持方面的比較 第三方廠商的支持 潛在的市場
3.2中間件技術 ? 3.2.1 中間件簡介
終端仿真/屏幕轉換中間件 數(shù)據(jù)訪問中間件 遠程過程調用中間件 消息中間件 交易中間件 對象中間件
Web服務器中間件 安全中間件
? 3.2.2 消息代理中間件 ? ?
? ? ? ? ? 1.? ? 1.? ? ? ? ? ? ? ?
? ? ? ? ? ? ? ? ?
? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
?
? 構件化的結構
可恢復性、易于管理、靈活性 具有數(shù)據(jù)轉換設施?？煽扛咝У耐ㄐ?多樣的管理能力 豐富的應用開發(fā)環(huán)境
? 3.2.3 面向數(shù)據(jù)庫的中間件
ODBC JDBC 數(shù)據(jù)庫網(wǎng)關
3.3構件技術 ? 3.3.1 構件庫
構件的存儲
構件的分類與檢索機制 構件庫的編目
構件庫的管理和維護
? 3.3.2 構件模型
3C模型
刻面（Facet）模型 青鳥模型
? 3.3.3 構件的屬性與特點
構件是可獨立配置的單元，構件必須自包容。
構件強調與環(huán)境和其他構件的分離，因此構件的實現(xiàn)是嚴格封裝的，外界沒機會或沒必要知道構件內部的實現(xiàn)細節(jié)。
構件可以在適當?shù)沫h(huán)境中被復合使用，因此構件需要提供清楚的接口規(guī)范，可以與環(huán)境交互。
構件沒有個體特有的屬性，最多僅有特定構件的一份副本。
? 3.3.4 構件與中間件
中間件，本質上是對分布式應用的抽象，中間件與系統(tǒng)架構實際上是從兩種不同的角度看待軟件的中間層次。
中間件促進了構件化軟件，基于中間件開發(fā)的應用系統(tǒng)是構件化的，中間件提供了構件的體系結構，極大提高了構件化軟件開發(fā)的效率和質量。構件化的軟件設計思想在中間件發(fā)展中起到了重要的作用。
3.4小節(jié)
Microsoft.NET平臺和J2EE平臺是目前最常用的兩大軟件開發(fā)平臺。作為彼此競爭的應用平臺，Microsoft.NET平臺和J2EE平臺在目標和體系結構上極其相似，但在實現(xiàn)上又完全不同。二者總的關系是：異中有同，同中有異。中間件是處于操作系統(tǒng)和應用程序之間的軟件。中間件保持了平臺的透明性，抽象了典型的應用模式。應用軟件開發(fā)者可以基于標準的中間件進行再開發(fā)，而不必再考慮操作系統(tǒng)的問題。
構件是可復用的軟件成份，可被用來構造其他軟件。中間件促進了構件化軟件，應用系統(tǒng)在中間件提供的環(huán)境中可以更好地集中于業(yè)務邏輯上，并以構件的形式存在。構件思想也反過來推動了中間件的發(fā)展。
第4章
軟件項目規(guī)劃
4.1項目策劃
? 1.? 1.從政策導向中尋找項目機會 從市場需求中尋找項目機會 從技術發(fā)展中尋找項目機會 從特定事件中尋找項目機會
4.2項目可行性分析 4.2.1 技術可行性分析
? ? ? ? ? 1.? ? ? ? ? ? ? ? ? 項目的必要性分析
軟件組織水平與能力分析 項目技術來源分析 與項目相關的專利分析
項目負責人及技術骨干的資質分析 項目總體技術方案分析 項目創(chuàng)新點分析 項目技術風險分析 項目技術成熟性分析
? 4.2.2 項目投資及效益分析
項目投資預算分析 項目投資來源分析
市場需求與產(chǎn)品銷售額分析
產(chǎn)品成本、利潤與盈虧平衡點分析 投資回收期、投資收益率分析 社會效益分析
4.3項目論證、評估與立項
? 4.3.1 項目論證與評估的基本概念
項目論證是指對擬實施項目技術上的先進性、成熟性、適用性，經(jīng)濟上的合理性、盈利性，實施上的可能性、風險性進行全面科學的綜合分析，為項目決策提供客觀依據(jù)的一種技術經(jīng)濟研究活動。
項目評估指在項目可行性研究的基礎上，項目投資者或項目主管部門或其委托的第三方權威機構根據(jù)國家頒布的政策、法律、法規(guī)、標準和技術規(guī)范，對擬開發(fā)項目的市場需求、技術先進性和成熟性、預期經(jīng)濟效益和社會效益等進行評價、分析和論證，進而判斷其是否可行的過程。
項目論證與評估的內容、程序和依據(jù)大同小異，只是側重點稍有不同，有時不加區(qū)分或合并進行。
? 4.3.2 項目可行性報告的真實性評估
項目申請單位的資質真實性評估 項目申請單位的財務真實性評估 項目申請單位的技術真實性評估 其他事項的真實性評估
? 4.3.3 項目可行性報告的客觀性評估
技術創(chuàng)新點的客觀性評估
技術先進性與成熟性的客觀性評估 ?
?
?
? ? ? ? ? ?
? ? ? ? 信息安全措施的客觀性評估
采用標準、規(guī)范的先進性、合理性評估 項目風險及應對方案的客觀性評估 其他事項的客觀性評估
? 4.3.4 評估報告
? 項目概況 ? 評估目標 ? 評估依據(jù) ? 評估內容
? 評估機構與評估專家 ? 評估過程
? 詳細評估意見
? 存在或遺漏的重大問題 ? 潛在的風險 ? 評估結論
? 進一步的建議
? 4.3.5 項目立項
項目立項的決定應當由項目團隊之外的、適當級別的、并為項目出資的項目發(fā)起人或投資人作出，通常以項目立項決定（通知）書、項目批文、項目許可證書和項目任務書等形式發(fā)布。
4.4項目開發(fā)計劃
? 1．引言 ? 2．引用文件 ? 3．項目最終成果 ? 4．需求與約束
? 5．系統(tǒng)開發(fā)總體計劃 ? 6．項目開發(fā)詳細計劃 ? 7．進度表與活動網(wǎng)絡圖 ? 8．項目組織與資源 ? 9．培訓
? 10．項目估算 ? 11．風險管理 ? 12．支持條件 ? 13．注解 ? 14．附錄
4.5小節(jié)
? 軟件項目規(guī)劃的任務主要包括項目策劃、可行性研究、論證、評估、立項與項目開發(fā)計劃的制訂工作。
? 項目策劃，也稱項目機會研究，其目的是選擇投資機會、鑒別投資方向。
? 項目可行性分析的目的是確定以下問題：項目有無必要？能否完成？是否值得去做？ ? 項目論證與評估的目的是審查項目可行性研究的可靠性、真實性和客觀性，為項目主管部門或投資機構的立項決策提供科學依據(jù)。
? 項目開發(fā)計劃是項目規(guī)劃階段的重要成果，編寫軟件項目開發(fā)計劃時可依據(jù)《GB/T 8567-2006 計算機軟件文檔編制規(guī)范》中的軟件開發(fā)計劃模版。
? ?
? ? ? ? ?
?
?
?
?
? ? ? ? ? ? ? ? ?
第5章
系統(tǒng)分析方法學 5.1系統(tǒng)需求分析與軟件需求
系統(tǒng)需求：系統(tǒng)總體功能和業(yè)務結構；硬件系統(tǒng)需求；軟件系統(tǒng)需求；硬件系統(tǒng)和軟件系統(tǒng)之間的接口需求。軟件需求：軟件能力需求；軟件外部接口需求；軟件內部接口需求；軟件內部數(shù)據(jù)需求；適應性需求；安全性需求；保密性和私密性需求；軟件環(huán)境需求；計算機資源需求；軟件質量需求；設計和實現(xiàn)的約束；數(shù)據(jù)需求；操作需求；故障處理需求；算法需求；相關人員需求；相關培訓需求；相關后勤需求；包裝需求；其他需求。
5.2結構化分析
結構化分析（SA）方法是一種面向數(shù)據(jù)流的需求分析方法，基本思想是自頂向下逐層分解。
數(shù)據(jù)流圖（DFD）和數(shù)據(jù)字典（DD）是結構化分析最常用的工具。數(shù)據(jù)流圖用來描述數(shù)據(jù)流從輸入到輸出的變換流程。
數(shù)據(jù)字典是關于數(shù)據(jù)的信息的集合，也就是對數(shù)據(jù)流圖中包含的所有元素的定義的集合。
數(shù)據(jù)流圖和數(shù)據(jù)字典共同構成系統(tǒng)的邏輯模型。
5.3原型化方法
? 5.3.1 原型化方法與結構化方法的比較
結構化方法的假設：所有的需求都能被預先定義；修改定義不完備的系統(tǒng)代價昂貴且實施困難；項目參加者之間能夠清晰進行準確的通信；靜態(tài)描述或圖形模型對應用系統(tǒng)的反映是充分的；結構化方法的生命周期的各階段都是固有正確的。
原型化方法的假設：并非所有的需求在系統(tǒng)開發(fā)以前都能準確地說明；有快速的系統(tǒng)建造工具；項目參加者之間通常都存在通信上的障礙；需要實際的、可供用戶參與的系統(tǒng)模型；需求一旦確定，就可以遵從嚴格的方法；大量的反復是不可避免的、必要的，應該加以鼓勵。
? 5.3.2 原型生命周期及其策略
原型生命周期劃分：選擇開發(fā)方法；識別基本需求；開發(fā)工作模型；模型驗證；修正和改進；判定原型完成；差別細部說明；嚴格說明細部；判定原型效果；整理原型和提供文檔。
原型化的策略：建立數(shù)據(jù)模型；利用組合工程；剪裁和粘貼；用系統(tǒng)舉例；字典驅動；文檔的自動化；小的原型化隊伍；交互式開發(fā)平臺；陳述性規(guī)格說明；終端用戶報表生成器；專業(yè)原型化人員；開發(fā)人員參加原型化。
5.4面向對象的分析
? 5.4.1 面向對象方法學概述
對象與封裝 類
繼承與多態(tài)性 消息通信
面向對象方法學的優(yōu)點
? 5.4.2 面向對象的分析方法
OMT方法簡介 建立對象模型 建立動態(tài)模型 建立功能模型
?
?
? ? ?
? ? ? ? ? ? ? 1.? ? 1.? ? ? ? ?
? ? ? ? ? ?
5.5小節(jié)
系統(tǒng)分析涉及系統(tǒng)需求的獲取、分析、規(guī)格說明和確認。系統(tǒng)需求可分為以下幾個方面：系統(tǒng)總體功能和業(yè)務結構、硬件系統(tǒng)需求、軟件系統(tǒng)需求、硬件系統(tǒng)和軟件系統(tǒng)之間的接口需求。
常用的系統(tǒng)分析方法包括結構化分析、原型化方法和面向對象的分析。
第7章
系統(tǒng)分析文檔
7.1系統(tǒng)/子系統(tǒng)需求規(guī)格說明
引言 引用文件
需求：要求的狀態(tài)和方式；需求概述；系統(tǒng)能力需求；系統(tǒng)外部接口需求；系統(tǒng)內部接口需求；系統(tǒng)內部數(shù)據(jù)需求；適應性需求；安全性需求；保密性和私密性需求；操作需求；可使用性、可維護性、可移植性、可靠性和安全性需求；故障處理需求；系統(tǒng)環(huán)境需求；計算機資源需求；系統(tǒng)質量需求；設計和構造的約束；相關人員需求；相關培訓需求；相關后勤需求；包裝需求；其他需求；需求的優(yōu)先次序和關鍵程度 合格性規(guī)定 需求可追蹤性 非技術性需求 尚未解決的問題 注解 附錄
7.2接口需求規(guī)格說明
引言 引用文件 需求
合格性規(guī)定 需求可追蹤性 注解 附錄
7.3軟件需求規(guī)格說明
引言 引用文件
軟件需求：要求的狀態(tài)和方式；需求概述；需求規(guī)格；軟件能力需求；軟件外部接口需求；軟件內部接口需求；軟件內部數(shù)據(jù)需求；適應性需求；安全性需求；保密性和私密性需求；軟件環(huán)境需求；計算機資源需求；軟件質量需求；設計和實現(xiàn)的約束；數(shù)據(jù)需求；操作需求；故障處理需求；算法需求；相關人員需求；相關培訓需求；相關后勤需求；包裝需求；其他需求；需求的優(yōu)先次序和關鍵程度 合格性規(guī)定 需求可追蹤性 尚未解決的問題 注解 附錄
7.4小節(jié)
根據(jù)《GB/T 8567-2006 計算機軟件文檔編制規(guī)范》（Specification for computer
? ? ?
? ?
? ? ? ? ? ?
? ? ? ? ?
?
? software documentation），系統(tǒng)分析文檔主要包括系統(tǒng)/子系統(tǒng)需求規(guī)格說明（SSS）、接口需求規(guī)格說明（IRS）和軟件需求規(guī)格說明（SRS）。系統(tǒng)/子系統(tǒng)需求規(guī)格說明（SSS）為一個系統(tǒng)或子系統(tǒng)指定需求以及保證每個需求得到確認所使用的方法。
接口需求規(guī)格說明（IRS）描述為實現(xiàn)一個或多個系統(tǒng)、子系統(tǒng)、硬件配置項（HWCI）、計算機軟件配置項（CSCI）、用戶
軟件需求規(guī)格說明（SRS）描述對計算機軟件的需求以及確保每個需求得到確認所使用的方法。
第8章
系統(tǒng)設計基礎 8.1系統(tǒng)設計概述
? 8.1.1 系統(tǒng)級設計決策
系統(tǒng)級設計決策，是指系統(tǒng)行為的設計決策（忽略其內部實現(xiàn)，從用戶角度出發(fā)，描述系統(tǒng)將怎樣運轉以滿足需求）和其他對系統(tǒng)部件的選擇和設計產(chǎn)生影響的的決策。系統(tǒng)級設計決策內容：有關系統(tǒng)接收的輸入和產(chǎn)生的輸出的設計決策；對每個輸入或條件進行響應的系統(tǒng)行為的設計決策；系統(tǒng)數(shù)據(jù)庫/數(shù)據(jù)文件如何呈現(xiàn)給用戶的設計決策；為滿足安全性、保密性和私密性需求所選用的方法；硬件或硬軟件系統(tǒng)的設計和構造選擇；為了響應需求而作出的其他系統(tǒng)級設計決策。
? 8.1.2 系統(tǒng)架構設計
總體設計
系統(tǒng)部件設計 動態(tài)交互設計 接口設計
? 8.1.3 運行設計
系統(tǒng)初始化——說明本系統(tǒng)的初始化過程。
運行控制——說明對系統(tǒng)施加不同的外界運行控制時所引起的各種不同的運行組件組合、每種運行所經(jīng)歷的內部組件和支持軟件、每一種外界運行控制的方式方法和操作步驟、每種運行組件組合將占用各種資源的情況以及系統(tǒng)運行時的安全控制。運行結束——說明本系統(tǒng)運行的結束過程。
? 8.1.4 系統(tǒng)出錯處理設計
出錯信息——包括出錯信息表、故障處理技術等。補救措施——說明故障出現(xiàn)后可能采取的補救措施。
? 8.1.5 系統(tǒng)維護設計
檢測點的設計——說明在系統(tǒng)中專門安排用于系統(tǒng)檢查與維護的檢測點。
檢測專用組件的設計——說明在系統(tǒng)中專門安排用于系統(tǒng)檢查與維護的專用組件。
8.2軟件設計概述
? 8.2.1 軟件級設計決策
軟件級設計決策是指軟件行為的設計決策（忽略其內部實現(xiàn)，從用戶角度出發(fā)，描述軟件將怎樣運轉以滿足需求）和其他影響組成該軟件的軟件配置項的選擇與設計的決策。
軟件級設計決策內容：有關軟件接收的輸入和產(chǎn)生的輸出的設計決策；對每個輸入或條件進行響應的軟件行為的設計決策；有關數(shù)據(jù)庫/數(shù)據(jù)文件如何呈現(xiàn)給用戶的設計決策；為滿足安全性、保密性和私密性需求所選用的方法；為響應需求而作出的其他軟件級設計決策。
? 8.2.2 軟件架構設計
? ? ? ? ? ? ? ? ? ? ? 程序結構設計
全局數(shù)據(jù)結構設計 軟件配置項設計 動態(tài)交互設計 接口設計
? 8.2.3 軟件詳細設計
軟件配置項設計決策
軟件配置項設計中的約束、限制或非常規(guī)特征 軟件配置項使用的編程語言考慮 軟件配置項使用的過程式命令選取
軟件配置項的局部數(shù)據(jù)與軟件配置項的輸入或輸出數(shù)據(jù)設計 軟件配置項的邏輯設計
8.3設計原則 ? 8.3.1 組件化
組件的可分解性 組件的可組裝性 組件的可理解性 組件的連續(xù)性 組件的保護性
? 8.3.2 抽象
抽象就是抽出事物的本質特性而暫時忽略其細節(jié)，使得不同的事物可以當作相同的事務來處理。
軟件工程過程的每一步都是對軟件解法的抽象層次的一次精化。
軟件設計中的抽象機制主要包括類、模板、過程抽象、數(shù)據(jù)抽象和控制抽象。
? 8.3.3 內聚與耦合
內聚是指一個組件內各個元素彼此結合的緊密程度 內聚種類（由低到高排列）：偶然內聚；邏輯內聚；瞬時內聚；過程內聚；通信內聚；順序內聚；功能內聚
耦合是指一個軟件結構內不同組件之間的互連程度 耦合種類（由高到低排列）：內容耦合；公共耦合；外部耦合；控制耦合；標記耦合；數(shù)據(jù)耦合；非直接耦合
組件的高內聚、低耦合原則稱為組件獨立原則
? 8.3.4 封裝與信息隱蔽
第一，組件是其全部屬性和全部服務緊密結合而形成的一個不可分割的整體。
第二，組件是一個不透明的黑盒子，表示組件狀態(tài)的數(shù)據(jù)和實現(xiàn)操作的代碼都被封裝在黑盒子里面。使用一個組件的時候，只需知道它向外界提供的接口形式，無須知道它的數(shù)據(jù)結構細節(jié)和實現(xiàn)操作的算法。
? 8.3.5 啟發(fā)式規(guī)則
深度、寬度、扇出與扇入 作用域和控制域 功能的可預測性
8.4設計視圖
? 8.4.1 架構視圖（靜態(tài)視圖）
架構描述語言（ADL）? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
? ? ?
?
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
? ? 類圖與對象圖 組件圖
協(xié)作責任卡（CRC）部署圖
實體-聯(lián)系圖（E-R圖）接口描述語言（IDL）結構圖
Jackson結構圖
? 8.4.2 行為視圖（動態(tài)視圖）
活動圖 協(xié)作圖 順序圖 數(shù)據(jù)流圖
決策表和決策圖
流程圖和結構化流程圖 狀態(tài)圖
形式化描述語言 偽碼
8.5小節(jié)
系統(tǒng)設計是定義一個系統(tǒng)或軟件的架構、組件、接口和其它特征的過程。包括系統(tǒng)級設計決策、系統(tǒng)架構設計、運行設計、系統(tǒng)出錯處理設計和系統(tǒng)維護設計。
軟件設計主要包括軟件級設計決策、軟件架構設計（概要設計）與詳細設計。軟件架構設計的主要任務是程序結構設計、全局數(shù)據(jù)結構設計、軟件配置項設計、動態(tài)交互設計和接口設計。軟件詳細設計是指每一個軟件配置項的具體設計。
組件化、抽象、高內聚與低耦和、封裝與信息隱蔽是軟件設計的基本原則。軟件設計視圖通?？煞譃榧軜嬕晥D（靜態(tài)視圖）和行為視圖（動態(tài)視圖）兩類。第9章
系統(tǒng)設計方法 9.1結構化設計
? 9.1.1 結構化設計方法概述
分析系統(tǒng)的總體需求，并將需求逐步分解為基本、具體的功能。確定每個功能應當記錄的數(shù)據(jù)。
列出系統(tǒng)中應提供的各項基本功能，并分析各項基本功能之間的耦合關系，根據(jù)高內聚、低耦和的原則分配到系統(tǒng)中適當?shù)哪K中。
? 9.1.2 系統(tǒng)結構圖
模塊 調用 數(shù)據(jù) 控制 轉接符號
? 9.1.3 系統(tǒng)結構圖分類
變換流與事務流 變換型系統(tǒng)結構圖 事務型系統(tǒng)結構圖 ? ? ?
? ? ? ? ? ? ? ?
? 混合型系統(tǒng)結構圖
9.2面向數(shù)據(jù)結構的設計
? 9.2.1 面向數(shù)據(jù)結構的設計概述
分析并建立適合系統(tǒng)的數(shù)據(jù)結構；
根據(jù)數(shù)據(jù)結構在相應的層次建立程序結構；
羅列出程序中用到的各種基本操作，并將這些基本操作分配到程序結構中合適的模塊中。
? 9.2.2 Jackson圖
順序結構 選擇結構 重復結構
改進的Jackson圖
? 9.2.3 Jackson方法
分析并確定輸入和輸出數(shù)據(jù)的邏輯結構，并利用Jackson 找出輸入和輸出數(shù)據(jù)結構中存在對應關系的數(shù)據(jù)單元。從描繪數(shù)據(jù)結構的Jackson圖導出描繪程序結構的Jackson
列出所有操作和條件(包括分支條件和循環(huán)結束條件)，并且把它們安排到程序結構圖的適當位置。用偽代碼表示。
9.3面向對象的設計
? 9.3.1 面向對象的設計概述
面向對象設計的基本思想是通過建立和客觀實際相對應的對象，并通過這些對象的組合來創(chuàng)建具體的應用。
面向對象設計具有基于抽象、信息隱藏、功能獨立和模塊性構造系統(tǒng)的能力。
對于面向對象的系統(tǒng)，可以定義一個四個層次的設計金字塔：子系統(tǒng)層；類及對象層；消息層；責任層。
? 9.3.2 面向對象設計技術
? Coad/Yourdon方法 ? Booch方法 ? OMT方法 ? ?
? 9.3.3 面向對象設計過程
系統(tǒng)設計過程：將分析模型劃分為子系統(tǒng)；子系統(tǒng)分配及與問題的并發(fā)性；任務管理；數(shù)據(jù)管理；資源管理；人機界面；子系統(tǒng)間通信
對象設計過程：對象描述；算法與數(shù)據(jù)結構設計；接口設計與模塊化
9.4設計模式
? 9.4.1 設計模式概述
設計模式就是將面向對象軟件的設計經(jīng)驗記錄下，可供設計者能夠復用的設計方案。設計模式極大提高了面向對象軟件開發(fā)的效率，降低了軟件的復雜度。
在軟件設計中使用設計模式，將使用開發(fā)出來的軟件更容易理解、更容易維護、更容易擴展，使用設計模式同時也能夠提高開發(fā)團隊和個人的開發(fā)能力。
? 9.4.2 設計模式基本組成
模式名稱：惟一標識一個設計模式。問題：描述應該在何時使用該模式。? ? ?
? ? ? ? ? ? ? ? ?
? ? ?
? ? ?
? ?
? 解決方案：描述設計的組成要素，以及它們之間的相互關系及各自的職責與相互之間協(xié)作的方式。
? 效果：描述應用設計模式的效果，以及使用設計模式必須考慮的限制和約束因素。
? 9.4.3 設計模式分類
? 面向對象模式 ? 代碼模式
? 框架應用模式
? 創(chuàng)建型模式、結構型模式與行為型模式 ? 類模式與對象模式
? 9.4.4 如何使用設計模式
? 針對接口編程，而不是針對實現(xiàn)編程 ? 優(yōu)先使用對象組合，而不是類繼承 ? 找出變化并封裝
9.5小節(jié)
? 系統(tǒng)設計是一系列迭代的過程，主要任務包括數(shù)據(jù)結構、體系結構、接口及過程細節(jié)的設計等，而設計方法是軟件設計活動中實現(xiàn)設計模型的方法。? 系統(tǒng)設計方法主要包括面向過程的結構化設計方法、面向數(shù)據(jù)結構的設計，以及面向對象的設計方法與設計模式。
第10章
數(shù)據(jù)庫設計 10.1數(shù)據(jù)建模
? 10.1.1 數(shù)據(jù)模型分類
? 概念數(shù)據(jù)模型 ? 結構數(shù)據(jù)模型 ? 物理數(shù)據(jù)模型
? 10.1.2 實體-聯(lián)系（E-R）模型
? 實體 ? 屬性 ? 聯(lián)系 ? 實體型 ? 實體集 ? 鍵 ? 域
? 10.1.3 數(shù)據(jù)模型
? 層次數(shù)據(jù)模型（hierarchical model）? 網(wǎng)狀數(shù)據(jù)模型（network model）? 關系數(shù)據(jù)模型（relational model）
? 面向對象模型（object oriented model）
10.2數(shù)據(jù)規(guī)范化
? 10.2.1 數(shù)據(jù)規(guī)范化的基本概念
? 函數(shù)依賴
? 非平凡函數(shù)依賴 ? 完全函數(shù)依賴 ? 部分函數(shù)依賴
? 傳遞函數(shù)依賴 ? 鍵
? 10.2.2 范式
? ? ? ? 第一范式（1NF）第二范式（2NF）第三范式（3NF）BC范式（BCNF）
10.3數(shù)據(jù)庫設計過程 ? 10.3.1 數(shù)據(jù)庫需求分析
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 數(shù)據(jù)邊界的確定 數(shù)據(jù)環(huán)境的確定 數(shù)據(jù)內部關系 數(shù)據(jù)字典
數(shù)據(jù)性能需求
數(shù)據(jù)需求分析說明書
? 10.3.2 數(shù)據(jù)庫概念設計
概念設計與概念模型 概念設計的主要方法 分解與抽象 局部概念模式 全局概念模式
? 10.3.3 數(shù)據(jù)庫邏輯設計
初始模式的形成 子模式設計
應用程序概要設計 模式評審 修正模式
? 10.3.4 數(shù)據(jù)庫物理設計
存儲記錄結構設計 確定數(shù)據(jù)存放位置 存取方法設計
完整性和安全考慮 程序設計
10.4小節(jié)
? 數(shù)據(jù)庫系統(tǒng)普遍采取數(shù)據(jù)模型表示和處理客觀事物的數(shù)據(jù)特征與信息。數(shù)據(jù)模型主要由數(shù)據(jù)結構、數(shù)據(jù)操作和完整性約束三部分組成，從抽象層次上描述和模擬了系統(tǒng)的靜態(tài)特征、動態(tài)行為和約束條件。
? 關系數(shù)據(jù)庫中的關系必須滿足一定的要求，即滿足不同的范式。目前關系數(shù)據(jù)庫中常用的范式包括：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）和BCNF。? 數(shù)據(jù)庫設計主要包括需求分析、概念設計、邏輯設計和物理設計等幾個階段。
第11章
用戶界面設計
11.1基本概念
? ? ?
? ? ? ? ? ? ? ? ? ?
? ? ? ? ? ?
? ? ? ? ? ? ? ? ? ? ? ?
? 11.1.1 界面設計目標
可用性目標：可行性、有效性、易學性、易記性、安全性、通用性
用戶體驗目標：令人滿意、令人愉快、引人入勝、富有啟發(fā)、激發(fā)創(chuàng)造??
可用性目標主要從客觀角度來評價系統(tǒng)界面，而用戶體驗目標則是從用戶主觀感受的角度來評價系統(tǒng)界面。
? 11.1.2 界面設計原則
可視性：將系統(tǒng)功能呈現(xiàn)得一目了然。
反饋性：返回與活動相關的信息，以便用戶能夠繼續(xù)這個活動。限制性：將用戶的行為限制在一定的范圍內。
對應性：明確系統(tǒng)某個控制與其控制效果之間的對應關系。一致性：用相似的元素表現(xiàn)相似的操作或相似的任務。啟示性：界面元素應給予用戶某種提示。
? 11.1.3 界面設計過程
標識出用戶的真實需要并建立需求模型 設計出候選方案
構建或實現(xiàn)設計的原型版本 對界面設計進行評估
11.2界面設計技術
? 11.2.1 界面設計分析技術
GOMS模型及GOMS擊鍵層模型 Hick律 Fitts律
? 11.2.2 界面設計方法
原型設計方法
以用戶為中心的設計方法 用戶界面設計的支持工具
11.3界面設計評估
? 11.3.1 構造性評估與總結性評估
構造性評估：在設計過程中對所設計的系統(tǒng)或產(chǎn)品界面進行評估以確保其滿足用戶需求。
總結性評估：對已經(jīng)完成的產(chǎn)品或系統(tǒng)界面進行評估。
? 11.3.2 評估范型
快速評估 可用性測試 實地研究 預測性評估
? 11.3.3 評估方法與技術
觀察用戶
征求用戶意見 征求專家意見 用戶測試
用戶執(zhí)行情況的分析模型
? 11.3.4 評估框架
明確（Determine）
? ? ? ? ? ? ? ? ?
發(fā)掘（Explore）選擇（Choose）標識（Identify）決定（Decide）評估（Evalute）
11.5小節(jié)
用戶界面體現(xiàn)了用戶利用系統(tǒng)完成任務的方式以及系統(tǒng)對用戶行為的響應方式，一個沒有良好的用戶界面設計的系統(tǒng)很可能會成為一個沒有用戶的系統(tǒng)。可用性目標與用戶體驗目標。
界面設計的量化模型：GOMS模型及其子模型-擊鍵層模型，Hick律和Fitts律。構造性評估與總結性評估。
第12章
系統(tǒng)設計文檔
12.1系統(tǒng)/子系統(tǒng)（結構）設計說明
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 引言 引用文件
系統(tǒng)級設計決策
系統(tǒng)體系結構設計：總體設計；系統(tǒng)部件設計；動態(tài)交互設計；接口設計 運行設計
系統(tǒng)出錯處理設計 系統(tǒng)維護設計 尚未解決的問題 需求的可追蹤性 注解 附錄
12.2
接口設計說明
引言 引用文件 接口設計
需求的可追蹤性 注解 附錄
12.3
軟件（結構）設計說明
引言 引用文件
軟件級設計決策
軟件體系結構設計：程序結構設計；全局數(shù)據(jù)結構設計；軟件配置項設計；動態(tài)交互設計；接口設計 軟件詳細設計 需求的可追蹤性 注解 附錄
12.4數(shù)據(jù)庫設計說明
? ? ? ? ? ? ? ? ?
? ? ? ? ?
引言 引用文件
數(shù)據(jù)庫級設計決策 數(shù)據(jù)庫詳細設計
用于數(shù)據(jù)庫操縱或訪問的軟件配置項的詳細設計 需求的可追蹤性 注解 附錄
12.5
小節(jié)
根據(jù)《GB/T 8567-2006 計算機軟件文檔編制規(guī)范》，系統(tǒng)設計文檔主要包括系統(tǒng)/子系統(tǒng)設計（結構設計）說明（SSDD）、接口設計說明（IDD）、軟件（結構）設計說明（SDD）和數(shù)據(jù)庫設計說明（DBDD）。
系統(tǒng)/子系統(tǒng)設計（結構設計）說明（SSDD）描述了系統(tǒng)（或子系統(tǒng)）的系統(tǒng)級（或子系統(tǒng)級）設計決策與體系結構設計。
接口設計說明（IDD）描述了一個或多個系統(tǒng)、子系統(tǒng)、硬件配置項（HWCI）、計算機軟件配置項（CSCI）、用戶或其他系統(tǒng)部件的接口特性。
軟件（結構）設計說明（SDD）描述了計算機軟件系統(tǒng)的軟件級設計決策、軟件體系結構設計（概要設計）與詳細設計。
數(shù)據(jù)庫（頂層）設計說明（DBDD）描述了數(shù)據(jù)庫的設計。系統(tǒng)設計文檔可以使用自然語言，可以使用形式化語言，也可以根據(jù)具體的系統(tǒng)設計方法使用各種圖形工具，還可以根據(jù)實際情況混合使用多種表現(xiàn)形式。
第四篇：系統(tǒng)分析與設計 期末考試
10.在一個課程注冊系統(tǒng)中，定義了類CourseSchedule和類Course，并在類CourseSchedule中定義了方法add(c: Course)和方法remove(c: Course)，則類CourseSchedule和類Course之間的關系是：（）A.泛化（generalization）關系 B.組合（composition）關系 C.依賴（dependency）關系 D.包含（include）關系 13.進行企業(yè)系統(tǒng)規(guī)劃，哪種規(guī)劃方法使目標識別比較全面
A、企業(yè)系統(tǒng)規(guī)劃法 B、關鍵成功因素法
C、戰(zhàn)略目標集轉化法 D、成本效益分析法 14.系統(tǒng)開發(fā)的生命周期中不包括下列哪個階段（）A.系統(tǒng)規(guī)劃 B.系統(tǒng)分析 C.系統(tǒng)設計 D.系統(tǒng)實施
19.面向對象程序設計將描述事物的數(shù)據(jù)與()封裝在一起,作為一個相互依存、不可分割的整體來處理。A.信息 B.數(shù)據(jù)隱藏 C.對數(shù)據(jù)的操作 D.數(shù)據(jù)抽象 22.屬于系統(tǒng)設計階段的工具是（）：
A.數(shù)據(jù)流程圖 B.處理流程圖 C.系統(tǒng)流程圖 D.HIPO圖
23.進行企業(yè)系統(tǒng)規(guī)劃，哪種規(guī)劃方法可以形成一套完整的信息系統(tǒng)結構方案（）A.企業(yè)系統(tǒng)規(guī)劃法 B.關鍵成功因素法 C.戰(zhàn)略目標集轉化法 D.成本效益分析法
30.導出模塊結構圖的基礎是（）
A.業(yè)務流程圖 B.數(shù)據(jù)流程圖 C.處理流程圖 D.層次結構圖
32.（）是從用戶使用系統(tǒng)的角度描述系統(tǒng)功能的圖形表達方法。
A.類圖 B.對象圖 C.序列圖 D.用例圖
35.UML中，對象行為是通過交互來實現(xiàn)的，是對象間為完成某一目的而進行的一系列消息交換。消息序列可用兩種圖來表示，分別是（D）
A.狀態(tài)圖和順序圖 B.活動圖和協(xié)作圖
C.狀態(tài)圖和活動圖 D.順序圖和協(xié)作圖
36.用例（Use-case）用來描述系統(tǒng)在事件做出響應時所采取的行動。用例之間是具有相關性的。在一個“訂單輸入子系統(tǒng)”中，創(chuàng)建新訂單和更新訂單都需要檢查用戶帳號是否正確。那么，用例“創(chuàng)建新訂單”、“更新訂單”與用例“檢查用戶帳號”之間是（A）關系。
A.包含（include）B.擴展（extend）
C.分類（classification）D.聚集（aggregation）
1、組成UML有三種基本的建筑塊是：（A），事物和圖
A、關系 B、類 C、用例 D、實體
2、UML體系包括三個部分：UML基本構造塊，（A）和UML公共機制
A、UML規(guī)則 B、UML命名 C、UML模型 D、UML約束
4、（A）模型的缺點是缺乏靈活性，特別是無法解決軟件需求不明確或不準確的問題
A、瀑布模型 B、原型模型 C、增量模型 D、螺旋模型
5、下面哪個不是UML中的靜態(tài)視圖（A）
A.狀態(tài)圖 B.用例圖 C.對象圖 D.類圖
6、（A）技術是將一個活動圖中的活動狀態(tài)進行分組，每一組表示一個特定的類、人或部門，他們負責完成組內的活動。
A、泳道 B、分叉匯合 C、分支 D、轉移
7、下列關于狀態(tài)圖的說法中，正確的是（C）
A.狀態(tài)圖是UML中對系統(tǒng)的靜態(tài)方面進行建模的五種圖之一。B.狀態(tài)圖是活動圖的一個特例，狀態(tài)圖中的多數(shù)狀態(tài)是活動狀態(tài)
C.活動圖和狀態(tài)圖是對一個對象的生命周期進行建模，描述對象隨時間變化的行為。D.狀態(tài)圖強調對有幾個對象參與的活動過程建模，而活動圖更強調對單個反應型對象建模
8、對反應型對象建模一般使用（A）圖
A、狀態(tài)圖 B、順序圖 C、活動圖 D、類圖
12、（D）是系統(tǒng)中遵從一組接口且提供實現(xiàn)的一個物理部件，通常指開發(fā)和運行時類的物理實現(xiàn) A、部署圖 B、類 C、接口 D、組件
13、關于協(xié)作圖的描述，下列哪個不正確（B）
A.協(xié)作圖作為一種交互圖，強調的是參加交互的對象的組織； B.協(xié)作圖是順序圖的一種特例 C.協(xié)作圖中有消息流的順序號；
D.在ROSE工具中，協(xié)作圖可在順序圖的基礎上按“F5”鍵自動生成； 8定義大多數(shù)的需求和范圍的工作是在UP中的 B 階段完成的。A初始階段 B細化階段 C構造階段 D提交階段
1.信息系統(tǒng)設計是系統(tǒng)開發(fā)的重要階段，進行系統(tǒng)設計的主要依據(jù)應是（）。A、可行性研究報告B 系統(tǒng)分析報告
C、系統(tǒng)調查報告 D、系統(tǒng)規(guī)劃報告
3.在系統(tǒng)總體結構設計時，應采納什么樣的方法（）。A、程序設計 B、結構化設計 C、由里向外 D、自底向上 4.結構化設計的基本思想是（）。
A、模塊化 B、集成化 C、自底向上，逐步求精 D、規(guī)范化
5.在結構化生命周期法中，系統(tǒng)分析和系統(tǒng)實施之間的階段是（）。A、詳細設計 B系統(tǒng)設計 C、需求分析 D、編程調試 6.對于結構化設計思想的描述哪一項是錯誤的（）。
A、在結構化設計中，模塊的功能應當簡單明確，易于理解 B、自頂向下，逐步求精
C、設計者應先設計頂層模塊
D、越下層模塊，其功能越具體，越復雜 8.系統(tǒng)設計階段的主要目的是（）。
A、設計新系統(tǒng)的目標 B 將系統(tǒng)邏輯方案轉換成物理方案 C、代碼設計 D、程序設計 19.結構化設計方法中繪制模塊結構圖的基礎是（）。A 數(shù)據(jù)流程圖 B、數(shù)據(jù)關系圖 C、數(shù)據(jù)結構圖 D、業(yè)務流程圖 29.系統(tǒng)設計階段的主要工作內容之一是（）。
A、程序設計 B、購置計算機 C、畫出數(shù)據(jù)流程圖 B、規(guī)定處理過程 31.系統(tǒng)的呑吐量指的是（）。
A、每天的數(shù)據(jù)輸出量 B、每秒數(shù)據(jù)的處理量 C、每日數(shù)據(jù)的輸入量 D、每秒執(zhí)行的作業(yè)數(shù)
33.在系統(tǒng)物理配置方案的設計中，系統(tǒng)的（）可以用連續(xù)工作時間來表示。A、吞吐量 B、響應時間 C 可靠性 D、地域范圍 34.計算機和網(wǎng)絡系統(tǒng)配置說明，應包含在()中。
A、系統(tǒng)規(guī)劃說明書 B、系統(tǒng)設計說明書 C、系統(tǒng)實施說明書 D、系統(tǒng)分析說明書 35.屬于系統(tǒng)詳細設計工作的是（）。
A、輸入輸出設計 B、系統(tǒng)平臺設計 C、系統(tǒng)結構設計 D、程序設計 39.系統(tǒng)設計報告的主要作用是作為（）的依據(jù)。A、系統(tǒng)規(guī)劃 B、系統(tǒng)分析 C、系統(tǒng)實施 D、系統(tǒng)評價
1.B 3.B 4.A 5.B 6.D8.B 19.A 29.D 31.D 33.C 34.B 35.A 39.C 11.系統(tǒng)設計階段需要從數(shù)據(jù)流程圖導出模塊結構圖。B.生命周期結構(Lifecycle Architecture)里程碑 4．系統(tǒng)實施的主要活動包括（D）。C.初始功能(Initial Operational)里程碑 A、編程、系統(tǒng)調試 B、系統(tǒng)安裝 C、新舊系統(tǒng)轉換 D、以上都是 1．系統(tǒng)實施是以（B）為依據(jù)的。
A、系統(tǒng)分析文檔資料 B、系統(tǒng)設計文檔資料
C、系統(tǒng)分析和設計文檔資料 D、數(shù)據(jù)流程圖
7.一般子系統(tǒng)的劃分是在系統(tǒng)()階段,根據(jù)對系統(tǒng)的功能/數(shù)據(jù)分析的結果提出的.A.需求分析 B.邏輯階段 C.總體設計 D.詳細設計 答案: A 4.業(yè)務系統(tǒng)規(guī)劃法(BSP)的核心是()A.明確企業(yè)目標 B.定義(識別)業(yè)務過程 C.進行數(shù)據(jù)分析 D.確定信息結構 答案: C 7.一般子系統(tǒng)的劃分是在系統(tǒng)()階段,根據(jù)對系統(tǒng)的功能/數(shù)據(jù)分析的結果提出的.A.需求分析 B.邏輯階段 C.總體設計 D.詳細設計 答案: A 4.業(yè)務系統(tǒng)規(guī)劃法(BSP)的核心是()A.明確企業(yè)目標 B.定義(識別)業(yè)務過程 C.進行數(shù)據(jù)分析 D.確定信息結構 答案: C 12.RUP中的軟件生命周期在時間上被分解為四個順序的階段,分別是:初始階段(Inception),細化階段(Elaboration),構造階段(Construction)和交付階段(Transition),每個階段結束于一個主要的里程碑(Major Milestones).構建階段結束時是第三個重要的里程碑:初始功能(Initial Operational)里程碑.A.生命周期目標(Lifecycle Objective)里程碑
D.產(chǎn)品發(fā)布(Product Release)里程碑 答案: C
14.信息系統(tǒng)開發(fā)的結構化方法的一個主要原則是().A.自頂向下原則 B.自底向上原則 C.分步實施原則 D.重點突破原則 答案: A
16.一般來說,占維護工作比例最高的是().A.糾錯性維護 B.適應性維護 C.完善性維護 D.預防性維護 答案: C
17.用戶開發(fā)應用系統(tǒng)的主要手段是().A.生命周期法 B.原型法 C.第四代語言 D.面向對象方法 答案: A
19.系統(tǒng)規(guī)劃的主要任務包括().A.明確組織的信息需求,制定系統(tǒng)總體結構方案 B.對系統(tǒng)進行經(jīng)濟,技術和使用方面的可行性研究 C.選擇計算機和網(wǎng)絡系統(tǒng)的方案 D.確定軟件系統(tǒng)的模塊結構 答案: A
20.系統(tǒng)設計階段的主要成果是().A.用戶的決策方針 B.用戶的分析方案 C.系統(tǒng)設計說明書 D.系統(tǒng)總體設計方案
答案: C
21.信息系統(tǒng)建設的結構化方法中用戶必須參與的原則是用戶必須參與().A.系統(tǒng)建設中各階段工作 B.系統(tǒng)分析工作 C.系統(tǒng)設計工作 D.系統(tǒng)實施工作 答案: A
22.結構化生命周期法的主要缺點之一是().A.系統(tǒng)開發(fā)周期長 B.缺乏標準,規(guī)范
C.用戶參與程度低 D.主要工作集中在實施階段 答案: A 24.系統(tǒng)分析工作的全面總結和主要成果是().A.可行性研究報告B.數(shù)據(jù)詞典 C.系統(tǒng)說明書 D.系統(tǒng)詳細調查報告 答案: A 28.生命周期法的特點之一是().A.整個系統(tǒng)的開發(fā)工作是非勞動密集型的 B.系統(tǒng)開發(fā)時間短
C.對用戶需求的變更能做出迅速響應 D.適合大型復雜系統(tǒng) 答案: C 30.系統(tǒng)維護中要解決的問題來源于().A.系統(tǒng)分析階段 B.系統(tǒng)設計階段 C.系統(tǒng)實施階段 D.三者都包括
答案: D 38.下面哪一項不是系統(tǒng)設計階段的主要活動().A.系統(tǒng)總體設計 B.系統(tǒng)硬件設計 C.系統(tǒng)詳細設計 D.編寫系統(tǒng)實施計劃 答案: D 39.對于結構化設計思想的描述哪一項是錯誤的().A.在結構化設計中,模塊的功能應當簡單明確,易于理解
B.自頂向下,逐步求精
C.設計者應先設計頂層模塊
D.越下層模塊,其功能越具體,越復雜
答案: D 73.在系統(tǒng)生命周期的各階段中,花費費用和人力投入最多的階段是().A.分析與設計 B.編制程序 C.測試程序 D.系統(tǒng)維護
答案: A 78.在UML提供的圖中,()用于描述系統(tǒng)與外部系統(tǒng)及用戶之間的交互.A.用例圖 B.類圖 C.對象圖 D.部署圖
答案:A 79.在UML提供的圖中,()用于按時間順序描述對象間的交互.A.網(wǎng)絡圖 B.狀態(tài)圖 C.協(xié)作圖 D.序列圖（順序圖）答案:D 96.系統(tǒng)分析報告的主要作用是().A.系統(tǒng)規(guī)劃的依據(jù) B.系統(tǒng)實施的依據(jù) C.系統(tǒng)設計的依據(jù) D.系統(tǒng)評價的依據(jù) 答案:C 95.繪制系統(tǒng)流程圖的基礎是().A.數(shù)據(jù)關系圖 B.數(shù)據(jù)流程圖 C.數(shù)據(jù)結構圖 D.功能結構圖 答案:B
9.信息系統(tǒng)開發(fā)的步驟是:在系統(tǒng)規(guī)劃后,循進行_____, _____, _____ ,_____ 工作.答案: 系統(tǒng)分析 系統(tǒng)設計 系統(tǒng)構建與實施 系統(tǒng)評價 13.信息系統(tǒng)規(guī)劃有哪些方法
答:用于企業(yè)信息系統(tǒng)規(guī)劃的方法主要有戰(zhàn)略分析法,即關鍵成功因素法(Critical Success Factors,CSF);企業(yè)分析法,即企業(yè)系統(tǒng)規(guī)劃法(Business System Planning,BSP);基于BPR的信息系統(tǒng)戰(zhàn)略規(guī)劃方法.其他的方法還有戰(zhàn)略目標集轉化法(Strategy Set Transformation,SST),企業(yè)信息分析與集成技術(BIAIT),投資回收法(R01)等.12.RUP中的軟件生命周期在時間上被分解為四個順序的階段,分別是:初始階段(Inception),細化階段(Elaboration),構造階段(Construction)和交付階段(Transition),每個階段結束于一個主要的里程碑(Major Milestones).構建階段結束時是第三個重要的里程碑:初始功能(Initial Operational)里程碑.A.生命周期目標(Lifecycle Objective)里程碑 B.生命周期結構(Lifecycle Architecture)里程碑 C.初始功能(Initial Operational)里程碑 D.產(chǎn)品發(fā)布(Product Release)里程碑
答案: C
14.信息系統(tǒng)開發(fā)的結構化方法的一個主要原則是().A.自頂向下原則 B.自底向上原則 C.分步實施原則 D.重點突破原則 答案: A
16.一般來說,占維護工作比例最高的是().A.糾錯性維護 B.適應性維護 C.完善性維護 D.預防性維護 答案: C
17.用戶開發(fā)應用系統(tǒng)的主要手段是().A.生命周期法 B.原型法 C.第四代語言 D.面向對象方法
答案: A
19.系統(tǒng)規(guī)劃的主要任務包括().A.明確組織的信息需求,制定系統(tǒng)總體結構方案 B.對系統(tǒng)進行經(jīng)濟,技術和使用方面的可行性研究 C.選擇計算機和網(wǎng)絡系統(tǒng)的方案 D.確定軟件系統(tǒng)的模塊結構 答案: A
20.系統(tǒng)設計階段的主要成果是().A.用戶的決策方針 B.用戶的分析方案 C.系統(tǒng)設計說明書 D.系統(tǒng)總體設計方案 答案: C
21.信息系統(tǒng)建設的結構化方法中用戶必須參與的原則是用戶必須參與().A.系統(tǒng)建設中各階段工作 B.系統(tǒng)分析工作 C.系統(tǒng)設計工作 D.系統(tǒng)實施工作 答案: A 22.結構化生命周期法的主要缺點之一是().A.系統(tǒng)開發(fā)周期長 B.缺乏標準,規(guī)范
C.用戶參與程度低 D.主要工作集中在實施階段 答案: A 24.系統(tǒng)分析工作的全面總結和主要成果是().A.可行性研究報告B.數(shù)據(jù)詞典 C.系統(tǒng)說明書 D.系統(tǒng)詳細調查報告 答案: A 28.生命周期法的特點之一是().A.整個系統(tǒng)的開發(fā)工作是非勞動密集型的 B.系統(tǒng)開發(fā)時間短
C.對用戶需求的變更能做出迅速響應 D.適合大型復雜系統(tǒng) 答案: C 30.系統(tǒng)維護中要解決的問題來源于().A.系統(tǒng)分析階段 B.系統(tǒng)設計階段 C.系統(tǒng)實施階段 D.三者都包括 答案: D 38.下面哪一項不是系統(tǒng)設計階段的主要活動().A.系統(tǒng)總體設計 B.系統(tǒng)硬件設計 C.系統(tǒng)詳細設計 D.編寫系統(tǒng)實施計劃
答案: D 39.對于結構化設計思想的描述哪一項是錯誤的().A.在結構化設計中,模塊的功能應當簡單明確,易于理解
B.自頂向下,逐步求精
C.設計者應先設計頂層模塊
D.越下層模塊,其功能越具體,越復雜
答案: D 73.在系統(tǒng)生命周期的各階段中,花費費用和人力投入最多的階段是().A.分析與設計 B.編制程序 C.測試程序 D.系統(tǒng)維護
答案: A 78.在UML提供的圖中,()用于描述系統(tǒng)與外部系統(tǒng)及用戶之間的交互.A.用例圖 B.類圖 C.對象圖 D.部署圖 答案:A 79.在UML提供的圖中,()用于按時間順序描述對象間的交互.A.網(wǎng)絡圖 B.狀態(tài)圖 C.協(xié)作圖 D.序列圖（順序圖）
答案:D
96.系統(tǒng)分析報告的主要作用是().A.系統(tǒng)規(guī)劃的依據(jù) B.系統(tǒng)實施的依據(jù) C.系統(tǒng)設計的依據(jù) D.系統(tǒng)評價的依據(jù) 答案:C
95.繪制系統(tǒng)流程圖的基礎是().A.數(shù)據(jù)關系圖 B.數(shù)據(jù)流程圖 C.數(shù)據(jù)結構圖 D.功能結構圖 答案:B
9.信息系統(tǒng)開發(fā)的步驟是:在系統(tǒng)規(guī)劃后,循進行_____, _____, _____ ,_____ 工作.答案: 系統(tǒng)分析 系統(tǒng)設計 系統(tǒng)構建與實施 系統(tǒng)評價 13.信息系統(tǒng)規(guī)劃有哪些方法
答:用于企業(yè)信息系統(tǒng)規(guī)劃的方法主要有戰(zhàn)略分析法,即關鍵成功因素法(Critical Success Factors,CSF);企業(yè)分析法,即企業(yè)系統(tǒng)規(guī)劃法(Business System Planning,BSP);基于BPR的信息系統(tǒng)戰(zhàn)略規(guī)劃方法.其他的方法還有戰(zhàn)略目標集轉化法(Strategy Set Transformation,SST),企業(yè)信息分析與集成技術(BIAIT),投資回收法(R01)等.2.信息系統(tǒng)規(guī)劃是指對組織目標、組織現(xiàn)狀進行分析，從而制定指導信息系統(tǒng)建設的總體規(guī)劃和信息系統(tǒng)長期發(fā)展展望。在眾多的信息系統(tǒng)規(guī)劃方法當中，具有代表性的主要有 企業(yè)系統(tǒng)規(guī)劃法、戰(zhàn)略目標轉移法、關鍵成功因素法。
4.信息系統(tǒng)建設的特點決定了信息系統(tǒng)建設要做大量復雜和細致的工作。信息系統(tǒng)建設主要包括 信息系統(tǒng)規(guī)劃、信息系統(tǒng)開發(fā)、信息系統(tǒng)維護 和 信息系統(tǒng)管理 四方面的工作。
1． UML統(tǒng)一建模語言共定義了哪兩類、哪八種圖形？
答：（1）靜態(tài)結構圖：類圖，對象圖，構件圖，實施圖
（2）動態(tài)行為圖：用例圖，順序圖，協(xié)作圖，狀態(tài)圖，活動圖
2.在下圖所示的用例分析類圖中，請指出各個概念類屬于哪一類，并分別解釋三種概念類的特點及概念。“售書處理”的用例分析類圖書目售書員售書界面產(chǎn)生待售圖書待售圖書開書單打印進程架存圖書出售圖書售出圖書答：屬于實體類的有：書目、架存圖書、代售圖書、售出圖書。
屬于邊界類的有：售書界面。
屬于控制類的有：產(chǎn)生待售圖書、出售圖書、開書單。三種概念類的特點及概念：
特點：概念類面向功能需求，一般不考慮性能要求，具有突出業(yè)務領域、突出概念性及大粒度的特征。概念：（1）實體類是信息系統(tǒng)表示客觀實體的抽象要素。它一般對應著在業(yè)務領域中的客觀事物，或是具有較穩(wěn)定信息內容的系統(tǒng)元素。（2）邊界類是描述系統(tǒng)與參與者之間交互的抽象要素。邊界類只是對信息系統(tǒng)與參與者之間交互的抽象建模，并不表示交互的具體內容及交互界面的具體形式。
（3）控制類是表示信息系統(tǒng)對其他對象實施協(xié)調處理、邏輯運算的抽象要素。3．請根據(jù)下圖所示的概念模型，將其轉換為邏輯模型(即寫出其關系模式)。
編號姓名讀者職業(yè)電話住址郵編*待售圖書*類別單價出版日期書號架位架存冊數(shù)書號書名作者出版社1選書*架存圖書*11書目書單號冊數(shù)折扣率交款標記售書員答：根據(jù)其E-R圖，其關系模式為：
讀者(編號，姓名，職業(yè)，電話，住址，郵編)架存圖書(書號，架位，架存冊數(shù))
待售圖書(書單號，冊數(shù)，折扣率，交款標記，售書員)書目(書號，書名，作者，出版社，出版日期，類別，單價)9.如圖，是在網(wǎng)上商店系統(tǒng)經(jīng)理的用例圖如下：
網(wǎng)上購物系統(tǒng)顧客的功能用例
1.單一職責原則（Single Responsibility Principle, SRP）：
? There should never be more than one reason for a class to change.? 應該有且僅有一個原因引起類的變更 2.里氏替換原則 最正宗的定義：
If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when o1 is substituted for o2 then S is a subtype of T.（如果對每一個類型為S的對象o1，都有類型為T的對象o2，使得以T定義的所有程序P在所有的對象o1都代換成o2時，程序P的行為沒有發(fā)生變化，那么類型S是類型T的子類型。）里氏替換原則
通俗講，只要父類出現(xiàn)的地方子類就可以出現(xiàn)，而且替換為子類也不會產(chǎn)生任何錯誤或異常，使用者可能根本就不需要知道是父類還是子類。但是反過來就不行了，有子類出現(xiàn)的地方，父類未必就能適應。3.迪米特法則
迪米特法則的定義：
迪米特法則（Law of Demeter, LoD）也稱為最少知識原則，一個對象應該對其他對象有最少的了解。
一個類應該對自己需要耦合或調用的類知道得最少，被耦合或調用的類的內部如何復雜都和我沒有關系，那是你的事情，我就知道你提供的這么多public方法，我就調用這么多，其他的我一概不關心。4.開閉原則
開閉原則的定義：
一個軟件實體如類、模塊和函數(shù)應該對擴展開放，對修改關閉。
一個軟件實體應該通過擴展來實現(xiàn)變化，而不是通過修改已有的源代碼來實現(xiàn)變化。5.依賴倒置原則
依賴倒置原則包含三層含義：
? 高層模塊不應該依賴低層模塊，兩者都應該依賴其抽象；
? ? 抽象不應該依賴細節(jié)； 細節(jié)應該依賴抽象。
在java語言中，抽象就是指接口或抽象類，兩者都是不能直接被實例化的；細節(jié)就是實現(xiàn)類，實現(xiàn)接口或繼承抽象類而產(chǎn)生的類就是細節(jié)，其特點就是可以直接被實例化，也就是可以加上一個關鍵字new產(chǎn)生一個對象。6.接口隔離原則
接口隔離原則定義：
? ? 客戶端不應該依賴它不需要的接口；
類間的依賴關系應該建立在最小的接口上。
建立單一接口，不要建立臃腫龐大的接口，接口盡量細化，同時接口中的方法盡量少。它要求“盡量使用多個專門的接口”。專門接口指提供給每個模塊的都應該是單一接口，提供給幾個模塊就應該有幾個接口，而不是建立一個龐大的臃腫接口，容納所有的客戶端訪問。
1.在RUP中，軟件開發(fā)生命周期根據(jù)時間和RUP的核心工作流劃分為二維空間。橫軸表示項目的時間維，縱軸以內容來組織為自然的邏輯活動。
第五篇：系統(tǒng)分析與設計心得
讀《系統(tǒng)分析與設計方法》一書有感
作為一個軟件專業(yè)的學生，理解和掌握系統(tǒng)分析與設計的知識是必不可少的。在閱讀《系統(tǒng)分析與設計方法》一書中以及加上老師教導，我學到了很多東西，收獲不少。
系統(tǒng)就是由若干可以相互區(qū)別、由相互聯(lián)系并且各自獨立的單元組成各個子系統(tǒng)之間同樣是獨立而又相互聯(lián)系的。系統(tǒng)具有集合性、相關性、目的性、整體性和環(huán)境適應性。在開發(fā)完成一個軟件項目的過程中，系統(tǒng)工程必須經(jīng)過開發(fā)階段、建造階段、運行階段、更新階段、維護階段。
系統(tǒng)分析與設計的方法主要包括結構化生命周期法（又稱瀑布法）、原型化方法（迭代法）、面向對象方法。
按時間過程來分，開發(fā)方法分為生命周期法和原型法，實際上還有許多處于中間狀態(tài)的方法。原型法又按照對原型結果的處理方式分為試驗原型法和演進原型法。試驗原型法只把原型當成試驗工具，試了以后就拋掉，根據(jù)試驗的結論做出新的系統(tǒng)。演進原型法則把試好的結果保留，成為最終系統(tǒng)的一部分。
按照系統(tǒng)的分析要素，可以把開發(fā)方法分為三類：
①面向處理方法（Processing Oriented，簡稱PO）。
②面向數(shù)據(jù)方法（Data Oriented，簡稱DO）。
③面向對象的方法（Object Oriented，簡稱OO）。
系統(tǒng)分析和設計應遵循的原則有：
系統(tǒng)開發(fā)是面向客戶的，應從客戶的角度考慮。
諸如系統(tǒng)開發(fā)生命周期之類的產(chǎn)品更新?lián)Q代機構應該在所有的信息系統(tǒng)開發(fā)項目中建立起來。
信息系統(tǒng)開發(fā)的過程并不是一個順序的過程，它允許步驟的重疊和倒轉等。
如果系統(tǒng)的成功可能性受到很大限制時，應取消整個項目。文檔材料是系統(tǒng)開發(fā)生命周期中重要的可遞交成果，應加以重視。在本書的第一部分中，主要集中于系統(tǒng)分析和設計的整體描述，包括系統(tǒng)分析和設計方法的環(huán)境，信息系統(tǒng)構件，信息系統(tǒng)開發(fā)，項目管理。期中印象比較深刻的是系統(tǒng)開發(fā)過程的能力成熟度模型（CMMI）。信息系統(tǒng)和軟件的CMM框架用來幫助改善其系統(tǒng)開發(fā)過程的成熟度。CMM包括了五個成熟度等級：初始級、可重復級、已定義級、已管理級、優(yōu)化級。期中，每個等級都是下一個等級的必須條件。
在軟件開發(fā)過程中需求分析階段是至關重要的一個階段，需求分析階段可能被稱為定義階段或者邏輯設計階段。需求分析階段的第一個任務是確定需求，在這個階段至少將目標轉換成為滿足其需要的功能需求和非功能需求的框架。在這個階段需要交付的成果是功能需求和非功能需求的草稿。在初步定義完了功能需求和非功能需求后，得排列需求的優(yōu)先次序。如果一個項目落后于進度或者超出預算，知道哪個需求比其他需求更重要可能是很有用的。在排列需求的優(yōu)先次序中可以使用到時間盒的技術。需求分析并不會真正的技術，因為企業(yè)需要具有快速適應不斷變化的需求和機會的能力。信息系統(tǒng)不能比企業(yè)自身的響應技術還慢。
在學習本書第二部分的時候，我了解到了需求分析在整個項目開發(fā)中的作用以及成為整個項目主導的因素。只要好的需求才能設計開發(fā)出好的軟件項目。在項目開發(fā)過程中，我們還可以利用圖表的形式來簡化方便人員的開發(fā)設計。期中有五種圖表是系統(tǒng)分析師常用的：類圖、用例圖、協(xié)作圖、順序圖、狀態(tài)圖。期中用例圖是用例建模的產(chǎn)物，它以圖形化的方式將系統(tǒng)描述成用、參與者（用戶）及其之間的關系。簡單的說就是用直立的小人來表示參與者（用戶），用圓圈來表示用例，他們之間以箭頭的形式來連接。關系包括了：關聯(lián)關系、擴展關系、使用關系、依賴關系、繼承關系。但是書上沒講到《include》關系，跟老師的講解有點出路。老師在講義上通過畫圖的方式很好的解釋了《include》和《extend》的關系。
數(shù)據(jù)建模這一章節(jié)中，我了解了數(shù)據(jù)建模的含義，它是一種為數(shù)據(jù)庫定義業(yè)務需求的技術。數(shù)據(jù)建模中比較重要的概念有實體和屬性之間的關系，關系是連接實體的一個時間，或者僅僅是存在于實體之間的邏輯關系。關系有很多種類，多對多、一對多、一對
一、等等。這些關系的圖形化符號記起來很不容易，但是我自己想到了一個比較容易記憶的簡單的方法。一個就用 “|”表示，零個就用“0”表示，多個就用“<”表示，然后根據(jù)相應的說明來選擇。比如零個或一個（0|），一個或多個（|<）。過程建模是一種組織和記錄數(shù)據(jù)的結構和流向的技術，它記錄系統(tǒng)的“過程”和有系統(tǒng)的“過程”實現(xiàn)的邏輯、策略和程序。期中也介紹到了數(shù)據(jù)流圖（DFD），數(shù)據(jù)流圖是一種描述通過系統(tǒng)的數(shù)據(jù)流以及系統(tǒng)實施的工作或處理過程的工具。我覺得數(shù)據(jù)流圖DFD的最大的優(yōu)點就是容易閱讀，因為數(shù)據(jù)流圖僅有三種符號和一種連接：圓角矩形表示要完成的過程或者工作，正方形表示外部代理（系統(tǒng)的邊界），開放的方框表示數(shù)據(jù)存儲（可以是文件或者數(shù)據(jù)庫），箭頭表示數(shù)據(jù)流（可以是輸入和輸出，或者是表示到過程和來自過程）。統(tǒng)一建模語言UML的目的就是對面向對象系統(tǒng)進行可視化、評述、和文檔化。它適用于系統(tǒng)開發(fā)從需求規(guī)格描述道系統(tǒng)完成后測試的不同階段（需求分析階段、分析階段、設計階段、編程階段、測試階段）。UML2.0的模型主要圖包括了：用例圖、活動圖、類圖、對象圖、狀態(tài)機圖、組合結構圖、交互圖、定時圖、組件圖、部署圖和包圖。在理解這章的過程中，我感覺比較輕松，但是把一些關系，事件，實體等等用圖形化的形式表示出來還是非常難的。用UML設計面向對象系統(tǒng)時候，我們得準確的找到實體類、接口類、控制類、持續(xù)類、系統(tǒng)類和設計關系。在面向對象設計的過程中，主要包括了一下活動：對用例模型加以精煉以反映實現(xiàn)環(huán)境；建模支持用例情景的對象交互、行為和狀態(tài)；修改對象模型以反映實現(xiàn)環(huán)境。
前面說到需求分析是整個軟件項目開發(fā)中最重要的一環(huán)，其實我覺得可行性分析也是跟需求分析一樣的重要。因為信息是一個必須經(jīng)過檢驗的重要資本投入，就像市場要檢驗一個新產(chǎn)品，系統(tǒng)分析員應該考慮投資能夠收回嗎？是否有其他投資能夠帶來比預期更高的回報。要說他們的區(qū)別，我個人覺得是：可行性分析是要決定“做還是不做”。需求分析是要決定“做什么，不做什么”。可行性分析報告有六個準則：運行可行性、文化可行性、技術可行性、進度可行性、經(jīng)濟可行性。只有進行了可行性分析報告，才能夠確定企業(yè)是否要 做這個項目。如果說在可行性報告中顯示沒有成功的可能，那么就沒有必要再做需求分析了，整個項目就不會做下去了。進行可行性分析報告可以避免項目中途告終的結果，在系統(tǒng)開發(fā)過程中舉足輕重。
數(shù)據(jù)庫開發(fā)與設計這章，感覺書上講解的沒有老師講的詳細。書上并沒有提到范式，但是在課堂上我了解到數(shù)據(jù)庫設計的范式。有第一范式、第二范式、第三范式、BC范式等。等級越高，數(shù)據(jù)冗余越少，對系統(tǒng)調用數(shù)據(jù)庫更方便。數(shù)據(jù)庫的核心是DBMS，DBMS的核心是數(shù)據(jù)庫引擎，引擎響應專門的命令以創(chuàng)建數(shù)據(jù)庫結構，然后創(chuàng)建、讀取、修改和刪除數(shù)據(jù)庫中的記錄。DBMS使用數(shù)據(jù)定義語言（DDL）創(chuàng)建記錄類型、字段和結構化關系，還定義了數(shù)據(jù)庫視圖；DBMS還是用數(shù)據(jù)處理語言（DML）用來創(chuàng)建、讀取、修改和刪除數(shù)據(jù)庫中的記錄。但是并非所有數(shù)據(jù)庫的DBMS都被要求使用DDL和DML。看完這章，總結了一下建立關系數(shù)據(jù)庫模式的步驟，首先要為每個實體類型建立一張表，然后為每張表選擇一個主鍵，同時增加外鍵來表示一對多的關系，接著還可以建立幾個新表來表示多對多的關系，然后還得定義參照完整性約束，評價模式質量，并且進行必要的改進，最后為每個字段選擇適當?shù)臄?shù)據(jù)類型和取值約束。數(shù)據(jù)庫在系統(tǒng)開發(fā)的過程中是必不可少的，幾乎所有框架類型都得用到數(shù)據(jù)庫，它也是MVC框架的底層核心。
對于本書的還有一個比較映像深刻的就是UI（user interface），用戶界面設計。一個良好的用戶界面應該為用戶提供友好的使用方式，通過用戶界面用戶可以同應用程序打交道，處理輸入并且獲得輸出。Galitz曾經(jīng)提出過用戶界面設計的原則：理解你的用戶及任務、讓用戶參與界面設計、在實際用戶中測試系統(tǒng)、進行迭代設計。記得以前大二的時候學習JAVA的時候，我曾經(jīng)開發(fā)過基于圖形用戶界面（GUI）的聊天軟件，不過當時的界面設計完全設計的是隨心所欲，并沒有理論作為指導。在學習VB課程的時候學過UAR，簡單的了解了一些關于界面友好化設計的原則。這本書也給出了用戶界面設計過程的幾個步驟：1.以圖表形式描述用戶界面對話；2.原型化對話和用戶界面；3.獲得用戶反饋；4.如果需要，回到1步或者2步。
最后總結下，雖然我沒用把這本書的每一個地方都認真精讀，有些地方略讀的，但是看完整本書后我收獲很大。讀完《系統(tǒng)分析與設計方法》這本書再加上老師在課堂上的一些講解以及以前學習事件過程中的收獲，我對于系統(tǒng)分析與設計有了進一步的理解，能高屋建瓴的看待系統(tǒng)分析與設計整個過程的步驟以及增加了一些開發(fā)設計中的重要事件的理論知識。
對于系統(tǒng)分析的心得
點擊咨詢 