Лекции - Проектирование автоматизированных систем обработки и управления (АСОиУ)

Подождите немного. Документ загружается.

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

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

использованию знаний системного аналитика, владеющего методологией и

техникой IDEF0, и знаний специалистов – экспертов в предметной области,

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

7. Отделение «организации» от «фун кции». При разработке моделей следует

избегать изначальной «привязки» функций исследуемой системы к

существующей организационной структуре моделируемого объекта. Это

помогает избежать субъективной точки зрения, навязанной

организационной структурой и ее руководством. Организационная

структура должна явиться результ атом использования модели. Сравнение

результата с существующей структурой позволяет, во-первых, оценить

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

совершенствование этой структуры.

Компонентами синтаксиса IDEF0 являются:

• блоки – представляют функции, определяемые как деятельность, процесс,

операция, действие или преобразование;

• стрелки – представляют данные или материальные объекты, связанные с

функциями;

• диаграммы – обеспечивают формат графического и словесного опис ани я

моделей.

Достоинство функциональной модели заключается в простоте

графического представления, которое и спользует всего два конструктивных

элемента: «блок» и «стрелки».

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

представляет функцию или активную часть проце сс а, продуцирующую

действие. Поэтому названиями блоков должны быть глаголы в неопределенной

форме с последующим дополнением, например, «принять заказ», «определить

потребность» и т.д. Название записывается внутри прямоугольника, поэтому

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

название дается по названию действия, обеспечивающего основной выходной

результат процесса.

Блоки на диаграмме нумеруются. Номер проставляется в правом нижнем

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

соответ ствующем тексте.

Число блоков на одной диаграмме должно быть от двух до семи. Блоки

размещают на диаграмме в определенном порядке – по степени важности или

по порядку очередности выполнения. Этот порядок называется

доминированием. Более доминирующие блоки размещаются выше и левее

относительно менее доминирующих. В ре зультате получается ступенчатая

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

остальные.

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

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

возникать различные альтернативные варианты декомпозиции. Такие варианты

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

номеру диаграммы).

Каждая сторона функционального блока имеет определенное назначение:

• левая предназначена для входов;

• верхняя – для управления;

• правая – для выходов;

• нижняя – для механизмов (исполнителей).

Такая спецификация отражает определе нные системные п ринципы,

принятые при построении диаграмм модели в стандарте IDEF0:

• входы преобразуются в выходы;

• управление предписывает или ограничивает условия выполнения

преобразований; управление в ходе выполнения БП, как правило, остается

неизменным;

• механизмы (исполнители) показывают, кто или что выполняет

преобразование. По завершении БП механизмы могут покидать из БП

практически в неизменном состоянии.

Интерфейсные дуги изображают ся в виде стрелок, ориентация которых

отображает направление потоков объектов. Объекты могут быть различной

природы: материальные, финансовые, информационные.

Стрел ки не предст авляют послед овательно сть событий , ка к в

традиционных блок-схемах. Они лишь показывают потоки объектов. Потоки

объектов однонаправленны, т.е. на интерфейсной дуге может быть только одна

стрелка.

Дуги помечаются текстовыми метками. Так как метки изображают

объекты, то метки должны быть именами существительными или

существительными с определениями.

По характеру использования в функциональных блоках объекты могут

быть:

• входными;

• выходными;

• управляющими;

• механизмами (исполнителями).

Управляющие объекты соответствуют нормативным актам

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

выполняются процессы. Кроме того, управляющие объекты рассматриваются

как ограничения, обстоятельства, условия выполнения процесса, например,

«номенклатура – ценники», «списки клиентов и поставщиков», «состояние

запасов», «состояние расчетного счета», «загруженность производственных

мощностей» и пр. Управляющие объекты должны обязательно отражаться в

функциональной модели, а входные объекты – не обязательно.

Механизмы – это объекты, которые исполняют процессы (исполнители).

К механизмам относят структурные подразделения предприятия, персонал,

автоматизированные рабочие места, оборудование.

Интерфейсные дуги в соответствии со своим типом должны соединяться

с соответ ствующими сторонами функциональных блоков:

• входные дуги – с левой стороной блока;

• выходные дуги – с правой стороной блока;

• управляющие дуги – с верхней стороной блока;

• дуги механизмов (исполнителей) – с нижней стороной блока.

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

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

объектом, или механизмом для другого функционального блока.

В ряде случаев нецелесообразно передавать объекты с одного уровня

декомпозиции на другой. Например:

• важные объекты системы, не показанные ранее на более высоких уровнях

описания модели, могут появляться при описании новых деталей. В то же

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

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

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

уровней модели. Их передача на более детальные уровн и загромоздит

диаграмму.

Если дугу нецелесообразно передавать на другой уровень детализации, то

ее помещают в «туннель». Помещение дуги в «туннель» является способом

скрыть ее источник (приемник).

Существуют два вида помещаемых в туннель дуг:

• со скрытым источником – дуга как бы появляется «из туннеля».

• со скрытым приемником – дуга как бы уходит «в туннель».

Дуга со скрытым источником помечается круглыми скобками у своего

нача ла. Дуга со скрытым приемником помечается круглыми скобками у сво его

конца (у стрелки).

18 МЕТОДОЛОГИЯ ПОТОКОВ ДАННЫХ DFD

В основе данной методологии лежит построение модели анализируемой

ИС – проектируемой или реа льно существующей. В соответствии с

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

данных (DFD), описывающих асинхронный процесс преобразования

информации от ее ввода в систему до выдачи пользователю. Диаграммы

верхних уровней иерархии (контекстные диаграммы) определяют основные

процессы или подсистемы ИС с внешними входами и выходами. Они

детализируются при помощи диаграмм нижнего уровня. Такая декомпозиция

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

не будет до стигнут т акой уровень декомпозиции, на котором проце сс

становятся элементарными и детализировать их далее невозможно.

Источники информации (внешние сущности) порождают информацион-

ные потоки (потоки данных), переносящие информацию к подсистемам или

процессам. Те в свою очередь преобразуют информацию и порождают новые

потоки, которые переносят информацию к другим процессам или подсистемам,

накопителям данных или внешним сущностям – потребителям информации.

Таким образом, основными компонентами диаграмм потоков данных являют ся:

• внешние сущности;

• системы/подсистемы;

• процессы;

• накопители данных;

• потоки данных.

Внешняя сущность представляет собой материальный предмет или

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

например, заказчики, персонал, поставщики, клиенты, склад. Определение

некоторого объекта или системы в качестве внешней сущности указывает на то,

что она находится за пределами границ анализируемой ИС. В процессе анализа

некоторые внешние сущности могут быть перенесены внутрь диаграммы

анализируемой ИС, если это необходимо, или, наоборот, часть процессов ИС

может быть вынесена за пределы диаграммы и представлена как внешняя

сущность.

Внешняя сущность обозначается квадратом (рисунок 21.1),

расположенным как бы «над» диаграммой и бросающим на нее тень, для того,

чтобы можно было выделить этот символ среди других обозначений:

Рисунок 21.1 – Внешняя сущность

При построении модели сложной ИС она может быть представлена в

самом общем виде на так называемой контекстной диаграмме в виде одной

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

подсистем.

Подсистема (или система) на контекстной диаграмме изображается

следующим образом (рисунок 21.2).

Рисунок 21.2 – Подсистема

Номер подсистемы служит для ее идентификации. В поле имени вводится

наименование подсистемы в виде предложения с подлежащим и

соответ ствующими определениями и дополнениями.

Процесс представляет собой преобразование входных потоков данных в

выходные в соответствии с определенным алгоритмом. Физически процесс

может быть реализован различными способами: это может быть подразделение

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

программа, аппаратно реализованное логическое устройство и т.д.

Процесс на диаграмме потоков данных изображается, как показано на

рисунке 2.15.

Рисунок 21.3 – Процесс

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

наименование процесса в виде предложения с активным недвусмысленным

глаголом в неопределенной форме, за которым следуют существительные в

винительном падеже, например, «ввести сведения о клиентах».

Информация в поле физической реализации показывает, какое

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

данный процесс.

Накопитель данных представляет собой абстрактное устройство для

хранения информации, которую можно в любой момент поместить в накопитель

и через некоторое время извлечь, причем способы помещения и извлечения

могут быть любыми.

Накопитель данных может быть реализован физически в виде таблицы в

оперативной памяти. Нако питель данных на диаграмме потоков данных

изображается, как показано на рисунке 21.4

Рисунок 21.4 – Накопитель данных

Накопитель данных идентифицируется буквой «D» и произвольным

числом. Имя накопителя выбирается из соображения наибольшей

информативности для проектировщика.

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

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

информационной моделью.

Поток данных определяет информацию, передаваемую через некоторое

соединение от источника к приемнику. Реальный поток данных может быть

информацией, передаваемой по кабелю между двумя устройствами,

пересылаемыми по почте письмами, магнитными лентами или дискетами,

переносимыми с одного компьютера на другой и т.д.

Поток данных на диаграмме изображается линией, оканчивающейся

стрелкой, которая показывает направление потока (рисунок 21.5). Каждый

поток данных имеет имя, отражающее его содержание.

Рисунок 21.5 – Поток данных

Первым шагом при построении иерархии DFD является построение

контекстных диаграмм. Обычно при проектировании относительно про стых ИС

строится единственная контекстная диаграмма со звездообразной топологией, в

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

приемниками и источниками информации, посредством которых с системой

взаимодействуют пользователи и другие внешние системы.

Если же для сложной системы ограничиться единственной контекстной

диаграммой, то она будет содержать слишком большое количество источников и

приемников информации, которые трудно расположить на листе бумаги

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

раскрывает структуры распределенной системы.

Для сложных ИС строится иерархия контекстных диаграмм. При этом

контекстная диаграмма верхнего уровня содержит не единственный главный

процесс, а н абор подсистем, соединенных потоками данных. Контекстные

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

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

функциональных подсистем проектируемой ИС как между собой, так и с

внешними входными и выходными потоками данных и внешними объектами, с

которыми взаимодействует ИС.

После построения кон текстных диаграмм полученную модель следует

проверить на полноту исходных данных об объектах системы и

изолированность объектов (отсутствие информационных связей с другими

объектами).

Для каждой подсистемы, присутствующей на контекстных диаграммах,

выполняется ее дета лизаци я при помощи DFD. Каждый процесс на DFD, в

свою очередь, может быть детализирован при помощи DFD или

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

правила:

• правило балансировки – означает, что при детализации подсистемы или

процесса детализирующая диаграмма в качестве внешних источников/

приемников данных может иметь только те компоненты, с которыми имеет

информационную связь дета лизируемая подсистема или проце сс на

родительской диаграмме;

• правило нумерации – означает, что при детализации процессов должна

поддерживатьс я их иерархическая нумерация. Наприм ер, процессы,

детализирующие процесс с номером 12, получают номера 12.1, 12.2 и т.д.

Миниспецификация (описание логики процесса) должна формулировать

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

выполняющий реализацию проекта, смог выполнить их или разработать

соответ ствующую программу.

Миниспецификация является конечной вершиной иерархии DFD.

Решение о завершении детализации процесса и использовании миниспецифика-

ции принимается аналитиком исходя из следующих критериев:

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

выходных потоков данных (2-3 потока);

• возможно сти описания преобразования данных проце ссом в виде

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

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

входной информации в выходную;

• возможности описания логики процесса при помощи миниспецификации

небольшого объема (не более 20-30 строк).

При построении иерархии DFD переходить к детализации процессов

следует только после определения содержания всех потоков и накопителей

данных, которое описывается при помощи структур данных. Структуры данных

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

условные вхождения и итерации. Условное вхождение означает, что данный

компонент может отсутствовать в структуре. Альтернатива означает, что в

структуру может входить один из перечисленных элементов. Итерация означает

вхождение любого числа элементов в указанном диапазоне. Для каждого

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

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

см и т.п.), диапазон значений, точность представления и форма физического

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

значений.

После построения законченной модели системы ее необходимо

верифицировать (проверить на полноту и согласованность). В полной модели

все ее объекты (подсистемы, процессы, потоки данных) должны быть подробно

описаны и детализированы. Выявленные недетализированные объекты следует

детализировать, вернувшись на предыдущие шаги разработки. В согласованной

модели для всех потоков данных и накопителей данных должно выполняться

правило сохранения информации: все поступающие куда-либо данные должны

быть считаны, а все считываемые данные должны быть записаны.