Курсовые - Система психологического тестирования

МОДЕЛИ ПРЕДСТАВЛЕНИЯ СИСТЕМЫ И ИХ ОПИСАНИЕ

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

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

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

Рассмотрим диаграмму данной системы (рисунок 3.1).

Рисунок 3.1 – Диаграмма вариантов использования

         Здесь в роли актёров выступают администратор и пользователь.

У администратора больше прав чем у пользователя, а именно:

  • Манипулировать данными тестов, а именно: удалять, добавлять и редактировать тесты.
  • Просматривать тесты.
  • Зарегистрироваться. Добавить нового администратора.
  • Авторизоваться.
  • Выйти из системы.

Другим актёром системы является пользователь. К ним относятся:

  • Пройти тест.
  • Редактировать профиль. Добавить более подробную информацию о себе.
  • Авторизоваться.
  • Зарегистрироваться.
  • Просмотреть тесты.

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

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

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

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

         Рассмотрим диаграмму последовательности процесса авторизации пользователя в системе (рисунок 3.3).

Рисунок 3.3 – Диаграмма последовательности процесса авторизации

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

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

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

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

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

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

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

         Рассмотрим диаграмму компонентов (рисунок 3.4).

Рисунок 3.4 – Диаграмма компонентов

         Диаграмма компонентов отображает файловую структуру всей информационной базы.

 

3.5 Диаграмма развёртывания

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

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

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

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

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

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

Рассмотрим диаграмму развертывания на рисунке 3.5.

Рисунок 3.5 – Диаграмма развёртывания

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

 

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

 

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

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

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

Операция есть функция или преобразование. Операция может иметь параметры и возвращать значения.

Виды связей:

  • ассоциация
  • агрегация
  • наследование.

Ассоциация (association) – представляет собой отношения между экземплярами классов.

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

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

Агрегация (aggregation) – это ассоциация типа «целое-часть». Агрегация в UML представляется виде прямой с ромбом на конце.

Ромб на связи указывает, какой класс является агрегирующим (т.е. «состоящим из»), — класс с противоположного конца — агрегированным (т.е. те самые «части»).

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

Важно понимать разницу между агрегацией и композицией: при агрегации объекты-части могут существовать сами по себе, а при композиции — нет. Пример агрегации: автомобиль—колесо, пример композиции: дом—комната.

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

Диаграмма класса представлена на рисунке 3.6.

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

Количество комментариев: 0

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