Embedded 嵌入式代码示例的用例图

我正试图使用用例图对我的嵌入式软件进行建模，但如果方向正确，我找不到任何可以比较的例子

我发现的这些只适用于购物、图书馆、网站、银行等软件

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

我的主要困难是：

• 如何描述参与者（在我的例子中是其他DSP和遥测设备）
• 如何描述基本流程/路径，因为函数非常直接：执行算法X；向遥测发送数据；等等

• 如何描述参与者（在我的例子中是其他DSP和遥测设备）

定义系统的边界；边界内是您将在软件和硬件上构建的所有内容。与系统交互的边界之外的一切都是参与者——或者至少是候选参与者

通常情况下，您希望以抽象的术语描述参与者与系统应用程序相关的目的，而不是用于实现它们的技术——这超出了您的范围，不符合您的兴趣。因此，您不会有一个参与者“DSP”，例如，因为它描述的是解决方案技术，而不是应用领域技术。DSP实现的是参与者

• 如何描述基本流程/路径，因为函数非常直接：执行算法X；向遥测发送数据；等等

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

在开发使用模型时，定义用例；这些是您的系统可以做的独特的事情。例如，在电梯控制系统中，用例是“请求服务”、“进行旅程*”、“维护系统”、“乘客警报”：

参与者是系统外与系统交互的事物。但这些通常是“末端效应器”，而不是中间连接技术，因此，例如，在上面的示例中，为了执行维护，维护人员可以连接某种工具，可能是基于笔记本电脑或PDA的，但参与者最终是维护技术员，而不是工具。同样，这是关于需求，而不是解决方案。如果您还必须开发这样一个工具，它要么在您的范围内，要么被定义为一个单独的系统，由电梯和维护人员作为参与者

正如您所看到的，用例图本身在语义上是简单的，除了组织思想、支持需求分析和利益相关者沟通之外，它本身并不能为您做很多事情。一个完整的使用模型必须不仅仅是这个图。必须定义和细化每个用例。复杂的用例将有多个场景——每个场景都是一条贯穿使用的“路径”，涵盖了使用可能发生变化的所有方式。其中一些场景是与其他用例的隐含关系。扩展在用例的某些场景中是活动的，而由关系指示的包含在包含它们的用例的所有场景中是活动的

可以使用文本来描述场景，但是考虑到用例图的使用以及您对系统建模的需求，其他UML图（如序列图或协作图）将更合适。用例作为一个整体可以使用状态机图或活动图来定义-如果您只有几个场景，这可能就足够了，但是在有很多场景的情况下，通常使用序列图或协作图来描述主要场景是很有用的。这些图表示通过状态机或活动图的单一路径，可用于向涉众强调和澄清棘手的细节。例如，上面示例中请求服务用例的序列图可能如下所示：

请注意，使用模型本身通常不是您为需求捕获和分析创建的唯一模型。您还可以定义一个范围模型，它定义了系统边界以及内部和外部。电梯系统示例： 上下文关系图与使用模型共享相同的边界和参与者。在我的示例中，上下文图是协作图的惯用用法，其中包含表示接口和子系统的原型，以及表示系统和参与者之间交换的事件和数据的消息

此外，还可以创建模式模型。许多嵌入式系统具有模态行为，这可以通过高级状态机图进行有效建模。这仍然是一个需求模型，不是一个必须在软件中实现的状态机；而是对外部可观察状态或操作模式进行建模。它与上下文模型共享事件，与使用模型共享用例——事件触发的动作是使用模型中的用例；因此，模式模型协调用例的执行或启用——确定在每个模式中如何使用系统。同样，对于电梯示例：

这三个模型的关系如下：

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