Case-технлогии

информация о покупателе, автомашине и продавце, поскольку именно контракты

приносят продавцам вознаграждения за продажи.

Первый шаг моделирования - извлечение информации из интервью и выделение

сущностей.

Сущность (Entity) - реальный либо воображаемый объект, имеющий существенное

значение для рассматриваемой предметной области, информация о котором

подлежит хранению (рисунок 2.18).

Рис. 2.18. Графическое изображение сущности

Каждая сущность должна обладать уникальным идентификатором. Каждый

экземпляр сущности должен однозначно идентифицироваться и отличаться от

всех других экземпляров данного типа сущности. Каждая сущность должна

обладать некоторыми свойствами:

каждая сущность должна иметь уникальное имя, и к одному и тому же имени

должна всегда применяться одна и та же интерпретация. Одна и та же

интерпретация не может применяться к различным именам, если только они не

являются псевдонимами;

сущность обладает одним или несколькими атрибутами, которые либо

принадлежат сущности, либо наследуются через связь;

сущность обладает одним или несколькими атрибутами, которые однозначно

идентифицируют каждый экземпляр сущности;

каждая сущность может обладать любым количеством связей с другими

сущностями модели.

Обращаясь к приведенным выше выдержкам из интервью, видно, что сущности,

которые могут быть идентифицированы с главным менеджером - это автомашины и

продавцы. Продавцу важны автомашины и связанные с их продажей данные. Для

администратора важны покупатели, автомашины, продавцы и контракты. Исходя

из этого, выделяются 4 сущности (автомашина, продавец, покупатель,

контракт), которые изображаются на диаграмме следующим образом (рисунок

2.19).

Рис. 2.19.

Следующим шагом моделирования является идентификация связей.

Связь (Relationship) - поименованная ассоциация между двумя сущностями,

значимая для рассматриваемой предметной области. Связь - это ассоциация

между сущностями, при которой, как правило, каждый экземпляр одной

сущности, называемой родительской сущностью, ассоциирован с произвольным (в

том числе нулевым) количеством экземпляров второй сущности, называемой

сущностью-потомком, а каждый экземпляр сущности-потомка ассоциирован в

точности с одним экземпляром сущности-родителя. Таким образом, экземпляр

сущности-потомка может существовать только при существовании сущности

родителя.

Связи может даваться имя, выражаемое грамматическим оборотом глагола и

помещаемое возле линии связи. Имя каждой связи между двумя данными

сущностями должно быть уникальным, но имена связей в модели не обязаны быть

уникальными. Имя связи всегда формируется с точки зрения родителя, так что

предложение может быть образовано соединением имени сущности-родителя,

имени связи, выражения степени и имени сущности-потомка.

Например, связь продавца с контрактом может быть выражена следующим

образом:

продавец может получить вознаграждение за 1 или более контрактов;

контракт должен быть инициирован ровно одним продавцом.

Степень связи и обязательность графически изображаются следующим образом

(рисунок 2.20).

Рис. 2.20.

Таким образом, 2 предложения, описывающие связь продавца с контрактом,

графически будут выражены следующим образом (рисунок 2.21).

Рис. 2.21.

Описав также связи остальных сущностей, получим следующую схему (рисунок

2.22).

Рис. 2.22.

Последним шагом моделирования является идентификация атрибутов.

Атрибут - любая характеристика сущности, значимая для рассматриваемой

предметной области и предназначенная для квалификации, идентификации,

классификации, количественной характеристики или выражения состояния

сущности. Атрибут представляет тип характеристик или свойств,

ассоциированных со множеством реальных или абстрактных объектов (людей,

мест, событий, состояний, идей, пар предметов и т.д.). Экземпляр атрибута -

это определенная характеристика отдельного элемента множества. Экземпляр

атрибута определяется типом характеристики и ее значением, называемым

значением атрибута. В ER-модели атрибуты ассоциируются с конкретными

сущностями. Таким образом, экземпляр сущности должен обладать единственным

определенным значением для ассоциированного атрибута.

Атрибут может быть либо обязательным, либо необязательным (рисунок 2.23).

Обязательность означает, что атрибут не может принимать неопределенных

значений (null values). Атрибут может быть либо описательным (т.е. обычным

дескриптором сущности), либо входить в состав уникального идентификатора

(первичного ключа).

Уникальный идентификатор - это атрибут или совокупность атрибутов и/или

связей, предназначенная для уникальной идентификации каждого экземпляра

данного типа сущности. В случае полной идентификации каждый экземпляр

данного типа сущности полностью идентифицируется своими собственными

ключевыми атрибутами, в противном случае в его идентификации участвуют

также атрибуты другой сущности-родителя (рисунок 2.24).

Рис. 2.23.

Рис. 2.24.

Каждый атрибут идентифицируется уникальным именем, выражаемым

грамматическим оборотом существительного, описывающим представляемую

атрибутом характеристику. Атрибуты изображаются в виде списка имен внутри

блока ассоциированной сущности, причем каждый атрибут занимает отдельную

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

выделяются знаком "#".

Каждая сущность должна обладать хотя бы одним возможным ключом. Возможный

ключ сущности - это один или несколько атрибутов, чьи значения однозначно

определяют каждый экземпляр сущности. При существовании нескольких

возможных ключей один из них обозначается в качестве первичного ключа, а

остальные - как альтернативные ключи.

С учетом имеющейся информации дополним построенную ранее диаграмму (рисунок

2.25).

Помимо перечисленных основных конструкций модель данных может содержать ряд

дополнительных.

Подтипы и супертипы: одна сущность является обобщающим понятием для группы

подобных сущностей (рисунок 2.26).

Взаимно исключающие связи: каждый экземпляр сущности участвует только в

одной связи из группы взаимно исключающих связей (рисунок 2.27).

Рис. 2.25.

Рис. 2.26. Подтипы и супертипы

Рис. 2.27. Взаимно исключающие связи

Рекурсивная связь: сущность может быть связана сама с собой (рисунок 2.28).

Неперемещаемые (non-transferrable) связи: экземпляр сущности не может быть

перенесен из одного экземпляра связи в другой (рисунок 2.29).

Рис. 2.29. Неперемещаемая связь

2.4.2. Методология IDEF1

Метод IDEF1, разработанный Т.Рэмей (T.Ramey), также основан на подходе

П.Чена и позволяет построить модель данных, эквивалентную реляционной

модели в третьей нормальной форме. В настоящее время на основе

совершенствования методологии IDEF1 создана ее новая версия - методология

IDEF1X. IDEF1X разработана с учетом таких требований, как простота изучения

и возможность автоматизации. IDEF1X-диаграммы используются рядом

распространенных CASE-средств (в частности, ERwin, Design/IDEF).

Сущность в методологии IDEF1X является независимой от идентификаторов или

просто независимой, если каждый экземпляр сущности может быть однозначно

идентифицирован без определения его отношений с другими сущностями.

Сущность называется зависимой от идентификаторов или просто зависимой, если

однозначная идентификация экземпляра сущности зависит от его отношения к

другой сущности (рисунок 2.30).

Рис. 2.30. Сущности

Каждой сущности присваивается уникальное имя и номер, разделяемые косой

чертой "/" и помещаемые над блоком.

Связь может дополнительно определяться с помощью указания степени или

мощности (количества экземпляров сущности-потомка, которое может

существовать для каждого экземпляра сущности-родителя). В IDEF1X могут быть

выражены следующие мощности связей:

каждый экземпляр сущности-родителя может иметь ноль, один или более

связанных с ним экземпляров сущности-потомка;

каждый экземпляр сущности-родителя должен иметь не менее одного связанного

с ним экземпляра сущности-потомка;

каждый экземпляр сущности-родителя должен иметь не более одного связанного

с ним экземпляра сущности-потомка;

каждый экземпляр сущности-родителя связан с некоторым фиксированным числом

экземпляров сущности-потомка.

Если экземпляр сущности-потомка однозначно определяется своей связью с

сущностью-родителем, то связь называется идентифицирующей, в противном

случае - неидентифицирующей.

Связь изображается линией, проводимой между сущностью-родителем и сущностью-

потомком с точкой на конце линии у сущности-потомка. Мощность связи

обозначается как показано на рис. 2.31 (мощность по умолчанию - N).

Рис. 2.31. Мощность связи

Идентифицирующая связь между сущностью-родителем и сущностью-потомком

изображается сплошной линией (рисунок 2.32). Сущность-потомок в

идентифицирующей связи является зависимой от идентификатора сущностью.

Сущность-родитель в идентифицирующей связи может быть как независимой, так

и зависимой от идентификатора сущностью (это определяется ее связями с

другими сущностями).

Рис. 2.32. Идентифицирующая связь

Пунктирная линия изображает неидентифицирующую связь (рисунок 2.33).

Сущность-потомок в неидентифицирующей связи будет независимой от

идентификатора, если она не является также сущностью-потомком в какой-либо

идентифицирующей связи.

Рис. 2.33. Неидентифицирующая связь

Атрибуты изображаются в виде списка имен внутри блока сущности. Атрибуты,

определяющие первичный ключ, размещаются наверху списка и отделяются от

других атрибутов горизонтальной чертой (рисунок 2.34).

Рис. 2.34. Атрибуты и первичные ключи

Сущности могут иметь также внешние ключи (Foreign Key), которые могут

использоваться в качестве части или целого первичного ключа или неключевого

атрибута. Внешний ключ изображается с помощью помещения внутрь блока

сущности имен атрибутов, после которых следуют буквы FK в скобках (рисунок

2.35).

Рис. 2.35. Примеры внешних ключей

3. Характеристики CASE-средств

3.1. Silverrun+JAM

3.1.1. Silverrun

CASE-средство Silverrun американской фирмы Сomputer Systems Advisers, Inc.

(CSA) используется для анализа и проектирования ИС бизнес-класса [22] и

ориентировано в большей степени на спиральную модель ЖЦ. Оно применимо для

поддержки любой методологии, основанной на раздельном построении

функциональной и информационной моделей (диаграмм потоков данных и диаграмм

"сущность-связь").

Настройка на конкретную методологию обеспечивается выбором требуемой

графической нотации моделей и набора правил проверки проектных

спецификаций. В системе имеются готовые настройки для наиболее

распространенных методологий: DATARUN (основная методология, поддерживаемая

Silverrun), Gane/Sarson, Yourdon/DeMarco, Merise, Ward/Mellor, Information

Engineering. Для каждого понятия, введенного в проекте имеется возможность

добавления собственных описателей. Архитектура Silverrun позволяет

наращивать среду разработки по мере необходимости.

Структура и функции

Silverrun имеет модульную структуру и состоит из четырех модулей, каждый из

которых является самостоятельным продуктом и может приобретаться и

использоваться без связи с остальными модулями.

Модуль построения моделей бизнес-процессов в форме диаграмм потоков данных

(BPM - Business Process Modeler) позволяет моделировать функционирование

обследуемой организации или создаваемой ИС. В модуле BPM обеспечена

возможность работы с моделями большой сложности: автоматическая

перенумерация, работа с деревом процессов (включая визуальное

перетаскивание ветвей), отсоединение и присоединение частей модели для

коллективной разработки. Диаграммы могут изображаться в нескольких

предопределенных нотациях, включая Yourdon/DeMarco и Gane/Sarson. Имеется

также возможность создавать собственные нотации, в том числе добавлять в

число изображаемых на схеме дескрипторов определенные пользователем поля.

Модуль концептуального моделирования данных (ERX - Entity-Relationship

eXpert) обеспечивает построение моделей данных "сущность-связь", не

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

экспертную систему, позволяющую создать корректную нормализованную модель

данных посредством ответов на содержательные вопросы о взаимосвязи данных.

Возможно автоматическое построение модели данных из описаний структур

данных. Анализ функциональных зависимостей атрибутов дает возможность

проверить соответствие модели требованиям третьей нормальной формы и

обеспечить их выполнение. Проверенная модель передается в модуль RDM.

Модуль реляционного моделирования (RDM - Relational Data Modeler) позволяет

создавать детализированные модели "сущность-связь", предназначенные для

реализации в реляционной базе данных. В этом модуле документируются все

конструкции, связанные с построением базы данных: индексы, триггеры,

хранимые процедуры и т.д. Гибкая изменяемая нотация и расширяемость

репозитория позволяют работать по любой методологии. Возможность создавать

подсхемы соответствует подходу ANSI SPARC к представлению схемы базы

данных. На языке подсхем моделируются как узлы распределенной обработки,

так и пользовательские представления. Этот модуль обеспечивает

проектирование и полное документирование реляционных баз данных.

Менеджер репозитория рабочей группы (WRM - Workgroup Repository Manager)

применяется как словарь данных для хранения общей для всех моделей

информации, а также обеспечивает интеграцию модулей Silverrun в единую

среду проектирования.

Платой за высокую гибкость и разнообразие изобразительных средств

построения моделей является такой недостаток Silverrun, как отсутствие

жесткого взаимного контроля между компонентами различных моделей (например,

возможности автоматического распространения изменений между DFD различных

уровней декомпозиции). Следует, однако, отметить, что этот недостаток может

иметь существенное значение только в случае использования каскадной модели

ЖЦ ПО.

Взаимодействие с другими средствами

Для автоматической генерации схем баз данных у Silverrun существуют мосты к

наиболее распространенным СУБД: Oracle, Informix, DB2, Ingres, Progress,

SQL Server, SQLBase, Sybase. Для передачи данных в средства разработки

приложений имеются мосты к языкам 4GL: JAM, PowerBuilder, SQL Windows,

Uniface, NewEra, Delphi. Все мосты позволяют загрузить в Silverrun RDM

информацию из каталогов соответствующих СУБД или языков 4GL. Это позволяет

документировать, перепроектировать или переносить на новые платформы уже

находящиеся в эксплуатации базы данных и прикладные системы. При

использовании моста Silverrun расширяет свой внутренний репозиторий

специфичными для целевой системы атрибутами. После определения значений

этих атрибутов генератор приложений переносит их во внутренний каталог

среды разработки или использует при генерации кода на языке SQL. Таким

образом можно полностью определить ядро базы данных с использованием всех

возможностей конкретной СУБД: триггеров, хранимых процедур, ограничений

ссылочной целостности. При создании приложения на языке 4GL данные,

перенесенные из репозитория Silverrun, используются либо для автоматической

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

Для обмена данными с другими средствами автоматизации проектирования,

создания специализированных процедур анализа и проверки проектных

спецификаций, составления специализированных отчетов в соответствии с

различными стандартами в системе Silverrun имеется три способа выдачи

проектной информации во внешние файлы:

Система отчетов. Можно, определив содержимое отчета по репозиторию, выдать

отчет в текстовый файл. Этот файл можно затем загрузить в текстовый

редактор или включить в другой отчет;

Система экспорта/импорта. Для более полного контроля над структурой файлов

в системе экспорта/импорта имеется возможность определять не только

содержимое экспортного файла, но и разделители записей, полей в записях,

маркеры начала и конца текстовых полей. Файлы с указанной структурой можно

не только формировать, но и загружать в репозиторий. Это дает возможность

обмениваться данными с различными системами: другими CASE-средствами, СУБД,

текстовыми редакторами и электронными таблицами;

Хранение репозитория во внешних файлах через ODBC-драйверы. Для доступа к

данным репозитория из наиболее распространенных систем управления базами

данных обеспечена возможность хранить всю проектную информацию

непосредственно в формате этих СУБД.

Групповая работа

Групповая работа поддерживается в системе Silverrun двумя способами:

В стандартной однопользовательской версии имеется механизм контролируемого

разделения и слияния моделей. Разделив модель на части, можно раздать их

нескольким разработчикам. После детальной доработки модели объединяются в

единые спецификации;

Сетевая версия Silverrun позволяет осуществлять одновременную групповую

работу с моделями, хранящимися в сетевом репозитории на базе СУБД Oracle,

Sybase или Informix. При этом несколько разработчиков могут работать с

одной и той же моделью, так как блокировка объектов происходит на уровне

отдельных элементов модели.

Среда функционирования

Имеются реализации Silverrun трех платформ - MS Windows, Macintosh и OS/2

Presentation Manager - с возможностью обмена проектными данными между ними.

Для функционирования в среде Windows необходимо иметь компьютер с

процессором модели не ниже i486 и оперативную память объемом не менее 8 Мб

(рекомендуется 16 Мб). На диске полная инсталляция Silverrun занимает 20

Мб.

3.1.2. JAM

Средство разработки приложений JAM [28] (JYACC's Application Manager) -

продукт фирмы JYACC (США). В настоящее время поставляется версия JAM 7 и

готовится к выходу JAM 8.

Основной чертой JAM является его соответствие методологии RAD, поскольку он

позволяет достаточно быстро реализовать цикл разработки приложения,

заключающийся в формировании очередной версии прототипа приложения с учетом

требований, выявленных на предыдущем шаге, и предъявить его пользователю.

Структура и функции

JAM имеет модульную структуру и состоит из следующих компонент:

Ядро системы;

JAM/DBi - специализированные модули интерфейса к СУБД (JAM/DBi-Oracle,

JAM/DBi-Informix, JAM/DBi-ODBC и т.д.);

JAM/RW - модуль генератора отчетов;

JAM/CASEi - специализированные модули интерфейса к CASE-средствам (JAM/CASE-

TeamWork, JAM/CASE-Innovator и т.д.);

JAM/TPi - специализированные модули интерфейса к менеджерам транзакций

(например, JAM/TPi-Server TUXEDO и т.д.);

Jterm - специализированный эмулятор X-терминала.

Ядро системы (собственно, сам JAM) является законченным продуктом и может

самостоятельно использоваться для разработки приложений. Все остальные

модули являются дополнительными и самостоятельно использоваться не могут.

Ядро системы включает в себя следующие основные компоненты:

редактор экранов. В состав редактора экранов входят: среда разработки

экранов, визуальный репозиторий объектов, собственная СУБД JAM - JDB,

менеджер транзакций, отладчик, редактор стилей;

редактор меню;

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

средства изготовления промышленной версии приложения.

При использовании JAM разработка внешнего интерфейса приложения

представляет собой визуальное проектирование и сводится к созданию экранных

форм путем размещения на них интерфейсных конструкций и определению

экранных полей ввода/вывода информации. Проектирование интерфейса в JAM

осуществляется с помощью редактора экранов. Приложения, разработанные в

JAM, имеют многооконный интерфейс. Разработка отдельного экрана заключается

в размещении на нем интерфейсных элементов, возможной (но не обязательной)

их группировке и конкретизации различных их свойств, включающих визуальные

характеристики (позиция, размер, цвет, шрифт и т.п.), поведенческие

характеристики (многообразные фильтры, форматы, защита от ввода и т.п.) и

ряд свойств, ориентированных на работу с БД.

Редактор меню позволяет разрабатывать и отлаживать системы меню.

Реализована возможность построения пиктографических меню (так называемые

toolbar). Назначение каждого конкретного меню тому или иному объекту

приложения осуществляется в редакторе экранов.

В ядро JAM встроена однопользовательская реляционная СУБД JDB. Основным

назначением JDB является прототипирование приложений в тех случаях, когда

работа со штатной СУБД невозможна или нецелесообразна. В JDB реализован

необходимый минимум возможностей реляционных СУБД за исключением индексов,

хранимых процедур, триггеров и представлений (view). С помощью JDB можно

построить БД, идентичную целевой БД (с точностью до отсутствующих в JDB

возможностей) и разработать значительную часть приложения.

Отладчик позволяет проводить комплексную отладку разрабатываемого

приложения. Осуществляется трассировка всех событий, возникающих в процессе

исполнения приложения.

Утилиты JAM включают три группы:

конверторы файлов экранов JAM в текстовые. JAM сохраняет экраны в виде

двоичных файлов собственного формата. В ряде случаев (например для

изготовления программной документации проекта) необходимо текстовое

описание экранов;

конфигурирование устройств ввода/вывода. JAM и приложения, построенные с

его помощью, не работают непосредственно с устройствами ввода/вывода.

Вместо этого JAM обращается к логическим устройствам ввода/вывода

(клавиатура, терминал, отчет). Отображение логических устройств в

физические осуществляется с помощью средств конфигурирования;

обслуживание библиотек экранов (традиционные операции с библиотеками).

Одним из дополнительных модулей JAM является генератор отчетов. Компоновка

отчета осуществляется в редакторе экранов JAM. Описание работы отчета

осуществляется с помощью специального языка. Генератор отчетов позволяет

определить данные, выводимые в отчет, группировку выводимой информации,

форматирование вывода и др.

Приложения, разработанные с использованием JAM, не требуют так называемых

исполнительных (run-time) систем и могут быть изготовлены в виде

исполняемых модулей. Для этого разработчик должен иметь компилятор C и

редактор связей. Для изготовления промышленной версии в состав JAM входит

файл сборки (makefile), исходные тексты (на языке C) ряда модулей

приложения и необходимые библиотеки.

JAM содержит встроенный язык программирования JPL (JAM Procedural

Language), с помощью которого в случае необходимости можно написать модули,

реализующие специфические действия. Данный язык является интерпретируемым,

что упрощает отладку. Существует возможность обмена информацией между

средой визуально построенного приложения и такими модулями. Кроме того, в

JAM реализована возможность подключения внешних модулей, написанных на

каком-либо языке, совместимым по вызовам функций с языком C.

С точки зрения реализации логики приложения JAM является событийно-

ориентированной системой. В JAM определен набор событий, включающий

открытие и закрытие окон, нажатие клавиши клавиатуры, срабатывание

системного таймера, получение и передача управления каждым элементом

экрана. Разработчик реализует логику приложения путем определения

обработчика каждого события. Например, обработчик события "нажатие кнопки

на экране" (мышью или с помощью клавиатуры) может открыть следующее

экранное окно. Обработчиками событий в JAM могут быть как встроенные

функции JAM, так и функции, написанные разработчиком на C или JPL. Набор

встроенных функций включает в себя более 200 функций различного назначения.

Встроенные функции доступны для вызовов из функций, написанных как на JPL,

так и на C.

Промышленная версия приложения, разработанного с помощью JAM, включает в

себя следующие компоненты:

исполняемый модуль интерпретатора приложения. В этот модуль могут быть

встроены функции, написанные разработчиками на языках 3-го поколения;

экраны, составляющие само приложение (могут поставляться в виде отдельных

файлов, в составе библиотек экранов или же быть встроены в тело

интерпретатора);

внешние JPL-модули. Могут поставляться в виде текстовых файлов или в

прекомпилированном виде, причем прекомпилированные внешние JPL-модули могут

быть как в виде отдельных файлов, так и в составе библиотек экранов;

файлы конфигурации приложения - файлы конфигурации клавиатуры и терминала,

файл системных сообщений, файл общей конфигурации.

Взаимодействие с другими средствами

Непосредственное взаимодействие с СУБД реализуют модули JAM/DBi (Data Base

interface). Способы реализации взаимодействия в JAM разделяются на два

класса: ручные и автоматические. При ручном способе разработчик приложения

самостоятельно пишет запросы на SQL, в которых как источниками, так и

адресатами приема результатов выполнения запроса могут быть как

интерфейсные элементы визуально спроектированного внешнего уровня, так и

внутренние, невидимые для конечного пользователя переменные. Автоматический

режим, реализуемый менеджером транзакций JAM, осуществим для типовых и

наиболее распространенных видов операций с БД, так называемых QBE (Query By

Example - запросы по образцу), с учетом достаточно сложных взаимосвязей

между таблицами БД и автоматическим управлением атрибутами экранных полей

ввода/вывода в зависимости от вида транзакции (чтение, запись и т.д.), в

которой участвует сгенерированный запрос.

JAM позволяет строить приложения для работы более чем с 20 СУБД: ORACLE,

Informix, Sybase, Ingres, InterBase, NetWare SQL Server, Rdb, DB2, ODBC-

совместимые СУБД и др.

Отличительной чертой JAM является высокий уровень переносимости приложений

между различными платформами (MS DOS/MS Windows, SunOS, Solaris (i80x86,

SPARC), HP-UX, AIX, VMS/Open VMS и др.). Может потребоваться лишь

"перерисовать" статические текстовые поля на экранах с русским текстом при

переносе между средами DOS-Windows-UNIX. Кроме того, переносимость

облегчается тем, что в JAM приложения разрабатываются для виртуальных

устройств ввода/вывода, а не для физических. Таким образом при переносе

приложения с платформы на платформу, как правило, требуется лишь определить

соответствие между физическими устройствами ввода/вывода и их логическими

представлениями для приложения.

Использование SQL в качестве средства взаимодействия с СУБД также создает

предпосылки для обеспечения переносимости между СУБД. При условии переноса

структуры самой БД в ряде случаев приложения могут не требовать никакой

модификации, за исключением инициализации сеанса работы. Такая ситуация

может сложиться в том случае, если в приложении не использовались

специфические для той или иной СУБД расширения SQL.

При росте нагрузки на систему и сложности решаемых задач (распределенность

и гетерогенность используемых ресурсов, количество одновременно

подключенных пользователей, сложность логики приложения) применяется

трехзвенная модель архитектуры "клиент-сервер" с использованием менеджеров

транзакций. Компоненты JAM/TPi-Client и JAM/TPi-Server позволяют достаточно

просто перейти на трехзвенную модель. При этом ключевую роль играет модуль

JAM/TPi-Server, так как основная трудность внедрения трехзвенной модели

заключается в реализации логики приложения в сервисах менеджеров

транзакций.

Интерфейс JAM/CASE подобен интерфейсу к СУБД и позволяет осуществить обмен

информацией между репозиторием объектов JAM и репозиторием CASE-средства

аналогично тому, как структура БД импортируется в репозиторий JAM

непосредственно из БД. Отличие заключается в том, что в случае интерфейса к

CASE этот обмен является двунаправленным. Кроме модулей JAM/CASEi,

существует также модуль JAM/CASEi Developer's Kit. С помощью этого модуля

можно самостоятельно разработать интерфейс (т.е. специализированный модуль

JAM/CASEi) для конкретного CASE-средства, если готового модуля JAM/CASEi

для него не существует.

Мост (интерфейс) Silverrun-RDM JAM реализует взаимодействие между CASE-

средством Silverrun и JAM (перенос схемы базы данных и экранных форм

приложения между CASE-средством Silverrun-RDM и JAM версии 7.0). Данный

программный продукт имеет 2 режима работы:

прямой режим (Silverrun-RDM->JAM) предназначен для создания объектов CASE-

словаря и элементов репозитория JAM на основе представления схем в

Silverrun-RDM. В этом режиме мост позволяет, исходя из представления

моделей данных интерфейса в Silverrun-RDM, производить генерацию экранов и

элементов репозитория JAM. Мост преобразует таблицы и отношения реляционных

схем RDM в последовательность объектов JAM соответствующих типов. Методика

построения моделей данных интерфейса в Silverrun-RDM предполагает

применение механизма подсхем для прототипирования экранов приложения. По

описанию каждой из подсхем RDM мост генерирует экранную форму JAM;

обратный режим (JAM->Silverrun-RDM) предназначен для переноса модификаций

объектов CASE-словаря в реляционную модель Silverrun-RDM.

Режим реинжиниринга позволяет переносить модификации всех свойств экранов

JAM, импортированных ранее из RDM, в схему Silverrun. На этом этапе для

контроля целостности базы данных не допускаются изменения схемы в виде

добавления или удаления таблиц и полей таблиц.

Групповая работа

Ядро JAM имеет встроенный интерфейс к средствам конфигурационного

управления (PVCS на платформе Windows и SCCS на платформе UNIX). Под

управлением этих систем передаются библиотеки экранов и/или репозитории.

При отсутствии таких систем JAM самостоятельно реализует часть функций

поддержки групповой разработки.

Использование PVCS (см. подраздел 3.6) является более предпочтительным по

сравнению с SCCS, так как позволяет организовать единый архив модулей

проекта для всех платформ. Так как JAM на платформе UNIX не имеет прямого

интерфейса к архивам PVCS, то выборка модулей из архива и возврат их в

архив производятся с использованием PVCS Version Manager. На платформе MS-

Windows JAM имеет встроенный интерфейс к PVCS и действия по

выборке/возврату производятся непосредственно из среды JAM.

Среда функционирования

JAM, как среда разработки, и приложения, построенные с его использованием,

не являются ресурсоемкими системами. Например, на платформе MS-Windows

достаточно иметь 8MB оперативной памяти и 50 MB дискового пространства для

среды разработки. На UNIX-платформах требования к аппаратуре определяются

самой операционной системой.

3.2. Vantage Team Builder (Westmount I-CASE) + Uniface

3.2.1. Vantage Team Builder (Westmount I-CASE)

Vantage Team Builder [14] представляет собой интегрированный программный

продукт, ориентированный на реализацию каскадной модели ЖЦ ПО и поддержку

полного ЖЦ ПО.

Структура и функции

Vantage Team Builder обеспечивает выполнение следующих функций:

проектирование диаграмм потоков данных, "сущность-связь", структур данных,

структурных схем программ и последовательностей экранных форм;

проектирование диаграмм архитектуры системы - SAD (проектирование состава и

связи вычислительных средств, распределения задач системы между

вычислительными средствами, моделирование отношений типа "клиент-сервер",

анализ использования менеджеров транзакций и особенностей функционирования

систем в реальном времени);

генерация кода программ на языке 4GL целевой СУБД с полным обеспечением

программной среды и генерация SQL-кода для создания таблиц БД, индексов,

ограничений целостности и хранимых процедур;

программирование на языке C со встроенным SQL;

управление версиями и конфигурацией проекта;

многопользовательский доступ к репозиторию проекта;

генерация проектной документации по стандартным и индивидуальным шаблонам;

экспорт и импорт данных проекта в формате CDIF (CASE Data Interchange

Format).

Vantage Team Builder поставляется в различных конфигурациях в зависимости

от используемых СУБД (ORACLE, Informix, Sybase или Ingres) или средств

разработки приложений (Uniface). Конфигурация Vantage Team Builder for

Uniface отличается от остальных некоторой степенью ориентации на спиральную

модель ЖЦ ПО за счет возможностей быстрого прототипирования,

предоставляемых Uniface. Для описания проекта ИС используется достаточно

большой набор диаграмм, конкретные варианты которого для наиболее

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

|Сущность-свя|ERD |+ |+ |+ |

|зь | | | | |

|Потоков |DFD |+ |+ |+ |

|Структур |DSD |+ |+ |+ |

|Архитектуры |SAD |+ |+ |+ |

|Потоков |CSD |+ |+ |+ |

|Типов данных|DTD |+ |+ |+ |

|Структуры |MSD |+ | | |

|Последовател|BSD |+ | | |

|Последовател|FSD | |+ |+ |

|Содержимого |FCD | |+ |+ |

|Переходов |STD |+ |+ |+ |

|Структурных |SCD |+ |+ |+ |

При построении всех типов диаграмм обеспечивается контроль соответствия

моделей синтаксису используемых методов, а также контроль соответствия

одноименных элементов и их типов для различных типов диаграмм.

Страницы: 1, 2, 3, 4

Рефераты

Case-технлогии