Лекции по "Информационному технологии"

Лекция. Моделирование потоков данных

 Лекция № 4

 

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

 

 

Содержание

(Программные  вопросы лекции)

 

1. Средства и правила описания элементов модели Гейна-Сарсона.

2. Описание структурных  элементов модели.

 

Литература

1. [3], с. 28-34.
2. [4], с. 18-38, 159-174.

Учебно-материальное обеспечение

Организационно-методические указания

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

 

Введение

 

 

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

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

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

3. Возможность детализации потоков  и накопителей данных с описанием их элементов в виде структурограмм;

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

5. 85-90% существующих CASE-систем поддерживают  ДПД и лишь 2-3% – SADT.

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

 

 

Учебные вопросы

 

1. Средства  и правила описания элементов  модели Гейна-Сарсона

В настоящее время широко применяются  следующие методологии ССА:

методология Гейна-Сарсона, используемая в CASE.Аналитик;

методология Йордона, используемая в CASE Vantage Team Builder.

Данные методологии близки по своей  сущности. Основные отличия заключаются в порядке изображения элементов модели и их детализации. В лекции рассматривается методология Гейна-Сарсона.

В соответствии с данной методологией модель функционирования АСОИУ определяется как иерархия диаграмм информационных потоков (ДИП) и описаний их элементов в виде структурограмм.

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

Диаграммы верхних уровней  иерархии – контекстные диаграммы (КД) определяют основные подсистемы (функциональные области) АСОИУ с внешними входами и выходами. Эти подсистемы детализируются при помощи диаграмм нижнего уровня, показывающие проходящие через них информационные потоки, процессы преобразования потоков, а также используемые накопители данных (НД) и информационные каналы (ИК).

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

структурный естественный язык;

псевдокод;

визуальные языки проектирования (типа FLOW-форм и диаграмм Насси-Шнейдермана);

формальные компьютерные языки.

Детализация содержания информационных потоков, ИК, НД описывается при помощи структурограмм описания данных (СГД). В зависимости от типа детализируемого элемента различают следующие типы СГД:

структурограммы данных,

структурограммы событий,

структурограммы накопителей,

структурограммы каналов.

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

Для построения Мф по методологии  Гейна-Сарсона, с учетом особенностей ее применения в CASE.Аналитик используются следующие основные структурные элементы:

внешняя сущность (ВС);

подсистема (ПС);

процесс (П);

управляющий процесс (УП);

информационный поток (ИП): поток данных (ПД) и поток  управления (ПУ);

накопитель данных (НД);

информационный канал (ИК).

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

Основные правила  записи в нотации Бэкуса-Наура:

А В – объект типа “А” детализируется при помощи объекта типа “В”.

А=ВС – объект А состоит из объектов В и С;

А=В|С – объект А состоит либо из В, либо из С;

А=[В] – объект А может состоять либо из В,  либо из пустого множества;

А={В} – объект А может состоять из любого числа (даже Æ) объектов В.

При построении модели функционирования используют следующие типы ДИП:

контекстные диаграммы (КД);

диаграммы потоков управления (ДПУ);

диаграммы потоков данных (ДПД).

Таким образом, с учетом рассмотренных  элементов можно определить компоненты ДИП в нотации Бэкуса-Наура:

<КД> = {<ПС>}{<ВС>}{<ИК>}{<ИП>}

<ДПУ> = {<УП>}{<П>}{<ИК>}{<ВС>}{<ИП>}

<ДПД> = {<П>}{<ВС>}{<ИК>}{<НД>}{<ПД>}

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

 

2. Описание структурных элементов ДИП

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

Например, при моделировании системы  производства полетов в а/ч РЛС является элементом внешнего окружения, не входящим в систему. Следовательно, в модели (если это необходимо учесть) РЛС должна быть представлена в виде внешней сущности (ВС) и выступает в роли источника информации (передача РЛИ).

Каждая ВС должна иметь  собственное имя и, если есть дублирование, номер копии. Графическое представление  показано на рис.1. Тогда в нотациях Бэкуса-Наура:

<Внешняя  сущность> = <имя>[<номер копии>].

Подсистема (рис.2) – характеризует относительно самостоятельный вид деятельности в системе, не зависящий от ее конкретной структуры.

Подсистема является составной частью контекстной диаграммы и отражает конкретную функционально законченную часть автоматизируемой предметной области: "Управление полетами ЛА в а/ч", "Планирование полетов в а/ч". Она может детализироваться с помощью ДПУ или ДПД. В контекстной диаграмме должна присутствовать хотя бы одна подсистема.

Каждая подсистема имеет  свой уникальный номер, имя и наименование органа, который реализует составляющие ее процессы. Тогда в нотациях Бэкуса-Наура:

<Подсистема> = <номер><имя><реализующий орган>;

<Подсистема>® <Диаграмма информационных потоков>.

 

Процесс (рис.3) – элементарное действие по преобразованию (в соответствии со своей внутренней логикой) входных информационных потоков в выходные.

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

Нумерация процесса отличается от нумерации подсистем и осуществляется в соответствии с его положением в иерархии диаграмм и номером в конкретной ДИП. В нашем случае нумерация данного процесса будет иметь вид "1.3".

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

Тогда в нотациях Бэкуса-Наура:

<Процесс> = <номер><имя><реализация>;

<Процесс>® <Диаграмма потоков данных>½<Мини-спецификация>.

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

Управляющий процесс (рис.4.) – “командный пункт”, который, реагируя на изменение внешних условий, выдает команды, выполняемые процессами.

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

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

Выделение связей между  элементами диаграммы одного уровня осуществляется с помощью информационных потоков (ИП).

Логически информационный поток есть информация, передаваемая через некоторое соединение от источника  к приемнику.

Различают два типа ИП – поток данных (ПД) и поток  управления (ПУ). Тогда:

<Информационный  поток> = <поток данных> | <поток управления>;

Поток данных (рис.5) – информация, передаваемая через некоторое соединение от источника к приемнику.

Поток данных описывается  именем, отражающим семантику (смысл) передаваемых данных. В нотациях Бэкуса-Наура:

<Поток данных> = <имя>;

<Поток данных>®<Структурограмма данных>.

Поток управления (рис. 6) – управляющая информация (команда), обработка которой процессом, приводит к изменению состояния системы..

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

 

Накопитель данных (рис.7) – представляет собой устройство для хранения информации, куда ее можно поместить и через некоторое время изъять.

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

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

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

Таким образом, в нотациях Бекуса-Наура:

<Накопитель  данных> = <номер накопителя><имя>[<номер  копии>];

<Накопитель  данных>® <Структурограмма накопителя>.

Информационный канал.

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

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

"Состояние боевой готовности а/ч";

"Анализ причин летных происшествий в а/ч";

"Состояние авиационной  техники" и др.