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

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

Министерство образования Республики Беларусь

БЕЛОРУССКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ

ИНФОРМАТИКИ И РАДИОЭЛЕКТРОНИКИ

Факультет информационных технологий и управления

Кафедра информационных технологий автоматизированных систем

Курсовой проект

На тему:

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

Дисциплина: Проектирование автоматизированных систем

Студент: гр.020602 Архипов А.И.

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

Хаджинова Н.В.

Минск 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.

Рассмотрим подробнее используемые нами программные средства:средство 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

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

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

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