CC BY
43
6
ТЕХНОЛОГИИ ПРИБОРОСТРОЕНИЯ
ПРИМЕНЕНИЕ UP ДЛЯ ПРОЕКТИРОВАНИЯ ПОДСИСТЕМ ТПП Д.Д. Куликов
В работе рассмотрена методология автоматизации технологической подготовки на базе «унифицированного процесса» (Unified Process - UP). Проектирование подсистем ТПП представлено как итеративный процесс, имеющий свои фазы и вехи. Для каждой фазы рассмотрены основные рабочие процессы, на основе которых сформулирована стратегия автоматизации ТПП.
Введение
Совершенствование технологической подготовки производства (ТПП) - это сложный и продолжительный во времени процесс. Поэтому необходимо иметь эффективную методику и инструментальные средства для разработки автоматизированных подсистем ТПП. Следовательно, имеет смысл говорить о некоторой метасистеме как надстройке над АСТПП, с помощью которой выполняется проектирование самой АСТПП. Такую метасистему назовем «Системой проектирования технологической подготовки производства» (СП ТПП). Так как процесс совершенствования ТПП носит итерационный характер и СП ТПП будет неоднократно использоваться, то целесообразно включить ее в состав АСТПП как подсистему. Необходимость и возможность такого подхода показана в работе [2]. В этой работе выделены целевые и собственные функции АСТПП, и в состав ее собственных функций включена функция «Проектирование и настройка программных систем». СП ТПП создается на основе использования концепций CALS, должна быть интегрирована с другими подсистемами АСТПП и функционировать под управлением PDM-системы в рамках единого информационного пространства [1].
С помощью СП ТПП реализуется заданная стратегия развития АСТПП. Стратегия развития АСТПП представляет собой способ организации жизненного цикла подсистем ТПП. От выбранной стратегии во многом зависит эффективность функционирования подсистем ТПП. В настоящее время при разработке сложных программных систем наибольшее применение получают подходы, основанные на объектно-ориентированном анализе и проектировании программных комплексов. Эти подходы пришли взамен каскадных и спиральных моделей проектирования программных систем. Одной из наиболее перспективных в настоящее время считается методология, основанная на использовании «унифицированного процесса» (Unified Process - UP). Под UP понимается формализованная технология разработки сложных программных систем, использующая универсальный язык моделирования UML [3]. Наиболее законченный вид эта методология нашла в унифицированном процессе компании Rational Software Corporation (Rational Unified Process - RUP), важной особенностью которого является, помимо большого набора справочных пособий и шаблонов для основных артефактов, наличие инструментария (Rational Suite) для эффективного проектирования сложных программных систем.
На наш взгляд, стратегия, основанная на UP, в наибольшей степени соответствует предлагаемой концепции создания АСТПП, так как позволяет достаточно быстро проектировать работоспособные варианты подсистем ТПП и запускать их в эксплуатацию. Поэтому в данной работе рассмотрена методика применения UP для разработки подсистем ТПП.
Содержание
Унифицированный процесс является развитием спиральной модели Боэма, и разработка программной системы в этой идеологии организуется в виде эволюционно-инкрементного жизненного цикла (рис. 1). Эволюционная составляющая цикла основывается на доопределении требований в ходе проектирования, инкрементная составляющая - на планомерном приращении реализации требований или, другими словами, на пошаговом наращивании возможностей (incremental) системы.
Как показано на рис.1, при выполнении итерации выполняется управление рисками. Наиболее важными рисками являются следующие:
• несвоевременное выполнение этапа работ;
• превышение бюджета, отведенного на этап;
• результаты выполнения этапа не отвечают требованиям заинтересованных сторон.
Рис.1. Итеративный и инкрементный процесс разработки подсистем ТПП
После выделения самых опасных рисков организуется планирование и выполнение действий по созданию системы, которые закреплены за данной итерацией. По завершению итерации производится оценка результатов выполнения этой итерации. В случае неудовлетворительных результатов пересматривается план проекта, и итерация повторяется. Таким образом, работа с рисками - выделение самых опасных рисков, определение способов их устранения, регулярный пересмотр рисков - является важной составной частью иР, необходимой для успешного завершения проекта.
В соответствии с этой методологией создание автоматизированной подсистемы ТПП рассматривается как процесс, жизненный цикл которого проходит определенные фазы, причем в каждой фазе возможны итерации, связанные с переходом фазы в новое состояние (рис. 2). Результатом итерации является инкремент, который представляет собой версию системы с дополнительными или усовершенствованными функциональными возможностями по сравнению с предыдущей версией. В свою очередь, каждая фаза завершается вехой, отражающей результаты выполнения фазы. Вехи дают руководителям возможность провести анализ и принять нужные решения перед тем, как работа перейдет на следующую фазу. В частности, отслеживая время и усилия, затраченные на очередную фазу, руководство корректирует планы и ресурсы, необходимые для выполнения следующих фаз.
Важной особенностью процесса проектирования АСТПП является то обстоятельство, что ввиду сложности подсистем ТПП в начале их создания известны не все требования, поэтому их дополнение и изменение осуществляется на всех итерациях жизненного цикла. Между фазами и этапами ТПП может быть проведено следующее
соответствие. Фазе «Исследования» соответствуют этапы предпроектного анализа ТПП и разработки технического задания, фазе «Уточнение» - этапы технического проекта, фазе «Построение» - этап рабочего проекта, а фазе «Развертывание» - этапы, связанные с внедрением и эксплуатацие подсистем ТПП.
Исследование Уточнение Построение Развертывание
Итерация 1
Итерация 2
Итерация х
Итерация х+1
Итерация у
Итерация у+1
Итерация ъ
Время Вехи
Цели жизненного Архитектура Первоначальная Выпуск
цикла жизненного работоспособность продукта
цикла
Рис. 2. Фазы, итерации и вехи жизненного цикла подсистем ТПП
В структуре иР выделяют два измерения: горизонтальная ось представляет время и демонстрирует прохождение по фазам жизненного цикла проектов подсистем ТПП; вертикальная ось представляет рабочие потоки, которые являются логическими группировками действий.
Рис. 3. Структура унифицированного процесса в двух измерениях
Как видно из рис. 3, первое измерение представляет динамическую сторону процесса, выражаемую через фазы, итерации и вехи. Второе измерение представляет статическую сторону процесса - его описание через компоненты процесса: управление требованиями; анализ; проектирование; реализация; тестирование.
Кривые приближенно изображают (их не следует воспринимать слишком буквально) объемы рабочих процессов, выполняемых в каждой из фаз. Каждая фаза, как было показано выше, дополнительно разделяется на итерации (мини-проекты). Таким образом, процесс анализа и проектирования можно представить как поуровневый спуск от наиболее общих моделей и представлений концептуального уровня к более частным и детальным представлениям логического и физического уровня. При этом на каждой итерации модели последовательно дополняются все большим количеством деталей, что позволяет им более адекватно отражать различные аспекты конкретной реализации подсистемы ТПП.
Одним из принципов построения моделей сложных систем является принцип мно-гомодельности: никакая единственная модель не может с достаточной степенью адекватности описывать различные аспекты сложной системы. Это означает, что достаточно полная модель сложной системы допускает некоторое число взаимосвязанных представлений (см. рис. 4).
Указанные представления фиксируются с помощью комплекса моделей, выражаемых с помощью комплекса диаграмм ЦМЬ. В этот комплекс входят диаграммы прецедентов, деятельности, последовательностей, вариантов использования, классов,. состояний, коопераций, компонентов, развертывания.
Логическое представление
(конечный пользователь)
Внешние и внутренние структурные отношения
Представление реализации
(программист)
Отношения между компонентами
программного обеспечения
Модель ТПП
Представление Представление
процесса размещения
функциони рования компонентов
(системный интегратор) (системный администратор)
Производительность и Топология взаимосвязей и
масштабируемость Коммуникаций компонентов
компонентов системы системы
V V
Концептуальная модель ТПП Физическая модель ТПП
У
Статическая модель ТПП
V Динамическая модель ТПП
Рис. 4. Общая схема взаимосвязей моделей и представлений в ТПП
Заложенные в языке ЦМЬ потенциальные возможности могут быть использованы не только для объектно-ориентированного моделирования систем, но и для представления знаний в интеллектуальных системах, которыми, по существу, станут перспективные сложные подсистемы ТПП [4].
Рассмотрим в первом приближении применение ЦР при проектировании какой-либо подсистемы ТПП. Проектирование начинается с фазы «Исследование». В этой фазе в первую очередь выполняется процесс «Требования». Целью выполнения этого процесса является анализ предметной области и выявление требований к проектируемой
подсистеме ТПП. Этому процессу в стандартах ЕСТПП соответствует стадия предпро-ектного анализа ТПП.
Необходимость предпроектного анализа вызвана тем обстоятельством, что технологическая подготовка изделий на каждом предприятии имеет свои особенности. Поэтому подсистемы ТПП каждого предприятия являются уникальными, хотя и реализованы на базе общих принципов, зафиксированных в соответствующих стандартах ЕСТПП, ЕСКД, ЕСТД и т. д.
Применительно к ТПП процесс предметную область целесообразно моделировать в виде диаграмм IDEF0. Выбор стандарта IDEF0 вызван тем, что методология SADT, положенная в основу IDEF0, получила широкое применение в мире для функционального моделирования бизнес-процессов и поэтому была закреплена в ряде международных и государственных стандартов. В качестве инструментальных средств для моделирования ТПП может быть использован пакет Platinum BPwin 4.0 фирмы Computer Associater или Design/IDEF фирмы Meta Software. В первой части «Анализ ТПП» рабочей операции «Требования» (фаза «Исследование») в первую очередь составляются диаграммы IDEF0.
В диаграмме первого уровня (контекстной диаграммы IDEF0) фиксируются все подсистемы ТПП. В соответствии с поставленной целью на диаграммах следующих уровней фиксируются лишь функциональные блоки, связанные с проектированием и утверждением комплекта технологических документов. Важно правильно выбрать глубину и ширину детализации. Уровень детализации должен быть выдержан ровно настолько, насколько это необходимо для того, чтобы разобраться в процессе получения технологических документов. Документирование ситуации, сложившейся к определенному моменту (модели «как есть» - «as is») необходимо для создания на следующих фазах моделей «как должно быть» (модели «to be»).
При выполнении бизнес-моделирования в первую очередь, как было показано выше, анализируются функции, задачи и процедуры ТПП и создаются диаграммы прецедентов и диаграммы деятельности. На базе этих диаграмм проектируется концептуальная модель предметной области существующей ТПП.
На основе анализа выполняется вторая часть - «Определение требований» - рабочей операции «Требования». В этой части необходимыми являются следующие виды деятельности.
• Сформулировать область действия проекта, т.е. зафиксировать среду, важнейшие требования и ограничения с тем, чтобы к завершению проекта можно было получить критерии приемлемости.
• Спланировать и подготовить бизнес-план, а также оценить альтернативы для управления рисками, кадрового обеспечения, плана проекта и выбора компромисса между ценой, графиком работ и рентабельностью.
• Спроектировать возможную архитектуру, оценить компромиссы в проекте и определиться, какие компоненты будут создаваться, какие - покупаться, а какие - использоваться повторно, с тем, чтобы оценить стоимость, ресурсы и график работ.
Главным результатом этой части является техническое задание на выполнение проекта. В техническом задании фиксируется первая из основных вех - веха цели жизненного цикла. Необходимо отметить, что приведенная в ТЗ оценка ресурсов, требуемых для реализации всего проекта, должна рассматриваться как весьма приблизительная, «интуитивная». Эта оценка будет корректироваться при последующих фазах и итерациях, и с каждой такой итерацией она будет точнее.
Следующая фаза «Уточнение» примерно соответствует разработке технического проекта по стандартам ЕСТПП. Целью фазы является установление архитектуры создаваемой подсистемы, разработка плана проекта и исключение из проекта элементов наибольшего риска. Для достижения этого требуется осмотреть систему «на километр в
ширину, на сантиметр в глубину». Данная фаза является самой критичной фазой проекта. После ее завершения наступает важнейший момент принятия решения: стоит ли реа-лизовывать фазы построения и развертывания. Фаза соответствует переходу от мобильной, гибкой работы с низким уровнем риска к более дорогой и рискованной работе.
В фазе «Уточнение» за одну или несколько итераций (это зависит от области действия, размера, риска и новизны проекта) создается выполнимый архитектурный прототип подсистемы ТПП. Эта работа, как минимум, должна дать критические прецеденты, определенные в фазе исследования; обычно они показывают основные технические риски проекта. В фазе «Уточнение» необходимыми являются следующие виды деятельности:
• тщательная разработка видения и установление четкого понимания наиболее критичных прецедентов, направляющих архитектурные и проектные решения;
• тщательная разработка процесса, инфраструктуры и среды разработки, а также согласование процесса, инструментальных средств и автоматизированной поддержки;
• разработка архитектуры и выбор компонентов; оценка потенциальных компонентов для последующего определения стоимости и графика работ фазы «Построение».
Фаза «Уточнение» плана заканчивается второй важной вехой архитектуры жизненного цикла. В этот момент исследуется область действия системы, конкретизируются цели, а также осуществляется выбор архитектуры и способов разрешения важнейших рисков.
Во время фазы «Построение» все оставшиеся компоненты и функции приложений разрабатываются и интегрируются в окончательный продукт; кроме того, все функции проходят тщательное тестирование. На выходе этой фазы получаем продукт, готовый к передаче конечному пользователю. Он включает, как минимум, следующее: программный продукт, реализуемый на соответствующей платформе; комплект эксплуатационной документации; описание текущей версии.
Фаза построения завершается третьей основной вехой проекта - вехой первоначальной работоспособности. В этот момент принимается решение, готовы ли к активной работе программное обеспечение, узлы и пользователи и не подвергнуты ли они высоким рискам. Такая версия продукта обычно называется бета-версией. Если проект не сможет пройти эту веху, то фазу развертывания, вероятно, придется отсрочить на одну версию.
Целью фазы «Развертывание» является передача программного продукта подразделениям ТПП и начальная эксплуатация подсистемы (этап опытно-промышленной эксплуатации подсистемы по стандартам ЕСТПП). Данная фаза включает следующее.
• бета-тестирование, позволяющее убедиться, что новая система соответствует ожиданиям пользователя;
• параллельное функционирование с существующей системой, которую должна заменить разрабатываемая;
• перекодирование эксплуатационных баз данных;
• подготовка пользователей и персонала поддержки.
В фазе развертывания акцент делается на видах деятельности, необходимых для передачи программного обеспечения в руки пользователей. Как правило, эта фаза включает несколько итераций, в том числе выпуск бета-версий, а также корректирующих и модернизирующих версий. Эта конечная точка жизненного цикла может совпадать с начальной точкой следующего цикла, вызывая «рождение» нового поколения или версии подсистемы ТПП. Фаза «Развертывание» завершается четвертой важнейшей вехой проекта - вехой выпуска продукта. В этот момент принимается решение, достигнуты ли поставленные цели и стоит ли начинать еще один цикл разработки.
Таким образом, рассмотренная методология разработки программных систем позволяет осуществить современный подход к созданию подсистем ТПП и обеспечить необходимое качество программных продуктов.
Возможны два принципиально различных подхода к автоматизации ТПП и соответствующие им стратегии автоматизации ТПП. Первый подход, который можно назвать «сначала вширь, а затем вглубь», основан на автоматизации максимально возможного количества рабочих мест в ТПП при минимальном уровне автоматизации решаемых на них задач. Под минимальным уровнем понимается решения задач с использованием текстовых и графических редакторов, с последующей записью полученных документов в электронный архив.
Второй подход, который можно назвать «сначала вглубь, а затем вширь» основан на высокой автоматизации отдельных подсистем ТПП, причем автоматизация осуществляется последовательно - подсистема за подсистемой.
Первый подход, на наш взгляд, является предпочтительней, так как позволяет:
• организовать единое информационное пространство;
• на базе ЕИП организовать интеграцию между подсистемами ТПП, а также между подсистемами ТПП и АСУ предприятия;
• осуществлять эффективное управление ТПП на основе использования PDM-системы;
• организовать автоматизированный контроль процесса подготовки изделий к производству на основе технологии «workflow».
Заключение
Стратегию автоматизации ТПП целесообразно организовать на основе «сначала вширь, а затем вглубь» с использованием инструментальных средств СП ТПП. Такая стратегия даст возможность создать единое информационное пространство и реализовать функционирование подсистем ТПП под управлением PDM-системы при минимальном начальном уровне автоматизации рабочих мест.
Литература
1. Куликов Д. Д., Яблочников Е.И. Методологические аспекты автоматизации технологической подготовки производства. // Вестник компьютерных и информационных технологий. 2004. №4. С. 35-42.
2. Технологическая подготовка гибких производственных систем. / С.П. Митрофанов, Д. Д. Куликов, О.Н. Миляев, Б.С. Падун. Л.: Машиностроение: Ленингр. отд-ние, 1987. 352 с.
3. Буч Г., Рамбо Дж., Джекобсон А. Язык UML. Руководство пользователя. Пер. с англ. М.: ДМК, 2000. 432 с.
4. Яблочников Е.И. Построение функциональных моделей процессов технологической подготовки производства с применением диаграмм UML // Инновации в науке, образовании и производстве. Труды СПбГПУ. № 488. СПб: Изд-во СПбГПУ, 2004. С. 221-227.
