А.М. Вендров - Объектно-ориентированный анализ и проектирование, страница 9

Например, Ивар Якобсонутверждал, что для проекта с трудоемкостью в 10 человеко-лет количествовариантов использования может составлять около 20 (не считая связей"включения" и "расширения"). Следует предпочитать небольшие идетализированные варианты использования, поскольку они облегчаютсоставление и реализацию согласованного плана проекта.Достоинства модели вариантов использования заключаются в том, чтоона:• определяет пользователей и границы системы;• определяет системный интерфейс;• удобна для общения пользователей с разработчиками;• используется для написания тестов;• является основой для написания пользовательской документации;• хорошо вписывается в любые методы проектирования (какобъектно-ориентированные, так и структурные).1.4.2.

Диаграммы взаимодействияДиаграммывзаимодействияописываютповедениевзаимодействующих групп объектов (в рамках варианта использованияили некоторой операции класса).42Как правило, диаграмма взаимодействия охватывает поведениеобъектов в рамках только одного потока событий варианта использования.На такой диаграмме отображается ряд объектов и те сообщения, которымиони обмениваются между собой.Сообщение (message) - средство, с помощью которого объектотправитель запрашивает у объекта-получателя выполнение одной из егоопераций.Информационное (informative) сообщение - сообщение, снабжающееобъект-получатель некоторой информацией для обновления его состояния.Сообщение-запрос (interrogative) - сообщение, запрашивающее выдачунекоторой информации об объекте-получателе.Императивное (imperative) сообщение - сообщение, запрашивающее уобъекта-получателя выполнение некоторых действий.Существует два вида диаграмм взаимодействия: диаграммыпоследовательности и кооперативные диаграммы.Диаграммы последовательностиДиаграммыпоследовательностиотражаютвременнуюпоследовательность событий, происходящих в рамках вариантаиспользования.

Например, вариант использования "Снять деньги со счета"предусматривает несколько возможных потоков событий, такие как снятиеденег, попытка снять деньги, не имея их достаточного количества на счету,попытка снять деньги по неправильному PIN-коду и некоторые другие.Нормальный сценарий (основной поток событий) снятия некоторой суммыденег со счета показан на рис. 1.14.Все действующие лица показаны в верхней части диаграммы; вприведенном примере изображено действующее лицо Клиент (Customer).Объекты, требуемые системе для выполнения варианта использования"Снять деньги со счета", также представлены в верхней части диаграммы.Стрелки соответствуют сообщениям, передаваемым между действующимлицом и объектом или между объектами для выполнения требуемыхфункций.На диаграмме последовательности объект изображается в видепрямоугольника на вершине пунктирной вертикальной линии. Этавертикальная линия называется линией жизни (lifeline) объекта.

Онапредставляет собой фрагмент жизненного цикла объекта в процессевзаимодействия.Каждое сообщение представляется в виде стрелки между линиямижизни двух объектов. Сообщения появляются в том порядке, как онипоказаны на странице сверху вниз.

Каждое сообщение помечается какминимум именем сообщения; при желании можно добавить такжеаргументы и некоторую управляющую информацию, и, кроме того, можнопоказать само-делегирование (self-delegation) - сообщение, которое объект43посылает самому себе, при этом стрелка сообщения указывает на ту жесамую линию жизни.Рис.

1.14. Диаграмма последовательностиОдин из способов первоначального обнаружения некоторых объектов- это изучение имен существительных в потоке событий. Поток событийдля варианта использования "Снять деньги со счета" говорит о человеке,снимающем некоторую сумму денег со счета с помощью банкомата.44Не все объекты, показанные на диаграмме, явно присутствуют впотоке событий. Там, например, может не быть форм для заполнения, ноих необходимо показать на диаграмме, чтобы позволить действующемулицу ввести новую информацию в систему или просмотреть ее.

В потокесобытий, скорее всего, также не будет и управляющих объектов (controlobjects). Эти объекты управляют последовательностью событий в вариантеиспользования.Кооперативные диаграммыВторым видом диаграммы взаимодействия является кооперативнаядиаграмма (рис. 1.15).Рис. 1.15. Кооперативная диаграмма45Подобно диаграммам последовательности, кооперативные диаграммыотображают поток событий варианта использования. Диаграммыпоследовательности упорядочены по времени, а кооперативные диаграммыконцентрируют внимание на связях между объектами. На рис.

1.15приведена кооперативная диаграмма, описывающая, как клиент снимаетденьги со счета. На ней представлена та же информация, которая была и надиаграмме последовательности, но кооперативная диаграмма по-другомуописывает поток событий. Из нее легче понять связи между объектами,однако, труднее уяснить последовательность событий.По этой причине часто для какого-либо сценария создают диаграммыобоих типов. Хотя они служат одной и той же цели и содержат одну и туже информацию, но представляют ее с различных точек зрения.На кооперативной диаграмме так же, как и на диаграммепоследовательности, стрелки обозначают сообщения, обмен которымиосуществляется в рамках данного варианта использования.

Их временнаяпоследовательность, однако, указывается путем нумерации сообщений.1.4.3. Диаграммы классовДиаграмма классов определяет типы классов системы и различногорода статические связи, которые существуют между ними. На диаграммахклассов изображаются также атрибуты классов, операции классов иограничения, которые накладываются на связи между классами.Диаграмма классов для варианта использования "Снять деньги со счета"показана на рис. 1.16.На этой диаграмме присутствуют четыре класса: Card Reader(устройство для чтения карточек), Account (счет), ATM Screen (экранАТМ) и Cash Dispenser (кассовый аппарат).

Связывающие классы линииотражают взаимодействие между классами. Так, класс Account связан склассом ATM Screen, потому что они непосредственно сообщаются ивзаимодействуют друг с другом. Класс Card Reader не связан с классомCash Dispenser, поскольку они не сообщаются друг с другомнепосредственно. В изображении классов присутствуют также стереотипы,которые будут рассматриваться в подразд. 1.4.8.Для группировки классов, обладающих некоторой общностью,применяются пакеты. Пакет - общий механизм для организации элементовмодели в группы. Пакет может включать другие элементы. Каждыйэлемент модели может входить только в один пакет. Пакет являетсясредством организации модели в процессе разработки, повышения ееуправляемости и читаемости, а также единицей управленияконфигурацией.46Рис.

1.16. Диаграмма классов для варианта использования "Снять деньгисо счета"Существует несколько подходов к группировке классов. Во-первых,можно группировать их по стереотипу (типу класса). Например, одинпакет содержит классы-сущности предметной области, другой - классыпользовательского интерфейса и т.д. Этот подход может быть полезен сточки зрения размещения системы в среде реализации.Другой подход заключается в объединении классов по ихфункциональности. Например, в пакете Security (безопасность) содержатсявсе классы, отвечающие за безопасность приложения.

В таком случаедругие пакеты могут называться Employee Maintenance (Работа ссотрудниками), Reporting (Подготовка отчетов) и Error Handling(Обработка ошибок). Преимущество этого подхода заключается ввозможности повторного использования.47Если между любыми двумя классами, находящимися в разныхпакетах, существует некоторая зависимость, то имеет место зависимость имежду этими двумя пакетами. Таким образом, диаграмма пакетов (рис.1.17) представляет собой диаграмму, содержащую пакеты классов изависимости между ними. Строго говоря, пакеты и зависимости являютсяэлементами диаграммы классов, то есть диаграмма пакетов - это формадиаграммы классов.

Диаграммы пакетов можно считать основнымсредством управления общей структурой системы.Рис. 1.17. Диаграмма пакетовПакеты также используются для представления подсистем (модулей)системы (рис. 1.18). Подсистема - это комбинация пакета (поскольку онавключает некоторое множество классов) и класса (поскольку она обладаетповедением, т.е. реализует набор операций, которые определены в ееинтерфейсах). Связь между подсистемой и интерфейсом называетсясвязью реализации. Подсистема используется для представлениякомпонента в процессе проектирования.<<subsystem>>Subsystem NameInterfaceРис. 1.18.

Подсистема1.4.4. Диаграммы состоянийДиаграммы состояний определяют все возможные состояния, вкоторых может находиться конкретный объект, а также процесс смены48состояний объекта в результате наступления некоторых событий.Существует много форм диаграмм состояний, незначительноотличающихся друг от друга семантикой.На рис. 1.19 приведен пример диаграммы состояний для банковскогосчета. Из данной диаграммы видно, в каких состояниях можетсуществовать счет. Можно также видеть процесс перехода счета из одногосостояния в другое. Например, если клиент требует закрыть открытыйсчет, он переходит в состояние "закрыт".