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

Министерство образования Республики Беларусь БЕЛОРУССКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ ИНФОРМАТИКИ И РАДИОЭЛЕКТРОНИКИ Факультет информационных технологий и управления Кафедра информационных технологий автоматизированных систем Курсовой проект На тему:

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

Дисциплина: Проектирование автоматизированных систем Студент: гр.20 602 Архипов А.И.

Руководитель: препод. кафедры ИТАС Хаджинова Н.В.

Минск 2014

• Введение
• Глава 1. Общесистемная часть
• 1.1 Анализ предметной области
• 1.2 Постановка задачи
• 1.3 Анализ возможностей методологии и инструментальных средств проектирования
• Глава 2. Разработка функциональных и логических схем. алгоритмы работы программы
• 2.1 Функциональная методология IDEF0
• 2.2 Создание модели в стандарте IDEF0
• 2.3 Методология DFD
• 2.4 Методология IDEF3
• Глава 3. Модели в нотации языка UML
• 3.1 Диаграмма вариантов использования в среде Rational Rose
• 3.2 Построение диаграммы в среде Enterprise Architect
• Глава 4. Концептуальная модель базы данных
• 4.1 Методология IDEF1X
• 4.2 Построение модели
• Заключение
• Список использованных источников

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

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

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

Работу с этими диаграммами поддерживает AllFusion ERwin Data Modeler.

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

алгоритм программа прием заказ

Глава 1. Общесистемная часть

1.1 Анализ предметной области

Курсовой проект по дисциплине «Проектирование автоматизированных систем» предусматривает проектирование и разработку систем обработки данных (СОД) для заданных объектов управления, автоматизированных систем (АИС) разного назначения.

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

Система приема заказов включает в себя следующие:

— прием заявок на продукты,

— обработка заявок,

— выполнение заявок.

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

1.2 Постановка задачи

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

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

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

В ходе данной курсовой работы были использованы такие программные средства, как: CASE средство ERwin, CASE средство BPwin.

Рассмотрим подробнее используемые нами программные средства:

CASE средство ERwin — средство разработки структуры базы данных (БД). ERwin сочетает графический интерфейс Windows, инструменты для построения ER-диаграмм, редакторы для создания логического и физического описания модели данных и прозрачную поддержку ведущих реляционных СУБД и настольных баз данных. С помощью ERwin можно создавать или проводить обратное проектирование (реинжиниринг) баз данных.

Семейство продуктов ERwin представляет собой набор средств концептуального моделирования данных, использующих метод IDEF1X. ERwin реализует проектирование схемы БД, генерацию ее описания на языке целевой СУБД (Oracle, Informix, Sybase, DB2, Microsoft SQL Server и др.) и реверсный инжиниринг существующей БД. Выпускается в нескольких конфигурациях, ориентированных на наиболее распространенные средства разработки приложений 4GL. Интегрируется с популярными средствами разработки клиентской части приложений PowerBuilder, Visual Basic, Delphi, что позволяет автоматически генерировать код приложений.

Методология DFD (DFD — Data Flow Diagrams) или диаграмм потоков данных это методология описания системы позволяющая отражать такие характеристики, как движение объектов (потоки данных), хранение объектов (хранилища данных), источники и потребители объектов (внешние сущности).

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

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

Глава 2. Разработка функциональных и логических схем. алгоритмы работы программы

2.1 Функциональная методология IDEF0

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

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

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

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

Общий вид блока диаграммы, построенной согласно методологии IDEF0 (IDEF0-диаграммы, или IDEF0 — модели).

Рисунок 2.1 — Блок диаграмма.

Смысл стрелок, используемый на IDEF0 — диаграмме, следующий:

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

Управление (Control) — правила, стратегии, процедуры или стандарты, которыми руководствуется работа. Каждая работа должна иметь хотя бы одну стрелку управления. Стрелка управления рисуется как входящая в верхнюю грань работы.

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

Выход (Output) — материал или информация, которые производятся работой. Каждая работа должна иметь хотя бы одну стрелку выхода. Работа без результата не имеет смысла и не должна моделироваться. Стрелка выхода рисуется как исходящая из правой грани работы.

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

2.2 Создание модели в стандарте IDEF0

Построение модели начинается с описания функционирования предприятия (системы) в целом в виде контекстной диаграммы. Контекстная диаграмма АС приема заказов представлена на рисунке 2.2:

Рисунок 2.2 — Контекстная диаграмма АС

Взаимодействие системы с окружающей средой описывается в терминах входа (на рисунке 2.2 это «Клиенты»), выхода (основной результат процесса — «Заявка выполнена», «Заявка отменена» и «Прибыль»), управления («Правила, нормы, стандарты») и механизмов («Склад», «Помещение», «Персонал», «Интернет-ресурс» — это ресурсы, необходимые для процесса функционирования системы заявок).

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

" Правила, нормы, стандарты" - это правила, которыми управляется процесс приема заявок, для которого разрабатывается АС.

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

Декомпозиция диаграммы представлена на рисунке 2.3.

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

Рисунок 2.3 — Диаграмма декомпозиции АС

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

Рисунок 2.4 — Диаграмма декомпозиции АС. Прием заявок.

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

Обработка заявки включает в себя получение продукта со склада, планирование графика доставки, согласование с клиентом и оформление всех документов.

Планирование графика доставки — это добавление доставки в курьерский план. Согласование с клиентом — это уточнение удобного для доставки времени и конечного утверждения в графике доставки.

Диаграмма представлена на рисунке 2.5.

Рисунок 2.5 — Диаграмма декомпозиции АС. Обработка заявки.

Выполнение заявки представлено на рисунке 2.6.

Предоставление продукта клиенту — курьер доставляет продукт клиенту в назначенное время. Далее клиент проверяет продукт на соответствие с заявленным. После чего производится оплата продукта клиентом. Выполненные заявки фиксируются.

Рисунок 2.6 — Диаграмма декомпозиции АС. Выполнение заявки.

2.3 Методология DFD

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Техника описания набора данных IDEF3 является частью структурного анализа. В отличие от некоторых методик описаний процессов 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

Enterprise 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.

[3] Моделирование бизнес-процессов средствами BPwin [Электронный ресурс]. — Режим доступа: 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/.