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

Размещено на http://www.allbest.ru/

ФЕДЕРАЛЬНОЕ АГЕНСТВО СВЯЗИ

ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ БЮДЖЕТНОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ОБРАЗОВАНИЯ «САНКТ-ПЕТЕРБУРГСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ ТЕЛЕКОММУНИКАЦИЙ ИМ. ПРОФ. М.А. БОНЧ-БРУЕВИЧА»

Факультет «Информационные системы и технологии»

Кафедра «Информационные управляющие системы»

Дисциплина «Инструментальные средства информационных систем»

Пояснительная записка

На тему: Разработка и проектирование информационной системы для реализации задач в транспортной компании

Санкт-Петербург 2023



Оглавление

Введение

1. Анализ предметной области. Постановка задачи

2. Моделирование бизнес - процессов в нотациях IDEFO, DFD, IDF3

3. Моделирование бизнес - процессов в нотации BPMN

4. Создание проекта в ERWin. Методология IDEF1X. Создание логической модели. Нормализация. Создание физической модели

5. Технология функционально-стоимостного анализа (ABC - Activity Based Costing). Определение центров затрат функциональных блоков модели. Расчет стоимости модели

Заключение

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



Введение

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

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



1. Анализ предметной области. Постановка задачи

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

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

Рассмотреть теоретические основы перегрузочного процесса транспортной компании;

Анализ перегрузочного процесса транспортной компании;

Разработка информационных систем для транспортных компаний.

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

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

Информационная система должна обеспечивать:

Ведение базы данных (запись, чтение, изменение, удаление);

Хранить информацию о заказах;

Хранить информацию о перевозчике;

Хранить информацию о клиентах.

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

Графы таксономии обеспечивают механизм логической организации знаний, полученных в результате системного обучения. Существуют два типа таких диаграмм: диаграммы строгой классификации (Description Subsumment - DS) и диаграммы естественной или видовой классификации (Natural Kind Classification - NKC). Основное отличие диаграмм ДС состоит в том, что классоопределяющие свойства высшего уровня и всех последующих уровней являются достаточными и необходимыми признаками принадлежности объектов к тому или иному классу [2].

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

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

Рисунок 1 - Классификация участников грузовых перевозок

Перевозчик принимает непосредственное участие в выполнении заказа.

Карта классификации сотрудников показана на рис. 2.



Рисунок 2 - Диаграмма классификации сотрудников

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

Composition Schematics -- это механизм графического представления состава классов онтологий, фактически инструмент исследования онтологий, основанный на принципе «что из чего состоит». В частности, композиционные схемы могут наглядно отображать сочетания объектов, принадлежащих к определенным категориям [3].

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

Составная схема перевозки груза представлена на рис. 3.



Рисунок 3 - Схема состава для перевозки груза

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

Схема состава транспортной компании представлена на рис. 4.

Рисунок 4 - Схема состава транспортной компании

Эти композиционные схемы могут представить состав основных объектов транспортной компании в графическом виде для удобства понимания. Object State Schemantic позволяет записывать конкретные процессы с точки зрения изменения состояний объектов.

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

Рисунок 5 - Диаграмма статуса заказа (касса)

После того, как заказ размещен, он выполняется. Перевозчик идет к месту погрузки товара на транспортное средство и к месту погрузки товара. После погрузки перевозчик доставляет товар к месту разгрузки. В месте разгрузки груз выгружается из транспортного средства. После этого заказ считается выполненным.

Диаграмма состояния заказа показана на рис. 6.



Рисунок 6 - Диаграмма состояния ордера (исполнение)

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

Диаграмма состояния груза показана на рис. 7.

Рисунок 7 - Диаграмма состояния груза (погрузка)

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

Диаграмма состояния груза показана на рис. 8.

Рисунок 8 - Схема состояния груза (транспортировка)

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

Карта состояния груза показана на рис. 9.

Рисунок 9 - Диаграмма состояния груза (выгружен)

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

Обзор методов проектирования и разработки ИС

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

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

В объектно-ориентированном подходе программа представляет собой описание объектов, их свойств (или атрибутов), коллекций (или классов), отношений между ними, способов их взаимодействия и операций над объектами (или методами) [5].

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

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

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

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

Инструменты проектирования интегральных схем

В качестве средств проектирования ИС транспортного предприятия:

Анализ бизнес-процессов организации - BPWin;

Создать модель данных - ERWin;

Проверить качество модели данных - ERWin Examiner;

Создание организационной модели, модели процессов/управления, диаграммы UML -- Argo UML;

Для реализации базы данных -- MySQL;

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

Целостность и непротиворечивость модели чертежа гарантируется рядом методов и обозначений. BPwin поддерживает три таких метода: IDEF0, IDEF3 и DFD [8].

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

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

ERwin Examiner предназначен для быстрого выявления проблем обработки данных, которые подрывают целостность и производительность корпоративных систем электронной коммерции. Выявляя такие малозаметные, но потенциально серьезные проблемы, ERwin Examiner ускоряет разработку и внедрение баз данных, повышает качество и помогает разработчикам баз данных и администраторам принимать более обоснованные решения во время разработки [9].

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

2. Моделирование бизнес - процессов в нотациях IDEFO, DFD, IDF3

Бизнес-процесс состоит из взаимосвязанных действий в информационной системе компании для достижения одной (или нескольких) бизнес-целей компании.

Контекстная диаграмма деятельности транспортной компании показывает основные бизнес-функции в действии:

Заказы (логин);

Товары (входные);

Прибыль (выпуск);

Право Российской Федерации (администрация);

Регламенты и ГОСТ (администрация);

Учетная система (механизм);

Работники (механизмы);

Торговое обеспечение (механизмы).

Схема бизнес-процесса в нотации IDEF0 показана на рис. 10.

Рисунок 10. Контекстная диаграмма активности

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

Диаграмма декомпозиции деятельности транспортной компании представлена на рис. 11.



Рисунок 11. Транспортная компания в разобранном виде

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

Покомпонентное представление выполнения заказа показано на рис. 12.

Рисунок 12 - Развернутая диаграмма выполнения заказа

Анализ бизнес-процессов помогает в понимании операций транспортной организации, а также в проектировании и разработке информационных систем.

3. Моделирование бизнес - процессов в нотации BPMN

BPMN (нотация моделирования бизнес-процессов, нотация и модель бизнес-процессов) -- это нотация для моделирования бизнес-процессов.

Смоделируем процесс добавление нового заказа по грузоперевозке в нотации BPMN. В этом процессе участвуют 2 участника «Покупатель» и «Поставщик». Диаграмма BPNM показан на рис. 13.

Рисунок 13. Диаграмма BPNM

4. Создание проекта в ERWin. Методология IDEF1X. Создание логической модели. Нормализация. Создание физической модели

Для разработки модели базы данных использовался инструмент ERwin Case и его метод IDEF1X.

В ERwin есть два уровня представления и моделирования: логический и физический.

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

Создание модели данных обычно начинается с создания логической модели. После описания логической модели проектировщик может выбрать необходимую СУБД, и ERwin автоматически создаст соответствующую физическую модель. На основе физической модели ERwin может генерировать системные каталоги СУБД или соответствующие сценарии SQL [10].

В кейс-инструменте ERwin разработана логическая модель базы данных для хранения информации о транспортной компании с учетом всех нюансов и деталей предметной области. Модель состоит из трех таблиц, связанных между собой логическими связями. Логическая модель показана на рис. 14.

Рисунок 14 - Диаграмма сущностей и свойств логического уровня модели

Физическая модель данных зависит от конкретной СУБД и фактически является отображением системного каталога. Физическая модель содержит информацию обо всех объектах базы данных. Поскольку нет стандарта для объектов базы данных (например, нет стандарта для типов данных), физическая модель зависит от конкретной реализации СУБД. Поэтому одной и той же логической модели может соответствовать несколько разных физических моделей [11]. Физическая модель показана на рис. 14.

Рисунок 15. Диаграмма символов физического уровня IDEF1X

Данная физическая модель была разработана для реляционной СУБД MS SQL Server.

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

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

Стрелки в модели процесса (BPwin) представляют часть информации, используемой в системе моделирования. В ERwin на логическом уровне модели данных информация представляется в виде сущностей (соответствующих таблицам на физическом уровне) и составляются атрибуты сущностей (соответствующие столбцам таблицы) [12].

Соответствие между стрелками и сущностями показано в таблице 2.

Таблица 2 - Соответствие между стрелками и объектами

имя стрелки	Сущность
сотрудник	оператор
приложение	клиенты, приложения
выгода	Оплата

Процесс связывания показан на рисунках 16 и 17.

Рисунок 16 - Arrow Data



Рисунок 17 - Редактор использования данных

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

BPwin позволяет связывать элементы модели данных, созданной с помощью ERwin, документируя влияние работы на данные, позволяя создавать спецификации доступа к данным для каждого процесса. Джобс не может использовать данные без разбора. Данные можно прочитать (Read), обновить (Update), удалить (Delete), создать (Create). Пример настройки прав доступа к данным для процесса заполнения информации показан на рисунке 17.

Нормализация базы данных

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

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

Исключить некоторые виды избыточности

Исправить некоторые исключения обновления;

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

Упростить процедуру применения необходимых ограничений целостности.

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

Реляционная переменная находится в первой нормальной форме (1NF), если каждый атрибут кортежа содержит ровно одно значение.

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

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

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

При проверке ErwinExaminer обнаружил 6 ошибок модели, 4 из которых относились к категории ошибок проектирования индексов и ограничений, а 2 относились к отсутствию альтернативных ключей (неопределенный альтернативный ключ).

После устранения ошибки выполните повторную проверку (рис. 18).

Рисунок 18 - Дерево ошибок

Ошибка в списке Undefined Alternate Key указывает на то, что таблица имеет суррогатный первичный ключ без альтернативного ключа. Чтобы исправить ошибку, в каждую таблицу были добавлены альтернативные ключи.

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

Для устранения ошибок к каждой таблице добавляются кластерные индексы.

Общая структура базы данных заказчиков представлена на рис. 19.

Рисунок 19 - структура БД (Customers)



5. Технология функционально-стоимостного анализа (ABC - Activity Based Costing). Определение центров затрат функциональных блоков модели. Расчет стоимости модели

Определим центры затрат для каждого функционального блока модели, созданной в Задаче 2.

1. Стоимость блока «Получение заказа»

Описание выполненных работ;

Формирование и выпуск различных сводок и отчетов.

2. Стоимость блока «Поиск исполнителя заказа»

Формирование и печать путевых листов;

Учет автотранспорта собственного парка, документы по учету;

Сервисные записи и выполненные работы по техническому обслуживанию;

План технического обслуживания;

3. Стоимость блока «Выполнения заказа»

Ответственный за работу водителя;

Учет эксплуатации шин и аккумуляторов;

Учет и работа с контрагентами;

Нормы учета и калькулирования горюче-смазочных материалов;

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

Выполним запросы к базе данных:

Первый запрос возвращает все записи из таблицы «Customers»:

SELECT * FROM `customers`

Результат выполнения запроса (Рисунок 20):



Рисунок 20 - Результат выполнения запроса №1

Второй запрос возвращает столбец «phone» всех записей таблицы «Customer»

SELECT `phone` FROM `customers`;

Результат выполнения запроса (Рисунок 27):

Рисунок 21 - Результат выполнения запроса №2

Третий запрос добавляет заказчика в базу данных

INSERT INTO `customers` (`id`, `name_customer`, `phone`, `inn`, `adress`, `count`) VALUES ('1', 'ООО \"Тарелки\"', '+1234567890', '1122334455', 'г. Москва, ул. Северная 1', '4');

Результат выполнения запроса (Рисунок 22):

Рисунок 22 - Результат выполнения запроса №3

Четвертый запрос сортирует информацию о пользователях, которые имеют записи о номере телефона.

SELECT * FROM `customers` ORDER BY `customers`.`adress` ASC

Результат выполнения запроса (Рисунок 23):



Рисунок 23 - Результат выполнения запроса №4

Пятый запрос изменяет значение номера телефона.

UPDATE `customers` SET `phone` = '123456789' WHERE `customers`.`id` = 1 AND `customers`.`name_customer` = 'ООО \"Тарелки\"' AND `customers`.`phone` = 1234567890 AND `customers`.`inn` = 1122334455 AND `customers`.`adress` = 'г. Москва, ул. Северная 1' AND `customers`.`count` = 4 LIMIT 1;

Результат выполнения запроса (Рисунок 24):

Рисунок 24 - Результат выполнения запроса №5

Шестой запрос удаляет заказчика из таблицы данных

DELETE FROM customers WHERE `customers`.`id` = 2 AND `customers`.`name_customer` = 'ООО \"Серко\"' AND `customers`.`phone` = 222444333 AND `customers`.`inn` = 523697 AND `customers`.`adress` = 'г. Питер, ул. Красная 2' AND `customers`.`count` = 12 LIMIT 1

Результат выполнения запроса (Рисунок 25):

Рисунок 25 - Результат выполнения запроса №6

Седьмой запрос возвращает заказчика, который имеет кол-во перевозок равной 12

SELECT * FROM `customers` WHERE `customers`.`count`=12;

Результат выполнения запроса (Рисунок 26):

Рисунок 26 - Результат выполнения запроса №7

Восьмой запрос возвращает имя и телефон заказчика, ИНН которых >10000.

SELECT `name_customer`,`phone` FROM `customers` WHERE `customers`.`inn`>10000;

Результат выполнения запроса (Рисунок 27):

Рисунок 27 - Результат выполнения запроса №8

Девятый запрос возвращает информацию имя и адрес заказчика, у которого ИНН <10 или кол-во заказов >10.

SELECT `name_customer`,`adress` FROM `customers` WHERE `customers`.`inn`<10 OR `customers`.`count`>10;

Результат выполнения запроса (Рисунок 28):

Рисунок 28 - Результат выполнения запроса №9

Десятый запрос возвращает информацию заказчике, который имеет перевозок меньше 6.

SELECT * FROM `customers` WHERE `customers`.`count`<6;

Результат выполнения запроса (Рисунок 29):

Рисунок 29 - Результат выполнения запроса №10



Заключение

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

По проанализированным данным построена модель данных на базе СУБД MySQL с использованием программных продуктов семейства ERWin и проведено тестирование качества модели.

Программное обеспечение Argo UML используется для построения организационных моделей, моделей процессов/управления и диаграмм UML.

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

Снижение случайных ошибок, связанных с ручным заполнением документов;

Автоматическая обработка информации в системе;

Накапливать, хранить, обрабатывать и анализировать данные.

По результатам функционального тестирования информационная система работает нормально.



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

1. Моделирование бизнес-процессов: лабораторный практикум /. М. Ю. Арзуманян., М. А. Деревянко ; СПбГУТ. - СПб., 2014. - 48 с

2. Федотова Д.Э., СеменовЮ.Д., Чижик К.Н. CASE-технологии: Практикум. - М.: Горячая линия-Телеком,2005.-160 с

3. Горбаченко, В.И Проектирование информационных систем с CAERwin Modeling Suite 7.3 / В.И. Горбаченко, Г.Ф. Убиенных, Г.В. Бобрышева - Пенза: Изд-во ПГУ, 2012. - 154 с.

4. Аксенов, с. Аксенов, К. А. Работа с CASE-средствами BPwin, ERwin. / К. А. Б. И. Клебанов; Уральский гос. техн. ун-т. - Екатеринбург, 2004.

5. Маклаков, С.В. BPwin и ERwin: СASE-средства для разработки информационных систем / С.В. Маклаков. - М.: Диалог-МИФИ, 2009. - 238 с.

6. Прошкина, Е.Н. Методы и средства проектирования информационных систем и технологий. Методические указания к выполнению лабораторных работ / Е.Н. Прошкина; Изд-во ПГУ. - Пенза, 2014. - 93 с.

7. Дейт, К. Дж. Введение в системы баз данных/ К. Дж. Дейт; 8-е издание.: Пер. с англ. - М.: Издательский дом «Вильямс», 2005 - 1328 с.

8. Фиайли, К. SQL: VISUAL QUICKSTART GUIDE / К. Фиайли Пер. с англ. - М.: ДМК Пресс. 2013. - 452 с.

Размещено на Allbest.ru

...