Подходы к разработке системы автоматизированного выпуска текстовой конструкторской документации

Тип работы:
Реферат
Предмет:
ТЕХНИЧЕСКИЕ НАУКИ


Узнать стоимость новой

Детальная информация о работе

Выдержка из работы

УДК 658. 5
ПОДХОДЫ К РАЗРАБОТКЕ СИСТЕМЫ АВТОМАТИЗИРОВАННОГО ВЫПУСКА ТЕКСТОВОЙ КОНСТРУКТОРСКОЙ ДОКУМЕНТАЦИИ
А.В. Сумцов
На основе обзора существующих программных средств формирования текстовой документации обоснована необходимость создания системы с модульной структурой, которая позволит без реструктуризации расширять свою функциональность и совместимость для решения специфических задач. С учетом сформулированных требований предложены подходы к разработке системы автоматизированного выпуска текстовой документации «Автодок». Ключевые слова: система автоматизированного выпуска документации, модульная структура, база данных, конструкторская документация, выпуск, формирование, анализ, оптимизация, подход.
Введение
Основным назначением разрабатываемой системы «Автодок» является автоматизация выпуска текстовых документов (ТД). Их внешний вид определяется шаблонами оформления, а содержание формируется на основе информации из базы данных (БД). Под текстовым документом в настоящей работе будем также понимать документ и со смешанным содержимым — текстом и статической графикой, созданной при помощи стороннего программного обеспечения (ПО). Для обоснования необходимости проведения работ по созданию новой системы проведем краткий обзор аналогичных средств выпуска ТД.
Известны системы Catia (разработка компании Dassault Systemes) и Creo Elements (Parametric Technology Corp.). В них номенклатура документации, формируемой автоматизированным путем, ограничивается инженерной спецификацией на изделие [1, 2]. Система автоматизированного проектирования (САПР) NX дополнительно обеспечивает возможность составления ведомостей и перечней покупных изделий [3]. Но в перечисленных пакетах перечень элементов заимствуется из структуры трехмерной модели. Таким образом, выпуск документации на изделие, для которого необходимость наличия модели отсутствует (например, комплекты запасных частей или соединителей), является нерентабельным.
Дополнительный набор функциональности, связанной с выпуском ТД, представляет система T-Flex DOCs — разработка российской компании Топ Системы [4]. Все ее компоненты функционируют на основе единой информационной платформы технического документооборота и ведения состава изделия. Набор шаблонов формируемой документации, характерный ранее рассмотренным системам, дополняется функцией формирования на основе электронной структуры изделия (ЭСИ) различных видов отчетов, технологических карт и ведомостей.
Как показывает проведенный обзор, некоторые из представленных на рынке САПР тесно связывают процесс выпуска документации со структурой модели изделия и не подходят для разработок, которые не требуют трехмерного прототипирования. Другие, в частности, T-Flex DOCs, используют для этих задач ЭСИ и не подходят для условий, когда информация об элементах находится в произвольной БД, не связанной с системой управления жизненным циклом изделия (PLM-системой). Кроме того, рассмотренные САПР не обладают возможностью комплектного формирования документации (комплекты кабельных частей соединителей (КЧС), запасных частей, инструментов и принадлежностей (ЗИП)), т. е. они не обеспечивают решение специфических задач, характерных для рабочих процессов различных предприятий.
Из изложенного следует вывод о необходимости создания системы с модульной структурой, обладающей возможностью расширения функциональности и области интегрирования. Сформулируем требования к ней более подробно.
Требования к системе
В основу модульной структуры заложены основная программная составляющая (ядро) и динамически подключаемые модули. Обмен данными между конкретным источником (трехмерная модель, ЭСИ или произвольная БД) и системой обеспечивается модулем интеграции. Функциональный модуль решает задачу расширения ее возможностей.
Современные тенденции развития системных сред диктуют требования кроссплатформенной архитектуры проектируемого ПО. Таким образом, система становится более универсальной и позволяет решать специфические задачи, характерные для различных предприятий. Отметим, что функции, выполняемые проектируемой системой «Автодок», не предусматривают формирования конструкторской документации параметрически зависимого (на основе переменных данных) графического содержания — различных видов чертежей, схем и т. п.
Исходя из результатов обзора современных САПР и учитывая выделенные требования, сформулирована цель работы — создать систему выпуска ТД, обладающую следующими особенностями. 1. Модульная структура, позволяющая:
— расширять перечень автоматически формируемых документов, а также добавлять правила генерации их комплектов посредством подключения функциональных модулей, обеспечивающих специфику пользовательского интерфейса для выполняемых задач-
— расширять перечень систем управления данными, с которыми разрабатываемое ПО взаимодействует в части импорта исходной информации. В случае интеграции с различными PLM-системами появляется возможность дополнить цикл выпуска документации этапами, обеспечивающими процесс ее согласования и сдачи в архив. 2. Кроссплатформенная архитектура, обеспечивающая работу ПО в любой системной среде с предустановленной Java Runtime Environment.
Ключевое отличие проектируемой системы «Автодок» от аналогов — ее модульная структура и, как следствие, универсальность, необходимая для решения специфических задач. Объектами автоматизации в проектируемой системе являются процессы формирования комплектов документации на комплекты КЧС и комплекты ЗИП.
Задача, решение которой необходимо для достижения поставленной цели, состоит в поиске наиболее рациональных подходов к проектированию системы автоматизированного выпуска ТД. На этапе формулирования требований к ПО и последующей их реализации является целесообразным построение модели системы. Опишем подходы, позволяющие сформировать наглядное визуальное и, одновременно, детальное ее представление, а также сокращающие затраты на проектирование и построение сложной модели данных.
Построение графической UML-модели и конкретизация функциональных возможностей системы
Последовательная разработка ПО содержит следующие основные этапы: анализ требований к будущей системе, ее реализация, тестирование и развертывание [5−7]. Преимущество такого подхода состоит в простоте процесса проектирования, а недостаток — в отсутствии реверсивности (возможности возврата на ранее пройденные этапы). По этой причине перед разработчиками встает довольно трудоемкая задача по формированию полного перечня требований к системе на начальном этапе ее создания [8], которую на практике удается решить лишь на 80% [9]. Для реализации оставшихся 20% возможностей после выпуска первой версии ПО часто требуется полная переработка приложения с его реструктуризацией. Можно заключить, что последовательный процесс не приемлем для организации проектирования сложных систем с большим количеством элементов и их высокой степенью связности. В связи с этим для разработки ПО автоматизированной системы был выбран подход, использующий графическое описание модели при помощи унифицированного языка моделирования UML (Unified Modeling Language). Визуальным моделированием называется процесс графического представления модели при помощи некоторого стандартного набора элементов. Стандартизация необходима для реализации одного из ключевых преимуществ подхода — гибкости, которую он привносит в процесс разработки. Кроме того, объектно-ориентированная технология имеет итеративный и инкрементальный характер и заключается в периодичном прохождении всех этапов создания системы с ее последовательным уточнением [10, 11].
Взаимодействие пользователя с объектами системы формирует некоторые сценарии работы, для представления которых в нотации UML предназначена диаграмма вариантов использования (use case diagram). Она разрабатывается на этапе анализа и определяет конкретные функциональные возможности будущего ПО.
На рис. 1 представлена диаграмма вариантов использования, являющаяся составной частью графической UML-модели системы «Автодок». «Актеры» — это объекты, взаимодействующие с системой («Разработчик», «Источник данных» и т. п.), варианты использования — сценарии, посредством которых происходят все внутренние и внешние взаимодействия («управлять сундуками», «добавить шаблон» и др.). С помощью специальных видов связей (стрелка с белым треугольником) изображаются правила наследования элементами определенных возможностей. Например, формировать комплекты ЗИП и КЧС могут оба типа пользователей. Сообщить о сбое системы может только разработчик (администратор в этом не испытывает необходимости). В свою очередь, только администратор может добавить или удалить шаблон оформления. Прямоугольный контур графически обозначает функциональный набор системы.
Ввиду ограниченности человеческих возможностей (таких как память, концентрация внимания и т. п.) трудоемкость проектирования пропорциональна сложности систем. Для ее снижения составляется модель. Предложенный подход использует в качестве нотации язык UML, реализующий объектно-ориентированную технологию, которая имеет следующие особенности:
— упрощает процесс поэтапной детализации модели-
— представляет удобные для восприятия диаграммы, упрощающие обмен информацией между участниками проекта-
— мотивирует разработчика определиться с перечнем ее конкретных функциональных возможностей.
Выбор инструмента для работы с языком визуального моделирования относится, скорее, к области личных предпочтений проектировщика.
Графическая модель позволяет формализовать функциональные возможности сколь угодно сложной системы. Однако объем работ по моделированию может быть уменьшен путем оптимизации структуры объектов автоматизации.
Рис. 1. Диаграмма вариантов использования автоматизированной системы Анализ и оптимизация структуры комплектов ЗИП и КЧС
Автоматизация процесса выпуска документации предполагает формирование структурированного пакета ТД, вид и состав которых регламентируется международными, государственными стандартами и внутренними руководящими документами предприятий.
До оптимизации в состав электронной структуры комплекта КЧС (рис. 2) (в общем случае, ЭСИ) для каждого соединителя входил свой сборочный чертеж. Поскольку проектируемая система не решает задачи параметрического формирования изображений, ЭСИ была подвергнута анализу, который выявил способ унификации данных о сборочных единицах.
Комплект кабельных частей соединителей
Прибор 1 1
-Соединитель 1 |- Спецификация ^ Сборочный чертеж
— Соединитель 2 Ь Спецификация '--Сборочный чертеж
— Соединитель М Ь Спецификация '--Сборочный чертеж
'--Ярлык
Прибор 2 1
-Соединитель 1 |- Спецификация '--Сборочный чертеж
— Соединитель 2 I- Спецификация '--Сборочный чертеж
— Соединитель N Ь Спецификация '--Сборочный чертеж
'--Ярлык
Прибор 1_
— Соединитель 1 Ь Спецификация ^ Сборочный чертеж
— Соединитель 2 Ь Спецификация ^ Сборочный чертеж
— Соединитель К Ь Спецификация '--Сборочный чертеж
'--Ярлык
Рис. 2. Фрагмент электронной структуры комплекта конструкторской документации
Выявление конструктивных особенностей и проведение классификации применяемых соединителей позволило описать все сборочные единицы определенного типа соответствующей таблицей комплектования. Это исключило задачу динамического формирования сборочного чертежа, который был заменен типовой инструкцией по сборке и маркировке. Унифицированная ЭСИ (рис. 3) позволяет подготовить необходимые шаблоны и организовать процесс автоматизированного выпуска комплекта документации [12].
Комплект кабельных частей соединителей
-Этикетка
¦Таблицы комплектования -Таблица упаковывания
-Типовая инструкция по сборке и маркировке ¦Единая инструкция по упаковыванию -Ярлык
Рис. 3. Унифицированная электронная структура комплекта конструкторской документации
Итак, предложенный подход к проектированию для разрабатываемой системы «Автодок» позволяет не столько оптимизировать, сколько сделать возможным решение задачи автоматизированного выпуска ТД без параметрического формирования чертежей. В общем случае его суть заключается в проведении анализа и последующей унификации ЭСИ, что позволяет существенно сократить затраты на составление алгоритмов и шаблонов представления на этапе проектирования системы, а также на ее расширение в будущем.
Как было сказано ранее, UML-модель обеспечивает разработчика преимуществами итеративного процесса проектирования. Наиболее значимое из них — возможность вносить изменения на любых этапах без существенной реструктуризации разработки. Для снижения затрат на реализацию подобных изменений был разработан и применен подход, который обеспечил простоту масштабируемости модели данных, что позволило абстрагироваться от специфики организации определенной PLM-системы.
Многоуровневая зависимость в сложных наборах данных
Создавая Б Д для хранения больших объемов сложно организованной информации, на первых этапах невозможно сразу построить ее точную и полную структуру. Вместо этого можно увеличить степень ее универсальности, используя ключевое преимущество реляционной модели данных — возможность применения формального аппарата алгебры отношений и реляционного исчисления для обработки информации [13].
На рис. 4 схематично представлен фрагмент реляционной модели данных для разрабатываемой системы «Автодок». Используются следующие условные обозначения и сокращения: названия первичных ключей выделены подчеркиванием и полужирным начертанием, обязательные поля выделены полужирным начертанием, необязательные поля оформлены регулярным начертанием- ID (Identifier) — идентификатор записи, PK (Primary Key) — первичный ключ, FK (Foreign Key) — внешний ключ. В левой колонке каждого блока указан тип поля (РК или FK).
Atlnbute Definition
PK IQ
ЫЛМЕ TYPE
Attribute
PK ID
FKI FK1, FK3,FK4 DEFJD OBJECT ID VALUE
Object
PK ID
NAME
NUMBER
VERSION
IS LATEST
Object ToObjectL ink
PK Ю
FK2 ROLE A
FK1 ROLE В
LINK CLASS

Рис. 4. Фрагмент реляционной модели данных системы
В разрабатываемой системе «Автодок» основной информационной единицей является деталь (соединитель, комплектующая часть для него или принадлежность комплекта ЗИП), характеристика которой содержится в таблице Object. Но в ней указываются лишь общие для всех записей атрибуты (Name, Number, Version, Is_latest), остальные выносятся в отдельные таблицы (Attribute и AtributeDefenition). Сущность подхода состоит в использовании многоуровневой зависимости данных. Таблица Object содержит основной набор свойств, описывающих объект- наборы дополнительных свойств, которые могут отличаться от объекта к объекту, хранятся в отдельной таблице Attribute. В свою очередь, таблица Attribute хранит в себе лишь базовые поля, описывающие конкретное свойство объекта- остальные содержатся в отдельной таблице AttributeDefinition. Таким образом, строится многоуровневая зависимость таблиц, придающая модели данных необходимую гибкость. Обеспечивается возможность изменять объекты, доопределяя их различными специфическими свойствами.
Представленный подход к проектированию сложных наборов данных, использующий многоуровневые зависимости между таблицами, позволяет добиться гибкой спецификации не только самих объектов, но также и их свойств. Его применение для разрабатываемой системы обеспечило простоту процесса масштабирования модели данных, что, в свою очередь, позволило абстрагироваться от специфики организации конкретной PLM-системы.
Заключение
Предложены следующие подходы, апробированные в процессе разработки системы автоматизированного выпуска текстовой документации «Автодок»:
— графическое UML-моделирование, упрощающее процесс проработки модульной архитектуры системы и позволяющее учитывать возникающие на различных этапах ее проектирования требования-
— анализ и оптимизация структуры объектов автоматизации, позволяющие исключить параметрическое формирование чертежей, которое не входит в сферу решаемых системой задач, а также сократить затраты на создание шаблонов оформления-
— многоуровневые зависимости между таблицами, обеспечивающие простоту масштабируемости модели данных системы, и, как следствие, исключающие специфику обмена информацией с конкретной PLM-системой.
Для сокращения затрат на проектирование целесообразно проведение анализа структуры объекта автоматизации и, при необходимости, ее унификация. Сложную структуру и поведение системы, реализация которой требует тщательного планирования и аннотирования, рекомендуется описывать при помощи модели. Использование для этих целей унифицированного языка моделирования UML обеспечивает разработчиков удобствами объектно-ориентированного процесса проектирования. Для обеспечения гибкости модели данных и снижения затрат на расширение функциональности системы могут использоваться многоуровневые зависимости между таблицами. Предложенные подходы позволяют создать надежное программное обеспечение и снизить издержки на его реализацию.
Проект является лауреатом программы «Участник молодежного научно-инновационного конкурса 2010» (проект № У-2010−2/14 «Автоматизация», № 12 649).
Литература
1. Орлов Д. А., Крутов В. Н., Треяль В. А., Смирнов А. А. CREO — новое поколение САПР для машиностроения // Инструмент и технологии. — 2011. — № 31. — Вып. 1. — С. 50−54.
2. Басов К. А. CATIA V5. Геометрическое моделирование. — СПб: Питер, 2008. — 272 с.
3. Гончаров П. С., Ельцов М. Ю., Коршиков С. Б., Лаптев И. В., Осиюк В. А. NX для конструктора-машиностроителя. — М.: ДМК-Пресс, 2010. — 504 с.
4. Бунаков П. Ю. Сквозное проектирование в T-FLEX. — М.: ДМК-Пресс, 2009. — 396 с.
5. Арлоу Д., Нейштадт А. UML 2 и Унифицированный процесс. Практический объектно-ориентированный анализ и проектирование: Пер. с англ. — 2-е изд. — СПб: Символ-Плюс, 2007. — 624 с.
6. Гатчин Ю. А., Крылов Б. А. Концептуальное и инфологическое моделирование проектно-конструкторских задач в интегрированных САПР // Всероссийский научно-технический журнал «Проектирование и технология электронных средств». — Владимир, 2001. — № 4. — С. 32−34.
7. Гатчин Ю. А., Донецкая Ю. В. Разработка методик для автоматизации проектирования изделий приборостроения // Труды конгресса по интеллектуальным системам и информационным технологиям «AIS-AT'-09». — Научное издание в 4-х томах. — М.: Физматлит, 2009. — Т. 3. — С. 145−149.
8. Соммервилл И. Инженерия программного обеспечения: Пер. с англ. — 6-е изд. — М.: Вильямс, 2002. -624 с.
9. Фаулер М., Скотт К. UML. Основы: Пер. с англ. — СПб: Символ-Плюс, 2002. — 192 с.
10. Боггс У., Боггс М. UML и Rational Rose: Пер. с англ. — М.: Лори, 2004. — 583 с.
11. Кватрани Т. Rational Rose 2000 и UML. Визуальное моделирование: Пер. с англ. — М.: ДМК-Пресс, 2001. — 176 с.
12. Сумцов А. В., Черкас Д. А. Автоматизация процесса разработки комплектов конструкторской документации // Материалы докладов XII конференции молодых ученых «Навигация и управление движением». — СПб: ГНЦ РФ ОАО «Концерн «ЦНИИ «Электроприбор», 2010. — 408 с.
13. Teorey Т., Lightstone S., Nadeau T. Database Modeling & amp- Design: Logical Design. Fourth Edition. — USA: Elsevier, 2006. — 275 p.
Сумцов Андрей Владимирович — Санкт-Петербургский национальный исследовательский университет информационных технологий, механики и оптики, аспирант, felix2k@tut. by

Показать Свернуть
Заполнить форму текущей работой