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

Размещено на http://www.allbest.ru/

IX. ИСПОЛЬЗОВАНИЕ CASE - ТЕХНОЛОГИЙ ДЛЯ ПРОЕКТИРОВАНИЯ БД



Содержание

1. Обоснование необходимости использования Case средств

2. Состав, структура и функциональные особенности Case средств

2.1 Классификация Case средств

2.2 Обзор современных средств

3. Анализ систем

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

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

Заключение

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

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



1. Обоснование необходимости использования Case средств

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

неадекватная спецификация требований;

неспособность обнаруживать ошибки в проектных решениях;

низкое качество документации, снижающее эксплуатационные качества системы;

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

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

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

CASE (Computer Aided Software Engineering) - технология представляет собой методологию проектирования ИС, а также набор инструментальных средств, позволяющих в наглядной форме моделировать предметную область, анализировать эту модель на всех этапах разработки и сопровождения ИС и разрабатывать приложения в соответствии с информационными потребностями пользователей.

CASE-средства представляют собой программные средства, поддерживающие процессы создания и/или сопровождения ИС, такие как: анализ и формулировка требований, проектирование баз данных и приложений, генерация кода, тестирование, обеспечение качества, управление конфигурацией и проектом. То есть использование case-технологий охватывает весь процесс разработки ИС в целом [1].

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



а) б)

Рисунок 1 - Модели жизненного цикла создания БД

а) без использования б) с использованием CASE

Таблица 1 - Оценка трудозатрат при различных способах разработки БД

Способ разработки	Анализ	Проектирование	Кодирование	Тестирование
Традиционная разработка	20%	15%	20%	45%
Использование case-технологий	40%	40%	5%	15%

Таблица 2 - Преимущества традиционной разработки и с помощью case-средств

Традиционная разработка	Разработка с помощью case
Основные усилия на кодирование и тестирование	Основные усилия на анализ и проектирование
"Бумажные" спецификации	Быстрое итеративное прототипирование
Ручное кодирование	Автоматическая кодогенерация
Ручное документирование	Автоматическая генерация документации
Тестирование кодов	Автоматический контроль проекта
Сопровождение кодов	Сопровождение спецификаций проектирования

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

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

При проектировании БД на основе case технологии используется спиральный цикл создания системы, рис.2. При неполном завершении работ на каждом этапе разработки переходим на следующий этап, не дожидаясь полного завершения работы на текущем этапе. При итеративном способе разработки недостающую работу выполняем на следующей итерации. Главная же задача ставится так - как можно быстрее показать пользователям системы работоспособный продукт, тем самым активизируя процесс уточнения и дополнения требований. Основная проблема спирального цикла - определение момента перехода на следующий этап. Для ее решения необходимо ввести временные ограничения на каждый из этапов жизненного цикла [4].

Рисунок 2 - Спиральная модель жизненного цикла ИС [2]

Можно перечислить следующие факторы, усложняющие определение возможного эффекта от использования case-средств:

широкое разнообразие качества и возможностей case-средств;

относительно небольшое время использования case-средств в различных организациях и недостаток опыта их применения;

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

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

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

различная степень интеграции case-средств в различных проектах.

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

Среди наиболее важных проблем использования case - технологии можно выделить следующие:

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

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

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

негативное отношение персонала к внедрению case-технологии может быть главной причиной провала проекта.



2. Состав, структура и функциональные особенности Case средств

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

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

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

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

· Проектирование (для уровня представления или реализации).

· Системное моделирование - использовать исполняемые модели (имитационное моделирование), чтобы помочь справиться со сложностями и рисками, а также повысить взаимодействие и взаимопонимание в командах.

· Качество - сосредоточиться на достижении качества уже на стадии дизайна, нежели надеяться только лишь на тестирование и испытания.

· Глобальное взаимодействие в реальном времени - обеспечить объединение и взаимодействие распределенных команд.

Моделирование БД для конкретной СУБД.

Документирование БД.

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

§ человеческий фактор, определяющий разработку БД как легкий, удобный и экономичный процесс;

§ широкое использование базовых программных средств, получивших массовое распространение в других приложениях (СУБД, компиляторы с различных языков программирования, отладчики, документаторы, издательские системы, оболочки экспертных систем и др.);

§ автоматизированная или автоматическая кодогенерация, выполняющая несколько видов генерации кодов: преобразование для получения документации, формирование БД, ввод/модификация данных, получение выполняемых машинных кодов из спецификаций программного обеспечения, автоматическая сборка модулей из словарей и моделей данных и повторно используемых программ, автоматическая конверсия ранее используемых файлов в форматы новых требований;

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

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

§ рентабельность;

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

Case-средства служат инструментарием для поддержки и усиления методов структурного анализа и проектирования. Эти инструменты поддерживают работу пользователей при создании и редактировании графического проекта в интерактивном режиме, они способствуют организации проекта в виде иерархии уровней абстракции, выполняют проверки соответствия компонентов. Case-средства представляют собой новый тип графически-ориентированных инструментов поддержки жизненного цикла. Обычно к ним относят любое программное средство, обеспечивающее автоматическую помощь при разработке БД, его сопровождении или деятельности по управлению проектом, и проявляющее следующие дополнительные черты:

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

· интеграция, обеспечивающая легкость передачи данных между средствами и позволяющая управлять всем процессом проектирования и разработки БД непосредственно через процесс планирования проекта;

· использование компьютерного хранилища (репозитория) для всей информации о проекте, как основа для автоматического продуцирования кода и повторного его использования в будущих системах.

Интегрированное case-средство (или комплекс средств, поддерживающих полный жизненный цикл БД) содержит следующие компоненты:

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

· графические средства анализа и проектирования, обеспечивающие создание и редактирование иерархически связанных диаграмм, образующих модели БД;

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

· средства конфигурационного управления, документирования, тестирования, управления проектом, реинжиниринга.

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

Средства централизованного хранения всей информации о проектируемой БД в течение всего ЖЦ (репозитарий). Соответствующая БД должна иметь возможность поддерживать большую систему описаний и характеристик и предусматривать надежные меры по защите от ошибок и потерь информации. Репозитарий должен обеспечивать:

· интерактивный режим при вводе описаний объектов;

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

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

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

· сборку любой запрошенной версии;

· контроль информации на корректность, полноту и состоятельность.

Средства ввода предназначены для ввода данных в репозитарий, а также для организации взаимодействия с case-пакетом. Эти средства должны поддерживать различные методологии и использоваться на всем ЖЦ разными категориями разработчиков: аналитиками, проектировщиками, инженерами, администраторами и т.д.

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

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

2.1 Классификация Case средств

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

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

Вторую категорию составляют собственно средства проектирования БД, рассматриваемые в комплексе со средствами разработки приложений (например, Oracle Designer).

Классификация case-средств по типам отражает их функциональную ориентацию. Ниже дано рассмотрение case-средств на различных этапах проектирования БД.

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

Проектирование БД и файлов. Средства данной группы обеспечивают логическое моделирование структур данных, автоматическое преобразование моделей данных в третью нормальную форму, автоматическую генерацию схем БД и описаний структур данных на уровне программного кода.

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

2.2 Обзор современных средств

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

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

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

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

· редакторы кодов, автоматически изменяющие при редактировании и все предшествующие коду структуры;

· средства доступа к спецификациям, их модификации и генерации нового (модифицированного) кода;

· средства реверсного инжиниринга, транслирующие коды в спецификации.

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

- управление ЖЦ данных и приложений (разработчики БД должны проводить сквозное моделирование данных, чтобы обеспечить соответствие между новыми и уже существующими моделями данных во всех БД предприятия, независимо от того находятся ли они в стадии разработки или уже используются);

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



3. Анализ систем

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

Таблица 3 - Наиболее популярные средства проектирования данных

CASE - средство	Производитель	URL
Designer 2000	Oracle	http://www.oracle.com/
ERwin	Computer Associates	http://www.cai.com/
PowerDesigner	Sybase	http://www.sybase.com/
ER/Studio	Embarcadero	http://www.embarcadero.com/
System Architect	Popkin Software	http://www.popkin.com/
Visible Analyst	Visible Systems	http://www.visible.com
Visio Enterprise	Microsoft	http://www.microsoft.com/

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

· поддержка множества языков программирования;

· широкие возможности моделирования;

· возможность одновременного ведения нескольких проектов;

· возможность совместной разработки;

· поддержка стандарта визуальной нотации - языка UML (Unified Modeling Language), который с 1997 г. определен как стандарт языка для этой области инструментальных средств [2].

Rational Rose поддерживает:

· генерацию кода и реинжениринг для нескольких языков, включая Visual Basic, C++, Java, Delphi, PowerBuilder, Data Definition Language для большинства СУБД;

· визуальное моделирование, полностью совместимое с UML;

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

Базу инструментальной среды Designer+Developer Oracle составляют:

· методология структурного нисходящего проектирования;

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

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

· наличие репозитария, для хранения спецификаций проекта по созданию БД на всех этапах ее разработки;

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

· автоматизация последовательного перехода от одного этапа разработки к следующему;

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

Генератор серверной части автоматически строит по спецификациям БД тексты программ на языке SQL, используя все средства определения БД, включая триггеры, хранимые процедуры и т.д. Генераторы клиентской части обеспечивают автоматическое формирование текстов программных модулей по их спецификациям, записанным в репозитарии. Все модули приложения классифицируются по типам, основными из которых являются экранные формы, отчеты, процедуры. Для каждого типа имеется свой генератор, результатом работы которого является программа, написанная на языке, соответствующем этому типу: генератор форм создает приложения для Oracle Forms, генератор отчетов позволяет получать процедуры на PL/SQL либо приложения для Oracle Report.

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

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

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

Case PowerDesigner (Sybase) служит для разработки структуры БД и генерации ее в целевой системе. Здесь предоставляются возможности работы в терминах объектно-ориентированной, концептуальной или физической моделей. Пользовательская рабочая среда отображается в виде иерархии объектов, таких как модель, отчет, пакет, внешние документы и т.д. PowerDesigner реализует следующие возможности:

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

· проверка модели на соответствие целевой системе;

· синхронизация модели и целевой системы (с автоматическим или ручным принятием решений);

· настройка целевого формата;

· генерация целевой системы.

Case ERwin представляет собой средство концептуального моделирования БД, реализует функции проектирования схемы БД, генерацию ее описания на языке целевой СУБД (ORACLE, Ingres, Sybase, DB/2, Microsoft SQL Server и др.) и реинжиниринг существующей БД. Версия ERwin/OPEN полностью совместима со средствами разработки приложений PowerBuilder и SQLWindows и позволяет экспортировать описание спроектированной БД непосредственно в репозитории данных средств. Для ряда средств разработки приложений (PowerBuilder, SQLWindows, Delphi, Visual Basic) выполняется генерация форм и прототипов приложений.

Семейство продуктов ERWin предназначено для моделирования и создания БД произвольной сложности. В настоящее время ERWin является наиболее популярным пакетом моделирования данных благодаря поддержке широкого спектра СУБД самых различных классов: SQL-серверов (Oracle, Sybase, MS SQL Server, DB2, Ingress и др.) и "настольных" СУБД dBASE, FoxPro, MS Access и др.). ERwin Data Modeling Suite предоставляет расширенную поддержку СУБД Teradata, SQL Server 2008 и DB2 z/OS v.9, возможности обмена метаданными с инструментами управления данными Oracle Business Intelligence.

Информационная модель представляется в виде диаграмм "сущность-связь", отражающих основные объекты предметной области и связи между ними. Дополнительно определяются атрибуты сущностей, характеристики связей, индексы и бизнес-правила, описывающие ограничения и закономерности предметной области. После создания ER-диаграммы пакет автоматически генерирует SQL-код для создания таблиц, индексов и других объектов БД. По заданным бизнес-правилам формируются стандартные триггеры БД для поддержки целостности данных, для сложных бизнес-правил можно создавать собственные триггеры, используя библиотеку шаблонов.

Пакет может осуществлять реинжиниринг существующих БД: по SQL-текстам автоматически генерируются ER-диаграммы. Пакет поддерживает выполнение последовательности следующих функций:

· импорт с сервера существующей БД;

· автоматическая генерация модели БД;

· модификация модели;

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

Для разработки клиентской части приложения имеются специальные версии пакета, обеспечивающие интеграцию с такими инструментами как SQLWindows, PowerBuilder, Visual Basic, Delphi.

Для коллективной разработки модели БД предназначен специальный продукт ModelMart, позволяющий контролировать версии модели, гибко распределять права доступа между членами группы, строить библиотеки моделей, осуществлять объединение моделей и т.п. Erwin версии 7.3 позволяет архитекторам данных осуществлять межсистемный анализ, обеспечивая интеграцию с моделями данных, платформами бизнес-аналитики, хранилищами данных, унаследованным и разрабатываемым программным обеспечением. Версия пакета для моделирования и анализа данных ERwin Data Modeling Suite снабжена технологией профилирования данных, что делает продукт центром в управлении в организациях.

В новом решении CA ERwin® Data Modeling Suite компания CA сделала возможным объединение моделирования данных с другими инструментами. Пакет CA ERwin® Data Modeler включает следующие возможности:

* создание отчетов о графической информации в самых популярных форматах (электронная таблица, PDF, HTML и т. д.);

* доступность и совместное использование всей имеющейся в компании информации, используя широкий набор инструментов и интерфейсов для составления отчетов;

* обмен критически важной деловой и технической информацией с популярными системами управления данными, такими как Oracle®, Cognos®, SAP NetWeaver® и другими;

* поддержку СУБД Teradata®, SQL Server® 2008 и DB2®, что позволяет оптимизировать процессы анализа и проектирования БД;

* упорядоченную разработку и развертывание промышленных приложений на базе СУБД SQL Server для операционных систем Windows XP, Windows 2003 Server и Windows Vista;

* для аналитиков выборочно открывать, документировать и заново использовать ERP-метаданные, чтобы упростить многочисленные бизнес-данные, а также управление данными, приложениями и руководство инициативами;

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

SoDA (Software Documentation Automation) - разработка компании Rational Software Corporation (http://www.rational.com) значительно упрощающая процесс создания проектной документации и поддержания ее в течение всего цикла разработки БД. SoDA, по существу, представляет собой макрос, написанный для MS Word и особенно полезный при реализации крупных информационных проектов, в которых на составление документации и ее постоянную переработку обычно тратится очень много времени и сил разработчиков. SoDA поддерживает всю линейку продуктов Rational Software, позволяя создавать сложные комбинированные отчеты на основе выходных данных программ состава Rational Suite. SoDA имеет доступ к данным из Microsoft Project. Основные возможности системы включают [3]:

· автоматическое извлечение информации из файлов, созданных различными инструментальными средствами. SoDA "понимает" структуру информации, хранимой теми системами, с которыми она интегрирована, а сама информация доступна ей через API этих систем;

· сохранение при "перекомпиляции" текста и графики, введенных пользователем вручную в текстовом редакторе Microsoft Word;

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

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

· частичная "перекомпиляция" больших документов;

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

· документирование всех этапов работы над проектом;

· проверка соблюдения требований, предъявляемых к разрабатываемой системе. SoDA позволяет сформировать таблицы, из которых можно понять, насколько полученные результаты соответствуют требованиям, определенным на начальных этапах проектирования;

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

ER/Studio (Embarcadero Technologies, http://www.embarcadero.com/products/Design/erdatasheet.htm). По своему назначению этот продукт сходен с ERwin -- он представляет собой специализированное средство проектирования БД и не содержит в своем составе инструментов для объектно-ориентированного моделирования или моделирования бизнес-процессов. Список поддерживаемых СУБД у этого продукта достаточно широк и включает все наиболее популярные серверные и настольные СУБД.

ER/Studio поддерживает написание макросов. Этот язык позволяет создавать макросы для выполнения однотипных операций, например добавления стандартных полей к вновь создаваемым сущностям. С помощью этого же языка можно генерировать стандартные триггеры и хранимые процедуры для вставки, удаления, изменения записей. Код на этом языке можно отлаживать и обращаться к свойствам сущностей для конструирования серверного кода. Однако, в отличие от ERwin, ER/Studio не позволяет добавить к каждой таблице свои шаблоны триггеров или просмотреть код конкретного триггера в процессе разработки модели -- чтобы получить код одного триггера, нужно сгенерировать скрипт для всей модели.

Модели ER/Studio можно сохранить не только в виде DDL-скрипта, но и в формате XML. Можно также создать репозитарий для их хранения в любой серверной СУБД. ER/Studio может импортировать модели ERwin, но при импорте теряются связи шаблонов серверного кода с конкретными таблицами, и не все макросы ERwin корректно преобразуются в макросы. ER/Studio позволяет сгенерировать Java-классы для клиентских приложений.

System Architect (Popkin Software, http://www.popkin.com/products/sa2001/data/data.htm) представляет собой универсальное CASE-средство, позволяющее осуществить не только проектирование данных, но и структурное моделирование. Средство проектирования БД и создания ER-диаграмм является одной из составных частей этого продукта. Продукт поддерживает СУБД практически всех ведущих производителей, включая Oracle, Sybase, DB2, SQL Server, Informix, Sybase, Access, dBASE, Paradox и др.

В процессе логического моделирования можно проверить модель на соответствие правилам проектирования данных (например, на соответствие ее первой, второй или третьей нормальным формам). При генерации DDL-скрипта можно сгенерировать триггеры (в том числе и нестандартные). Все компоненты System Architect позволяют документировать процесс работы над проектом, включая техническое задание, план тестирования и др.

Модели System Architect, как и в случае других CASE-средств, можно сохранять в репозитарии. Однако в отличие от традиционных репозитариев, обладающих более или менее стандартной структурой хранимых данных, репозитарий System Architect является настраиваемым -- к сохраняемым объектам можно добавлять дополнительные свойства, определенные пользователем. System Architect обладает встроенным Visual Basic for Application, что позволяет создавать разнообразные решения на базе этого продукта, включая автоматическую генерацию моделей и проектной документации. System Architect позволяет генерировать код клиентских приложений для Visual Basic, Delphi и PowerBuilder, классы C++, а также код и текстовые экранные формы COBOL.

Visible Analyst (Visible Systems Corporation, http://www.visible.com/dataapp/daprods.html) выпускается в трех редакциях: Visible Analyst DB Engineer, который включает средства проектирования данных; Visible Analyst Standard, который кроме проектирования данных позволяет осуществлять структурное моделирование; Visible Analyst Corporate, который помимо указанных выше возможностей позволяет осуществлять также объектно-ориентированное моделирование. Visible Analyst поддерживает широкий спектр СУБД с точки зрения генерации серверного кода, включая Oracle 7, Sybase SQL Server; Informix, DB2, Ingres. Для Informix и DB2 позволяет генерировать DDL-скрипты, учитывающие специфические особенности организации физической памяти наиболее популярных серверных СУБД, такие как управление табличным пространством, размером экстентов, режимами блокировки данных, степенью заполнения данными, а также создавать кластеризованные индексы и генерировать триггеры для выполнения стандартных операций. Из этих же СУБД можно производить непосредственно обратное проектирование. Помимо этих двух СУБД обратное проектирование можно производить также из DDL-скриптов, сгенерированных для других СУБД, а также на основе кода языка COBOL. Visible Analyst позволяет на основе созданных моделей генерировать код для языков Visual Basic, С++ и COBOL.

Visio Enterprise (Microsoft, http://www.microsoft.com/office/visio/) содержит в своем составе полноценное case-средство, позволяет производить прямое и обратное проектирование БД, преобразовывать логическую модель в физическую. Этим средством поддерживаются драйверы ODBC и OLE DB-источники данных. С его помощью можно создавать триггеры для стандартной обработки нарушений ссылочной целостности в случае, если DDL-скрипт создается для Microsoft SQL Server, и серверные ограничения, если скрипт создается для другой СУБД. Visio при генерации скриптов позволяет указывать параметры организации физической памяти Oracle, Informix, Microsoft SQL Server, DB2 и некоторых других СУБД. Visio, в отличие от специализированных средств проектирования данных, не обладает скриптовым языком, позволяющим создавать серверный код, не связанный с конкретной СУБД. При использовании этого продукта такой код нужно создавать на этапе физического проектирования в уже созданном скрипте. Этот продукт является сервером автоматизации, обладает весьма обширной объектной моделью и встроенным средством разработки -- Visual Basic for Applications, что позволяет, в частности, создавать на его базе разнообразные решения, в том числе и автоматизировать разработку моделей данных.

fabFORCE.net DBDesigner (www.fabforce.net/dbdesigner4) - Open Soucre программа, представляющая собой удобную визуальную среду проектирования БД и сочетающий профессиональные возможности с простым и ясным интерфейсом. Программа распространяется по лицензии GRL и способна работать под Linux Gnome/KDE и Microsoft Windows 2K/XP. Программа оптимизирована под другой Open Source продукт MySQL и называется MySQL Workbench (http://www.varvashenia.ru/ru/software/DBDesigner4/).

DBDESIGNER - это свободно распространяемая CASE-система, предназначенная для проектирования, моделирования, создания и поддержки информационных систем. Программа может использоваться для Windows 2000/XP, Linux KDE/Gnome и MySQL. DBDesigner позволяет:

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

- преобразовывать модели системы в 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).



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Действия пользователя	Отклик системы
Пользователь входит в БД	Приглашение к регистрации
Пользователь регистрируется (вводит имя и пароль)	2. Проверяется правильность ввода имени и пароля В случае правильного ввода система выдает список услуг В противном случае система выдает сообщение "пароль не совпадает" и предлагает повторить ввод имени и пароля до 3 раз, после третьего раза происходит разрыв связи с пользователем
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 - Пример технологических этапов и операций сбора, обработки и распространения данных