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

На диаграмме компонентов представлены основные компоненты проекта. Контроллеры и связанные с ними компоненты, аналогичные EditController, не представлены. Классы сущности и связанные с ними компоненты, аналогичные Users, не представлены (см. рисунок 3.1.4.1).

Рисунок 3.1.4.1 – Диаграмма компонентов социальной сети «В Общаге»

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

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

Рисунок 3.1.5.1 – Диаграмма развёртывания социальной сети «В Общаге»

3.2 Описание применения паттернов проектирования

Применение паттернов проектирования GoF Singleton и Template Method было уже описано в 3.1.3. Также применялся паттерн проектирования GoF MVС. Для реализации паттерна MVC были созданы следующие компоненты: View (представление) – страницы jsp, Controller – классы-контроллеры, Model – классы, заканчивающиеся на Service, в которых сосредоточена бизнес-логика, и вызываются удалённые методы, в которых сосредоточена бизнес-логика. Применив этот паттерн, можно изменить классы, заканчивающиеся на Service, без изменения представления. Также можно создать, кроме представления станицы jsp, другие представления. Например, представления на основе jFrame или представления для мобильных телефонов. [6]

Применялись также архитектурные паттерны проектирования. Типовое решение MVC уже описано. Также применялось типовое решение шлюз таблицы данных. Для доступа к данным не нужно писать SQL-запросов, а можно получать данные из таблиц и записывать данные в таблицы, используя сессионные бины для таблиц сущностей (см. рисунок 3.1.3.1) [8].

3.3 Обоснование выбора технологии клиентского приложения

Выбор технологии и их обоснование описано в разделе 2 в обзоре методов решения поставленных задач. Более подробное описание технологий клиентского приложения представлено в разделе 5.

4 Информационная модель системы социальной сети «в общаге» и её описание

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

Рисунок 4.1 – Логический уровень представления модели

Рисунок 4.2 – Физический уровень представления модели

Экземпляр сущности users содержит информацию о конкретном пользователе. Сущность messages используется для хранения сообщений. Поле UserName – это UserName пользователя, отправившего сообщение. idReceiver – UserName пользователя, которому сообщение было отправлено. Сущность usersPhotos используется для хранения фотографий пользователя. Сущность Authorities хранит информацию о роле пользователе. Например, ROLE_USER или ROLE_ADMIN. Поля UserName и authority в данном приложении должны иметь именно такие имена и типы данных, потому что в приложении используется фреймворк Spring Security. Более подробно об этом описано в разделе 5. Скрипт генерации базы данных приведён в приложении В.

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

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

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

Т.к. все сущности спроектированной базы данных находятся в третьей нормальной форме, то информационная модель проекта соответствует вышеперечисленным требованиям, следовательно, находится в третьей нормальной форме. [9]