u/text/302/181130/ html Открытые системы, процессы стандартизации и профили стандартов
| Вид материала | Документы |
- «Открытые системы. Субд», 65.57kb.
- Html динамический html, 177.06kb.
- Концепция www 4 Создание Web-страницы с помощью языка html 6 1 Язык html 6 Структура, 213.14kb.
- Концепция www 4 Создание Web-страницы с помощью языка html 6 1 Язык html 6 Структура, 214.3kb.
- Концепция www 5 Создание Web-страницы с помощью языка html 7 1 Язык html 7 Структура, 217.81kb.
- 1 Призначення html, 333.23kb.
- tza ru/index html, 6253.05kb.
- rsant ru/doc html, 96.01kb.
- /culture/2006/12/21/61584. html, 63.49kb.
- csti ru/irr/25 html, 99.48kb.
***
Критика инструментов и технологий отдельно взятых компаний-производителей всегда будет запоздалой. Это позволит ИТ-индустрии и впредь создавать несовместимую продукцию (терминологию, инструменты, технологии, решения и т.д.), предоставляя потребителям долго и упорно интегрировать ее с остальным ИТ-богатством. В этой энтропии выживут те компании, которые используют комплексный системный подход к созданию архитектуры данных предприятия и стандартизации использования ИТ-продуктов. Раннее тестирование идей, терминов и понятий, выдвигаемых производителями, позволит этим предприятиям упреждать как их ошибки, так и преднамеренный выпуск «лоскутной» продукции.
Литература
Михаил Зырянов, Сложность и производство. Директор информационной службы, 2004, № 3. Дмитрий Волков, Что входит в задачи PLM? Computerworld Россия, 2003, № 39. Dassault Systemes, «Dassault PLM Software Glossary», ссылка скрыта Леонид Черняк, PLM — не роскошь, а необходимость. Открытые системы, 2003, № 6. В.И. Дмитров, Опыт внедрения CALS за рубежом. Автоматизация проектирования, 1997, № 1. NATO CALS Handbook, Version 2, June 2000 1.0 Introduction, ссылка скрыта. Виктор Когаловский, Происхождение ERP. Директор информационной службы, 2000, № 5. Дмитрий Волков, Наталья Дубова, Два взгляда на ILM. Открытые системы, 2004, № 3.
Михаил Головко (MGolovko@yandex.ru) — независимый консультант по CALS-технологиям (Казань).
Web-центричное взаимодействие
Павел Брук, Геля Рузайкин
ссылка скрыта :: ссылка скрыта
В 2001 году состоялось объединение компаний UGS и SDRC в новое подразделение корпорации EDS под названием PLM Solutions. Задача этого, пятого подразделения EDS — разработка и продвижение решений на рынке систем управления жизненным циклом продукции.
Традиционно на промышленных предприятиях боролись за эффективное управление процессами проектирования, производства и обслуживания своих изделий на протяжении всего жизненного цикла путем внедрения методик и приложений, призванных улучшить оперативную эффективность в отдельных частных процессах. На протяжении более тридцати лет данная стратегия проводилась и в отечественной промышленности в рамках национальных стандартов, поддерживаемых организационно-техническими мерами, включая военную приемку. Основной акцент этих работ приходился на программно-технические возможности информационных технологий, в то время как, серьезной проблемой оставалось распределение знаний, аккумулированных на всех этапах жизненного цикла изделия как в недрах различных подразделений и предприятия в целом, так и у поставщиков, партнеров и заказчиков. С переменным успехом обмен знаниями удавалось организовать лишь путем громоздкой и медленно функционирующей организационной поддержки, основу которой составляла стандартизованная система системной документации, включающая не только конструкторскую, но техническую и программную (различные ЕСД).
Сегодня, в ходе жесткой конкуренции такой подход не эффективен, не говоря уже о том, что до недавнего времени ни один поставщик программного обеспечения в области управления данными не предлагал сколько-нибудь общего решения, отвечающего потребностям управления жизненным циклом изделия и обеспечивающего достаточными знаниями все службы предприятия: маркетинг, проектный отдел, технологический отдел, производство, сервисное обслуживание и т.п. Учитывая всю сложность и комплексность проблемы организации управления всеми этими процессами, ни одна компания не смогла пока вывести на рынок адекватного эффективного решения. Вполне возможно, что подход PLM Solutions, основанный на опыте компаний EDS, SDRC и UGS позволит через год-полтора достигнуть определенного прогресса в PLM-решениях. В рамках технологии TeamCenter предлагается получить достаточно общее решение по управлению знаниями об изделии, начиная от выработки требований к нему и кончая утилизацией (рис. 1).
 |
| Рис. 1. Спектр задач, решаемых в TeamCenter |
TeamCenter — это Web-центричное решение по управлению жизненным циклом изделия, обеспечивающее поддержку взаимодействия всех субъектов, связанных с конкретным изделием и аккумуляцию информации вокруг него. Все это нужно для того, чтобы сократить цикл выпуска новых изделий, повысить их качество, снизить затраты и повысить эффективность эксплуатации
Платформа данной технологии опирается на средства обеспечения открытой архитектуры (рис. 2), позволяющие осуществлять на корпоративном уровне интеграцию приложений типа ERP, SCM, CRM и т.п. Ядром данного решения является инструментарий для создания среды взаимодействия (Collaboration foundation), поддерживающей управление важной информацией об изделиях и процессах. Это ядро создает платформу для обеспечения взаимодействия, управления данными, визуализации и интеграции со всеми приложениями, имеющимися на предприятии. Сюда же включаются средства для формирования и поддержки работы коллективов специалистов (Collaboration community), такие как «чат» и конференции в реальном времени. Это слой призван обеспечить безопасное взаимодействие на виртуальном предприятии в реальном времени с использованием технологий Internet.
Следующий слой архитектуры — интегрированные средства визуализации TeamCenter, обеспечивающие динамическую визуализацию всех системных двухмерных и трехмерных объектов, поддержку стандартных форматов, полную интеграцию с интерфейсом пользователя. Средства инженерного взаимодействия (Engineering Collaboration) обеспечивают совместную среду для управления данными об изделии, полученными из различных систем САПР: Unigraphics, Solid Edge, AutoCAD, I-DEAS, CATIA и т.п. Одновременно предоставляются интегрированные возможности по управлению инженерными изменениями и конфигурациями изделия, управлению геометрией, документообороту, безопасности, а такие дополнительные средства как проектирование в контексте и новое поколение средств управления цифровыми макетами ускоряют процесс разработки изделия.
 |
| Рис. 2. Архитектура TeamCenter |
Вокруг этой структуры (рис. 2) сконцентрирован набор частных решений, таких как управление техническими требованиями (requirements management), управление проектами (project management), планирование производства (manufacturing planning), управление данными об изделии (product data management). Все эти продукты и решения, собственно, и предоставляют ценность для заказчиков. Важно отметить, что TeamCenter призван предоставить всем участникам процесса работы над изделием единый информационный источник для получения решений задач, возникающих на разных этапах жизненного цикла и имеется возможность оценки успешности каждого очередного шага.
Концептуально технология TeamCenter включает интегрирующие компоненты PLM, решения и программные продукты. Имеются компоненты визуализации необходимой информации, а также организации сообщества и координации его работы путем отслеживания выполнения системных требований к изделию, согласования действий различных групп разработчиков и производственников. Жизненный цикл изделия неразрывно связывается Сетью. В PLM-решениях сегодня появляется компонент поддержки информационного сотрудничества, консолидирующий информацию о конкретном изделии. Естественна также интеграция с другими системами управления, используемыми на данном предприятии.
Например, управление жизненным циклом изделия для ОЕМ-партнеров и поставщиков предусматривает контроль соблюдения требований к изделию, следование его концепции, предоставление информации о планировании производства и фактическом состоянии дел, о производственных испытаниях и их результатах, а также об обслуживании и ремонте. При этом службы маркетинга, инженерные, производственные и сервисные подразделения поставщиков и партнеров в полной мере используют информацию о процессах в необходимых объемах, однако первым доступна лишь электронная модель, а другие имеют доступ к базам знаний. Таким образом, TeamCenter поддерживает:
- взаимодействие при управлении техническими требованиями на изделие;
- управление данными об изделии (отслеживает отдельные сведения, документы, изменения, конфигурации) в части инженерного взаимодействия, планирования производства, моделирования, а также сервисной поддержки;
- управление проектами.
Модульные приложения, интегрированные в ядро TeamCenter, обеспечивают развитие и адаптацию PLM-технологии к конкретным условиям и требованиям проектов. Например, модуль управления техническими требованиями работает с техническими и распорядительными требованиями и, собственно говоря, определяет не только направление развития изделия, но и отслеживает верность соответствия проекта исходным требованиям. Модуль управления проектами, обеспечивает координацию работ и ускоряет разработку изделий, одновременно позволяя быстро реагировать на изменения. При этом решения по управлению информацией об изделии обеспечивают простой контролируемый доступ через Сеть ко всей базе знаний с данными об изделии. Модуль планирования производственных процессов позволяет управлять процессом проектирования изделия с учетом особенностей его производства, начиная с ранних стадий разработки, обеспечивая рациональное использование ресурсов предприятия.
Решение TeamCenter Design Collaboration — возможность синхронизации структуры изделия и электронного макета. Оно высвобождает средства электронного макетирования под управлением PDM для работы со средой визуального конфигурирования изделия. Эти возможности открылись благодаря базированию на общей модели продуктов и процессов, что обеспечивает эффективное использование информации.
 |
| Рис. 3. Эволюция TeamCenter |
Распространение технологии TeamCenter не повлияет на намерения компании EDS поддерживать и развивать уже существующие продукты — ни один из них не останется вне поля зрения. В частности, объявлено о намерении продолжать приемлемую поддержку и развитие I-DEAS, i-Man, Metaphase, Unigraphics и Solid Edge. Кроме того, заказчики через год-полтора получат интегрированное решение. Будет продолжен выпуск запланированных версий i-Man и, одновременно, будет организовано взаимодействие с технологией TeamCenter, поддерживаемое расширенным набором собственных средств двух решений. Следующим шагом (рис. 3) будет создание компонентной технологии PDM, а впоследствии интеграция компонентов i-Man PDM в единое общее решение TeamCenter через общие объектные и Web-службы. Аналогично, компонентная технология из продуктов Metaphase и i-Man превратится в объединенное решение TeamCenter. Важно при этом отметить, что функциональность i-Man в области инженерного взаимодействия станет доступной пользователям технологии TeamCenter.
Павел Брук (Pavel.Brouk@ugs.com) — директор по продажам PDM, компания EDS, (Москва); Геля Рузайкин — научный редактор журнала «Мир ПК».
Обещания и просчеты UML 2.0
Сергей Кузнецов
ссылка скрыта :: ссылка скрыта
Темой февральского номера журнала Computer (IEEE Computer Society, Vol. 38, No. 2, February 2006) стала «Управляемая моделями разработка программного обеспечения» (Model-Driven Software Development).
П
олноценная тематическая подборка статей предваряется объемной заметкой приглашенного редактора Дугласа Шмидта (Douglas Schmidt), которая озаглавлена «Управляемая моделями инженерия» (Model-Driven Engineering). Последние пятьдесят лет исследователи и разработчики программного обеспечения создают абстракции, помогающие им программировать в терминах целей своего проекта, а не используемой компьютерной среды, и защищающие их от сложностей этой среды. С самого начала эти абстракции включали технологии языков программирования и операционных систем. Ранние языки программирования защищали разработчиков от сложностей программирования в машинных кодах, а ранние операционные системы — от сложностей программирования на уровне аппаратуры. Но, хотя они и повышали уровень абстракции, они явно были «ориентированными на вычисления», обеспечивая абстракции пространства решений (т.е. самих компьютерных технологий), а не абстракции, позволяющие вести разработку в терминах прикладной области.Впоследствии предпринимались многочисленные попытки дальнейшего повышения уровня абстракции. Одно из наиболее известных направлений 80-х годов — CASE-системы, которые обеспечивают методы и средства создания программного обеспечения, позволяющие разработчикам выражать свои конструкции с использованием графических средств общего назначения, разного вида диаграмм. Одной из целей создания CASE-средств было обеспечение более тщательного анализа графических программ за счет их меньшей сложности, чем у программ на традиционных языках программирования (к примеру, в графических программах невозможны ошибки, приводящие к повреждению памяти). Другой целью являлся автоматизированный синтез программ из графических представлений, позволяющий сократить объем ручного труда. CASE-системам уделялось значительное внимание в профессиональной литературе, однако они не были широко приняты на практике. Объем и сложность генерируемого кода, требуемого для компенсации ограниченности реализационных платформ (они в основном представляли собой изолированные операционные системы — DOS, OS/2 или Windows), выходили за пределы возможностей существовавших технологий трансляции, что затрудняло разработку, отладку и развитие CASE-средств и приложений, создаваемых с их использованием. Другой проблемой подхода CASE являлась его неспособность масштабироваться до сложных, производственных систем в широком диапазоне прикладных областей. CASE-средства плохо поддерживали параллельную разработку; на их основе можно было разрабатывать программы в одиночку или группой, члены которой по очереди обращались к файлам, используемым этими средствами. В результате в 80-е и 90-е годы подход CASE оказывал сравнительно небольшое влияние на разработку коммерческого программного обеспечения, фокусируясь на отдельных прикладных областях, например, на обработке вызовов в телекоммуникационных системах, где хорошо подходили представления в виде конечных автоматов. Даже там, где CASE-средства применялись, обычно использовалась только их часть, позволяющая рисовать диаграммы программных архитектур и документировать свои решения, на основе чего программисты затем вручную производили и развивали реализации. Однако, поскольку прямая связь между диаграммами и реализациями отсутствовала, разработчики не стремились к большой точности диаграмм, поскольку они редко синхронизировались с кодом на дальнейших стадиях проектов.
В последние двадцать лет достижения в области языков программирования и платформ привели к повышению уровня абстракций, доступных для разработчиков, смягчив один из недостатков подхода CASE. Сегодня разработчики обычно используют более выразительные объектно-ориентированные языки (в частности, C++, Java и C#), а не Фортран или Си. Повторно используемые библиотеки классов и платформы поддержки приложений минимизируют потребность в изобретении общих и прикладных сервисов — транзакций, отказоустойчивости, оповещения о событиях, безопасности, распределенного управления ресурсами и т.д. Однако проблемы остаются. В центре этих проблем — сложность платформ, которая растет быстрее способности языков общего назначения ее маскировать. Популярные платформы промежуточного слоя J2EE, .Net и CORBA содержат тысячи классов и методов со многими сложными зависимостями и тонкими побочными эффектами, что требует значительных усилий при программировании и тщательной настройки. Более того, поскольку эти платформы быстро развиваются, разработчики тратят много сил на перенос кода приложений. Кроме того, код большинства приложений по-прежнему пишется на языках третьего поколения; значительных усилий требует выполнение интеграционных действий (в том числе развертывание, конфигурирование и поддержка качества системы). Так, на Java или C# трудно написать код, корректно и оптимально развертывающий распределенные системы с сотнями тысяч взаимосвязанных компонентов. Ситуацию не спасает даже использование описаний развертывания на языке XML из-за семантического разрыва между целью разработки и выражением этой цели в тысячах строк вручную произведенного XML-кода, синтаксис которого не имеет отношения ни к семантике прикладной области, ни к цели разработки.
Из-за этих проблем программная индустрия приближается к пределу допустимой сложности. В то же время платформенные технологии нового поколения становятся настолько сложными, что программисты, годами овладевая платформенными API и шаблонами использования, часто оказываются знакомыми только с частью возможностей платформы. Фрагментарность представления проекта затрудняет понимание того, какие части приложений являются чувствительными к побочным эффектам, возникающим при изменении требований заказчиков или среды разработки. Часто это вынуждает разработчиков производить неоптимальные решения, дублируя части кода, нарушая ключевые архитектурные принципы, усложняя развитие системы и обеспечение требуемого качества.
Многообещающим подходом, направленным на решение этих проблем, является инженерия, управляемая моделями (Model-Driven Engineering, MDE). При использовании MDE разработка ведется на предметно-ориентированных языках моделирования DSML (Domain-Specific Modeling Language), в системах типов которых формализуется структура, поведения и требования приложения внутри соответствующей предметной области. В используемых метамоделях определяются связи между понятиями предметной области, точно специфицируется основная семантика и ограничения, ассоциируемые с этими понятиями. Разработчики применяют DSML для построения приложений, используя элементы системы типов, зафиксированной в метамодели, и выражают проектный замысел в декларативном, а не императивном стиле. Важнейшие компоненты MDE — трансформационные процессоры и генераторы, которые анализируют определенные аспекты моделей и синтезируют исходный код, входные данные для имитационного моделирования, XML-описания развертывания или альтернативные представления моделей. Возможность синтеза на основе моделей помогает поддерживать согласованность между реализациями и аналитической информацией о зафиксированных в модели требованиях к функциональным возможностям системы и ее качеству. Этот процесс часто называют «правильным по построению» (correct-by-construction) в отличие от утомительного и чреватого ошибками традиционного процесса разработки вручную в стиле «построения путем коррекции» (construct-by-correction).
Первая статья тематической подборки называется «Разработка приложений с использованием управляемых моделями сред разработки» (Developing Applications Using Model-Driven Design Environments). Авторы статьи — Кришнакумар Баласубраманьян (Krishnakumar Balasubramanian), Анируддха Гокхейл (Aniruddha Gokhale), Габор Карсай (Gabor Karsai), Янош Штипанович (Janos Sztipanovits) и Сандип Нема (Sandeep Neema). Исторически методологии разработки программного обеспечения фокусируются в большей степени на совершенствовании средств собственно разработки, а не на создании инструментов, помогающих конструировать и интегрировать системы. Компонентное программное обеспечение промежуточного слоя (Enterprise JavaBeans, Microsoft .Net и CORBA Component Model) способствуют повышению уровня повторного использования кода на основе абстракции компонента. Однако при принятии на вооружение этих коммерческих технологий возникает разрыв между такими доступными и совершенными средствами разработки, как компиляторы и отладчики, и средствами, используемыми для компоновки, анализа и тестирования законченной системы. В результате разработчики продолжают выполнять интеграцию с использованием подручных методов. Управляемая моделями разработка (Model-Driven Development, MDD) — это развивающаяся парадигма, решающая многочисленные проблемы композиции и интеграции крупномасштабных систем и опирающаяся при этом на достижения в области технологий разработки (в частности, на компонентное программное обеспечение промежуточного слоя). Популярным вариантом MDD является модельно-управляемая архитектура (Model-Driven Architecture, MDA), предложенная и развиваемая консорциумом Object Management Group. В подходе MDA системы представляются с использованием языка моделирования общего назначения Unified Modeling Language и его конкретных профилей. Эти модели преобразуются в артефакты, выполняемые на разнообразных платформах, в частности, на EJB, .Net и CCM. В отличие от MDA, в другом варианте MDD, называемом модельно-интеграционными вычислениями (Model-Integrated Computing, MIC), для представления элементов системы и их связей используются предметно-ориентированные языки моделирования DSML, а также их преобразования в плаформенно-зависимые артефакты. Технология MIC создана и развивается в университете Вандербилта (www.isis.vanderbilt.edu/research/research.phpl#MIC). Концепция MIC успешно применена в разработке нескольких наборов инструментальных средств. Авторы статьи концентрируются на двух разработках. Язык платформно-независимого компонентного моделирования PICML (Platform-Independent Component Modeling Language) помогает разрабатывать, конфигурировать и развертывать системы с использованием CCM. Язык встроенных управляющих систем ECSL (Embedded Control Systems Language) поддерживает разработку распределенных встроенных автомобильных приложений. Оба набора инструментов построены с использованием общей среды моделирования GME (Generic Modeling Environment, ссылка скрыта). GME представляет собой свободно доступную метапрограммируемую среду предметно-ориентированных разработок.
Обещания и просчеты UML 2.0
Сергей Кузнецов
ссылка скрыта :: ссылка скрыта
Следующая статья написана Адамом Чайлдсом (Adam Childs), Джессом Гринуолдом (Jesse Greenwald), Джорджем Джангом (Georg Jung), Мэтью Хузэ (Matthew Hoosier) и Джоном Хатклифом (John Hatcliff). Название статьи — «CALM и Cadena: метамоделирование для основанной на компонентах разработки продуктового ряда» (CALM and Cadena: Metamodeling for Component-Based Product-Line Development). Масштабные работы по созданию программного обеспечения все чаще основываются на продуктовых линиях. Разработчики при этом создают сходные семейства продуктов на основе повторно используемой архитектуры и общих прикладных компонентов. В данном подходе особое значение придается систематическому повторному использованию; следование ему может сократить время разработки и внедрения в производство, а также общую стоимость более чем на порядок. Данный подход поддерживается использованием компонентного программного обеспечения промежуточного слоя за счет обеспечения правильно определенных интерфейсов, которые предотвращают излишнюю привязку клиентского кода к низкоуровневым реализациям, и упрощения добавления и изъятия модулей, что способствует повторному использованию и развитию системы. Разработка на основе подхода продуктовых линий с использованием компонентных каркасов успешно зарекомендовала себя в многочисленных прикладных областях: от масштабных распределенных систем реального времени и встроенных систем, систем управления электросетями, систем управления производственными процессами до операционных систем пользовательского уровня и систем интеграции приложений для ПК. Системы, основанные на компонентном программном обеспечении, состоят из интегрирующего слоя, который абстрагирует среду исполнения и реализует сервисы и коммуникационные каналы, и сети взаимодействующих компонентов, выполняемых за счет сервисов промежуточного программного обеспечения и обеспечивающих исполнение бизнес-логики. Явное разделение инфраструктуры и модулей приложения, а также возможность простой компоновки этих модулей позволяет выделить в разработке три роли. Архитектор продуктовой линии формирует архитектуру системы, выбирает инфраструктурные платформы и организует процесс разработки, разработчик компонентов создает модули бизнес-логики, интегратор компонентов собирает компоненты в систему. Достижения в областях языков описания архитектур и сред метамоделирования позволяют скрыть сложности деталей низкоуровневой реализации путем определения структурных абстракций компонентов, интерфейсов, соединителей и компоновки системы, которые могут визуализироваться и анализироваться, а также управлять автоматической генерацией различных видов инфраструктурного кода. Однако эти средства моделирования часто не нацеливаются непосредственно на поддержку подхода продуктовых линий.
Платформа поддержки разработки Cadena (ссылка скрыта) и ее основное средство моделирования CALM (Cadena Architecture Language with Metamodeling) позволяет преодолеть этот недостаток за счет обеспечения адаптивной среды моделирования с мощной, гибкой и расширяемой инструментальной поддержкой. CALM — это язык описания архитектур, поддерживающий строго типизированное моделирование платформ, компонентов этих платформ и сборок компонентов конкретных сценариев. Язык поддерживает основанную на наследовании иерархическую организацию платформ с использованием механизмов аспектов для включения в общие архитектурные описания атрибутов конкретных платформ. Cadena обеспечивает разнообразную поддержку создания, редактирования, запрашивания, просмотра и преобразования CALM-моделей, которые связываются с каркасами компонентного программного обеспечения, а также со средствами генерации кода через подключаемые модули Cadena. Эти модули фактически являются интерпретаторами моделей, реализующими семантику CALM-моделей. Cadena, разрабатываемая с нуля, должна стать расширяемой инструментальной платформой, а не автономным инструментом. Cadena реализуется в виде набора подключаемых модулей Eclipse.
Статья «Автоматизация эволюции изменений в модельно-управляемой инженерии» (Automating Change Evolution in Model-Driven Engineering) написана Джефом Греем (Jeff Gray), Джейн Лин (Jane Lin) и Джинг Жанг (Jing Zhang). С расширением областей применения моделей программного обеспечения появилась срочная потребность в управлении сложной эволюцией изменений внутри представления моделей. Разработчикам нужна возможность быстрой и простой проверки различных проектных альтернатив среди бесчисленных и разнотипных конфигурационных возможностей. В идеале инструмент должен был бы производить имитационное моделирование каждой новой проектной конфигурации для определения того, каким образом некоторый аспект конфигурации (например, коммуникационный протокол) влияет на наблюдаемое свойство (например, на пропускную способность). Для поддержки такого уровня поддержки эволюции моделей инструмент должен обеспечивать две категории изменений, которые сейчас выполняются разработчиками вручную. Первую категорию составляют изменения, пересекающие иерархию представления модели. Примером является эффект изменения пропускной способности на качество обслуживания компонентов авиационного электронного оборудования, которые должны отображать в реальном времени видеопоток. Чтобы оценить последствия такого изменения, разработчик должен вручную обойти иерархию модели. Этот процесс утомителен и чреват ошибками, поскольку модели систем часто содержат иерархии глубиной в несколько уровней. Вторая категория изменений включает увеличение масштаба частей модели, что доставляет особые беспокойства при разработке масштабных встроенных систем реального времени, содержащих тысячи крупномодульных компонентов. Для этого типа изменения требуется создание нескольких модельных элементов и соединений между ними. Работа с инструментом моделирования для масштабирования базовой модели до модели с тысячами элементов требует поразительно большого числа операций с мышью и клавиатурой. Этот процесс чреват ошибками, например, можно забыть установить соединение между двумя задублированными элементами. Кроме того, ручное масштабирование влияет не только на эффективность моделирования, но и на корректность представления. Обе эти категории эволюции изменений существенно выиграли бы от автоматизации. С этой целью авторы разработали обобщенный процессор трансформаций для манипулирования моделями, названный ими C-Saw (Constraint-Specification Aspect Weaver). C-Saw — это подключаемый модуль для GME (см. выше). Для работы с изменениями, пересекающими иерархию, в C-Saw используется аспектно-ориентированный подход. Комбинация трансформации модели с компоновкой аспектов обеспечивает мощную технологию для быстрого преобразования унаследованных систем на основе высокоуровневых свойств, описываемых моделью. Далее, путем применения аспектно-ориентированных методов и преобразования программ небольшие изменения на модельном уровне могут инициировать очень крупные трансформации на уровне кода.
Последнюю статью тематической подборки — «Модельно-ориентированная разработка с использованием UML 2.0: обещания и просчеты» (Model-Driven Development Using UML 2.0: Promises and Pitfalls) — написали Роберт Франс (Robert France), Судипто Гош (Sudipto Ghosh), Трунг Динх-Тронг (Trung Dinh-Trong) и Арнор Солберг (Arnor Solberg).
Достижения в областях разработки программ и технологий обработки информации привели к попыткам создания более сложных программных систем. Эти попытки демонстрируют неадекватность абстракций, обеспечиваемых современными языками высокого уровня. Возникает потребность в языках, моделях и технологиях, повышающих уровень абстракции, на котором задумываются, создаются и развиваются. OMG отвечает на это требование подготовкой версии 2.01 языка UML и инициативой MDA. Широкая осведомленность о проблемах ранних версий UML вместе с растущим интересом к MDD породили надежды, что разработчикам UML 2.0 удастся предложить версию языка с существенно сокращенным набором модельных понятий для точного и удобного описания самых разнообразных приложений. Ожидалось также, что в этой версии появится точная семантика, которая могла бы облегчить автоматизацию, требуемую для продвижения MDD за пределы традиционных возможностей CASE-средств. Те, кто не знаком с внутренней кухней стандартизации, находят поразительными размер и сложность стандарта UML 2.0. Действительно, конечные результаты кажутся далекими от посылок, которые мотивировали начало работы по крупному пересмотру языка. Многочисленные модельные понятия, плохо определенная семантика и легковесные механизмы расширений затрудняют изучение языка и его применение в среде MDD. Данные проблемы требуют решения, но не следует удивляться тому, что этот язык моделирования первого поколения далек от совершенства. Как отмечают некоторые разработчики UML, разработка языков моделирования все еще переживает период становления. Защитники UML 2.0 отмечают, что в стандарте отражен лучший производственный опыт применения моделирования. Они говорят про следующие основные усовершенствования. Улучшена поддержка UML как семейства языков за счет использования профилей и точек семантических вариаций, которые помечают части UML, умышленно оставленые без семантики, чтобы можно было нагрузить их семантикой, определяемой пользователями. Улучшена выразительность моделирования, включая моделирование бизнес-процессов, поддержку классификаторов повторного использования моделирования и поддержку архитектур распределенных неоднородных систем. Произведена интеграция семантики действий, которая может использоваться разработчиками для определения семантики моделей во время выполнения и обеспечивает семантическую точность, требуемую для анализа моделей и их трансляции в реализации. По мнению авторов, слишком высокая оценка UML и соответствующих технологий MDD столь же пагубна, как и несправедливая критика. Авторы статьи пытаются развеять облака рекламы, окружающие UML 2.0, и представить обоснованную оценку обеспечиваемой поддержки MDD.
Вне тематической подборки в февральском номере опубликована всего одна статья — «Распределенные встроенные интеллектуальные видеокамеры для приложений электронного наблюдения» (Distributed Embedded Smart Cameras for Surveillance Applications). Авторы статьи: Михаель Брамбергер (Michael Bramberger), Андреас Добландер (Andreas Doblander), Арнольд Майер (Arnold Maier), Бернхард Риннер (Bernhard Rinner) и Гельмут Швабах (Helmut Schwabach).
ссылка скрыта ссылка скрыта 2 ссылка скрыта ссылка скрыта
Обещания и просчеты UML 2.0
Сергей Кузнецов
ссылка скрыта :: ссылка скрыта
Современные достижения в областях вычислительной техники, коммуникаций и сенсорных технологий ускоряют разработку многих новых решений. Эта тенденция особенно заметна в областях повсеместных вычислений (pervasive computing), сенсорных сетей и встроенных систем. Одним из примеров таких новаций являются интеллектуальные видеокамеры, оборудованные высокопроизводительной встроенной вычислительной и коммуникационной инфраструктурой. В одном встраиваемом устройстве объединяются возможности видеовосприятия, обработки и коммуникаций. Путем обеспечения доступа ко многим точкам обзора за счет взаимодействия отдельных видеокамер сети встроенных камер потенциально могут поддерживать более сложные и проблемные приложения — включая интеллектуальные комнаты, электронное наблюдение, анализ движения, — чем одиночная видеокамера. Разработанная авторами интеллектуальная видеокамера является полностью встраиваемым устройством. При разработке учитывались требования экономного энергопотребления и обеспечения гарантированного качества в условиях ограниченных ресурсов. Видеокамера представляет собой масштабируемую, встраиваемую, высокопроизводительную многопроцессорную платформу, состоящую их сетевого процессора и различного числа сигнальных процессоров. На основе использования разработанной программной среды эти встраиваемые камеры поддерживают такие службы системного уровня, как динамическое распределение нагрузки и реконфигурацию задач. Кроме того, имеется возможность объединения нескольких интеллектуальных камер в распределенную встроенную систему электронного наблюдения, в которой поддерживаются взаимодействия видеокамер и коммуникации между ними. Хотя у интеллектуальных камер имеются различные области применения, авторы концентрируются на приложениях электронного наблюдения за дорожным движением, в которых выдвигаются повышенные требования к поддержке видеообработки и алгоритмов сжатия со стороны аппаратуры и программного обеспечения. Более точно, эти требования включают возможность автономного мониторинга трафика на заданном участке автомагистрали, обработку статистики трафика, доставку сжатых реальных видеоизображений на станцию мониторинга и выполнение высокоуровневого видеоанализа (например, опознание водителей, нарушающих правила, и аварийных ситуаций). Для удовлетворения этих требований распределенная архитектура электронного наблюдения должна быть масштабируемой и гибкой. Для демонстрации реализуемости предлагаемой системы электронного наблюдения авторы разработали прототип, включающий несколько интеллектуальных видеокамер.
До следующей встречи, Сергей Кузнецов, kuzloc@ispras.ru.
mySAP PLM — инструмент управления жизненным циклом
Наталья Тоскина
ссылка скрыта :: ссылка скрыта
Сегодня практически завершен процесс преобразования рынка продавцов в рынок, ориентированный на покупателя. На смену клиенту «вообще» пришел «индивидуальный клиент», усилилась роль качества продукции и услуг. Компаниям-изготовителям стало выгоднее подключать к своим проектам субподрядчиков, производящих или проектирующих комплектующие изделия. Длительность жизни такой проектной группы определяется временем выполнения проекта или жизненным циклом изделия. Однако на практике оказывается, что работники такого предприятия географически удалены друг от друга, используют несовместимые платформы и программные решения — возникает необходимость в единой среде совместного ведения бизнеса, обеспечивающей одновременную работу в реальном времени, интеграцию данных в контексте больших сборок, интерфейс со средствами анализа и подготовки производства.
П
онятие качества продукции стало сегодня более субъективным, а уровень качества стал определяться степенью соответствия товара набору характеристик, предъявляемых конкретным потребителем. Сегодня характерно также полномасштабное использование информационных технологий на протяжении всего жизненного цикла изделия, причем, в производственно-информационное пространство стало вовлекаться все большее количество участников. Кроме того, усилилась специализация производства. Сегодня изготовителям стало выгоднее подключать к своим проектам компании, производящие комплектующие изделия, а также конструкторские бюро в качестве субподрядчиков. Длительность жизни такой проектной группы определяется временем выполнения проекта или жизненным циклом изделия. В терминах технологий CALS (Continuous Acquisition and Life Cycle Support — «непрерывная информационная поддержка жизненного цикла изделия») такая структура названа «виртуальным предприятием» [1-3] и характеризуется общим информационным пространством, обеспечивающим (при соблюдении стандартов) совместное использование информации (рис. 1).  |
| Рис.1. Виртуальное предприятие |
Однако на практике оказывается, что работники такого предприятия географически удалены друг от друга, используют несовместимые платформы и программные решения. Отсюда возникает необходимость в единой среде совместного ведения бизнеса, обеспечивающей одновременную работу в реальном времени, интеграцию данных в контексте больших сборок, интерфейс со средствами анализа и подготовки производства. С точки зрения ИТ это означает поддержку совместной деятельности групп разработчиков, информационное сопровождение, управление транзакциями и т.д. Все это увязывается, например, через сервер приложений, над которым должна находиться система управления жизненным циклом изделия (PLM — product lifecycle management), в свою очередь координирующая работу модулей управления данными о продуктах (PDM — product data management), управления отношениями с клиентами (CRM — customer relationship management) и планирования ресурсов предприятия (ERP — enterprise resource planning) [4].
Компания SAP AG предложила интегрированное решение mySAP Product Lifecycle Management, в котором помимо компонентов платформы mySAP.com широко используется XML.