应用实例电梯调度模拟器
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
UML程序设计实例
—电梯调度模拟器—
本章通过电梯调度模拟器的例子详细介绍了如何利用UML进行一个实际系统的开发。这个系统的实现过程,遵循Rational统一软件开发过程,最后用Vc++编码实现。
问题描述
在开发任何一个系统之前,开发人员对所要开发的系统的初步理解首先是从用户的问题描述开始的。问题描述的内容包括系统的基本功能需求,用户对系统的性能,外观等特性的要求。这种描述根据开发项目的规模不同,呈现不同的形式。对于大的项目,问题描述可能是长达几页(几十页)的需求规格说明;对于小的项目,可能只是口头上的几句陈述。通过问题描述,开发人员对要开发的系统产生一个大概的印象。
此实例的问题描述如下:
有一座8层楼房,每层提供一组按钮(“上”或“下”),用于请求电梯的到达;每部电梯内部提供一个控制面板,提供用户对目标楼层的选择,并显示电梯当前所处楼层、运行方向。两部电梯由一个调度器统一调度。如果没有请求,并超过一定时限,电梯回到一楼。希望开发人员能实现一个电梯调度模拟器来模拟如上所述的一切,对电梯的调度准则没有做特别要求。
此外,用户还可能会对系统的性能,外观等特性提出要求,这些都需要在开发过程中加以考虑。
需求分析
拟订侯选需求
在系统开发启动之前,首先要对项目做一些可行性分析。在Rational统一软件开发过程中,称这个阶段为初始阶段。
在初始阶段主要是跟各方进行交流,广泛收集信息,听取客户和专家的建议。并对这些信息和建议进行记录,整理得到一个后选需求列表。
后选需求列表中应包括如下各项
1.名称
2.简要说明
3.状态(建议的、批准的、并入的或证实的)
4.实现成本估算(人小时,人月)
5.优先级(关键的、重要的或辅助的)
6.实现风险的级别(关键的、重要的或一般的)
表1 后选需求列表
这时对系统所要实现的功能在整体上有了一个大致的了解。然后明确哪一部分功能是系统中应该实现的,哪一部分功能是由其它外部系统实现的。即确定出系统的功能范围,并粗略估计一下项目的花费和可能得到的收益。这个阶段最重要的是弄清楚启动这个项目是不是有意义,有价值。
初始阶段根据项目的大小,表现为不同的形式。对于小的项目,可能只需要与相关人员进行一些交流和讨论。而对于大的项目可能要花费几个月的时间进行可行性分析。
经过分析,作出启动项目的决定之后,就进入开发过程的细化阶段。
理解系统上下文
建立领域模型
如果对要实现系统所要解决的问题领域没有一个清楚的了解,就不可能开发出一个满足用户需求的软件。因此,进行系统建模时,应首先建立领域模型,描述问题领域中的基本概念。建立领域模型时,先不要考虑软件是怎样实现的,而只关心如何将用户和领域专家头脑中与业务过程相关的概念组织起来,并将业务过程描绘出来。所以在电梯调度模拟器这个实例中,暂不考虑用户界面,而首先考虑把电梯的运做过程描述清楚。用户界面的加入推迟到分析阶段的后期进行。
首先从问题描述和所了解的领域知识中抽取出可能与解决问题有关的重要概念(领域对象)。
本例中通过分析问题描述提取出了这样一些名词(概念)。同时,为了便于理解,各名词的修饰语也被一同标注出来。
1.楼房
2.(两部)电梯
3.(每层)一组按钮(“上”或“下”)
4.(电梯内部)控制面板
5.用户
6.调度器
接下来,再抽取问题描述中重要动词短语,它们可能会成为某个类的属性或方法。
1.请求电梯的到达;
2.提供用户对目标楼层的选择;
3.显示电梯当前所处楼层、运行方向
通过对这些概念做进一步分析,不难发现2.电梯、3.按钮(“上”或“下”)、4.控制面板、5.用户、9.调度器等这些概念在电梯运做过程中都担当一定的职责,可以把它们抽象为系统中的一个类。“请求电梯的到达”可以作为外部控制面板的职责;“提供用户对目标楼层的选择”作为内部控制面板的职责;“显示电梯当前所处楼层、运行方向”
作为电梯的职责。
此外,还有1.楼房,它在电梯运做过程中不与任何其它对象交互,也不承担任何职责,也不能成为任何其它对象的属性或方法,则把它删除。
根据以上分析,初步地找出了系统中的一些类实体,再根据用户或领域专家对电梯运做过程的描述,以及开发者本人对问题的理解,建立起这些对象之间的关联关系。此外,根据问题描述中限定这些概念的量词(例如:8层、两部、一个等),还可以进一步描述它们之间的多重性关系。然后,为每个类分配职责,并添加一些必要的注释信息。
这样就建立起了这个系统的原始领域模型,如图1所示。
图1 电梯运行系统领域模型
建立业务模型
至此,通过领域模型描述了问题领域中存在的重要概念,并从静态视角描述了它们之间的关系。考察系统的动态行为是正确理解一个系统运做情况的关键。所以还需要刻画出系统的动态特性。这一点通过建立系统的业务模型来实现。
在这个实例中,主要通过活动图和交互图来描述电梯使用的内部运做过程。
根据对问题的理解,建立下面的活动图来描述乘客使用电梯过程中发生的各个活动。
图2 电梯运作之活动图
为了进一步描述领域对象之间的交互关系,建立下面的顺序图描述电梯运作系统中各对象间的信息传递。
图3 电梯运作之顺序图
建立词汇表
在建立领域模型和业务模型的同时,收集问题领域中的一些重要概念,建立起一个可供用户,项目经理、系统分析员、开发人员、测试人员和其他相关人员共同使用的词汇表。这样各种人员就可以使用共同的术语来进行讨论和交流,不仅为系统的实现带来很多便利,还可以防止因误解而使开发的系统偏离用户的真正需求。
提取用例建立用例模型
对系统运作过程有了一定了解之后,下一步开始考虑系统的功能。通过分析业务模型找出执行者并提取用例,建立用例模型来描述系统应实现的功能。
首先,通过分析业务模型找出系统的潜在用户,即执行者。在本实例中只有一类执行者——电梯乘客。然后,通过跟踪执行者与系统的交互行为,找出用例。在本实例中,用户与系统有两次交互,一次是按上/下按钮,请求电梯到达,另一次是进入电梯后,通过内部控制面板选择目标楼层。进一步分析,会发现用户与电梯的这两次交互都需要对电梯进行调度。因此提取出公共用例“调度电梯”。用例图如图4。