基于UML的小区物业管理系统的分析与设(共26页).doc

精选优质文档-倾情为你奉上基于UML的小区物业管理系统的分析与设计一、项目背景随着人们生活水平的不断提高,伴随着人们住宅小区的规模也不断扩大和业主的不断增多,像小区中的汽车、公共设施,小区的安全、小区的各项维修等都将越来越复杂,物业工作人员的工作量也随之增加。但一直以来许多物业公司都是使用传统人工的方式来对各种物业相关数据的处理,这种管理方式当然会存在着许多缺点,例如管理的效率低、相关数据的保密性差,随时间的推移,还会产生大量的文件和多余数据,将会给我们的查找、管理带来不少的麻烦。另外我国农村城市化的脚步不断加快，小区的出现成为了这一进程的历史见证。但如何对小区进行有效的管理是现代社会所不得不深思的事情。现代的小区有很多的弊端，如：设施陈旧、管理松懈、乱收费以及治安混乱等等！很多人对小区的抱着不满的情绪，如果这种情况再继续恶化下去，那么城市化的进程势必会遭到难以想象的阻碍。因此，为提升小区物业管理的网上技术水平和更新管理理念,提高物业管理工作的效率和质量,降低物业管理成本,本文结合我国小区物业管理的发展趋势、小区物业管理的工作特点以及物业管理的实际需要,采用面向对象的分析方法与结构化的设计方法对系统进行分析。开发合理的小区物业管理系统对提高小区的管理效率、增加居民的满意度有着很大的作用，同时也是为我国顺利进行农村城市化所迈出的重要一步。1.1项目必要性分析为了了解项目的必要性我们必须对项目的实施就有一定的认识，以下是我通过网络、书籍以及调查所得到的小区业务基本信息1）小区管理中为住户提供的业务比较繁多，主要有公共设备的管理、小区绿化、文化娱乐服务、住户投诉、费用的收取等。小区的主要部门主要有财务部、保洁部、维修部、仓库部、警卫部等。2）小区工作人员的主要职能有，库管人员管理主要设备，记录设备的状态是否完好，并对其他人员如保洁员、维修员领取设备进行登记，设备缺货时及时向采购部反馈。采购人员主要采购管理下去需要的设备，保安人员主要负责小区的安全，对小区的人员流动进行登记和记录小区的异常情况和突发事件等。保洁人员主要负责小区的卫生以及小区的绿化。维修人员管理小区公共设备，收取用户的保修信息等。3）各种单据的管理，如收费单据、未缴费用单据、催费通知、住户档案、进货单据、销售单据等。通过上述的业务描述我们可以看出小区的管理是一项复杂的任务，而且在小区业务管理的运作中存在着很多不足之处，主要有：单据票据繁多，要记录的项目太多，在整理收集与统计方面需要花费大量的人力，有时由于一些人为地失误，使单据票据丢失。由于人员无法准确的定位，所以很多小区的卫生恶化、设施常年无人过问、维护效率极其低下等。因此小区物业管理系统的需要是解决这一系列问题的必要条件。1.2项目可行性分析通过调查我们发现规模比较小的小区管理系统的管理操作还是通过手工操作，记录，管理，工作效率很低，而且手工操作还存在着诸多弊端,由于不可避免的人为因素,造成数据的遗漏、误报，计算错误，数据丢失率很高。同时在统计数据,数据分析等方面还存在许多不足之处,统计等操作耗时,耗力,不能够很好的满足管理者的需求.而这些问题在用上一个科学的管理系统以后几率会大大的缩小。因为，这些发生在人员方面的因素对电脑而言完全可以克服。用户通过登陆小区物业管理系统可以查询自己的缴费情况，以及进行网上报修，网上缴费等，小区管理人员通过小区物业管理系统可以优化管理业务，合理分配管理人员是小区的管理效率大大提高。下面是通过网上收集的数据对小区满意度的调查。图一：小区满意度调查饼状图二、需求工作流2.1问题域的描述按照现在的小区业务的管理模式，小区物业管理系统主要包括财务管理、保洁管理、维修管理、仓库管理、安全管理、人员管理等。财务管理主要负责费用的收取、接受用户财务状况的查询、通知业主未缴纳的费用、自主打印凭据、小区正常运行的开销。保洁管理主要包括小区卫生状况的统计、区域保洁人员的分配、小区的绿化管理、接受用户请求。维修管理的主要功能包括接受用户的维修请求、小区公共设施的检查与维护。仓库管理的主要功能有小区设备的记录，自动统计缺失设备。安全管理的功能包括人员出入的统计、特殊情况发生的统计、接受用户的报警请求。人员管理的功能主要包括对用户档案的管理、小区工作人员的管理。其涉及得主要术语见术语表：表一：系统涉及的主要术语绿化小区的绿色区域地带记录对特殊情况的描述设备小区工作人员所需要的工具催费对欠费的住户催促其缴纳未交费用仓库小区存放设备的地方档案记录住户的一些信息2.2系统整体结构的设计通过描述问题域，我们可以知道整个系统操作业务人员角色包括：业主、保安、管理员、财务人员、维修人员、系统管理员。每个角色在系统中承担着不同的任务, 物业管理部门通过使用统一的访问界面进行日常的小区管理, 业主则可以通过小区网络连接到小区物业管理系统进行有必要的报修或查询。本系统在小区管理中以数字服务为核心, 充分发挥网络优势, 解放劳动力, 集中有限人力和物力资源, 实现管理的高效性和快捷性, 从而降低成本, 提高管理水平。对于小区物业管理系统的系统设计的原则主要由以下几个方面：1、系统性。从整个系统的角度进行考虑，系统的代码要统一，设计规范要标准，传递语言要尽可能一致，对系统的数据采集要做到数出一处、全局共享，使一次输入得到多次利用。2、灵活性。系统应具有较好的开放性和结构的可变性，采用模块化结构，提高各模块的独立性，尽可能减少模块间的数据偶合，使各子系统间的数据依赖减至最低限度。3、可靠性。可靠性是指系统抵御外界干扰的能力及受外界干扰时的恢复能力。一个成功的管理信息系统必须具有较高的可靠性，如安全保密性、检错及纠错能力、抗病毒能力等。4、经济性。经济性指在满足系统需求的前提下，尽可能减小系统的开销。一方面，在硬件投资上不能盲目追求技术上的先进，而应以满足应用需要为前提；另一方面，系统设计中应尽量避免不必要的复杂化，各模块应尽量简洁，以便缩短处理流程、减少处理费用。在充分考虑小区物业管理系统系统整体结构设计原则上，我们给出了小区物业管理系统的整体结构图如下：小区物业管理系统财务管理保洁管理仓库管理人员管理安全管理费用收取通知未缴纳费用用户财务查询卫生状况的统计小区的绿化管理保洁人员的分配小区设备的记录自动统计缺失设备人员出入的统计特殊情况发生的统计用户档案的管理小区工作人员的管理小区运行开销自主打印凭据维修管理接受用户的维修请求公共设施的检查与维护接受用户的报警请求图二：本系统总体结构 通过对小区物业管理系统总体结构的描述我们可以得到本系统初步业务项目Ø 住户通过系统查看自己的缴费情况、网上报修、网上投诉Ø 财务人员通过该系统查看住户缴费情况、催促未交费用户缴纳费用、查看小区开销情况和接受用户缴费。Ø 保洁人员通过该系统接受用户请求、查看小区卫生情况、查看小区绿化情况、查看自己的工作及工作区域。Ø 维修人员通过登陆该系统查看用户请求、查看公共设施的基本情况并决定是否进行维护。Ø 仓库管理员通过登陆该系统查看仓库库存信息、并向财务部申请财务进行设备的采购。Ø 保安人员通过该系统登记出入人员情况、特殊事件情况等Ø 人事部门的工作人员通过登陆该系统进行用户档案的管理、接受用户投诉和小区工作人员的管理。2.3主要业务模型的建立 由本系统初步业务模型我们可以看出本系统具有六大功能，现在通过建模工具给出相应的用例图，并对用例进行详细描述，用活动图描述参与者与系统的交互过程。以下是分别建立业务模型：图三：Examine Expense初始业务用例图 通过Examine Expense初始业务用例图我们可以得到此用例的详细描述见下表：表二：Examine Expense初始业务详细描述简短描述Examine Expense 使user可以查看缴费情况逐步描述1. 用户输入自己的登陆账号和密码进入自己的信息页面2. 查看自己的历史缴费情况3. 检查自己的未交费项目和应该缴费的金额4. 财务人员进入小区财务系统5. 查看用户所需要缴纳费用5.1 查看已缴费的记录 5.2 查看未缴纳费用的记录6. 查看用户历史缴费记录7. .查看员工工资情况下面将给出Finance Manage初始业务用例图及其详细描述。图四：Finance Manage初始业务用例图财务人员通过该系统实现的功能主要有查看住户缴费情况、催促未交费用户缴纳费用、查看小区开销情况、对小区的开支进行预算、接受用户缴费、计算员工工资和接受其他部门的财务申请并进行审核。通过Finance Manage初始业务用例图及Finance Manage用例所要实现的功能我们可以得到此用例的详细描述见下表：表三：Finance Manage初始业务详细描述简短描述Finance Manage 使财务人员可以对财务进行管理逐步描述1. 财务人员通过该系统向未缴纳费用的用户发出缴费通知2. 将违规的用户信息反馈到维修部要求维修部对其采取一定措施3. 统计在特定时间内的支出总额4. 预算在下一个阶段所需要的开支5. 查看用户缴费总额和所缴费事项（包括应缴费用和违约费用）并接受用户缴费6. 计算员工工资并给他们分发工资7. 接受其他部门的财务申请8. 打印凭据下面将给出Equipment Repair初始业务用例图及其详细描述。图五：Equipment Repair初始业务用例图通过Equipment Repair初始业务用例图我们可以得到此用例的详细描述见下表：表四：Equipment Repair初始业务详细描述简短描述Equipment Repair 使user对小区设备进行管理逐步描述1. 用户进入小区设备进行管理页面2. 输入用户所要报修的设备并描述设备出现的状况并填写信息以便维修人员可以及时与用户取得联系3. 维修人员查看用户维修请求和投诉4. 维修人员对小区设备进行统计维护下面将给出Warehouse Manage初始业务用例图及其详细描述。图六：Warehouse Manage初始业务用例图通过Warehouse Manager初始业务用例图我们可以得到此用例的详细描述见下表：表五： Warehouse Manager初始业务详细描述简短描述Warehouse Manager 使仓库管理员对小区仓库进行管理逐步描述1. 查看仓库设备剩余情况2. 向财务部门申请购买设备的款项3. 接受维修部门和保洁人员的设备申请4. 记录小区仓库的设备使用后的归还情况下面将给出Personnel Manage初始业务用例图及其详细描述。图七：Personnel Manage初始业务用例图通过Personnel Manager初始业务用例图我们可以得到此用例的详细描述见下表：表六：Personnel Manage初始业务详细描述简短描述Personnel Manage 使管理者对小区人员进行管理逐步描述1. 管理者对小区的用户档案进行登记和修改2. 管理员对小区的工作人员信息进行整理3. 对搬出小区的用户或不在小区工作的工作人员信息进行备份和删除下面将给出Personnel Manage初始业务用例图及其详细描述。图八：Safety Manage初始业务用例图通过Safety Manage初始业务用例图我们可以得到此用例的详细描述见下表：表七：Safety Manage初始业务详细描述简短描述Safety Manage 使保安工作者对小区安全进行管理逐步描述1. 保安人员通过该系统登记出入人员情况2. 保安对特殊事件情况进行处理3. 接受用户报警2.4系统用例的建立用例图是显示处于同一系统中的参与者和用例之间的关系的图。一个用例图是一个包括参与者、由系统边界封闭的一组用例、参与者和用例之间的关联、用例间的联系以及参与者的泛化等模型元素的图。在小型物业管理信息系统中由主要业务模型我们可以看出小区物业管理系统有六个大部分分别为财务查询、财务管理、设备管理、仓库管理、人员管理，系统用力如下：图九：小区物业管理系统的用例图2.5活动图的绘制活动图是UML用于对系统的动态行为建模的另一种常用工具，它描述活动的顺序，展现从一个活动到另一个活动的控制流。活动图在本质上是一种流程图。活动图着重表现从一个活动到另一个活动的控制流，是内部处理驱动的流程。活动图可以描述参与者与系统的交互过程，可以形象的表示系统的功能以及数据流的流向、描述一个操作的执行过程中所完成的工作或者动作和对象内部的工作，小区物业管理系统的活动图如下：图十：小区物业管理系统的活动图三、分析工作流分析小区物业管理系统的工作流有两个目标。首先，我们希望得到对需求的更深入理解。其次，我们希望以某种方式描述需求，这种方式要求易于维护并提供了对要开发的信息系统结构的深入理解。3.1系统类的提取 在统一过程中有三种类：实体类、边界类和控制类。在小区物业管理系统中 Equipment Class就是一个实体类，因为在系统中不得不长期保留关于设备的信息。下面我们将分别提取系统中的类并进行类建模。3.1.1实体类的提取实体类提取包含三个步骤，他们是迭代式和增量式地执行：1、 功能性建模。展示所有用例的方案。2、类建模。确定实体类及其属性。然后确定实体类之间的相互关系及交互。以类图的形式展示该信息。3、动态建模。确定由每一个实体类或子类执行的操作或者对他们执行的操作。以状态图的形式展示该信息。由需求分析我们可以知道用例图描绘了信息系统及信息系统的用户之间的交互。例如用户执行Finance Manage系统功能。但用例表达不出基本的关联和对象的属性。类图不仅解决了关联和属性而且还可以表达出扩展信息，例如，每个类中的方法、属性类型信息和属性的可见性以及两个对象之间的导航。在Examine Expense初始业务用例图和Finance Manage初始业务用例图中我们可以得到用例中的类主要有Finance Class(财务类)、Account Class(账户类)、 Capital Class(资金类)。图十一：关于财务的初始类图通过Equipment Repair初始业务用例图我们可以得到用例中的类主要有Equipment Class（设备类）、Repair Tools Class(维修工具类)、Cleaning Tools Class(清洁工具类)、Other Tools Class(其他工具类)。图十二：关于设备的初始类图由于Warehouse Manager和Safety Manage初始业务用例所涉及的用例很少而且在系统的开发中也很容易理解，所以在此就不讨论它们的类图。以下我们通过Personnel Manage初始业务用例图可以得到用例中的类主要有Personnel Class(人员类)、Worker Class(工作人员类)、Resident Class(用户类)、Other Personnel Class(其他人员类)。图十三：关于人员的初始类图3.1.2边界类的提取与实体类不同，边界类通常易于提取。一般来讲，每个输入屏幕、输出屏幕和打印的报告都是通过类来建模的。所以通过对小区物业管理系统的分析，我们可以得到相应的初始边界类如下：表八：系统初始边界类 User Interface ClassPrint Report Class3.1.3控制类的提取控制类通常与边界类一样易于提取。一般来讲，每种重要的计算都是通过控制类来建模的。在小区物业管理系统中涉及的计算有三个Compute break contract Money Class(计算违约金)、Compute Expense Class(计算应缴费用)、Compute Pay Money(计算支出费用)。3.2系统的状态图绘制 状态图反映了由信息系统执行的或为其执行的所有操作，以表示引起从一种状态到另一种状态的转变的那些事件。根据给出的小区物业管理系统中用例图及其描述，我们可以绘制出其系统的状态图如下：图十四：小区物业管理系统的状态图3.3交互图的绘制 交互图是描述对象之间的关系和对象之间的信息传递的图，是由组成活动者、对象、生命线、控制焦点、消息交互片断构成。主要有两种图状态图和顺序图。对于小区物业管理系统我们通过建立顺序图来描述对象之间的关系。其步骤为：² 确定交互的范围² 识别参与交互的对象和活动者² 设置对象生命线的开始和结束² 设置消息² 细化消息关于财务对象之间的关系以及对象之间的信息传递的时序图如下：图十五：财务对象之间的时序图设备的类有主要有Equipment Class（设备类）、Repair Tools Class(维修工具类)、Cleaning Tools Class(清洁工具类)、Other Tools Class(其他工具类)。关于设备对象之间的关系以及对象之间的信息传递的时序图如下：图十六：设备对象之间的时序图对于其他几个用例图的时序图这里就不在给出，因为他们所涉及的类不是很多，而且也很容易找到他们之间所关联的消息。3.4系统功能的划分及包图的绘制对于一个较为复杂的系统建模，要使用大量的模型元素，这时就有必要把这些元素进行组织。把关系密切的模型元素组织在一起，不但可以控制模型的复杂度，有助于理解，而且也有助于按组来控制模型元素的可见性。在小区物业管理系统中总共有7个用户，所以在功能划分的时候我们将按照这些模块分别给出各自的功能。在第一个模块中住户通过系统查看自己的缴费情况、网上报修、网上投诉和网上缴费。在第二个模块中财务人员通过该系统查看住户缴费情况、催促未交费用户缴纳费用、查看小区开销情况和接受用户缴费。在第三个模块中保洁人员通过该系统接受用户请求、查看小区卫生情况、查看小区绿化情况、查看自己的工作及工作区域。在第四个模块中维修人员通过登陆该系统查看用户请求、查看公共设施的基本情况并决定是否进行维护。在第五个模块中仓库管理员通过登陆该系统查看仓库库存信息、并向财务部申请财务进行设备的采购。在第六个模块中保安人员通过该系统登记出入人员情况、特殊事件情况等。在第七个模块中人事部门的工作人员通过登陆该系统进行用户档案的管理、接受用户投诉和小区工作人员的管理。下面我们将给系统的包图。包是UML的模型元素之一，包可以包含其他包和类。包与包之间可以有关系，如依赖等。包是一种分组机制，他把一些模型元素组织成语义上相关的组，包中拥有或涉及的所有模型元素叫做包的内容。包图绘制原则a) 最小化包之间的依赖，最小化每个包中的public、protected元素的个数，最大化每个包中private元素个数b) 在建模时应该避免包之间的循环依赖，也就是不能够包含相互依赖的情况，对于这种情况应进行分析：包图使用应注意以下几个方面：每个包都应该是在概念、语义上相互接近的元素组成；对每个包找出应标记为公共的元素，但应尽可能地少；一般使用默认的use构造型，在映射到编程时考虑明确import构造型；考虑采用泛化来对特殊包进行建模。在表示这种模型时，注意只标明对每个包都起核心作用的元素；另外也可以标识每个包的文档标记值，以使其更加清晰对体系结构建模对体系结构进行建模（程序分层），是包图更有意义的一个用途。体系结构是一个软件系统的核心逻辑结构常用的体系结构 模式包括分层、MVC、管道、黑板、微内核等，而在应用软件中，分层和MVC通过上的分析我们可以得出小区物业管理系统的包图如下：图十七：系统的包图四、设计工作流4.1类图的细化类图技术是OO方法的核心技术，应用非常广泛，其中类、对象以及它们之间的关系是最基本的建模元素。类模型和对象模型揭示了系统的结构。类是具有相似结构、行为和关系的一组对象结合。类的获取和命名。最顶部的格子包含类的名字。类的命名应尽量用应用领域中的术语,应明确、无歧义，以利于开发人员与用户之间的相互理解和交流。类的获取是一个依赖于人的创造力的过程,必须与领域专家合作,对研究领域仔细地分析，抽象出领域中的概念，定义其含义及相互关系，分析出系统类，并用领域中的术语为类命名。类的属性。中间的格子包含类的属性，用以描述该类对象的共同特点。类的属性应能描述并区分每个特定的对象而且只有系统感兴趣的特征才包含在类的属性中。因此小区物业管理系统的财务模块的类图可以细化成下图形式：图十八：关于财务类图的细化在关于财务类图的细化中Finance Class。其中WaterRAte代表水费、PowerRAte代表电费、OtherRate代表物业管理费。 (1)管理服务人员的工资和按规定提取的福利费；(2)公共设施、设备日常运行、维护及保养费；(3)绿化管理费；(4)清洁卫生费；(5)保安费；(6)办公费；(7)物业管理单位固定资产折旧费；(8)法定税费。操作ComputeEXpenses()代表费用的计算，STatisticUnpaid()代表未交费用的统计，ExamineExpense()代表对费用进行查看。Account Class中AccountName代表账户名，AccountId代表账户号码 。操作Pay()代表支出，Income代表收入。Captial Class类中CaptialSum代表总资产，Add()代表增加资产，Reduce()代表减少资产。图十九：关于设备类图的细化在关于设备类图的细化中Equipment Class，EquipmentName代表设备的名字，EquipmentAmount代表设备的数量，EquipmentLoanTime代表设备借出的时间，EquipmentReturnTime代表设备归还时间。操作EquipmentCount()代表对设备的统计。在Repair Tools Class中，RepairToolsName代表维修设备名，RepairToolsID代表维修设备的D号，RepairToolslendWorker代表维修设备的借出人员。操作ConfirmLend()代表确认借出，ConfirmReturn()代表确认归还。同理Cleaning Tools Class、Other Tools Class具有相似的属性和功能。图二十：关于人员类图的细化在关于人员类图的细化中，关于Personnel Class中的属性PersonnelName代表人员名、PersonnelID代表人员的ID，PersonnelTelphone代表人员的联系方式、PersonnelAdr代表人员的地址、PersonnelAge代表人员的年龄、PersonnelSex代表人员的性别。操作AddSet()代表增加一个人员记录，DeleteSet()代表删除一个人员记录，ReviseSet()代表修改一个人员记录，FoundSet()代表查看一个人员的记录。在Worker Class除了继承Personnel Class中的属性外还具有自己特别的属性如：PositionName代表工作者的工作性质，WorkerTime代表工作者的工作时间，MonthAlary代表工作者的工作月薪。同样在Resident Class中也具有自己的属性，EnterTime表示用户入住小区的时间，WorkSituation代表用户的工作情况。操作InquiryIfo()可以执行对自己信息的查看。4.2数据库设计系统将在工作过程中获得大量数据 这就必须存储和管理这些数据. 因此要建立一个良好的数据组织结构和数据库使整个系统都可以迅速、方便、准确地调用管理所需的数据. 在设计过程中 需对各种表单的数据项进行研究. 选择保留数据项 将这些数据项列出几个基本关系表 去掉重复项. 对这些表的形式进行了规范化定义 最后达到第3 范式的要求 而后根据对这些数据库相互之间的关系的分析建立数据库各表之间总体结构关系。数据库设计是小区物业管理系统建设的关键，小区物业管理信息数据库涉及的数据可以分为空间数据和属性数据两大类。其中空间数据是指小区内部设施的空间位置信息，主要包括公用设备位置信息、公用设施状况信息等；属性数据主要包括：人员管理信息、住户基本信息、设备管理信息、维修信息、保安管理信息以及收费管理信息等。4.2.1数据库的概念模型数据库概念模型实际上是现实世界到机器世界的一个中间层次。数据库概念模型用于信息世界的建模，是现实世界到信息世界的第一层抽象，是数据库设计人员进行数据库设计的有力工具，也是数据库设计人员和用户之间进行交流的语言。建立数据概念模型，就是从数据的观点出发，观察系统中数据的采集、传输、处理、存储、输出等，经过分析、总结之后建立起来的一个逻辑模型，它主要是用于描述系统中数据的各种状态。这个模型不关心具体的实现方式（例如如何）和细节，而是主要关心数据在系统中的各个处理阶段的状态。对于小区物业管理系统的数据库的概念模型我们将通过逐步建立，最后将所有模块整合到一起。即：迭代和增量，如下图所示为小区业务管理系统的基于E-R图的数据库概念模型设计。图二十一：小区业务管理系统的数据库概念模型4.2.2数据库的逻辑模型逻辑数据模型反映的是系统分析设计人员对数据存储的观点，是对概念数据模型进一步的分解和细化。逻辑数据模型是根据业务规则确定的，关于业务对象、业务对象的数据项及业务对象之间关系的基本蓝图。 逻辑数据模型的内容包括所有的实体和关系，确定每个实体的属性，定义每个实体的主键，指定实体的外键，需要进行范式化处理。 逻辑数据模型的目标是尽可能详细的描述数据，但并不考虑数据在物理上如何来实现。 在小区物业中，逻辑模型是着重用逻辑的过程或主要的业务来描述小区物业，描述系统要“做什么”，或者说具有哪些功能。小区物业的开发策略，即通过对系统进行分析得到系统的逻辑模型, 进而从逻辑模型求得最优的。数据库的每个主题都是由多个表来实现的，这些表之间依靠主题的主键联系在一起，形成一个完整的主题。在概念模型设计时，我们就确定了数据库的基本主题，并对每个主题的主键、基本内容等做了描述。在这一步里，我们将要对选定的当前实施的主题进行模式划分，形成多个表，并确定各个表的关系模式，即将数据库的概念模型转换成关系模型。现在将小区物业数据库的概念模型转换成关系模型如下：Finance拥有属性WaterRate（水费）、PowerRate（电费）、FinanceID（财务编号）、OtherRate（其他费用）Possess拥有属性FinanceID（财务编号）、accountId（账户号码）Account拥有属性accountId（账户号码）、accountname（账户名）、accountmoney（账户金额）purchase拥有属性EquipmentID（设备编号）、FinanceID（财务编号）Equipment拥有属性Equipmentname（设备名）、EquipmentID（设备编号）、EquipmentClass（设备性质）、EquipmentLoanTime（设备借出时间）、EquipmentReturnTime（设备归还时间）Management拥有属性PersonnelID（人员编号）、 EquipmentID（设备编号）Personnel拥有属性WorkPlace（工作地点）、PersonnelName（人员名）、PersonnelAdr（人员住址）、PersonnelID（人员编号）PersonnelAge（人员年龄）、PersonnelTelphone（人员的联系方式）、PersonnelSex（人员的性别）Employ拥有属性PersonnelID（人员编号）、VillageID（小区编号）Village拥有属性VillageID（小区编号）、VillageName（小区名）、telphone（小区的联系电话）、Villageaddr（小区地址）其中有下划线的属性为键码。关系的键码函数决定该关系的所有其他属性，由于键码能唯一的确定一个元组，所以，也可以说关系的键码函数决定该关系的所有属性。换句话说，一个关系中的所有属性都函数依赖于该关系的键码。4.2.3数据库的实体属性设置数据库应用系统中的绝大多数关键属性均以代码形式出现, 其设置的规范性和设置的方法对系统的性能有很大影响。对实体属性进行了详细的分类, 对不同类型的实体给出了通用的设置原则和各自的设计规范。现在分别给出各个实体的属性值：表八：Finance的属性值名称类型是否为主码是否可以为空WaterRateMoney否是PowerRateMoney 否是FinanceIDChar(10)是否OtherRateMoney否是表九：Account的属性值名称类型是否为主码是否可以为空accountIdchar(10)是否accountnameChar(6)否是accountmoneymoney否是表十：Equipment的属性值名称类型是否为主码是否可以为空EquipmentnameChar(6)否是EquipmentIDChar(10)是否EquipmentClassChar(4)否是EquipmentLoanTimetime否是EquipmentReturnTimetime否是表十一：Personnel的属性值名称类型是否为主码是否可以为空WorkPlaceChar(16)否是PersonnelNameChar(6)否是PersonnelAdrChar(20)否是PersonnelIDChar(10)是否PersonnelAgedigit否是PersonnelTelphoneChar(12)否是PersonnelSexbool否是表十二：Village的属性值名称类型是否为主码是否可以为空VillageIDChar(10)是否VillageNameChar(6)否是telphoneChar(12)否是VillageaddrChar(20)否是五、系统界面设计界面是软件与用户交互的最直接的层，界面的好坏决定用户对软件的第一印象。而且设计良好的界面能够引导用户自己完成相应的操作，起到向导的作用。同时界面如同人的面孔，具有吸引用户的直接优势。设计合理的界面能给用户带来轻松愉悦的感受和成功的感觉，相反由于界面设计的失败，让用户有挫败感，再实用强大的功能都可能在用户的畏惧与放弃中付诸东流。目前界面的设计引起软件设计人员的重视的程度还远远不够，直到最近网页制作的兴起，才受到专家的青睐。我们的界面设计遵循以下基本原则：易用性、规范性、帮助、合理性、美观与协调性、独特性、安全性考虑、多窗口的应用与系统资源。图二十二：小区管理信息系统的登陆界面进入小区管理信息系统我们将看到如下的系统模块，其中财务模块对应于Finance Manage和Examine Expense两个部分，仓库模块主要包括Warehouse Manage和Equipment Repair两个部分，安全模块对应于Safety Manage部分，人员模块对应于Personnel Manage部分。将菜单栏用中文表示主要为了便于用户的使用。但由于在编码是用的是阿拉伯字符，所以在文档中对应的属性都设置为英文。主要为了便于以后的编码工作。通过下图我们可以看到，当普通用户登录到小区管理信息系统时，他只能使用用户查询和缴费两个功能，这是为了时系统更加安全和更加人性化而设置的。因为开支预算和打印凭据只有财务管理员才可以使用。现在我们以用户查询为例，来进行讲解系统的使用方法。图二十三：小区管理信息系统的主界面如果用户需要查询自己的缴费记录，便可进入用户查询界面。用户查询界面主要包含四个功能未交费用查询、已交费用查询、历史缴费查询、用户账号查询。当用户进入历史缴费查询时将出现如下的界面：图二十四：小区用户历史缴费记录查询如上图所示当用户选择2011年9月的时候点击查询，系统将调用数据库中的历史记录，当搜索完毕时将显示如下的结果界面：图二十五：小区用户历史缴费记录查询结果上面展示了用户的历史缴费记录查询步骤界面。从软件的软件面板设计来看，软件具有缩放功能，面板对功能区间划分清晰，和对话框、弹出框等风格匹配，而且节省空间，切换方便。 在菜单设计中有选中状态和未选中状态，具有一定的直观感。 六、总结 面向对象分析与设计导论-使用UML和统一过程及其课程设计的心得体会。UML是一种用来设计和编制软件系统蓝图的标准化语言，在课程设计中UML的视图模型主要采用用例图、类图、包图、对象图、状态图、活动图、顺序图来建立系统模型，而这7种模型图从不同方面对系统进行了描述，在软件开发的需求、分析、设计可以使用不同的UML视图对系统进行描述。在需求分阶段我知道了每个用例是一组场景的集合，而每个场景又是一个步骤序列，一开始我在设计用例的时候忽略了这一点。后来听同学为我讲解用例的作用才意思到，但那时我的需求工作基本上已经做的差不多了，所以在后来修改需求工作时费了很大的力气。而且在需求分阶段我对用例之间的关系的描述也很模糊，对包含与扩展关系很难去理解，在设计用例视图时不能很好地区别和真正理解它们之间的区别。后来通过询问才了解包含与扩展关系都是用带虚线的箭头表示，包含是指一个用例作为另一个用例必需的部分被使用，箭头指向被包含的用例；而扩展则是指一个用例扩充了另一个用例的功能，但这个扩充功能不是必需的，箭头指向被扩充的用例。在分析阶段在绘制系统的状态图、顺序图由于不能很好地了解系统所要实现的功能，所以绘制过程中不断的出现删除与修改。所以在以后做系统时一定要把需求分析做好才能在后继工作中顺利的进行。在设计工作流对类进行详细描述也是困难重重，因为每一个类包含很多属性及其操作，有时很难找全类的属性，这样这会为后面的开发设下了很大的阻碍。总之，课程设计是在面向对象分析与设计导论-使用UML和统一过程这门课的基础上进行的。要想学好这门课就要认真的做好课程设计，只有在实践中检验自己的知识才能不断的完善自己。在课程设计中让我真正的体会到理论学习很简单，实际操作不是很容易，所以以后我们要加强实际动手能力。七、参考文献1. 祝铭钰，基于ArclMS的Web