Cli*_*ord 10
- 如何描述演员(在我的情况下,其他DSP和遥测设备).
您定义系统的边界; 在边界内部是您将在软件中构建的所有内容以及它将运行的硬件.与系统交互的边界之外的所有东西都是演员 - 或者至少是候选演员.
您通常希望以与系统应用程序相关的目的来描述演员,而不是用于实现它们的技术 - 这是在您的边界之外而不是感兴趣的.因此,您不会拥有演员"DSP",因为它描述的是解决方案技术,而不是应用领域技术.DSP 实现的是演员.
- 如何描述基本流程/路径,因为功能非常直接:执行算法X; 将数据Y发送到遥测; 等等
这不是用例图的用途.用例图是顶级使用模型.它主要用于需求建模而不是软件设计或实现 ; 它远比那更抽象.
在开发使用模型时,您可以定义用例 ; 这些是您的系统可以做的不同的事情.因此,例如在电梯控制系统中,用例将是诸如" 请求服务 ","使旅程*"," 维护系统 "," 乘客警报 " 之类的事情:
该角色是与系统交互的系统之外的那些东西.但这些通常是"末端效应器"而不是中间连接技术,所以例如在上面的例子中进行维护,维护者可以连接某种工具,可能是基于笔记本电脑或PDA,但演员最终是维护技术人员,不是工具.再次,它关于要求,而不是解决方案.如果你还需要开发这样一个工具,那要么在你的边界内,要么被定义为一个单独的系统,电梯和维护者作为演员.
正如您所看到的,仅使用用例图在语义上很简单,除了组织思想和支持需求分析以及利益相关者沟通之外,它本身并没有为您做很多事情.一个完整的使用模型必须更多只是这个图.必须定义和改进每个用例.复杂的用例将有多个场景 - 每个场景都是一个"途径",涵盖了使用方式可能变化的所有方式.其中一些场景是隐含的与其他用例的关系.一个扩展是在一个用例的一些情形中活跃,而一个包含由所指示的关系是活动的包含它们的用例的所有场景.
可以使用文本来描述场景,但是考虑到用例图的使用以及您对系统建模的期望,其他UML图(例如序列图或协作图)将更合适.整个用例可以使用状态机图或活动图来定义- 如果您只有几个场景,这可能就足够了,但是在有很多场景的情况下,通常用顺序或协作描述主要场景是有用的.图.这些图表表示通过状态机或活动图的单一路径,可用于突出显示和澄清利益相关者的棘手细节.例如,上面示例中的请求服务用例的序列图可能如下所示:
请注意,仅使用模型通常不是您为需求捕获和分析创建的唯一模型.您还可以定义范围模型,这是定义系统边界以及内部和外部的内容.电梯系统示例:
上下文关系图与使用模型共享相同的边界和角色.在我的例子的上下文关系图是一个习惯使用的协作图与定型来表示接口和子系统,和消息以指示系统和参与者之间交换的事件和数据.
此外,您可以创建模式模型.许多嵌入式系统具有模态行为,这可以通过高级状态机图来有效地建模.这仍然是一种需求模型,并不是必须在软件中实现的状态机; 相反,它模拟外部可观察的状态或操作模式.这股与使用模式的上下文模型和用例的事件-的行动被触发事件是从使用模式的使用情况; 因此模式模型协调用例的执行或启用 - 确定如何在每种模式下使用系统.再次,对于电梯示例:
这三个模型涉及如下:
正如我所强调的,使用模型主要是需求模型.为了实现,您将使用其他UML图进行建模; 主要是类图,类本身详细说明了状态机和活动图,以及用序列和协作图详细阐述的类之间的交互.此活动涉及将需求模型转换为解决方案模型.需求模式描述了系统必须执行的操作; 解决方案模型描述了如何完成.