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

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

Рисунок 3.3 – Диаграмма декомпозиции «Просмотр документации»

Далее идут две диаграммы декомпозиции «Просмотр тарифов» (рисунок 3.4) и «Просмотр услуг» (рисунок 3.5). Здесь участвует все также один актер «Пользователь». Просмотреть тарифы или услуги он сможет, выбрав соответствующую вкладку на сайте. Ему будет предоставлена информация по тарифам перевозок из Москвы, Санкт-Петербурга и Владивостока.

Рисунок 3.4 – Диаграмма декомпозиции «Просмотр тарифов»

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

Рисунок 3.5 – Диаграмма декомпозиции «Просмотр услуг»

1. Диаграммы автоматов

После создания одной или нескольких диаграмм вариантов использования системный аналитик с заказчиком определяют приоритетность проработки вариантов использования и детализируют их. Главная цель данной процедуры – поиск ответа на вопрос: «В процессе какого поведения система обеспечит необходимую функциональность?».

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

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

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

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

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

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

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

А именно инициализация подсистемы «Пользователь» и инициализация «Администратор». Инициализация подсистемы пользователь происходит автоматически как юзер заходит на сайт. Ему не надо для этого регистрироваться, так как функционал сайта позволяет этого не делать.

Для авторизации администратора нужно добавить в URL-строке после домена сайта /manager. Тогда откроется новое окно с запросом на введение логина и пароля. После правильного ввода логина и пароля, открывается панель администратора MODX.

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

Далее будут подробно рассмотрены диаграммы декомпозиции «Инициализация подсистемы администратор» и «Инициализация подсистемы пользователь».

Диаграмма декомпозиции «Инициализация подсистемы администратор» представлена на рисунке 3.7. Что бы попасть в подсистему администратора необходимо в URL-сроке в браузере добавить /manager. При авторизации в системе как «Администратор», будут доступны следующие функции:

• создание, редактирование, обновление содержимого;

• редактирование, создание html – страниц;

• создание web-ресурсов;

• создание web-элементов (чанки, шаблоны, плагины и т.д.);

• управление правами пользователей;

• создание и просмотр отчетов.

Рисунок 3.7 – Диаграмма декомпозиции «Инициализация подсистемы администратор»

Далее идет диаграмма декомпозиции «Инициализация подсистемы пользователь» (рисунок 3.8). Пользователем становиться любой человек посетивший сайт. Он может выполнять некоторые действия на сайте, такие как:

• заполнение и отправка заявки на перевозку;

• просмотр услуг компании;

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

• просмотр тарифов;

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

• звонок оператору компании;

• скачивать документацию.

Рисунок 3.8 – Диаграмма декомпозиции «Инициализация подсистемы пользователь»

1. Модель анализа

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

Построение этой модели необходимо:

• для выявления внутренней архитектуры (определения подсистем и основных классов);

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

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

При разработке модели анализа рекомендуется построить следующие диаграммы (основные артефакты):

• классов анализа;

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

• коммуникации.

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

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

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

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

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

Существует два вида:

• статический вид диаграммы рассматривает логические взаимосвязи классов между собой;

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

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

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

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

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

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

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

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

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

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

Рисунок 3.10 – Диаграмма последовательности «Подача заявки»

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

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

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

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

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

Рисунок 3.11 – Диаграмма коммуникаций «Подача заявки»

1. Модель проектирования

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

Построение этой модели необходимо:

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

• уточнения требований;

• определения детализированных алгоритмов работы системы в целом и ее отдельных элементов.

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

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

Для описания поведения системы и ее отдельных элементов (поведенческих моделей) в UML предусмотрено четыре вида диаграмм. Три из них диаграммы автоматов, последовательности и коммуникации.

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

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