Переключаться между двумя последними диаграммами удобно при помощи значка Browse Previous Diagram.

Рис. 4.6

Диаграмма Use Case после добавления значка «Оператор»

Заметим, что план выращивания должен поступать в систему и обраба­тываться. Также оператор должен иметь возможность просматривать про­токол работы системы.

Создадим новый объект и назовем его Контроллер. Соединим его связью с элементом «создать план выращивания». Создадим новый значок «создать протокол», который соединим связью с Контроллером. Теперь у нас получился диаграмма, представленная на рис. 4.7.

Рис. 4.7

Диаграмма Use Case после добавления значка «Контроллер»

Также контроллер должен управлять исполнительными устройствами. Для отражения этого процесса создадим use case с именем «управлять уст­ройствами» и новое действующее лицо «Устройства».

Также необходимо создать новое действующее лицо «Датчик» и use case «измерить показатели среды». После соединения связями этих значков у вас должно получиться изображение, показанное на рис. 4.8.

Рис. 4.8

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

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

1. оператор должен иметь возможность задать план выращивания;

2. оператор должен иметь возможность просматривать протокол работы системы;

3. система должна получать информацию от датчиков;

4. система должна иметь возможность управлять внешними устройст­вами на основе показателей датчиков и введенного плана выращива­ния.

Как вы заметили, я не углублялся в детали поведения того или иного актера, так как написание эффективных сценариев поведения — это целая наука и здесь мы лишь попробовали свои силы при помощи инструмента Rational Rose.

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

Устройства тепличного хозяйства

Теперь вы можете создать устройства таким образом, как это показано на рис. 5.5.

Рис. 5.5

Устройства тепличного хозяйстве

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

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

Исполнительные устройства представлены лампой, нагревателем, вентилятором, водным резервуаром и резервуаром с удобрениями.

Лампа должна включаться при недостатке освещения, однако, датчик освещенности не предусмотрен, значит, лампа должна гореть всегда, когда система переходит в режим «день» и выключаться когда система переходит в режим «ночь».

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

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

 

Создание заготовок классов

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

, Исходя из рассмотренных в главе 5 устройств, получаем следующих кандидатов для создания классов:

• EnvironmentalController — контроллер управления исполнительными устройствами;

• TemperatureSensor — датчик температуры;

• pHSensor — датчик кислотности;

• Heater — нагреватель;

• Cooler — вентилятор для снижения температуры;

• Light — осветитель;

• WaterTank — хранилище для воды;

• NutrientTank — хранилище для удобрений

В-State (состояние)

Инструмент State позволяет отразить состояние или ситуацию в течение жизни объекта, которая отвечает некоторому положению объекта или ожиданию им некоторого события. Каждое состояние представляет собой совокупную историю поведения объекта. Его имя должно быть уникально внутри класса, так как состояния с одинаковыми именами считаются представлением одних и тех же состояний. В текущем значке State могут быть отражены действия по входу, выходу из состояния, действия не свя­занные с событиями или реакция на события. Подробнее установку этих действий рассмотрим далее.

Start State (начало)

Инструмент Start State позволяет создать значок начала работы. Для диаграммы Statechart он обозначает событие, которое переводит объект в первое состояние на диаграмме.

Замечание

Все диаграммы состояний начинаются со значка Start State и должны заканчиваться значком End State. При этом значок начала работы может быть только один, а значков окончания может быть сколько угодно. За этим Rational Rose следит самостоятельно.

End State (завершение)

Инструмент End State позволяет создать значок окончания работы. Направление перехода может быть установлено только в данный значок, однако, никаких ограничений на количество переходов в End State, а также на количество таких элементов на диаграмме, не налагается.

••

State Transition (состояние перехода)

Инструмент State Transition позволяет создать значок состояния перехода, который означает, что объект переходит из одного состояния в другое в случае наступления определенного события или по изменению определенных условий.

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

Transition To Self (переход на себя)

Инструмент Transition To Self позволяет создать значок перехода в то же состояние, из которого осуществляется переход.

Данный переход похож на State Transition, однако, он не осуществляет переход в другое состояние при наступлении некоторого события. Таким образом, при наступлении события оно обрабатывается, и после обработки объект возвращается в то состояние, в котором он находился до наступления события.

Для того чтобы назвать событие, которое переводит систему из началь­ного состояния в состояние ожидания, выделим стрелку события и проде­лаем следующее RClick=>Open Specification=>General==>Event=New Plan­ting, что в переводе означает «посадка семян». Должно получиться состоя­ние, показанное на рис. 6.6.

Рис. 6.6 <

Состояние ожидания

 

Состояние тестирования датчиков

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

В нашем случае не будем рассчитывать на большую интеллектуальность датчиков. Датчики не будут иметь своего процессора и будут только выда­вать измененные параметры по запросу контроллера. Таким образом, сле­дующим состоянием будет опрос датчиков. Добавим это состояние на диа­грамму, назовем Testing Environment и соединим с состоянием Idle. Это со­бытие назовем Timer. Имеется в виду, что у контроллера есть встроенные часы, которые через заданное время инициализируют это событие.

Теперь разберем подробнее, что необходимо сделать для тестирования параметров среды.

Активизировавшись, контроллер опрашивает датчики температуры и рН. Для того чтобы отразить, что опрос датчиков происходит в течение данного состояния, необходимо добавить новое действие (Action). Для этого во вкладке Actions (98i Detail) из контекстного меню выбираем Insert.

Выберем полученное действие двойным нажатием мыши и попадем в диалоговое окно, представленное на рис. 6.7 (окно показано для версии 98i).

Для версии 2000 это окно получило некоторые изменения, которые, впрочем, не отразились на его сути (рис. 6.8).

Здесь мы можем переключаться между действием (Action) и посылкой сообщения (Send Event). Разница между этими пунктами в том, что действие осуществляется самим классом, для которого мы создаем диаграмму состояния, то есть здесь вызывается метод этого класса, а посылка сообщения направлена на объект другого класса, метод которого вызывается при помощи этого сообщения. Этот объект задается в строке Send target. Также можно задать имя вызываемого метода класса в строке Send event и аргументы в строке Send arguments.

Можно настроить момент, в который происходитотмеченное действие. Здесь предоставляется выбор из четырех состояний:

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

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

• Do (Entry until exit для 98i) — действия, производимые в течение состояния до выхода. Если таких действий набирается несколько, то почти наверняка их можно выделить в отдельную диаграмму состояния.

• On Event (Upon event для 98i) — действия в ответ на определенные события, обрабатываемые в текущем состоянии. При выборе этого пункта открывается возможность заполнить события (Event), параметры (Arguments) и условия, когда это действие обрабатывается (Conditi­on), то есть может случиться так, что событие произошло, а условие его обработки не наступило. Этот пункт удобно использовать при обработке события, которое не приводит к переходу в другие состояния и отражается значком Transition To Self. Нужно заметить, что при изменении этих параметров изменяется и над­пись на значке состояния.

События отражаются при помощи символа " перед ним. Действия: при входе: entry:, при выходе: exit:, в течение работы: do:, действия по сообщению: on:. Условие обработки показывается выражением в квадратных скобках. Данная нотация довольно удобна и позволяет, не активизируя окно свойств, одним взглядом оценить сделанное.

Заполним событие как показано на рис. 6.7-6.8. По аналогии заполним действие для опроса датчика рН и получим рис. 6.9.

Рис. 6.9

Значок состояния при тестировании среды после изменений

Вывод диаграммы из цикла

После того как протестировано состояние среды, необходимо привести по­казатели к норме посредством включения соответствующих исполнительных устройств. Для отражения этого действия создадим состояние Adjusting Environment, которое соединим с состоянием Testing Environment.

После настройки среды система переходит в ожидание следующего мо­мента времени. Отразим это при помощи стрелки, соединяющей состояния Adjusting Environment и Idle.

Однако у нас получилась система с бесконечным циклом. У нее нет вы­хода. Но мы знаем, система должна закончить работу в тот момент, когда урожай созрел. Ключом созревания будем считать истечение времени вы­ращивания растения по плану выращивания.

Для отражения этого введем состояние Analysing Time, которое включим между состоянием Idle и Testing Environment. Перетащим конец стрелки Timer на Analysing Time и соединим его новой стрелкой Testing Envi­ronment. Добавим End State, соединим это состояние с Analysing Time, за­полним условие RClick=>Open Specification=>Detail (рис. 6.10), говорящее о том, что переход осуществляется только тогда, когда истекло время роста растения. Это окно имеет практически те же заполняемые поля, что и рас­смотренное ранее, поэтому не будем на нем подробно останавливаться. Единственное, что хотелось бы отметить, это то, что стрелку можно перене­сти прямо отсюда, изменив позиции From (откуда) и То (куда).

Добавление замечания

Для добавления последнего, еще не использованного нами значка, вве­дем в диаграмму комментарий, который соединим при помощи значка Anchor Note to Item с состоянием Analysing Time, и должно получиться примерно следующее (рис. 6.11).

Рис. 6.11

Диаграмма состояния после добавления замечания

Настройка среды

Распишем подробнее, какие состояния должна пройти система для на­стройки среды в соответствии с планом выращивания, при этом сделаем следующие допущения:

• для увеличения температуры в теплице необходимо включить нагре­ватель;

• для уменьшения температуры необходимо включить вентилятор;

• для переключения в режим «День» необходимо включить освещение;

• для переключения в режим «Ночь» необходимо выключить освещение;

• для уменьшения рН необходимо добавить в раствор воды;

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

Произведя анализ необходимых действий, нетрудно заметить, что пере­численный набор можно разделить на три независимые части, это:

• настройка температуры;

• настройка освещения;

• настройка уровня рН.

Так как мы приняли допущение, что процессор у нас только один, то эти состояния будут пройдены последовательно. Но если для каждой части используется свой процессор, то можно было бы создать автономные клас­сы для управления этими состояниями.:

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

Добавим три новых состояния Adjusting t (настройка температуры), Adjusting Light (настройка освещения) и Adjusting рН (настройка рН). Для этого добавим новые состояния прямо в значок Adjusting Environ­ment. Перед добавлением значок будет выделен рамкой, а после добавле­ния будет автоматически раздвинут, чтобы в него уместился добавленный элемент. Изменим направления входящей и выходящей стрелок так, чтобы входящая указывала на Adjusting рН, а выходящая исходила из Adjusting t, и соединим эти состояния последовательно. Теперь распишем, что происходит в этих состояниях (рис. 6.12).

Рис. 6.12

Настройка среды

Настройка температуры происходит только при ее изменении, что пока­зывают функции tempDown и tempUp. Если произошло одно из этих собы­тий, то температура сравнивается с той, которая должна быть по плану, и если она меньше, то включается нагреватель, а еслибольше — вентилятор.

Однако если температурадостигла нормального уровня, то вентилятор и нагреватель отключаются. Аналогично происходит и с уровнем рН.

Для освещения лампочка просто включается при наступлении времени освещения и выключается при наступлении ночного времени суток.

States History (история состояний)

Единственное, что осталось не рассмотренным на этом типе диаграмм, — это настройка States History.

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

Протоколирование начинается при изменениях в условиях (Environ­ment Changed). После этого создается Log файл (Create Log) и система пере­ходит в состояние ожидания (Log ready). При необходимости записать из­менения они записываются (Logged), и система снова переходит в состоя­ние ожидания. При этом в следующий раз необходимо начинать с состоя­ния Log ready, а не с создания протокола.

Рис. 6.13

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

Создание Activity Diagram

Назначение диаграммы активности

Activity Diagram (диаграмма активности) — новая по отношению к вер­сии 981. Она позволяет моделировать последовательность бизнес-процессов или операций класса по принципу от активности к активности или от ак­тивности к состоянию.

Этот тип диаграмм может использоваться для моделирования различ-, ных типов действий и заменять такое известное CASE-средство, как BPwin компании PLATINIUM.

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

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

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

Начало создания диаграммы

Теперь посмотрим, как изменится диаграмма, если создавать не диа­грамму состояния, а диаграмму активности для работы объекта Environ-mentalController.

Создадим начало диаграммы, поместив на диаграмму значок Start State и состояние Idle. Соединим их связью State Transition и назовем ее New Planting.

Теперь вспоминаем, что перед тем, как перейти в состояние ожидания, контроллер должен установить значение таймера, продолжительность вы­ращивания, время ожидания между опросами датчиков. В этом случае можно сразу разделить функции, выполняемые таймером и контроллером, для чего создадим отдельные разделители Swimlane для этих объектов.

Создание значка анализа времени

На диаграмме Statechart, созданной нами ранее, следующим значком был анализ времени, который здесь можно расписать подробнее.

Рис. 7.8

Диаграмма после заполнения значка активности

Совет

Переключаться между двумя последними диаграммами удобно при помощи значка Browse Previous Diagram.

Добавление значка получения времени

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

Для отображения этого процесса создадим новый значок Activity и на­зовем его GetCurrentTime, который соединен со значком Idle событием Timer. Добавим значок GetCurrentTime для отражения обращения к тай­меру за текущим временем. Создадим значок ReturnTime для объекта Timer и введем значок решения для контроллера (рис. 7.9).

Рис. 7.9

Диаграмма активности после ввода значка решения

Для того чтобы отразить, что работа контроллера должна быть законче­на, добавим значок EndState и соединим его стрелкой с условием, что пере­ход должен осуществляться только в случае, когда закончилось время вы­ращивания растений. На рис. 7.10 показано, как необходимо заполнить свойства для StateTransition в этом случае.

Рис. 7.10

Установка свойств для State Transition

Рис. 7.11

Диаграмма после добавления значка синхронизации

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

Обычно линии синхронизации используются при проектировании про­цессов клиент-сервер, когда клиенты выдают запросы сразу нескольким серверам и ожидают от них ответа, или при проектировании бизнес-про­цессов, происходящих в нескольких структурных подразделениях одного офиса, где, например, различные документы обрабатываются в подразде­лениях, а затем, по завершении создания всех документов, происходит их группировка в один отчет.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Добавление класса plantDayHour

Если посмотреть на созданную ранее диаграмму состояний (рис. 6.13), то после получения сообщения от таймера происходит анализ времени, прошедшего от начала посадки растений. Этот анализ неплохо было бы пе­реложить на плечи объекта специального класса, например класса plant­DayHour. Этот класс будет отвечать за отсчет текущего дня и часа. Доба­вим объект m_plantDayHour и создадим для него новый класс plantDay­Hour. Соединим новыми сообщениями UpdateTimeQ и GetCurrentTime() объект контроллера и m_plantDayHour и получим рис. 8.9.

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

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

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

На этом рисунке добавлены датчики, нагреватель и вентилятор. Доба­вить Water-Tank, NutrientTank и Light вы можете самостоятельно.