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

 

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

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

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

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

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

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

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

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

 

 

Этапы проектирования.

Процесс проектирования базы данных – это процесс, допус­кающим возврат к предыдущим этапам для пересмотра ранее принятых ре­шений и включает следующие этапы:

1. Выделение сущностей и связей между ними.

2. Построение диаграмм ER-типа с учетом всех сущностей и их связей.

3. Формирование набора предварительных отношений с указанием пред­полагаемого первичного ключа для каждого отношения и использованием диаграмм ER-типа.

4. Добавление неключевых атрибутов в отношения.

5. Приведение предварительных отношений к нормальной форме Бойса-Кодда, например, с помощью метода нормальных форм.

6. Пересмотр ER-диаграмм в следующих случаях:

• некоторые отношения не приводятся к нормальной форме Бойса-Кодда;

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

После преобразования ER-диаграмм осуществляется повторное выполне­ние предыдущих этапов проектирования (возврат к этапу 1).

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

В рассмотренных выше примерах связь ВЕДЕТ всегда соединяет две сущно­сти и поэтому является бинарной. Сформулированные ниже правила формиро­вания отношений из диаграмм ER-типа распространяются именно на бинарные связи. Поэтому, когда речь идет о связях, слово «бинарные» далее опускается.

Проблемы проектирования.

Проектирование ИС, включающих в себя БД, осуществляется на физ. и лог. уровнях. Решение проблем проектирования на физ. уровне во многом зависит от используемой СУБД, зачастую автоматизирована и скрыта от пользователя.

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

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

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

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

2) формулирование знаний о системе и требований к обработке данных, получение с помощью CASE-системы готовой схемы БД или даже готовой прикладной ИС;

3) структурирование информации для использования в ИС в процессе проведения системного анализа на основе совокупности правил и рекомендаций.

Следует различать простое и избыточное дублирование данных. Наличие первого из них допускается в БД, а избыточное дублирование данных может приводить к проблемам при обработке данных.

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

С_Т

Сотрудник	Телефон
Иванов
Петров
Егоров
Сидоров

 

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

С_Т_Н

Сотрудник	Телефон	Н_комн
Иванов
Петров
Егоров
Сидоров

 

Избыточное дублирование данных создает проблеиы при обработке кортежей отношения, названные Коддом «аномалиями обновления отношений».

Реляционная модель.

Реляционная модель данных предложена сотрудником фирмы IBM Эдга­ром Коддом и основывается на понятии отношение.

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

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

Таблица имеет строки (записи) и столбцы (колонки). Каждая строка таб­лицы имеет одинаковую структуру и состоит из полей. Строкам таблицы со­ответствуют кортежи, а столбцам — атрибуты отношения.

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

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

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

Основными недостатками реляционной модели являются следующие: от­сутствие стандартных средств идентификации отдельных записей и слож­ность описания иерархических и сетевых связей.

Примерами зарубежных реляционных СУБД являются следу­ющие:, DB2 (IBM), R:BASE (Microrim), FoxPro, Paradox и dBASE for Windows (Borland),, Visual FoxPro и Access (Microsoft), Clarion (Clarion Software), и Oracle (Oracle).

К отечественным СУБД реляционного типа относятся системы: ПАЛЬ­МА (ИК АН УССР), а также система HyTech (МИФИ).