醫(yī)院管理信息系統(tǒng)UML[共34頁]
《醫(yī)院管理信息系統(tǒng)UML[共34頁]》由會員分享,可在線閱讀,更多相關《醫(yī)院管理信息系統(tǒng)UML[共34頁](35頁珍藏版)》請在裝配圖網上搜索。
1、UML課程設計 目錄 1 引言 1 2可行性分析 2 2.1經濟可行性分析 2 2.2技術可行性分析 3 2.3法律可行性分析 3 2.4總結 3 3 需求分析 4 3.1客戶需求分析 4 3.1.1具體功能要求 4 3.1.2功能模塊圖 6 3.2用例建模 7 3.2.1確定系統(tǒng)范圍、系統(tǒng)邊界及執(zhí)行者 7 3.2.2確定用例 7 3.2.3分層繪制用例圖 8 4 系統(tǒng)分析 19 4.1對象靜態(tài)建模 19 4.2對象動態(tài)建模 20 4.2.1順序圖描述系統(tǒng)中的交互模型 20 4.2.1狀態(tài)圖 24 5 數據
2、庫設計 25 5.1實體及實體屬性描述 25 5.2 E-R圖設計 26 6 數據庫表結構設計 27 7 總結 32 參考文獻 33 1引言 1.1編寫目的 科技進步將人類帶到了信息時代,計算機已成為各行各業(yè)在業(yè)務處理與管理工作中必不可少的輔助工具,并對各行業(yè)的發(fā)展起到越來越大的推動作用。計算機信息管理技術的應用,除了能在相當大的程度上代替人工作業(yè),從而減少人員工作量,減輕工作負擔,減少工作中因人為原因而產生的錯誤從而避免不必要的損失外,更重要的是能建立準確暢通、簡便的信息流通渠道,為工作提供所需要的準確、即時的信息以幫助做出正確而及時的選擇與決
3、定,從而給采用這門技術的單位帶來了巨大的可見或不可見的利益與效益。 隨著信息時代來臨,信息處理的利器—計算機應用于醫(yī)院的日常管理為醫(yī)院的現代化帶來了從未有過的動力和機遇,為醫(yī)療衛(wèi)生領域的飛速發(fā)展提供了無限潛力。采用計算機管理信息系統(tǒng)已成為醫(yī)院管理科學化和現代化的重要標志,給醫(yī)院帶來了明顯的經濟效益和社會效益。為了加快醫(yī)院系統(tǒng)的信息化步伐,提高醫(yī)院的業(yè)務水平,建設和完善醫(yī)院信息系已變得十分必要。系統(tǒng)的建設將本著“以患者為中心”的原則,以方便患者、提高就診效率為目的,力爭為患者提供最滿意的服務,同時也將提高醫(yī)院的社會效益和經濟效益。與市場經濟的接軌的過程中,每個醫(yī)院都面臨著強化內部管理、樹立醫(yī)院
4、形象、上層次晉等級、進而提高社會效益和經濟效益的艱巨任務。在醫(yī)院管理過程中應用計算機系統(tǒng),可隨時進行經濟核算,展開成本效益分析,使醫(yī)院經營決策科學化;借據計算機數據處理嚴密可靠的特有機制,在改善醫(yī)院人、財、物管理,降低醫(yī)管人員工作強度,提高醫(yī)療工作質量,杜絕人情方、搭車藥、減輕病員負擔,創(chuàng)造醫(yī)院良好信譽等諸多方面,益康醫(yī)院管理信息系統(tǒng)都將成為您不可或缺的助手和工具。 1.2項目背景 目前面向對象的程序設計語言已廣為流行,但許多數據庫支持者仍傾向采用結構化設計方法來設計系統(tǒng)結構,使得對象的屬性及方法分散在設計中,很難將設計中的對象同現實中的對象完全對于起來,對系統(tǒng)的完全性、可靠性、開放性均
5、有影響。造成這種現象的原因大致有兩個設計人員習慣于結構化設計,難以立刻轉向面向對象設計。面向對象設計相對來說比較抽象,繁瑣,用它設計規(guī)模不是很大的系統(tǒng)得不償失。但無論如何,若想充分發(fā)揮面向對象編程的優(yōu)越性,就必須采用面向對象的設計方法。UML是軟件世界第一個統(tǒng)一建模語言,已成為國際軟件界廣泛承認的標準,應用領域非常廣泛。可由于多種類型軟件系統(tǒng)開發(fā)建模的各個階段,使用UML建模的優(yōu)越性在于數據類型豐富,可處理復雜數據結構,數據庫語言與程序環(huán)境一致,直接存取對象執(zhí)行效率高,適用于對象系統(tǒng)應用。 2可行性分析 2.1 經濟可行性分析 2.1.1 支出 (1
6、)基本建設投資 1) ADP設備1萬; 2) 數據通訊設備2千; 3) 安全與保密設備5千; 4) ADP操作系統(tǒng)的和應用的軟件5千; 5) 數據庫管理軟件5千。 (2)其他一次性支出 1)研究(需求的研究和設計的研究)3千; 2)開發(fā)計劃與測量基準的研究5千; 3)數據庫的建立5千; 4)ADP軟件的轉換5千; 5)檢查費用和技術管理性費用5千; 6)培訓費、旅差費以及開發(fā)安裝人員所需要的一次性支出2萬; (3)非一次性支出 該系統(tǒng)生命期內按月或按季或按年支出的用于運行和維護的費用,包括: 1)設備的租金和維護費用1千; 2)軟件的租金和
7、維護費用1千; 3)數據通訊方面的租金和維護費用1千; 4)人員的工資、獎金5千; 5)公用設施方面的開支2千; 6)保密安全方面的開支2千; 7)其他經常性的支出3千。 2.1.2 收益 (1)一次性收益 1)開支的縮減 改進了的系統(tǒng)的運行,資源要求減少,運行效率加快,數據進入、存貯和恢復技術增強,系統(tǒng)性能可監(jiān)控,處理集中化; 2)價值的增升 應用系統(tǒng)的使用價值的增升所引起,資源利用改進,管理和運行效率提高以及出錯率減少。 (2)非一次性收益 整個系統(tǒng)生命期內人員開支每月減少1.5萬,紙張等材料的開支均可避免。 (3)不可定量的收益 服務改
8、進,增強病案查詢的效率和質量; 由操作失誤引起的風險減少; 信息掌握情況加強; 增進我院的醫(yī)療服務質量,外界形象改善。 2.1.3 收益/投資比 整個系統(tǒng)生命期的收益/投資比值為80/43 2.1.4 投資回收周期 收益的累計數開始超過支出的累計數的時間在系統(tǒng)運行后第12個月。 2.2 技術可行性分析 2.2.1風險分析 風險是損失發(fā)生的不確定性,是對潛在的,為了可能發(fā)生損失的一種度量,如果確實發(fā)生了,則它的發(fā)生會對項目產生有害的或負面的影響。 醫(yī)院管理信息系統(tǒng)風險風險分析: l 客戶需求不明; l 進度要求緊,合同額有限 l 開發(fā)人員對測試工作不重視 l
9、供貨商、外包商的質量問題 l 開發(fā)人員的交流 2.2.2資源分析 軟件方面有UML建模,C#,Java等工具已足夠供開發(fā)使用,硬件方面設備齊全,工作環(huán)境都已具備,開發(fā)人員熟悉面向對象設計開發(fā)方法,有多年開發(fā)經驗。費用投入充足,院領導很支持。 2.2.3技術分析 目前面向對象技術發(fā)展已趨于成熟,開發(fā)人員對此技術已充分認識,有多年開發(fā)經驗。尤其UML建模語言已在各大院校廣泛普及。各種開發(fā)語言工具能充分開發(fā)現實系統(tǒng)。另外本院有自己的計算中心,有較強的技術力量支持。 2.3 法律可行性 《醫(yī)生工作站系統(tǒng)》必須符合國家、地方有關法律、法規(guī)、 規(guī)章制度的要求: 1.《中華人民共和國執(zhí)業(yè)醫(yī)
10、師法》 2.《醫(yī)療機構管理條例) 3.《醫(yī)療機構診療科目名錄》 4.《醫(yī)療機構基本標準》 5.《城鎮(zhèn)職工基本醫(yī)療保險用藥范圍管理暫行辦法》 6.《城鎮(zhèn)職工基本醫(yī)療保險—定點醫(yī)療機構管理暫行辦法》 2.4總結 綜上所述:無論在經濟,法律,技術方面都具有開發(fā)可行性。 3需求分析 3.1客戶需求分析 3.1.1具體功能要求 (1)掛號收費管理 ●門診掛號:錄入患者的基本信息,農合,醫(yī)保劃卡及掛單查詢 ●門診收費/退費:錄入患者的基本信息,農合,醫(yī)保劃卡及掛單查詢 ●門診處方:門診收費,票據的打印/藥品,檢查,治療的退費及查詢 (2)藥房管理
11、 ●發(fā)藥/退藥:(門診/住院)患者(發(fā)藥/退藥) ●藥品申領/申退:藥品申領/申退操作,以及統(tǒng)計和查詢功能 ●盤存/報損;藥房藥品數量和金額的盤存,藥品抱損操作原因,查詢 ●查詢系統(tǒng):藥房進藥,收費的統(tǒng)計,藥品的統(tǒng)計和報警藥品查詢 (3)住院管理 ●入院登記:登記住院患者的基本信息 ●住院預繳:住院費用的交納,收取。 ●出院結算:住院期間費用結算 ●查詢功能:這里可以查詢,入院/預繳/出院患者的詳細信息 (4)住院醫(yī)護 ●病員管理:病員收住/病房,床位設置,科內轉床,轉科申請,轉院出院 ●住院醫(yī)護:醫(yī)囑校對/執(zhí)行/撤消,套餐設置/退住院,檢查/治療項目費 ●查詢打?。翰?/p>
12、員收住/科內轉床/轉科申請/轉科接收/當前醫(yī)囑/醫(yī)囑執(zhí)行/轉院出院的查詢,擺藥單/催款通知書/收費清單打印 (5)藥庫管理 ●設置:設置藥品/藥庫字典/藥品調價/藥房平調/零記錄清理/盤存初始化操作,查詢 ●入庫:藥品入庫/記錄查詢/操作統(tǒng)計/藥品統(tǒng)計/供貨單位統(tǒng)計/入庫單打印 ●開單:調撥開單操作/開單記錄查詢/開單操作統(tǒng)計/開單藥品統(tǒng)計/打印 ●出庫:藥品出庫/藥房申領查詢/出庫記錄查詢/操作統(tǒng)計/出庫藥品統(tǒng)計/調撥方向報表/批量藥品出庫/出庫單打印 ●退庫:(院內/院外)退庫/退庫記錄查詢/退庫原因分析/退庫單打印 ●庫存核算:藥品數量盤存/藥品金額盤存/盤存記錄查詢(包含
13、操作和藥品統(tǒng)計) ●報損:藥品抱損/抱損記錄(含操作和藥品統(tǒng)計)/抱損原因/打印抱損單 ●退貨和采購:藥庫退貨/記錄查詢(含操作和藥品統(tǒng)計)/采購構思和計劃以及單據打印 ●查詢:藥庫明細表以及藥庫報警表 (6)決策查詢 ●業(yè)務查詢:門診掛號收費處方統(tǒng)計及明細 ●藥房查詢:藥房明細/門診和住院發(fā)藥記錄統(tǒng)計/進藥報損消耗盤存記錄統(tǒng)計 ●藥庫查詢:藥庫明細/出入庫退庫退貨報損統(tǒng)計明細/盤存記錄以及統(tǒng)計 ●痕跡查詢:門診改號退號記錄/門診撤費退費/住院退費/處方廢除等 ●分類考核:門診科室門診醫(yī)生住院醫(yī)師住院病區(qū)門診及住院項目/輔助科室 (7)財務管理 ●業(yè)務報表:門診掛號處方收
14、費退費的統(tǒng)計,住院預繳統(tǒng)計。發(fā)票使用統(tǒng)計等 ●藥庫核算:出入庫操作統(tǒng)計/報損退庫退貨統(tǒng)計/數量金額統(tǒng)計/藥品及報警名細 ●藥房核算:進發(fā)藥/門診退藥住院退藥統(tǒng)計/藥品消耗及報損統(tǒng)計/數量和金額盤存明細/藥品明細/報警明細/藥品收費記錄統(tǒng)計 ●收費統(tǒng)計:門診科室門診醫(yī)生住院醫(yī)師住院病區(qū)門診及住院項目/輔助科室/門診收費住院收費,門診病員住院病員以及住院結算 (8)系統(tǒng)維護 ●基本設置:系統(tǒng)信息設置(門診科室醫(yī)生)住院病區(qū)醫(yī)生,輔助科室設置用戶信息設置等 ●系統(tǒng)設置:系統(tǒng)連接/系統(tǒng)初始化/門診過期住院過期清理等 ●高級設置:門診發(fā)票設置,掛號單項/住院發(fā)票/預繳金單/門診處方可選功能
15、 3.1.2功能模塊圖 醫(yī)院管理信息系統(tǒng) 掛號/收費子系統(tǒng) 藥房管理子系統(tǒng) 系統(tǒng)設置子系統(tǒng) 住院管理子系統(tǒng) 財務管理子系統(tǒng) 醫(yī)護管理子系統(tǒng) 藥庫管理子系統(tǒng) 決策查詢子系統(tǒng) 門診掛號 收費統(tǒng)計 藥房核算 藥庫核算 業(yè)務報表 發(fā)藥/退藥 住院預繳 住院醫(yī)護 入院登記 病員管理 入庫 設置 藥房查詢 業(yè)務查詢 退庫 領藥出庫 查詢打印 開單 痕跡查詢 藥庫查詢 收費/退費 申領/申退 查詢 出院結算 庫存
16、核算 查詢 門診處方 核算/報損 分類考核 退貨/采購 報損 高級設置 系統(tǒng)設置 基本設置 3.2用例建模 3.2.1確定系統(tǒng)范圍、邊界和執(zhí)行者 由于系統(tǒng)較復雜這里只對“門診管理”、“藥房管理”、“藥庫管理”做詳細說明。 (1)門診子系統(tǒng)的業(yè)務范圍、邊界及執(zhí)行者 “門診子系統(tǒng)”只負責病人掛號、處方、收費和退費。與“財務管理子系統(tǒng)”和“藥房管理子系統(tǒng)”有系統(tǒng)邊界。有兩個系統(tǒng)執(zhí)行者,三個人執(zhí)行者。 u “
17、病人”執(zhí)行者只要是首先通過掛號繳費,領取掛號單,看病,接到醫(yī)生處方,到藥房拿藥。 u “工作人員”執(zhí)行者分為醫(yī)生和管理員,醫(yī)生負責看病開處方,并把處方傳到財務管理子系統(tǒng),管理員主要負責收取掛號費,藥費,退費等工作。 u “院長”執(zhí)行者主要通過查詢功能來查看每天業(yè)務情況。 u “財務管理系統(tǒng)”通過接收醫(yī)生開的處方,來進行劃價收費?;虿∪送怂幫速M處理等。 u “藥房管理子系統(tǒng)”主要通過財務系統(tǒng)傳來的已收費處方進行核對拿藥。 (2)藥房管理子系統(tǒng)的業(yè)務范圍、邊界及執(zhí)行者 “藥房管理子系統(tǒng)”負責根據門診子系統(tǒng)藥品申請/申退信息,及“財務管理子系統(tǒng)”的收據進行發(fā)藥/退藥處理,核算每天盤存。與
18、“門診管理子系統(tǒng)”和“藥庫管理子系統(tǒng)”有系統(tǒng)邊界。有兩個系統(tǒng)執(zhí)行者“門診管理子系統(tǒng)”和“藥庫管理子系統(tǒng)”,兩個人執(zhí)行者“藥房管理員”和“病人”。 u “門診管理子系統(tǒng)”主要通過開處方來完成藥品申請和申退。 u “藥庫管理子系統(tǒng)”主要通過藥品發(fā)放及盤存核算監(jiān)控藥品庫存量,當庫存量小于預警庫存量時及時組織采購。 u “藥房管理員”負責藥品核對藥品申請/申退信息及收據發(fā)藥/退藥。并進行盤存/報損把數據傳給“藥庫管理子系統(tǒng)”。 (3)藥庫管理子系統(tǒng)的業(yè)務范圍、邊界及執(zhí)行者 “藥庫管理子系統(tǒng)”主要負責藥品類別設置及藥品歸類,采購管理,入庫管理,出庫管理,報損,庫存核算等業(yè)務。與“財務管理子系統(tǒng)
19、”和“藥房管理系統(tǒng)”有系統(tǒng)邊界。有兩系統(tǒng)執(zhí)行者“財務管理子系統(tǒng)”和“藥房管理子系統(tǒng)”,一個人執(zhí)行者“藥庫管理者”。 u “藥房管理子系統(tǒng)”把每天庫存報損及盤存數據傳給“藥庫管理子系統(tǒng)”,“藥庫管理子系統(tǒng)”通過這些數據檢查庫存量,及時進行采購。 u “財務管理子系統(tǒng)”通過接受“藥庫子系統(tǒng)”傳來的庫存核算進行流動資產管理,根據采購入庫單發(fā)放資金等。 u “業(yè)務管理員”對“庫存管理子系統(tǒng)”各個功能進行操作。 3.2.2確定用例 (1)“門診管理子系統(tǒng)”中的用例 l 門診掛號 l 生成處方 l 收費/退費 (2)“藥房管理子系統(tǒng)”中的用例 l 藥品申請/申退 l 發(fā)藥/退藥處理
20、 l 盤存/報損處理 (3)“藥庫管理子系統(tǒng)”中的用例 l 基礎設置 l 采購管理 l 入庫管理 l 出庫管理 l 盤存/報損 l 庫存核算 l 退貨管理 l 查詢 3.2.3繪制分層用例圖 1)第一層用例圖 2)第二層用例圖 (1)門診子系統(tǒng)用例圖 (2)藥房管理用例圖 (3)住院管理用例圖 (4)住院護理用例圖 (5)藥房管理用例圖 (6)決策查詢用例圖 (7)財務管理用例圖
21、 (8)系統(tǒng)維護用例圖 3)三層用例圖 (1)掛號管理用例圖 (2)收費退費管理用例圖 (3)生成處方用例圖 (4)病員管理用例圖 (5)住院醫(yī)護用例圖 (6)制定采購計劃 (7)合同管理 3.3活動圖 4系統(tǒng)分析 根據建立的醫(yī)護需求模型,在系統(tǒng)分析階段要進一步確立三個模型:對象靜態(tài)圖模型、對象動態(tài)模型,系統(tǒng)功能模型。 4.
22、1對象類靜態(tài)模型 對象靜態(tài)結構模型描述了系統(tǒng)的靜態(tài)結構,包括構成系統(tǒng)的類和對象、它們的屬性和操作以及這些對象類之間的聯系。對象類靜態(tài)結構模型是系統(tǒng)開發(fā)模型的核心模型,實質上是定義系統(tǒng)“對誰做”的問題。 醫(yī)院管理信息系統(tǒng)類及類之間的關系圖如下: 4.2對象動態(tài)模型 對象動態(tài)模型描述了系統(tǒng)的動態(tài)行為,它們指明了系統(tǒng)如何響應外部事件或激勵,涉及系統(tǒng)中對象的執(zhí)行順序和狀態(tài)變化,側重于系統(tǒng)控制邏輯的描述,實質上是解決系統(tǒng)中的對象“何時做”的問題。對象動態(tài)結構模型包括:對象交互模型和對象狀態(tài)模型。其中對象交互模型用順序圖和合作圖描述,對象狀態(tài)模型用狀態(tài)圖和活動圖描述。 4.2.1順序圖描述醫(yī)院管
23、理信息系統(tǒng)中的交換模型 (1)掛號抓藥順序圖 (2) 住院治療順序圖 (3) 藥庫管理順序圖 (4) 制定采購訂單順序圖 (5)到貨入庫順序圖 (6)付款處理順序圖 4.2.2狀態(tài)圖 5 數據庫設計 5.1實體及實體屬性描述 實體-聯系圖(Entity-Relation Diagram)用來建立數據模型,在數據庫系統(tǒng)概論中屬于概念設計階段,形成一個獨
24、立于機器,獨立于DBMS的ER圖模型。通常將它簡稱為ER圖,相應地可把用ER圖描繪的數據模型稱為ER模型。 ER圖提供了表示實體(即數據對象)、屬性和聯系的方法,用來描述現實世界的概念模型。 (1)病人(編號 姓名 性別 年齡 病癥描述 病史記錄) (2)醫(yī)生(編號 姓名 性別 出生年月 職稱 職務 權限 密碼) (3)護士(編號 姓名 性別 出生年月 級別 職務 權限 密碼) (4)管理員(編號 姓名 性別 出生年月 學歷 職責 權限 密碼) (5)病房(編號 名稱 床位數 備注) (6)病床(編號 價格 備注) (7)藥品(編號 名稱 價格 作用說明 類別 庫存警戒線
25、 備注) (8)藥房(編號 名稱 備注) (9)藥庫(編號 名稱 備注) (10)科室(編號 名稱 職責 備注) 5.2實體及實體間的關系E-R圖 病人 醫(yī)生 科室 處方 藥品 管理員 床位 病房 藥庫 藥房 護士 開方 看病 包含 分屬 護理 接受 管理 管理 管理 管理 住院 存放 包含 n 1 n m n m n 1 1 m n n m m m n m 1 1 1 n 1
26、 n 1 1 1 6數據庫表結構設計 (1)病人數據庫表 表6.1 Patient Table 列名 數據類型 長度 可否為空 說明 聲明 P-num Nchar 20 NOT NULL 編號 主鍵 P-name Varchar 50 NULL 姓名 P-sex Char 4 NULL 性別 P-birthday Date 20 NULL 年齡 Disease
27、 Varchar 50 NULL 病癥 Case history Varchar 100 NULL 病史記錄 Remarks Varchar 100 NULL 備注 (2)醫(yī)生數據庫表 表6.2 Doctor Table 列名 數據類型 長度 可否為空 說明 聲明 D-num Nchar 20 NOT NULL 編號 主鍵 D-name Varchar 50 NULL 姓名 D-sex Char 4 NULL 性別 Post Varchar 10 NULL 職稱 D-bir
28、thday Date 20 NULL 出生年月 D-duties Varchar 50 NULL 職務 D-authority Varchar 50 NULL 權限 D-code Varchar 20 NULL 密碼 (3)護士數據庫表 表6.3 Nurse Table 列名 數據類型 長度 可否為空 說明 聲明 N-num Nchar 20 NOT NULL 編號 主鍵 N-name Varchar 50 NULL 姓名 N-sex Char 4 NULL 性別 N-
29、birthday Date 20 NULL 出生年月 N-grade Varchar 20 NULL 級別 N-duities Varchar 50 NULL 職務 N-authority Varchar 50 NULL 權限 N-code Varchar 20 NULL 密碼 (4)管理員數據表 表6.4 Manager Table 列名 數據類型 長度 可否為空 說明 聲明 Manager-num Nchar 20 NOT NULL 管理員編號 主鍵 Ma
30、nager-name Verchar 50 NULL 姓名 Manager-sex Char 4 NULL 性別 Manager-birthday Date 20 NULL 出生年月 Manager-degree Nchar 20 NULL 學歷 Manager-duties Varchar 50 NULL 職責 Manager-code Varchar 20 NOT NULL 密碼 Manager-authority Varchar 50 NOT NULL 權限 (5)病房數據庫表 表6.
31、5 Sickroom Table 列名 數據類型 長度 可否為空 說明 聲明 Sickroom-num Nchar 20 NOT NULL 編號 主鍵 Sickroom-name Varchar 50 NULL 名稱 Sickroom-capacity Varchar 50 NULL 床位數 Remarks Varchar 100 NULL 備注 (6)床位數據庫表 表6.6 Bad Table 列名 數據類型 長度 可否為空 說明 聲明 Bad-num Nchar 20 NOT NU
32、LL 編號 主鍵 Sickroom-num Nchar 20 NULL 病房編號 外鍵 Remarks Varchar 50 NULL 備注 表6.7 Medicines Table (7)藥品數據庫表 列名 數據類型 長度 可否為空 說明 聲明 Medicines-num Nchar 20 NOT NULL 編號 主鍵 Medicines-name Varchar 50 NULL 藥品名稱 Storeroom-num Nchar 20 NOT NULL 藥房編號 外鍵 Medicines-pr
33、ice Float 20 NULL 價格 Medicines-kinds Varchar 50 NOT NULL 類別 外鍵 Illustrate Varchar 100 NULL 作用說明 Remarks Varchar 100 NULL 備注 表6.8 Storeroom Table (8)藥房數據庫表 列名 數據類型 長度 可否為空 說明 聲明 Storeroom-num Nchar 20 NOT NULL 藥房編號 主鍵 Storehouse-num Nchar 20 NOT NU
34、LL 藥庫編號 外鍵 Storeroom-name Varchar 50 NULL 藥庫名稱 Medicines-kinds Varchar 50 NULL 藥品類別 Remarks Varchar 100 NULL 備注 (9)藥庫數據庫表 表6.9 Storehouse Table 列名 數據類型 長度 可否為空 說明 聲明 Storehouse-num Nchar 20 NOT NULL 藥庫編號 主鍵 Storehouse-name Varchar 50 NULL 藥庫名稱 Secu
35、rity line Float 20 NULL 警戒線 Remarks Varchar 50 NULL 備注 (10)藥品類別 表6.10 MKind Table 列名 數據類型 長度 可否為空 說明 聲明 MKind-num Nchar 20 NOT NULL 類別編號 主鍵 MKind-name Verchar 50 NOT NULL 類別名稱 Remarks Varchar 100 NULL 備注 (11)病例數據庫表 表6.11 Case Table 列名 數據類型 長度
36、可否為空 說明 聲明 Case-num Nchar 20 NOT NULL 病例編號 主鍵 Case-name Verchar 50 NULL 病例名稱 Case-describe Varchar 100 NOT NULL 描述 Casekind-num Nchar 20 NOT NULL 類型編號 外鍵 Treatment Varchar 50 NULL 治療方法 Case-total Varchar 20 NULL 病例統(tǒng)計 Remarks Varchar 100 NULL 備注
37、 (12)病例種類數據庫表 表6.12 Casekind Table 列名 數據類型 長度 可否為空 說明 聲明 Casekind-num Nchar 20 NOT NULL 病例編號 主鍵 Casekind-name Verchar 50 NOT NULL 病例名稱 Casekind-describe Varchar 100 NOT NULL 描述 Remarks Varchar 100 NULL 備注 (13)科室數據庫表 表6.13 Administrative Table 列名
38、 數據類型 長度 可否為空 說明 聲明 Administrative-num Nchar 20 NOT NULL 科室編號 主鍵 Administrative-name Verchar 50 NULL 科室名稱 Administrative-duties Nchar 20 NOT NULL 職責 Remarks Varchar 100 NULL 備注 (14)處方數據庫表 表6.14 Prescription Table 列名 數據類型 長度 可否為空 說明 聲明 Prescription-num
39、 Nchar 20 NOT NULL 處方編號 主鍵 Prescription-name Varchar 50 NULL 處方名稱 D-num Nchar 20 NOT NULL 醫(yī)生編號 外鍵 P-num Nchar 20 NOT NULL 病人編號 外鍵 Prescription Varchar 150 NULL 處方內容 Illustrate Varchar 100 NULL 說明 Remarks Varchar 100 NULL 備注 (15)住院記錄表 表6.15 Record Table
40、 列名 數據類型 長度 可否為空 說明 聲明 Record-num Nchar 20 NOT NULL 記錄編號 主鍵 P-num Nchar 20 NOT NULL 病人編號 主鍵 Enter-date Date 20 NOT NULL 入院日期 Eksit-date Date 20 NOT NULL 出院日期 Total-date Nchar 50 NOT NULL 總計天數 Manager-num Nchar 20 NUT NULL 辦理員編號 外鍵 Remarks Verchar 10
41、0 NULL 備注 (16)掛號類型統(tǒng)計表 表6.16 Registerkind Table 列名 數據類型 長度 可否為空 說明 聲明 Registerkind-num Nchar 20 NOT NULL 掛號種類編號 主鍵 Register-cost Verchar 50 NOT NULL 掛號費用 Register-total Varchar 100 NOT NULL 掛號量總計 Register-Date Date 20 NOT NULL 掛號日期 (17)醫(yī)生分屬科室關系表 表6
42、.17 A-D Table 列名 數據類型 長度 可否為空 說明 聲明 Administrative-num Nchar 20 NOT NULL 病例編號 主鍵 D-num Verchar 50 NULL 病例名稱 主鍵 D-total Varchar 100 NOT NULL 描述 (18)護士醫(yī)護病人關系表 表6.18 N-P Table 列名 數據類型 長度 可否為空 說明 聲明 N-num Nchar 20 NOT NULL 護士編號 主鍵 P-num Nchar 50 NOT
43、 NULL 病人名稱 主鍵 Record Varchar 20 NOT NULL 醫(yī)護記錄 Remarks Varchar 100 NULL 備注 7總結 科技進步將人類帶到了信息時代,計算機已成為各個行業(yè)在業(yè)務處理與管理工作中必不可少的輔助工具,并對各行業(yè)的發(fā)展起到越來越大的推動作用。醫(yī)療衛(wèi)生是圍繞在我們生活中的一個非常重要的部分,與我們的生活息息相關。建設一個適合、實用的醫(yī)院管理信息系統(tǒng),對醫(yī)院經濟效益、社會效益、管理水平及至醫(yī)療水平的提高都大有裨益。也正是由于這個原因,我決定選擇醫(yī)院門管理
44、信息系統(tǒng)這個題目進行項目開發(fā)。 在確定題目后,首先我進行了大量的信息收集工作,包括網上查詢、學校圖書館查詢,甚至跑遍了學校周圍的所有書店。根據搜索的資料及現實生活中的經驗開始可行性分析,需求分析,系統(tǒng)分析。其中需求分析是最重要的,只有通過需求分析才能確定系統(tǒng)要實現的功能,最終通過UML建模語言中的用例圖來描述,用活動圖來進行復雜用例的詳細描述。接著對系統(tǒng)進行靜態(tài)結構建模通過對象類圖描述,確定類及類之間的關系是最主要的,設計中的對象與現實中的對象聯系起來,并不是件容易的事。如果對象確定不好會給系統(tǒng)設計實現帶來很大的麻煩。而它們之間的關系并不是簡單連接就能表述的,它們之間的關系有關聯,繼承,聚合
45、,依賴和細化。由此提現了UML建模語言強大的語言表達能力。建立系統(tǒng)動態(tài)模型,動態(tài)模型分為動態(tài)交互模型、狀態(tài)模型,其中交互模型主要通過順序圖和合作圖來描述,狀態(tài)模型主要通過狀態(tài)圖和活動圖來描述。這些中及存在區(qū)別,也存在著聯系,區(qū)別在于它們描述的側重點不同,能從不同角度對系統(tǒng)中的動作狀態(tài)進行描述,聯系在于它們都是以體系結構為中心,以用例為驅動,許多模型元素都相同,可以互相轉化。在設計過程中最大的難題在于對象類之間的動作狀態(tài)的確定,以及引起轉化遷移事件的確定,只有對系統(tǒng)有深入的分析之后才能確定。 通過這次UML建模課程設計,讓我對UML建模語言有了更深入的了解,不只是停留在表面知識上,而是真正成為
46、描述系統(tǒng)模型的語言來使用。在設計過程中充分體現了UML以系統(tǒng)體系結構為中心,以用例為驅動,以風險控制和質量管理為目標,以漸增迭代為開發(fā)方式的面向對象獨有的語言特色。同時我體會到了軟件開發(fā)需要細心和耐心,不求最好只求更好。培養(yǎng)了我對完美不懈的追求精神,嚴謹做事的態(tài)度。不一定每一個人都要成為專業(yè)軟件的開發(fā)人員,但做任何事卻要具備開發(fā)人員思維和態(tài)度。對我以后的人生道路有很好的引導啟發(fā)作用。 參考文獻 [1]刁成嘉,UML系統(tǒng)建模與分析設計,北京:機械工業(yè)出版社,2007 [2]刁成嘉,UML系統(tǒng)建模與分析設計課程設計,北京:機械工業(yè)出版社,2008 [3]J.L. Whitten,L.D. Bentley,肖剛,孫慧譯,《系統(tǒng)分析與設計方法》,北京:機械工業(yè)出版社,2007 - 35 -
- 溫馨提示:
1: 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
2: 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯系上傳者。文件的所有權益歸上傳用戶所有。
3.本站RAR壓縮包中若帶圖紙,網頁內容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
4. 未經權益所有人同意不得將文件中的內容挪作商業(yè)或盈利用途。
5. 裝配圖網僅提供信息存儲空間,僅對用戶上傳內容的表現方式做保護處理,對用戶上傳分享的文檔內容本身不做任何修改或編輯,并不能對任何下載內容負責。
6. 下載文件中如有侵權或不適當內容,請與我們聯系,我們立即糾正。
7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。