3.9 需求建模的模式

软件模式是获取领域知识的一种机制，以使得遇到新问题时可以重复使用。在某些情况下，领域知识在同一应用领域中用于解决新问题。在另外一些情况下，通过模式获取的领域知识可借助模拟用于完全不同的应用领域。

分析模式的最初创作者没有“创建”模式，但在需求工程工作中发现了模式。模式表示了在某些应用领域中合并一个类、一个功能或一个行为的解决方案，当为某个领域的应用执行需求建模时会重用模式。分析模式都存储于一个仓库中，以便软件团队的成员能够使用搜索工具找到并复用。一旦选择到合适的模式，就可以通过参考模式名称整合到需求模型中。

需求模型由各种元素组成：基于场景（用例）、基于数据（数据模型）、基于类、基于流和行为。其中每个元素都是从不同的视角检查问题，并且每一个都提供一种发现模式的机会，可能发生在整个应用领域，或者横跨不同的应用领域。

在需求模型的描述中最基本的元素是用例，一套连贯用例可以成为服务于发现一个或多个分析模式的基础。语义分析模式（semantic analysis pattern，SAP）“描述了一小套连贯用例，这些用例一起描述了通用应用的基础”。

下面来考虑要求控制和监控“实时查看摄像机”和汽车临近传感器的软件用例。

用例：监控反向运动。

描述：当车辆安装了反向齿轮，控制软件就能从后向视频摄像机将一段视频输入到仪表板显示器上。控制软件在仪表板显示器上叠加各种距离和方向的线，以便车辆向后运动时驾驶员能保持方向。控制软件还能监控临近传感器，以判定在车后方3米内是否有物体存在。如果临近传感器检测到某个物体在车后方x英尺内就会让车自动停止，这个x值由车辆的速度决定。

在需求收集和建模阶段，本用例包含（在一套连贯用例中）各种将要精炼和详细阐述的功能。建议用例要简单，要广泛地适用于SAP，即具有基于软件的监控和在一个物理系统中对传感器和执行器的控制。在本例中，“传感器”提供临近信息和视频信息。“执行器”用于车辆的停止系统（如果一个物体离车辆很近就会调用它）。但是更常见的情况是发现大量的应用模式。许多应用领域的软件需要监控传感器和控制物理执行器，所依照的分析模式描述了能广泛应用的通用需求，这个模式称为Actuator-Sensor（执行器-传感器）。