本人工程實踐項目為自選題基於科大軟院學生選課系統的開發，最近也在准備開題報告，所以跟這次高軟作業也有部分重疊之處，本博客主要基於老師《從需求分析到軟件設計》章節指導思想進行完成，從需求分析、用例建模、業務領域建模、數據模型、概念模型及工作過程角度進行了詳細的分析與建模。也相信這次高軟作業能對工程實踐課題的理解大有裨益。
一、需求分析
顯然對於本項目，用戶主要有三類，一為科大軟院的學生，二為參與授課的老師，三位負責整個系統維護的管理員，下面我們分別從不同用戶的角度對其需求進行分析。
1.1學生角度
1.選課需求：在管理員設置的開放選課的時間段進行選課與退課，同時選課時要遵循以下四個要求：不得超過課程容量上限，不得選擇有時間沖突的課程，不得超過學分限制，不得選擇與本專業方向沖突的課程。
2.信息查詢需求：這里的信息查詢主要是指對於課程信息的查詢、個人成績的查詢以及對於已選課程的查詢。
4.基本信息的登記與修改需求：基本信息主要包括姓名、學號、性別、年級、出生年月、專業方向、電話號碼、郵箱等，學生可以對其進行修改。
3.登錄需求：通過輸入學號與密碼才能登錄到本系統，同時當忘記密碼時，可以聯系管理員進行密碼的修改。
1.2教師角度
1.登錄需求：通過輸入職工號與密碼才能登錄到本系統，同時當忘記密碼時，可以聯系管理員進行密碼的修改。
2.課程設置需求：主要包括對於自身開設的課程的信息填寫，主要包括授課老師姓名、課程描述、課程容量、授課時間、授課周數，同時結課時需要登錄相應的成績。
3.基本信息的登記與修改需求：基本信息主要包括姓名、職工號、性別、出生年月、任職學院、電話號碼、郵箱、辦公地點，老師可以對其進行填寫與修改。
1.3管理員角度
1.對學生信息增刪改查：主要包括對學生選課信息進行增刪，對學生基本信息進行增刪改查，修改課程成績這三個部分
2.對教師信息增刪改查：主要包括修改教師的基本信息，修改教師的課程信息。
3.對選課時間的管理：設定一輪選課的時間，設定二輪選課的時間。
二、用例建模
根據上述對各個層次用戶群體的需求分析，我們不難做出如下的用例圖：
2.1管理員的用例圖
1.2學生的用例圖
1.3教師用例圖
三、業務領域建模
業務領域建模的基本步驟如下：
1.收集業務領域的信息
2.執行團隊進行頭腦風暴
3.將這些業務領域概相關的知識概念進行分類
4.最后使用UML圖將業務領域知識變得圖形化
3.1本項目中的業務領域建模
上述基本步驟具體化到本項目中則變成了學生基礎信息、教師基礎信息、課程信息、賬號密碼儲存、選課信息儲存、管理員類六個類。
我們將其進行細化可以得到如下的屬性：
學生基礎信息類：學號、姓名、性別、年級、出生年月、專業方向、聯系方式、郵箱
教師基礎信息類：教職工號、姓名、性別、出生年月日、任職學院、聯系方式、郵箱、辦公地點
課程信息類：課程編號、課程名、起始結束周、課程容量、授課老師職工號、課程介紹、上課起始結束節數
賬號密碼儲存類：用戶類型、用戶id、密碼
選課信息儲存類：選課學生學號、該記錄id、學生成績、所選課程id號
管理員類：賬號id
同時我們對各個類之間進行分析，可以繪制出如下類圖：
四、數據模型
根據前面的需求分析與業務類圖，我們可以設立出六個不同的表項用於存儲所需的數據，前三張為學生、教師、課程的基礎信息表，主要記錄了一些關於教師、學生和課程的基礎信息，后兩張分別存儲了學生的選課信息情況及學生教師管理員的賬號密碼，最后一張存儲了管理員的基本信息。通過這六張表即完成了數據模型的部分。
4.1學生基礎信息表
| 屬性名 | 類型 | 是否可取空（Y/N） | 注釋 |
| student_id | int | N | 學生學號（主鍵） |
| student_name | varchar | N | 學生姓名 |
| student_sex | set<Male> | N | 性別選項 |
| student_grade | set<Grage> | N | 年級選項 |
| student_date | set<Date> | N | 出生年月日選項 |
| student_major | set<Major> | N | 專業方向選項（網安、嵌入式、大數據、軟設） |
| student_phone | int | N | 學生聯系方式 |
| student_mail | varchar | N | 學生郵箱 |
4.2教師基礎信息表：
| 屬性名 | 類型 | 是否可取空（Y/N） | 注釋 |
| teacher_id | int | N | 教職工號（主鍵） |
| teacher_name | varchar | N | 教師姓名 |
| teacher_sex | set<Male> | N | 性別選項 |
| teacher_date | set<Date> | N | 出生年月日選項 |
| teacher_college | set<Major> | N | 教師任職學院 |
| teacher_phone | int | N | 教師聯系方式 |
| teacher_mail | varchar | N | 教師郵箱 |
| teacher_location | varchar | N | 教師辦公地點 |
4.3課程信息表
| 屬性名 | 類型 | 是否可取空（Y/N） | 注釋 |
| course_id | int | N | 課程編號（主鍵） |
| course_name | varchar | N | 課程名 |
| course_startWeek | set<Week> | N | 課程起始周 |
| course_endWeek | set<Week> | N | 課程結束周 |
| course_member | int | N | 課程容量 |
| course_teacherId | int | N | 授課老師教職工號 |
| course_introduce | varchar | N | 課程介紹 |
| course_startTime | set<Time> | N | 課程第幾節起始 |
| course_endTime | set<Time> | N | 課程第幾節結束 |
| course_day | set<Day> | N | 星期幾上課 |
4.4賬號密碼存儲表
| 屬性名 | 類型 | 是否可取空（Y/N） | 注釋 |
| protect_id | int | N | 學生/教師/管理員id號(主鍵) |
| protect_type | Set<Type> | N | 用戶類型選項 |
| protect_password | varchr | N | id對應的密碼 |
4.5選課信息存儲表
| 屬性名 | 類型 | 是否可取空（Y/N） | 注釋 |
| choose_studentId | set<StudentId> | N | 選擇該課學生的學號 |
| choose_id | int | N | 該選課記錄條目序號（主鍵） |
| choose_grades | set<Grades> | Y | 該學生本課程的成績（初始值為空） |
| choose_courseId | set<courseId> | N | 該學生所選課程id號 |
4.5管理員基礎信息表：
| 屬性名 | 類型 | 是否可取空（Y/N） | 注釋 |
| Administrator_id | int | N | 管理員id |
| First_Start_Time | DATETIME | Y | 一輪選課開始時間 |
| First_End_Time | DATETIME | Y | 一輪選課結束時間 |
| Second_Start_Time | DATETIME | Y | 二輪選課開始時間 |
| Second_End_Time | DATETIME | Y | 二輪選課結束時間 |
5. 概念原型及對應工作過程
5.1 概念原型的定義
在理解概念原型之前，我們首先要理解概念的定義——即人對能代表某種事物或發展過程的特點及意義所形成的思維結論。因此我們可以得出概念原型的定義，其是一種虛擬的、理想化的軟件產品形式，更加直觀的來說，概念原型等於數據模型加上用例。
5.2 基於本選課系統項目的概念原型
總上所述，我們已經將用例和數據模型一一列出，至此我們可以得出基於本項目的概念原型——在本項目中一共有三個用例：軟院學生、教師、管理員。及六個數據模型：學生基礎信息表、教師基礎信息表、課程信息表、賬號密碼儲存表、選課信息儲存表、管理員基礎信息表。
5.3基於本選課系統項目的工作過程
通過上述的概念模型我們可以給出整個項目的工作過程：首先，不論是學生、管理員還是教師都需要用戶輸入學號（教職工號）和密碼，才能登錄系統，若需要修改密碼則可通知管理員，統一進行操作。修改后對應賬號密碼存儲表表項將被修改，教師及學生登錄后可以修改個人基礎信息，對於教師而言可以教師增添授課信息、修改個人信息及登記學生成績，這些操作將對教師基礎信息表、課程信息表進行更新，學生可以查看已開設的課程信息，已選課程，課程考試成績在合理的選課時間可以進行選課，同時也可以對已經選擇的課程進行退課，這些操作也將會對課程信息儲存表、學生基礎信息表進行更新。最后，作為管理員，整個系統的最高權限者，其囊括了教師及學生的全部功能，同時，作為選課時間的管理者，還可以設置選課即搶課時間，同時由於管理員需要處理學生、教師賬號密碼遺失的問題，也須有修改賬號密碼存儲表的權限。
|
|