Case-технлогии

SQLWindows и ObjectPro). Основной вариант - Rational Rose/C++ - позволяет

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

также генерировать программные коды на С++. Кроме того, Rational Rose

содержит средства реинжиниринга программ, обеспечивающие повторное

использование программных компонент в новых проектах.

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

В основе работы Rational Rose лежит построение различного рода диаграмм и

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

статические и динамические аспекты. В их число входят диаграммы классов,

состояний, сценариев, модулей, процессов [21].

В составе Rational Rose можно выделить 6 основных структурных компонент:

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

(browser), средства контроля проекта, средства сбора статистики и генератор

документов. К ним добавляются генератор кодов (индивидуальный для каждого

языка) и анализатор для С++, обеспечивающий реинжиниринг - восстановление

модели проекта по исходным текстам программ.

Репозиторий представляет собой объектно-ориентированную базу данных.

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

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

диаграмм к другому и т. д. Средства контроля и сбора статистики дают

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

после завершения его описания. Генератор отчетов формирует тексты выходных

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

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

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

формируют файлы заголовков и файлы описаний классов и объектов. Создаваемый

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

программирования на языке С++. Анализатор кодов С++ реализован в виде

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

создавать модули проектов в форме Rational Rose на основе информации,

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

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

текстов и диагностику ошибок. Модель, полученная в результате его работы,

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

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

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

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

элементы выходной модели следует выводить на экран. Таким образом, Rational

Rose/С++ обеспечивает возможность повторного использования программных

компонент.

В результате разработки проекта с помощью CASE-средства Rational Rose

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

диаграммы классов;

диаграммы состояний;

диаграммы сценариев;

диаграммы модулей;

диаграммы процессов;

спецификации классов, объектов, атрибутов и операций

заготовки текстов программ;

модель разрабатываемой программной системы.

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

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

всех диаграмм и спецификаций).

Тексты программ являются заготовками для последующей работы программистов.

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

содержащие описания классов) и .cpp (заготовки программ для методов).

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

начинаются с последовательности символов //##. Состав информации,

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

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

программистами в полноценные программы.

Взаимодействие с другими средствами и организация групповой работы

Rational Rose интегрируется со средством PVCS для организации групповой

работы и управления проектом и со средством SoDA - для документирования

проектов. Интеграция Rational Rose и SoDA обеспечивается средствами SoDA.

Для организации групповой работы в Rational Rose возможно разбиение модели

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

загружается в модель. В качестве подмодели может выступать категория

классов или подсистема.

Для управляемой подмодели предусмотрены операции:

загрузка подмодели в память;

выгрузка подмодели из памяти;

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

установка защиты от модификации;

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

Наиболее эффективно групповая работа организуется при интеграции Rational

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

(PVCS). В этом случае защита от модификации устанавливается на все

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

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

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

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

окажутся невозможными.

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

Rational Rose функционирует на различных платформах: IBM PC (в среде

Windows), Sun SPARC stations (UNIX, Solaris, SunOS), Hewlett-Packard (HP

UX), IBM RS/6000 (AIX).

Для работы системы необходимо выполнение следующих требований:

Платформа Windows - процессор 80386SX или выше (рекомендуется 80486),

память8Mб (рекомендуется 12Mб), пространство на диске 8Mб + 1-3Mб для одной

модели.

Платформа UNIX - память 32+(16*число пользователей)Mб, пространство на

диске 30Mб + 20 при инсталляции + 1-3Mб для одной модели.

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

3.6. Вспомогательные средства поддержки жизненного цикла ПО

3.6.1. Средства конфигурационного управления

Цель конфигурационного управления (КУ) - обеспечить управляемость и

контролируемость процессов разработки и сопровождения ПО. Для этого

необходима точная и достоверная информация о состоянии ПО и его компонент в

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

изменениях.

Для решения задач КУ применяются методы и средства обеспечивающие

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

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

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

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

Наиболее распространенным средством КУ является PVCS фирмы Intersolv (США),

включающее ряд самостоятельных продуктов: PVCS Version Manager, PVCS

Tracker, PVCS Configuration Builder и PVCS Notify.

PVCS Version Manager [18] предназначен для управления всеми компонентами

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

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

локальных сетей. Понятие "проект" трактуется как совокупность файлов. В

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

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

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

этого, фиксируются имена разработчиков, ответственных за тот или иной файл,

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

при необходимости к какому-либо из предыдущих состояний файла (например,

при обнаружении ошибки, которую в данный момент трудно исправить).

PVCS Version Manager предназначен для использования в рабочих группах.

Система блокировок, реализованная в PVCS Version Manager позволяет

предотвратить одновременное внесение изменений в один и тот же файл. В то

же время, PVCS Version Manager позволяет разработчикам работать с

собственными версиями общего файла с полуавтоматическим разрешением

конфликтов между ними.

Доступ к архивам PVCS Version Manager возможен не только через сам Version

Manager, но и из более чем 50 инструментальных средств, в том числе MS

Visual C и MS Visual Basic, Uniface, PowerBuilder, SQL Windows, JAM,

Delphi, Paradox и др.

Результатом работы PVCS Version Manager является созданный средствами

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

версии программного продукта вместе с необходимыми комментариями и метками.

PVCS Version Manager функционирует в среде MS Windows, Windows 95, Windows

NT, OS/2, SunOS, Solaris, HP-UX, AIX и SCO UNIX и может исполняться на

любом персональном компьютере с процессором 80386 или выше, рабочих

станциях Sun, HP и IBM (RS-6000).

Другим средством конфигурационного управления является PVCS Tracker [19] -

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

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

исполнителям и контроля за исполнением. Интеграция с PVCS Version Manager

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

Отчетные возможности PVCS Tracker включают множество разновидностей

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

срезы по различным компонентам проекта, разработчикам и тестировщикам. С их

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

временные тенденции.

Персонал, работающий с PVCS Tracker делится на пять групп в зависимости от

их обязанностей: пользователи, разработчики, группа тестирования и контроля

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

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

групп PVCS Tracker:

пользователи (Submitters) - имеют ограниченные права на внесение замечаний

и сообщений об ошибках в базу данных PVCS Tracker;

разработчики (Development Engineers) - имеют право производить основные

операции с требованиями и замечаниями в базе данных PVCS Tracker. Если

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

заданы отдельные списки прав доступа;

тестировщики (Quality Engineers) - имеют право производить основные

операции с требованиями и замечаниями;

сопровождение (Support Engineers) - имеют право вносить любые замечания,

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

работ и изменению их приоритетности и сроков исполнения;

руководители (Managers) - имеют право распределять работы между

исполнителями и принимать решения о их надлежащем исполнении. Руководителям

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

Tracker.

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

администратора базы данных и 11 дополнительных групп, которые могут быть

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

сотрудников, использующих PVCS Tracker.

Требование или замечание поступающее в PVCS Tracker проходит четыре этапа

обработки:

регистрация - внесение замечания в базу данных;

распределение - назначение ответственного исполнителя и сроков исполнения;

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

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

приемка - приемка работ и снятие их с контроля или направление на

доработку.

Требования и замечания, поступающие в базу данных PVCS Tracker оформляются

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

стандартных значений и до 12 произвольных текстовых строк. При разработке

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

записей в базе данных.

Для получения содержательной информации о ходе разработки PVCS Tracker

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

диаграммы распределения.

Частотные отчеты содержат информацию о частоте поступающих замечаний за

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

частотного отчета не существует, т.к. на оценку качества влияют тип методов

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

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

к полной остановке разработки, хуже большого числа замечаний к внешнему

виду интерфейса пользователя. Следовательно, частотные отчеты должны быть

настроены на выявление какого-либо конкретного аспекта качества для того,

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

проектом.

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

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

Они позволяют ответить на вопросы:

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

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

процесса;

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

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

и т.п.

Диаграммы распределения - наиболее разнообразные и полезные для

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

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

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

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

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

уделено недостаточно внимания и т.д.

PVCS Tracker предназначен для использования в рабочих группах, объединенных

в общую сеть. В этом случае центральная база или проект PVCS Tracker

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

посредством ODBC-драйверов, входящих в состав PVCS Tracker. Главной

особенностью PVCS Tracker по сравнению с обычным приложением СУБД является

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

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

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

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

электронную почту.

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

взаимодействует с СУБД dBase, ORACLE, SQL Server и SYBASE посредством ODBC.

PVCS Tracker может быть интегрирован с любой системой электронной почты,

поддерживающей стандарты VIM, MAPI или SMTP.

PVCS Version Manager и PVCS Tracker окружены вспомогательными компонентами:

PVCS Configuration Builder и PVCS Notify.

PVCS Configuration Builder предназначен для сборки окончательного продукта

из компонент проекта. PVCS Configuration Builder позволяет описывать

процесс сборки как на стандартном языке MAKE, так и на собственном

внутреннем языке, имеющем существенно большие возможности. PVCS

Configuration Builder позволяет осуществлять сборку программного продукта

на основании файлов, хранящихся в репозитории PVCS Version Manager.

Обычная процедура сборки программного продукта с помощью PVCS Configuration

Builder состоит из трех шагов:

строится файл зависимостей между исходными модулями;

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

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

Результатом работы PVCS Configuration Builder является специальный файл,

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

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

PVCS Notify обеспечивает автоматическую рассылку сообщений об ошибках из

базы данных пакета PVCS Tracker по рабочим станциям назначения. При этом

используется офисная система электронной почты cc:Mail или Microsoft Mail.

PVCS Notify расширяет возможности PVCS Tracker и используется только

совместно с ним.

PVCS Notify настраивается из среды PVCS Tracker. Настройка включает в себя

определение интервала времени, через который PVCS Notify проверяет

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

уведомлений, определение списков адресов для рассылки. После настройки PVCS

Notify начинает работу в автономном режиме, автоматически рассылая

уведомления об изменениях в базе данных PVCS Tracker.

PVCS Notify предназначен для использования в больших рабочих группах, часть

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

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

программного продукта, замечаниях, ошибках, ходе и результатах его

тестирования.

Результатом работы PVCS Notify являются оформленные в соответствии с одним

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

электронной почты.

3.6.2. Средства документирования

Для создания документации в процессе разработки ИС используются

разнообразные средства формирования отчетов, а также компоненты

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

CASE-средства. Исключением являются некоторые пакеты, предоставляющие

дополнительный сервис при документировании. Из них наиболее активно

используется SoDA (Software Document Аutomation).

Продукт SoDA предназначен для автоматизации разработки проектной

документации на всех фазах ЖЦ ПО. Он позволяет автоматически извлекать

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

и включать ее в выходные документы. При этом контролируется соответствие

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

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

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

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

приложениями осуществляется через стандартный программный интерфейс API.

Переход на новые инструментальные средства не влечет за собой

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

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

программное обеспечение DOD 2167A. На их основе можно без специального

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

пользователями.

Пакет включает в себя графический редактор для подготовки шаблонов

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

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

извлекаемая из разнообразных источников информация. Изменения автоматически

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

программе. Это сокращает время подготовки документации за счет отказа от

перегенерации всей документации.

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

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

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

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

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

Разные виды документации, сопровождающие различные этапы ЖЦ, связаны между

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

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

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

книга). Документ может храниться в файле формата SoDA (Frame Builder),

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

документа (или его части) возможен из системы SoDA.

Среда функционирования SoDA - ОС типа UNIX на рабочих станциях Sun

SPARCstation, IBM RISC System/6000 или Hewlett Packard HP 9000 700/800.

SoDA требует по крайней мере 32 MB оперативной памяти, 100-300 MB для

установки и 64 MB рабочего пространства на диске.

3.6.3. Средства тестирования

Под тестированием понимается процесс исполнения программы с целью

обнаружения ошибок. Регрессионное тестирование - это тестирование,

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

изменений.

Одно из наиболее развитых средств тестирования QA (новое название - Quality

Works) [20] представляет собой интегрированную, многоплатформенную среду

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

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

QA позволяет начинать тестирование на любой фазе ЖЦ, планировать и

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

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

Основными компонентами QA являются:

QA Partner - среда для разработки, компиляции и выполнения тестов;

QA Planner - модуль для разработки планов тестирования и обработки

результатов. Для создания и выполнения тестов в процессе работы QA Planner

вызывается QA Partner;

Agent - модуль, поддерживающий работу в сети.

Процесс тестирования состоит из следующих этапов:

создание плана тестирования;

связывание плана с тестами;

пометка и выполнение тестов;

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

Создание тестового плана в QA Planner включает в себя составление схемы

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

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

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

функции и характеристики, определить, сколько из них будет реализовано в

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

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

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

(скрипты) на специальном языке 4Test и тесты, которые выполняют требования

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

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

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

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

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

неудавшиеся тесты, сравнить результаты предыдущего выполнения тестов,

выполнить или отменить отчет.

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

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

Комплекс QA занимает на жестком диске не более 21МВ. Поддерживаемые

платформы: Windows 3.x, Windows 95, Windows NT, OS/2, Macintosh, VMS, HP-

UX, AIX, Solaris.

3.7. Примеры комплексов CASE-средств

В заключение приведем примеры комплексов CASE-средств обеспечивающих

поддержку полного ЖЦ ПО. Здесь хотелось бы еще раз отметить

нецелесообразность сравнения отдельно взятых CASE-средств, поскольку ни

одно из них не решает в целом все проблемы создания и сопровождения ПО. Это

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

затрагивают все этапы ЖЦ ПО. Сравниваться могут комплексы методологически и

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

полный ЖЦ ПО и обеспеченные необходимой технической и методической

поддержкой со стороны фирм-поставщиков. По мнению автора, на сегодняшний

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

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

основанный на методологии и технологии DATARUN. В состав комплекса входят

следующие инструментальные средства:

CASE-средство Silverrun;

средство разработки приложений JAM;

мост Silverrun-RDM JAM;

комплекс средств тестирования QA;

менеджер транзакций Tuxedo;

комплекс средств планирования и управления проектом SE Companion;

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

объектно-ориентированное CASE-средство Rational Rose;

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

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

Vantage Team Builder for Uniface + Uniface (фирмы "DataX/Florin" и

"ЛАНИТ");

комплекс средств, поставляемых и используемых фирмой "ФОРС":

CASE-средства Designer/2000 (основное), ERwin, Bpwin и Oowin (альтернатив-

ные);

средства разработки приложений Developer/2000, ORACLE Power Objects (ос-

новные) и Usoft Developer (альтернативное);

средство настройки и оптимизации ExplainSQL (Platinum);

cредства администрирования и сопровождения SQLWatch, DBVision, SQL Spy,

TSReorg и др. (Platinum);

средство документирования ORACLE Book.

комплекс средств на основе продуктов фирмы CENTURA:

CASE-средства ERwin, Bpwin и Oowin (объектно-ориентированный анализ);

средства разработки приложений SQLWindows и TeamWindows;

средство тестирования и оптимизации приложений "клиент-сервер" SQLBench

(ARC);

cредства эксплуатации и сопровождения Quest и Crystal Reports.

Литература

1. Вендров А.М. Один из подходов к выбору средств проектирования баз

данных и приложений. "СУБД", 1995, №3.

2. Зиндер Е.З. Бизнес-реинжиниринг и технологии системного

проектирования. Учебное пособие. М., Центр Информационных Технологий,

1996

3. Калянов Г.Н. CASE. Структурный системный анализ (автоматизация и

применение). М., "Лори", 1996.

4. Марка Д.А., МакГоуэн К. Методология структурного анализа и

проектирования. М., "МетаТехнология", 1993.

5. Международные стандарты, поддерживающие жизненный цикл программных

средств. М., МП "Экономика", 1996

6. Создание информационной системы предприятия. "Computer Direct", 1996,

N2

7. Шлеер С., Меллор С. Объектно-ориентированный анализ: моделирование

мира в состояниях. Киев, "Диалектика", 1993.

8. Barker R. CASE*Method. Entity-Relationship Modelling. Copyright Oracle

Corporation UK Limited, Addison-Wesley Publishing Co., 1990.

9. Barker R. CASE*Method. Function and Process Modelling. Copyright

Oracle Corporation UK Limited, Addison-Wesley Publishing Co., 1990.

10. Boehm B.W. A Spiral Model of Software Development and Enhancement. ACM

SIGSOFT Software Engineering Notes, Aug. 1986

11. Chris Gane, Trish Sarson. Structured System Analysis. Prentice-Hall,

1979.

12. Edward Yourdon. Modern Structured Analysis. Prentice-Hall, 1989.

13. Tom DeMarco. Structured Analysis and System Specification. Yourdon

Press, New York, 1978.

14. Westmount I-CASE User Manual. Westmount Technology B.V., Netherlands,

1994.

15. Uniface V6.1 Designers' Guide. Uniface B.V., Netherlands, 1994.

16. IEEE Std 1348-1995. IEEE Recommended Practice for the Adoption of CASE

Tools.

17. IEEE Std 1209-1992. IEEE Recommended Practice for the Evaluation and

Selection of CASE Tools.

18. PVCS Version Manager. User's Guide.

19. PVCS Tracker. User's Guide.

20. QA Partner. User's Guide.

21. Новоженов Ю.В. Объектно-ориентированные технологии разработки сложных

программных систем. М., 1996.

22. Панащук С.А. Разработка информационных систем с использованием CASE-

системы Silverrun. "СУБД", 1995, №3.

23. Горчинская О.Ю. Designer/2000 - новое поколение CASE-продуктов фирмы

ORACLE. "СУБД", 1995, №3.

24. Горин С.В., Тандоев А.Ю. Применение CASE-средства Erwin 2.0 для

информационного моделирования в системах обработки данных. "СУБД",

1995, №3.

25. Горин С.В., Тандоев А.Ю. CASE-средство S-Designor 4.2 для разработки

структуры базы данных. "СУБД", 1996, №1.

26. DATARUN Concepts. Computer Systems Advisers Research Ltd., 1994.

27. SE Companion Installation and Administration Manual. SECA Inc., 1995.

28. Петров Ю.К. JAM - инструментальное средство разработки приложений в

информационных системах архитектуры "клиент/сервер", построенных на

базе РСУБД. "СУБД", 1995, №3.

Страницы: 1, 2, 3, 4, 5, 6, 7, 8