我正在尝试为无线网卡驱动程序编写用例图。用户与驱动程序没有直接的交互。如何为驱动程序编写用例图?
答案 0 :(得分:3)
'用户'在用例中,不一定是按键或任何东西的人。这是一个演员'在被描述的系统外部,可以与正在描述的系统进行交互。
在这里,这些演员可能包括你想要连接到或想要连接到它的路由器或其他硬件位;它包括NIC插入的硬件和操作系统,NIC与之交换信号;和它们连接的设备以及它们交换的信号。
用例包括:
NIC检测到可用的路由器.... NIC收到来自......的请求
等等,以涵盖您希望NIC执行的操作。
答案 1 :(得分:2)
通过更多信息和示例扩展previos 2答案......
用例模型的关键方面是上下文,或系统范围(在图表上用边界元素描述 - 参见示例)。所有内容都是"内部"范围由UC提取,并且来自"外部"由演员(人或系统)建模。用例建模交互,对话,两者之间的信息交换。
我看到您的案例中至少有两个系统角色,一个受控设备和一个客户端程序。在以下示例中添加了另一个可能的actor,以通过驱动程序显示与设备的最终定期通信:
这是一个非常好的例子,说明不同的UML图如何一起显示以显示全部真相。 UC图侧重于系统与其环境之间的有意义的交互,没有显示关于它的技术信息。
为了做到这一点,你需要另一个图表(这里组件,但类也可以,即使两者都是)。此图是定义接口,API,方法签名,依赖项的地方......
您当然可以更进一步,使用序列/交互图表将用例与相应的组件连接起来(在我的示例中仅显示" trace"清除哪些参与者由哪些组成部分实施)。像这样:
注意一些名为" Data"被发送到驱动程序(和设备)。这可以进一步在类图中定义,从而在该系统上形成全新的观点。
通常的做法是将所有这些信息都放在用例描述中。虽然这种方法甚至可能在语法上是正确的,但是通过分离不同图表中的关注点来释放UML的全部功能,使每个关注点尽可能简单明了,只关注一个问题并清除其他问题。
答案 2 :(得分:1)
在您的场景中,Actor是系统。您可以将系统作为参与者包含在用例中,如果该系统正在开发 ,并且直接与您正在开发的系统进行交互。< / p>
您可能还需要定义系统的边界,这意味着它的范围和接口。例如:您可能想为路由器创建一个actor。优先行动将是他们与您的驱动程序进行交互的方式,因为它们直接与您正在开发的系统进行交互。
希望这会有所帮助。 如果您需要进一步说明,请在下面评论。