Основные черты CASE – технологии

1. поддержка репозитария, хранящего спецификации проекта информационной системы на всех этапах ее разработки

2. возможность одновременной работы с репозитарием многих разработчиков

3. автоматизация различных стандартных действий по проектированию и реализации приложения

CASE-системы поддерживают следующие этапы процесса разработки:

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

2. Концептуальное моделирование - создание модели "сущность-связь" на основе перечня объектов, полученного на предыдущем этапе.

3. Реляционное моделирование - преобразование модели "сущность-связь" в соответствии с требованиями реляционной модели.

4. Генерация схемы базы данных.

5. Генерация прототипов программных модулей по иерахии функций и потокам данных.

Методология SADT (Structured Analisys and Design Technique) разработана Дугласом Т. Россом в 1969-73 годах. Она изначально создавалась для проектирования систем более общего назначения по сравнению с другими структурными методами, выросшими из проектирования программного обеспечения.

IDEF0 (подмножество SADT) используется для моделирования бизнес-процессов в организационных системах и имеет развитые процедуры поддержки коллективной работы.

Правила интерпретации модели:

1. Функциональный блок (функция) преобразует входные объекты в выходные

2. Управление определяет, когда и как это преобразование может или должно произойти

3. Исполнитель осуществляет это преобразование

Каждый блок IDEF0-диаграммы может быть представлен несколькими блоками, соединенными интерфейсными дугами, на диаграмме следующего уровня. Эти блоки представляют подфункции (подмодули) исходной функции. Каждый из подмодулей может быть декомпозирован аналогичным образом. Число уровней не ограничивается, зато рекомендуется на одной диаграмме использовать не менее 3 и не более 6 блоков.

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

Диаграммы потоков данных (DFD - Data Flow Diagramm)

нотация Йордона - Де Марко

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

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

При интерпретации DFD-диаграммы используются следующие правила:

1. Функции преобразуют входящие потоки данных в выходящие

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

3. Преобразования потоков данных во внешних сущностях игнорируется

Для каждого информационного потока и хранилища определяются связанные с ними элементы данных.

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

Информационные хранилища преобразуются в сущности, проектировщику остается только решить вопрос с использованием элементов данных, не связанных с хранилищами.

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

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

Поиск по сайту: