UML网吧管理系统.doc

网吧管理系统文档姓 名：李文豪班级名称：软工三班指导教师：刘卫平实验日期：2016.3.27日期版本描述作者2016年3月- 13 -目 录1. 概述- 3 -1.1 系统简述- 3 -1.2 软件设计目标- 3 -1.3 参考资料- 3 -2. 术语表- 4 -3. 用例- 4 -4. 设计概述（此处请用简单的结构化描述）- 4 -4.1 简述- 4 -4.2 系统结构设计- 4 -4.3 系统界面- 5 -4.4 约束和假定- 5 -5. 对象模型- 5 -5.1 类定义- 5 -5.2 类关联描述- 6 -5.3 对象模型图- 6 -6. 对象数据字典描述- 6 -6.1 子系统1中的对象- 7 -7. 动态模型- 8 -7.1 场景（Scenarios）- 8 -7.2事件定义（Events）- 8 -7.3 状态图- 9 -8. 功能模型- 9 -8.1 确定输入输出与事件关系- 9 -8.2 功能模型图- 9 -9. 数据库定义- 9 -10. 部署图- 9 -11. 非功能性需求- 9 -12. 辅助文档- 10 -13. 词汇索引- 10 -1. 概述1.1 系统简述网吧是开放的营利性上网场所，上网者可利用网吧内的计算机及上网接入设备等进行网页浏览、学习、网游、聊天、视频、音乐、分享，或其他活动，网吧是向成年人开设的学习、休闲、娱乐等活动的场所。网吧管理者通过收取使用费或提供其他增值服务获得收入，网吧管系统为网吧管理者提供了更好更方便的管理。1.2 软件设计目标设计网吧管理系统的总体目标是：利用我们所学的知识开发一个体系功能结构完备、界面方便使用的网吧管理系统，实现其对网吧管理，使管理者可以方便查看会员以及上网人员的上网信息。 网吧管理系统设计的基本功能：（1）录入会员信息，然后把它们保存起来。（2）会员信息查找，任意输入一位会员号，查找出他的数据。（3）会员登陆系统，输入身份证 号及密码登陆系统。（4）上网用户的上下机及计费。（5）用户能呼叫网管寻求帮助。1.3 参考资料列出本文档中所引用的参考资料。（至少要引用需求规格说明书），格式如下)：(序号 作者. 书籍或者论文名称. 出版社或者期刊名称, 出版年.月如果是期刊后面必须有起止页码，格式如下：1 董国林,刘鑫. 基于STC单片机的指纹考勤系统设计. 工业控制计算机,2012.11(25):110-1112 林.巴斯等. 软件构架实践. 清华大学出版社, 2003.8 2. 术语表对本文档中所使用的各种专业术语、容易引起歧义的术语以及自定义的术语进行说明。如果一些术语在需求规格说明书中已经说明过了，此处不用再重复，可以指引读者参考需求说明。3. 用例查找信息注册会员上机3.1 用例图下机下机充值查询 用户 管理员 换机3.2 用例描述用例编号：001 用例名：注册会员参与者：管理员 前置条件：管理员已登录 后置条件：信息已被更新 事件路径： 1、管理员选择注册用户 2、系统数据被更新用例编号：002 用例名：查找信息参与者：管理员 前置条件：管理员已登录 后置条件：用户信息已修改事件路径： 1、管理员选择信息查找 2、系统显示用户信息用例编号：003 用例名：上下机及充值参与者：管理员 前置条件：管理员已登录 后置条件：用户信息已记录 事件路径： 1、管理员选择信息修改2、系统显示会员信息 3、系统数据被更新用例编号：004 用例名：上下机及查询参与者：用户 前置条件：用户已登录 后置条件：显示请求查询的用户信息 事件路径： 1、员工通过查询界面上下机和查询余额 2、点击查询条件 3、显示查询结果 4、退出界面 4. 设计概述（此处请用简单的结构化描述）4.1 简述这部分要求突出整个设计所采用的方法（是面向对象设计还是结构化设计）、系统的体系结构（例如客户/服务器结构）以及使用到的相应技术和工具（例如OMT、Rose）4.2 系统结构设计这部分要求提供高层系统结构的描述，使用方框图来显示主要的组件及组件间的交互。最好是把逻辑结构同物理结构分离，对前者进行描述。别忘了说明图中用到的俗语和符号。4.2.1 顶层系统结构4.2.2 子系统1结构4.2.3 子系统2结构4.3 系统界面各种提供给用户的界面以及外部系统在此处要予以说明。如果在需求规格说明书中已经对用户界面有了叙述，此处不用再重复，可以指引读者参考需求说明。如果系统提供了对其它系统的接口，比如说从其它软件系统导入/导出数据，必须在此说明。4.4 约束和假定描述系统设计中最主要的约束，这些是由客户强制要求并在需求说明书写明的。说明系统是如何来适应这些约束的。另外如果本系统跟其它外部系统交互或者依赖其它外部系统提供一些功能辅助，那么系统可能还受到其它的约束。这种情况下，要求清楚地描述与本系统有交互的软件类型（比如某某某数据库软件，某某某EMail软件）以及这样导致的约束（比如只允许纯文本的Email）。实现的语言和平台也会对系统有约束，同样在此予以说明。对于因选择具体的设计实现而导致对系统的约束，简要地描述你的想法思路，经过怎么样的权衡，为什么要采取这样的设计等等。5. 对象模型5.1 类定义（1） 用户类：属性有用户名、密码、用户身份证号码。 （2） 电脑类：属性有电脑号、机器地址。（3） 管理员类：属性有用户名、密码。 5.2 类关联描述一个用户可以选择多台电脑登录，而一台电脑可能有被多个用户登录，一个管理员管理多个用户和电脑。5.3 对象模型图 6. 对象数据字典描述在这个部分叙述每个对象的细节，它的属性、它的方法。在这之前必须从逻辑上对对象进行组织。你可能需要用结构图把对象按子系统划分好。为每个对象做一个条目。在系统对象模型中简要的描述它的用途、约束（如只能有一个实例），列出它的属性和方法。如果对象是存储在持久的数据容器中，标明它是持久对象，否则说明它是个临时对象（transient object）。对每个对象的每个属性详细说明：名字、类型，如果属性不是很直观或者有约束（例如，每个对象的该属性必须有一个唯一的值或者值域是有限正整数等）。对每个对象的每个方法详细说明：方法名，返回类型，返回值，参数，用途以及使用的算法的简要说明（如果不是特别简单的话）。如果对变量或者返回值由什么假定的话，Pre-conditions和Post-conditions必须在此说明。列出它或者被它调用的方法需要访问或者修改的属性。最后，提供可以验证实现方法的测试案例。6.1 子系统1中的对象6.1.1 对象：对象1用途：约束：持久性：6.1.1.1 属性描述：1. 属性：属性1类型：描述：约束：2. 属性：属性26.1.1.2 方法描述：1. 方法：方法1返回类型：参数：返回值：Pre-Condition：Post-Condition：读取/修改的属性：调用的方法：处理逻辑：测试例：用什么参数调用该方法，期望的输出是什么7. 动态模型管理员与用户两者都存在重复操作 状态图用户与管理员进行默写操作的顺序图用户.管理员 窗口 旧密码 新密码 主机 换机 用户余额用户充值顺序图管理员 充值窗口 垂直类别 充值这部分的作用是描述系统如何响应各种事件。例如，可以建立系统的行为模型。一般使用顺序图和状态图。确定不同的场景（Scenario）是第一步，不需要确定所有可能的场景，但是必须至少要覆盖典型的系统用例。不要自己去想当然地创造场景，通常的策略是描述那些客户可以感受得到的场景。7.1 场景（Scenarios）对每个场景做一则条目，包括以下内容：场景名：给它一个可以望文生义的名字场景描述：简要叙述场景是干什么的以及发生的动作的顺序。顺序图：描述各种事件及事件发生的相对时间顺序。7.1.1 场景：场景1描述：动作1动作27.2事件定义（Events）文字定义事件画出事件跟踪图画出事件流图7.3 状态图这部分的内容包括系统动态模型重要的部分的状态图。可能你想为每个对象画一个状态图，但事实上会导致太多不期望的细节信息，只需要确定系统中一些重要的对象并为之提供状态图即可。7.3.1 状态图18. 功能模型8.1 确定输入输出与事件关系8.2 功能模型图功能模型图有很多，请分开表示8.2.1 对象1的功能模型图8.2.2 对象2的功能模型图9. 数据库定义1