2006－6－27 隨筆－Struts課程設計(1)

上午結束了Struts最後的一節課後，並給學生們佈置了一個課程設計；於是便開始想自己的想法有多少會被學生們接收。因為對於Struts框架本身而言只是一個開發框架，並沒有具體的要求，雖然開發者會選擇一些整合的軟體開發工具來開發（如：Eclipse,JBuilder等）；但是對於開發本身是一個完整的結構，開發工具只是提供了一個提高構建階段效率的工具，開發框架也只是提供了一個設計期間可用的模式；對於軟體開發依然需要一個系統化的過程才能實現軟體。基於這個想法，我為我的學生們做了這個課程設計，希望他們可以體會到我的用意。

上午的時候由於昨天的義大利和澳大利亞的世界盃比賽，所以遲到了；不過學生們似乎習慣了我的遲到所以都在教室裡等這我。我到了教室和他們閒聊一下昨天晚上（應該是今天早上凌晨）的比賽結果，然後進入正題佈置我前幾天準備的課程設計題目。其實此時我心裡在想，這些學生們只接觸了MVC設計模式和Struts不到2周是否能夠真的理解Struts框架的意義。所以，對於這個課程設計的目標我定義的很清楚就是讓他們體驗一些如何設計一個軟體，然後把主要精力集中在軟體構建階段（設計和修改軟體介面，編碼，測試，整合執行）。因此我這樣劃分了任務

2.介紹專案範圍
業務流程
劃分功能模組
瞭解模組設計
構建開發系統
專案測試＆驗收
總結

其中1～4階段是軟體的範圍定義和分析設計，所以就由我自己來定義了。這個需要我所製作的幻燈片和我的講解來達到讓學生們可以體驗一個軟體設計的過程。

介紹專案範圍
   該課程設計是把一個專案審批系統的核心部分簡化得到的一個原形，無論是業務流程還是程式邏輯都做了相應的簡化，以保證學生可以在一天左右完成這個程式（事實上以我的經驗一般一個勤快的學生一天最多也只願意在課外花2～4小時在學習上）。程式範圍如下：
系統包括兩類使用者使用該軟體
       1. 專案申請人
       2. 專案稽核人
專案申請人主要使用系統功能如下：
       1. 提出專案申請
       2. 管理專案申請資訊
       3. 專案預算分析
專案稽核人主要使用系統功能如下：
        1. 專案審批
       2. 管理審批資訊
        3. 統計專案總體費用

事實上這裡是一個用例描述，不過這裡沒有做用例圖，因為我比較喜歡在上課的時候在白板上畫用例。我始終覺得邊畫邊講會比先畫好了再講要好些；因為這樣資訊的傳遞過程中，學生不是處在一個被動過程，而是處在一個理解並接收的過程，當然這需要講解過程中的一些溝通技巧。當然光靠一個用例就能把範圍講清楚，這個基本是很難做到的，因為對於Use－Case還需要搭配用例說明，所以這裡還需要對每個用例功能做業務性的描述。

為了更好的描述這個業務過程，我做了一個業務流程圖。這個業務流程圖根據角色和任務以橫向的角度來劃分軟體的流程。

接下來，就是對資料的分析，因為業務流程中，對於程式的處理主要是處理流程中的資料，所以下面做的事情就是設計E－R圖和資料流圖。如下圖：

該E－R圖所描述的資料結構，我們可以通過下面5張表格來說明：

表名： Projects

欄位名	型別	約束	說明	備註
Pid	Char(20)	PK	專案編號
UserId	Char(20)	Not Null	使用者ID
PSubject	varChar(20)	Not Null	專案名稱
PDate	Datetime	Default now	申請日期
Budgets	Decimal(10,2)	Default 0.0	專案預算
表說明：	表示準備審批的專案

表名：Users

欄位名	型別	約束	說明	備註
UserID	Char(20)	PK	使用者ID
Password	Char(20)	Not Null	密碼
Prid	Char(10)	FK Not Null	許可權
表說明：	表示使用者，可以根據許可權決定使用者

表名：Priority

欄位名

型別

約束

說明

備註

Prid

Char(10)

PK

許可權

表說明：

表示使用者許可權

表名：Budgets

欄位名	型別	約束	說明	備註
UserID	Char(20)	PK	使用者ID
BID	Char(10)	PK	預算編號
Money	Decimal(10,2)	Default 0.0	預算金額
表說明：	表示每個使用者的預算，一個預算可對應多個使用者

表名：Audits

欄位名	型別	約束	說明	備註
Pid	Char(20)	PK	專案編號
Checked	Bit	Default false	是否審批通過
表說明：	表示審批專案

接下來我們把資料的在業務流程的流動中的轉換過程通過資料流圖進行描述，如下圖：

專案申請資料流圖

專案審批資料流圖

以上是傳統的資訊化軟體工程設計中經常用到的資料分析方法，通過上面的方法可以很清楚知道，軟體要做那些事情；這些事情要使用那些資料；而這些資料又要被程式處理後已什麼樣的形式出現。可是這些設計完成了以後，使用者也無法直接操作軟體，所以此時根據我個人的經驗我比較傾向與開始著手設計UI使用者介面。我們再圍繞這兩個流程簡單的設計兩個頁面，分別來處理這兩個流程

這個頁面用來做專案的申請工作，使用者可以新建一個要申請的專案，刪除一個已經申請但還沒有批准的專案，如果專案已經批准則已紅色顯示並且無法做任何修改和刪除工作，當然使用者也可以選擇一個還沒有批准的專案做修改，然後儲存。

該頁面是由稽核人使用的頁面，使用者可以通過打勾來確定那些專案可以稽核通過，同時修改預算。

最後我們到了設計類圖的階段，這也是定義軟體的功能模組的階段。這裡我們要結合Struts框架來做設計，也就是考慮MVC各個模組的設計介面，再類圖設計的時候必須結合講解每一個類和每一個方法完成什麼功能和任務，上下層模組之間的介面是如何呼叫的。

最後預算一下這個工程要花多少事件，來完成也給學生們一個明確的任務界限

類名	開發時間	類名	開發時間
DBAccess	20 min	ProjectAction	30 min
Project	2 h	EditProjectAction	20 min
User	20 min	DeleteProjectAction	10 min
Proposer	10 min	AuditAction	10 min
Assessor	1 h	PageSplitAction	20 min
ProjectForm	10 min	總計：	5.5 h

到此時，我已經花了近一個小時介紹這個課程設計，接下來我和我的學生們討論一些細節問題；然後我就讓他們準備上機實踐，並準備驗收。

2006－6－27 隨筆－Struts課程設計(1)

相關文章