嵌入式代码示例的用例图

Question

我正在尝试使用用例图对我的嵌入式软件进行建模，但如果我去的话，我无法找到任何可比较的例子。在正确的方向。

我找到的，仅适用于购物，图书馆，网站，银行等软件。

有没有人有这种情况的例子或提示？

我的主要缺点是：

• 如何描述演员（在我的情况下，其他DSP和遥测设备）。
• 如何描述基本流程/路径，因为功能非常直接：执行算法X;将数据Y发送到遥测;等

Answer 1

  

  
• 如何描述演员（在我的情况下，其他DSP和遥测设备）。
  

您定义系统的边界;在边界内部是您将在软件中构建的所有内容以及它将运行的硬件。与系统交互的边界之外的所有东西都是演员 - 或者至少是候选演员。

您通常希望根据与系统应用程序相关的目的来抽象地描述演员，而不是用于实现它们的技术 - 这是在您的边界之外而不是感兴趣的。所以你不会有演员＆＃34; DSP＆＃34;例如，因为它描述了解决方案技术而不是应用领域技术。 DSP 实现的是演员。

  

  
• 如何描述基本流程/路径，因为功能非常直接：执行算法X;将数据Y发送到遥测;等
  

这不是用例图的用途。用例图是顶级使用模型。它主要用于需求建模而不是软件设计或实现;它远比那更抽象。

在开发使用模型时，您可以定义用例;这些是您的系统可以做的不同的事情。例如，在电梯控制系统中，用例将是＆＃34; 请求服务＆＃34;，＆＃34; make journey *＆＃34 ;，＆＃34; 维护系统＆＃34;，＆＃34; 乘客报警＆＃34;：

actors 是系统外与系统交互的东西。但这些通常是＆＃34;末端效应器＆＃34;不是中间连接技术，所以例如在上面的例子中进行维护，维护者可以连接某种工具，可能是基于笔记本电脑或PDA，但演员最终是维护技术人员，而不是工具。再次，它关于要求，而不是解决方案。如果你还需要开发这样一个工具，那要么在你的边界内，要么被定义为一个单独的系统，电梯和维护者都是演员。

正如您所看到的，用例图本身在语义上很简单，除了组织思想和支持需求分析以及利益相关者沟通之外，它本身并没有为您做很多事情。一个完整的使用模型必须比这个图更多。每个用例必须定义并进行细化。复杂的用例将有多个场景 - 每个场景都是一个＆＃34;途径＆＃34;通过使用涵盖使用可能变化的所有方式。其中一些场景暗示了 与其他用例的关系。 扩展在用例的某些情​​况下处于活动状态，而由 关系指示的包含处于活动状态 all 包含它们的用例场景。

可以使用文本描述场景，但是考虑到使用用例图和您对系统建模的愿望，其他UML图例如序列图或协作图会更合适。可以使用状态机图或活动图来定义整个用例 - 如果您只有几个场景，这可能就足够了，但是在有很多场景的情况下，通常用序列图或协作图来描述主要场景是很有用的。这些图表表示通过状态机或活动图的单一路径，可用于突出显示和澄清与利益相关者的棘手细节。例如，上面示例中的请求服务用例的序列图可能如下所示：

请注意，使用模型通常不是您为需求捕获和分析创建的唯一模型。您还可以定义范围模型这是定义系统边界以及内部和外部的内容。电梯系统示例： 上下文关系图与使用模型共享相同的边界和角色。在我的示例中，上下文关系图是协作图与构造型的习惯用法，用于表示 interfaces 和 subsystems ，以及指示系统和参与者之间交换的事件和数据的消息。

此外，您可以创建模式模型。许多嵌入式系统具有模态行为，这可以通过高级状态机图来有效地建模。这仍然是一种需求模型，并不是必须在软件中实现的状态机;相反，它模拟外部可观察的状态或操作模式。它与上下文模型共享事件，使用案例与使用模型共享 - 事件触发的操作是来自使用模型的用例;因此模式模型协调用例的执行或启用 - 确定如何在每个模式中使用系统。再次，对于电梯示例：

这三个模型涉及如下：

正如我所强调的，使用模型主要是需求模型。为了实现，您将使用其他UML图进行建模;主要是类图，类本身详细说明了状态机和活动图，以及用序列和协作图详细阐述的类之间的交互。此活动涉及将需求模型转换为解决方案模型。需求模式描述了您的系统必须执行的操作;解决方案模型描述将如何。