物业会计建模

上海殷行物业管理公司的传统业务是国有公房的租赁管理。随着国家房改政策的推行，一些租户开始买房，私房管理逐渐成为公司的核心业务。该公司的软件系统开发有两大难题：一、业务规则复杂，特别是历史遗留的各项政策法规，许多公司员工也难以理解清楚；二、系统必须能随着公司业务重心从公房租赁到私房管理的转移过程和各项政策的变化而进化，这需要一个稳定的软件构架（ Software Architecture ）。传统的瀑布式软件开发过程不能满足该系统在需求和系统进化方面的要求。 由于殷行物业管理系统需求获取的难度和对软件构架的要求，我们选择采用 RUP 来开发该系统，并最终开发出了令人满意的产品。 2 统一过程的特点 RUP 是一个通用的软件开发过程框架，它可通过裁剪和扩充应用于各种不同类型的软件系统、各种不同的应用领域、各种不同的组织和各种不同的项目规模。 RUP 具有以下三个重要特征：用例驱动、以构架为中心和迭代增量开发。 2.1 用例驱动的过程 首先，在业务建模（ Business Modeling ）工作流中，业务流程（ Business Process ）被定义为数个不同的业务用例（ Business Use Case ），其中每个业务用例都代表业务中某个特定的工作流程，业务主角（ Business Actor ）（客户、合作伙伴等）通过业务用例中的动作序列获得组织的服务。所有的业务用例和业务主角构成了组织的业务用例模型（ Business Use － Case Model ）。 在需求（ Requirements ）工作流中，根据业务用例模型确定待开发系统支持业务用例实现（ Business Use － Case Realization ）的功能并限定系统的边界，这些功能用系统用例（ System Use Case ）来描述，用例主角为组织内部的业务工人（员工、直接使用系统的客户等）。所有的系统用例和用例主角构成了系统用例模型（ System Use － Case Model ），它描述了系统的功能需求。 在分析设计工作流（ Analysis & Design ）中，开发人员使用系统用例模型作为输入，对每个系统用例进行用例分析（ Use Case Analysis ）和用例设计（ Use Case Design ），得到相应的用例实现（ Use Case Realization ）。用例实现在设计模型（ Design Model ）中提供了一种结构，用于组织与用例有关但却属于设计模型的工件。这些相关工件包括协作图（ Collaboration Diagram ）和序列图（ Sequence Diagram ），这些图使用协作对象说明用例行为。最终这些协作对象可以归纳为系统要开发的分析类和设计类。 在实施 (Implementation) 工作流中，将设计模型作为输入，将设计类实现为组件，创建实施模型（ Implementation Model ）。 在测试工作流期间，根据用例的功能描述编写测试用例（ Test Case ），验证系统是否实现了的用例的功能。因此，用例将各个工作流整合成一个流――确定用例、分析用例、设计用例、实现用例、根据用例编写测试用例来验证系统设计。 2.2 以构架为中心的过程 在 RUP 中，软件系统的构架是指系统重要组件的组织或结构，这些重要组件通过接口与那些由不断减小的组件与接口所构成的组件进行交互。构架具有以下作用： 1 ）理解系统 RUP 使用 UML 可视化建模系统的构架，并以构架为中心进行开发，这使得开发人员、管理人员及其他相关人员能够详细理解所需要做的工作，以利于他们参与系统的开发。 2 ）组织开发 构架设计师通过将系统划分为带有明确定义接口的子系统，并让开发小组负责每个子系统，可以显著减少开发组之间交流的工作量，而且接口双方的软件可独立地进化。 3 ）鼓励重用 好的构架为开发人员提供了可以在其上开展工作的稳定的骨架，它有助于开发人员知道在哪里能有效地找到可重用的元素以及发现合适的可重用的组件。 4 ）进化系统 一个具有稳定的构架的系统在分析和设计时就考虑到系统进化的需求，从而具有一定的容变能力，系统可以适度地进化。 2.3 迭代和增量开发 迭代（ Iteration ）是指带有已建立基准（ Base Line ）的计划和评估准则的独特活动序列，迭代生成系统的内部或外部发布版（ Release ）。增量（ Increment ）是指在后续迭代结束后，两个发布版本之间存在的差异（差值）。在 RUP 中，软件的生命周期是由一系列迭代组成的，这些迭代都是由软件项目分解成的许多袖珍项目（ mini-project ）。每个迭代都产生以内部版本形式交付的实际结果，其中每个内部版本会增加一个增量并表明所关注的风险得以降低。这些版本可以展示给客户，从而获得有价值的反馈以确认工作成果。早期阶段的迭代主要是关注确定项目的范围，消除关键风险和建立系统构架基准。后期迭代则不断增加增量结果，直至得到一个可对外发布的产品。迭代有助于管理层规划、组织、监控和控制项目。 迭代和增量开发具有以下的一些优点：（ 1 ）允许变更需求；（ 2 ）允许持续的集成；（ 3 ）及早降低风险；（ 4 ）有助于组织学习和提高；（ 5 ）提高复用性；（ 6 ）生成性能更强壮的产品。 3 殷行物业管理系统的开发过程 该系统主要包括以下几个模块： • 小区管理 公司经营业务所涉及的小区的信息管理。 • 房屋管理 公司所管理的房屋的资料的管理和维护。 • 房屋租赁管理 实现房屋租赁的功能。 • 租金管理 实现租户租金的收取和各项报表的编制功能。 • 私房管理费管理 实现私房用户的管理费管理。 • 系统维护 系统的用户、安全和公共信息的管理。 我们首先和用户一起对该公司的业务进行建模，建立业务用例模型，然后再一起分析这些业务用例的实现，明确用户对将要开发系统的功能需求。通过分析，我们获得了“接收房屋”、“出租可租房”、“建租户账”、“收取租金“、“租金调整”和“租金减免” 等对于决定系统构架具有重要作用的核心系统用例。因为租金调整和减免方面的业务规则非常复杂而且易变，我们决定采用 EJB 组件构架，将业务规则封装在企业 JavaBeans 中，以利用 EJB 构架在系统维护和进化方面的优势。图 1 是该系统构架的部署视图（ Deployment View ）。 由于 RUP 的特征和 EJB 技术的采用，我们在开发过程中很好地克服了需求变更和更改设计方面的难题，在开发的后期没有出现什么重大的错误设计和返工。 4 房屋租赁管理子系统的开发实例 限于篇幅，我们以房屋租赁管理子系统在第一次生命周期中的开发过程来阐述 RUP 的应用方法，这里给出的只是一个基本的过程框架。 4.1 业务建模 业务建模的目的在于了解目标组织的结构、机制、当前存在的问题、改进的可能性，并确保客户、最终用户和开发人员就目标组织达成共识，最后还要导出支持目标组织所需的系统需求。 下面是房屋租赁子系统业务用例模型中的“客户租房“业务用例（这里我借鉴了 Cockburn 的用例思想）： 用例名称 (Use case) ：客户租房 首要主角 (Primary Actor) ：客户 范围 (Scope) ：殷行物业公司 层次 (Level) ：概要目标 前提条件 (Preconditions) ：当前有空的出租房 触发条件 (Trigger) ：客户申请租房 成功保证 (Success Guarantees) ：客户顺利地租到房屋 最低保证 (Minimal Guarantees) ：客户取消租房 基本流 (Basic Flow) ： • 客户向公司提出租房申请，并提供相关材料和客户租房条件。 • 业务员审核客户材料，并根据客户租房条件检索可租房 。 • 客户选定中意的可租房。 • 业务员出租选中的可租房 。 • 计账员为客户建立租金账户 。 备选流 (Alternative Flow) ： // … （略） 2b 、未找到符合客户租房要求的房屋 3a 、客户不满意所选的房屋 a 、客户重新提出租房 条件 a1 、业务员根据客户租房条件检索可租房屋 。 这个过程可重复多次，直到客户接受房屋或取消租房。 b 、客户不再租房，流程终止。 业务用例实现由业务对象模型来描述，它是对业务工人和业务实体之间应该如何联系和协作以执行业务的一种抽象。 系统分析员使用 该模型来确定系统主角和系统用例。 4.2 需求 分析业务用例模型中“客户租房“业务用例的实现，可以确定 业务员 和计账员等业务工人 (Business Worker) 对系统的功能需求，从而得到三个系统用例，如以上斜体部分所示。采用类似方法获得的所有系统用例构成了系统的功能需求。 这时，业务用例中的业务工人映射为系统用例的主角。下面是“出租可租房”系统用例的事件流： 用例名称 (Use Case) ：出租可租房屋 首要主角 (Primary Actor)：业务员 范围 (Scope) ：殷行物业管理信息系统 层次 (Level)：用户目标 前提条件 (Preconditions)：客户选定可租房 触发条件 (Trigger)：业务员开始租房 成功保证 (Success Guarantees)：待租房屋顺利租出 最低保证 (Minimal Guarantees) ：（无） 基本流 (Basic Flow) ： • 业务员输入租户信息。 • 业务员输入租赁凭证资料。 • 系统 添加新租户 。 • 系统将 可租房转换为已租房 。 • 系统 创建租赁凭证 。 备选流 (Alternative Flow) ： //…. （略 去了备选流中的用例 ） 4.3 分析设计 分析设计工作流的主要目的是将需求转化为系统的设计以及开发出健壮的构架。涉及到的角色有构架设计师、设计师和数据库设计师等。构架设计师的主要工作是构架分析、确定设计机制等。设计师的主要工作是用例分析、用例设计、类设计和子系统设计等。数据库设计师设计系统的数据模型。 对“ 出租可租房屋 “系统用例进行用例分析和设计，得到其用例实现的协作图（图 2 ）。 从图中可得到如下的设计类：实体类（ RenterWithouAccount －未建账租户、 RentingCard －租赁凭证、 RentedHouse －已租房、 RentableHouse －可租房、 RentableHouseSet －可租房集合）、控制类（ RentingManager －租赁管理器、 TransactionManager －事务管理器）、边界类（ RentingForm －租赁窗体、 RentingCardDlg －租赁凭证资料对话框）。 根据实体类之间的关系，可以得出关于房屋租赁的局部数据模型（图 3 ）。 4.4 实施 在实施阶段，将分析设计阶段产生的设计模型作为输入，探讨如何用源代码、脚本、二进制代码、可执行体等组件来实现系统。由于我们采用了 EJB 技术，因此在 Rational Rose 中，我们将以上的实体类映射成了 EntityBean 类，控制类映射为 SessionBean 类，而边界类则映射为客户端的 JavaBean 。最终， RenterWithouAccount 、 RentingCard 、 RentingManager 等企业 Bean 类被部署在 JBoss 应用服务器中。 至此，房屋租赁管理子系统的第一个版本已经产生，用户可以试用该系统以提出改进意见和新的需求，并在下一轮迭代中加以实现。实际上，我们只经过了四轮迭代，用户便接受了该子系统。 5 结束语 由于 RUP 是一个庞大复杂的软件开发过程框架，在实际开发过程中，我们对 RUP 进行了适当的裁剪以适应系统的规模和特点，省去了开发大规模系统所需的活动和工件。 CASE 工具我们主要选用了 Rational Rose 、 ClearQuest 、 Soda 和 RequistePro ，开发工具选用了 JBuilder5 ，数据库选用了 SQLServer7 ，应用服务器选用了 JBoss ， web 服务器选择了 Tomcat 。最终我们以较低的成本，在客户要求的进度内开发出了令人满意的物业管理信息系统。