Третья стадия: Библиотеки CORBA-объектов, "стандартные" архитектурные конфигурации, коллективная разработка, внутренние стандарты
Обзор поставленных перед разработчиками задач
Усовершенствование процесса создания информационных систем с использованием технологий CORBA и Java.
Описание использованных технологий и решений
Технологии и решения, использованные на первой и второй стадиях, с учетом выявленных проблем и путей их решения.
Анализ возникших проблем и пути их решения
К настоящему моменту, было выполнено несколько крупных проектов по созданию распределенных информационных систем с помощью технологии CORBA.
Поэтому усовершенствования в использовании технологий CORBA и Java в основном были продиктованы увеличившейся сложностью решаемых задач, которая сопровождалась тесным взаимодействием нескольких групп разработчиков.
Во-первых, стало необходимым разработка "жестких" соглашений (внутренних стандартов), определяющих правила именования, группировки IDL-интерфейсов по модулям, правила использования библиотек CORBA-объектов. Коллективная разработка, предполагающая работу нескольких групп, привела к необходимости жесткой регламентации процесса контроля версий программного кода, проектных моделей, моделей этапа анализа предметной области.
Во-вторых, отсутствовали единые методики описания и хранения проектных моделей CORBA-объектов, предназначенных для повторного использования, библиотек классов (например, на С++), упрощающих процесс реализации CORBA-объектов.
В-третьих, при большом количестве IDL-интерфейсов, переход от проектирования к реализации (от IDL-интерфейсов к описанию и реализации классов на языке С++) занимал достаточно много времени.
В-четвертых, было отмечено, что в процессе разработки довольно часто требуется предоставить доступ к CORBA-объекту, как через IDL-интерфейс, так и через "локальный", не зависящий от CORBA, интерфейс взаимодействия (например, посредством вызовов методов C++ объекта другими C++ объектами, расположенными в том же пользовательском процессе операционной системы). Первоначальная реализация объекта на конкретном языке программирования делает его независимым от технологий взаимодействия распределенных объектов, что в конечном итоге упрощает процесс перехода на другую технологию (например, с Java RMI на CORBA), облегчает процесс тестирования логики производимых объектом вычислений.
В-пятых, был достаточно трудоемок процесс формирования моделей этапа проектирования, ибо немаловажными сущностями модели являлись IDL-интерфейсы, описание которых требовало много ручного труда.
Появление продуктов, ориентированных на поддержку процесса разработки информационных систем в технологии CORBA, позволяет в большинстве своем решить указанные проблемы. В качестве одного из решений можно считать использование языка UML. Отметим, что на предыдущих стадиях также использовался язык UML, но построение моделей осуществлялась в графических редакторах (например, в Visio).
Применение среды проектирования, обеспечивающей моделирование на языке UML, существенно упрощает процессы проектирования и реализации. Язык UML становится базисом, обеспечивающим единую инженерную нотацию при описании моделей, позволяет разработать методику обмена знаниями между разработчиками. В связи с этим, все библиотеки CORBA-объектов и C++ классов были "подняты" на уровень проектных моделей, что существенно упростило процесс их сопровождения, использования на этапе проектирования.
Использование CASE-продуктов делает возможным автоматическую кодогенерацию, позволяющую прозрачным образом переходить от логического проектирования к проектированию с учетом среды реализации (с учетом конкретного языка программирования).
Стало видно, что в релевантных проблемных областях возникают макроархитектуры (совокупность design patterns (объектных служб)), которые можно рассматривать как "стандартные" архитектурные конфигурации. Определяя структуры взаимодействующих подсистем распределенных информационных систем и описанные с помощью какой-либо инженерной нотации (например, UML) , они с наименьшими трудозатратами и в более короткие сроки позволяют проектировать архитектуру информационной системы, осуществлять реализацию программных компонентов. Так, примером макроархитектуры можно считать конфигурацию, объединяющую Workflow, Transaction Service, Concurrency Control Service, Normative Server, Abstract Factory, и др.
Назад |
Содержание |
Вперед