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

Содержание:

Введение

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

Цель курсовой работы – моделирование предметной области «Транспортная доставка заказов» с помощью UML

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

1. Описать предметную область «Транспортная доставка заказов»

2. Выбрать средства для моделирования предметной области

3. Провести моделирование предметной области «Транспортная доставка заказов» с помощью объектно-ориентированного подхода к проектированию

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

1. Аналитическая часть

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

Согласно статистическим данным перевозка более половины всех грузов на территории РФ осуществляется автомобильным транспортом. Поэтому в курсовой работе при описании предметной области «Транспортная доставка заказов» будем опираться на документационный оборот, используемый в автомобильных перевозках.

Правовое регулирование грузового автотранспортного сообщения в России регулируются постановлением Правительство РФ № 272 от 15 апреля 2011 года, которое утвердило новые Правила перевозок грузов автомобильным транспортом. Данное постановление регулирует отношения между перевозчиками, грузоотправителями, грузополучателями и другими участниками процесса транспортировки.

Основными документами этого процесса являются:

1. Перевозка груза осуществляется на основании договора перевозки груза. Заключение договора перевозки груза подтверждается транспортной накладной.

Транспортная накладная (Рисунок 1) – первичный документ, который предназначен для учета движения товарно-материальных ценностей и сопровождает груз при его перевозке от грузоотправителя к грузополучателю.

Товарно-транспортная накладная (далее – ТТН) оформляется в двух случаях:

• при перевозке товарно-материальных ценностей силами автотранспортной компании;
• при перевозке товарно-материальных ценностей самим грузоотправителем.

Рисунок – Образец транспортной накладной

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

Использования ТТН в электронном виде не представляется возможным. В соответствии с Приказом ФНС РФ от 29.06.2012 года №ММВ-7-6/465@ транспортные накладные могут быть направлены в налоговый орган только в виде сканированных копий.

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

Рисунок – Образец договора фрахтования

В договор фрахтования должны включаться следующие пункты:

• Предмет сделки.
• Пункты выбытия и прибытия.
• Количество мест (объем вместимости) для груза, пассажиров, багажа.
• Условия оплаты.
• Вид (род) груза.
• Кроме этого, обязательно указываются наименования (ФИО) субъектов, оформляющих соглашение, отправителя и получателя груза.

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

Рисунок – Образец акта о повреждении груза

В соответствии с Правилами акты составляются в случаях, если (п. 79 Правил):

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

Акт, должен содержать (п. 82 Правил) следующие пункты:

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

Анализирую постановление Правительства РФ № 272, и документы которыми регулируется «Правил перевозок грузов автомобильным транспортом», можно выделить участников процесса «Транспортная доставка заказов»

В «Транспортной доставке заказов» участвуют четыре стороны (Рисунок 4):

• грузоотправитель,
• логист,
• грузоперевозчик
• грузополучатель.

Рисунок – Участники процесса «Транспортная доставка грузов»

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

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

1.2 Предлагаемые мероприятия по улучшению технологии решения задачи

Процесс доставки грузов можно разделить на три этапа (Рисунок 5):

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

2. Второй этап – перевозка груз – это этап транспортировки груза в место, указанное в заявке.

3. Третий этап – разгрузка груза. После доставки груза транспортное средство разгружают.

После выполнения трех этапов «Транспортная доставка заказов» является завершенной.

Рисунок – Общая схема «Транспортной доставки заказов»

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

• сотрудники
• материально-техническое обеспечение (Рисунок 6).

Рисунок – Общая схема работы транспортной компании

Процесс, который будет автоматизироваться это первый этап Транспортной доставки грузов, а именно прием груза (Рисунок 7). Прием заказа на транспортную доставку является одной из обязанностей логиста.

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

В любой из этих документов понадобиться внести следующие данные:

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

Рисунок – Процесс оформления заказа на транспортную доставку заказов

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

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

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

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

2 глава. Проектная часть

2.1. Выбор средства для моделирования предметной области решаемой задачи

Под моделью предметной области понимают — систему, имитирующая структуру или функционирование исследуемой предметной области и отвечающая основному требованию – быть адекватной этой области.

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

При создании моделей предметной области необходимо учитывать следующие требования:

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

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

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

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

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

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

3. С точки зрения релевантности содержания модели делятся на ():

• Модель «Как есть» («AS IS»): отражает реальное состояние дел во время описания, фактически существующих бизнес процессов предприятия.
• Модель «Как должно быть» («TO BE»): отражает целевое состояние, которое в будущем предполагается реализовать. Например, модель вновь открытого предприятия или новый (совершенно новый или улучшенный старый) порядок выполнения любой работы.
• Модель «Как должно бы быть» (английский «SHOULD BE»): отражает «идеализированное» положение дел (например, согласно нормативным документам, тогда как фактическая схема работы в действительности может быть несколько иной). На практике необходимость создания таких моделей встречается редко.

Рисунок – Взаимосвязь моделей при реинжиниринге бизнес-процессов

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

UML () — это объектно-ориентированный язык со следующими характеристиками:

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

• содержит механизм для расширения и специализации базовой концепции языка.

Рисунок – Логотип языка UML

Основными понятиями языка UML являются:

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

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

3. Модель — объект, отображающий наиболее значимые для конкретной задачи характеристики системы. Модели бывают разные – нематериальные и материальные, естественные и искусственные, математические и декоративные.

4. Диаграмма — графическое представление множества элементов. Чаще всего изображается в виде графа с вершинами (сущностями) и ребрами (отношениями). Примеров диаграмм : блок-схема, и схемы монтажа оборудования, и дерево файлов и каталогов на диске и т.д. Рисунок воспринимается легче, чем текст…

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

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

1. Rational Rose
2. Microsoft Visio
3. Sybase PowerDesigner
4. Case Complete
5. Artiso Visual Case

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

1 Rational Rose

Rational Rose () — CASE-средство фирмы Rational Software Corporation (США) — предназначено для автоматизации этапов анализа и проектирования ПО, а также для генерации кодов на различных языках и выпуска проектной документации [3]. Rational Rose использует синтез-методологию объектно-ориентированного анализа и проектирования.

Рисунок — Логотип Rational Rose

Основной вариант — Rational Rose/C++ — позволяет разрабатывать проектную документацию в виде диаграмм и спецификаций, а также генерировать программные коды на С++.

В основе работы Rational Rose лежит построение различного рода диаграмм и спецификаций, определяющих логическую и физическую структуры модели, ее статические и динамические аспекты. В их число входят диаграммы классов, состояний, сценариев, модулей, процессов [4].

Принципиальное отличие Rational Rose от других средств заключается в объектно-ориентированном подходе. Графические модели, создаваемые с помощью этого средства, основаны на объектно-ориентированных принципах и языке UML (Unified Modeling Language). Инструменты моделирования Rational Rose позволяют разработчикам создавать целостную архитектуру процессов предприятия, сохраняя все взаимосвязи и управляющие воздействия между различными уровнями иерархии.

2 Microsoft Visio

Microsoft Visio — векторный графический редактор, редактор диаграмм и блок-схем для Windows. Выпускается в трёх редакциях: Standard, Professional и Pro for Office 365 ([12].

Рисунок — Логотип Microsoft Visio

Visio предоставляет множество различных объектов, с которыми можно взаимодействовать. Они организованы в виде иерархии, которая точно соответствует пользовательскому интерфейсу. [17]

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

После ознакомления с программными продуктами для разработки автоматизированных информационных систем и для определения среды разработки для практической части курсовой работы были выделены около 30 критериев. Критерии сгруппированы следующим образом (Таблица 1)

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

— Экспорт – должны быть доступны разные форматы экспорта. Шаблоны документов должны легко модифицироваться..

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

— Минимизация рутины — инструмент делает некоторые вещи сам – например, генерируем тест-кейсы, объектный дизайн из БД, куски кода.

Таблица 1 Сравнение CASE-средств

Программный продукт/ Критерии	Проектирование системы	Экспорт	Удобство пользования	Минимизация рутины
Rational Rose	+	—	+	—
Microsoft Visio	+	+	+	—

Исходя из таблицы и субъективное сравнение программных продуктов не выявило абсолютного лидера. Но в силу использования Microsoft Visio в других разработках, автором отдается предпочтение именно этому программному продукту.

2.2 Моделирование предметной области решаемой задачи с использованием объектно-ориентированного подхода к проектированию

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

Диаграммы вариантов использования (Рисунок 14) позволяют наглядно представить ожидаемое поведение системы. Основными понятиями диаграммы вариантов использования являются: действующее лицо, вариант использования и связь.

Действующее лицо (актер) – внешняя по отношению к разрабатываемой системе сущность, которая взаимодействует с ней в целях получения или предоставления какой-либо информации [4]. Действующими лицами могут быть пользователи, ПО или какие-либо технические средства, взаимодействующие с системой.

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

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

Связь – взаимодействие действующих лиц и соответствующих вариантов использования [3].

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

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

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

Варианты использования	Оформление документов, Оформление заявки, оплата перевозки, Проверка возможности оплаты груза.
Основные актеры	Логист, Грузоотправитель
Краткое описание	Грузоотправитель приходит в транспортную компанию отправить груз. Логист оформляет груз. Формируются ТТН и чек
Цель	Более качественное и быстрое обслуживание грузоотправителей. Формирование базы данных грузоотправителей.

Диаграмма последовательности (англ. sequence diagram) — диаграмма, на которой для некоторого набора объектов на единой временной оси показан жизненный цикл какого-либо определённого объекта (создание-деятельность-уничтожение некой сущности) и взаимодействие акторов (действующих лиц) ИС в рамках какого-либо определённого прецедента (отправка запросов и получение ответов). Используется в языке UML. [6]

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

Рисунок – Диаграмма последовательности

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

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

Используются следующие условные обозначения:

• Круг, обозначающий начальное состояние.
• Окружность с маленьким кругом внутри, обозначающая конечное состояние (если есть).
• Скруглённый прямоугольник, обозначающий состояние. Верхушка прямоугольника содержит название состояния. В середине может быть горизонтальная линия, под которой записываются активности, происходящие в данном состоянии.
• Стрелка, обозначающая переход. Название события (если есть), вызывающего переход, отмечается рядом со стрелкой. Охраняющее выражение может быть добавлено перед «/» и заключено в квадратные скобки (название_события[охраняющее_выражение]), что значит, что это выражение должно быть истинным, чтобы переход имел место. Если при переходе производится какое-то действие, то оно добавляется после «/» (название_события[охраняющее_выражение]/действие).
• Толстая горизонтальная линия с либо множеством входящих линий и одной выходящей, либо одной входящей линией и множеством выходящих. Это обозначает объединение и разветвление соответственно.

Рисунок – Диаграмма состояний

Далее разрабатываем диаграмму классу (Рисунок 17). Диаграмма классов (англ. Static Structure diagram) — диаграмма, демонстрирующая классы информационной ссистемы и взаимосвязи между ними. [9]

Существует два вида:

• Статический вид диаграммы рассматривает логические взаимосвязи классов между собой;
• Аналитический вид диаграммы рассматривает общий вид и взаимосвязи классов, входящих в систему.

Существуют разные точки зрения на построение диаграмм классов в зависимости от целей их применения: [10]

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

Рисунок – Диаграмма классов

• Точка зрения спецификации — диаграмма классов применяется при проектировании информационных систем;
• Точка зрения реализации — диаграмма классов содержит классы, используемые непосредственно в программном коде (при использовании объектно-ориентированных языков программирования).

Диаграммы деятельности удобно применять для визуализации алгоритмов, по которым работают операции классов. [8]

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

Рисунок – Диаграмма деятельности

Диаграммы деятельности состоят из ограниченного количества фигур, соединённых стрелками. Основные фигуры: [11]

• Прямоугольники с закруглениями — действия
• Ромбы — решения
• Широкие полосы — начало (разветвление) и окончание (схождение) ветвления действий
• Чёрный круг — начало процесса (начальное состояние)
• Чёрный круг с обводкой — окончание процесса (конечное состояние)
• Стрелки идут от начала к концу процесса и показывают последовательность переходов.

Заключение

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

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

Основные бизнес-процессы, рассмотренные в курсовой работе, транспортная доставка заказов:

• Оформление документов (ТТН),
• Оформление заявки
• оплата перевозки (формирование чека),
• Проверка возможности оплаты груза.

На UML в среде MS Visio были разработаны следующие схемы:

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

Следующим этапом после проведения логического проектирования системы является физическое проектирование.

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

Список литературы

1. Буч, Г. Объектно-ориентированный анализ и проектирование с примерами приложений на С++ / Г. Буч. – М.: Бином, 2016. – 560 с.
2. Буч, Г. Язык UML. Руководство пользователя / Г. Буч, Дж. Рамбо, А. Якобсон. — СПб.: Питер, 2014. — 432 с.
3. Вендров, А.М. CASE-технологии. Современные методы и средства проектирования информационных систем / А.М. Вендров. – М. : Финансы и статистика, 1998. – 176 с.
4. Википедия. [Электронный ресурс] ru.wikipedia.org. Режим свободного доступа. Дата обращения 13.11.2020
5. ГОСТ Р ИСО/МЭК 12207–02. Информационная технология. Процессы жизненного цикла программных средств.
6. Йордан, Э. Объектно-ориентированный анализ и проектирование систем / Э. Йордан, С. Аргила. — М.: Издательство «ЛОРИ», 2017. — 264 с.
7. Ларман, К. Применение UML и шаблонов проектирования: Уч. Пос / К. Ларман. — М.: Издательский дом «Вильямс», 2015. — 496 с.
8. Леоненков, А.В. Объектно-ориентированный анализ и проектирование с использованием UML / А.В. Леоненков. – www.intuit.ru.
9. Маклаков, С.В. Создание информационных систем с AllFusion Modeling Suite / С.В. Маклаков. – М. : ДИАЛОГ-МИФИ, 2016. – 432 с.
10. Петров, В.И. Информационные системы / В.Н. Петров. – СПб. : Питер, 2002. – 688 с.
11. Фаулер, М. UML. Основы. Третье издание. / М. Фаулер. – М.: Символ-Плюс, 2016. – 192 с.
12. Элиенс, А. Принципы объектно-ориентированной разработки программ / А. Элиенс. – М.: Издательский дом «Вильямс», 2012. – 496 с.
13. Якобсон, А. Унифицированный процесс разработки программного обеспечения / А. Якобсон, Г. Буч, Дж. Рамбо. — СПб.: Питер, 2012. — 496 с.

Министерство транспорта Российской Федерации

Федеральное агентство железнодорожного транспорта

ФГБОУ ВО «ДАЛЬНЕВОСТОЧНЫЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ ПУТЕЙ СООБЩЕНИЯ»

Кафедра «Информационные технологии и системы»

К ЗАЩИТЕ ДОПУСТИТЬ

Заведующий кафедрой

___________ М. А. Попов

«____» ___________ 2017 г.

РАЗРАБОТКА WEB-ПРИЛОЖЕНИЯ ДЛЯ ТРАНСПОРТНО-ЛОГИСТИЧЕСКОЙ КОМПАНИИ

Пояснительная записка к выпускной квалификационной работе бакалавра

ВКР 09.03.02.240 ПЗ

Студент гр. 240	А. В. Мамонтов
Руководитель (к.т.н., доцент)	Р. А. Ешенко
Нормоконтроль (доцент, к.п.н., доцент)	В. И. Шестухина

Хабаровск – 2017

Abstract

In the framework of this master’s thesis, is an Internet application developed for transport and logistics companies. In order to develop this application, scope, object, types of operations, as well as the services of this company were studied. Based on these data, functional, informational and behavioral models of information system are designed and manufactured, and the interface for Internet applications. In addition, the program was chosen for the development of Internet applications and create a working prototype.

Содержание

Введение 3

1 Описание предметной области 5

2 Цели и задачи 6

3 Проектирование системы 8

3.1 Модель вариантов использования 8

3.2 Диаграммы вариантов использования 8

3.3 Диаграммы автоматов 13

3.4 Модель анализа 17

3.5 Диаграмма классов анализа 18

3.6 Диаграммы последовательности 19

3.7 Диаграммы коммуникаций 21

3.8 Модель проектирования 22

3.9 Диаграмма деятельности 23

3.10 Модель реализации 26

4 Практическая часть 31

4.1 Выбор программного обеспечения 31

4.2 Разработка интерфейса проекта 38

4.3 Руководство пользователя 40

4.4 Руководство администратора 46

Заключение 50

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

Введение

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

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

Поэтому, логично сделать вывод, что с точки зрения рекламы, продажи, покупки продукции или услуг различного рода, Internet – наиболее значимый ресурс. Множество людей, по всему миру пользуются Интернетом, как для получения информации, так и для развлечений.

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

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

Для создания Web – приложений нужно учитывать несколько задач, следуя которым можно упросить его разработку:

• ознакомиться с современными Интернет-технологиями и, по возможности, использовать их в своей разработке;

• изучить программный инструментарий, применяемый для разработки и создания Web — приложений;

• выявить и учесть методы и способы представления на Web — страницах различных видов информации, не препятствующие их доступности;

• ознакомиться с основными правилами и рекомендациями по разработке и созданию Web — приложений и неукоснительно следовать им в своей практике;

• определиться со структурой Web — страниц;

• выбрать стратегию разработки и создания Web — приложения.

1. Описание предметной области

Транспортно-экспедиторская компания «Л-Стрим» оказывает логистические услуги полного цикла и пользуется репутацией надежного партнера. Основная деятельность компании — международные грузовые перевозки из стран Азиатско-Тихоокеанского региона, перевозки по территории России, комплексные услуги ВЭД, складские услуги.

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

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

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

Основная документация:

• ОГРН;

• ИНН;

• устав предприятия;

• реквизиты;

• заявка на перевозку сборного груза;

• договор.

1. Цели и задачи

Целью разработки WEB-приложения «Л-Стрим» является создание удобного и эффективного инструмента оказания логистических услуг, а именно международные перевозки из стран Азиатско-Тихоокеанского региона, перевозки по территории России, комплексные услуги ВЭД, складские услуги. Пользователь должен иметь возможность ознакомиться с полным объемом информации о деятельности и услугах компании.

Задачи, которые должно реализовывать разрабатываемое Web-приложение:

• дать возможность клиенту пользоваться услугами компании;

• предоставить возможность получения новой информации, касающихся перевозок;

• минимизировать телефонные/почтовые контактов с заказчиком за счет удобной подачи информации на Web-приложении;

• частично автоматизировать процесс оказания услуг заказчикам.

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

При разработке Web-приложения необходимо решить следующие задачи:

• ознакомиться с деятельностью компании;

• рассмотреть основные понятия web-технологий;

• изучить основные технологии создания web-приложений;

• разработать web-приложение;

• разработать хороший интерфейс web-приложения;

• разместить приложение в сети Интернет.

Web-приложение должно соответствовать правилам, указанным компанией ООО «Л-Стрим».

1. Проектирование системы

1. Модель вариантов использования

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

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

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

Построение этой модели необходимо для выявления:

• внешнего окружения, взаимодействующего с системой (актеров);

• основных функций системы (вариантов использования) с возможным уточнением технологии их выполнения;

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

1. Диаграммы вариантов использования

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

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

При этом актером (действующим лицом, актантом, актором) называется любой объект, субъект или система, взаимодействующая с моделируемой системой извне. В свою очередь вариант использования – это спецификация сервисов (функций), которые система предоставляет актеру.

Согласно UML актера графически можно отобразить тремя способами:

• «проволочный человечек»;

• класс с текстовым стереотипом «actor»;

• произвольная иконка.

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

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

Актерами в данной системе выступают:

• пользователь;

• администратор.

Варианты использования:

• формирование и изменение предложения;

• просмотр информации;

• редактирование информации;

• заполнение заявки;

• обращение к специалисту;

• обработка заявки.

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

Рисунок 3.1 – Контекстная диаграмма вариантов использования

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

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

Просмотреть диаграмму декомпозиции «Подача заявки» можно на рисунке 3.2.

На этой диаграмме подробно описан процесс того, как актер «Пользователь» подает заявку на перевозку.

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

Рисунок 3.2 – Диаграмма декомпозиции «Подача заявки»

Следующая диаграмма (рисунок 3.3) подробно рассматривает возможность пользователя просматривать всю доступную документацию на сайте компании. Такую как, устав предприятия, ИНН, ОГРН. Так же он может скачать некоторые доступные файлы.

Для этого пользователю достаточно открыть вкладку «Просмотр документации».

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

Проект системы учета заказов на грузоперевозку автотранспортной компании ‘ТрансАвто’

Содержание

 

Перечень сокращений, условных обозначений, символов, единиц и
терминов

Введение

1. Описание предметной области

1.1 Характеристика объекта автоматизации

1.2 Обоснование необходимости разработки ИС с помощью
объектно-ориентированной методологии

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

3. Разработка модели поведения задачи «Учет заказов на
грузоперевозку автотранспортной компании «Трансавто» с использованием
диаграмм действий

4. Разработка логической структуры задачи «Учет заказов на
грузоперевозку автотранспортной компании «Трансавто» с использованием
диаграмм классов

5. Разработка модели взаимодействия объектов задачи «Учет заказов
на грузоперевозку автотранспортной компании «Трансавто» с
использованием диограмм последовательности

6. Разработка физического представления задачи «Учет заказов
на грузоперевозку автотранспортной компании «Трансавто» с
использованием диаграмм развертывания и компонентов

Выводы

Перечень ссылок

Перечень
сокращений, условных обозначений, символов, единиц и терминов

АС
— автоматизированная система;

БД — база данных;

ИС — информационная система;

КТС — комплекс технических средств;

ОА — объект автоматизации;

ОС — операционная система;

ОУ — объект управления;

ПК — персональный компьютер;

ПО — программное обеспечение;- Data Access Object- Graphic
User Interface- Unified Modeling Language.

Введение

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

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

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

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

Указанная проблема устранена с помощью автоматизации задачи
учета заказов на грузоперевозку автотранспортной компании «ТрансАвто»

1. Описание
предметной области

1.1
Характеристика объекта автоматизации

Объектом автоматизации является автотранспортная компания
«ТрансАвто».

Данная компания занимается предоставлением услуг
грузоперевозки по территории Украины. Маршруты перевозки данной компании
подразделяются на основные и заказные. К основным относятся те, что основаны на
долгосрочных контрактах, а заказные выполняются при одноразовом заказе.

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

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

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

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

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

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

Процессы, протекающие в автотранспортной компании:

Прием заказов на перевозку груза;

Определение дальности следования;

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

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

Транспортировка груза в пункт назначения;

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

информационная система учет заказ

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

Работа с кадрами (наем, оплата труда);

Решение организационных вопросов.

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

Схема организационной структуры автотранспортной компании
представлена на рисунке 1.1.

Рисунок 1.1 — Схема организационной структуры
автотранспортной компании «ТрансАвто»

Непосредственно объектом автоматизации является аналитический
отдел автотранспортной компании.

Специалисты данного отдела занимаются следующими вопросами:

Приемом заказа от заказчика перевозки;

Структурирование исходных данных для их последующей
обработки;

Определение дальности следования;

Определением необходимого автомобиля;

Расчет тарифа перевозки.

Данный отдел занимается приемом и аналитической обработкой
заказов на перевозку груза. Оператор принимает заказ от клиента по телефону или
при его личном присутствии в офисе компании. При этом в документ «Бланк
заказа» вносятся все необходимые данные для реализации перевозки, такие
как пункт отправления, пункт назначения, физические особенности груза, кто
является заказчиком и другие. Заполненный документ передается аналитику,
который знакомится с входящей информацией и проводит ее анализ.

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

Полученные результаты передаются главному аналитику, который
знакомится с ними и вносит коррективы при необходимости. Главный аналитик
передает некоторые данные бухгалтеру и формирует документ «Заказ на
перевозку» для директора, который в свою очередь подписывает этот заказ
для дальнейшего его исполнения.

1.2
Обоснование необходимости разработки ИС с помощью объектно-ориентированной
методологии

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

Недостатками работы в данной компании являются:

Работа с данными выполняется традиционным (бумажным)
способом;

Высокая трудоемкость сбора информации;

Низкая скорость взаимодействия между подсистемами;

Невозможность редактирования уже созданных документов;

Отсутствие единой базы документов.

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

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

Для разработки информационной системы используются различные
методологии. Модели разрешают нам наглядно продемонстрировать желательную
структуру и поведение системы. Одним из наиболее распространенных языков
моделирования есть унифицированный язык моделирования UML (Unіfіed Modelіng
Language), предназначен для моделирования, представления, проектирования и
документирования программных систем, организационно-экономических систем,
технических систем и других систем различной природы. Визуальные модели
разрешают организовать общение между заказчиками и разработчиками.также
используют для моделирования бизнес-процессов, системного проектирования и
отображения организационных структур. UML позволяет разработчикам программного
обеспечения достигнуть соглашения в графических обозначениях для представления
общих понятий (таких как класс, компонент, обобщение (generalization),
объединение (aggregation) и поведение) и больше сконцентрироваться на
проектировании и архитектуре. Он упрощает сложный процесс проектирования ПО
путем создания «чертежа» для построения системы. Язык UML не привязан
к какой-либо отдельной платформе или языку программирования, поэтому он хорошо
подходит для соединения сетей различных систем. Он разрабатывался с учетом гибкости
и поэтому способен адаптироваться к возникающим новым проблемам [5].содержит
стандартный набор диаграмм и нотаций разнообразных видов. UML содержит
следующий набор диаграмм:

диаграммы классов (class dіagrams) — для моделирования статической
структуры классов системы и связей между ними;

диаграммы компонентов (component dіagrams) — для
моделирования иерархии компонентов (подсистем) системы;

диаграммы размещения (deployment dіagrams) — для
моделирования физической архитектуры системы;

модели поведения (behavіoral):

диаграммы вариантов использования (use case dіagrams) — для
моделирования функциональных требований к системе (в виде сценариев
взаимодействия пользователей с системой);

диаграммы взаимодействия (іnteractіon dіagrams), такие как
диаграммы последовательности (sequence dіagrams) и кооперативные диаграммы
(collaboratіon dіagrams) — для моделирования процесса обмена сообщениями между
объектами;

диаграммы состояний (statechart dіagrams) — для моделирования
обращения объектов системы при переходе с одного состояния в другого;

диаграммы деятельности (actіvіty dіagrams) — для
моделирования обращения системы в рамках разных вариантов использования, или
потоков управления.

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

Для описания функциональной структуры системы используется
диаграмма вариантов использования. Этот тип диаграмм описывает общую
функциональность системы. Они отображают взаимодействие между вариантами
использования, которые представляют функции системы, и действующими лицами,
которые представляют людей или системы, которые получают или передают
информацию в данную систему. Каждая функциональность изображается в виде
«прецедентов использования» (use case) или просто прецедентов.
Прецедент — это типичное взаимодействие пользователя с системой, которая может
представлять разные уровни детализации, описывать видимую пользователем
функцию, обеспечивать достижение конкретной цели, важной для пользователя.
Прецедент изображается как овал, связанный с типичными пользователями, которые
называются актерами (actors). Список всех прецедентов фактически определяет
функциональные требования к ИС [8].

Достоинства модели вариантов использования состоят в том, что
она:

определяет пользователей и границы системы;

определяет системный интерфейс;

удобная для общения пользователей с разработчиками;

используется для написания тестов;

является основой для написания пользовательской документации.

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

Расширение (extend) — показывает, что вариант использования
расширяет базовую последовательность действий и вставляет собственную последовательность.
При этом в отличие от типа отношений «включение» расширенная
последовательность может осуществляться в зависимости от определенных условий.

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

Рисунок 2.1 — Диаграмма прецедентов

На диаграмме представлены актеры: менеджер, клиент, который
непосредственно является пользователем системы со стороны «клиент». В
таблице 2.1 приводится описание вариантов использования.

Таблица 2.1 — Описание вариантов использования

Название	Описание	Связи
1	2	3
Работа с клиентами	Просмотр всего списка клиентов, личных данных клиентов, возможность удалить клиента и зарегистрировать. В результате соответствующих манипуляций происходит изменение БД.	Отношение ассоциации к Менеджеру
Подсчитать стоимость перевозки	Подсчитывается стоимость перевозки на основе данных вводимых пользователем	Отношение ассоциации к Менеджеру и Клиенту
Оставить заявку на перевозку	Заполняется поля заявки для дальнейшей отправки, сохранения в БД и обработки менеджером	Отношение ассоциации к Менеджеру и Клиенту
Сменить тариф	Менеджер может изменять тарифную базу путем занесения новых значений.	Отношение ассоциации к Менеджеру
Обработать заказы	Менеджер обрабатывает информацию о заказах	Отношение ассоциации к Менеджеру
Формирование отчета	Формирование отчета по заказам за определенный период	Отношение ассоциации к Менеджеру
Заполнение формы регистрации	Заполнение формы регистрации	Отношение включения к Регистрация клиента
Удаление клиента	Удаление клиента из базы	Отношение расширения к Работа с клиентами
Просмотр клиентов	Просмотр всего списка клиентов	Отношение расширения к Работа с клиентами
Просмотр заказов конкретного клиента	Просмотр заказов конкретного клиента	Отношение расширения к Работа с клиентами
Оформить заказ	Оформление заказа	Отношение включения к оставить заказ на перевозку
Просмотр тарифов на перевозку	Просмотр тарифов на перевозку	Отношение расширения к Сменить тариф

3. Разработка
модели поведения задачи «Учет заказов на грузоперевозку автотранспортной
компании «Трансавто» с использованием диаграмм действий

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

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

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

Деятельностью (Actіvіty) называется поведение, реализованное
объектом, когда он находится в данном состоянии. Деятельность — поведение,
которое может прекращаться. Она может выполняться к своему завершению, если
объект находится в данном состоянии, либо может быть прерванная переходом
объекта в другой состояние [8].

Приведем диаграмму деятельности, что описывает модель
поведения варианта использования «Работа с клиентами» в
информационной системе «ТрансАвто». Диаграмма представлена на рисунке
3.1.

Рисунок 3.1 — Диаграмма деятельности для варианта
использования «Работа с клиентами»

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

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

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

Приведем диаграмму деятельности для варианта использования
«Оставить заказ на перевозку». Диаграмма представлена на рисунке 3.3.

Рисунок 3.3 — Диаграмма деятельности для варианта
использования «Учет состава учителей»

Приведем диаграмму деятельности для варианта использования
«Подсчет стоимости перевозки». Диаграмма представлена на рисунке 3.4.

Рисунок 3.4 — Диаграмма деятельности для варианта
использования «Подсчет стоимости перевозки»

Менеджер имеет право вносить изменения в тарифную базу, при
изменении политики компании или при подорожании топлива.

Приведем диаграмму деятельности для варианта использования
«Сменить тариф». Диаграмма представлена на рисунке 3.5.

Рисунок 3.5 — Диаграмма деятельности для варианта
использования «Сменить тариф»

Для получения отчетных документов используется прецедент
«Формирование отчета» в котором можно указать период за который нужно
выдать отчет, выбрать направления следования по которым нужно произвести
анализ, а также определить клиентов по которым нужно получить отчетности.

Приведем диаграмму деятельности для варианта использования
«Формирование отчета». Диаграмма представлена на рисунке 3.6.

Рисунок 3.6 — Диаграмма деятельности для варианта
использования «Формирование отчета»

4. Разработка
логической структуры задачи «Учет заказов на грузоперевозку автотранспортной
компании «Трансавто» с использованием диаграмм классов

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

Диаграмма классов показывает статическую структуру системы.
Составляющими данного типа диаграмм есть классы, объекты и отношения между
ними. Кроме того, диаграмма классов может включать комментарии и ограничения.
Ограничения могут неформально задаваться на естественном языке или же могут
формулироваться на языке объектных ограничений OCL (Object Constraints
Language).

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

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

В диаграмме классов могут участвовать связи трех разных
категорий: зависимость (dependency), обобщение (generalization) и ассоциация
(association).

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

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

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

Для класса можно указать одно из трех значений:іc (открытый).
Этот класс видим всем другим классам системы;, prіvate (защищенный, закрытый).
Класс может быть видим во вложенных у него классах, «друзьям» этого
класса или из самого класса;or Іmplementatіon (пакет или реализация). Класс
может быть видим только из классов того же пакета [8].

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

Рисунок 4.1 — Диаграмма классов для задачи учета заказов
грузоперевозку автотранспортной компании «ТрансАвто»

Диаграмма состоит из 14 классов. Все классы разбиты по
пакетам, в зависимости от их предназначения.

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

В пакете DAO находятся классы. которые реализуют шаблон
проектирования DAO (Data Access Object) и предназначены для доступа к данным
БД.

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

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

5. Разработка
модели взаимодействия объектов задачи «Учет заказов на грузоперевозку
автотранспортной компании «Трансавто» с использованием диограмм
последовательности

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

Существует два типа диаграмм взаимодействия:

диаграммы последовательности;

кооперативные диаграммы.

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

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

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

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

Диаграммы взаимодействия разрабатываются для каждого варианта
использования. На рисунках 5.1-5.9 представлены диаграммы для вариантов
использования «Работа с клиентами», «Формирование отчета», «Регистрация
клиента», «Удаление клиента», «Просмотр всех
клиентов», «Просмотр заказов конкретного клиента», «Подсчет
стоимости перевозки», «Отправить заказ на перевозку»,
«Сменить тариф», «Обработать заказы».

Рисунок 5.1 — Диаграмма взаимодействия для варианта
использования «Работа с клиентами»

Рисунок 5.2 — Диаграмма взаимодействия для варианта
использования «Формирование отчета»

Рисунок 5.3 — Диаграмма взаимодействия для варианта
использования «Регистрация клиента»

Рисунок 5.4 — Диаграмма взаимодействия для варианта
использования «Удаление клиента»

Рисунок 5.5 — Диаграмма взаимодействия для варианта
использования «Просмотр всех клиентов»

Рисунок 5.1 — Диаграмма взаимодействия для варианта
использования «Работа с клиентами»

Рисунок 5.6 — Диаграмма взаимодействия для варианта
использования «Подсчет стоимости перевозки»

Рисунок 5.7 — Диаграмма взаимодействия для варианта
использования «Отправить заказ на перевозку»

Рисунок 5.8 — Диаграмма взаимодействия для варианта
использования «Сменить тариф»

Рисунок 5.9 — Диаграмма взаимодействия для варианта
использования «Обработать заказы»

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

6. Разработка
физического представления задачи «Учет заказов на грузоперевозку
автотранспортной компании «Трансавто» с использованием диаграмм
развертывания и компонентов

Данные, необходимые для решения данной задачи, организованы в
виде БД. В качестве СУБД была выбрана MySQL 5.0. MySQL — это система управления
реляционными базами данных с открытым исходным кодом [9]. Сервер баз данных
MySQL — очень быстрый, надежной и простой в эксплуатации. Среди преимуществ
СУБД MySQL можно отметить такие, как производительность, масштабируемость,
независимость от платформ (аппаратных, операционных и сетевых), безопасность.
Максимальные размеры таблиц определяются ограничениями, которые накладываются
операционной системой на размеры файлов, а не внутренними ограничениями MySQL.
В качестве операционной системы можно использовать Windows XP.

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

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

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

Диаграммы компонентов и развертывания представлены на
рисунках 6.1-6.2.

Рисунок 6.1 — Диаграмма развертывания

Рисунок 6.2 — Диаграмма компонентов

 

Выводы

В курсовой работе проанализированы особенности предметной
области и объекта автоматизации. Разработаны проектные решения для задачи
«Учет заказов на грузоперевозку автотранспортной компании
«ТрансАвто». Обоснован выбор необходимости разработки ИС с помощью
объектно-ориентированной методологии. Приведены характеристики диаграмм UML.

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

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

Перечень
ссылок

1. Закон Украины
об образовании [Електронний ресурс] / Законодательная база Украины — Режим
доступа: <http://www>. base. spinform.ru — Дата доступa: май 2009. —
Название с экрана.

. Кодекс законов
о труде [Електронний ресурс] / Законодательная база Украины — Режим доступа:
<http://www>. zakon. rada. kiev.ru

. Формирование
нагрузки учителей в школе [Електронний ресурс] / Pedsovet — Режим доступа:
<http://www>. pedsovet.ru

. Распределение
часов по предметам в школе [Електронний ресурс] / School — Pежим доступа:
<http://ps>.1september.ru

5.
Фаулер, М., Скотт К. UML в кратком изложении. Применение стандартного языка
объектного моделирования [Текст] / М. Фаулер, К. Скотт: пер. с англ. — М.: Мир,
1999. — 721 с.

6.
Хансен, Г. Базы данных: разработка и управление [Текст] /Г. Хансен. — М.: ЗАО
Издательство «БИНОМ», 1999. — 704 с.

.
MySQL. Справочник по языку. [Текст] / Компания MySQL AB.: пер. с англ. — М.:
Издательский дом «Вильямс», 2005. — 432с.

.
Борисенко, В.П., Левыкин, В.М., Пономарев, Ю.В., Борисенко Т.И.
Объектно-ориентированный анализ и проектирование ИКС на основе UML [Текст] / В.
П Пономарев, В.М. Левыкин, Ю.В. Пономарев, Т.И. Борисенко. — Х:
«ХНУРЭ», 2004. — 80 с.

.
Грофф, Дж. SQL: Полное руководство [Текст] / Дж. Грофф: пер. с англ. — К.:
Издательская группа BHV, 2001. — 816 с.

.
Рахимов, Т.Н., Заикин, О.А., Советов, Б.Я. Основы построения АСУ [Текст] / Т.Н.
Рахимов, О.А. Заикин, Б.Я. Советов. — Ташкент: «Укитувчи», 1984. —
370 с.

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

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

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

Рисунок
9 – Диаграмма вариантов использования
информационной системы формирования
автомашины с грузом загрузки автомашин
транспортно-экспедиционной компании.

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

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

Рисунок
10 – Диаграмма деятельности обработки
заказа

Рисунок
11 – Диаграмма деятельности информационной
системы

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

Разрабатываемая
система должна решить следующие задачи:

• Повысить
  эффективность использования грузового
  пространства в транспортно-экспедиционной
  компании;

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

1. Проектирование информационной системы управления объемами загрузки транспортно-экспедиционной компании

1. Формирование требований к системе

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

Основные
операции, реализуемые информационной
системой формирования автомашины с
грузом, представлены в таблице 6.

Таблица
6
–
Основные операции ИС

№	Наименование операций
1	Хранение данных о всех груза
2	Хранение данных о всех автомашинах предприятиях
3	Расчет стоимость доставки
4	Решение задачи «О ранце»
5	Формирование документов

Информационная
система формирование автомашин с грузом
транспортно-экспедиционной компании
обеспечивает:

• единую,
  базу данных с информацией о всех
  автомашинах предприятия и грузах;

• формирование
  автомашин с грузом и предоставление
  наиболее оптимальных вариантов для
  выбора диспетчером;

• формирование
  документов на всех этапах обработки
  заявок;

• хранить
  статус процесса выполнения заказа

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

1. Диспетчер
   оформляет заявку на основе обращения
   клиента.

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

1. Сравнительный анализ информационных систем-аналогов

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

Для
анализа были выбраны следующие системы:
Packer3d, Truckfill, Wiraj,
Truck Loader System. Для всех выбранных
информационных систем имеется не менее
десяти внедрений в российских компаниях.

Рассмотрим
информационную систему Packer3d, она обладает
следующей функциональностью:

• Учет
  приоритета установки единиц грузов в
  кузове;

• Отображение
  схемы укладки в удобном виде;

• Существует
  удобный online-инструмент.

Далее
рассмотрим программный продукт Truckfill,
который обладает следующими возможностями:

• Создание
  планов загрузки для автотранспорта;

• Возможность
  экспортировать результаты в другие
  приложения;

• Наличае
  3D
  редактора, для наглядного отображения
  загрузки;

• Формирование
  отчетности.

Рассмотрим
программный продукт Wiraj.
Основными плюсами являются:

• Легкая
  масштабируемость под предприятия
  различного размера;

• 2D
  и 3D
  редактор, позволяющий редактировать
  размещение;

• Автоматическая
  расстановка грузов, предупреждение о
  не поместившихся грузах;

• Возможность
  работы с нестандартными грузами.

Основные
минусы:

• высокая
  начальная стоимость внедрения
  информационной системы;

• высокая
  стоимость сопровождения системы;

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

Доработка
данной информационной системы может
существенно увеличить ее стоимость.

Далее
рассмотрим информационную систему
Truck Loader System. Особенности продукта:

• Наличие
  графического редактора;

• Возможность
  формирования отчетности.

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

Осуществим
выбора критериев для сравнительного
анализа аналогов информационных систем,
используя методы системного анализа
метод анализа иерархий (МАИ).

При
анализе информационных систем будем
руководствоваться следующими критериями:

• Стоимость
  владения информационной системы.

• Функциональная
  полнота (в соответствии с требованиями).

• Формирование
  отчетности.

• Возможность
  настройки информационной системы (при
  изменении структуры и организации
  бизнес-процессов).

Основные
сравнительные качественные и количественные
характеристики сведем в таблицу 7.

Таблица
7–
Сравнительная таблица аналогов

	Packer3d	Truckfill	Wiraj	Truck Loader System
Стоимость владения (руб.)	1000 000	1100 000	1200 000	890 000
Функциональная полнота	Высокое	Среднее	Среднее	Высокое
Формирование статистики	Высокое	Среднее	Высокое	Среднее
Возможность настройки	Среднее	Среднее	Среднее	Среднее

Составим
матрицу попарных сравнений критериев
анализа, назначая ему значение от 0 до
9 в зависимости от важности (таблица 8).

Таблица
8 – Матрица попарных сравнений критериев

	Стоимость владения (руб.)	Функциональная полнота	Формирование статистики	Возможность настройки	Оценки компонент собственного вектора	Нормализованные оценки вектора приоритета
Стоимость владения (руб.)	1	1/2	3	1/5	0.64	0.113
Возможность настройки	2	1	5	1/6	1.44	0.18
Формирование статистики	1/3	1/5	1	1/7	0.51	0.272
Функциональная полнота	5	6	7	1	3.61	0.435
Сумма:	6,2

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

Таблица
9 – Сравнение ИС по критерию «Стоимость
владения»

	Packer3d	Truckfill	Wiraj	Truck Loader System	Оценки компонент собственного вектора	Нормализованные оценки вектора приоритета
Packer3d	1	1/3	1/2	1/7	0.59	0.166
Truckfill	3	1	2	1/5	1.25	0.168
Wiraj	2	1/2	1	1/6	0.57	0.18
Truck Loader System	7	5	6	1	3.71	0.45
Сумма:	6.287

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

Таблица
10 – Сравнение ИС по критерию «Возможность
настройки»

	Packer3d 7.5	Truckfill	Wiraj	Truck Loader System	Оценки компонент собственного вектора	Нормализованные оценки вектора приоритета
Packer3d 7.5	1	6	4	3	2.81	0.557
Truckfill	1/6	1	1/2	1/3	0.41	0.078
Wiraj	1/4	2	1	1/2	0.71	0.136
Truck Loader System	1/3	3	2	1	1.18	0.228
Сумма:	5.11

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

Таблица
11– Сравнение ИС по критерию «Формирование
статистики»

	Packer3d 7.5	Truckfill	Wiraj	Truck Loader System	Оценки компонент собственного вектора	Нормализованные оценки вектора приоритета
Packer3d 7.5	1	3	2	4	2.21	0.352
Truckfill	1/3	1	1/2	2	0.86	0.256
Wiraj	1/2	2	1	3	1.46	0.2
Truck Loader System	1/4	1/2	1/3	1	0.95	0.192
Сумма:	5.48

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

Таблица
12– Сравнение ИС по критерию «Функциональная
полнота»

	Packer3d	Truckfill	Wiraj	Truck Loader System	Оценки компонент собственного вектора	Нормализованные оценки вектора приоритета
Packer3d	1	1/3	1/2	1/7	0.89	0.056
Truckfill	3	1	2	1/5	1.05	0.168
Wiraj	2	1/2	1	1/6	1.47	0.18
Truck Loader System	7	5	6	1	3.81	0.55
Сумма:	7.387

Сведем
все полученные результаты в таблицу
13.

Таблица
14 – Сводная таблица альтернатив и
критериев

	Критерии
Стоимость владения	Функциональная полнота	Формирование статистики	Возможность настройки	Глобаль-ные приорите-ты
Численное значение вектора приоритета
0.113	0.18	0.272	0.435
Packer3d	0.166	0.056	0.352	0.557	0.173
Truckfill	0.168	0.168	0.256	0.078	0.276
Wiraj	0.18	0.18	0.2	0.136	0.209
Truck Loader System	0.45	0.55	0.192	0.228	0.322

Выбранной
альтернативе с максимальным значением
глобального приоритета является система
Truck Loader System, глобальный приоритет которой
равен 0,322.

Однако
стоимость информационной системы Truck
Loader System составляет 890 000 рублей и ее
приобретение экономически невыгодно,
с точки зрения возможности собственной
разработки. В соответствии с проведенным
анализом можно сделать вывод о
целесообразности разработки и внедрения
информационной системы формирования
автомашины с грузом для
транспортно-экспедиционной компании.

Федеральное государственное образовательное бюджетное учреждение
высшего образования
ФИНАНСОВЫЙ УНИВЕРСИТЕТ при ПРАВИТЕЛЬСТВЕ РФ
Факультет прикладной информатики и информационных технологий
Кафедра «Бизнес-информатика»

КУРСОВАЯ РАБОТА 1

НА ТЕМУ:

Разработка модели информационной системы фирмы грузовых перевозок на
основе UML

Руководитель:к.т.н. Зараменских Евгений Петрович
Студент: Каргин Андрей Валерьевич
Группа БИ2-

Москва 2017

СОДЕРЖАНИЕ

ВВЕДЕНИЕ……………………………………………………………………………………………………

• ВВЕДЕНИЕ……………………………………………………………………………………………………
• 1. Основная часть…………………………………………………………………………………………
  • 1 Бизнес-моделирование предметной области………………………………………..
    • 1. Схема организационной структуры……………………………………………………..
    • 1. Таблица функций………………………………………………………………………………..
    • 1. Диаграмма процесса оформления заказа в нотации BPMN…………………..
  • 1 Статические модели проектируемой информационной системы…………
    • 1. Диаграмма вариантов использования (бизнес-модель)……………………….
    • 1. Диаграмма вариантов использования (системная модель)…………………..
    • 1. Диаграмма классов……………………………………………………………………………
  • 1 Динамические модели проектируемой информационной системы………
    • 1. Диаграмма последовательности…………………………………………………………
    • 1. Диаграмма деятельности……………………………………………………………………
• ЗАКЛЮЧЕНИЕ……………………………………………………………………………………………
• Список использованных источников……………………………………………………………..
• ПРИЛОЖЕНИЯ……………………………………………………………………………………………

Бухгалтер, Начальник отдела перевозок и Секретарь. Организация предоставляет услуги грузовых перевозок по Москве и Московской области. Общее число сотрудников: 19. Компанию возглавляет Генеральный директор. У него в подчинении находятся Начальник отдела кадров, Начальник Call-центра, Специалист по логистике, Менеджер по маркетингу,
Отдел кадров возглавляет Начальник отдела кадров, в подчинении у которого находятся 2 Менеджера по персоналу.
Call-центр возглавляет Начальник Call-центра, в подчинениОтдел логистики состоит из 1 Специалиста по логистике.и у которого находятся 2 оператора.
Отдел маркетинга состоит из 1 Менеджера по маркетингу.
Бухгалтерский отдел возглавляет бухгалтер.Во главе отдела перевозок стоит Начальник отдела перевозок, в подчинении которого находятся 3 Грузчика и 4 Водителя.

1. Основная часть…………………………………………………………………………………………

1 Бизнес-моделирование предметной области………………………………………..

1) Схема организационной структуры……………………………………………………..

ИмяГенеральный директор

ИмяНачальник отдела кадров

ИмяМенеджер по персоналу [2]
Отдел кадров

ИмяБухгалтер

Бухгалтерский отдел

ИмяСпециалист по логистике

Отдел логистики Отдел маркетинга

ИмяМенеджер по маркетингу

ИмяНачальник отдела
перевозок

ИмяГрузчик [3]

ИмяНачальник Call-центра

ИмяОператор Call-Центра [2]

ИмяВодитель [4]

Call-центра

ИмяСекретарь

Отдел перевозок

Описание:

Организация предоставляет услуги грузовых перевозок по Москве и
Московской области. Общее число сотрудников: 19. Компанию возглавляет
Генеральный директор. У него в подчинении находятся Начальник отдела
кадров, Начальник Call-центра, Специалист по логистике, Менеджер по
маркетингу, Бухгалтер, Начальник отдела перевозок и Секретарь.

Отдел кадров возглавляет Начальник отдела кадров, в подчинении у которого
находятся 2 Менеджера по персоналу.

Call-центр возглавляет Начальник Call-центра, в подчинении у которого
находятся 2 оператора.

Отдел логистики состоит из 1 Специалиста по логистике.

Отдел маркетинга состоит из 1 Менеджера по маркетингу.

Бухгалтерский отдел возглавляет бухгалтер.

Во главе отдела перевозок стоит Начальник отдела перевозок, в подчинении
которого находятся 3 Грузчика и 4 Водителя.

2) Таблица функций………………………………………………………………………………..

Подразделение Должность Функции
Генеральный директор 1. Формирует
дальнейшую
стратегию развития
компании.
2. Отвечает за
организацию
эффективного
взаимодействия
структурных
подразделений
компании.
3. Утверждает штатное
расписание
компании.
4. Организует
эффективный
документооборот.
5. Обеспечивает
соблюдение
законности в
деятельности
организации.
Секретарь 1. Ведение
делопроизводства
2. Планирование
рабочего дня
Генерального

ведение
делопроизводства
своего отдела в
компании.
3. Контролирует
работоспособность и
эффективность
информационных
технологий Call-
центра.
Оператор Call-центра 1. Принимает звонки от
клиентов
2. Рассказывает об
услугах компании.
3. Рассчитывает
стоимость перевозок
4. Оформляет заказы.
Отдел логистики Специалист по
логистике

1. Составляет маршрут
   перевозок и
   осуществляет его
   корректировку
2. Координирует работу
   водителей.
3. Разрешает спорные
   вопросы,
   возникающие при
   выполнении заказа.
4. Отслеживает заказы.

Отдел маркетинга Менеджер по
маркетингу

1. Изучает рынок и его
   тенденции.
2. Отвечает за
   разработку и
   удержание
   конкурентного
   преимущества.
3. Налаживает
   отношения с

клиентами.

Бухгалтерский отдел Бухгалтер 1. Осуществляет
контроль за
своевременным и
правильным
оформлением
бухгалтерской
документации.
2. Осуществляет
перечисление
налогов и сборов в
бюджеты разного
уровня.
3. Составляет расчеты
по зарплате
сотрудников.
Отдел перевозок Начальник отдела
перевозок

1. Руководит
   разработкой и
   внедрением
   технологий и
   методов организации
   перевозок.
2. Руководит
   работниками отдела
   перевозок.
3. Участвует в
   организации
   контроля за
   соблюдением правил
   перевозок грузов.
4. Контролирует
   ведение
   делопроизводства
   отдела перевозок в
   компании.
   Водитель 1. Согласовывает
   маршрут следования

1 Статические модели проектируемой информационной системы…………

системы

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

1) Диаграмма вариантов использования (бизнес-модель)……………………….

(Приложение 2)

Потоки событий:

a) Потоки событий для прецедента «Получение информации о маршруте»

Основной поток событий.

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

Альтернативные потоки.

A1. Водитель не прошел идентификацию пользователя.
 Система полностью блокирует информацию обо всех грузоперевозках.
 Получение информации о маршруте возможно после ввода верных
данных.
 Прецедент завершается.

A2. Водитель не является непосредственным участником выбранного
маршрута.

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

Потоки ошибок.

E1. База данных недоступна

1. Система выводит сообщение о недоступности базы данных.

b) Потоки событий для прецедента «Получение информации о выплатах и
произведенных перевозках»

Основной поток событий.

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

Альтернативные потоки.

A1. Водитель не прошел идентификацию пользователя.
 Система полностью блокирует информацию обо всех грузоперевозках.
 Получение информации о выплатах и произведенных перевозках
возможно после ввода верных данных.
 Прецедент завершается.

1 Динамические модели проектируемой информационной системы………

системы

1) Диаграмма последовательности…………………………………………………………

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

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

2) Диаграмма деятельности……………………………………………………………………

Диаграмма деятельности — UML-диаграмма, показывающая разложение
некоторой деятельности на её составные части. Диаграмма деятельности может
относиться к отдельному классу, варианту использования операции класса,
представлению или пакету. (Приложение 6)

ЗАКЛЮЧЕНИЕ

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

Были изучены процессы, протекающие в предметной области (фирма
грузоперевозок). Разработана модель организационной структуры компании,
таблица функций, был смоделирован процесс оформления заказа в нотации
BPMN.
Дальнейшим шагом стало создание статических и динамических моделей
информационной системы: диаграмм вариантов использования, диаграммы
классов, диаграммы последовательности и диаграммы деятельности.
В результате выполнения курсовой работы был сформирован вывод, что
внедрение информационных систем может способствовать:
 Уменьшению затрат на оказание услуг
 Освобождению работников от рутинной работы за счет её автоматизации
 Обеспечению безопасности информации


ПРИЛОЖЕНИЯ

ПРИЛОЖЕНИЕ 1

3) Диаграмма процесса оформления заказа в нотации BPMN…………………..

ПРИЛОЖЕНИЕ 3

Диаграмма вариантов использования (системная модель)

Клиент Работа фирмы грузоперевозок Водитель

Оператор Call-центра Специалист по логистике

Оформление заказа &lt;&lt;include&gt;&gt;Составление маршрута&lt;&lt;include&gt;&gt; Осуществление грузоперевозки Оплата

&lt;&lt;include&gt;&gt; &lt;&lt;include&gt;&gt;

Внесение информации о заказе в БД

&lt;&lt;include&gt;&gt;

Расчет стоимости перевозки

&lt;&lt;include&gt;&gt; Выдача чека&lt;&lt;include&gt;&gt;

Наложение штрафных санкций за повреждение груза

Внесение информации о маршруте в БД&lt;&lt;include&gt;&gt; &lt;&lt;extend&gt;&gt;
Корректировка маршрута

&lt;&lt;extend&gt;&gt;
Получение информации о маршруте

&lt;&lt;include&gt;&gt;

ПРИЛОЖЕНИЕ 4

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

БД фирмы
+Кодовый номер заказа: Integer+Информация о грузе: String
+Маршрут: String+ФИО клиента: String
+Номер телефона клиента: String+Статус оплаты: Boolean
+Дата выполнения заказа: Date+ID водителя: Integer
+Стоимость перевозки: Float
+Создание нового заказа()+Корректировка заказа()
+Поиск заказа()+Удаление заказа()

Оператор Call-центра
+ID сотрудника: Integer+ФИО: String
+Должность: String
+Прием звонков от клиентов()+Оформление заказа()
+Расчет стоимости перевозки()

Специалист по логистике
+ID сотрудника: Integer+ФИО: String
+Должность: String
+Построение маршрута()+Изменение маршрута()
+Консультация водителя()

Водитель
+ID водителя: Integer+ID сотрудника: Integer
+ФИО: String+Должность: String
+Получение информации о маршруте()+Прием оплаты от клиента()
+Изменение статуса оплаты()+Осуществление грузоперевозок()

1
1

• 1

1

• 1

Время на прочтение
10 мин

Количество просмотров 159K

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

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

---

Сегодня мы разберемся с тем, как использовать диаграмму вариантов использования UML (англ. «Unified Modeling Language») – стандартизированный язык моделирования при проектировании программ.

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

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

• Что будет делать приложение?

• Кто будет пользоваться этим приложением?

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

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

Диаграмма вариантов использования

Диаграмма вариантов использования (англ. use-case diagram) – диаграмма, описывающая, какой функционал разрабатываемой программной системы доступен каждой группе пользователей.

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

В этой системе можно выделить следующие группы пользователей:

• Обучающиеся

• Преподаватели

• Классные руководители

• Заместители директора

Заместители директора есть, а где же сам директор?

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

Каждая из групп пользователей может пользоваться нашей системой по-своему.

Обучающиеся могут:

• Смотреть расписание

• Просматривать свои оценки

Преподаватели могут:

• Размещать материалы для уроков

• Выставлять оценки в электронный журнал

Классные руководители могут делать все то же самое, что и преподаватели плюс:

• Составлять расписание родительских собраний

Заместители директора могут:

• Составлять расписание

• Публиковать посты с важной информацией

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

• Отправлять сообщения

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

А почему мы описываем так мало возможностей?

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

Построение диаграммы

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

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

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

Так же изобразим актёров для оставшихся групп пользователей:

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

В терминологии UML, этот эллипс называется вариантом использования (англ. «use-case»). В общем случае, вариант использования – набор действий, который может быть использован актёром для взаимодействия с системой.

Связи между элементами

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

Отношение ассоциации

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

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

Отношение ассоциации предназначено только для соединения актёров и вариантов использования. Нет никакого смысла соединять отношением ассоциации двух актёров или два варианта использования.

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

Почему отношение ассоциации называется так и не иначе?

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

Добавим еще вариантов использования и соединим их с соответствующими актёрами:

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

Отношение обобщения

Заметим, что в нашей системе группы пользователей «Преподаватель» и «Классный руководитель» обладают схожими возможностями. Чтобы изобразить это на диаграмме, мы можем пойти одним из трёх путей:

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

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

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

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

Разумеется, мы воспользуемся третьим путём. В этом нам поможет, так называемое, отношение обобщения. Отношение обобщения обозначается сплошной линией с полой треугольной стрелкой.

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

Ниже представлены несколько примеров использования отношения обобщения.

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

Вернёмся к нашему основному примеру. Изобразим отношение обобщения от актёра «Кл. руководитель» к актёру «Преподаватель».

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

Давайте обратим внимание на действие «Узнать свои оценки». Логично предположить, что обучающиеся захотят не только знать список своих оценок, но и знать свою среднюю оценку за некоторый период времени или среднюю оценку по определённому предмету.

Изобразим это на диаграмме. Для этого создадим два варианта использования «Узнать среднюю оценку за некоторый период времени» и «Узнать среднюю оценку по предмету» и соединим их с вариантом использования «Узнать свои оценки» отношением обобщения.

Присоединим это к основной диаграмме:

Отношение включения

Для заместителя директора мы отмечали, что ему нужно составлять расписания. Условно расписание можно поделить на три категории:

1. Расписание занятий

2. Расписание мероприятий

3. Расписание каникул

Всё это составляется заместителем директора, поэтому покажем это на диаграмме. Для этого будем использовать отношение включения. Отношение включения обозначается пунктирной линией с V-образной стрелкой на конце, над стрелкой добавляется надпись “include”.

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

Когда мы используем отношение включения, мы подразумеваем, что составные варианты использования ОБЯЗАТЕЛЬНО входят в состав общего варианта использования.

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

Снова вернёмся к нашему основному примеру.

Как итог, наша диаграмма принимает следующий вид:

В целом, на этом можно остановиться. Хоть наш пример и демонстрационный, он немного отражает функциональность реального приложения. Тем не менее, остался еще один элемент, который мы не рассмотрели.

Отношение расширения

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

Во время дистанционного обучения школьникам необходимо выполнять домашние задания и присылать их в виде архива или фотографий учителям. Получается, нужно добавить возможность прикреплять файл к сообщению в нашей системе. Чтобы отобразить это на диаграмме мы будем использовать отношение расширения. Отношение расширения обозначается пунктирной линией с V-образной стрелкой на конце (похоже на отношение включения), над стрелкой добавляется надпись “extend ”.

Зачем над пунктирными линиями добавлять надписи “include” и “extend”?

В UML пунктирная линия с V-образной стрелкой, в общем случае, называется отношением зависимости. Для диаграммы вариантов использования выделяют различные виды зависимостей: отношение включения и отношение расширения. Чтобы их различать, над стрелками пунктирной линией пишут “include” и “extend” соответственно.

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

Два нижних варианта использования описывают возможные «расширения» для базового варианта использования. Исходя из этого примера, мы можем сделать важное замечание.

Можно сказать, что отношение расширения — это выборочное отношение включения. Если отношение включения обозначает, что элемент обязательно включается в состав другого элемента, то в случае отношения расширения это включение необязательно.

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

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

Как итог, получим такую диаграмму:

Вот и всё. Я постарался рассказать вам про все моменты построения диаграммы вариантов использования при проектировании программных систем. В следующем вашем проекте обязательно попробуйте построить данную диаграмму на стадии проектирования. Ваши усилия обязательно окупятся!

Что делать, если я путаюсь в направлении стрелок?

Общие рекомендации:

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

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

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

4. Не дублируйте варианты использования на диаграмме. Если приходится дублировать варианты использования, то элементы диаграммы надо постараться расставить по-другому.

5. Пользуйтесь специальными компьютерными программами для построения диаграмм. Это существенно упростит весь процесс моделирования.