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

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. Диаграмма последовательности

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

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

---