Лекци 12 - Кафедра анализа данных и исследования

Проектирование классов
Проектирование классов, скрывающих информацию
Скрывающие информацию классы, проектируемые на этом этапе, подразделяются на
категории в соответствии со стереотипом. Они документируются с помощью спецификаций.
Классы, выводимые из аналитической модели, то есть те, которые определены спецификой
предметной области, подразделяются на сущностные, интерфейсные, управляющие и
относящиеся к логике приложения. Кроме них -существуют классы, зависящие от области
решения; они проектируются позже по мере необходимости:
сущностные классы, представленные в аналитической модели, служат для
инкапсуляции данных. На диаграммах классов они помечаются стереотипом «сущность».
Сущностные объекты - экземпляры сущностных классов - обычно хранят в себе информацию
и существуют в течение длительного времени. Для приложений, работающих с базами данных,
часто требуется хранить инкапсулированные данные в базе. В таком случае сущностный
класс скорее предоставляет интерфейс к базе, чем инкапсулирует данные. Поэтому на
этапе проектирования классов сущностные классы подразделяются на классы
абстрагирования данных, инкапсулирующие структуры данных, и на классы-обертки.
Класс-обертка скрывает детали взаимодействия с внешней системой, в которой хранятся
данные. В качестве примера можно привести файловую систему или систему управления
базами данных. Класс-обертка базы данных скрывает информацию о том, как данные
хранятся в базе, обычно реляционной. Класс-обертка может также скрывать информацию
об интерфейсе с унаследованной системой;
интерфейсные классы, реализующие интерфейс с внешней средой, можно
разделить на следующие группы:
классы интерфейса устройства, взаимодействующие с устройствами
ввода/вывода;
классы интерфейса пользователя, осуществляющие человеко-машинный
интерфейс;
классы интерфейса системы, общающиеся с внешней системой или подсистемой;
управляющие классы, координирующие совместную работу нескольких объектов,
которые участвуют в прецеденте. Среди них можно выделить классы координации,
классы, зависящие от состояния, и классы таймера. Предполагается, что классы
координации и классы таймера активны (то есть являются задачами);
классы прикладной логики, инкапсулирующие особенности логики и алгоритмов
приложения, подразделяются на классы бизнес-логики и классы алгоритмов;
внутренние программные классы, скрывающие те решения проектировщиков,
которые могут впоследствии измениться. Их нельзя определить на основе аналитической
модели, они появляются в процессе проектирования.
Проектирование операций классов
Далее рассмотрим, как выявляются операции, предоставляемые классами. Хотя для
отражения операций классов предназначена статическая модель, их проще выявить на
основе анализа динамической модели. Это обусловлено тем, что в динамической модели
отражен обмен сообщениями между объектами, а, следовательно, и операции объектаполучателя.
Здесь представлено несколько примеров проектирования классов. На диаграммах
кооперации показано, как пассивный объект, операции которого мы проектируем,
взаимодействует с другими объектами. Из приведенных примеров станет ясно, как
диаграммы кооперации из аналитической модели отображаются на диаграммы
кооперации проектной модели. Основное внимание в примерах обращается на
проектирование конкретного класса и его операций.
1
Проектирование операций классов на основе модели взаимодействия
Мы воспользуемся моделью взаимодействия объектов для выявления операций
классов. Для этой цели годится как диаграмма кооперации так и диаграмма
последовательности. Операции классов определяются путем рассмотрения того, как
объект данного класса взаимодействует с другими объектами, поскольку взаимодействие
двух объектов состоит в том, что один из них вызывает операцию другого
Рассматривая два взаимодействующих объекта, необходимо понять, чьи операции
вызываются. Обычно для этого недостаточно диаграммы классов из статической модели,
так как на ней показаны только статические отношения между классами. С другой
стороны, из динамической модели видно направление передачи сообщений от одного
объекта к другому. Если спроецировать объекты на последовательную программу, то
окажется,
что
объект-отправитель
вызывает
операцию
объекта-получателя.
Следовательно, сообщению ставится в соответствие вызов операции. Имя сообщения
отображается на имя операции, а параметры сообщения - на параметры операции.
Операции объекта допустимо определить непосредственно из диаграммы
взаимодействия, на которой этот объект присутствует. В аналитической модели акцент
ставится на той информации, которой обмениваются объекты, а не на точном синтаксисе
операции. Поэтому имя сообщения на диаграмме кооперации может быть
существительным (отражающим тип передаваемых данных) или глаголом (описывающим
саму выполняемую операцию).
В модели проектирования специфицируются операции классов. Если имя
сообщения было существительным, необходимо определить операцию объекта, который
получит поименованную информацию. Если же имя сообщения было глаголом, оно и
становится именем операции. Имя, данное операции в проектной модели, должно
отражать ее назначение в классе.
Важно также выяснить, у каких операций есть входные и выходные параметра В
аналитической модели все сообщения на диаграмме кооперации изобразится в виде
простых сообщений, посылаемых одним объектом другому. В некоторых случаях простое
сообщение - это ответ на полученное сообщение. На диаграммах кооперации из проектной
модели сообщения, вызывающие операции, изображаются как синхронные. Те простые
сообщения, представленные в аналитической модели, которые соответствуют данным,
возвращенным операцией, то есть ответам, отображаются на выходные параметры
операции.
Рассмотрим, к примеру, класс Карточка Банкомата (класс абстрагирования
данных), который инкапсулирует информацию, прочитанную с карточки. Из диаграммы
кооперации в составе аналитической модели (рис 1а) видно, что объект Интерфейс
Устройства Считывания Карточек посылает сообщение Данные от Устройства Считывания
рис 1. а - аналитическая модель; б – проектная модель (д. сотрудничества);
в – проектная модель (д. классов)
2
объекту Карточка Банкомата. Позже объект Интерфейс Клиента отправляет сообщение
Запрос Карточки объекту Карточка Банкомата, который возвращает Данные Карточки. На
этапе проектирования определяется точный интерфейс класса. Простое сообщение
Данные от Устройства Считывания из проектной модели (рис. 16) отображается на вызов
операции писать (данныеКарточки), предоставляемой объектом Карточка Банкомата.
Сообщение Запрос Карточки отображается на вызов операции читать объекта Карточка.
Простому сообщению Данные Карточки соответствует выходной параметр операции
читать. Вызовы операций изображаются с помощью нотации UML для синхронных
сообщений. На рис. 1в показан класс абстрагирования данных Карточка Банкомата.
Представлены как атрибуты, так и операции. У операции писать имеется один входной
параметр - данныеКарточки. У операции читать есть один выходной параметр прочитанные данныеКарточки.
После определения операции на основе диаграммы кооперации она изображается
на статической модели вместе с классом, который ее содержит. Очень удобно
одновременно выявлять операции из диаграмм кооперации и изображать их на
диаграммах классов.
Проектирование операций классов на основе конечного автомата
Операции классов можно также вывести из диаграммы состояний. На ней
представлены действия и деятельности, инициируемые в результате перехода состояний.
Действия, как правило, отображаются на операции класса. На диаграмме состояний
показаны все зависящие от состояния действия и деятельности. Если действия
выполняются пассивными классами, то они выводятся из диаграммы состояний.
Проектирование операций классов на основе статической модели
Проектировать операции классов на основе диаграмм классов из статической
модели тоже можно, особенно для сущностных классов. Стандартными являются
операции создать, читать, обновить, удалить. Но зачастую состав операций легко
адаптировать под нужды конкретного класса абстрагирования данных, определив, какие
сервисы он должен предоставлять.
Классы абстрагирования данных
Каждый сущностный класс из аналитической модели, который инкапсулирует
данные, проектируется как класс абстрагирования данных. Сущностный класс хранит
данные и предоставляет операции для доступа к ним - операции чтения и записи. Класс
абстрагирования данных используется для инкапсуляции структуры данных, то есть
сокрытия деталей ее внутреннего представления. Операции проектируются как процедуры
или функции доступа, внутреннее устройство которых также скрыто.
Информация об атрибутах класса абстрагирования данных должна уже
присутствовать в статической модели предметной области. Операции такого класса
определяются путем рассмотрения тех сервисов, которые нужны клиентским объектам
для опосредованного доступа к данным. Это можно сделать, проанализировав способы
использования объекта абстрагирования данных в модели кооперации.
Пример класса абстрагирования данных
Для знакомства с классами абстрагирования данных рассмотрим диаграмму
кооперации из аналитической модели (рис. 2а), состоящую из двух объектов, которым
нужен доступ к объекту Наличные Банкомата. Атрибуты данного объекта приведены в
статической модели: это количество пяти-, десяти- и двадцатидолларовых купюр в
устройстве выдачи наличных. Таким образом, в объекте должны быть внутренние
переменные, содержащие соответствующие счетчики купюр. Таким образом, мы
проектируем класс Наличные Банкомата с четырьмя атрибутами: имеющаясяСумма,
пятидолларовыеКупюры,
десятидолларовыеКупюры,
двадцатидолларовыеКупюры.
Начальное значение всех атрибутов установлено в ноль.
Необходимы сведения о том, какие сообщения посылаются объекту Наличные
3
Банкомата и какова последовательность их отправки. Так, из аналитической модели
явствует, что, когда объект Наличные Банкомата получает сообщение Снимаемая со Счета
Сумма от объекта Интерфейс Устройства Выдачи Наличных, он должен вычислить,
сколько купюр каждого достоинства выдать. В аналитической модели эта информация
посылается в ответном сообщении Ответ о Выдаче Наличных.
Объект Наличные Банкомата получает также сообщение от объекта Интерфейс
Оператора. Человек-оператор пополняет запас наличных в банкомате купюрами разного
достоинства, а соответствующая информация передается объекту Наличные Банкомата.
Добавив наличные, оператор уведомляет банкомат с помощью объекта Интерфейс
Оператора, который посылает сообщение Добавлены Наличные объекту Наличные
Банкомата (рис. 2а).
Теперь мы можем специфицировать операции класса Наличные Банкомата так, как
показано на диаграмме кооперации проектной модели на рис. 2б. Нужны две операции:
добавитьНаличные и выдатьНаличные, У операции выдатьНаличные один входной
параметр: суммаКВыдаче - и три выходных: вы-датьПятидолларовыхКупюр,
выдатьДесятидолларовыхКупюр,
выдатьДвадцатидолларовыхКупюр.
У
операции
добавитьНаличные
три
входных
параметра:
добавленоПятидолларовыхКупюр,
добавленоДесятидолларовыхКупюр и добавленоДвадцатидолларовыхКутдар. Вот как
специфицируются операции:
выдатьНаличные(in суммаКВыдаче, out выдатьПятидолларовыхКупюр,
out выдатьДесятидолларовыхКупюр, out выдатьДвадцатидолларовыхКупюр)
добавитьНаличные(in добавленоПятидолларовыхКупюр,
in добавленоДесятидолларовыхКупюр, in добавленоДвадцатидолларовыхКупюр)
Диаграмма классов изображена на рис. 2в.
Объекты этого класса поддерживают инвариант: общая сумма наличных в
банкомате должна равняться суммарному значению достоинств всех купюр:
имеющаясяСумма = 5 * пятидолларовыеКупюры +
+ 10 * десятидолларовыеКупюры + 20 * двадцатидолларовыеКупюры
Недостаток наличных - это ошибка, которую нужно распознавать. Обычно такие
ошибки обрабатываются как исключения.
4
рис 2 Пример класса абстрагирования
а – аналитическая модель (д. кооперации), б – проектная модель (д. кооперации);
в – проектная модель (д. классов)
5