第一篇：教學培訓信息管理系統的分析與設計

教學培訓信息管理系統的分析與設計

【摘 要】一個高效率的教學培訓系統能夠對學員信息進行信息化管理，減輕管理人員的工作負擔，高效并規范地管理學員信息。在對培訓機構主要業務和需求的詳細分析基礎上，結合軟件工程的理論和技術分析并設計了一個培訓信息管理系統，從軟硬件兩方面把學院建設成一流的信息管理、教育教學的平臺，幫助培訓機構高效科學的處理信息，并為經營決策者提供更方便的統計分析機制。

【關鍵詞】培訓；ASP.NET；模塊

隨著知識經濟時代的來臨，世界各國不約而同地把目光投向了發展教育，提高全民素質上，教育終身化成為社會發展的大趨勢。我國政府也提出了“科教興國”的戰略決策。教育的全民性、終身性，要求學歷教育與非學歷教育比翼齊飛。一方面，要大力發展基礎教育、高等教育和職業教育等各種學歷教育；另一方面，也要大力發展面向各類人群、各行各業、各種內容的非學歷教育。各類教學培訓機構在經濟建設和社會發展中起到非常重要的作用。然而對于教學培訓機構而言，如何更好的處理培訓的相關信息，從軟硬件兩方面把學院建設成一流的信息管理、教育教學的平臺，成為一個重中之重的環節，因此，有必要設計適用于培訓機構信息高效、科學地處理的教學培訓管理系統。

由于教學培訓信息管理系統的研究具有分布式特點，并且需要采用模塊化的設計，因此，在系統的分析與設計中，使用的體系架構為B/S模式的三層架構。同時，系統使用ASP.NET作為開發平臺，并使用統一建模語言進行分析描述，后臺使用的數據庫為常用的SQL Server 2005數據庫。B/S架構下的管理軟件具有簡單而方便的業務擴展，實現增加服務器功能只需相應地增加網頁；功能維護也簡單方便，僅需改變網頁，就能實現所有用戶使用時的同步更新；開發相對簡單，共享性強。因此用 B/S 模式來設計項目培訓管理系統比較合適，服務器端采用 SQL Server 數據庫系統和 ASP.NET 組件來構成項目培訓管理的應用服務系統；客戶端采用瀏覽器來完成學院完成培訓任務的全過程，同時管理員可進行遠程系統維護和管理。

本文所設計的系統，功能模塊包括學員信息管理、培訓信息管理、員工信息理、考試信息管理，以及成績和證書管理模塊。系統運用方便、操作簡單，效率高，可以大大提高培訓機構員工的辦公效率，對各個開設培訓科目的報名情況及發展狀況進行統計分析，幫助經營決策者提供更方便的統計分析機制。系統的功能需求分析

對學員信息、員工信息、培訓信息、考試信息、成績和證書進行管理，主要包括修改刪除學員信息，添加科目報名信息，調班和退班，查詢和統計，添加員工信息，修改及刪除員工信息，員工查詢，查詢和添加班級，修改及刪除班級，班級學員導入，上課記錄，考試學員安排，對于證書的發放記錄、發放時間和經辦人等。系統的概要設計

2.1 主要功能模塊設計

圖1 主要功能模塊

根據培訓信息管理系統的需求以及相關的系統業務流程，我們采用模塊結構化設計，整個系統按層次進行模塊劃分，各個模塊完成自己特定的功能。本系統一共分為五大模塊，這五大模塊分別是：學員信息管理模塊、培訓信息管理模塊、員工信息管理模塊、考試信息管理模塊以及成績與證書管理模塊，每個模塊的功能都按照培訓信息管理的日常業務進行設計，各模塊功能概述如圖1。

2.2 數據庫概念結構設計

對于數據庫的概念設計，表現數據庫的概念結構最常用的方法是使用E-R（Entity-Relationship）數據模型。E-R數據模型的實現方式為利用屬性、實體以及兩者之間的關聯統一描述現實世界的信息結構。

圖2 系統E-R圖

2.3 數據庫邏輯結構設計

數據庫的邏輯結構設計對應的工作為把概念結構設計時提出的E-R實體聯系圖進行轉化，從而與數據庫管理系統產品所支持的數據模型達到一致。并在此E-R實體聯系的基礎上，構建數據庫中對應的數據表，同時還包括數據表之間的所有關聯信息。

培訓信息管理系統數據庫中的主要數據表如下。辦公室表（Office）和校區表（Campus）略。

表1 科目信息表（Course）

學員信息管理模塊用于處理學員基本信息和科目報名信息，涉及到的信息表如表2所示，科目報名信息表（Subject）和學員狀態信息表（StudentSatue）略。

表2 學員基本信息表主要字段（Student）

培訓信息管理模塊用于管理班級信息，并記錄到課情況，涉及到的信息表主要如表3所示，班級成員表（ClassMember）、上課記錄表（ClassRecord）和到課點名表（OrderName）略。

表3 班級信息表

員工信息管理模塊用于處理員工的基本信息，以及分配操作權限給不同員工，涉及到的信息表如表4所示，權限信息（Position）表略。

表4 員工基本信息表（Manager）

考試信息管理模塊用于記錄考試的基本信息，以及考試結果和相關的證書領取信息，涉及到的信息表如表5所示，考試內容表（ExamDetails）、考試名單表（ExamPerson）、乘車信息表（Traffic）、證書信息表（Certificate）略。

表5 考試安排表（Exam）界面設計

3.1 登陸界面

3.2 其它界面（略）結束語

本文在對培訓機構需要執行的數據操作進行詳細分析的基礎上，結合B/S等技術，分析設計了適合培訓機構管理日常工作信息的管理系統。該系統的完成給培訓機構的員工和學員帶來了實用性和方便性。解決了學員信息錄入時的冗余性，減少了數據出錯的可能性；為員工提供了方便、快捷的數據查詢功能，同時，便于對各個培訓科目進行統計分析；系統合理地區分學員的不同狀態，也為學員提供掌握自己培訓所處階段提供方便；通過這個系統，員工基本上可以對整個培訓流程中的所有信息進行合理處理，大大提高工作操作效率。

【參考文獻】

[1]眭碧霞，李春華，張瑋.ASP.NET 程序設計與開發[M].西安：西安電子科技大學出版社，2008.[2]萬科，覃劍.Visual C#.NET 程序設計基礎與上機指導[M].北京：清華大學出版社，2007.[3]劉桂林，謝堯，李大友.SQL Sever 數據庫應用技術[M].北京：中國計劃出版社，2007.[4]劉玉萍，劉海玲.基于Web 的教學計劃管理系統設計與實現[J].信息技術，2006（11）.[5]王艷娥，周立.基于Web的職工培訓管理系統的設計與實現[J].中國管理信息，2012（06）.[6]黃艷.基于B/S模式的人力資源管理系統的設計與實現[J].網絡財富，2010（08）.[責任編輯：謝慶云]

第二篇：信息管理系統分析與設計候選題目

《信息管理系統分析與設計》課程設計候選題目

題目一 “教務管理系統之子系統——系內課程安排” 1． 系統簡介

每學期的期中，學院教務處分別想個系發出下學期的教學計劃，包 括課程名、課時、班級類別（本科、?？?、高職）、班號等；系教學主管人員根據教學任務和要求給出哥們課程的相關限制（如：任課教師職稱、和班數、最高周學時數等）；任課教師自報本人授課計劃，經所在教研室協調確認，將教學計劃上交系主管教學計劃的主任，批準后上報學院教務處，最終有教務處給出下學期全系教師的教學任務書。

假設上述排課過程全部為人工操作，現要求改造為能利用計算機實現的自動處理過程。2． 限定條件

（1）每位教師的主講門數不超過2門/學期：講師以下職稱的教師不能承擔系定主課的主講任務。

（2）系級干部的主講課時不能超過4學時/周。

（3）本學期出現嚴重教學事故的教師不能承擔下學期的主講任務。（4）本系統的輸入項至少應包含3個：教務處布置的教學計劃、系教師自報的講課計劃和系定的有關講課限制條件。

（5）本系統的輸出項至少應包含2個：教務處最終下達的全系教師教學任務書和系各教學班一學期的課程表（可不包含上課地點）。

題目二“學樣教材訂購系統” 1． 系統簡介

本系統可細化為二個子系統：銷售系統和采購系統

銷售系統的主要工作過程為：首先由教師或學生提交購書單，經教材發行人員審核是有效購書單后，開發票、登記并返給教師或學生領書單，教師和學生可去書庫領書。

采購系統的主要工作過程為：若是脫銷教材，則登記缺書，發缺書單給書庫采購人員；一旦新書入庫后，即發進書通知單給教材發行人員。

以上系統的功能要求在計算機上實現。2． 技術要求及限定條件

（1）當書加中的各種書籍數量發生變化（包括領書或進書）時，都應修改相關的書庫記錄，如庫存表或進/出庫表。（2）在實現上述銷售和采購的工作過程時，需考慮有關單據的合法性驗證（如：購書單、領書單等的有效性）。

（3）系統的外部項至少包括3個：教師、學生和教材工作人員。（4）系統的相關數據存儲項至少包括6個：購書表、庫存表、缺書登記表、待購教材表、進/出庫表

題目三：“機票預訂系統” 1． 系統簡介：

航空公司為給旅客提供方便，需要開發一機票預定系統。各旅行社把預訂機票的旅客信息（姓名、性別、工作單位、身份證號碼、旅行時間、旅行日期等）輸入到該系統，系統為旅客安排航班。當旅客交付了預定金后，系統印出取票通知單和賬單給旅客。旅客在飛機起飛的前一天憑取票通知和賬單交款取票，系統核對無誤碼即印出機票給旅客。此外，航空公司為隨時掌握各航向飛機的乘載情況，需要定期進行查詢統計，以便做適當調整。

2． 技術要求及限定條件

（1）在分析系統功能時，應考慮有關證件的合法性驗證（如身份證、取票通知、交款發票等）

（2）對于本系統還應補充以下功能： ①旅客延誤了取票時間的處理 ②班機取消后的處理

③旅客臨時更新機票班次的處理

（3）系統的外部項至少包括3個：旅客、旅行社和航空公司

題目4“學校內部房產管理系統” 1． 系統簡介

該房產管理系統具有分房、調房、退房和咨詢統計等功能，房產科把用戶申請表輸入系統后，系統首先檢查申請表的合法性，對不合法的申請表系統將拒絕接受；對合法的申請表將根據類型分別進行處理。

如果是分房申請，則根據申請者的情況（年齡、工齡、職稱、職務、家庭人口等）計算其分數，當分數高于閾值分數時，按分數高低將申請表插到分房隊列的適當位置。每月最后一天進行一次分房活動，從空房文件中讀出空房信息，如房號、面積、等級、單位面積房租等，把好房優先分配給排在分房隊列前面的符合該等級住房條件的申請者，從空房文件中刪除這個房號的信息，從分房隊列中刪掉該申請表，并把此房號的信息和住戶信息一起寫出住房文件中，輸出信房分配單給住戶，同時計算房租并將計算出的房租寫出房租文件中。

如果是退房申請，則從住房文件和房租文件中刪掉有關的信息，再把此房號的信息寫入空房文件中。

如果是調房申請，則根據申請者的情況確定其住房等級，然后在空房文件中查找屬于該等級的空房，退掉原住房，再進行與分房類似的處理。

住戶可以向系統詢問目前分房的閾值分數、居住某類房屋的條件、其房號的單位面積和房租等信息。房產科可以要求系統打印出住房情況的統計表，或更新某類房屋的居住條件、單位面積和房租等。2． 技術要求及限定條件

（1）本系統可分為4個主要功能模塊：分房、調房、退房和咨詢（可不考慮統計功能）。

（2）系統的外部項至少包括4個：校內職工、校外住戶、房管部門和主管房產領導。

（3）分房申請表的類型主要依據申請人的工作類型，如教師、行政人員、后勤人員、特殊照顧對象等。

（4）分房申請者的分數計算原則及其他分房政策可由學生自定。

題目五“學校內部工資管理系統” 1． 系統簡介

假設學校共有教職工約1000人，十個行政職能部門和八個系、部。每個月20日前各部門（包括各系、部）要將出勤情況表上報人事處，23日前人事處將人員出勤工資、獎金及扣款清單送財務處。財務處于每月月底將教職工的工資表做好并將數據送銀行。每月初（3日前）將工資條發給各單位。若有員工調入、調出、校內調動、離退休等數據變化，則由人事處通知相關部門和財務處。2． 技術要求及限定條件

（1）本系統的數據存儲至少應包括：工資表、工作總表、部門匯總表、扣稅款表、銀行發放表。

（2）除人事處、財務處外，其他職能部門和系、部名稱可簡化，如系

1、系2??

（3）工資、獎金及扣款細節可由學生自定。

題目六“學校校園網絡管理信息系統” 1． 系統簡介

假設目前我校已完成校園網硬件結構設計和實現（總體結構采用網絡拓撲結構和Client/Server模式），各辦公室職能部門都已具備使用校園網的硬件環境。本管理信息系統應由各部門的子系統組成（如校長/書記辦公系統、教務管理系統、財務管理系統、人事管理系統、圖書管理系統、學生管理系統等），應能滿足校內各部門在數據、文件、資料等公用信息傳輸的要求：各層領導能通過網絡查詢各部門的工作情況并傳達有關指示：實現“無紙化”辦公和全校數據共享。此外，各層領導、各系教師、各職能辦公室都可以通過E MAIL發信、留言；有關部門可在“公告牌”上發布消息，供大家瀏覽。

2． 技術要求及限定條件

（1）系統的外部項至少應包括12個，如校長/書記、校辦、系辦（至少考慮3個系）、教務處、財務處、人事處、圖書館、學生處等，（2）對于每個外部項，都應根據其不同的需要確定相關的功能需求，即根據外部項來劃分相應的子系統功能（可認為不同“系辦”的功能相同）。（3）在確定各子系統功能時，要注意數據的保密性和相關用戶的不同級別。

題目七“實驗室設備管理系統” 1．系統簡介

每學年要對實驗室設備使用情況進行統計、更新，其中：

（1）對于已徹底損壞的作報廢處理，同時詳細記錄有關信息。（2）對于有嚴重問題（故障）的要及時修理，并記錄修理日期、設備名、修理廠家、修理費、責任人等信息。

（3）對于急需但又缺少的設備需以“申報表”的形式送交上級領導請求批準購買。新設備購入后，要立即進行設備登記（包括類別、設備名、型號、規格、單價、數量、購置日期、生產廠家、購買人），同時更新申報表的內容。

（4）隨時對現有設備及其修理、報廢情況進行統計、查詢，要求能夠按類別和時間段（某日期之前）查詢。

2．技術要求及限定條件

（1）所有工作由專門的人員負責完成，其他人不得任意使用。（2）每件新設備在做入庫記錄時均由系統根據類別自動順序編號，形成設備號；設備報廢時要及時修改相關設備記錄且有領導認可。

（3）本系統的數據存儲至少應包括：設備記錄、修理記錄、報廢記錄、購買申請。

（4）本系統的輸入項至少包括：新設備信息、修理信息、申請購買信息、報廢信息、具體查詢統計要求。

（5）本系統的輸出項至少包括：設備購買申請表、修理/報廢注銷/設備資金統計表。

題目八“飯店餐飲業務管理系統” 1． 系統簡介

本飯店餐飲管理系統主要包括菜單管理、零點處理、采購處理、銷售額統計。

菜單管理主要實現菜單的輸入、修改、刪除；零點處理包括顧客用餐（點菜）記錄、添加、更改及費用的計算；采購處理主要是對每天采購來的食品做詳細記錄；銷售額統計分別以日、周、月、季為單位進行總額、純利的計算，以菜項為單位進行點菜量統計，并以此作為菜單修改的依據。2． 技術要求及限定條件

（1）本系統的輸入項至少包括：菜單、顧客所點菜、采購單、統計要求。（2）本系統的輸出項至少包括：顧客點菜單、飯店的菜譜、各種統計表。（3）本系統相關的數據存儲至少包括：菜譜、點菜記錄、采購記錄。（4）采購和統計功能由專門的人員負責操作；（5）飯店為每一位服務員編制一個序號，服務員每做一筆點菜記錄都要同時記錄自己的序號，以便出現問題隨時核對。

網絡版

題目九：個人博客系統 題目十：搜索引擎的制作 題目十一：論壇系統 題目十二：在線考試系統 題目十三：Wiki系統制作

面向對象技術：

題目十四：圖書管理系統 題目十五：ATM管理軟件 題目十六：學生信息管理系統 題目十七：教學管理系統 ??

第三篇：社會信息管理系統分析

概述

社會管理信息平臺是運用先進的信息技術和現代管理理念，構建的區域性社會管理信息化平臺。整合政法（綜治）、維穩、公安、司法、信訪、應急、安監、民政、人社等十多個職能部門的資源和條塊力量；及時收集并管理影響社會和諧穩定的各種熱點、難點信息和輿情；及早防控和化解各類源頭性、苗頭性、突發性社會問題和矛盾；快速應急和處置重大緊急事件，規范和監督社會管理行為，實現資源共享、聯管聯動、動態跟蹤、全面覆蓋、科學高效的社會管理新格局。

應用領域

省、市及區縣政法委

解決的關鍵問題

構建“五位一體”信息化平臺，創新社會管理模式。

實行“一個中心、兩大整合、三個流程、四個統一、五級管理服務”，為市、縣（區）、鎮、村各級各部提供“一體化”工作平臺，實現社會管理網絡化、常態化的新格局。健全“五大”運行體系，創新社會管理機制。

訴求防控機制創新，從源頭上控制基層出現的苗頭性社會問題；

風險評估機制創新，預防重大事件發生；

快速反應機制創新，實時聯動互動，快速處置；

監督管理機制創新，全程跟蹤提高效能；

責任追蹤機制創新，倒逼時效、倒查問責。

實行“四個統一”，規范管理手段。

統一技術標準、統一業務規范、統一報表流程，統一管理服務；避免重復投資，可延伸開發新功能模塊，逐步實現“大社會、大平臺、大管理”的目標要求。

提升“三大”管理效能，解決傳統工作弊端。

提升資源整合、信息共享、扎口管理能力；提升快速反應、動態掌控、監督管理能力；提升科學管理水平和行政服務效能。

如何獲取

可在美基營銷官方網站獲取系統相關信息，也可以直接聯系美基營銷工作人員幫您處理相關問題，百度搜索美基營銷便可進入官網。

第四篇：關于學生信息管理系統分析

關于學生信息管理系統分析

一、論題提出的背景和意義

隨著我國高等院校的連年擴招,學生人數不斷增加,給學校各院系的學生管理工作帶來了巨大的壓力.同時,信息時代的到來,使高校的學生管理工作不可抗拒的地加速進入信息網絡時代,學生信息的管理采取和利用在高校中將發揮越來越重要的作用

同時隨著素質教育的深入開展,要做好學生管理工作,各院系就必須盡可能多地掌握學生情況.在學生人數大量增加,而學生管理教師緩慢增加的同時,我們就必須有一個良好的學生信息管理系統,這樣才能把握學生的信息動態.在這其中,信息的采集是尤為重要的,只有具有了全面的學生信息,才能在了解學生的同時降低學生管理的工作量也只有擁有了健全完整的學生信息,我們才能更好的合理的利用學生管理信息,并服務于學生

學生管理系統是一個學校不可缺少的部分，它的內容對于學校的決策者和管理者來說都至關重要，所以學生管理系統應該能夠為管理者提供充足的信息和快捷的查詢手段。但一直以來人們使用傳統人工的方式管理文件信息，這種管理方式存在著許多缺點：效率低、保密性差，另外，時間一長，將產生大量的文件和數據，這對于查找、更新和維護都帶來了不少的困難，隨著科學技術的不斷提高，計算機科學日漸成熟，其強大的功能已為人們深刻認識，它已進入人類社會的各個領域，并發揮著越來越重要的作用，作為計算機應用的一部分，使用計算機對學生信息進行管理，具有手工管理無法比擬的優點，例如：檢索迅速、查找方便、可靠性高、存儲量大、保密性好、壽命長、成本低等。這些優點能夠極大地提高學生信息管理的效率，也是學校的科學化、正規化、管理與世界接軌的重要條件，因此。開發這樣一套系統成為很有必要的事情

二、國內外現狀的研究

計算機在管理中的應用開始于1954年，當時美國首先用計算機處理工資單。40多年來，計算機在處理管理信息方面發展迅速。例如，60年代美國計算機在管理中應用項目不到300項，到了1975年達到2670項。而現在，美國在財務會計上90%的工作由計算機完成；物資管理中80—100%的信息處理由計算機完成；計劃管理中是80—90%。據計算機應用方面發展較快的國家統計，計算機用于經濟管理的約占80%；用于科技運算的占8%；用于生產過程控制的占12%。我國在全國范圍內推廣計算機在管理中的應用，是在70年代末開始的，雖然起步較晚，近幾年發展卻較快，特別是微型計算機的出現和普及為信息處理提供了物美價廉的手段，對于推動我國管理信息處理的現代化起了重要的作用。

三、目前存在的問題

傳統紙媒介管理的信息管理系統論文難于共享匯總，其統計數據正確性也難以考證。存在著較多的缺點，如：效率底，保密性差，時間一長將產生大量的文件和數據，更不便于查找，更新，維護等。計算機在全國普及后，管理媒介有了質的飛躍。

隨著學校的規模不斷擴大，學生數量急劇增加，有關學生的各種信息量也成倍增長。面對龐大的信息量，就需要有學生信息管理系統來提高學生管理工作的效率。通過這樣的系統，可以做到信息的規范管理、科學統計和快速的查詢，從而減少管理方面的工作量。由于計算機和網絡的普及，若建立一個C/S或B/S結構的學生信息管理系統，學生便可以通過網絡來選課并且查詢自己的有關信息，使得學生信息管理工作系統化，規范化，自動化，大大提高了學校管理學生的效率。

主要存在的問題

1．缺乏信息化觀念，機構設置和管理方法跟不上。學生管理信息化的實現首先是信息化觀念的樹立。盡快突破學生管理文本模式。當前，高校學生管理機構的設置幾乎均是以業務分割為依據，信息化工作往往被忽視。機構設置的滯后會帶來管理方法的滯后，雖然，當前普遍采用的部門分工中滲透著信息工作，但沒有明確的機構設置很難實現人事信息管理方法的系統化。

2．信息冗余、資源浪費。學生管理信息冗余最突出的表現為學生基礎信息的多頭建立，在高校管理部門職均擁有各自的學生基礎信息庫。同時各自對信息庫進行維護。當前，各部門建立的最簡單的信息庫也要設置近20個信息段，有的信息庫字段上百個，信息庫的維護工作量極大。另外，信息庫的維護需要極高的精度，往往不易批量處理。這就造成了人力、設備資源的嚴重浪費。信息的冗余度也居高不下。

4．管理信息系統建設滯后。學生管理實現信息化，不但要實現基礎信息的健全，而且要實現信息應用的系統化。目前，高校學生管理信息系統建設滯后于基礎信息建設。表現為：一是較完整、全面、實用的高校學生管理系統稀缺，功能單一的小系統和小軟件成為信息化的代名詞，具體工作中，更多的是直接對基礎信息庫的查閱和改動。二是即便有較大的學生管理系統。也不完全適合于各地高校的學生管理，其系統開發和學生管理專業縫隙明顯。

四、研究解決方法

（一）可行性分析

學生信息，作為一個學校，就有一定的工作量存在，而學生信息，它的工作量可能是其它信息工作量的幾倍，班級的增加、班級的查找、班級的修改；學生檔案；課程管理；成績管理；繳費管理；統計等等，每個信息的數據都在不斷地變化著，如果采用人工的方式進行操作，那么，一天的工作量，足以讓人覺得比較繁瑣，吃不消。針對這樣的情況，采用讓數據的查詢變得簡單化，數據變的更讓每個人都在任何時刻都可以了解到

（二）解決方案

1.查詢相關資料，了解本系統的研究意義。可以上網搜索或者是去圖書館查閱相關資料。

2.通過查詢資料了解該系統要如何做，既要做哪些東西。

3.設計出大體上的功能模塊，畫出模塊圖。

4.通過進一步的了解，對每個功能模塊進行細化，將每一步都想清楚。制定出每一步的做法和注意的地方。

5.對設計好的程序進行調試，通過調試發現存在的問題并解決，從而達到完善系統的目的。

6.最后，整理個階段的設計記錄文檔，寫成論文稿。

（三）研究內容

系統管理模塊

該模塊的主要任務是維護系統的正常運行和安全性設置，包括添加用戶、修改密碼、重新登錄、退出系統等功能。

班級管理模塊

該模塊的功能是實現對全校班級的管理工作，包括添加班級信息、修改班級信息兩個子功能，這兩個子功能模塊各自獨立，實現學校中全部班級的管理功能。

學生學籍管理模塊

該模塊的主要功能是實現對學生的基本信息的管理工作，包括添加學籍、修改學籍、查詢學籍等功能，從而方便學校管理部門對學校的基本情況的快速查詢和了解。

課程管理模塊

在該模塊中可以對各個年級的課程進行設置，并可在其中進行全校所有課程信息的添加和修改，方便了學校教材管理部門和教務科人員的工作。該模塊包括添加課程、修改課程和設置年級開課三個子功能。

成績管理模塊

在我國，學生的考試成績是檢驗學生學習情況的一個主要依據，所以學生成績管理功能在一個學生信息管理系統中占有非常重要的地位，本系統的成績管理模塊包括添加、修改成績信息和查詢成績信息等子功能。

五、進度計劃

2011年1月初開始進行系統調查

2011年1月中旬對其進行可行性分析

2011年2月初進行系統詳細設計階段

2011年2月中旬進行系統實施

2011年3月整理、撰寫論文

2011年3月中旬提交論文

2011年3月末根據指導老師意見對論文進行修改

2011年4月進行論文答辯

六、成果預計

學生信息管理系統是學校信息管理系統的一個重要組成部分。他為其他系統（如學校圖書管理系統、學校檔案管理系統、教學管理系統、總務后勤管理系統等）提供學生的基本信息，同時它也需要如教學管理系統提供課程設置數據等。這些系統在具體應用中構成一個大系統，相互調用對方的數據。

由以上分析，我們可以充分認識到設計并開發一個學生信息管理系統的必要性和迫切性，本次設計和開發的學生信息管理系統[NextPage]應符合學校學生信息管理的規定，滿足對學校學生信息管理的需要，并達到操作過程中的直觀，方便，實用，安全等要求。系統采用模塊化程序設計的方法，既便于系統功能的組合和修改，又便于未參與系統開發的技術維護人員補充和維護。SIMS通過教育網絡或互聯網把整個學校的學生信息匯聚起來，為學校教育主管部門提供全面及時的學生信息，方便管理，同時亦可通過校園網擴展各類信息化應用，共享學生信息。

七、參考資料

1、《SQL Server數據庫應用技術》張蒲生、何升 清華大學出版社

2、《計算機網絡基礎及應用》白以恩 哈爾濱工業大學出版社

3、《軟件開發工具》陳禹、方美琪經濟科學出版社

第五篇：軟件系統分析與設計

第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軟件生存周期與軟件開發模型

? 1.2.1 軟件生存周期

? Boehm定義的軟件生存周期模型

? GB 8566-1988定義的軟件生存周期模型

? GB/T 8566-1995定義的軟件生存周期過程模型 ? GB/T 8566-2001定義的軟件生存周期過程模型 ? UP定義的軟件生存周期模型

? 1.2.2 軟件開發模型

? 瀑布模型（waterfall model）

? 快速原型模型（rapid prototype model）? 演化模型（evolutionary model）? 增量模型（incremental model）? 螺旋模型（spiral model）

? 噴泉模型（water fountain model）

1.3軟件質量模型與軟件質量管理

? 1.3.1 軟件質量模型

? 軟件產品的內部質量、外部質量和使用質量 ? 質量特性、質量子特性和度量

? 功能性：適宜性、準確性、互用性、依從性、安全性 ? 可靠性：成熟性、容錯性、可恢復性 ? 可用性：可理解性、易學性、可操作性 ? 效率：時間特性、資源特性

? 可維護性：可分析性、可修改性、穩定性、可測試性 ? 可移植性：適應性、易安裝性、一致性、可替換性

? 1.3.2 軟件質量管理

? 質量需求分析 ? 質量計劃 ? 質量保證 ? 質量控制 ? 質量改進

? 軟件質量管理體系

? ? ? ? ? ? ? ? ? ?

? ?

? ? ? ? ? ? ? ? ? ? ? ? ?

? ? ?

1.4軟件配置管理

? 1.4.1 軟件配置項與基線

計算機軟件配置項（CSCI）基線（baseline）

功能基線（functional baseline）指派基線（allocated baseline）產品基線（product baseline）

? 1.4.2 軟件配置管理過程

對象標識 版本控制 變化控制 配置審計 配置報告

1.5軟件過程管理

? 1.5.1 軟件能力成熟度模型（CMM）

CMM的5個等級：初始級、可重復級、已定義級、已管理級、優化級 CMM的關鍵過程域（KPA）：需求管理、軟件項目計劃、軟件項目跟蹤和監控、軟件子合同管理、軟件質量保證、軟件配置管理、組織級過程焦點、組織級過程定義、培訓大綱、集成軟件管理、軟件產品工程、組間協調、同行評審、定量過程管理、軟件質量管理、缺陷預防、技術變更管理、過程變更管理

? 1.5.2 軟件過程與軟件能力成熟度評估

第一步，建立評估組 第二步，填寫提問單 第三步，響應分析 第四步，現場考察

第五步，提出調查發現清單

第六步，制作關鍵過程域（KPA）剖面圖

? 1.5.3 軟件過程改進

第一步，比較“目標狀態”與“目前狀態”，找出所有差距 第二步，確定改進目標 第三步，制定改進計劃 第四步，執行改進計劃

第五步，總結本輪改進經驗，開始下一輪改進

1.6

小節

軟件工程學是研究如何有效地組織和管理軟件開發的工程學科。

軟件產品所要經歷的計劃、分析、設計、編程、測試、維護直至被淘汰這樣一個全過程被稱為軟件生存周期。用不同的方式將軟件生命周期中的所有開發活動組織起來，可以形成不同的軟件開發模型。

軟件質量就是軟件與明確地和隱含地定義的需求相一致的程度。軟件質量管理是指軟件開發機構為保證軟件項目滿足客戶需求所要實施的質量活動。軟件配置管理是在軟件的整個生命期內管理變化的一組活動，目標是使變化更正確且更容易被適應。

軟件過程是指人們用于開發和維護軟件及其相關產品的一系列活動，包括軟件工程過程和軟件管理過程。軟件過程管理的目的就是提升軟件組織的提高軟件開發能力。

? 1.? 1.? ? ? ? ?

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?

第2章

項目管理基礎知識 2.1項目與項目管理 ? 2.1.1 項目

項目是在特定條件下、具有特定目標的一次性任務，是在一定時間內、滿足一系列特定目標的多項相關工作的總和。項目的臨時性 項目的獨特性 項目的漸進性

2.1.2 項目管理

項目管理就是將各種知識、技能、工具和技術應用于項目之中，以達到項目的要求。項目范圍 項目時間 項目成本 項目質量

2.2項目管理過程與過程組 ? 2.2.1 過程與過程組

過程就是一組為了完成一系列事先指定的產品、服務或成果而需執行的互相聯系的行動和活動。軟件項目管理過程可歸納為五個過程組。啟動過程組（initiating process group）規劃過程組（planning process group）實施過程組（executing process group）

監控過程組（monitoring and controlling process group）收尾過程組（closing process group）

? 2.2.2 項目管理過程的交互作用

項目管理過程并不是互不相干的一次性事件

項目管理過程組之間是一種前后銜接、承前啟后的關系

項目管理過程組之間有時又是一種時間交錯、空間并行的關系 項目管理過程組之間還是一種信息收集、存儲、處理和傳遞的關系 某些過程組的關聯具有重復迭代性

規劃過程組、執行過程組和監控過程組之間形成一種閉環的關系 過程組的交互作用往往還會跨越項目階段 項目階段和過程之間有相互聯系

? 2.2.3 項目管理過程的裁剪

不同類型的軟件項目應選用不同的項目管理過程 不同階段的軟件項目應選用不同的項目管理過程 不同軟件項目的管理過程會有不同的具體過程 不同軟件項目的管理過程會有不同的具體過程順序 不同軟件項目的管理過程會有不同的條件與約束 不同軟件項目的管理過程會有不同的簡化程度 不同軟件項目的管理過程需要不同的集成程度 項目變更會使項目管理過程隨之變化

2.3項目管理知識體系

項目綜合管理 項目范圍管理

? ? ? ? ? ? ? ? ? ? 項目時間管理 項目成本管理 項目質量管理 項目人力資源管理 項目溝通管理 項目風險管理 項目采購管理

2.4小節

項目管理就是將項目管理知識、技能、工具和技術應用于項目活動之中，可以將軟件項目管理活動視做一系列相互聯系的過程。

項目管理過程可歸納為5個過程組：啟動過程組、規劃過程組、實施過程組、監控過程組與收尾過程組。

項目管理包括9個知識領域：項目綜合管理、項目范圍管理、項目時間管理、項目成本管理、項目質量管理、項目人力資源管理、項目溝通管理、項目風險管理與項目采購管理。

第3章

軟件開發技術 3.1軟件開發平臺

? 3.1.1 Microsoft.NET平臺

Microsoft.NET Framework：.NET CLR（通用語言運行環境）；.NET BCL（基礎類庫）；ASP.NET；ADO.NET。

Microsoft Visual Studio.NET：ADO.NET組件；XML數據組件；Windows表單組件；ASP.NET應用服務；ASP.NET Web表單；Web服務支持。

? 3.1.2 J2EE平臺

組件-容器：搭建體系架構平臺標準服務 多層應用模型

3.1.3 Microsoft.NET與J2EE的異同

類似的平臺基礎構造 相同的三層/多層體系 不同的移植、性能和擴展 在Web支持方面的比較 第三方廠商的支持 潛在的市場

3.2中間件技術 ? 3.2.1 中間件簡介

終端仿真/屏幕轉換中間件 數據訪問中間件 遠程過程調用中間件 消息中間件 交易中間件 對象中間件

Web服務器中間件 安全中間件

? 3.2.2 消息代理中間件 ? ?

? ? ? ? ? 1.? ? 1.? ? ? ? ? ? ? ?

? ? ? ? ? ? ? ? ?

? ? ? ? ? ? ? ? ? ? ? ? ? ? ?

?

? 構件化的結構

可恢復性、易于管理、靈活性 具有數據轉換設施?？煽扛咝У耐ㄐ?多樣的管理能力 豐富的應用開發環境

? 3.2.3 面向數據庫的中間件

ODBC JDBC 數據庫網關

3.3構件技術 ? 3.3.1 構件庫

構件的存儲

構件的分類與檢索機制 構件庫的編目

構件庫的管理和維護

? 3.3.2 構件模型

3C模型

刻面（Facet）模型 青鳥模型

? 3.3.3 構件的屬性與特點

構件是可獨立配置的單元，構件必須自包容。

構件強調與環境和其他構件的分離，因此構件的實現是嚴格封裝的，外界沒機會或沒必要知道構件內部的實現細節。

構件可以在適當的環境中被復合使用，因此構件需要提供清楚的接口規范，可以與環境交互。

構件沒有個體特有的屬性，最多僅有特定構件的一份副本。

? 3.3.4 構件與中間件

中間件，本質上是對分布式應用的抽象，中間件與系統架構實際上是從兩種不同的角度看待軟件的中間層次。

中間件促進了構件化軟件，基于中間件開發的應用系統是構件化的，中間件提供了構件的體系結構，極大提高了構件化軟件開發的效率和質量。構件化的軟件設計思想在中間件發展中起到了重要的作用。

3.4小節

Microsoft.NET平臺和J2EE平臺是目前最常用的兩大軟件開發平臺。作為彼此競爭的應用平臺，Microsoft.NET平臺和J2EE平臺在目標和體系結構上極其相似，但在實現上又完全不同。二者總的關系是：異中有同，同中有異。中間件是處于操作系統和應用程序之間的軟件。中間件保持了平臺的透明性，抽象了典型的應用模式。應用軟件開發者可以基于標準的中間件進行再開發，而不必再考慮操作系統的問題。

構件是可復用的軟件成份，可被用來構造其他軟件。中間件促進了構件化軟件，應用系統在中間件提供的環境中可以更好地集中于業務邏輯上，并以構件的形式存在。構件思想也反過來推動了中間件的發展。

第4章

軟件項目規劃

4.1項目策劃

? 1.? 1.從政策導向中尋找項目機會 從市場需求中尋找項目機會 從技術發展中尋找項目機會 從特定事件中尋找項目機會

4.2項目可行性分析 4.2.1 技術可行性分析

? ? ? ? ? 1.? ? ? ? ? ? ? ? ? 項目的必要性分析

軟件組織水平與能力分析 項目技術來源分析 與項目相關的專利分析

項目負責人及技術骨干的資質分析 項目總體技術方案分析 項目創新點分析 項目技術風險分析 項目技術成熟性分析

? 4.2.2 項目投資及效益分析

項目投資預算分析 項目投資來源分析

市場需求與產品銷售額分析

產品成本、利潤與盈虧平衡點分析 投資回收期、投資收益率分析 社會效益分析

4.3項目論證、評估與立項

? 4.3.1 項目論證與評估的基本概念

項目論證是指對擬實施項目技術上的先進性、成熟性、適用性，經濟上的合理性、盈利性，實施上的可能性、風險性進行全面科學的綜合分析，為項目決策提供客觀依據的一種技術經濟研究活動。

項目評估指在項目可行性研究的基礎上，項目投資者或項目主管部門或其委托的第三方權威機構根據國家頒布的政策、法律、法規、標準和技術規范，對擬開發項目的市場需求、技術先進性和成熟性、預期經濟效益和社會效益等進行評價、分析和論證，進而判斷其是否可行的過程。

項目論證與評估的內容、程序和依據大同小異，只是側重點稍有不同，有時不加區分或合并進行。

? 4.3.2 項目可行性報告的真實性評估

項目申請單位的資質真實性評估 項目申請單位的財務真實性評估 項目申請單位的技術真實性評估 其他事項的真實性評估

? 4.3.3 項目可行性報告的客觀性評估

技術創新點的客觀性評估

技術先進性與成熟性的客觀性評估 ?

?

?

? ? ? ? ? ?

? ? ? ? 信息安全措施的客觀性評估

采用標準、規范的先進性、合理性評估 項目風險及應對方案的客觀性評估 其他事項的客觀性評估

? 4.3.4 評估報告

? 項目概況 ? 評估目標 ? 評估依據 ? 評估內容

? 評估機構與評估專家 ? 評估過程

? 詳細評估意見

? 存在或遺漏的重大問題 ? 潛在的風險 ? 評估結論

? 進一步的建議

? 4.3.5 項目立項

項目立項的決定應當由項目團隊之外的、適當級別的、并為項目出資的項目發起人或投資人作出，通常以項目立項決定（通知）書、項目批文、項目許可證書和項目任務書等形式發布。

4.4項目開發計劃

? 1．引言 ? 2．引用文件 ? 3．項目最終成果 ? 4．需求與約束

? 5．系統開發總體計劃 ? 6．項目開發詳細計劃 ? 7．進度表與活動網絡圖 ? 8．項目組織與資源 ? 9．培訓

? 10．項目估算 ? 11．風險管理 ? 12．支持條件 ? 13．注解 ? 14．附錄

4.5小節

? 軟件項目規劃的任務主要包括項目策劃、可行性研究、論證、評估、立項與項目開發計劃的制訂工作。

? 項目策劃，也稱項目機會研究，其目的是選擇投資機會、鑒別投資方向。

? 項目可行性分析的目的是確定以下問題：項目有無必要？能否完成？是否值得去做？ ? 項目論證與評估的目的是審查項目可行性研究的可靠性、真實性和客觀性，為項目主管部門或投資機構的立項決策提供科學依據。

? 項目開發計劃是項目規劃階段的重要成果，編寫軟件項目開發計劃時可依據《GB/T 8567-2006 計算機軟件文檔編制規范》中的軟件開發計劃模版。

? ?

? ? ? ? ?

?

?

?

?

? ? ? ? ? ? ? ? ?

第5章

系統分析方法學 5.1系統需求分析與軟件需求

系統需求：系統總體功能和業務結構；硬件系統需求；軟件系統需求；硬件系統和軟件系統之間的接口需求。軟件需求：軟件能力需求；軟件外部接口需求；軟件內部接口需求；軟件內部數據需求；適應性需求；安全性需求；保密性和私密性需求；軟件環境需求；計算機資源需求；軟件質量需求；設計和實現的約束；數據需求；操作需求；故障處理需求；算法需求；相關人員需求；相關培訓需求；相關后勤需求；包裝需求；其他需求。

5.2結構化分析

結構化分析（SA）方法是一種面向數據流的需求分析方法，基本思想是自頂向下逐層分解。

數據流圖（DFD）和數據字典（DD）是結構化分析最常用的工具。數據流圖用來描述數據流從輸入到輸出的變換流程。

數據字典是關于數據的信息的集合，也就是對數據流圖中包含的所有元素的定義的集合。

數據流圖和數據字典共同構成系統的邏輯模型。

5.3原型化方法

? 5.3.1 原型化方法與結構化方法的比較

結構化方法的假設：所有的需求都能被預先定義；修改定義不完備的系統代價昂貴且實施困難；項目參加者之間能夠清晰進行準確的通信；靜態描述或圖形模型對應用系統的反映是充分的；結構化方法的生命周期的各階段都是固有正確的。

原型化方法的假設：并非所有的需求在系統開發以前都能準確地說明；有快速的系統建造工具；項目參加者之間通常都存在通信上的障礙；需要實際的、可供用戶參與的系統模型；需求一旦確定，就可以遵從嚴格的方法；大量的反復是不可避免的、必要的，應該加以鼓勵。

? 5.3.2 原型生命周期及其策略

原型生命周期劃分：選擇開發方法；識別基本需求；開發工作模型；模型驗證；修正和改進；判定原型完成；差別細部說明；嚴格說明細部；判定原型效果；整理原型和提供文檔。

原型化的策略：建立數據模型；利用組合工程；剪裁和粘貼；用系統舉例；字典驅動；文檔的自動化；小的原型化隊伍；交互式開發平臺；陳述性規格說明；終端用戶報表生成器；專業原型化人員；開發人員參加原型化。

5.4面向對象的分析

? 5.4.1 面向對象方法學概述

對象與封裝 類

繼承與多態性 消息通信

面向對象方法學的優點

? 5.4.2 面向對象的分析方法

OMT方法簡介 建立對象模型 建立動態模型 建立功能模型

?

?

? ? ?

? ? ? ? ? ? ? 1.? ? 1.? ? ? ? ?

? ? ? ? ? ?

5.5小節

系統分析涉及系統需求的獲取、分析、規格說明和確認。系統需求可分為以下幾個方面：系統總體功能和業務結構、硬件系統需求、軟件系統需求、硬件系統和軟件系統之間的接口需求。

常用的系統分析方法包括結構化分析、原型化方法和面向對象的分析。

第7章

系統分析文檔

7.1系統/子系統需求規格說明

引言 引用文件

需求：要求的狀態和方式；需求概述；系統能力需求；系統外部接口需求；系統內部接口需求；系統內部數據需求；適應性需求；安全性需求；保密性和私密性需求；操作需求；可使用性、可維護性、可移植性、可靠性和安全性需求；故障處理需求；系統環境需求；計算機資源需求；系統質量需求；設計和構造的約束；相關人員需求；相關培訓需求；相關后勤需求；包裝需求；其他需求；需求的優先次序和關鍵程度 合格性規定 需求可追蹤性 非技術性需求 尚未解決的問題 注解 附錄

7.2接口需求規格說明

引言 引用文件 需求

合格性規定 需求可追蹤性 注解 附錄

7.3軟件需求規格說明

引言 引用文件

軟件需求：要求的狀態和方式；需求概述；需求規格；軟件能力需求；軟件外部接口需求；軟件內部接口需求；軟件內部數據需求；適應性需求；安全性需求；保密性和私密性需求；軟件環境需求；計算機資源需求；軟件質量需求；設計和實現的約束；數據需求；操作需求；故障處理需求；算法需求；相關人員需求；相關培訓需求；相關后勤需求；包裝需求；其他需求；需求的優先次序和關鍵程度 合格性規定 需求可追蹤性 尚未解決的問題 注解 附錄

7.4小節

根據《GB/T 8567-2006 計算機軟件文檔編制規范》（Specification for computer

? ? ?

? ?

? ? ? ? ? ?

? ? ? ? ?

?

? software documentation），系統分析文檔主要包括系統/子系統需求規格說明（SSS）、接口需求規格說明（IRS）和軟件需求規格說明（SRS）。系統/子系統需求規格說明（SSS）為一個系統或子系統指定需求以及保證每個需求得到確認所使用的方法。

接口需求規格說明（IRS）描述為實現一個或多個系統、子系統、硬件配置項（HWCI）、計算機軟件配置項（CSCI）、用戶

軟件需求規格說明（SRS）描述對計算機軟件的需求以及確保每個需求得到確認所使用的方法。

第8章

系統設計基礎 8.1系統設計概述

? 8.1.1 系統級設計決策

系統級設計決策，是指系統行為的設計決策（忽略其內部實現，從用戶角度出發，描述系統將怎樣運轉以滿足需求）和其他對系統部件的選擇和設計產生影響的的決策。系統級設計決策內容：有關系統接收的輸入和產生的輸出的設計決策；對每個輸入或條件進行響應的系統行為的設計決策；系統數據庫/數據文件如何呈現給用戶的設計決策；為滿足安全性、保密性和私密性需求所選用的方法；硬件或硬軟件系統的設計和構造選擇；為了響應需求而作出的其他系統級設計決策。

? 8.1.2 系統架構設計

總體設計

系統部件設計 動態交互設計 接口設計

? 8.1.3 運行設計

系統初始化——說明本系統的初始化過程。

運行控制——說明對系統施加不同的外界運行控制時所引起的各種不同的運行組件組合、每種運行所經歷的內部組件和支持軟件、每一種外界運行控制的方式方法和操作步驟、每種運行組件組合將占用各種資源的情況以及系統運行時的安全控制。運行結束——說明本系統運行的結束過程。

? 8.1.4 系統出錯處理設計

出錯信息——包括出錯信息表、故障處理技術等。補救措施——說明故障出現后可能采取的補救措施。

? 8.1.5 系統維護設計

檢測點的設計——說明在系統中專門安排用于系統檢查與維護的檢測點。

檢測專用組件的設計——說明在系統中專門安排用于系統檢查與維護的專用組件。

8.2軟件設計概述

? 8.2.1 軟件級設計決策

軟件級設計決策是指軟件行為的設計決策（忽略其內部實現，從用戶角度出發，描述軟件將怎樣運轉以滿足需求）和其他影響組成該軟件的軟件配置項的選擇與設計的決策。

軟件級設計決策內容：有關軟件接收的輸入和產生的輸出的設計決策；對每個輸入或條件進行響應的軟件行為的設計決策；有關數據庫/數據文件如何呈現給用戶的設計決策；為滿足安全性、保密性和私密性需求所選用的方法；為響應需求而作出的其他軟件級設計決策。

? 8.2.2 軟件架構設計

? ? ? ? ? ? ? ? ? ? ? 程序結構設計

全局數據結構設計 軟件配置項設計 動態交互設計 接口設計

? 8.2.3 軟件詳細設計

軟件配置項設計決策

軟件配置項設計中的約束、限制或非常規特征 軟件配置項使用的編程語言考慮 軟件配置項使用的過程式命令選取

軟件配置項的局部數據與軟件配置項的輸入或輸出數據設計 軟件配置項的邏輯設計

8.3設計原則 ? 8.3.1 組件化

組件的可分解性 組件的可組裝性 組件的可理解性 組件的連續性 組件的保護性

? 8.3.2 抽象

抽象就是抽出事物的本質特性而暫時忽略其細節，使得不同的事物可以當作相同的事務來處理。

軟件工程過程的每一步都是對軟件解法的抽象層次的一次精化。

軟件設計中的抽象機制主要包括類、模板、過程抽象、數據抽象和控制抽象。

? 8.3.3 內聚與耦合

內聚是指一個組件內各個元素彼此結合的緊密程度 內聚種類（由低到高排列）：偶然內聚；邏輯內聚；瞬時內聚；過程內聚；通信內聚；順序內聚；功能內聚

耦合是指一個軟件結構內不同組件之間的互連程度 耦合種類（由高到低排列）：內容耦合；公共耦合；外部耦合；控制耦合；標記耦合；數據耦合；非直接耦合

組件的高內聚、低耦合原則稱為組件獨立原則

? 8.3.4 封裝與信息隱蔽

第一，組件是其全部屬性和全部服務緊密結合而形成的一個不可分割的整體。

第二，組件是一個不透明的黑盒子，表示組件狀態的數據和實現操作的代碼都被封裝在黑盒子里面。使用一個組件的時候，只需知道它向外界提供的接口形式，無須知道它的數據結構細節和實現操作的算法。

? 8.3.5 啟發式規則

深度、寬度、扇出與扇入 作用域和控制域 功能的可預測性

8.4設計視圖

? 8.4.1 架構視圖（靜態視圖）

架構描述語言（ADL）? ? ? ? ? ? ? ? ? ? ? ? ? ? ?

? ? ?

?

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?

? ? 類圖與對象圖 組件圖

協作責任卡（CRC）部署圖

實體-聯系圖（E-R圖）接口描述語言（IDL）結構圖

Jackson結構圖

? 8.4.2 行為視圖（動態視圖）

活動圖 協作圖 順序圖 數據流圖

決策表和決策圖

流程圖和結構化流程圖 狀態圖

形式化描述語言 偽碼

8.5小節

系統設計是定義一個系統或軟件的架構、組件、接口和其它特征的過程。包括系統級設計決策、系統架構設計、運行設計、系統出錯處理設計和系統維護設計。

軟件設計主要包括軟件級設計決策、軟件架構設計（概要設計）與詳細設計。軟件架構設計的主要任務是程序結構設計、全局數據結構設計、軟件配置項設計、動態交互設計和接口設計。軟件詳細設計是指每一個軟件配置項的具體設計。

組件化、抽象、高內聚與低耦和、封裝與信息隱蔽是軟件設計的基本原則。軟件設計視圖通?？煞譃榧軜嬕晥D（靜態視圖）和行為視圖（動態視圖）兩類。第9章

系統設計方法 9.1結構化設計

? 9.1.1 結構化設計方法概述

分析系統的總體需求，并將需求逐步分解為基本、具體的功能。確定每個功能應當記錄的數據。

列出系統中應提供的各項基本功能，并分析各項基本功能之間的耦合關系，根據高內聚、低耦和的原則分配到系統中適當的模塊中。

? 9.1.2 系統結構圖

模塊 調用 數據 控制 轉接符號

? 9.1.3 系統結構圖分類

變換流與事務流 變換型系統結構圖 事務型系統結構圖 ? ? ?

? ? ? ? ? ? ? ?

? 混合型系統結構圖

9.2面向數據結構的設計

? 9.2.1 面向數據結構的設計概述

分析并建立適合系統的數據結構；

根據數據結構在相應的層次建立程序結構；

羅列出程序中用到的各種基本操作，并將這些基本操作分配到程序結構中合適的模塊中。

? 9.2.2 Jackson圖

順序結構 選擇結構 重復結構

改進的Jackson圖

? 9.2.3 Jackson方法

分析并確定輸入和輸出數據的邏輯結構，并利用Jackson 找出輸入和輸出數據結構中存在對應關系的數據單元。從描繪數據結構的Jackson圖導出描繪程序結構的Jackson

列出所有操作和條件(包括分支條件和循環結束條件)，并且把它們安排到程序結構圖的適當位置。用偽代碼表示。

9.3面向對象的設計

? 9.3.1 面向對象的設計概述

面向對象設計的基本思想是通過建立和客觀實際相對應的對象，并通過這些對象的組合來創建具體的應用。

面向對象設計具有基于抽象、信息隱藏、功能獨立和模塊性構造系統的能力。

對于面向對象的系統，可以定義一個四個層次的設計金字塔：子系統層；類及對象層；消息層；責任層。

? 9.3.2 面向對象設計技術

? Coad/Yourdon方法 ? Booch方法 ? OMT方法 ? ?

? 9.3.3 面向對象設計過程

系統設計過程：將分析模型劃分為子系統；子系統分配及與問題的并發性；任務管理；數據管理；資源管理；人機界面；子系統間通信

對象設計過程：對象描述；算法與數據結構設計；接口設計與模塊化

9.4設計模式

? 9.4.1 設計模式概述

設計模式就是將面向對象軟件的設計經驗記錄下，可供設計者能夠復用的設計方案。設計模式極大提高了面向對象軟件開發的效率，降低了軟件的復雜度。

在軟件設計中使用設計模式，將使用開發出來的軟件更容易理解、更容易維護、更容易擴展，使用設計模式同時也能夠提高開發團隊和個人的開發能力。

? 9.4.2 設計模式基本組成

模式名稱：惟一標識一個設計模式。問題：描述應該在何時使用該模式。? ? ?

? ? ? ? ? ? ? ? ?

? ? ?

? ? ?

? ?

? 解決方案：描述設計的組成要素，以及它們之間的相互關系及各自的職責與相互之間協作的方式。

? 效果：描述應用設計模式的效果，以及使用設計模式必須考慮的限制和約束因素。

? 9.4.3 設計模式分類

? 面向對象模式 ? 代碼模式

? 框架應用模式

? 創建型模式、結構型模式與行為型模式 ? 類模式與對象模式

? 9.4.4 如何使用設計模式

? 針對接口編程，而不是針對實現編程 ? 優先使用對象組合，而不是類繼承 ? 找出變化并封裝

9.5小節

? 系統設計是一系列迭代的過程，主要任務包括數據結構、體系結構、接口及過程細節的設計等，而設計方法是軟件設計活動中實現設計模型的方法。? 系統設計方法主要包括面向過程的結構化設計方法、面向數據結構的設計，以及面向對象的設計方法與設計模式。

第10章

數據庫設計 10.1數據建模

? 10.1.1 數據模型分類

? 概念數據模型 ? 結構數據模型 ? 物理數據模型

? 10.1.2 實體-聯系（E-R）模型

? 實體 ? 屬性 ? 聯系 ? 實體型 ? 實體集 ? 鍵 ? 域

? 10.1.3 數據模型

? 層次數據模型（hierarchical model）? 網狀數據模型（network model）? 關系數據模型（relational model）

? 面向對象模型（object oriented model）

10.2數據規范化

? 10.2.1 數據規范化的基本概念

? 函數依賴

? 非平凡函數依賴 ? 完全函數依賴 ? 部分函數依賴

? 傳遞函數依賴 ? 鍵

? 10.2.2 范式

? ? ? ? 第一范式（1NF）第二范式（2NF）第三范式（3NF）BC范式（BCNF）

10.3數據庫設計過程 ? 10.3.1 數據庫需求分析

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 數據邊界的確定 數據環境的確定 數據內部關系 數據字典

數據性能需求

數據需求分析說明書

? 10.3.2 數據庫概念設計

概念設計與概念模型 概念設計的主要方法 分解與抽象 局部概念模式 全局概念模式

? 10.3.3 數據庫邏輯設計

初始模式的形成 子模式設計

應用程序概要設計 模式評審 修正模式

? 10.3.4 數據庫物理設計

存儲記錄結構設計 確定數據存放位置 存取方法設計

完整性和安全考慮 程序設計

10.4小節

? 數據庫系統普遍采取數據模型表示和處理客觀事物的數據特征與信息。數據模型主要由數據結構、數據操作和完整性約束三部分組成，從抽象層次上描述和模擬了系統的靜態特征、動態行為和約束條件。

? 關系數據庫中的關系必須滿足一定的要求，即滿足不同的范式。目前關系數據庫中常用的范式包括：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）和BCNF。? 數據庫設計主要包括需求分析、概念設計、邏輯設計和物理設計等幾個階段。

第11章

用戶界面設計

11.1基本概念

? ? ?

? ? ? ? ? ? ? ? ? ?

? ? ? ? ? ?

? ? ? ? ? ? ? ? ? ? ? ?

? 11.1.1 界面設計目標

可用性目標：可行性、有效性、易學性、易記性、安全性、通用性

用戶體驗目標：令人滿意、令人愉快、引人入勝、富有啟發、激發創造??

可用性目標主要從客觀角度來評價系統界面，而用戶體驗目標則是從用戶主觀感受的角度來評價系統界面。

? 11.1.2 界面設計原則

可視性：將系統功能呈現得一目了然。

反饋性：返回與活動相關的信息，以便用戶能夠繼續這個活動。限制性：將用戶的行為限制在一定的范圍內。

對應性：明確系統某個控制與其控制效果之間的對應關系。一致性：用相似的元素表現相似的操作或相似的任務。啟示性：界面元素應給予用戶某種提示。

? 11.1.3 界面設計過程

標識出用戶的真實需要并建立需求模型 設計出候選方案

構建或實現設計的原型版本 對界面設計進行評估

11.2界面設計技術

? 11.2.1 界面設計分析技術

GOMS模型及GOMS擊鍵層模型 Hick律 Fitts律

? 11.2.2 界面設計方法

原型設計方法

以用戶為中心的設計方法 用戶界面設計的支持工具

11.3界面設計評估

? 11.3.1 構造性評估與總結性評估

構造性評估：在設計過程中對所設計的系統或產品界面進行評估以確保其滿足用戶需求。

總結性評估：對已經完成的產品或系統界面進行評估。

? 11.3.2 評估范型

快速評估 可用性測試 實地研究 預測性評估

? 11.3.3 評估方法與技術

觀察用戶

征求用戶意見 征求專家意見 用戶測試

用戶執行情況的分析模型

? 11.3.4 評估框架

明確（Determine）

? ? ? ? ? ? ? ? ?

發掘（Explore）選擇（Choose）標識（Identify）決定（Decide）評估（Evalute）

11.5小節

用戶界面體現了用戶利用系統完成任務的方式以及系統對用戶行為的響應方式，一個沒有良好的用戶界面設計的系統很可能會成為一個沒有用戶的系統。可用性目標與用戶體驗目標。

界面設計的量化模型：GOMS模型及其子模型-擊鍵層模型，Hick律和Fitts律。構造性評估與總結性評估。

第12章

系統設計文檔

12.1系統/子系統（結構）設計說明

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 引言 引用文件

系統級設計決策

系統體系結構設計：總體設計；系統部件設計；動態交互設計；接口設計 運行設計

系統出錯處理設計 系統維護設計 尚未解決的問題 需求的可追蹤性 注解 附錄

12.2

接口設計說明

引言 引用文件 接口設計

需求的可追蹤性 注解 附錄

12.3

軟件（結構）設計說明

引言 引用文件

軟件級設計決策

軟件體系結構設計：程序結構設計；全局數據結構設計；軟件配置項設計；動態交互設計；接口設計 軟件詳細設計 需求的可追蹤性 注解 附錄

12.4數據庫設計說明

? ? ? ? ? ? ? ? ?

? ? ? ? ?

引言 引用文件

數據庫級設計決策 數據庫詳細設計

用于數據庫操縱或訪問的軟件配置項的詳細設計 需求的可追蹤性 注解 附錄

12.5

小節

根據《GB/T 8567-2006 計算機軟件文檔編制規范》，系統設計文檔主要包括系統/子系統設計（結構設計）說明（SSDD）、接口設計說明（IDD）、軟件（結構）設計說明（SDD）和數據庫設計說明（DBDD）。

系統/子系統設計（結構設計）說明（SSDD）描述了系統（或子系統）的系統級（或子系統級）設計決策與體系結構設計。

接口設計說明（IDD）描述了一個或多個系統、子系統、硬件配置項（HWCI）、計算機軟件配置項（CSCI）、用戶或其他系統部件的接口特性。

軟件（結構）設計說明（SDD）描述了計算機軟件系統的軟件級設計決策、軟件體系結構設計（概要設計）與詳細設計。

數據庫（頂層）設計說明（DBDD）描述了數據庫的設計。系統設計文檔可以使用自然語言，可以使用形式化語言，也可以根據具體的系統設計方法使用各種圖形工具，還可以根據實際情況混合使用多種表現形式。