Анализ и оценка средств реализации структурных методов анализа и проектирования экономической информационной системы (Структурный анализ потоков данных (Структурный анализ потоков данных DFD )

Содержание:

Введение

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

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

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

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

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

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

Структурный подход к проектированию информационных систем

• 1. Основные понятия экономической информационной системы

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

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

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

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

В основном, в практике организации проектирования экономических информационных систем существует два подхода:

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

Причины, толкающие предприятия и банки разрабатывать свои автоматизированные информационные системы (АИС) собственными силами следующие:

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

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

• необходимо осуществить правильный выбор, как архитектуры построения корпоративной сети, так и профессиональные СУБД.
• использование при разработке современного инструментальных средств разработки (CASE средства, эффективные средства разработки: Delphi, Designer2000, Developer2000, SQL-Stations и т.п.);
• применение эффективных организационно-технических средств по управлению проектом и контролю версий АИС;
• освоение новых технологий, позволяющих разрабатывать АИС, с использование современных возможностей мобильной связи и интернет;
• создание полноценного комплекта документации, с последующей его корректировкой при изменении программ.

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

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

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

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

Метод и сущность структурного подхода

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

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

Второй, объектно-ориентированный подход использует объектную декомпозицию, но данную методологию в этой работе рассматривать не будем.

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

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

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

• принцип «абстрагирования» – выделение существенных аспектов системы и отвлечение от несущественных;
• принцип «непротиворечивости» – обоснованность и согласованность элементов системы;
• принцип «структурирования данных» – данные должны быть структурированы и иерархически организованы.

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

Структурированная (формализуемая) задача — задача, где известны все ее элементы и взаимосвязи между ними.

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

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

Структурный подход заключается в поэтапной декомпозиции системы при сохранении целостного о ней представления Основные принципы структурного подхода (первые два являются основными):

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

Анализ методологий структурного моделирования

2.1. Метод функционального моделирования IDEF0

В настоящее время одним из наиболее эффективных методов построения и анализа бизнес-процессов в предметной области является технология структурного анализа и проектирования систем. В её основе лежит использование IDEF-моделей.

DEF0 - методология функционального моделирования. Функциональная модель (модель деятельности) рассматривает систему как набор действий, в котором каждое действие преобразует некоторый объект или набор объектов. Функциональные модели выделяют действия посредством представления в виде специального элемента – блока (Рис. 2.1).

Рисунок 2.1 Блок

Первое основное понятие графического языка IDEF0 - это функциональный блок (Activity Box)

Рисунок 2.2 Функциональный блок

Функциональный блок (Рис. 2.2) графически изображается в виде прямоугольника и олицетворяет собой некоторую конкретную функцию в рамках рассматриваемой системы. По требованиям стандарта название каждого функционального блока должно быть сформулировано в глагольном наклонении (например, «производить услуги», а не «производство услуг»). Каждый функциональный блок в рамках единой рассматриваемой системы должен иметь свой уникальный идентификационный номер. Каждая из четырех сторон функционального блока имеет своё определенное значение:

• Верхняя сторона имеет значение «Управление» (Control);
• Левая сторона имеет значение «Вход» (Input);
• Правая сторона имеет значение «Выход» (Output);
• Нижняя сторона имеет значение «Механизм» (Mechanism).

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

Графическим отображением интерфейсной дуги является однонаправленная стрелка. Каждая интерфейсная дуга должна иметь свое уникальное наименование (Arrow Label). По требованию стандарта, наименование должно быть оборотом существительного.

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

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

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

Входящие и управляющие интерфейсные дуги имеют схожую природу. При проектировании важно правильно отделять их друг от друга. Например, «технологические указания» можно рассматривать как управление при обработке детали (Рис. 2.3):

Рисунок 2.3 «Технологические указания» в качестве управления

Когда имеем дело с процессом коррекции технологических указаний, «технологические указания» поступают на вход функционального блока (Рис. 2.4):

Рисунок 2.4 «Технологические указания» на входе

В случае рассмотрения предприятий и организаций существуют пять

основных видов объектов:

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

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

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

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

Модель IDEF0 всегда начинается с представления системы как единого целого - одного функционального блока с интерфейсными дугами, простирающимися за пределы рассматриваемой области. Такая диаграмма с одним функциональным блоком называется контекстной диаграммой, и обозначается идентификатором «А-0». В пояснительном тексте к контекстной диаграмме должна быть указана цель построения диаграммы (Purpose) в виде краткого описания и зафиксирована точка зрения (Viewpoint).

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

Правильный выбор точки зрения существенно сокращает временные затраты на построение конечной модели, поскольку именно точка зрения определяет основное направление развития модели и уровень необходимой детализации. Например, функциональные модели одного и того же предприятия, с точек зрения главного технолога и финансового директора, будут существенно различаться по направленности их детализации. В процессе декомпозиции, функциональный блок подвергается детализации на другой диаграмме. Получившаяся диаграмма второго уровня содержит функциональные блоки, отображающие главные подфункции функционального блока и называется дочерней (Child diagram) по отношению к нему. В свою очередь, диаграмма, которая содержит родительский блок (Parent Box), называется родительской диаграммой (Parent Diagram). Каждая из подфункций дочерней диаграммы может быть далее детализирована путем аналогичной декомпозиции соответствующего ей функционального блока. В случае декомпозиции функционального блока все интерфейсные дуги, входящие в данный блок, или исходящие из него фиксируются на дочерней диаграмме. Этим достигается структурная целостность IDEF0-модели (Рис. 2.5).

Рисунок 2.5 Декомпозиция функциональных блоков

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

Часто бывают случаи, когда отдельные интерфейсные дуги не имеет смысла продолжать рассматривать в дочерних диаграммах ниже какого-то определенного уровня в иерархии, или наоборот - отдельные дуги не имеют практического смысла выше какого-то уровня. Иногда необходимо избавиться от отдельных «концептуальных» интерфейсных дуг и не детализировать их глубже некоторого уровня. Для решения подобных задач в стандарте IDEF0 предусмотрено понятие туннелирования. Обозначение «туннеля» (Arrow Tunnel) в виде двух круглых скобок вокруг начала интерфейсной дуги обозначает, что эта дуга не была унаследована от функционального родительского блока и появилась (из «туннеля») только на этой диаграмме. В свою очередь, такое же обозначение вокруг конца интерфейсной дуги в непосредственной близи от блока - приёмника означает тот факт, что в дочерней, по отношению к этому блоку, диаграмме эта дуга отображаться и рассматриваться не будет.

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

Метод моделирования данных IDEF3

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

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

Технология IDEF3 также может быть использована как метод проектирования бизнес-процессов. IDEF3-моделирование органично дополняет традиционное моделирование с использованием стандарта IDEFO. В настоящее время оно получает все большее распространение как вполне жизнеспособный путь построения моделей проектируемых систем для дальнейшего анализа имитационными методами. Имитационное тестирование часто используют для оценки эксплуатационных качеств разрабатываемой системы.

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

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

Рис. 2.6 Схема бизнес-процесса в стандарте IDEF3.

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

Таблица 1. Типы связей между работами в стандарте IDEF3.

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

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

Перекресток "Исключающий ИЛИ" обозначает, что после завершения работы "A" (рис. 6), начинает выполняться только одна из трех расположенных параллельно работ B, С или D в зависимости от условий 1, 2 и 3. Перекресток "И" обозначает, что после завершения работы "A", начинают выполняться одновременно три параллельно расположенные работы B, С и D. Перекресток "ИЛИ" обозначает, что после завершения работы "A", может запуститься любая комбинация трех параллельно расположенных работ B, С и D. Например может запуститься только одна из них, могут запуститься три работы, а также могут запуститься двойные комбинации В и С, либо C и D, либо B и D. Перекресток "Исключающий ИЛИ" является самым неопределенным, так как предполагает несколько возможных сценариев реализации бизнес-процесса и применяется для описания слабо формализованных ситуаций.

Рис. 2.7 Применение перекрестков "Исключающий ИЛИ", "И" и "ИЛИ" - схемы расхождения.

Перекрестки "И" и "ИЛИ" подразделяются еще на два подтипа – синхронные и асинхронные. Перекрестки синхронного типа обозначают, что работы В, С и D запускаются одновременно после завершения работы A. Перекрестки асинхронного типа требований к одновременности не предъявляют.

Приведенные на рис. 2.7 схемы взаимосвязи работ и перекрестков называются схемами расхождения, так как от перекрестков расходятся несколько работ. Существует и другие схемы взаимосвязи перекрестков и работ – это так называемые схемы схождения, когда к перекрестку подходит несколько работ (рис. 2.8).

Рис. 2.8 Применение перекрестков "Исключающий ИЛИ", "И" и "ИЛИ" - схемы схождения.

В таблице 2 приведены обозначения, названия и смысл всех типов перекрестков как в схемах схождения, так и в схемах расхождения.

Таблица 2. Обозначения, названия и смысл типов перекрестков в схемах схождения и расхождения.

Название перекрестков		Обозначение перекрестков	Смысл перекрестков
			Схема расхождения	Схема схождения
"Исключающий ИЛИ"			Только одна последующая работа запускается	Только одна предшествующая работа должна быть завершена
"И"	Асинхронный		Все последующие работы запускаются	Все предшествующие работы должны быть завершены
	Синхронный		Все последующие работы запускаются одновременно	Все предшествующие работы должны быть завершены одновременно
"ИЛИ"	Асинхронный		Одна или несколько последующих работ запускаются	Одна или несколько предшествующих работ должны быть завершены
	Синхронный		Одна или несколько последующих работ запускаются одновременно	Одна или несколько предшествующих работ должны быть завершены одновременно

С помощью объектов ссылки показывается прочая важная информация, которую целесообразно зафиксировать при описании бизнес-процесса.

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

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

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

Структурный анализ потоков данных (DFD)

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

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

Построение DFD-диаграмм в основном ассоциируется с разработ­кой программного обеспечения, поскольку нотация DFD изначально была разработана для этих целей. В частности, графическое изображе­ние объектов на DFD-диаграммах этой главы соответствует принято­му Крисом Гейном (Chris Gane) и Тришем Сарсоном (Trish Sarson), ав­торами DFD-метода, известного как метод Гейна — Сарсона. Другой распространенной нотацией DFD является так называемый метод Йордана — Де Марко (Yourdon — DeMarco).

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

Функциональный блок DFD моделирует некоторую функцию, ко­торая преобразует какое-либо сырье в какую-либо продукцию (или, в терминах IDEF, вход в выход). Хотя функциональные блоки DFD и изображаются в виде прямоугольников с закругленными углами, они почти идентичны функциональ­ным блокам IDEFO и действиям IDEF3. Как и действия IDEF3, функциональные блоки DFD имеют входы и выходы, но не имеют управления и механизма исполнения как IDEFO. В не­которых интерпретациях нота­ции DFD Гейна — Сарсона механизмы исполнения IDEFO моделируются как ресурсы и изображаются в нижней части прямоугольника.

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

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

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

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

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

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

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

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

Уникальные номера присваиваются также каждому хранилищу данных и каждой внешней сущности вне зависимости от расположе­ния объекта на диаграмме. Каждый номер хранилища данных содержит префикс D (от английского Data Store) и уникальный номер хранилища в модели (например, D3). функционального блока DFD.

Аналогично каждый номер каждой внешней сущности содержит префикс Е (от английского External entity) и уникальный номер сущ­ности в модели (например, Е5).

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

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

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

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

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

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

системе. STD описывают отношения между входными и выходными управляющими потоками на управляющем процессе. STD моделируют последующее функционирование системы на основе ее предыдущего и настоящего функционирования.

Объекты STD

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

Цель - определяет будущее состояние по прошлому и текущему.

Переход - определяет перемещение системы из одного состояния в другое.

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

Событие - состоит из какого-либо управляющего потока (внешнего, внутреннего) и происходит при выполнении некоторого условия. При этом следует отметить:

• не все события вызывают переходы.
• события не всегда вызывают переходы.
• события не всегда вызывают переход в одно и то же состояние.

Условие - событие, вызывающее переход и названое именем перехода.

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

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

Пример STD диаграммы для работы банкомата приведен на рисунке 2.8.

На диаграмме элементы нотации обозначаются следующим образом:

• состояния – как узлы (например, Ожидание);
• переходы – как дуги (например, Корректный пароль);
• условия - идентифицируются именем перехода (например, Корректный пароль);
• действия - отклики на события, которые "привязываются" к переходам, записываются под условием (например, Обеспечить требуемый сервис).

STD имеет только одно начальное состояние. Но система может иметь большое количество завершающих состояний.

Контроль STD диаграмм осуществляется по типу метода контрольных

вопросов:

• все ли состояния определены и имеют имя?
• все ли состояния достижимы?

Для каждого состояния определяют:

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

Рисунок 2.8. Диаграмма перехода состояний STD

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

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

Рис. 2.9 Условные обозначения диаграмм переходов состояний:

a — терминальное состояние; б — промежуточное состояние; в — переход

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

Рисунок 2.10 Диаграмма переходов состояний

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

Матрица переходов состояний содержит по вертикали перечень состояний системы, а по горизонтали список условий. Каждый ее элемент содержит список действий, а также имя состояния, в которое осуществляется переход. Используется и другой вариант данной нотации: по вертикали показываются состояния, из которых осуществляется переход, а по горизонтали — состояния, в которые осуществляется переход. При этом каждый элемент матрицы со­держит соответствующие условия и действия, обеспечивающие переход из «вертикального» состояния в «горизонтальное».

1. Сравнительный анализ и оценка средств реализации структурных методов анализа и проектирования информационных систем

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

• DFD (Dаta Flоw Diagrams) - диаграммы потоков данных или SАDT-диаграммы, иллюстрирующие функции, которые должна выполнять система;
• ЕRD (Entity-Relationship Diagrams) - диаграммы "сущность-связь", моделирующие отношения между данными;
• SТD (State Transition Diagrams) - диаграммы переходов состояний, моделирующие зависящее от времени поведение системы (аспекты реального времени).

Так как в настоящее время практически нет альтернативы методологиям ЕRD и STD, используемых для, соответственно, информационного и поведенческого моделирования, интерес представляет сравнительный анализ средств функционального моделирования, а именно, DFD и SАDT-диаграмм.

С этой точки зрения все разновидности структурного системного анализа могут быть разбиты на две группы - применяющие методы и технологию DFD (в различных нотациях) и использующие SADT-методологию.

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

1. Адекватность средств решаемым задачам. Модели SАDT (IDEF0) используются традиционно для моделирования организационных систем (бизнес-процессов). С другой стороны, не существует принципиальных ограничений на использовании модели DFD в качестве средства моделирования бизнес-процессов.

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

2. Выразительные средства. В SАDT отсутствуют вообще выразительные средства для моделирования особенностей ИС, а DFD с самого начала создавались как средства проектирования ИС (тогда как SADT — как средство моделирования систем вообще) и имеют более богатый набор элементов, более адекватно отражающих специфику таких систем (к примеру, хранилища данных являются прообразами файлов или баз данных, внешние сущности отражают взаимодействие моделируемой системы с внешним миром).

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

3. Согласованность с другими средствами структурного анализа. Так как SADT-диаграммы предназначены для моделирования систем общего класса, в них отсутствуют средства описания данных и событий, то согласование модели, к примеру, с моделями ЕRD- или SТD практически невозможно.

 В свою очередь, модели DFD-, ERD- и STD- дополняют взаимно друг друга и по сути являются согласованными представлениями различных аспектов одной и той же модели.

Интеграция DFD→STD может быть осуществлена за счет расширения классической DFD специальными средствами проектирования систем реального времени (потоками, управляющими процессами, хранилищами данных). Интеграция DFD→ЕRD осуществляется с использованием отсутствующего объекта в SADT - хранилища данных, структура которого описывается в модели ЕRD и согласуется в DFD по соответствующим потокам и другим хранилищам.

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

5. Ограничения модели. Жесткие ограничения SADT, запрещающие использовать более 6—7 блоков на диаграмме, в ряде случаев вынуждают искусственно детализировать процесс, что затрудняет понимание модели заказчиком, резко увеличивает ее объем и, как следствие. В качестве примера можно рассмотреть модель операций по снятию денег с вклада физического лица в банке. Для моделирования этих операций целесообразно использовать единственную диаграмму DFD, так как все операции без исключения имеют одни и те же входы (сберегательная книжка и расходный ордер) и выходы (сберегательная книжка и наличные деньги), различаются лишь механизмами начисления процентов. Если попытаться структурировать данные операции в соответствии с ограничениями SADT путем группирования по какому-либо признаку (срочные, пенсионные и т.п.), то получится минимум 6 диаграмм, сложность каждой из которых не меньше сложности единственной DFD диаграммы.

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

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

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

Рассмотрим достоинства и недостатки рассмотренных средств реализации структурных методов анализа и проектирования информационных систем в таблице 3.

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

Название методики	Достоинства	Недостатки	Сфера применения
IDEF0	- полнота описания бизнес-процесса (управление, информацион­ные и материальные потоки, обратные связи); - комплексность декомпозиции; - возможность агрегирования и детализации потоков данных и информации (разделение и слияние дуг); - наличие жестких требований, обеспечивающих получение моде­лей стандартного вида; - простота документирования	- сложность восприятия (большое число дуг на диаграммах); - большое число уровней декомпозиции; - трудность увязки нескольких процессов, представленных в раз­личных моделях одной и той же организации	В наибольшей степени подходит для описания процес­сов верхнего уровня управления, для моделирования бизнес-процессов организации
IDEF3	- позволяет точно показать порядок действий, разветвления и параллельные процессы; - не ограничивает аналитика чрезмерно жесткими рамками синтаксиса, что может привести к созданию неполных или противо­речивых моделей; - содержит все необходимое для постро­ения моделей, которые в дальнейшем могут быть использованы для имитационного анализа	- отсутствие переноса и контроля стрелок на детализацию; - отсутствие возможности расщепления и слияния модели	Диаграммы DDEF3 удобно использовать, где нет документов (например, в описании действий автомата), IDEF3 может быть использован в дополнении к диаграмме IDEF0
DFD	- возможность однозначно определить внешние сущности, анализируя потоки информации внутри и вне системы; - возможность проектирования сверху вниз, что облегчает построение «как должно быть»; - наличие спецификаций процессов нижнего уровня, что позволяет преодолеть незавершенность функциональной модели	- необходимость искусственного ввода управляющих процессов, поскольку управляющие воздействия (потоки) и управляющие процессы в DFD ничем не отличаются от обычных; - отсутствие понятия времени (анализа временных промежутков)	Используется для описания документооборота и обработки информации. DFD-диаграмма легко преоб­разуется в UML-документ

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

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

Заключение

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

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

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

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

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

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

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

Список литературы

1. Балабанов И.Т. Современные моделирования./ И.Т. Балабанов - СПб: Питер, 2002. - 120 с.: ил. - (серия “Основы”).
2. Вендров А.М. Проектирование программного обеспечения экономических информационных систем: Учебник. – М.: Финансы и статистика, 2000. – 352 с.
3. Дубейковский, В.И. Практика функционального моделирования / В. И. Дубейковский– М.: Диалог-МиФи, 2004. – 464 с.
4. Калянов Г.Н. Теория и практика реорганизации бизнес-процессов. Серия «Реинжиниринг бизнеса». – М.: СИНТЕГ, 2000, 212 с.
5. Ларман К. Применение UML и шаблонов проектирования. Введение в объектно – ориентированный анализ и проектирование :Пер. с англ. – М.: Издательский дом «Вильямс», 2001. -496 с.
6. Маклаков С.В. BPwin и ERwin. CASE-средства разработки информационных систем. – М.: ДИАЛОГ-МИФИ, 2001 – 304 с.
7. Мишенин А.И. теория экономических информационных систем. М.: Финансы и статистика, 2007. 240 с.
8. Пустовалов Д., Архитектура программных систем сбора данных и управления Открытые системы М.: Издательство "Открытые системы" 1997. №5 с. 35
9. Репин В.В., Елиферов В.Г. Процессный подход к управлению. Моделирование бизнес-процессов. – Изд. «Стандарты и качество», 2009. – 408с.
10. Сериков А.В., Титов Н.В. Компьютерное моделирование бизнеспроцессов. – Изд. «Бурун Книга», 2007. – 304 с.
11. Смирнова Г.Н., Сорокин А.А., Тельнов Ю.Ф. Проектирование экономических информационных систем: Учебник.-М.: Финансы и статистика, 2002.-512 с.
12. Суркова Н.Е. Методы проектирования информационных систем / Н.Е. Сур-кова, А.В. Остроух. М.: РосНОУ, 2004. 144 с.
13. Ефимов В. Опьгг использования функционального моделирования при разработке банковских систем. - DiasoftNFO // Банковские технологии. - 1998. - Сентябрь. - С. 64-68.
14. Черемных С.В. и др. Моделирование и анализ систем IDEF-технологии: практикум. М.: Финансы и статистика, 2002. 192 с.