Файл: Задания заочникам ТИПИС.pdf

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

1.2 Основные черты CASE – технологии
1. использование методологии структурного проектирования "сверху-вниз"
2. разработка прикладной системы представляется в виде последовательных

четко определенных этапов:

3. поддержка

репозитария,

хранящего

спецификации

проекта

информационной системы на всех этапах ее разработки

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

реализации приложения

CASE-системы поддерживают следующие этапы процесса разработки:
1. Моделирование и анализ деятельности пользователей в рамках предметной

области.

2. Концептуальное моделирование - создание модели "сущность-связь" на

основе перечня объектов, полученного на предыдущем этапе.

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

соответствии с требованиями реляционной модели.

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

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

потокам данных.

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

для проектирования систем более общего назначения по сравнению с другими
структурными

методами,

выросшими

из

проектирования

программного

обеспечения.

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

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

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

выходные

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

произойти

3. Исполнитель осуществляет это преобразование
Каждый блок IDEF0-диаграммы может быть представлен несколькими

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

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

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

Несмотря на то, что методология IDEF0 получила широкое распространение в

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

Элемент

Описание

Обозначение

Функция

Действие,

выполняемое

моделируемой системой

Поток данных

Объект,

над

которым

выполняется

действие.

Может

быть

информационным
(логическим)

или

управляющим.
(Управляющие

потоки

обозначаются

пунктирной

линией со стрелкой).

Хранилище данных

Структура для хранения
информационных объектов

Внешняя сущность

Внешний по отношению к
системе

объект,

обменивающийся с нею
потоками данных

Функции, хранилища и внешние сущности на DFD-диаграмме связываются

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

При интерпретации DFD-диаграммы используются следующие правила:
1. Функции преобразуют входящие потоки данных в выходящие
2. Хранилища  данных  не  изменяют  потоки  данных,  а  служат  только  для

хранения поступающих объектов

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

с ними элементы данных.

Каждому элементу данных присваивается имя, также для него может быть

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

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

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