Работа над диаграммой класса для прецедента завершается определением отношений между классами. Особый интерес представляют отношения ассоциации и наследования (см. главу 3 об ассоциации и агрегации).
Удобно выявлять такие отношения на базе диаграммы сотрудничества. Если на такой диаграмме между двумя классами есть связь, следовательно, имеется потребность в сообщении между ними, что ясно говорит о существовании отношения.
Также следует определить направление связи. Связь может быть однонаправленной, т.е. экземпляр класса А может посылать сообщение классу В, но не наоборот, или двунаправленной, т.е. каждая сторона может посылать сообщение своему партнеру по отношению. Каждое отношение следует также проверить на кратность. Например, если в ассоциации может участвовать до четырех экземпляров класса, на этой стороне ассоциации должна быть указана кратность 0..4.
Всегда есть искушение дополнить диаграмму классов новыми отношениями, которые кажутся необходимыми или могут стать такими позже. Однако надо помнить, что этот анализ базируется прежде всего на прецедентах, и только то, что входит в прецедент, может стать отношением.
На рис. 8.11 изображена диаграмма классов для прецедента "Перевод денег".
Эта диаграмма требует некоторых замечаний. Во-первых, класс управления не должен сохранять ссылки н* классы профиля клиента Profile и реестра транзакций Transactions-Register для последующих обращений. Эти ссылки создаются каждый раз заново в зависимости от участвующего клиента и после завершения собственно транзакции. Следовательно, эти отношения выражаются как зависимости, а не как ассоциации. Во вторых, в сценарии перевода денег участвует два счета (первый и второй). Этот факт выражается кратностью 2 для класса-сущности Account.
Слияние классов анализа
Когда все прецеденты проанализированы и для каждого прецедента построена диаграмма классов, приходит время объединить разные классы анализа в единую модель анализа. Это важный этап работы, если мы хотим уменьшить количество классов до минимума и избежать в окончательной модели ненужной избыточности.
Главная задача на этой стадии состоит в выявлении классов, которые в точности или с небольшими вариациями дублируются в разных прецедентах. Например, классы управления, которые имеют похожее поведение или представляют одну и ту же концепцию в разных прецедентах, следует слить в один класс. Также слиянию подлежат классы-сущности, которые имеют одни и те же атрибуты.
На рис. 8.12 показана предварительная модель анализа для практического исследования системы HomeDirect после слияния основных прецедентов. Обратите внимание на объединение разных классов управления, которые определены для нескольких отдельных прецедентов, в три общих класса управления. Эти классы образуются при слиянии классов управления для близкородственных прецедентов (например, входа в систему, оплаты по счету и т.д.).
На данной стадии еще ни один аспект системы не зафиксирован окончательно, и поэтому многие подробности еще предстоит раскрыть. Очень вероятно, что эта модель еще не раз будет отклонена и критически проанализирована, прежде чем станет приемлемой для всех сторон.
Подробнее о конкретных сценариях и связанных с ними проблемах см. главу 16.
Распределение по пакетам
В относительно простой электронной банковской системе HomeDirect, рассматриваемой в этой книге, мы определили около десятка прецедентов. В свою очередь, в каждом прецеденте выделяются один, два, три или больше классов анализа, что дает тридцать или даже больше классов уже на самой первой итерации. Ясно, что дальше по ходу проекта это число имеет серьезные шансы возрасти.
Уважаемый посетитель!
Чтобы распечатать файл, скачайте его (в формате Word).
Ссылка на скачивание - внизу страницы.