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

- выбор стратегии автоматизации:

- определение архитектуры;

- формирование бизнес-плана.

Различают следующие виды стратегий автоматизации:

- полная;

- по направлениям;

- по участкам;

- хаотичная.

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

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

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

Таким образом, в качестве стратегии автоматизации выбран проект автоматизации по участкам.

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

- покупка готового программного продукта;

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

- взять в аренду, существующую программную систему;

- самостоятельная разработка.

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

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

---

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

Моделирование предметной области включает в себя разработку в программной среде Rational Rose следующих схем предметной области управления заявками на техническое обслуживание:

1. диаграмма вариантов использования (диаграмма прецедентов)
2. диаграмма последовательности
3. диаграмма состояний
4. диаграмма деятельности
5. диаграмма классов

Диаграмма вариантов использования (диаграмма прецедентов) для рассматриваемой предметной области представлена на рис.1. Эта диаграмма в UML отражает отношения между акторами и прецедентами и позволяет описать систему на концептуальном уровне^[7].

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

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

Основными прецендентами в системе являются (рис.1):

- сделать заявку;

- уточнить заявку;

- оплатить услуги;

- планировать работу;

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

- фиксировать заявку;

- консультировать;

- выполнить работы;

- формировать счет.

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

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

В соответствии с диаграммой последовательности (рис.3), выполняются следующие преценденты.

1. Клиент делает заявку на сайте предприятия (активность 1).
2. Менеджер получает заявку на сайте предприятия (активность 2).
3. Менеджер уточняет заявку у Клиента. (активность 3).
4. Менеджер фиксирует заявку (активность 4).
5. Менеджер включает заявку в план работ (активность 5).
6. Специалист технического обслуживания получает план работ (активность 6).
7. Специалист технического обслуживания выполняет ремонт и консультации (активность 7).
8. Специалист технического обслуживания формирует счет (активность 8).
9. Специалист технического обслуживания фиксирует выполнение работ (активность 9).
10. Клиент выполняет оплату счета за предоставленные услуги технического обслуживания (активность 10).

---

После получения оплаты объект заявка перестает свое существование.

Для описания возможных последовательности состояний и переходов, которые в совокупности характеризуют поведение элемента модели в течение его жизненного цикла^[8], используем диаграмму состояний (рис.4).

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

Начало работы системы управления заявками на техническое обслуживание вызывает «Ожидание заявки» (рис.3). При отсутствии заявок система перейдет в конечное состояние.

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

После фиксирования заявки система переходит в состояние «Ожидание включения в план работ». После наступления события «Работа в плане» система находится в состоянии «Проверка типа обслуживания».

В случае определения типа «Консультация» выполняется состояние «Консультирование клиента». После наступления события «Консультация завершена» система переходит в состояние «Ожидание заявки».

В случае определения типа «Технические работы» выполняется состояние «Обработка заявки на техническое обслуживания». Наступление события «Работа выполнена» переводит в состояние «Ожидание окончания работ», а после выполнения события «Работа закончена» переводится в состояние «Ожидание счета».

При формировании счета система переходит в состоянии «Ожидание оплаты». При наступлении события «Квитанция получена» система производит «Фиксирование выполнения». Из этого состояния выводит событие «Выполнение зафиксировано» и переводит в состояние «Ожидание заявки».

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

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

Как видно на рис.4, начало работы происходит на сайте предприятия, путем осуществления приема заявки, которое в свою очередь характеризуется состоянием «Заказ получен». После этого Менеджер выполняет активности: «Уточнить заявку» и «Зафиксировать заявку». Выполнение этих активностей характеризуется состоянием «Заявка зафиксирована». После этого выполняется активность «Внести в план работ», который формируется для Специалиста технического обслуживания. Выполнение этой активности характеризуется состоянием «План работ (создан)».

---

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

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

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

Описания основных атрибутов и методов классов представлены в таблицах 2–3.

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

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

№ п/п	Класс	Атрибуты	Тип	Назначение
1	Должность	Наименование	Символьное	Для обозначения должности сотрудника предприятия
2	Сотрудник	Фамилия	Символьное	Фамилия сотрудника
3	Сотрудник	Имя	Символьное	Имя сотрудника
4	Сотрудник	Дата рождения	Символьное	Дата рождения сотрудника
5	Счет	№ счета	Целое	Номер выписанного счета специалистом технического обслуживания
6	Счет	Сумма	Целое	Сумма, выставленная для оплаты клиенту
7	Счет	дата	Дата/время	Дата формирования счета клиенту
8	Клиенты	Фамилия	Символьное	Фамилия клиента
9	Клиенты	Имя	Символьное	Имя Клиента
10	Клиенты	№ договора	Целое	№ договора о предоставлении услуг
11	Клиенты	Адрес	Символьное	Адрес нахождения клиента
12	Заявка	Номер	Целое	Номер заявки в системе
13	Заявка	Описание	Символьное	Описание технической неисправности
14	Заявка	Дата/время	Дата/время	Дата /время формирования заявки
15	Заявка	флаг фиксирования	Логическое	Флаг фиксирования заявки в системе
16	Заявка	флаг выполнения	Логическое	Флаг фиксирования выполнения заявки в системе
17	План работы	Дата	Дата/время	Текущая дата выполнения заявки
18	План работы	Номер заявки	Целое	Номер заявки в системе
19	План работы	время	Дата/время	Время на которое спланировано выполнение заявки
20	План работы	Сотрудник	Символьное	Сотрудник службы технического обслуживания, который будет выполнять заявку
21	План работы	Примечание	Символьное	Примечание к выполнению заявки
22	План работы	№ пункта	Целое	№ пункта плана работы сотрудника

---

Таблица 2 (Продолжение). Основные атрибуты классов для управления заявками на техническое обслуживание

№ п/п	Класс	Атрибуты	Тип	Назначение
23	Выполнение	№ заявки	Целое	Номер заявки в системе управления
24	Выполнение	Дата/время	Дата /время	Дата /время выполнения заявки
25	Выполнение	Примечание	Символьное	Примечание к выполнению заявки
26	Квитанция	№	Целое	№ квитанции об оплате
27	Квитанция	Дата	Дата/время	Дата совершения транзакции
28	Квитанция	Сумма	Целое	Сумма, оплаченная по квитанции
29	Квитанция	№ заявки	Целое	№ заявки, согласно которой осуществлялся платеж
30	Квитанция	клиент	Символьное	Клиент совершивший оплату
31	Вид заявки	тип	Перечисляемый	Перечисляемый тип заявки может принимать значение «Консультация», «Техническое обслуживание»

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

№ п/п	Класс	Метод	Назначение
1	Должность	AddDolgnost	Добавить должность сотрудника
2	Должность	Remove()	Модифицировать должность
3	Должность	Delete()	Удалить должность
4	Сотрудник	AddSotrudnyk	Добавить сотрудника
5	Сотрудник	RemoveSotrudnyk	Удалить сотрудника
6	Сотрудник	GetSotrudnyk	Выдать информацию о сотруднике
7	Сотрудник	GetAllSotrudnyk	Выдать информацию о всех сотрудниках
8	Счет	add()	Создать счет
9	Счет	modify()	Модифицировать счет
10	Счет	delete()	Удалить счет
11	Клиент	add()	Создать клиента
12	Клиент	modify()	Модифицировать сведения о клиентах

---