Файл: «Анализ и оценка средств реализации структурных методов анализ и проектирования экономической информационной системы».pdf

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

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

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

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

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

Он идентифицируется буквой «D» и произвольным числом. Имя накопителя выбирается из соображений наибольшей информативности для проектировщика.

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

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

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

---

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

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

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

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

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

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

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

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

---

Мини спецификация (описание логики процесса) должна

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

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

• наличие у процесса относительно небольшого количества входных и выходных потоков данных (2-3 потока);
• возможности описания преобразования данных процессом в виде последовательного алгоритма;
• выполнение процессом единственной логической функции преобразования входной информации в выходную; возможность описания логики процесса при помощи мини спецификации небольшого объема (не более 20-30 строк).

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

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

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

---

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

2.3. Диаграммы переходов состояний (SDT).

Используются для моделирования поведения систем STD (State Transition Diagrams)мы, зависящего от времени или реакций системы на некоторые события.

STD состоит из следующих объектов:

• Состояние – моделируемая система в любой заданный момент времени должна находится точно в одном из конечного множества состояний
• Начальное состояние является стартовой точкой для начального системного перехода, соответствующего состоянию системы после её инсталляции. STD должна иметь только одно начальное состояние, а также любое (конечное) число завершающих состояний.
• Переход определяет перемещение моделируемой системы из одного состояния в другое. При этом имя перехода идентифицирует событие, являющееся причиной перехода и управляющее им. Это событие обычно состоит из управляющего потока (сигнала), возникающего как во внешнем мире, так: и внутри системы при выполнении некоторого условия.
• Действие – это операция, которая может быть связана с переходом, и выполняющаяся при выполнении перехода

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

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

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

---

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

Такая совокупность методик, разработанная в США по программе компьютеризации промышленности ICAM (Integrated Computer-Aided Manufacturing), получила название IDEF (аббревиатура от Icam DEFinition или Integrated DEFefinition).

Название	Назначение
IDEF0	Функциональное моделирование (Function Modeling Method)
IDEF1 и IDEF1X	Информационное моделирование (Information and Data Modeling Methods)
IDEF2	Поведенческое моделирование (Simulation Modeling Method)
IDEF3	Моделирование процессов (Process Flow and Object State Description Capture Method)
IDEF4	Объектно-ориентированное проектирование (Object-Oriented Design Method).
IDEF5	Систематизация объектов приложения (Ontology Description Capture Method)
IDEF6	Использование рационального опыта проектирования (Design Rationale Capture Method)
IDEF8	Взаимодействие человека и системы (Human-System Interaction Design)
IDEF9	Учёт условий и ограничений (Business Constraint Discovery)
IDEF14	Моделирование вычислительных сетей (Network Design)

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

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

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

Госстандартом России приняты рекомендации по стандартизации Р50.1.028-2001 "Информационные технологии поддержки жизненного цикла продукции. Методология функционального моделирования". Они описывают язык моделирования IDEF0, правила и методику структурированного графического представления описания процессов (бизнес-процессов) предприятия или организации.

IDEF0 применяется для построения двух видов моделей.

При обследовании предприятия строится функциональная модель КАК ЕСТЬ, которая позволяет чётко зафиксировать, какие деловые процессы осуществляются на предприятии, какие информационные объекты используются при выполнении деловых процессов и отдельных операций.

---