Разработка автоматизированной системы управления колонны в установки по переработке мазута

Рисунок 8 - Диаграмма деятельности 

Диаграмма последовательности

     Диаграммы последовательности отражают поток  событий, происходящих в рамках варианта использования. На диаграмме последовательности (рисунок 9) объект изображается в виде прямоугольника, от которого вниз проведена пунктирная вертикальная линия. Эта линия называется линией жизни (lifeline) объекта. Она представляет собой фрагмент жизненного цикла объекта в процессе взаимодействия. Каждое сообщение представляется в виде стрелки между линиями жизни двух объектов. Каждое сообщение помечается как минимум именем сообщения; при желании можно добавить также аргументы и некоторую управляющую информацию, и, кроме того, можно показать само-делегирование (self-delegation) – сообщение, которое объект посылает самому себе, при этом стрелка сообщения указывает на ту же самую линию жизни.

     В процессе работы системы происходит обмен сообщениями между объектами  в определенной последовательности во времени. Объекты, являющиеся клиентами, посылают сообщения, а объекты, являющиеся серверами, обрабатывают их.

     Для моделируемой модели этот поток событий  выглядит следующим образом. Основным сервером  является блок Regulation Device:Controller. Сервер в первом шаге делает запрос о времени к клиенту Timer, что является первоочередной задачей для продолжения работы системы. Сообщение обладает свойством timeout, определяющим условие: клиент отказывается от выдачи сообщения, если сервер в течение определенного времени не может его принять. После принятия данных сервер опрашивает клиентов относящихся к типу датчиков. После сбора информации сервер обрабатывает данные(data processing) и формирует нормы. После этого сервер начинает посылать запросы к типу клиентов исполнительные устройства, определяя в запросе их действия. Очередность в этих действиях отсутствует, так регулирование осуществляется в зависимости от  требований запроса.

Рисунок 9 - Диаграмма последовательности 

Кооперативная диаграмма

     Вторым  видом диаграммы взаимодействия является кооперативная диаграмма. Подобно диаграммам последовательности, кооперативные диаграммы (collaborations) отображают поток событий через  конкретный сценарий варианта использования. Диаграммы последовательности упорядочены  по времени, а кооперативные диаграммы  больше внимания заостряют на связях между объектами. На рисунке 10 приведена кооперативная диаграмма, описывающая, как контроллер управляет работой.

Рисунок 10 - Кооперативная диаграмма 

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

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

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

     Контроллер  является глобальным (global) по отношению к другим объектам и используется совместно (shared). Объекты, относящиеся к датчикам, имеют видимость (parameter), то есть передаются параметром в другой объект Исполнительные устройства и таймер включены в объект (field). 

Диаграмма компонентов

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

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

     В данном случае система разрабатывается  на языке VС++. У каждого класса имеется свой собственный заголовочный файл и файл с расширением .СРР, так что каждый класс преобразуется в свои собственные компоненты на диаграмме.

     Диаграммы компонентов применяются  участниками  проекта, кто отвечает за компиляцию системы. В соответствии с рисунком 9,10 видно, в каком порядке надо компилировать компоненты, а также, какие исполняемые компоненты будут созданы системой. На такой диаграмме показано соответствие классов реализованным компонентам. Она нужна там, где начинается генерация кода. 

Рисунок 11 - Диаграмма компонентов 
 
 

Диаграмма классов

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

     В языке UML определены три основных стереотипа классов: Boundary (граница), Entity (сущность) и Control (управление).

     Граничными  классами (boundary classes) называются  классы, которые расположены на границе  системы и всей окружающей среды. Это экранные формы, отчеты, интерфейсы с аппаратурой (такой как принтеры или сканеры) и интерфейсы с другими  системами.

     Чтобы найти граничные классы, надо исследовать  диаграммы вариантов использования. Каждому взаимодействию между действующим  лицом и вариантом использования  должен соответствовать, по крайней  мере, один граничный класс. Именно такой класс позволяет действующему лицу взаимодействовать с системой. Классы-сущности (entity classes) содержат хранимую информацию. Они имеют наибольшее значение для пользователя, и потому в их названиях часто используют термины из предметной области. Обычно для каждого класса-сущности создают  таблицу в базе данных. Управляющие  классы (control classes) отвечают за координацию  действий других классов. Обычно у каждого  варианта использования имеется  один управляющий класс, контролирующий последовательность событий этого  варианта использования. Управляющий  класс отвечает за координацию, но сам  не несет в себе никакой функциональности, так как остальные классы не посылают ему большого количества сообщений. Вместо этого он сам посылает множество  сообщений. Управляющий класс просто делегирует ответственность другим классам, по этой причине его часто  называют классом-менеджером.

     В системе могут быть и другие управляющие  классы, общие для нескольких вариантов  использования. Например, может быть класс SecurityManager (менеджер безопасности), отвечающий за контроль событий, связанных с безопасностью. Класс TransactionManager (менеджер транзакций) занимается координацией сообщений, относящихся к транзакциям с базой данных. Могут быть и другие менеджеры для работы с другими элементами функционирования системы, такими как разделение ресурсов, распределенная обработка данных или обработка ошибок. Помимо упомянутых выше стереотипов можно создавать и свои собственные. Полученная диаграмма классов представлена на рисунке 12. 

Рисунок 12 - Диаграмма классов 

     В данной среде возможна генерация  программного кода, при котором автоматически  создается диаграмма классов. Это  возможно благодаря библиотеке классов фирмы Microsoft - MFC. Для последующей генерации используется модуль Model Assistant. Необходимо для каждого класса указать стереотип класса, язык на котором он будет создан, и определить компонент, в котором этот класс будет храниться. Для данной системы был использован язык Microsoft Visual C++ v.6.0. В данном приложении также автоматически генерируется исходный код взаимодействующих классов на языке VC++, который в дальнейшем используется для создания визуальных моделей уже по написанному исходному коду.

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

ЗАКЛЮЧЕНИЕ

     Технологические установки перегонки нефти предназначены  для разделения нефти на фракции  и последующей переработки или  использования их как компоненты товарных нефтепродуктов. Они составляют основу всех НПЗ. На них вырабатываются практически все компоненты моторных топлив, смазочных масел, сырье для  вторичных процессов и для  нефтехимических производств. От их работы зависят ассортимент и  качество получаемых компонентов и  технико-экономические показатели последующих процессов переработки  нефтяного сырья.

     Целью данного проекта была автоматизация  колонны вакуумного блока установки ЭЛОУ АВТ - 6.

     Несомненными  преимуществами данной системы управления являются:

     - высокая надежность;

     - быстродействие;

     - непрерывный контроль над системой;

     - гибкость;

     - экономичность.

     На  последних этапах были рассчитаны технико-экономические  показатели внедрения АС. Срок окупаемости  проекта составил 0,7 года.