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

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

Содержание:

Введение

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

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

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

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

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

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

Цель курсовой работы – моделирование предметной области «Управление заявками на техническое обслуживание»

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

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

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

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

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

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

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

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

Рисунок 1 –Обобщенная организационная структура предприятия

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

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

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

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

Рисунок 2 - Схема документооборота

Трудозатраты на осуществление документооборота процесса складываются из затрат специалистов ИТ-отдела на прием и распределение заявок, обработку заявок и составление отчетов о проделанной работе. Характеристика документооборота по существующей схеме представлена в таблице 1.

Таблица 1 - Характеристика формирования документооборота

Характеристика	Заявка	Отчет о проделанной работе
Количество документов в год, шт.	1	1
Количество символов в документе, шт.	1000	3000
Частота возникновения в год	10 000	12
Трудозатраты на обработку в год, чел-час	7300	3000

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

Таблица 2 - Характеристика формирования документооборота после автоматизации

Характеристика	Заявка	Отчет о проделанной работе
Количество документов в год, шт.	1	5
Количество символов в документе, шт.	1000	3000
Частота возникновения в год	10 000	12
Трудозатраты на обработку в год, чел-час	6800	1000

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

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

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

Характеристика справочников представлена в таблице 3.

Таблица 3 - Характеристика справочников

Характеристика	Должность	Вид проблемы	Отдел
Ответственный за ведение	Администратор системы
Объем справочника в записях	2	20	4
Частота актуализации	По мере необходимости
Объем актуализации	1-10 записей
Реквизитный состав	Наименование	Наименование	Наименование
Характеристика	Сотрудник	Статус заявки
Ответственный за ведение	Администратор системы
Объем справочника в записях	100	10
Частота актуализации	По мере необходимости
Объем актуализации	1-10 записей
Реквизитный состав	Фамилия	Наименование
	Имя
	Отчество
	Телефон

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

ФИО сотрудника.
Отдел.
Дата заявки.
Описание проблемы.

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

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

Отчет по анализу заявок содержит следующие данные:

Вид проблемы.
Количество заявок по каждому виду проблемы.

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

ФИО сотрудника.
Дата начала.
Дата окончания.
Количество заявок.
Среднее время обработки заявки.

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

Вид проблемы.
Статус.
Заявка.
Сотрудник.
Стадия.

Характеристика таблиц с результатной информацией представлена в таблице 4.

Таблица 4 - Характеристика таблиц с результатной информацией

Наименование таблицы	Наименование поля
Статус	Наименование
Наименование таблицы	Наименование поля
Заявка	Номер
Заявка	Дата
Вид проблемы	Наименование
Сотрудник	Фамилия
	Имя
	Отчество
Стадия	Наименование

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

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

Существует несколько видов стратегий автоматизации:

кусочная (хаотичная) автоматизация;
автоматизация по участкам;
автоматизация по направлениям;
комплексная автоматизация.

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

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

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

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

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

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

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

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

ФИО сотрудника, оставившего заявку.
Должность.
Отдел.
Вид проблемы.
Описание проблемы.

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

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

Номер заявки.
Дата.
Время принятия.
Статус заявки.
Время решения.
Вид проблемы.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Rational Rose
Microsoft Visio
Sybase PowerDesigner
Case Complete
Artiso Visual Case

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

1 Rational Rose

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

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

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

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

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

2 Microsoft Visio

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

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

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

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

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

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

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

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

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

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

Программный продукт/

Критерии

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

Экспорт

Удобство пользования

Минимизация рутины

Rational Rose

Microsoft Visio

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

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

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

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

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

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

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

Системный администратор.
Руководитель ИТ-отдела.
Сотрудник организации.
Администратор системы.

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

Таблица 6 - Разграничение прав доступа

Раздел	Справочники	Заявки	Отчеты
Руководитель ИТ-отдела	Просмотр, редактирование	Создание, редактирование	Просмотр
Системный администратор	Просмотр, редактирование	Редактирование	Просмотр
Сотрудник организации	-	Создание	-
Администратор системы	Создание, редактирование, удаление	Создание, редактирование, удаление	Просмотр

Диаграмма прецедентов (англ. Usecase diagram, диаграмма вариантов использования) — диаграмма, на которой отражены отношения, существующие между актерами и прецедентами [7].

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

При работе с вариантами использования важно помнить несколько простых правил:

каждый вариант использования относится как минимум к одному действующему лицу,
каждый вариант использования имеет инициатора,
каждый вариант использования приводит к соответствующему результату (результату с «бизнес-значением») [8].

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

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

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

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

Рисунок 8- Диаграмма последовательности для варианта использования ввод и изменение информации об отделах

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

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

Основные бизнес-процессы рассмотренные в курсовой работе, Управление заявками на техническое обслуживание:

Создание заявки на техническое обслуживание,
Редактирование заявки
удаление заявки,
Формирования отчетов.

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

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

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

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

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

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