CC BY
29
Применение шаблонов проектирования при построении информационных систем предприятий машиностроения
И.В. Илларионов Воронежский государственный университет, кафедра Программирования и информационных технологий, [email protected]
В.Н. Старов
Воронежский государственный технический университет, кафедра Автоматизации оборудования В. А. Муранов
Воронежский государственный технический университет, кафедра Автоматизации оборудования, [email protected]
Новая редакция международных стандартов в области качества ISO 9000 2000 года предполагает использование процессоориентированного подхода, как идеологической основы построения систем управления качеством продукции. Различные методики такого подхода на настоящий момент известны и активно используются как элемент информационных технологий, например, при проектировании программных средств и информационных систем управления предприятиями. Каждая из них включает в себя в той или иной степени стандартизированную графическую нотацию, реализующие ее программные средства и методические материалы по использованию. Особо отметим важность графической нотации, которая наряду с предоставлением исходной информации для программных средств, обеспечивающих генерацию кодов, выполняет методически не менее важную задачу - служит своеобразным «интерфейсом» между специалистом в предметной области (менеджером, технологом, финансистом) и специалистами в области информационных технологий. Именно на этапе их взаимодействия во многом закладывается степень адекватности, с которой проектируемая система сможет описывать функционирование предприятия или организации и, в конечном итоге, качество программного продукта.
Предприятия материального производства или сферы услуг, рассматриваемые во всем многообразии их внешних связей и взаимодействий составляющих их частей, очевидно, требуется рассматривать как сложную
систему /1,2/, для описания различных сторон функционирования которых целесообразно использование различных способов. Например, известная группа методик IDEF /3/ позволяет описать функциональную структуру (IDEF0), информационную структуру (IDEF1Х), динамику функционирования (IDEF3) объекта. При использовании каждой из них приходится учитывать возможности соответствующих программных средств. Так, если для IDEF0 и IDEF1Х существует значительное количество активно используемых программных пакетов, то для описания динамического поведения вместо IDEF3 гораздо удобнее и экономически целесообразнее использовать иные нотации (UML), лучше поддержанные программными средствами.
На начальном этапе проектирования требуется определить системы предприятия и входящие в них процессы и объекты с целью последующего управления ими. Такое описание начинается с наиболее общих задач с последующим уточнением до элементарных составляющих.
В ГОСТ Р ИСО 9001:2001 к обязательным бизнес-процессам относятся:
- реализация ответственности высшего руководства в рамках системы качества;
- менеджмент ресурсов (кадры, инфраструктура, рабочая среда);
- менеджмент производственных процессов (процессов жизненного цикла продукции приравненных к ним по степени важности вспомогательных процессов обеспечения);
- процессы измерения, контроля и улучшения системы качества.
Кроме того, как обязательные элементы процессов, составляющих бизнес-процесс, рассматриваются:
• документы, содержащие политику, цели организации в сфере менеджмента качества, руководство по качеству;
• документированные процедуры, в том числе документы, содержащие ответственность сотрудников организации;
• документация на процессы, необходимая для обеспечения их эффективного планирования, управления и улучшения;
• записи качества, и т.д.
Соответственно, функциональная модель должна содержать все обязательные процессы и элементы в соответствии с требованиями ГОСТ Р ИСО 9000:2001.
В пользу применения методологии IDEF0 для описания и классификации процессов говорит то, что она является официальным стандартом функционального моделирования в ряде стран, включая США и Россию. Последнее обстоятельство делает возможным использовать методологию IDEF0 в качестве единого языка для обмена информацией между организациями.
Для промышленного предприятия действующего в современной конкурентной среде наряду с выполнением задачи построения его информационной модели не менее важной является способность построенной модели обеспечивать эффективную поддержку задачи постоянной реструктуризации производства (в частности технологических процессов материального производства и соответствующих им информационных технологий). Наиболее эффективно эти задачи решаются при поддержке программных средств. Так, развитие продукции, направленное на повышение её характеристик, эффективно поддерживается CAD/CAM/CAE - системами, обеспечивающими конструирование, проектные расчеты, кинематическое моделирование и др.
Цена продукции определяется, в свою первую очередь, её себестоимостью, на которую оказывает влияние значительное количество факторов. Оптимизация здесь может быть осуществлена при поддержке систем управления предприятием - ERP - систем, обеспечивающих оптимальное планирование, повышение загрузки оборудования, сокращение складских запасов, сокращение длительности производственных циклов, и т.д.
С внедрением в практику стандартов CALS место идеологической основы проектирования информационных систем прочно занял объектный подход, для которого, в свою очередь, стандартом проектирования стала нотация языка UML /4,5/ . Далее рассматривается формальное описание процессов
машиностроительного производства с учетом динамики поведения и взаимодействия отдельных объектов.
Наибольший эффект от внедрения автоматизированного оборудования может наблюдаться лишь при полной интеграции всех систем производства. Дело в том, что в контексте крупного предприятия очень трудно заставить работать все системы слаженно и синхронно, обеспечить выполнение и взаимодействие множества параллельных процессов в реальном времени. Много предприятий, вышедших на рынок, показали полную свою несостоятельность и неспособность конкурировать с вновь созданными фирмами. Однако, повышение их эффективности всё же возможно. Одно из направлений - построение единой информационной системы предприятия.
С развитием компьютерных технологий можно было наблюдать революцию в интеграции различных этапов проектирования и производства изделий; пришли новые технологии, таких производителей CAE/CAD/CAM-систем как Unigraphics Solutions, Dassault Systemes, Autodesk, Structural Dynamics Research Corporation и других. Но у отечественной промышленности зачастую просто не хватает средств на покупку этого, вне всякого сомнения, мощного современного программного обеспечения и его поддержку.
Итак, перед отечественной промышленностью стоит задача построения информационной системы, интегрирующей в своих рамках различные подсистемы производства. В данной работе предлагается подход к построению такой системы, основанный на шаблонах проектирования.
На предприятиях работают специалисты предметной области. Для осуществления проекта построения информационной системы необходим контроль над его реализацией со стороны экспертов в предметной области, при этом надо чётко разделить труд программиста и эксперта. К сожалению, такая практика у нас используется не всегда.
Разработка крупномасштабного программного обеспечения- достаточно сложная задача, требующая использования CASE-технологий (Computer-Aided Software Engineering - автоматизированная разработка программного
обеспечения) и UML (Universal Modeling Language - универсальный язык моделирования). Перечисленные средства позволяют жестко формализовать процесс создания ПО и разбить его на приемлемые по размеру части - для параллельной разработки несколькими группами /6,7/ .
При выполнении работы авторы исходили из следующих задач:
1) Изучение возможностей CASE-технологий и UML применительно к разработке программного обеспечения для материального производства.
2) Построение общей концептуальной модели техпроцесса (на примере сверления) как потомка абстрактного техпроцесса и словаря начального уровня информационной системы машиностроительного производства с использованием UML и шаблонов проектирования.
3) Подетальная проработка системы управления предприятием на уровне шаблонов.
4) Проектирование:
• услуг, предоставляемых системой, на диаграммах прецедентов или случаев использования (use case diagrams);
• их реализаций в виде ассоциаций классов на диаграммах коопераций (collaboration diagrams);
• классов на диаграммах классов (class diagrams);
• процессов и объектов во временных рамках на диаграммах последовательностей и состояний (sequence diagrams, state diagrams);
• физического развёртывания системы в пространстве на диаграммах развёртывания (deployment diagrams) для лучшего понимания масштаба системы и физической связи её отдельных звеньев.
Чтобы потребителем данной системы могло стать любое предприятие машиностроения, проектирование её ведётся с использованием шаблонов.
5) Проектирование целевой части проекта (CAM-системы) до самого логически низкого уровня. Этим демонстрируется реальный пример разработки ПО с использованием CASE-технологии.
6) Разработка с использованием технологии CASE универсального CAM - программного обеспечения (АСТПП) для упрощения обслуживания и повышения эффективности работы оборудования с ЧПУ в рамках информационной системы предприятия. Разрабатываемая САМ-система - среда визуального проектирования формализованных техпроцессов сверления для операционной системы Windows с интуитивно понятным графическим интерфейсом, требующим минимум времени для освоения. САМ-система имеет клиентскую и серверную составляющие: собственно среда визуального проектирования с локальной базой данных (БД) и ПО оснастки сервера БД техпроцессов. Так реализуется принцип сотрудничества разработчиков техпроцессов: доступ к серверу базы данных возможен с любого компьютера, подключённого к корпоративной сети (рассматриваются сети, работающие по протоколу TCP/IP), на котором имеется клиентская часть CAM-системы. Права на удаление техпроцессов и управление базой данных пользователей и паролей для простых разработчиков отсутствуют. Для этих возможностей реализован вход для администратора через веб-интерфейс с любого компьютера, с которого опять же есть доступ к корпоративной сети, и установлен любой обозреватель сети (Internet Explorer, Netscape, Opera). Таким образом, администрирование главной БД техпроцессов может производиться с компьютера с любой операционной системой. Так частично реализован принцип кроссплатформенности. Для полной его реализации следует переписать клиентскую часть CAM-системы на Java, что, к сожалению, приведёт к снижению производительности и появлению ограничений, накладываемых на графический интерфейс, поэтому в рамках этого проекта мы не используем Java. Для конкретизации клиентская часть CAM-системы ориентирована на создание техпроцессов сверления.
Написание CAM-системы не имело целью создать систему прямого программирования оборудования с ЧПУ. На выходе системы предполагалось получать именно формализованный техпроцесс, который на следующем этапе должен обрабатываться парсером (синтаксическим анализатором), написанным
для конкретного станка. Так реализован принцип универсальности (аналогия с виртуальной Java машиной).
Проектирование велось в три этапа, результатом чего стали диаграммы верхнего, нижнего и среднего уровня.
Самый верхний уровень абстракции представлен девятью диаграммами прецедентов, с разных позиций и с разным уровнем детализации отражающие процессы, происходящие в АСУП.
• Диаграмма общей системы. На ней присутствуют актёры, представляющие людей или системы, внешних относительно АСУП, и прецеденты, представляющие в рамках АСУП те услуги, которые она предлагает потребителям. Обобщённо говоря, прецеденты показывают процессы, происходящие в системе, а актёры - их клиентов.
• Диаграмма системы поддержки жизненного цикла продукта. Как говорилось выше, предприятие, применительно к которому рассматривается разработка АСУП, работает в рамках стандартов CALS или ISO9000:2000, то есть обслуживает весь жизненный цикл своих продуктов - маркетинговое исследование, проектирование, разработка, испытание, техническая поддержка
• Диаграмма системы управления кадрами. АСУП в частности обеспечивает автоматизированную работу с кадрами, включая набор кадров через биржи труда, их обучение и т.д.
• Диаграмма системы работы с репозиторием (базой знаний). Репозиторий -это база знаний, в которой хранятся все наработки данного предприятия и других, схожих по профилю, а также нормативная документация (ГОСТ, ОСТ и пр.), каталоги моделей стандартизированных деталей и материалов и подобная информация. Репозиторий не однороден по своей природе и удачная организация его может служить залогом успешной работы в дальнейшем. Нами избрана объектно-релятивистская модель базы данных для организации базы знаний. Как сказано выше, такие базы данных основаны на следующих принципах:
Каждая сущность, информация о которой хранится в БД, — это объект.
1. Каждый объект уникален в пределах БД и имеет уникальный идентификатор.
2. Объект имеет свойства (строковые, числовые, временные, перечислимые), которые описывают атрибуты сущности.
3. Объекты могут быть связаны между собой произвольным образом. Связь характеризуется связанными объектами и типом связи. Например, сотрудник фирмы может быть связан с отделом, в котором он работает, связью типа «сотрудник в отделе» и т.п. Связь в определенном смысле аналогична понятию ссылки на таблицу-справочник в традиционной модели БД.
4. Объект может быть хранилищем. В этом случае допускается хранение в нем других объектов (например, товара на складе).
5. Такая БД не привязана к конкретной бизнес-модели и позволяет реализовать «над собой» практически любую бизнес-логику. Логика выделяется в отдельный программный слой и, как правило, реализуется на сервере приложений, где по запросу клиента создаются объекты, загружающие информацию о себе из БД и реализующие «поведение» объектов реального мира. В то же время, в силу однообразности модели хранения, эти объекты довольно легко создаются на основе базовых классов, инкапсулирующих функциональность по загрузке и сохранению свойств и связей в БД.
Таким образом, для организации репозитория требуется пополняемая библиотека классов. Задача создания и поддержки такой библиотеки, а также введения отдельного программного слоя бизнес-логики достаточно трудоёмка и с точки зрения программирования, и с точки зрения проектирования, тем не менее, усилия, затраченные на это, в дальнейшем принесут немало пользы.
• Диаграмма системы управления ресурсами. Система управления ресурсами является неотъемлемой частью АСУП. Она включает в себя системы прогнозирования ресурсоёмкости, снабжения ресурсами и энергией и т. д.
• Диаграмма процессов, связанных с оборудованием.
Диаграмма системы контроля. Конечной целью система контроля является обеспечение высокого и стабильного уровня качества продукции и повышение эффективности производства за счёт слаженной работы всех его подсистем.
Диаграмма процессов, связанных с реализацией продукта и его поддержкой. Рассматриваемое предприятие является звеном в сети аналогичных и, одновременно, самодостаточным образованием. Следовательно, у него должна быть развитая система реализации продукции и поддержки продукции.
Диаграмма подготовки производства. Наиболее важная для настоящего проекта диаграмма высокого уровня - это диаграмма прецедентов системы подготовки производства. Это последняя диаграмма уровня прецедентов. Она состоит собственно из диаграммы АСТПП, диаграммы базы знаний (репозитория) и актёров.
Для диаграмм среднего уровня выделяются
Диаграмма концептуальной модели техпроцесса - служит для иллюстрации концептуальных связей реальных понятий предметной области. На диаграмме концептуальной модели присутствуют два основных понятия: «Техпроцесс» и производное от него «Техпроцесс сверления». В верхней ветви диаграмма содержит отношение абстрактного техпроцесса и его составляющих частей - этапов техпроцесса, состоящих из «Операций»; «Операции» - из «Позиций», «Позиции» - из «Технологических переходов». Для описания конкретного техпроцесса (сверление) его структура несколько упрощена - «Техпроцесс сверления» имеет в своём составе три основных операции: «Позиционирование», «Смена инструмента» и «Режим резания». Также он соотносится с понятиями «Станок» и «Инструмент» для получения информации об имеющемся оборудовании для подбора верных параметров операций (здесь техпроцесс принимается как некая сущность, способная к самоформированию).
• Диаграммы состояний рабочего и оборудования - иллюстрируют поведение объекта в системе. Согласно методологии объектно-ориентированного программирования, всякий объект на протяжении времени его жизни находится в различных состояниях. Простейший пример - окно Windows может находиться в состоянии «активно» или «неактивно». Так и рабочий в контексте системы имеет ряд состояний.
• Диаграмма последовательностей «Заготовка-техпроцесс-рабочий» -служит для демонстрации взаимодействий объектов во времени. Взаимодействие осуществляется с помощью событий, которые могут быть как синхронными, так и асинхронными. При проектировании данной диаграммы мы ограничились использованием синхронных процедурных событий, суть которых состоит в вызове методов одного объекта другим. В диаграмме использована также разновидность синхронных событий, при посылке которых объект сам запускает свой метод.
• Диаграмма прецедентов CAM-системы.
Диаграммы нижнего уровня -
• Диаграмма физических данных БД техпроцессов
• Диаграмма классов CAM-системы
• Диаграмма развёртывания CAM-системы
• Диаграмма компонентов системы визуального проектирования техпроцессов
Они строятся непосредственно перед разработкой программной системы, описывают все необходимые аспекты разработки и служат для генерации скриптов базы данных, а также «каркаса» программы -заголовочных и исходных программных файлов (*.h и *.cpp), в которых прописаны все заголовки и описания классов и проставлены все связи. Скрипты серверного приложения администрирования базы данных достаточно просты в написании, поэтому на этапе создания диаграмм нижнего уровня упоминаются лишь в диаграмме развёртывания системы.
• Диаграмма физических данных БД техпроцессов - моделирует структуру базы данных техпроцессов. Использование нотации иМЬ позволяет на основе этой диаграммы сгенерировать специальную подпрограмму, так называемый «скрипт базы данных», которая позволяет создать базу данных с определёнными нами атрибутами. При разработке сложных баз данных очень важно, чтобы и программисты, и специалисты по базам данных работали в рамках одной нотации. Поэтому и в рамках настоящего проекта очень полезно будет использовать иМЬ, чтобы проиллюстрировать многогранность этой нотации.
• Диаграмма классов САМ-системы - описывает классы, используемые в системе. Ограничимся двумя главными классами: класс техпроцесса (СТесИРгосеББ) и класс элемента техпроцесса (СТРИеш). Класс техпроцесса является листовым, то есть на данном этапе не имеет потомков, а класс элемента техпроцесса -абстрактным базовым, то есть экземпляр (объект) этого класса создать невозможно, но есть классы-потомки этого класса, создание экземпляров (объектов) которых допускается.
• Диаграмма развёртывания САМ-системы. Диаграммы развёртывания очень полезны при проектировании систем с уровнем сложности выше малого. Они позволяют спланировать, как будут размещены в пространстве элементы проектируемой системы, на каких устройствах будут установлены, как будут связаны между собой (вплоть до физических параметров коммуникаций). Строго говоря, для эффективного функционирования проектируемого элемента САМ-системы необходимо пять процессоров. Процессорами в методологии иМЬ называются любые устройства, имеющие некоторую вычислительную мощность. В данном случае это четыре компьютера и один станок с ЧПУ. Файлы, относящиеся к модулю
администрирования базы данных, помещаются на любой сервер сети, имеющий доступ к серверу базы данных и открытый для доступа с рабочих станций сети. Фактически производительность у скрипт-языков на несколько порядков ниже производительности приложений на C++, однако, в отличие от них, скрипты платформеннонезависимы, то есть работают в любой операционной системе. К тому же доступ к базе данных занимает какое-то время, что при определённых условиях почти сравнивает по производительности приложения на C++ и на PHP, так что использование скрипт-языка вполне допустимо в проектируемой нами системе. Серверу HTTP необходимо иметь двухстороннюю цифровую связь с сервером БД по протоколу TCP/IP.
• Диаграмма компонентов системы визуального проектирования техпроцессов. Диаграмма компонентов позволяет правильно расставить связи между компонентами разрабатываемой системы. Компоненты - это файлы, из которых состоит проект. На диаграммах компонентов часто изображают динамически подгружаемые библиотеки (*.dll), дополнительные компоненты Windows (*.ocx) и исполнимые файлы (*.exe), то есть те элементы программных систем, которые имеются в наличии только после компиляции их исходных кодов.
Разработка системы визуального проектирования техпроцессов велась с использованием методологии RAD, то есть присутствовало несколько циклов разработки с распределением задач между группами разработчиков. Это позволяет снизить фактический уровень сложности разработки и повысить оперативность обмена информацией с предметной областью. На каждом этапе разработки ведётся планирование следующего этапа, а также исследования в предметной и программной области с целью оптимизации работы системы и максимального удовлетворения требований предметной области.
Разработанная программная система состоит из двух частей: система визуального проектирования техпроцессов сверления и модуль администрирования базы данных. Система визуального проектирования позволяет создавать техпроцессы сверления, состоящие из операций трёх типов, у которых можно задавать параметры. На выходе системы -формализованный технологический процесс, который может быть использован для генерации технологической, экономической и пр. документации. Программа поддерживает сохранение формализованных техпроцессов в базу и на диск и открытие их из базы и с диска. Модуль администрирования -позволяет просматривать базу и удалять техпроцессы из неё.
Всё это обеспечение включено в инсталляционный комплект, который также производит установку на компьютер HTTP-сервера Apache, языка PHP /8/ , СУБД MySQL /9/ и драйвера MyODBC последних (на момент завершения проекта) версий.
Список литературы
1 Зиндер Е.З. Бизнес-реинжиниринг и технологии системного проектирования. Учебное пособие. - М., Центр Информационных технологий, 1996
2 Международные стандарты, поддерживающие жизненный цикл программных средств. - М., МП «Экономика», 1996
3 Дэвид А. Марка. Методология структурного анализа и проектирования. /Дэвид А. Марка, Клемент МакГоуэн/ - Электронная версия.
4 Крег Ларман. Применение UML и шаблонов проектирования. - СПб., Питер-пресс. 2001
5 Inside the Unified Modeling Language. Rational Corp., ® 2000
6 Илларионов И.В. «Проектирование иерархической структуры классов для систем механообработки при проектировании системы управления качеством продукции» / Новые информационные технологии: материалы
четвёртого научно-практического семинара. /Муранов В. А., Илларионов И.В./ -Моск. гос. ин-т электроники и математики. М., 2000. стр. 220-230
7 Илларионов И.В. «Информационное моделирование процессов механической обработки» / Новые информационные технологии: материалы пятого научно-практического семинара. /Муранов В.А., Илларионов И.В., Старов В.Н./ - Моск. гос. ин-т электроники и математики. М., 2001. стр. 180-191
8 Хьюгс Стерлинг. PHP: руководство разработчика. / Хьюгс Стерлинг, Андрей Змиевски/ - К:. «ДиаСофт». 2001 ю - 384 с.
9 David Axmark. MySQL reference manual. David Axmark, Michael (Monty) Widenius, Paul DuBois, Kim Aldale
