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

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

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

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

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

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

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

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

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

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

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

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

---

Затем составим список разделов системы и опишем права доступа для каждой категории пользователей. Права доступа представлены в таблице 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 были разработаны следующие схемы:

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

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

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

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

1. Буч, Г. Объектно-ориентированный анализ и проектирование с примерами приложений на С++ / Г. Буч. – М.: Бином, 2016. – 560 с.
2. Буч, Г. Язык UML. Руководство пользователя / Г. Буч, Дж. Рамбо, А. Якобсон. - СПб.: Питер, 2014. - 432 с.
3. Вендров, А.М. CASE-технологии. Современные методы и средства проектирования информационных систем / А.М. Вендров. – М. : Финансы и статистика, 1998. – 176 с.
4. Википедия. [Электронный ресурс] ru.wikipedia.org. Режим свободного доступа. Дата обращения 29.03.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 с.

---