Аналитической модели
Модель анализа последовательно разрастается по мере анализа все новых и новых
вариантов использования. На каждой итерации мы выбираем варианты использования,
которые будем включать в модель анализа. Мы строим систему в виде структуры,
состоящей из классификаторов (классов анализа) и отношений между ними.
Мы также описываем кооперации, реализующие варианты использования, то есть
реализации вариантов использования. На следующей итерации мы выбираем для
проработки следующие варианты использования и добавляем их к результатам
предыдущей итерации. В подразделах «Итеративный подход — управляемый рисками
» главы 5 и «Расстановка приоритетов вариантов использования» главы 12
мы рассматриваем, как на первых итерациях идентифицировать и выбрать «важнейшие
» варианты использования, чтобы построить стабильную архитектуру на
ранних стадиях жизненного цикла системы.
Работа обычно выполняется так: сначала идентифицируются и описываются
варианты использования текущей итерации, затем в соответствии с описанием для
каждого варианта использования (как показано в подразделе «Варианты использования
определяют систему» данной главы) предлагаются классификаторы и ассоциации,
необходимые для реализации этого варианта использования. Мы проделываем
эту работу для всех вариантов использования текущей итерации. В зависимости
от того, в какой точке жизненного цикла мы находимся и с какой итерацией
работаем, архитектура может уже быть определена, тогда она поможет нам
обнаруживать новые классификаторы и повторно использовать существующие (см.
подраздел «Варианты использования и архитектура» главы 4). Каждый классификатор
играет в реализации варианта использования одну или несколько ролей.
Каждая роль классификатора определяет обязанности, атрибуты и другие характеристики,
которыми классификатор будет обладать в реализации варианта использования.
Мы можем считать эти роли зародышами классификаторов. В UML роль
является классификатором сама по себе. Например, мы можем думать о роли класса
как о представлении этого класса. Таким образом, она включает содержимое этого
класса, то есть обязанности, атрибуты и другие характеристики — но только те,
которые имеют отношение к его роли в реализации варианта использования. Другой
способ описать роль класса состоит в том, чтобы рассматривать ее как то, что
остается от класса после наложения на него фильтра, отсекающего все то, что относится
к другим ролям класса, за исключением совместно выполняемых обязанностей.
Такой подход к роли кратко описан в этой главе. Для упрощения понимания
материала во второй части этой книги, где классификаторы обсуждаются подробнее,
этот подход не используется.
Пример. Реализация варианта использования в модели анализа. На рис. 3.4 мы
показываем, как с помощью кооперации реализуется вариант использования Снять__
деньги со счета (то есть реализацию варианта использования) с зависимостью
«трассировка» (трассировка — стереотип зависимости, которая обозначена кавычками,
« и ») между ними. В реализации варианта использования участвуют и играют
свои роли четыре класса. Как можно понять из рисунка, нотацией реализации
варианта использования или сотрудничества является эллипс, контур которого
нарисован пунктиром.
Рис. 3.4. Классы анализа, участвующие в реализации варианта использования
Снять деньги со счета. Устройство выдачи и Интерфейс кассира —
граничные классы, Получение — управляющий класс
и Счет — класс сущности
Обычно мы начинаем работу с изучения нескольких вариантов использования,
создаем для них реализации вариантов использования и выделяем роли классификаторов.
Затем мы делаем то же самое для других вариантов использования и выделяем
новые роли классификаторов. Некоторые из этих новых ролей могут оказаться
новыми или изменившимися ролями уже обнаруженных классификаторов,
в то время как другие роли потребуют новых классификаторов. Тогда мы снова
просматриваем первую порцию вариантов использования и так, чередуя варианты
использования, постепенно строим устойчивую модель анализа. В результате
каждый классификатор может участвовать и играть соответствующие роли в нескольких
реализациях вариантов использования.
СТЕРЕОТИПЫ АНАЛИЗА
В модели анализа используется три различных стереотипа классов — граничный класс, управляющий
класс и класс сущности. Устройство выдачи и Интерфейс кассира — это граничные
классы; эти классы в основном используются для моделирования взаимодействия
между системой и ее актантами (то есть пользователями и внешними системами). Получение—
управляющий класс; эти классы в основном используются для представления координации,
последовательности, взаимодействия и управления другими объектами — и часто
применяются для инкапсуляции управления, относящегося к определенному варианту использования
(в данном случае — варианту использования Снять деньги со счета). Банковский
счет— класс сущности; эти классы в основном используются для моделирования информации
длительного хранения, часто постоянной. Таким образом, каждый из стереотипов
классов поддерживает различные типы поведения (или, если хотите, функциональные
возможности). В результате стереотипы помогают нам построить надежную систему. Мы
подробно рассмотрим эту тему в главе 8. Этот подход также помогает находить кандидатов
на многократное использование и места, в которых возможно применение готовых классов,
поскольку классы сущностей часто бывают одинаковыми для многих вариантов использования,
а следовательно, и для многих различных приложений. Подразделение классов анализа
на эти три стереотипа более подробно описано в [34]. Этот прием был проверен многолетней
практикой, широко используется сейчас и включен в UML [57].
Пример.Класс, участвующий в нескольких реализациях варианта использования
модели анализа. В левой части рис. 3.5 — набор вариантов использования для
банкомата (тот же самый, что и на рис. 3.3), в правой части — соответствующая
структура системы, в данном случае — классы анализа, реализующие варианты
использования. Структура системы моделируется диаграммой классов(приложение
А). Диаграммы классов обычно используются для демонстрации классов
и их отношений, но их также можно использовать для демонстрации подсистем
и интерфейсов (мы рассмотрим этот вопрос при обсуждении проектирования
в подразделе «Создание модели проектирования из аналитической модели» данной
главы). Для того чтобы было проще понять, в какой реализации варианта использования
участвует данный класс, мы использовали различную штриховку. Диаграмма
показывает, как каждый из вариантов использования (слева) реализован
в структуре классов анализа (справа). Так, например, классы Интерфейс кассира,
Получение, Банковский счет и Устройство выдачи участвуют в реализации варианта
использования Снять деньги со счета. Классы Интерфейс кассира и Банковский
счет участвуют и исполняют роли во всех трех реализациях вариантов использования.
Остальные классы участвуют в одной реализации варианта использования
каждый, они исполняют только одну роль.
Рис. 3.5. Реализация каждого из вариантов использования (слева)
в структуре классов анализа (справа)__
Диаграмма классов банкомата (рис. 3.5) была получена в результате изучения
описаний трех вариантов использования и поиска способов реализации каждого
из них. Мы можем сделать это примерно так.
О Реализации трех вариантов использования Снять деньги со счета, Перечислить
деньги на другой счет и Внести деньги на счет используют граничный класс
Интерфейс кассира и класс сущности Банковский счет. Выполнение каждого
варианта использования начинается с объекта(приложение А) Интерфейс кассира.
Затем выполнение переходит к управляющему объекту, который координирует
выполнение варианта использования. Класс этого объекта уникален для
каждого варианта использования. Класс Получение, таким образом, участвует
в варианте использования Снять деньги со счета и т. д. Объект Получение предлагает
Устройству выдачи выдать деньги, а объекту Банковский счет — уменьшить
баланс счета.
О В реализации варианта использования Перечислить деньги на другой счет участвуют
два объекта Банковский счет. Они оба нуждаются в запросе на изменение
баланса счета от объекта Перечисление.
О Объект Вклад принимает деньги через Устройство приема и предлагает объекту
Банковский счет увеличить баланс счета.
Пока целью нашей работы было определение структуры системы для текущей
итерации. Мы идентифицировали обязанности участвующих классификаторов
и определили отношения между классификаторами. Однако мы не старались подробно
идентифицировать взаимодействия, необходимые для понимания вариантов
использования. Мы нашли структуру и теперь должны наложить на нее шаблоны
взаимодействия, требующиеся для каждой реализации варианта использования.
Как мы уже говорили, каждый вариант использования преобразуется в реализацию
варианта использования и каждая реализация варианта использования содержит
набор участвующих в ней классификаторов, исполняющих различные роли.
Понимание шаблонов взаимодействия означает, что мы определяем, как выполняется
реализация варианта использования или создается экземпляр. Например, что
происходит, когда некий Клиент банка снимает деньги со счета, то есть когда он
выполняет вариант использования Снять деньги со счета. Мы знаем, что в реализации
варианта использования будут участвовать классы Интерфейс кассира, Получение,
Банковский счет и Устройство выдачи. Мы также знаем, какие у них обязанности.
Однако нам не известно, как они или, что более правильно, как объекты
этих классов взаимодействуют между собой в реализации варианта использования.
Мы должны это выяснить. Сначала мы используем диаграммы кооперации
(приложение А) для того, чтобы смоделировать взаимодействия между объектами
анализа (для моделирования взаимодействий в UML также имеются диаграммы
последовательностей, их мы рассмотрим в подразделе «Создание модели проектирования
из аналитической модели» данной главы, когда будем говорить о проектировании).
Диаграмма кооперациинапоминает диаграмму классов, но на ней
изображаются не классы и ассоциации, а экземпляры и связи (приложение А). Она
показывает, как объекты последовательно или параллельно взаимодействуют
с нумерацией сообщений, которыми они обмениваются.__
Пример.Использование диаграммы кооперации для описания реализаций вариантов
использования в модели анализа. На рис. 3.6 мы используем диаграмму кооперации
для описания того, как группой объектов анализа выполняется реализация
варианта использования Снять деньги со счета.
Диаграмма показывает, как по мере выполнения варианта использования фокус
перемещается от объекта к объекту и как между объектами пересылаются сообщения.
Сообщение, посланное от одного объекта другому, переключает фокус
на объект-приемник и побуждает его выполнить одну из обязанностей, порученных
этому классу.
Название сообщения описывает предполагаемый смысл взаимодействия вызывающего
объекта с вызываемым. Позже, в ходе проекта, эти сообщения будут
преобразованы в одну или более операции, содержащиеся в соответствующих классах
проектирования. Мы рассмотрим это в подразделе «Создание модели проектирования
из аналитической модели» данной главы.
Рис. 3.6. Диаграмма кооперации для реализации варианта использования
Снять деньги со счета модели анализа
Разработчики могут также добавить к диаграмме кооперации текст, поясняющий
взаимодействие объектов при выполнении последовательности событий варианта
использования. Существует также множество других способов описания
реализации, например использование структурированного текста или псевдокода.
Пример. Описание последовательности событий реализации варианта использования.
Здесь мы опишем реализацию варианта использования Снять деньги со
счета в понятиях взаимодействующих объектов и актантов, как показано на
рис. 3.6.
Клиент банка, желая снять деньги со счета, активирует объект Интерфейс кассира.
Клиент банка идентифицирует себя и указывает, сколько денег снять и с какого
счета (1). Интерфейс кассира проверяет идентификацию Клиента банка
и предлагает объекту Получение выполнить операцию (2).
Если идентификация Клиента банка признана верной, объект Получение предлагает
объекту Банковский счет подтвердить, что Клиент банка имеет право получить
запрошенную сумму. Объект Получение делает это, предлагая объекту Банковский
счет подтвердить правильность запроса и, если он верен, списать указанную
сумму с баланса (3).__
После этого объект Получение разрешает Устройству выдачи выдать сумму,
запрошенную Клиентом банка (4). Клиент банка при этом получает запрошенную
сумму денег (5).
Отметим, что этот простой пример описывает только одну последовательность
действий из возможных при реализации варианта использования, а именно вариант
без каких-либо осложнений. Осложнением мы называем, например, вариант,
когда баланс Банковского счета меньше запрошенной к выдаче суммы.
Итак, мы проанализировали все варианты использования и идентифицировали
роли классов, принимающих участие в каждой из реализаций вариантов использования.
Перейдем теперь к анализу классов.
Каждый класс должен играть все свои роли