Главная - Литература

0 1 2 3 4 5 6 7 8 9 10 11 12 13 [14] 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294

Дмшяшшьные €8еден11я О про*

Производительность

В требованиях следует определить показатели производительности. Если они связаны с использованием ресурсов, актировании высокопроизводи-надо определить приоритеты для разных ресурсов, в том тельных систем см. книгу Конни числе соотношение быстродействия, использования памя- Смит «f*erfoFmance Irineering of ти и затрат. Systems* (ВтШ, 1990).

Архитектура должна включать оценки производительности

и объяснять, почему разработчики архитектуры считают эти показатели достижимыми. Если они могут быть не достигнуты, это тоже должно быть отражено в архитектуре. Если для достижения некоторых показателей требуются специфические алгоритмы или типы данных, также укажите это в спецификации архитектуры. Кроме того, в архитектуре можно указать объем пространства и время, выделяемые каждому классу или объекту.

Масштабируемость

Масштабируемостью называют возможность системы адаптироваться к росту требований. Архитектура должна описывать, как система будет реагировать на рост числа пользователей, серверов, сетевых узлов, записей в БД, транзакций и т. д. Если развитие системы не предполагается и ее масштабируемость не играет роли, это должно быть явно указано в архитектуре.

Взаимодействие с другими системами

Если некоторые данные или ресурсы будут общими для разрабатываемой системы и других программ или устройств, в архитектуре нужно указать, как это будет реализовано.

ченной памяти, архитектура должна также определять способ управления памятью. Архитектура должна включать оценку ресурсов, используемых в номинальном режиме и при экстремальной нагрузке. В простейшем случае эти оценки должны подтвердить, что предполагаемая среда использования приложения будет располагать нужными ресурсами. В более сложной ситуации в приложении, возможно, придется реализовать более активное управление выделенными ему ресурсами. Если это так, архитектуру менеджера ресурсов нужно спроектировать не менее тщательно, чем любой другой компонент системы.

Безопасность

Архитектура должна определять подход к безопасности на

уровне проекта приложения и на уровне кода. Если модель fittp: cc2exom/0S3Q

угроз до дих пор не разработана, это следует сделать при проектировании архитектуры. О безопасности нужно помнить и при разработке принципов кодирования, в том Лшптшшт»щтп\р Г 5 краснбе обсуждение защиты ПО

числе методик обработки буферов и ненадежных данных «ШЮд Secure Code

(данных, вводимых пользователями, файлов «cookie», кон- 24Ы»{НтШШШ\т2Ш)

фигурационных данных и данных других внешних интер- и в тшщкт номере журнала

фейсов), подходов к шифрованию, уровню подробности «1Ш Softwafe> за 2002 год-сообщений об ошибках, защите секретных данных, находящихся в памяти, и другим вопросам.



Интернационализация/локализация

«Интернационализацией» называют реализацию в программе поддержки региональных стандартов. Вместо слова «internationalization» часто используется аббревиатура «118п», составленная из первой и последней букв слова и числа букв между ними. «Локализацией» (известной как «L10n>> по той же причине) называют перевод интерфейса программы и реализацию в ней поддержки конкретного языка.

Вопросы интернационализации заслуживают особого внимания при разработке архитектуры интерактивной системы. Большинство интерактивных систем включает десятки или сотни подсказок, индикаторов состояния, вспомогательных сообщений, сообщений об ошибках и т. д., поэтому нужно оценить объем ресурсов, используемых строками. Если разрабатывается коммерческая программа, архитектура должна показывать, что при ее создании были рассмотрены типичные вопросы, связанные со строками и наборами символов, такие как выбор набора символов (ASCII, DBCS, EBCDIC, MBCS, Unicode, ISO 8859 и т. д.) и типа строк (строки С, строки Visual Basic и т. д.), а также способа изменения строк, который не требовал бы изменения кода, и метода перевода строк на иностранные языки, оказывающего минимальное влияние на код и GUI. Строки можно встроить в код, инкапсулировать в класс и использовать посредством интерфейса или сохранить в файле ресурсов. Архитектура должна объяснять, какой вариант выбран и почему.

Ввод-вывод

Ввод-вывод - еще одна область, на которую стоит обратить внимание при проектировании архитектуры. Архитектура должна определять схему чтения данных: упреждающее чтение, чтение с задержкой или по требованию. Кроме того, она должна описывать уровень, на котором будут определяться ошибки ввода-вывода: на уровне полей, записей, потоков данных или файлов.

Обработка ошибок

Обработка ошибок - одна из самых сложных проблем современной информатики, и к ней нельзя относиться с пренебрежением. По оценкам некоторых ученых код на целых 90% состоит из блоков обработки исключительных ситуаций, ошибок и т. п., из чего следует, что только 10% кода отвечают за номинальный режим работы программы (Shaw in Bentley, 1982). Раз уж на обработку ошибок приходится такая большая часть кода, стратегия их согласованной обработки должна быть выражена в архитектуре.

Обработку ошибок часто рассматривают на уровне конвенции кодирования, если вообще рассматривают. Однако она оказывает влияние на всю систему, поэтому лучше всего рассматривать ее на уровне архитектуры. Вот некоторые вопросы, на которые нужно обратить внимание.

Является ли обработка ошибок корректирующей или ориентированной на их простое обнаружение? В первом случае программа может попытаться восстановиться от последствий ошибки. Во втором - может продолжить работу как ни в чем не бывало или завершиться. Как бы то ни было, она должна известить пользователя об ошибке.



Является ли обнаружение ошибок активным или пассивным? Система может активно предвосхищать ошибки (например, проверяя корректность данных, введенных пользователем) или пассивно реагировать на них только в том случае, если избежать их не удалось (например, когда введенные пользователем данные привели к численному переполнению). В обоих случаях сделанный выбор повлияет на дизайн GUI.

Как программа поступает при обнаружении ошибки? Обнаружив ошибку, программа может отбросить данные, вызвавшие ошибку, может отнестись к ошибке как положено и перейти в состояние обработки ошибки или может выполнить оставшиеся действия и уведомить пользователя о том, что (где-то) были обнаружены ошибки.

Каковы соглашения обработки сообщений об ошибках? Если в спецификации архитектуры не определена единственная согласованная стратегия, GUI покажется непонятной комбинацией разных интерфейсов, относящихся к разным частям программы. Чтобы избежать этого, при проектировании архитектуры нужно определить соглашения вывода сообщений об ошибках.

Как обрабатываются исключения? Архитектура должна определять, когда код может генерировать исключения, где они будут перехватываться, как регистрироваться в журнале, документироваться и т. д.

На каком уровне программы обрабатываются ошибки? щщ иуиа дцц Вы можете обрабатывать их в точке обнаружения, пере- стратегии обработки давать классу обработки ошибок или возвращать по цепи ошибок, который следует рас-вызовов, смотреть на архитектурном

Какова ответственность каждого класса за проверку по- ДО*®» согласованный метод

гг обработки недопустимых пара-

лучаемых данных? Каждый класс отвечает за проверку pg примеры см. в главе 8. собственных данных или есть группа классов, проверяющих данные для всей системы? Могут ли классы конкретного уровня полагать, что полученные ими данные корректны?

Хотите ли вы использовать механизм обработки ошибок, встроенный в среду программирования, или создать собственный? Если в среде реализован конкретный подход к обработке ошибок, это не значит, что он лучше всего соответствует вашим требованиям.

Отказоустойчивость

При разработке архитектуры системы следует указать ожидаемый уровень ее отказоустойчивости. Отказоустойчивостью называют совокупность свойств системы, повышающих ее надежность путем обнаружения ошибок, восстановления, если это возможно, и изоляции их плохих последствий, если восстановление невозможно.

Например, вычисление системой квадратного корня можно сделать отказоустойчивым несколькими способами.

В случае неудачи система может вернуться в предыдущее состояние и попробовать вычислить корень еще раз. Если первый ответ неверен, она может вернуться в состояние, при котором все наверняка было правильно, и продолжить работу с этого момента.



0 1 2 3 4 5 6 7 8 9 10 11 12 13 [14] 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294



0.005