篮球比赛数据统计系统的架构设计.docx

篮球比赛数据统计系统的架构设计.docx

《篮球比赛数据统计系统的架构设计.docx》由会员分享，可在线阅读，更多相关《篮球比赛数据统计系统的架构设计.docx（10页珍藏版）》请在冰豆网上搜索。

篮球比赛数据统计系统的架构设计

UML软件架构程序设计

课程设计报告

项目题目：

篮球比赛数据统计系统的架构设计

专业班级：

软件工程074

项目组成员：

姓名

学号

指导教师：

开始日期：

2009年6月27日

完成日期：

2009年7月8日

一、引言

1.1编写目的

本详细设计说明书是基于系统概要设计说明书，经过项目组成员讨论后，将系统的各个功能模块细化，将总的用例图的功能细化到每个序列图中。

并且为后续的编码工作提供依据,也是系统测试用例编写和后期维护的主要参考资料。

为篮球比赛数据统计系统提供类图（表明属性和方法）；各种关联图；主要用例的活动图和顺序图；用文字说明分析和设计的过程（例如先用文字描述用例的步骤序列然后才画活动图和顺序图）。

本详细设计说明书主要面向项目组所有成员,是代码编写和测试的主要依据。

1.2项目背景

篮球比赛已经很流行了，像美国的NBA更是全球闻名，篮球比赛的计分显得尤为重要。

1.3名词解释

UML（UnifiedModelingLanguage，统一建模语言）：

是一种可视化的建模语言，它能让系统构造者用标准的、易于理解的方式建立起能够表达出他们想象力的系统蓝图，并且提供了便于不同的人之间有效地共享和交流设计结果的机制。

状态图（StatechartDiagram）是描述一个实体基于事件反应的动态行为，显示了该实体如何根据当前所处的状态对不同的时间做出反应的。

时序图（SequenceDiagram）用来显示对象之间的关系，并强调对象之间消息的时间顺序，同时显示了对象之间的交互。

时序图中包括如下元素：

类角色，生命线，激活期和消息

活动图:

和流程图很类似,它可以显示出工作步骤（活动）,判定点和分支

继承是面向对象术语中，UML中也称它为泛化。

在泛化关系中，子类可以替代父类。

也就是说，父类出现的地方，子类都可以出现。

但是反过来却不成立。

关联（Association）：

当类之间在概念上有连接关系。

篮球（Ball）、篮框（Basket）、篮球队（Team）、队员（Player）、后卫队员（Guard）、前锋队员（Forward）、中锋（Center）、投球（Shot）、进攻时间时钟（ShotClock）、三分线（threepointline）、罚球（freethrow）、犯规（Foul）、罚球线（freethrowline）、球场（Court）、比赛时钟（GameClock）。

投篮（shoot）、推进（advance）、运球（dribble）、传球（Pass）、犯规（Foul）、抢篮板球（rebound）。

1.4参考资料

《软件工程（第二版）》张海潘

《UML面向对象建模与设计》（美）MichaelBlahaJamesRumbaugh

二、软件结构概述

2.1主要的类

篮球（Ball）、篮框（Basket）、篮球队（Team）、队员（Player）、后卫队员（Guard）、前锋队员（Forward）、中锋（Center）、投球（Shot）、进攻时间时钟（ShotClock）、三分线（three—pointline）、罚球（freethrow）、犯规（Foul）、罚球线（free-throwline）、球场（Court）、比赛时钟（GameClock）。

根据上面的类可以得到下面的需要用到的类的初步类图（后面的步骤中将对这些类逐步细化）：

在上面的初步图中得到一个泛化图：

将上图的泛化图中的类的信息进行详细的填充.填充类的时候,通常还需要和客户进行沟通,必要时也可以自己添加。

通过和用户的交谈，我们可以发现：

Player和Guard、Forward、Center有泛化关系，并且Player是Guard、Forward、Center三个类的父类，Guard、Forward、Center是Player的子类。

Guard、Forward、Center有Player父类的很多属性和操作特性，Guard、Forward、Center可以泛化Player父类的很多属性和操作特性，当然在Guard、Forward、Center还可以覆盖Player父类的属性和操作特性，还可以添加属于Guard、Forward、Center自己的属性和操作特性。

XX文库-让每个人平等地提升自我

得到一个Ball的要发生交互的类：

将上面的交互图类的信息进行详细的细化填充：

得到一个Player的类要发生交互的类：

将上面得到的交互的类图细化填充：

2.2关联图

在队员和球队的关联中，如果球队是职业篮球队，那么它就是队员的雇主（Employer），队员就是球队的雇员（Employee）。

下图说明了如何表示出这些角色。

队员和球队之间的关联。

可以用一个短语“队员为篮球队效力（playson）”来刻划这个关联。

关联的可视化表示方法是用一条线连接两个类，并把关联的名字放在这个连接线之上。

关联的方向用一个实心三角形箭头来指明。

关联还可以从另—个方向发生：

篮球队雇佣（Employs）队员。

可以把这两个方向上的关联表示在一个图中，用实心三角形箭头指明各自关联的方向。

Guard、Forward、Center类和Team类之间的关联，将会得到如下所示的关联图。

2.3活动图

活动图:

和流程图很类似,它可以显示出工作步骤（活动）,判定点和分支。

比赛开始的时候两队争球，只有一个队能拿到球，如果己方拿球就协助队友推进，等待队友的传球，或者是掩护队友进攻或者投球。

如果自己或者队友的球被抢了以后则马上防守。

如果队友投球进了得分也马上防守，因为己方得分后敌方发球进攻。

如果敌方推进过程中己方队友或者自己抢到敌方的球则马上协助队友推进或者自己推进，协助队友投球或者自己投球。

当比赛时间到后，分数高的就是胜利者，如果时间到了双方的分数相同，则进入加时赛。

2.4顺序图

状态图的焦点是对象的状态。

UML顺序图更进一步显示出随着时间的变化对象之间是如何通信的。

顺序图的关键思想是对象之间的交互是按照特定的顺序发生的，这些按特定顺序发生的交互序列从开始到结束需要一定的时间。

当建立一个系统时，必须要指明这种交互序列，顺序图就是用来完成这项工作的UML组件。

顺序图由采用通常方式表示的对象组成：

对象用矩形框表示，其中是带下划线的对象名：

消息用带箭头的实线表示；时间用垂直虚线表示。

比赛开始的时候两队争球，只有一个队能拿到球，如果己方拿球就协助队友推进，等待队友的传球，或者是掩护队友进攻或者投球。

如果自己或者队友的球被抢了以后则马上防守。

如果队友投球进了得分也马上防守，因为己方得分后敌方发球进攻。

如果敌方推进过程中己方队友或者自己抢到敌方的球则马上协助队友推进或者自己推进，协助队友投球或者自己投球。

当比赛时间到后，分数高的就是胜利者，如果时间到了双方的分数相同，则进入加时赛。

在加时赛中顺序图一样，只是时间大大缩短了，当比赛时间结束后任没有分出胜负，则算平局。

2.5用例图

用例是由参与者发起的，参与者能够从用例的执行中获得有价值的事物。

用例模型的图形表示法很直观。

用例用一个椭圆形表示，直立人形图标表示参与者。

用例的发起参与者在用例图的左侧，接收参与者在用例图的右侧。

参与者的名字放在参与者图标的下方，用例的名字可以放在椭圆形里面也可以放在椭圆形下面。

关联线连接参与者和用例，并且表示参与者与用例之间有通信关系。

关联线是实线，和类之间的关联线类似。

用例分析的一个好处是它能展现出系统和外部世界之间的边界。

下面是某球员传球次数、投篮次数、计算命中率等主要用例的用例图，这些都是用于提取数据的统计的用例图。

三、总结

对课程设计进行总结:

通过全组人员的共同努力，本次设计顺利完成。

但是在设计中也出现了很多问题：

1:

充分看出我们在平时的学习中还存在诸多的不足。

在程序设计时，对面向对象程序设计的只是掌握不够，深深感受到“书到用时方恨少”，我们掌握的知识很难完全解决在设计中遇到的问题。

2:

通过设计，我们也发现我们的自学能主动性太差，对数据库相关的知识了解很少，以至在工作中解决问题的方法单一，知识面狭窄。

虽然如此，但是我们通过本次设计，从中学到了很多东西:

1：

对用UML软件架构的方法去一场篮球比赛的静态建模步骤有了大体的了解，在以后的学习道路上会更有动力更加努力。

2：

在遇到问题时，大家相互讨论，一同寻找解决的办法，这也让我们充分的感受到团队的力量。

学会与团队之间的合作才是成功的捷径。