Разработка информационной системы для отдела грузоперевозок ОАО «Кричеврайагропромтехснаб»

Введение

Курсовой проект на тему «Отдел грузоперевозок ОАО „Кричеврайагропромтехснаб“» выполнен с целью автоматизации работы диспетчера отдела грузоперевозок. В настоящее время большинство предприятий и организаций в той или иной мере используют в своей деятельности различные информационные системы (ИС). ИС могут быть связаны с различными областями деятельности предприятия, будь то бухгалтерия, управление персоналом или конкретный производственный процесс. Компьютеры способны облегчить работу человеку в любой сфере деятельности, так как с помощью вычислительных машин есть возможность автоматизировать многие задачи, тем самым сэкономить время на повторяющихся действиях. Компьютеры могут производить труднейшие для человека вычисления за секунды, а также исключают ошибки вычислений. В любом случае ИС имеют дело с огромными массивами информации, которые необходимо хранить, обновлять, корректировать, а также производить различные вычисления.

1. Проектирование функциональной модели АСОИ

1.1 Определение требований к проектируемой АСОИ Проектирование многопользовательской информационной системы. Систему предполагается использовать на рабочем месте диспетчера для упрощения системы регистрации заказов и учета грузового склада.

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

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

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

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

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

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

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

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

Система должна удовлетворять следующим требованиям:

— Надежности;

— Безопасности;

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

— Данные должны храниться в соответствии с имеющимися документами.

— Система должна быть доступна только с компьютеров заведующего складами, заведующего автотранспортом, ответственного за доставки и заведующего отделом заказов.

— Информация, которая хранится в системе, должна быть защищена от аварийных ситуаций, влияния внешних воздействий (радиоэлектронная защита).

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

1.2 Диаграмма вариантов использования Диаграммы вариантов использования применяются в UML (Universal Modeling Language — универсальный язык моделирования) для моделирования динамических аспектов системы. Диаграммы прецедентов играют основную роль в моделировании поведения системы, подсистемы или класса. Каждая такая диаграмма показывает множество прецедентов, актеров и отношения между ними.

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

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

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

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

Связь коммуникации — это связь между вариантом использования и действующим лицом. Связи коммуникации показывают с помощью однонаправленной ассоциации (сплошной линии).

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

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

Рассмотрим варианты использования более подробно (таблица 1).

Таблица 1 — Основные варианты использования программы

1.3 Модель данных Рисунок 2 — Контекстная диаграмма Контекстная диаграмма разбивается на уровни. Первый уровень диаграммы представлен на рисунке 3, с помощью которой производится детализация основного процесса, находящегося на контекстной диаграмме. Контекстную диаграмму разбиваем на 3 блока в соответствии со спецификой осуществляемых действий.

Рисунок 3 — декомпозиция процесса AO «Организовать работу предприятия грузоперевозок»

Полученные блоки — «Организовать работу отдела по приему заказов», «Организовать работу бухгалтерии», «Организовать работу автопарка» — также подлежат дальнейшей детализации (рисунки 4, 5, 6).

Рисунок 4 — декомпозиция процесса А1 «Организовать работу отдела по приему заказов»

Рисунок 5 — декомпозиция процесса А2 «Организовать работу бухгалтерии»

Рисунок 6 — декомпозиция процесса А3 «Организовать работу автопарка»

Блок «Организовать работу консультанта» процесса А1 разбиваем на 2 блока — «Получить информацию о заказах, автотранспорте, водителях» и «Выдать информацию о сотрудниках» (рисунок 7).

Рисунок 7 — декомпозиция процесса А11 «Организовать работу диспетчера»

Блок «Организовать работу регистратора заказов» процесса А1 разбиваем на 6 блоков — «Получить информацию о заказе, грузе», «Выдать инфу о сотрудниках», «Выдать информацию об автомобилях», «Добавить водителя», «Добавить маршрут» и «Добавить новый заказ"(рисунок 8).

Рисунок 8 — декомпозиция процесса А12 «Организовать работу регистратора заказов»

Блок «Организовать работу бухгалтеров» А2 разбиваем на 3 блока — «Получить информацию о прибыли и расходах предприятия» ,"Произвести плдсчет прибыли" и «Подсчитать среднюю прибыль"(рисунок 9).

Рисунок 9 — декомпозиции процесса А21 «Организовать работу бухгалтеров»

Блок «Организовать работу экономистов» А2 разбиваем на 3 блока — «Получить информацию о расходах предприятия», «Выдать информацию о зарплате по типу валюты» и «Вычислить минимальные затраты» (рисунок 10).

Рисунок 10 — декомпозиция процесса А22 «Организовать работу экономистов Блок «Организовать работу начальника автопарка» процесса А3 разбиваем на 3 блока- «Получить информацию об автомобилях предприятия», «Добавить новый автомобиль» и «Выдать информацию о маршрутах"(рисунок 11).

Рисунок 11 — декомпозиция процесса А31 — «Организовать работу начальника автопарка»

Блок «Организовать работу водителя» процесса А3 разбиваем на 3 блока — «Провести техосмотр транспорта», «Выдать информацию о зарплате по типу валюты» и «Получить информацию о кузовных автомобилях"(рисунок 12).

Рисунок 12 — декомпозиция процесса А32 «Организовать работу водителя»

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

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

Диаграмма дерева узлов проектируемой базы данных представлена на рисунке 13.

Рисунок 13 — Диаграмма дерева узлов

2. Проектирование бизнес-логики

2.1 Диаграмма классов

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

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

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

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

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

Символ «+» — обозначает атрибут с областью видимости типа общедоступный (public). Атрибут с этой областью видимости доступен или виден из любого другого класса пакета, в котором определена диаграмма.

Символ «#» — обозначает атрибут с областью видимости типа защищенный (protected). Атрибут с этой областью видимости недоступен или невиден для всех классов, за исключением подклассов данного класса.

Символ «-» — обозначает атрибут с областью видимости типа закрытый (private). Атрибут с этой областью видимости недоступен или невиден для всех классов без исключения.

И, наконец, символ «~» — обозначает атрибут с областью видимости типа пакетный (package). Атрибут с этой областью видимости недоступен или невиден для всех классов за пределами пакета, в котором определен класс-владелец данного атрибута.

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

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

Базовыми отношениями на диаграммах классов, являются:

— отношение ассоциации (association relationship);

— отношение обобщения (generalization relationship);

— отношение агрегации (aggregation relationship);

— отношение композиции (composition relationship);

— отношение зависимости (dependency relationship).

Разрабатываемая программа включает в свой состав три основных части:

1) Пользовательские формы, содержащие функции, связанные с обработкой событий форм (классы пакета «Формы»);

2) Управляющие классы пользовательских форм, использующиеся на соответствующих формах (пакет «Процедуры»);

3) Выходные документы и отчеты (пакет «Отчеты»).

Диаграмма классов пакета «Формы», «Процедуры», «Отчеты» представлена в графической части на листе «Диаграмма классов». Между классами существует отношение ассоциации, так как классы существуют самостоятельно и не наследуют друг друга. Рассмотрим классы пакета «Процедуры» более подробно.

1) Класс DobProc

Таблица 2 — Методы класса DobProc

2) Класс UdProc

Таблица 3 — Методы класса UdProc

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

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

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

Диаграмма деятельности представлена в графической части на листе «Диаграмма деятельности».

информационный диспетчер грузоперевозка программный

3. Разработка программного обеспечения

3.1 Выбор среды программирования В качестве среды разработки программы была выбрана среда Microsoft Visual Studio 2010. Данная среда очень удобна для разработки приложений любых типов, так как содержит большое количество разнообразных визуальных элементов, что позволяет создать довольно удобный интерфейс за короткое время. Наличие огромного числа библиотек, созданных разработчиками данного набора, позволяет программистам довольно быстро решать прямые задачи построения АСОИ, не отвлекаясь на написание дополнительных классов и методов (например, сортировки массивов или вставка или удаление конкретных элементов).

В качестве языка программирования был выбран язык C#, являющийся одним из языков программирования среды разработки Microsoft Visual Studio 2010.

В качестве СУБД была выбрана Microsoft SQL Server 2010, так как она удобна в использовании и позволяет формировать весьма сложные запросы к базам данных.

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

3.2 Разработка таблиц базы данных АСОИ В реляционной базе данных информация организована в виде таблиц. Таблица описывает некоторый класс объектов, важных для разрабатываемой системы. Любая таблица состоит из столбцов и строк (атрибуты и кортежи, соответственно). Каждый столбец определяет атрибут класса объектов, представленных таблицей. А каждая строка описывает отдельный экземпляр объекта, представленного таблицей.

Таблицы являются отправной точкой для создания большинства приложений.

Разрабатываемая АСОИ содержит 5 таблиц. Структура таблиц представлены в графической части на листе «Схема данных».

3.3 Разработка форм Для организации ввода, изменения, добавления данных используется мощное и гибкое средство — формы. При проектировании форм основное внимание уделяется удобству ввода и анализа информации.

Форма «Form1» служит для входа пользователя в систему и начала работы с основными формами.

Форма «Form2» является основной для работы главного пользователя. Здесь пользователь выбирает форму для работы с определёнными данными.

Форма «работа_с_заказами» служит для работы пользователя с данными таблицы «Заказ».

Форма «работа_со_складом» служит для работы пользователя с данными таблицы «Груз».

Форма «доп» служит для просмотра пользователем данных следующих таблиц: «Водитель», «Путевой_лист», «Товарно_транспортная_накладная».

Заключение

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

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

1. Шрайберг Я. Л. Основные положения и принципы разработки автоматизированных библиотечно-информационных систем и сетей: главные тенденции окружения, основные положения и предпосылки, базовые принцмпы: Учебно-практическое пособие. — Изд. 2-е, испр. И доп. — М.: Либерея, 2001.

2. Алешин Л. И. Автоматизация в библиотеке. — Учебное пособие. Часть 1. — М.: Изд-во МГУКИ, ИПО Профиздат, 2001. — 176 с.

3. Алешин Л. И. Автоматизация в библиотеке. — Учебное пособие. Часть 2. — М.: Изд-во МГУКИ, ИПО Профиздат, 2001. — 144 с.

4. Вершинин М., Иванова Е. C# Enterprise Edition. Технологии проектирования и разработки. — М.: BHV, 2003 г. — 1088 с.

5. Леоненков А. В. Объектно-ориентированный анализ и проектирование с использованием UML и IBM Rational Rose: Учебное пособие / А. В. Леоненков. — М.: Интернет-Университет Информационных Технологий; БИНОМ. Лаборатория знаний, 2006. — 320 с.

6. Ларман К. Применение UМL и шаблонов проектирования.

Введение

в объектно-ориентированный анализ и проектирование. — М: Издательский дом «Вильямс», 2001. — 496 с.:ил.

7. SQL — запросы для простых смертных. Практическое руководство по манипулированию данными в SQL. Майкл Дж. Хернандес, Джон Л.Вьескас. — 473 с.: ил.

8. Проектирование и реализация баз данных Microsoft SQL Server 2000. Учебный курс MCAD/MCSE, MCDBA/Пер. с англ. — 2-е изд., испр. — М.: Издательско-торговый дом «Русская Редакция», 2003. — 512стр.: ил.

9. Тиори Т., Фрай Д. Проектирование структур баз данных. Т.1. — М.: Мир, 1985 — 287 с.: ил.

10. Дэйт К.Дж.

Введение

в системы баз данных. — СПб.: Питер, 1999. — 318 с.: ил.

11. Троелсен Э. С# и платформа .NET 3.0, специальное издание. — СПб.: Питер, 2008. — 1456 с.: ил.

12. Постолит А. Visual Studio .NET: разработка приложений баз данных. -М.: BHV, 2003 г. — 544 с.

13. Гук М. Интерфейсы ПК: справочник — СПб: ЗАО «Издательство «Питер», 1999. — 416 с.: ил.

14. Иртегов Д. В.

Введение

в операционные системы. — СПб.: БХВ-Петербург, 2002. — 624 с.: ил.