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

Моделирование предметной области «Управление заявками на техническое обслуживание» с помощью UML (Описание предметной области. Постановка задачи)

Содержание:

Введение

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

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

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

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

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

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

- определить пути совершенствования существующей системы и предложить решение для модернизации системы;

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

- выполнить проектирование информационной системы средствами языка UML.

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

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

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

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

Техническому обслуживанию подлежит следующее оборудование, находящееся на балансе предприятия:

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

Техническое обслуживание оборудования включает в себя следующие направления деятельности:

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

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

Заявка на ремонт содержит следующую информацию:

- от кого заявка;

- на ремонт и обслуживание какого оборудования заявка;

- поломка (со слов заявителя);

- дата составления заявки.

При этом обращения имеют различную срочность:

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

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

- периодическое (запланированное) обслуживание техники.

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

Таким образом, сотрудникам IT-отдела необходимо выполнять следующие виды работ:

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

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

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

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

При наличии такой системы сотрудники IT-отдела должны будут при работе:

- зарегистрировать заявку в системе;

- сформировать график для определения заявок к исполнению;

- поставить отметку об исполнении заявки.

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

1.2. Предлагаемые мероприятия по улучшению бизнес-процессов

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

Данный процесс предусматривает, как правило, два основных этапа:

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

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

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

применение методов ИТ для анализа и конструирования бизнес-процессов, например, объектно-ориентированное моделирование;
появление новых бизнес-процессов, позволивших коренным образом изменить базовые правила работы организации.

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

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

- проанализировать порядок выполнения каждого бизнес-процесса;

- определить «узкие места» в каждом бизнес-процессе с точки зрения времени выполнения, качества выполнения, стоимости выполнения;

- определить методы исключения «узких мест», в том числе и с применением IT-технологий;

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

В деятельности IT-отдела можно выделить следующие бизнес-процессы:

Основные – техническое обслуживание оборудования:

- диагностика и выявление неисправностей оборудования;

- техническое обслуживание и ремонт оборудования.

Вспомогательные:

- получение (регистрация) заявок на техническое обслуживание;

- формирование плана выполнения заявок;

- формирование отчетов по выполненным работам.

Реорганизация бизнес-процессов позволит повысить эффективность работы IT-отдела.

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

Регистрация заявок на техническое обслуживание в журнале заявок (ориентировочно – 3 минуты);
Определение (диагностика) неисправности и определение сроков выполнения облуживания (ориентировочно – 10 минут);
Определение заявки к выполнению из всего множества имеющихся заявок (ориентировочно – 5 минут, так как надо просмотреть и проанализировать все заявки);
Составление отчета по выполненным заявкам (ориентировочно – 10 минут).

Как видно, время работы с заявками оставляет около 28 минут, что при 8-часовом рабочем дне составляет 5% рабочего времени. Очевидно, что в течение дня приходит несколько заявок и время работы с ними может достигать 50% рабочего времени.

Сокращение времени возможно за счет автоматизации следующих операций:

Автоматическое определение следующей заявки к выполнению на основании сроков подачи заявки и срочности техобслуживания (с 5 минут до 0,5-1 минуты);
Автоматическое составление отчета по выполненным заявкам (с 10 минут до 1 минуты).

Автоматизация этих операций позволит сократить время работы с одной заявкой на 14 минут, то есть в 2 раза.

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

Помимо сокращения времени, внедрение информационной системы должно позволить:

- заносить унифицированную информацию по заявкам;

- автоматически формировать различные аналитические отчеты;

- более грамотно планировать свою работу.

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

Следовательно, для улучшения бизнес-процессов предлагаются следующие мероприятия:

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

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

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

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

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

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

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

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

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

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

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

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

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

Основными понятиями объектно-ориентированного подхода являются объект и класс.

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

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

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

Объектный подход содержит набор моделей, связанных с понятием класса/объекта, объединяющего данные (состояние) и поведение. В настоящее время наиболее естественным является применение набора моделей, входящих в UML (универсальный язык моделирования), так как этот язык стандартизирован, широко используется и постоянно развивается. Распространенность языка UML можно объяснить тем, что он создан авторами трех самых известных в мире объектных методов (OMT, OOSE и Booch method). Прекращение "войны методов" и объединение ведущих специалистов привело к открытости и стандартной интерпретации моделей. Стандарт UML открыт для обсуждения и развивается при участии ведущих технологических фирм: Rational Software, Microsoft, Hewlett-Packard, Oracle, IBM, Platinum Technology и других. При этом следует понимать, что основным направлением объектного подхода является анализ бизнес-операций.

Объектно-ориентированный подход обладает следующими преимуществами:

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

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

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

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

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

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

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

Наиболее популярным средством объектно-ориентированного моделирования является язык UML и средство Rational Rose. Поэтому данное средство выбирается для моделирования.

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

Моделирование предметной области традиционно начинается с построения диаграммы вариантов использования (диаграммы прецедентов).

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

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

ассоциация между действующим лицом и вариантом использования;
обобщение между действующими лицами;
обобщение между вариантами использования;
зависимости (различных типов) между вариантами использования [2].

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

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

На диаграмме выделены три действующих лица (актера):

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

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

- Начальник IT-отдела получает и анализирует отчеты по работе отдела для принятия решений по дальнейшей работе.

В соответствии с действиями актеров, выделены следующие прецеденты:

- Регистрация заявки. Этот прецедент может вызвать как актер «Сотрудник предприятия», так и актер «Сотрудник IT-отдела». Поведение системы в обоих случаях одинаковое. Заявка регистрируется в системе и попадает в базу заявок.

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

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

- Формирование отчетов. Может использоваться как сотрудником IT-отдела, так и начальником IT-отдела. Актеры запрашивают определенный вид отчета, система предоставляет им отчет на основании данных из базы.

Диаграмма последовательности (sequence diagram) ‒ это способ описания поведения системы на основе указания последовательности передаваемых сообщений.

Диаграмма последовательности представляет собой это запись протокола конкретного сеанса работы системы (или фрагмента такого протокола). В объектно-ориентированном программировании самым существенным во время выполнения является пересылка сообщений между взаимодействующими объектами. Именно последовательность посылок сообщений отображается на данной диаграмме, отсюда и название[2].

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

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

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

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

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

Основными элементами диаграммы состояний являются «Состояние» и «Переход». Диаграмма состояний имеет схожую семантику с диаграммой деятельности, только деятельность здесь заменена состоянием, переходы символизируют действия. Таким образом, если для диаграммы деятельности отличие между понятиями «Деятельность» и «Действие» заключается в возможности дальнейшей декомпозиции, то на диаграмме состояний деятельность символизирует состояние, в котором объект находится продолжительное количество времени, в то время как действие моментально [2].

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

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

Диаграмма состояний рассматривается с точки зрения основного действующего лица системы – сотрудника IT-отдела.

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

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

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

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

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

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

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

Узел объединения имеет два и более входящих узла и один исходящий. Узлы решения объединения аналогичны логическому выражению «строгое или», т.е. для узла объединения - только при выполнении того или иного действия осуществляется переход к следующему узлу управления. Соответственно для узла решения – только при выполнении того или иного условия становится доступна возможность перехода к одному из следующих действий [3].

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

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

Порядок действий в соответствии с диаграммой следующий:

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

Сотрудник IT-отдела регистрирует заявку.

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

Информационная система определяет следующую заявку.

Сотрудник IT-отдела регистрирует выполнение заявки.

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

Диаграмма классов (class diagram) ‒ основной способ описания структуры системы.

На диаграмме классов применяется один основной тип сущностей: классы (включая многочисленные частные случаи классов: интерфейсы, примитивные типы, классы-ассоциации и многие другие), между которыми устанавливаются следующие основные типы отношений:

ассоциация между классами (с множеством дополнительных подробностей);
обобщение между классами;
зависимости (различных типов) между классами и между классами и интерфейсами [2].

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

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

Для системы выделены следующие классы:

- Управляющий класс «Инф. система», который управляет остальными классами системы.

-Граничный класс «Подсистема регистрации», который отвечает за регистрацию заявки в системе.

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

- Управляющий класс «Подсистема планирования», который отвечает за формирование плана выполнения заявок и определяет следующую заявку к исполнению.

- Управляющий класс «Подсистема формирования отчетов», который отвечает за формирование отчетов по запросу пользователя.

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

- Класс-сущность «Оборудование», хранящий информацию об оборудовании, нуждающемся в техническом обслуживании.

- Класс-сущность «Сотрудники», хранящий информацию о сотрудниках предприятия.

- Класс-сущность «Сотрудники IT», хранящий информацию о сотрудниках IT-отдела.

Для каждого класса определены атрибуты и методы (таблицы 1-12).

Таблица 1

Атрибуты класса «Подсистема планирования»

Атрибут	Описание	Тип данных
Заявка	Следующая заявка на выполнение	Класс Заявки

Таблица 2

Методы класса «Подсистема планирования»

Метод	Описание
Получить заявку на исполнение	Определяет следующую заявку на выполнение путем построения графика исполнения заявок

Таблица 3

Атрибуты класса «Подсистема регистрации»

Атрибут	Описание	Тип данных
Заявка	Регистрируемая заявка на исполнение	Класс Заявки

Таблица 4

Методы класса «Подсистема регистрации»

Метод	Описание
Зарегистрировать заявку	Записывает в базу заявку

Таблица 5

Атрибуты класса «Подсистема сбора результатов»

Атрибут	Описание	Тип данных
Заявка	Выполненная заявка	Класс Заявки
Сотрудник IT	Сотрудник, исполнивший заявку	Класс Сотрудники IT
Дата выполнения	Дата исполнения заявки	Дата
Результат	Результат исполнения заявки	Строка

Таблица 6

Методы класса «Подсистема сбора результатов»

Метод	Описание
Зарегистрировать исполнение заявки	Находит в базе заявку и дополняет ее информацией о выполнении

Таблица 7

Атрибуты класса «Подсистема формирования отчетов»

Атрибут	Описание	Тип данных
Начало периода	Начало отчетного периода	Дата
Окончание периода	Окончание отчетного периода	Дата

Таблица 8

Методы класса «Подсистема формирования отчетов»

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

Таблица 9

Атрибуты класса «Сотрудники IT»

Атрибут	Описание	Тип данных
ФИО	ФИО сотрудника	Строка

Таблица 10

Атрибуты класса «Сотрудники»

Атрибут	Описание	Тип данных
ФИО	ФИО сотрудника	Строка
Подразделение	Подразделение, где работает сотрудник	Строка

Таблица 11

Атрибуты класса «Оборудование»

Атрибут	Описание	Тип данных
Инв.Номер	Инвентарный номер оборудования	Целое
Тип оборудования	Тип оборудования (Принтер, монитор и т.д.)	Строка
Ответственный	Лицо, ответственное за оборудование	Класс Сотрудники

Таблица 12

Атрибуты класса «Оборудование»

Атрибут	Описание	Тип данных
Номер заявки	Номер заявки	Целое
Дата заявки	Дата подачи заявки	Дата
Сотрудник	Сотрудник, подавший заявку	Класс Сотрудники
Срочность	Срочность заявки: может быть выражена числом, например: 1 – срочная, 2 – не срочная	Целое
Диагноз	Результат предварительной диагностики или диагноз со слов сотрудника	Строка
Дата выполнения	Дата исполнения заявки	Дата
Результат	Результат исполнения заявки	Строка

Заключение

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

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

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

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

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

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

Во второй главе было выбрано средство для проектирования – язык UML. Были разработаны следующие виды диаграмм:

- диаграмма вариантов использования;

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

- диаграмма состояния;

- диаграмма деятельности;

- диаграмма классов.

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

Таким образом, поставленная цель достигнута.

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

Грекул, В. И. Проектирование информационных систем : учебник и практикум для академического бакалавриата / В. И. Грекул, Н. Л. Коровкина, Г. А. Левочкина. — М. : Издательство Юрайт, 2018. — 385 с. — (Серия : Бакалавр. Академический курс)
Новиков Ф.А., Иванов Д.Ю. ‒ Моделирование на UML. Теория, практика, видеокурс. ‒ СПб.: Профессиональная литература, Наука и Техника, 2010
Леоненков А.В. Самоучитель UML 2. СПб.: БХВ-Петербург, 2007. — 576 с.