Дж. Рамбо, М. Блаха - UML 2.0 - Объектно-ориентированное моделирование и разработка (1158633), страница 66
Текст из файла (страница 66)
Этот список не может претендовать на полноту: всегда можно придумать какуюто новую архитектуру. Подходы, описанные в этой главе, рассчитаны на небольшие и средние программные проекты. Крупные и сложные системы, в создании которых участвует более десяти разработчиков, ограничены из-за недостатков взаимодействия между людьми, и потому они требуют гораздо более внимательного отношения к логистике. Большая часть рекомендаций, которые мы здесь приводим, применимы не только к объектно-ориентированным системам. 14.1. Обзор проектирования систем В процессе анализа мы сосредоточиваемся на том, что должно быть сделано, и не задумываемся о том, как это следует делать.
В процессе проектирования разработчики принимают решения о том, каким образом они будут решать задачу, сначала на высоком уровне, а потом в деталях. Проектирование системы — это первый этап проектирования, в процессе которого выбирается базовый подход к решению задачи. Разработчики формулируют общую структуру и стиль решения. Архитектура системы определяет ее разбиение 14.2. Оценка производительности 287 на подсистемы. Кроме того, архитектура создает контекст, в котором принимаются последуюшие решения о детальном устройстве системы.
Создание архитектуры требует последовательного выполнения следуюших действий. 1. Оценить производительность системы (раздел 14.2). 2. Составить план повторного использования (раздел 14.3). 3. Разбить систему на подсистемы (раздел 14А). 4. Выявить присущую задаче параллельность (раздел 14.5). 5. Распределить подсистемы по аппаратному обеспечению (раздел 14.6).
6. Спланировать хранилища данных (раздел 14.7). 7. Распределить глобальные ресурсы (раздел 14.8). 8. Выбрать стратегию управления программным обеспечением (раздел 14.9). 9. Обработать пограничные условия (раздел 14.10). 10. Установить приоритеты при компромиссах (раздел 14.11).
11. Выбрать стиль архитектуры (раздел 14.12). Достаточно часто для выбора архитектуры системы можно использовать аналогию с предыдущими системами. Некоторые виды архитектуры применимы к широкому классу задач. В разделе 14.12 мы приводим обзор нескольких наиболее распространенных видов архитектуры вместе с задачами, для решения которых они используются. Не все задачи можно решить с помошью этих видов архитектуры.
Комбинируя их между собой, вы будете получать новые виды архитектуры. 14.2. Оценка производительности На начальном этапе планирования новой системы вы должны провести приближенную оценку ее производительности. Цель состоит не в том, чтобы получить высокую точность оценки, а в том, чтобы определить, реально ли построить нужную систему. Вы можете ошибиться в два раза в ту или иную сторону, обычно такой точности оказывается вполне достаточно. Все зависит от задачи. Расчет должен быть простым и основанным на здравом смысле.
Вам придется делать упрошающие предположения. Не беспокойтесь о деталях: приближайте, оценивайте, а при необходимости — угадывайте нужные значения. Пример с банкоматом. Представим, что мы проектируем сеть банкоматов для одного банка. Действовать можно так. У банка есть 40 филиалов (в каждом должен быть терминал). Предположим, что такое же количество терминалов расположено в супермаркетах н других магазинах. В загруженный день половина терминалов может быть занята одновременно.
(Можно предположить, что все они заняты — результаты от этого изменятся не сильно. Главное — определить приемлемые границы производительности.) Предположим, что каждый клиент завершает один сеанс работы с банкоматом примерно за минуту н большая часть транзакций состоят из одного взноса или снятия денег со счета.
Таким образом, пиковая нагрузка на сеть может составлять около 40 транзакций в минуту или одна транзакция в секунду. Этот результат может быть не очень точным, но он показывает, 288 Глава И «Проектирование системы что нам не потребуется особенно быстродействующее оборудование. Совсем другой результат получился бы, если бы мы оценивали требования к сетевой бирже или к книжному магазину. Для них вычислительная мо~цность компьютеров становится очень важным критерием.
Аналогичным образом можно оценить потребности в хранении данных. Подсчитайте количество клиентов, оцените объем данных для каждого из них и перемножьте полученные величины. Если речь идет о банке, то требования получатся более жесткие, чем к вычислительной могцности компьютеров, но все же их вряд ли можно будет назвать запредельными. Напротив, для спутниковой системы геофотосъемки ключевыми факторами, определяющими архитектуру, будут потребности в хранении данных и в их передаче. 14.3.
Планирование повторного использования Повторное использование часто называется основным преимушеством объектноориентированной технологии, но оно не обеспечивается одним только фактом применения этой технологии. Повторное использование характеризуется двумя существенно разными аспектами: можно использовать существующие вещи, а можно создавать новые с расчетом на повторное использование. Гораздо проще использовать существующее, чем проектировать новое, ориентируясь на неизвестные перспективы повторного использования.
Конечно, чтобы мы сейчас мотли повторно использовать какие-то сущности, кто-то в прошлом должен был их создать. Суть в том, что большинство разработчиков используют существующее, и лишь небольшая их часть создает новое. Не думайте, что вам придется начинать работу с объектно-ориентированными технологиями с создания новых сущностей. Для этого требуется большой опыт. Повторно используемыми бывают модели, библиотеки, каркасы и образцы.
Наиболее практичным можно назвать повторное использование моделей. Логика модели часто бывает применима ко множеству задач. 14.3.1. Библиотеки Библиотека (!! Ьгагу) — это совокупность классов, которые могут оказаться полезными во множестве контекстов. Эта совокупность должна быть хорошо устроена, чтобы пользователи могли искать нужные им классы.
Чтобы построить такую библиотеку, требуется много усилий, и часто бывает трудно решить, где должен быть размещен какой-либо объект. В решении этой задачи может помочь сетевой поиск, но он не заменит хорошей организации библиотеки. Кроме того, классы должны иметь точное и подробное описание, чтобы пользователи могли сами решить, подходят они им или нет.
В книге !Когзоп-92! отмечаются некоторые качества, которыми должны обладать «хорошие» библиотеки классов. ° Цельность. Библиотека классов должна охватывать небольшое количество четко определенных тем. ° Полнота. Библиотека классов должна полностью описывать поведение по выбранным темам. И.З. Планирование повторного использования 289 ° Согласованность.
Полиморфные операции должны обладать одинаковыми именами и сигнатурами в разных классах. ° Эффективность. Библиотека должна предоставлять альтернативные реализации алгоритмов (таких как алгоритмы сортировки), позволяющие выбирать между скоростью и объемом памяти. ° Расширяемость. Пользователь должен иметь возможность определять подклассы классов библиотеки. ° Универсальность. Везде, где это возможно, должны использоваться параметризованные определения классов.
К сожалению, при интеграции библиотек из нескольких источников могут возникать проблемы [Вегйп-901. Разработчики часто размазывают конкретные решения по многим классам в иерархии наследования. Библиотеки классов могут отвечать политикам, имеющим смысл по отдельности, но несовместимым друг с другом. Такие рассогласования трудно устранить, конкретизировав какой- нибудь класс или добавив собственный код. Вместо этого приходится нарушать инкапсуляцию и изменять исходный код.
Эти проблемы настолько серьезны, что именно они фактически ограничивают возможности использования кода из библиотек классов. ° Проверка аргументов. Приложение может проверять аргументы в совокупности или по одному во время их ввода. Групповая проверка подходит для интерфейса командной строки: пользователь вводит все аргументы, и только после этого осуществляется проверка. Активный интерфейс проверяет аргументы по одному или независимыми группами, как только пользователь их вводит. Комбинация библиотек классов, некоторые из которых проверяют аргументы группой, а другие — индивидуально, даст в конечном итоге ужасный пользовательский интерфейс. ° Обработка ошибок.
В разных библиотеках классов используются разные методики обработки ошибок. Методы одной библиотеки могут возвращать код ошибки вызывающей программе, в то время как методы другой библиотеки могут обрабатывать ошибки самостоятельно. ° Парадигмы управления. Приложение может управляться событиями (еоепсг(преп солгто)) или процедурами (ртосеците-г(пвеп салгто!). В первом случае пользовательский интерфейс вызывает методы приложения. Во втором случае приложение вызывает методы пользовательского интерфейса.
Объединить оба типа управления в одном приложении достаточно сложно. ° Групповые операции. Групповые операции часто оказываются неэффективными и неполными. Например, примитив удаления объекта может заблокировать базу данных, произвести удаление, после чего завершить транзакцию. Если вы хотите удалить группу объектов в одной транзакции, библиотека классов должна поддерживать функцию группового удаления. ° Сборка мусора. Библиотеки классов по-разному подходят к управлению выделением памяти и предотвращением ее утечек.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
