Диплом (1210331), страница 3

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

Текст из файла (страница 3)

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

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

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

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

Также существует начальное и конечное состояние.

Начальное состояние (чёрная точка) – это состояние, в котором находится экземпляр сущности после своего создания или, перейдя в составное состояние. Из начального состояния исходят только переходы.

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

Переход (отображается в виде однонаправленной ассоциации) - это смена состояний. Если переход сработал, то состояния сменилось. Переходы бывают трех видов: триггерный (переход по наступлению какого – либо события), не триггерный и рефлексивным (переход направлен в то же состояние, из которого он выходит).

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

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

Диаграмма будет состоять из одной контекстной и двух диаграмм автоматов для отдельных объектов.

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

На рисунке 2.8 представлена контекстная диаграмма автоматов.

Условные обозначения на диаграмме:

• CloseApp() – закрытие приложения;

• SelectItem() – вход в систему.

Рисунок 2.8 – Контекстная диаграмма автоматов

Далее будут пробно рассмотрены состояния «Подсистема работника» и «Подсистема менеджера».

Диаграмма декомпозиции «Подсистема работник» представлена на рисунке 2.9. При авторизации в системе как «Работник», будут доступны следующие функции:

• просмотр акций;

• просмотр заказов;

• бронирование заказа;

• просмотр новостей;

• и т.д.

Рисунок 2.9 – «Подсистема работник»

Диаграмма декомпозиции «Подсистема менеджера» представлена на рисунке 2.10. При авторизации в системе как «Менеджер», будут доступны следующие функции:

• оформление заказа клиента;

• просмотр и редактирование действующих акций и скидок;

• внесение данных о заказе;

• внесение оплаты;

• и т.д.

Рисунок 2.10 – «Подсистема менеджер»

2.2.4 Диаграмма классов анализа

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

Фундаментальными понятиями объектно-ориентированного подхода являются понятия объекта и класса, которые представляются абстракциями реальной или воображаемой сущности (набора сущностей). Класс анализа – еще более абстрактная сущность, чем просто класс, представляет собой набор из одного или более классов. Таким образом, класс анализа – это укрупненная абстракция, которая на концептуальном уровне (без точного определения атрибутов и операций) описывает некоторый фрагмент системы.

На рисунке 2.11 приведена диаграмма классов анализа для данной системы.

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

Рисунок 2.11 – Диаграмма классов анализа

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

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

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

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

На рисунке 2.12 изображена диаграмма последовательности для процесса «Оформления заказа». Пользователь выбирает пункт меню оформить заказ. Ему открывается форма с заказом. На этой форме пользователь выбирает шоу, дату и время, которые ему нужны. Система проверит на занятость данные параметры. Если один из параметров занят, то система выведет на экран сообщение: «Выберите другие параметры». Если же все параметры свободны, то пользователю предлагается выбрать способ оплаты на отдельной форме. После выбора способа, откроется форма, в которой пользователь должен указать свои контактные данные и подтвердить заказ. Система сохранит данные о заказе на сервере ИС. После заказа менеджер отправит реквизиты компании клиенту.

Рисунок 2.12 – Диаграмма последовательности «Оформить заказ»

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

Рисунок 2.13 – Диаграмма последовательности «Бронирование заказа»

2.2.6 Диаграммы коммуникаций

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

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

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

На рисунке 2.14 изображена диаграмма коммуникации «Оформление заказа». На данной диаграмме подробное описание (в том числе и последовательность) того, что пользователь делает при выборе пункта меню «Оформить заказ». Первым делом пользователь попадает на главную форму и переходит уже непосредственно к оформлению заказа в соответствующую форму. Затем он выбирает параметры (шоу, дату, время) заказа, если же какой из параметров уже занят, то выдается сообщение на экране о выборе других параметров, если же все свободно, то переходит к форме «Способ оплаты», на данной форме указывает контактные данные и переходит на форму «Подтверждение заказа». Созданный пользователем заказ сохраняется на сервере нашей информационной системы.

Рисунок 2.14 – Диаграмма коммуникации «Оформление заказа»

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

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

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

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

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

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

Рисунок 2.15 – Диаграмма деятельности «Оформление заказа»

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

Рисунок 2.16 – Диаграмма деятельности в виде блок-схемы «Поиск шоу»

2.2.8 Диаграммы компонентов

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

При разработке диаграмм компонентов преследуются цели:

• спецификация общей структуры исходного кода системы;

• спецификация исполнимого варианта системы.

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

Диаграмма компонентов разрабатывается для следующих целей:

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

• спецификации исполняемого варианта программной системы;

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

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

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

Характеристики

Список файлов ВКР