Система безналичных расчетов платежными поручениями (стр. 4 из 6)

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

ЭВМ-СЕРВЕР;

АИС;

СУБД банка;

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

База Данных;

ПК клиента;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Амортизация	Затраты, связанные с износом капитала, инвентаря, технических и программных средств
Налоги	НДС, НДФЛ, налог на прибыль и т.д.
Обслуживание клиентов	Затраты на обслуживание клиентов, связанные с выдачей наличных, размещением средств, прием запросов и т.д.
Персонал	Затраты на оплату сотрудников банка соот-х структурных подразделений

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рис.12 Логическая модель в 3НФ нотации IDEF1. X

3.2 Физическая модель

В ERwin также представлены два уровня физической модели: трансформационная модель и модель СУБД. Целью трансформационной модели является предоставление информации администратору. Модель СУБД транслируется из трансформационной модели. Являясь отображением системного каталога, ERD-диаграмма графически представляет структуру данных проектируемой ИС. Сущности отображаются при помощи прямоугольников, содержащих имя, взаимосвязи - при помощи линий, соединяющих отдельные сущности.