Дж. Рамбо, М. Блаха - UML 2.0 - Объектно-ориентированное моделирование и разработка (1158633), страница 87
Текст из файла (страница 87)
Верхняя половина — модель классов предметной области, а нижняя — модель классов приложения. На этой диаграмме мы указали не все имеющиеся в модели операции. 17.4. Реализация ассоциаций Ассоциации — это «клей», соединяющий в одно целое модель классов. Мы должны сформулировать стратегию реализации ассоциаций. Можно выбрать глобальную стратегию и реализовать все ассоциации одинаковым образом или выбирать конкретную методику для каждой ассоциации в отдельности с учетом того, как 364 Глава 17 ° Моделирование реализации оиа будет использоваться в приложении.
Начнем мы с анализа прослеживаии ассоциаций в модели. (огбегеб), АТМ йвпюгв Тгапвас!юп Ирба!е савЬОпидпб апюип1 Мпб Еп!егебОп ба15Т!те ЯиупопгебВу чеп!уСавЬСа п! чеп!уАтоип1 б!вьигсерипбв гесейерипбв 0..1 0..1 СагбАиИюг!ааеоп йвпю1ейесе!р! 1 СавЬСагб равваюгб ата 1 1аб вепа!МитЬег ро51Тгапвасиоп в оп Собе Сопвог!!ит Вала сагб Себе 1 155ив5 0..1 пате 1 01 Сов! опгвг ассоипгсобе Ассоип! вег Атоип1 дег Ассоип1 0..1 Иввг1пгвггасв СопвогИит!п1егтасв РгоЫвтТуре пате Соп!го!1егРгоЫвт 515П051ет!те 515П051ет!те Сап!,сап! асбчеСагб 0..1 АТМвввв!оп 0..1 0-1 Маг10агеТ!те Ассоипг асвчеАссоип! Зввв!опСоп1годег 1 5151и5 Рис. 17.6.
Модель классов банкомата дпя реализации чеп!уВапКСобе ЬапКСобе чеп!ТРавваогб сгеа158ач!пввАссоип1 сгеа!еСЬеипвАссоип1 сгеа!еСавЬСагб чеп!уАпюип1 Ьа!а псе сгеб!1 !т!1 1уре С!Овв чеп!уАтоипг рс51 аббАссоип1 геп!очеАссоип1 С!Овв пате абгевв 1 1етрАтоип1 17.4. Реализация ассоциаций 365 17Я.1. Анализ прослеживания ассоциаций До этого момента мы предполагали, что все ассоциации являются двусторонними. В абстрактном смысле это, несомненно, правильное предположение. Но если в вашем приложении есть ассоциации, которые прослеживаются только в одном направлении, их реализацию можно существенно упростить.
Впрочем, не забывайте о том, что в будущем требования могут измениться и вам придется добавлять операцию, которая будет прослеживать зту ассоциацию в обратном направлении. Для работы с прототипами мы всегда используем двусторонние ассоциации, чтобы иметь возможность быстро добавлять новое поведение и изменять приложение. Однако в рабочей версии приложения некоторые ассоциации оптимизируются. В любом случае, реализация должна быть скрыта.
Тогда вам проще будет поменять свое решение. 17А.2. Односторонние ассоциации Если ассоциация прослеживается только в одном направлении, ее можно реализовать при помощи указателя — атрибута, содержащего ссылку на объект. Обратите внимание, что в этой главе мы употребляем слово указатель (ро1пгег) в логическом смысле. При реализации может быть использован указатель илн ссылка выбранного языка программирования или даже внешний ключ базы данных. Если ассоциация имеет кратность «один» (рнс. 17.7), указатель тоже будет один. Если же кратность ассоциации «много», придется работать со множеством указателей.
Медаль классов: Рвализацил: Рис. Х7.7. Реализация односторонней ассоциации при помощи указателей 17А.З. Двусторонние ассоциации Чаще всего ассоциации прослеживаются в обоих направлениях, хотя и не с одинаковой частотой. Существует три подхода к реализации таких ассоциаций. ° Односторонняя реализация. Реализовать в виде одностороннего указателя и выполнять поиск при прослеживании в обратном направлении. Этот подход полезен только в том случае, когда частота прослеживания в двух направлениях отличается очень сильно, а для приложения важно сократить затраты на хранение и обновление информации. Прослеживание в обратном направлении будет при этом дорогостоящей операцией.
366 Глава 17 ° Моделирование реализации ° Двусторонняя реализация. Реализовать с указателями в обоих направлениях, как показано на рис. 17.8. Этот подход обеспечивает быстрый доступ, но если объект у одного из полюсов ассоциации обновляется, на втором полюсе также необходимо выполнить обновление, чтобы связь осталась согласованной. Этот подход полезен в том случае, когда запросы выполняются чаще, чем обновления. Рис. 17.8.
Реализация двусторонней ассоциации через указатели ° Реализация при помощи объекта. Реализовать ассоциации при помощи выделенного объекта, не зависящего от обоих связаиных классов (рис. 17.9) (КцшЬацйЬ-87 1. Объект ассоциации — это множество пар связанных объектов (или троек связанных объектов в том случае, когда ассоциация является квалифицированной), которое хранится в одиом объекте переменного размера. В целях повышения эффективности можно реализовать объект ассоциации при помощи двух словарных объектов, каждый из которых будет связан с одним из направлений. При данном подходе доступ получается несколько более медленным, чем при использовании указателей, но с применением хэшироваиия время доступа остается независящим от количества объектов.
Этот подход удобен для расширения предопределенных классов библиотек, которые не могут быть изменены, потому что в данном случае добавления атрибутов к исходным классам не требуется. Выделенные объекты также удобны для «разрежеиныхь ассоциаций, в которых не участвует большинство объектов класса, потому что память расходуется только иа фактически существующие связи.
Рис. 17.9. Реализация ассоциации в виде объекта 175. Тестирование 367 17.4.4. Сложные ассоциации Методы реализации сложных ассоциаций зависят от их особенностей. ° Классы ассоциаций. Обычно такую ассоциацию превращают в класс. Это позволяет реализовать как атрибуты, так и ассоциации, относящиеся к классу. Однако преврашение изменяет смысл модели: у такой ассоциации имеется своя собственная индивидуальность, а потому методы должны какимто образом принудительно поддерживать зависимость класса ассоциации от участвующих в ассоциации классов. Если ассоциация относится к типу «один-к-одному» и не имеет дальнейших ассоциаций, ее можно реализовать при помощи указателей, а атрибуты ассоциации хранить в объектах участвующих классов.
То же касается ассоциации типа «один-ко-многимгс атрибуты ассоциации в этом случае хранятся в объектах класса, имеющего кратность «много», потому что каждый объект этого класса участвует в ассоциации один раз. ° Упорядоченные ассоциации. Используйте упорядоченное множество указателей (аналогично рис.
17.8) или словарь с упорядоченным набором пар (аналогично рис. 17.9). ° Последовательности. То же, что и упорядоченная ассоциация, но требует использования списка указателей. ° Мультимножества. То же, что и упорядоченная ассоциация, но требует использования массива указателей. ° Квалифицированные ассоциации. Реализуйте квалифицированную ассоциацию с кратностью «один» в виде объекта-словаря (см. рис. 17.9). Квалифицированные ассоциации с кратностью «много» встречаются редко.
Их можно реализовать в виде словаря множеств объектов. ° Х-арные ассоциации. Сделайте ассоциацию классом. При этом изменится смысл модели, что придется компенсировать дополнительным кодом (как для классов ассоциаций). ° Агрегация. Агрегацию следует рассматривать как обычную ассоциацию. ° Композиция. Композицию тоже нужно рассматривать как обычную ассоциацию. Зависимость части от целого придется обеспечивать дополнительным кодом. Пример с банкоматом. Реализация ассоциаций из модели банкомата рассматривается в упражнении 17.1. 17.5. Тестирование Аккуратное моделирование приложения сокращает количество ошибок в будушей системе и позволяет снизить затраты на ее тестирование.
Однако полностью обойтись без проверки все равно не удастся. Тестирование — это механизм контроля 363 Глава 17 ° Моделирование реализации качества, предназначенный для обнаружения оставшихся ошибок. Кроме того, оно позволяет независимо оценить качество вашего программного обеспечения. Количество ошибок, обнаруженных в процессе тестирования, — индикатор качества программы. С ростом опыта в моделировании эта величина должна сокращаться.
Аккуратно записывайте все обнаруживаемые ошибки, а также жалобы клиентов. Если система достаточно цельная, основную сложность представляет поиск случайных ошибок. Их исправление практически не вызывает затруднений. Напротив, если программа разработана бессистемно, исправить найденные ошибки может быть достаточно сложно. Тестирование нужно проводить на всех стадиях разработки, а не только на этапе реализации. Однако природа тестирования на разных этапах разная.
В процессе анализа вы сравниваете модель с ожиданиями пользователя, задавая вопросы и пытаясь обнаружить в модели ответ на них. В процессе проектирования вы тестируете архитектуру и можете моделировать ее производительность. В процессе реализации вы тестируете реальный код, а модель служит для поиска возможных маршрутов прослеживания. При тестировании следует переходить от небольших составляющих ко всему приложению в целом. Разработчикам следует в первую очередь проверять свой собственный код, свои классы и методы.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
