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

Введение

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

UML содержит стандартный набор диаграмм и нотаций самых разнообразных видов.

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

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

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

В UML выделяют следующие типы диаграмм:

– диаграммы вариантов использования(usecase diagrams

– диаграммы классов(class diagrams)

– диаграммы поведения системы(behavior diagrams);

– диаграммы взаимодействия(interaction diagrams)

– диаграммы состояний(statechart diagrams

– диаграммы деятельностей(activity diagrams)


- диаграммы последовательности.

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

Описание предметной области

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

- Создание комплексных информационных систем;

- Обслуживание парка ПК;

- Продажа программного обеспечения;

- Проектирование и монтаж локальных сетей;

- Информационная защита данных;

- Разработка фирменного стиля.

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

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

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

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

В ходе изучения деятельности организации так же были выявлены

следующие проблемы:

- В системе отсутствует функция оперативного оповещения сотрудников и руководителя о «горящей» или даже просроченной заявки.

Сотрудник видит все свои заявки, но без напоминания может пропустить срок их исполнения;

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

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

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

Диаграмма прецедентов

Перед построением диаграммы прецедентов (рис. 1) составим таблицу распределения требований по субъектам и прецедентам:

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

Сценарий (scenario) – это последовательность шагов, описывающих взаимодействие пользователя и системы.

В терминах прецедента пользователи называются актерами. Актер (actor) представляет собой некую роль, которую пользователь играет по отношению к системе. Актерами могут быть пользователь, торговый представитель пользователя, менеджер по продажам и товаровед.

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

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

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

Можно выделить такие цели создания диаграмм прецедентов:

определение границы и контекста моделируемой предметной области на ранних этапах проектирования;

формирование общих требований к поведению проектируемой системы;

разработка концептуальной модели системы для ее последующей детализации;

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

Таблица 1 – Распределение требований по субъектам и прецедентам

Рис. 1 Диаграмма прецедентов

Диаграмма деятельности

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

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

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

В контексте языка UML деятельность (activity) представляет собой совокупность отдельных вычислений, выполняемых автоматом, приводящих к некоторому результату или действию (action). На диаграмме деятельности отображается логика и последовательность переходов от одной деятельности к другой, а внимание аналитика фокусируется на результатах. Результат деятельности может привести к изменению состояния системы или возвращению некоторого значения.

Состояние действия

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

Графически состояние действия изображается прямоугольником с закругленными углами Внутри этого изображения записывается выражение действия (action-expression), которое должно быть уникальным в пределах одной диаграммы деятельности.

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

Иногда возникает необходимость представить на диаграмме деятельности некоторое сложное действие, которое, в свою очередь, состоит из нескольких более простых действий. В этом случае можно использовать специальное обозначение состояния под-деятельности (subactivity state). Такое состояние является графом деятельности и обозначается специальной пиктограммой в правом нижнем углу символа состояния действия (рис. 6). Эта конструкция может применяться к любому элементу языка UML, который поддерживает вложенность своей структуры. При этом пиктограмма может быть дополнительно помечена типом вложенной структуры.