3 Модели представления «социальной сети» и их

ОПИСАНИЕ, ОПИСАНИЕ ПРИМЕНЕНИЯ ПАТТЕРНОВ

ПРОЕКТИРОВАНИЯ, ОБОСНОВАНИЕ ВЫБОРА

ТЕХНОЛОГИИ КЛИЕНТСКОГО ПРИЛОЖЕНИЯ

3.1 Модели представления системы и их описание

Для данной системы была разработаны модели UML. Были построены диаграмма вариантов использования, диаграмма последовательности, диаграмма состояний, диаграмма классов, диаграмма развертывания, диаграмма компонентов. [5]

Диаграмма вариантов использования и её описание представлены выше (см. рисунок 2.1).

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

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

Рисунок 3.1.1.1 Диаграмма состояний объекта Name

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

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

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

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

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

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

AbstractFacade реализует паттерн проектирования GoF шаблонный метод. UserFacade и аналогичные классы – конкретные реализации абстрактного класса AbstractFacade (см. рисунок 3.1.3.1). [6]

Рисунок 3.1.3.1 – Диаграмма классов-бинов Users

Рассмотрим классы, которые есть только на клиенте.

Классы, заканчивающиеся на Controller, являются контроллерами. Они нужны для связи представления(jsp) и бизнес-логики, которая, как правило, сосредоточена в классах, заканчивающихся на Service. Также бизнес-логика сосредоточена в классах, заканчивающихся на Controller, тогда, когда не требуется громоздких вычислений и сложных алгоритмов. Класс Name содержит поля пользователей. Он служит для того, чтоб на jsp, используя spring, можно было легко получать и вводить эти поля.

Класс MyContext служит для создания прописывания свойств Context, который служит для соединений клиента с сервером, используя JNDI. Т.к. свойства для соединений одинаковый, нет необходимости прописывать их много раз, а достаточно прописать один раз и сохранить в private поле класса, и последующие разы проверять на то, что свойства прописаны. Если свойства не прописаны, то их прописать. Конструктор этого класса вызвать нельзя, он объявлен с модификатором private. Есть доступ только к статической функции MyContext, которая возвращает объект типа Context с прописанными свойствами. Листинг класса в приложении Б. Этот класс реализует паттерн Одиночка (см. рисунок 3.1.3.2). [6]

Рисунок 3.1.3.2 – Диаграмма классов-контроллеров, сервлетов, Name, MyContext

Для работы страницы администратора используется фреймворк JavaServer Faces (JSF). Функции класса UsersJPAController аналогичны функциям класса UsersFacade. Остальные классы вспомогательные для этого класса, а также для вывода данных на страницу jsp (см. рисунок 3.1.3.3). [7]

Рисунок 3.1.3.3 – Диаграмма классов, которые используются для работы страницы администратора