Использование case-технологий для проектирования баз данных

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рисунок 7 - Прецедент Web портала - услуга

(пользователь выбирает, оплачивает и получает услугу)

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

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

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

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

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

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

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

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

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

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

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

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

На основе концептуальной модели можно описать системные операции по форме табл.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.

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

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

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

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

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

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

Размещено на Allbest.ru