Отправляет email-рассылки с помощью сервиса Sendsay

Клуб профессиональных программистов

Рассылка закрыта

При закрытии подписчики были переданы в рассылку "Килограмм килобайтов" на которую и рекомендуем вам подписаться.

Вы можете найти рассылки сходной тематики в Каталоге рассылок.

←   Февраль 2007   →
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
Автор
RXL

Статистика

1.297 подписчиков
-1 за неделю
←   Все выпуски   →

Клуб профессиональных программистов :: Выпуск #31




Рассылка Клуба профессиональных программистов "Весельчак У"
comp.soft.prog.veselchak
выпуск #31
Здравствуйте, уважаемые читатели!

Представляем вашему вниманию новую статью, появившуюся на нашем сайте.

Практическое применение методологии MDA при разработке программ с многозвенной архитектурой клиент-сервер на языке программирования Ada


Что нам стоит дом построить?
Нарисуем – будем жить.
(народная мудрость)

Как мы дом строили или экскурс в историю

Коллективом филиала группы компаний ТехноСервъ А/С в рамках проекта по реконструкции зонального центра управления воздушным движением было разработано функциональное программное обеспечение подсистемы информационно-справочного справочного обеспечения автоматизированной системы управления воздушным движением. Разработанное программное обеспечение предназначено для управления базой данных различной справочной информации (технических характеристик воздушных судов, элементов структуры воздушного пространства и др.) и поиска и выдачи информации оперативному составу дежурной смены и другим подсистемам системы управления воздушным движением (в частности, подсистемам планирования использования воздушного пространства и управления воздушным движением).

Широкий спектр применения функционального программного обеспечения требовал выполнения в рамках одного продукта множества требований, наиболее важными из которых являются:
  • высокая отказоустойчивость - система управления воздушным движением работает 24 часа в сутки 365 дней в году и 20 лет до реконструкции;
  • всестороннее обеспечение защиты информации - хранимая информация является весьма критичной для всех этапов управления воздушным движением и содержит сведения, составляющие коммерческую тайну;
  • возможность предоставления актуальной информации на любой заданный момент времени как в "глубоком" прошлом (не менее 1 года), так и в "недалеком" будущем (не менее 28 дней) - планирование использования воздушного пространства начинается за две недели до начала использования, и в течение этого периода времени может произойти изменение информации;
  • возможность предоставления информации с моделированием поведения в прошлом - при выполнении объективного контроля необходимо в точности восстановить поведение автоматизированной системы и действия оперативного состава дежурной смены;
  • возможность ввода и проверки введенных данных параллельно со штатной работой автоматизированной системы.

Проектирование функционального программного обеспечения началось с анализа предметной области и построения модели предметной области. Параллельно велась работа по проектированию архитектуры программного обеспечения, позволяющей выполнить все накладываемые требования.

Архитектура функционального программного обеспечения была сформирована достаточно быстро. Основой являлась архитектура клиент-сервер; взаимодействие осуществлялось посредством архитектуры CORBA (в реализации PolyORB). Использование CORBA позволило сразу же и с минимальными затратами решить ряд важных требований, таких как: отказоустойчивость и защита информации. В состав CORBA входит специальная спецификация - отказоустойчивая CORBA (Fault Tolerant CORBA). Её реализация обеспечивает возможность создания и управления репликами объектов, равно как и прозрачность этого управления для клиентских приложений. Защита информации также является неотъемлемой частью CORBA, а точнее, службой защиты информации CORBA (CORBA Security Service). Третьей важной службой CORBA, явно не связанной с требованиями к функциональному программному обеспечению, но также позволяющей снизить затраты на разработку, является служба распределенных транзакций CORBA (CORBA Transaction Service).

Для хранения информации серверная часть функционального программного обеспечения использует базу данных Линтер-ВС 6.0 (аналог PostgreSQL 7.4, доработанный для выполнения требований по защите информации).

Если архитектура функционального программного обеспечения была сформирована достаточно быстро и в ходе разработки претерпела лишь небольшие и, в основном, косметические изменения, то процесс анализа предметной области и реализации функционального модуля был весьма непростым и тернистым. При этом были попытки использования самых различных методов и инструментальных средств, чему, собственно, и будет посвящена оставшаяся часть статьи.

На момент начала работ фактически все сотрудники уже имели достаточно большой опыт разработки различных программных систем (баз данных, распределенных систем, систем сбора и обработки информации), но все разработанные системы использовали лишь одну архитектуру (SQL клиент для базы данных, клиент-сервер CORBA). Соответственно каждый привык производить анализ и проектирование либо вообще без инструментальных средств, либо используя инструментальные средства, поставляемые с использовавшимся продуктом.

Предполагалась возможность возникновения недопонимания и расхождения во взглядах. Поэтому изначально предлагалось унифицировать используемые инструментальные средства и языки моделирования. Одним из самых удачных и перспективных выглядел унифицированный язык моделирования UML (Unified Modelling Language). Однако разработчики не смогли прийти к соглашению, и изначально анализ и проектирование выполнялось с использованием визуальных средств для проектирования баз данных и непосредственным написанием интерфейсов на языке CORBA IDL (Interface Definiton Language).

Несколько месяцев работы фактически не привели к какому-либо реальному результату - никак не удавалось разумно и рационально совместить требования по предоставлению информации на указанный момент времени и моделированию поведения в прошлом, а также наложить на получившееся решение механизм ввода и проверки введенных данных. Говорить о количестве неточностей и несоответствий между схемой базы данных и описанием интерфейсов, равно как и о затрачиваемых на их синхронизацию усилий, вообще не приходится.

Толчок к разрешению ситуации пришёл совершенно не с той стороны, с которой его можно было ожидать. Найденные в Internet работы, посвящённые битемпоральным базам данных, показали элегантный путь решения требований по выдачи информации на указанный момент времени и моделированию поведения в прошлом. Пристроить механизм ввода данных и их проверки на работающей в штатном режиме системе для небольшого примера оказалось достаточно просто, равно как и разработать соответствующее описание интерфейса. Но... каждая таблица базы данных получила четыре дополнительных атрибута (начало и конец действия в реальном времени и в системном времени), и вдобавок появилось две копии таблицы (для основных данных и подготавливаемых данных); невероятно усложнились накладываемые ограничения для контроля целостности базы данных; а спецификация интерфейса объявляла три интерфейса для каждого класса. Прототип был готов и проверен, но его предстояло использовать 144 раза! Вот тут стало совершенно понятно, что либо надо что-то менять, либо имеющимися силами проект реализовать невозможно.

В результате детального анализа полученного результата были выведены чёткие формальные правила формирования схемы базы данных (таблиц, ограничений, словаря данных); построения SQL запросов с учётом всех составляющих контекста работы (двух времён и вводимых/проверяемых данных); формирования описания интерфейса и кода реализации интерфейса.

Сложившаяся ситуация позволила увидеть, что львиную долю работы по реализации серверной части функционального программного обеспечения возможно автоматизировать. Однако нужны исходные данные, а именно: модель предметной области, которую можно подать в качестве исходных данных. Основной стоявший вопрос: как построить эту модель? Использовавшиеся средства моделирования (если их вообще можно было назвать таковыми) были изначально ориентированы на используемые технологические решения - базы данных или описание интерфейсов. Требовалось же нечто более абстрактное и не связанное ни с первыми, ни со вторыми.

И вот тут опять вернулась идея использования UML. Он, как язык моделирования, не привязан к используемым технологическим решениям, обладает всеми необходимыми элементами абстракции, широко поддерживается различными инструментальными средствами. Однако... здесь поджидало очередное разочарование. Как довольно быстро выяснилось, предлагавшиеся на рынке инструментальные средства не полностью соответствовали или вообще не поддерживали стандарт UML 2.0, зачастую были ориентированы на один определённый язык программирования, не поддерживали экспорт данных в формате XMI (специальная схема для XML, позволяющая представить UML модели) и т.д. и т.п.

На этот раз всё же было решено использовать именно UML, несмотря на обозначенные трудности. В конце концов, когда-нибудь они будут устранены. С этого момента работа была разделена на два направления: анализ и построение UML модели предметной области и разработка инструментального средства генерации необходимого кода реализации. В качестве исходных данных для этого инструментального средства было решено разработать собственный формат представления модели. Таким образом, преобразование UML модели в формат представления модели осуществлялось вручную, но в связи с использованием близких абстракций это преобразование в достаточной мере было механическим и, как показал опыт, его поддержание оказалось не столь ресурсоёмким.

Собственно, дальше мы занимались непосредственно реализацией... Модель прикладной области была успешно разработана одним человеком в течение трёх месяцев, за это время группа из двух человек сделала основную работу по разработке инструментального средства генерации кода, в течение полугода три человека полностью реализовали клиентскую часть - интерфейс пользователя, и ещё один человек разработал программу загрузки данных из одного из широко используемых для распространения аэронавигационной информации формата данных.

Уже после предварительных испытаний функционального программного обеспечения был произведён перевод модели с UML 1.4 на UML 2.0; избавились от собственного формата представления модели и начали получать данные непосредственно из модели в XMI формате; расширили состав хранимой и обрабатываемой информации; а также доработали генератор кода для генерации тестов и наборов тестовых данных.

Параллельно с разработкой проекта международный консорциум OMG (Object Management Group) осуществлял разработку целого ряда спецификаций, предназначенных для поддержки разработанной им же методологии MDA (Model Driven Architecture - основанная на моделях архитектура). На сегодняшний день большая часть этих спецификаций утверждена и имеет статус международных рекомендаций. Методология MDA очень похожа на использованный в конечном счёте процесс разработки, а сопутствующие ей спецификации позволяют провести дополнительное совершенствование использованного процесса разработки программного обеспечения.

Но обзор MDA и сопутствующих спецификаций оставим на следующий раз...

Принять участие в обсуждении этой статьи вы можете на нашем форуме.

Ждем вас также в разделе форума "Идеи для статей".
Здесь собраны вопросы, ответы на которые не сформулировать в двух словах. Попробуйте свои силы.

Подробнее по ссылке: http://forum.shelek.com/index.php/board,105.0.html


И не забудьте посетить наш "домик" на карте в Интернете по ссылке
http://www.internetmap.info/cgi-bin/go.cgi?site_id=4131%22%20


А теперь прощаемся с Вами до следующего выпуска.

                                        С уважением, команда Клуба.
В избранное