• Создавать модель проектируемой системы;

• преобразовывать модели системы в SQL-код, который можно использовать для создания базы данных с помощью DBDesigner или другого средства;

• проводить реинжиниринг - построение исходной модели программной системы путем исследования ее программных кодов. Эта функция очень удобна в случае, если необходимо разобраться уже существующей базе данных. Для проведения реинжиниринга следует выбрать в меню Database - Revers Engineering;

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

• создавать SQL-запросы для внесения изменений и проведения операций над данными.

DBDesigner позволяет преобразовывать полученную модель в код на языке SQL, который может быть использован для создания базы данных с помощью других средств, например, с помощью MySQL. DBDesigner позволяет также создавать базу данных на сервере и выполнять с ней различные операции. Это обеспечивается за счет подключения DBDesigner к MySQL серверу, созданию базы данных и установлению синхронизации между базой на сервере и визуальной моделью. Синхронизация - это сравнение визуальной модели и базы данных, находящейся на сервере. В случае внесения изменений в таблицу, изменения связей между таблицами или удаления таблиц в модели, DBDesigner внесет и соответствующие изменения в базу на сервере.

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

Таблица 4 - Характеристики систем проектирования

Характеристики	West-mount I-СASE + Uniface	Rational Rose	Designer/2000 Developer/2000	SILVERRUN + JAM	Power Designer
Поддержка полного цикла разработки ИС	+	+	+	+	-
Обеспечение целостности проекта	+	+	+	-	-
Целевые форматы	ORACLE, Informix, Sybase, Ingres, СУБД с dbf-форматом	ORACLE, Informix, MS SQL и др.	ORACLE	ORACLE, Informix, Sybase, Ingres и др.	ORACLE, Informix, Sybase, поддержка ODBC
Платформы	Большинство платформ UNIX. Windows планируется в версии 4.0	Windows	Windows	Windows, OS/2, Macintosh Solaris	Windows
Одновременная групповая разработка БД и приложений	+	+	Работа с базой данных только после завершения ее проектирования

CASE-средства используются для:

• анализа, построения и моделирования предметной области (case -Design/IDEF; BPwin, Logic Works);

• анализа и проектирования на основе наиболее распространенных методологий проектирования и создания проектных спецификаций компонентов и интерфейсов системы, архитектуры системы, алгоритмов и структур данных (case -Vantage Team Builder, Designer ORACLE; Silverrun);

• проектирования БД, обеспечивая моделирование данных и генерацию схем БД для наиболее распространенных СУБД (case - Erwin, S-Designor, DataBase Designer, Designer Oracle, Silverrun);

• разработки приложений для PowerBuilder, Sybase; Developer ORACLE; Informix; MS SQL;

• реинжиниринга, обеспечивающего анализ программных кодов и схем БД и формирование на их основе различных моделей и проектных спецификаций (case - Silverrun, Designer 2000, ERwin, S-Designor);

• планирования и управления проектом (SE Companion, Microsoft Project и др.);

• конфигурационного управления (PVCS, Intersolv);

• тестирования (Quality Works, Segue Software);

• документирования (SoDA, Rational Software).

Методика проектирования БД с помощью Case

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

Абстрагирование – это процесс упрощения и игнорирования деталей, не имеющих отношения к целостному пониманию системы на некотором уровне.

Спецификация – это описание свойств и поведения системы.

Процесс создания БД состоит из исследования и построения БД.

Исследование предметной области включает планирование и построение БД.

Планирование БД включает:

• разработку приблизительного плана создания БД;

• создание предварительного отчета об исследованиях;

• определение требований;

• запись терминов в словарь;

• реализация прототипа;

• определение основных прецедентов высокого уровня;

• определение приблизительной концептуальной модели;

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

• уточнение плана.

Построение БД включает анализ, проектирование и конструирование.

Анализ включает:

• определение основных прецедентов;

• уточнение диаграмм прецедентов;

• уточнение концептуальной модели;

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

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

• определение операций;

• построение диаграмм состояний.

Проектирование включает:

• определение реальных прецедентов;

• создание отчетов и интерфейсов пользователей;

• уточнение архитектуры системы;

• построение диаграмм классов;

• определение структуры БД.

Конструирование включает:

• реализацию классов и интерфейсов, методов, графических элементов интерфейса, отчетов, схемы БД;

• написание тестовых кодов.

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

В соответствии с выявленными целями создания БД (получение прибыли, повышение уровня автоматизации в организации) определяются функции системы, табл.5.

Таблица 5 - Функции системы

Функции	Категории
Ввод данных	Очевидная
Вычисление статистических характеристик	Скрытая
Регистрация пользователей	Скрытая
Поддержка актуальности БД	Очевидная
Анализ ситуации	Скрытая
Выдача рекомендаций	Дополнительная

Критерии выполнения функций (табл.6) - характеристики системы: простота в использовании, отказоустойчивость (24 часа бесперебойной работы), время отклика, стиль интерфейса (графический), стоимость, используемая платформа (Windows, Linux, др.).

Таблица 6 - Функции и критерии их выполнения

Функция	Категория	Критерий	Значение, ограничения	Категория
Регистрация пользователей	Обязательная	Время отклика	5сек	Обязательная
Ввод данных	Обязательная	Опоздание для ввода новых данных	2 часа	Обязательная
Вычисление статистических характеристик	Обязательная	Опоздание для расчета	2 дня после окончания месяца	Обязательная
Регистрация пользователей	Обязательная	Опоздание с регистрацией	1 день	Обязательная
Поддержка актуальности БД	Обязательная	Опоздание с загрузкой новых порций данных	1 час	Обязательная
Выдача рекомендаций	Не обязательная	Опоздание по реагированию на ситуацию	10 мин после загрузки	Обязательная

После выявления функций системы необходимо:

• определить границы системы, идентифицировать исполнителей и прецеденты;

• записать все прецеденты, разделить их по категориям (основной, второстепенный и дополнительный);

• построить диаграмму прецедентов, описать прецеденты;

• определить взаимоотношения между прецедентами на диаграмме;

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

• идентифицировать всех участников, взаимодействующих с БД (администратор, пользователи, разработчики приложений, СУБД);

• построить концептуальную модель;

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

Для определения прецедентов:

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

• идентифицируйте внешние события, на которые реагирует система;

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

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

• требования определяются и формулируются при описании прецедентов;

• временные и финансовые оценки прямо или косвенно зависят от количества прецедентов, их сложности, требуемых служб поддержки и т.д.;

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

• набор требований для одного конкретного цикла разработки вытекает из описания прецедента;

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

Таблица 7 – Пример описания прецедентов

Свойства прецедента	Описание
Название прецедента	Регистрация пользователей
Исполнители	Пользователь, администратор, менеджер
Тип	Главный, вспомогательный
Описание	Пользователь входит в БД ……
Цель	Ведение регистра пользователей и платежей за услуги
Функции	Регистрация, проверка ввода, поиск, выдача результатов, сведений об ошибках, др.

Таблица 8 - Ход событий по прецеденту

Действия пользователя	Отклик системы
Пользователь входит в БД	Приглашение к регистрации
Пользователь регистрируется (вводит имя и пароль)	2. Проверяется правильность ввода имени и пароля В случае правильного ввода система выдает список услуг В противном случае система выдает сообщение "пароль не совпадает" и предлагает повторить ввод имени и пароля до 3 раз, после третьего раза происходит разрыв связи с пользователем
Пользователь работает (вводит данные, осуществляет поиск, др.)	5. Проверяется правильность ввода данных, если есть ошибка, то выдается сообщение («Дата записана неверно»), в противном случае данные записывают в БД 6. Осуществляется поиск в БД 7. Система выдает данные, если данные не найдены, то выдается сообщение «Для указанных критериев запроса данные отсутствуют»

Для описания событий по созданию БД можно использовать сетевой график создания БД, который представлен на рис.3, а технологические этапы и операции сбора, обработки и распространения данных - в табл.9.

Рисунок 3 - Сетевой график создания БД

Обозначения:

1. Исследование информационных потребностей и обследование потребителей

2.Выбор носителя для ввода данных

3.Разработка ТЗ на создание БД

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

5.Разработка технологии занесения данных на носитель

6.Разработка инструкции по занесению данных

7.Разработка ТЗ на программу первичной обработки, разработка алгоритмов и программ контроля данных

8.Опытное занесение данных

9.Опытная эксплуатация программ первичной обработки

10.Программирование

11.Сдача технологии занесения данных на носитель в эксплуатацию

12.Эксплуатация технологии

13.Эксплуатация БД

14.Разработка технологии занесения данных на носитель

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

16.Исправление ошибок

17.Подготовка документации на БД

18.Экспертиза данных (рецензирование)

19.Архивация данных (акт сдачи)

Таблица 9 - Пример технологических этапов и операций сбора, обработки и распространения данных

Этапы	Выполняемые операции
Производство измерений (наблюдений)	Кодирование информации
	Занесение данных на бумажный носитель в источнике данных
	Высылка данных и носителей в центр сбора
	Контроль данных
	Заполнение таблиц
	Проверка таблиц
	Составление документации на передаваемые данные
	Заполнение форм отчетности
	Составление акта экспертизы
	Пересылка данных в промежуточный центр сбора
Сбор данных в промежуточном источнике	Производство наблюдений, заполнение книжек и журналов наблюдений
	Подготовка справочной информации, создание схемы данных
	Занесение данных на технический носитель
	Обработка данных на ЭВМ
	Контроль и корректировка данных
	Накопление данных
	Прикладная обработка данных на месте
	Комплектование данных на носителе
	Копирование данных на сменный носитель для передачи в центр данных
	Прием и контроль отчета в организации – владельце данных
	Передача отчетных материалов в центр данных
Хранение	Каталогизация, копирование, контроль физического состояния
Обработка	Поиск, трансформация, прикладная обработка, передача, визуализация
Прогнозирование	Усвоение, моделирование
Поддержка решений	Реализация действий, объяснение, обучение

Создание диаграмм прецедентов

Прецеденты, участвующие в создании БД, представлены на рис.4, идентификация исполнителей и прецедентов дана в табл.10. Описания прецедентов "Оплата по кредитной карточке" и "Оплата по договору" даны в табл.11 и 12. Рекомендации по созданию диаграмм включают:

• создание отдельных диаграмм для каждой системной операции;

• разбиение диаграмм на несколько, если она оказалась слишком сложной;

• использование в качестве отправной точки постусловий, указаний в описании операции, а также описание прецедентов;

• разработку диаграммы взаимодействия с учетом решения этих задач.

Рисунок 4 - Прецеденты БД

Определим транзакцию как объект, содержащий следующие пять компонент:

• СОБЫТИЕ в системе или ее внешнем окружении;

• СИГНАЛ к системе;

• ДЕЙСТВИЕ системы;

• ОТКЛИК от системы;

• ВЛИЯНИЕ на систему или ее окружение.

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

• СОБЫТИЕ - Диспетчер замечает, что корабль движется слишком быстро.

• СИГНАЛ - Замедлить скорость корабля на 210 м/сек.

• ДЕЙСТВИЕ - Определить какой из тормозных ракетных двигателей включить и на какое время.

• ОТКЛИК - Сигнал тормозному двигателю ракеты для его включения на 4.8 сек.

• ВЛИЯНИЕ - Корабль замедлил скорость до 210 м/сек.

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

• СОБЫТИЕ - Владелец дачи устал пилить и колоть дрова для камина и решил установить газовое отопление.

• СИГНАЛ - Информация о Владельце и его даче, а также дата начала обслуживания.

• ДЕЙСТВИЕ - Добавить данные о Владельце дачи в базу данных клиентов.

• ОТКЛИК - Разрешение на предоставление услуг.

• ВЛИЯНИЕ - В освободившееся от дровяных работ время Владелец дачи проектирует систему автоматизации газовой компании.

Рисунок 5 - Уточнение диаграммы авторизации

Диаграммы авторизации пользователей продемонстрированы на Рис.6.

Рисунок 6 - Диаграмма авторизации пользователей

Таблица 10 - Идентификация исполнителей и прецедентов

Исполнитель	Прецеденты	Ранг	Обоснование
Пользователь	Регистрация Получение услуг	Высокий	Влияет на безопасность
Администратор	Разрешение (выдача пароля)	Минимальный	Влияет на безопасность
Система	Представление меню для регистрации Представление меню для входа в систему Проверка пароля Предоставление перечня услуг Отметка об обращении к услуге	Высокий	Влияет на развитие системы
Пользователь	Дает разрешение на оплату по: - Кредитной карточке - Хоздоговору - Списанию за счет ранее внесенной суммы	Высокий	Влияет на прибыль

Таблица 11 - Описание прецедента "Оплата по кредитной карточке"

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

Таблица 12 - Описание прецедента "Оплата по хоздоговору"

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

На рис.7 дан пример прецедента для проектированияWeb портала.

Рисунок 7 - Прецедент Web портала - услуга (пользователь выбирает, оплачивает и получает услугу)

Ранжирование прецедентов производится на основе следующих критериев, табл.13:

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

• важность информации и внутренняя структура проекта обеспечивается за счет сравнительно небольших усилий;

• включает рискованные, сложные или срочные функции;

• требует дополнительного исследования или применения новой и ненадежной технологии;

• представляет основной экономический процесс;

• напрямую обеспечивает повышение эффективности.

Таблица 13 - Ранжирование прецедентов

Прецедент	1	2	3	4	5	6	Сумма
Регистрация	5	3	2	0	5	3	18
Выполнение запросов	5	0	1	0	5	5	16
Оплата стоимости услуг	5	3	5	4	5	3	25

Концептуальная модель должна помочь выделить типовой ход событий при работе с БД:

• пользователь вводит критерии запроса;

• СУБД анализирует критерии, сравнивает со значениями в БД и выдает на экран;

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

На основе концептуальной модели можно описать системные операции по форме табл.14 и выделить предположения и упрощения для прецедентов, табл.15.

Таблица 14 - Описание системной операции

Характеристика операции	Описание
Имя	Имя операции и ее параметры (словесное описание обязанностей данной операции)
Обязанности	Ввести (записать) данные
Тип	Имя типа (понятие, программный класс, интерфейс) - системная
Ссылки	Ссылка на функции системы
Примечания	Использовать самый быстрый доступ к БД
Исключения	Исключительная операция (Если значение параметра выходит за допустимые пределы, то выдать сообщение об ошибке)
Вывод	Информация, не касающаяся интерфейса пользователя (например, число обработанных записей)
Предусловия	Предельные значения параметров заранее известны системе
Постусловия	Декларируемся изменения состояния объектов концептуальной модели (создание или удаление экземпляров, модификация атрибута, формирование и разрыв ассоциаций)

Таблица 15 - Предположения и упрощения для прецедентов

Прецедент	Предположения и упрощения
Регистрация	Рассматривается отдельный центр данных, не являющийся частью более крупной организации
Авторизация	Для каждого типа кредитной карточки задействована своя служба авторизации (банк, выдавший карточку)
Списание за счет ранее внесенных сумм	Поддерживается частичная оплата
Отметка об обращении	Сведения о всех запросах выполненных и невыполненных, регистрация в журнале
Перечень услуг	Сведения об услугах заносятся в отдельную таблицу

Таким образом, необходимо описать все процессы, прецеденты, операции. Факторами, требующими увеличения продолжительности цикла разработки, являются:

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

• введение новой технологии или методов;

• отсутствие специалистов в предметной области;

• значительная распределенность процесса, конкуренция и согласование деятельности групп участников;

• появление новых сотрудников;

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

• работа над проектом в распределенных коллективах;

• большие коллективы разработчиков.

Заключение

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

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

• поддержка создания логических моделей, не зависящих от СУБД, и генерации физических моделей на их основе;

• поддержка нескольких типов СУБД, включая не только серверные, но и настольные;

• поддержка специфических особенностей тех или иных СУБД ведущих производителей (генерация триггеров, управление физическим хранением данных);

• способность осуществлять обратное проектирование на основе либо имеющейся БД;

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

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

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

Успешное внедрение CASE-средств обеспечивает такие выгоды как:

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

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

• позитивность отдачи от инвестиций в CASE-средства.

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

Тенденциями развития CASE-инструментов являются:

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

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

В первом, узком, но глубоком подходе попытки усилить возможности инструмента в направлении получения программного кода приводят к ограничению множества типов отношений и объектов, которые можно описывать с использованием инструмента. Плата за такой сервис — предопределенная системная архитектура программного кода.

Второй - широкий, но мелкий подход, подразумевающий расширение множества отношений и объектов, реализуем только при разделении труда, когда «неглубокий» инструмент снабжается необходимыми интерфейсами для использования продуктов других разработчиков.

CASE средство нацелено на то, чтобы обеспечить возможность эффективного использования (выживаемости) БД; существенно снизить затраты на поддержку жизненного цикла системы. CASE обеспечивает построение моделей, и — на основе этих моделей — поддерживает построение конкретной реализации собственно программного обеспечения.

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

• предпочитайте простоту (не вводите дополнительные свойства объектов, не требующиеся сегодня, архитектурные, аналитические требования должны быть как можно более простыми и понятными для всех заинтересованных лиц, не перегружайте диаграмму излишними деталями);

• учитывайте изменения;

• обеспечивайте будущую работу (создавайте необходимую документацию по программному продукту и его поддержке);

• вносите изменения последовательно (сначала строите диаграмму высокого уровня и далее развивайте);

• привлекайте больше заинтересованных лиц – заказчиков, пользователей;

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

• знайте инструментальные средства создания БД;

• каждый участник разработки БД должен иметь возможность работать с case;

• тестируйте созданные модели данных;

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

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

Список литературы

1. Вендров А.М. CASE- технологии. Современные методы и средства проектирования информационных систем. – М.: - Финансы и статистика, 1998.http://www.interface.ru/logworks/caset/glava4/glava4_1.htm

2. Ларман Крэг. Применение UMLи шаблонов проектирования: Введение в объектно - ориентированный анализ и проектирование. - М. - Санкт-Петербург- Киев. 2001. - Издательский дом "Вильямс. - 496 с.

3. Новичков А. Система генерации проектной документации Rational SoDA // Журнал «КомпьютерПресс». 2001. № 10. www.compress.ru

4. Федоров А., Елманова Н. Средства проектирования данных // Журнал «КомпьютерПресс». 2001. - № 1.

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

1. Какие case-средства Вы знаете?

2. Составьте список процессов, происходящих при создании БД

3. Какие события и операции происходят в подсистеме создания БД?

4. Что делают системные операции в подсистеме выполнения запросов?

5. Когда использование CASE-систем и технологий эффективно? Как это связано со способом получения прикладного программного обеспечения на предприятии - покупкой готового пакета или заказной разработкой?