天盟房地产概要设计.docx
《天盟房地产概要设计.docx》由会员分享，可在线阅读，更多相关《天盟房地产概要设计.docx（20页珍藏版）》请在冰豆网上搜索。
天盟房地产概要设计
天盟房地产项目概要设计文档
1.引言
1.1编写目的
本文档旨在描述对天盟房地产中介信息协作平台的总体概要设计，为后续各模块的设计、实现提供依据。
本文的预期读者为项目管理人员、项目开发人员、用户。
1.2背景
随着房地产市场化进程的加快，国内房地产中介企业已经从小规模、作坊式的个体运营模式向规模化、品牌化的大型现代企业方向发展。
发达地区出现了一些拥有上百家分店的巨型房地产中介企业，而国外的大牌房地产经纪公司也开始纷纷抢滩中国市场。
在这种情况下中介企业的管理者们普遍意识到信息化管理的必然趋势，中介企业的信息化不仅是效率上的提高更是企业核心竞争力的提高。
加快企业信息化建设，不只是提高效率，更是管理上的革命，而谁能快速把握这一利器，谁就能获得竞争优势。
中介企业迫切需要一种专业的应用集成产品，使他们“无须花巨大的费用，就可以将各种新、旧应用系统集成起来”，实现数据、功能共享，实现业务自动协作。
正是在这样的背景下产生的。
1.3定义
缩写、术语
解释
MIS
ManageInformationSystem信息管理系统
SD
系统设计，SystemDesign
TMDC
天盟房地产中介信息协作平台
…
1.4参考资料
1、《ASP.NET案例开发》
2、《概要设计范例》
2.总体设计
2.1系统概述
2.1.1目标和远景
天盟房地产信息协作平台系统提供功能强大且易于使用的房源查找，发布，修改，删除、客户管理，中介管理和用户管理功能，实现各种中介的房源信息共享和整合。
提供丰富的报表及查询功能，为系统提供基础数据和直观的图表。
天盟房地产信息协作平台具有良好的市场前景，和XX集团的合作为项目确定了明确的实现目标，降低了需求不确定导致的项目风险，提高了项目成功率。
系统将来在XX集团的成功实施及运行，将为公司今后的市场推广提供良好的范例及宣导作用，有助于提高该系统在该市场的占有率，并产生良好的经济效益和规模效益。
2.1.2功能概述
2.1.2.1中介管理
功能：
天盟房地产公司是一个跨省大型企业，在全国各地都拥有分公司，因此，对中介分公司的管理是总公司一项重要任务。
首先，中介总部根据分公司的分布建立连接、增加、删除、修改等操作，并把分公司进行调整如撤销、增加或修改等信息发布在网站上，让公司的信息得到及时的更新，使得公司的成员能够随时掌握到公司的实时信息，以实现最高权限管理。
再次，汇总分公司反映的情况，比如房价、当地房源信息等，及时调整公司相关政策，同时出台相应措施，以最前沿的信息为主体，发挥房源中介机构的优势。
2.1.2.2用户权限管理
功能：
公司的高层要及时了解公司员工的基本信息，则可以对他们账户赋予查看员工信息的权限；公司内部随时会对员工进行调整，当公司员工的身份改变了，其对于本网站的使用权限也会随之改变，则要将用户帐号所属角色更改，当员工新进或是辞退都要对员工信息进行增加删除的操作；或者当员工信息改变了，员工也可以对自己的信息进行修改。
权限管理主要控制用户登录时对用户的审核，管理员可以设置登录用户的权限，还可以对各个已有客户资料及权限进行修改，并对已退客户进行删除清理，及时更新，对不同用户要赋予不同的角色，所以为了帐号分配的方便，首先要定义好各个角色，在为系统用户分配帐号是定义其为相应的角色即可。
在公司内部，中介管理员可以对新来的业务员进行增加、对已退出公司人员进行删除、在工作期间对业务员的信息进行修改、查询等。
2.1.2.3站内平台管理
功能：
为方便天盟房地产公司对下属中介分公司机构的管理而建立起的一个平台。
公司可以在网站上对中介分公司机构发布相关信息并分配有关任务。
该交流平台主要实现三个功能，即作业管理、文件管理和短信管理。
作业管理就是分公司员工对于中介分公司管理者每天布置的各项工作任务的总结报告等进行上传，管理员则接收管理这些报告并及时阅读清理；文件管理就是用户们对于各个同事或者客户通过短信平台发送的附件文件进行管理及清理；短信管理是处理用户与中介分公司中心交流的短信进行管理。
站内平台管理主要实现四个功能，即作业管理、文件管理和短信管理，业务管理。
作业管理就是分公司员工对于中介分公司管理者每天布置的各项工作任务的总结报告等进行上传，管理员则接收管理这些报告并及时阅读清理；文件管理就是用户们对于各个同事或者客户通过短信平台发送的附件文件进行管理及清理；短信管理是处理用户与中介分公司中心交流的短信进行管理。
业务管理是对各个中介分公司机构的业务进行管理，了解各个分公司的业务情况，更有利于系统管理员的管理。
2.1.2.4业绩查询
功能：
目前大多企业公司实行的工资制度，都是根据业绩来评判。
因此，获得其分公司的业绩也是中介中心管理员的任务。
业绩取决于交易的多少，所以统计数据库中交易数来取得分公司的业绩，从而进行工资分配、福利、奖金等活动。
2.1.2.5客户信息管理
功能：
客户是与我们公司交易成功的人，对于他们的信息天盟房地产总公司可以对他们的信息进行增加、删除、修改、查询等操作。
2.1.2.6游客信息管理
功能：
根据游客进入网站浏览信息后，若有意愿求租（求购）房子，在网站相应位置进行注册，填写必要的个人信息（如姓名、电话、住址、邮箱、QQ号码、MSN、求租或求购房源类型等等）。
微机操作员根据游客所提供的信息经过一定的审核后确定该游客是否是潜在的客户，若是，则把游客信息加到数据库中，还可以对游客信息进行查询；若不是，则删除游客信息。
可以对客户信息进行增加、修改、删除、更新等操作。
2.1.2.7系统基础数据管理
功能：
系统基础数据管理记录了系统各种基础数据信息、并对这些信息进行增，删，改，查操作。
方便在房源模块时候的数据录入。
2.1.2.8房源信息管理
功能：
房源中心按租赁和买卖的不同记录了普宅、公寓、别墅、写字楼等物业类型的房源信息。
在房源信息描述中可加入外景图、室内格局图等信息。
2.2设计约束
（1）明显约束
本系统应当遵循的标准或规范
软件、硬件环境（包括运行环境和开发环境）的约束
接口/协议的约束
用户界面的约束
软件质量的约束，如正确性、健壮性、可靠性、效率（性能）、易用性、清晰性、安全性、可扩展性、兼容性、可移植性等等。
（2）隐含约束
有一些假设或依赖并没有在需求文档中明确指出，但可能会对系统设计产生影响，设计人员应当尽可能地在此处说明。
例如对用户教育程度、计算机技能的一些假设或依赖，对支撑本系统的软件硬件的假设或依赖等。
2.3体系结构
系统分解——建立系统的体系结构
可用的软件库以及程序员的编程经验。
通过面向对象分析得到的问题域精确模型，为设计体系结构奠定了良好的基础，建立了完整的框架。
体系部件功能及实现简介如下：
2.3.1Web表示层
功能：
为用户提供应用系统的使用界面及功能。
实现
1）界面设计部分：
使用母版页、服务器控件、用户控件、Web页面及css样式表来控制及实现。
2）功能部分：
服务器控件：
实现模板的公共功能；
用户控件：
实现一些通用的构件（比如：
选择框）。
2.3.2数据中间层
功能：
提供所有与数据库的操作。
包括：
从数据库返回数据集，向数据库更新数据，及承担部分数据验证的功能。
实现：
数据中间层组件为.CS类文件，数据库访问操作相关类统一放在DAO包，各类中应提供静态方法，数据实体类及中间层数据传输类统一放在DTO包。
2.3.3数据库
功能：
主要提供数据存储及查询功能，并需承担部分数据验证的功能。
实现：
在Web.Config配置文件中定义连接字符串以访问数据库。
2.4系统结构图
2.5功能模块命名规则
请选择易读的标识符名称。
命名统一采用中文翻译成英文字符。
可读性比简洁性更重要。
名称长度不应超过12个字符。
若名称太长，可考虑使用缩写，并必须遵守缩写规则。
缩写约定：
尽量使用组织约定的、众所周知、通用的缩写。
缩写原则为：
去除元音及重复的字线。
建立新的缩写名称，须通报给项目相关人员或管理人员公示该缩写
2.6系统功能模块划分
模块名
编号
输入
输出
主要功能
调用模块
被调模块
存取的库、表
中介管理
2.1.2.1
中介基本信息
中介信息列表
对中介信息进行查询，增加，修改，删除等功能。
Agency
用户权限管理
2.1.2.2
用户名，密码
用户列表
审核，增加，删除，修改用户和角色
User
Power
站内平台管理
2.1.2.3
管理员的基本信息
短信列表
发布信息，获取信息
TopicReply
MessageMessageRecevie
业绩查询
2.1.2.4
管理员的信息
业务员的业绩
对业务员的业绩的掌握，对表现优秀的进行奖励
Agency
CustomerMessage
Will
客户
信息管理
2.1.2.5
客户的基本信息
客户列表
对客户信息进行查询，增加，修改，删除等功能。
基础数据模块
CustomerMessage
游客信息管理
2.1.2.6
用户的信息
求购求租列表
对游客信息进行查询、增加、修改、删除等。
Area
City
Agency
BuyMessage
基础数据维护
2.1.2.7
基础数据
资基础数据列表
增加，删除，修改基础数据
房源信息管理
2.1.2.8
房源的各种信息
房源列表
对房源信息进行查询，发布，修改，删除等功能。
基础数据模块
HouseMessage
2.7功能需求与软件模块的关系
前台
后台
房源信息查询
●
房源信息管理
●
客户信息管理
●
基础数据管理
●
中介管理
●
用户权限管理
●
游客信息管理
●
业绩查询
●
站内平台管理
●
2.8系统框架设计
解决方案，命名为：
TMDC
2.8.1包图
命名空间
数据访问层：
NameSpace：
.DataAccess
其下一级命名空间包括：
.DataAccess.Common
.DataAccess.Util
.DataAccess.<模块>
数据传输层：
NameSpace:
.DTO
其下一级命名空间包括：
.DTO.<模块>
业务逻辑层：
NameSpace:
.Biz
其下一级命名空间包括：
.Biz.Common
.Biz.Util
.Biz.Facade（封装内部业务逻辑的调用）
.Biz.<模块>
WebUI层：
NameSpace:
.WebUI
其下一级命名空间包括：
.WebUI.Common
.WebUI.Resources
.WebUI.Controls.<模块>
.WebUI.Forms.<模块>
2.8.2包（类库项目）说明
1、DataAccess包：
负责对后台数据的读写操作。
2、DTO包：
负责数据实体的模型表示，作为传递给DataAccess等其他层的数据载体.
3、Biz包：
负责封装内部业务逻辑的调用、管理事务逻辑。
4、WebUI包：
负责提供Web应用环境下用户界面的表现逻辑。
2.8.3类结构图
2.8.3.1主要关键类说明
2.9系统功能设计
2.9.1总业务流程图：
系统业务流程图主要说明普通用户的业务流程。
2.9.1网站前台
2.9.1.1界面描述
2.9.1.1.2功能描述
1.用户打开系统前台页面，查看房源信息，并提供登录系统（如果用户没注册，系统提供注册功能）。
2.用户经过验证登录之后，提供房源信息管理，客户信息管理，修改密码等功能。
2.9.1.2.房源信息管理
2.9.1.2.1界面描述
界面描述如下：
2.9.1.2.2相关类的描述
主要的类属性、变量
2.9.1.2.3功能描述
房源中心按租赁和买卖的不同记录了普宅、公寓、别墅、写字楼等物业类型的房源信息。
在房源信息描述中可加入外景图、室内格局图等信息。
2.9.1.3客户管理
2.9.1.3.1界面描述
2.9.1.3.2功能描述
客户中心记录了客户信息、客户需求信息以及客户投诉、咨询等信息。
2.9.1.4基础代码维护
2.9.1.4.1界面描述
2.9.1.4.2功能描述
为系统其它模块提供基础的录入数据。
并对这些数据进行增加，删除，修改操作。
2.9.1.5中介管理
2.9.1.5.1界面描述
2.9.1.5.2功能描述
对中介信息这些数据进行增加，删除，修改操作，方便其他模块关联。
2.9.1.6用户信息管理
2.9.1.6.1界面描述
2.9.1.6.2相关类的描述
2.9.1.6.3功能描述
1.管理员对注册用户进行管理，包括增加，删除，修改操作。
2.对用户进行权限管理、角色管理
2.10尚未解决的问题
界面设计不是最终版本
3数据库设计
3.1数据库环境说明
3.11数据库的选型
本项目所用数据库选用MicrosoftSQLServer2005企业版。
数据建模工具：
MicrosoftOfficevisio2003
数据库编程工具：
SQLServer2005企业管理器。
数据库管理工具：
SQLServer2005企业管理器。
3.12数据库的配置
3.13数据库的部署
3.2数据库的命名规则
数据库名称是唯一标志数据库的符号。
数据库名称：
tmdc_DB
表名的要求：
在程序代码及文档中表名各字母首字母大写，其他的小写；各业务平台按如下方式添加表头：
用户User
关系表以R+关系表1名称+关系表2名称+…的形式组织，如学生跟课程对应关系可以这样组织：
RStudentCourse,
字段的要求：
各表名的序号以表名+ID的形式组织，如StudentI_id，基本信息标的Info可以省略；如表名较长且有多个单词组成且长度超过8个字母，可以以首单词+其他单词的首字母大写组合
表名内的字段命名要言简意赅，如表BuyMessage中的字段人员名称直接定义成BM_name即可，除序号外的字段不要组织成“BuyMessageName”或“BuyMessage_Name”的形式，使编程变得复杂；
在程序代码及文档中各字段的单词的首字母大写；
主键、索引要定义，组合键要加注释说明缘由；
各字段一定要加备注，说明各字段的含义；
数据库对象的命名：
触发器命名：
所有的触发器取名为trg触发器名。
存储过程命名：
所有的存储过程名为sp过程名。
普通变量：
Var变量名。
记录型变量：
Rec变量名。
表类型变量：
Tab表类型变量名。
数据文件的命名：
数据文件：
tmdc.mdf、tmtc.ldf。
3.3逻辑结构设计要点
主要的实体、索引属性信息:
房源信息表：
序号
列名
数据类型
长度
小数位
标识
主键
允许空
默认值
说明
1
HR_id
varchar
7
0
√
房源ID
2
HR_person
varchar
30
0
房源提供者
3
HR_email
varchar
30
0
√
Email
4
L_tel
varchar
20
0
√
固定电话
5
L_mob
varchar
20
0
√
联系人手机
6
H_type
varchar
20
0
√
房型
7
HR_type
varchar
10
0
√
房源类型
8
HR_style
varchar
10
0
√
房源类别
9
City_name
varchar
50
0
√
城市名称
10
Area_name
varchar
50
0
√
区县名称
11
HR_address
varchar
30
0
√
地址
12
PropertyRight
int
4
0
√
产权ID
13
Face
varchar
10
0
√
朝向
14
Use_Area
varchar
10
0
√
使用面积
15
Build_Area
varchar
50
0
√
建筑面积
16
Price
decimal
9
2
√
价格
18
AllFloor
int
4
0
√
楼层高度
19
Floor
int
4
0
√
所在楼层
20
H_age
int
4
0
√
房龄
21
MM_Price
decimal
9
2
√
物业管理费
22
MMPrice_unit
varchar
20
0
√
物业管理单位
23
HR_massage
text
16
0
√
房源描述
24
Time_limit
varchar
50
0
√
期限情况
“房源编号”是表的主键，不可重复。
3.4物理结构设计要点
逻辑名称相同的字段原则上物理名称也必须相同，比如：
逻辑名称：
描述，物理名称：
Description。
每个表必须有RowID字段，字段类型为int。
用于数据处理中唯一确定表的一条记录。
对于自增的主键，递增量为1。
主索引，应由唯一标识表中一条记录的字段或字段组组成。
须考虑“是否为空”及默认值。
考虑在日期或日期时间型字段的末尾加后缀Date表示日期时间类型。
作为外键的字段，考虑使用ID作为字段后缀。
字段名包含ID的，ID全部小写，如A_id
字段名要使用下划线字符（_）如A_id
例：
关系：
综合数据控制及性能方面考虑，按需要将表之间的逻辑关系转为数据表的关系并设置外键及参照完照性。
客户表信息：
序号
列名
数据类型
长度
小数位
标识
主键
允许空
默认值
说明
1
CM_id
int
4
0
√
编号（自动生成）
2
CM_name
varchar
50
0
客户名
3
Area_name
varchar
50
0
区县名称
4
City_name
varchar
50
0
城市名称
5
CM_address
varchar
30
0
√
联系地址
6
Register_time
datetime
8
3
登记日期
7
CM_tel
varchar
20
0
√
固定电话
8
CM_mob
varchar
20
0
√
移动电话
9
Price
decimal
9
2
价格
10
A_id
varchar
4
0
所属中介ID
11
HR_id
int
4
0
房源ID
12.
CM_worker
varchar
50
0
√
业务员姓名
“编号”为主键，不可重复。
3.5保密要求
用户密码字段内容：
须经加密后存储。
数据库中的其它敏感数据：
视业务需要和性能要求作综合考虑，采用合适的保密方案。
3.6数据结构与程序的关系
说明各个数据结构与访问这些数据结构的形式：
系统名称
模块名
存取的库、表
权限管理
用户管理
User
角色认证
Power
房源信息
房源管理
HR
4环境配置
4.1开发环境
类别
标准配置
最低配置
计算机硬件
软件
网络通信
其它
4.2运行环境
类别
标准配置
最低配置
计算机硬件
软件
网络通信
其它
4.3测试环境
5系统出错处理设计
5.1出错信息
系统出现错误时，捕捉到系统的错误，存入错误记录文件中，供相关人员查看。
在界面上，不弹出错误页面，以脚本形式给出出错的大概信息提示浏览者。
5.2补救措施
软件出现错误后可采取的措施：
1、重新启动操作系统
2、检查是否启动服务
3、备份数据，重新部署系统。
4、根据错误记录文件，作出相应错误处理。
5.3系统维护设计
为方便系统的维护，在代码设计中，以对象设计为主、过程设计为辅，每一个步骤都给出注释，方便维护人员查看代码和阅读代码。
升级会员 