РЕИНЖИНИРИНГ ТЕХНОЛОГИЧЕСКИХ ПРОЦЕССОВ СРЕДСТВАМИ UML

1

• Авторы
• Файлы

Лосев В.В. Статья в формате PDF 225 KB Среди задач реинжиниринга технологических процессов, протекающих на цеховом уровне, информационная поддержка которого осуществляется системами CNC (Computer Numerical Control), являющимися составной частью АСУТП (Автоматизированной Системы Управления Технологическими Процессами), выделим следующие задачи: определение автоматизированной предметной области, подлежащей преобразованию; декомпозиция уровня информационной поддержки средствами uml-диаграмм; внедрение изменений в полученную логическую модель. Переход к физической реализации.

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

Методика BPR (Business Process Reengineering) направлена на преобразование информационной структуры предприятия, с целью улучшения показателей эффективности бизнеса. При этом фаза исследования, экономического обоснования и определение границ пересмотра информационной структуры является основополагающей. Принято считать, что CASE - средства, как основной инструментарий данной методики направлены на анализ и разработку таких уровней информационного обеспечения предприятия как ERP, MRP, MES, SCADA. Разработка данных систем управления, а также сам реинжиниринг основаны на методах объектно-ориентированного проектирования. Ведущие CASE - средства процесс моделирования создаваемой системы выстраивают при помощи графических uml-диаграмм способных описать пpaктически любую автоматизируемую предметную область с последующей реализацией программного кода.

Преобразование структуры информационной поддержки цехового уровня также возможно представить с помощью uml-диаграмм описывающих ТП моделью-спецификацией. Исходными данными для построения логической модели служат: технологическое оборудование (датчики, исполнительные устройства, технические средства автоматизации), участвующее в жизненном цикле продукции; технологический регламент. Первым шагом является составления usecase диаграмм, описывающих операции (use case) совершаемые объектами (actor) ТП, на основе набора таких диаграмм создается список требований к системе и определяется множество выполняемых системой функций. Диаграмма Deployment предназначена для анализа аппаратной части системы, при этом выделяются: ведущее устройство (processor), устройства не имеющие операционную платформу (device) и связи (connection). Следующий шаг диаграмма Statechart предназначена для описания состояний объекта и условий перехода между ними, что отражает модель его поведения при получении различных сигналов и взаимодействии с другими объектами. В данном случае уместна теория конечных автоматов, согласно которой сложную систему возможно разложить на простые автоматы имеющие определенные состояния. Диаграмма Activity является разновидностью диаграммы состояний, описывающая моделирование последовательности действий ограниченных значками активности. Кроме сценария поведения каждого объекта  необходимо  точно  представлять  взаимодействие

этих объектов между собой, определение клиентов и серверов и порядка обмена сообщений (сигналов) между ними. Обмен сообщениями происходит в определенной последовательности, и диаграмма Sequence позволяют получить отражение этого обмена во времени. Второй тип диаграмм взаимодействия - это Collaboration Diagram отличается от предыдущей тем, что не акцентирует внимание на последовательности передачи сообщений, только отражает наличие взаимосвязей, сообщений от клиентов к серверам. Диаграмма показывает взаимодействие между объектами, а не классами, то есть является мгновенным снимком объектов системы в некотором состоянии. Завершением построения модели являются два типа диаграмм. Class - основная диаграмма для создания кода приложения, при помощи которой формируется компонентная структура будущего программного обеспечения, описывается наследование и взаимное положение классов друг относительно друга. Что отражает логическое представление системы, так как классы это лишь заготовки, на основе которых затем будут определены физические объекты. Component диаграмма позволяет создать физическое отражение текущей модели, показывает организацию и взаимосвязи программных компонентов, представленных в исходном коде, двоичных или исполняемых файлах. Связи в данном типе диаграммы представляют зависимости одного компонента от другого и имеют специальное отображение. Данный тип диаграммы позволяет получить представление о поведении компонентов по предоставляемому ими интерфейсу.

Решив задачу декомпозиции информационного обеспечения цехового уровня, становится возможным отразить изменения в каждой uml-диаграмме полученной моделиспецификации согласно планов модернизации и технического переоснащения данного этапа производства. Процесс реинжиниринга не обходится без современных CASE - инструментов, одним из ведущих является Rational Rose, среда которого позволяет выстроить uml-диаграммы, а на основе диаграммы Class создать код класса на одном из языков программирования.

---