CBA赛事管理系统需求分析.doc

目录
1 引言 3
1.1 立项背景 3
1.2 立项原因概述 3
1.3 UML 概述 3
1.4 参考文献 4
2 项目概述 5
2.1 面向的用户 5
2.2 实现目标 5
2.3 项目开发要求 5
2.4 开发工具 5
3 系统描述 6
3.1 系统概述 6
3.2 系统总体结构 6
3.3 系统各部分功能模块 6
4 系统分析 7
4.1 用例图 7
4.1.1赛事信息管理 7
4.1.2赛程安排管理 8
4.1.3比赛场地管理 9
4.1.4比赛赛数据计分管理 10
4.1.5人员信息管理 11
4.2 活动图 13
4.2.1赛程安排管理 13
4.2.2赛事信息的查询 13
4.2.3比赛场地安排管理 14
4.2.4比赛球员计分项目管理 15
4.2.5数据查询管理 16
4.2.6人员信息管理 17
4.3 时序图 17
4.3.1赛程安排时序图 17
4.3.2场地赛程安排时序图 18
4.3.3比赛球员统计计分时序图 20
4.3.4数据查询时序图 21
4.3.5 人员信息管理时序图 22
4.4 类分析 23
4.4.1赛程安排用例的实现 23
4.4.2比赛场地的用例实现 23
4.4.3 数据管理用例实现 24
4.4.4普同用户用例实现 24
4.4.5管理员用户用例实现 25
4.5 类设计 26
4.5.1赛事安排类关系图 26
4.5.2球员数据类关系图 27
4.5.3人员信息类关系图 28
5 系统接口 29
5.1 用户接口 29
5.2 硬件接口 29
6 性能需求 30
6.1 精度要求 30
6.2　时间特征 30
6.3　灵活性 30
7 软件属性 31
7.1 系统安全性 31
7.2 可维护性 31
8 其它需求 32
8.1 数据库需求 32
8.2 系统操作要求 32
8.3 故障及其处理 32

1 引言
1.1 立项背景
随着我国经济水平的不断提高，体育运动的迅猛发展，篮球运动是一项在我国普及最广的运动之一，各级各类的篮球比赛连连不断，目前，很多篮球比赛都采用手工的管理方式，为了提高篮球竞赛的管理制度，需要有一套针对于篮球赛事的管理系统。
1.2 立项原因概述
针对CBA赛事的特点，为了帮助提高篮球竞赛的管理水平，适应篮球竞赛当前市场化的需要，我们将开发一个CBA赛事管理系统
1.3 UML 概述
面向对象的系统分析与设计，包括OOA（面向对象分析）与OOD（面向对象设计）两个部分。其中OOA 的主要任务是分析问题，找出问题解决方案。同时，发现对象并分析对象内部构成和外部关系，建立软件系统的对象模型。OOD 的主要任务是根据已确立的系统对象模型，运用面向对象技术，设计对象与类，进而设计系统结构、人机界面、数据管理、任务管理等子系统。
UML（Unified Modeling Language）是第3 代的面向对象建模语言。UML 是由Rational 公司的面向对象技术研究专家Grady Booch、Ivar Jacobson 和Jim Rumbaugh 联合开发的。它采纳和扩展了Booch 标记法、OMT 的面向对象建模技术的方法，以及面向用例(Use-Case)的OOSE 方法，并且吸取了其他学者和软件厂商的建议。UML 在提交给OMG( Obicct ManagementGroup)后，最终成为大众所接受的标准建模语言。UML建模语言吸取和发展了Booch、OMT 和OOSE 方法，以及其它OO 和非OO 方法的优点。它融入了软件工程领域的新思想、新方法和新技术，提出如模板、扩展机制、活动图等新概念。UML 易于表达且功能强大，应用广泛。它不但适用于面向对象的软件分析与设计，还支持从需求分析开始的软件开发的全过程。UML 定义了一系列图形工具，以对现实世界进行面向对象建模。
标准建模语言UML 已成为面向对象技术的主流建模工具，支持系统分析、设计和实现等软件开发全过程。UML 定义了5 类10 种模型图，用于提供静态建模机制和动态建模机制。
静态模型包括用例图、类图、对象图、包图、构件图。配置图动态模型包括行为图（活动图，状态图）和交互图（顺序图，合作图）。
（1）用例图：描述应用领域需求与功能，以及事务（用例）之间的逻辑关系。
（2）类图：是显示一组类、接口、协作以及它们之间关系的图。
1）对象图：类的实例图。
2）包图：提供类图的分组优化机制
（3）行为图：描述跨越多个用例的对象行为（数据操作功能），包括活动图和状态图。
1）活动图：描述多用例和多对象的复杂行为及活动间的约束关系；或者说，描述复杂行为中的活动及其执行顺序。
2）状态图：描述单个对象的所有可能状态及转移条件。
（4）交互图：显示一个交互，由一组对象和它们之间的关系构成，其中包括在对象间传递的消息，包括顺序图和协作图。
1）顺序图：是强调消息的时间顺序的交互图。
2）协作图：是强调发送和接收消息的对象之间的结构组织的交互图。
（5）实现图：用于描述系统实现的一些特性，包括构件图和配置图。
1）构件图：描述软构件及相互间的依赖（及调用）关系，包括源文件、二进制文件、可执行文件。
2）配置图：描述构件运行环境及系统软硬件体系结构。
1.4 参考文献
[1] 齐志昌，谭庆平，宁洪.软件工程(第二版)[M].北京.高等教育出版社.2004
[2] 王珊，萨师煊.数据库系统概论（第四版）[M].北京.高等教育出版社.2006
......
2 项目概述
2.1 面向的用户
赛事管理员主要是查询、录入和修改赛事信息，参赛队员、观众主要是查询、系统管理员主要维护系统和数据处理。
2.2 实现目标
（1）建立一个具有友好界面，操作简单的CBA赛事管理系统；
（2） 能够更好的管理、维护和保存赛事的相关信息；
（3） 实现对参赛队员、裁判员信息录入，并建立完整的数据库，对所有的工作人员统一管理；
（4）管理员登陆本系统，可以查询、修改、更新系统数据，参赛队员和观众只能查询数据信息；
2.3 项目开发要求
（1）项目开发规范统一、模块划分；
（2）程序优化、安全并要有良好的可扩展性；
（3）用户界面简洁明了、操作简单实用；
（4）与用户保持良好的沟通，及时根据用户新的需求改善系统功能。
2.4 开发工具
Microsoft Visual C++ 6.0
Rational Rose2003

3 系统描述
3.1 系统概述
CBA赛事管理系统主要分为四大系统，分别是人员信息管理系统、参赛队信息管理系统、计分项目管理系统、赛事安排管理系统和场地管理系统。管理员可以对系统里面的数据进行修改、更新查询等操作，但一般人员只能进行查询操作。
CBA赛事管理系统
3.2 系统总体结构

参赛队信息管理
人员信息管理
赛事信息管理
计分项目管理
场地管理

查询参赛队信息

修改参赛队信息

录入参赛队信息
修改人员信息
录入人员信息
录入赛事信息
安排赛事
查询赛事
录入成绩

查询场地安排
查询人员信息
安排场地
查询成绩
统计成绩
修改成绩

CBA赛事管理系统
3.3 系统各部分功能模块

登陆界面

运动员登陆
普通用户登录
管理员登陆

成绩查询模块
管理员管理模块

成绩查询模块

4 系统分析
4.1 用例图
4.1.1赛事信息管理

用例分析：
用例名称：赛事信息
描述：赛事管理员录入所有的赛事情况（共有多少比赛）
标识符:uc1
优先级：A(高)
角色:赛事管理员
前置条件：赛事管理员已成功登录系统并具有录入赛事信息的权限
主事件流:
1.赛事管理员选择“赛事信息管理”选项，用例开始
2. 赛事管理员获取赛事信息表
3. 赛事管理员输入赛事信息并检查赛事信息的有效性
A1：信息无效
4．系统自动更新数据库的赛事信息表
6. 将更新的信息写入日志文件
7．用例结束
其他事件流：
A1:输入的赛事信息错误
(1)系统显示错误的提示信息 例如：一个参赛队在一个时间段只能打一场比赛
(2)返回主事件流第 3步

后置条件：系统成功将赛事信息赛程安排管理系统
特殊需求：

4.1.2赛程安排管理

用例分析：
用例名称：赛程安排管理
描述：赛事管理员使用赛程安排管理用例完成安排赛程任务
标识符:uc1
优先级：A(高)
角色:赛事管理员
前置条件：赛事管理员已成功登录系统并具有修改赛程安排的权限
主事件流:
1.赛事管理员选择“安排赛程管理”选项，用例开始
2. 赛事管理员打开赛事安排界面获取赛程信息表
3. 赛事管理员输入赛程信息并检查赛程信息的有效性
A1：信息无效
4．系统自动更新数据库的赛程信息表
6. 将更新的信息写入日志文件
7．用例结束
其他事件流：
A1:输入的赛程信息错误
(1)系统显示错误的提示信息
(2)返回主事件流第 3步
后置条件：系统成功将赛程安排信息记入计分项目管理系统
特殊需求：计分项目管理系统和赛程安排管理系统之间应该存在相应的接口
4.1.3比赛场地管理

用例分析：
用例名称：比赛场地管理
描述：安排参赛队的比赛场地使用情况。
角色：场地管理员
前置条件：场地时可利用的
主事件流:
1、场地管理员安排参赛队的比赛场地，用例开始
2. 场地管理员打开场地安排界面
3. 场地管理员安排场地并检查场地安排的有效性
A1：信息无效
4．系统自动更新数据库的场地安排信息
5. 将更新的信息写入日志文件
6．用例结束
其他事件流：
后置条件：
特殊需求：

4.1.4比赛赛数据计分管理

用例分析：
用例名称：比赛球员数据统计
描述：运动员在一场比赛中，在赛场上的表现以数据形式统计下来。
角色：数据管理员
前置条件：运动员在比赛中有上场。
主事件流:
1. 数据管理员选择“比赛球员数据统计”选项，用例开始
2. 打开比赛球员数据统计窗体
3. 选择需要编辑的球员
4. 数据管理员对球员的数据进行修改或添加
5. 数据管理员保存改动后的数据
6. 用例结束
其他事件流：
后置条件：
特殊需求：

用例名称：查看数据
描述：球员可对自己或其他球员数据查询
角色：球员
主事件流：
1. 查看数据
2. 查看得分，篮板，抢断，犯规，失误，助攻情况
3. 用例结束
其他事件流：
后置条件：
特殊需求：
4.1.5人员信息管理

用例分析：
用例名称：人员信息管理
描述：对人员信息进行统一的管理。
角色：管理员
前置条件：有与赛事有关的所有的人员档案资料
主事件流:
1、管理员获取人员信息，用例开始
2. 管理员打开人员信息管理界面
3. 管理员录入人员信息并设置访问权限
4．系统自动更新数据库的人员信息
5. 将更新的信息写入日志文件
6．用例结束
其他事件流：
后置条件：
特殊需求：

4.2 活动图
4.2.1赛程安排管理

4.2.2赛事信息的查询

4.2.3比赛场地安排管理

4.2.4比赛球员计分项目管理

4.2.5数据查询管理

4.2.6人员信息管理

4.3 时序图
4.3.1赛程安排时序图

4.3.2场地赛程安排时序图

4.3.3比赛球员统计计分时序图

4.3.4数据查询时序图

4.3.5 人员信息管理时序图

4.4 类分析
4.4.1赛程安排用例的实现

4.4.2比赛场地的用例实现

4.4.3 数据管理用例实现

4.4.4普同用户用例实现

4.4.5管理员用户用例实现

4.5 类设计
4.5.1赛事安排类关系图

4.5.2球员数据类关系图

4.5.3人员信息类关系图

5 系统接口
5.1 用户接口
说明人机交互界面的用户需求，如屏幕格式，报表，菜单的格式与内容及功能键定义。
5.2 硬件接口
本产品的用户一般需要通过终端进行操作，进入主界面后点击相应的窗口，分别进入相对应的界面(如：输入界面、输出界面)。用户对程序的维护，最好要有备份。6 性能需求
6.1 精度要求
（1）软件的输入精度:小数点后保留3位有效数字。
（2）输出数据精度的要求: 小数点后保留3位有效数字。
（3）传输过程中的精度: 小数点后保留3位有效数字。
6.2　时间特征
（1）WEB首页打开速度5s以下，web登陆速度 15s以下。
（2）系统能在高于实际系统运行压力1倍的情况下，稳定的运行12小时 。
（3）数据的转换和传送时间: 1秒以内。
（4）解题时间: 1秒以内 。
6.3　灵活性
（1）操作方式上的变化:该软件实用与现在流行的操作系统。
（2）精度和有效时限的变化:可以根据实际情况自行设置。

7 软件属性
7.1 系统安全性
通过sql的数据库安全设置，一定程度上保证了数据库的安全性。系统根据用户身份不同赋予不同权限，用户用密码登陆，同样也保证了系统数据的安全性。
定期备份数据库，以确保因病毒、系统崩溃等其他原因引起数据丢失。
7.2 可维护性
系统管理者和维护者须懂得SQL数据库应用等方面的技能，必要时由对其进行培训。8 其它需求
8.1 数据库需求
对数据库的静态结构，动态组织，访问信息的方式，使用频率以及数据的存储等方面提出需求。
8.2 系统操作要求
本系统使用SQL server（数据库） ，可利用其自带的各种功能进行管理。
对不同数据信息和其它信息分类存储，使用索引查找。
8.3 故障及其处理
为避免系统运行中故障造成的数据丢失，我们建议：
（1）重要数据用户应自行备份。
（2）做好数据库的日常维护工作。

- 31 -