写字楼的办公室统计管理系统分析与设计文档.docx
《写字楼的办公室统计管理系统分析与设计文档.docx》由会员分享，可在线阅读，更多相关《写字楼的办公室统计管理系统分析与设计文档.docx（153页珍藏版）》请在冰豆网上搜索。
写字楼的办公室统计管理系统分析与设计文档
《面向对象分析设计》
大作业
写字楼的办公室统计管理系统分析与设计
专业：
软件工程
班级：
1107
学号：
201112164
姓名：
王圳祖
成绩：
二〇一四年六月
大连理工大学城市学院
第一章写字楼的办公室统计管理系统需求规格说明书
1.导言
1.1目的
该文档是关于用户对于写字楼的办公室统计管理系统的功能和性能的要求，重点描述了写字楼的办公室统计管理系统的功能需求，是概要设计阶段的重要输入。
本文档的预期读者是：
·设计人员；
·开发人员；
·项目管理人员；
·测试人员；
·用户。
1.2范围
该文档是借助于当前系统的逻辑模型导出目标系统的逻辑模型的，解决整个项目系统的“做什么”的问题。
在这里，没有涉及开发技术，而主要是通过建立模型的方式来描述用户的需求，为客户、用户、开发方等不同参与方提供一个交流的平台。
1.3编写说明
UML,UnifiedModelingLanguage（统一建模语言）的缩写，是一个标准的建模语言。
SA,SystemAdministrator（系统管理员）的缩写。
PM，PropertyManager（物业经理）的缩写。
PA，PropertyAdministrator（物业管理员）的缩写。
1.4术语定义
无
1.5引用标准
[1]《企业文档格式标准》，****************有限公司软件工程过程化组织
[2]《需求规格报告格式标准》，************有限公司软件工程过程化组织
1.6参考资料
[1]《UML说明》，***********************软件有限公司
[2]《需求规格报告格式标准》，************公司软件工程过程化组织
1.7版本更新信息
本文档的更新记录如表A-1所示。
表A-1版本更新记录
修改编号
修改日期
修改后版本
修改位置
修改内容概述
001
2014.3.5
0.1
全部
初始发布版本
2.系统定义
我们分别阐述一下项目的来源、背景，项目的用户特点和项目的目标。
2.1项目来源及背景
本项目是为某公司开发的一个写字楼的办公室统计管理系统，由于这个公司的规模比较小，需要管理的办公室数量有限，但是公司为了更加方便的管理办公室信息，公司希望开发一个写字楼的办公室统计管理系统能够给他们带来工作的便利，提高工作效率，同时能够精简工作人员数量。
为实现更加方便地管理办公室信息，我们开发了写字楼的办公室统计管理系统。
系统可以像纸质文件一样便于观看，更重要的是该系统能够更快速的管理写字楼的办公室信息，更精确的查找相关信息。
2.2用户的特点
本系统的用户都是写字楼的办公人员，包括两类，第一类是物业经理，他们的差异比较小，学历基本相似，工作经验也大致相同。
另外一类用户是管理用户，他们是公司内部的人，主要是物业管理员和系统管理人员。
物业管理员对办公室管理业务很熟悉，系统管理人员对系统很熟悉，总之，他们对使用管理软件比较熟悉。
2.3项目目标
本项目设定的目标如下：
·系统能够提供友好的用户界面，使操作人员的工作量最大限度的减少；
·系统具有良好的运行效率，能够达到提高生产率的目的；
·系统应有良好的可扩充性，可以容易地加入其他系统的应用；
3.应用环境
根据用户的需求陈述，可以确定本项目只有管理端，主要功能是提供管理租赁用户信息，管理缴费信息，管理房间维修信息，管理房间信息，管理入驻单位信息，结算维修费用等等。
它们的关系如图A-1所示。
图A-1写字楼的办公室统计管理系统流程图
3.1系统运行的网络环境
图A-2网络拓扑结构图
3.2系统运行的硬件环境
本系统的硬件环境如下：
客户机：
普通PC
·CPU：
P41.8GHz以上
·内存：
256MB以上
·能够运行IE5.0以上或者Netscape4.0以上版本的机器
·分辨率：
推荐使用1024×768像素
服务器
·CPU：
P41.0GHz
·内存：
1G以上
·硬盘：
80GB以上
·网卡：
KMb/s速度
数据库服务器
·CPU：
P42.0GHz
·内存：
1GB以上
·硬盘：
80GB以上
系统运行软件环境
本系统的软件环境如下：
·操作系统：
Windowsxp或以上版本
·数据库：
SQLServer2000
·开发工具包：
JDKVersion1.4.2
·Web服务器：
Tomcat
·浏览器：
IE6.0以上
4.功能规格
我们采用面向对象分析作为主要的系统建模方法，使用UML（UnifiedModelingLanguage）作为建模语言。
UML为建模活动提供了从不同角度观察和展示系统的各种特征的方法。
在UML中，从任何一个角度对系统所作的抽象都可能需要几种模型来描述，而这些来自不同角度的模型图最终组成了系统的映像。
用例描述角色（用户、外部系统以及系统处理）是如何与系统交互来完成工作的。
用例模型提供了一个非常重要的方式来界定系统边界以及定义系统功能，同时，该模型将来可以派生出动态对象模型。
设计用例时，我们遵循下列步骤：
1）识别出系统的角色。
角色可以是用户、外部系统，甚至是外部处理，通过某种途径与系统交互。
重要的是着重从系统外部执行者的角度来描述系统需要提供哪些功能，并指明这些功能的执行者（角色）是谁。
尽可能地确保所有角色都被完全识别出来。
2）描述主要的用例。
可以采取不断地问自已“这个角色究竟想过系统做什么？
”来准确地描述用例。
3）重新审视每个用例，为它们下个详尽的定义。
4.1角色定义
角色或者执行者指与系统产生交互的外部用户或者外部系统。
4.1.1入驻者
入驻者是指这个写字楼的办公室统计管理系统的外部人员，不能使用该系统。
4.1.2管理用户
管理用户是指管理端的用户，它们的关系如图A-3所示。
图A-3管理用户角色的关系
管理用户具体说明如下：
PA
·租赁用户管理者。
管理租赁用户。
·缴费信息管理者。
管理缴费信息。
·维修信息管理者。
管理维修信息。
系统管理员（SA）
·房间信息管理。
管理房间信息。
·相关单位信息管理。
管理相关单位信息。
PM（物业经理）：
·统计缴费信息。
对年度或者季度的缴费信息进行统计。
·结算维修费用。
对已经修过的房间给维修人员缴纳维修费用。
4.1.3数据库
数据库是一个与系统产生交互的外部系统，这个角色负责系统的数据查询、增加、删除和修改等操作。
4.2系统主用例图
写字楼的办公室统计管理系统只有一个主系统，该系统可以完整的管理写字楼的办公室的各项信息。
系统的主用例如图A-4所示。
图A-4系统的主用例图
4.3.1登陆（login）
登陆是指系统的各种管理人员想要操作系统必须登陆之后才能对系统进行相关操作。
具体描述如下。
图A-5是它的活动图
登录系统的用例文档
1.前置条件打开系统登录界面
2.后置条件用例成功执行后，用户获得系统使用权限。
3.扩展点无
4.事件流
4.1基本事件流
当用户想要获得系统使用权限时，用例开始。
1>用户提供用户名和密码
2>系统检索用户名（E-1）
3>系统核对密码（E-2）
4>登录成功，获得使用权限
4.2替代流
E-1用户名不存在，系统显示提示信息，用例终止。
E-2用户名和密码不匹配，用例终止
图A-5登录管理活动视图
4.3.2管理租赁用户信息
在一个写字楼内会有多个房间被用户租用，租赁用户管理模块主要是完成对每个用户的增加，删除，修改，查询等维护功能。
具体描述如下：
用例描述：
管理租赁用户信息
1.1前置条件
在这个用例开始前，物业管理员必须登录到系统中。
1.2后置条件
如果这个用例成功，在系统中建立并存储用户信息记录。
否则，系统的状态没有变化。
1.3事件流
1.3.1基流
1）物业管理员提供房间信息。
2）系统检索房间信息（E-1）。
3）物业管理员为用户分配，修改，删除使用房间房间（E-2）。
4）系统管理员保存用户信息，用例结束。
4.3.3管理缴费信息
在一个写字楼内会有多个房间被用户租用，每个用户或者房间会产生多个缴费记录，缴费信息管理模块主要是完成对每个用户缴费信息的增加，删除，修改，查询等维护功能
用例描述：
增加缴费信息
1.1前置条件
在这个用例开始前，物业管理员必须登录到系统中。
1.2后置条件
如果这个用例成功，在系统中建立并存储缴费信息记录。
否则，系统的状态没有变化。
1.3事件流
1.3.1基流
当房间用户缴纳租金时，用例启动。
1）物业管理员提供房间信息和租金信息。
2）系统检索房间信息和用户信息。
3）系统提供缴费信息查询功能，但要输入房间信息。
4）系统可以提供缴费信息删除功能，当该房间不再使用并且统计过缴费信息之后，可有物业经理选择删除。
5）物业管理员可以增加缴费记录，收取费用并记录缴费信息。
4.3.4管理维修信息
在一个写字楼内会有多个房间被用户租用，每个房间在使用过程中难免会发生物品损坏的情况，维修信息管理模块主要是完成对每个房间维修信息的增加，删除，修改，查询等维护功能。
用例描述：
管理维修信息
1.1前置条件
在这个用例开始前，物业管理员必须登录到系统中。
1.2后置条件
如果这个用例成功，在系统中建立并存储维修信息记录变化。
否则，系统的状态没有变化。
1.3事件流
1.3.1基流
当房间用户申请维修、需要查询，修改，删除维修记录时，用例启动。
1）物业管理员接受房间维修申请。
2）系统通知维修人员房间损坏情况。
3）维修人员上门进行维修。
4）维修完成后物业管理员收取维修费用并记录维修缴费信息。
5）系统提供查询维修记录功能，只要输入维修日期或者房间编号即可查询。
6）系统提供修改、删除维修记录功能，只要输入维修日期或者房间编号即可进行相关操作。
4.3.5管理房间信息
在一个写字楼内会有多个房间被用户租用，每个房间都会在系统中存在登记，房间管理管理模块主要是完成对每个房间信息的增加，删除，修改，查询等维护功能。
1.1前置条件
在这个用例开始前，系统管理员必须登录到系统中。
1.2后置条件
如果这个用例成功，在系统中建立并存储房间信息记录。
否则，系统的状态没有变化。
1.3事件流
1.3.1基流
当房间不够欲变动房间信息时，用例启动。
1）系统提供房间信息。
2）系统检索房间信息。
3）系统提供增加房间信息功能，管理员为新使用房间分配房间号码。
4）系统提供查询房间信息功能，管理员只要输入房间号即可查询该房间相关的各项信息。
4.3.6管理相关单位信息
在一个写字楼内会有多个房间被用户或者单位租用，每个单位有时租用不止一个房间，相关单位信息管理模块主要是完成对每个单位信息的增加，删除，修改，查询等维护功能。
1.1前置条件
在这个用例开始前，系统管理员必须登录到系统中。
1.2后置条件
如果这个用例成功，在系统中建立并存储单位信息记录。
否则，系统的状态没有变化。
1.3事件流
1.3.1基流
当公司或者单位入驻，离开，更换房间时，用例启动
1）系统管理员提供房间信息。
2）系统检索房间信息。
3）系统提供增加单位信息功能，当有单位前来入驻写字楼租房间的时候，管理员向系统提交单位信息并保存。
4）系统提供查询公司单位信息。
5）系统提供修改，删除单位信息功能，当单位发生变化或者该单位离开写字楼的时候，管理员向系统提交相关信息，即可完成相关操作。
4.3.7催缴房租
如果房间使用者没有按时缴纳房租，当物业管理员登录系统之后，系统将会提醒物业管理员该用户没有按时缴纳房租。
具体描述如下。
图A-6是它的活动图
催缴房租
1.1前置条件
在这个用例开始前，物业管理员必须登录到系统中，并且存在用户未及时交房租。
1.2后置条件
如果这个用例成功，系统保存修改后的信息。
否则，系统的状态没有变化。
1.3事件流
1.3.1基流
当用户未及时交房租时，用例启动
1）物业管员查看房租交纳情况。
2）系统显示所有缴费记录。
3）管理员查找未交费用户。
4）管理员向该用户发送催缴房租信息。
1.3.2替代流
无
图A-6催缴房租活动视图
4.3.8结算维修费用
当有房间申请维修并且维修完成的时候，物业经理将会为维修人员支付维修费用，具体功能描述如下。
图A-7是它的活动图
用例描述：
结算维修费用
1.1前置条件
在这个用例开始前，物业经理必须登录到系统中。
1.2后置条件
如果这个用例成功，系统保存修改后的信息。
否则，系统的状态没有变化。
1.3事件流
1.3.1基流
当需要结算维修费用时，用例启动
1）物业经理查看房间维修情况。
2）系统显示所有维修记录。
3）物业经理统计维修费用。
4）物业经理通知财务支付维修费用。
1.3.2替代流
无
图A-7结算维修费用活动视图
4.3.9统计缴费
在季度末或者年末的时候，物业经理需要统计季度或者年度缴费信息，系统提供该功能。
具体功能描述如下。
图A-8是它的活动图
用例描述：
统计缴费
1.1前置条件
在这个用例开始前，物业经理必须登录到系统中。
1.2后置条件
无
1.3事件流
1.3.1基流
当需要统计缴费情况时，用例启动
1）物业经理查看房间缴费情况。
2）系统显示所有维修记录。
3）物业经理统计缴费信息。
4）系统显示统计后的信息。
1.3.2替代流
无
图A-8统计缴费信息活动视图
5.性能需求
根据用户对本系统的要求，确定系统在响应时间、可靠性、安全性等方面有较高的必能要求。
5.1界面需求
系统的界面要求如下。
1）页面内容：
主题突出，站点定义、术语和行文格式统一、规范、明确、栏目、菜单设置和布局合理，传递的信息准确、及时。
内容丰富，文字准确，语句通顺，专用术语规范，行文格式统一规范。
2）导航结构：
页面具有明确的导航指示，且便于理解，方便用户使用。
3）技术环境：
页面大小适当，控制字体大小和版面布局。
4）艺术风格：
界面、版面形象清晰悦目、布局合理，字号大小适宜、字体选择合理，前后一致，美观大方，动与静搭配恰当，动静效果好；色彩和谐自然，与主题内容相协调。
5.2响应时间需求
当用户登录，进行任何操作的时候，系统应该及时地进行反应，反应的时间在5秒以内。
系统应能监测出各种非正常情况，如无法连接数据库服务器等，以避免出现长时间等待甚至无响应。
5.3可靠性需求
系统应保证20人可以同时操作，此时系统能正常运行，正确提示相关内容。
5.4开放性需求
系统应具有较强的灵活性，以适应将来功能扩展的需求。
5.5可扩展性需求
系统设计要求能够体现扩展性要求，以适应将来功能扩展的需求。
5.6系统安全性需求
系统有严格的权限管理功能，各功能模块需有相应的权限方能进入。
系统需能够防止各类误操作可能造成的数据丢失，破坏。
防止用户非法获得内容。
6.产品提交
提交产品为：
a）应用系统软件包；
b）数据库初始数据；
c）系统开发过程文档；
d）系统使用、维护说明文档，提交方式为CD介质。
7.实现约束
系统的实现约束如下：
a）操作系统为Windows200；
b）开发平台为：
********
c）数据库为SQLserer2000。
8.签字
本需求规格经过双方认可，特签字如表A-2所例。
表A-2需求规格签字
用户签署信息
企业签署信息
单位名称北京XXX公司
（盖章）
签署人姓名
签署日期2014.4.18
单位名称********软件有限公司
（盖章）
签署人姓名
签署日期2014.4.18
第二章软件项目的概要设计说明书
案例说明
网上招聘系统项目的概要设计说明书如下。
网上招聘系统概要设计
1.导言
1.1目的
该文档的目的是描述网上招聘系统项目的概要设计，其主要内容包括：
·系统功能简介；
·系统结构设计；
·系统接口设计；
·数据设计；
·模块设计；
·界面设计。
本文档的预期的读者是：
·开发人员；
·项目管理人员；
·测试人员。
1.2范围
该文档定义了系统的结构和单元接口，但未确定单元的实现方法，这部分内容将在详细设计/实现中确定。
1.3编写说明
UML：
UnifiedModelingLanguage（统一建模语言）的缩写，是一个标准的建模语言。
HR：
HumanResource（人力资源管理）的缩写。
JSP：
JavaServerPage（java服务器页面）的缩写，一个脚本化的语言。
MVC:
Model-View-Control（模式-视图-控制）的缩写，表示一个三层的结构体系。
EJB:
EnterpriseJavaBean（企业级JavaBean）的缩写。
1.4术语定义
JSPModel2:
Servlet/JSP规范的0.92版本中描述的术语，定义了如何在同一个应用程序中联合使用Servlet和JSP的体系结构。
JavaBean：
用Java语言实现的满足一定功能的类。
1.5引用标准
[1]《企业文档格式标准》，************软件有限公司
[2]《软件概要设计报告格式标准》，************软件有限公司软件工程过程化组织
1.6参考资料
[1]《实战struct》（美）TedHusted机械工业出版社，
[2]《软件重构》清华大学出版社，
1.7版本更新信息
本文档的更新记录如表B-1所示。
表B-1版本更新记录
修改编号
修改日期
修改后版本
修改位置
修改内容概述
000
001
2006.4.18
2006.4.25
0.1
1.0
全部
6.5节
初始发布版本
修改问卷管理模块的设计
2.系统分析
本系统可以实现网上在线招聘，应聘者通过互联网投递简历进行网上测评。
同时，招聘单位可以汇总简历，游览简历，并通过测评结果选择合格的简历，通知面试，进行面试。
方便企业与求职者的交流。
系统包括管理端子系统和客户端子系统。
管理端子系统包括题库管理、问卷管理、职位发布、简历管理、面试管理、用户管理等功能。
客户端子系统包括查询职位，简历录入，回答问卷，提交简历等功能。
图B-1和图B-2为客户端和管理端的组成构图。
图B-1客户端子系统图示图B-2管理端子系统
3.界面设计
本系统的用户界面按功能分为客户端界面和管理端界面。
图B-3管理端的页面流程
3.1管理端界面设计
管理端主要实现题库管理、问卷管理、职位发布、简历管理、面试管理以及用户管理等功能。
主要界面设计如下：
·登录界面：
通过输入用户各和密码实现用户登录，并判断用户的权限；
图B-4用户登录界面设计
·管理首页：
根据用户的权限，进入首页，并在首页中展示此用户相应可以操作的权限功能；
·管理题库：
包括“题目列表”、“题目详细信息”、“增加试题”、“删除试题”、“修改试题”、“增加答案”和“删除答案”等页面；
图B-5管理题库界面设计
·问卷管理：
包括“试题列表”、“试题详细信息”、“修改试题”、“增加试题”、“删除试题”和“预览试题”等页面；
图B-6管理问卷界面设计
·发布职位：
包括“职位列表”、“职位详细信息”、“查询职位”、“增加职位”、“删除职位”和“修改职位”等页面；
图B-7发布职位界面设计
·管理简历：
包括“职位列表”、“应聘者列表”、“应聘者申请表”、“查看试卷答案”、“回复信息”和“打印简历”等页面；
图B-8管理简历界面设计
·面试管理：
包括“职位列表”、“应聘者列表”、“应聘者求职申请表”、“查看试卷答案”、“未发通知”、“等待面试”和“面试完成”等页面；
图B-9管理面试界面设计
·用户管理：
包括“用户列表”、“用户信息”、“修改用户信息”、“增加用户”和“删除用户”、“用户权限设置”等页面；
图B-10管理用户界面设计
3.2客户端界面设计
图B-11客户端的页面流程
客户端主要为应聘者提供网上应聘的过程，应聘者通过选择合适的职位，填写个人简历，并通过问卷来进行测评，提交的简历和测评结果一同到服务器端，供管理者挑选合适的简历。
在客户界面，应聘者首先进入企业招聘界面，点击“招贤纳士”按钮进入职位列表界面，包括“职位列表”、“职位详细信息”、“申请职位”、“填写个人基本信息”、“填写工作经历”、“填写教育经历”、“填写基本技能”、“填写家庭成员”、“填写个人评价”、“预览简历”和“答题”等页面。
图B-12客户端主页面界面设计
图B-13应聘者查询职位界面设计
图B-14应聘者查询职位列表界面设计
图B-15应聘者查询职位详细信息界面设计
图B-16应聘者填写简历界面设计
图B-17应聘者填写工作经历界面设计
图B-18应聘者填写教育经历界面设计
图B-19应聘者填写基本技能界面设计
图B-20应聘者填写家庭成员界面设计
图B-21应聘者填写自我评价界面设计
图B-22应聘者回答问卷界面设计
4.体系结构
系统的总体结构设计遵循如下原则。
1）系统应具有良好的适应性：
能适应用户对系统的软件环境、管理内容、模式和界面的要求；
2）系统应具有可靠性：
采用成熟的技术方法和软件开发平台，以保证系统在以后的实际应用中安全、可靠；
3）系统应具有较好的安全性：
应提高安全机制和用户权限限制机制的完善程度，确保数据的受限访问；
4）系统应具有良好的可维护性：
系统应易于维护、安装；
5）系统应具有良好的可扩展性：
系统应适应未来信息化建设的要求，能方便地进行功能扩展，以建立完善的信息集成管理体系。
本系统采用体系结构，struct是一个基于模型（Model）一视图（View）一控制器（Controller），即MVC模式的应用架构的开源框架。
4.1体系结构
目前软件项目中有很多体系结构，其中struct是比较流行的一种。
4.1.1struct体系结构
对于开发Web应用，要从头设计并开发出一个可靠、稳定的框架不是一件容易的事情。
随着Web开发技术的日趋成熟，在Web开发领域出现了一些现成的优秀的框架、开发者可以直接使用它们，struct就是一个很好的框架结构，它是在JSPModel2基础上实现的一个MVC框架，在struct框架在模型由实现业务逻辑的JavaBean或者EJB组件构成，控制器由ActionServlet和Action来实现，视图由一组JSP文件组成，图B-5显示了Struct实现的MVC框架。
其中：
·视图，就是一组JSP文件，这些JSP文件没有业务逻辑，也没有模型信息，只有标签，这些标签可以是标准的JSP标签或者是客户化标签，如struct标签库的标签。
此外，通常将struct框架中的ActionFormBean也划为视图模块，ActionFormBean是一种JavaBean，除了具有一些JavaBean
升级会员 