Стандартные методы совместного доступа к базам и программам в сложных информационных системах.

Компоненты программного обеспечения требуют реализации на разных языках и используют разную программно – техническую платформу. Его задача – осуществить интеграцию изолированных систем, дать возможность программам, написанным на разных языках, работающим в разных узлах сети, взаимодействовать друг с другом так же просто, как если бы они находились в адресном пространстве одного процесса. CORBA объединяет программный код в объект, содержащий информацию о функциональности объединяемого кода и интерфейсах доступа. Готовые объекты могут вызываться из других программ, расположенных в сети. CORBA использует язык описания интерфейсов для определения интерфейсов взаимодействия объектов с внешним миром. Язык описания интерфейсов – IDL. CORBA описывает правила отображения из языка описания интерфейсов в язык, используемый разработчиком CORBA – объекта. Программный интерфейс COM – это компонентная объектная модель, разработанная корпорацией Microsoft. Структура системы аналогична структуре CORBA. Однако применение COM ограничено в последнее время рамками операционной системы Windows. В то время, как CORBA многоплатформенная система. Но по сравнению с CORBA COM проще и распространяется бесплатно. Однако, CORBA обладает большими возможностями для создания больших интегрированных информационных систем. ODBC – это программный интерфейс (API) доступа к базам данных, разработанный фирмой X Open. Позволяет единообразно оперировать с разными источниками данных, отвлекаясь от особенностей взаимодействия в каждом конкретном случае. ODBC – это широко распространенный комплекс драйверов фирмы Microsoft для связи с разнородными базами данных, удовлетворяющий стандартом ISO. Технологии связи с разнородными базами данных в условиях архитектуры клиент – сервер с использованием ODBC. Связь клиентской и серверной частей осуществляется с помощью глобальной или локальной сети. Доступ к соответствующей базе данных со стороны клиента из прикладных программ обеспечивается трехслойным программным интерфейсом. Клиентская часть состоит из: Управляющий модуль ODBC. Позволяет определить необходимые источники данных для прикладной программы. Драйвер ODBC. Это динамически загружаемая библиотека, которую клиентское приложение загружает в свое адресное пространство для доступа к источникам данных. Драйверы для СУБД. Для каждой используемой СУБД необходим свой собственный ODBC драйвер, осуществляющий функции клиентских интерфейсов. ODBC драйвер для конкретной СУБД переформировывает формат запроса прикладной программы во внутренний формат, распознаваемый СУБД, к которой обращен запрос. Традиционная технология использования ODBC создает много сложностей системному администратору при появлении новых СУБД. Проблема состоит в необходимости инсталляции дополнительных драйверов для СУБД на каждом клиентском месте. Выход найден в технологии связи с разнородными базами данных с использованием сервера ODBC.

34. Этапы моделирования систем. Схема взаимодействия инструментальных средств моделирования.

35. Model Mart – назначение, установка, подключение базы.

интеграция с ModelMart. Сервер приложений для программных продуктов CA ModelMart поддерживает мощный набор инструментальных программных средств, обеспечивающих совместное (групповое) проектирование и разработку программных систем, включая механизмы объединения моделей и анализа изменений, контроль версий, возможность создания "компонент" модели и т.д. Для организации хранилища моделей в ModelMart используются СУБД на платформах Oracle, Sybase, Informix или SQL Server. Кроме того, поддерживаются прямые связи ModelMart с ERwin и BPwin

36. управление проектом и проектная документация. Автоматизация процесса документирования.

37. Методика описание набора данных и построения базы данных в RRose.

38. Подготовка генерации кода в RRose. Установка свойств генерации программного кода. Генерация кода, процесс обратного проектирования.

Генерация программного кода в среде IBM Rational Rose 2003 возможна для отдельного класса или компонента. Для этого нужный элемент модели предварительно следует выделить в браузере проекта и выполнить операцию контекстного меню: ANSI C++ Generate Code_ (Язык ANSI C++ Генерировать код). В результате этого будет открыто диалоговое окно с предложением выбора классов для генерации программного кода на выбранном языке программирования (рис. 14.6). После выбора соответствующих классов и нажатия кнопки OK программа IBM Rational Rose 2003 выполняет кодогенерацию.

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

Для осуществления обратного проектирования, в Rational Rose предусмотрен мощный модуль - Analyzer, чье основное предназначение, вытекающее из названия, анализ программ, написанных на С и С++. Данный модуль способен проанализировать имеющийся файл на одном из вышеупомянутых языков, и преобразовать его в визуальную модель, присвоив выходному файлу расширение mdl. Далее файл можно спокойно открыть для модификации из Rational Rose уже в визуальном режиме.

Analyzer представляет собой отдельный программный файл, вызываемый как из самой Rose, так и обычным способом. Модуль входит не во все поставки Rational Rose, а только в Enterprise, Professional и RealTime. В поставку Data Modeler данный модуль не входит, поскольку специфика поставки не предусматривает генерации кода и обратного проектирования.

Дальнейшая часть статьи будет посвящена как раз обратному проектированию, мы рассмотрим на конкретных прмерах, что разработчик получит от Rational Rose, применяя ее в качестве инструмента визуального ОО-проектирования.

Еще одна немаловажная ремарка. Как правило обратному проектированию подвергается полноценный проектный файл, содержащий в себе и директивы #INCLUDE для определений, и комментарии... а также прочие сопроводительные инструкции. И естественно разработчику хочется иметь такой инструмент, который адекватно будет реагировать на все составляющие. Спешу обрадовать: модуль Analyzer в режиме (DetailedAnalysis) обеспечивает следующее:

• Анализ и преобразование в визуальную модель классов и структур
• Генерацию связей в модели (между классами или структурами)
• Нахождение в исходном тексте комментариев и перенос их в качестве атрибутов компонентов модели. То есть если исходный текст снабжен комментариями, то они все перейдут в виде атрибутов, соответствующему элементу (переменной, массиву... итд).
• Способен закачать в проект все заголовочные файлы (по цепочке один за другим)