48965 (Система безналичных расчетов платежными поручениями), страница 3

Диаграмма декомпозиции в методологии DFD представлена на рис.7.

Рис.5 Диаграмма декомпозиции в методологии DFD

2.5 Диаграммы декомпозиции в методологии IDEF3

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

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

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

Методология IDEF3 в работе была использована при декомпозиции работы "Операции по платежным поручениям" и "Автоматизация расчетов". Диаграмма декомпозиции "Операции по платежным поручениям" состоит из следующих работ:

Анализ запросов плательщиков по осуществлению расчетов;

Перечисления в специальные фонды;

Расчеты за товары и услуги;

Расчеты по кредитам;

Перечисление на счет получателей;

Обработка данных по перечисленной сумме;

Для отражения взаимоотношений работ используются связи типа Старшая (precedence) и типа Referent. Диаграмма содержит ссылку "Запросы плательщиков", перекрестки типа Аsynchronous OR и Synchronous OR. Перекрестки типа Аsynchronous OR под номерами J2 показывает, что все следующие процессы должны быть запущены, а перекресток типа Synchronous OR под номером J3 показывает, что один или несколько предшествующих процессов завершены одновременно.

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

В результате диаграмма декомпозиции в методологии IDEF3 примет вид изображенный на рис.8.

Рис.6 Диаграмма декомпозиции в методологии IDEF3 "Операции по платежным поручениям"

Диаграмма декомпозиции "Автоматизация расчетов" состоит из следующих работ:

ЭВМ-СЕРВЕР;

АИС;

СУБД банка;

Администратор БД;

База Данных;

ПК клиента;

Для отражения взаимоотношений работ используются связи типа Старшая (precedence) и типа Referent. Диаграмма содержит ссылку "Поток данных", перекресток типа Asynchronous AND под номером J4 показывает, что все предшествующие процессы должны быть завершены.

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

В результате диаграмма декомпозиции в методологии IDEF3 примет вид изображенный на рис.8.

Рис.7 Диаграмма декомпозиции в методологии IDEF3 "Автоматизация расчетов"

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

Для создания сценария необходимо из диаграммы декомпозиции А2.1

удалить работы, стрелки и перекрестки, не входящие в сценарий. На рисунке 6 показана диаграмма сценария под номером А2.2 созданная на основе диаграммы IDEF3 "Сценарий платежных поручений".

Рис.8 Сценарий диаграммы декомпозиции в методологии IDEF3 "Сценарий платежных поручений"

2.6 Функционально-стоимостной анализ (Activity Based Costing)

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

B BPwin модуль ABC применяется для:

понимания происхождения выходных затрат и определения их стоимости;

определение действительной стоимости производства продукта;

определения требуемых ресурсов;

определение действительной стоимости поддержки клиента;

оценки и анализа затрат на осуществление различных видов деятельности;

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

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

Применение модуля ABC и имеющихся в BPwin средств подготовки отчетов позволяет обеспечить корпоративную стратегию управления хозяйственной деятельностью.

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

Рис.9 Отчет по функционально-стоимостному анализу

2.7 Диаграммы FEO и диаграмма дерево узлов

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

Рис.10 Диаграмма FEO

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

На рисунке 10. показана диаграмма дерева узлов.

Рис.11 Диаграмма дерева узлов.

3. Информационная модель в нотации IDEF 1. X

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

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

ER-диаграммы были приняты в качестве основы для создания стандарта IDEF1X. Предварительный вариант этого стандарта был разработан в военно-воздушных силач США и предназначался для увеличения производительности при разработке компьютерных систем. В 1981г. этот стандарт был формализован и опубликован организацией ICAМ, и с тех пор является наиболее распространенным стандартом для создания моделей баз данных по всему миру.

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

Case-средство ERwin поддерживает методологию IDEF1X и стандарт IE. Методология IDEF1X подразделяется на уровни, соответствующие проектируемой модели данных систем. Каждый такой уровень соответствует определенной фазе проекта. Такой подход полезен при создании систем "сверху вниз". Три уровня модели, объединяющие в себе логические модели, состоят из диаграммы сущность-связь, модели данных, основанной на ключах и полной атрибутивной модели. Цель модели диаграмма сущность-связь - формирование общего взгляда на систему для ее дальнейшей детализации.

3.1 Логическая модель

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

Данные, относящиеся к связям, очень важны и часто являются критическими данными, которые мы используем в повседневном бизнесе. Например, важно знать о каком-то типе инструмента, но знание того, к кому относится конкретный инструмент (связь между человеком и инструментом) может иметь критическую важность. Связь - это соотношение либо между двумя сущностями, либо между сущностью и этой же сущностью. Связь - "логический" объект, представленный одним или несколькими атрибутами - внешними ключами. Связь в ERwin обычно содержит пять типов информации: тип связи, родительский конец связи, дочерний конец связи, ERwin toolbox содержит два типа сущностей: независимые и зависимые. Независимая СУЩНОСТЬ это сущность, экземпляры которой могут быть уникальным образом идентифицированы без определения ее связи с другой сущностью. Она представляется в ERwin в виде прямоугольника. Первичный ключ независимой сущности не включает в себя первичных ключей других сущностей. Зависимая СУЩНОСТЬ - это сущность, экземпляры которой не могут быть уникальным образом идентифицированы без определения ее связи с другой сущностью или сущностями. Она представляется на ЕR-диаграмме в виде прямоугольника с закругленными углами. Первичный ключ зависимой сущности включает первичные ключи одной или более родительских сущностей.

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

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