Аис1

DATA STORE (хранилище данных) – графическое представление потоков данных импортируемых/экспортируемых из соответствующих баз данных. Обычно это таблицы для хранения документов. В отличие от стрелок, описывающих объекты в движении, хранилища данных изо-бражают объекты в покое. Накопители данных являются неким прообразом базы данных ин-формационной системы организации. Хранилища данных включаются в модель системы в том случае, если имеются этапы технологического цикла, на которых появляются данные, которые необходимо сохранять в памяти. При отображении процесса сохранения данных стрелка пото-ка данных направляется в хранилище данных, и, наоборот – из хранилища, если идет импорт данных.

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

в материальных системах - там, где объекты ожидают обработки, например в очереди;

в системах обработки информации для моделирования механизмов сохранения

данных для дальнейших операций.

По нотации Гейн-Сарсона хранилище данных обозначается двумя горизонтальными линиями, замкнутыми с одного края. Каждое хранилище данных должно идентифицироваться для ссылки буквой D и произвольным числом в квадрате с левой стороны, например D5. Имя должно подбираться с учетом наибольшей информативности для пользователя.

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

EXTERNAL REFERENCE (внешняя ссылка, внешняя сущность, external entities) – объект диаграммы потоков данных, являющийся источником или приемником информации извне модели. Внешние ссылки/сущности изображают входы и/или выходы, т.е. обеспечивают интерфейс с внешними объектами, находящимися вне моделируемой системы. Внешними ссылками системы обычно являются логические классы предметов или людей, представляю-щие собой источник или приемник сообщений, например, заказчики, конструкторы, технологи, производственные службы, кладовщики и т.д. Это могут быть специфические источники, такие, как бухгалтерия, информационно-поисковая система, служба нормоконтроля, склад. Если рассматриваемая система принимает данные от другой системы или передает данные в другую систему, то эта другая система является элементом внешней системы. Без объекта «внешняя сущность» аналитику бывает иногда сложно определить, откуда пришла в компанию данные документы. Или какие документы еще приходят от, такой внешней сущности как, например, "клиент".

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

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

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

OFF-PAGE REFERENCE (межстраничные ссылки) – инструмент нотации DFD, описывающий передачу данных или объектов с одной диаграммы модели на другую. Стрелка межстраничной стрелки имеет идентифицирующее имя, номер и изображение окружности. При интерпретации DFD-диаграммы используются следующие правила:

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

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

121

поступаю-щих объектов;преобразования потоков данных во внешних ссылках игнорируется.

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

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

Построение диаграмм

Диаграммы DFD могут быть построены с использованием традиционного структурного анализа, подобно тому, как строятся диаграммы IDEFO:

строится физическая модель, отображающая текущее состояние дел;

полученная модель преобразуется в логическую модель, которая отображает требования к существующей системе;

строится модель, отображающая требования к будущей системе;

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

Альтернативным подходом является подход, применяемый при создании программного обеспечения, называемый событийным разделением (event partitioning), в котором различные диаграммы DFD выстраивают модель системы:

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

с помощью модели окружения система описывается как взаимодействующий с событиями из внешних сущностей объект. Модель окружения (environment model) обычно содержит описание цели системы, одну контекстную диаграмму и список событий. Контекстная диаграмма содержит один блок, изображающий систему в целом, внешние сущности, с которыми система взаимодействует, ссылки и некоторые стрелки, импортированные из диаграмм IDEF0 и DFD. Включение внешних ссылок в контекстную диаграмму не отменяет требования методологии четко определить цель, область и единую точку зрения на моделируемую систему;

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

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

Пример DFD-диаграмм по нотации Гейна-Сарсона для предприятия, строящего свою деятельность по принципу "изготовление на заказ" приведен на рисунке.

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

122

обеспеченным и повторяет вышеописанный маршрут.

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

123

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

Автор, в свою очередь, также письменно соглашается с критикой или отвергает её с изложением логики принятия решения и вновь возвращает откорректированный черновик для дальнейшего рассмотрения. Этот цикл продолжается до тех пор, пока авторы и читатели не придут к единому мнению. Этап асинхронного письменного рецензирования модели, называется цикл «автор/читатель», в котором автором является разработчик (аналитик), а читателем - те, кто читает и критикует создаваемую модель (эксперты)

В результате, за достаточно короткое время и при привлечении минимума человеческих ресурсов со стороны консультационной компании получается модель предприятия по принципу «AS-IS», причем, она представляет предприятие с позиции сотрудников, которые в нем работают и досконально знают все нюансы, в том числе неформальные. В дальнейшем, эта модель будет передана на анализ и обработку к аналитикам, которые будут заниматься поиском «узких мест» и оптимизацией основных процессов, трансформируя модель «AS-IS» в соответствующее представление «TO-BE». На основании этих изменений и выносится итоговое заключение, которое содержит в себе рекомендации по реорганизации существующей ИС предприятия.

Этап 4. Контроль качества моделей. Когда автор считает, что диаграмма уже достаточно проработана и достигла уровня «Рекомендация», он пересылает ее библиотекарю для дальнейшей передачи на утверждение в комитет контроля, где она проходит окончательную экспертизу. Утверждение согласованной модели происходит руководителем рабочей группы в том случае, если у авторов модели и читателей отсутствуют разногласия по поводу ее адек-ватности. Окончательная модель представляет собой согласованное представление о пред-приятии (системе) с заданной точки зрения и для заданной цели. После внесения замечаний и окончательных изменений диаграмма (или набор диаграмм) окончательно утверждается, получает статус «Публикация» и может быть распечатана и распространена среди участников проекта. В дальнейшем, на базе построенной модели могут быть организованы новые проекты, нацеленные на производство изменений на предпри-ятии (в системе).

Папки IDEF

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

В папку могут включаться сопутствующие отчеты, в том числе словарь стрелок и функций, диаграмма верхнего уровня, дерево узлов и любая необходимая дополнительная документация. На папке регистрируются входящие данные - дата, автор, данные читателя и т. д. Термин «папка» относится в IDEF к части материалов, предназначенных для рецензирования. Понятие папки появилось в связи с тем, что IDEF-проекты технически организованы вокруг автора и группы читателей. Папка является основной единицей информации и основным средством общения между участниками IDEF-проекта. Взаимодействие между автором и читательской аудиторией является циклическим, в ходе которого созданные автором папки изучаются читателями и возвращаются к автору, который читает их и снова отсылает читателям. Обычно отдельная папка рецензируется одновременно несколькими читателями. После рецензирования папки возвращаются библиотекарю.

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

Таким образом, методология IDEF поддерживает как параллельный, так и асинхронный просмотр модели, что является наиболее эффективным способом распределения работы в коллективе.

125

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

Для большинства IDEF-проектов типичным является рабочая папка, включающая:

титульный лист;

одну контекстную диаграмму;

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

лист глоссария (возможно);

иллюстрации (возможно).

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

область идентификации, в которой авторы заполняют, так же как на диаграммах, проставляя свою фамилию, дату, название проекта, статус материалов и С-номера;

область для информации о содержании папки, в которой авторы записывают номер узла и название папки, а также номер узла, название и С-номер для каждой страницы папки;

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

для помещения замечаний о папке в целом

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

За титульным листом в порядке возрастания номеров узлов располагаются диаграммы. Листы иллюстраций и глоссария, которые дополняют диаграммы, располагаются сразу же после тех диаграмм, к которым они относятся. Если в папку включен дополнительный материал, количество диаграмм следует уменьшить.

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

Папка составляется:

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

если автору не хватает информации для продолжения работы или он сомневается в верности сделанного.

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

Завершение моделирования

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

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

126

модель не будет иметь одинаковую глубину. Хотя многие IDEF-модели имеют глубину 5-6 уровней, они чаще всего состоят не более чем из нескольких десятков диаграмм и редко превосходят предел в 100 диаграмм.

Обычно модель строится слоями, большинство из которых не являются глубокими, ибо ограничиваются тремя уровнями. Опыт показывает, что, как правило, создаются несколько диаграмм второго и третьего уровней только для того, чтобы убедиться, что для достижения цели уже первый уровень содержит достаточно информации. Типичной также является декомпозиция части IDEF-модели на глубину 5-6 уровней. В этом случае на такую глубину декомпозируется обычно один из блоков диаграммы АО. Функции, которые требуют такого уровня детализации, часто очень важны, и их детальное описание дает глубокое понимание работы всей системы. Но хотя важные функции могут нуждаться в глубокой детализации, таких функций при создании одной модели насчитывается, как правило, немного. Модели, такого типа называются «зонтичными», т.к. имеют форму зонтика с широким тонким куполом и длинной ручкой, на которой происходит детализация.

Большие аналитические проекты обычно разбиваются на несколько отдельных более мелких проектов, каждый из которых создает модель одного конкретного аспекта всей проблемы. Поэтому вместо одной неуправляемой гигантской модели создаётся сеть из нескольких небольших управляемых и понятных моделей.

Условия прекращения декомпозиции

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

если:

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

необходимо изменить уровень абстракции, чтобы достичь большей детализации функции. Иногда при декомпозиции блока выясняется, что диаграмма начинает описывать, как функционирует блок, вместо описания того, что блок делает. В этом случае происходит из-менение уровня абстракции - изменение сути того, что должна представлять модель (т.е. изменение способа описания системы). В IDEF0 изменение уровня абстракции часто означает выход за пределы цели модели и, следовательно, это указывает на прекращение де-композиции. Изменение уровня абстракции обычно происходит, когда модель уже имеет 2-3 уровня глубины, и их легко заметить. Небольшие изменения, однако, могут остаться неза-меченными для автора. Обычно ошибки обнаруживаются в процессе рецензирования диа-грамм. Свежий взгляд читательской аудитории определяет замену «что» на «как». Если изменение уровня абстракции не обнаружено во время цикла автор/читатель, то при следующей декомпозиции диаграммы оно обычно становится очевидным;

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

сигнализируют о возможной замене точки зрения:

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

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

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

127

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

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

определен блок, представляющий тривиальную функцию. Обычно такие тривиальные функции, понимание которых не требует никаких объяснений. Эти функции выполняют очень важную роль, поясняя работу более сложных функций, а иногда и соединяя вместе основные подсистемы. Поэтому при анализе не следует пропускать тривиальные функции. Наоборот, их существование должно быть зафиксировано и они должны быть детализированы, как и любые другие функции. В случае появления тривиальных функций целесообразным является отказ от декомпозиции, потому что роль IDEF0 заключается в превращении сложного вопроса в понятный, а не в разработке очевидных деталей. Разумно избегать декомпозиции тривиальных блоков, т.к. в таких случаях декомпозиция определенных бло-ков может принести больше вреда, чем пользы. Тривиальные функции лучше всего описываются небольшим объемом текста. Эффективность и производительность труда разработчиков функциональных моделей могут быть повышены за счет применения типовых моделей и отдельных диаграмм, ориентированных на применение в конкретных предметных областях.

Большинство IDEF0-моделей содержат от 10 до 320 диаграмм, поэтому лучшее время для начала оценки блоков, когда модель достигает этих размеров. Если какая-то часть модели достигла уровня, не требующего дальнейшей декомпозиции, то необходимо обратиться к собственному критерию для определения момента завершения моделирования, прежде чем декомпозировать блок, который еще не был детализирован.

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

Чтение диаграмм

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

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

128

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

Полная IDEF-модель обычно читается двумя способами:

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

в глубину - детальное чтение, при котором читают отдельную ветвь дерева вплоть до диа-грамм самого нижнего уровня.

Процесс чтения диаграммы разбивается на четыре последовательных этапа:

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

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

3.Уточнения места диаграммы в модели.

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

Этап изучения деталей

Для точного понимания деталей отдельной диаграммы читателю необходимо последовательно:

1.Прочитать название и номер узла диаграммы, содержащиеся на бланке. Название и номер узла позволяет сосредоточиться на обсуждаемом объекте и уровне его детализации в модели.

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

·что делает?

·что преобразует?

·определить входы и выходы;

·что ограничивает выполнение (его управления)?

3.Изучить внутренние дуги, что позволяет раскрыть:

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

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

-обратные связи. В IDEF можно описывать два типа обратной связи:

-по данным. Обратные связи по данным слабее, т.к. они просто передают данные от одной функции к другой; -по управлению. Обратные связи по управлению намного сильнее, т.к. они указы-

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

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

5.Просмотреть весь связанный с диаграммой дополнительный материал

(иллюстрации, текст и глоссарий), которые прилагаются к диаграммам для усиления наглядности контекста, разъяснения ключевых моментов или пояснения терминологии.

Этап изучения контекста и уточнения

129

места диаграммы

Этап изучения контекста

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

1. Блока и дуг, появляющихся на родительской диаграмме являющихся ограничениями для диаграммы-потомка. Чтение блока родительской диаграммы позволяет:

-получить представление об общей функции диаграммы;

-взаимосвязи диаграммы с остальными частями модели;

-определить ICOM-метки диаграммы;

-прочитать внешние дуги диаграммы и определить соответствие каждого из ICOMкодов одной из граничных дуг родительской диаграммы;

-если имеются какие либо несоответствия или пропуски, их следует отметить и сообщить об этом автору.

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

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

Этап уточнения места диаграммы

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

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

Этап критической оценки содержания

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

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

1.Верен ли синтаксис диаграммы?

2.Понимаю ли я, что хотел сказать автор?

130