Дж. Рамбо, М. Блаха - UML 2.0 - Объектно-ориентированное моделирование и разработка (1158633), страница 80
Текст из файла (страница 80)
Проектирование — это подбор оптимального соотношения составляющих. Пример с банкоматом. Мы уже упомянули некоторые важные механизмы. Системе требуется коммуникационная и распределительная инфраструктура. Компьютеры банков и банкоматы находятся в разных местах и при этом должны быстро и эффективно взаимодействовать между собой. Более того, архитектура должна быть устойчива к ошибкам и сбоям на линии. 15.6. Реорганизация Исходный проект набора операций неизбежно будет несогласованным, избыточным и неэффективным.
Это естественно, потому что большой проект невозможно разработать правильно с первого раза. Вам приходится принимать решения, которые связаны с другими решениями. Неважно, в каком порядке вы будете это делать, — некоторые решения окажутся не вполне оптимальными. Более того, эволюция проекта одновременно приводит к его деградации. Хорошо, когда операцию или класс можно использовать в нескольких целях. Однако созданная с одной целью операция не может идеально подходить для другой цели. Вы должны пересмотреть свой проект и переработать классы и операции таким образом, чтобы они удовлетворяли всем поставленным целям и были цельными с концептуальной точки зрения. В противном случае приложение получится хрупким, запутанным, неудобным для расширения и обслуживания и в конце концов рухнет под собственным весом.
Марти Фаулер [Роч~!ег-99! определяет реорганизацию (ге(асгог!пй) как изменение внутренней структуры программного обеспечения для усовершенствования проекта без изменения внешней функциональности. Фактически, вы должны отступить на шаг, рассмотреть все множество классов и операций и реорганизовать их так, чтобы облегчить дальнейшую разработку. Реорганизация может показаться вам пустой тратой времени, но она является важной частью любого хорошего инженерного процесса. Недостаточно просто обеспечить нужную функциональность. Если вы планируете в дальнейшем о(клуживать собственную систему, вы должны сделать ее проект ясным, понятным и разбитым на отдельные модули. Реорганизация позволяет сохранить жизнеспособность проекта в процессе разработки.
Пример с банкоматом. В разделе 15.4А мы рассматривали операции варианта использования ргосезз гталзасйоп (обработка транзакции). Очевидное действие на этапе реорганизации — объединение Ассоиш.стей~(атоипг) и Ассоиш.г(еЫ(атоипг) в одну операцию Ассоилг.розг(атоипг) (изменение суммы на счете). Дополнительные возможности реорганизации откроются после формулирования операций для других вариантов использования. 336 Глава 15 ° Проектирование классов 15.7. Оптимизация проекта Чтобы спроектировать систему, нужно сначала правильно определить логику ее работы, а затем выполнить оптимизацию.
Дело в том, что оптимизировать проект непосредственно в процессе разработки достаточно сложно. Более того, если начать заботиться об эффективности слишком рано, проект получится неудачным. После того как логика будет готова, вы сможете запустить приложение, измерить его производительность, а затем заняться тонкой настройкой. Чаще всего большую часть времени выполняется небольшой участок кода, который и нужно оптимизировать. Лучше сосредоточить усилия на небольших составляюших приложения, чем распределять их равномерно. Сказанное не означает, что нужно полностью забывать об эффективности на ранних этапах проектирования. Неэффективность некоторых подходов может быть настолько очевидна, что вы даже не будете их рассматривать.
Если существует ясный, простой и эффективный способ разработать что-либо — воспользуйтесь им. Но не используйте сложных и неестественных подходов только из-за беспокойства о возможных проблемах с производительностью. Сначала нужно сделать так, чтобы простой проект заработал.
Потом его можно будет оптимизировать. Тогда может обнаружиться, что проблема была совсем не в том месте, о котором вы беспокоились. Проектная модель строится на основе аналитической модели. Аналитическая модель описывает логику приложения, а проектная модель добавляет к ней детали, относящиеся к вопросам разработки. Вы можете оптимизировать неэффективную, но при этом семантически корректную аналитическую модель для повышения производительности, но оптимизированная система будет менее понятной и будет иметь меньше шансов на повторное использование.
Вы должны выдерживать баланс между эффективностью и ясностью. Оптимизация проекта включает в себя следующие задачи: ° предоставление эффективных путей доступа; ° реорганизация вычислений для повышения производительности; ° сохранение промежуточных результатов для исключения необходимости повторного вычисления. 15.7.1. Добавление избыточных ассоциаций для повышения эффективности доступа Наличие избыточных ассоциаций в модели на этапе анализа нежелательно, поскольку они не несут в себе никакой добавочной информации. Однако цели проектирования отличаются от целей анализа: главной задачей становится обеспечение реализации приложения.
Можно ли реорганизовать ассоциации для оптимизации критических участков системы? Нужно ли добавить новые ассоциации? Ассоциации аналитической модели могут образовывать далеко не самую эффективную сеть с учетом статистики обращений и их относительных частот. Рассмотрим проект базы данных о профессиональных качествах сотрудников компании. На рис.
15.5 показана часть аналитической модели классов. Операция 15.7. Оптимизация проекта 337 Сотралу~тгУБЫИО возвращает множество сотрудников компании, обладающих заданным качеством. Например, приложению может потребоваться список всех сотрудников, умеющих говорить на японском языке.
Етр/оуз НазЯМ! Сошралу , Регзол, , аып Рмс. 1б.б. Аналитическая модель базы данных о сотрудниках Предположим, что в компании работает 1000 сотрудников, каждый из которых в среднем обладает десятью качествами. Простой вложенный цикл должен будет 1000 раз проследить ассоциацию Етр!оуз (ДержитНаСлужбе) и 10 000 раз проследить ассоциацию НазБЫП (ОбладаетКачеством). Если на японском языке говорят только 5 сотрудников, отношение общего числа проверок к числу успешных будет 2000. В эту модель можно внести несколько усовершенствований. Например, для реализации Наз5Ы! можно использовать хэш, а не простой неупорядоченный список. Операция может выполнять хэшированне за постоянное время, поэтому стоимость проверки наличия данного качества тоже будет постоянной (при условии, что существует только один объект 5Ы( для качества зреаЬ /аралезе (говорит по-японски)).
Такая схема сокращает количество проверок с 10 000 до 1000 (по одному на каждого сотрудника). В случае когда количество успешных результатов, возвращаемых запросом, не будет большим, потому что лишь малая доля объектов удовлетворяет условию проверки, доступ к объектам можно ускорить при помощи индексирования (1пг1ех). Например, на рис.
15.6 добавлена выводимая ассоциация БреаЫллйиаде (ГоворитНаЯзыке) между классами Сотрапу (Компания) и Релюп (Сотрудник), в которой квалификатором является язык. Выводимая ассоциация не добавляет в модель новой информации, но она помогает быстро обращаться к сотрудникам, разговаривающим на конкретном языке. Индексирование требует определенных затрат памяти. Его приходится выполнять каждый раз при обновлении базовых ассоциаций. Необходимосп построения индекса должен определять именно проектировщик. Учтите, что если в большинстве случаев в ответах на запросы присутствует значительная доля объектов, индекс не дает существенной экономии времени поиска.
lэреаззсалдоаде Рис. Хб.б. Усовершенствованная модель с выводимой ассоциацией Вы должны исследовать каждую операцию и выяснить, какие ассоциации прослеживает эта операция для получения необходимых данных. Затем для каждой операции нужно оценить следующие параметры. ° Частота обращения. Как часто вызывается эта операция? ° Веерность. Какова степень веерности маршрута в модели? Оцените сред- нее значение элементов в каждой из ассоциаций с кратностью «много». 338 Глава 15 ° Проектирование классов Перемножьте эти величины, чтобы получить веерность всего маршрута. Связи с кратностью «один» не увеличивают веерности, но они несколько повышают стоимость отдельной операции; о таких небольших эффектах беспокоиться не следует.
° Избирательность. Какова доля «попаданий» в конечном классе? Какая доля объектов удовлетворяет критерию поиска? Если в результате прослеживания отбрасывается большая часть объектов, простой вложенный цикл может быть недостаточно эффективным решением. Для часто вызываемых операций с малой долей возвращаемых результатов нужно обеспечивать индексирование, потому что реализация таких операций с использованием вложенных циклов будет неэффективной. Пример с банкоматом.
В комментарии к операции розгТтатасгюпО в разделе 15А.4 мы решили связать Весе~рг (Чек) и СахАСагН (БанковскаяКарта). Однако нам может потребоваться быстро найти клиента по его чеку. Поскольку прослеживание от СазлСапl (БанковскаяКарта) к Сагг(Аигйогпагюп (КартаАвторизации) не имеет веерности, поиск будет быстрым, а, следовательно, добавлять выводимую ассоциацию необходимости нет. В США банки должны докладывать об операциях с суммами более 10 000 наличными правительству. Мы люгли бы выполнить прослеживание от Валя (Банк) к Ассоилг (Счет), затем от Ассоилг к Правоте (Обновление) и отфильтровать операции с наличными, сумма которых превышает 10 000 долларов. Однако тут нам потребовалось бы уточнить модель классов, чтобы отличать операции с наличными от безналичных. Мы могли бы расширить определение Ыий, чтобы отличать наличные операции от безналичных.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
