
- •9. Проектирование классов
- •9.1. Проектирование классов, скрывающих информацию
- •9.2. Проектирование операций классов
- •9.3. Классы абстрагирования данных
- •9.4. Классы интерфейса устройства
- •9.5. Классы, зависящие от состояния
- •9.6. Классы, скрывающие алгоритмы
- •9.7. Классы интерфейса пользователя
- •9.8. Классы бизнес-логики
- •9.9. Классы-обертки базы данных
- •9.10. Внутренние программные классы
- •9.11. Применение наследования при проектировании
- •9.12. Примеры наследования
- •9.13. Спецификация интерфейса класса
9.8. Классы бизнес-логики
Класс бизнес-логики определяет логику принятия решения при обработке запроса клиента, специфичную для данного приложения. Он предназначен для инкапсуляции бизнес-правил, которые способны изменяться независимо друг от друга. Обычно во время выполнения объект бизнес-логики обращается к различным сущностным объектам.
Примером такого класса может служить класс Менеджер Транзакций Снятия (рис.9.8), где инкапсулированы правила обработки запроса на снятие денег.
Рис.9.8. Пример класса бизнес-логики: а – аналитическая модель (диаграмма кооперации); б – проектная модель (диаграмма кооперации); в – проектная модель (диаграмма классов)
В нем есть операции инициализировать, снять, подтвердить, и отменить. Операция инициализировать вызывается на этапе инициализации, операция снять – для снятия денег со счета клиента, операция подтвердить – для подтверждения факта успешного проведения транзакции, а операция отменить – в случае, когда транзакция закончилась неудачно, в частности если банкомат не выдал наличные. При определении операций необходимо тщательно проанализировать диаграмму кооперации Банковский Сервер из аналитической модели (рис.9.8а) и описание последовательности сообщений, где приведены детальные сведения о каждом сообщении. По результатам такого анализа строится диаграмма кооперации для проектной модели (рис.9.86) и диаграмма классов (рис.9.8в).
9.9. Классы-обертки базы данных
В аналитической модели представлены сущностные классы, которые инкапсулируют данные. В ходе проектирования нужно решить, должна ли информация храниться в самом сущностном классе или же в базе данных. В первом случае применяются классы абстрагирования данных, которые инкапсулируют структуры данных, а во втором – классы-обертки базы данных, скрывающие детали реализации доступа к базе.
На сегодняшний день наиболее широко распространены реляционные базы данных, так что класс-обертка предоставляет объектно-ориентированный интерфейс к такой базе. При этом необходимо отобразить сущностные классы из статической модели на структуры базы данных.
Атрибуты сущностного класса становятся отношениями в базе, а операции доступа к атрибутам встраиваются в класс-обертку. Для отображения сущностных классов на отношения требуется систематический подход, поскольку отношения – это плоские структуры, а сущностные классы необязательно являются таковыми. Необходимо определить первичные ключи, а ассоциации, явно представленные в диаграмме классов, следует отобразить на внешние ключи.
Класс-обертка скрывает детали доступа к данным, хранящимся в таблицах базы, а значит, и все операторы языка SQL. Обычно один класс соотносится с одной таблицей, но возможны также классы-обертки и для представлений, то есть соединения двух или более таблиц.
Рис.9.9. Пример класса-обертки базы данных:
а – аналитическая модель; б – проектная модель
Пример класса-обертки базы данных приведен на рис.9.9. В банковской системе все устойчивые данные хранятся в базе, поэтому сущностные классы Банковского Сервера отображаются как на отношение базы данных, так и на класс-обертку. Рассмотрим, к примеру, сущностный класс Дебетовая Карточка из аналитической модели (рис.9.9а). Поскольку информация с карточки хранится в реляционной базе данных, этому классу соответствует отношение в базе. Атрибуты класса отображаются на атрибуты отношения. Кроме того, надо указать первичный ключ; мы выбрали атрибут идентификатор Карточки, так как он однозначно определяет строку отношения (рис.9.96). Требуется также внешний ключ для представления ассоциации Клиент владеет Дебетовой Карточкой.
Внешний ключ является первичным в таблице, связанной с данной. Он соответствует ассоциации между классами и используется для навигации между таблицами. Первичный ключ для отношения Клиент – это НСС Клиента (номер социального страхования), так что именно он становится внешним в отношении Дебетовая Карточка.
Необходимо спроектировать класс-обертку Дебетовая Карточка (рис.9.96), в котором будут следующие операции: создать, проверить, проверитьСуточныйЛимит, обнулитьИтог, обновить, читать и удалить. Эти операции инкапсулируют операторы SQL для доступа к отношению Дебетовая Карточка. Обратите внимание, что атрибуты класса разрешается обновлять независимо, поэтому для каждого атрибута имеется своя операция обновить. Вызов любой операции приводит к выполнению некоторого оператора SQL.