UML 网吧管理系统（精选8篇）
UML 网吧管理系统 第1篇
贵州师范大学职业技术学院
系统名称:
姓 名：
班 级: 08 专 业: —— UML基础教程 ——
考 察 报 告
网吧管理系统 成豪 王建勇 何汶峰 彭健 杨茂科 杨胜文 杨兴福 杨家权 计应 计算机应用技术
目
录
UML实验报告
UML实验报告
UML实验报告
UML实验报告
UML实验报告
UML实验报告
UML实验报告
UML实验报告
UML实验报告
UML实验报告
UML实验报告
UML实验报告
UML实验报告
UML 网吧管理系统 第2篇
第1章 需求分析
1.1系统建设的意义
随着社会的发展，人们的生活节奏不断加快，各种突发事故也频繁发生。因此对于医护人员来说提高单位时间内的工作效率显得原发重要。门诊管理系统结合了各种新的技术，还将医务人员从繁琐重复的病历文书书写工作中解脱出来，为医务人员节省出大量的时间，更好的为门诊和患者服务，集中精力关注病人的诊疗。
1.2系统需求描述
从系统功能描述可以划分为以下几方面：
挂号子系统：该系统有人工挂号系统和自主挂号系统。挂号子系统主要描述了挂号过程中的各种活动，让病人和医护人员更加清楚这一过程中的环节。遵循这个规范则可以节省更多的时间，从而提高医护人员的工作效率。
查询子系统：此查询系统可为患者提供个人病例查询，药品的相关信息的查询和就诊医生的相关的信息，病人需输入相关的验证信息；另外医务人员还可以通过此查询为病人拿相应的药品。
收费子系统：该子系统的功能是主要医院提供打印收费票据、医疗项目收费统计、收费汇总等功能。此外还可以为本院的忠实患者办理医疗卡、进行医疗卡预存。医疗卡能方便患者进行挂号及自助挂号和缴付各种医疗费用。系统主要功能是面向医院的工作人员。
办理就诊卡子系统：对于初来患者需要录入本人的相关信息并办好就诊卡，以后挂号就可以直接使用就诊卡进行挂号，这样既减轻了医务人员的工作负担，同时也缩短了患者的挂号时间，能够更短时间的就诊。
第2章 系统的UML基本模型
2.1系统整体的用例模型
图2-1系统整体用例模型
用例模型描述：患者主要使用查询病例信息用例和自主挂号用例。收银员主要使用药费和办理医疗卡用例，其中用费用例又包含收取挂号费和检查费用例。护士的主要使用挂号、配药、办理就诊卡和登记患者信息用例；信息管理人员主要使用医护人员管理、药品管理和病人信息管理用例；医生主要使用检查和诊断用例，其中诊断用例有包含开检查单、开药方和开诊断结果用例。
2.2系统整体的用户类图
图2-2系统整体用户类图
系统用户类图描述：系统用户有病人、医生、护士、收银员、信息管理人员。其中病人输入相关验证信息可以查询自己的病例和相关的药品信息；医生可以把病人的诊断结果以及真短信息写入；护士可以给病人挂号和办就诊卡；收银员收取诊断费和检查费用；信息管理人员主要是针对医务人员、患者和药品的相关信息进行增加、删除和修改。
2.3系统总体的顺序图
图2-3门诊信息系统主要的顺序图
系统总体顺序图描述：系统总体可以分为登陆窗口界面、系统界面、相应管理界面和信息界面。在登陆窗口界面，输入正确的身份验证信息之后，进入相应身份的系统界面，然后在系统界面点击或者输入相关的信息，在数据库中提取信息并进入相应的信息界面。
2.4查询
2.4.1查询系统类图
图2-4查询系统类图 类图说明：信息查询器类处理所有的信息查询操作。系统中所有用户的查询功能都是通过此类提供的各种查询方法实现。信息查询器根据用户的不同级别控制其信息的访问权限
2.4.2查询系统活动图
图2-5查询系统活动图
2.4.3查询病例顺序图
图2-6查询病例顺序图
2.5挂号
2.5.1挂号管理子系统类图
图2-7挂号管理子系统类图
2.5.2挂号管理活动图
图2-8挂号管理活动图
2.6自助挂号
2.6.1自助挂号活动图
图2-9自主挂号活动图 2.6.2自助挂号顺序图
图2-10自助挂号顺序图
2.7收费系统
2.7.1收费子系统类图
图2-11收费系统类图
2.7.2收费系统顺序图
图2-12收费系统顺序图
2.8办理就诊卡系统
2.8.1办理就诊卡类图
图2-13办理就诊卡类图 2.8.2办理就诊卡顺序图
教学管理系统UML用例建模方法 第3篇
一、用例 (Use Case) 概念
用例 (Use Case) 的概念是Jacobson在1992年首先提出的。此后在Firesmith和Booch等几种软件开发方法中对于确切地描述用户需求中的功能需求;帮助发现系统中应设立哪些对象;核实每种功能需求是否有相应的对象予以满足等, 都起到了很好的促进作用, 因此受到人们的重视和好评。
二、系统需求分析
需求分析是系统开发中的一个重要步骤, 是整个系统开发的基础。需求分析的结果将直接影响到整个软件工程的成功与失败。如果需求定义错误 (如需求不完全、不合乎逻辑、不贴切或使人易于发生误解) , 那么不论以后的工作质量如何, 都必然导致系统开发的失败。大量实践证明, 信息系统产生的许多错误都是由于需求定义不准确或错误导致的。而且, 如果在需求定义阶段发生错误, 修改这些错误的代价是非常高的。因此, 信息系统开发中需求分析是系统成功的关键一步, 必须引起足够的重视。只有在正确的需求分析基础之上, 才能顺利完成系统的设计与实现工作。
三、用例 (Use Case) 建模
教学管理系统功能设计利用UML方法完成, 通过用例图描述了系统的主要功能及其使用的对象。
创建用例模型的工作包括:确定活动者和用例、描述用例、定义用例间的关系、最后确认模型。用例模型由用例图组成, 用例图展示了活动者、用例以及它们之间的关系。在创建用例模型时, 用户与开发者之间的积极合作和交流是十分重要的, 用户的参与使模型能够反映出用户所希望的细节, 并以用户的语言和术语来描述用例等。
USE CASE图可以按下列步骤建立:
1. 定义活动者。
活动者 (Actor) 是用户作用于系统的一个角色 (Role) 。活动者有自己的目标, 并且通过与系统的交互达到目标。
2. 定义USE CASE。
USE CASE本身是用户或其他系统与正在设计的系统的一个交互, 每一个USE CASE都是一个活动者与系统在交互中执行的有关事物序列。应当根据系统的需求找出全部的USE CASE, 并从活动者的角度给出事件流。当USE CASE执行时, 系统应提供给活动者服务。
3. 绘制USE CASE图。
USE CASE图是系统的外部行为视图。在确定了活动者和USE CASE的基础上绘制USE CASE图, 可以更清楚地了解系统的行为。绘制USE CASE图应先从顶层抽象开始, 然后逐步分解、精细化USE CASE图, 直到能清晰地表达问题、满足系统分析与建立模型的需要为止。基于前面的分析过程, 在此绘制了系统顶层用例图, 如图1所示。
四、结束语
基于UML的钥匙集中管理系统 第4篇
大学教务管理系统——UML模型 第5篇
随着高校校园网的建设和Internet技术的引进，基于校园网和Internet的应用系统的开发正在蓬勃发展。教务管理师高校教学管理的一向重要工作，现代化的高校教务管理需要现代化的信息管理系统支持。新世纪背景下，高校教育体制进行了大规模的改革，招生人数逐年增加，教学计划不断更新。在高校日常管理中，教务管理无疑是核心工作，重中之重。其管理模式的科学化与规范化，管理手段的信息化与自动化对于学校的总体发展产生深远的影响，由于管理内容过多，繁琐，处理的过程也非常复杂，并且随着学校人员的增加，教务管理系统的信息量大幅上升，因此往往很难及时准确地掌握教务信息的运作状态这使得高校教务管理的工作量大幅度增加，另外，随着教育改革的不断深化，教学管理模式也在发生变化，例如实施学分制、学生自主选课等。这一切都有赖于计算机网络技术和数据库技术的支持，在这样的形势下建立和完善一个集成化的教务管理系统势在必行。
目前，国内高校都开发了自己基于校园网的教务管理系统。由于其教务管理模式不尽相同，不同学校的实际教务管理情况各有自己的特点，因而各高校需要针对自己的教务管理模式和特点建立自己的教务管理系统。本设计是基于某高校的教务管理模式开发的基于校园网的教务管理系统。这样一个系统不仅可以降低工作量、提高办公效率，而且使分散的教务信息得到集中处理，对减轻教务工作负担、提高教务管理水平、实现教务管理的现代化具有重要意义。
1.建立系统用例模型
1.1确定系统模型的参与者
仔细分析教务管理系统问题描述。在UML中，角色代表位于系统之外和系统进行交互的一类对象，本系统中创建主要的角色有以下三类：
（1）教务员：教务员在教学管理系统中对全体学生进行用户登录、学籍管理、选课管理、教学管理和成绩管理，并且对教师进行登录管理、教学管理和成绩管理。教务处工作人员处理日常的系统维护，例如维护和及时更新学生，教师信息以及安排选课等。
（2）教师：教师根据教务系统的选课安排进行教学，将学生的考试成绩录入此系统。（3）学生：学生能够在教务管理系统更改学籍信息、进行选课、查询已选课程和考试成绩。
1.2识别用例
用例是系统外部参与者与系统在交互过程中需要完成的任务，识别用例最好的方法就是从分析系统的参与者开始，考虑每一类参与者需要使用系统的哪些功能，如何使用系统，根据教务管理系统的运行流程个提取的参与者信息，确定系统分为以下几个用例：(1)学生参与者用例：
用户登录 学籍管理 选课管理(2)教师参与者用例：
用户登录 成绩管理 教学管理
(3)教务员参与者用例：
用户登录 学籍管理 排课管理 成绩管理 选课管理 教学管理 系统维护
1.3建立如下四个用例图模型
（1）顶层用例图如图1-1所示
图1-1顶层用例图
从用例图1-1可以看出学生、教师和教务员都使用了“用户登录”用例，表示学生必须先进行用户登录后才可以进行学籍管理和选课管理。同理，教师也必须登录后才能进行成绩管理和教学管理。教务员登录后进行系统设置、学籍管理、排课管理和教学管理等操作。
（2）学生角色用例图 如图1-2所示
图1-2学生角色用例图
从用例图1-2可以看出学生登录后才能进行所有的操作，这样可以提高系统的安全性。（3）教师角色用例图如图1-3所示
图1-3教师角色用例图 从用例图1-3可以看出教师所有的用例都是建立在“用户登录”基础上，表示教师必须先登录后才可以执行相应的功能，这样可以提高系统的安全性，以免有人故意提供虚假信息。（4）教务员角色用例图如图1-4所示
图1-4教务员角色用例图
从用例图1-4可以看出教务员的用例相对较多，但是教务员的所有的用例都必须在“用户登录”的基础上，表示教务员必须先登录才可以执行相关的功能，这样同样可以提高系统的安全性，避免有人故意更改信息。建立系统动态模型 2.1活动图
经过活动图的建模可以比较清楚地了解整个进程过程的操作过程，本系统中主要的活动图有如下几个：学生成绩查询活动图、教务员修改学生资料活动图、学生选课活动图以及教师成绩录入活动图
（1）学生成绩查询图如图2-1所示
图2-1 学生成绩查询活动图
从图2-1可以看出，活动图分为多个不同的泳道，每个泳道表示学生在查询成绩活动中不同参与者的工作流。每个泳道中的活动是参与者要执行的操作。通过不通泳道之间的活动过渡，可以了解参与者之间的通信。这些信息可以帮助我们更好地理解系统的业务过程。
在学生成绩查询活动图中可以知道，学生、教师和教务员之间存在着相互联系。学生登录以后可以查询已选科目和成绩单，如果发现自己的成绩单有错误后可以通知教务员成绩有误，教务员联系教师后，教师修改成绩，然后教务员更新数据库。成绩无误后，查询结束。
（2）教务员学生资料修改活动图如图2-2所示；（3）学生选课活动图如图2-3所示；
图2-2教务员学生资料修改活动图图2-3学生选课活动图
从图2-2可以看出，教务员登录教务系统，系统验证用户名和密码，若有错误重新输入，无误后进行选择修改项目，确定修改，图2-3学生选课活动图图2-4 教师成绩录入活动图
2.2顺序图
主要包括如下几个顺序图 ①教务学籍管理顺序图 ②学生注册顺序图 ③学生选课顺序图 ④教师成绩录入顺序图
图2-5教务学籍管理顺序图
图2-6学生注册顺序图
图2-7教师成绩录入顺序图
3系统类模型 3.1系统包图
将整个教务管理系统划分为人员信息、接口和事务3个包，分别控制不同的应用。
3.2类图
根据系统划分的三类包图，分别讨论人员信息包，接口包和事务包中的类图分别为：（1）人员信息包内的类图（2）接口包内的类图（3）事务包内的类图
图3-1 人员信息包内的类图
图3-2接口信息包内的类图
网吧规章制度-网吧管理网吧卫生 第6篇
第一章 前言
第一条大家要团结友爱，心态端正，不允许勾心斗角；
第二条服从管理，配合完成主管交待工作，鼓励提出有建设性合理性建意及意见；
第三条每位员工必须明确各自工作岗位责任、工作范围，及执行标准；
第四条做事情态度要认真，要有责任感，不可推卸责任，配合完成好各项工作；
第五条不允许出现打架、吵架及影响网吧形像及损坏网吧内部团结等行为。
第六条所有员工必须遵守此网吧规章制度，所以有都有义务帮助完善此网吧制度；
第七条今后若法律法规变更将作相应的调整，若以后制度有更改以最新为准；
第八条本制度自正式下发之日开始执行。
员工录用制度
第二章 试用期和正试员工
网吧根据业务需要择优录用人才。凡具有一定相关专业知识身体健康、五官端正、作风正派的青年均可应聘求职。聘任程序：携带本人身份证复印件；
第一条新员工实习或试用期间，必须服从网吧安排，不适应工作的可申请离职，一经录用以后，考勤从到网吧上班时算起；
第二条见工期为3天（不计工资）保洁员录用计工资;
第三条见工期员工进入试用期限,试用期为一个月，底薪1500人民币（奖金另计）
第四条试用期满正式录用，月薪1700元人民币(奖金另计)
第五条试用期为1个月；全勤奖100元；
第六条每年元旦、五
一、中秋、国庆，每个员工有100元出勤资金，春节每个员工有200元出勤奖金由网吧统一发放。
第七条特殊贡献奖：贡献奖不限时间、名额及岗位。员工对网吧提出合理化建议，使网吧效益明显提高的：有突出表现受到客或全体员工的好评的；保护网吧利益，积极与坏人坏事作斗争，避免网吧损失，抵制歪风气；揭检举徇舞弊的，可根据实际情况给予50元—200元的奖励
第八条如连续三个月被评为优秀员工，将增加基本工资50元。
第九条年终奖：一年内获得优秀员工奖的次数超过六次的最多的前三名（不分岗位），定出优秀员工，第一名奖励1000元，第二名奖励800元，第三名奖励500元
第三章 辞职及非正常离职处罚：
第一条网吧对所有员工都本着来去自由的双向选择方针；
第二条在正式期内员工辞职，须提前30天写出书面辞职申请；
第三条经批准后满或超过30天的可以正常离职，未满30天而按自行辞职处理；（按辞职书上实际批准
日期计算）
第四条正常辞职按正式工资标准发放，返还实际所押押金及奖金
第五条未提交书面辞职申请而擅自离职按自行离职处理；（不批急辞工）
第六条自行离职扣除所有工资，奖金及押金。
第四章 开除与辞退：
第一条满足以下条件的予于开除
1)
2)
3)
4)
5)
6)
第二条开除者扣除所有工资、奖金及押金。如果有造成重大损失的上报公安机关处理。
第三条对于工作业务经过多次培训无法胜任工作岗位，并已调换其它岗位后培训仍然无法胜任工作岗
位的或自身客观条件不符合录用条件的予于辞退；
第四条正式员工辞退工资按正式员工工资标准发放，并返还所有押金及奖金 ；
被依法追究刑事责任； 对于有严重违反本网吧规章制度、态度恶劣； 有意损坏网吧形像或利益等，或已造成损失； 偷盗、非法占有公司及个人财物或擅自挪用公款； 严重失职、营私舞弊、给网吧造成重大损害； 正式员工当月考勤迟到、早退、矿工累计多于10次以上的给予开除；
考 勤 制 度
第一章
第一条每天上下班必需按时打卡，下班进行交接班，时间以吧台时间为准；
第二条上班打卡不允许提前半小时，下班打卡不允许超过半小时；
第二章考勤
第一条 工作时间划分
收银员：每日工作时间8小时:早班8:30-15:00；中班16:30-01:00；晚班00:30-09:30；
网管：每天工作时间8小时:早班8:30-15:00；中班16:30-01:00；晚班00:30-09:30；
保洁员：
每日工作时间9小时:7:30-11:30;13:00-18:00;
8:00-10:30;18:30-01:00
第二条 迟到、早退
一、于规定上班时间超过一分钟后且在一个小时以内为迟到；
二、于规定下班时间前离去为早退；
三、以吧台时间为准；
第三条 事假
一、职工人员因私人事务必须亲自处理时，可以申请事假； 总 则
第四条 病假
一、职工因疾病、非因公负伤必须休养时，可以申请病假；
二、申请一天以上病假需出示医院证明，否则按事假处理；
第五条 旷工
一、未经准假或未办理请假手续而未到职者按旷工处理；
二、迟到一个小时及一小时以上按旷工处理。
第三章 附 则
第一条 事假病假以日为最小计算单位，不满半日以一日计算;
第二条 连续旷工三日，视为自动离职。扣除当月全部工资，不返还押金及奖金；
第三条 矿工一天扣除四天的底薪。
第四条 每月有一次迟到、早退、请假（包括病假）等。取消发放其该月的全勤奖。
第五条 事假、病假可以以调休方式补回，但需经主管同意。
岗位及岗位职责
第一章网吧主管职责
第一条
第二条
第三条
作。
第四条
第五条
第六条
第二章 收银员工作职责
第一条
第二条
第三条
第四条
第五条
第六条
第七条
第八条
第九条
第十条 洁身自爱，严于律已；小心谨慎，细心认真；坚持遵循财务制度办事。收银员当班营业额发生差额，差额由当班收银员承担。（必须在交班时点清，否则由当班人承担）。如发现假钞立即退还客人。若当班收到假钞，由当班者承担。充值（网费）务必先收现金，否则不予充值。出错时必须在出错本上做详细记录并得当班领班不得挪用公款，或是用公款代垫私人费用，一经查明，立即辞退。商品销售、网费充值为现金支付，不得借出任何商品或赊账。交接班时不得到接班人签名确认，前收银员不得离开收银台。（若未签名确认擅自离开吧台时帐机器有故障，收银员必须实时通知网管，网管接到收银员通知时须第一时间去查看并解决问题，购买网吧一切物品必须按销售价格买，禁止私自销售任何物品给予客人。（一经发现立即辞退）随时保持收银台的整洁卫生。负责网吧的考勤制度的执行。负责记录好网吧内各个时段的上机人流量。负责执行网吧规章制度的落实。负责网吧内的一切日常事务，包括检查、监督及考核网吧内所有员工的工作表现、网吧卫生情每月须总结该月网吧的经营情况，提供详细的经营报告。若网吧当月业绩下滑明显，必须分析协调网吧所有员工的工作，进行人性化管理；调动员工作的积极性，让他们更好的完成本职工况、计算机运行情况、网吧的经营情况等。并总结原因，并给出合理的改善经营状况的方法。每月申报一位优秀员工。签名认可。目不对的，由前一班收银员承担。已经交班签名后，所有责任归于下一班收银员所有。）否则属网管责任。（如网管实在解决不了的，应及时告知技术员即使处理）
第十一条 耐心解答顾客提出的帐务及网吧资费方面的问题。
第十二条 面带微笑、语音甜美，用标准的普通话服务，收款付款要求吐字清晰，唱收唱付，提醒客人钞票当面点清，交付无误后向客人道别，严禁“摔、甩、扔、丢”。
第十三条 熟悉掌握各个上机价格和网吧内商品的售价;
第十四条 负责按照收银-登记-发卡-开机上网的步骤工作，积极做好网城形象宣传，推广会员卡。第十五条 语气温和，态度坚决地拒绝顾客的赊帐要求。
第十六条 收银员在对顾客进行IC卡挂失或更改密码时，应要求顾客出示相关证件，或能确切核证其身份时，才能做出相关操作。网吧员工不允许查密码;
第十七条 在找补零钱的时候，凡是需要找零7元以上包括7元的必须询问顾客有没有零钱然后找补十元。第十八条 当收银员上班时时间不允许打电话发信息，如发现罚100元（有特殊情况须向上级申请）第十九条 私人钱财和网吧营业款公私分明，不允许私人钱财在收银台出现
第二十条 收银员开临时卡时，应细心操作。如临时卡错开成普通卡时，扣罚当班收银员卡钱，错开IC卡上交。收银员在给会员加钱时，必须严格按照规定金额加钱
第二十条 做好收款机数据维护（万像收费软件有问提），一旦发现异常必须马上与经理及技术组联系
第二十一条 收银员交班时必须清点商品。周转资金，严禁当班时间点钱，多款上交，短款自负。每天进货，账目要详细登记，收银台现金如有差错由收银员个人承担经济责任
第二十二条 本网吧员工严禁查询IC卡密码，每人必须合用自己实名开办的金钻卡，不可以使用任何一张本人以外的IC卡（违规者罚款600元）上班时间睡觉罚款300元。
第二十三条当班收银下班前要将冰柜里的商品摆满、玻璃柜内商品摆放整齐。
第二十四条当班收银监督员工上网登记（员工卡只允许本人上网使用，禁止借给任何人），检查解锁。第二十五条上班时间不得接打电话，发信息，进前台以后手机随身携带物品放入指定地点，中途不得动用，下班时取走。私人财产和网吧营业款公私分明，上班时间禁止点查营业款，交班时收款人进前台后才可以点押金，快餐请在前台外付款，上班时间不得消费饮料，泡面等网吧商品。不接受顾客赠送，除就餐以外，只允许饮用网吧提供的纯净水。
第二十六条收银员及时做好零钱换取工作，收到大面额钱币要认真辨别，不能只依靠验钞器，假钞自负；
第三章 网管工作职责
第1条
第2条
第3条
第4条
第5条
第6条
第7条
位。
第8条
第9条 及时满足顾客所有合理性要求，不得推委，更不能不做。负责耐心解答顾客提出的技术性问题。（要求；当与其它正在做的工作发生冲突时，要先解决计当听到有人呼叫网管或服务员以后，要在第一时间内赶到顾客身边，给他排忧解难。坚持微笑服务、敬语服务。负责招呼本厅上机顾客，妥善安排在本厅等待上机的客人。配合除尘、清理卫生。遇到排除不了的机器故障，立即联系技术员，并详细记录故障原因、时间，短时间内未解决或保持本厅环境卫生，每半小时时这一次巡视，随时清理桌上杂物，预先了解客人需要，避免聆注意客人需要，做到客人一喊就到，顾客离去时，要立即检查机器、桌椅等有无损坏，如有损解决不了的跟踪记录。听客人闲聊及长时间站在上机客人身后。坏，立即上报并要求相应赔偿。提醒顾客不忘随身物品，按程序关闭计算机，并将周围设施擦试干净、归算机问题和顾客上机问题）。
第10条 网管在看到顾客的手机或贵重物品应主动提醒他，注意保管好随身物品，当看到顾客有损坏公物的行为，也应上前给他说明，请爱护公物，损坏照价赔偿。
第11条 网管或服务员要定期清理桌椅上的垃圾，如：烟灰缸，桌面卫生，鼠标键盘的摆放
第十一章 保洁员工作职责
第1条
第2条
第3条
第4条
第5条
第6条
第7条
第十一章 库管工作职责
1． 库管的主要职责是对网吧内的货品进行上架，管理，账目登记，利润结算等工作。
2． 库管需每天把利润报表整理清楚，每天二班，白班的利润于晚上交班时间一起上交。夜班的利润于早晨交班时间一起上交。
3． 负责网吧所有物资的入库、保管、发放工作，做到熟悉自己所管物资品种、规格、存放位置、领用及库存情况。
4． 库房所有商品物资应排放整齐有序。
5． 新进物品做好验收入库工作，认真核对质量、数量、规格，如与收据不符或质量不合格的应拒绝入库，并及时报告领班以便及时处理
。如若领班不能够即使处理的应通知经理。
6． 发放物品必须严格手续，做到计量准确，当面点清，不得私自将物品外借，严禁凭白条发货。
7． 建立明细帐，每日盘点，务必帐物相符，帐帐相符、帐表相符，月末将所有单据装订成册，妥善保管及时报表。
8． 配合好收银把货物即使补充到货柜。
9． 在库存管理的期间，发现如何的短款，缺货等问题后果均由库管人员自行承担。库管人员的工资发放时间为当月利润账目结算结束以后方可发放工资。
卫生标准
为保证为广大网友提供一个干净舒适的上网环境，本网吧制定以下卫生标准：
1、进门处卫生标准：
（1）保持地面清洁、无污渍、无杂物；
（2）防火门要经常擦拭保持无污渍；
2、卫生间卫生标准
（1）卫生间地面保持清洁，无痰渍、水渍；
（2）便池表面要保持清洁，无便渍及杂物；
（3）清洁工具要摆放整齐，不得随意乱丢；
（4）洗手池表面要求保持清洁，无污渍及杂物；
（5）卫生间空气要求保持无异味；
3、客上网区域卫生标准
（1）桌椅表面要求无灰尘、污渍及杂物； 上下班均要冲洗洗手间，每隔1.5小时要到洗手间检查，看看洗手盆的开关是否有关好，别浪费桌面每天要擦。地板每天要拖，早上拖一次、下午拖一次，且要拖干净。椅子里外都要擦。下午上班先检查洗手间的卫生，然后将没人上机的桌子、椅子擦一遍，再拖地板。上下班垃圾要倒，不是很满的可以倒到另外的垃圾桶再换垃圾袋。看到脏的请自觉打扫。拖把用完，必须将其清洗干净，然后放一个地方晒干，不充许一整团的泡在桶里。拖把拖使用服从领班的安排。安排的事情没能及时完成的，等做完之后方可下班 水资源（有些顾客洗完手会忘记关的）。要分清楚(洗手间和大厅需分开)。
（2）地面保持清洁，无污渍、杂物、水渍；
（3）顾客上网区域要求保持空气清新，无异味；
处罚制度
第一章、总则
第一条
第二条
第三条
第四条
第五条
第六条
第七条 未成年进入长时间逗留或上网，未能及时发现处罚50元/次。工作态度不端正，语气不友好和顾客产生争吵处罚50元/次，被投诉等同； 打架、吵架等或影响团结处罚50元/次，情节严重给予开除;在上班时间睡觉、上网处罚50元/次； 迟到、早退处罚10元/次，矿工一次给予处罚50元/次，在任何务服务器上上网、聊QQ等50元/次；(收费机及各种服务器，技术员技术维护时除外)所有任何处罚本月内重复触犯，超过三次以上的按原标准乘翻倍处罚，具体为1至3 原标准，第四次X 2，第五次X 4，以此类推；如：迟到第一至第三次是10元次，第四次20元，第五次40元；
第八条 本章所有规定适用于以下每章。
第二章、收银员
第一条
第二条
第三条
第四条
第三章、网管
第一条
第二条
日常工作流程及注意事项
1、未成年人要特别注意，吧台在客人刷卡时要严格查询可疑客人的身份证，必须在第一关把未成年人拒绝在门外，并随时配合好服务员的查询工作。对未成年人的工作必须每天都要提醒检查。未成年的问题第一次罚10元，以后每次加倍处罚。
5、进货注意：检查价格有没有算对、货的数量以及真假，对不合格的货要及时跟他们讲或退换货。
6、吧台每天都要打扫，货架（包装食品）两天擦一次，灰尘多的时候天天擦。
图书管理系统UML分析与设计 第7篇
系统的功能性需求描述如下：
·
图书管理系统为管理员提供主功能界面。
·
图书管理系统在启动时要求管理员输人口令，只有口令正确，才可以进入系统的主功能界面。
·
管理员负责对图书管理系统的维护工作，因此系统应赋予管理员对图书信息、读者信息和出版社信息进行录入、修改、查询和删除等功能的操作权限。
·
管理员作为读者的代理实现借书与还书业务。
·
图书信息、读者信息和出版社信息保存在对应的数据库表中。
在上述功能性需求分析的基础上，可以写出较为详细的需求规格说明书，作为进行系统分析、设计和实现的依据。需求分析规格说明书由系统最终用户提出需求，系统分析人员负责编写。图书管理系统需求分析规格说明书如下：
·
这是一个图书馆图书借阅管理的应用系统；
·
图书管理系统负责将图书、杂志借给读者，前提条件是这些读者在系统进行了注册，图书和杂志也在系统中进行了注册；
·
图书馆负责新书的购买，当书和杂志已经过时或者破旧不堪时，可以将这些图书和杂志从图书馆管理系统中删除；
·
图书管理员是图书馆的员工，负责与读者打交道，并且是在系统提供的支持下开展工作；
·
图书管理系统能够容易地建立、修改和删除系统中的信息，包括图书信息、读者信息、以及出版社信息等；
·
图书管理系统能够在所有流行的平台环境(windows，uNIx等操作系统)上运行，并具有一个美观的图书用户界面；
·
图书管理系统容易扩展新功能。
2.分析建模
Use case diagram 分析
采用下列描述项撰写用例的脚本。
· 用例名称——表明用户的意图或用例的用途。
· 参与者——与该用例相关的参与者列表。
· 前置条件——一个条件列表，如果其中包含条件，则这些条件必须在访问用例之前得到满足。
· 后置条件——一个条件列表，如果其中包含条件，则这些条件将在用例完成以后得到满足。
· 基本事件流——描述用例中各项活动都正常进行时用例的工作方式。
· 分支事件流——描述用例中某项活动的子活动各项工作都正常进行时用例的工作式。
· 异常事件流——描述用例的变更工作方式，以及出现异常或发生错误的情况下所执行的路径。
图书管理系统中每个用例的脚本描述如下：
1．系统登录
用例名称：系统登录
参与者：图书管理员 1．1前置条件 无
1．2后置条件
如果用例成功，参与者可以启动系统，使用系统提供的功能。反之，系统的状态不发生变化。
1．3基本事件流
当图书管理员登录系统时，用例启动。
①系统提示用户输入用户名和密码。
②用户输入用户名和密码。
③系统验证输入的用户名和密码，若正确，则用户登录到系统中。
1．4异常事件流
如果用户输入无效的用户名／密码，则系统显示错误信息。用户可以选择返回基本事件流的起始点，重新输入正确的用户名／密码；或者取消登录，用例结束。
2．图书借阅
用例名称：借阅图书
参与者：读者，图书管理员 2．1前置条件
在这个用例开始之前，图书管理员必须登录到系统；否则，系统的状态不发生变化。
2．2后置条件
如果这个用例成功实现，则在系统中创建并存储借阅记录。2．3基本事件流
当读者借阅图书时，用例启动。
①登录系统。
②输人图书ID和读者ID。
③检索读者ID。
④检索图书ID。
⑤根据时间算法确定图书借出日期和归还日期。
⑥图书馆将图书借给读者。
⑦创建借阅记录。
⑧存储借阅记录。2．4异常事件流
①如果读者未注册，则系统显示提示信息，用例被终止。
②如果要借图书不存在，系统显示提示信息，用例被终止。
③如果要借图书都已借出，则系统提示信息，用例被终止。3．图书归还
用例名称：图书归还
参与者：读者，图书管理员 3．1前置条件
在这个用例开始之前，图书管理员必须登录到系统；否则，系统的状态不发生变化。
3．2后置条件
如果这个用例成功实现，则系统删除借阅记录；否则，系统的状态不发生变化。3．3基本事件流
当读者归还借阅的图书时，用例被启动。
①登录系统。
②输入图书ID和读者ID。③检索图书ID。
④检索读者ID。
⑤查询图书借阅记录。⑥删除借阅记录。3．4异常事件流
①如果归还图书不存在，则系统显示提示信息，用例被终止。②如果借阅记录不存在，则系统显示提示信息，用例被终止。4．读者维护
用例名称：读者维护 ‘ 参与者：图书管理员 ’ 4．1前置条件
在这个用例开始之前，图书管理员必须登录到系统；否则，系统的状态不发生变化。4．2后置条件
如果这个用例成功地实现，则系统添加、修改或检索读者信息；否则，系统的状态不发生变化。
4．3基本事件流
当图书管理员维护读者信息时，用例被启动。①登录系统。
②如果选择的活动是“添加读者信息”，则执行分支事件流4．3．1：添加读者信息。③如果选择的活动是“修改读者信息”，则执行分支事件流4．3．2：修改读者信息。④如果选择的活动是“检索读者信息”，则执行分支事件流4．3．3：检索读者信息。4．3．1分支事件流
①提供读者的信息，例如，读者ID，读者姓名、电话号码等。②系统存储读者信息。4．3．2分支事件流 ①输入读者ID。
②查询并显示读者信息。③更新系统中读者信息。4．3．3分支事件流 ①输入读者ID。
②查询并显示读者信息。4．4异常事件流
①如果读者已经存在，则系统显示提示信息，用例被终止。②如果查询不到读者，则系统显示提示信息，用例被终止。5．图书维护
用例名称：图书维护 参与者：图书管理员 5．1前置条件
在这个用例开始之前，图书管理员必须登录到系统；否则，系统的状态不发生变化。5．2后置条件
如果这个用例成功实现，则系统添加、修改或检索图书信息；否则，系统的状态不发生变化。
5．3基本事件流
当图书管理员维护图书信息时，用例被启动。①登录系统。
②如果选择的活动是“添加图书信息”，则执行分支事件流5．3．1：添加图书信息。③如果选择的活动是“修改图书信息”，则执行分支事件流5．3．2：修改图书信息。④如果选择的活动是“检索图书信息”，则执行分支事件流5．3．3：检索图书信息。5．3．1分支事件流
①提供图书的信息，例如，图书ID，图书名称、编著者、出版社、价格、出版年份筹 ②系统存储图书信息。5．3．2分支事件流 ①输人图书ID。
②查询并显示图书信息。⑨更新系统中图书信息。5．3．3分支事件流 ①输入图书ID。
②查询并显示图书信息。5．4异常事件流
①如果该图书已经存在，则系统显示提示信息，用例被终止。②如果查询不到该图书，则系统显示提示信息，用例被终止。
系统总体功能结构
根据用例图定义分析包以及分析包（子系统）之间的关系。
图书管理系统分析包详细结构
定义类、用例实现（序列图）、类关系图(1)系统登录
类图：
系统登录分析类图
用例实现：
登录系统成功顺序图
登录系统失败顺序图
(2)登录图书信息
类图：
登录图书信息分析类图
用例实现：
登录图书信息顺序图
(3)修改图书信息
类图：
修改图书信息分析类图
用例实现：
修改图书信息顺序图
(4)检索图书信息
类图:
检索图书信息分析类图
用例实现：
检索图书信息顺序图
(5)借阅图书 类图：
借阅图书分析类图
用例实现：
借阅图书顺序图
(6)归还图书
类图：
归还图书分析类图
用例实现：
归还图书顺序图
(7)借出图书一览表
类图：
借出图书一览表分析类图
用例实现：
借出图书一览表顺序图
(8)类关系图
系统实体类（业务类）之间的关系
(9)类的具体定义
1．图书表类
编号：A—l一0l
类名：图书表
职责：存放图书馆所能处理的所有图书的基本信息
属性：图书代号，图书名称，编著者，ISBN代码，出版社代码，出版年份，页数，价格，购入日期，过期日期，书架代码，备注
说明：该类存放所有图书类的公用信息，它是“图书借阅表”的父类。图书也有身份，可以通过不同的ISBN相区别。在图书管理系统中，图书也有相关的行为，图书因为使用期限等可以被销毁，所以图书表也是系统中的一个对象。
2．登录图书界面类
编号：A一1—02
类名：登录图书界面
职责：提供输入所有图书信息的界面
属性：图书代号，图书名称，编著者，ISBN代码，出版社代码，出版年份，页数，价格，购入日期，过期日期，书架代码，备注
说明：该类的所有属性是非持久性的，但它为用户保存永久性的图书属性提供了一个临时的输入接口。
3．登录图书信息控制类
编号：A—l—03
类名：登录图书信息控制类
职责：实现登录图书界面类与图书表类所提供信息的交互。
属性：图书代号，图书名称，编著者，ISBN代码，出版社代码，出版年份，页数，价 格，购人日期，过期日期，书架代码，备注
说明：该类的所有属性是非持久性的，但它为用户保存永久性的图书属性提供了一 个临时的输人接口。
4．出版社表类
编号：B—l—01
类名：出版社表
职责：存放图书表所使用的所有图书的出版单位
属性：出版社代码，出版社名称
说明：该类与出版社表之间存在着单向关联的关系。
5．读者表类
编号：C一1一Ol
类名：读者表
职责：存放图书馆的所有读者的基本信息
属性：读者代码，读者名，联络电话
说明：该类类描述了物理借阅者的信息，代表了系统中存储的物理借阅者的信息，即物理借阅者在系统中的账户。同时，读者表又是图书借阅表的组成成分之一。
6．图书借阅表类
编号：D—l—01
类名：图书借阅表
职责：存放图书馆所能处理的所有图书的基本信息
属性：图书代号，读者代号，借书日期，还书日期，说明：该类描述了从图书馆借阅图书的借阅记录。一个该类的对象对应一个借阅者和一本图书。该类的对象的存在表示借阅者借阅了借阅记录中记录的物理图书。当图书被归还时，要删除借阅记录(对象)。
形成系统分析规约（注意规约可能会有活动图、状态图等）
3.系统设计
设计模型的主要工作： 1）．软件平台设计
软件平台是系统开发和运行的环境。图书管理系统的开发和运行环境如下：
· 操作系统——操作系统是计算机系统中最重要的系统软件。图书管理系统可以运行在Windows 95／98／2000／NT／Windows XP等桌面操作系统上。
· 支撑软件——支撑软件是协助人们开发和维护软件的工具和环境软件。数据库系统、集成开发环境等都属于支撑型软件，例如，Delphi、Oracle、Java等。图书管理系统使用的DBMS是Access 2003，数据库中间件是JDBC。
· CASE平台——采用CASE开发环境可保证系统开发质量，提高开发效率，保证文档的一致性。图书管理系统的分析、设计j实现和部署模型是在Rose 2003建模环境下创建的，清晰地表达了在不同的开发阶段的系统模型。2）．结构设计
结构设计是把软件分解成为多个子系统，并确定出由各子系统及其接口构成的软件结构。子系统是对软件分解的一种中间形式，也是组织和描述软件的一种方法。由多个子系统构成系统软件，每一个子系统又包括多个用例设计、设计类和接口。结构设计具体要做的工作是将系统划分成相对独立、功能相对完整的子系统(包)，将系统模型中的元素划分到不同的包中，说明在什么地方定义包，各个包之间的依赖性和主要通信机制。从而得到尽可能简单和清晰的结构，各部分之间的依赖尽可能的少，并尽量减少双向的依赖关系。3）．详细设计与界面设计
详细设计是对软件结构中确定出的各个子系统内部的设计，需要分析和确定每一个子系统中的用例设计、设计类和接口。详细设计还要描述每个类的细节，并用动态模型描述类的实例在具体环境中的行为。
界面设计是对人和外部系统与系统之间交互界面的设计，包括输入界面、输出界面和输入／输出界面的设计。另外，界面设计还涉及到人机交互方式、人机交互流程、输入输出设备和媒体等内容。4）．数据库设计
数据库是系统存储和管理数据的主要技术手段，数据库设计的任务是根据给定的系统应用需求和系统环境，设计出合理的数据库结构。数据库设计可分为概念设计、逻辑设计和物理设计3个阶段。用UML进行数据库设计的主要思想，是利用UML的扩展机制定义一些版型，用于表示与数据库相关的一些概念。Rose 2003提供了对数据库设计的支持，所设计的模型可以直接生成具体数据库中的表、触发器、存储过程等。
系统结构设计
系统框架视图
· 用户界面包(User Interface Package)——用于描述整个用户界面使用的类，这些类提供的操作允许用户浏览系统中的数据，允许用户输入新数据。用户界面类基于Java AWT包设计，AWT包是Java语言中用于编写用户界面应用程序的一个标准库。用户界面包与业务模型包相互协作，调用业务模型包中类实例的方法对图书信息进行检索和插入操作。
。业务模型包(Business Model Package)——包含分析阶段主要的类(借阅图书类、归还图书类、图书类、读者类、出版社类)。在设计阶段将进一步细化这些类，从而完整地定义它们的操作，并为它们增加永久性存储支持。业务模型包与数据库包相互协作，访问数据库中的数据。· 数据库包(Database Package)——为业务模型包中的类提供数据存取服务，以便这些类能够实现数据的永久性存储功能。
。组件包(Utility Package)——包含一些可以被系统中其他包所使用的服务。
界面设计
详细设计
图书信息管理详细设计：
1．设计类图
“图书信息管理’’是一个用例，在“图书信息管理”用例所提取的3个概念类的基础上，可以确定该用例有3个设计类：登录图书信息(LoginBook)、修改图书信息(UpdateBook)、检索图书信息(SelectRook)。如图13．2所示为“图书信息管理”用例的设计类图。
“图书信息管理”用例设计类图
·
BpFrame类——属于用户界面包，定义系统检索与修改界面的框架。
·
BpSelectFrame类——属于用户界面包，继承BpFrame类，定义检索界面框架。
·
BpUpdateFrame类——属于用户界面包，继承BpSelectFrame类，定义系统修改界面框架。
·
SelectBook类——属于用户界面包，继承BpSelectFrame类，与DbChoice类相关联，显示图书信息检索界面。
·
LoginBook类——属于业务模型包，继承BpUpdateFrame类，与DbChoice类相关联,实现图书信息登录功能。
·
UpdateBook类——属于业务模型包，继承BpUpdateFrame类，与DbChoice类相关联，实现图书信息修改功能。
·
DbChoice类——属于组件包，定义了用于数据库操作的实例变量和实例方法。
2．顺序图
为实现用例的功能，每个用例要实现的功能要通过用例中各个类的对象的操作的相互协作完成，这就要在顺序图或协作图中反映各个对象之间的消息调用过程。如图13．3所示为添加的图书ID不重复的情况下“登录图书信息”用例的顺序图。
“登录图书信息”顺序图
3．属性和方法设计
用例设计中识别出了大量的设计类，接下来要详细地设计所识别出来的每一个设计类，即设计类的属性和方法。属性设计应该注意的问题是：一要补充属性分析时没有考虑到的属性，确定属性的全部内容，其中包括属性名、可视性、范围、类型、初始值；二要尽量采用系统采用的程序设计语言的语法规范描述属性。
方法设计包括数据结构设计、算法设计和流程设计。方法设计要注意的是：一要立足于所采用的程序设计语言；二所选用的程序设计语言应该能够提供丰富的数据结构；三要根据所实现的功能确定算法设计；四是可以用程序流程图或活动图来描述流程设计的结果。
如图所示为添加了属性和方法“图书信息管理”用例的设计类图。
添加属性和方法后的“图书信息管理”类图
LoginBook类的属性和方法设计如下：
·
sql属性——定义执行插人操作的SQL命令字符串。
·
chpublish_id属性——定义出版社ID。
·
LoginBook()方法——类的构造方法。①调用DbChoice类的对象实例，以实现加载JDBC驱动程序，创建数据库连接等功能；②提供添加图书信息界面。
·
cheekInsea()方法——①检查各输入项的输人格式是否正确；②检查图书ID是否重复。
·
makelnsertStmt()方法——定义执行插人操作的SQL命令字符串。
·
afterlnsert()方法——清空登录图书界面的各输入项。
SelectBook类的属性和方法设计如下：
·
sql属性——定义执行插入操作的SQL命令字符串。
·
chpublish_id属性——定义出版社ID。
·
SelectBook()方法——类的构造方法。①调用DbChoice类的对象实例，以实现加载JDBC驱动程序，创建数据库连接等功能；②提供检索图书界面。
·
checkSelect()方法——检查是否输入要检索的图书ID。
·
makeSelectStmt()方法——定义执行检索操作的SQL命令字符串。
·
setSelectedData()方法——显示检索图书的结果。
·
clear()方法——清空图书检索界面各检索项。
UpdateBook类的属性和方法设计如下：
·
sql属性——定义执行插入操作的SQL命令字符串。
·
chpublish_id属性——定义出版社ID。
·
UpdateBook()方法——类的构造方法。①调用DbChoice类的对象实例，以实现加载JDBC驱动程序，创建数据库连接等功能；②提供检索图书界面；③提供修改图书功能。
·
checkSelect()方法——检查是否输人要检索的图书ID。
·
makeSelectStmt()方法——定义执行检索操作的SQL命令字符串。
·
setSelectedData()方法——显示检索图书的结果。
·
clear()方法——清空图书修改界面各修改项。
·
checkUpdate()方法——检查各修改项的修改格式是否正确。
·
makeUpdateStmt()方法——定义执行修改操作的SQL命令字符串。
读者信息管理详细设计： 1．设计类图
“读者信息管理”是一个用例，在“读者信息管理”用例确定了3个概念类：添加读者信息、修改读者信息、检索读者信息。但是，该用例的功能相对比较简单。可以用1个设计类Borrow实现这3个概念类的功能。如图所示为“读者信息管理”用例的设计类图。
图13．5 “读者信息管理”用例设计类图
· Borow类——属于业务模型包，继承BpupdateFrame类，实现读者信息添加修改和检索功能。
2．顺序图
如图13．6所示为添加的读者ID不重复的情况下“添加读者信息”用例的顺序图。
“添加读者信息”顺序图
通过分析如图所示的顺序图，可以得到下图所示为“读者信息管理”用例的设计类图。
图优化后的“读者信息管理”用例设计类图
3．属性和方法设计
如下图所示为添加了属性和方法“读者信息管理”用例的设计类图。
添加属性和方法后的“读者信息管理”类图
Borrow类的属性和方法设计如下：
· sql属性——定义执行插入操作的SQL命令字符串。
· Borrow()方法——类的构造方法。①调用DbChoice类的对象实例，以实现加载JDBC驱动程序，创建数据库连接等功能；②提供添加、修改和检索读者信
息界面。
· checkSelect()方法——检查是否输入要检索的读者ID。
· makeSeleetStmt()方法——定义执行检索操作的SQL命令字符串。
· setSelectedData()方法——显示检索读者的结果。
· ehecklnsert()方法——检查是否可执行插入操作。
· makeInsertStmt()方法——定义执行插入操作的SQL命令字符串。
· afterlnsert()方法——清空各输入项。
· checkUpdate()方法——检查是否可执行修改操作。
· makeUpdateStmt()方法——定义执行修改操作的SQL命令字符串。
· checkData()方法——检查各输入项的输人格式是否正确。
· clear()方法——清空各文本框。
出版社信息管理详细设计： 1．设计类图
“出版社信息管理”是一个用例，可以用1个设计类Publish实现添加出版社信息、修改出版社信息、检索出版社信息3个概念类。如图13．9所示为“出版社信息管理”用例的设计类图。
图13．9 “出版社信息管理”用例设计类图
· Publish类——属于业务模型包，继承BpUpdateFrame类，实现出版社信息添加、修改和检索功能。
2．顺序图
如图13．10所示为添加的出版社ID不重复情况下“添加出版社信息”用例的顺序图。
图13．10 “添加出版社信息”顺序图
3．属性和方法设计
如图13．1l所示为添加了属性和方法“出版社信息管理”用例的设计类图。
图13．11 添加属性和方法后的“出版社信息管理”类图
Publish类的属性和方法设计如下：
· sql属性——定义执行插入操作的SQL命令字符串。
· Publish()方法——类的构造方法。①调用DbChoice类的对象实例，以实现加载JDBC驱动程序，创建数据库连接等功能；②提供添加、修改和检索出版社信息界面。
· checkSelect()方法——检查是否输入要检索的出版社ID。
· makeSelectStmt()方法——定义执行检索操作的SQL命令字符串。· setSelectedData()方法——显示检索出版社的结果。· checklnsert()方法——检查是否可执行插入操作。
· makeInsertStmt()方法——定义执行插入操作的SQL命令字符串。· afterInsert()方法——清空各输人项。
· checkUpdate()方法——检查是否可执行修改操作。
· makeUpdateStmt()方法——定义执行修改操作的SQL命令字符串。· checkData()方法——检查各输入项的输人格式是否正确。· clear()方法——清空各文本框。
图书借还信息管理详细设计： 1．设计类图
“图书借还信息管理”是一个用例，在“图书信息管理”用例所提取的4个概念类的基础上，可以确定该用例有4个设计类：借阅图书（BorrowBook)、归还图书(RetumBook)、借出图书一览表(BorrowBookList)和未按期归还图书一览表(OverdueList)。如图所示为“图书借还信息管理”用例的设计类图。
图“图书借还信息管理”用例设计类图
· BorrowBook类——属于业务模型包，继承BpUpdateFrame类，与DbChoice类相关联，实现图书借阅功能。
· ReturnBook类——属于业务模型包，继承BpUpdateFrame类，与DbChoice类相关联，实现图书归还功能。
· BorrowBookList类——属于业务模型包，继承BpSelectFrame类，与DbChoice类相关联，显示借出图书清单一览表。
· OverdueList类——属于业务模型包，继承BpSelectFrame类，与DbChoice类相关联，显示未按期归还图书与读者清单一览表。
2．顺序图
如图所示为读者ID与图书ID都存在情况下的“借阅图书”用例的顺序图。
“登录图书信息”顺序图
3．属性和方法设计
如图所示为添加了属性和方法“图书借还信息管理”用例的设计类图。
添加属性和方法后的“图书借还信息管理”类图
BorrowBook类的属性和方法设计如下：
· sql属性——定义执行插入操作的SQL命令字符串。
· BorrowBook()方法——类的构造方法。①调用DbChoice类的对象实例，以实现加载JDBC驱动程序，创建数据库连接等功能；②提供添加图书信息界面。· checklnsert()方法——①检查各输入项的输入格式是否正确；②检查借阅图书ID是否存在。
· makeInsertStmt()方法——定义执行插入操作的SQL命令字符串。
· afterInsert()方法——清空借阅图书界面的各输入项。
· checkSelect()方法——检查是否输入读者ID和图书ID。
· makeSelectStmt()方法——显示检索结果。
· checkDelete()方法——检查是否可执行删除操作。
· makeDeleteStmt()方法——定义执行删除操作的SQL命令字符串。
· afterDelete()方法——清空删除操作后的各输入项。
· clear()方法——清空所有的文本框。ReturnBook类的属性和方法设计如下：
· sql属性——定义执行插人操作的SQL命令字符串。
· RetumBook()方法——类的构造方法。①调用DbChoice类的对象实例，以实现加载JDBC驱动程序，创建数据库连接等功能；②提供图书归还界面。
· checkUpdate()方法——检查各修改项的修改格式是否正确。
· makeUpdateStmt()方法——定义执行修改操作的SQL命令字符串。· afterUpdate()方法——清空所有的文本框。BorrowBookList类的属性和方法设计如下：
· sql属性——定义执行插入操作的SQL命令字符串。
· BorrowBookList()方法——类的构造方法。①调用DbChoice类的对象实例，以实现加载JDBC驱动程序，创建数据库连接等功能；②提供实现“借出图书一览表”功能的界面。
· makeSelectStmt()方法——定义执行检索操作的SQL命令字符串。
· setSelectedData()方法——显示检索结果。OverdueList类的属性和方法设计如下：
· sql属性——定义执行插入操作的SQL命令字符串。
· xOverdueList()方法——类的构造方法。①调用DbChoice类的对象实例，以实现加载JDBC驱动程序，创建数据库连接等功能；②提供实现“未按期归还图书一览表”功能的界面。
· makeSelectStmt()方法——定义执行检索操作的SQL命令字符串。
· setSelectedData()方法——显示检索结果。
组件包设计：
组件包包含被所有其他包使用的通用组件，图书管理系统的组件包由Const、DbChoice、BpUtil三个类组成，这三个类定义了系统所有其他类所使用的公共常量与公共方法。另外，IconCanvas(加载系统界面所使用的图标)、MsgDialog(信息显示对话框)、SQLExceptionDialog(显示数据库异常信息对话框)3个类也为系统所有其他类所公共使用。在此与组件包中的类一起进行说明。1．Const类
Const类定义了系统所使用的公共名称等常量，其类图如图所示。
Const类的类图
2．BpUtil类
BpUtil类定义了系统使用的公共方法，其类图如图所示。
BpUtil类的类图
BpUtil类的方法设计如下：
· repeateString()方法——返回指定个数的字符串对象。
· varchar2text()方法——返回按照指定长度调整的字符串对象。
· setComp()方法——在组件上按照CridBagConstraints布局配置Panel。· checkWaming()方法——检查数据库连接操作是否出现异常。· isNumeric()方法——验证字符串能否转换为数值。
· getToday()方法——以YYYY／MM／DD的格式返回今日的日期。
· getToday()方法——返回以今日为基点的指定为YYYY／MM／DD格式的日期。· isYMD()方法——验证能否识别YYYY／MM／DD格式的字符串。· GB2312Unicode()方法——GB2312转换为Unicode。· UnicodeGB2312()方法——Unicode转换为GB2312。
· getRowCount()方法——求数据表中满足条件的记录数。
· convYMD()方法——Java．util．Date类型数据转换为YYYY／MM／DD格式。
3．DbChoice类
DbChoice类定义了用于数据库操作的实例变量与实例方法，其类图如图所 示。
DbChoice类的类图
DbChoice类的属性和方法设计如下：
· con属性——定义用于数据库连接的实例变量。· query属性——定义用于SELECT语句的实例变量。· displayCol属性——定义用于检索结果的列数。
· valueCol属性——定义方法getSelectedVal()返回值的列数。
· vItem属性——定义用于保存方法getSelectedVal()返回值的Vector · DbChoice()方法——构造方法，用于初始化实例变量。· setQueryData()方法——执行检索操作。· getSelectedVal()方法——返回检索结果。· setValueCol()方法——设置列的值。· getValueCol()方法——返回列的值。
· setDisplayCol()方法——设置显示列的值。· getDisplayCol()方法——返回显示列的值。
· setDisplayhem()方法——设置显示项的列的值。4．IconCanvas类
IconCanvas类用于完成加载系统界面所使用图标的功能，其类图如图所示。
IconCanvas类的类图
IconCanvas类的方法设计如下：
· IconCanvas()方法——构造方法，用于完成加载图像文件的功能。· paint()方法——用于完成显示图像文件的功能。5．MsgDialog类
MsgDialog类用于完成显示系统界面所使用的信息对话框功能，其类图如图13．19所 示。
MsgDialog类的类图
MsgDialog类的属性和方法设计如下：
· MsgDialog()方法——构造方法，用于生成信息显示区域，定义信息对话框的标题、布局管理器等功能。
· actionPerformed()方法——用于处理发生的事件。
6．SQLExceptionDialog类
当发生数据库异常时，SQLExceptionDialog类定义了用于显示数据库异常信息对话框，其类图如图所示。
SQLExceptionDialog类的类图
SQLExceptionDialog类的属性和方法设计如下：
· SQLExceptionDialog()方法——构造方法，用于定义发生的SQL异常。· actionPerformed()方法——用于处理发生的事件。· setMessage()、方法——用于显示发生的异常信息。系统管理详细设计：
系统管理由Bookplate和LoginDialog两个类组成，Bookplate类用于显示系统主功能界面，LoginDialog类用于显示用户登录对话框界面。Bookplate类与LoginDialog类之间有单向关联关系，即Bookplate类中定义的实例变量dialog可以调用LoginDialog类的构造函数，以实现系统登录界面的显示，描述两者之间关系的类图如图所示。
“系统管理”用例设计类图
Bookplate类的方法设计如下：
· main()方法——系统执行的入口点，用于显示系统主功能界面。
· Bookplate()——构造方法，用于设置系统框架(Frame)、标题、菜单、按钮布局、标签等系统组件。
· aetionPerformed()——当用鼠标左键点击各功能按钮时，分别调用各个子功能系统，同时实现生成、显示和隐藏对应的框架的功能。LoginDialog类的方法设计如下：
· LoginDialog()方法——构造方法，用于设置用户登录对话框界面的标题、显示信息区域、设置标签和文本域、生成按钮等功能。
· actionPerformed()——当用鼠标左键点击功能按钮时，处理所触发的事件。· getStatus()——返回按钮的状态值。· getUserID()——返回用户ID。· getPassword()——返回用户口令。
数据库设计（表略）
基于UML的机房管理系统的设计 第8篇
高校的计算机机房是计算机实验教学的场所, 是实验教学的重要环节。不仅要满足实验课程的需求, 同时还要承担各种开放实验, 对学生开放课余上机的任务。在如今, 学校越来越重视实验教学, 重视培养学生动手能力的培养, 机房的各项工作十分繁杂。通过有针对性的设计并实现一个机房管理系统, 能够对机房进行积极有效的管理, 满足机房实验教学的需求, 使机房使用效率得到极大的提高。
1. UML建模机制
当前应用系统软件的编制面临着一些亟需解决的问题, 如软件结构越来越复杂、功能更新越来越快, 而组件耦合性却越来越小。这些问题如果单纯依赖传统的结构化系统分析开发方法是无法解决的, 必须把目光转向面向对象的设计方法。面向对象的设计方法具有封装性、继承性和多态性等特点, 在各个领域的应用系统软件开发过程中都取得了良好的应用效果, 因此也逐渐成为软件开发的主流方法。统一建模语言 (UML) 为面向对象的软件开发提供了一个丰富的、统一的平台, 并且已经成为当今建模语言的主流标准UML是一种通用的面向对象的可视化建模语言, 是各种面向对象方法和技术在建模语言级别上的融合、统一。UML提供了各种静态视图和动态视图, 可以在设计的不同阶段进行详细的描述以辅助建立起分析模型、设计模型和实施模型, 为系统的迭代式开发和扩充提供了良好的保证。
2. 基于UML机房管理系统建模
2.1 用例建模
建立模型, 需求分析是第一步。这里首先识别系统的用户和相关外部系统, 以确定系统角色 (Actor) 。这么做可以帮助界定软件系统的边界, 引导和发掘用户需求。其次再依据系统功能来确立系统的用例 (Use Case) 模型。用例是系统中的一个功能单元, 可以被描述为参与者与系统之间的一次交互作用。用例模型的用途是列出系统中的用例和参与者, 并显示哪个参与者参与了哪个用例的执行。在UML中, 角色代表位于系统之外和系统进行交互的一类对象, 用它可以对软件系统与外界发生的交互进行分析和描述。在这里, 我们对机房管理系统涉及到的角色进行分析, 可以将机房管理系统中的角色分为三个:机房管理人员:需要对系统进行管理, 对业余开放机房进行安排;教务处, 负责实验课程的安排, 需要对实验课程表进行管理和维护, 还需要进行数据的导入导出, 信息的查询和统计;校园一卡通系统, 一个外部系统, 对业余开放费用进行结算。在确定角色之后, 设计出的用例图如下:
在设计用例图的时候, 需要清楚地区分用例与用例图。用例只是简单地描述了用户要求系统应具备的功能;而用例图把用户、用例都包含在了一个系统之中, 或者一个或多个子系统中。尽管执行者在用例图中是用类似人的图形来表示, 但执行者并不一定是实体的人, 也可以是一个外部的系统, 它可能需要从当前系统中获取信息, 或者是外部信息的提供者。总之, 它与当前系统有交互作用, 如本例中的校园一卡通系统。
2.2 静态建模
静态建模的主要任务是找出系统中的类和对象, 并确定它们之间的关系, 用类图来描述。根据用例图和它的文本描述即可识别出大部分的对象, 而其中需要处理分析和保存的信息都可能是一个类或对象。在分析了机房管理系统的类及其关系之后, 可以得出如图2所示的类图, 其中主要给出了类的属性和操作。
在现实系统中, 类往往是和其他的类相互联系的。在UML中, 它们之间的关系分为关联 (association) 、泛化 (generalization) 、依赖 (dependence) 和细化 (refinement) 4种。如图2中黑色箭头所表示的是最普通的关联关系, 而空心箭头所表示的即为依赖关系。
2.3 动态建模
动态建模是指使用UML提供的状态图、活动图、时序图和协作图构建系统动态视图模型。用例图是对系统功能需求的一种图示表达, 只描述了"谁或什么使用了该系统, 交互中, 它们扮演什么角色", 在UML中, 除了建立用例模型之外, 还要分析系统各模块的工作流程。本文通过系统的工作流程分析和对象交互分析来建立机房管理系统的时序图。时序图主要表示以时间安排的对象之间的交互, 描述对象之间动态的交互关系, 着重体现对象间消息传递的时间顺序。时序图中有两个轴:水平轴表示不同的对象;垂直轴表示时间。对象之间的通信通过消息表示, 当收到信息时, 接收对象即激活。在机房管理系统中, 系统管理员登录系统后, 可以对机房业余开放进行管理, 并且可以得到系统返回的结果。其时序图如图3所示。
时序图的用途是用来表示用例中行为的时间顺序, 当执行一个用例行为时, 顺序图中的每条消息对应一个类操作或状态机中引起转换的触发事件。
2.4 实现建模
配置图描述了系统硬件的物理拓扑结构以及在这些结构上执行的组件, 可以显示计算机节点的拓扑结构和通讯路径、节点上运行的软件组件、软件组件包含的逻辑单元 (对象) 等。利用UML的配置图, 可以从更抽象的系统设计角度上, 考察每一个软件模块、每一个软件的可执行体在物理节点之间的通信方式。本系统结构基于c/s架构, 配置图如图4所示。图中的立方体表示系统配置的节点, 包括服务器、Switch和客户端PC机。
系统在教务处部署一台数据库服务器, 此外通过交换机与校园一卡通服务器, 由校园一卡通系统提供机房业余开放费用的结算。另外教务处服务器配备一台备份服务器。备份服务器与主服务器通过心跳线相连, 实现双机热备份。在系统运行时, 备份服务器与主服务器同步工作, 使各服务器中的数据保持一致。当主服务器出现故障时, 备份服务器可立即投入工作, 使系统得以快速恢复。
3、结束语
本文通过机房管理系统的分析和设计, 介绍了UML的实际建模过程。在系统开发过程中, 使用UML将系统的分析、设计和实现有机集成起来, 便于对系统在更高抽象层次上进行维护提高系统的可扩展性。UML提供的丰富视图从多个视角描述系统的不同侧面, 可以有效地用于软件系统的建模、分析与设计。利用上面的建模过程进行系统分析, 为后面的编码设计工作和测试及配置工作奠定了坚实的基础。
摘要：统一建模语言 (UML) 是面向对象分析和设计过程中重要的建模工具, 适用于软件生命周期的各个阶段。使用UML对机房管理系统进行需求建模, 静态建模, 动态建模和实现模型的建模。将UML应用在系统的的需求, 设计, 实现等阶段, 提高了系统的可维护性和扩展性。
关键词：UML,机房管理,建模
参考文献
[1].im Arlow, Ila Neustadt著.方贵宾等译.UML和统一过程实用面向对象的分析和设计[M].机械工业出版社, 2003
[2].周世兵, 刘渊.运用UML为软件项目建模研究[J].计算机应用研究, 2002 (8)
