关于 篮球赛过程的UML课程设计.docx
《关于 篮球赛过程的UML课程设计.docx》由会员分享，可在线阅读，更多相关《关于 篮球赛过程的UML课程设计.docx（21页珍藏版）》请在冰豆网上搜索。
关于篮球赛过程的UML课程设计
关于“篮球赛”过程的UML课程设计
Ⅰ.课程设计的目的：
进行软件架构设计，可以使应用软件达到以下成效：
（1）可靠性，
（2）安全性，（3）可维护性，（4）易用性，（5）可扩展性。
通过本设计使学生熟悉软件设计的过程，掌握UML模型建立规范，熟练掌握实体类、接口类、控制类。
用例类、系统类等模型的建立，锻炼学生的软件设计能力，并绘制规范的模型图，理解如何将书本上的程序知识应用到实际项目中，通过与同组同学的合作，锻炼学生的合作能力。
Ⅱ.课程设计教学基本要求:
1、四人为一个小组，小组成员既要有相互合作的精神，又要分工明确。
每个学生都必须充分了解整个设计的全过程。
2、从开始的系统需求分析、整体构架到系统设计、部署，都要有详细的计划，设计文档应按照软件架构文档的要求规范书写。
3、系统中的数据表设计应合理、高效，尽量减少数据冗余。
4、绘制的各种建模图形都必须规范清晰，顺序图、活动图的流程应清晰明白。
Ⅲ.课程设计的内容:
根据本设计书所提供的基础知识，选择一个题目（见附录1），按软件设计的流程，设计应实现相应的项目，并写出设计步骤、绘制相关图形，完成设计报告。
主要完成开发背景、可行性分析、需求分析、系统整体构架、体系结构、信息系统架构总体视图、关键技术设计、系统设计模式，相应的进行绘制用例图、类图、包和对象图、顺序图、协作图、状态图、活动图、组件与配置图、布署视图、数据视图等。
Ⅳ.课程设计方式:
讨论并撰写软件项目设计方案，上机编程，部分功能开发实现。
Ⅴ.课程设计进度安排:
1）选题：
了解基础知识，讨论该设计题目的主要内容，及开发思路；
2）确定需求：
将你选的题目的所有功能需求写清楚，并绘制一份功能模块结构图（便于参考）；
3）整体构架研究：
包含各个子系统的体系结构、风格研究；
4）系统设计模式：
包含设计与绘制用例图、类图、包和对象图、顺序图、协作图、状态图、活动图、组件与配置图、布署视图、数据视图等所需的图形；
5）撰写设计报告
“篮球赛”过程的UML课程设计
一．类建模
（一）发现类：
类代表的是领域知识中的词汇和术语。
同客户交谈，分析他们的领域知识，设计用来解决领域中的问题的计算机系统，同时也就是在学习这些领域词汇，并用UML中的类建立这些领域词汇的类模型。
在与客户的交谈中，要注意客户用来描述业务实体的名词术语。
这些名词可作为领域模型中的类。
还要注意你听到的动词，因为这些动词可能会构成这些类中的操作。
当得到一组类的核心列表后，应当向客户询问在业务过程中每个类的作用。
他们的回答将告诉你这些类的职责。
假设你是一个系统分析员，要建立篮球比赛模型，现在你正在会见一名教练员来了解比赛规则情况。
谈话的过程可能如下：
分析员：
“教练，请大致介绍一下篮球比赛。
”
教练员：
“比赛的目标是要把篮球投入蓝框并且要尽量比对手得更多的分。
每个篮球队由5名队员组成：
两名后卫、两名前锋和一名中锋。
每个队要将球推进到篮框附近，目的是将篮球投中篮框。
”
分析员：
“如何将球推进?
”
教练员：
“通过运球和传球。
但是某一方篮球队必须在规定的进攻时间内投篮。
”
分析员：
“规定的进攻时间?
”
教练员：
“是的，在某一方获得控球权后，必须在规定的进攻时间内投篮。
美国职业篮球比赛是24秒，国际篮球比赛是30秒，美国大学篮球比赛是35秒。
”
分析员：
“如何计算篮球比赛得分？
”
教练员：
“三分线之内每投中一坎篮柜得两分，三分线之外投中一次得三分。
一次罚球得—分。
顺便说一下，罚球是对方犯规后判罚的投球。
如果某一个队员犯规，则比赛暂停，由被侵犯的队员在罚球线处罚球。
”
教练员：
“国际比赛场地为28米长、15米宽。
蓝框离地面3.05米高。
在美国职业篮球比赛中，一场比赛为48分钟，分为4节，每节12分钟。
在美国大学和国际比赛中，一场比赛40分钟，分为上下两个20分钟的半场。
有专门的比赛时钟记录比赛还剩下多少时间。
我们现在停止说明这些对话，来看看谈话的内容。
下面是在对话中发现的名词：
篮球（Ball）、篮框（Basket）、篮球队（Team）、队员（Player）、后卫队员（Guard）、前锋队员（Forward）、中锋（Center）、投球（Shot）、进攻时间时钟（ShotClock）、三分线（three—pointline）、罚球（freethrow）、犯规（Foul）、罚球线（free-throwline）、球场（Court）、比赛时钟（GameClock）。
还有—些动词：
投篮（shoot）、推进（advance）、运球（dribble）、传球（Pass）、犯规（Foul）、抢篮板球（rebound）。
可以得到上述名词的一些附加信息——例如每个位置的队员的相对高度、篮球场大小、进攻时间以及比赛时间。
最后，根据常识可以为这些类建立一些属性和操作。
例如，通常球类都有体积（vo1ume）和直径（diameter）等属性。
使用这些信息，可以建立一个如下图所示的图。
它说明了领域中的类，并提供了—些属性、操作和约束。
这个图也可以表示职责。
（二）．类的关系
在第一中所完成的模型中，只有一些代表了篮球运动词汇的类。
还缺少类之间的连接方式。
回顾上面已经建立的初步模型，就会发现图中并没有说明队员和篮球之间有什么关系，队员是如何组成球队的，或者一场比赛是如何进行的。
2.1关联：
当类之间在概念上有连接关系时，这种关系叫做关联（association）。
篮球比赛的初步模型中提供了这样的例子。
下面我们来研究篮球比赛中各个类之间的关系。
例如，其中的一个关联——队员和球队之间的关联。
可以用一个短语“队员为篮球队效力（playson）”来刻画这个关联。
关联的可视化表示方法是用一条线连接两个类，并把关联的名字（例如“playson”）放在这个连接线之上。
表示出关联的方向是很有用的，关联的方向用一个实心三角形箭头来指明。
图2.1说明如何可视化表示队员和球队之间的Playson关联。
一个类和另一个类发生关联时，每个类通常在关联中部扮演着某种角色。
可以在图中靠近每个类的地方的关联线上标明每个类的角色。
在队员和球队的关联中，如果球队是职业篮球队，那么它就是队员的雇主（Employer），队员就是球队的雇员（Employee）。
简略后的图2.2说明了如何表示出这些角色。
关联从另—个方向发生：
篮球队雇佣（Employs）队员。
可以把这两个方向上的关联表示在一个图中，用实心三角形箭头指明各自关联的方向，如图2.3所示。
将几个类可以连接同一个类。
现在开始设计Guard、Forward、Center类和Team类之间的关联，将会得到如下图2.4所示的关联图。
2.2关系类：
和类一样，关联也可以有自己的属性和操作。
此时，这个关联实际上是个关联类。
关联类的可视化表示方式与一般的类相同，但是要用一条虚线把关联类和对应的关联线连接起来。
关联类也可以与其他类关联。
下面设计一下player类和Team类之间的Playson关联对应的关联类：
Contract（契约）关联类。
它又同时和GeneralManager（总经理）类发生关联（如图2.5）。
2.3链
在上面我们设计出来相关类的关联和关联类，已经基本清楚相关类间的关系。
正如对象是类的实例一样，关联也有自己的实例。
如果我们想象要一个特定的队员效力一个特定的球队，那么两者之间的Plays0n关系就叫做一个链（link），可以用两个对象之间的连线来表示它。
和对象的名字要加下划线一样，链的名字也要加下划线，如下图所示。
2.4多重性关系
到目前为止，在Player类和Team类之间所建立的关联似乎是一对一关系。
然而常识告诉我们这并不一定正确。
一支篮球队有5名队员（不包括替补队员）。
因此Has（拥有）关联必须考虑到这一点。
在另一个方向上，一个队员只能为一支球队效力，Playson关联也必须考虑这—点。
上面说的就是多重性的例子：
某个类有多少个对象可以和另一个类的单个对象关联。
表示多重性的方法是在参与关联的类的附近的关联线上注明多重性数值。
这个例子所举的多重性并不是唯一可能的类型。
实际上存在各种可能的多重性。
两个类之间可以是一对一、—对多、—对—或多、—对零或一、一对有限间隔。
UML使用星号（*）来代表许多（more）和多个（many）。
在一种语境中，两点代表or（或）关系，例如“1..*”代表一个或者多个。
在另一种语境中，or关系用逗号来表示，例如“5，10”代表5或者10。
下图显示了可能的各种多重性的表示方法。
2.5继承和泛化
继承是面向对象术语中，UML中也称它为泛化。
在泛化关系中，子类可以替代父类。
也就是说，父类出现的地方，子类都可以出现。
但是反过来却不成立。
在UML中，用父类到子类之间的连线来表示继承关系。
父类连线部分，指向父类的一端带台一个空心三角形箭头。
这种连接类型的短语的含义为isakindof（属于…中的一种）。
如图2.8所示。
其中有Player、Guard、Forward、和Center等类。
Player类通常有name（名字）、height（身高）、weight（体重）、runningSpeed（奔跑速度）和verticalLeap（垂直起跳高度）等属性，以及dribble（）、pass（）、rebound（）和shoot（）等操作。
Guard、Forward和Center继承了这些属性和操作，并且增加了他们自己的一些属性和操作。
另一种可能的情况是系统分析员注意到两个或者多个类可能具有相同的属性和操作数。
篮球比赛类模型中有一个GameClock类（它负责记录距离比赛停止还剩下多少时间），还有一个ShotClock类（它记录某方得到控球权后还剩下多长时间该方必须投篮）。
因为两者都是用来记录时间，意识到这点后，系统分析员就能设计出Clock（时钟）类。
它具有—个trackTime（）操作（计时操作），GameClock类和ShotClock类都继承了这个操作。
2.6抽象类
在篮球比赛模型中，刚才提及的两个类（Player类和Clock类）是很有用的，因为它们是一些重要子类的父类。
然而，Player和Clock这两个类将不提供任何模型实例，因为它们的对象派不上什么用途。
像这样的类（不提供实例对象的类）被称为是抽象的（abstract）。
表明一个类是抽象类的方法是类名用斜体书写。
二．状态建模
在前面我们已经比较全面的剖析了系统的对象结构及其相关关系（类模型）。
接下来将继续从另一个角度研究此系统，即检查对象及其关系随着时间的变化（状态模型）。
首先我们先研究研究本篮球比赛系统的设计构思“假想图”，在这个图中我们可以看到每一场比赛每个时间发生的“事件”和“状态”。
状态模型描述描述响应外部激励而发生的操作序列，而不是描述操作做了什么，对什么进行操作，或操作是如何实现的。
状态模型由多个状态图组成，每个类对应一个状态图，描述对应程序来说是重要的那些时序行为。
状态图是一个标准的计算机概念（有限状态机的图形表示法），联系起时间和状态。
事件表示外部激励，状态表示对象的取值。
事件是指在某个时刻发生的事情，如本篮球赛比赛系统中，初始化时间（TimerInit）、开始计时（TimerBegin）、时间暂停（TimerPause）、进球（shot_in）、未进球（shot_out）、犯规（foul）、换人（exchangeplayer）等。
状态时对象取值和链接的抽象。
根据对象的总体行为，将取值和链接的集合组成一个状态。
在UML中，状态的表示方法——其中包含可选状态名的圆角方框，现在设计约定是黑体在方框中部列出状态名，首字母大写。
如本蓝球比赛系统设计中出现的状态：
ReceivingBall（接球）、DrivingBall（运球）、PassingBall（传球）、ShottingBall（投球）、shotting_in（进球）、Shotting_out（未进球）、FreeShotting（任意球）等。
状态图的结点是状态，有向弧式状态间的迁移。
状态图详细说明了由事件序列引起的状态序列。
状态名在状态图的作用域内必须是唯一的。
类中所有的对象都执行该类的状态图，状态图会建模对象的公共行为。
可以通过直接解释实现状态图，或通过将语义转换成等效的程序代码来实现状态图。
状态模型包含了多个状态图，没各类一个状态图，状态体建模重要的时序行为。
状态图必须匹配他们的接口——事件和警戒条件。
单独的状态图可以通过传达事件，以及通过警戒条件的副作用进行交互。
事件和状态两者都依赖于抽象的层次。
可以用不同的方法刻画状态，这个状态有一个提示性的名称，并用自然语言描述其意图。
进入和退出活动，作为候选方法，要现实在前以上的活动，可以把活动绑定到某状态的入口和出口。
两者表示法的表达能力没有太大的差异，所有进入某种状态的迁移经常会执行相同的活动，在这种情况下，更简洁的做法是把活动链接在状态上。
根据图3.2，下面我们继续研究一下状态与状态间转变的事件关系图：
从图3.5我们可以清晰的认识到，“接球”状态的状态转换关系，比赛开始通过“发球”事件或是这个时刻计时器TimerInit（）信号，状态会进入接球状态（RecivingBall）；比赛过程中，队员与队员间有“传球”，也会自然进入“接球状态”。
状态图是另一类UML元素。
这个新类被称为行为元素，它们能够展示UML模型部件如何随时间变化。
事物的一个普遍的现象是随着时间的流逝，都要经历变化。
任何计算机系统也是如此。
当系统与用户（也可能是其他系统）交互的时候，组成系统的对象为了适应交互要经历必要的变化。
如果要对系统建立模型，那么模型中必须要反映出这种变化。
三．用例图
可视化允许你向用户显示用例，他们能向你提供更多的信息。
实际生活中用户常常知道的比他们清楚表达出来的要多，用例能够帮助用户解决这个问题。
另外，可视化的表达形式允许将用例图和其他种类的图结合起来。
用例是由参与者发起的，参与者（也许是发起者，但不是必须的）能够从用例的执行中获得有价值的事物。
用例模型的图形表示法很直观。
用例用一个椭圆形表示，直立人形图标表示参与者。
用例的发起参与者在用例图的左侧，接收参与者在用例图的右侧。
参与者的名字放在参与者图标的下方，用例的名字可以放在椭圆形里面也可以放在椭圆形下面。
关联线连接参与者和用例，并且表示参与者与用例之间有通信关系。
关联线是实线，和类之间的关联线类似。
用例分析的一个好处是它能展现出系统和外部世界之间的边界。
参与者是典型地系统外部实体，而用例是典型地属于系统内部。
系统的边界用一个矩形（里面写上系统的名字）来代表。
系统的用例装入矩形之内。
用例图在开发过程中的应用
开发过程从与客户会谈开始。
这些会谈可以产生初步类图，它可作为理解系统领域（也就是要解决的问题的范围）知识的基础。
在了解了客户领域的一般术语后，就可以开始准备与用户交谈了。
与用户会谈开始时谈论领域术语，但是要马上转到用户的术语。
会谈的初步成果是能够发现—些参与者以及高层用例，这些高层用例概括地描述了
本图用例的主要内容
1、发起用例的参与者
用例参与者主要包含以下几个对象：
运动员，计时员，记分员，裁判
2、用例的前置条件
3、场景中的步骤
开球，拿到球，传球，投球（进球）
4、场景完成后的后置条件。
5、从用例中获益的参与者。
四．顺序图
顺序图由采用通常方式表示的对象组成：
对象用矩形框表示，其中是带下划线的对象名：
消息用带箭头的实线表示；时间用垂直虚线表示。
对象从左到右布置在顺序图的顶部。
布局以能够使图尽量简洁为准。
从每个对象向下方伸展的的虚线叫做对象的生命线（lifeline）。
在生命线上的窄矩形条被称为激活。
激活表示该对象正在执行某个操作。
激活矩形的长度表示出激活的持续时间。
下图显示了对象、生命线和激活的表示法。
消息，一个对象到另一个对象的消息用跨越对象生命线的消息线表示。
对象还可以发送消息给它自己——也就是说，消息线从自己的生命线出发又回到自己的生命线。
消息可以是简单的（simple）、同步的（synchronous）或异步的（asynchronous）。
简单消息是从—个对象到另一个对象的控制流的转移。
如果一个对象发送了—个同步消息，那么它要等待对方对消息的应答，收到应答后才能继续自己的操作。
而发送异步消息的对象不需要等待对方的应答便可以继续自己的操作。
在顺序图中，简单消息是—个简单箭头，同步消息是实心箭头。
异步消息是—个半边箭头，如下图所示。
时间，顺序图中垂直方向代表时间维，时问流逝的方向为自顶向下。
靠近顶部的消息发生的时间要比靠近底部的消息早。
因此，顺序图是两维的。
自左至右的维数代表对象的布局，自顶向下的维数代表时间的流逝。
下图说明了顺序图的基本图符集。
对象横放在图的项部。
每个对象的生命线都是一条从对象向下的虚线。
图中的实线与箭头连接另一条生命线并代表对象之间相互发送的消息。
人形表示—个参与者，他发起了序列。
但严格地讲，参与者的图标不属于顺序图图符集。
UML顺序图在对象交互的表示中加入了时间维。
在顺序图中，对象位于图的顶部，从上到下表示时间的流逝。
每个对象都有一个垂直向下的对象生命线。
对象生命线上的窄矩形条代表激活——该对象某个操作的执行。
可以沿着对象的生命线表示出对象的状态。
消息（简单的、同步的或异步的）用连接对象生命线之间的带箭头连线表示。
消息在垂直方向上的位置表示了该消息在交互序列中发生的时间。
越靠近图项部的消息发生的越早，越靠近底部的消息发生的越晚。
根据以上分析和了解，我们可以进一步设计本篮球比赛系统的时间顺序图，如图。
计数器主要分为计时器（运动员控球时间）和计分器（运动员投球次数和进球次数）
（1）当运动员A拿到球（可以是裁判发出的球、也可以是队友传出的球、也可以是篮板球等）之后，如果是首次拿到球，则所有的计数器清零；如果不是第一次拿到球，则在以前的基础上开始计时
（2）如果A传球的时候，所有计数器暂停计数
（3）如果A投球的时候，投球次数+1
a）如果进球的，进球次数+1
b）如果没有投进{
If（该球员抢到球，所有计数器继续计数（相当于返回第1步））
Elseif（B抢到球，则球员A的所有计数器暂停并且返回所有属性给球员A；B球员的计数器开始计数（相当于B球员进入第1步））
Else（如果球丢到场外，所有计数器都暂停并且返回所有属性给球员A）
（4）球员A保存属性
升级会员 