收藏 分享(赏)

17章开发用例.ppt

上传人:kpmy5893 文档编号:7915546 上传时间:2019-05-29 格式:PPT 页数:33 大小:212.50KB
下载 相关 举报
17章开发用例.ppt_第1页
第1页 / 共33页
17章开发用例.ppt_第2页
第2页 / 共33页
17章开发用例.ppt_第3页
第3页 / 共33页
17章开发用例.ppt_第4页
第4页 / 共33页
17章开发用例.ppt_第5页
第5页 / 共33页
点击查看更多>>
资源描述

1、第十七章 开发用例,收集了系统的需求,下一步就该分析系统的每项需求了。这一章要学习的内容有: 分析和描述用例。 用例的描述格式、前置条件和后置条件。 描述用例执行步骤。 绘制用例图。第18章“收集系统需求”所得到的每个功能包中的用例说明了系统必须要做的事。开发组还必须分析和理解每个用例。开发组正在从理解领域逐步走向,对实际系统的理解。用例是两者之间的桥梁。如果你已经体会到系统开发项目是由用例驱动的,那么就能更好地理解整个开发过程。注意联合应用开发会议并没有讨论开发小组如何完成每个用例所涉及的活动。会议的主题仅仅是尽可能列出所有可能的用例。这一章要详细分析上一章所列举出的用例,并开始研究如何将W

2、IN系统中的构件具体化。开发过程进行到现在,要开发的具体系统才开始真正成为舞台上的主角。我们将跟踪开发组的工作,处理上一章列举的部分用例。,17.1 分析和描述用例,为了分析用例,还要再开一次联合应用开发会议,这个会议的议题是导出和分析每个用例。这里有一句告诫:用例联合应用开发会议可能是最困难的会议,因为它需要与会者(最终系统的可能用户)成为系统分析员。在他们每个人各自的职责范围内,每人都是小的领域专家,必须发挥出他们各自的专长。典型情况是,他们不习惯于或者不善于表达出或分析出他们所了解的业务知识。这可能是因为,他们以前从没有参与过系统的开发工作,缺乏经验。或者是他们不能很清楚地表达出到底要让

3、系统为他们做什么事。为了解决或缓解这个问题,最好在组织联合应用开发会议时一次只请一组用户参加(例如,一组服务员)。作为整体领域专家的餐馆老板,也应出席会议,帮助参加会议的一组服务员分析他们的用例。在处理Customer包中的用例时,包括多种用户的混合用户组应当一起参加会议。系统中的用例数目通常很大。为了简化本章的内容,我们只处理Server包中的前9个用例。学习完,这些用例的处理过程后,你将能够处理Server包中的其余用例,以及其他包中的用例。,17.2 用例分析,回忆“用例图”中的部分内容:每个用例是一组场景的集合,每个场景又由一系列步骤组成。对于每个用例中的每个场景,需要说明的内容有:

4、场景的简单陈述。 关于场景的假设条件。 场景的前置条件。, 用例的发起参与者。 场景中与系统相关的步骤序列。 场景完成后的后置条件。 用例的受益参与者。除了上述内容以外,还包括异常条件或可选的场景流程。本章做了适当的简化。在设计文档中(提交给客户和程序员的用来指导开发的文档),每个用例应当单独占一页,这一页最好包括一张用例图,图中画出这个用例和用例的参与者。,与系统相共的步骤序列在场景中极其重要。它说明了系统的预期工作方式。当联合应用开发会议的参与者告诉分析员这些步骤序列时,也就意味着告诉了分析员系统最终如何工作。当会议结束后,分析员就能得出系统中包括那些构件。关于场景的假设也很重要。后面将会

5、看到,根据这些假设清单,就可以列出设计中要注意的事项。以上说明了系统开发项目是由“用例驱功”的。用例是构造系统的途径。,17.3 Server包,Server类要参与许多活动,因为Server类几乎与其他每个类都有关联。Server包中的用例有:,17.3.1 用例“Take an order”我们从用例“Take an order”开始。我们必须根据服务员提供的用例描述、假设条件、前置条件、步骤序列和后置条件来描述用例。功能包早已清楚地指明这个用例的发起参与者(Server)和受益参与者(Customer)。对这个用例的一句话的叙述可以是“服务员将顾客的定单信息输入到他的手提式个人计算机中并

6、将定单信息传递到厨房。”假设条件是顾客想就餐,顾客已经阅读了菜单并做出了选择。另一个假设条件是服务员的手提式个人计算机已经出现了“输入定单”用户界面。,前置条件是顾客已经就坐并阅读了菜单,后置条件是定单被输入进WIN系统中。用例的步骤序列是:1服务员激活他的手提式个人计算机的“输入定单”用户界面。2“输入定单”用户界面出现在显示器屏幕上。3服务员将顾客的菜单选项输入到WIN系统中。4系统将定单发送到厨房的桌面电脑。尽管我们假设“输入定单”用户界面的存在,但到目前为止我们根本不知道这个界面看起来是什么样子,也没有说明传送定单的任何技术细节。,这里的基本原则是当我们阐述出系统的设计假设后,就开始考

7、虑系统应当能够做什么,并且要开始绞尽脑汁地思考怎样让系统做它应当做的事。用例的步骤序列迫使我们不得不思考组成系统的构件有哪些。记住,用例分析的目标是描述出用户所看到的系统。 17.3.2 用例“Transmit the order to the kitchen”这个用例至少应被包含在(也就是被使用)两个用例当中前一个用例和用例“Change an order”。用例的叙述是:“将输入到手提式个人计算机中的定单通过无线网络传送到厨房的桌面电脑。”假设,条件是已经具备了通信手段(通过无线网络)以及具备了“输入定单”用户界面。与其他用例的假设条件重复了的假设条件还要叙述出来吗?是的。每个用例在设计文

8、档中都占单独的页。为了清晰起见,即使与其他用例的假设条件相同,每个用例的假设条件都应该完整地被叙述出来。前置条件是定单信息已经被录入到手提式个人计算机中,后置条件是定单被正确传递到厨房的桌面电脑。受益参与者是Customer类。步骤序列如下:1点击“定单”用户界面上的“send to kitchen”,按钮。2WIN系统将定单发送进入无线局域网。3定单到达回房的桌面电脑。4“输入定单”用户界面出现提示信息,提示定单已经被正确传递到厨房的桌面电脑。很显然,应该修改Server包中的用例图。必须在“Take an order”、“Change an order”这两个用例与本用例之间添加inclu

9、de依赖关系。下图是修改后的Server包中的用例图。,17.3.3 用例“Change an order”下面分析用例“Change an order”。它的叙述是:修改一份已经被录入到WIN系统中的定单,假设条件是定单已经被录入并发到了厨房的桌面电脑中,但是顾客又想修改定单。进一步假设:WIN系统中有一个定单数据库,服务员可以查询该数据库,了解到是谁输入的定单;定单来自哪个餐桌;服务员可以通过自己的手提式个人计算机访问数据库;WIN系统可以在服务员的手提式个人计算机与厨房的桌面电脑之间双向传输定单;服务员的手提式个人电脑上有“修改定单”用户界面。,前置条件是定单已经被传给厨房的桌面电脑。后

10、置条件是修改后的定单传到厨房的桌面电脑。受益参与者是Customer。本用例的步骤序列是:1服务员激活他的手提式个人计算机中的“修改定单”用户界面。2屏幕上出现了这名服务员已经发送了的定单列表。3服务员在菜单列表中选择要修改的定单。4服务员录入要修改的定单的修改信息。,5系统将修改后的定单发送到厨房的桌面电脑。步骤5包含了前面分析过的用例“Transmit the order to kitchen”。 17.3.4 用例“Track order status”在最初的关于未来餐馆的讨论中涉及到确定一个顾客的定单何时完成,并从厨房传递出来。本用例描述的就是这项需求。在系统中实施这个用例对方便服务

11、员的工作大有帮助。用例的叙述是:跟踪已经被输入到WIN系统中的定单的状态。假设条件有:定单已经被发送到厨房;顾客想知道他们点的饭菜何时才能做好。此外还有两,个与前一个用例的假设条件相同的假设条件。还假设服务员的手提式个人计算机和厨房的桌面电脑中都有跟踪定单状态的用户界面。前置条件是定单已被发送到厨房。后置条件是定单的状态信息被传送到服务员的手提式计算机中。受益参与者是Customer。步骤序列包括:1服务员激活他的手提式个人计算机中的“跟踪定单状态”用户界面。2屏幕上出现这名服务员已经发送了的定单列表。,3服务员选择欲跟踪的定单。4系统产生一个跟踪消息到厨房的桌面电脑。5厨房的桌面电脑收到了这

12、条消息。6在厨房的桌面电脑上厨师把要跟踪定单的界面激活。7厨师在用户屏幕界面中输入一个时间估计值。8 系统将厨师输入的时间估计值传给服务员的手提式个人计算机。 17.3.5 用例“Notify chef about party status”从这个用例开始,使用更小的子标题来描述用,例分析的各个方面,使用黑色圆点来标记子标题下面的子标题但有两个例外:步骤序列的每一步前仍使用序号;用例叙述不用黑色圆点分隔。用例叙述服务员通过无线网络告诉厨师:顾客马上就要吃完小菜。假设条件 服务员呆在顾客所在的服务区。 服务员能够端详出顾客下一步要干什么。 系统提供了“顾客状态”用户屏幕界面。, 系统可以在服务员

13、的手提式个人计算机和厨房的桌面电脑之间双向传递信息。前置条件 顾客几乎就要吃完小菜。后置条件 厨师做主菜的最后工序。步骤序列1服务员激活他的手提式个人计算机上的“顾客状态”用户界面。2 用户界面上出现了服务员所在的服务区中的餐桌列表。,3服务员在列表中选择餐桌。4服务员发送有关这个餐桌的一条“almost finished appitizer”消息给厨房的桌面电脑。5厨房的桌面电脑接收到了这条消息。6服务员收到了来自厨房桌面电脑的一个确认应答消息。最后一步使用了Server包中的用例“Receive acknowledegement”。下图是说明这个用例及相关用例的用例图。,受益参与者 Cus

14、tomer,17.3.6 用例“Total up a check”用例叙述在定单中添加定单条目。假设条件 系统中有一个能够通过服务员手提式电脑访问的定单数据库。 定单中的每个条目都有标价。前置条件 一组顾客就餐完毕。后置条件 计算出帐单的总价格。,步骤序列1服务员激活有关的用户界面,使一个活动的定单条目列表出现在他的手提式个人计算机的屏幕界面上。2服务员选择要结帐的定单。3服务员点击屏幕上的一个按钮,计算帐单总价格。4系统根据每个定单条目的价格计算出帐单总价,并显示在屏幕上。受益参与者 Customer,17.3.7 用例“Print a check”尽管这个用例看起来不起眼,但在实际的交易中

15、它是非常重要的一部分。用例叙述打印已经计算出总价的帐单。假设条件 每个服务区都有一台(无线)网络打印机。前置条件帐单总价格已被计算出。后置条件 打印出一份帐单。,步骤序列1服务员点击一个按钮。2网络打印机开始打印。3服务员再点击一个按钮将这个帐单对应的定单从活动定单列表中删除。受益参与者 Customer 17.3.8 用例“Summon an busser”用例叙述要求一名清洁师清理餐桌,迎接下一组顾客的到来。,假设条件 系统中允许两名雇员之间进行无线通信。 系统提供了用于向一名清洁师发送消息的用户界面。前置条件 存在一个要被清理的餐桌。后置条件 清洁师及时赶来,并清理和调整餐桌。步骤序列1

16、服务员激活用来给清洁师发送消息的用户界面,并给他发消息。,2服务员接收到来自清洁师的一个确认应答消息。要包含用例“Notify chef about party status”,最后一步也要使用“Receive acknoelegement”用例。受益参与者 Busser,17.4 系统中的构件,用例分析的一个重要方向是揭示出组成系统的构件。在本章结束之前,让我们记录一下在前而对Server包中的用例进行分析时都提到了系统中的那些,构件。在每个用例的“假设条件”段可以找到这些构件。从软件构件来看,显然要包括一组用户界面。WIN系统需要包括服务员手提式计算机上出现过的“输入定单”、“修改定单”、

17、“跟踪定单状态”、“顾客状态“以及“发送消息给清洁师”等用户屏幕界面。为了便于组织这些屏幕界面,还可以设计一幅“主屏幕”。则N系统还需要用户界面用来在厨房的桌面电脑上跟踪定单状态。另一个明显的软件构件是存储和管理所有定单信息的数据库。数据库的记录要包括餐桌号、定单号、定单录入时间、服务员姓名、定单是否处于活动状态,等数据字段。从硬件构件来看,需要一个无线局域网络、可移动雇员(服务员、助手、清洁师)使用的手提式个人计算机以及经理办公室、厨房和休息室里要安装的桌面电脑。每个服务区还要按装一台网络打印机。也许衣帽保管员还需要配备电脑和打印机。,17.5 小结,只列举出系统中行那些用例是不够的。开发组要理解整个系统就必须分析和理解系统的每个用例。因此本章的主要内容就是介绍复杂用例的分析。,用例分析的内容包括叙述出用例,找出用例的前置和后置条件,详细说明用例的步骤序列。用例分析的一个重要方面是能够初步提示出组成系统的构件。本章对前几章得出的用例图做了修改。随着知识的积累,不可能不对原先的分析结果做修改。原先得到的用例只是建立在当时的知识范围基础上,是当时的个“快照”。修改后的用例反映了开发组后期的观点。,作业: 1绘制用例“Summon a busser”的用例图。 2分析Server包中的“Take a drink order to lounge”用例,绘制对应用例图。,

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 企业管理 > 管理学资料

本站链接:文库   一言   我酷   合作


客服QQ:2549714901微博号:道客多多官方知乎号:道客多多

经营许可证编号: 粤ICP备2021046453号世界地图

道客多多©版权所有2020-2025营业执照举报