Правило выбора управления

Часто возникает проблема, когда автор модели не может однозначно определить, к какому из типов дуг отнести ту или иную интерфейсную стрелку. Прежде всего такая ситуация возникает, когда речь идет об отображении на диаграмме информационных потоков. Для преодоления этой проблемы и существует правило выбора управления. В соответствии с этим правилом если одни и те же данные служат и для управления, и для входа, вычерчивается только стрелка управления. Этим подчеркивается управляющий характер данных и уменьшается сложность диаграммы (Error: Reference source not found).

Правила нумерации и именования диаграмм, блоков и дуг

Правило нумерации блоков

Каждый блок диаграммы декомпозиции получает номер, помещаемый в правом нижнем углу (Error: Reference source not found); порядок нумерации - от верхнего левого к нижнему правому блоку (в соответствии с доминированием блоков).

Правило нумерации диаграмм

Каждая диаграмма имеет свой уникальный код, который формируется следующим образом (Error: Reference source not found):

Правило именования

Имена блоков (выполняемых функций) и метки дуг должны быть уникальными (Error: Reference source not found). Если метки интерфейсных стрелок совпадают, это значит, что стрелки отображают тождественные данные.

Правила компоновки объектов диаграмм

Правило компоновки блоков

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

Правило рисования стрелок

Надо пытаться максимально увеличивать расстояние между параллельными стрелками (Error: Reference source not found), что облегчает размещение меток, их чтение и позволяет проследить пути стрелок.

Правило минимизации пересечений

При соединении большого числа блоков необходимо избегать необязательных пересечений стрелок. Следует минимизировать число петель и поворотов каждой стрелки (Error: Reference source not found

Правило связывания дуг

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

Дуги объединяются, если они имеют общий источник или приемник, или они представляют связанные данные. Общее название лучше описывает суть данных. Следует минимизировать число дуг, касающихся каждой стороны блока, если, конечно, природа данных не слишком разнородна (Error: Reference source not found).

Правило присоединения дуг к блокам

Если возможно, дуги присоединяются к блокам в одной и той же позиции. Тогда соединение дуг конкретного типа с блоками будет согласованным и чтение диаграммы упростится (Error: Reference source not found).

Процесс моделирования

В одной из лучших книг по SADT-моделированию дается следующая характеристика этой методологии: «В значительной мере успех методологии SADT объясняется ее графическим языком, хотя не менее ценным является сам процесс моделирования. Процесс моделирования в SADT включает сбор информации об исследуемой области, документирование полученной информации и представление ее в виде модели и уточнение модели посредством итеративного рецензирования. Кроме того, этот процесс подсказывает вполне определенный путь выполнения согласованной и достоверной структурной декомпозиции, что является ключевым моментом в квалифицированном анализе системы. SADT уникальна в своей способности обеспечить как графический язык, так и процесс создания непротиворечивой и полезной системы описаний». Если процесс моделирования описанный в РД IDEF0-2000 представить в нотации IDEF0, то получится следующее видение (Error: Reference source not found

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

6. Нотация DFD. Виды нотаций DFD. Синтаксис DFD. [8]

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

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

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

• наличие большого количества внешних сущностей (десять и более);

• распределенная природа системы;

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

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

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

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

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

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

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

Миниспецификация является конечной вершиной иерархии DFD. Решение о завершении детализации процесса и использовании миниспецификации принимается аналитиком исходя из следующих критериев:

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

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

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

• возможности описания логики процесса при помощи миниспецификации небольшого объема (не более 20-30 строк).

Синтаксис DFD включает четыре основных элемента:

• поток данных;

• процесс;

• хранилище;

• внешняя сущность.

Рассмотрим эти элементы подробнее.

Поток данных

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

Потоки на диаграммах изображаются стрелками (обычно именованными), ориентация которых указывает направление движения информации (Error: Reference source not found).

ОПР.: Процесс преобразует значения данных.

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

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

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

ОПР. 2: ХРАНИЛИЩЕ (НАКОПИТЕЛЬ) ДАННЫХ позволяет на определенных участках определять данные, которые будут сохраняться в памяти между процессами. Фактически хранилище представляет "срезы" потоков данных во времени. Информация, которую оно содержит, может использоваться в любое время после ее определения, при этом данные могут выбираться в любом порядке. Имя хранилища должно идентифицировать его содержимое и быть существительным. В случае, когда поток данных входит или выходит в/из хранилища, и его структура соответствует структуре хранилища, он должен иметь то же самое имя, которое нет необходимости отражать на диаграмме.

ОПР. 1: ВНЕШНЯЯ СУЩНОСТЬ (или ТЕРМИНАТОР) представляет сущность вне контекста системы, являющуюся источником или приемником системных данных. Ее имя должно содержать существительное. Предполагается, что объекты, представленные такими узлами, не должны участвовать ни в какой обработке.

ОПР. 2: Под внешней сущностью (External Entity) понимается материальный объект, являющийся источником или приемником информации.

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

7. Нотация IDEF3. Типы диаграмм в IDEF3. Синтаксис IDEF3. [8]

ОПР. 1: IDEF 3 – (workflow modeling, Рrocess Description Capture Method) методология описания бизнес-процессов (потоков работ).

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

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

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

• Определять и анализировать точки слияния и разделения потоков информации.

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

• Содействовать принятию оптимальных решений при реорганизации процессов.

• Разрабатывать модели процессов, по принципу "КАК БУДЕТ, ЕСЛИ..."

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