NBA 数据分析系统
软件需求
1. 引言
1.1 目的
本文档描述了 NBA 数据分析系统的功能需求和非功能需求。开发小组的软件系统实现与验证工作都以此文档为依据。
除特殊说明之外,本文档所包含的需求都是高优先级需求。
1.2 范围
NBA 数据分析系统是为 NBA 球迷开发的数据分析系统,在提高观众对 NBA 球队和球员的认识。
1.3 参考文献
1、 IEEE 标准
2. 总体描述
2.1 商品前景
2.1.1 背景与机遇
近年来,NBA 赛事的收视率不断上升,越来越多的年轻人开始关注 NBA 赛事,并有了自己喜爱的 NBA 球队和球员,但是他们常常只在宏观上知道球队和球员的情况,难于从微观数据上分析球队和球员的情况,NBA 数据分析系统 DASN 就是为满足球迷这一需求所开发的。
NBA 数据分析系统 DASN 就是为满足球迷想从微观上了解 NBA 球队和球员情况的要求而开发的,它包括一个数据集中服务器和多个客户端。数据集中服务器将所有的数据存储起来进行维护。用户通过客户端完成日常任务,客户端与数据集中服务器才是实时通信的方式完成数据交换。
2.1.2 业务需求
· 系统上线运行 1 个月后,收视率增加,球迷对 NBA 赛事满意度上升
BR1: 在系统上线运行 1 个月后,收视率上升 10%
BR2: 在系统上线运行 1 个月后,球迷对 NBA 赛事满意度上升 10%
2.2 商品功能
SF1:提供可靠即时的 NBA 数据
SF2:提高观众满意度
SF3:增加收视率
2.3 用户特征
2.4 约束
CON1:系统将运行在 Window 7 操作系统上
CON2:系统不使用 Web 界面,而是图形界面
CON3:项目要使用持续集成方法进行开发。
CON4:在开发中,开发者要提交软件需求规格说明文档、设计描述文档和测试报告。
2.5 假设和依赖
AE1:NBA 赛事数据由数据生成程序不断添加动态数据。
3.用户界面
UI1:球队/球员信息查找
UI1.1:用户输入要查找的球队/球员名称,选择赛季总数据或场均数据并点击查找按钮时,系统应该显示查找结果界面,如下图
UI2 球队球员信息排序
UI2.1:在用户点击排序按钮时,系统应该显示排序界面
UI2.2:在用户选择排序依据,选择排序方式和排序数据,并点击确认按钮时,系统应该显示排序后的列表,如下图:
UI3 球员筛选
UI3.1:在用户点击筛选按钮时,系统应该显示筛选界面
UI3.2:在用户选择筛选依据和筛选数据并点击确认按钮时,系统应该显示筛选结果列表,如下图:
UI4 当天热点球员/赛季热点球员/赛季热点球队/进步最快球员查看
UI4.1:用户选择热点查看,系统应该显示热点球员/球队查看界面
UI4.2:用户选择热点排序依据,并点击查看按钮,系统应该显示当前排序依据条件筛选出的前 5 位热点球员/球队
UI5 查看每场比赛的数据
UI5.1 用户选择查看比赛数据,系统显示查看比赛界面
UI5.2 用户选择查找比赛的日期期间,系统显示在此比赛期间发生的所有比赛数据
UI5.3 用户选择查找比赛的队伍,系统显示此球队参加的比赛数据
UI5.4 用户选择查找比赛的球员,系统显示此球员参加的比赛数据
项目设计
1 引言:
内容和说明 | |
1 编写目的(说明整个文档所有达到的目标) | 本文档提供 NBA 数据分析系统的软件架构概览,采用若干架构视图描述系统的不同方面,以便表示架构系统所需要的重要架构决策 |
2.对象与范围(说明整个文档的内容范围和针对的读者对象) | 本文档的读者是宇宙无敌工作组团队内的开发和管理人员,参考了 RUP 的《软件架构文档模板》,用于指导下一循环的代码开发和测试工作 |
3.参考文献(说明) | 《软件需求规格说明书》,宇宙无敌工作组《软件架构文档模板》,RationaSoftware Corporation,2002;The Object Management Group (OMG), The Unified Modeling Language Specification v1.4, 2003 |
4.名词与术语(说明文档中常用的技术缩略和相关词条) | DASN(Data Analysis System of NBA) |
2 逻辑视角:
系统分为以下 3 个逻辑层次。
1)表示层:用于前台界面展示和和配置的层次。
2)业务层:包含业务控制和逻辑的层次。
3)数据层:定义和储存系统中相关数据的层次
系统可以部署在 1 个物理层次。
1)访问层:用于用户访问系统的层次
2)业务层:部署业务控制和逻辑的层次
3)数据层:部署和存储系统中相关数据的层次
系统的架构设计如下。
系统架构中的对象分为:
1)UI 对象,负责处理系统数据的展现和用户的交互。
2)IController 对象,控制器负责获取用户输入,并调用 IService 模块的服务。
3)BLService 对象,负责提供服务的抽象接口,获取从数据端组装好的数据。
4)BLServiceImpl 对象,负责对于抽象接口的实现模块
5)PO 对象,负责封装从 DataService 中获取的数据
6)VO 对象,负责封装从 BlService 中获取的数据
系统中
7)DataService 对象,负责提供数据服务的接口,处理数据,封装数据成对象:
3 组合视角
3.1 开发包图
NBA 信息检索系统客户端开发包图如下图所示:
3.2 运行时进程
在 NBA 信息查看系统中,展示层,逻辑层和数据层君部署在客户端,各个客户端有各自的进程。
图 5 进程图
3.3 物理部署
NBA 信息查看系统中客户端构件是放在客户端机器上。部署图如图 6 所示。
图 6 部署图
4 接口视角
4.1 模块的职责
客户端模块模块视图如下图所示
下表为客户端各层的职责
层 | 职责 |
启动模块 | 负责初始化客户端,启动用户界面 |
用户界面层 | 基于窗口的 NBA 信息检索客户端用户界面 |
业务逻辑层 | 对于用户界面的输入进行响应并进行业务处理逻辑 |
数据层 | 负责数据的持久化及数据访问接口 |
接口 ID | 连接组件 | 接口信息 | |
I1 | 连接 UI 和 BlService | 语法 | Return(Response)Interface(Request) |
前置条件 | 用户输入正确 | ||
后置条件 | 处理控制组件处理请求并且响应 | ||
不变量 | 无 | ||
I2 | 连接 ServiceImp 和 DataService | 语法 | Return(DataSet)Interface(command) |
前置条件 | 无 | ||
后置条件 | 返回数据对象 | ||
不变量 | 无 |
借用查看球队信息用例来说明层之间的调用,每一层之间都是由上一层依赖了一个接口(需接口),而下层实现了这个接口(供接口)。TeamBLService 提供了 Team 界面所需要的所有业务逻辑功能。TeamDataService 提供了对持久化数据的查看功能。这样的实现就大大降低了层与层之间的耦合。
4.2 用户界面层的分解
根据需要,系统 2 个用户界面:球队主界面和球员主界面。界面跳转如下图所示:
4.2.1 用户界面层模块的职责
如下表所示为用户界面层模块的职责。
模块 | 职责 |
MainFrame | 界面 Frame,负责界面的显示和界面的跳转 |
4.2.2 用户界面层模块的接口规范
用户界面层模块的接口规范如下表所示:
MainFrame | 语法 | Init(args:String[]) |
前置条件 | 无 | |
后置条件 | 显示 Frame |
用户界面层需要的服务接口如下表所示:
服务名 | 服务 |
Businesslogicservice.*BLService | 每个界面都有一个相应的业务逻辑接口 |
4.2.3 用户界面模块设计原理
用户界面利用 Java 的 Swing 和 AWT 库来实现。
4.3 业务逻辑层的分解
业务逻辑层包括多个针对界面的业务逻辑处理对象。例如,Player 对象负责处理 Player 界面的业务逻辑;Team 对象负责处理 Team 界面的业务逻辑。业务逻辑层的设计如下图所示:
4.3.1 业务逻辑层模块的职责
业务逻辑层模块的职责如下表所示:
模块 | 职责 |
Matchbl | 负责实现对应球员和球队界面所需要的关于比赛的服务 |
Playerbl | 负责实现对应球员界面所需要的服务 |
Teambl | 负责实现对应球队界面所需要的服务 |
4.4 数据层的分解
数据层主要给业务逻辑层提供数据访问服务,包括对于持久化数据的查。Player业务逻辑需要的服务由PlayerDataService接口提供。由于持久化数据的保存可能存在多种格式:Txt文件,数据库等,所示抽象了数据服务。数据层模块的描述具体如下图所示。
4.4.1 数据层模块的职责
数据层模块的职责如下表所示:
模块 | 职责 |
PlayerDataService | 持久化数据层的接口,提供集体/个体查服务 |
PlayerDataServiceTxtFileImpl | 基于 Txt 文件的持久化数据库的接口,提供集体/个体查服务 |
PlayerDataServiceMySqlImpl | 基于 MySQL 数据库的持久化数据库接口,提供集体/个体查服务 |
5 结构视角
5.1 业务逻辑层的分解
5.1.1 MatchBl 模块
(1) 模块概述
MatchBl 模块承担的需求参见需求规格说明文档功能需求及相关非功能需求
MatchBl模块的职责及接口参见软件系统结构描述分档
(2) 整体结构
根据体系结构的设计,我们将系统分为展示层、业务逻辑层、数据层。每一层之间为了增加灵活性,我们会添加接口。比如展示层和业务逻辑层之间,我们添加 businesslogicservice.Matchblservice.MatchBLService 接口。业务逻辑层和数据层之间添加 dataservice.Matchdataservice.MatchDataService 接口。为了隔离业务逻辑职责和逻辑控制职责,我们添加了 MatchController,这样 MatchController 会将对比赛的业务逻辑处理委托给 Match 对象。MatchPO 是作为比赛记录的持久化对象被添加到设计模型中去的。
Matchbl 模块各个类的职责如下表所示:
模块 | 职责 |
Match | 负责实现比赛界面所需要的服务 |
AbstractQueue | PlayerQueue 和 TeamQueue 的父类 |
MatchController | 负责实现比赛相关的服务 |
PlayerQueue | 负责保存一个球员的所有比赛信息 |
PlayerYourInfo | 负责保存对方球队的信息 |
TeamQueue | 负责保存一个球队的所有比赛信息 |
(3) 模块内部类的接口规范
MatchController 和 Match 的接口规范如下表所示:
提供的服务(供接口) | ||
MatchController.update | 语法 | public void update(); |
前置条件 | 需要查看是否有新的比赛信息 | |
后置条件 | 查看是否有新的比赛信息更新,如有,则更新比赛对应的球队球员的信息 | |
MatchController.changed | 语法 | public boolean changed() |
前置条件 | 需要查看是否有新的文件更新 | |
后置条件 | 如有新的文件更新,则返回 true,没有,则返回 false | |
MatchController.getTodayMatches | 语法 | public MatchesPO[] getTodayMatches() |
前置条件 | 得到今天进行的比赛信息 | |
后置条件 | 返回今天发生的比赛 | |
MatchController.getAllMatches | 语法 | public MatchesPO[] getAllMatches() |
前置条件 | 得到所有的比赛信息 | |
后置条件 | 返回所有的比赛信息 | |
MatchController.getRecentPlayerMatches | 语法 | public MatchesPO[] getRecentPlayerMatches(String playerName, int num) |
前置条件 | 得到和 playerName 相应的最近 num 场比赛 | |
后置条件 | 返回和 playerName 相应的最近 num 场比赛 | |
MatchController.getRecentTeamMatches | 语法 | public MatchesPO[] getRecentTeamMatches(String teamName, int num) |
前置条件 | 得到和 teamName 相应的最近 num 场比赛 | |
后置条件 | 返回和 teamName 相应的最近 num 场比赛 | |
MatchController.getPlayerMatches | 语法 | public MatchesPO[] getPlayerMatches(String playername) |
前置条件 | 得到和 playername 相应所有比赛 | |
后置条件 | 返回和 playername 相应的所有比赛 | |
MatchController.getTeamMatches | 语法 | public MatchesPO[] getTeamMatches(String teamname) |
前置条件 | 得到和 teamname 相应所有比赛 | |
后置条件 | 返回和 teamname 相应的所有比赛 | |
MatchController.getTimeMatches | 语法 | public MatchesPO[] getTimeMatches(Date date1, Date date2) |
前置条件 | 得到在 date1 和 date2 之间发生的所有比赛 | |
后置条件 | 返回在 date1 和 date2 之间发生的所有比赛 | |
需要的服务(需接口) | ||
服务名 | 服务 | |
Match.getAllMatchData | 得到所有比赛的数据 | |
Match.getTodayMatches | 得到今天发生的比赛信息 | |
Match.getRecentPlayerMatches | 得到球员最近的比赛 | |
Match.getRecentTeamMatches. | 得到球队最近的比赛 | |
Match.changed | 询问是否有新的比赛信息 | |
Match.getNewMatches | 得到新的比赛的信息 |
(4) 业务逻辑层的动态模型
下图是 Match 领域对象得到球员场均数据的顺序图
得到球员场均数据的顺序图
5.1.2 PlayerBl 模块
(1) 模块概述
PlayerBl 模块承担的需求参见需求规格说明文档功能需求及相关非功能需求
PlayerBl模块的职责及接口参见软件系统结构描述分档
(2) 整体结构
根据体系结构的设计,我们将系统分为展示层、业务逻辑层、数据层。每一层之间为了增加灵活性,我们会添加接口。比如展示层和业务逻辑层之间,我们添加 businesslogicservice.Playerblservice.PlayerBLService 接口。业务逻辑层和数据层之间添加 dataservice.Playerdataservice.PlayerDataService 接口。为了隔离业务逻辑职责和逻辑控制职责,我们添加了 PlayerController,这样 PlayerController 会将对比赛的业务逻辑处理委托给 Player 对象。PlayerPO 是作为比赛记录的持久化对象被添加到设计模型中去的。
Playerbl 模块各个类的职责如下表所示:
模块 | 职责 |
Player | 保留所有的 player 列表和每个 player 的比赛信息 |
PlayerController | 负责实现对应于球员界面所需要的服务 |
SortBy | 负责实现球员排序的服务 |
(3) 模块内部类的接口规范
PlayerController 和 Player 的接口规范如下表所示:
提供的服务(供接口) | ||
PlayerController.sortAvePlayers | 语法 | public PlayerMatchVO[] sortAvePlayers(PlayerSortBy playerSortBy, SortType sortType) |
前置条件 | 界面层需要对球员场均信息进行排序 | |
后置条件 | 调用 Player 领域对象的 sortAvePlayers 方法 | |
PlayerController.sortTotalPlayer | 语法 | public PlayerMatchVO[] sortTotalPlayers(PlayerSortBy playerSortBy, SortType sortType) |
前置条件 | 界面层需要对球员所有信息进行排序 | |
后置条件 | 调用 Player 领域对象的 sortTotalPlayers 方法 | |
PlayerController.screenAvePlayers | 语法 | public PlayerMatchVO[] screenAvePlayers(String playerPosition, Area playerArea, PlayerSortBy sortBy) |
前置条件 | 界面层需要使用场均数据筛选 | |
后置条件 | 调用 Player 领域对象的 screenAvePlayers 方法 | |
PlayerController.findPlayer | 语法 | public PlayerMatchVO[] screenTotalPlayers(String playerPosition, Area playerArea, PlayerSortBy sortBy) |
前置条件 | 界面层需要使用所有数据筛选 | |
后置条件 | 调用 Player 领域对象的 screenTotalPlayers 方法 | |
PlayerController.getDayHorPlayer | 语法 | public PlayerMatchVO[] getDayHotPlayer(PlayerSortBy sortby) |
前置条件 | 界面层需要当日热点球员信息 | |
后置条件 | 调用 Player 领域对象的 getDayHotPlayer 方法 | |
PlayerController.getSeasonHotPlayer | 语法 | public PlayerMatchVO[] getSeasonHotPlayer(PlayerSortBy sortby) |
前置条件 | 界面层需要当季热点球员信息 | |
后置条件 | 调用 Player 领域对象的 getSeasonHotPlayer 方法 | |
PlayerController.getPromotePlayer | 语法 | public PlayerMatchVO[] getPromotePlayer(PlayerSortBy sortby) |
前置条件 | 界面层需要进步最快球员的信息 | |
后置条件 | 调用 Player 领域对象的 getPromotePlayer 方法 | |
PlayerController.fuzzilyFind | 语法 | public Iterator fuzzilyFind(String info) |
前置条件 | 界面层需要模糊查找相应球员 | |
后置条件 | 返回字符串匹配的所有球员全名 | |
PlayerController.findPlayer | 语法 | public PlayerPO findPlayer(String info) |
前置条件 | 需要通过球员全名得到一个球员对象 | |
后置条件 | 返回一个球员对象 | |
需要的服务(需接口) | ||
服务名 | 服务 | |
Player.getAllPlayerData | 得到所有球员的基本信息 |
(4) 业务逻辑层的动态模型
下图为 Player 领域对象需要根据排序条件对数据进行排序时候的顺序图
球员排序顺序图
5.1.3 TeamBl 模块
(1) 模块概述
TeamBl 模块承担的需求参见需求规格说明文档功能需求及相关非功能需求
TeamBl模块的职责及接口参见软件系统结构描述分档
(2) 整体结构
根据体系结构的设计,我们将系统分为展示层、业务逻辑层、数据层。每一层之间为了增加灵活性,我们会添加接口。比如展示层和业务逻辑层之间,我们添加 businesslogicservice.Teamblservice.TeamBLService 接口。业务逻辑层和数据层之间添加 dataservice.Teamdataservice.TeamDataService 接口。为了隔离业务逻辑职责和逻辑控制职责,我们添加了 TeamController,这样 TeamController 会将对比赛的业务逻辑处理委托给 Team 对象。TeamPO 是作为比赛记录的持久化对象被添加到设计模型中去的。
Teambl 模块各个类的职责如下表所示:
模块 | 职责 |
Team | 球队的领域模型对象,拥有所有球队的基本信息(球队全名,缩写,所在地,赛区,分区,主场,建立时间),以及相应球队的比赛信息可以解决球队查看的问题 |
TeamController | 负责实现对应于球队界面所需要的服务 |
SortTool | 提供球队排序的服务 |
(3) 模块内部类的接口规范
TeamController 和 Team 的接口规范如下表所示:
提供的服务(供接口) | ||
TeamController. getHotTeams | 语法 | public TeamMatchVO[] getHotTeams(TeamSortBy sortby) |
前置条件 | 需要得到热点球队的信息 | |
后置条件 | 调用 Team 领域对象的 getHotTeams 方法 | |
TeamController.getSortedAveTeams | 语法 | public TeamMatchVO[] getSortedAveTeams(TeamSortBy sortby, SortType type) |
前置条件 | 需要使用场均数据排序的球队信息 | |
后置条件 | 返回使用场均数据排序的球队信息 | |
TeamController.getSortedTotalTeams | 语法 | public TeamMatchVO[] getSortedTotalTeams(TeamSortBy sortby, SortType type) |
前置条件 | 用户需要知道球队的位置信息 | |
后置条件 | 返回球队所属分区 | |
TeamController.getPlayers | 语法 | public String[] getPlayers(String team) |
前置条件 | 需要相应队伍的所有成员的名字 | |
后置条件 | 返回相应队伍的所有成员的名字 | |
TeamController.getTotalTeam | 语法 | public TeamMatchVO getTotalTeam(String teamname) |
前置条件 | 得到相应队伍的总信息 | |
后置条件 | 返回相应队伍的总信息 | |
TeamController.getAveTeam | 语法 | public TeamMatchVO getAveTeam(String teamname) |
前置条件 | 得到相应队伍的场均数据 | |
后置条件 | 返回相应队伍的场均数据 | |
TeamController.fuzzilyFind | 语法 | public Iterator fuzzilyFind(String info) |
前置条件 | 需要模糊查找球队 | |
后置条件 | 返回和相应字符串配对的所有队伍名称字符串的迭代器 | |
TeamController.getTeamData | 语法 | public TeamPO getTeamData(String team) |
前置条件 | 需要相应的队伍的数据 | |
后置条件 | 返回和相应队伍名称对应的球队对象 | |
TeamController.getAllPlayerMatchAve | 语法 | public PlayerMatchVO[] getAllPlayerMatchAve(String teamname) |
前置条件 | 需要根据球队简称查找其下的球员的场均数据 | |
后置条件 | 返回根据球队简称查找其下球员的场均数据 | |
TeamController.getAllPlayerMatchTotal | 语法 | public PlayerMatchVO[] getAllPlayerMatchTotal(String teamname) |
前置条件 | 需要根据球队简称查找其下的球员的总数据 | |
后置条件 | 返回根据球队简称查找其下的球员的总数据 | |
TeamController.getPlayerBase | 语法 | public PlayerPO getPlayerBase(String playername) |
前置条件 | 需要通过球员名字获得球员的基本信息 | |
后置条件 | 返回通过球员名字获得球员的基本信息 | |
需要的服务(需接口) | ||
服务名 | 服务 | |
Team.getAllTeamData | 得到所有球队的基本信息 |
(4) 业务逻辑层的动态模型
下图为寻找一个球队信息时候的顺序图
寻找球队信息的顺序图
5.2 数据层的分解
5.2.1 MatchData 模块
提供的服务(供接口) | ||
MatchData.getAllMatchData | 语法 | public MatchesPO[] getAllMatches(); |
前置条件 | 逻辑层需要所有比赛的数据 | |
后置条件 | 返回所有比赛的数据 | |
MatchData.getTodayMatches | 语法 | public MatchesPO[] getTodayMatches(); |
前置条件 | 逻辑层需要今日比赛的数据 | |
后置条件 | 返回今日比赛的数据 | |
MatchData.getRecentPlayerMatches | 语法 | public MatchesPO[] getRecentPlayerMatches(String playerName, int num); |
前置条件 | 逻辑层需要最近 num 场比赛对应球员的信息 | |
后置条件 | 返回相应的比赛信息 | |
MatchData.getRecentTeamMatches | 语法 | public MatchesPO[] getRecentTeamMatches(String teamName, int num); |
前置条件 | 逻辑层需要最近 num 场比赛对应球队的信息 | |
后置条件 | 返回相应的比赛信息 | |
MatchData.changed | 语法 | public boolean changed(); |
前置条件 | 数据层需要确定是否有新的 txt 文件添加 | |
后置条件 | 若有新的文件添加则返回 true,如果没有新文件添加则返回 false | |
MatchData.getNewMatches | 语法 | public MatchesPO[] getNewMatches(); |
前置条件 | 逻辑层需要最新的比赛数据 | |
后置条件 | 返回最新的比赛数据 |
5.2.2 PlayerData 模块
提供的服务(供接口) | ||
PlayerData.getAllPlayerData | 语法 | public PlayerPO[] getAllPlayerData(); |
前置条件 | 逻辑层需要所有球员的基本信息 | |
后置条件 | 返回所有球员的基本信息的数组 |
5.2.3 TeamData 模块
提供的服务(供接口) | ||
TeamData.getAllTeamData | 语法 | public TeamPO[] getAllTeamData(); |
前置条件 | 逻辑层需要所有球队的基本信息 | |
后置条件 | 返回所有球员的基本信息的数组 |
6 依赖视角
下图是客户端各自的包之间的依赖关系。
客户端包图
7 信息视角
7.1 数据持久化对象
系统的 PO 类就是对应的相关的实体类,在此只做简单的介绍
MatchesPO 类包含比赛的双方队伍信息和比赛的日期的属性
MatchPlayerPO 类包含参加比赛球员的球员名称,所属球队,参赛场数,先发场数,篮板数,助攻数,在场时间,投篮命中率,三分命中率,罚球命中率,进攻数,防守数,抢断数,盖帽数,失误数,犯规数,得分,效率,GmSc 效率值,真实命中率,投篮效率,篮板率,进攻篮板率,防守篮板率,助攻率,抢断率,盖帽率,失误率,使用率,球队和是否为脏数据的属性
MatchPO 类包含参加比赛球员的球员名称,所属球队,参赛场数,先发场数,篮板数,助攻数,在场时间,投篮命中率,三分命中率,罚球命中率,进攻数,防守数,抢断数,盖帽数,失误数,犯规数,得分,效率,GmSc 效率值,真实命中率,投篮效率,篮板率,进攻篮板率,防守篮板率,助攻率,抢断率,盖帽率,失误率,使用率和是否为脏数据的属性
MatchTeamPO 类包含球队的队员,球员得分,全队所有得分,和球队名字的属性
PlayerPO 类包含球员大身图片,全身图片,姓名,球衣号码,位置,身高的英尺,身高的英寸,体重(磅),生日,年龄,球龄和毕业院校的属性
TeamPO 类包含球队队伍图标,队伍名称,名称缩写,所在地,赛区,分区,主场,建立时间的属性
持久化队伍对象 TeamPO 的定义如下所示:
public class TeamPO {
private Document image; // 队伍图标
private String name; // 队伍名称
private String nameAbridge; // 名称缩写
private String address; // 所在地
private String matchArea; // 赛区
private Area playerArea;// 分区
private String manage; // 主场
private int foundYear; // 建立时间
public String toString()
{
return name+" "+nameAbridge+" "+address+" "+matchArea+" "+manage+" ";
}
public TeamPO(Document image, String name, String nameAbridge, String address,
String matchArea, Area playerArea, String manage, int foundYear) {
super();
this.image = image;
this.name = name;
this.nameAbridge = nameAbridge;
this.address = address;
this.matchArea = matchArea;
this.playerArea = playerArea;
this.manage = manage;
this.foundYear = foundYear;
}
public Document getImage() {
return image;
}
public String getName() {
return name;
}
public String getNameAbridge() {
return nameAbridge;
}
public String getAddress() {
return address;
}
public String getMatchArea() {
return matchArea;
}
public Area getPlayerArea() {
return playerArea;
}
public String getManage() {
return manage;
}
public int getFoundYear() {
return foundYear;
}
}
7.2 Txt 持久化格式
1.比赛信息
文件命名格式:
例如:
文件内容格式:
赛季日期对阵队伍
13-14_01-01_CHA-LAC
时间;对阵队伍;比分; 第一节比分;第二节比分;第三节比分;第四节比分;
队伍 1 缩写
球员名;位置;在场时间;投篮命中数;投篮出手数;三分命中数;三分出手数;罚球命中数;罚
球出手数;进攻 (前场) 篮板数;防守 (后场) 篮板数;总篮板数;助攻数;盖帽数;失误数;犯规 数;
个人得分;
……
队伍 2 缩写
球员名;位置;在场时间;投篮命中数;投篮出手数;三分命中数;三分出手数;罚球命中数;罚
球出手数;进攻 (前场) 篮板数;防守 (后场) 篮板数;总篮板数;助攻数;盖帽数;失误数;犯规 数;
个人得分;
……
例如:
01-01;CHA-LAC;85-112;
27-25;29-31;13-25;16-31;
CHA
Anthony Tolliver;F;37:01;4;11;3;10;0;0;0;3;3;1;0;0;0;1;11;
Josh McRoberts;F;28:10;4;8;2;4;0;0;0;3;3;4;1;0;0;2;10;
AJefferson;C;30:00;7;15;0;0;0;0;1;11;12;4;1;0;3;0;14;
Gerald Henderson;G;32:19;3;11;0;1;6;6;0;0;0;1;0;0;0;3;12;
Kemba Walker;G;33:13;4;10;1;4;5;5;0;7;7;3;2;0;5;1;14;
Cody Zeller;;19:50;0;6;0;0;6;6;3;1;4;1;2;0;1;3;6;
Chris Douglas-Roberts;;17:26;1;1;0;0;0;0;1;1;2;0;0;0;2;0;2;
Ramon Sessions;;21:42;3;9;0;2;2;2;1;1;2;4;1;0;2;3;8;
Bismack Biyombo;;17:36;3;5;0;0;2;3;1;4;5;1;0;1;2;0;8;
Jannero Pargo;;2:43;0;0;0;0;0;0;0;0;0;0;0;0;1;0;0;
LAC
Jared Dudley;F;32:40;7;10;6;9;0;0;0;1;1;5;0;0;1;2;20;
Blake Griffin;F;38:07;14;20;1;2;2;4;2;10;12;2;0;0;4;4;31;
DeAndre Jordan;C;36:31;3;4;0;0;0;0;3;9;12;2;1;1;3;3;6;
JamaCrawford;G;35:20;5;14;1;8;0;0;0;2;2;4;2;2;0;2;11;
Chris Paul;G;32:23;7;14;1;4;2;2;0;4;4;14;1;0;3;1;17;
Darren Collison;;16:08;3;3;0;0;2;2;1;2;3;5;5;0;0;2;8;
Matt Barnes;;19:32;2;10;0;6;0;0;1;4;5;2;0;0;0;2;4;
Antawn Jamison;;4:22;0;2;0;2;0;0;0;0;0;0;0;0;0;0;0;
Willie Green;;12:40;2;3;0;1;0;0;0;2;2;2;0;0;1;1;4;
Ryan Hollins;;10:55;2;3;0;0;1;2;1;2;3;0;0;0;1;3;5;
Byron Mullens;;1:22;2;2;2;2;0;0;0;0;0;0;0;0;0;0;6;
- 球员信息
文件命名格式(图片会包含.png 后缀) :
例如:
球员姓名
Aaron Gray
文件内容格式:
例如:
╔═══════════════╤═══════════════╗
║Name │ 姓名 ║
╟───────────────┼───────────────╢
║Number │ 球衣号码 ║
╟───────────────┼───────────────╢
║Position │ 位置 ║
╟───────────────┼───────────────╢
║Height │ 身高(英尺 – 英寸) ║
╟───────────────┼───────────────╢
║Weight │ 体重(磅) ║
╟───────────────┼───────────────╢
║Birth │ 生日(月 日, 年) ║
╟───────────────┼───────────────╢
║Age │ 年龄 ║
╟───────────────┼───────────────╢
║Exp │ 球龄 ║
╟───────────────┼───────────────╢
║Schoo │ 毕业学校 ║
╚═══════════════╧═══════════════╝
╔═══════════════╤═══════════════╗
║Name │Aaron Brooks ║
╟───────────────┼───────────────╢
║Number │0 ║
╟───────────────┼───────────────╢
║Position │G ║
╟───────────────┼───────────────╢
║Height │6-0 ║
╟───────────────┼───────────────╢
║Weight │161 ║
╟───────────────┼───────────────╢
║Birth │JAN 14, 1985 ║
╟───────────────┼───────────────╢
║Age │29 ║
╟───────────────┼───────────────╢
║Exp │5 ║
╟───────────────┼───────────────╢
║Schoo │Oregon ║
╚═══════════════╧═══════════════╝
- 球队信息
文件命名格式:
所有球队的文本信息均包含在 teams 文件中,球队标志命名方法:
例如:
文件内容格式:
例如:
球队缩写(大写).svg
CHI.svg
║ 球队全名 │ 缩写 │ 所在地 │ 赛区 │ 分区 │ 主场 │ 建立时间 ║
╔══════════╤═══╤═════════════╤═╤════════════╤════════════════════╤════╗
║Hawks │ATL│Atlanta │E│Southeast │Philips Arena │1949║
║Nets │BKN│Brooklyn │E│Atlantic │Barclays Center │1976║
╚══════════╧═══╧═════════════╧═╧════════════╧════════════════════╧════╝