Добавление опроса датчиков

Далее для получения картины работы контроллера введем значок активности TestingEnvironment, который, как и в Statechart диаграммы показывает опрос датчиков теплицы.

Алгоритмы опроса датчиков могут быть различны. Выбор алгоритма зависит от проектировщика системы, его опыта и предпочтений. Здесь задача состоит в том, что необходимо в первую очередь создать работоспособную систему и на ее примере научиться пользоваться инструментом. Разберем различные варианты создания датчиков:

1. Создать активные датчики, которые будут сами посылать сообщения контроллеру при изменении параметров, а контроллер будет активизировать исполнительные устройства.

2. Опрашивать датчики по одному с немедленной реакцией на отклонения.

3. Опросить сначала все датчики, а затем, сравнив с необходимыми значениями параметров, заложенными в плане выращивания, активизировать исполнительные устройства для приведения этих параметров в должное состояние.

Первый вариант подразумевает создание нескольких контроллеров определенных параметров среды, которые не связаны друг с другом. С точки зрения объектно-ориентированного проектирования я бы счел этот вариант предпочтительным. Он позволит на основе класса контроллера создавать контроллеры различных параметров и, главное, позволит в дальнейшем расширять систему, добавляя новые контроллеры дополнительных параметров среды практически без затрагивания уже работающих контроллеров.

Второй вариант тоже может быть реализован, но он недалеко уходит от последнего, который, опять же, для простоты создания нашей учебной системы мы и примем к реализации.

По принятому варианту необходим опрос датчиков температуры и рН, затем сравнение с необходимыми значениями и настройка среды путем включения или выключения исполнительных устройств и занесение в протокол данных при изменении параметров.

Окончательный вариант диаграммы

Для отражения этих действий добавим на диаграмму значки действий TestingEnvironment, Writing, AdjustingEnvironmemt. Мы не будем расшифровывать содержание этих действий, чтобы не загромождать диаграмму, но добавим значки решений, которые направляют действия при изменении (IsChanged) среды и при необходимости настройки (NeedAdjust) среды. При этом должна получиться диаграмма, представленная на рис. 7.12.

Рис. 7.12. Диаграмма после добавления всех действий

В окончательном варианте на диаграмме получен полный алгоритм работы контроллера от тестирования параметров среды до их настройки с протоколированием.

В отличие от Statechart Diagram здесь мы не стали подробно расписывать действия TestingEnvironment, Writing, AdjustingEnvironmemt, которые далее распишем при помощи вложенных диаграмм. Вложенные диаграммы в версии 2000 можно создать для каждого значка состояния или активности.

Эта возможность позволяет не загромождать саму диаграмму, а создавать сколько угодно вложенных, что не только скрывает ненужные детали, но и позволяет легко разделить проект для работы команды программистов и также легко собрать проект обратно.

Если вы посмотрите на полученную диаграмму, то заметите, что по алгоритму запись в протокол происходит до проверки на необходимость настройки среды. Это сделано потому, что возможно изменение среды без ее настройки. Например, согласно плану выращивания необходимо скорректировать показатели, а показатели уже изменились в нужную сторону благодаря изменению внешних условий. В этом случае необходимо записать данные об изменениях, но настраивать, т.е. включать исполнительные устройства, нет необходимости.

Но это лишь мое допущение. Создание алгоритма — работа творческая и у каждого проектировщика алгоритм может несколько отличаться в деталях. Но самое главное, Rational Rose позволяет создать такие диаграммы, которые позволяют сделать алгоритм работы программы четким, легко читаемым, понятным даже тому, кто видит его впервые.