Материал: Проектирование автоматизированной системы приема заказов

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

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

На рисунке 2.7 представлена детализация процесса "Поиска продукта", описывающая деятельность клиента.

"Клиенты" и ”Персонал ” - это внешние ссылки, источник данных из вне модели.

"База данных продуктов" и ”Интерфейс” - хранилища данных.

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

Рисунок 2.7 - Детализация процесса "Поиск продукта"

На рисунке 2.8 представлена Детализация процесса "Оформление заказа", описывающая деятельность по оформлению заказа.

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

Рисунок 2.8 - Детализация процесса "Оформление заказа".

2.4 Методология IDEF3

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

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

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

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

Диаграмма является основной единицей описания в IDEF3. Важно правильно построить диаграммы, поскольку они предназначены для чтения другими людьми (а не только автором).

Единицы работы - Unit of Work (UOW) - также называемые работами (activity), являются центральными компонентами модели. В IDEF3 работы изображаются прямоугольниками с прямыми углами и имеют имя, выраженное отглагольным существительным, обозначающим процесс действия, одиночным или в составе фразы, и номер (идентификатор); другое имя существительное в составе той же фразы обычно отображает основной выход (результат) работы (например, "Изготовление изделия"). Часто имя существительное в имени работы меняется в процессе моделирования, поскольку модель может уточняться и редактироваться. Идентификатор работы присваивается при создании и не меняется никогда. Даже если работа будет удалена, ее идентификатор не будет вновь использоваться для других работ. Обычно номер работы состоит из номера родительской работы и порядкового номера на текущей диаграмме.

На рисунке 2.9 иллюстрируется процесс "Получение продукта со склада".

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

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

Рисунок 2.9 - IDEF3 диаграмма "Получение продукта со склада"

На рисунке 2.10 иллюстрируется процесс "Предоставления продукта клиенту".

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

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

Рисунок 2.10 - IDEF3 диаграмма "Предоставление продукта клиенту"

Глава 3. Модели в нотации языка UML

3.1 Диаграмма вариантов использования в среде Rational Rose

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

-             определить общие границы и контекст моделируемой предметной области;

-             сформулировать общие требования к функциональному поведению проектируемой системы;

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

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

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

На рисунке 3.1 представлена диаграмма вариантов использования "Приема заявки на продукт".

Рисунок 3.1 - Диаграмма вариантов использования

3.2 Построение диаграммы в среде Enterprise Architect

Architect от Sparx Systems позиционируется как набор UML инструментов для бизнес и системного анализа, охватывающий все стадии разработки программного обеспечения: анализ, разработку, тестирование и поддержку. EA также может успешно служить в качестве практически полноценной системы управления требованиями, при условии, что основным инструментом описания требований является UML.

На рисунке 3.2 представлена диаграмма "Приема заявки на продукт".

Рисунок 3.2 - Диаграмма "Прием заявки на продукт"

Глава 4. Концептуальная модель базы данных

4.1 Методология IDEF1X

Одной из наиболее перспективных методологий информационного моделирования является методология IDEF1X (INTEGRATION DEFINITION FOR INFORMATION MODELING).

IDEF1X является методом для разработки реляционных баз данных и использует условный синтаксис, специально разработанный для удобного построения концептуальной схемы. Концептуальной схемой мы называем универсальное представление структуры данных в рамках коммерческого предприятия, независимое от конечной реализации базы данных и аппаратной платформы. Будучи статическим методом разработки, IDEF1X изначально не предназначен для динамического анализа по принципу "AS IS", тем не менее, он иногда применяется в этом качестве, как альтернатива методу IDEF1. Использование метода IDEF1X наиболее целесообразно для построения логической структуры базы данных после того, как все информационные ресурсы исследованы (скажем с помощью метода IDEF1) и решение о внедрении реляционной базы данных, как части корпоративной информационной системы, было принято. Однако не стоит забывать, что средства моделирования IDEF1X специально разработаны для построения реляционных информационных систем, и если существует необходимость проектирования другой системы, скажем объектно-ориентированной, то лучше избрать другие методы моделирования.

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

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

Основными элементами модели являются:

-       сущности;

-       домены;

-       связи;

-       первичные ключи;

-       вторичные ключи.

4.2 Построение модели

Основой для создания модели базы данных является DFD-диаграммы, на которых отображены хранилища данных. На рисунке 4.1 представлена база данных, построенная с помощью методологии IDEF1X.

Были созданы следующие сущности:

-       "График доставок" - хранится информация о доставках;

-       "Сотрудники" - хранится информация о персонале;

-       "Продукты" - хранится информация о предоставляемых продуктах;

-       "Заявки" - хранится информация о заявках (заказах);

-       "Статистика посещений" - хранится информация о посещении пользователями Интернет-ресурса.

Рисунок 4.1 - База данных

На рисунке 4.2 представлена схема базы данных, сгенерированной в Microsoft Office Access.

Рисунок 4.2 - Схема базы данных

Заключение

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

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

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

-       освобождению работников от рутинной работы за счет ее автоматизации;

-       снижения влияния человеческого фактора;

-       обеспечению достоверности информации;

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

-       уменьшению затрат на производство продуктов и услуг.

Список использованных источников

[1] Визуальное моделирование в среде IBM Rational Rose [Электронный ресурс]. - Режим доступа: <http://www.intuit.ru/studies/courses/14/14/info>.

[2] Уніфікована мова моделювання UML [Электронный ресурс]. - Режим доступа: http://www.znannya.org/? view=uml <http://www.znannya.org/?view=uml>.

[3] Моделирование бизнес-процессов средствами BPwin [Электронный ресурс]. - Режим доступа: http://old. intuit.ru/department/se/devis/7/ <http://old.intuit.ru/department/se/devis/7/>.

[4] IDEF1X - Методология Построения Реляционных Структур [Электронный ресурс]. - Режим доступа: <http://www.itstan.ru/funk-strukt-analiz/idef1x-metodologija-postroenija-reljacionnyh-struktur.html>

[5] Моделирование бизнес-процессов средствами BPwin часть-2 [Электронный ресурс]. - Режим доступа: http://old. intuit.ru/department/se/devis/8/ <http://old.intuit.ru/department/se/devis/8/>.