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

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

4. Поток данных (англ. Data flow). В нотации отображается в виде стрелок, которые показывают, какая информация входит, а какая исходит из того или иного блока на диаграмме.

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

Какие правила необходимо знать, чтобы создать DFD диаграмму:

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

DFD-диаграммы активно применяются при разработке программного обеспечения. При этом:

- хранилища данных - это электронные таблицы и базы данных,

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

- процессы - это выполняемые функции и модули в системе.

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

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

STD - State Transition Diagrams - диаграммы переходов состояний - методология моделирования последующего функционирования системы на основе ее предыдущего и текущего функционирования.

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

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

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

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

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

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

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

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

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

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

1) Программный пакет Design/IDEF (Meta Software Corp.) – графическая среда, позволяющая осуществлять проектирование и моделирование систем различного уровня сложности и назначения. Программный пакет поддерживает несколько методология, а именно:

• методологии по описанию и моделированию системных функций (IDEF0/SADT)
• методологии описания структуры системы и потоков данных внутри системы (IDEF1, IDEF1X,E-R)
• методологии описания поведения проектируемой системы(IDEF/CPN).

С помощью пакета Design/IDEF был были созданы проекты систем высокого уровня сложности. Анные системы автоматизировали производство, управление контролем, компьютезировали телекоммуникации и аэрокосмонавтику. Данный программный пакет использован в качестве составной части в таких известных пакетах как «САЕ» и «CIM». Он принят за стандарт для выполнения проектов, финансирование которых производится американскими и европейскими разработчиками.

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

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

Возможности пакета программ Design/IDEF:

1. Возможность представления графики. Пакет Design/IDEF позволяет быстро и качественно представить проектируемую информационную систему в графическом виде, включая создание различных объектов – как стандартных, так и пользовательских, манипуляции с этими объектами, указание атрибутов и надписей. Дополнительно имеются возможности для осуществления редактирования данных, построения различного типа линий, а также осуществление маршрутизации и связывания дуг.
2. Обеспечение поддержки проверки непротиворечивости модели. В пакет Design/IDEF включены специальные возможности, позволяющие осуществить проверку разрабатываемой модели на точность, целостность и непротиворечивость. Причем данная проверка может проводится на любом этапе создании информационной системы, и не один раз. Так при изменении текста, описывающего дугу или функциональный блок в одной части модели, то и в случае нахождения этого блока или дуги на других страницах модели, соответствующий текст будет изменен автоматически.
3. Наличие словаря данных. Пакет Design/IDEF имеет поддержку встроенного словаря, позволяющего хранить информации, производить оздание отчетов о функциях и потоках данных. Так же он позволяет определить начальную информацию о каждом объекте. С помощью словаря возникает возможность востановления и сохранения целостности файлов данных. Все возможности использования словаря данных имеют большую гибкость и позволяют для каждого параметра указывать неограниченное количество параметров.
4. Возможность генерации отчетов. Пакет Design/IDEF позволяет генерировать пять видов отчетов: отчет по контролю за полнотой модели, отчет по функциям, отчетом по дугам, отчет по ссылкам, IDEF-отчет. Отчеты можно как отобразить на экране компьютера, так и вывести на принтер. Также отчеты могут быть экспортированы для использования данных в других программных пакетах.
5. Возможность коллективной работы. Пакет Design/IDEF позволяет работать группе разработчиков работать одновременно над одной IDEF-моделью. Причем все подмодели легко объединяются в одну модель.

Пакет Design/IDEF имеет поддержку все первые стадии создания информационной системы:

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

2) Программный пакет Power Designer функционально разбит на несколько модулей:

1. Process Analyst – модуль для функционального моделирования, имеют поддержку нотаций Йордона-де Марко, Гейна-Сарсона и некоторых других. Существует возможность описания элементов данных, связанных с потоками данных, а также с хранилищами данных. Все элементы впоследствии передаются на следующий этап проектирования, при этом имеется возможность автоматического преобразования хранилища данных в сущности.
2. Data Analyst – модуль, служащий для построения моделей «сущность-связь». Также существует возможность автоматически генерировать на основе модели «сущность-связь» реляционной структуры. Причем исходные данные для модели «сущность-связь» можно получить из DFD-моделей, созданных ранее. Существует поддержка синтаксиса языка SQL приблизительно для 30 реляционных СУБД, при этом существует возможность генерации структуры базы данных. Для этого создается сценарий языка SQL (набор команд CREATE для создания таблиц и связей между ними), после выполнения которого создаст спроектированную структуру базы данных. Также можно задать параметры соединения с СУБД (как правило используя интерфейс ODBC) и получить готовую базу данных автоматически. Имеются возможности автоматической проверки правильности моделей, расчета размера проектируемой базы данных, построения диаграмм и т.д.
3. Application Modeler – модуль, позволяющий автоматически генерировать прототипы программ для обработки данных, основываясь на моделях, построенных в модуле Data Analyst. Результатом работы модуля является программный код для языков Visual Basic и Delphi, либо для систем разработки PowerBuilder, Uniface, Progress и др. Программный код генерируется на основе шаблонов, поэтому управление процессом генерации может осуществляться только путем соответствующего шаблона.

На российском сервере компании Sybase находится ознакомительная демо-версия пакета Power Designer. Ограничение её функционала лишь в заблокированной возможности сохранения построенных моделей.