文章目录

一、模型总体设计

1 创建系统的Use Case 视图

2 创建系统的 Logical 视图

3 创建系统的 Class 框图

4 创建系统的 StateChart 框图

5 创建系统的 Activity 框图

二、软件模块结构图设计

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

2 完成第二级分解

3 完成第三级分解

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

三、程序流程图设计

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

2 程序描述

四、数据库设计

1 软件数据流图设计

2 软件系统数据字典

五、后言

---

一、模型总体设计

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 软件系统重要模块的详细设计

1. 房屋信息维护程序流程图

 

图3.1

1. 处理空房文件程序流程图