Диаграмма последовательности отображает некоторый набор объектов на единой временной оси показан жизненный цикл какого-либо определённого объекта (создание-деятельность-уничтожение некой сущности) и взаимодействие актёров (действующих лиц) ИС в рамках какого-либо определённого прецедента (отправка запросов и получение ответов).
Диаграмма последовательностей для АСУ, показана на рисунке 6.
Рисунок 6 – Диаграмма последовательности
Как видно из рисунка 6, пользователь включает систему, после чего система обращает к датчикам верхней и нижней границ и записывает их данные. После считывание данных с датчиков система обращается к критическим данным и записывает их. После того как система получила все необходимые данные она начинает сравнивать показания окружающей среды и критических данных, и на основе сравнения принимает решение включить или выключить насосы для полива почвы. После этого система выводит показания влажности почвы.
Диаграмма кооперации
Диаграмма кооперации относится к тому же классу диаграмм, что и диаграмма последовательности, а именно, к диаграммам деятельности.
Диаграмма кооперации для АСУ приведена на рисунке 7.
Рисунок 7 – Диаграмма кооперации[i11]
Диаграмма кооперации в точности повторяет разработанную диаграмму последовательности, поэтому на следующем этапе можно приступить к разработке диаграммы программных классов для АСУ.
Диаграмма программных классов
На основании выполненного анализа в диаграмме классов вносить изменения не будем, и она будет повторять диаграмму концептуальных классов, как это показано на рисунке 8.
Рисунок 8 – Диаграмма программных классов
Как видно из рисунка 8, при разработке АСУ необходимо предусмотреть возможность отслеживать состояние полива при помощи датчиков верхней и нижней границ, и обеспечить полив с помощью насоса.
Раздел 4. Модель данных
После проведения объектно-ориентированного анализа в среде Rational Rose выполним разработку модели данных в среде Erwin (рисунок 9).
Рисунок 9 – Модель данных в среде Erwin
Как видно из рисунка 9, в модели данных используются сущности «Контроль», «Насосы», «Критические данные датчиков», «Датчик верхней границы воды» и «Датчик нижней границы воды». Между сущностями выбрана не идентифицирующая связь «один-ко-многим».
Раздел 5. Модель реализации[i12]
Модель реализации делаем с помощью диаграммы классов, представленной на рисунке 9. При помощи плагинов, подключенных к приложению Caseberry, мы генерируем, компилируем и собираем данные. На выходе получаем приложение, основанное на диаграмме классов. Рисунок главной страницы приложения представлен на рисунке 10.
Рисунок 10 – Главная страница приложения
На рисунке представлена главная форма с помощью, которой можно зайти ещё на пять форм: «Контроль», «ДатчикВерхнейГраницыВоды», «ДатчикНижнейГраницыВоды», «КритическиеДанныеДатчиков» и «Насосы»
В формах «ДатчикВерхнейГраницыВоды» и «ДатчикНижнейГраницыВоды» представлена работа датчиков верхней и нижней границ уровня воды. Номер датчика указывает на присвоенный ему номер. Проверка уровня воды показывает превышен ли порог жидкости в резервуарах, если значение датчика равно 0 значит уровень не превышен, если 1 значит превышен. Рисунки форм датчиков представлены на рисунках 11 и 12.
Рисунок 11 – Форма датчика верхней границы уровня воды
Рисунок 12 – Форма датчика нижней границы уровня воды
С помощью формы «КритическиеДанныеДатчиков» можно сколько раз жидкость в резервуарах превышала датчики границ. Рисунок формы критических данных представлен на рисунке 13.
Рисунок 13 – Форма критических данных с датчиков
На рисунке 14 представлена форма «Насосы», в этой форме указано количество насосов, подключенных к системе и их номера.
Рисунок 14 – Форма насосов
Форма «Контроль» суммирует данные со всех остальных форм и показывает есть ли отклонение границе жидкости. Рисунок формы контроль представлен на рисунке 15.
Рисунок 14 – Форма контроль[i13]
Заключение[i14]
В процессе выполнения работы был выполнен объектно-ориентированный анализ и разработана АСУ по контролю за микроклиматом в тепличном комплексе и проанализирован блок контроля за подачей воды и удобрений.
Были выполнены следующие этапы:
· Проведен системный анализ и анализ требований к системе
· Разработана модель прецедентов
· Разработана модель предметной области
· Разработана модель проектирования
· Модель данных
· Модель реализации
Для разработки моделей в курсовой работе была использована среда Caseberry, которая позволяет реализовать объектно-ориентированный анализ на основании языка UML, так же в данной среде с помощью языка С# было разработано приложение модели реализации.