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

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

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

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

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

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

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

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

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

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

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

---

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

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

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

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

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

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

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

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

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

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

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

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

---

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

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

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

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

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

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

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

---

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

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

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

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

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

Рисунок 4 – Логотип языка 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 (Рисунок 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 диаграмм. Есть ли в нём функциональность для создания зависимости между объектами разных типов, возможность отслеживать изменения.

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

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

---