- •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. Спецификация интерфейса класса
Сервер Банковских Транзакций, Менеджер
Транзакций Проверки ПИН-кода,
Менеджер Транзакций Снятия, Менеджер
Транзакций Справки, Менеджер
Транзакций Перевода, Чековый Счет,
Сберегательный Счет, Дебетовая Карточка,
Карточный Счет, Протокол Транзакций;
• временные характеристики:
– активизация: асинхронная – по мере поступления сообщений от клиентов. Интервал между последовательными поступлениями в худшем случае 100 мс. Среднее время между поступлениями больше 1 с;
– время выполнения Сi: 10 мс на одно сообщение;
• приоритет.
Высокий – должна успевать отвечать на входные сообщения;
• обнаруживаемые ошибки.
Неопознанное сообщение;
• логика упорядочения событий.
Определяется на этапе детального проектирования программы.
9. Проектирование классов
На этом этапе проектируются скрывающие информацию классы, из которых создаются экземпляры пассивных объектов. Первоначально классы определяются на этапе построения аналитической модели в ходе разбиения системы на объекты и классы. Класс применяет сокрытие информации для решения различных вопросов, связанных со статической структурой, например сокрытия информации об устройстве или абстрагирования данных. Операции класса можно вывести как из статической, так и из динамической модели. Хотя статическая модель предназначена для отражения операций классов, их проще выявить посредством анализа динамической модели – прежде всего, диаграммы кооперации или последовательности. Ниже мы покажем, как операции класса выводятся из модели кооперации, из описания конечного автомата и из статической модели, но основное внимание уделим модели кооперации.
9.1. Проектирование классов, скрывающих информацию
Скрывающие информацию классы, проектируемые на этом этапе, подразделяются на категории в соответствии со стереотипом. Они документируются с помощью спецификаций интерфейсов.
Классы, выводимые из аналитической модели, то есть те, которые определены спецификой предметной области, подразделяются на сущностные, интерфейсные, управляющие и относящиеся к логике приложения. Кроме них существуют классы, зависящие от области решения; они проектируются позже по мере необходимости:
– сущностные классы, представленные в аналитической модели, служат для инкапсуляции данных. На диаграммах классов они помечаются стереотипом «сущность». Сущностные объекты – экземпляры сущностных классов - обычно хранят в себе информацию и существуют в течение длительного времени. Для приложений, работающих с базами данных, часто требуется хранить инкапсулированные данные в базе. В таком случае сущностный класс скорее предоставляет интерфейс к базе, чем инкапсулирует данные. Поэтому на этапе проектирования классов сущностные классы подразделяются на классы абстрагирования данных, инкапсулирующие структуры данных, и на классы-обертки. Класс-обертка скрывает детали взаимодействия с внешней системой, в которой хранятся данные. В качестве примера можно привести файловую систему или систему управления базами данных. Класс-обертка базы данных скрывает информацию о том, как данные хранятся в базе, обычно реляционной. Класс-обертка может также скрывать информацию об интерфейсе с унаследованной системой;
– интерфейсные классы, реализующие интерфейс с внешней средой, можно разделить на следующие группы:
классы интерфейса устройства, взаимодействующие с устройствами ввода/вывода;
классы интерфейса пользователя, осуществляющие человеко-машинный интерфейс;
классы интерфейса системы, общающиеся с внешней системой или подсистемой;
– управляющие классы, координирующие совместную работу нескольких объектов, которые участвуют в прецеденте. Среди них можно выделить классы координации, классы, зависящие от состояния, и классы таймера. Предполагается, что классы координации и классы таймера активны (то есть являются задачами), поэтому мы их обсуждать не будем;
– классы прикладной логики, инкапсулирующие особенности логики и алгоритмов приложения, подразделяются на классы бизнес-логики и классы алгоритмов;
– внутренние программные классы, скрывающие те решения проектировщиков, которые могут впоследствии измениться. Их нельзя определить на основе аналитической модели, они появляются в процессе проектирования.