Идентификация архитектурных решений и механизмов

В процессе проектирования определяются детали реализации архитектурных механизмов, обозначенных в процессе анализа. Поскольку практически все механизмы — это некоторые типовые решения (образцы), они документируются в проекте (модели) с помощью кооперации со стереотипом «mechanism», при этом структурная часть механизма описывается с помощью диаграмм классов, а поведение — с помощью диаграмм взаимодействия.

В качестве примера рассмотрим механизм хранения данных в БД. Предположим, что в проекте системы регистрации в качест­ве языка программирования используется.Java. Поскольку суще­ствующая система каталога курсов функционирует на основе ре­ляционной СУБД, таким механизмом, обеспечивающим доступ к этой внешней базе данных, должен быть JDBC (Java Database Connectivity). На рис. 4.18 показана диаграмма классов образца, описывающего JDBC.

Рис. 4.18. Диаграмма классов кооперации, описывающей JDBC

Все классы, изображенные на данной диаграмме, можно раз­делить на две группы:

· Собственно классы JDBC (DriverManager, Connection, Statement, ResultSet), которые отвечают за реализацию зап­роса к БД (выполнение оператора SQL). Эти классы при­надлежат к архитектурному уровню Middleware и входят в соответствующий пакет.

· Классы со стереотипом <<role>>, являющиеся «заполните­лями» (placeholders) реальных классов, создаваемых разра­ботчиком системы. Они выполняют следующее назначение:

DBClass — отвечает за чтение и запись данных. Класс такого типа создается для каждого устойчивого (persistent) класса, или, иначе говоря, класса, данные которого будут храниться в некото­рой БД (в данном случае — в таблицах реляционной БД). Напри­мер, в системе регистрации на курсы в процессе анализа в соот­ветствии с образцом Information Expert определено, что класс-сущность Course должен отвечать за сохранение информации об учебных курсах в базе данных. Однако при этом, как было сказа­но в данном образце, возникает проблема перегруженности клас­са лишними обязанностями, поскольку класс Course должен не­посредственно содержать вызовы сервисов JDBC. Разделение ос­новных функций системы на уровни (применение образца «Уровни») в данном случае означает, что обязанности взаимодей­ствия с БД выносятся из класса Course в класс DBCourse.

PersistencyClient — класс, запрашивающий создание, чтение, обновление или удаление данных.

PersistentClass — класс-сущность, объекты которого содержат необходимые данные.

PersistentClassList — список объектов, являющихся результа­том запроса к БД — выполнения операции DBClass.read().

Выполнение операций, реализуемых механизмом JDBC (опе­раций класса DBClass), документируется с помощью диаграмм взаимодействия. Одна из таких диаграмм — кооперативная диаг­рамма, показывающая выполнение операции создания новых данных (create), приведена на рис. 4.19.

Из диаграммы на рис. 4.19 видно, что для создания новых данных (нового класса) объект PersistencyClient. запрашивает DBClass. DBClass создает новый объект PersistentClass и загружа­ет в него данные. Затем DBClass создает новый оператор SQL, ис­пользуя операцию createStatement() класса Connection. В резуль­тате выполнения этого оператора данные помещаются в БД.

Рис. 4.19. Диаграмма выполнения операции create