《UML与Rose建模应用》教材课件-子情境3.2.ppt

* * * * * * * * 子情景3.2 用例分析 情境3：嵌入式软件建模—MP3播放器 学习情境3：嵌入式系统建模—MP3播放器 UML及Rose建模应用 子情境3.2 用例分析 根据子项目3.1的需求分析报告，确定嵌入式MP3系统的参与者、用例、参与者与用例之间的关系，包括：确定用户使用MP3系统行为、计算机与系统交互系统行为；最后设计出用户使用播放器的用例图和出计算机与系统交互的用例图。 子项目描述 任务1:识别参与者、用例和建立用例图 任务描述 根据需求分析中提取的名词来确定参与者；根据需求分析中的主要任务来确定用例。最后，按照用例模型的创建方法来建立用户使用播放器的用例图和计算机与系统交互的用例图。 用例之间的关系： 用例描述系统满足需求的方式。当细化描述用例操作步骤时，就可以发现有些用例以几种不同的模式或特例在运行，而有些用例在整个执行期间会出现多重流程。如果将用例中重要的可选性操作流程从用例中分隔出来，以形成一个新的用例，这对整个系统的好处是显而易见的。当分离可重复使用的用例后，用例之间就存在着某种特殊关系。包含和扩展是两个用例紧密相关时，关联用例的两种方法。包含关系用于表示用例为执行其功能时需要从其他用例引入功能。类似地，扩展关系则表示用例的功能可以通过其他用例的功能得到扩充。 相关知识 1．包含关系 在对系统进行分析时，通常会发现有些功能在不同的环境下都可以被使用。在编写代码时，我们希望编写可重用的构件，这些构件包括诸如可以从其他代码中调用或参考的类库、子过程以及函数。在用例图中UML支持同样的做法。用例之间的包含关系在UML中的标记符如图3-2所示。注意图中虚线箭头指向被包含用例。 相关知识 图3-2 包含关系标记符 包含关系和对象之间的调用关系比较相像，它描述的是一个用例需要某种类型的功能，而该功能被另外一个用例定义，那么在用例的执行过程中，就可以调用已经定义好的用例。被包含的用例由两种方法确定：一种是被包含的用例事前已经存在，它们是因为某个目的而定义，在系统的开发过程中，恰好需要同样的功能，这样就不需要在系统中重新定义用例，直接将其包含到新的用例中就可以了；另外一种确定被包含用例的方法是从已经存在的几个用例中提取实现相同功能的操作步骤，以形成新的用例。被包含用例称为提供者用例，包含用例称为客户用例，提供者用例提供功能给客户使用。 相关知识 为了更好地理解包含关系是如何起作用的，下面列出了“图书管理系统”的系统用例模型的一部分，如图3-3所示。 相关知识 图3-3 图书管理系统中的包含关系 当图书管理员执行借书操作和还书操作用例时，由于这两个用例都需要进行是否超时的检查，因此，可以将处理超时从这两个用例中提取出来，形成一个公用的新用例。 为了使用包含关系，用例必须遵循以下两个约束条件： 客户用例只依赖于提供者用例的返回结果，不必了解提供者用例的内部结构。 客户用例总会要求提供者用例执行，对提供者用例的调用是无条件的。 在为系统建立模型时，使用包含关系是十分明智的。因为它有助于在将来实现系统时，确定哪里可以重用某些功能，在编写代码时就可实现代码的重用，从而从长远意义上缩短系统的开发周期。 相关知识 2．扩展关系 扩展关系是意中依赖关系，它指定了一个用例可以增强另外一个用例的功能。扩展关系与包含关系一样，只是将单词include替换成了表示扩展关系的单词extend。从如图3-4所示的扩展关系可以看出，扩展关系的虚线箭头是指向基用例的（被扩展用例），箭头的尾部则处在扩展用例上。 相关知识 图3-4 扩展关系标识符 下面的示例将演示在图书管理系统中如何使用扩展关系：处理超时用例由通知超时用例进行扩展，如图3-5所示。在本示例中，基用例是处理超时,扩展用例是通知超时。如果借阅者按时归还图书，那么就不会执行通知超时用例。而当归还图书时超过了规定时间，则处理超时用例就会调用通知超时用例提醒管理员对此进行处理。 相关知识 图3-5 用例间扩展关系示例 正如3-5中所表示的，通知超时用例指向处理超时用例。这样创建的原因是因为通知超时用例扩展了处理超时用例，即通知超时用例是添加到处理超时用例中的一项功能，而不是处理超时用例每次都调用通知超时用例。如果每次检查是否超时都要提醒图书管理员，那么就要使用如图3-6所示的包含关系。 相关知识 图3-6 提示是否超期 子任务1:建立用户使用播放器的用例图 子任务描述 用户使用MP3播放器进行播放音乐、选择曲目、调节音量、上下曲进行切换等操作，根据以上操作设计出MP3播放器与用户之间的用例图。 用例编号 用例名称 用例编号