員工工資管理信息系統(tǒng)課程設計

1、<p>　　課 程 設 計 報 告</p><p>　　指導教師： 職稱: </p><p>　　2011年 7 月 15 日</p><p>　學生姓名:學 號：</p><p>　學 院:</p><p>　班 級:</p><p>

2、　題 目:員工工資管理信息系統(tǒng)課程設計</p><p><b>　　目 錄</b></p><p>　　1. 選課背景1</p><p>　　2. 人事工資管理系統(tǒng)需求分析2</p><p>　　2.1 人事工資管理系統(tǒng)的需求陳述2</p><p>　　2.2 需求分析2&l

3、t;/p><p>　　2.2.1 功能需求2</p><p>　　2.2.2 性能需求3</p><p>　　2.3 系統(tǒng)需求建模3</p><p>　　2.3.1 確定參與者4</p><p>　　2.3.2 確定用例4</p><p>　　2.3.3 系統(tǒng)用例建模6</p&g

4、t;<p>　　2.3.4 用例描述6</p><p>　　3. 員工工資管理系統(tǒng)系統(tǒng)分析8</p><p>　　3.1 系統(tǒng)用例建模8</p><p>　　3.2 靜態(tài)結構模型11</p><p>　　3.2.1 類的識別11</p><p>　　3.2.3 類的屬性描述11</

5、p><p>　　3.2.4 類圖的構建12</p><p>　　3.3 系統(tǒng)動態(tài)模型12</p><p>　　3.3.1 系統(tǒng)執(zhí)行順序分析12</p><p>　　3.3.2 系統(tǒng)的協(xié)作分析14</p><p>　　3.3.3 系統(tǒng)狀態(tài)分析14</p><p>　　3.3.4 系統(tǒng)活動分

6、析15</p><p>　　4.系統(tǒng)設計與實現17</p><p>　　4.1 UML體系結構設計17</p><p>　　4.1.1 硬件體系結構設計17</p><p>　　4.1.2 軟件體系結構設計18</p><p>　　4.2 對象模型設計19</p><p>　　4

7、.3 系統(tǒng)實現20</p><p>　　4.3.1 組件分析20</p><p>　　4.3.2 配置分析21</p><p>　　5.課程設計心得體會22</p><p><b>　　參考文獻23</b></p><p><b>　　1. 選課背景</b>&l

8、t;/p><p>　　隨著社會的進步和計算機技術的發(fā)展，特別是微型計算機的大范圍普及，現在應用在大中型企業(yè)的信息管理系統(tǒng)中，幾乎都包括了工資管理模塊。有些環(huán)境中是有大型ERP軟件中的一個模塊引進的，有些作為企業(yè)的財務系統(tǒng)的一部分。計算機處理的數據量不斷增加。文件管理系統(tǒng)采用的一次最多存取一個記錄的訪問方式，以及在不同文件之間缺乏相互聯系的結構，越來越不能適應管理大量數據的需要，于是數據庫管理系統(tǒng)便應運而生。有了數據庫

9、我們便能方便快捷的對數據進行讀取、存取，并維護數據庫的數據。但，西方管理制度設計的工資管理軟件，在很多時候還不能完成解決中國特色中小企業(yè)的問題，本文介紹的畢業(yè)設計的研究工作就是要為這些具有中國特色的中小企業(yè)解決他們在工資管理方面的問題。今天，數據庫管理已成為計算機信息管理的主要方式。數據庫的應用非常廣泛，可應用于各行各業(yè)，只要是稍復雜的數據，都可制作成數據庫，交由電腦來管理。用電腦管理數據，運算速度快，檢索迅速、查找方便、可靠性高、存儲

10、量大、保密性好、壽命長、成本低且不易出錯等，這些優(yōu)點能夠極大地提高工資管理的效率,也是科學化、正規(guī)化管理的重要條件，尤其是現在的中小型企業(yè)正需要這種對口的工資管理</p><p>　　2. 員工工資管理系統(tǒng)需求分析</p><p>　　2.1 員工工資管理系統(tǒng)的需求陳述</p><p>　　工資管理系統(tǒng)的主要任務是通過工資費用的計算和分配，為成本核算與賬務處理提供

11、依據，并且根據工資制度和職工勞動數量與質量，計算并發(fā)放應該支付給職工的工資。工資核算時工資管理的主要內容。工資核算包括工資結算與工資分配兩個方面。工資結算是指應付工資、代扣款項和實發(fā)工資的計算；工資分配是指按部門、類別進行工資匯總，并按工資的用途對工資進行分配。</p><p>　　工資總額是指各單位在一定時期內支付給本單位全體職工的全部勞動報酬總額。按照國家統(tǒng)計局的規(guī)定，工資總額有計時工資、計件工資、獎金、津貼

12、和補貼、加班加點工資和特殊情況下支付的工資6部分組成，其中計時工資和計件工資是工資總額中最基本的部分。上述工資構成要件所組成的工資總額只是應發(fā)工資，并非每個職工拿到手的實發(fā)工資，原因在于存在一些應扣項目，例如水電費、工會會費、保險費、公積金、病事假扣款、曠工扣款和個人所得稅等。在計算每個職工實發(fā)工資之前應在工資總額中扣除這部分款項，即有如下關系：</p><p>　　應發(fā)工資 = 基本工資 + 工齡工資 + 崗位

13、津貼 + 固定補貼 + 加班加點工資 + 獎金</p><p>　　扣款合計 = 水電費 + 保險費 + 個人所得稅 + 病假扣款 + 事假扣款 + 曠工扣款 + 其他扣款</p><p>　　實發(fā)工資 = 應發(fā)工資 – 扣款合計</p><p>　　每個月財務部門根據人事部門提供的職工基本工資數據、所得稅率和人事變動情況計算所有員工的基本工資信息，然后根據各個部門

14、提供并審核后的各種表格，如完成任務表、考勤表、考核表、職工當月的扣款情況（包括水電費、病事假扣款等）等計算職工變動工資、個人所得稅和應發(fā)放工資等，編制工資單。按類進行匯總，編制工資匯總表。將實發(fā)工資轉入代發(fā)銀行，由銀行代發(fā)工資，并進行賬務處理。工資結算過程主要設計如下會計賬戶：現金、銀行存款、應付工資、其他應付款、其他應收款等。</p><p><b>　　2.2 需求分析</b><

15、/p><p>　　2.2.1 功能需求</p><p>　　工資管理系統(tǒng)涉及到員工基本信息的錄入、修改和刪除，工資標準的設定、查詢和結算等。</p><p>　　典型的工資管理系統(tǒng)主要有以下基本功能：</p><p>　　a) 系統(tǒng)數據初始化</p><p>　　b) 員工基本信息的錄入、修改、刪除等功能</p>

16、;<p>　　c) 工資標準的設定功能，集體包括職務工資、職稱工資、其他工資標準和福利的設定。</p><p>　　d) 工資信息的瀏覽</p><p>　　e) 員工工資信息表的創(chuàng)建及查詢</p><p><b>　　f) 工資調整管理</b></p><p><b>　　g) 工資計算<

17、/b></p><p><b>　　h) 工資報表打印</b></p><p>　　2.2.2 性能需求</p><p>　　需求分析的目的在于與開發(fā)人員與用戶之間達成系統(tǒng)開發(fā)的共識，使開發(fā)人員所考慮的系統(tǒng)在功能（系統(tǒng)能做什么）、簡單操作，良好界面，個人信息保密性，系統(tǒng)安全與穩(wěn)定，良好帳戶管理，友好信息返回模式（如報表及打印功能）。<

18、;/p><p>　　此工資管理系統(tǒng)對工資數據精度的計算能在默認情況之下精確到小數點后3位小數，即是精確到分的計算。但在用戶使用過程中，能自行根據實際情況進行小數計算精度的設定，最大能允許保留小數點后5位的精度。在時間特性上，當用戶發(fā)出命令請求時的服務器的響應時間、對數據更新處理、工資數據的查詢檢索等上，同樣要求系統(tǒng)響應時間不會超過0.5秒時間。系統(tǒng)支持多種操作系統(tǒng)的運行環(huán)境，多不同操作系統(tǒng)，不同文件格式的磁盤上的數據

19、均能實現信息的互通，及共享。當服務器移植到其他的系統(tǒng)平臺，如：Linux平臺下時，同樣能和其他的系統(tǒng)進行數據存取同步，不會出現系統(tǒng)之間互不兼容的情況，系統(tǒng)支持多系統(tǒng)之間的互連互通，系統(tǒng)有巨大的強健性。</p><p>　　2.3 系統(tǒng)需求建模</p><p>　　在進行用例建模之前，我們首先了解到用例模型描述的是外部執(zhí)行者(Actor)所理解的系統(tǒng)功能。它主要用于需求分析階段，它的建立是

20、系統(tǒng)開發(fā)者和用戶反復討論的結果，表明了開發(fā)者和用戶對需求規(guī)格達成的共識。它的重要作用對于我們人事管理系統(tǒng)的分析和設計主要體現在以下幾個方面：</p><p>　　首先，它描述了待開發(fā)系統(tǒng)（人事管理系統(tǒng)）的功能需求；</p><p>　　其次，它將系統(tǒng)看作黑盒，從外部執(zhí)行者的角度來理解系統(tǒng)；</p><p>　　再次，它驅動了需求分析之后各階段的開發(fā)工作，不僅在開發(fā)過

21、程中保證了系統(tǒng)所有功能的實現，而且被用于驗證和檢測所開發(fā)的系統(tǒng)，從而影響到開發(fā)工作的各個階段和UML的各個模型。</p><p>　　從本質上講，一個用例是用戶與計算機之間的一次典型交互作用。在UML中，用例被定義成系統(tǒng)執(zhí)行的一系列動作，動作執(zhí)行的結果能被指定執(zhí)行者察覺到。</p><p>　　幾乎在任何情況下都會使用用例。用例用來獲取需求，規(guī)劃和控制項目。用例的獲取是需求分析階段的主要任

22、務之一，而且是首先要做的工作。大部分用例將在項目的需求分析階段產生，并且隨著工作的深入會發(fā)現更多的用例，這些都應及時增添到已有的用例集中。</p><p>　　2.3.1 確定參與者</p><p>　　在分析過程開始的時候，我們考慮到獲取用例首先要找出系統(tǒng)的執(zhí)行者。，有鑒于此，我們通過用戶回答一些問題的答案來識別執(zhí)行者。</p><p>　　1.誰使用系統(tǒng)的主要功

23、能(主要使用者)。</p><p>　　2.誰需要系統(tǒng)支持他們的日常工作。</p><p>　　3.誰來維護、管理使系統(tǒng)正常工作(輔助使用者)。</p><p>　　4.系統(tǒng)需要操縱哪些硬件。</p><p>　　5.系統(tǒng)需要與哪些其它系統(tǒng)交互，包含其它計算機系統(tǒng)和其它應用程序。</p><p>　　6.對系統(tǒng)產生的結

24、果感興趣的人或事物。</p><p>　　通過回答這六個問題以后，再進一步分析可以識別出系統(tǒng)頂層上的8個活動類：公司主管 、人力資源部、用人部門、培訓部門、財務處、公司工會、系統(tǒng)管理員、應聘人員</p><p>　　2.3.2 確定用例</p><p>　　在對現行住院管理系統(tǒng)的分析過程中，在我們獲取了執(zhí)行者之后，我們就對每個執(zhí)行者提出以下問題以獲取用例。</

25、p><p>　　1.執(zhí)行者要求系統(tǒng)提供哪些功能(執(zhí)行者需要做什么)。</p><p>　　2.執(zhí)行者需要讀、產生、刪除、修改或存儲的信息有哪些類型。</p><p>　　3.必須提醒執(zhí)行者的系統(tǒng)事件有哪些，或者執(zhí)行者必須提醒系統(tǒng)的事件有哪些，怎樣把這些事件表示成用例中的功能。</p><p>　　4.為了完整地描述用例，還需要知道執(zhí)行者的某些典型

26、功能能否被系統(tǒng)自動實現。</p><p>　　除了以上考慮到的問題之外，我們還考慮了一些不針對具體執(zhí)行者問題(即針對整個系統(tǒng)的問題)，以使自己的分析結果更加準確。</p><p>　　1.系統(tǒng)需要何種輸入輸出，輸入從何處來，輸出到何處。</p><p>　　2.當前運行系統(tǒng)(也許是一些手工操作而不是計算機系統(tǒng))的主要問題。</p><p>　

27、　因為系統(tǒng)比較大，因此不可能給出全部的分析過程，因此列舉出在人事分系統(tǒng)中一部分比較有代表性的過程。</p><p>　　圖2.1用例的生成過程</p><p>　　每個事件并不總是對應一個用例?？赡苡行┦录窍嘟蛳嗤?，如果多個事件有共同點或者多個事件的最終目標相同，那么就可以將這些事件合并為一個事件。</p><p>　　系統(tǒng)層的用例識別過程如下：</p&

28、gt;<p>　　通過前面對人力資源管理的系統(tǒng)描述，按照上面介紹的用力識別方法，可以從頂層系統(tǒng)中識別出的用例。它們是：</p><p><b>　　(1)管理組織機構</b></p><p><b>　　(2)管理招聘</b></p><p><b>　　(3)管理職位</b></

29、p><p><b>　　(4)規(guī)劃人力資源</b></p><p><b>　　(5)考評員工績效</b></p><p><b>　　(6)管理人事檔案</b></p><p><b>　　(7)管理勞動合同</b></p><p>

30、<b>　　(8)管理培訓</b></p><p><b>　　(9)管理員工薪資</b></p><p><b>　　(10)管理員工福</b></p><p>　　(11)管理系統(tǒng)權限</p><p><b>　　(12)登錄系統(tǒng)</b></p&

31、gt;<p>　　(13)修改個人資料</p><p>　　2.3.3 系統(tǒng)用例建模</p><p>　　針對人事管理系統(tǒng)的流程的分析，我們采用的是面向對象的分析方法(OOA)。使用用例圖來描述參與者與外部用戶所能觀察到的系統(tǒng)功能的模型圖，在此模型中列出了系統(tǒng)中的用例和參與者，并顯示哪個參與者參與了哪個用例的執(zhí)行。</p><p>　　2.3.4 用例

32、描述</p><p>　　一個用例對應并描述一個完整的功能。路徑是用例中事件的步驟。一個路徑也稱為一個場景。每一個用例包含多種路徑，每一個路徑由一系列業(yè)務步驟組成。如果用例的粒度太粗，一個路徑甚至一個業(yè)務步驟也可以定義為一個用例；如果用例的粒度太細，則一個用例只有一條路徑，這會導致某一功能支離破碎。因此要合理掌握用例的粒度。</p><p>　　路徑有3個層次：主要的、可選的和例外的。主路

33、徑是用例中最通常情況下發(fā)生的路徑；可選路徑是合法的但不是經常發(fā)生的路徑；例外路徑是不按設想順序進行的路徑，是應用程序中必須要捕獲的錯誤情況。用例描述了系統(tǒng)做什么，但沒有規(guī)定怎么做，即用例圖沒有顯示不同的路徑，只顯示了活動者與用例之間的關系。因此，需要為用例配上結構化敘述的文體。為了統(tǒng)一格式，每個項目應該使用一個用例模板。在論文中，系統(tǒng)實例使用如下所示的用例模板來描述用例。</p><p><b>　　用

34、例模板</b></p><p>　　用例名稱 (用例名)</p><p>　　用例目標 (用例在系統(tǒng)中的目標)</p><p>　　級別 (概要任務／首要任務／子功能)</p><p>　　活動者 (此用例的活動者)</p><p>　　狀態(tài) (未定義路徑／只定義了初始路

35、徑／路徑定義完成)</p><p>　　前件條件 (用例執(zhí)行前系統(tǒng)應具有的狀態(tài))</p><p>　　成功后件 (用例成功執(zhí)行后系統(tǒng)應具有的狀態(tài))</p><p>　　主路徑 (用例主路徑的名稱)</p><p>　　可選路徑 (用例的可選路徑)</p><p>　　例外路徑 (用例的例

36、外路徑)</p><p>　　這個模板描述了一個用例的主要方面。下面以管理招聘用例為例說明用例模板的用法。</p><p>　　用例名稱：工資管理；</p><p>　　用例目標：制定年度人力資源計劃及招聘計劃，發(fā)布招聘公告，管理員工篩選過程及評估工作；</p><p><b>　　級別：子功能；</b></p&g

37、t;<p>　　活動者：人力資源部，公司主管，用人部門；</p><p>　　狀態(tài)：只定義了初始路徑；</p><p>　　前件條件：人力資源部登錄系統(tǒng)；</p><p>　　成功后件：管理整個員工信息過程；</p><p>　　主路徑 考勤部門對員工進行日常出勤考察并登記出勤和缺勤情況，并且對員工的工作情況作出評價。

38、</p><p>　　例外路徑 無。</p><p>　　圖2.2 員工工資管理系統(tǒng)用例圖</p><p>　　3. 員工工資管理系統(tǒng)系統(tǒng)分析</p><p>　　3.1 系統(tǒng)用例建模</p><p>　　1、職工檔案管理：實現對員工基本信息的管理操作，包括員工基本數據信息的添加、修改、刪除和查詢等功能。

39、</p><p>　　2、職工信息定義： 實現對工資結構信息的添加、修改、刪除和查詢等功能。</p><p>　　3、考勤管理：根據職務分析，將員工分為不 同層面、不同類別，分別設計考評標準。對業(yè)績、能力、態(tài)度等進行月份、季度、年度考評，對考核數據提供統(tǒng)計分析功能，為薪酬、獎懲、培訓開發(fā)等方面提供依據。</p><p>　　4、工資款項標準：設定工資款項的標準。&l

40、t;/p><p>　　5、工資數據匯總：實現對工資數據的匯總、查詢等功能。</p><p>　　6、工資項目定義：實現對工資公式定義以及工資的多次發(fā)放定義。</p><p>　　7、輸入工資：輸入職工工資信息。</p><p>　　8、工資發(fā)放：發(fā)放工資，查看工資發(fā)放情況。</p><p>　　圖3.1 職工信息管理用例圖

41、</p><p>　　圖3.2 職工工作評價管理用例圖</p><p>　　圖3.3 員工福利管理用例圖</p><p>　　圖3.5 員工工資管理用例圖</p><p>　　圖3.4 員工考勤管理用例圖</p><p>　　3.2 靜態(tài)結構模型</p><p>　　3.2.1 類的識別<

42、;/p><p>　　識別類的方法通常使用的識別方法是名詞識別方法一般來說，描述問題域實體都用名詞或名詞短語。應用名詞識別方法時，要從系統(tǒng)描述中找出名詞、名詞短語或名詞性代詞，因為它們往往對應著對象(類)。其中單數名詞可以識別為對象，而復數名詞則可以識別為類，但是要注意，并不是每個名詞都對應著一個對象(類)，可能有的名詞只是其他對象的一個屬性，也可能幾個名詞對應著一個對 象(類)。</p><p

43、>　　要看找出的名詞是否都應該成為系統(tǒng)的對象(類)，考察其是否有與該對象(類)</p><p>　　3.2.3 類的屬性描述</p><p>　　屬性是對象的性質，通過對象類和結構有更深入，更具體的認識。一般來說確定屬性的過程包括分析和選擇兩個步驟。屬性的確定既與問題有關，也和目標系統(tǒng)的任務有關。應該僅考慮與具體應用直接相關的屬性，不要考慮那些超出所要解決的問題范圍的屬性。在分析過程

44、中應該首先找出最重要的屬性，以后在逐漸把其余屬性添加進去。</p><p>　　此次分析過程中，我們在分析階段沒有考慮那些純粹用于實現的屬性。只是在最后認真考察了經初步分析而確定下來的那些屬性，從中刪掉了那些不正確的或不必要的屬性。部分對象類的屬性描述如下：</p><p><b>　　經理：部門編號</b></p><p>　　員工：員工編號

45、、姓名、部門編號</p><p>　　相關部門：增加部門、刪除部門</p><p>　　員工工資：員工編號、基本工資、動態(tài)工資</p><p>　　員工管理員：增加員工、刪除員工、查詢員工、需該員工、調動員工</p><p><b>　　用戶：用戶姓名</b></p><p><b>　

46、　部門：部門編號</b></p><p>　　員工管理者：姓名、編號、所在部門</p><p><b>　　用戶管理者：</b></p><p>　　參勤情況：員工編號、遲到天數、早退天數、請假天數、加班次數</p><p>　　3.2.4 類圖的構建</p><p>　　圖3.6 員

47、工工資管理類圖</p><p>　　3.3 系統(tǒng)動態(tài)模型</p><p>　　3.3.1 系統(tǒng)執(zhí)行順序分析</p><p>　　為了實現一個合適的系統(tǒng)，第一步應對公司目前情況進行調研分析，掌握現有的工作模式和工作流程。經過對現行公司的調查和分析，人事部門的業(yè)務主要涉及兩大塊，一塊是員工基本信息，另一塊是工資管理，兩塊業(yè)務相對獨立。本文研究的是人事管理系統(tǒng)中的工資管

48、理系統(tǒng)，根據調查得出工資管理過程。</p><p>　　在順序圖中，一條豎線代表一個對象，每個時間用一條水平的箭頭線表示，箭頭方向從事件的發(fā)送對象指向接受對象，時間從上向下遞增，箭頭線在垂直方向上的相對位置表示事件發(fā)生的先后。根據工資管理過程可以繪制出如圖3.7所示的員工信息管理子模塊的順序圖。</p><p>　　圖3.7員工信息管理順序圖</p><p>　　3

49、.3.2 系統(tǒng)的協(xié)作分析</p><p>　　合作圖也稱為協(xié)作圖，用于描述相互合作的對象間的交互關系和鏈接關系。與順序圖一樣，合作圖也展示了對象間的動態(tài)協(xié)作關系。它除了說明信息的交換外，還顯示對象間的連接關系，描述信息在連接的對象之間的傳遞。</p><p>　　根據對員工信息管理系統(tǒng)的業(yè)務流程進行分析得出的順序圖，可以得出該系統(tǒng)的協(xié)作圖如圖3.8所示</p><p&g

50、t;　　圖3.8員工基本信息管理子模塊協(xié)作圖</p><p>　　3.3.3 系統(tǒng)狀態(tài)分析</p><p>　　狀態(tài)圖(State Diagram)用來描述一個特定對象的所有可能狀態(tài)及其引起狀態(tài)轉移的事件。</p><p>　　狀態(tài)圖描述了事件和對象狀態(tài)的關系。用戶在使用該系統(tǒng)之前要先進行注冊，輸入密碼注冊成功后進入系統(tǒng)。</p><p>　

51、　在進入系統(tǒng)之后要驗證用戶身份，若無權訪問則被強制退出系統(tǒng)，若有權訪問則可進入系統(tǒng)。進入系統(tǒng)后課根據需要修改、增加和刪除員工信息，確認才做后則修改完成</p><p>　　圖3.9 管理員注冊狀態(tài)圖</p><p>　　圖3.10員工信息管理狀態(tài)圖</p><p>　　3.3.4 系統(tǒng)活動分析</p><p>　　活動圖是由狀態(tài)圖轉化而來的，

52、它描述了系統(tǒng)中各種活動執(zhí)行的順序，刻畫了一個系統(tǒng)中所要進行的各項活動的執(zhí)行流程。根據上文中繪制得出的順序圖以及合作圖，對兩圖中相互交互的對象進行分析可以得出系統(tǒng)主要的活動如下：</p><p>　　圖3.11 用戶注冊活動圖</p><p>　　圖3.12員工信息管理系統(tǒng)活動圖</p><p><b>　　4.系統(tǒng)設計與實現</b></p

53、><p>　　4.1 UML體系結構設計</p><p>　　人事管理子系統(tǒng)采用面向對象技術對系統(tǒng)進行總體的設計和實現，用UML及其集成環(huán)境Rational Rose對系統(tǒng)進行分析和建模，采用PowerBuilder’s完成組件平臺建設，后端數據存儲是當前流行的Oracle9i數據庫。本系統(tǒng)基于PowerBuilder’s構建三層C/S結構，數據庫服務器運行數據庫管理系統(tǒng)軟件，COM+組件運

54、行在應用服務器上，客戶機運行住院管理系統(tǒng)客戶端軟件。</p><p>　　4.1.1 硬件體系結構設計</p><p>　　本系統(tǒng)采用C/S結構開發(fā)，三層C/S結構是在客戶和服務器之間引入應用層的概念，即在客戶端與數據庫之間加入了一個“中間層”。它將應用邏輯移到應用層完成，而客戶端弱化為一個圖形用戶接口，成為一個瘦客戶機。其解決方案是:對這三層進行明確分割，并在邏輯上使其獨立形成三層軟件結

55、構。在這種結構中，表示層、業(yè)務邏輯層和數據訪問層在邏輯上是彼此分離的，表示層向用戶提供數據，并有選擇地允許用戶使用邏輯數據。對于基于PC的應用程序來說，本機用戶和基于Web的用戶接口是其兩個主要的用戶接口。本機用戶接口使用底層操作系統(tǒng)服務，基于Web的用戶以HTML為基礎，可通過任何平臺的瀏覽器來閱讀。本系統(tǒng)的三層C/S結構如圖4.1所示。</p><p>　　圖4.1硬件體系結構圖</p><

56、;p>　　4.1.2 軟件體系結構設計</p><p>　　信息系統(tǒng)的軟件結構是由信息系統(tǒng)軟件的各子系統(tǒng)按照確定的關系構成的結構框架，一般呈現多層次結構模式。子系統(tǒng)是對軟件進行分解的一種中間形式，也是組織和描述軟件的一種方法。軟件結構設計就是把軟件分解成多個子系統(tǒng)，并確定各子系統(tǒng)及其接口之間的相互關系。員工工資管理子系統(tǒng)的軟件結構如圖4.2所示</p><p>　　圖4.2員工工資管

57、理軟件體系結構圖</p><p>　　4.2 對象模型設計</p><p>　　在前文中，對系統(tǒng)所有關聯對象經過非正式分析后得出員工工資管理子模塊的初始類如下：</p><p>　　員工、經理、部門、部門管理者評價、評價分、員工請假信息、歷史調動信息、員工檔案、員工管理者、參勤情況、福利信息、員工工資、用戶、用戶管理者</p><p>　　

58、對以上候選類進行嚴格的考察篩選，去掉不正確的或不必要的，僅保留確實應該記錄其信息或需要其提供服務的那些對象，增加和實現有關的類與對象，得出以下類與對象：</p><p>　　員工、經理、部門、評價、評價分、歷史調動信息、員工管理者、參勤情況、福利信息、員工工資、用戶、用戶管理者</p><p>　　此次分析過程中，我們在分析階段沒有考慮那些純粹用于實現的屬性。只是在最后認真考察了經初步分析

59、而確定下來的那些屬性，從中刪掉了那些不正確的或不必要的屬性。部分對象類的屬性描述如下：</p><p>　　員工：員工編號、姓名、部門編號；增加福利、修改福利、評價組內員工</p><p>　　經理：部門編號；評價員工</p><p>　　部門：部門編號、部門經理、員工人數</p><p>　　部門管理者：增加部門</p>&l

60、t;p>　　員工管理者：增加員工、刪除員工、修改員工、調動員工</p><p>　　經理對員工評價：工作分工、完成情況、工作態(tài)度；部門經理評分</p><p>　　評價分：部門經理評分、組內員工評分；計算總分</p><p>　　組內員工評價：工作態(tài)度、合作情況；組內員工評分</p><p>　　歷史調動信息：員工編號</p>

61、;<p>　　參勤情況：員工編號、正常出勤天數、遲到早退次數、請假天數、加班次數；統(tǒng)計出勤情況、修改加班表</p><p><b>　　福利信息：員工編號</b></p><p>　　用戶：用戶編號、權限等級</p><p>　　用戶管理者：用戶添加、用戶刪除、用戶權限等級設置</p><p>　　圖4.3

62、 員工工資管理對象模型圖</p><p><b>　　4.3 系統(tǒng)實現</b></p><p>　　本章使用UML建模技術，對人事管理系統(tǒng)進行了建模設計，使的開發(fā)出的產品在面對不同的客戶時方便修改和維護，大大減少了投入的人力和時間，同時大大縮小了產品的成本。在UML中，描述實現的視圖稱為組件視圖。它對模型中的組件建模，描述應用程序搭建的軟件單元以及組件之間的依賴，從

63、而可以估計更改的影響。它還對類及其他元素在組件中的分配建模。布局視圖包括組件圖、配件圖以及配置圖，他們分別從不同的角度反映并顯示了本系統(tǒng)的軟件和硬件的物理配置。</p><p>　　4.3.1 組件分析</p><p>　　組件可以看作包與類對應的物理代碼模塊，邏輯上與包、類對應，它實際上是一個文件，可以有源代碼構件、二進制構件、可執(zhí)行構件。構件對外提供的可見操作和屬性稱為構件的界面。在U

64、ML中，組件圖描述了組件及組件之間的關系，表示了組件之間的組織和依賴關系。組件圖是用來為面向對象系統(tǒng)的物理方面建模的圖形之一。經過分析，員工工資管理子系統(tǒng)的組件圖如圖4.3所示。</p><p>　　圖4.3 員工工資管理子系統(tǒng)組件圖</p><p>　　4.3.2 配置分析</p><p>　　配置圖用來描述系統(tǒng)硬件的物理拓撲結構以及在此結構上執(zhí)行的軟件，即系統(tǒng)運

65、行時刻的結構?？梢燥@示計算機結點的拓撲結構和通信路徑，結點上執(zhí)行的軟構件，軟構件包含的邏輯單元等，特別對于分布式系統(tǒng)，配置圖可以清楚的描述系統(tǒng)中硬件設備的配置，通信以及在各硬件設備上各種軟構件和對象的配置。配置圖是描述任何基于計算機的應用系統(tǒng)的物理配置或邏輯配置的有力工具，人事管理子系統(tǒng)的配置圖如圖4.4所示。</p><p>　　圖4.4 人事管理子系統(tǒng)配置圖</p><p>　　5.課

66、程設計心得體會</p><p>　　我們進行了為期一周的課程設計。通過這次課程設計我們拓寬了知識面，鍛煉了能力，綜合素質也有了較大的提高。安排課設的基本目的，在于理論與實際的結合、人與人的溝通，進一步提高思想覺悟。預期是觀察、分析和解決實際問題的實際工作能力能力，以培養(yǎng)適應社會主義現代化建設需要的高素質復合型人才。作為整個學習體系的有機組成部分。課設的一個重要功能在于運用學習成果，檢驗學習成果。運用學習成果吧課堂

67、上學到的理論知識，嘗試性的運用到實際設計工作，并從理論的高度對設計工作的現代化提出一些有針對性的建議和設想。檢驗學習成果，看一看課堂學習與實際工作底有多大差距。并通過綜合分析找出學習中存在的不足，以便為完善學習計劃，改變學習內容與方法提供實踐依據。對我們信息管理與信息系統(tǒng)專業(yè)的學生來說，實際能力培養(yǎng)至關重要，而這種能力培養(yǎng)單靠課堂教學是遠遠不夠的，必須從課堂走向時間。這也是為畢業(yè)設計做預演，通過課程設計讓我們了解到自身與實際的差距，并在

68、以后學習期間及時補充相關知識，為求職與工作做好了充分的只是、能力準備。從而縮短了從學校走向社會心里轉型期。通過這次課程設計，我對軟件工程這門課有了更深的了解，知道了UML的重大意義</p><p><b>　　參考文獻</b></p><p>　　【1】張海藩，軟件工程，清華大學出版社，2009.7</p><p>　　【2】王欣，管理信息系統(tǒng)

69、，中國水利水電出版社，2004（2007重?。?lt;/p><p>　　【3】余文森，林旖宏．淺談面向對象技術席平師專學報，2002，</p><p>　　【4】薛春芳．基于面向對象技術的圖書館管理系統(tǒng)研究．武漢化工學院學</p><p><b>　　報，2006</b></p><p>　　【5】于重重．基于UML的網上審