高校运动会管理系统的分析与设计

陈少波+钟鸣

摘要： 该系统针对高校运动会的需求，采用面向对象的分析与设计方法，建立了以类图表示的系统静态模型，以用例模型为主，顺序图、活动图等为辅表示的系统动态模型，最后对分析与设计中应该重点考虑的问题进行了总结。

Abstract： In order to meet the needs of college sports game， the system uses object-oriented analysis and design method， establishes a system static model expressed by class diagram， and a system dynamic model based on use case model and supplemented by sequence diagram and activity diagram. Finally， the key issues in the analysis and design are summarized.

关键词： 高校；运动会；管理系统

Key words： university；sports game；management system

中图分类号：G647 文献标识码：A 文章编号：1006-4311（2018）01-0210-04

0 引言

随着我国高等教育的迅猛发展，万人大学、几万人大学比比皆是，每所大学每年都要举办校级运动会，参加运动会的教职工及学生数以千计，运动会的组织管理工作是一项复杂、琐粹的工作。信息管理是运动会组织管理工作不可缺少的组成部分，也是运动会组织管理走向科学化、规范化的必要条件。目前各高校都已普及千兆校园网，开发出依托校园网的“高校运动会管理系统”已经水到渠成。

高校运动会管理系统的设计至少应该达到以下的目标：

①管理员能够及时便捷的对信息进行必要处理，包括查询、添加、删除、汇总、修改、统计等

②为便于资源共享，可在网上发布各种运动会信息。

③运动员可以在自己的权限内对信息进行访问，即时查询相关信息。

1 系统需求分析

本系统开展分析和设计采用面向对象的方法。

面向对象方法和结构化方法存在一定差别，在该方法中对于分析和设计的界限是比较模糊的，分析和设计工作共存于一个连续体上，不同的实践者在这个连续体上的活动关于“分析”和“设计”存在一定分类界限。之所以这样，根本原因就在于面向对象方法中的“分析”與“设计”表达工具的一致性，开发过程通常是迭代进行的，我们必须牢牢把握的是：“需求调研是了解问题，分析是定义问题，而设计则是解决问题。”

一切软件开发都毫无例外地必须从需求出发。用软件工程的专业术语来说，“弄清楚要做什么”即为“需求分析”。未来所有的软件项目都是基于需求分析开展的。

作者认为，分析阶段一般来说包括以下两个方面的工作：建立一个以类图表示的反映问题域静态关系的概念模型；建立一个以用例模型表示的反映系统行为的动态模型。

帮助开发团队理解问题域的各种概念、各种名词、以及它们之间的各种关系是概念模型建立的作用；帮助开发团队理解用户对系统的各种功能需求是用例模型建立的作用。分析工作的主要内容是做这两方面的工作，其结果就是得到明确的问题定义。即知道系统不该做什么、该做什么，以及要达到的目标。

1.1 建立系统概念模型

在大多数面向对象的书籍中，把用例建模当成是分析阶段的工作，而把概念建模当成是设计阶段的工作。也就是说，用例建模是在概念建模之前。作者认为，这是一种误解。因为面向对象的开发是迭代进行的，也就无所谓谁先谁后，而是取决于对模型作用的理解。把建立概念模型作为第一步，目的是从需求分析开始就能使开发团队从整体上把握系统。

表达概念模型的是类图。类图是描述类、接口以及它们之间关系的图，它是一种静态模型，显示了系统中各个类的静态结构。类图根据系统中的类以及各个类的关系，描述系统的静态视图。

对于面向对象系统建模来说，类图是最为基本和常用的图之一，其它大部分图都是在此基础上经过进一步描述得出的，比如配置图、通信图、顺序图、状态图等。

采用“名词动词法”，从发现系统中的类（管理员、运动员、项目、成绩）开始，添加属性、找到类的职责，一步一步建立起以类图表示的系统概念模型如图1所示。

1.2 建立系统用例模型

用例的概念是伴随着UML一起传入国内的，所以一些人认为用例模型就是UML用例图，其实不然。这是因为UML标准中根本没有讨论用例的内容以及如何去编写用例，而用例模型不仅包括用例图，也包括比用例图更重要的用例描述。

用例模型是应用系统中与静态模型相配合的动态模型。用例模型的建立从确定系统的参与者开始，参与者确定后，我们就可以从参与者的角度出发，考虑参与者需要系统完成什么样的功能，从而建立参与者所需要的用例。

参与者是对系统外的对象的描述，是用户作用于系统的一个角色，参与者通过与系统的交互来实现自已的目标。参与者可以是人，也可以是一个外部系统。通过分析，我们确定本系统的参与者为：管理员、普通用户、组委会、裁判员。endprint

用例是对系统的用户需求（主要是功能需求）的描述，即描述了系统的功能和提供的服务。

本系统用例：用户登录、系统管理、退出系统、信息查询、信息录入、信息发布、成绩处理、赛程安排、现场成绩统计、成绩查询等，我们可以依此建立系统的用例图如图2所示。

对系统的各种基本信息的操作，都是由管理员完成的，如图3所示。

对比赛成绩的录入、成绩的公布以及各比赛项目决赛名单的公告等操作，也是由管理员完成的，如图4所示。

用例图及用例描述，构成了系统的用例模型。用例具有三个基本特征：用例总是由参与者启动，用例为参与者提供结果值，用例具有完整性。因此，用例描述必须清晰地反映了这些特征。限于篇幅，本文仅以“成绩处理”用例为例进行用例描述。

2 系统设计

概念模型描述了组成系统结构各部分的各种类型；用例模型描述了系统必须做什么。然而，上述两种模型无法解释系统是如何运作的。但通过交互建模可满足上述要求，它能够让应用系统看上去是能“运行的”。这是通常所说的设计阶段要做的事情。

交互建模通常使用时序图、通信图、顺序图，在具体的应用中，可以互换通信图和顺序图。顺序图描述了系统运行时各对象之间如何进行交互以及交互的次序，其应用是最为广泛的。所以，用于描述系统特定用例时，使用顺序图不仅会涉及到该用例所需要的对象，还包括对象之间的交互和交互发生的次序。对于小型系统而言，只需使用顺序图即可。

2.1 建立顺序图

顺序图是用来表示用例中的行为顺序，描述了对象之间传递消息的时间顺序。当执行一个用例行为时，顺序图中的每条消息对应了一个类方法或一个引起转换的触发事件。它着重显示了参与相互作用的对象和所交换消息的顺序。

顺序图代表了一个以时间为次序的相互作用对象之间的通信集合，它不包括对象联系，但包括时间次序。为用例构建逻辑模型是顺序图的作用之一，利用顺序图可进一步解释和实现所有用例。用例常常被细化为一个或者多个顺序图。作为例子，运动员信息查询及管理员成绩处理顺序图如图5、图6所示。

2.2 建立活动图

描述事件流是活动图的主要作用，事件流中一组动作的执行都用一个活动表示。通过使用活动图，我们能够知道系统中那些地方存在功能，及其相关组件的功能等，便于使用用例图建模。

活动图本质上是面向对象的流程图，其中几乎所有或大多数的状态都处于活动状态，它描述从活动到活动的控制流。用活动图来对事件流建模时，可以显示用例内部和用例之间的路径；活动图还可以向读者说明需要满足什么条件用例才会有效，以及用例完成后系统保留的条件或者状态；活动图可以用来为用例事件流建模，更可以理解为用例图的具体细化；在构建活动图时，常常会发现前面没有想到、附加的用例。

以决赛名单处理为例，其活动图如图7所示。

2.3 建立组件图和部署图

组件图和部署图可以描述应该如何根据系统软、硬件的各个组件间的关系来布置物理组件。在完成系统的逻辑设计之后，接下来要考虑的就是系统的物理实现。对面向对象系统的物理实现进行建模需要构造组件图和部署图。构造组件图可以描述软件的各个组件以及它们之间的关系，构造部署图可以描述硬件的各个组件以及它们之间的关系。

组件是软件的单个组成部分，它可以是一个文件、产品、可执行文件或脚本等。通常情况下，组件代表了将系统中的类、接口等逻辑元素打包后形成的物理模块。组件图的主要目的是显示系统组件间的结构关系。本系统的组件图如图8所示。

组件图用来对软件组件进行建模，但无法体现这些软件组件在计算机硬件中的位置，而部署图是用来显示系统中软件和硬件的物理架构。从部署图中，您可以了解到软件和硬件组件之间的物理关系以及处理节点的组件分布情况。使用部署图可以显示运行时系统的结构，同时还表示构成应用程序的硬件和软件元素的配置和部署方式。系统部署图如图9所示。

3 结束语

经过前面的工作，从分析和设计的角度来看，可以说工作已经完成了。当然，从系统可以投入使用的角度来看，工作还远未结束，还有编码、测试及数据库设计等工作要做。如果我们把到此为止的工作做得足够好的话，后面的工作完全可以转给别人做，这就是通常所说的软件外包。

当你决定采用面向对象方法对某个特定的应用系统进行开发时，对问题域进行建模和对用例进行建模就构成了应用系统开发的基础。因此，你必须对它们的本质和作用有清晰的认识和理解：

①问题域模型：问题域模型反映的是应用系统所涉及的客观世界的所有物体，我们对其进行抽象，并以类图的形式表达出来。这个类图是整个系统开发的基础，后续的各项工作都是在这个基础上对系统进行扩展和完善。因此，在对问题域进行建模时，所构建出来的模型只是演化的基础，故没有必要苛求它的精确性。在随后的开发工作中，还有许多机会对该模型进行更新。在建立问题域模型时，最重要的事情就是我们必须用类的思想来看世界，否则，我们就偏离了面向对象方法的基本思路。

②用例模型：用例模型是用户需求的一种有效的表达方式，它是用户使用场景的抽象。用例模型與使用场景之间的关系，类似于类与对象之间的关系。即用例模型是站在用户的角度，尽可能全面地捕捉用户可能的使用场景，以反映用户的实际操作情况。

在分析和设计中，最重要的事情是用面向对象的视角来观察与抽象现实世界，并能有效地使用用例（用例模型）对用户需求进行分析和整合，建立起静态和动态两个模型。

参考文献：

[1]郭琳，张文静，简平.面向对象的图书馆信息系统设计与分析[J].图书情报工作，2013，57（增刊1）.

[2]樊莉丽.面向对象设计的软件工程开发分析[J].产业与科技论坛，2014，13（15）.

[3]张宏鸣，李书琴，王美丽，张晓婷，张阳.面向对象分析与设计课程教学改革探索与实践[J].教育教学论坛，2015（6）.

[4]赵池龙，程努华.实用软件工程[M].北京：电子工业出版社，2015.

[5]林加强.分析统一建模语言在面向对象分析与设计中的应用[J].信息系统工程，2016，7，20.

[6]罗曦.基于分段式教学的《面向对象分析与设计》的课程研究[J].信息系统工程，2016，11，20.endprint