1、数据采集气象监测站11.1 初始我们的气象监测系统是一个简单得多应用，仅仅包含少数的类。咋一看，面向对象的新手们可能很想采用一种本质上非面向对象的方式来解决这个问题，即考虑数据流和不同的输入/输出之间的映射。然而，正如我们将要看到的那样，即使是像这样小的一个系统，也可以很好地借鉴面向对象架构，并在开发过程中展示出一些面向对象开发过程的基本原则。11.1.1 气象监测站需求本系统应提供各种气象条件的自动检测。具体地说，它必须测量：a、风速b、温度c、气压d、湿度系统也应提供一下导出的测量数据：a、风湿度b、露点温度c、温度趋势d、气压趋势系统应有一个决定当前时间和日期的方法，以便它能够报告过去
2、24 小时内 4 种主要测量数据的最高值和最低值。系统应有一个显示屏，不断显示所有 8 个主要数据和导出数据，同时显示出当前的时间和日期。用户可以通过小键盘来指挥系统，让它显示任意一个主要测量数据在 24 小时内的最高值和最低值，以及出现这些值的时间。系统应该允许用户根据已知的值来校正传感器，并允许设置当前的时间和日期。11.1.2 定义问题的边界分析时首先要考虑的是软件运行的硬件平台，这是系统分析的因有问题，涉及到制造能力和成本问题，这些问题远远超出本书的讨论范围。为了限定问题边界，以便展示软件分析设计问题，我们做以下战略性的假定：a、处理器（即 CPU）采用 PC 或手持式备式的。b、时间
3、和日期由一个时钟提供。c、通过远程的传感器来测量温度、气压和湿度。d、用一个带有风向标（能感知 16 个方向中任一方向的风）和一些风杯（推动计数器对回转进行计数）的标注来测量风速和风向。e、通过小键盘提供用户输入。f、显示器是一个现货 LCD 图形设备。g、计算机每 1/60 秒有一次定时器中断。图 11-1 提供一个部署图来说明这个硬件平台在这个问题上，我们已经选择放弃一些俄硬件，这样就可以更好的聚焦在系统软件上。显然，去掉一些硬件（如去掉一些用户输入和图形设备的硬件）就可能需要更多的软件，但在这个特定的应用中，改变硬件/软件的界限对我们的面向对象架构来说，在很大的是无足轻重的。确实，面向对
4、象系统的特征之一就是倾向于用问题的词汇说话，从而描绘出一个与问题的关键实体的抽象相并行的虚拟机。改变系统硬件得到细节仅仅影响对系统底层的抽象。通过围绕每一个这样的接口包装一个类，硬件接口的细节很容易从软件抽象隔离。例如，可以设计出一个简单的类来访问当前的日期。首先对这个隔离类进行分析，考虑这个抽象应当扮演的角色和承担的职责。这样，我们就可以决定，这个类负责追踪当前的日期和时间，包括时、分秒、月、日和年。我们的分析可能会决定将这些职责转变为连个服务，分别表示为操作 currentTime 和currentDate。操作 currentTime 返回以下格式的字符串：13:56:42表示当前的时、
5、分和秒操作 currentDate 返回以下格式的字符串：6-10-93表示当前的月、日和年。进一步分析可以得出一个更加完善的抽象，允许客户选择 12 小时制或 24 小时制的时间格式，我们可以为这种抽象提供一个另外的更改操作 setFormat。通过从公开客户的视角来指定这个抽象行为，我们将接口和实现做了清晰的分离。基本的思想是对每一个类建立外部视图，就好像已经完全控制了它下面的平台，然后将类的实现作为通向它内部视图的桥梁。这样，在系统硬件/软件边界处的类的实现就将抽象的外部视图同它下面的平台衔接在一起，下面的平台是受系统决策约束的，而系统的决策并不掌握在软件工程师的手中。当然，抽象的内外视
6、图之间的鸿沟并非大的需要一个厚重而低效的实现来粘合它们。因此，时间和日期类的职责必须包括设定时间和日期。完成这个职责需要新的服务集来进行，我们通过以下操作提供：setHour、setMinute、setSecond、setDay、setMonth 和 setYear。下面总结以下时间/日期类的抽象。类名：TimeDate职责：跟踪当前的时间和日期。操作：currentTimecurrentDatesetFormatsetHoursetMinutesetSecondsetMonthsetYear属性：timedate这个类的实例有动态的生命周期，这一点可以从如图 11-2 所示的状态转换图中看出
7、。可以看到，初始化之后，类的实例重新设置它的 time 和 date 属性，然后无条件地进入 Running 状态，运行24-hour mode 状态下。一旦在 Running 状态，setFormat 操作可以将对象的运行模式在 12-hour mode 和 24-hour mode 之间切换。无论对象处于哪种嵌套状态，设置时间内和日期都会引起对象重新规范化它的属性。同样地，请求时间或日期也会引起对象计算一个新的字符串值。图-对上面 4 个具体类(Temperature Sensor、Pressure Sensor Humidity Sensor 和 Windspeesd Sensor)进行
8、快速的领域分析，可以揭示另一个共同的行为:这些类都可以根据两个已知的数据点，用线性内插法来校正自己。我们不是将这个行为复制到 4 个类中，而是创建一个更高一级的超类 Calibrating Sensor 来负责这个行为，它的规格说明如下。类名:Calibrating Sensor职责:给定两个已知数据点，提供线性插值的值。操作:currentValueseHighVa1uesetLowVa1ueCalibrating Sensor 是 Historical Sensor 的直接超类。最后一个具体传感器一风向传感器有点不同，它既不需要校正也不需要报告历史趋势，这个实体的抽象可以表示为下面的规格说
9、明。类名:windDirection Sensor职责:跟踪当前风向，表示为罗盘图上的点。操作:currenDirection属性:direction为了统一传感器抽象，我们创建抽象基类 Sendor，它是类windDirection Sensor 和类 Calibrating sensor 的直接超类。图11-4 说明了这个完整的层次结构。虽然用于用户输入的小键盘抽象不是传感器类层的一部分，但是它有一个简单的规格说明。图类名:Keypad职责:跟踪最近一次用户输入。操作:lastKeyPress属性:key值得注意的是，这个类对任何特定键的含义一无所知，它的实例仅仅知道几个键申的一个被按下。
10、我们将解释这些键的含义的职责委托给不同的类，我们将确定什么时候把这些具体的边界类应用到场景中。LCD Device 类的抽象可以将软件与可能使用的特定硬件隔离。为了解除软件与可能使用的特定图形硬件之间的藕合，分析促使我们去做气象监测系统的一些常用显示画面的原型，然后确定界面需求。图 11-5 提供了这样一个原型。在这个原型中，我们省略了风冷度和露点的显示需求，也省略一些细、么例如，如何显示主要测量数据在过去 24 小时内的最高值或最低值。但是，出现了某些模式:我们只需要显示文本(以两种不同的大小和两种不同的风格)、圆和线(粗细不同)。此外，我们还注意到，显示的一些元素是静态的(如 TEMP 标
11、签)，另外一些元素是动态的(如风向)。我们选择通过软件来显示这些静态和动态元素。这样，LCD 自身就不需要特别的标签，从而减轻硬件的负担，但同时也会稍微增加软件的工作量。图可以将这些需求转换成以下的类规格说明。类名:LCDDevice职责:管理 LCD 设备，为显示某些图形元素提供服务。操作:drawTeXtdrawL1nedrawC1rc1esetTeXtS1zesetTeXtSty1esePenS1ze正像类 Keypad 一样，类 LcD Device 并不知道它所操纵的元素的含义。该类的实例仅仅知道怎样显示文字和直线，而不知道这些图形代表什么。这种关注分离留给我们松藕合的抽象(这正是我
12、们想要的)，但是这需要我们找到一个代理，负责协调原始的传感器和显示器。我们推迟创建这个新的抽象，直到研究这个系统的一些应用场景之后。最后一个需要考虑的边界类是关于定时器的。我们将做出一个简化的假定，每个系统中有且只有一个定时器，它每间隔 1160 秒向计算机发出中断，调用一个中断服务例程。这个细节特别鳖脚，如果能够对其他的软件抽象隐藏这个实现细节，那是最好的。我们可以设计一个类，它使用回调函数，并且仅仅提供静态成员(这样就限制了系统中只有一个定时器)。图 11-6 提供了一个序列图来说明这个抽象的一个用例。从图中可以看出定时器如何与他的客户合作:首先，客户提供一个回调函数，然后每隔 1/60
13、秒定时器调用这个函数。在这种方式中。客户不逼知道怎么去截取定时事件，定时器也不必要知道当这样一个定时事件出现时该怎么做。这个协议对客户要求的主要职责比较简单，客户必须在 1/60 秒之内执行完其回调函数，否则定时器将错过一个事件。由于要截取定时事件，Timer 类应当是一个主动的抽象，这就意味着它处于控制线程的根部。下面是这个类抽象的规格说明。类名:Tin1er职责:截取定时事件，并相应地调用一个回调函数。操作:setCallback11.1.3 场景我们已经在系统边界处建立了抽象，现在通过研究几个使用场景来继续分析。首先列出一些主要用例(参见图 11-7)，这些用例是从系统客户的观点来看的。
14、 监测基本的气象测量数据，包括风速、风向、温度、气压和湿度。监测导出的测量数据，包括风冷度、露点、温度趋势和气压 111趋势。显示选定测量数据的最高值和最低值。、设置时间和日期。校正选定的传感器。 111启动系统。 1 11在增加两个次要用例：电源故障。 1 11传感器故障。 11111.2 细化为了阐明系统的行为（但不是设计） ，让我们考察以下这些场景。11.2.1 气象监测系统用例监测基本的气象测量数据是气象监测系统的首要功能点。其中一个系统约束是：不可能在 1 秒内测量 60 次以上。幸运的是，大多数感兴趣的气象条件的改变要慢得多。通过分析，我们提出了以下采样速率，这些速率能够充分地捕获气象状况的改变。风向：每 0.1 秒。 111风速：每 0.5 秒。 111温度、气压和湿度：每五分钟。 111早先我们已经决定，表示每个主要传感器的类不负担处理定时事件的职责。因此我们的分析需要设计一个外部代理来协助这些传感器完成这个场景。我们暂时推迟对代理的行为进行规格说明(它如
