气象监测站.doc

数据采集——气象监测站 11.1 初始 我们的气象监测系统是一个简单得多应用，仅仅包含少数的类。咋一看，面向对象的新手们可能很想采用一种本质上非面向对象的方式来解决这个问题，即考虑数据流和不同的输入/输出之间的映射。然而，正如我们将要看到的那样，即使是像这样小的一个系统，也可以很好地借鉴面向对象架构，并在开发过程中展示出一些面向对象开发过程的基本原则。 11.1.1 气象监测站需求 本系统应提供各种气象条件的自动检测。具体地说，它必须测量： 风速 温度 气压 湿度 系统也应提供一下导出的测量数据： 风湿度 露点温度 温度趋势 气压趋势 系统应有一个决定当前时间和日期的方法，以便它能够报告过去24小时内4种主要测量数据的最高值和最低值。 系统应有一个显示屏，不断显示所有8个主要数据和导出数据，同时显示出当前的时间和日期。用户可以通过小键盘来指挥系统，让它显示任意一个主要测量数据在24小时内的最高值和最低值，以及出现这些值的时间。 系统应该允许用户根据已知的值来校正传感器，并允许设置当前的时间和日期。 11.1.2 定义问题的边界 分析时首先要考虑的是软件运行的硬件平台，这是系统分析的因有问题，涉及到制造能力和成本问题，这些问题远远超出本书的讨论范围。为了限定问题边界，以便展示软件分析设计问题，我们做以下战略性的假定： 处理器（即CPU）采用PC或手持式备式的。 时间和日期由一个时钟提供。 通过远程的传感器来测量温度、气压和湿度。 用一个带有风向标（能感知16个方向中任一方向的风）和一些风杯（推动计数器对回转进行计数）的标注来测量风速和风向。 通过小键盘提供用户输入。 显示器是一个现货LCD图形设备。 计算机每1/60秒有一次定时器中断。 图11-1提供一个部署图来说明这个硬件平台 在这个问题上，我们已经选择放弃一些俄硬件，这样就可以更好的聚焦在系统软件上。显然，去掉一些硬件（如去掉一些用户输入和图形设备的硬件）就可能需要更多的软件，但在这个特定的应用中，改变硬件/软件的界限对我们的面向对象架构来说，在很大的是无足轻重的。确实，面向对象系统的特征之一就是倾向于用问题的词汇说话，从而描绘出一个与问题的关键实体的抽象相并行的虚拟机。改变系统硬件得到细节仅仅影响对系统底层的抽象。 通过围绕每一个这样的接口包装一个类，硬件接口的细节很容易从软件抽象隔离。例如，可以设计出一个简单的类来访问当前的日期。首先对这个隔离类进行分析，考虑这个抽象应当扮演的角色和承担的职责。这样，我们就可以决定，这个类负责追踪当前的日期和时间，包括时、分秒、月、日和年。我们的分析可能会决定将这些职责转变为连个服务，分别表示为操作currentTime和currentDate。操作currentTime返回以下格式的字符串： 13:56:42 表示当前的时、分和秒 操作currentDate返回以下格式的字符串： 6-10-93 表示当前的月、日和年。 进一步分析可以得出一个更加完善的抽象，允许客户选择12小时制或24小时制的时间格式，我们可以为这种抽象提供一个另外的更改操作setFormat。 通过从公开客户的视角来指定这个抽象行为，我们将接口和实现做了清晰的分离。基本的思想是对每一个类建立外部视图，就好像已经完全控制了它下面的平台，然后将类的实现作为通向它内部视图的桥梁。这样，在系统硬件/软件边界处的类的实现就将抽象的外部视图同它下面的平台衔接在一起，下面的平台是受系统决策约束的，而系统的决策并不掌握在软件工程师的手中。当然，抽象的内外视图之间的鸿沟并非大的需要一个厚重而低效的实现来粘合它们。 因此，时间和日期类的职责必须包括设定时间和日期。完成这个职责需要新的服务集来进行，我们通过以下操作提供：setHour、setMinute、setSecond、setDay、setMonth和setYear。 下面总结以下时间/日期类的抽象。 类名：TimeDate 职责：跟踪当前的时间和日期。 操作： currentTime currentDate setFormat setHour setMinute setSecond setMonth setYear 属性： time date 这个类的实例有动态的生命周期，这一点可以从如图11-2所示的状态转换图中看出。可以看到，初始化之后，类的实例重新设置它的time和date属性，然后无条件地进入Running状态，运行24-hour mode状态下。一旦在Running状态，setFormat操作可以将对象的运行模式在12-hour mode和24-hour mode之间切换。无论对象处于哪种嵌套状态，设置时间内和日期都会引起对象重新规范化它的属性。同样地，请求时间或日期也会引起对象计算