Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.
Предоплата всего
Подписываем
Лабораторна робота №1. Аналіз. Вибір предметної області.
Хід роботи
Вимоги:
Система повинна забезпечувати автоматичний моніторинг наступних первинних погодних параметрів:
Система також повинна обчислювати деякі похідні параметри, у число яких входять:
У системі повинна бути передбачена можливість визначення поточного часу й дати, які будуть використатися при генерації повідомленні про максимальні й мінімальні значення первинних параметрів за останні 24 години.
Система повинна забезпечувати постійний вивід на дисплей поточних значень всіх восьми первинних і похідних параметрів, а також поточний час і дату. Користувач повинен мати можливість побачити максимальні й мінімальні значення кожного з первинних параметрів за 24 години, супроводжувані інформацією про час добутку відповідного виміру.
Система повинна дозволяти користувачеві проводити калібрування датчиків по відомих опорних значеннях, а також установлювати поточний час і дату.
Абстракція класу часу й дати виглядає так:
Ім'я: TimeDate
Відповідальність: Підтримка інформації про поточний час і про поточну дату.
Операції:
CurrentTime - поточний час
currentDate - поточна дата
setFormat - установка формату
setHour - установка години
setMinute - установка хвилин
setSecond - установка секунд
setMonth - установка місяця
setDay - установка дня
setYear - установка року
Атрибути:
time - час
date - дата
Екземпляри цього класу мають динамічний життєвий цикл. При ініціалізації екземпляра класу відбувається обнуління значень атрибутів і безумовний перехід у робочий стан у режимі 24-годинного формату. У робочому стані можна перемикати режими за допомогою операції setFormat. Операція переустановки часу й дати нормалізує його атрибути поза залежністю від поточного вкладеного стану об'єкта. Запит щодо поточного часу або дати приводить до виконання необхідних обчислень і генерації текстового рядка.
Клас TemperatureSensor (температурний датчик) служить аналогом апаратного температурного датчика нашої системи. Ізольований аналіз поводження цього класу дає в першому наближенні наступний результат:
Ім'я: TemperatureSensor
Відповідальність: Підтримка інформації про поточну температуру.
Операції:
currentTemperature - поточна температура
setLowTemperature - установка мінімальної температури
setHighTemperature - установка максимальної температури
Атрибути:
temperature - температура
Назва операції currentTemperature (поточна температура) говорить саме за себе. Призначення двох інших операцій (установка мінімальної й максимальної температур) прямо визначається вимогою до системи, а саме необхідністю проведення калібрування датчиків. Сигнал від кожного датчика - це число з фіксованою крапкою з деякого робочого діапазону, граничні значення якого повинні бути задані. Проміжні значення температури обчислюються простою лінійною інтерполяцією між цими двома крапками.
Навіщо ми створюємо спеціальний клас для даної абстракції, коли у вимогах до системи ясно сказано, що температурний датчик може бути тільки один? З метою забезпечення можливості повторного використання абстракції ми все-таки виділяємо її в окремий клас. Насправді кількість температурних датчиків не повинне впливати на архітектуру нашої системи, і, виділяючи окремий клас TemperatureSensor, ми відкриваємо можливість його використання в інших програмах подібного типу.
Абстракція для датчика барометричного тиску може виглядати в такий спосіб:
Ім'я: PressureSensor
Відповідальність: Підтримка інформації про поточний барометричний тиск.
Операції:
currentPressure - поточний тиск
setLowPressure - установка мінімального тиску
setHighPressure - установка максимального тиску
Атрибути:
pressure - тиск
Однак, при більше докладному розгляді вимог до системи з'ясовується, що ми упустили одну важливу характеристику поводження даних класів. А саме, вимоги до системи передбачають визначення тенденцій зміни температури й барометричного тиску (відносна зміна, тренд). У даний момент (на етапі аналізу) ми оборотний основну увагу на природу цього поводження й, найважливіше, з'ясуємо, яка абстракція повинна відповідати за нього.
І для температурного датчика, і для датчика тиску тренд може бути визначений як дійсне число, що змінюється в діапазоні від -1 до 1 і, яке представляє собою нахил графіка змін температури й тиски на деякому інтервалі часу [Значення 0 показує, що температура або тиск стабільний. Значення 0.1 указує на невеликий ріст, значення -0.3 відповідає різкому зменшенню. Значення, близькі до -1 і 1 натякають на природний катаклізм, що виходить за рамки тих сценаріїв, у яких наша система повинна справно працювати]. Таким чином, до опису двох вищезгаданих класів можна додати ще одну відповідальність і відповідну їй операцію:
Відповідальності:
Визначення тренда тиску або температури як нахилу графіка (у лінійному наближенні) зміни їхніх значень за даний інтервал часу.
Операції:
trend - тренд
Відзначивши подібність поводження обох класів, розумно було б створити загальний суперклас, відповідальний за визначення тренда. Назвемо його TrendSensor.
Загалом кажучи, подібна схема не є єдино можливою. Ми вирішили передати відповідальність за визначення тренда датчикам. Можна було б створити зовнішній стосовно датчиків клас, який би періодично їх опитував і обчислював тренд, але ми відкинули такий варіант, тому що він невиправдано ускладнив би систему. Первісний опис класів температурного датчика й датчика тиску вже мало на увазі можливість обчислення тренда "самотужки", а виявивши спільність (організувавши суперклас TrendSensor), ми одержали в результаті просту й зв'язну систему абстракцій.
Абстракцію, що відповідає датчику вологості, можна визначити в такий спосіб:
Ім'я: HumiditySensor
Відповідальність:
Підтримка інформації про поточну вологість, вираженої у відсотках від 0% до 100%.
Операції:
currentHumidity - поточна вологість
setLowHumidity - установка мінімальної вологості
setHighHumidity - установка максимальної вологості
Атрибути:
humidity - вологість
Нам не ставиться завдання визначення тренда вологості, тому клас HumiditySensor, на відміну від класів TemperatureSensor і PressureSensor, не є нащадком класу TrendSensor.
Однак вимоги до системи мають на увазі наявність загального поводження для всіх трьох перерахованих вище класів. Зокрема, ми повинні забезпечити показ максимального й мінімального значень кожного параметра за 24-години. Цей обов'язок можна відбити в наступному описі, загальному для всіх трьох класів:
Відповідальність:
Генерація повідомлень про максимальні й мінімальні значення параметрів за 24-години.
Операції:
highValue - максимальне значення
lowValue - мінімальне значення
timeOfHighValue - час, що відповідає максимальному значенню
timeOfLowValue - час, що відповідає мінімальному значенню
Поки відкладемо рішення питання про те, як реалізувати цю відповідальність; ми повернемося до нього на етапі проектування. Однак, зважаючи на те, що дане поводження є загальним для всіх трьох датчиків, представляється доцільним організація ще одного суперкласу, що ми назвемо HistoricalSensor. Клас HumiditySensor є прямим нащадком класу HistoricalSensor, так само як і TrendSensor. Останній служить проміжним абстрактним класом, перехідним між абстрактним HistoricalSensor і конкретними TemperatureSensor і PressureSensor.
Абстракція для датчика швидкості вітру може виглядати в такий спосіб:
Ім'я: WindSpeedSensor
Відповідальність: Підтримка інформації про поточну швидкість вітру.
Операції:
currentSpeed - поточна швидкість
setLowSpeed - установка мінімальної швидкості
setHighSpeed - установка максимальної швидкості
Атрибути:
speed - швидкість
Вимоги до системи не припускають можливості одержання швидкості безпосередньо від датчика; поточна швидкість вітру повинна визначатися як відношення числа обертів на лічильнику до величини інтервалу часу, за яке вироблялися виміри. Отримане число потім треба помножити на калібрований коефіцієнт, значення якого визначається конструкцією вимірювального пристрою. Цей алгоритм повинен бути, природно, реалізований усередині класу. Клієнти не повинні піклуватися про те, яким образом полічена поточна швидкість вітру.
Короткий аналіз останніх чотирьох класів системи (TemperatureSensor, PressureSensor, HumiditySensor і WindSpeedSensor) показує, що в них є ще одна загальна риса: калібрування обмірюваних значень за допомогою лінійної інтерполяції. Замість того, щоб реалізовувати цю здатність окремо в кожному із класів, можна виділити особливий суперклас CalibratingSensor, відповідальний за виконання калібрування.
Відповідальність:
Забезпечення лінійної інтерполяції значень, що лежать у відомому інтервалі.
Операції:
currentValue - поточне значення
setLowValue - установка мінімального значення
setHighValue - установка максимального значення
CalibratingSensor є безпосереднім суперкласом для класу HistoricalSensor.
Останній розглянутий датчик - датчик визначення напрямку вітру - трохи відрізняється від всіх інших, тому що він не має потреби ні в калібруванні, ні в обчисленні мінімальних і максимальних значень. Ми можемо визначити дану абстракцію в такий спосіб:
Ім'я: WindDirectionSensor
Відповідальність: Підтримка інформації про поточний напрямок вітру, що вказує як крапка на троянді вітрів.
Операції:
currentDirection - поточний напрямок
Атрибути:
direction - напрямок
Щоб об'єднати всі класи, що ставляться до датчиків, в одну ієрархію, має сенс створити ще один абстрактний базовий клас Sensor, що є безпосереднім суперкласом для WindDirectionSensor і CalibratingSensor.
Для побудови UML діаграми використаємо TopCoder UML Designer Tool (ver. 1.3). Він дозволяє працювати зі всіма типами діаграм (Class Diagram, Use Case Diagram, Sequence Diagram, Activity Diagram). Робоча область програми виглядає наступним чином:
Кінцева діаграма класів виглядатиме наступним чином: