embedded - 嵌入式代码示例的用例图

Question

我正在尝试使用用例图对嵌入式软件进行建模，但是如果我朝着正确的方向前进，我找不到任何可以比较的示例。

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

有人针对这种情况有任何示例或提示吗？

我的主要任务是:

如何描述Actor(在我的情况下为其他DSP和遥测设备)。

由于功能非常直接，因此如何描述基本流/路径:执行算法X；执行X。发送数据Y给遥测；等

Answer 1

• How to describe the Actors (other DSP's and telemetry devices, in my case).

您定义系统的边界；在边界内，是您将要构建的软件以及将在其上运行的硬件的所有内容。与系统交互的边界之外的所有事物都是参与者-或至少是候选参与者。

通常，您会希望以抽象的术语来描述参与者，这些参与者是相对于系统应用程序而言的目的，而不是用于实现它们的技术，这超出了您的范围，并且不感兴趣。因此，您将没有参与者“DSP”，例如，因为它描述的是解决方案技术而不是应用程序域技术。 DSP实现的是演员。

• How to describe the Basic Flow/Paths, because the functions are very direct: execute algorithm X; send data Y to telemetry; etc.

那不是用例图的目的。用例图是顶级使用模型。它主要用于需求建模，而不是软件设计或实现；它远不止于此。

在开发使用模型时，您要定义用例。这些是系统可以完成的独特工作。因此，例如在电梯控制系统中，用例将是“请求服务”，“旅途*”，“维护系统”，“乘客警报”之类的事情:


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

如您所见，用例图本身在语义上很简单，除了组织思想和支持需求分析以及与利益相关者之间的沟通之外，它本身对您没有多大帮助。完整的使用模型不仅限于此图。每个用例都必须定义和完善。复杂的用例将具有多种场景-每个场景都是使用的“途径”，涵盖了使用可能发生变化的所有方式。这些方案中的某些是与其他用例的隐含关系。扩展在用例的某些情​​况下是 Activity 的，而由关系指示的包含在包括它们的用例的所有情况下都是 Activity 的。

可以使用文本描述场景，但是鉴于使用案例图的使用以及您对系统进行建模的需求，其他UML图(例如序列图或协作图)将更为合适。整个使用案例可以使用状态机图或 Activity 图来定义-如果您只有少数场景，这可能就足够了，但是，在有很多场景的情况下，通常用顺序或协作来描述主要场景很有用。图。这些图表示通过状态机或 Activity 图的单个路径，可用于与利益相关者一起突出显示和阐明棘手的细节。例如，上例中的请求服务用例的序列图可能类似于:

注意，仅使用模型通常不是您将为需求捕获和分析创建的唯一模型。您可能还定义了作用域模型，它定义了系统边界以及内部和外部。电梯系统示例:

上下文图与使用模型共享相同的边界和参与者。在我的示例中，上下文图是对协作图的惯用用法，协作图具有构造型来表示接口(interface)和子系统，而消息则用于表示系统和参与者之间交换的事件和数据。

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

这三个模型的关系如下:

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