Размещено на http://www.allbest.ru/



Оглавление

автоматизация предметный диаграмма технический

Введение

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

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

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

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

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

Диаграмма вариантов использования

Диаграмма состояний

Диаграмма классов

Заключение

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



Введение

Язык 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	Клиент должен иметь возможность подать заявку на ремонт.	Клиент	Оформление заявки
2	Клиент должен быть зарегистрирован в системе, чтобы записаться.	Клиент	Регистрация клиентов
3	Клиент должен иметь возможность отменить заявку на любом этапе оформления, пока он не подтвердил его.	Клиент	Оформление заявки
4	Персонал сервисного центра должен получить заявку для ее дальнейшего выполнения.	Персонал Сервисного центра	Оформление заявки
5	Клиент должен иметь возможность посмотреть список доступных услуг.	Клиент	Информация об услугах
6	Клиент должен иметь возможность получить информацию по состоянию его заявки.	Клиент	Информация о состоянии заявки
7	Персонал Салона красоты должен иметь возможность отказать клиенту в ремонте.	Персонал Сервисного центра	Проверка техники
8	Клиент должен получить окончательный сумму заявки с отчетом о работах и сумме на запчасти в печатном виде.	Клиент Бухгалтер	Конец обслуживания клиента
9	Персонал Салона красоты должен иметь возможность ввести данные о выполненной заявке (номера услуг, стоимость и т.д.) для формирования окончательного счета.	Персонал Сервисного центра	Конец обслуживания клиента



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

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

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

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

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

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

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

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

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

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

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

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

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

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



Рис. 2 Диаграмма деятельности системы



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

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

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

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



Диаграмма вариантов использования

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

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

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

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

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

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

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

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

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

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

Для создания модели взаимодействий сначала определим действующих лиц или актеров.

Для приложения действующими лицами будут Приемщик, Клиент, Бухгалтер.

Варианты работы Сервисного центра (см. рис. 3): 1) Принять технику - Приемщик принимает у клиента технику в ремонт. 2) Определение неисправности - Выполняется проверка, возможно ли исправить данный дефект силами Сервисного центра и определить; какие для этого потребуются запчасти 3)Проверить наличие запчастей -проверка наличия на складе нужных запчастей, определение недостающего количества 4) Заказ запчастей - заказ необходимого количества запчастей и расходных материалов; 5) Оформление заявки - оформление заявки на техническое обслуживание.

Определим начальное и конечное события для каждого варианта использования: 1) Принять технику- Начальное событие - Приемщик принимает у клиента технику в ремонт. Конечное событие - Определение неисправности 2) Определение неисправности - Начальное событие - Выполняется проверка, возможно ли исправить данный дефект силами Сервисного центра и определить; какие для этого потребуются запчасти; Конечные события - если техника подлежит ремонту - определение запчастей, если нет - отказ; 3) Проверить наличие запчастей -Начальное событие - проверка наличия на складе нужных запчастей, конечное событие - заказ запчастей; 4) Заказ запчастей - начальное событие - заказ необходимых запчастей, конечное событие - получение запчастей; 5) Оформление заявки - начальное событие - согласование стоимости ремонта - конечное событие - оформление заявки.

Рис. 4 Диаграмма вариантов использования



Диаграмма состояний

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

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

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

Система может находиться в состояниях: Подлежит ремонту (техника подлежит ремонту), Ремонту не подлежит (Отказ в обслуживании0, Проверить наличие запчастей (Проверка наличия запчастей и расходных материалов), Оформить заявку (Оформление заявки).

Рис. 5 Диаграмма состояний



Диаграмма классов

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

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

Классы

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

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

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

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

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

Если необходимо явно указать к какому пакету относится тот или иной класс, то используется символ разделитель двойное двоеточие «::». Синтаксис строки имени класса в этом случае будет следующий: <Имя_пакета>::<Имя_класса>. Например, если определен пакет с именем «Банк», то класс «Счет» в этом банке может быть записан в виде: «Банк::Счет».

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

<квантор видимости><имя атрибута>[кратность]:

<тип атрибута> = <исходное значение>{строка-свойство}

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

· «+» обозначает атрибут с областью видимости типа общедоступный (public). Атрибут с этой областью видимости доступен или виден из любого другого класса пакета, в котором определена диаграмма;

· «#» обозначает атрибут с областью видимости типа защищенный (protected). Атрибут с этой областью видимости недоступен или невиден для всех классов, за исключением подклассов данного класса;

·

· «-» обозначает атрибут с областью видимости типа закрытый (private). Атрибут с этой областью видимости недоступен или невиден для всех классов без исключения.

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

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

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

[нижняя_граница1.. верхняя_граница1, нижняя_граница2.. верхняя_грашца2,..., нuжняя_гpaнuцak.. верхняя_границаk],

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

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

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

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

· Клиент

· Вид техники

· Техника

· Заявка

· Неисправности

· Материалы

· Запчасти

· Расходные материалы

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

Рис. 5 Диаграмма классов



Заключение

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

· диаграмма вариантов использования;

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

· диаграмма последовательности;

· диаграмма состояний;

· диаграмма классов

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



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

1. Кознов Д.В Языки визуального моделирования: проектирование и визуализация программного обеспечения. Учебное пособиеСПб.: Изд-во СПбГУ, 2004, 143 с

2. Буч Г., Якобсон А., Рамбо ДжUML 2.0СПб.: Питер, 2006, 735 с

3. UML 2.0 Infrastructure SpecificationMarca D.A., McGowan C.LSADT Structured Analysis and Design Technique McGraw-Hill, 1988

4. Якобсон А., Буч Г., Рамбо Дж Унифицированный процесс разработки програмСПб.: Питер, 2002, 492 с

5. Фаулер М., Скотт К UML. ОсновыСПб.: Символ, 2006, 184 с

6. Леоненков А.ВОбъектно-ориентированный анализ и проектирование с использованием UML и IBM Rational Rose
М.: Интернет-Университет Информационных Технологий; БИНОМ. Лаборатория знаний, 2006, 319 с

7. Павлинов А., Кознов Д., Перегудов А., Бугайченко Д., Казакова А., Чернятчик Р., Фесенко Т., Иванов А О средствах разработки проблемно-ориентированных визуальных языков. Сб. «Системное программирование», Вып. 2

8. Гамма Э., Хелм Р., Джонсон Р., Влиссидес ДжПриемы объектно-ориентированного проектированияИзд-во Питер, 2005, 368 с

Размещено на Allbest.ru