基于UML的小区物业管理系统的分析与设1.docx
《基于UML的小区物业管理系统的分析与设1.docx》由会员分享，可在线阅读，更多相关《基于UML的小区物业管理系统的分析与设1.docx（31页珍藏版）》请在冰点文库上搜索。
基于UML的小区物业管理系统的分析与设1
基于UML的小区物业管理系统的分析与设计
一、项目背景
随着人们生活水平的不断提高,伴随着人们住宅小区的规模也不断扩大和业主的不断增多,像小区中的汽车、公共设施,小区的安全、小区的各项维修等都将越来越复杂,物业工作人员的工作量也随之增加。
但一直以来许多物业公司都是使用传统人工的方式来对各种物业相关数据的处理,这种管理方式当然会存在着许多缺点,例如管理的效率低、相关数据的保密性差,随时间的推移,还会产生大量的文件和多余数据,将会给我们的查找、管理带来不少的麻烦。
另外我国农村城市化的脚步不断加快，小区的出现成为了这一进程的历史见证。
但如何对小区进行有效的管理是现代社会所不得不深思的事情。
现代的小区有很多的弊端，如：
设施陈旧、管理松懈、乱收费以及治安混乱等等！
很多人对小区的抱着不满的情绪，如果这种情况再继续恶化下去，那么城市化的进程势必会遭到难以想象的阻碍。
因此，为提升小区物业管理的网上技术水平和更新管理理念,提高物业管理工作的效率和质量,降低物业管理成本,本文结合我国小区物业管理的发展趋势、小区物业管理的工作特点以及物业管理的实际需要,采用面向对象的分析方法与结构化的设计方法对系统进行分析。
开发合理的小区物业管理系统对提高小区的管理效率、增加居民的满意度有着很大的作用，同时也是为我国顺利进行农村城市化所迈出的重要一步。
1.1项目必要性分析
为了了解项目的必要性我们必须对项目的实施就有一定的认识，以下是我通过网络、书籍以及调查所得到的小区业务基本信息
1）小区管理中为住户提供的业务比较繁多，主要有公共设备的管理、小区绿化、文化娱乐服务、住户投诉、费用的收取等。
小区的主要部门主要有财务部、保洁部、维修部、仓库部、警卫部等。
2）小区工作人员的主要职能有，库管人员管理主要设备，记录设备的状态是否完好，并对其他人员如保洁员、维修员领取设备进行登记，设备缺货时及时向采购部反馈。
采购人员主要采购管理下去需要的设备，保安人员主要负责小区的安全，对小区的人员流动进行登记和记录小区的异常情况和突发事件等。
保洁人员主要负责小区的卫生以及小区的绿化。
维修人员管理小区公共设备，收取用户的保修信息等。
3）各种单据的管理，如收费单据、未缴费用单据、催费通知、住户档案、进货单据、销售单据等。
通过上述的业务描述我们可以看出小区的管理是一项复杂的任务，而且在小区业务管理的运作中存在着很多不足之处，主要有：
单据票据繁多，要记录的项目太多，在整理收集与统计方面需要花费大量的人力，有时由于一些人为地失误，使单据票据丢失。
由于人员无法准确的定位，所以很多小区的卫生恶化、设施常年无人过问、维护效率极其低下等。
因此小区物业管理系统的需要是解决这一系列问题的必要条件。
1.2项目可行性分析
通过调查我们发现规模比较小的小区管理系统的管理操作还是通过手工操作，记录，管理，工作效率很低，而且手工操作还存在着诸多弊端,由于不可避免的人为因素,造成数据的遗漏、误报，计算错误，数据丢失率很高。
同时在统计数据,数据分析等方面还存在许多不足之处,统计等操作耗时,耗力,不能够很好的满足管理者的需求.而这些问题在用上一个科学的管理系统以后几率会大大的缩小。
因为，这些发生在人员方面的因素对电脑而言完全可以克服。
用户通过登陆小区物业管理系统可以查询自己的缴费情况，以及进行网上报修，网上缴费等，小区管理人员通过小区物业管理系统可以优化管理业务，合理分配管理人员是小区的管理效率大大提高。
下面是通过网上收集的数据对小区满意度的调查。
图一：
小区满意度调查饼状图
二、需求工作流
2.1问题域的描述
按照现在的小区业务的管理模式，小区物业管理系统主要包括财务管理、保洁管理、维修管理、仓库管理、安全管理、人员管理等。
财务管理主要负责费用的收取、接受用户财务状况的查询、通知业主未缴纳的费用、自主打印凭据、小区正常运行的开销。
保洁管理主要包括小区卫生状况的统计、区域保洁人员的分配、小区的绿化管理、接受用户请求。
维修管理的主要功能包括接受用户的维修请求、小区公共设施的检查与维护。
仓库管理的主要功能有小区设备的记录，自动统计缺失设备。
安全管理的功能包括人员出入的统计、特殊情况发生的统计、接受用户的报警请求。
人员管理的功能主要包括对用户档案的管理、小区工作人员的管理。
其涉及得主要术语见术语表：
表一：
系统涉及的主要术语
绿化
小区的绿色区域地带
记录
对特殊情况的描述
设备
小区工作人员所需要的工具
催费
对欠费的住户催促其缴纳未交费用
仓库
小区存放设备的地方
档案
记录住户的一些信息
2.2系统整体结构的设计
通过描述问题域，我们可以知道整个系统操作业务人员角色包括：
业主、保安、管理员、财务人员、维修人员、系统管理员。
每个角色在系统中承担着不同的任务,物业管理部门通过使用统一的访问界面进行日常的小区管理,业主则可以通过小区网络连接到小区物业管理系统进行有必要的报修或查询。
本系统在小区管理中以数字服务为核心,充分发挥网络优势,解放劳动力,集中有限人力和物力资源,实现管理的高效性和快捷性,从而降低成本,提高管理水平。
对于小区物业管理系统的系统设计的原则主要由以下几个方面：
1、系统性。
从整个系统的角度进行考虑，系统的代码要统一，设计规范要标准，传递语言要尽可能一致，对系统的数据采集要做到数出一处、全局共享，使一次输入得到多次利用。
2、灵活性。
系统应具有较好的开放性和结构的可变性，采用模块化结构，提高各模块的独立性，尽可能减少模块间的数据偶合，使各子系统间的数据依赖减至最低限度。
3、可靠性。
可靠性是指系统抵御外界干扰的能力及受外界干扰时的恢复能力。
一个成功的管理信息系统必须具有较高的可靠性，如安全保密性、检错及纠错能力、抗病毒能力等。
4、经济性。
经济性指在满足系统需求的前提下，尽可能减小系统的开销。
一方面，在硬件投资上不能盲目追求技术上的先进，而应以满足应用需要为前提；另一方面，系统设计中应尽量避免不必要的复杂化，各模块应尽量简洁，以便缩短处理流程、减少处理费用。
在充分考虑小区物业管理系统系统整体结构设计原则上，我们给出了小区物业管理系统的整体结构图如下：
图二：
本系统总体结构
通过对小区物业管理系统总体结构的描述我们可以得到本系统初步业务项目
Ø住户通过系统查看自己的缴费情况、网上报修、网上投诉
Ø财务人员通过该系统查看住户缴费情况、催促未交费用户缴纳费用、查看小区开销情况和接受用户缴费。
Ø保洁人员通过该系统接受用户请求、查看小区卫生情况、查看小区绿化情况、查看自己的工作及工作区域。
Ø维修人员通过登陆该系统查看用户请求、查看公共设施的基本情况并决定是否进行维护。
Ø仓库管理员通过登陆该系统查看仓库库存信息、并向财务部申请财务进行设备的采购。
Ø保安人员通过该系统登记出入人员情况、特殊事件情况等
Ø人事部门的工作人员通过登陆该系统进行用户档案的管理、接受用户投诉和小区工作人员的管理。
2.3主要业务模型的建立
由本系统初步业务模型我们可以看出本系统具有六大功能，现在通过建模工具给出相应的用例图，并对用例进行详细描述，用活动图描述参与者与系统的交互过程。
以下是分别建立业务模型：
图三：
ExamineExpense初始业务用例图
通过ExamineExpense初始业务用例图我们可以得到此用例的详细描述见下表：
表二：
ExamineExpense初始业务详细描述
简短描述
ExamineExpense使user可以查看缴费情况
逐步描述
1.用户输入自己的登陆账号和密码进入自己的信息页面
2.查看自己的历史缴费情况
3.检查自己的未交费项目和应该缴费的金额
4.财务人员进入小区财务系统
5.查看用户所需要缴纳费用
5.1查看已缴费的记录
5.2查看未缴纳费用的记录
6.查看用户历史缴费记录
7..查看员工工资情况
下面将给出FinanceManage初始业务用例图及其详细描述。
图四：
FinanceManage初始业务用例图
财务人员通过该系统实现的功能主要有查看住户缴费情况、催促未交费用户缴纳费用、查看小区开销情况、对小区的开支进行预算、接受用户缴费、计算员工工资和接受其他部门的财务申请并进行审核。
通过FinanceManage初始业务用例图及FinanceManage用例所要实现的功能我们可以得到此用例的详细描述见下表：
表三：
FinanceManage初始业务详细描述
简短描述
FinanceManage使财务人员可以对财务进行管理
逐步描述
1.财务人员通过该系统向未缴纳费用的用户发出缴费通知
2.将违规的用户信息反馈到维修部要求维修部对其采取一定措施
3.统计在特定时间内的支出总额
4.预算在下一个阶段所需要的开支
5.查看用户缴费总额和所缴费事项（包括应缴费用和违约费用）并接受用户缴费
6.计算员工工资并给他们分发工资
7.接受其他部门的财务申请
8.打印凭据
下面将给出EquipmentRepair初始业务用例图及其详细描述。
图五：
EquipmentRepair初始业务用例图
通过EquipmentRepair初始业务用例图我们可以得到此用例的详细描述见下表：
表四：
EquipmentRepair初始业务详细描述
简短描述
EquipmentRepair使user对小区设备进行管理
逐步描述
1.用户进入小区设备进行管理页面
2.输入用户所要报修的设备并描述设备出现的状况并填写信息以便维修人员可以及时与用户取得联系
3.维修人员查看用户维修请求和投诉
4.维修人员对小区设备进行统计维护
下面将给出WarehouseManage初始业务用例图及其详细描述。
图六：
WarehouseManage初始业务用例图
通过WarehouseManager初始业务用例图我们可以得到此用例的详细描述见下表：
表五：
WarehouseManager初始业务详细描述
简短描述
WarehouseManager使仓库管理员对小区仓库进行管理
逐步描述
1.查看仓库设备剩余情况
2.向财务部门申请购买设备的款项
3.接受维修部门和保洁人员的设备申请
4.记录小区仓库的设备使用后的归还情况
下面将给出PersonnelManage初始业务用例图及其详细描述。
图七：
PersonnelManage初始业务用例图
通过PersonnelManager初始业务用例图我们可以得到此用例的详细描述见下表：
表六：
PersonnelManage初始业务详细描述
简短描述
PersonnelManage使管理者对小区人员进行管理
逐步描述
1.管理者对小区的用户档案进行登记和修改
2.管理员对小区的工作人员信息进行整理
3.对搬出小区的用户或不在小区工作的工作人员信息进行备份和删除
下面将给出PersonnelManage初始业务用例图及其详细描述。
图八：
SafetyManage初始业务用例图
通过SafetyManage初始业务用例图我们可以得到此用例的详细描述见下表：
表七：
SafetyManage初始业务详细描述
简短描述
SafetyManage使保安工作者对小区安全进行管理
逐步描述
1.保安人员通过该系统登记出入人员情况
2.保安对特殊事件情况进行处理
3.接受用户报警
2.4系统用例的建立
用例图是显示处于同一系统中的参与者和用例之间的关系的图。
一个用例图是一个包括参与者、由系统边界封闭的一组用例、参与者和用例之间的关联、用例间的联系以及参与者的泛化等模型元素的图。
在小型物业管理信息系统中由主要业务模型我们可以看出小区物业管理系统有六个大部分分别为财务查询、财务管理、设备管理、仓库管理、人员管理，系统用力如下：
图九：
小区物业管理系统的用例图
2.5活动图的绘制
活动图是UML用于对系统的动态行为建模的另一种常用工具，它描述活动的顺序，展现从一个活动到另一个活动的控制流。
活动图在本质上是一种流程图。
活动图着重表现从一个活动到另一个活动的控制流，是内部处理驱动的流程。
活动图可以描述参与者与系统的交互过程，可以形象的表示系统的功能以及数据流的流向、描述一个操作的执行过程中所完成的工作或者动作和对象内部的工作，小区物业管理系统的活动图如下：
图十：
小区物业管理系统的活动图
三、分析工作流
分析小区物业管理系统的工作流有两个目标。
首先，我们希望得到对需求的更深入理解。
其次，我们希望以某种方式描述需求，这种方式要求易于维护并提供了对要开发的信息系统结构的深入理解。
3.1系统类的提取
在统一过程中有三种类：
实体类、边界类和控制类。
在小区物业管理系统中 EquipmentClass就是一个实体类，因为在系统中不得不长期保留关于设备的信息。
下面我们将分别提取系统中的类并进行类建模。
3.1.1实体类的提取
实体类提取包含三个步骤，他们是迭代式和增量式地执行：
1、功能性建模。
展示所有用例的方案。
2、类建模。
确定实体类及其属性。
然后确定实体类之间的相互关系及交互。
以类图的形式展示该信息。
3、动态建模。
确定由每一个实体类或子类执行的操作或者对他们执行的操作。
以状态图的形式展示该信息。
由需求分析我们可以知道用例图描绘了信息系统及信息系统的用户之间的交互。
例如用户执行FinanceManage系统功能。
但用例表达不出基本的关联和对象的属性。
类图不仅解决了关联和属性而且还可以表达出扩展信息，例如，每个类中的方法、属性类型信息和属性的可见性以及两个对象之间的导航。
在ExamineExpense初始业务用例图和FinanceManage初始业务用例图中我们可以得到用例中的类主要有FinanceClass（财务类）、AccountClass（账户类）、 CapitalClass（资金类）。
图十一：
关于财务的初始类图
通过EquipmentRepair初始业务用例图我们可以得到用例中的类主要有EquipmentClass（设备类）、RepairToolsClass（维修工具类）、CleaningToolsClass（清洁工具类）、OtherToolsClass（其他工具类）。
图十二：
关于设备的初始类图
由于WarehouseManager和SafetyManage初始业务用例所涉及的用例很少而且在系统的开发中也很容易理解，所以在此就不讨论它们的类图。
以下我们通过PersonnelManage初始业务用例图可以得到用例中的类主要有PersonnelClass（人员类）、WorkerClass（工作人员类）、ResidentClass（用户类）、OtherPersonnelClass（其他人员类）。
图十三：
关于人员的初始类图
3.1.2边界类的提取
与实体类不同，边界类通常易于提取。
一般来讲，每个输入屏幕、输出屏幕和打印的报告都是通过类来建模的。
所以通过对小区物业管理系统的分析，我们可以得到相应的初始边界类如下：
表八：
系统初始边界类
UserInterfaceClass
PrintReportClass
3.1.3控制类的提取
控制类通常与边界类一样易于提取。
一般来讲，每种重要的计算都是通过控制类来建模的。
在小区物业管理系统中涉及的计算有三个ComputebreakcontractMoneyClass（计算违约金）、ComputeExpenseClass（计算应缴费用）、ComputePayMoney（计算支出费用）。
3.2系统的状态图绘制
状态图反映了由信息系统执行的或为其执行的所有操作，以表示引起从一种状态到另一种状态的转变的那些事件。
根据给出的小区物业管理系统中用例图及其描述，我们可以绘制出其系统的状态图如下：
图十四：
小区物业管理系统的状态图
3.3交互图的绘制
交互图是描述对象之间的关系和对象之间的信息传递的图，是由组成活动者、对象、生命线、控制焦点、消息交互片断构成。
主要有两种图状态图和顺序图。
对于小区物业管理系统我们通过建立顺序图来描述对象之间的关系。
其步骤为：
✧确定交互的范围
✧识别参与交互的对象和活动者
✧设置对象生命线的开始和结束
✧设置消息
✧细化消息
关于财务对象之间的关系以及对象之间的信息传递的时序图如下：
图十五：
财务对象之间的时序图
设备的类有主要有EquipmentClass（设备类）、RepairToolsClass（维修工具类）、CleaningToolsClass（清洁工具类）、OtherToolsClass（其他工具类）。
关于设备对象之间的关系以及对象之间的信息传递的时序图如下：
图十六：
设备对象之间的时序图
对于其他几个用例图的时序图这里就不在给出，因为他们所涉及的类不是很多，而且也很容易找到他们之间所关联的消息。
3.4系统功能的划分及包图的绘制
对于一个较为复杂的系统建模，要使用大量的模型元素，这时就有必要把这些元素进行组织。
把关系密切的模型元素组织在一起，不但可以控制模型的复杂度，有助于理解，而且也有助于按组来控制模型元素的可见性。
在小区物业管理系统中总共有7个用户，所以在功能划分的时候我们将按照这些模块分别给出各自的功能。
在第一个模块中住户通过系统查看自己的缴费情况、网上报修、网上投诉和网上缴费。
在第二个模块中财务人员通过该系统查看住户缴费情况、催促未交费用户缴纳费用、查看小区开销情况和接受用户缴费。
在第三个模块中保洁人员通过该系统接受用户请求、查看小区卫生情况、查看小区绿化情况、查看自己的工作及工作区域。
在第四个模块中维修人员通过登陆该系统查看用户请求、查看公共设施的基本情况并决定是否进行维护。
在第五个模块中仓库管理员通过登陆该系统查看仓库库存信息、并向财务部申请财务进行设备的采购。
在第六个模块中保安人员通过该系统登记出入人员情况、特殊事件情况等。
在第七个模块中人事部门的工作人员通过登陆该系统进行用户档案的管理、接受用户投诉和小区工作人员的管理。
下面我们将给系统的包图。
包是UML的模型元素之一，包可以包含其他包和类。
包与包之间可以有关系，如依赖等。
包是一种分组机制，他把一些模型元素组织成语义上相关的组，包中拥有或涉及的所有模型元素叫做包的内容。
包图绘制原则
a）最小化包之间的依赖，最小化每个包中的public、protected元素的个数，最大化每个包中private元素个数
b）在建模时应该避免包之间的循环依赖，也就是不能够包含相互依赖的情况，对于这种情况应进行分析：
包图使用应注意以下几个方面：
•每个包都应该是在概念、语义上相互接近的元素组成；
•对每个包找出应标记为公共的元素，但应尽可能地少；
•一般使用默认的《use》构造型，在映射到编程时考虑明确《import》构造型；
•考虑采用泛化来对特殊包进行建模。
•在表示这种模型时，注意只标明对每个包都起核心作用的元素；另外也可以标识每个包的文档标记值，以使其更加清晰对体系结构建模
•对体系结构进行建模（程序分层），是包图更有意义的一个用途。
体系结构是一个软件系统的核心逻辑结构
•常用的体系结构模式包括分层、MVC、管道、黑板、微内核等，而在应用软件中，分层和MVC
通过上的分析我们可以得出小区物业管理系统的包图如下：
图十七：
系统的包图
四、设计工作流
4.1类图的细化
类图技术是OO方法的核心技术，应用非常广泛，其中类、对象以及它们之间的关系是最基本的建模元素。
类模型和对象模型揭示了系统的结构。
类是具有相似结构、行为和关系的一组对象结合。
类的获取和命名。
最顶部的格子包含类的名字。
类的命名应尽量用应用领域中的术语,应明确、无歧义，以利于开发人员与用户之间的相互理解和交流。
类的获取是一个依赖于人的创造力的过程,必须与领域专家合作,对研究领域仔细地分析，抽象出领域中的概念，定义其含义及相互关系，分析出系统类，并用领域中的术语为类命名。
类的属性。
中间的格子包含类的属性，用以描述该类对象的共同特点。
类的属性应能描述并区分每个特定的对象而且只有系统感兴趣的特征才包含在类的属性中。
因此小区物业管理系统的财务模块的类图可以细化成下图形式：
图十八：
关于财务类图的细化
在关于财务类图的细化中FinanceClass。
其中WaterRAte代表水费、PowerRAte代表电费、OtherRate代表物业管理费。
（1）管理服务人员的工资和按规定提取的福利费；
（2）公共设施、设备日常运行、维护及保养费；（3）绿化管理费；（4）清洁卫生费；（5）保安费；（6）办公费；（7）物业管理单位固定资产折旧费；（8）法定税费。
操作ComputeEXpenses（）代表费用的计算，STatisticUnpaid（）代表未交费用的统计，ExamineExpense（）代表对费用进行查看。
AccountClass中AccountName代表账户名，AccountId代表账户号码。
操作Pay（）代表支出，Income代表收入。
CaptialClass类中CaptialSum代表总资产，Add（）代表增加资产，Reduce（）代表减少资产。
图十九：
关于设备类图的细化
在关于设备类图的细化中EquipmentClass，EquipmentName代表设备的名字，EquipmentAmount代表设备的数量，EquipmentLoanTime代表设备借出的时间，EquipmentReturnTime代表设备归还时间。
操作EquipmentCount（）代表对设备的统计。
在RepairToolsClass中，RepairToolsName代表维修设备名，RepairToolsID代表维修设备的D号，RepairToolslendWorker代表维修设备的借出人员。
操作ConfirmLend（）代表确认借出，ConfirmReturn（）代表确认归还。
同理CleaningToolsClass、OtherToolsClass具有相似的属性和功能。
图二十：
关于人员类图的细化
在关于人员类图的细化中，关于PersonnelClass中的属性PersonnelName代表人员名、PersonnelID代表人员的ID，PersonnelTelphone代表人员的联系方式、PersonnelAdr代表人员的地址、PersonnelAge代表人员的年龄、PersonnelSex代表人员的性别。
操作AddSet（）代表增加一个人员记录，DeleteSet（）代表删除一个人员记录，ReviseSet（）代表修改一个人员记录，FoundSet（）代表查看一个人员的记录。
在WorkerClass除了继承PersonnelClass中的属性外还具有自己特别的属性如：
PositionName代表工作者的工作性质，WorkerTime代表工作者的工作时间，MonthAlary代表工作者的工作月薪。
同样在ResidentClass中也具有自己的属性，EnterTime表示用户入住小区的时间，WorkSituation代表用户的工作情况。
操作InquiryIfo（）可以执行对自己信息的查看。
4.2数据库设计
系统将在工作过程中获得大量数据这就必须存储和管理这些数据.因此要建立一个良好的数据组织结构和数据库使整个系统都可以迅速、方便、准确地调用管理所需的数据.在设计过程中需对各种表单的数据项进行研究.选择保留数据项将这些数据项列出几个基本关系表去掉重复项.对这些表的形式进
升级会员 