М. Б. Гузаиров, В.В. Мартынов, В. И. Рыков
Уфимский государственный авиационный технический университет
В статье описывается концепция управления содержательной составляющей научных программ и процесса обучения специалистов в области CALS (ИПИ) технологий. В ее основе лежит принцип инструментального управления информационными процессами в рамках объектного подхода. Концепция реализована в методологии средств управления проектами Rational Unified Process (RUP) фирмы IBM Rational. Используется набор программных средств, поддерживающих указанную методологию.
Задачей CALS является обеспечение информационного обмена между процессами, реализующими жизненный цикл (ЖЦ) продукции. Каждый из этапов ЖЦ сложной наукоемкой продукции имеет специфический набор операций и тезаурус, которые отражают профессиональные (социальные, технические, технологические и т. д.) особенности конкретной профессиональной среды. На многих этапах ЖЦ указанной продукции используются специализированные программные и программно-технические комплексы (CAD/CAM/CAE /PDM/ERP …). Сложные изделия имеют профессионально-смысловое деление и внутри основных этапов ЖЦ, в большей степени это касается этапов проектирования и производства.
Назовем отдельную описанную выше локальную информационно-технологическую область ЖЦ-подсистемой. С информационной точки зрения каждая ЖЦ-подсистема имеет границу, отделяющую одну подсистему от другой, собственные информационные ресурсы (в том числе язык предметной области) и технологию документооборота, отражающего технологические операции данной предметной области. Примером служит процесс проектирования и производства газотурбинного двигателя, где специалисты по воздухозаборнику, компрессору, камере сгорания, турбине и соплу общаются со специалистами смежниками на специализированных (внешних) языках документов. Указанные особенности ЖЦ-подсистемы позволяют рассматривать ее как объект сферы информационных технологий.
Представление ЖЦ-подсистемы как объекта, позволяет уточнить исходную парадигму CALS:
Формат информационного взаимодействия между ЖЦ-подсистемами существенно зависит от технологии решения прикладных задач в каждой из подсистем. Действительно, структуру данных определяет получающая сторона, обработку и выдачу данных в нужном формате обеспечивает, в силу своих возможностей, подсистема, выдающая информацию. Реально мы наблюдаем типичную контрактную технологию информационного взаимодействия ЖЦ-подсистем как объектов. Ответственность за качество информации в рамках контракта несет генерирующая подсистема, ответственность за правильность запроса несет принимающая информацию подсистема. Источником / приемником данных может быть человек или информационно-техническая система. Естественно, что форматы данных информационного обмена подсистем должны максимально придерживаться стандартов, если таковые существуют (концепция единого информационного пространства, ЕИП).
В рамках объектного подхода, взаимодействие между подсистемами осуществляется активными объектами – Актерами (Actors). В качестве актера может выступать человек, например, при работе с интерактивным электронным техническим руководством, или технологическая система, например PDM.
Методика формирования надежного информационного взаимодействия между подсистемами в рамках RUP подхода сводится к выделению актеров указанных подсистем, определению потребностей актеров и описанию вида запросов к соответствующим бизнес процессам подсистемы, которые данные потребности удовлетворяют. В языке UML (Unified Modeling Language), принятом в RUP, указанные запросы носят название «варианты использования» системы (Use Case).
Комплекс актеров и связанных с ними вариантов использования является информационной моделью (Use Case модель) процессов информационного обмена между подсистемами, т. е. информационной моделью ИПИ.
Таким образом, информационный обмен между ЖЦ-подсистемами, рассматриваемыми как объекты, сводится к выполнению некоторого контракта. Получающая сторона формулирует задачу, сторона-исполнитель реализует требуемую задачу информационного обмена в рамках заранее установленного контракта (варианта использования системы-Use Case).
В зависимости от типа Use Case, в методологии и реализующей ее технологии ИПИ можно выделить три уровня деятельности :
Характерной особенностью ИПИ задач является их нечеткая постановка. Данное обстоятельство связано с проблемами в области семиотики и вызвано различиями в концептуальных базах отправителя и приемника информации. Представители разных предметных областей обычно имеют несовпадающие взгляды на один и тот же объект. Проблемы возникают на нескольких уровнях. Сравнительно простой является ситуация, когда различается лишь лингвистическая компонента концепта, а содержание концепта, обозначающего объект реального мира, совпадает в обеих предметных областях. Данная ситуация типична при передаче данных от одной к другой PDM или САПР системе и проблема решается построением требуемого транслятора (Рис. 1).
В случае несовпадения концептуального взгляда на один и тот же объект, получатель не может воспринять информацию, содержащуюся в сообщении по причине отсутствия в его тезаурусе соответствующих концептов. Полноценный информационный обмен между ЖЦ-подсистемами может быть установлен только как результат процесса обмена знаниями. Итерационный характер технологии RUP имеет принципиальное значение для решения научных ИПИ задач. Проект в RUP рассматривается как последовательность итераций, каждая из которых улучшает сопоставимость семантики концептов участников информационного обмена, необходимых для понимания вопросов и правильного истолкования ответов.
Рис. 1.
Реализация RUP имеет гибкий характер и может быть использована для решения ИПИ задач различного объема и уровня сложности. Таким же образом, возможно использование данной технологии на разных уровнях формализации документооборота решаемой задачи.
Центральное место в методологии занимает система управления требованиями Requi-site Pro. Use Case требования анализируются средствами системы и сопоставляются перечню научных задач или перечню дисциплин обучения, если это требования к знаниям обучаемого. Каждой теме научного исследования или дисциплине обучения можно сопоставить диаграмму Ганта системы Microsoft Project и выполнить анализ системы требований (научной программы, учебного плана) на временные ограничения или критичность при использовании исследовательских, дидактических, временных или лабораторных ресурсов. Комплекс Use Case требований, хранящийся в базе проекта используется двояким образом. Формируется текстовый документ специального вида - «Концепция проекта» (Vision). Документ содержит формализованный набор сведений о проекте, как коммерческом предложении. Цель доку - мента – согласовать взгляды участников информационного обмена на пользователей, задачи, методы и средства решения проблемы информационного обмена.
Те же требования служат основой для построения средствами языка UML информационной модели проекта. Для построения модели служит система Rational Rose. Средствами указанной системы участники, требования и протоколы решаемой задачи информационного обмена могут быть описаны с требуемой степенью наглядности и подробности, вплоть до структуры алгоритмов.
Программы Rational Rose, Requisite Pro и документ концепции проекта Vision взаимосвязаны и изменения в номенклатуре, содержании или статусе требований Use Case, выполненные в одной из программных систем, отражаются в остальных системах. Документирование задач проекта может быть реализовано на основе программы SoDa, генерирующей Word- документ, или же непосредственным обращением к базе проекта, хранящей в прозрачном режиме все основные данные проекта, средствами VBA или Delphi.
Предлагаемая концепция и реализующая ее технология описывается Use Case диаграммой (Рис. 2). Диаграмма содержит объекты и варианты использования - Use Case.
Рис. 2.
Не уменьшая общности, опишем технологию применения указанной концепции в сфере обучения. Задачи сферы научных исследований и задачи взаимодействия указанных областей решаются аналогичным образом.
Рассмотрим содержание этапов (Рис. 3):
Рис. 3.
Основой предлагаемой технологии является методика управления требованиями к знаниям специалиста. Комплекс требований формируется в процессе построения информационной модели проекта обучения. Требования могут быть ранжированы и описаны с различных точек зрения (дидактической, научной, ресурсной …). Имеется возможность сопоставить учебные требования дисциплинам учебного плана и оценить информационную нагрузку каждого предмета в реальном времени. Использование CASE возможностей для управления требованиями позволяет варьировать план обучения в зависимости от исходных знаний обучаемого, потребностей промышленности или науки.
Перенос комплекса требований или дисциплин обучения в среду системы Microsoft Project и представление информационной компоненты процесса обучения в виде диаграмм Ганта дает возможность оценить реализуемость процесса обучения в плане ресурсных нагрузок, провести исследование дидактических характеристик указанного процесса.
Концептуальные, дидактические, технологические и инструментальные средства формирования процесса обучения реализуются в виде референтных моделей или описываются в виде методологий в рамках обучающего CALS-центра. CALS-центр содержит референтные Use Case и Requisite Pro модели обучения в области CALS-технологий по направлениям, методики построения Microsoft Project моделей учебных планов и средства настройки указанных моделей на требования конкретной специальности.
Основной дидактической единицей обучающего CALS центра является модель процесса обучения. Модель состоит из информационной Use Case модели, выполненной средствами Rational Rose на языке UML, проекта управления требованиями в Requisite Pro, проекта в Microsoft Project и Word документа Vision. Документ Vision представляет собой стандартный текстовый документ технологии RUP и играет роль ТЗ проекта.
В случае, когда основой информационной модели служит государственный образовательный стандарт или другой текстовый документ, информационная модель строится на основе документа Vision. Требования стандарта копируются в Word документ Vision, описываются и погружаются в среду Requisite Pro. На основе требований проекта Requisite Pro формируется модель управления проектом Microsoft Project, далее формируются требования Use Case в системе Rational Rose, и строится полноценная информационная модель с использованием средств языка UML.
Модели проектов обучения, не имеющие аналогов, например «CALS технологии в авиадвигателестроении » изначально строятся выразительными средствами языка UML в рамках системы Rational Rose. Далее модель переносится в среду Requisite Pro/Microsoft Pro- ject/Vision.
Задачей Use Case модели является согласование точек зрения промышленности – заказчика специалистов и потребителя результатов научных исследований в области CALS технологий и вуза – исполнителя проекта. С точки зрения промышленного предприятия, модель описывает потребности производственные процессы, требующие участия специалистов с конкретными функциями и навыками. С точки зрения вуза, модель служит для формирования списка требований к специалисту, позволяющего сформировать и оценить реализуемость соответствующего учебного плана. Верхний уровень Use Case модели предприятия имеет вид (Рис. 4).
В модели указывается структура предприятия, и в терминах Use Case диаграмм описываются потребности предприятия в области CALS технологий.
Use Case диаграмма верхнего уровня, отражающая, например, точку зрения Генерального конструктора, имеет вид:
Жизненный цикл двигателя описывается диаграммой (Рис. 6):
Требования к специалисту отражаются в виде списка (Рис. 7).
Согласованные между участниками проекта требования к специалисту копируются параллельно в документ Vision и программу Requisite Pro. Средствами программы требования ранжируются по требуемым в дидактике параметрам и сопоставляются дисциплинам обучения.
Рис. 4.
Рис. 5.
Рис. 6.
Рис. 7.
Данная диаграмма (Рис. 8) описывает информационную составляющую учебного плана.
Реализуемость учебного плана и оценку его качества по использованию педагогических ресурсов – загруженность студентов, наличие лабораторий т. д. проверяется средствами системы Microsoft Project. Представление последовательности требований или дисциплин в виде диаграмм Ганта позволяет определить критические точки учебного плана.
При необходимости, учебный план корректируется на уровне информационной Use Case модели, согласовывается и измененный план утверждается в виде документа Vision. Заметим, что изменение требований в любом из документов автоматически находит свое отражение в остальных (исключая Microsoft Project).
Рис. 8.
В рамках указанной технологии была решена задача построения центров обучения в области CALS технологий по направлениям на ряде кафедр технического университета (УГАТУ). Разработаны референтные модели по каждому из направлений обучения. Средства применяемой технологии позволяют использовать настраиваемую референтную модель процесса обучения для гибкого управления содержательной составляющей учебного плана в зависимости от целей обучения, исходного уровня обучаемых и потребностей промышленности. Средства WEB публикации проекта позволяют обеспечить доступ к информации всем заинтересованным лицам.
Методология управления разверткой, запуском и развитием средств обучающего CALS центра представлена в виде программно-методического CALS комплекса.
За дополнительной информацией обращайтесь в компанию Interface Ltd.
| INTERFACE Ltd. |
| ||||
