_分房管理系统Rose模型设计过程

原创

会洗碗的CV工程师

发布于 2023-11-23 21:40:29

2060

发布于 2023-11-23 21:40:29

文章被收录于专栏：LongJava学习资料LongJava学习资料

一、模型总体设计

1 创建系统的Use Case 视图

Use Case框图显示系统中的使用案例与角色及其相互关系，角色是与所建系统交互的对象（人或物），使用案例是系统提供的高级功能模块，演示了人们如何使用案例。首先创建主Use Case框图，显示系统的总体视图。

下图是该分房管理系统的普通用户用例图，表示用户使用的系统案例有申请住房、申请调房、申请退房和申请其他服务，还有如果申请的是住房需填写申请表。

图1.1

图1.2描述了系统的另一个方面的功能——系统管理的功能，他（业务员）可以做的事情包括包括处理申请表，处理住房，处理调房，处理其他业务，

图1.2

图1.3描述该系统的最高级别管理者——老板在该系统的功能，可以对业务员进行增加，删除，修改信息和查询业务员的信息及这个系统的所有信息等。用到的系统用例有增加业务员，删除业务员，更新业务员，查询信息。

图1.3

2 创建系统的 Logical 视图

首先在Logical视图中创建Sequence框图，也就是Interaction框图。Interaction框图一步一步显示使用案例的流程。包括：流中需要什么对象；对象相互发送什么消息；什么角色启动流；消息按什么顺序发送。图1.4是系统处理申请入住表的Sequence 框图。

在处理表信息的时候要查找表格式是否有错误，如果没有的话则进行处理，入住申请表包含各种信息，比如说用户信息，要入住的房间信息等，成功处理表信息的会对相关文件进行更新

图1.4

图1.5是系统添加住房信息的Senquence框图，展示了业务员如何进行房间添加操作。

业务员添加入住房间时，首先要输入房间信息，然后检查业务员是否本人操作，确认信息无误后更新住房文件，删除空房文件，增加住房链表，更新空房链表，这里就涉及到对文件数据库操作。

而对于增加住房链表，更新空房链表是对于成功入住的；没有入住成功则处于等待状态，不执行操作。

图1.5

图1.6是系统添加业务员的Senquence框图，操作对象是老板，因为只有老板才可以对业务员进行操作。

首先‘老板’要进行登录验证，因为是最高级别，验证要求要比其余要复杂一点，先进行登录，登录成功后还需要输入验证‘老板’专属的密码，这样才能确保是‘老板’本人在进行操作。登录成功后，输入业务员信息、更新业务员文件、添加员工总人数，添加总工资，因为这两方面对以后导出数据需要和‘老板’进行统一管理的方便。

图1.6?

3?创建系统的 Class 框图

Class框图显示系统中所有类，提供系统组件及其相互关系的静态图形。Class框图是项目开发小组的良好设计工具，有助于开发人员在编码之前显示和计划系统结构，保证系统一开始就设计合理。

图1.7是系统业务员进行申请住房需要用到的class 框图，缺点是在于没有用到包思想去构造类图，而是采取了按照应用类型来构造类图。这个方式的缺点就是不够直观明显。

添加描述

图1.7

File接口是封装了一些文件类需要经常用到的方法，比如说增加文件，删除文件，更新文件信息，查询文件信息等业务层方法。这个接口的优点在于降低了业务的耦合度，实现了多态。

DBUtil是所有数据库操作的最顶层接口。

Apply是处理用户申请的顶层接口。

LiveRoomFile类就是File接口的实现类，对File接口的方法进行了重写，根据业务需求进行实现。体现了多态思想。里面的方法除了要实现的方法还新增了根据Id选择需要查找的信息和查询全部住房房间信息。里面包含的成员变量还有id和sum，sum指代的是住房房间的总数，此变量应为静态变量。

NullRoomFile类也是File接口的实现类，同样重写了File接口的方法，同样新增了根据id查询空房信息，查询所有空房信息，更新文件信息等方法。里面包含的变量同样是id和sum，id是成员变量，每一个Room的id都不一样，这里的sum是空房的总数，也应当作为一个静态变量。

ApplyForm类是申请入住表的实体类，里面包含有User用户类，sum：住房总人数，scope入住分数。该三个变量都应作为成员变量；scope是如果当前房屋住满的情况下，则需要进行排队入住处理，而这个分数则刚好作为排队顺序的依靠。该分数通过方法countScope（）计算分数方法获得。

ApplyLive类是业务员处理申请入住的实体类，主要变量包括id和ApplyForm，id必然是入住者的id这个在构造方法的时候就应当初始化，ApplyForm，进行入住处理则用户申请表也必然不可或缺。包含的方法有进行分数排序、检查已经居住的房屋、安排房间入住、添加到客户要入住的房间到链表中、更新住房文件信息。

User类是普通用户实体类成员属性和业务员表一样。具有Id，Name，Phone，Password等属性。

DBUser是需要对User进行数据库处理的数据库操作类。根据User类需求进行重写DBUtil接口的方法

图1.8就是根据系统需要进行调房需要用到的类而画的class 框图。

由于在上面已经介绍了三个接口File，DBUtil，Apply接口，在这里就不进行重复介绍了，只介绍新建的类。

ApplySwap类是处理用户申请换房的类，该类属性包含User用户类，roomId房间号，flag对方是否同意标志。如果需要换房的房间没有人入住则flag恒为true,即同意换房，否则需要根据别人意愿是否进行换房。而方法包含检查标志，即是否可以换房、交换房间、更新文件信息等方法。

ApplyOut类是处理用户申请退房的类，该类包含的属性有User u，roomId等。包含的方法有检查住房时间是否正常，即用户是否在规定时间内退房、退房处理、更新有关文件信息等方法。

Manger类是业务员实体类成员属性和业务员表一样。具有Id，Name，Phone，Password等属性。

DBUser是需要对Manger进行数据库处理的数据库操作类。根据Manger类需求进行重写DBUtil接口的方法。

图1.8

图1.9是系统根据‘老板’所需要操作的对象进行制作class框图。

MangerFile类是新增的业务员文件类，同样实现了File接口。里面包含业务员的所有信息，属性有sum即总员工数，totalSalary总工资数和Manger类对象。包含的方法除了需要重写File接口的方法还新增了获得总业务员数和总工资数。和设置总人数和总工资等方法。

Boss类是业务员实体类成员属性和业务员表一样。具有Id，Name，Password,Ratio等属性。这个Ratio就是‘老板’专属的验证密码。

DBUser是需要对Boss类进行数据库处理的数据库操作类。根据Boss类需求进行重写DBUtil接口的方法。

图1.9

4?创建系统的 StateChart 框图

状态图描述一个特定对象的所有可能的状态以及引起状态转换的事件。大多数面向对象技术都用状态图表示单个对象在其生命期中的行为。一个状态图包括一系列状态、事件以及状态之间的转移。

图1.10展示了用户申请表对象的状态图。

图1.10

在图1.10中我们可以直观感受到初态时填写入住表，然后处理表数据、提交后台排队，有两种可能。第一种就是无需排队，也就是说此时有空闲房子；第二种就是需要排队，并且每隔一段时间重复刷新值，直到有空闲房间可以入住。

图1.11展示了在房间有人住的情况下进行换房申请的申请状态对象图。

图1.11

在图1.11中，初态，用户提交换房申请，此时对方接受到换房申请，然后对方可以选择同意和不同意，终态就是返回自己的结果。这个状态图比较简单且易理解。

图1.12是用户提交退房申请后的申请对象的状态图。

图1.12?

在图1.12中，初态为用户提交退房申请，此时的状态是未处理，业务员看见退房申请后，业务员处理申请则退房成功，清理有关数据，比如说住房文件有些房间信息需要删除，而空房文件则需要添加有关信息。

5?创建系统的 Activity 框图

在用例模型中，活动图用来捕捉用例的活动，用框图的方式显示动作及其结果，活动图是一个流图，描述了从活动到活动的流u。它是一种描述交互的方式，描述了采取何种动作、动作的结果是什么（动作状态改变）、何时发生（动作序列）以及在何处发生（泳道）。

可以将一个转移分解为两个或者更多的转移，从而导致并发的动作。所有的并行转移在合并之前必须被执行。一条粗黑线表示将转移分解成多个分支，同样用粗黑线来表示分支的合并，粗黑线表示同步棒。

图1.13展示了添加房屋信息用例的活动图。

图1.13

在图1.13中，有三个接口分别是用户接口、业务逻辑接口、数据库接口。在用户接口中就相当于用户能看得到的东西，首先这里指代的用户是业务员，只有业务员才可以对房屋信息进行增加。

在用户接口中业务员可以看得到的信息就是输入房屋信息，等待后台处理，处理完成后显示房屋信息，否则将继续输入房间信息。

在业务逻辑接口中要处理的东西就比较复杂。先验证输入的房屋信息格式和内容是否有误，如果有误则将继续输入，否则进入下一层，获取验证码，然后输入验证码，验证码如果输入错误则需要重新输入，否则进入数据库接口，修改房屋文件。

而在数据库接口中只做三件事，第一是修改房屋信息，第二是添加插入记录，最后返回活动给业务逻辑层接口修改房屋文件，再由业务逻辑层接口返回给用户接口层显示房屋信息。

至此，添加房屋信息用例活动结束。

图1.14显示用户申请入住用例活动图

图1.14

在图1.14中，同样存在三个接口。

在用户接口中先填写入住表，等待后台处理有关信息，然后告知用户接口处理是否成功。

业务逻辑接口中收到入住表，先对入住表信息进行验证，如果表信息不正确则重新输入，反之，验证成功则开始处理表信息，同样，如果处理表信息出错也是需要用户重新填写入住表，否则处理完入住表，得到入住分数，转移到数据库接口进行活动。

在数据库接口中需要做的事情同样只有三件，第一件是修改住房文件；第二件是添加房间到入住链表；最后返回信息给业务逻辑接口打印入住清单。

在业务逻辑接口再返回到用户接口，如果入住成功则直接显示入住成功，否则显示排队列表。

图1.15则显示用户换房用例的活动图

图1.15

在图1.15中涉及到的用例还有用户接受申请处理用例。

在用户接口上，用户首先填写换房申请，等待业务逻辑接口和数据库接口返回结果。

在业务逻辑接口中先处理换房信息，如果信息不合法则返回用户接口，提示用户再次填写调房申请。否则需要查看该房间是否为空，如果不为空则向被调房的房主发送调房申请，该用户再发送结果给业务逻辑接口，如果该用户不同意换房则直接返回用户接口显示结果，否则进入可以换房阶段，转到数据库接口层执行相应的活动。如果该房间为空也是直接转到数据库接口执行相应的活动。

在数据库接口上，修改住房文件，添加交换记录，然后把结果返回业务逻辑层打印交换记录，再转移到用户接口层显示结果。

二、软件模块结构图设计

主要解决实现该系统需求的程序模块设计问题。(包括如何把该系统划分成若干个模块、决定各个模块之间的接口、模块之间传递的信息，以及数据结构、模块结构的设计等。)

1 根据系统功能进行第一级分解

图2.1

2 完成第二级分解

对上图的“房屋信息维护”“处理用户申请表”和“住房信息处理”进行分解。

房屋信息维护模块分解：

图2.2

处理用户申请表模块分解：

图2.3

住房信息模块处理：

图2.4

3 完成第三级分解

对上图的“分房申请处理”“调房申请处理”“退房申请处理”和“统计住房信息”进行分解。

分房申请模块分解：

图2.5

调房申请模块分解：

图2.6

退房申请处理模块分解：

图2.7

统计住房信息模块分解：

图2.8

4 整合得到完整的软件系统模块图

将上面三部分整合在一起得到初始的软件结构图：

图2.9

三、程序流程图设计

1 软件系统重要模块的详细设计

房屋信息维护程序流程图

图3.1

处理空房文件程序流程图

图3.2

处理住房信息统计的程序流程图

图3.3

2 程序描述

房屋信息维护程序流程图：管理员在界面点击房屋信息维护菜单，进入程序入口，然后再分别提供输入新房，删除房屋，进行排序三个子菜单供用户选择。如果用户选择了输入新房子菜单，则需要用户输入新房的信息，如果管理员输入的信息不合法则需要重新输入。
处理空房文件程序流程图：这个程序是同时适用于其他模块处理空房文件的，里面包括了管理员可对空房进行增加，删除，查看等操作。

（3）住房信息统计程序流程图：给管理员提供了查询住房信息，统计住房信息，打印住房信息等功能，同时统计住房信息里面又包含三个小功能分别是对住房文件进行增删改等操作，更方便于管理员管理住房信息。

四、数据库设计

1 软件数据流图设计

（1）顶层数据流图?

图4.1

（2）1层数据流图?

图4.2

（3）2 层数据流图?

分房申请的数据流图：

图4.3

调房申请的数据流图：

图4.4

退房申请的数据流图：

图4.5

2 软件系统数据字典

（1）数据流条目：以分房申请的数据流图为例

数据流名：分房申请

简述：根据申请者情况（年龄、工龄、职称、职务、家庭人口等）计算其分数，高于阀值的进行排队。分房时，读空房文件，把好房优先分给排在分房队列前面的人，并将房屋信息与申请者一起写入住房文件中。

组成：房屋信息和申请者

来源：作为用户分房申请表数据源的外部实体

去向：作为住房文件数据汇点的外部实体。

（2）加工条目：以计入的加工为例

加工名：计入

编号：4.2

简述：用户退房后把房屋信息记入空房文件

输入：房屋信息

输出：空房文件

加工逻辑：得到用户退房的房屋信息之后先把该房屋信息从住房文件中删除，然后再把该房屋信息计入空房文件。

（3）文件条目：以住房文件为例

文件名：住房文件

简述：存放的是用户居住的房屋信息

组成：房屋信息和申请者信息

输入：从住房申请获取数据

输出：由退房申请使用数据

存取方式：直接存取

存取频率：一个月

3 数据库表设计

用户信息表

字段序号	字段名	字段类型	字段长度	是否非空	是否主键
1	userId	varchar	18	是	是
2	userPassword	varchar	18	否	否
3	userName	varchar	30	是	否
4	userSex	varchar	3	是	否
5	userNumber	integer	11	是	否

表4.1

管理员信息表

字段序号	字段名	字段类型	字段长度	是否非空	是否主键
1	rootId	varchar	18	是	是
2	rootName	varchar	30	是	否
3	rootNumber	integer	11	是	否

表4.2

房屋信息表

字段序号	字段名	字段类型	字段长度	是否非空	是否主键
1	roomId	varchar	6	是	是
2	maxPeoples	integer	3	是	否
3	roomType	varchar	8	是	否

表4.3

住房信息表

字段序号	字段名	字段类型	字段长度	是否非空	是否主键
1	userId	varchar	18	是	是
2	userName	vrachar	30	是	否
3	roomId	varchar	6	是	是
4	userNumber	integer	11	是	否
5	roomNumber	integer	3	否	否
6	roomType	varchar	8	是	否

表4.4

空房信息表

字段序号	字段名	字段类型	字段长度	是否非空	是否主键
1	roomId	varchar	6	是	是
2	roomType	varchar	8	是	否
3	maxPeoples	integer	3	是	否

表4.5

用户申请表

字段序号	字段名	字段类型	字段长度	是否非空	是否主键
1	userId	varchar	18	是	是
2	userName	varchar	30	是	否
3	userNumber	integer	11	是	否
4	peoples	integer	3	否	否
5	grade	integer	3	是	是

五、后言

? ? ? ? ?这也是我自己的课程设计论文，其中我觉得排版还可以，然后放上去给大家分享一下，但是里面内容可能不是很严谨，请各位看官老爷子按照自己需求对着看一下找到适合自己就可以了，如有错漏，也欢迎大家在评论区指正啊！

我正在参与2023腾讯技术创作特训营第三期有奖征文，组队打卡瓜分大奖！

原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。

如有侵权，请联系 cloudcommunity@tencent.com 删除。

2023腾讯·技术创作特训营第三期

原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。

如有侵权，请联系 cloudcommunity@tencent.com 删除。

2023腾讯·技术创作特训营第三期

登录后参与评论

0 条评论

热度