ABSTRACTI 論文題目：現代小區智能化管理信息系統設計與實現工程領域軟件工程指導教師陳小平副教授作者姓名莊惠琴學號200992250411

分類號密級UDC注1學位論文現代小區智能化管理信息系統設計與實現（題名和副題名）莊惠琴（作者姓名）指導教師姓名陳小平高工電子科技大學成都 張文生高工汕頭市測試技術研究院汕頭（職務、職稱、學位、單位名稱及地址）申請專業學位級別碩士專業學位類別工程碩士工程領域名稱軟件工程提交論文日期2011.10論文答辯日期2011.11學位授予單位和日期電子科技大學答辯委員會主席評閱人年月日注1：注明《國際十進分類法UDC》的類號獨創性聲明本人聲明所呈交的學位論文是本人在導師指導下進行的研究工作及取得的研究成果。據我所知，除了文中特別加以標注和致謝的地方外，論文中不包含其他人已經發表或撰寫過的研究成果，也不包含為獲得電子科技大學或其它教育機構的學位或證書而使用過的材料。與我一同工作的同志對本研究所做的任何貢獻均已在論文中作了明確的說明并表示謝意。簽名：日期：年月日關于論文使用授權的說明本學位論文作者完全了解電子科技大學有關保留、使用學位論文的規定，有權保留并向國家有關部門或機構送交論文的復印件和磁盤，允許論文被查閱和借閱。本人授權電子科技大學可以將學位論文的全部或部分內容編入有關數據庫進行檢索，可以采用影印、縮印或掃描等復制手段保存、匯編學位論文。（保密的學位論文在解密后應遵守此規定）簽名：導師簽名：日期：年月日摘要摘要本文論述了物業管理信息系統的開發過程。分析了我國小區物業管理信息系統的發展和使用現狀，指出了現階段存在的問題，闡述了物業管理信息化的必要性。從業務需求出發，建立了小區物業管理系統的功能模型和實現方案。經過實際的需求分析，結合管理信息系統開發的概念、結構及系統開發的基本原理和方法，設計開發了小區物業管理系統。本文采用Rational統一過程(RUP)為軟件開發方法，以統一建模語言(UML)為分析設計描述語言，以.NET為技術平臺架構，對中實物業管理信息系統進行了需求分析和系統設計，具體分析設計了小區信息管理、財務收費、維修管理、投訴管理、車位管理和業主網上信息查詢等功能模塊。本文分析了系統開發的背景和管理信息系統的發展現狀，簡要描述了系統需要解決的主要問題;概要描述了系統的整體情況;對系統的需求分析和架構設計進行了詳細描述;并對部分有代表性的實例的詳細設計和實現進行了描述。關鍵詞:管理信息系統;統一建模語言UML;.NET;SQLServer2005ABSTRACTIIABSTRACTThispaperhaselaboratedthedevelopmentofthecommunitypropertymanagementinformationsystemperformanceanalysisofChina'spropertymanagementinformationsystemdevelopmentanduseofthestatusquo,pointingouttheproblemsatthisstageonthepropertymanagementoftheneedforinformation.Embarkedfromtheservicedemand,ithasestablishedthepropertymanagementsystemfunctionmodelandtherealizationplan.Aftertheactualdemandanalysis,combinedwiththemanagementofinformationsystemdevelopmentconcept,structureandsystemstodevelopthebasicprinciplesandmethods,designanddevelopmentofthecommunitypropertymanagementsystem.Itisnotedthat,throughthewholeprojectdesigncycleincludingsystemrequirementanalysesandsystemmodeling,RationalUnifiedProcessorRUPisusedasdevelopmenttooltoanalyzeandconfiguresoftwaredevelopmentprocess.TheUnifiedModelingLanguageorUMLisusedasstandardlanguageforspecifying,visualizing,constructing,anddocumentingtheartifactsofsoftwaresystems;.NETisusedasaprogramminganddevelopmentplatform.Thispaperwillpresentanalysesanddesignforcommunityinformationmanagement,financechargesmanagement,repairmanagement,complaintsmanagement,parkingmanagementandownersofonlineinformationandsoon.Basedonthedetailedanalysisfortheprojectbackgroundandcurrentstatusforenterprisesinternationally,thispaperpresentsthemajorissuemustbesolvedandpresentsthewholesystemdescriptions.Furthermore,itgivesthedetailedrequirementanalysesandsystemarchitecture.Toillustrate,sometopicalsamplesareusedtoshowhowsystemmodulesaredesignedandimplemented.Keywords:ManagementInformationSystemsUnifiedModelingLanguage(UML);.NET;SQLServer2005目錄III目錄第一章緒論........11.1系統開發背景.............................................11.2國內外研究現狀........31.3研究內容............51.4論文結構安排........6第二章系統需求分析.82.1需求獲取...82.2需求分析.................................................102.2.1業務模型...........................................122.2.2功能性需求.........................................152.2.3非功能性需求.......................................第三章系統架構設計..............................233.1系統功能架構...................................233.2系統數據架構.............................................273.3系統層次架構.............................................283.4系統技術架構.............................................283.4.1系統MVC架構.......................................293.4.2系統持久層架構.....................................303.4.3系統通訊架構.......................................31第四章系統詳細設計..............................324.1概述.....................................................324.2系統功能模塊設計.........................................334.2.1用戶權限管理模塊設計................................334.2.2系統設置模塊設計....................................344.2.3小區信息管理模塊設計................................354.2.4財務收費模塊設計....................................364.2.5維修管理模塊設計....................................394.2.6投訴管理模塊設計....................................41第一章緒論IV4.2.7車位管理模塊設計...................................424.2.8業主網上信息查詢模塊設計...........................444.3數據庫設計...............................................454.3.1系統概念模型.......................................454.3.2系統面向對象模型...................................464.3.3系統數據庫模型.....................................47第五章系統實現....................................555.1用戶權限管理.............................................555.2系統設置.................................................565.3小區信息管理.............................................575.4財務收費.................................................585.5維修管理.................................................585.6投訴管理.................................................625.7車位管理.................................................635.8業主網上信息查詢.........................................63第六章總結與展望.................................666.1論文的特點...............................................666.2系統展望.................................................66參考文獻.........................................................67致謝............................................................691第一章緒論1.1系統開發背景從1981年3月10日我國大陸第一家物業管理公司深圳市物業管理公司成立起，我國對物業管理新體制的探索和實踐至今已走過了20多年的風雨歷程。21世紀，中國物業管理將會進入一個競爭激烈、管理完善的新階段，這也將是其發展、完善和成熟的重要時期。現代化物業管理系統就是運用綜合的現代化管理科學及先進的技術，把國家對物業管理的各項規定與要求物化在各種設備中，并由這些設備與管理人員構成某種工作目標和服務的人機信息處理系統，它的核心是一批高技術、高素質的系統管理員、軟件工程師和工程技術人員。管理者的責任就是充分利用小區的高科技設施和現代化管理系統，為用戶創造出更加方便、親切、安全、和諧的居住環境。伴隨著我國城市住宅小區建設的蓬勃發展，小區物業管理已形成規模，其效益也越來越明顯。在經濟效益對地方政府而言，主要體現為:減少了大量的財政補貼，對住宅區開發企業而言，能提高物業市場競爭力，使開發企業的房產暢銷，加速資金周轉。同時，完善的小區物業管理能為開發商樹立良好的企業形象，吸引更多的房地產交易商和消費者。在環境效益上，住宅區內的環境和布局、治安等與整個建設風貌融為一體，提高了房地產業的綜合效益。物業管理作為一個新興行業，逐漸成為一個涉及社會方方面面，與千家萬戶息息相關的朝陽產業，目前正處于物業管理成長過程的關鍵階段。隨著住房制度改革的不斷深化，住宅產權多元化格局已經形成，物業管理作為城市管理的一種新形式和市場經濟條件下的新興服務產業，經歷了從無到有、從小到大的發展過程，形成了多類別、多層次、多形式的物業管理局面，初步確立了社會化、專業化、市場化、經營性的物業管理新體制。我國加入WTO后，物業管理標準化、科學化、規范化、國際化已是物業公司迫在眉睫的首要任務。通過提高日常物業管理工作中的科技含量，促進當前管理方式、管理手段的現代化，使物業管理能夠適應現代科技和現代建筑技術的發展潮流，保持物業管理的高水平。隨著市場經濟的發展和人們生活水平的提高，住宅小區已經成為人們安家置業的首選，幾十萬到幾百萬的小區住宅比比皆是。人們花的錢越多，不但對住宅電子科技大學碩士學位論文2的本身的美觀、質量要求越來越高，同時對物業小區的服務和管理也要求很高，諸如對小區的維修維護，甚至對各項投訴都要求小區管理者做的好，做的完善。這樣要求小區管理者對小區物業管理進行宏觀的和微觀的細致管理，其中最好的辦法是用計算機操作的小區物業管理系統來實現對小區物業的管理，這就為我們設計小區物業管理系統提供了市場需要。物業管理系統在現代社會是最熱門的行業，是最關切老百姓實際生活的設計，各種人性化的配置，使管理者和業主對住宅小區中的事物能更方便、更快捷、更滿意的得到答復。伴隨著小區的規模不斷擴大和住戶的不斷增多，像小區中的汽車，小區附帶設施，小區的各項維修、投訴等都將越來越復雜，工作量也將越來越大。但一直以來人們使用傳統人工的方式管理各種數據，這種管理方式存在著許多缺點，比如效率低、保密性差，另外時間一長，將產生大量的文件和數據，這對于查找、更新和維護都帶來了不少的困難。對于整個物業管理行業來講，僅靠簡單的單向、手工管理己經不能適應物業管理需求水平的提高，必須走規模化，網絡化的計算機綜合管理道路。在此前提下，我國各地涌現出了一些運用現代的計算機、控制與通信技術的智能化住宅小區。但是許多智能化住宅小區都存在搭好了平臺卻沒有智能化的軟件在上面運行的情況，或者說缺少現代化的管理手段。智能化住宅小區開始建設的同時應該遵循“管理是保障”的原則，沒有高質量的住宅小區智能化管理，就不可能充分發揮住宅小區智能化的功能效果。科學高效的管理是智能化的真正內涵，簡單的硬件拼湊對于智能小區的實際應用是缺少實際意義的。為此，作為智能化住宅小區的實際管理者—物業管理公司應該運用現代化的計算機管理手段，使物業的硬件管理結合軟件管理，為物業管理走向現代化、制度化與規范化創造條件。管理信息系統(ManagementInformationSystems，簡稱MIS)在現代社會已深入到各行各業，由于計算機技術的迅速發展和普及，MIS事實上已成為計算機MISoMIS是一個不斷發展的新型學科，MIS的定義隨著計算機技術和通訊技術的進步也在不斷更新，在現階段普遍認為MIS是由人和計算機設備或其他信息處理手段組成并用于管理信息的系統。隨著科學技術的迅速發展，管理信息系統也深入到了物業行業，其強大的功能已為人們深刻認識。作為計算機應用的一部分，使用計算機對企業單位的各項信息進行管理，具有手工管理所無法比擬的優點。例如:檢索迅速、查找方便、可靠性高、存儲量大、保密性好、壽命長、成本低等。第一章緒論3這些優點能夠極大地提高工作的效率，也是企業的科學化、正規化管理與世界接軌的重要條件。物業管理是一個復雜的系統工程，其管理范圍大、內容廣，若采取舊的房地產管理方式，不僅耗費大量的人力物力，而且管理效率十分低下。隨著科學技術的迅猛發展，在物業管理中充分應用計算機管理信息系統及現代化的管理方式，尤其是一些高科技技術，讓物業管理中的許多日常工作實現自動化。隨著計算機運用的擴展與聯網，物業公司的電腦系統可以根據工作的需要，與銀行金融機構、自來水公司、供電公司等有關部門聯網，這給物業管理與住房的管理交費都帶來很大的方便。借助自動化管理，不僅可以引進嶄新的服務，或加強現有的服務，提高管理效率，達到降低成本的效果，向業主提供更高水準或更優質的服務，而且能夠提高物業管理的收入水平，達到物業增值的效果。因此，開發這樣一套小區物業管理系統軟件成為很有必要的事情，是企業降低管理成本、提高管理效率的關鍵和原動力。1.2國內外研究現狀目前，我國小區信息化管理的進程比較的緩慢，跟國外的小區相比管理依然落后。我國是進入80年代以后，小區的概念重新獲得確認并逐步被官方文獻所采用的。90年代初，政府主管部門正式提出了小區建設的思路。這就提出了社區管理體制改革的緊迫任務。國內部分小區管理軟件都已使用，但不能實現智能一體化，信息難以共享。而很多的小區還沒有實現信息化的管理，人工的管理使得效率低下，問題不斷;但在過去的十年里，中國城市小區發展取得了長足的進步。社會學家提出了一套小區發展指標體系，其中人口與環境兩項，基本上屬于國家或整個城市的施政范圍，在小區一級很難大有作為;居住質量取決于居住小區的設計和小區物業管理水平，現在整片開發新區中規模最大的或許居民人數也會多至數萬，小區文化體育也可以放在廣義的社區服務項目中;目前，國家也逐漸加大了對小區物業規范化管理的力度。隨著我國經濟發展和城市開發，物業管理己形成規模，其效益也越來越明顯。但是，目前在物業管理的實踐過程中還存在著如下問題:(I)物業管理架構不完善;(2)配套設施運作不理想;(3)維修保養不得力;(4)物業管理經費難以為繼;電子科技大學碩士學位論文4(5)物業管理法制不健全;(6)物業管理公司與社會相關方面關系不順;(7)物業管理不到位;(g)地區間發展不平衡。與此同時，傳統物業管理系統的構建和使用中，存在如下問題:(1)傳統物業管理業務處理繁瑣，手工工作量大，不適合網絡上的處理;(2)管理的內容缺乏標準化，管理手段缺乏規范化，導致信息不能共享，經營決策困難。(3)信息的發布不及時，準確率低，物業管理公司和業主缺乏有效的溝通。目前，物業管理已成為一門科學，其內涵己遠遠超出了傳統房產管理的范疇，發展成為集多種手段對物業進行綜合管理，并對相關物業資料進行保管、歸類、匯總、整理分析等于一體的綜合學科。在此前提下，我國各地涌現出了一些運用現代計算機、控制與通信技術的智能化住宅小區。然而許多智能化住宅小區都存在搭好了硬件平臺，卻沒有優秀的軟件在上面運行的情況，或者說缺少現代化的管理手段。有些物業管理單位僅僅將計算機用于WORD,EXCEL等OFFICE文檔的處理，可以說這是計算機資源的浪費。科學高效的管理是現代化的真正內涵，簡單的硬件拼湊對于現代化小區的實際應用是缺少實際意義的。物業管理系統，屬于管理信息系統的一種。管理信息系統(ManagementInformationSystems，簡稱MIS)在現代社會己深入到各行各業，由于計算機技術的迅速發展和普及，MIS事實上已成為計算機MISaMIS是一個不斷發展的新型學科，MIS的定義隨著計算機技術和通訊技術的進步也在不斷更新，在現階段普遍認為MIS是由人和計算機設備或其他信息處理手段組成并用于管理信息的系統，主要有以下三個特點:第一是MIS的對象是信息。信息是經過加工的數據，信息是對決策者有價值的數據。信息的主要特征是來源分散，數量龐大。信息來源于生產第一線，來源于社會環境，來源于市場，來源于行政管理等部門。信息具有時間性，信息的加工方式有多種形式。第二是系統是由相互聯系、相互作用的若干要素按一定的法則組成并具有一定功能的整體。系統有兩個以上要素，各要素和整體之間，整體和環境之間存在一定的有機聯系。系統由輸入、處理、輸出、反饋、控制五個基本要素組成。第三是管理信息由信息的采集、信息的傳遞、信息的儲存、信息的加工、信息的維護和信息的使用五個方面組成。任何地方只要有管理就必然有信息，如果形成系統就形成MIS。計算機設備使MIS更有效，尤其是現代社會，MIS已和計算機設備不可分離，因此一般來說MIS就是計算機MISoMIS包括計算機、網絡第一章緒論5通訊設備等硬件成份，包括操作系統、應用軟件包等軟件成份。并隨著計算機技術和通訊技術的迅速發展還會出現更多的內容。管理信息系統的主流技術經歷了三個發展時期:界面技術從DOS字符界面，到Windows圖形界面(或圖形用戶界面GUI)，直至今天的Browser瀏覽器界面。最新瀏覽器界面，不僅直觀和易于使用，更主要的是基于瀏覽器平臺的任何應用軟件其界面風格一致，用戶對操作培訓的要求大為下降，軟件可操作性增強。C/S結構，即Client/Server(客戶機/服務器)結構，是大家熟知的軟件系統體系結構，通過將任務合理分配到Client端和Server端，降低了系統的通訊開銷，可以充分利用兩端硬件環境的優勢。B/S結構，即Browser/Server(瀏覽器/服務器)結構，是隨著Internet技術的興起，對C/S結構的一種變化或者改進的結構。在這種結構下，用戶界面完全通過WVVW瀏覽器實現，一部分事務邏輯在前端實現，但是主要事務邏輯在服務器端實現，形成所謂3-tier結構。B/S結構利用不斷成熟和普及的瀏覽器技術實現原來需要復雜專用軟件才能實現的強大功能，并節約了開發成本，是一種全新的軟件系統構造技術。這種結構更成為當今應用軟件的首選體系結構。在實現B/S結構的多種解決方案中，由于..NET在開發Web應用時表現出的諸多優點，使其成為最受軟件應用歡迎的企業解決方案。伴隨著我國城市住宅小區建設的蓬勃發展，物業管理作為一個新興的服務行業日益顯現出他的重要性，并且在21世紀的發展中將發揮其越來越重要的作用。隨著人們生活水平的提高，物業管理的要求也越來越高，如何更好地管理好小區物業為住戶提供優質服務，成了物業管理的當務之急，他的出現使住宅小區的管理走向了科學、規范的發展道路。隨著計算機網絡技術的迅速發展，基于網絡的可視化物業管理是未來的發展方向，從而實現物業管理工作高效、科學、合理，適應時代的需求。1.3研究內容論文的主要研究內容包括:1、根據物業公司管理的實際需求和現有管理的不足造成的一些問題，提出系統的需求。小區物業管理在實際管理過程中，業主和物業公司均有其各自需求。對于業主，如果要對物業管理公司提供的服務收費，如上門維修等內容的收費、每月應繳納的水電費、管理費等進行查詢，必須等候物業管理的工作人員翻閱歷電子科技大學碩士學位論文6史記錄，費時費力。對于物業管理公司，業主們申請的各種服務項目，均要填寫、打印大量的各類表單，并要經過相關部門的審核、簽字、存檔，工作人員需要往返于各單位與各個部門之間。針對以上的類似需求，需要對系統進行詳細的需求分析，并采用軟件工程的相關分析和描述方法對需求進行細致的描述。2、論述物業管理系統的主要功能性需求和非功能性需求，及系統為實現這些需求而必須解決的主要技術問題，在此基地上提出了系統解決方案。系統需求主要包括功能性需求和非功能性需求兩種，在保障系統的功能性需求前提下，如何通過技術手段保障系統的非功能性需求，也是需要研究的重點，如保障系統的可用性、可擴展性和可維護性等等。同時，本文擬采用基于ASPNET相關技術來設計和實現系統，因為必須對.NET架構下的相關技術進行細致的了解，并進行技術選型。3、論述了物業管理系統的系統架構。良好的架構設計，是保障系統各項功能性需求和非功能性需求的基本要求。因此，本文需要對物業管理系統的架構，進行良好設計，包括系統功能架構、數據流程、實現技術架構以及部署架構等。在架構設計的基礎上，再進行系統的詳細設計。4、論述了物業管理系統各子系統的設計與實現。在系統整體架構設計的基礎上，需要對系統的數據庫選型、數據庫的ER關系圖等進行詳細設計;同時，需要給出各個子系統的業務流程、并用時序圖、狀態圖等進行細致的分析，對子系統進行全方位的描述。最后，給出各個子系統的實現方法和步驟，通過實際結果，對系統的分析和設計進行驗證。1.4論文結構安排全文共分為六章。第一章是緒論，主要介紹了系統的開發背景，以及國內外類似信息化建設的研究現狀，說明了系統的研究內容及組織結構。第二章是系統需求分心，主要圍繞需求獲取和需求分析兩個關鍵步驟描述了需求分析階段的主要工作。第三章是系統的架構設計部分，通過對系統的功能架構、技術架構，確定了系統的整體架構和核心功能。第四章是系統的詳細設計部分，主要描述了系統各子系統的分析設計和系統第一章緒論7數據庫的詳細設計。第五章主要描述了系統的實現，針對系統實現過程中的主要算法和解決的技術問題進行了闡述。第六章是總結與展望部分，對本文進行了總結，并對下一步的工作進行了展望。電子科技大學碩士學位論文8第二章系統需求分析解決任何問題的第一步都是理解問題的根本原因，與軟件開發有關的、最常見最嚴重的問題都與需求有關，需求分析無疑是軟件開發過程中的重要一環，直接關系到項目的成敗。整個軟件需求工程研究領域可劃分為需求開發和需求管理兩部分，如圖2-1所示。圖2-1.軟件需求工程域的層次分解需求開發可進一步分為:問題獲取、分析、編寫規格說明和驗證四個階段。這些子項包括軟件類產品中需求收集、評價、編寫文檔等所有活動。本章重點圍繞物業管理信息系統需求開發中的需求獲取和分析兩個關鍵步驟進行詳細闡述。2.1需求獲取需求獲取是在問題及其最終解決方案之間架設橋梁的第一步，是軟件開發中最困難、最關鍵、最易出錯及最需要交流的方面。需求獲取只有通過有效的客戶一開發者的合作才能成功。分析者必須建立一個對問題進行徹底探討的環境，而這些問題與產品有關。需求獲取是一個需要高度合作的活動，而并不是客戶所說的需求的簡單拷貝。作為一個分析者，必須透過客戶所提出的表面需求理解他們的真正需求。詢問一個可擴充的問題有助于更好地理解用戶目前的業務過程并且知道新系統如何幫助或改進他們的工作。獲取用戶需求需要執行的活動主要有:第二章系統需求分析91.了解客戶方的組織結構。小區物業管理企業的組織包括經理室、經營部、財務部、管理部、工程部和保安部。其組織結構圖如圖2-2所示:圖2-2.組織結構圖各部門主要業務如下:1)經營部:負責小區樓盤的各種信息管理和銷售。包括樓盤信息登記、房屋信息登記和戶型信息登記。2)財務部:負責小區各項物業項目的收費的管理和執行。包括收費登記管理、水費查詢管理、電費查詢管理、燃氣費查詢管理、小區物業管理費查詢管理和其他費用查詢管理。3)管理部:負責小區住戶信息的各種管理以及小區住戶的投訴管理。包括住戶信息登記、住戶信息查詢、住戶投訴登記、住戶投訴查詢。4)工程部:負責小區住戶的各種設施維修。包括維修信息登記、維修信息查詢。5)保安部:負責小區的安全維護。6)經理室:負責整個小區全面的業務管理監控。可以查詢所有信息，包括樓盤信息查詢、住戶信息查詢、報修信息查詢、投訴信息查詢和收費項目查詢。2.對用戶進行訪談和調研。交流的方式包括會議、電話、電子郵件、小組討論、模擬演示等不同形式。每一次交流都有記錄，對于交流的結果進行分類，便于后續的分析活動。例如，將需求細分為功能需求、非功能需求(如用戶并發數、響應時間、平均無故障工作時間、自動恢復時間等)、環境限制、設計約束等類型。3.對收集到的用戶需求做進一步的分析和整理。主要依據以下原則進行:電子科技大學碩士學位論文101)對于用戶提出的每個需求都要知道“為什么”，并判斷用戶提出的需求是否有充足的理由。2)將那種以“如何實現”的表述方式轉換為“實現什么”的方式，因為需求分析階段關注的目標是“做什么”，而不是“怎么做”。3)分析由用戶需求衍生出的隱含需求，并識別用戶沒有明確提出來的隱含需求(有可能是實現用戶需求的前提條件)，這一點往往容易忽略掉，經常因為對隱含需求考慮得不夠充分而引起需求變更。4).將調研的用戶需求以適當的方式呈交給用戶方的相關人員。在本系統中采用UML對系統建模，根據用戶需求做出用例圖及活動圖(詳見2.2需求分析)，并且采用快速原型法，制作靜態頁面，以可視化的方式表示出系統的流程，與用戶共同確認需求分析的結果是否真實地反映了用戶的意圖。在這個任務中需要執行下述活動:1)明確標識出那些未確定的需求項。2)保證需求符合系統的整體目標。3)保證需求項之間的一致性，解決需求項之間可能存在的沖突。2.2需求分析在RUP模型的新版本中，非常強調業務建模的重要性，因此采用RUP模式，需求分析的過程可以說是業務建模和用例建模的過程，主要包括業務建模和用例建模二個步驟，如圖2-3所示。圖2-3:需求分析過程示意圖第二章系統需求分析11如圖2-3所示，業務模型描述了客戶的業務現狀，但并不代表業務模型中所有的功能都將是信息系統實現的內容，因此需求分析的第二步就是根據業務模型進行用例建模，分析出信息系統的需求。信息系統的需求可以分為功能性需求和非功能性需求。本系統的開發模式主要采用RUP模式，需求分析的描述工具則主要采用UML，由于目前業界缺少成熟、規范的RUP和UML開發標準，因此在實際開發過程中開發人員之間容易產生分歧，從而增加了溝通成本，降低了開發效率。另外，由于缺少規范可能帶來的另外一個重大風險就是會產生模棱兩可的需求，一層含義是指諸多讀者對需求說明產生了不同的理解;另一層含義是指單個讀者能用不止一個方式來解釋某個需求說明。模棱兩可的需求會使不同的風險承擔者產生不同的期望，它會使開發人員為錯誤問題而浪費時間，并且使測試者與開發者所期望的不一致。因此在需求分析文檔的描述方法上，為了更加有利于和客戶的溝通，為系統設計人員提供一個準確的需求分析文檔，本系統采用了將傳統的軟件工程文檔描述方法和UML相結合的方式。另外為了避免文字描述的二義性，在編制文檔時還制定了幾個方面的具體規則。第一是描述語言要簡單、清晰。大多數的需求分析報告采用的仍然是自然語言，因為如果采用形式化語言的話，和用戶的溝通將成為一個大問題，這意味著客戶在開發軟件之前必須先進行形式化語言培訓，這是不現實的。自然語言對需求分析最大的弊病就是它的二義性，所以需要對需求分析中采用的語言做某些限制，例如盡量采用主語+動作的簡單表達方式，避免采用疑問句、修飾等華麗的表達方式。除了語言的二義性之外，還要注意不要過多地使用計算機術語。需求分析最重要的是和用戶溝通，可是用戶多半不是計算機的專業人士，如果在需求分析中過多地使用了計算機術語的話，就會造成用戶理解上的困難。例如，對于財務管理工作的目標，如果描述為“完成集團集中式財務管理工作”，盡管沒有錯誤，但也沒有實際意義，因為這樣的描述不夠精準。應該采用類似于這樣的描述方式:“在集團公司可以實時查詢到下屬單位的總賬及明細賬，完成下屬單位財務指標的自動采集及上報、接收工作，財務部可以進行綜合查詢分析”。第二是需求描述要與客戶的實際業務一致。簡單的來說，就是用戶需求必須和業務需求一致，功能需求必須和用戶需求一致。嚴格的遵守不同層次間的一致性關系，就可以保證最后開發出來的軟件系統不會偏離最初的實現目標。第三是需求要具有可測試性。一個項目的測試實際上從需求分析過程就開始電子科技大學碩士學位論文12了。需求分析是測試計劃的輸入和參照。這就要求需求分析是可測試的。只有系統的所有需求是可以被測試的，才能夠保證軟件始終圍繞著用戶的需要，保證軟件系統是成功的。2.2.1業務模型業務模型應該首先描述客戶的總體業務和流程，以便讀者對客戶的業務有一個概括性的了解，具體到每一個業務板塊，則首先描述該業務板塊的具體流程，對業務有一個整體的描述和說明，然后描述對業務現狀的分析，主要是分析研究各種不足之處，最后提出系統對現有業務的優化思路。這樣通過不斷地提出問題、分析問題、解決問題，可以較好地吸引客戶參與的興趣，實現了與客戶交流的互動，提高了業務需求的準確度。業務模型主要是描述客戶的現有業務，因此應該采用傳統的需求分析文檔模板，用文字、業務流程圖、表格等工具進行了描述，客戶可以比較容易閱讀。例如對于中實物業公司的總體業務描述，就采取了下面客戶易于理解的描述方法。小區物業管理企業的系統業務流程圖:圖形定義如下:第二章系統需求分析131.該小區物業管理總的業務流程圖如圖2-4所示:圖2-4總業務流程圖2.物業項目收費業務流程圖如2-5所示:圖2-5小區物業項目收費業務流程圖電子科技大學碩士學位論文143.住戶投訴、報修業務流程圖如圖2-6所示:圖2-6住戶投訴業務流程圖第二章系統需求分析154.住戶報修業務流程圖如圖2-7所示:圖2-7住戶報修業務流程圖2.2.2功能性需求按照RUP的要求，系統的功能性需求描述工具主要是用例(UseCase)，即將系統的功能性需求分解到每一個系統用例。RUP模式的最大優點是按照角(Actor)識別用例(UseCase)的方法，該方法可以較為直觀地建立起系統的架構，通過反復識別，避免需求中的漏項。為了清晰地描述系統用例的層次結構，可以采用將系統用例分為不同的包，每一個包表示一組相關的系統用例。為了清晰起見，本系統引入了包圖來將不同的功能用例進行分類，每個包圖作為一個子系統，如圖2-8所示。從功能上看，小區物業管理系統可以分為六個子系統:小區信息管理、財務收費、維修管理、投訴管理、車位管理、業主網上信息查詢。電子科技大學碩士學位論文16圖2-8子系統包圖在每個包中，通過用例圖來描述系統的參與者(Actor)和系統的用例(UseCase)，每一個用例通過用例規約進行詳細的描述。小區信息管理如圖2-9小區信息管理包括區域信息管理、樓宇信息管理、業主房間管理和房間使用報表四個用例。圖2-9小區信息管理用例圖第二章系統需求分析172、財務收費管理如圖2-10財務收費管理包括收費項目管理、分配費用、表值管理、收費管理、催繳費用和收費報表六個用例。圖2-10財務收費管理用例圖電子科技大學碩士學位論文183、維修管理如圖2-11財務收費管理包括報修單接收、收維修單派單、維修單暫停、維修單結單、維修單回訪和維修報表六個用例。圖2-11維修管理用例圖第二章系統需求分析194、投訴管理如圖2-12投訴管理包括投訴單接收、投訴單派單、投訴單結單和建議單回訪四個用例.圖2-12投訴管理用例圖5、車位管理如圖2-13車位管理包括車域信息管理、車位信息管理、汽車信息管理、車位費催繳和車位使用圖表五個用例。圖2-13車位管理用例圖電子科技大學碩士學位論文206、業主網上信息查詢如圖2-14業主網上信息查詢包括費用查詢、保修和投訴查詢三個用例。圖2-14業主網上信息查詢用例圖用例分析技術為軟件需求規格化提供了一個基本的元素，而且該元素是可驗證、可度量的。用例可以作為項目計劃、進度控制、測試等環節的基礎。而且用例還可以使開發團隊與客戶之間的交流更加順暢。用例描述是用例分析技術的核心。表2-1是對用戶“報修單回訪”用例的描述:表2-1報修單回訪用例描述第二章系統需求分析21表2-2是對用戶“報修單派單”用例的描述:表2-2報修單派單用例描述2.2.3非功能性需求1、規范性1)系統的結構設計遵循UML,XML,XMI(XMLMetadataInterchange),.NET,XPDL(XMLProcessDefinitionLanguage)等規范，保證細化設計和未來的發展保持完整性。2)遵循嚴格的開發規范，保證開發過程的質量和系統組件的可重用性。3)制定和遵循嚴格、先進和完整的接口標準，保證系統內各組件之間以及系統對外支持的應用系統的接口實現。電子科技大學碩士學位論文222、可擴展性1)系統能提供一組用于響應來源于企業信息系統請求和訪問平臺業務的應用接口，以保證相關業務系統可以方便地開發基于該平臺的應用組件或系統。2)系統所有的對外接口既可開發針對主流產品的完整接口，又可提供開發接口的SDK，用于擴展支持的對象，使用戶可以方便的開發新接口。3)系統自身采用分布式組件化設計，實現高度的開放性和可擴展性。3、可管理性1)系統提供完善的安裝、部署、配置、監控手段，保證平臺高度的可維護性。2)系統能針對企業信息系統的管理功能、數據定義與流程處理功能提供簡潔方便的管理或開發定制用戶界面，保證系統用戶能夠高效地實施操作。3)系統具備高度的適應性，以適應制造業信息化軟件的現狀。4)系統提供靈活、豐富可擴展的配置功能適應企業內部數據結構的變化。4、可靠性1)系統提供有效的安全保障機制并與整個軟件平臺的安全支撐系統相結合。2)系統結構設計的完整和堅固性，保證平臺運行穩定可靠。3)保證數據的安全性、重要數據的完整性、一致性和可恢復性。4)系統提供備份和恢復機制，確保在日常維護或是意外崩潰時企業信息化網絡平臺可以正常運轉。5)系統應用服務能力的線性擴展和流量均衡，以保證在大事務量、大數據量的環境下能加以調配以滿足實際情況的需求。6)服務器具備高可用性，以保證在個體服務器或服務出現故障時，平臺應用和服務不受影響。5、兼容性1)支持主流數據庫系統的市場現行版本，Oracle,MicrosoftSQLServer等。2)支持主流的應用服務器軟件的市場現行版本。3)支持主流的Web服務器的市場現行版本。4)支持主流的應用服務組件，包括:COM,WebService等。第三章系統架構設計23第三章系統架構設計在完成了系統的需求分析之后，進入系統設計階段。系統設計包括概要設計和詳細設計。概要設計，是將軟件需求轉化為數據結構和軟件的系統結構，一般包括系統結構設計和數據設計。系統結構設計定義軟件系統各主要成份之間的關系，數據設計側重于數據結構的定義。該階段注重宏觀上和框架上的設計。系統概要設計的目的是將軟件系統需求轉換為未來系統的設計，逐步開發出強壯的系統構架，并且使設計適合于實施環境，為提高性能而進行設計。概要設計的總體原則是由粗到細、互相結合的原則，可采取的方法有定性分析和定量分析相結合的方法、分解協調的方法以及模型化方法，要考慮系統的一般性、關聯性、整體性和層次性。本小區物業管理系統的目標是，提高管理人員的工作效率和滿足業主及其入住成員的多方面服務需求。管理人員或業主可以在任何時候從系統當中獲取最新的信息，實現自己的需要。具體的系統有6個設計目標。(1)客戶化。操作人員操作方便，容易上手，軟件操作界面友好美觀。(2)實用性。本系統是針對小區的管理業務來設計實現，所以它具有很強的實用性.(3)先進性。本系統采用B/S結構的設計思想，數據庫采用SQLServer2000，在設計和實現上具有先進性。(4)交互性。本系統通過建立B/S結構的網站，可以與物業小區內居民通過Internet進行很好的信息交流。(5)安全和保密性。通過功能和流程的有效分配和控制，并進行相關的權限設置，使系統具有很強的安全和保密性。(6)可擴充性。為了使本軟件具有更長久的實用價值，本系統在數據庫結構以及應用軟件設計上保留可擴充性接口，便于軟件更新升級。本章將從系統架構設計方面對系統設計階段所作的工作進行描述。3.1系統功能架構在設計系統功能架構時，采取分解協調的方法。分解協調的目的是為了創造更好的系統。系統分解是指將一個復雜的系統分解為若干個子系統，系統協調是指系統內協調，即根據系統的總結構、總功能、總任務和總目標的要求，使各個子系統之間互相協調配合，在各個子系統局部優化基礎上，通過內部平衡的協調控制，實現系統的整體優化。電子科技大學碩士學位論文24為了便于今后系統開發和系統運行，子系統的劃分應遵循如下幾點原則:1、子系統要具有相對獨立性。子系統的劃分，必須使得子系統內部功能、信息等各方面的凝聚性較好。子系統獨立可以減少子系統間的相互影響，有利于多人分工開發不同的模塊，從而提高軟件產品的生產率，保證軟件產品的質量，同時也增強了系統的可維護性和適應性。2、子系統之間數據的依賴性盡量小。子系統之間的聯系要盡量減少，接口要簡單明確。一個內部聯系強的子系統對外部的聯系必然很少，所以劃分的時候，應將聯系較多者列入子系統內部，剩余的一些分散、跨度比較大的聯系，就成為這些子系統之間的聯系和接口。這樣劃分的子系統，將來調試和運行相對比較方便。3、子系統劃分的結果應使數據冗余較小。如果把相關的功能數據分布到各個不同的子系統中，則會有大量的原始數據需要調用，大量的中間結果需要保存和傳遞，大量計算工作將要重復進行。從而使程序結構紊亂，數據冗余，不但給軟件編制工作帶來很大的困難，而且系統的工作效率也大大降低了。4、子系統的設置應考慮今后管理發展的需要。子系統的設置光靠上述系統分析的結果是不夠的，因為現存的系統由于各種原因，很可能沒有考慮到一些高層次管理決策的要求。5、子系統的劃分應便于系統分階段實現。信息系統的開發是一項較大的工程，它的實現一般都要分期分批進行，所以子系統的劃分應能適應這種分期分批的實施。另外，子系統的劃分還必須兼顧組織結構的要求。6、子系統的劃分應考慮到各類資源的充分利用。一個適當的子系統劃分應該既考慮有利于各種設備資源在開發過程中的搭配使用，又考慮到各類信息資源的合理分布和充分使用，以減少系統對網絡資源的過分依賴，減少輸入、輸出、通信等設備壓力。子系統劃分的方法有:功能劃分(按業務處理功能劃分)、順序劃分、數據擬和、過程劃分、時間劃分、環境劃分。按功能劃分是目前最常用的一種劃分方法。按業務處理順序劃分要依據業務流程分析的結果，這種劃分方式在一些時間和處理過程順序特別強的系統中常常采用.第三章系統架構設計25從系統需求分析我們可以看到，小區物業管理公司主要業務比較明確，因此采用按功能劃分的方法，將小區物業管理系統劃分為小區信息管理、財務收費、維修管理、投訴管理、車位管理和業主網上信息查詢六個子系統，另外，系統還包括幾個支撐子系統，包括用戶權限管理和系統設置。系統功能結構如圖3-1所示。電子科技大學碩士學位論文26圖3-1系統功能結構第三章系統架構設計273.2系統數據架構業務流程圖雖然形象表達了管理過程中信息的流動和存儲過程，但其中包含了很多的物質要素，為了對它進行更加形象、細致的描述，下面用數據流程圖分析。圖3-2數據架構電子科技大學碩士學位論文283.3系統層次架構隨著軟件行業的發展，軟件項目的規模越來越大，復雜度越來越高，為降低復雜度，應該將應用軟件系統進行分層設計，以降低各層的復雜度，利于軟件開27發的分工和復用。一般來講，軟件分層需遵循一定的規則，例如:各層之間不得跨層調用，每一層都只與直接相臨的層進行通信;上面各層都建立在下層的基礎上，隱藏下層的信息并為上層提供服務;各層要封裝自己的實現，向前一層提供訪問接口;各層支持分布式的部署，即可部署于不同的容器實例中。圖3-3基本說明了本系統架構思路，系統是采用多層架構開發。開發涉及到的部分分為三層，表示層、業務層、數據層。在基本的三層結構之外還有延伸即客戶端界面、數據存儲。圖3-3系統層次架構第三章系統架構設計293.4系統技術架構設計系統的技術架構，其任務是以系統需求分析的結果為依據，充分考慮系統的特點及用戶的要求，為系統選擇合適的開發平臺，并且選擇合適的方式構建組織系統。在小區物業管理系統技術架構時，需要重點考慮以下原則:1、為了消除用戶使用系統的地域局限性，以及系統升級帶來的不便，目前比較好最好的方式是將系統實現為B/S結構的Web應用。2、小區物業管理系統僅是整個智能化小區平臺的一個組成部分，在設計的時候要充分考慮系統的可擴展性及可維護性。NET平臺在這兩個方面都具有優勢，因此在物業管理信息系統中采用.net開發平臺。.NET是Microsoft的用以創建XMLWeb服務(下一代軟件)平臺，該平臺將信息、設備和人以一種統一的、個性化的方式聯系起來。借助于.NET平臺，可以創建和使用基于XML的應用程序、進程和Web站點以及服務，它們之間可以按設計、在任何平臺或智能設備上共享和組合信息與功能，以向單位和個人提供定制好的解決方案。3.4.1系統MVC架構ASRNETMVC是微軟官方提供的基于MVC模式開發ASP.NETWeb應用程序的一種編程模型。根據微軟官方說明，ASRNETMVC的出現不是用于取代現有的ASPNETWebform編程模型，而是提供了另外一種可選擇的方案。MVC這一概念最早由美國教授TrygveReenskaug于1979年提出。1988年MVC這一設計模式正式在(((ACookbookforUsingtheModel-View-ControllerUserInterfaceParadigminSmalltalk-80》一書中提出。伴隨著微軟Windows操作系統的迅速發展與普及，圖形化用戶界面應用程序逐漸成為主流，很多編程語言都出現了MVC框架，以方便開發人員使用該模式來設計應用程序。這些框架中大部分都是針對Web應用程序。ASRNETMVC將促進清晰的關注分離，可測試性，和TDD(測試驅動開發)。MVC框架中的所有核心契約都是基于接口的，可以輕易地通過mock來模擬(包括基于接口的IHttpRequest/IHttpResponse這些基本的東西)。可以不用在ASPNET進程中運行控制器(這樣可以使得單元測試速度很快)，就對應用程序進行單元電子科技大學碩士學位論文30測試。可以使用任何單元測試框架來做單元測試，包括NUnit,MBUnit,MSTest等。ASPNETMVC框架具有高度的可擴展性和可插拔性。MVC框架中所有的東西都是這樣設計的，它們可以被輕易地替換掉或者定制(例如，可以插入自定義的視圖引擎，路徑轉向策略(routingpolicy)，參數序列化等等)。它還支持使用現有的依賴注入(dependencyinjection)和控制反轉(IOC)容器模型(Unity,Windsor,Spring.Net,NHibernate等等)。ASRNETMVC框架將完全支持象forms/windows認證，URL授權，成員/角色，輸出和數據緩存，sessio吻rofile狀態管理，健康監側，配置系統，以及provider架構等等現有的ASPNET特性。3.4.2系統持久層架構EntityFramework(實體框架)是ADO.NET中的一組支持開發面向數據的軟件應用程序的技術。面向數據的應用程序的架構師和開發人員曾為實現兩個迥然不同的目標費盡心機:他們必須為要解決的業務問題的實體、關系和邏輯構建模型，還必須處理用于存儲和檢索數據的數據引擎。數據可能跨多個各有不同協議的存儲系統;甚至使用單個存儲系統的應用程序也必須在存儲系統的要求與編寫高效且容易維護的應用程序代碼之間取得平衡。實體框架使開發人員可以采用特定于域的對象和屬性(如客戶和客戶地址)的形式使用數據，而不必自己考慮存儲這些數據的基礎數據庫表和列。通過提升開發人員在處理數據時可以使用的抽象級別并減少創建和維護面向數據的應用程序所需的代碼，可以實現這一目的。因為實體框架是.:NETFramework的一個組件，所以實體框架應用程序可以在安裝了.NETFramework3.5ServicePack1(SPI)的任何計算機上運行。實體框架不僅僅是另一種對象關系映射解決方案，還從根本上使應用程序可以訪問和更改表示為概念模型中的實體和關系的數據。對象服務使用EDM將對概念模型中所表示的實體類型的對象查詢轉換為特定于數據源的查詢。查詢結果具體化為對象服務管理的對象。另外，實體框架中包含EntityClient數據提供程序。此提供程序管理連接，將實體查詢轉換為特定于數據源的查詢，并返回一個由對象服務用來將實體數據具體化為對象的數據讀取器。當不需要對象具體化時，通過使應用程序執行第三章系統架構設計31EntitySQL查詢并使用返回的只讀數據讀取器，還可以像標準ADO.NET數據提供程序一樣使用EntityClient提供程序。3.4.3系統通訊架構WindowsCommunicationFoundation(WCF)是Microsoft為構建面向服務的應用提供的分布式通信編程框架，是..NETFramework3.5的重要組成部分。使用該框架，開發人員可以構建跨平臺、安全、可靠和支持事務處理的企業級互聯應用解決方案。WCF是對于ASMX,.NetRemoting,EnterpriseService,WSE,MSMQ等技術的整合。由于WCF完全是由托管代碼編寫，因此開發WCF的應用程序與開發其它的.Net應用程序沒有太大的區別，我們仍然可以像創建面向對象的應用程序那樣，利用WCF來創建面向服務的應用程序。Web服務中包含了用于應用程序間通信的標準協議，它在全球范圍內的廣泛采納改變了軟件開發。例如，如今Web服務提供的功能包括安全性、分布式事務協調和可靠的通信。Web服務所發生的這些改變的效益應反映在開發人員所使用的工具和技術方面。設計WindowsCommunicationFoundation(WCF)的目的是為分布式計算提供可管理的方法，提供廣泛的互操作性，并為服務定位提供直接的支持。WCF通過一種面向服務的新型編程模型簡化了關聯應用程序的開發。通過提供分層的體系結構，WCF支持多種風格的分布式應用程序開發。WCF通道體系結構在底層提供了異步的非類型化消息傳遞基元。而建立在此基礎之上的是用于進行安全可靠的事務處理數據交換的各種協議功能，以及廣泛的傳輸協議和編碼選擇。電子科技大學碩士學位論文32第四章系統詳細設計詳細設計的目標是為系統結構設計確定的各個具體任務選擇適當的技術手段和處理方法，為系統的實現奠定良好的基礎。本章將從系統詳細設計方面對系統設計階段所作的工作進行描述。4.1概述系統的詳細設計過程和工作制品如圖4-1所示。圖4-1:系統詳細設計制品如圖4-1所示，按照統一軟件過程(RUP)和統一建模語言(UML)的要求，系統功能的詳細設計包括系統在靜態屬性方面的設計和動態功能方面的設計。系統的靜態屬性設計主要是用類圖來描述，動態功能主要是用時序圖來描述。類圖主要描述了系統實體之間的靜態關系，時序圖則描述了各對象之間的動態交互關系。UML作為詳細設計描述語言帶來的第一個問題就是對于界面類對象和控制類對象的描述力度不強。為了解決這個問題，在類圖和時序圖的基礎上，結合著傳第四章系統詳細設計33統的結構化程序設計方法，筆者給出了用例補充設計文檔的模板，重點放在界面設計和數據操作設計方面，這樣有效地解決了詳細設計文檔不能直接用于編碼的問題。由于面向對象數據庫技術還不成熟，目前主要應用的還是關系型數據庫系統(RDBMS)，這樣UML帶來的第二個問題就是如何解決永久性對象在關系型數據庫中的持久化存儲問題，即O/R轉換問題。O/R轉換問題曾有許多專題研究過，但是目前業界并沒有一個非常成熟的通用化解決方案。在本系統中也沒有直接采用通用的O/R轉換技術，而是采用了更為保守的方法，即在數據庫設計時仍然采用了關系型數據庫設計的方法，如圖4-1所示，在系統核心類圖的基礎上重新設計系統的數據庫結構，并在用例的補充設計中進行使用說明。4.2系統功能模塊設計4.2.1用戶權限管理模塊設計本系統采用ASPNET成員資格實現用戶權限管理。ASPNET成員資格是微軟提供的一套通用的用戶權限管理模塊。通過它可以創建、刪除、編輯用戶，對用戶的角色進行管理，實現用戶登錄、密碼找回等功能。ASP.NETMembership主要由內置的成員資格提供程序組成，這些提供程序與數據源及公開其功能的Membership靜態類進行通信。從ASP.NET代碼調用Membership類以執行用戶驗證和管理。ASPNET成員資格提供了一種驗證和存儲用戶憑據的內置方法。因此，ASPNET成員資格可用于管理網站中的用戶身份驗證。可以將ASP.NET成員資格與ASPNETForms身份驗證或ASP.NET登錄控件一起使用以創建一個完整的用戶身份驗證系統。電子科技大學碩士學位論文344.2.2系統設里模塊設計系統設置模塊中比較重要的系統中一些配置信息的管理。配置信息有可能保存在XML文件中，有可能保存在數據庫中。所以這里采用工廠模式實現配置的管理.圖4-2配置管理類圖中ConfigManager是配置管理父類FileConfigManager和DBConfigManager分別實現文件和數據配置的管理，其余幾個是各個功能配置類。圖4-2配置管理類圖第四章系統詳細設計354.2.3小區信息管理模塊主要是管理小區的一些基本信息，包括區域、樓宇和房間，還有房間使用報表。圖4-3小區信息管理模塊類圖1.區域信息的管理圖4-3中的類ResidentManager中的方法實現了對區域信息進行添加修改、刪除和查詢操作。2.樓宇信息的管理圖4-3中的類BuldingManager中的方法實現了對樓宇信息進行添加、修改、刪除和查詢操作。3.房間信息的管理圖4-3中的類HouseManager中的方法實現了對房間信息進行添加、修改、刪除、查詢和統計操作。電子科技大學碩士學位論文364.2.4財務收費模塊設計財務收費模塊主要有的收費項目管理、分配費用、表值管理、收費管理、催繳費用和收費報表等功能。圖4-4財務收費模塊主要類圖第四章系統詳細設計371.收費項目的管理圖4-4類中的FeeItemManager中的方法實現了對收費項目添加、修改、刪除和查詢操作。2.分配費用圖4-4類中的HouseFeeManager中的方法實現了對業主分配相關費用等相關操作。3.表值管理圖4-4類中的HouseFeeDetailManager中的方法實現了對表值類費用的管理操作。當工作人員分配表值費用時經常抄錯表值，如圖4-5可以通過命令行模式實現了超表值的撤銷功能。電子科技大學碩士學位論文38圖4-5抄表相關類圖4.收費管理圖4-4類中的HouseFeeManager中的方法實現了對業主收費等相關操作。5.催繳費用圖4-4類中的HastenHouseFeeViewManager中的方法實現了對業主催繳費用等相關操作。第四章系統詳細設計394.2.5維修管理模塊主要有的報修單接收、收維修單派單、維修單暫停、維修單結單、維修單回訪和維修報表等功能。圖4-6中類MaintailListManager中的方法實現了這些功能。圖4-6維修管理模塊主要類圖UML交互圖對用例中的業務流程進行描述。順序圖和協作圖，兩者均被稱為交互圖。它們是UML中用于對系統的動態方面進行建模的五種圖中的兩種。一張交互圖顯示的是一個交互，由一組對象和它們之間的關系組成，包含它們之間可電子科技大學碩士學位論文40能傳遞的消息。順序圖是強調消息時間順序的交互圖，協作圖則是強調接收和發送消息的對象的結構組織的交互圖。交互圖用于對一個系統的動態方面建模，可以單獨使用，來可視化、詳述、構造和文檔化一個特定的對象群體的動態方面，也可以用來對一個用例的特定的控制流進行建模川。在此，使用交互圖，不僅僅可以使用例的業務流程明朗化，圖4-7是為表2-2中描述的用例所做的順序圖。圖4-7報修單派單順序圖第四章系統詳細設計414.2.6投訴管理模塊設計投訴管理模塊主要有的投訴單接收、投訴單派單、投訴單結單和建議單回訪等功能。圖4-8中類ComplainManager中的方法實現了這些功能。圖4-8投訴管理模塊主要類圖電子科技大學碩士學位論文42這個模塊主要是圍繞著投訴單進行操作管理，這里用狀態圖能夠很好的描述投訴單的狀態的變化，如圖4-9圖4-9投訴單狀態圖4.2.7車位管理模塊設計車位管理模塊主要有車域信息管理、車位信息管理、汽車信息管理、車位費催繳和車位使用圖表等功能。第四章系統詳細設計43圖4-10車位管理模塊主要類圖1.車域信息管理圖4-10類中的CarResidentManager中的方法實現了對車域信息添加、修改、刪除和查詢操作。2.車位信息管理圖4-10類中的CarParkManager中的方法實現了對車位信息添加、修改、刪除和查詢操作，催繳費用也是在這個類中實現的。3.汽車信息管理圖4-10類中的CarManager中的方法實現了車位信息添加、修改、刪除和查詢操作。4.車位使用圖表圖4-10類中的CarParkReportManager中的方法實現了車位使用統計等操作。電子科技大學碩士學位論文444.2.8業主網上信息查詢模塊主要是給業主提供查詢收費信息、保修信息和投訴信箱的功能。為了方便和第三方的網站集成，采用Silverlight和WCF的技術以插件的形式提供給第三方。4.3數據庫設計數據庫是數據庫應用程序的核心。數據庫設計，或稱數據模型，是建立應用程序的關鍵性步驟，根據數據的不同用途，使用要求、統計渠道、安全保密性等，來決定數據的整體組織形式、表或文件的形式。一個好的數據庫能使信息處理速度快、占用存儲空間少、操作處理過程簡單、查找容易、系統開銷費用低等目的。為了把現實世界中的具體事物抽象、組織為某一DBMS支持的數據模型，常常首先將現實世界抽象為概念世界，然后將概念世界再轉換為機器世界。也就是說，首先把現實世界中的客觀對象抽象為實體(Entity)和聯系(Relationship),它們并不依賴于具體的系統或某個DBMS系統，這樣的模型就是我們所說的CDM(ConceptualDataModel)。然后再從CDM中抽象出面向對象的模型OOM(ObjectOrientedModel)，做出系統類圖。最后從類圖中尋找需要持久化的類，將需要持久化的類的邏輯模型進行整合轉化為物理模型，完成數據庫建模。最終建立的數據庫模型就是物理數據模型PDM(PhysicalDataModel)E91。這一過程如圖4-11所示:圖4-11現實世界到機器世界的抽象過程物業管理信息系統使用Sybase公司的數據庫建模工具PowerDesigner,根據以上過程建立系統數據庫模型。第四章系統詳細設計454.3.1系統概念模型模型就是抽象，就是有意識地忽略事物的某些特征。抽象帶來的好處是能夠反映模型中元素之間的關系，清晰把握大局。概念模型是模型的一種，簡單說就是抽象程度極高的一種模型。軟件工程概念模型是對軟件工程領域進行抽象描述的模型，它能夠使我們對軟件工程有一個完整把握。CDM的理論基礎是實體一關系理論。實體一關系理論，也叫E-R理論，是由PP.S.Chen在E.F.Codd博士關系模型理論的基礎上于1976年提出的。E-R理論中最主要的兩個模型元素即是實體(Entity)和關系(Relationship)實體，也叫實例，對應現實世界中可區別于其他對象的“事件”或“物體”，它可以是有形的或無形的、具體的或抽象的、有生命的或無生命的。在物業管理系統中的實體主要包括:員工、區域、樓宇、房間、維修單、投訴單等。關系是指實體集之間或實體集內部實例之間的連接，實體之間可通過關系來相互關聯。按照實體類型中實例之間的數量對應關系，通常可將其分為四類，即一對一、一對多、多對一、和多對多關系。經過分析，做出物業管理系統的主要概念模型如圖4-12所示。圖4-12系統概念模型電子科技大學碩士學位論文464.3.2系統面向對象模型在上一小節中，已從物業管理系統的業務領域中抽象出系統的概念模型。建立系統的面向對象的模型，目的是根據系統的概念模型和交互圖設計系統類圖。與概念模型相比，類圖中的設計類表示軟件類而不是現實世界中的概念的定義，表示應用中軟件類和接口的規格說明。類圖能夠表示的典型信息包括:類、關聯和屬性，接口以及接口上的操作和常數，方法，屬性類型信息，導航性，依賴。創建類圖的第一步是識別參與軟件解決方案的類。通過掃描概念模型以及交互圖，找到這些類。物業管理系統中存在如下實體類:員工類(UserInfo)、部門類(Department)、維修單類(MaintainList)等。第二步，為這些類以及在概念模型中以識別出來的屬性，繪制適當的類圖。將概念模型中實體的屬性轉換為類的屬性。以員工類為例，員工的姓名、性別、職務相應的轉換為UserInfo類的UserName,Sex,Post屬性。第三步，添加類的方法。每一個類的方法都可以通過分析交互圖得到。除了實體類的創建方法、屬性的存取方法，我們將實體類的添加、刪除、查詢方法以及與交互圖中的消息相對應的業務方法封裝在管理類中。例如，將實現論文分發的方法放入評審過程管理類中。第四步，進一步的細化，添加更多的類型信息。屬性的類型、方法參數的類型以及方法返回的類型都可以在類圖中可選的表示。第五步，添加關聯和導航。導航是角色的一個屬性，表示從一個源對象沿著關聯可以單向地到達一個目標類。導航意指可見性一通常是屬性可見性。一個帶有導航箭頭的關聯通常含義是從源類到目標類的屬性可見性，在面向對象編程語言中，通常轉換為源類擁有一個引用目標類實例的屬性。第六步，添加依賴關系。在類圖中，依賴關系常用來描述類之間的非屬性可見性，即參數、全局或本地聲明的可見性。最終建立物業管理系統核心類圖，如圖4-13顯示了其中一部分所示。第四章系統詳細設計47圖4-13物業管理系統核心類圖(部分)4.3.3在建立系統的面向對象模型之后，下一步的工作是從類圖中找出需要持久化的類，將