棋牌馆管理系统Word文档下载推荐.docx

棋牌馆管理系统Word文档下载推荐.docx

《棋牌馆管理系统Word文档下载推荐.docx》由会员分享，可在线阅读，更多相关《棋牌馆管理系统Word文档下载推荐.docx（18页珍藏版）》请在冰豆网上搜索。

《棋牌室管理系统》是一款专业的棋牌室计费管理系统，为所有的会员提供更加方便的服务，让大家在休闲之余可以更加方便的进行娱乐活动。

任何人都可以注册成为会员，注册时，会员需要注明自己的个人信息，包括：

姓名，联系方式，像电话、电子邮箱等。

注册成功后，系统管理员则会负责为会员发放会员卡，只有会员才可登录系统，登录成功之后，系统验证会员信息，验证成功后，会员就可进行其他操作，预订座位，会员进行查看座位信息，选择座位，还可以修改座位，删除座位，进行重新选择。

若座位已满，则需要等候，若有空座位，则管理员负责为其安排座位。

完成操作后，系统管理员根据会员所使用的时间来进行收费，收费方式分为：

现金结账和银行卡结账，付款成功之后，会员退出系统。

系统管理员则可以管理自己的信息与会员的信息，包括查看、修改、添加、删除，并支持修改密码、找回密码、重置密码等操作。

3参考资料

《软件工程》人民邮电大学出版社

《系统设计与分析》

4系统分析与设计

4.1需求分析

4.1.1识别参与者

会员、管理者、银联POS机

4.1.2对需求进行捕获与描述

用例名称：

登录执行者：

会员

目的：

完成一次登录的完整过程。

付款执行者：

完成一次付款的完整过程。

退出执行者：

完成一次退出系统的完整过程。

选择座位执行者：

完成一次选择座位的完整过程。

安排座位执行者：

系统管理员

完成一次安排座位的完整过程。

处理结帐执行者：

完成一次处理结帐的完整过程。

需求描述：

100.1

用例ID号及用例名

预定座位

100.2

用例概述

该用例描述一个棋牌馆管理系统中，客户来预订座位的操作，系统通过检验客户选择座位的有效性，验证座位信息的真实性，在系统确认座位信息之后，自动默认座位预订成功。

100.3

参与者：

101.4

前置条件（Pre-Conditions）

会员注册并登录

100.5

后置条件（Post-Conditions）

座位预定成功后由总台服务员来安排座位

100.6

事件流

100.6.1

基本事件流

（BasicFlow）

1）会员进行登录

2）系统显示会员信息

3）系统验证会员信息E—1

4）会员预定座位

5）系统产生预订座位信息

6）系统验证并确认座位信息E—2

7）会员查看座位信息

8）会员进行验证并确认E—3

9）座位预定成功并提示会员

100.6.2

扩展事件流（AlternativeFlows）

Ｅ－１（替代第3步）：

如果会员信息修改，则系统管理员要负责修改会员信息

Ｅ－２（替代第6步）：

如果座位信息不存在，或者座位已满，则需要客户重新进行选择或者排队等候，并需要重新确认。

则返回第4步进行操作

Ｅ－３：

（替代第8步）：

如果座位信息与刚开始不符，则要返回第四步重新选座位

4.1.3用例图

通过已掌握的需求，初步了解系统所要完成的功能。

下面给出用例图。

用例图如下：

4.1.4分析与讨论

1）建模用例图的步骤、方法？

①确定系统的边界和范围：

将属于系统的活动放到系统中去

②识别系统参与者：

在整个系统中只有管理员和用户是属于系统外的需要人工来完成的

③发现用例：

就是列举系统中可以完成的活动和功能

④描述用例集，确定用例关系

⑤建立用例图

⑥定义用例图的层次结构

2）如何识别系统的参与者？

应该如何划分用例，应注意哪些问题？

①参与者是用来模拟角色的，参与者代表了同系统交互的用户所充当的角色。

②用例的来源是参与者对系统的期望，所以识别用例的最好方法是从用户的需求入手。

③参与者需要从系统中获得哪些功能？

及参与者要系统做些什么？

参与者是否需要读取、产生、删除、修改系统中某些信息？

系统的状态改变是否通知参与者？

是否存在影响系统的外部事件？

系统需要什么样的输入输出信息？

需要注意：

一定不要在用例图中使用两种命名方法。

（椭圆内&

椭圆外，选一即可）用例规定了系统或部分系统的行为，它描述了系统所执行的动作序列集，并为执行着产生了一个可供观察的结果。

3）心得

4.2建立对象模型（类图包图要设计阶段的！

）

4.2.1候选类的数据字典

（1）登录

数据流条目有：

数据流名称：

登录

简述：

用户进入系统时所要进行的操作

来源：

去向：

完善个人信息

组成：

会员名称+密码+验证码

数据存储条目有：

数据存储名称：

会员名单

别名：

无

存放会员信息

会员名称+会员联系方式+密码+使用时间+卡号+管理员编号

组织方式：

数据文件，以卡号为关键字进行搜索

数据项条目：

数据项名称：

会员卡号

本系统中所有使用者的卡号

类型：

字符串

长度：

10

取值范围：

从0-9的数字，不可以包含其他的字符

加工：

加工名：

验证会员信息

激发条件：

会员进行登录操作时

优先级：

普通

输入：

会员卡号和密码

输出：

会员的正确审核信息

加工逻辑：

IF会员卡号存在AND会员密码正确AND验证码正确

THEN会员信息正确，登录成功

ELSE会员信息错误或者不存在，请重新登录或者注册

ENDIF

（2）选择座位

数据流条目：

数据流名称：

选择座位

会员在使用系统时的条件

检查座位信息

座位号+使用时间

数据存储条目：

座位使用文件

存放座位信息

座位号+座位使用情况+会员卡号

数据文件，以座位号和会员卡号进行索引

座位号

本系统中所有的座位编号

大写字母A-Z，以及0-9十个数字组成

验证座位信息

会员输入座位信息

座位使用情况

IF座位号存在AND座位为空

THEN会员预订座位成功

ELSE座位号不存在或座位被使用

THEN重新选择座位信息

（3）安排座位

安排座位

管理员为会员安排座位

（4）办理结帐

办理结帐

会员使用结束时的账单

系统停止使用

会员卡号+座位号+使用时间+消费金额

账单管理

存放会员的消费信息

组织：

会员卡号+使用时间+座位号+消费金额+会员信息

检查使用时间

会员退出系统

退出操作

使用时间及消费金额

IF会员退出系统

THEN计算消费金额

4.2.2定义类

（1）会员类：

·

属性

会员姓名（char）：

会员id（char）：

会员联系方式（char）：

会员密码（char）：

会员卡号（char）：

操作：

注册、登录、预定座位、付款、退出

（2）系统管理员类：

属性

姓名（char）：

联系方式（char）：

性别（char）：

管理员编号（char）：

操作

安排座位、处理结账

（3）登录：

属性：

登录日期（char）：

登录状态（char）：

登录id（char）：

登录密码（char）：

（4）座位：

座位号（char）：

座位状态（char）：

（5）处理结账：

结账时间（char）：

结账金额（char）：

结账方式（char）：

（6）付款：

付款方式（char）：

付款id（char）：

付款时间（char）：

付款金额（char）：

4.2.3绘制类图

在类图中标示出类的属性、操作、类之间的关系及多重性，并对所给出的类图解释说明。

4.2.4包图

对于大型复杂系统，常需要把大量的模型元素用包组织起来，以方便处理。

对所选系统的类进行分组，以便更清晰地了解系统的结构。

4.2.5分析与讨论

1）建模类图的步骤、方法？

1．确定类

1.找出候选类

2.审查与筛选类

2．识别类的属性和操作

3．识别类之间的关联

1.确定关联关系及其重要性

2.利用继承组织类

3.可以考虑是否存在聚集或组合关系，经过调整和筛选时类图进一步细化

4.对于大型、复杂的系统，可以考虑建立包图

4．定义类的结构和层次

2）识别类有哪些方法，你是如何识别类的？

识别类的方法有：

行为分析，名词识别法，CRC分析法，根据边界类、控制类、实体类的划分来帮助识别系统中的类。

我是先列举候选类，再从中挑选适合的类，删掉冗余的，增添必需的。

3）解释关联的多重性？

如何确定类的属性、操作、类之间的关联关系、组织类之间的继承？

关联的重要性：

对于每个关联，从一端看本端的一个对象可能与另一端的几个对象进行联系，把结果标注在连线的另一端。

如果需要的话，也可以添加关联角色和限定符，以详细描述关联的性质。

①确定属性可以通过提出以下问题得到：

按常识这个对象应该有哪些属性？

在当前的问题域中，对象应该有哪些属性？

根据系统责任，这个对象应具有哪些属性？

建立这个对象是为了保存和管理哪些信息？

对象为了完成其功能，需要增设哪些属性？

对象是否需要通过专设的属性区别其状态？

用什么属性表示聚集和关联？

可利用需求文档中的形容词或所有格短语。

②基本操作：

包括数据库检索和更新，如增加、删除、修改、分类、选择、查询、

计算、汇总

关键操作：

必须由对象提供的、在算法上复杂的业务操作（如要进行某些计算或

监控操作）。

操作的识别可以通过提出以下问题得到：

有哪些类会与该类交互？

所有与该类具有交互行为的类会发送哪些消息给该类？

该类又会发送哪些消息给这些类？

该类如何响应别的类发送来的消息？

在发送消息之前，该类需要做何处理？

从该类本身来说，它应该具有哪些操作来维持其信息的更新、一致性和完整性？

系统是否需要该类有另外一些职责？

4.3建立动态模型

系统的动态行为模型由交互图（顺序图和协同图）、状态机图和活动图表达。

在系统的分析和设计中应当对主要的UseCase和对象类绘制这些图形，以便分析系统的行为，印证和修改系统的静态结构，满足用户的需求，达到系统的目标。

4.3.1顺序图

会员在登录界面输入个人用户和密码，系统进行验证，若正确，则进入选择座位界面，否则返回登录界面，重新输入用户名和密码；

在选择座位界面输入座位信息后，等待系统验证，若信息不符，则重新输入座位信息，反之，进入软件界面，使用软件，结束后，退出登录，返回到登录界面。

4.3.2通信图

4.3.3活动图

活动图的主要作用是表示系统的业务工作流和并发处理过程。

针对自选系统主要的业务工作流绘制活动图。

活动图描述是活动的序列，即从一个活动到另一个活动的控制流，用来分析和验证用例，此活动图即描述了会员从登录状态到选择座位状态的控制流。

4.3.4状态图

状态机图表现一个对象（类）的生命史。

对于一些实现重要行为动作的对象应当绘制状态机图。

绘制状态机图需要确定一个对象的生命期可能出现的全部状态，哪些事件将引起状态的转移，将会发生哪些动作。

状态图是为某个对象在其生命期间的各种状态建立模型，描述一个对象穿越若干用例的行为。

此状态图即描述了系统管理员在管理会员信息时的各种动作。

4.3.5分析与讨论

比较顺序图与通信图、活动图与状态图的应用。

顺序图和通信图都属于交互图。

这两种图之间的区别在于：

顺序图基于时间，按时间顺序显示出现的任务；

而通信图显示任务和信息（对象）的交互方式。

在通信中，时间以编码形式显示，很难选取。

虽然存在这些根本区别，但这两类图有相同之处：

都用于显示对象和用户如何交互以执行任务

状态图是描述某一对象的状态转化的，它主要表现的是该对象的状态。

从状态图中可以看出，该对象在接受了外界的某种刺激之后，会做出什么样的反应。

描述的是一个对象的事情。

可以说是对类图的一种补充，帮助开发者完善某一类。

活动图是描述系统在执行某一用例时的具体步骤的，它主要表现的是系统的动作。

从活动图中可以看出，系统是如何一步一步的完成用例规约的，主要用于业务建模阶段。

活动图描述的是整个系统的事情。

可以说活动图是对用例图的一种细化，帮助开发者理解业务领域。

4.4物理模型

4.4.1建立构件图

系统实现的源代码、二进制码、执行码可以按照模块化的思想，用构件分别组织起来，明确系统各部分的功能职责和软件结构。

系统构件如上图所示，财务系统、管理员信息管理、会员信息管理、座位管理依赖于系统管理，而会员信息、选择座位号、消费金额依赖于会员信息管理，座位信息依赖于座位管理。

4.4.2建立部署图

建模部署图的目的是为了表示整个系统的软硬件的实际配置，即表示系统在运行期间的体系结构、结点的构造和软件的构造以及模块在不同结点上的分布。

棋牌馆管理系统由“前台收费”和“棋牌桌”两部分组成，“前台收费”由一个处理器和五个设备组成，处理器即前台收费，五个设备即银行卡、收费显示器、钞票扫描仪、POS机和收据打印器。

棋牌桌由一个处理器和两个设备组成，处理器即棋牌桌，设备即使用时间显示器和消费金额显示器。