CC BY-NC-ND
691
Современные технологии и средства разработки программного обеспечения
К.В. Логвинова,
К.ф.м.н., PhD in Mathematics, Профессор кафедры информационных систем и технологий, НФ ГУ ВШЭ.
Рассмотрены наиболее известные технологии, инструментальные средства и системы объектно-ориентированного моделирования с точки зрения достигнутого уровня абстрактности, перечислены основные принципы модельно-ориентированного подхода. Доказано, что современная программная индустрия находится в переходном состоянии на пути к повсеместному использованию модельно-ориентированного принципа проектирования и разработки программного обеспечения.
Основания
Современные средства разработки программного обеспечения и технологии позволяют создание и развитие чрезвычайно сложных, распределенных программных систем, взаимодействующих с различными внешними агентами. Эволюцию такой системы не в силах полностью контролировать отдельный разработчик, полагающийся лишь на частные эмпирические знания о её структуре и функциях. В то же время сложной программной системе, как и любой другой системе, присущи определенные общие закономерности, изучаемые в общей теории систем [1]. Увеличивающаяся сложность, многочисленность подсистем с противоречивыми целями и большое число взаимосвязей приводит к появлению в области проектирования, разработки и эксплуатации программных систем метасистемного перехода [2].
Это выражается в появлении на определенном этапе эволюции системы нового уровня иерархии. Он начинает контролировать нижние уровни, определяя новые ограничения на множестве их допустимых состояний, а процессы, агенты, и данные, до этого момента бывшие внешними по отношению к системе, становятся объективизированы в составе системы более высокого уровня сложности (метасистемы). Такая объективизация приводит к тому, что согласованное управление параметрами ранее несвязанных компонентов (определение
ограничений и контроль за их соблюдением) становится одной из задач, необходимых для достижения цели образовавшейся метасистемы. При этом цели метасистемы выражаются через вновь возникшие (emergent), более абстрактные свойства, а достижение этих целей требует решения новых интеллектуальных задач.
Знание подобных общесистемных принципов позволяет эффективно организовывать проектирование и разработку сложного программного обеспечения. При использовании наивысшего доступного на данный момент уровня абстракции (уровня управления системой) появляется возможность получения более эффективных результатов (в количественном исчислении. Это набор реализованных функций, а также более полное удовлетворение нефункциональным требованиям безопасности, переносимости и т.п.), при том же использовании интеллектуальной силы разработчиков. Однако побочным эффектом, который следует принимать во внимание, является увеличение накладных расходов на работу системы. Каждое повышение уровня абстракции и уровня управления требует привлечения дополнительных ресурсов (большее число представлений, затраты на реализацию отображений и т.п.). В программисткой практике это означает, что использование более абстрактных системных уровней приводит к большему размеру кода и меньшей производительности программ. Если бы мы сравнивали две программные системы с теми же
(или приблизительно теми же) функциями пользователя, то меньшим размером и большей производительностью обладала бы та, при проектировании и разработке которой использовались менее абстрактные средства. Наглядный пример такой ситуации — оценка ресурсов, требующихся для выполнения простейших алголритмов в виртуальной машине Java. Для виртуальной машины Wonka [3] требуется не меньше 4Мб оперативной памяти только для разворачивания машины.
Это обстоятельство приводит к интересной оптимизационной задаче по выбору наилучшего уровня абстракции при проектировании программной системы. В каждом конкретном случае используется своя комбинация критериев, со специфическими предпочтениями между ними.
Однако сейчас запасы по росту производительности процессоров и увеличению объема первичной, вторичной, третичной памяти еще большие. Поэтому для многих прикладных задач ростом накладных расходов можно пока пренебречь. Как показывает пример перспективных разработок компании Intel [4], несмотря на приближение к технологическому пределу в 65 нм в производстве отдельных процессоров, существуют схемотехнические решения, могущие обеспечить дальнейшее повышение производительности и снижение энер-гопоребления.
Для большинства прикладных задач самая эффективная стратегия — использование наиболее абстрактного уровня в системе технологий и набо-лее абстрактного уровня в системе проектирования. Нужно знать, на каком уровне находится сейчас каждая из этих систем и какие конкретно параметры находятся в распоряжении разработчика.
Задача этого обзора — краткое и неформальное описание технологий и методов разработки программного обеспечения, предоставляющих разработчику наивысший доступный уровень абстракции, следовательно, максимально способствующих качеству и эффективности инженерной деятельности.
Направление развития системного программного обеспечения (ПО). Компонентные системы
В настоящее время лидирующим методом проек-трования и разработки программного обеспечения является объектно-ориентированный подход [5]. За многие годы широкого использования этот метод показал свои возможности при моделировании различных предметных областей и в реализации
различных категорий ПО — от операционных систем до систем управления сложными технологическими объектами.
В свое время разработка объектно-ориентированного подхода к проектированию и реализации программного обеспечения явилась примером ме-тасистемного перехода в программной инженерии. Рассматриваемые ранее отдельно данные и прикладные алгоритмы элементов программы, моделирующие поведение различных сущностей предметной области, стали рассматриваться совместно в рамках одного понятия «объект». Это позволило разрешить многие сложные проблемы в архитектуре программной системы и в процессе ее практической реализации, унифицировать большое количество вспомогательных алгоритмов и абстракций, выведя их с поля зрения разработчиков прикладных алгоритмов на уровень системного ПО.
С использованием новых средств и методов объектно-ориентированного дизайна появилась возможность создания более сложных программных систем. В силу неумолимых законов развития возникли новые задачи более высокого уровня абстракции, требующие своего решения. К наиболее важным задачам относятся:
^ обеспечение эффективной распределенной
работы множества объектов; ^ поддержка транзакций;
^ безопасность объектно-ориентированной
системы; ^ долговечное сохранение данных; ^ разрешение нелокальных эффектов поведения объектов в контексте сложной распределённой системы.
Пока выбор и реализация таких решений возлагается на конкретного разработчика, эффективность распределенных объектно-ориентированных технологий остается невысокой, так как ее слишком сложно использовать, осуществлять поддержку и развитие в каждом конкретном случае. Пример — технология распределённых объектов СОЯВА, созданная OMG [6]. Такая сложность на руку отдельным разработчикам. Немногие из них становятся экспертами в этой области и могут монополизировать процесс разработки ПО, что приводит к неэффективному использованию ресурсов в рамках системы «пользователь—программный продукт-разработчик». Поэтому за пределами индивидуального человеческого рассудка эта система эволюци-онизирует к новому уровню организации, на котором все (или большинство) перечисленных систе-мых задач единообразно решаются в рамках
объективизированного процесса работы метасистемы, параметрами которого только и может управлять разработчик.
Эта эволюция приводит к появлению такого понятия программной архитектуры, как серверный компонент, и к возникновению новой разновидности системного ПО — мониторов компонентного взаимодействия (другое название — монитор компонентных транзакций; термин введён Анной Томас-Менс в 1999 г).
Наиболее распространенная практическая реализация серверных компонентов и мониторов компонентного взаимодействия — J2EE-технология Enterprise Java Beans [7]. Среди активно использующихся реализаций EJB-технологий отметим свободно-распространяемый продукт JBOSS [8], и коммерческий продукт BEA WebLogic.
Технология EJB определяет модель для проектирования, реализации, развертывания и управления жизненным циклом независимых серверных компонентов на языке Java, которые инкапсулируют данные и правила бизнес-логики для локальной задачи. Под моделью в данном случае понимается строго заданный набор правил, определяющих взаимодействие между разработчиком компонентов и системой, содержащей эти компоненты.
Наибольшую важность в технологии EJB представляют не правила создания отдельного сервер -ного компонента, а новый принцип организации распределенной системы из набора независимо созданных компонент. Функциональность, ранее создававшаяся заново (в виде действия), теперь (с точки зрения прикладного разработчика) представляется в форме параметров метасистемы. Все (или почти все) вопросы жизненного цикла, именования компонентов, безопасности, долговечности, прозрачного сетевого доступа объективно определены правилами взаимодействия серверного EJB-компонента и монитора компонентных взаимодействий. Разработчик может рассматривать функционирование своей системы в терминах представлений намного более высокого уровня абстракции и проводить настройку EJB-компонен-тов путем изменения их атрибутов в декларативном
виде, реализуя на практике так называемое программирование на основе атрибутов (attribute-based programming). Это позволяет эффективнее связывать систему с другими системами (внешним миром), рассуждать о функциях и возможностях созданного ПО.
Наиболее очевидное новшество технологии EJB — создание нового уровня абстракции доступа к долговременно сохраняемым данным программы. Этот уровень называется «управление долговременным хранением» (Container-Managed Persistence, CMP) [9] и позволяет разработчику использовать понятие «постоянных» объектов (persistent object), абстрагируясь от ранее требующих внимания вопросов соединения с базами данных, формирования SQL-запросов, определения моментов доступа к базам и т.п. «Проецирование» свойств EJB-компонента на модель используемой базы данных проводится декларативным способом в процессе развертывания на мониторе компонентного взаимодействия. Поэтому один и тот же EJB-компонент в различных распределенных системах может представлять различные базы данных1.
Развитие инструментальных средств
В результате использования возможностей компонентного программирования и мониторов компонентного взаимодействия пользователь (прикладной программист) освобождается от необходимости детального знания специфики реализации таких важных функций, как жизненный цикл, постоянство данных, транзакции и пр. Однако теперь он становится перед необходимостью подробного знания и понимания всех деталей синтаксиса и семантики параметров объективизированного процесса управления компонентами. При наличии большого количества независимых реализаций технологии EJB и неустановившихся стандартов владение всеми инструментами конфигурации для конкретного EJB-сервера становится затруднительным. Теперь требуется создавать вспомогательные
1 Если технология CMP EJB может рассматриваться как метасистемный переход в хранении данных, то в области реализации и управления действиями (алгоритмами) можно привести в качестве метасистемного перехода технологию автоматизации бизнес-процессов (Workflow Process Management). Появление и развитие систем управления бизнес-процессами [10] (по сути то, что Г. Виедерхолд называет мега-программированием [11]) дали возможность объективизировать понятия «бизнес-логика» и «поток управления». В спецификации WFMC дается описание интерфейсов программных оболочек и самих языков описания бизнес-процесса, которые в совокупности наглядно выражают все взаимосвязи и логические условия, используемые в ходе создания определенного алгоритма. Примеры доступных программных реализаций спецификаций WFMS:
OBE — OpenBusiness Engine [12];
^ JAWE [13];
^ SHARK [14].
Java-интерфейсы (так называемые интерфейсы home, remote, local*), которые напрямую к прикладной задаче не имеют никакого отношения.
Определенно, требуется следующий шаг в развитии инструментальных средств, объективизирующих сам процесс параметризации и облегчающих создание дополнительных языковых элементов, называемых артифактами (классы, интерфейсы, конфигурационные файлы и пр.), а также сборки из компонентов распределенной программы или последовательного применения специализированных инструментальных средств. К группе таких средств в настоящее время относятся:
^ средство автоматизации построения ANT [15]. Это средство, реализованное на языке Java, во многом напоминает известную утилиту make, но в нём появились новые черты. Важной мотивацией создания ANT являлось освобождение от особенностей программирования в различных командных оболочках UNIX при создании make-файлов. Вместо использования возможностей командных оболочек ANT использует собственный командный расширяемый язык, программа на котором выражается в форме XML-файла. Это позволяет переносить и расширять возможности ANT без привязки к конкретному типу командной оболочки, используемой на данном компьютере; ^ программная система XDOCLET [16] реализует концепцию литерального программирования включением особого рода комментариев в состав программ на языке Java. С использованием этого средства разрабочик освобождается от детального знания синтаксиса XML-конфигурационных файлов, требующихся для настройки и размещения серверных компонентов (причем для различных EJB-серверов), и необходимости создания дополнительных артифактов EJB-технологии (например, интерфейсов). При использовании средства XDOCLET в его распоряжении оказывается группа ключевых слов, которые прямо перед требующим спецификации элементом (классом, методом) позволяют задать необходимые параметры. После завершения работы над текстовым файлом алгоритмы системы XDOC-LET (реализованные в виде расширения ANT) производят препроцессорную обработку,
находя служебные комментарии XDOCLET и используя информацию из них для генерации дескрипторов развертывания и вспомогательных классов и интерфейсов EJB;
^ решение ANDROMDA [17] более кардинальное. Этот программный продукт использует в качестве основы для генерации всех артифактов EJB и соответствующих командных файлов программы ANT декларативную объектно-ориентированную модель на языке UML. При создании этой модели используются зарезервированные стереотипы для спецификации классов, аттрибутов, методов и связей. Эти стереотипы используются программой ANDROMDA для определения, какие из классов модели должны быть превращены в EJB-компоненты, какие атрибуты и методы должны быть для этих компонент сгенерированы. Пока используется генерация артифактов только для EJB-сервера JBoss.
Развитие средств моделирования
Описывая возможности программы ANDROMDA, мы переходим к важному вопросу об эволюции основных принципов проектирования ПО. Речь идет о появлении готовых к практическому использованию метатехнологий проектирования, основанных на иерархии формальных моделей и метамоделей предметной области и технологий программирования.
В области разработки ПО активное использование концепции иерархии моделей и метамоделиро-вание началось с конца 80-х гг. С ростом популярности Интернета и повышением важности задач по интеграции разнородных данных метамоделирова-ние стало наиболее важным направлением современной информатики и программной инженерии. Метамодели — основа для автоматизированной интеграции разнородной информации.
Метамодель — формальный язык, используемый для спецификации моделей — содержит описание всех конструктивных элементов, которые разрешено использовать при создании конкретной модели. Таким образом, каждая модель — экземпляр мета-модели. Метамодель обычно содержит: перечень типов разрешенных конструктивных элементов вместе с атрибутами; описание разрешенных типов
2 OMG — Object Management Group — международная организация; занимается широким кругом вопросов эффективного моделирования и разработки сложных объектно-ориентированных систем. OMG — родоначальник языка моделирования UML и основанных на нём методов проектирования ПО.
связей между различными строительными элементами; другую полезную информацию.
Все это вместе позволяет однозначно и в доступной для человека и компьютера форме определить смысловое значение (семантику) каждого конструктивного элемента в отдельности и модели в целом.
Модели определяют структуры данных, реально использующиеся в приложении. Так, в объектно-ориентированном программировании реальные объекты в программе являются экземплярами классов модели. Поэтому модели можно назвать метаданными (т.е. информацией о свойствах и структуре реально используемых данных).
Проиллюстрировать взаимоотношение между разными уровнями метамоделирования можно на основе стандартов международной организации OMG2. Для моделирования и интеграции сложных объектно-ориентированных программ эта организация предлагает использовать взаимосвязанную иерархию метамоделей и моделей из четырех уровней. Эта иерархия носит название Meta Object Facility, MOF (Средства МетаОбъектов) [28].
Уровни MOF определяются следующим образом, начиная с самого конкретного:
& уровень пользовательской информации состоит из той информации о реальном мире, которую требуется описать и непосредственно использовать в работе программы. Эту информацию обычно называют данными;
^ уровень модели состоит их метаданных, которые описывают структуру и связи информации. Метаданные чаще всего в информатике называют моделями; ^ уровень метамодели состоит из описаний структуры и смысла (семантики) метаданных (моделей). То есть на этом уровне располагаются метаметаданные, или как их чаще называют — метамодель. Метамодель можно считать единым языком, на котором описываются различные виды данных; уровень метаметамодели состоит из описаний структуры и смысла метаметаданных. Это единый язык, на котором описываются различные виды метамоделей.
На рис. 1 показан пример одной из возможных реализаций каждого из четырех уровней иерархии MOF.
В этом конкретном примере на уровне метамо-дели используется язык для представления простых, не связанных между собой записей, т.е. определяется составной тип Record (например, записи о работниках). Содержимое уровней определяется следующим образом:
уровень пользовательской информации содержит конкретные экземпляры записей с информацией об определённых сотрудниках;
Определены понятия:
Метаметамодель / метакласс, метааттрибут, \ Предопределена
Япод List и т.д. \ и не изменяется
Метакласс («Record» Метамодель / [Метааттрибут («Name», String,
Метаатрибут («Attributes», List<Field>) ])
Метакласс («Field» [Метааттрибут («Name», String)...])
Модель
Record («Employee» [Field («Name», String) Field («YearOfBirth, integer)])
Создаются и изменяются по желанию разработчика во время проектирования
Информация
Employee («Johnson», 1957) Employee («dark», 1963)
Рис. 1. Пример конкретной реализации иерархии MOF. Жирным шрифтом на каждом уровне иерархии MOF выделены вводимые на этом уровне понятия
& уровень модели включает метаданные, описывающие внутреннюю структуру типа данных Record с именем Employee для хранения иформации о сотруднике. Этот тип данных имеет два поля с заданными именами и типами;
& уровень метамодели определяет, что собственно означает «являться типом данных Record». Это определение выражается через содержимое метакласса с именем «Record». Он содержит два метааттрибута: первый определят имя типа Record, а второй определяет аттрибуты. Таким же образом особый метакласс определяет смысл элемента Field.
& уровень метаметамодели обычно жестко задан заранее и определяет все те конструкции, которые используются для определения метамо-делей. В нашем случае на этом уровне определяются понятия метакласс, метааттрибут и т.п.
Подход на основе метамоделирования предоставляет разработчику расширяемый механизм для описания всех деталей архитектуры программной системы, который позволяет повторно использовать существующие возможности (пользовательский интерфейс, управление жизненным циклом объектов и т.п.) и обеспечивает модульную интеграцию с чужими системами и структурами данных.
С использованием механизма метамоделей интеграция структур данных становится возможной за счет того, что само описание этих структур доступно в программе в виде данных, с которыми можно производить типичные операции (чтение, модификация, создание, удаление и т.п.). Например, в программе становится возможным узнать, какую внутреннюю структуру имеет тот или иной, заранее неизвестный тип данных, какая используется кодировка данных и т.п. Поэтому во время работы программы можно динамически «расшифровать» структуру экземпляра любого типа данных и преобразовать его значения в другой тип по потребности алгоритма или пользователя3.
Предложения OMG включают не только теоретическую концепцию, но и практические средства реализации метамоделирования. OMG рекомендует для создания метамоделей и моделей использовать один и тот же язык объектно-ориентированного моделирования — язык UML. В этом случае мета-модель определяет модель языка UML на самом
Метамодель
Используется _i_
Модель данных А
Используется
_Т
Общий алгоритм преобразования моделей
Используется
_4_
Модель данных Б
Используется
Jl
Используется
¿7
Используется
I
Средство автоматического преобразования данных
Рис. 2. Принципы автоматизированного преобразования разнородных данных на основе метамоделирования
высоком уровне абстракции и является наиболее компактным ее описанием — все основные понятия языка UML (класс, атрибут, операция, компонент, ассоциация и т.д.), их атрибуты и взаимосвязи формально определяются на уровне метамодели. Полная метамодель языка UML имеет сложную структуру и включает в себя порядка 90 метаклассов, более 100 метаассоциаций, организованных в три логические пакеты: основные элементы, элементы поведения и общие механизмы.
Любая UML-модель программной системы является экземпляром метамодели. Это означает: для построения модели могут использоваться только понятия, определенные в метамодели, которые разработчик специализирует или конкретизирует определенным образом.
Таким образом, возможности языка UML практически полностью удовлетворяют требованиям метамоделирования, позволяя создавать согласованные иерархии моделей и метамоделей, а также проводить их трансформации в рамках единой ме-татехнологии. Практический пример такой мета-технологии — подход Model-Driven Architecture — MDA [18], который также развивается под эгидой OMG. Авторы этого подхода, считают, что он
3 Это верно, пока используются типы данных, определенные с использованием иерархии МОЕ
позволяет отделить спецификацию функциональности разрабатываемой системы и стабильное описание концепций предметной области от спецификации альтернативных методов реализации с использованием определенной программной технологии или платформы4.
Следуя этому подходу разработчик концентрируется на разработке группы моделей (при этом, как правило, используется язык UML), фиксирующих в абстрактной (не зависящей от особенностей языка реализации и программных технологий), объектно-ориентированной форме структуру, функции и поведение всех элементов проектируемой системы в бизнес-контексте. Набор таких моделей называется в терминологии MDA платфор-монезависимой моделью (PIM — Platform-Independent Model).
При разработке модели используется строго специфицированный набор строительных элементов и типов их взаимосвязей, задающий по сути определенную метамодель. Таким образом, модель является строго формальной — строго определены ее форма (синтаксис), значение (семантика), а также правила анализа и логического вывода истинности и логической целостности ее составляющих. Это позволяет совместно использовать различные средства проектирования, моделирования и проведения имитационных экспериментов по построенным моделям, использовать единые понятия различными группами разработчиков.
Полученные платформонезависмые модели затем используются как исходные данные для автоматической генерации различных конкретных сущностей реализации, называемых артифактами. Такими артифактами являются, например, тексты классов, файлы конфигурации и др. Конечно, полностью уйти от ручного программирования не удается, но благодаря мощной инструментальной поддержке (защита пользовательских изменений при перегенерации артифактов, стандартные текстовые шаблоны, макросы, и пр.) объем ручного программирования значительно снижается.
Совокупность созданных автоматически или вручную артифактов составляет единую модель (или единую группу моделей), описывающую систему уже в связи с конкретными выбранными для реализации технологическим и инженерными решениями. Такую модель называют платфор-мозависимой моделью (PSM — Platform-Specific Model).
Важная особенность MDA-подхода — большой коэффициент повторного использования компонентов модели. Одни и те же модели могут быть использованы для генерации различных артифак-тов, в зависимости от выбранных пользователем языка реализации, конфигурации, программных технологий. Такая возможность появляется благодаря тому, что в MDA-подходе явно выделяется интерфейс и требования к компоненту маппинга, ответственному за генерацию определенной PSM-модели по абстрактной PIM-модели. Такой компонент обычно носит название MDA-картридж. Отдельный MDA-картридж является модулем расширения инструментального средства и умеет проводить генерацию артифактов для какого то конкретного набора параметров, языков и технологий (например, бизнес-логика:Java + EJB + WebLogic 6.1, GUI: Java + JSP + WebLogic 6.1, средства поддержки разработки: командные файлы для ANT, использование определенных библиотек) [28—30].
Практической иллюстрацией концепций MDA является продукт ArcStylertm компании Interactive Object [19]. Он позволяет с использованием принципов MDA проводить разработку, моделирование, генерацию, настройку и управление распределенными программными системами на основе стандартов J2EE, а также интегрировать устаревшие системы и пользовательскую инфраструктуру. С помощью продукта ArcStylertm можно использовать значительно более высокий уровень абстракции, чем при традиционном подходе к проектированию системы. Но за это приходится платить дополнительными накладными расходами — реализация простейшего пользовательского интерфейса на основе технологии JSP [20] требует около 600кБ кода.
Трансформация моделей в ArcStylertm реализована с помощью понятия MDA-картриджа, основной задачей которого является преобразование исходной платформонезависимой модели на языке UML в различные атрифакты целевой платфор-мно-зависимой модели. В большинстве случаев артифакты являются файлами с исходным кодом на определенном языке программирования и соответствуют классам исходной UML-модели. Внутренняя структура каждого артифакта предопределена с помощью так называемых секций артифак-тов. В случае текстовых файлов секция задает местоположение, возможное содержание определенного фрагмента файла и связь с элементами исходной модели (например, какие атрибуты классов
4 Под платформой в MDA понимаются технологические и инженерные детали разработки, которые несущественны с точки зрения фундаментальной функциональности системы или программного компонента.
исходной модели используются для генерации содержимого данной секции). Секции артифактов могут быть вложены друг в друга, таким образом полностью определяя иерархически структурированную целевую модель.
В целевой модели набор артифактов (Artifact Set) объединяет вместе артифакты, которые всегда создаются вместе в результате выполнения опре-деденного условия. Это условие строится на основе исходной модели и возможно с использованием дополнительной конфигурационной информации. Например, если MDA-картридж системы ArcStylertm реализует трансформацию UML-моде-ли (в которой EJB-компонент представляется в виде единственного класса), то для каждого элемента модели будет создан свой набор артифак-тов, состоящий из файлов с исходным кодом на языке Java для всех требуемых в технологии EJB интерфейсов (home, remote), классов реализации, Bean-классов, а также конфигурационных файлов (например, дескрипторов развертывания). Его генерация происходит в случае появления в исходной UML-модели элемента, представляющего EJB-компонент.
Знания о способах преобразования элементов исходной метамодели (связи, операции или атрибуты) в форму различных арифактов и секций артифактов целевой метамодели в системе Arcstylertm декларативно выражаются в виде так называемых Эскизов (Blueprints). Например, в случае применения EJB-технологии Эскиз для исходной UML метамодели будет определять как метаэлемент Operation, определенный в исходной метамодели UML, представляется в виде удаленного интерфейса и Bean-класса в целевой метамодели. Эскизы, взаимосвязанные в составе иерархии наследования, позволяют формально и полностю определить все правила трансформации любого элемента исходной метамодели.
Правила разработки самих Эскизов в системе Arcstylertm подчиняются основным принципам MDA. Поэтому разработчик может при необходимости проводить разработку Эскизов для специфичной программной технологии, получая за короткий срок возможность автоматической генерации целевой модели для новой платформы на основе ранее созданной платформно-независимой модели.
Для широкого распространения принципов мо-дельноориентированного проектирования и разработки кроме единообразных принципов использования ирерархий моделей и метамоделей необходим единый текстовый формат представления
созданных UML-моделей, чтобы можно было обращаться с моделями, созданными независимо в различных средствах проектирования и моделирования. Претендентом на такой единый текстовый язык представления моделей на сегодня является XMI [26]. Почему именно претендентом? В ходе работы с различными средствами разработки (Rational Rose [22], Together [23], Poseidon [24], MagicDraw [25]) и системами, поддерживающими генерацию артифактов (ANDROMDA, ArcStylertm) обнаружено большое различие в существующих версиях XMI. Это приводит к тому, что на практике перенос моделей из одного средства в другое на уровне XMI-документов крайне ограничен. Тем не менее XMI — практически единственный интероперабельный стандарт представления объектно-ориентированных моделей.
Выводы
Современные тенденции развития микроэлектронной техники и аппаратной архитектуры позволяют продолжить исследования в области повышения уровня абстракции методов и технологий проектирования и реализации сложных программных систем. Рост накладных расходов на реализацию внутренних уровней архитектуры программных средств и системных алгоримов вполне компенсируется новыми возможностями, открывающимися при использовании мониторов компонентного взаимодействия, распределенных многоагентых систем и модельно-ориентированных принципов проектирования и разработки программного обеспечения.
Решение задач эффективного использования интеллектуальной силы разработчиков, повышения повторной используемости и переносимости полученных ранее инженерных решений требует привлечения современных методов математического моделирования, представления и обработки знаний, а также совместных исследований в области информатики, психологии и программной инженерии.
К числу перспективных направлений работы относится разработка единой теории алгоритмов преобразования моделей и единых принципов построения программной архитектуры картриджей для генерации артифактов в технологии MDA. До сих пор эти аспекты проектирования до конца не стандартизированы. Разработчики инструментальных средств вынуждены проводить реализацию частных походов. Интерес представляет изучение глубинных взаимосвязей объектно-ориентированного моделирования и других вариантов моделирования
(в частности, моделей, описывающих бизнес-процессы, например, IDEF0). В этой связи упомянем средство разработки ArcStylertm, в котором реализованы возможности интеграции моделей, созданных с помощью известного средства бизнес-моделирования ARIS Toolsettm.
Повсеместное применение модельно-ориенти-рованных методов разработки программных систем заставляет искать новые принципы коллек-
тивной работы различных групп специалистов в ходе уточнения требований, построения архитектуры, реализации, тестрования и интеграции программ. Некоторые исследователи возлагают большие надежды на применение аппарата ASM — машин абстрактных состояний — для интеграции в модельно-ориентированную технологию самого трудноформализуемого этапа по сбору и формулированию требований. ■
Литература
1. Ван Гиг Дж. Прикладная общая теория систем, т.1,2 :- М., 1981.
2. Турчин В.Ф. Феномен Науки: Кибернетический подход к эволюции. М.: ЭТС, 2000.
3. Wonka - Java2 Virtual Machine Home Page. https://opensource.luminis.net/confluence/display/WONKA/Home.
4. Intel Silicon 65 nm Technology. http://www.intel.com/technology/silicon/65nm_technology.htm
5. Элиенс А. Принципы объектно-ориентированной разработки программ. Пер.с англ. - М.: «Вильямс», 2002. 496 с.
6. Ahmed S. A. CORBA Programming Unleashed. Sams Publishing, 1999. 578 c.
7. Монсон-Хефел Р. Enterprise JavaBeans. Пер. с англ. - Спб: Символ-Плюс, 2002. 672 с.
8. Marrs T., Davis S. JBoss at Work: A Practical Guide. O'Reilly Media, Inc, 2005. 306 c.
9. Tulachan P. Developing EJB 2.0 Components. Prentice Hall, 2002. 656 c.
10. Шеер А.-В. Бизнес-процессы. Основные понятия. Теория. Методы. Весть-Метатехнология, 1999. 152 c.
11. Wiederhold G., Wegner P., Ceri S. Toward Megaprogramming CACM, Volume 35, Issue 1, November 1992. С. 89-99.
12. OBE- Open Business Engine. http://obe.sourceforge.net/about/introduction.html.
13. JAWE - Open Source Java XPDL Editor. http://www.enhydra.org/workflow/jawe/index.html
14. SHARK - Open Source Java XPDL workflow Engine. http://www.enhydra.org/workflow/shark/index.html
15. Holzner S. Ant: The Definitive Guide. O'Reilly Media, Inc., 2005. 334 c.
16. Walls C., Richards N. XDoclet in Action. Manning Publications, 2003. 600 c.
17. ANDROMDA - MDSD/MDA Toolkit. http://www.andromda.org.
18. Mellor Stephen J., Scott K., Uhl A., and Weise D. MDA Distilled. Addison-Wesley Professional, 2004. 176 c.
19. ArcStyler Overview. http://www.interactive-objects.com/products/arcstyler-overview
20. Холл М. Сервлеты и JavaServer pages. Пер.с англ.- Спб.: Питер, 2001. 496 с.
21. Graessle P., Baumann H., Baumann P. Uml 2.0 in Action: A Project-based Tutorial. Packt Publishing, 2005. 248 c.
22. Quatrani T. Visual Modeling with Rational Rose 2002 and UML. Addison-Wesley Professional, 2002. 288 c.
23. Borland Together - Model Driven Architecture & Visual Modeling Application. http://www.borland.com/us/products/together/index.html
24. PoseidonUML Modeling tool. http://gentleware.com/index.php.
25. MagicDrawUML Modeling tool. http://www.magicdraw.com.
26. XML Metadata Interchange (XMI) Specification. http://www.omg.org/technology/documents/formal/xmi.htm.
27. OMG MetaObject Facility (MOF). http://www.omg.org/mof/.
28. Бабкин Э.А., Козырев О.Р., Куркина И.В. Принципы и алгоритмы искусственного интеллекта. Н.Новгород: изд-во НГТУ, 2006, 131 С.
29. Бабкин Э.А., Козырев О.Р., Полухина О.Е. Разработка информационных систем ERP класса. Н.Новгород: изд-во НГТУ, 2006, 259 С.
30. Бабкин Э.А., Козырев О.Р., Полухина О.Е. Архитектура и технология использования современных ERP систем на примере систем с открытым кодом. Н.Новгород: изд-во НГТУ, 2006, 321 С.
