Руководство по стилю программирования и конструированию по
 Скачать 7.6 Mb.
|
|
ГЛАВА 3 Семь раз отмерь, один раз отрежь: предварительные условия 45 ченной памяти, архитектура должна также определять способ управления памя- тью. Архитектура должна включать оценку ресурсов, используемых в номиналь- ном режиме и при экстремальной нагрузке. В простейшем случае эти оценки должны подтвердить, что предполагаемая среда использования приложения бу- дет располагать нужными ресурсами. В более сложной ситуации в приложении, возможно, придется реализовать более активное управление выделенными ему ресурсами. Если это так, архитектуру менеджера ресурсов нужно спроектировать не менее тщательно, чем любой другой компонент системы. Безопасность Архитектура должна определять подход к безопасности на уровне проекта приложения и на уровне кода. Если модель угроз до сих пор не разработана, это следует сделать при проектировании архитектуры. О безопасности нужно по- мнить и при разработке принципов кодирования, в том числе методик обработки буферов и ненадежных данных (данных, вводимых пользователями, файлов «cookie», кон- фигурационных данных и данных других внешних интер- фейсов), подходов к шифрованию, уровню подробности сообщений об ошибках, защите секретных данных, нахо- дящихся в памяти, и другим вопросам. Производительность В требованиях следует определить показатели производи- тельности. Если они связаны с использованием ресурсов, надо определить приоритеты для разных ресурсов, в том числе соотношение быстродействия, использования памя- ти и затрат. Архитектура должна включать оценки производительности и объяснять, почему разработчики архитектуры считают эти показатели дости- жимыми. Если они могут быть не достигнуты, это тоже должно быть отражено в архитектуре. Если для достижения некоторых показателей требуются специфи- ческие алгоритмы или типы данных, также укажите это в спецификации архитек- туры. Кроме того, в архитектуре можно указать объем пространства и время, вы- деляемые каждому классу или объекту. Масштабируемость Масштабируемостью называют возможность системы адаптироваться к росту тре- бований. Архитектура должна описывать, как система будет реагировать на рост числа пользователей, серверов, сетевых узлов, записей в БД, транзакций и т. д. Если развитие системы не предполагается и ее масштабируемость не играет роли, это должно быть явно указано в архитектуре. Взаимодействие с другими системами Если некоторые данные или ресурсы будут общими для разрабатываемой систе- мы и других программ или устройств, в архитектуре нужно указать, как это будет реализовано. http://cc2e.com/0330 Дополнительные сведения Пре- красное обсуждение защиты ПО см. в книге «Writing Secure Code, 2d Ed.» (Howard and LeBlanc 2003) и в январском номере журнала «IEEE Software» за 2002 год. Дополнительные сведения О про- ектировании высокопроизводи- тельных систем см. книгу Конни Смит «Performance Engineering of Software Systems» (Smith, 1990). 4 6 ЧАСТЬ I Основы разработки ПО Интернационализация/локализация «Интернационализацией» называют реализацию в программе поддержки региональ- ных стандартов. Вместо слова «internationalization» часто используется аббревиату- ра «I18n», составленная из первой и последней букв слова и числа букв между ними. «Локализацией» (известной как «L10n» по той же причине) называют перевод интер- фейса программы и реализацию в ней поддержки конкретного языка. Вопросы интернационализации заслуживают особого внимания при разработке архитектуры интерактивной системы. Большинство интерактивных систем вклю- чает десятки или сотни подсказок, индикаторов состояния, вспомогательных со- общений, сообщений об ошибках и т. д., поэтому нужно оценить объем ресурсов, используемых строками. Если разрабатывается коммерческая программа, архитек- тура должна показывать, что при ее создании были рассмотрены типичные вопро- сы, связанные со строками и наборами символов, такие как выбор набора симво- лов (ASCII, DBCS, EBCDIC, MBCS, Unicode, ISO 8859 и т. д.) и типа строк (строки C, строки Visual Basic и т. д.), а также способа изменения строк, который не требовал бы изменения кода, и метода перевода строк на иностранные языки, оказывающе- го минимальное влияние на код и GUI. Строки можно встроить в код, инкапсули- ровать в класс и использовать посредством интерфейса или сохранить в файле ресурсов. Архитектура должна объяснять, какой вариант выбран и почему. Ввод-вывод Ввод-вывод — еще одна область, на которую стоит обратить внимание при про- ектировании архитектуры. Архитектура должна определять схему чтения данных: упреждающее чтение, чтение с задержкой или по требованию. Кроме того, она должна описывать уровень, на котором будут определяться ошибки ввода-выво- да: на уровне полей, записей, потоков данных или файлов. Обработка ошибок Обработка ошибок — одна из самых сложных проблем современной ин- форматики, и к ней нельзя относиться с пренебрежением. По оценкам некоторых ученых код на целых 90% состоит из блоков обработки ис- ключительных ситуаций, ошибок и т. п., из чего следует, что только 10% кода от- вечают за номинальный режим работы программы (Shaw in Bentley, 1982). Раз уж на обработку ошибок приходится такая большая часть кода, стратегия их согла- сованной обработки должна быть выражена в архитектуре. Обработку ошибок часто рассматривают на уровне конвенции кодирования, если вообще рассматривают. Однако она оказывает влияние на всю систему, поэтому лучше всего рассматривать ее на уровне архитектуры. Вот некоторые вопросы, на которые нужно обратить внимание. 쐽 Является ли обработка ошибок корректирующей или ориентированной на их простое обнаружение? В первом случае программа может попытаться восста- новиться от последствий ошибки. Во втором — может продолжить работу как ни в чем не бывало или завершиться. Как бы то ни было, она должна извес- тить пользователя об ошибке. ГЛАВА 3 Семь раз отмерь, один раз отрежь: предварительные условия 47 쐽 Является ли обнаружение ошибок активным или пассивным? Система может активно предвосхищать ошибки (например, проверяя корректность данных, введенных пользователем) или пассивно реагировать на них только в том случае, если избежать их не удалось (например, когда введенные пользователем дан- ные привели к численному переполнению). В обоих случаях сделанный вы- бор повлияет на дизайн GUI. 쐽 Как программа поступает при обнаружении ошибки? Обнаружив ошибку, про- грамма может отбросить данные, вызвавшие ошибку, может отнестись к ошибке как положено и перейти в состояние обработки ошибки или может выполнить оставшиеся действия и уведомить пользователя о том, что (где-то) были обна- ружены ошибки. 쐽 Каковы соглашения обработки сообщений об ошибках? Если в спецификации архитектуры не определена единственная согласованная стратегия, GUI пока- жется непонятной комбинацией разных интерфейсов, относящихся к разным частям программы. Чтобы избежать этого, при проектировании архитектуры нужно определить соглашения вывода сообщений об ошибках. 쐽 Как обрабатываются исключения? Архитектура должна определять, когда код может генерировать исключения, где они будут перехватываться, как регист- рироваться в журнале, документироваться и т. д. 쐽 На каком уровне программы обрабатываются ошибки? Вы можете обрабатывать их в точке обнаружения, пере- давать классу обработки ошибок или возвращать по цепи вызовов. 쐽 Какова ответственность каждого класса за проверку по- лучаемых данных? Каждый класс отвечает за проверку собственных данных или есть группа классов, проверя- ющих данные для всей системы? Могут ли классы кон- кретного уровня полагать, что полученные ими данные корректны? 쐽 Хотите ли вы использовать механизм обработки ошибок, встроенный в среду программирования, или создать собственный? Если в среде реализован кон- кретный подход к обработке ошибок, это не значит, что он лучше всего соот- ветствует вашим требованиям. Отказоустойчивость При разработке архитектуры системы следует указать ожидаемый уровень ее отка- зоустойчивости. Отказоустойчивостью называют совокупность свойств системы, по- вышающих ее надежность путем обнаружения ошибок, восстановления, если это возможно, и изоляции их плохих последствий, если восстановление невозможно. Например, вычисление системой квадратного корня можно сделать отказоустой- чивым несколькими способами. 쐽 В случае неудачи система может вернуться в предыдущее состояние и попро- бовать вычислить корень еще раз. Если первый ответ неверен, она может вер- нуться в состояние, при котором все наверняка было правильно, и продолжить работу с этого момента. Перекрестная ссылка Еще один аспект стратегии обработки ошибок, который следует рас- смотреть на архитектурном уровне, — согласованный метод обработки недопустимых пара- метров. Примеры см. в главе 8. 4 8 ЧАСТЬ I Основы разработки ПО 쐽 Система может включать вспомогательный код, выпол- няемый при обнаружении ошибки в основном коде. Так, если первый ответ кажется ошибочным, система может переклю- читься на альтернативный метод вычисления квадратного корня. 쐽 Система может применять алгоритм голосования. Она может включать три класса, вычисляющих квадратный ко- рень разными способами. Каждый класс вычисляет квадрат- ный корень, после чего система сравнивает полученные результаты. В зависимости от реализованного типа отказоустойчивости сис- тема может использовать среднее, срединное или наиболее вероятное значе- ние из трех. 쐽 Система может заменять ошибочное значение поддельным значением, кото- рое положительно скажется на работе оставшейся части системы. Другими подходами к отказоустойчивости являются перевод системы при обна- ружении ошибки в состояние частичной работоспособности или ограниченной фунциональности. Система может отключиться или автоматически перезапустить себя. Конечно, эти примеры упрощены. Отказоустойчивость — захватывающая и сложная область, но не она является темой этой книги. Возможность реализации архитектуры Разработчики могут сомневаться в том, способна ли система достигнуть заданных показателей производительности, работать при ограниченности ресурсов и бу- дет ли она адекватно поддержана средами реализации. Архитектура должна под- тверждать, что система технически осуществима. Если невозможность реализации какого-то компонента может сделать проект неработоспособным, в архитектуре должно быть отражено, как изучались эти вопросы: при помощи прототипов, исследований или иначе. Эти аспекты риска следует устранить до начала полно- масштабного конструирования. Избыточная функциональность Надежностью называют способность системы продолжать работу после обнару- жения ошибки. Частенько в спецификации архитектуры разработчики определя- ют более надежную систему, чем указано в требованиях. Одна из причин этого в том, что система, состоящая из многих частей, удовлетворяющих минимальным требованиям к надежности, в целом может оказаться менее надежной, чем нуж- но. В мире ПО цепь не так крепка, как слабейшее звено; она так слаба, как все слабые звенья, вместе взятые. В спецификации архитектуры должно быть явно указано, могут ли программисты реализовать в своих блоках программы избыточную фун- кциональность или они должны создать простейшую работоспособную систему. Определить отношение к реализации избыточной функциональности особенно важно потому, что многие программисты делают это автоматически, из чувства профессиональной гордости. Явно выразив ожидания в архитектуре, вы сможете избежать феномена, при котором некоторые классы исключительно надежны, а другие лишь отвечают требованиям. Дополнительные сведения Хо- рошее введение в вопросы от- казоустойчивости см. в июльс- ком номере журнала «IEEE Soft- ware» за 2001 год. Кроме того, в статьях этого номера есть ссылки на многие отличные книги и статьи, посвященные данной теме. ГЛАВА 3 Семь раз отмерь, один раз отрежь: предварительные условия 49 Купить или создавать самим? Самый радикальный подход к созданию ПО — не создавать его вообще, а купить или загрузить из Интернета бесплат- ное ПО с открытым исходным кодом. Вы можете приобре- сти элементы управления GUI, менеджеры БД, процессоры изображений, компоненты для работы с графикой и диа- граммами, компоненты для коммуникации по Интернету, компоненты обеспечения безопасности и шифрования, обработки электронных таблиц и текста — список почти бесконечен. Одним из главных достоинств про- граммирования с использованием современных GUI-сред является объем функ- циональности, который вы получаете автоматически: классы для работы с графи- кой, менеджеры диалоговых окон, обработчики событий клавиатуры и мыши, код, поддерживающий любые принтеры и мониторы и т. д. Если архитектура не подразумевает применение готовых компонентов, она дол- жна объяснять, в каких аспектах компоненты, которые будут разработаны, ока- жутся лучше готовых библиотек и компонентов. Повторное использование Если план предусматривает применение существующего кода, тестов, форматов данных и т. д., архитектура должна объяснять, как повторно использованные ре- сурсы будут адаптированы к другим архитектурным особенностям, если это бу- дет сделано. Стратегия изменений Так как при создании продукта и программисты, и пользо- ватели обучаются, приложение скорее всего в период разра- ботки будет изменяться. Причинами этого могут быть изме- нения типов данных, форматов файлов, функциональности, реализация новых функций и т. д. Изменения могут быть новыми возможностями, которые были запланированы заранее или не были реализованы в первой версии системы. Поэтому разработчику архитектуры ПО следует сделать ее достаточно гибкой, чтобы в систему можно было легко внести вероятные изменения. Архитектура должна четко описывать стратегию изменений. Архитектура должна показывать, что возможные улучшения рассматривались и что реализация наиболее вероятных улучшений окажется наиболее простой. Если вероятны из- менения форматов ввода или вывода данных, стиля взаимо- действия с пользователями или требований к обработке, архитектура должна показывать, что все эти изменения были предвосхищены и каждое из них будет ограничено неболь- шим числом классов. Архитектурный план внесения изме- нений может быть совсем простым: включить в файлы данных номера версий, за- резервировать поля на будущее, спроектировать файлы так, чтобы в них можно было добавить новые таблицы и т. д. Если применяется генератор кода, архитек- тура должна показывать, что он поддерживает возможность внесения предпола- гаемых изменений. Перекрестная ссылка Список типов коммерческих программ- ных компонентов см. в подраз- деле «Библиотеки кода» разде- ла 30.3. Перекрестная ссылка О систе- матичной обработке изменений см. раздел 28.2. Ошибки проектирования часто являются довольно тонкими и объясняются эволюцией, при которой по мере реализации новых функций и возможностей разработчики забывают о сде- ланных ранее предположениях. Фернандо Дж. Корбати (Ferrnando J. Corbatу) 5 0 ЧАСТЬ I Основы разработки ПО В архитектуре должны быть отражены стратегии, которые позволяют программистам не ограничивать имеющийся у них выбор раньше времени. Так, архитектура может опре- делять, что вместо жестко закодированных тестов if будет применяться метод, основанный на проверке таблиц. Дан- ные таблиц можно хранить во внешнем файле, а не вклю- чать в программу, что позволит вносить в нее изменения без перекомпиляции. Общее качество архитектуры Хорошая спецификация архитектуры должна описывать классы системы, инфор- мацию, скрываемую каждым классом, и обосновывать принятые и отвергнутые варианты проекта системы. Архитектура должна быть продуманным концептуальным целым, включающим несколько специфических дополнений. Главный тезис самой популярной книги по разработке ПО «Мифический человеко-месяц» гласит, что основной пробле- мой, характерной для крупных систем, является поддержание их концептуальной целостности (Brooks, 1995). Хорошая архитектура должна соответствовать про- блеме. Изучая архитектуру, вы должны испытывать удовольствие от того, насколько естественным и простым кажется решение. Вам должно казаться, что проблема и архитектура неразрывно связаны. Вам следует знать, как архитектура изменялась во время ее проектирования. Каж- дое изменение должно быть четко согласовано с общей концепцией. Архитекту- ра не должна быть похожа на проект бюджета Конгресса США, предусматриваю- щий расходы на мероприятия, повышающие популярность чиновников. Цели архитектуры должны быть четко сформулированы. Проект системы, глав- ным требованием к которой является модифицируемость, будет отличаться от проекта системы, которая должна показывать высочайшую производительность, даже если по функциональности обе системы будут одинаковы. В архитектуре должны быть обоснованы важнейшие принятые решения. С подо- зрением относитесь к обоснованиям из разряда «мы всегда так делали». Здесь уместно вспомнить одну поучительную историю. Бет хотела приготовить туше- ное мясо по прославленному рецепту, передававшемуся из поколения в поколе- ние в семье ее мужа Абдула. Абдул сказал, что его мать солила кусок мяса, перчи- ла, обрезала его края, укладывала в горшок, закрывала и ставила в духовку. На вопрос Бет «Зачем обрезать оба края?» Абдул ответил: «Не знаю, я всегда так делал. Спро- шу у мамы». Он позвонил ей и услышал: «Не знаю, просто я так всегда делала. Спрошу у твоей бабушки». А бабушка заявила: «Понятия не имею, почему вы так делаете. Я делала так потому, что мой горшок был маловат». Хорошая архитектура ПО не зависит ни от платформы, ни от языка. Пожалуй, вы не сможете проигнорировать среду конструирования, однако максимальная не- зависимость от среды позволит вам устоять перед соблазном создать слишком подробную архитектуру и избежать работы, которую лучше выполнять во время конструирования. Если программа ориентирована на конкретную платформу или должна быть разработана на конкретном языке, это правило неактуально. Перекрестная ссылка О мерах, позволяющих не ограничивать возможность выбора, см. под- раздел «Тщательно выбирайте время связывания» раздела 5.3. Перекрестная ссылка О соотно- шении атрибутов качества см. раздел 20.1. |